怎样监控敏捷型软件项目质量？【下】-诊断会

本期话题：怎样衡量监控敏捷型软件项目质量（指标？工具？）【下】

一、背景说明

受诊人：有实体产品的项目一般都有成熟的质量管理体系，成熟通用的标准要求，但软件项目一般偏迭代和敏捷，没找到有成熟的度量体系指标，做为项目经理如何直观的监控到项目的软件产品的开发质量，有哪些好的通用的指标或管理工具。

公司正在认证CMMI4，正在确定项目度量项，暂时制定了工作量、偏差、缺陷几项指标，感觉无法反映出项目产品实际运行的质量情况。

二、诊断 

有小伙伴就问，我们都敏捷了，我们是在效率和质量中找平衡，说敏捷开发中的质量是不容易控制的，要回答这个问题，我设计了一个FAQ，内容如下：

问题1：

Q：敏捷开发是什么？ 

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

问题2：

Q：软件质量是什么？

A： 简单点说，软件质量就是软件产出的结果与原始需要的相匹配程度，包含的方面包括简装修、正确性、效率、完整性，可维护性，灵活性等等等等。

问题3：

Q：相对与敏捷开发，传统方式开发中软件质量是如何控制的？

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

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

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

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

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

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

问题4：

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

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

问题5：

Q：在敏捷软件开发中，通常团队会做哪些事情以保证质量呢？

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

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

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

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

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

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

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

三、 QA

Q：敏捷和迭代的区别是什么？

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

Q：敏捷的迭代是什么？

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

Q：敏捷开发，相关的文档什么的，都会弱化吗？一般哪些文档是必须的？

A：其实不是，其实如果你的组织曾经有完整的管理体系的话，在敏捷转型的过程中，一个合格的引导者会想办法把你曾经的过程帮助你们融合到敏捷过程中。

比如说需求，一般我们传统做需求会新做需求说明书，需求跟踪矩阵。

在敏捷中，我们是用需求故事看板和用户故事地图去代替这些东西。

Q：文档弱化，需求文档需要吗？若是没有的话，争议有依据吗？

A：如果是在一个敏捷团队中，理论上需求争议会被弱化。

一来，用户会参与到你的研发活动中，二来，你有更窄的反馈周期，然而，需求看板的作用是引发讨论和确认标准的。

Q：看了你们聊了这么多，我感觉作为甲方，我不需要敏捷，我需要快速迭代？

A：快速迭代增量开发，并持续的反馈和验证是对甲方有利的。其实做为敏捷来说，是一个持续的过程。就是团队在跟甲方也好，用户也好，不停的在对需求，不停的问我这做的对不对，不对马上改。

Q：敏捷项目的成本如何去管理呢？

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

结语：

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

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

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

讨论内容整理 ：

【以下关于项目团队管理的内容都来自于希赛「PM创造营」群内诊断会，由@小M妹妹 整理，由以下小伙伴分享完成@大懒-青岛-智能健身@小糊涂仙-重庆-物联网@Simon-杭州-聚合支付@沫水-合肥-软件@Lucy-成都-智慧园区运营@过客+郑州+实施@圣徒子-北京-人防环保政务三维GIS@啊潮-广州-互联网】