4 敏捷的挑战-衡量交付的价值
对于传统的、瀑布式的软件开发项目，功能性和非功能性需求一般在前期就已经确定了，在开发阶段不允许（或很少）进行更改。因此，就可能会导致在经 过长期的交付和测试阶段后，软件的需求变更可能已经很小。
敏捷开发的主要思想是通过短的反馈循环快速交付软件。敏捷开发是软件行 业中主流的方法，其优势如下：
⚫ 灵活性和适用性：敏捷方法，如Scrum或看板，优先考虑适应性。为了 使团队能够快速响应客户或市场需求，它们甚至可以在开发过程的后期更改需求、设计和优先级。
⚫ 以客户为中心：敏捷专注于通过迭代开发周期为客户提供价值。通过客户或其它利益相关者的定期反馈可确保交付的产品与客户需求一致。
⚫ 快速交付价值：敏捷强调在sprint（小型增量迭代）中交付工作产品。这意味着软件的功能部分可以快速交付，在开发过程的早期提供可见的交付。
⚫ 质量提升：持续的测试、频繁的评审和迭代有助于提高产品质量，及早发现并解决问题，可以降低最终产品出现重大缺陷的可能性。
⚫ 增强团队协作：敏捷可以促进跨职能团队之间的协作。每日站会、定期沟通和对任务的共同所有权都培养了团队合作和集体责任感。
⚫ 透明度和可见度：敏捷实践通过项目进度、挑战和障碍对所有团队成员可见的方式来提高透明度，有助于团队及时发现和解决问题。
⚫ 风险缓解：将项目分解为更小的迭代可以实现更好的风险管理。可以及早发现问题或障碍，并在更短的时间内解决，从而降低项目的总体风险。
⚫ 强调持续改进：敏捷方法强调持续改进。在每次迭代结束时，团队都会反思哪些工作的好，哪些不好，并为下一次迭代做调整。
⚫ 适应性规划：敏捷不依赖于僵化的长期规划。计划会根据反馈、不断变化的市场条件或新的需求进行调整，从而实现更有效、更现实的规划。
⚫ 客户满意度高：让客户参与整个开发过程并提供满足需求的功能，敏捷通常会带来更高的顾客满意度和更好的产品市场适应性。
这些优势有助于敏捷在产品交付方面的普及和成功，敏捷产品更符合客户需求，质量更高，并能以更高效和适应性更强的方式完成。
4.2 敏捷调查
在大多数企业中，每个团队的预算是可以预测的（每个团队成员的工作时间*每个团队成员成本），但产生的价值却并非如此。使用故事点度量的团队有时可能看起来非常高效，但实际上可能并没有产生预期的价值。如下图所示。
在图中，假设一个团队开始开发最小可行产品（MVP），并且正在进行的开 发使用Scrum（一个用于项目管理的敏捷框架）。
在图中的Y轴上，每次sprint的固定容量为1000工时。这些工时用于需要进行的各种活动。在第一次sprint中，可以在新增功能（绿色模块）上占用大量 的工作量。当然，也有一些必要的任务不能直接提供功能规模，例如设置测试环境等。这些任务（红色模块）是必要的，但不会产生可见的价值。因此，团队应 该尽可能少在这些没有产生可见价值的任务上耗费工作量。
随着时间的推移，客户可能会更改已开发的功能（蓝色模块），甚至删除已开发的功能（橙色模块）。在sprint中后期，可能会出现新的红色模块。比如：代码重构和bug修复， 在MVP上线后，可能还需要三线支持。
如前所述，许多团队使用主观的、相对的、工作量估算的故事点方法。他们将故事点分配给所有需要工作量的任务，但没有考虑任务类型。因此，红色模块也会分配故事点，因为它们也需要工作量。下图解释了这一说法。
当看到开发的故事点时，管理层可能会对团队的表现非常满意，因为团队每次sprint可以产生80个故事点，因此他们认为估算是准确的。然而，当查看以添加、修改和删除功能综合来表达提供的价值时，团队绩效会随着时间的推移而下降。
例如，当 MVP 的功能规模为 500 功能点时，故事点度量方法并不能看出：MVP 何时准备就绪，是否能够按时交付且与业务功能保持一致。而功能点度量方法可以。
功能规模测量的 Nesma 标准（ISO/IEC 24570-1983）中定义了特定时间段（例如，sprint、月份、版本、季度等）内项目规模的概念，如下所示：
项目规模=新增功能+修改功能+删除功能
项目规模是开发团队创造的价值，与项目规模相关的度量指标如下：
⚫ 生产率：工时/项目规模；
⚫ 成本效益：成本/项目规模；
⚫ 交付速度：项目规模/月数；
⚫ Sprint 质量：缺陷数/项目规模。
通过测量这些指标以及故事点，团队、产品负责人和管理层可以了解团队的真实绩效，也可以使用ISBSG数据对团队绩效进行基准测试。
5 度量方法的特点
好的度量方法都有共同的特点，这些特点能够有效地衡量团队绩效或项目进展：
1、相关性：应与项目目标直接一致，必须度量对预期结果有实际影响的指标；
2、清晰度：应该易于理解和解释，模棱两可或复杂的指标可能导致混淆和 误解；
3、可度量：度量是可量化的，或者至少有一个明确的度量方法。可以随着时间的推移进行一致的跟踪和比较；
4、可实施：好的度量应该是可实施的，并可以指出需要改进的地方；
5、及时性：应及时提供信息，实时或定期更新的度量方法通常更有价值， 因为这样有助于快速调整和决策；
6、一致性：在不同的时间、团队或部门之间保持一致和可比性。一致性确保了评估进程的可靠性；
7、成本效益：收集和分析过程不应过于耗费资源。使用该方法的成本应取决于其提供的价值；
8、战略一致性：应与企业更广泛的战略目标挂钩，因为这样有助于衡量实 现这些总体目标的进展情况；
9、背景：需要了解度量方法的背景，在不考虑背景的情况下进行比较很可能会产生误判；
10、闭环：良好的度量方法有助于形成闭环。
在下表中，从企业管理层面（包括利益相关者，如产品所有者、高级IT经理和管理层）对故事点度量方法和功能规模度量方法的特点进行了评价。
表中各符号含义：+++：非常相关，++：主要相关，+：部分相关，-：相关 性不大，---：不相关
那么，为什么在使用功能规模度量方法的企业却不多呢？在传统的软件开发时代，人们把许多项目的失败原因都归咎于功能点，因此功能点在当时使用并不 广泛。此外，反对使用功能点还有一层原因：由于需要经过认证的专家来度量功能规模，因此使用功能点方法的成本非常昂贵。
如今，有一种技术可以从用户故事中自动度量功能规模。此外，由于sprint中开发的功能通常是有限的（通常每个sprint 不超过100个功能点），因此手动度量所需时间非常短。例如，使用功能规模度量方法可以在2到4小时内度量一个Sprint的项目规模。Scrum大师或产品所有者都能够很容易地学习该方法。
6 总结
故事点度量对团队层面的规划非常有用。但是，故事点方法不适用于进行团队间的相互比较或与行业数据（如ISBSG数据）进行比较。
功能规模度量中的指标，如生产率、成本效益、交付速度和Sprint质量，是客观且可重复的，它们不依赖于非功能性和项目需求。
企业应致力于提升团队功能规模度量能力和使用自动度量功能规模的技术，从而帮助管理层提高其企业的价值交付能力。
以上就是软件造价评估公司中基数联为您带来的“故事点和功能点度量方法的主要差异分析（下）”所有内容，更多软件开发成本估算知识敬请关注中基数联！
