AgileChina 2009

ThoughtWorks作为倡导敏捷开发的旗舰公司,每年会在国内举办一次 AgileChina 敏捷中国大会。我一直是这个大会的常客,每年都受益非浅。 今年的AgileChian 2009比较特别,由ThoughtWorks和InfoQ中文站联合主办,实力大增,请来了很多重量级的人物。首先是Kent Beck,极限编程之父,TDD之养父,敏捷宣言十七人之一,在中国被广大程序员瞻仰的机会接近于日全食。 更让我感兴趣的是另一位大师,Dave Thomas,《The Pragmatic Programmer》、镐头书和《Agile Web Development with Rails》的合作者之一,Ruby和Ruby On Rails最热衷的推广者,不知道没有他,我还会不会在四年前一头扎入Ruby和Rails的世界,更不知道我的今天会是什么样。Dave在本次大会有两个演讲,一个是关于《The Pragmatic Programmer》十周年,谈方法论,一个是Ruby对象模型,讲技术,都是我非常感兴趣的话题。 昨天,从InfoQ中文站的泰稳那里得到一个优惠,如果你想参加AgileChina 2009,只要在报名过程中说是通过我介绍来参会的,有100元的优惠。感谢泰稳给我和大家提供的这样一个机会。具体大会的信息和报名,请参看敏捷中国大会官方网站。

再谈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来解决这些问题,读起来很流畅,不费力气。读完这本,再读微软那本效果会比较好。

You may be agile, but you are still a dog

五一放假结束后的第一周,在一位经验丰富的美国同事带领下进行了一周的敏捷开发实践。在此之前的半年时间里也试过scrum,并且体会到了一些好处,但那一周不仅让我们体会到了好处,可以看到了敏捷开发的力量。很多书本上早读过的观点和方法在他的帮助下确确实实为我们解决了实际问题,很让人兴奋。 此后将近一个月的时间里,我们尝试延续第一周的方法,必须承认我们还不是实施敏捷开发的专家,但还是取得了以前无法想象的成果。下面是一些体会: 1。短而递进的开发周期。我在以前也提过,现在能比以前更好的采用分而治之的方法。对于一个需求,如果需要十二天来完成,那么两天我们能完成到一个什么程度,或者是一个简化的需求,或者是这个需求的一部分,只要实现的完成度可以拿出来衡量,我们就制定一个两天的计划,两天后验收,然后一步一步做下去而不是“这是需求,十二天后见!”。 2。更准确的估计工作量。估计工作量对我来说一直是一个难题。当这次我又对一个work item给出不很确定的估计时,我被反问“哪些不确定因素造成了这些不确定地工作量”,我回答那里那里可能有潜在的问题可能会导致工作量的增加,“那么如果目前不去考虑这些潜在的问题,你对工作量的估计是多少?”,我的答案马上变的确定了。对于不确定的问题,我们只需要把它记下来,在问题浮现或者变得确定后再解决,而不是把它变成包袱背在身上。能绕过这个槛是我这次最大的收获。 3。分清什么是需求,什么是实现。工程师在讨论问题的时候很容易陷入细节,以至于忘记了事情的根源,即需求。我不止一次的被提醒“你现在讨论的是需求还是具体实现”,在回答了这个问题后,很多诸如“做什么”“怎么做”的问题自然就得到了答案。 4。unit test。没有UT就不是敏捷开发,不光是为了测试,有时候只有UT才能确定你工作是否完成,才能使短而递进的开发成为可能。在这一点上我还欠缺不少。 教训也是有的,最大的教训就是我们把计划定得太激进以至于经过这三个星期我们越来越不敏捷了。40小时每周是敏捷开发的核心,此话一点不假。 最后是同事发给我们的一副图片,最真实地再现了我们的工作:

再谈Object Setting和Performance review

在中期review的时候发了一篇牢骚,引来了一些朋友的共鸣和反馈,一位guest朋友留言谈了他的经验: 量化工作也是职业化的一种吧。尽管我个人对此并无赞同或者反对。不过如果特别是说程序员做Object Setting,我有一点经验,不知道有用没有:最重要的当然是需要完成的项目。每个项目都会有roadmap吧?roadmap上的milestone就可以作为一个时间上比较靠谱的参考。然后开发时候,陆续把所有的任务都敲碎放到bugzilla里去。到项目结束/年度结束,考察工作其实就是review bugzilla。再不懂技术的老板,看到通过解决的所有的可预见的问题和中途修改好的bug报表(所以要用bugzilla,因为它能自动生成报表),也都会对一年的工作有数了。至于说performance,这个东西应该是相对的,而且最好是这一年度的bug报表对于上一年度的比较。说真的,这东西确实没有什么实际用处,谁会因为多写了一年程序就真的提高了多少performance,这种循序渐进的东西确实无法量化。 对目标的制定也许会很让人迷惑,我的不一定有用的经验就是写的越具体越好。百分比应该用在对项目完成度的衡量上。但是如果有百分比,就一定指出来那些没有包括进来的百分比是留在下一年了,还是有团队的其它人来完成。这对于项目管理者来说也会有帮助的。 定期review工作的好处是,可以及时发现blocking bug,并且对此做出相应的调整。但是管理者不见得能够实践后一条,这可能也不说明review工作真的没有用,只是管理者本身执行得不够好。 其实我并不反对设定目标和定期的review,我反对的是这种纯粹management oriented的长期目标设定和review。 实施敏捷开发有一段时间了,一个scrum的周期最长也就是一个月,每天都会花很短的时间做前一天的review和目标的调整。我体会到的这个过程的要点就是:review要及时,目标设定要随时调整。我对以年为跨度的object setting和performance review的最大困惑就在于两者的严重脱节。 实际上,这样长跨度的目标设定,更倾向于一个career plan而不是project或者product plan。而拿一个career plan作为年终performance review的依据,纯粹就是牛头不对马嘴。