可工作的软件是首要的进度度量

敏捷开发强调的是交付价值，而交付价值怎么体现呢？交付价值只有在可工作的软件才能够体现。所以可工作的软件在敏捷开发里是非常重要的。价值观里有“可工作的软件 高于 面面俱到的文档”，12条敏捷原则里有“可工作的软件是首要的进度度量”。

可是由于受过去开发流程的影响，分为分析、设计、开发、测试四个阶段，产品团队在转型敏捷开发的过程中，往往意识不到这条原则的意义，还有的意识到了，但是当前能力达不到，结果形成每个迭代有一半的用户故事只做到了开发完成，没有进行测试，然后在周报里或者月报里就写上一个百分比的进度，结果第一周写完成50%，第二周到80%，第三周90%，第四周95%，第五周……，百分比一直上升，但是到底什么时候能够完成呢？

遇到这种问题，作为敏捷教练，怎么去协助团队解决呢？

首先需要和团队对齐目标。

在有的团队，产品负责人不关心每个迭代的交付，只关心3个月的产品里程碑计划，像这样的团队，就很难养成每个迭代都交付可工作的软件的习惯。所以在对齐团队目标时，首先需要跟产品负责人对齐目标，跟产品负责人展现按迭代交付的好处：按迭代交付是为了确保最终能够实现里程碑目标。不积跬步无以至千里，只有每一步走踏实了，3个月的目标才能够实现。可以拿历史的数据跟产品负责人进行沟通，展现过去的做法引起的问题。

跟产品负责人沟通，对齐目标后，需要跟团队对齐目标。按迭代完成可工作的软件，对团队的技能水平提出了更高的要求。过去一个项目做半年，系统测试做2个月，完全没有自动化测试，全靠手工点点点。现在需要每个迭代能够输出可工作的软件时，测试能力跟不上了，手工测试根本不能够去支撑。这时怎么办？只有自动化测试一条路可选，必须通过自动化测试来保障质量。

大多数团队都会卡在这里，因为不会写自动化测试。这个时候，团队经常以各种理由来说明做不到按迭代完成可工作的软件，就是不愿意承认不会写自动化测试代码。这个时候是比较困难的，关于写自动化测试，通常会经历如下阶段：拒绝、讨价还价、接受。

拒绝：对于不会的，普通人会先想着拒绝，会找各种借口：我们的产品质量要求不高，不需要写测试；我们的功能很简单，crud的，不需要写测试；我们的功能太复杂了，写不了测试；行业内有哪个公司在写测试？对于这些情况，一方面需要提供技能方面的支持，另一方面需要公司领导的压力，需要公司领导接受这个理念并坚持推广。

讨价还价：当被公司领导强压时，一般人就会被逼着做，这个时候就会跟公司讨价还价：写测试会降低开发效率，项目太紧急了，来不及写；把测试都写了，测试人员干嘛呢，不就失业了吗？原来这个功能做1天，现在需要做2天。说效率下降，需要的时间长，担心测试人员失业，从根本上来说还是因为不会写测试。这个时候，需要公司层面的坚持，还有培养出一些种子选手，教会他们写自动化测试，然后应用到日常工作中，让大家能够看到自动化测试带来的好处。

接受：慢慢的等大家都学会写自动化测试之后（不愿意学的就自然离开了），大家会意识到自动化测试的好处，习惯去写自动化测试，乃至于采用TDD方式进行开发。只有这时，才能做到每个迭代都输出可工作的软件，才能够缩短迭代周期。

可工作的软件是首要的进度度量，要能够实现可工作的软件，需要我们在思想层面和技能层面都进行提升，真正达到敏捷状态，持续地为客户交付价值。