主程序员团队与敏捷开发的联合应用（小型敏捷团队管理）

最新推荐文章于 2022-10-18 23:21:07 发布

火星人陈勇

最新推荐文章于 2022-10-18 23:21:07 发布

阅读量3.9k

点赞数

分类专栏：敏捷开发文章标签：敏捷开发敏捷测试工作产品微软

本文链接：https://blog.csdn.net/cheny_com/article/details/6191656

版权

敏捷开发专栏收录该内容

217 篇文章 8 订阅

订阅专栏

作者：陈勇

出处：blog.csdn.net/cheny_com

主程序员团队是曾经风靡一时的小型研发团队组织架构形式，很多团队都曾经有意无意地使用过。其模式是：由一个最好的程序员编写所有最终代码，其他人只进行测试及辅助工作。乍看起来与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后，主程序员团队中人员的成长远比一人一摊打死不相往来要快得多。

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