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

作者:陈勇

出处:blog.csdn.net/cheny_com

 

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

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

 

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

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

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

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

posted @ 2011-04-02 12:52  我的一天  阅读(163)  评论(0编辑  收藏  举报