敏捷开发方法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 域（不要犹豫，因为开发不明确的需求犹如盲人摸象，返工成本绝对够任