再谈scrum

从上一次写“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,或许有帮助。

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

7 thoughts on “再谈scrum

  • 问个问题,如果我们前期不得不用很长时间完成软件设计,而当我们投入了极大的精力和热情完成了设计发现我们的需求有变化,系统底层要变,切分好的任务要变,Sprint Backlog也要变, 怎么办,再来一遍?

  • 您好,我也有个问题请教。
    在Scrum里提到依据Backlog评估并制定Sprint的发布计划。那么这里面的Sprint Backlog应该做到怎样的粒度。它与需求用例、User Story等是什么关系,能让开发人员理解究竟要做什么吗?
    如果方便的话请您举个Backlog的具体实例,谢谢。

  • backlog是一个备忘录,也是sprint的候选列表。粒度可以比进入sprint的具体工作大一些,可以在进入sprint之前再切分。我的经验是,如果粒度过大,会增加时间评估的不确定性,如果开发者在面对某个条目感到没有头绪或者足够的把握,不能确定next action,那粒度可能是有点大了。但减低粒度是需要花费资源的,需要有一个折中。

  • 对于Sprint Backlog应该做到怎样的粒度,我的操作实践是:

    每个任务不能超过18小时,也就是3天(我们每天上班8小时,真正用到工作的时间是6小时)。。。再长的话,就不容易控制风险。。。最小的任务是1小时,但这样的任务一定要少,否则每天track起来,就会花去更多的精力。

    Blog: 敏捷软件开发随笔 http://scrumxp.blogspot.com

Comments are closed.