再谈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的失败或者效果不理想通常由以下因素造成: 对未知结果的恐惧心理。出于习惯,大多数人更愿意事先得到一个固定的最终发布日期和一个承诺的结果,哪怕到了日期无法得到结果再延期。我们常常都需要这样的心理安慰,宁愿把苦头放在后面而不愿正视软件开发的规律。 在sprint过程中加入新需求的诱惑。很难很难抵御这样的诱惑,scrum第一杀手。 不愿意调整目标而任意延长sprint的时间。不知不觉你就又回到了老路上。 急于看到结果而压缩sprint的时间。能得到一定的效果,但总体上消耗的更多的资源。我们曾经一度这样做,每周末完成一个可以审查的结果,很有效,但很累人,在整合上花了太多的力气。 scrum的实施 除了按照scrum的流程按部就班的执行,需要理解scrum的几个要点,否则很难达到效果。 理解软件开发过程中的几个变量:成本、期限、质量和功能。如果这四个变量都能确定,我们就在家数钱就可以了。有时候我们有机会尽量确定期限和功能,CMM之类的软件方法就是着重于在这种情况下如何尽可能保证质量。有时候我们希望通过加人手,提高成本来保证期限、功能和质量不受影响,《人月传说》有不少关于这样是否可行的讨论。也有的时候,频繁的需求变化导致功能无法确定,期限一拖再拖,成本不断增加,质量无从保证,一片混乱(chaos),这时候我们就可以通过scrum,先确定期限和成本,在短期内一定程度上确定需求,让这个四元方程式好解一些。 确保开发团队在sprint中不受干扰,不被分心。如果能理解上一条,你就能理解为什么在sprint中不随意添加修改需求对团队开发很重要。永远变化的需求只能导致永远不能发布的产品。scrum同时保证了你有足够的机会在下一个sprint实现新的需求,隔这样一段时间,你会对新需求有更多的了解,很有可能它并没有你想像得那么重要。 注意任务划分的粒度。任务划分的粒度越小,团队对任务的理解也越透彻,对时间的估计也会越准确。 彼此信任。特别是老板,应该信任他的团队,有能力使用正确的方法完成应该完成的工作,不然你雇他们干什么? scrum不是万灵药,不可能解决所有的问题。但是如果你要使用scrum,在完全领会它之前,最好按部就班的执行scrum要求的每个步骤,遵守每个原则,至少可以少走一些弯路。InfoQ上有一个Scrum Checklists,或许有帮助。 最后推荐一本书: 相比微软出版社的Agile Project Management with Scrum,我更喜欢这本,基本上是从实例出发,让你很快能了解scrum所针对的问题以及如何通过scrum来解决这些问题,读起来很流畅,不费力气。读完这本,再读微软那本效果会比较好。

scrum 第一天

一般来说我不太会专门去看软件开发方法类的书籍。我个人的偏见是:如果不可以亲自实践,只看这些书基本上没用。 近来项目开发,和美国同事合作,语言和距离的关系,遇到一些问题,美国同事提出使用scrum来管理开发过程,一次很好的实践敏捷开发的机会,我们都表示同意。 昨天老美花了一天作好了Scrum Sprint的表格,大家在每个属于自己的工作项目中添入估计时间,以小时为单位。今天早上我们开了第一次scrum meeting,15分钟,汇报每人具体在哪个条目上花了多少小时,并对估计时间做出调整。 我没有读更多scrum的介绍材料,但也有一些体会。 首先,以小时而不是传统的天、甚至人月来做预期以及跟踪进度,的确可以促使人换一个角度来看待工作时间分配。就好像用惯了变焦头,让你改用定焦头,思路不得不有所改变。时间段短了,步调不同了,当考虑到需要将这个小时划给某个工作时,进度很容易把握,分心以及用于焦虑的时间明显减少,符合getting things done的原则。以前也看过(10+2)*5的gtd方法,将时间片划得更小,要达到的效果是类似的。 再有,对项目进度的监督不再是交给每周数小时的例会,换之以每天15分钟,同时项目管理的方法更简单和直观,问题的发现和进度的调整都更容易更及时,效率得到提高。 今天是第一天,我没什么更多可说,时间长了,或许会发现更多好处或者缺陷,不管怎样,现在感觉还不错。