计划会议中的估算，你纠结吗?

　　计划会议中的估算

　　在Scrum中的计划会议中，估算是较为让人纠结的环节。主要的问题是：1) 花费的时间长;2) 估算不准确 3) 估算是否有必要

　　原因是什么?我认为主要是：1) 对需求的理解不到位;2) 每一个需求严格按照planning poker的方式，对于简单的需求和强分工的任务意义不大，但是耽误了时间;3) 设计的风险没有被发现;4) 团队受到“兑现承诺”的压力，一般会“悲观估算”

　　如何解决这些问题，我的建议是：

　　① PO在grooming会议之前提前将需求发出，开发团队是带着问题进行需求讨论，否则刚刚拿到需求，讨论的效果并不好

　　② 需求的描述，不拘泥于用户故事的形式，详细程度由团队的成熟度决定。团队越成熟，在简单的需求描述情况下依然可以把需求讨论清楚，可以简单描述;否则还是详细描述为佳。

　　③ 需求和设计的讨论，异常处理、用户使用场景、非功能需求往往是被遗漏和疏忽的地方

　　④ 风险前移：复杂的设计还是通过时序图等在白板上进行，不要把设计的风险带到实现中。

　　⑤ PO和团队都要承认“估算是不准确的”，估算的目的是为了帮助团队消除需求和设计的理解风险，并得到哪些需求可能被交付。PO和团队关注的焦点在于“迭代的目标是否被实现”，而不是“团队承诺的需求是否全部被实现”。

　　⑥ 忘掉前面几点，在回顾会议中找到适合自己的做法，持续改进。可能这样的方式最适合：估算和实际校准的成员，估算不需要扑克的方式，直接他估算即可;反之则需要发现原因，是需求理解还是设计风险，扑克、时序图、活动图、反讲都要用上。也可能另一种方式最适合：放弃估算，根据最后需求完成的情况不断分析问题所在，然后在迭代过程中加强这些问题的解决…

　　另外，做一个沙龙宣传：

　　你用scrum时遇到交付失败吗?用Scrum时遇到迭代内需求经常变化吗?如果是按需交付，不是按固定周期交付，Scrum是否用的很别扭?参加我们的沙龙吧，这里有我们的应对实践分享。 2013年04月14日，北京，“落地敏捷”第十一期沙龙，诚邀您参加。沙龙详情及报名在这里：

原文转自：http://kan.weibo.com/con/3559509385653244?sharetime=2013032422