健康资讯 本周五第8次迭代评审会结束后，资产产品团队实际涉及开发了73个故事点，验收通过只有20多个，远远低于我们历史的平均40个左右的故事点的速度。对于这个结果，产品交付团队做的没有问题。我们管理团队需要反思一下这个结果的原因并在未来作出切实改变，如果我们不满足于目前的已经取得的成绩，认为我们还有更大的提升空间。我们也许可以从几个方面改进：
1. 承认团队目前的能力：
团队的能力是客观存在的。产品交付团队中每个人的能力水平，工作态度，价值观等都不一样，不是一时半会儿能改变的。产品管理要有合理的预期，才有合理的结果。我们历史上只有40个故事点的能力，不必急于每次让团队去扑70-90个点的工作。不仅完不成所想要的更多的工作，就连本来可以完成的工作也不能被完成。
解决团队交付能力问题：1. 增加资源（直接成本高，见效快）；2. 改进工程实践（需要时间投入，见效慢）3. 完善绩效管理（奖励优秀的人，敲打混日子的人，不让团队能力退化）
2. 集中火力各个击破
力量分散在过多任务只会增加所有任务都不能按时完成的风险。我在本次迭代的几乎每一天的WIKI日志中都写到：涉及的故事点较多，考虑验收的效果。敏捷交付就是价值交付，如果有10个任务，分给10个人做，每个任务只完成50%，在迭代结束时候没有价值；按同样的能力，如果迭代中集中资源在5个任务上，同样10个人做，就完成了5个任务，交付了100%的客户价值，财务上说ROI就有了。
解决集中火力的问题：产品管理需要在迭代中根据历史速度期望符合团队能力的交付范围，设定合理的迭代目标，进行质量交付；关注更高的优先级和较小范围中的专注度。
3. 合理拆分用户故事并进行评估
目前碰到的问题是团队经常无法拆分大的用户故事，导致每个故事可能只完成一部分，不能让整个故事进入验收。无法做验收。昨天我也对团队做了进一步的培训，附件是《用户故事评估技巧》
解决用户故事拆分和评估：引导团队在每日工作中进行拆分和评估训练，团队拆分故事建议在2个工作日以内，且鼓励2人以上合作工作在同一个较大用户故事中；产品管理除了要给出简约且可进一步沟通的验收标准（目前已有），还要提前1个迭代给出功能界面原型（草图或设计稿）以帮助团队对用户故事拆分和评估，理解功能需求和可能的复杂度。
除了上面的反思，一个次要原因是在这次迭代我们客户的试运行环境部署也有工作在做，类似的情况会有很多，敏捷迭代交付中时刻存在更多计划外的事情，这在未来也算作工作量，即故事点。
作为交付负责人，必须对交付结果负责，作为敏捷教练，必须诊断产品管理和交付能力的对接及改进方向并提出建议。这些建议能否完全落地在于我们的产品管理实践。
网页链接
#敏捷##产品管理##用户故事##产品经理##敏捷教练#
