怎样监控敏捷型软件项目质量

怎样监控敏捷型软件项目质量

敏捷开发是以需求为中心，以交付价值为目的，持续增量交付的一种软件开发方法，对于敏捷团队来说，是一个自组织的，有集体目标感的，打了鸡血的理论上的全功能团队。

而软件质量就是软件产出的结果与原始需要的相匹配程度，包含的方面包括健壮性、正确性、效率、完整性，可维护性，灵活性等等等等。

一般来说，对于软件质量的控制是多角色、多层次的，一般会包含这些活动：

①过程管理，一般由QA这个角色通过一些手段来保证整个软件开发过程的正确性；

②评审活动，通常来说，在项目中产生的所有成果物都需要经过评审才能被使用或接收，从需求开始，也包含所有的设计文档，测试用例，还有代码等等；

③问题管理，经过评审了，那就不可能不出现问题，出现了问题怎么办呢，那就需要修正、跟踪，当然了，不是所有的问题就是由评审这个活动衍生出来的，也可能是由哪个项目干系人发现的，也有可能是由风险引发的；

④测试，测试活动像项目中的其他活动一样，也需要计划、实施、验证，也会包含一些其他的管理方面，包括用例管理，缺陷管理等，另外，测试是分阶段分层次的，要根据需求的双向可追踪性进行测试规划，还有很多的测试策略等等，测试是一门专门的学科，有机会我们再探讨。总之，测试在软件研发活动种是重要的，也是必不可少的。

一般来说，反映软件质量的指标和工具有比如，代码测试覆盖率，单位缺陷密度，帕累托分析什么的，这些学过PMP的同学都驾轻就熟，我就不多说了。

那么在敏捷开发中如何保证软件的质量？

一般在敏捷开发中，提倡的是团队整体参与的做法。也就是说，不只是单单一个质量，所有的事情都是全民参与的。那角色还是那些角色，QA和测试干啥去？其实，在敏捷开发中，这两种角色有更高层次的价值体现，比如说，她们更像是一个团队支撑和发现者。作为用户的角色参与到项目中，提供交付价值的建议帮助需求提供者确定验收标准，帮助团队搭建测试自动化工具，做探索性测试等等，保证需求和过程的正确。

在敏捷软件开发中，通常团队会做的是： 

①团队中统一的标准和工具，统一的IDE，统一的编码风格和规范，甚至统一的作息习惯，让团队更像是一个整体。

②静态代码检查，既然有统一的编码规范，这个活动完全可以用机器来解决，不符合规范的无法提交到版本库。

③持续的单元测试，甚至是测试驱动开发（TDD），由编码人员同时编写单元测试用例和代码。

④持续集成，持续检查，持续测试，持续发布，在过程中保证代码、需求、活动、业务行为的正确。

⑤重构，敏捷是快速交付的，总有些技术债是要还的，代码的改进也是改进的一部分。

⑥回顾，事后诸葛亮的事，为项目目标造成阻碍的事件或者是一些典型的缺陷都要彻底分析。

⑦与客户合作，只有客户才知道他要的到底是什么（也可能有的时候根本就不知道），只有看见的成果才能有建议，满足客户的需要也是质量的重要部分。

敏捷是迭代的，但是迭代的不一定敏捷。敏捷更适合自己研发产品的那种互联网企业。

一般来说，敏捷的迭代都是固定周期，且在一定的速率下，有潜在可交付成果的。

敏捷的成本一般来说由团队整体负责，一般的做法是做一个成本目标，这里的成本不光是钱，还是有资源，还有人力还有时间，团队的目标就是在几个迭代中交付怎样的价值成果，以及想对应的成本目标。

在敏捷中，我们更关注缺陷或者问题存在了多久，而不是他存在多少，也就是缺陷或者问题的生命周期，这个指标一般我们会定义缺陷的几个状态，比如说，open-fixed-close-reopen等，我们看在每个阶段停留的时间，分别去看看缺陷定位的时间（缺陷是不是描述的竞争），缺陷修复时间（改了多久），改了几遍（改没改对或者引发其他缺陷的）。另外，现在比较火的就是DevOps了，好处就不多说了，在这个过程中，有很多地方都是与质量和业务价值相关的，有兴趣的小伙伴请自行度娘。

经常看到有小伙伴反映因为过渡到了敏捷开发导致质量崩塌的案例，其实我觉得大家都有个误区，不一定我们追求效率了，那一定就会牺牲质量（另外，敏捷绝对不是用更短的时间），只不过我们可能没有找到合适的方法，或者说团队还不是那么的敏捷。所以对于质量这件事来说，不管是传统方法还是敏捷，我觉得企业质量文化对软件产品质量还是最重要的。总是能找到一种合适的方法，把项目质量搞上去。

“我见过很多团队因为转型敏捷造成质量崩溃的事了，这就是对敏捷是个什么东西还没弄清楚，或者还没找到所谓敏捷能落地的策略，在这种情况下，不太建议直接转型。”