敏捷团队怎么做，能让你的PO随叫随到
干货 | 《重构》都不如这七种武器“速效”
2019年7月16日
质量速度二选一？
2019年7月29日
前言
Preface
2.Sprint Planning meeting总超时怎么办？
3.Product Owner 跟团队在不同时区，如何让他更“Available to team”（能够被团队找到）？
“普通文档和敏捷文档的差别”以及“用户故事中‘why’的两个常见错误”中提到的敏捷方法设计细节，可以帮助PO和团队更容易的沟通彼此的想法，减少沟通的时间，降低沟通误解率。
“写好敏捷文档，让需求分析人员（BA）失业” 中提到的设计细节，能减少PO书写需求文档的工作量，让需求文档的描述更加准确。
“这么写敏捷文档，让BA/PO不再‘瞎’忙！”中提到的设计细节，则会通过实验性的方式尽早暴露一些对客户没有价值的需求，并移除他们，节省PO在需求沟通，分析，文档书写方面的精力。
如果上面这些细节在敏捷实施的过程中得到了很好的执行，那么PO的工作量能至少减少50%。这50%并不是提升PO效率而得来的，而是将工作流程和沟通方式中的浪费消除掉，从而节省出来的。我们把PO从这些不贡献价值的工作中解救出来，他自然就可以更有时间对团队“Available”。
很多团队在实施Scrum的时候，只注意到了宏观的流程及会议，并没有注意到Scrum对每个事件如何执行都设计有非常详尽的细节，每一个细节的背后，都对应要解决的IT项目团队中常见的问题。而这些细节在执行过程中的彰显，才是让Scrum真正发挥威力的关键所在。
- 选择适当数量的User Story，确定Sprint的工作范围。
- PO与团队围绕被选择的User Story进行讨论，并确定每个Story的Aacceptance criteria。
- 确定用户故事的DoD
- 将Story分解成Task并录入系统或者set up物理看板。
- 团队成员初步认领一下任务
我们把需要PO参与和贡献的部分集中在前30分钟（甚至更短）解决，从而减少他参与的时间成本，这就是一种“降低对方的响应成本”的设计。
这种降低别人响应成本的方法，不仅仅可以用在planning meeting上，也可以应用于其他任何的，你需要PO参与的会议上。甚至可以扩展到其他跟PO的合作活动上。所以读者们可以思考一个问题：
一个为期两周的迭代，理论上不会包含太多的业务需求。但如果花了大量的讨论来澄清需求的细节，那往往是由于User Story的颗粒度太大（例如单个user story工期超过4天），并没有在Planning会议前进行适当的分解的缘故。
用户故事在分解的过程中，功能之间的关联性，隐藏的需求和风险等等都会暴露出来。如果没有提前进行适度的分解，那么这些问题都会暴露在Planning meeting 上，并需要立刻讨论，于是会议就会超时。对所有参加会议的人，包括PO，都是一个巨大的负担—–人们会感觉浪费了太多的时间在开会上。
Sprint planning会议的一个重要输入就是“健康”的User Story。“健康”的内容包括：
- 未来一到两个迭代可能会做到的User Story具备合适大小的颗粒度。
- “Why”部分的描述清晰准确。
- 用户故事已经已经按照优先级进行排序。
PO 应该更关注业务上的”做什么”。但很多企业中，敏捷转型前，PO是在内部担任偏“BA”或者“项目管理”的岗位上，习惯日常参与讨论技术和实施细节，甚至参与决定团队分工，敏捷转型后这种行为肯定是错误的。
PO如果过多参与技术细节讨论，那么就压缩了团队在技术实施上的主动空间，降低了群策群力的效果，还会让产品的优秀程度更受限于PO个人的历史经验，从长远来看不利于团队能力的成长。
另外PO的精力是有限的， 我们希望他把有限的精力放在深入了解客户需求，构建产品愿景上，而不是focus在技术实施细节上。
避开了上面两个常见的问题， 你就会拥有一个特别高效率的Planning Meeting，而且大家的参与度也会越来越高。
很多人其实喜欢特别长的Planning meeting，因为如果PO的availability低，那么好不容易抓到他一次，就应该拖着他把问题充分讨论出来。我们先不谈这种“充分讨论”是否也有“过度计划”的嫌疑。别忘了PO也是人，如果一个事情对他来讲负担太重，那么可持续性就降低，负担重到一定程度，你就会发现他经常说：太忙了没法参加，发邮件吧。
另外一个可以尝试的方法是，尝试“采取更短的迭代周期”。随着沟通的成本被时差等综合因素推至一个相当高的程度，PO和团队都会更倾向于一次性计划更多的，更长周期的任务。这样做带来的潜在风险和瀑布开发的风险一样。
