作者：陈勇


 

主程序员团队是曾经风靡一时的小型研发团队组织架构形式，很多团队都曾经有意无意地使用过。其模式是：由一个最好的程序员编写所有最终代码，其他人只进行测试及辅助工作。乍看起来与Scrum的“跨职能团队”差别很大，但由于其提出也是为了达到更高效率、更高质量、更快响应变更等目标，与敏捷开发可以进行组合使用。

软件界常见的一种现象就是程序员之间的相差水平很大，业界的数据是在1～10倍之间，极端情况下可见到看20倍的情况。笔者在01～04年亲自观察到的情况包括11天的工作被1.5天替代、约2个月的工作被2周替代、约1个月的工作被一下午替代、一个项目经理私下里告诉我他其实编写了所有代码中的60%（团队有6个人）、约13个人用9年编制的程序被1个人用1.5年基本重写等等，在各个实例中后者无论效果、效率、质量都高于前者，而后者程序员的水平也高于前者。在这些案例中的却存在一些前期的探索促进了后期的效率的现象，但因为笔者亲身经历，可以确认其中的主要原因还是在于人的差异：实际上高手很少去参考新人失败的探索所得到的成果。

主程序员团队就是基于这一思想产生的，笔者在02～03左右有幸在两个项目中尝试过，无论进度和质量都超出之前管理过的项目。比如其中一个项目周期据客户透露只有客户原计划的55%（客户曾内部开发此项目但最终失败），而在其交付后的一年里只报告过一个缺陷。

主程序员是团队的核心，对业务的理解和对技术的把握都要很强。看似这样一个人非常难以获得，但实际上某些情况下要找到这样一个人的成本远远低于建立一个“人人都对业务和技术有所了解”的团队。主程序员不只是效率更高，完成的质量、所采用的方案的先进性也远远超出

其他人，再加上大大降低管理成本，投入产出比很高。在03年一个可担当主程序员的人员工资实际上只需要1万元上下，即使当下（2011年）1.5万元也就差不多了，其可能产出绝非两个7500元程序员可比。

尽管主程序员看似关键，其实“主程序员到底做什么，其他人到底做什么”才是关键中的关键。

某些工作并非水平高效率就高，比如：“搜索、下载、确认一段屏幕截图代码可用”的效率很难因水平高2倍而提高2倍效率，“为今天所做的2个功能增加17个自动测试用例”也是如此。这些工作就应该交给其他人员完成。

对主程序员团队的极端认识是：其他人永远打杂切无出头之日。因此要做好主程序员团队的成长（也包括一旦发现自己的团队无意中变成了“主程序员团队”），需要做好以下几点：

1. 主程序员每天应抽15分钟左右给大家讲解当日的进展，增加了哪些功能和代码。考虑到每人每天所能编写的代码其实只有110行左右（笔者自己的统计数据），这种讲解是很有效的。

2. 其他人员应主动学习主程序员编写的代码，尤其是那些经自己搜索、验证后，被主程序员重写或封装的代码。其中间的差异很好地表达了两个人自身的技术差距，应学习并逐渐消除差异。

3. 测试人员应每天通读代码后再行测试，测试用例应由主程序员提出但由测试人员实现，测试人员应顺便由此了解整个程序的设计思路。（笔者注：在MS Project 2003中用“软件开发模板”创建项目时，会看到有测试人员通读软件的任务，大概是微软自己的工作风格。）

4. 主程序员应主动将一些非决定性代码交由其他人来做，并进而发现和提拔新的程序员替自己做一些事情。关于如何鼓励这件“饿死师傅”的事情在笔者其他博文中会提及，简单说就是能被饿死的都不是什么好师傅，以及好师傅不可能被饿死。

实际上做好1234后，主程序员团队中人员的成长远比一人一摊打死不相往来要快得多。

主程序员团队不是万能的，比较适合下述情况：

1. 行业新产品研发，找不到合适的人的。

2. 高度机密产品，比如博主做过的数字电视加密系统。

3. 创意产品，比如某些游戏，直接编程的程序员很少。

4. 公司快速发展的。

多数情况下此类团队都不超过10个人，5个人居多。

从基于快速功能点的度量统计结果看，小型团队的交付周期较大型团队长（人多的团队整体战斗力还是强），但生产率高（每人天完成的国际标准功能点数），部分团队的生产率可达到国际标准值的4～8倍。因此把大型团队切分为很多小型团队并安排主程序员来主持是一种很好的节省成本又增加生产率的方法。微软的团队就是如此。

在大型团队中包含多个主程序员团队的一个附加的好处是降低了沟通成本，降低了文档甚至代码总数，且便于使用高薪/股权来保留核心人员。

与敏捷开发的配合

没有跨职能团队，没有Scrum Master，没有Product Owner（至少没有直接设），这个团队怎样敏捷？

其实主程序员团队仍可以使用Product Backlog和Sprint Backlog，也一样能持续集成/自动化测试，优先级排序也是自然的。

因此完全可以基于已经成为既成事实的主程序员团队建立敏捷开发，心中有刀胜过手中有刀。