敏捷开发方法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），找到最合适本身的实践。

做者：胡奇 for 51CTO.com