敏捷度量标准：七大类别

最新推荐文章于 2023-11-17 14:28:50 发布

赛希咨询

最新推荐文章于 2023-11-17 14:28:50 发布

阅读量295

点赞数

文章标签：软件工程敏捷度量

本文链接：https://blog.csdn.net/SaixiCo/article/details/130199299

版权

作者：Will Hayes ——卡耐基梅隆大学

越来越多依赖软件的国防部（DoD）系统的供应商正在舍弃传统的瀑布开发，转向使用敏捷。正如以前的文章所说的，敏捷方法对缩短交付周期和控制成本很有效。然而，如果要在国防部有效地实现这些优点，负责软件采购的人员必须熟练掌握监控这些项目的度量标准。本文着重介绍了卡耐基梅隆大学软件工程研究所的研究人员的研究成果，为监管用敏捷开发的主要系统的软件采购人员提供参考。本文还介绍了追踪敏捷度量的七个类别。

01、软件的实证法

国防部和联邦机构越来越多地采用软件密集型系统，而不是用内部资源来构建。然而，采购项目通常难以满足苛刻的成本、进度和技术目标。本文中提及的研究是我们先行工作的一部分，帮助国防部采购人士更有效地使用敏捷来克服这些挑战。我们最新的研究重点在进度监管和承包商，在之前研究的国防部管理和采购问题上进一步延伸，包括了信息安全保障。

许多政府和军事组织的业务机构都发现，他们的供应商、承包商正在使用敏捷。这些业务机构已经找到了新的方法，以更快的速度和更小的增量交付软件。然而，他们在使用这些技术时也遇到了困难，因为他们缺乏度量经验来把控进度。在这个领域中，存在一个详细的基础结构和一套相当好理解的定义。

当我们研究关于敏捷这一术语的编写、培训和讨论时，重点往往是由5～9人组成的团队在自主环境中一起工作。这些团队热衷于关注用户的价值，并采用经验法，但大部分的讨论都集中在小组上。

值得注意的是，在 Scrum中，通常是基于观察和实验做决策而不是前期规划。进度把控主要依赖于三个主要方面：透明性、检查和适应性。

在国防部的主要项目中使用敏捷并不是前所未有的。然而直到现在，出版物和培训课程都过于狭窄地关注开发团队。我们的研究结果表明，应用敏捷的组织在填补以小组为中心的度量和企业或项目层面所需的内容方面做得很好。因此，在满足大型项目管理需求的同时，不影响小型自主团队使用敏捷取得成功这一点很重要。

在许多大中型组织中，度量通常是在别人的要求下进行的，是让一方受益而强加于另一方的工作。一般情况下，遭到被团队领导和项目经理要求提供度量的人会反对。这种相互作用会限制敏捷的价值，而敏捷的旨在作为软件实证法的基础。

这种实证法包括实施爱德华·戴明的计划-行动-检查-行动循环，不过是在一个更直接更关注个人的层面上。这种方法涉及与开发人员之间更频繁的交流，并且更关注产品本身。

点击阅读文章—PDCA循环简介

从敏捷宣言及其12条原则的角度来看，展示进度的最好方式就是展示能力：用实际的产品来代替纸上的抽象概念。当然，如果没有纸上的抽象概念，产品也不可能构建成。但运用敏捷时，重点则是团队为自己的使用而收集的可演示的结果和数据。

02、敏捷的衡量标准

对敏捷开发来说，最重要的衡量标准之一便是交付商业价值。这些进度衡量标准虽然基于观察，但并不会损害团队精神。我们这项工作的主要目标是帮助项目经理更有效地把控进度。与此同时，我们希望团队在自己适应的环境中工作，并使用区别于项目层面、属于自己的度量标准。

我们就这一主题发表的技术报告----敏捷度量：敏捷外包的进度把控。该报告是由我、Suzanne Miller、Mary Ann Lapham、Eileen Wrubel和Timothy A. Chick共同撰写--详细介绍了敏捷团队度量的三个主要观点，这些观点在大多数使用敏捷时都适用：

◆ 速度。简单地说，速度反映了一个给定的团队在指定的时间内完成的工作总量。通常这是以每个冲刺阶段完成的故事点来衡量的。这种度量有时被敏捷从业者称为“昨天的天气”，似乎是为了表明它对当地条件和季节趋势的敏感性。事实上，大多数专家认为，速度是“团队独有的”，把它当作估算模型中的一个参数是错误的。团队的工作必须有自己的速度。

◆ sprint燃尽图。正如我们的技术说明中所详述的，这种图形技术为开发团队在冲刺阶段展示进度。当待办事项中的工作完成后，图表会显示工作的速度和数量。这个图表通常可以在团队的公共墙或电子仪表盘上查看。

◆ 发布燃尽图。作为冲刺阶段燃尽图的补充，发布燃尽图也被经常使用。许多人习惯于“sprint燃尽图和发布燃尽图”——尽管没有数学原理支撑。伴随着一次次的冲刺，交付的功能也在增长，发布燃尽图以一种直观的方式描述了这个过程。这个概念利用了工作流程管理工具和该概念的其他拓展。

我们的研究包括采访管理敏捷合同的专业人士，他们向我们提供了在国防部采办中成功地与敏捷供应商合作的专业人士的见解。

根据采访，本文确定了七种有效监控进度的方法，满足国防部常见的监管要求:

◆ 在使用敏捷时，软件规模通常用故事点来表示。这种方法是基于从用户角度(即用户故事)对功能进行分解的。将用户故事追踪到系统功能上可以有效地沟通工作中的层级问题，基于交付功能的进度监测将重点关注实用度和性能方面--而不是像代码行或功能点等。

◆ 必须追踪调查工作量和人员配置，因为它们往往是影响知识密集型工作成本的主要因素。使用敏捷不会改变这一基本事实，也没有必要大幅修改监控进度的机制。真正需要改变的是工作人员利用率。随着开发团队的稳定发展，使用敏捷时，团队架构中的专业人员中不再经常变动。一般来说，敏捷团队应该拥有所需的全部技能——尽管一些专业技术可能由兼职员工完成。此外，在监测合同绩效时，必须对打破既有的经验。在开发的早期阶段，希望人员配置缓慢增加可能是不对的；在项目的后半阶段(测试阶段)，可以减少开发人员了的想法也需要改变。组织可以建立测试团队，避开开发团队进行系统测试或回归测试。

◆ 计划表通常被可以反应工作进度。在敏捷开发中，其目的是要解决这个变量，并努力在明确的时间内使开发团队的绩效最大化。这对关系人的要求很高，他们必须及时沟通需求，并给工作排优先级。

◆ 在质量和客户满意度方面，敏捷提供了比传统方法更多的洞察机会。将重点放在频繁交付工作软件上使客户也能关注产品本身，而并非像需求规格和设计文档这样的过渡。对验证标准的着重关注（经常被称为 "已完成的定义"）加深了大家对所需功能以及对客户来说重要的产品属性的理解。

◆ 成本和资金结构可以根据敏捷的迭代性质进行调整。使用可选的合同资金额度或不确定交付不确定数量（IDIQ）的合同结构，可以增加开发组织工作规划和管理的灵活性。关于合同结构更详细的说明可以期待我后续即将出版的内容。

◆ 与传统的大规模瀑布开发方法相比，使用敏捷开发时，需求的表达常常变得不同。一个详细完整的需求规范说明文件(按照国防部的定义)通常不会被视为开始开发的先决条件。然而，以用户故事为代表，自由灵活地阐明、详细解释并重新确定需求的优先级对许多大型项目来说非常有利。需求变更产生的成本通常体现在必须用传统方法维护中间产品产生的连锁反应中。而敏捷开发的快节奏增量方法可以减少返工的程度。

◆ 交付和进度监控大概是用敏捷与用传统方法相比最大的区别所在。软件产品的（潜在可交付的）频繁交付，比平常通过检查中间产品更直接地了解进展。系统性能的展示让团队尽早改进完善，并确保正朝着预期的结果前进--而不只是确保在预算内按期完成。