敏捷开发方法Scrum经验总结

经过实践证明，Scrum 方法用于开发要求快速、灵活，且生命周期短的需求还是很给力的。

关于启动 Scrum 方法的套路就不再赘述了，都是经典的东西。下面总结一下独特的经验（大家鼓掌）：

1. 在 sprint planning meeting 上定好本次迭代（迭代即 sprint，之于Scrum的意义不解释）的计划，计算出总“人天”和这次迭代的总“工作日”，画出 burn down 图，burn down 图对于把控 sprint 的进度、及时发现进度和阻碍方面问题是有帮助的。
2. 可以考虑加入“投入程度 ”这个指标调节个人的“人天”数，如果有需求之外因素，例如技术变革啥玩意干扰的话。
3. 为方便管理和估算，最小的估算时间单位为 0.5人天 ，比这个还小的粒度或忽略或归并。
4. 一般最大的任务单位为 5人天 ，即一个工作周的时间。我认为一个任务工作量的估算超过这个数字就不适用 Scrum 敏捷的特征了，这时候要么拆解，要么直接回归经典软件工程的“人月神话”得了。
5. 在白板上建立 next 域 和 紧急任务 域 是非常重要的。前者可以确保你不会丢失因为种种原因而未排入本次 sprint 的需求任务；后者用于处理不可避免的紧急任务（一般是老大从战略角度压下来的，非计划的），这也能让管理者清楚的看到计划为何 delay 或为何要加班。
   1. 在 sprint 过程中，如果发现因为需求不明确而无法进行的任务，请立即归入 next 域（不要犹豫，因为开发不明确的需求犹如盲人摸象，返工成本绝对够任何人喝一壶的），这样可有效的避免浪费时间，可敦促需求人员完善设计，且不会丢失需求。——如果这种情况多了，burn down 图会很快燃尽，Scrum master 能够及时提醒 Scrum owner 提高需求和设计的质量。
   2. 对于临时插入的任务，重要且紧急 的立刻排入 紧急任务 域，立刻打断 sprint 计划，不惜代价开始搞，因为你已经将此任务识别为重要且紧急。——如果这种情况多了，白板上的反映为 紧急任务 域密密麻麻，而此段时间内，burn down 图将呈一条水平线。这是因为计划任务被大量紧急任务打断，而无法“燃烧”，这时候，插入临时任务的人就应该思考了？为什么那么多事情都没有计划！
   3. 对于临时插入的任务，重要且不紧急 的进入 next 域，走下次 sprint。这样即可以给这些重要的任务一个应有的地位，也不会打乱现有的计划。我们要尽量按计划做事，否则再好的计划也没有人会执行鸟。
   4. 除此之外的任务，开发人员还用考虑么？需求人员懂的。
6. 每天的晨会可以方便大家的互相了解情况，及时的发现并解决一些问题，隐藏的很深的 Block 一般在这个时候会被识别出来。
7. 周期再短的 sprint，也会有开发人员先行完成所有计划任务，这时候可以尝试把此人拿去和某些未完成关键任务的人去玩结队编程或同级评审（peer review）。这也可应付突发情况，例如，即使某个关键人物得了病，sprint 也不至于完蛋。
8. 对于任务完成（done）的定义就是：随时可以上线 。因为毕竟要上线还是需要一个“良辰吉日”——所有的相关需求都OK才行。
9. 每个 sprint 结束后，最好有一天间歇的时间整理总结。一个 sprint 紧接着一个 sprint 容易使人疲劳。
10. 对于需求人员（包括 Scrum owner）由于经验不足，在 sprint planning meeting 提出的需求过小，而 sprint 开始后需求频繁变更或扩大化导致技术人员对任务评估不足的情况。可以有下面3个解决步骤：
    1. 需求文档化。即执行CMM方法的需求管理模块，严格跟踪需求变更，需求必须文档化。需求变更可以，但是要有标记、可追溯。需求文档纳入配置管理。
    2. 识别：需求变更需要一部到位的。在达成需求扩大的共识后，把扩大的需求单独拆出，放到“紧急任务”域中。前面已经说了这在燃尽图上会体现出来，导致“燃不尽”，让问题暴露出来！
    3. 识别：需求变更可以分段优化的。在当前 sprint 中留出扩展接口，需求变更作为新需求扔到 next 域里，归入下一个 sprint。还是那句话，尽量按照计划来，这是个原则。
    4. 当然还要遵循“紧急/不紧急”的原则，可以这样理解：sprint 计划是 Scrum master 和 Scrum owner 签订的“合同”，合同不能篡改。而对于合同的增补和裁剪是允许的，但需要记录在案、有案可查。
11. “团队凝聚力”是 Scrum 的核心要素之一，如果一个团队同心协力完成了多个 sprint，团队成员就会变得非常紧密。他们会学会如何达成团队涌流（group flow，请参见 http://en.wikipedia.org/wiki/Flow_%28psychology%29 ），生产力会提升至难以置信的地步。不过要达到这个地步需要花上一定时间。如果不断变换团队组成，你就永远无法得到强悍的“团队生产力”。所以，如果你确实想要重新组织团队，请先考虑一下后果。这是个长期变化还是短期变化？如果是短期变化，最好考虑跳过这一步。如果是长期变化，那可以干。

互联网行业的开发非常适应 Scrum 的特点，因为周期短、变化多、交付快……。Scrum 本身是一种思想方法，不同的项目对其需要有不同的实现和裁剪，通过不断的迭代（sprint），找到最合适自己的实践。

     本文转自胡奇 51CTO博客，原文链接：http://blog.51cto.com/huqicto/367467，如需转载请自行联系原作者