十六 一体团队

大型团队敏捷实践得答应我3件事:

  • 我们追求一体化团队
  • 为何不能达成一体化团队
  • 如何达成一体化团队

精益生产中单件流模式最终依靠U型生产线实现,将传统生产方式中产生的库存及等待所产生的浪费降至最低,依靠需求拉动,和有缺陷及停止的制度,保证每件从U型流水线上流出的产品都是符合质量标准并满足需求的。

映射到敏捷软件开发中,将分析人员,开发人员,测试人员集中在一个一体化团队,每个团队的技能足以满足一个需求从设计,开发到测试各个阶段顺利完成,达到符合质量标准并满足需求的软件。这就是一体化团队的概念,就像精益里无处不在的U型生产线,它们处处体现着精益的基因。

在大规模生产的世界里,每个车间都负责生产一种零件,因为各个车间生产效率不同,每个车间都不同程度存在着库存或者等待的情况。市场的快速变化,使得这些库存成为不得不返工的零件,或者不得已低价销售,而等待造成的时间和人力消耗也是浪费的主要原因。

在传统软件开发的世界里,拆分小组的模式有多种:

  • 按照职责拆分:分析组、开发组、测试组、接口组、界面组等;
  • 按照技能拆分:C++组、JAVA组;
  • 按照模块拆分:客户管理组、个人用户组、开户组等;
  • 按照业务拆分:个人业务组、集团业务组等;

往往这种拆分是多维度的,例如:

  • 分析组:负责需求分析;
  • 个人业务组:负责个人业务相关的逻辑;
  • 集团业务组:负责集团业务相关的逻辑;
  • 接口组:负责接口配置相关工作;
  • 界面组:负责界面相关工作;
  • 测试组:负责测试工作;

往往这些小组被分散开来。一个相对敏捷化的团队会选择采用“岛式开发”并把这些组分部在各岛上,如下图所示。而完全传统的团队也许会被分布在不同楼层,并隶属于不同组织层级。

在这个例子里,客户需求被集中在“需求”中,验收物也是“需求”。因为“需求”的大小不一,有的开发时间可能超过了一个迭代,为了适应迭代化的要求,这些“需求”被拆分成若干用户故事。整个流程中的价值物就是“需求”,我们的目标是如何将“需求”转换成可交付的软件。一个典型的流程是:需求进入分析,拆分成用户故事,分派给若干组,各组开发完成后交给测试组,测试组收集所有完成的用户故事,对需求进行测试。

因为客户验收的交付物是“需求”,“需求”理论上便是这个生产流当中的价值,那么任何不以“需求”存在的“零件”便是不增加价值的东西—库存(客户不会对单独用户故事付钱)。这样在上面的价值流图中可以发现,红线才是真正增加价值的路径,而蓝线都在产生库存。产生库存的原因必然是各个小组(车间)生产的产出物速率不均匀,库存产生后的必然结果必然是测试车间必须等待所有用户故事(零件)都被完成,才能进行集成测试。

那么如果采用一体化团队的模式,联想精益生产中的U型生产线,每个子团队都配置有分析人员,来自每个模块团队的开发人员,和一位测试人员,那么在以下的价值流图中我们可以看出,没有等待产生(没有蓝线),每次从一体化团队产出的都是具备产品级别质量的软件,最后经过集成测试团队交付给客户。在这个过程中,不会有等待产生的库存,在发生需求变化的时候,可以从容变化(不需要返工库存),真正达到按需拉动的单件流生产模式。

因为界面开发的技术要求比较特殊,对业务的依赖较小,可以考虑将界面团队作为一只服务团队,资源自由灵活配置到两个一体化团队中提供支持,采取Pair的方法和业务开发人员一起完成用户故事(我们无法完美平衡进入生产线的需求对界面的要求)。此外,分析团队作为整个生产线的源头(原材料提供),考虑到消除知识壁垒,也可以作为一支独立存在的服务团队,为两个一体化团队提供加工好的需求(分析完毕)。当然每次价值传递都可能产生潜在的浪费和失真,但是团队分拆也可造成知识壁垒、交流不畅、管理难度大等问题,团队管理者应权衡两者带来的优劣,灵活配置。

一体化团队作为敏捷开发方法中最具精益思想基因的实践,事实上成为业内对敏捷的最大质疑—“如何在大型组织中实施敏捷”,换言之,你可以在一个10多人的团队中建立一体化团队,你如何在一个大型组织中建立一体化团队?不能在大型团队建立一体化团队的理由有:

  • 大型团队往往人员素质较低,长期按照模块化开发,技术能力和业务理解极为单一;
  • 大型团队往往对应复杂度较高的系统,系统架构复杂,耦合度极高,不适合特性开发,一体化团队经常“腐蚀”系统架构;
  • 大型团队对回归测试极为依赖,频繁提交导致回归测试经常失败,大家不敢改动,另一方面对测试的压力极大;

对应这三个问题,精益生产中是如何解决的呢?

  • 以人为本:尊重员工,组织各种学习交流活动消除知识壁垒,可视化各种操作工序,鼓励学习,丰田甚至采取终生雇佣制,实际上丰田在美国的员工远低于福特和通用员工的工资,但企业归属感和文化营造成为丰田留住人才的根本;
  • 持续改进:对于生产线的采取持续改进的态度,持续不断改进核心生产线,更新升级设备,让生产线不断适应新的生产方法;
  • 消除浪费:及时修复流水线上出现的缺陷,采用各种自动化检测工具装配在生产线上,任何残缺品都不能够流到下游;

那么在软件开发中,要达到一体化团队我们必须达到的条件是:

  • 鼓励学习和分享的人才培养氛围:尊重开发人员的工作,鼓励交流和学习新的技能和业务知识,消除知识壁垒,不人为阻隔员工,不有意识无意识的划分等级;
  • 重构:对系统进行必要的重构,消除强耦合,让系统架构适合特性化开发模式,同时养成重构的习惯,提升系统的可扩展性,杜绝坏习惯;
  • 自动化测试和持续集成:保证足量的自动化测试用例,和持续集成环境,及时发现提交时出现的缺陷及时修复,追求0缺陷;

这里我们可以看到,实施敏捷确实有些捷径,如果你的团队不超过12人,如果你是个新系统,采用轻架构,实行一体化团队的敏捷开发不是一件有难度的事情。但当团队人数巨大,系统又是耦合度极大的遗留系统,自动化测试又无法足量,质疑敏捷是否适应大规模团队是有道理的。

如果希望实施真正的敏捷,一体化团队是必然的一个阶段,当面临大规模团队又有计划实施敏捷,那么决策者应该问自己的是:

  • 我们是不是有足够鼓励人才知识交流的机制?
  • 我们是不是有一个足够健壮的系统架构?
  • 我们是不是有足量的自动化测试和持续集成环境?

如果任何一个的答案是“不”,那么我们离全面的敏捷还有一段距离,我们做的事情也很容易在未来某天成为流于形式,而不是精益基因决定的习惯,敏捷很可能最终失败。