2010年11月29日
16:31
有团队就需要过程管理，以便协调资源，高效合作。我们公司的“青蛙王子”，“三顶法”都是这样的代表。尽管透着朴实，但是曾经比较起作用的。
现成的主流方法论如何呢？现成的方法论有两个大类，一个大类是以RUP，CMMI为代表的重型方法；一类是集中于敏捷旗帜下的若干方法，如XP（极限编程），Scrum等。首先，我需要做一个声明，就是我并不打算评价这些方面的优劣——我不是方法学家，不会对他们都有完整全面的了解，也谈不上什么公正的评价——而是表达从我们小型团队的角度，看到了什么，尝试了什么，为和做出选择或者不选择的判断。我希望能够比较客观的提出看法，而不太多的夹杂个人的喜好，尽管这一点几乎不可避免——我提出的是“人”的看法。
RUP还好，我们有过第一手经验。在几个项目中都号称用RUP来进行软件开发过程的管理，然后几个项目完成，我们对RUP的看法几经变迁，留下的主要是“迭代开发”，“使用UML设计”这样的实践。大家决定后，在一个项目周期内就忘记了RUP的存在，而是每天面对屏幕，奋力敲入代码，回到自己擅长的部分。当然有时候用Rational ClearCase的时候，偶尔想起“恩，我们好像在‘RUP’呢”，然后继续code。实际上，RUP对我们的程序员的日常工作影响不多，我也不知道RUP引入后，我们因此和以往有什么进步。也许并非RUP不好，而是对我们不适合：那么多的文档，那么多的工件和工具，需要很多的时间去理解、消化、裁剪，然后为我所用。
对CMMI的了解则是来自于一些二手的经验。我曾经看过一家公司的CMMI的第四级实施，并和几位实施者讨论过。他们的开发部门共有50人左右，其中有8人在做这个实施，已经做了几个月，并且还要做几个月；他们都在编写文档，并且专门的一个会议室内堆了很多的文档。可是，当我问及CMMI对他们有什么好处的时候，他说：“过了级，更加容易拿到项目”。就是说，他们并没有更多的改进方法，也缺乏一定的改进上的针对性。文档和书也看了不少，讲座也听了N回，可是，我们该做什么呢？面对这样的一个基本问题，我承认我无话可说。
前些日子，我们做了scrum公开课。除了公司内的，还有其他公司的几个经理也被邀请过来。讲完后，我和其中一个经理谈了谈。他们公司刚好是用CMMI的！他们做了5年，并且这些年一直在伴随着咨询，文档众多，他说，“对于维护型的项目，我们共50多人做一个项目，CMMI显得严谨而有效，尤其是其中的需求变更流程；不过现在也常常会需要做些小型的项目，本来就几个月的时间，几个人做，大家都反应这样走流程，做很多工件太麻烦，几个项目经理都在和我闹，希望减少流程。”。他希望也考察下Scrum看看是否可以让公司接受新的方法论。我的结论是，敏捷对于小型团队是非常有用的，而大型些的项目，需要严谨的项目，CMMI也许更好。
XP 让我们有了新的看法。XP很明显是程序员创建的，因此面向代码方面更多一些。XP里谈及的12项实践，比如TDD,结对编程等都看来简单，实施起来很难。以TDD为例，在我们一个8000多个函数的项目中，通过TDD产生的函数不足100。这个项目中很多人都是老江湖了，他们依然要慨叹，TDD很难真正的实施。
对小型团队而言，CMMI，RUP太冗余，XP太难，至于其他的，我系统了解过，结论是不值一提。因此Scrum上位也就是理所当然的了。