敏捷开发方法Scrum{zj0}实践企业库|免费b2b网站

下面开始进入正题——{zj0}实践指导思想
Scrum和极限编程（XP）都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短、有时间限制。将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时间用建模工具来画UML图、编写xx的需求文档，也不会为了应对在可预计的未来中所有可能发生的变化而去写代码。实际上，Scrum和XP都关注如何把事情做好。这些团队承认在开发过程中会犯错，但是他们明白：

什么是“理想的人天”？问一下你的团队：“如果可以投入最适合的人员来完成这个故事（人数要适中，通常为2个），把这些人锁到一个屋子里，有很多食物:-P 在xx没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证的、可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。
一些小经验：不需要保证这个估值{jd1}无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半）；区别于“人月神话”中的“人月”，Scrum方法最小的估算粒度一般为“人天”，有时候可以小到“0.5人天”，再小就值得商榷了，我是这样认为的。这足够“敏捷”了。

13:00 – 13:30 产品负责人对Sprint目标进行总体介绍，概括产品Backlog。定下演示的时间地点。
13:30 – 15:00 团队估算时间，在必要的情况下拆分Backlog条目——把“故事”进一步拆分成“任务”。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。
15:00 – 16:00 团队选择要放入Sprint中的故事。计算生产率，用作核查工作安排的基础。
16:00 – 17:00 为每日Scrum会议（简称每日例会）安排固定的时间地点——如果和上次不同的话。
Sprint应该多长才好？
时间短就好。公司会因此而变得“敏捷”，有利于随机应变。

每个人都会得到如上图所示的13张卡片。在估算故事的时候，每个人都选出一张卡片来表示他的时间估算（以故事点的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。
如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。

{zh1}，呼应一下前面：我们用人/天作为所有时间估算的基础（我们也把它叫做故事点）。它的最小值是0.5，也就是说小于0.5的任务要么被移除，要么跟其他任务合并，要么就干脆给它0.5的估算值。干净利落。

本文出自 “” 博客，转载请与作者联系！