从生产线到生产岛：理解敏捷开发中的设计与测试活动

作者：陈勇

出处：blog.csdn.net/cheny_com

 

所谓生产线，就是大家各司其责，在一个线性的过程中配合工作。生产线尝试借助专业分工来提升效率，但也导致了问题：在传统生产线中，下游获得的中间产品是不太需要理解就可以在其上继续工作的，比如装配了一半的汽车，加工了一半的食品等等。

但在软件开发中就不一样了：人们需要深度理解上游产品，才能继续自己的工作，而这种“深度”最终导致了中间产品的膨胀，而中间产品大多数属于那种“没有它软件造不出来，等软件造出来它也没用了”的那类。另外一个严重问题是：各个产品线互相需要替对方解决问题，比如设计组设计不到位，开发组就要在开发中替其思考设计问题，而开发组质量不到位，测试组就要加班测试帮助其找缺陷。这种代劳而非协助的工作方式起因于分工，而最终会导致各个部门之家推诿打架。

 

生产岛则截然不同。假想一个人或一小群人失落荒岛，人们本非农民渔夫猎人，但却都有职责完成这些工作，而不能互相推诿。发生问题时主要工作不是弄清楚谁的责任，而是弄清楚如何解决，这样就解决了生产线上的打架问题。敏捷团队就是一个生产岛团队。

由于倡导故事负责制，敏捷开发人员更多地纵向分工，即一个人要跨越需求/设计/编码/测试这些工作。在139团队（另有博文描述）和“松结对编程”（另有博文描述，尚未写）中我们曾经提到过，为了解决并非每个人都能胜任需求/设计工作的问题，我们会安排类似1+3的松结对模式，即由一个高手带领三个新手结为一组完成一组工作，前者除了自己承担开发任务外，还以共同参与的方式帮助后者完成需求/设计工作。

那么类似测试这种人人都能胜任但却没人愿意干的活动怎么办呢？那就是以前曾写博文提到的敏捷测试。在“持续集成/自动测试”中，发现缺陷的不是测试人员而是提交代码的开发人员，这就把测试人员替别人发现缺陷变为帮别人发现缺陷。更进一步，如果开发人员自己开发测试程序（至少是可回归的功能测试程序），那么开发人员就在自己帮助自己了。如果有一天缺陷缠身，需要反省和行动的是整个开发团队，而不是测试团队指责缺陷太多，而开发团队指责设计不明确。