有小伙伴就问，我们都敏捷了，我们是在效率和质量中找平衡，说敏捷开发中的质量是不容易控制的，要回答这个问题，我设计了一个FAQ，内容如下：
敏捷开发是什么？
敏捷开发是以需求为中心，以交付价值为目的，持续增量交付的一种软件开发方法，至于什么是敏捷，就去问问度娘吧。对于敏捷团队来说，是一个自组织的，有集体目标感的，打了鸡血的理论上的全功能团队。
软件质量是什么？
简单点说，软件质量就是软件产出的结果与原始需要的相匹配程度，包含的方面包括简装修、正确性、效率、完整性，可维护性，灵活性等等等等。
相对与敏捷开发，传统方式开发中软件质量是如何控制的？
一般来说，对于软件质量的控制是多角色、多层次的，一般会包含这些活动：
1、过程管理，一般由QA这个觉得通过一些手段来保证整个软件开发过程的正确性；
2、评审活动，通常来说，在项目中产生的所有成果物都需要经过评审才能被使用或接收，从需求开始，也包含所有的设计文档，测试用例，还有代码等等；
3、问题管理，经过评审了，那就不可能不出现问题，出现了问题怎么办呢，那就需要修正、跟踪，当然了，不是所有的问题就是由评审这个活动衍生出来的，也可能是由哪个项目干系人发现的，也有可能是由风险引发的；
4、测试，测试活动像项目中的其他活动一样，也需要计划、实施、验证，也会包含一些其他的管理方面，包括用例管理，缺陷管理等，另外，测试是分阶段分层次的，要根据需求的双向可追踪性进行测试规划，还有很多的测试策略等等，测试是一门专门的学科，有机会我们再探讨。总之，测试在软件研发活动种是重要的，也是必不可少的。
一般来说，反映软件质量的指标和工具有比如，代码测试覆盖率，单位缺陷密度，帕累托分析什么的，这些学过PMP的同学都驾轻就熟，我就不多说了。
在敏捷开发中如何保证软件的质量？
一般在敏捷开发中，提倡的是团队整体参与的做法。也就是说，不只是单单一个质量，所有的事情都是全民参与的。那角色还是那些角色，QA和测试干啥去？其实，在敏捷开发中，这两种角色有更高层次的价值体现，比如说，她们更像是一个团队支撑着和发现者。作为用户的角色参与到项目中，提供交付价值的建议帮助需求提供者确定验收标准，帮助团队搭建测试自动化工具，做探索性测试等等，保证需求和过程的正确。
在敏捷软件开发中，通常团队会做这些事情以保证质量，并贯穿整个开发过程中
1、团队中统一的标准和工具，统一的IDE，统一的编码风格和规范，甚至统一的作息习惯，让团队更像是一个整体
2、静态代码检查，既然有统一的编码规范，这个活动完全可以用机器来解决，不符合规范的无法提交到版本库
3、持续的单元测试，甚至是测试驱动开发（TDD），由编码人员同时编写单元测试用例和代码
4、持续集成，持续检查，持续测试，持续发布，在过程中保证代码、需求、活动、业务行为的正确
5、重构，敏捷是快速交付的，总有些技术债是要还的，代码的改进也是改进的一部分
6、回顾，事后诸葛亮的事，为项目目标造成阻碍的事件或者是一些典型的缺陷都要彻底分析
7、与客户合作，只有客户才知道他要的到底是什么（也可能有的时候根本就不知道），只有看见的成果才能有建议，满足客户的需要也是质量的重要部分
在敏捷中，我们跟关注缺陷或者问题存在了多久，而不是他存在多少，也就是缺陷或者问题的生命周期，这个指标一般我们会定义缺陷的几个状态，比如说，open-fixed-close-reopen等，我们看在每个阶段停留的时间，分别去看看缺陷定位的时间（缺陷是不是描述的竞争），缺陷修复时间（改了多久），改了几遍（改没改对或者引发其他缺陷的）。另外，现在比较火的就是DevOps了，好处就不多说了，在这个过程中，有很多地方都是与质量和业务价值相关的，有兴趣的小伙伴请自行度娘。
经常看到有小伙伴反映因为过渡到了敏捷开发导致质量崩塌的案例，其实我觉得大家都有个误区，不一定我们追求效率了，那一定就会牺牲质量（另外，敏捷绝对不是用更短的时间），只不过我们可能没有找到合适的方法，或者说团队还不是那么的敏捷。所以对于质量这件事来说，不管是传统方法还是敏捷，我觉得企业质量文化对软件产品质量还是最重要的。总是能找到一种合适的方法，把项目质量搞上去。
分享到:
閱讀更多 懶人項目管理 的文章
