十年总结（12）：软件开发思想之争 － RUP VS XP

对我过去感兴趣的朋友们，请看十年总结系列文章
－－－
正式回到原来公司就职后，开发这边的管理团队形成了一个三足鼎立的局面，
田田，十几年工作经验，不怎么懂具体技术，负责纯管理，以及协调开发与市场，
乐乐，8－10年工作经验，03下半年，他牵头做了一个2.0版本的框架，java c/s架构，年底要移民澳洲，
我和乐乐各带了几个开发人员一起主持开发工作。

虽然多头领导并不是一件好事儿，但对我来讲并不是一件坏事儿，
因为来北京这几年，开发方面都是以我为主，很多时候我也不知道自己的决定是不是对，
我相信大家都有这种感受，自己做出的决策，虽然内心相信是正确的，但还是希望通过其它途径得到证实，
这就是常说的“他山之石，可以攻玉”，“外来的和尚会念经”。
我现在觉得，需要别人来证明自己的时候，正是自己还不成熟的时候，不过从青涩变得成熟，不都要经历这个阶段嘛！

04年，我的课程学分拿的差不多了，因为专业是软件工程，所以课程包括：过程改进、软件度量、算法设计、面向对象设计等等，
我当时的感觉就像一个熟读了武功秘籍的人，迫切的希望通过修炼来印证功法所说的种种妙用，
田田和乐乐都比我有经验，我自然乐得好好学习。

我有几年的软件开发经验，也切身体会到不少的问题，我也经常思考如何更合理的组织开发，
我的目标有些理想化，在我看来：
1、管理应该实现“无为而治”，也就是说管理者的精力应该不在管，而在于看，看结果，看未来
2、软件开发过程应该是可视、可控的。
3、软件开发的结果是可预期的。

我所学的各种管理课程都信誓旦旦的保证，规范的流程可以满足我的要求（除了第一条），
所以当乐乐提出开发团队要采用RUP的时候，我积极响应，表示大力支持。
于是，我们剪裁文档、安装Rational Rose、招聘测试人员和配置管理人员，制定版本管理规范等等。
我也在这一时期，阅读了《人月神话》、《IT项目管理》、《UML》等很多相关书籍。

然而，问题很快就出现了。

在小公司，我们虽然是产品研发团队，但我们无法做到和项目的完全隔离，我们发布出去的版本还不能稳定的像Window，office一样out of the box，
在流程的作用下，实施人员开始抱怨对问题的响应太慢（因为大家都习惯了有问题直接找开发，而现在我们要评审、修改文档然后改代码发布），
用户的“紧急”需求被我们安排到下一版本，但市场通过老板来改变我们的版本发布计划，插入更加急迫的需求。

由于规范的实施，导致开发与实施＋市场产生了一定的对立（我不清楚这是我们公司的特例还是普遍情况），
因为中国公司的客户总是很急，市场压力很大，于是每隔一段时间，当矛盾激化的时候，田田就召集我们和负责市场和实施的人开会，
讨论的结果往往是如下几种：
1、这个问题，需进一步“优化流程”，还是寄希望流程解决问题。
2、我们开发力量不够，需要继续加人（但公司的实力是有限的啊）
3、实施方面保证目前面临的是一个特殊情况，开发方面暂时妥协，尽快解决问题（一个项目总有足够多的“特殊”理由）
4、要么没有结论，保持问题依旧（实际上是实施方面妥协）

在一次次的摩擦中，虽然乐乐一直坚定不移的倡导他的“RUP”，并将很多问题归结为“流程不够优化”和“人员不足”时，
我却在疑惑和反思。
在一家小公司，什么样的开发过程才是合理的？
产品化之路在小公司行的通吗？
RUP实施的越彻底，所带来的管理消耗越大，到底有多少小公司可以承受？

正当我为此郁闷不已的时候，听到了“XP”一词。
那是04年第一学期结束的时候，回学校给导师汇报毕业论文的计划，
她提到最近参加一次国际会议，会上有人讲解国外方兴未艾的软件开发思路：极限编程（eXtreme Programming，简称XP）。
老师描绘的由XP带来的快速交付能力和代码质量的巨大提升，让我觉得心动不已，但又将信将疑。

回家后，我立刻上网搜索相关信息，阅读XP的最佳实践，
从XP又找到了敏捷建模、敏捷思想，并熟知了一些大师们的名字。
这些先进的思想，当时给我的感觉就是“天上掉下个林妹妹，似一朵轻云刚出岫”，让人眼前一亮，
我隐约觉得我所追寻的东西，就蕴含在这些大师们的思想之中。

经过初步分析，我觉得XP对开发团队来讲过于激进，而“敏捷”这个宗旨是比较有现实价值的，
于是毫不犹豫的买下了大师们写的几本书，包括：
《敏捷建模》，《测试驱动开发》等。

以最快的速度看完这些书后（要知道，解决问题式的学习和无目标的纯学习那是太不一样了），
我在一次团队会议上提出尝试让开发团队变得“敏捷一点”的想法。
在我介绍了XP以及敏捷的核心思路后，乐乐表示不相信这样做会有效，而田田则不置可否，认为需要证实，
于是，我建议讲相关资料分发给大家去学习，然后再开会讨论此事。

大家经过学习后（我其实很怀疑有些开发人员是不是真的在意过这些事情），只有军军这个小伙子表现出跟我一样的兴趣，
在后来安排的会议上，我就像诸葛亮舌战群儒一样，跟大家辩论敏捷和RUP哪个更适合我们。
经过辛苦的辩论（这可比我论文答辩辛苦多了），我们终于达成一致，在开发团队试行“敏捷”的开发方式。

真正实施起来，敏捷建模或者XP编程远没有想象的那么简单，以我的经验来看，敏捷的成败取决于如下几点：
1、成员对这种思想的认知和认同
2、对参与者的水平普遍要求较高
3、要防止XP演变成自由主义

我们团队中试行的“敏捷”虽然没有达到老外们“宣称”的效果，但在改善代码质量，提升团队的响应速度方面，有比较明显的作用，
因此，在以后的日子里，RUP也慢慢不再被人提及。


以后几年里，我经历了几家有CMM资质的公司，但发现一个现象，那就是“资质是公司的，而不是团队的”，
也就是说，虽然公司过了认证，但团队在做开发的时候，风格更多的取决于团队的领导。
我在实际的软件项目管理过程中逐渐形成了如下信念：
1、无法执行的规定还不如没有规定。
2、代码质量应该在一切可能的情况下成为开发人员的第一目标。

而我从关注方法过渡到关注结果（代码质量），是04年下半年的事情。

－－－

我并不否认RUP的伟大意义，但以我目前的经验来看，不是每家公司都适合，至少以项目为本的公司，不适合。
然而敏捷或者XP也有较高的实施门槛，所以，实施起来也并不容易。
但对于个人来讲，提升自己提交物（无论是代码还是文档）的质量，是经营个人品牌的重要举措。

以前也讨论过读不读研的问题。学校的课程不是没有价值，但如果不考虑学历文凭，我们不上学一样可以学到，
但有一点，学校是一个思想交汇的地方，借助你的导师和同学，能够发现一些有价值的知识或者机会，这一点自己不容易成就。
就像我接触到XP一样。

在工作中，不要让流程或者制度成为推卸责任的借口。

我觉得刚开始接触XP的时候，其思想比现在要极端的多（也许是我当年的感觉比较极端），而今天我看到RUP for XP之类的字眼，实在感觉有些哭笑不得，

以RUP为代表的“工程化”软件开发管理思想，很重要的一个思路就是拿软件开发和建筑开发做比较，希望能够像盖房子一样来做软件。
但盖房子和做软件最大的差异在于，软件质量的度量比建筑质量的度量要复杂太多。
传统软件工程思想是希望稳定需求，通过关注过程而保证结果，
而以XP为代表的敏捷阵营，关注的是参与开发的人，以及提交物的质量，强调沟通、协作，主张拥抱变化。
我个人觉得，这两者真的蛮难融合的。


很多人说我写的慢，每篇写的太少。
呵呵，没办法啊，我有我的家庭，我有我的工作，
写点东西，都是在业余时间中抽时间，我的每一篇文章，通常都要花2－3个晚上，大家没法发现我经常凌晨发贴子吗？
我要回忆，我要有取舍，我还要注意行文的流畅，最重要的，我还要从中思考与总结。
我也不可能把所有的精力都来写这一个系列，我还得随时捕捉思想中的灵感，因为我目前的人生课题是“思考”。

这不是在写小说，各位担待啊。