Open almightyBeck opened 4 years ago
1. sprint的目标管理 Q：在product backlog中，每一项都包含其value以及effort的预估，并且根据这些预估结果对它们进行排序。那么如果在设置完Sprint Goal后再选择当前Sprint需要完成的任务对话，是否会造成一些高优先级的任务的推迟以及可以选择的任务的数量受到限制？例如：设置当前的Sprint Goal为将日活数提高10%，但是在当前的product backlog中只有一个优先级高的项与这个目标相关。 A.sprint的目标一定是当前最紧急的，如果pb里和这个目标相关的条目优先级不高的话，应该先进行pb的梳理，调整优先级了 2.DOD的定义 Q：关于define of done. 我也有一点疑问，这个算是stop work的标准吗？达成了这些就可以算一个sprint结束。 A：DoD是用来评审完成的任务是否处于releasable状态的，作用的对象是每个任务而不是一个sprint 3.活动分享方 Q：各位敏捷家人，你们有没有想听哪个公司，或者团队的案例分享？ A：想听听几家互联网巨头的案例分享，阿里，腾讯，头条，快手，滴滴，美团等这几家 4.职业规划 Q：一直做制造业产品类的项目管理 想转行做软件类项目管理 不懂程序语言方面的知识 怎样才能入行 需要自学哪些方面的知识？ A：不需要懂语言，先看懂《敏捷项目管理》，以及《Scrum精髓》 5.Scrum Master的职责 Q：Scrum Master是应该在公司和团队呆在一起？ 是否需要和产品一起跑现场和业务？ A5-1.应该是发起人关注的吧，SM关注交付给发起人 A5-2.没有特定的规则 A5-3.感觉跑客户现场的是PM，不是SM 6.角色的划分 Q：我观察到的发起人通常没有精力写需求、原型图和产品设计文档，所以，有些组织还有一个中间人，就是专门负责写需求、原型图和产品设计文档的角色，而这个人在产品营销和业务干系人方面就会比较弱一些，然后呢，随着这个中间人的发展和成长，他又要配一个助理，专门给他处理文档文字工作，然后用户价值的传递就变成了三个人，发起人---》中间人---》助理，他们三个人共同组成了PO的角色。发起人：关注市场和客户、利润和营销 中间人：关注传递发起人的需求和做功能设计 助理：关注把需求细化成文档 A6-1,发起人更像是领域专家。中间人就是代理PO，如果代理PO足够强，就够了。代理PO还要请人写文档也是醉了。迭代插入紧急待办项的事情，这个提前约定好WIP的限制，也是开工前沟通，达成一致的过程。 A6-2.因为我们平常所讨论的关于敏捷其实在delivery level，并不能应用在对项目的指导和管理层上，你提的这个问题恰好就是完整的项目管理过程中会遇到的，可以了解一下PRINCE2 Agile框架 A6-3.整体来说，大家没有对一起做的这件事情的最终目的对焦过，项目规划出了问题 A6-4.你描述的这个和PRINCE2框架的结构十分相似，或者说是其简化版。发起人是整个project board，产品为PO，助理是SME。在大型项目中，每个角色分布在不同的层级，所具备的权利和对应的责任也不同，这是一个目标拆解的过程 7.PO与Scrum Master的区别 Q：所以很多公司不是缺Scrum Master，缺的是有能力的PO Master；领域专家+业务模式专家 A7.PO 有行业局限，SM 没有 8.优先级排序与调整 Q：优先级排序，其实才是最困难的事情，简单的一个优先级排序，那背后是5年以上的行业背景深耕，和市场敏感度 A8-1.用户一般都不管，所有必须一起做 A8-2.这个可以通过需求拆分的方式解决吗？让需求颗粒度变小，交付周期变短，优先级排序次数变多，被动调整优先级变成主动调整优先级 A8-3.个人理解，优先级排序，只是团队持续快速高质量交付有用价值的一个工具。团队在迭代中能承接的需求，是需要多种因素平衡的结果。不过这个工具充分利用起来，有利于针对紧急需求的管控。不过最终都需要团队达成共识。 A8-4.我理解重点是节奏一定要控制好，节奏不对，也会出乱子，一周一排序应该是非常快了 9.优先级排序与调整 Q：排了优先级又能咋样？大部分团队对优先级是没法的，一人一个模块，你干你的，我干我的，你有优先级也没用 A9.我们团队现在就是一周排一次需求优先级，需求颗粒度控制在2周内完成，很多需求是小的，可以在一周内完成，那就能来接新的优先级高的需求了。 10.优先级排序与调整 Q：来了新任务插入，马上把优先级低的换出去。是这个意思吗 A10.开始开发的需求尽量不要叫停，而是去替换没有开发的列表里高优先级的需求 11.敏捷测试 Q：但是测试很痛苦，特别是那种，开发做了已经合并到release了，新的需求来了，立即开发新的。这时候是停下原先的工作，重新做澄清和计划、用例设计？ 还有一种是测试已经测完了，版本还没稳定，立马又来了新需求，测试又得从头测试。这时候可以重复跑的自动化测试就很重要了。 A11.这时候CICD就很重要了 12.技术债与质量 Q：如果需求变得很快，开发基本上就不怎么考虑质量。因为开发弹性很大，一个功能做8小时可以考虑很多耦合、性能问题；但是你只给他2小时，她也能做，但就会埋下很多技术债 A12.如果有CICD，技术就是自己玩自己 13.业务与开发效率质量 Q：明明是业务没理顺，非要说开发效率不高，质量低 A13.这种在评审需求的时候就应该发现一部分，不是等到开发过程中才发现有逻辑问题 14.业务与开发效率质量 Q：单纯的追求交付速度 不意味着效率高，在时间压迫的情况下，很多技术方案并不完善，后续还要不断的优化；而很多业务发展，并不一定会给技术重构或优化的时间 A14.技术债也是需求之一
1. sprint的目标管理 Q：在product backlog中，每一项都包含其value以及effort的预估，并且根据这些预估结果对它们进行排序。那么如果在设置完Sprint Goal后再选择当前Sprint需要完成的任务对话，是否会造成一些高优先级的任务的推迟以及可以选择的任务的数量受到限制？例如：设置当前的Sprint Goal为将日活数提高10%，但是在当前的product backlog中只有一个优先级高的项与这个目标相关。 A.sprint的目标一定是当前最紧急的，如果pb里和这个目标相关的条目优先级不高的话，应该先进行pb的梳理，调整优先级了 2.DOD的定义 Q：关于define of done. 我也有一点疑问，这个算是stop work的标准吗？达成了这些就可以算一个sprint结束。 A：DoD是用来评审完成的任务是否处于releasable状态的，作用的对象是每个任务而不是一个sprint 3.活动分享方 Q：各位敏捷家人，你们有没有想听哪个公司，或者团队的案例分享？ A：想听听几家互联网巨头的案例分享，阿里，腾讯，头条，快手，滴滴，美团等这几家 4.职业规划 Q：一直做制造业产品类的项目管理 想转行做软件类项目管理 不懂程序语言方面的知识 怎样才能入行 需要自学哪些方面的知识？ A：不需要懂语言，先看懂《敏捷项目管理》，以及《Scrum精髓》 5.Scrum Master的职责 Q：Scrum Master是应该在公司和团队呆在一起？ 是否需要和产品一起跑现场和业务？ A5-1.应该是发起人关注的吧，SM关注交付给发起人 A5-2.没有特定的规则 A5-3.感觉跑客户现场的是PM，不是SM 6.角色的划分 Q：我观察到的发起人通常没有精力写需求、原型图和产品设计文档，所以，有些组织还有一个中间人，就是专门负责写需求、原型图和产品设计文档的角色，而这个人在产品营销和业务干系人方面就会比较弱一些，然后呢，随着这个中间人的发展和成长，他又要配一个助理，专门给他处理文档文字工作，然后用户价值的传递就变成了三个人，发起人---》中间人---》助理，他们三个人共同组成了PO的角色。发起人：关注市场和客户、利润和营销 中间人：关注传递发起人的需求和做功能设计 助理：关注把需求细化成文档 A6-1,发起人更像是领域专家。中间人就是代理PO，如果代理PO足够强，就够了。代理PO还要请人写文档也是醉了。迭代插入紧急待办项的事情，这个提前约定好WIP的限制，也是开工前沟通，达成一致的过程。 A6-2.因为我们平常所讨论的关于敏捷其实在delivery level，并不能应用在对项目的指导和管理层上，你提的这个问题恰好就是完整的项目管理过程中会遇到的，可以了解一下PRINCE2 Agile框架 A6-3.整体来说，大家没有对一起做的这件事情的最终目的对焦过，项目规划出了问题 A6-4.你描述的这个和PRINCE2框架的结构十分相似，或者说是其简化版。发起人是整个project board，产品为PO，助理是SME。在大型项目中，每个角色分布在不同的层级，所具备的权利和对应的责任也不同，这是一个目标拆解的过程 7.PO与Scrum Master的区别 Q：所以很多公司不是缺Scrum Master，缺的是有能力的PO Master；领域专家+业务模式专家 A7.PO 有行业局限，SM 没有 8.优先级排序与调整 Q：优先级排序，其实才是最困难的事情，简单的一个优先级排序，那背后是5年以上的行业背景深耕，和市场敏感度 A8-1.用户一般都不管，所有必须一起做 A8-2.这个可以通过需求拆分的方式解决吗？让需求颗粒度变小，交付周期变短，优先级排序次数变多，被动调整优先级变成主动调整优先级 A8-3.个人理解，优先级排序，只是团队持续快速高质量交付有用价值的一个工具。团队在迭代中能承接的需求，是需要多种因素平衡的结果。不过这个工具充分利用起来，有利于针对紧急需求的管控。不过最终都需要团队达成共识。 A8-4.我理解重点是节奏一定要控制好，节奏不对，也会出乱子，一周一排序应该是非常快了 9.优先级排序与调整 Q：排了优先级又能咋样？大部分团队对优先级是没法的，一人一个模块，你干你的，我干我的，你有优先级也没用 A9.我们团队现在就是一周排一次需求优先级，需求颗粒度控制在2周内完成，很多需求是小的，可以在一周内完成，那就能来接新的优先级高的需求了。 10.优先级排序与调整 Q：来了新任务插入，马上把优先级低的换出去。是这个意思吗 A10.开始开发的需求尽量不要叫停，而是去替换没有开发的列表里高优先级的需求 11.敏捷测试 Q：但是测试很痛苦，特别是那种，开发做了已经合并到release了，新的需求来了，立即开发新的。这时候是停下原先的工作，重新做澄清和计划、用例设计？
还有一种是测试已经测完了，版本还没稳定，立马又来了新需求，测试又得从头测试。这时候可以重复跑的自动化测试就很重要了。 A11.这时候CICD就很重要了 12.技术债与质量 Q：如果需求变得很快，开发基本上就不怎么考虑质量。因为开发弹性很大，一个功能做8小时可以考虑很多耦合、性能问题；但是你只给他2小时，她也能做，但就会埋下很多技术债 A12.如果有CICD，技术就是自己玩自己 13.业务与开发效率质量 Q：明明是业务没理顺，非要说开发效率不高，质量低 A13.这种在评审需求的时候就应该发现一部分，不是等到开发过程中才发现有逻辑问题 14.业务与开发效率质量 Q：单纯的追求交付速度 不意味着效率高，在时间压迫的情况下，很多技术方案并不完善，后续还要不断的优化；而很多业务发展，并不一定会给技术重构或优化的时间 A14.技术债也是需求之一