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

作者: 陈勇

来源: 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％（客户在内部开发了该项目，但失败了），交付后一年仅报告了一个缺陷.

主要程序员是团队的核心，对业务有深刻的了解，对技术也有很强的掌握. 看起来很难找到这样的人，但是实际上，在某些情况下找到这样的人的成本比建立“每个人都知道业务和技术的团队”要低得多. 主程序员不仅效率更高，而且还提高了完成质量和采用的方案的先进性.

其他人，连同大大降低的管理成本，具有很高的投入产出比. 2003年，一个可以当主要程序员的人的薪水实际上只有一万元左右. 即使是现在（2011年），也几乎相同. 它可能无法与两个7500元的程序员相提并论.

尽管主要程序员似乎是关键，但实际上，“主要程序员做什么以及其他人做什么”是关键.

某些工作在高水平上效率不高. 例如，“搜索，下载并确认屏幕快照代码可用”的效率很难将效率提高2倍，因为该级别高2倍. “对于今天完成的2个功能，该功能增加了17个自动测试用例”. 这些任务应移交给其他人员.

对首席程序员团队的极端理解是，其他人将永远在一起做很多工作. 因此，要做好主要程序员团队的成长（包括一旦发现您的团队无意中变成了“主要程序员团队”），您需要执行以下操作:

1. 主程序员每天应该花费大约15分钟来解释一天的进度，其中添加了哪些功能和代码. 考虑到每个人每天只能写约110行代码（作者自己的统计数据），这种解释非常有效.

2. 其他人应该主动学习由主程序员编写的代码，尤其是那些经过自己搜索和验证后由主程序员重写或封装的代码. 他们之间的差异很好地表达了两个人之间的技术鸿沟. 他们应该学习并逐步消除差异.

3. 测试人员应每天阅读代码，然后进行测试. 测试用例应由主程序员提出，但应由测试人员实施. 测试人员应该顺便了解整个程序的设计思想. （作者注: 在MS Project 2003中使用“软件开发模板”创建项目时，您会看到测试人员通读了软件任务，可能是Microsoft自己的工作风格. ）

4. 首席程序员应主动将一些不确定的代码交给其他人去做，然后发现并促进新的程序员为自己做点事情. 作者的其他博客文章中将提到如何鼓励这个“挨饿的大师”. 简而言之，没有人可以饿死，一个好主人也不能饿死.

实际上，在将1234做好之后，主要程序员团队的人员增长比没有接触的杀害要快得多.

主要的程序员团队并不是万能的，并且更适合以下情况:

1. 行业中没有合适的人来开发新产品.

2. 高度机密的产品，例如博客作者制造的数字电视加密系统.

3. 某些游戏等创意产品很少有直接编程的程序员.

4. 公司发展迅速.

在大多数情况下，此类团队不超过10个，其​​中大多数是5个.

根据基于快速功能点的度量统计，小型团队的交付周期较大（拥有很的团队仍然强大），但是生产率较高（每人每天完成的国际标准功能点），团队的生产力可以达到国际标准值的4-8倍. 因此，通过将一个大团队分成多个小团队并安排主程序员来托管，是节省成本和提高生产率的一种好方法. 微软团队就是这种情况.

在一个大型团队中包含多个领导程序员团队的另一个好处是，它降低了沟通成本，减少了文档甚至代码的总数，并促进了使用高薪/权益来保留核心员工.

与敏捷开发合作

没有跨职能团队，没有Scrum Master，没有产品负责人（至少没有直接设计），这个团队的敏捷度如何？

实际上，主要的程序员团队仍然可以使用Product Backlog和Sprint Backlog，它们也可以用于连续集成/自动化测试. 优先级排序也是很自然的.

因此，完全有可能在已经成为既成事实的大师级程序员团队的基础上构建敏捷开发，并且要以刀为刀.

点击下载免费的敏捷开发教科书: “ Martian敏捷开发手册”

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-249288-1.html