石锅拌饭 Robin Lu’s weblog

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元的优惠。感谢泰稳给我和大家提供的这样一个机会。具体大会的信息和报名，请参看敏捷中国大会官方网站。

最近把版本管理系统换成git了，果然非常好用，难怪大家都在推荐。

首先不要有心理障碍，那些名词都是吓唬人的。所谓的“非线性开发”无非是指强大的branch和merge的能力，“分布式版本管理”就是说每人自己都有一套本地的repository，不存在一个集中的版本服务器。

给我带来的最直接的好处有：

1. 傻瓜都会的初始化，git init, git commit -a, 就完了。对于随便写两行代码就要放到SCM里的人来说，再合适不过。也可以拿git做备份系统，或者同步两台机器的文档，都很方便。
2. 绝大部分操作在本地完成，不用和集中SCM服务器交互，终于可以随时随地大胆地check in代码了。
3. branch管理容易多了，无论是建立新的branch，还是在branch之间切换都一条命令完成，不需要建立多余的目录。
4. branch之间merge时，不仅代码会merge在一起，check in历史也会保留，这点非常重要。

工具之所以好，除了方便好用，还在于它帮助并鼓励你做正确的事情。频繁check in是一件很好的事情，好处我不多说了，git就鼓励你频繁check in。branch也是一件好事情，我们大多很怕branch因为它太麻烦了，去掉这层心理包袱，branch可以让我们的开发工作很有条例。

还有一些实用的功能，比如bisect,用二分法来寻找regression，你以前手动做过这种事么？我做过。以后如果要做就不会怕了。还有stash，做hot fix非常方便。

如果正在用svn，劝服所有合作开发者使用git之前，可以先用git-svn，和svn整合得非常好。

分布式版本管理系统取代集中式版本管理系统，只是时间的问题了。

Scott Berkun，The art of Project Management的作者，最新总结出一套开发方法，是那么的似曾相识：

Asshole Driven development (ADD)

团队中重大决定掌握在最操蛋的人手里。所有的智慧、逻辑和流程在Mr. Asshole到来的一刻都灰飞烟灭。也许有规则，也许有process，但被Mr. Asshole全部打破，其他人只有跟随。

Cognitive Dissonance development (CDD)

团队里存在两派，对于产品应该如何完成有着截然不同的观点。两股势力在各种会议和表达个人意见的时候都表现出强烈的冲突(war meeting, there’s a name for such thing)，完全只按照个人意愿来定义项目。

Cover Your Ass Engineering (CYAE)

我们所做的一切只为了不让屎盆不扣在自己头上。

Development By Denial (DBD)

大家都假装自己有办法搞定，事情发展一切良好(The future is so bright….)，而实际上早就乱成一团糟。事情越糟糕，大家越不愿意承认现实，这成了他们能够让自己解脱的唯一方式。

Get Me Promoted Methodology (GMPM)

大家做这做那只为了让自己更醒目，满足老板的奇思怪想，让自己能够快点升职。他们可以为此人为地制造麻烦借此创造英雄，做立竿见影却后患无穷的鲁莽修改，做表面文章胜过创造真正的价值。

当大家都清楚自己在创造垃圾却无法摆脱，当最重要的事情是迎合你的老板，当只有踩倒了别人你才能再上一步，你还能做什么？

谢天谢地我不用再经历那一切了。

今天在一个藏袍看到一篇有趣的文章，是关于如何成功地从起点走到目标，其中过程和控制的关系等等。
感觉他应该是一个幸福的人，有那么多可以达到目标的途径。
为什么我总经历这样的过程？

(蓝线表示控制，对过程的控制。)

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