Agile的第三个关键词，high-quality,consumable code，讲的是质量。

质量是范围、成本、进度等诸多因素综合博弈的结果（如下图）；同时还要在客户满意与不镀金、不范围蔓延之间不断权衡。因此质量问题往往非常复杂。

就像我们的软件业，质量问题一直是让人头疼的问题（这2-3年或许好一些），我们deliver的软件产品，似乎大多数都很折磨人。:-( 可是在很多时候，还真是“人在江湖、身不由己“。

那么如何解决质量问题呢？其实，致力于解决质量问题的研究由来已久，正如PMP课程上吴永达老师show给我们的PPT（如下图）。这里罗列的思想和理论背后有很多故事，有兴趣的话以后慢慢聊。

Agile汲取了很多上面的质量管理思想，如质量持续改进、零缺陷、JIT、Fitness for use等；并在此基础上进一步提出consumable的概念。确切的说不但要求consumable，而且每一次迭代（iteration，sprint）的成果都要consumable。

什么是consumable？

正如这些刚出锅的糕点，如果我点的是糕点，而你给我的是合格（物美价廉、三聚氰胺不超标），而且好吃（色香味俱佳，并有营养）的糕点，那么我就会觉得这些糕点可以称为consumable的。

映射到软件领域，如果满足以下三点，似乎也可以称为consumable的。

首先，deliver的东西的确要是糕点。也就是要能满足Stakehodler的需求。
这是最根本的，最重要的质量标准。背离了这一点就好比作文考试跑题，写得再好也很难及格。就好比我点的是糕点，那么无论你给我多么物美价廉的饮料，我也不能接受。

看似是废话？可是，在软件项目中跑题的事情比比皆是。其原因可能是甲乙双方都没有搞清他们共同的需求,或是需求不停的变化使我们打不准靶；在这种条件下deliver的产品的就是费力不讨好。
如何克服它呢？前面的关于StakeHolder和迭代的2篇文章已经提到了一些Agile里面的解决方案。

第二，这个糕点要能吃，合格
三鹿的确deliver了牛奶，可是三聚氰胺超标，这样的质量只能是死路一条！不管你是否“身不由己“！
软件项目deliver的产品也一样，有一系列的标准卡着你。要1000个/秒的并发量，cpu消耗量低于10%,Long Run 要坚持15天......这些都满足了，产品才合格。就像我是做监控软件的，假如我们的产品要监控WebSphere，而我们的产品和客户的WebSphere跑在一起时，消耗的cpu比客户的应用还高，那我们也是死路一条。

另外很多软件产品deliver的时候还带着一大堆defects(bug)，这就太不consumable啦。如果非要面对很多defects、limitation，使用很多临时性的workaround才能用你的产品，Stakeholder就会很郁闷,很受折磨! 因此,除了meet了各项指标以外,尽可能的避免defects也是很重要的。不过，现在来看好像还没有一个公司的一个稍微成型的产品能完全避免这种现象。

第三，这个糕点要好吃，有点像服务行业的微笑服务
这个很难，咸了不行，淡了不行，哎！众口难调！
做软件的也是，deliver的产品不仅要让Stakeholder能用，还要让他们用着爽，用着舒服、顺手！你的产品要比同类产品看着漂亮，逻辑清晰，点的东西少，输入的东西更要少......
听来有点像镀金吧？不是，因为这些已经成为客户的需求、市场的需求了，我们在最初的范围规划里边就要考虑们。这是必须的，买方市场。正如前面所说，软件业、软件产品从无到有的时代快过去了，现在或不久的将来是从有到成熟，从成熟到excelent的时代！

这些都做到了，目前看来一个consumable的产品就算炼成了。用一句Agile的话来说叫做Done is Done了。不过的确好难！
顺便说下，Done is Done就是说你deliver的东西是有意义的，是consumable的；给客户他们就用的很爽，给下一道工序，他们就用的很方便；不会返回来跟你打架、找后帐、返工......

那么，一个consumable的产品要怎样炼成呢？？？
如上图所示，传统行业炼了这么多年，其经验教训有很多，我们IT人要站在巨人的肩膀上，Agile人也是这样想的，那么就让我们先从新旧两类质量管理观点的对比开始吧。

现代的质量管理的主要观点是认为好的质量来自于好的计划，以及诚实和不取巧的贯彻计划流程；从而将问题扼杀于早期，帮助产品达到标准，满足Stakeholder需要。个人认为很有道理。而且PMP用的也是这个观点。

PMP给出的质量管理有3个主要过程。
1 质量规划
选择适当的质量标准（ISO），制定适于本组织的质量控制流程以达到这些标准。
2 质量控制
严格走流程，确保deliver的产品符合质量标准。
3 质量保证
审核Team是否遵守了流程，审核流程本身是否合理，提出流程改进措施。

Agile也采用了这些过程。而且更有的独到之处。
1 质量规划
选择质量标准是所有项目必须的，Agile了也是这样。不同的是Agile里边还要强调consumable和Done is Done。
为了达到这些标准，Agile也有很多流程。以我们的实践为例。
首先，我们会通过Stakehoder分析，customer参与开发，以及Stakehoder在每个迭代后的review等一系列活动，确保team及时准确的获取Stakeholder需求，迅速调整team行动方向，从而使产品达到质量的根本需求，即不跑题，满足客户需求的目的。
第二，我们会通过一系列及时而必要的测试和review保证产品合格，达到既定的技术指标。例如通过carefuly design， design review，在第一时间保证设计符合客户需求，并且从技术角度来看完善而合理；在功能，集成，性能，翻译，刻盘，regression等很多可能造成系统defect的领域综合考虑，防患于未然。通过UT和code Review保证code正确、规范、易维护。通过FVT(Function Verfication Test),SVT(System Verfication Test),Performance Test,GVT(Globalaztion Verfication Test)，TVT(Translation Verfication Test)， Accessibility Test，Media Check， Regression Test等保证产品自身质量。
第三，我们也会有专门对于Consumablity的研究和测试，让用户高高兴兴的用我们的产品。

2 质量控制
流程确定了，就要执行流程并按技术指标检查可交付成果。具体的技术指标因不同项目、产品不同而异。但有一点值得一说，就是Virtual Zero Defects。
所谓Virtual Zero Defects，就是在每一个Sprint结束的时候，产的defects基本上为0；尽最大所能不把defects defer到下一个Sprint，更不能留给customer。在这个名词里之所以用Virtual，是因为defect为0不一定真的可以达到；但适用ZERO是一种态度和方法。个人强烈推荐Zero Defects的做法，因为遗留的defect会给你未来的工作带来意想不到的可怕后果。
Virtual Zero Defects后，Defect的backlog的形状应该和下图有相似之处。应该是不言而喻了吧，希望你有同感。

3 质量保证 Agile的质量保证相对于通用的PM来说是个亮点。 Agile有更多的跌代，因而在Agile里边我们会有更多的机会去take reflection。去审核我们流程的执行情况，并提出改进措施。就像前面质量规划里边说的，我们定义了那么多过程，没有人能保证他们是永远正确的，是永远必要的？因此，我们会在每一个spint结束的时候审视他们，调整他们，使他们更科学，更符合时宜。这才是辩证的，现身说一下，通过这种高速迭代的质量保证活动，我们的team在很多方面进步神速！ 此外，我们是IT人，我们有很强的自动化能力，因此我们在质量保证里也强调了自动化的东西。而且在高速迭代的Agile里边，为了避免Regression Test成为越来越重的包袱，我们也必须使用自动化技术。自动化的东西通常更客观、而且高效。在Agile里我们通常用下面几个关键词，代表了几种自动化的方向。 Automation：通常指的是自动化测试，包括功能、性能等 Test Driven Development(TDD): 测试驱动开发，狭义的来说是code及的自动化测试，像junit、cppunit的使用。 Continue Integration（CI）：通常指build的自动化。 这些名词在这里是个引子，他们都有很多技术的背景。我会在后面的文章里详细讨论。 因此，一个完整的scenario是 1）Developer Check in Code 2）TDD脚本本驱动被驱动，对code逻辑进行校验 3）CI Extract new Code 并 Build test images 4）Automation dispatch images 并 自动测试。