01. 那些对速度（Velocity）的误解

误解1 – 点数跟天数对应？

用户故事的估点跟天数对应，1个点的故事对应2天的工作量；

统计每个用户故事所耗费的天数，如果点数对应的天数到了，先标记为“开发完成”，第二天Desk check就不用增加天数了；

为了赶进度，由结对改为不结对，原来结对的两人并行做不同的task，天数还是按照结对的情况来统计…

问题：

• 虽然按照故事点来估算，但是每个点都跟天数对应起来，而且不是理想人天，是实际耗费人天；
• 把这种估算当做一种承诺，要求故事需要在点数对应的天数内完成；
• 用户故事的只是关注开发完成。

到底该如何估算？点数又该如何使用呢？

误解2 – 做不完了给用户故事涨点？

如果用户故事没有在预定的天数内完成，需要涨点，那么得先说服客户；

列出涨点原因并且跟客户解释不是一件容易的事情，团队有时候宁愿加班加点按照原来的估点完成也不要去跟客户解释…

或者，为了避免以后涨点的各种麻烦，在估算的时候多估一些点，导致估点不准确…

问题：

• 开发团队的估算不应该受到外部因素的影响；
• 虚估点导致的估算不准确失去了估算原本的价值和意义。

估算的意义是什么？什么时候需要调整点数进行重估？

误解3 – 速度驱动一切？

周报里的速度保持稳定，每周每对pair在2个点上下；

性能调优，客户觉得目前看不到价值不给点，所以团队就不做了；

技术改进，同样的，客户看不到价值不给点，就不做了；或者团队实在无法忍受想要改进，那就从别的功能用户故事里多估算一些点来留时间给做技术改进；

目前组内开发速度不够，用户故事都做不完了，生产环境的support能给别的组就给别的组做吧，那个太耽误开发进度了！

问题：

• 一切围绕速度，如果比较顺利，满足了速度要求，团队可能就放松了，不一定会做更多的特性开发；如果不顺利，速度赶不上，那就可能面临着加班或者愁着怎么能给故事涨点以增加速度；
• 不再是业务价值驱动，不会正常的从价值的角度去考虑工作的优先级，速度被严重的误用。

速度有什么用？又该如何利用呢？

带着这些误解中引发的疑问，我们一起来探讨一下。

02. 两种估算方法

1. 基于故事点的估算

故事点是纯粹对用户故事大小的相对度量，不应该跟任何的天数或者工作量等关联。

用户故事本身的大小属性不会发生变化，基于故事点的估算不会过期，不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如，一个点数为3的用户故事，它的复杂度相对于那个点数为1的基准故事来说不会发生变化，不管谁、也不管用什么技术来开发这个用户故事。

故事点的大小是指团队所有角色工作加一起的统一估算数值，需要多个角色一起合作讨论才能得出这个估算，因此，故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意，不应该按照开发的点数、测试的点数去估算用户故事的大小，需要结合一起给出一个唯一的数值。

2. 基于理想人天的估算

理想人天的估算需要基于这样的假设：

• 所估算的故事是唯一要做的工作
• 所有需要的东西在故事开始前都会准备好
• 故事开发过程中不会被打断。

在不考虑其他因素的情况下，这种理想人天的估算是类似于故事点的估算方法，同样是一种相对大小的估算。

理想时间跟耗用时间是不同的。比如一场NBA比赛的理想时间为12分钟一小节，但是实际比赛耗用时间需要比这个时间长很多，因为中间有暂停、死球等时间。理想人天的估算是基于理想时间的，在软件开发过程中会有多个因素导致实际耗用时间跟理想时间会有很大的不同，比如开会、讨论等。

理想人天的估算方法很容易让人根据一个故事所需完成的任务多少去估算，而不是从这个故事跟其他故事的相对大小角度去考虑；不同人估算的理想人天也会有不同，导致估算可能会不太准确。这在估算的时候是需要特别注意的。

在团队不熟悉故事点估算方法的初期，理想人天的估算方法更容易开始；理想人天的估算对于团队外部人员更容易解释清楚，也更方便预测速度。

哪种方法更好

从前面的介绍可以看到，两种估算方法各有利弊，都是对于用户故事大小的相对度量，不能跟实际完成天数关联起来。通常，更推荐使用故事点的估算方法，根据团队自身情况也可以选择采用理想人天。

03. 什么情况需要重估

前面提到的误解里对于用户故事没有在预定的天数内完成考虑给故事涨点，也就是重估，这种以进度来驱动重估的做法是不对的。没有在估算天数内做完可能有两个方面的原因：
1. 估算不准确，低估了；
2. 被其他工作所打断，或者团队技术原因导致进度较慢…

发现估算不准确的情况可能需要调整，但不能是因为做不完赶不上进度而调整。当所有用户故事的相对大小是准确的时候，不需要重估；只有当其中一个或多个用户故事的相对大小不准确的时候，需要调整该部分用户故事的点数大小。

我们来举例解释这个问题：

1. 不需要重估的情况

假设一个团队有4个复杂度相当的用户故事，原本估算均为3，预计能够在一个迭代完成的。在第一个迭代结束后，只完成了其中的两个用户故事，也就是完成了6个点，团队感觉这两个用户故事比预估的要大，想调整为原来点数的两倍，由6变成12；由于四个用户故事的大小相当，剩下的两个用户故事也需要调整为原来的两倍，剩下的工作量也变成了12，同样的可能还需要一个迭代才能完成。这样的重估就没有意义。

因此，如果只是发现用户故事实际耗费时间比原来预测的要多，但是故事的相对大小并没有问题的时候，不需要重估，而是要去回顾和分析耗费时间长的原因，并采取相应的措施去改进。

2. 需要重估的情况

假设团队由A、B、C、D四个用户故事，刚开始给每个故事的估点均为3。在开发故事A的过程中发现A比原来估算的值要大，需要调整为5才合适，另一个类似的故事B也是一样，需要调整为5；但是C和D跟它们不一样，估算值应该是准确的，还可以保持为3。这种情况下对A和B的重估是有价值的，因为相对大小发生了变化。

04. 速度的作用

速度是对团队的进度生产率的度量，可以通过计算团队在一次迭代中完成的用户故事所分配的故事点数的总和来得到。比如，完成5个3个点的用户故事，速度是15；如果完成了2个5个点的用户故事，速度是10。关于“完成”的定义不能只是到“开发完成”，而应该是“交付完成”，开发完成不能说明什么，可能后续测试还不能过关、有很多缺陷需要修复等情况。

速度可以修正计划的误差。估算把对工作量的估算和对工作时长的估算完全隔离开来，将必须完成的所有用户故事的点数总和除以迭代的速度，可以推算出迭代的次数，也就是项目持续时间。我们通过一个例子来看速度如何修正误差：

假设团队估算出项目中包含了200个故事点的工作，一开始认为可以在每次迭代中完成25点，也就是将用8次迭代来完成工作。但是，在项目开始以后，团队发现速度只能达到20点。这样，不用对任何工作进行重估，就可以正确的认识到项目需要10次迭代，而不是8次。

速度不会是稳定不变的。根据团队对技术和业务领域知识的熟悉程度，速度可能会增加；而随着团队人员调整，有新人加入以后，速度可能会下降。在故事点估算准确的情况下，速度正好是反映团队状态的一个参数。不应该为了保持速度的不变去调整估算的结果，而应该根据速度的变化来观察和分析团队的健康程度。

05. 估算与计划

估算是为了更好的做计划，通过估算推算出的持续时间是一种可能性，而不是对交付时限的一种承诺。估算的是用户故事固有的属性，其大小不应该受到交付时长的干扰。老马在文章《WaterfallProcess》里讲到敏捷开发里的计划应该是适应性的，而预测性的、承诺性的计划不属于真正的敏捷。我们需要认真做好估算，尽量的准确，利用速度并根据团队状态和其他项目因素来适时地调整、修正计划。

客户都会希望更短的时间交付更多的功能，但是不要让客户只把目光关注到进度上，要引导客户更多的关注交付的业务价值。因此，在考虑任务的优先级的时候，需要以价值为导向，而不是进度为导向。比如，重构等技术改进、性能调优、生产环境的支持，这些可能比新的特性开发带来的价值更大、有着更高的优先级。

06. 小结

• 不管是故事点还是理想人天的估算方法，估算的都是用户故事的相对大小，跟实际完成时间没有直接关系。
• 不能因为用户故事没有在预期的时间内完成而进行重估，只有相对大小发生变化的时候需要重估。
• 估算是为了更好的计划，不能把估算当做一种承诺；速度是可变化的，可以用来修正计划的误差。
• 始终要以价值为导向，更多的关注质量而不仅仅是进度，计划应该是可适应性的。

07. 参考文献

1. 《敏捷软件开发实践：估算与计划》，作者：Mike Cohn，译者：金明
2. 《点之殇》，作者：冉冉，https://insights.thoughtworks.cn/story-point/
3. 《WaterfallProcess》，作者：Martin Fowler，https://martinfowler.com/bliki/WaterfallProcess.html

问：谁应该为质量负责？
答：QA是负责测试把关，主要负责吧，DEV也要在设计和代码上对质量负责。
问：那其他角色呢？
答：BA还好吧，跟质量的关系没那么大。
……

在蓝鲸项目，似乎大家对质量的关注意识有些欠缺，于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈，上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题，肯定不会有人回答不出。可是，事实并非如此 …

为什么会这样呢？我猜想可能是大家对质量的理解不一致的缘故，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责。

因此，我们来看看质量到底是什么？

质量是什么

产品质量不是检测出来的，从产品生产出来后质量就已经在那了。

——著名的质量管理专家戴明

在讲什么是质量之前，我们有必要区分两个不同的概念：测试只能检测、发现缺陷，而质量要通过缺陷预防来实现。 测试与质量不可同日而语，以后再也不要说“上线这么多问题，测试是怎么测的”这种话了。

那么，质量到底是什么？对于不同的角色、不同的利益相关者，质量有着不同的含义。总的来说，可以分为外部质量和内部质量两种。

1. 外部质量

顾名思义，外部质量就是软件呈现给用户的外部形态，是否有缺陷、是否稳定、是否有性能问题等。也就是最终用户在软件使用过程中的各种体验，包括软件可学习、高效、不易出错、有用、难忘等特性，都属于外部质量范畴。外部质量也可以称为使用质量，主要是从使用软件的用户角度来看的。

外部质量能够被用户直接感知到，直接影响用户的使用，因而显得特别重要，客户/用户一般也比较容易为外部质量买单。

2. 内部质量

同样的，内部质量就是指软件系统内部的质量状态，包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性等。内部质量主要从开发人员角度来看，也称为代码质量。

内部质量不会被最终用户感知到，不容易被客户/用户买单，也常容易被团队忽略。但是，内部质量会影响外部质量，需要团队引起重视，加强设计、开发等环节的质量把控。

3. 内建质量

质量不能被检测出来，要提高软件产品的内、外部质量，都需要通过质量内建（或质量内嵌）的方式，做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试：

• 自动化测试：从多个层次（单元、组件、端到端等）写自动化测试，并将其作为部署流水线的一部分来执行，每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时，都要执行这些测试。同时，随着项目业务和技术架构的演进，自动化测试策略也需要随之调整、不断改进。
• 手动测试：手动测试也是很关键的部分，如需求验证、演示、可用性测试和探索式测试等，在整个项目过程中都应该持之以恒的做下去。

另外，质量内建不仅要考虑功能测试，对于跨功能测试同样是需要做到内建的，比如安全内建、持续性能测试等。

软件构建过程中多大程度上做到了质量内建，有多少缺陷做到了提前预防，这是“内建质量”。内建质量虽然跟内、外部质量不在一个维度，但也是体现质量好坏的一个方面，在此也把它作为衡量质量的一个维度，测试或使用过程中发现的缺陷数量可以作为度量指标。

因此，我们可以从这三个维度来度量软件产品的质量，可以通过以下方式来度量：

外部质量：用户反馈、Support的问题数量

内部质量：code review、结对编程、静态代码质量检查

内建质量：测试环境、生产环境缺陷，Support的反馈

了解了三个维度质量的含义，我们不难理解：

❌质量不是零缺陷，不是百分百的测试覆盖率，也不是没有技术债；
✅质量是快速反馈，任何改变能够快速验证，并且快速修复；
✅质量是把精力都集中在正确的事情上；
✅质量是团队在代码、设计和交付上有信心做出改变；
✅质量是团队对任何改变负责。

容易忽视的质量

从前面对质量的定义，广义的质量其实包括软件产品交付流程中的方方面面，每个环节的一点疏忽都可能对软件质量造成不同程度的影响。下面列举一些从项目上经历的对质量关注有所欠缺的内容：

• 需求分析过程仓促，或者参与人员角色比较单一，导致业务上下文了解不够，关键场景缺乏考虑等；
• 忙于交付更多的feature，忽略了对代码质量的关注，该重构的没有重构，在原本不太健康的代码基础上继续增加更多的代码，导致混乱，筑起高高的技术债；
• 没有足够的测试覆盖，导致新增代码容易破坏已有功能；
• Dev提交代码后，就投入新代码的开发，对所提交代码缺乏关注，CI pipeline红了不能及时修复，可能影响后面QA的测试进度；
• 大面积的重构发生在release前夕，无法全面回归，带来很大的风险；
• 项目初期只考虑少量用户的场景，随着业务的发展，系统功能难以扩展，导致严重性能瓶颈；
• 技术选型失误，开发困难，没有及时改进，一错再错，最后问题严重到无法弥补；
• 第三方组件评估不够充分，导致线上环境无法承载等；
• 开发缺少对异常情况的处理，测试过程缺乏探索，只覆盖到主干路径，边角case可能引发问题；
• 开发或者测试都只考虑当前功能模块，缺乏更广范围的考虑；
• 缺乏跨功能需求的关注，导致严重的安全或者性能问题；
• 对线上环境了解不够，而且没有足够日志信息记录，线上问题难以定位，导致宕机时间过长；
• ……

这样的问题还有很多很多，无法一一枚举。每个角色，每个环节都有可能出现纰漏，导致产品质量问题。

那么，谁该为质量负责是不是已经很清楚了？

谁该为质量负责

前面已经讲到，质量是贯穿项目整个生命周期的非常关键的部分，质量保障工作也是需要在每个环节加强关注，每个角色都需要为质量负责。

上表列出的是敏捷开发流程中的各个实践活动，它们都与质量有关，每个活动都要求多个不同的角色同时参与。

下面从敏捷团队三个主力角色BA、QA和Dev的不同视角来看看各自怎么为质量负责。

BA：Busines Analyst，业务分析师

BA主要负责业务需求的分析工作，要理解客户的业务，并将业务分解成便于Dev和QA理解的功能点，同时，还要能够帮助用户验证开发完成的软件系统功能，并展示给客户。需求作为软件开发的源头，是极为关键的。

BA视角的质量，主要是需求分析的准确性和清晰度，要帮助团队对需求有一致的认识，从用户旅程的角度关注交付给最终用户的产品是否真的带来了价值。

Dev：Developer，开发人员

Dev作为软件系统实现的主力，对质量内建是至关重要的。从需求的理解、整洁的代码实现、测试覆盖率的保证、频繁的代码提交、持续的集成、对生产环境的关注、运维的支持等方面，都有着不可替代的职责，每个环节都不可忽略。

因此，Dev视角的质量不仅是按照需求实现功能的开发，还要把功能高效的交付给最终用户。

QA：Quality Analyst，质量分析师

QA作为软件质量的倡导者，是唯一一个全流程都要参与的角色，从需求到上线后的支持，每个环节都不可缺。清晰理解需求、制定质量保障策略、做好各个环节的测试工作（手动、自动化、探索式、跨功能、非功能测试，以及生产环境的QA等）、关注项目整体质量状态、及时反馈质量信息给团队、识别业务风险和优先级、帮助优化业务价值，这些都是QA的职责。

三个主力角色中的BA一般都会有从用户旅程的角度去考虑，其实Dev和QA也需要同样的思维模式，不能把story或者AC割裂来看，而是要从整体的用户旅程的角度、端到端的去考虑需求的实现和测试工作。

除了三个主力角色，团队还有其他角色也都是要对质量负责的，比如：架构师要负责项目架构的健康，基础设施负责人要管理和维护好基础设施以保障开发和运维工作的顺利开展，PM要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等，这些都是跟质量相关的。

写在最后

质量不仅是某个角色的事情，团队每个成员都撇不开质量这个话题。团队为质量负责要求所有质量角色都将质量推向看板的左侧，从每个用户故事的开始就将质量融入其中。

软件开发生命周期的每个环节、每个实践活动都不可轻视，只有在每个点上都做好质量的工作，才能实现真正的高质量交付，每个角色对此都有着非常重要的职责。