敏捷与质量

 

敏捷与质量

 

陈能技

2007-10-9

 

原文：Agility and Quality – Alan S.Koch

 

摘要

对于什么是“质量”有很多的定义，“质量是由旁观者定义的”，有些人会说这是不可能使用的定义，因为它很难在真正的业务场景中工作。但是敏捷方法不同意。敏捷方法就是用这种方法让产品的质量由顾客塑造。他们承认不同的人会用不同的观点看问题，所以对于项目来说谁的观点最能说了算（最终顾客）就是敏捷方法要追求的。

 

项目的高质量是什么由什么组成的？不要问我！问你的顾客！

 

项目是用来学习的

在传统的软件开发方法中，我们努力构建顾客想要的产品。我们花费大量的时间努力从顾客那里获取需求，我们针对需求进行分析和建模，并且归纳成说明书。然后我们评审说明书，与顾客开会讨论，最后签字。看起来我们将要构建的产品确实是满足顾客要求的。但是通常那不是最终结果。通常，在项目快要结束的时候，需求和范围、产品的适用性成为争论的焦点。开发人员埋怨顾客改变了主意，顾客则不明白开发人员怎么会偏离这么远。

 

是谁的错？敏捷方法指出每个人都有错，但是每个人都没有错。他们告诉我们开发项目不是别的，而是一个学习的体验。没有谁能完全理解所有需求之后才开始项目；即使是顾客也一样。顾客一开始有一些主意，但是他们也在项目的进展过程中学到关于他们的需要。同样的，开发人员在一开始学习到他们能知道的东西，但是他们需要继续通过项目来学习更多的东西。

 

没有人完全清楚会构建出什么来，直到项目结束。因为每个人都在通过项目学习，敏捷方法改变了过程以便识别出持续学习，并培养每个人的学习能力。

 

他们通过把与顾客交互的过程从项目的开始阶段移到项目的“心脏”。不是摘取顾客的想法然后使用写下来的说明书作为开发的基础，敏捷方法使用顾客自己！他们让顾客有规律地参与到项目的每个迭代过程中来。

 

敏捷方法中的质量

在敏捷项目开始的时候，顾客和开发人员一起定义项目会做什么。他们建立XP所说的“项目隐喻”，这是用快速的大笔触描绘产品的大概样子。另外，会提炼出一份需求列表（XP称之为“故事”），但是不像传统的需求，这些故事不会有详细的细节，也不是一成不变的。

 

敏捷项目通过很多一个月左右的短期开发周期来增量地构建产品。每个周期开始于顾客决定哪个故事应该先构造。开发人员通过对技术可行性的分析来调节顾客的期望值，然后一起决定在这个迭代开发中需要成功构建哪些内容。

 

随着开发人员构建了增量的部分，他们需要通过测试来保证产品没有很多缺陷，像顾客需要的那样工作。在他们工作的过程中能随时得到顾客的回答，因此能感觉自信他们构建的是顾客想要的。然后，当开发的增量部分完成后，系统会交付顾客进行测试或使用（如果顾客选择这样做的话）。

 

开发人员和顾客之间都有很多反复的过程，任何人都可以随时对现在的需求提出更改，甚至删减或增加需求。对于顾客，这是他们对“高质量”进行微调的机会，结果是改变了对开发人员的指导。

 

从简单的bug修正到激进的需求改变都添加到“需求”列表。然后，在下一次的迭代计划中，顾客与开发人员一起制订下一步增量开发的内容，从而向顾客眼中的“高质量”产品迈进一步。

 

关于测试人员

开发人员负责在每个增量迭代中进行测试，顾客在迭代的最后进行“可接收测试”，看起来测试人员在这种敏捷方法中无处生存。目前敏捷方法关于“测试员”角色的讨论比较少，但是敏捷社区的讨论声音好像比较一致：认为测试人员在敏捷方法中有他们自己的位置。虽然这些讨论在继续，但是还没有一致的清晰的角色定义。

 

如果测试人员的目的是找缺陷，那么与开发人员的测试有点重复。如果他们的目的是站在顾客那边来判断系统是否满足需求，那么他们与顾客的接收测试有点重复。但是质量不仅仅是缺陷少和可用。质量是多维的，例如可靠性、可维护性、安全性、可用性、性能等。

 

测试人员能通过两种方式给敏捷项目带来真正的价值。第一个是通过专业的独立的测试扩展开发人员的测试和顾客的测试。独立的测试人员能从不同的视角对系统进行测试，因此他们会找到不同的缺陷或可用性问题。

 

第二种方式是专注于质量的其它维。开发人员和顾客的测试很可能忽略这些质量的方面，因此测试人员对它们的关注是项目成功的关键因素之一。

 

敏捷质量

敏捷方法对于产品质量来说有新的方式，专注于开发人员负责发现和移除缺陷，专注于顾客负责确保项目向真正满足他们需要的高质量产品迈进。这些方法做了很多恰当的工作来达到质量。同时，关于加入测试人员的角色使其更强大的讨论在继续。

 

敏捷和质量不仅仅是兼容的；它们还能很好地工作在一起。