石锅拌饭 Robin Lu's weblog

从上一次写“scrum“到现在，已经有一年多的时间了，期间碰到很多问题，也有不少收获。目前离开了原来的项目，回到了“瀑布”的怀抱，但对于scrum，还是有不少体会可以分享。

scrum和GTD

scrum和GTD有很多相同的地方。首先，他们的问题域就很相似，都是为了应对变化的复杂的任务。如果你可以确切的定义(define)你的任务，比如耕一块地，或者使用限定技术针对一个明确且不会变更的需求完成一个软件，你即不需要GTD也不需要scrum。
scrum有着和GTD几乎完全一致的流程。GTD中的“collection”对应scrum中整理Product Backlog的过程，GTD中确定“Next Actin”对应scrum中团队确定“Sprint Backlog”。它们又都存在回顾(review)的过程，且都讲究流程的回归反复(iteration)。
可以说，如果你理解GTD的精髓，scrum对你来说就是水到渠成，反之亦然。从另一方面，也能说明GTD和scrum都不是石缝中蹦出的猴子，都来源于现实，都为了解决现实的问题。

影响scrum不能正常实施的因素

scrum的失败或者效果不理想通常由以下因素造成：

1. 对未知结果的恐惧心理。出于习惯，大多数人更愿意事先得到一个固定的最终发布日期和一个承诺的结果，哪怕到了日期无法得到结果再延期。我们常常都需要这样的心理安慰，宁愿把苦头放在后面而不愿正视软件开发的规律。
2. 在sprint过程中加入新需求的诱惑。很难很难抵御这样的诱惑，scrum第一杀手。
3. 不愿意调整目标而任意延长sprint的时间。不知不觉你就又回到了老路上。
4. 急于看到结果而压缩sprint的时间。能得到一定的效果，但总体上消耗的更多的资源。我们曾经一度这样做，每周末完成一个可以审查的结果，很有效，但很累人，在整合上花了太多的力气。

scrum的实施

除了按照scrum的流程按部就班的执行，需要理解scrum的几个要点，否则很难达到效果。

1. 理解软件开发过程中的几个变量：成本、期限、质量和功能。如果这四个变量都能确定，我们就在家数钱就可以了。有时候我们有机会尽量确定期限和功能，CMM之类的软件方法就是着重于在这种情况下如何尽可能保证质量。有时候我们希望通过加人手，提高成本来保证期限、功能和质量不受影响，《人月传说》有不少关于这样是否可行的讨论。也有的时候，频繁的需求变化导致功能无法确定，期限一拖再拖，成本不断增加，质量无从保证，一片混乱(chaos)，这时候我们就可以通过scrum，先确定期限和成本，在短期内一定程度上确定需求，让这个四元方程式好解一些。
2. 确保开发团队在sprint中不受干扰，不被分心。如果能理解上一条，你就能理解为什么在sprint中不随意添加修改需求对团队开发很重要。永远变化的需求只能导致永远不能发布的产品。scrum同时保证了你有足够的机会在下一个sprint实现新的需求，隔这样一段时间，你会对新需求有更多的了解，很有可能它并没有你想像得那么重要。
3. 注意任务划分的粒度。任务划分的粒度越小，团队对任务的理解也越透彻，对时间的估计也会越准确。
4. 彼此信任。特别是老板，应该信任他的团队，有能力使用正确的方法完成应该完成的工作，不然你雇他们干什么？

scrum不是万灵药，不可能解决所有的问题。但是如果你要使用scrum，在完全领会它之前，最好按部就班的执行scrum要求的每个步骤，遵守每个原则，至少可以少走一些弯路。InfoQ上有一个Scrum Checklists，或许有帮助。

最后推荐一本书:

相比微软出版社的Agile Project Management with Scrum，我更喜欢这本，基本上是从实例出发，让你很快能了解scrum所针对的问题以及如何通过scrum来解决这些问题，读起来很流畅，不费力气。读完这本，再读微软那本效果会比较好。