|
敏捷开发已经有了很成熟的实践集合，所以它可以覆盖大部分GJB5000B的实践域。相对来说，在GJB5000B的4大实践域类别中，敏捷开发对于项目管理类和工程类实践域覆盖较全面。 这里继续介绍下敏捷开发的GJB5000B工程类实践域的实施。 5. 同行评审 PR 3.1 建立并维护同行评审规程和准则 敏捷开发没有这方面的实践，本实践的实施按照GJB5000B要求进行。 PR 3.2 准备同行评审 根据需要，在评审前准备相关材料。 PR 3.3 同行评审 敏捷开发中的评审多数为非正式的评审。开发人员的办公环境可以很方便地进行两人或多人的交流。需求、设计等的评审都是通过这种方式进行的。代码的评审，因其使用结对编程，是由领航员负责的（结对编程中坐在前面操作键盘的称为操作手；坐在操作手的后面审查敲击出来的代码的称为领航员）。 敏捷开发中较正式的评审是迭代评审，它是在每次迭代完成后对本次迭代的成果进行确认。 PR 3.4 处理同行评审问题 敏捷开发在非正式的评审如结对编程和较正式的评审如迭代评审中发现的问题，要及时进行处理。 PR 3.5 分析同行评审数据 每次迭代完成后，敏捷开发会进行迭代回顾——总结本次迭代的经验和教训，以便在后续迭代中改进。在迭代回顾中可以完成本次迭代的同行评审数据分析，评价同行评审的有效性。 6. 验证与确认 VV 2.1 选择要验证与确认的产品及方法 敏捷开发的验证与确认方法有非正式的评审——结对编程中领航员对操作员编写的代码进行审查、自动化测试等。 VV 2.2 建立并维护验证与确认的规程和准则 敏捷开发实施测试驱动开发，编写代码前先写测试；软件在交付或发布前需要先通过验收测试。 VV 2.3 建立并维护验证与确认的环境 根据测试需要，搭建测试环境。 VV 2.4 执行验证与确认并记录、 沟通和处理结果 敏捷开发实施测试驱动开发，每日构建前进行自动化测试，软件交付或发布前进行验收测试，在迭代评审时沟通测试结果。 VV 3.1 分析验证与确认的结果 敏捷开发对于持续集成过程中的自动化测试、软件交付或发布前的验收测试结果要进行分析，发现存在的问题，在迭代回顾中识别改进机会。 VV 3.2 基于组织级可重用资产实施验证与确认 敏捷开发没有这方面的实践，本实践的实施按照GJB5000B要求进行。 VV 3.3 开展可靠性安全性等通用质量特性的验证与确认 敏捷开发没有这方面的实践，本实践的实施按照GJB5000B要求进行。 7. 运行维护 MT 2.1 策划运行维护活动 敏捷开发没有这方面的实践，本实践的实施按照GJB5000B要求进行。 MT 2.2 提供技术支持与服务 敏捷开发实施的是持续交付，每次交付都需要开发、测试、运维协同合作，能够及时监控软件的健康状态，发现维护需求；而且由于与顾客代表及时沟通，也能及时发现维护需求。 MT2.3 开展产品升级与维护 敏捷开发通过与顾客的沟通，能够及时获取软件升级维护需求；开发人员完成软件升级通过验收测试确认软件满足需求后再进行交付或发布。 MT 3.1 分析并使用运行维护数据 敏捷开发没有这方面的实践，本实践的实施按照GJB5000B要求进行。 这正是： 工程活动用敏捷，大多实践能符合 对照标准找不足，逐步完善无差错 作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。 |
|
|
