如果对敏捷有所了解的话，肯定很多人会知道敏捷关注“完成”的热情是非常高的，甚至还会有DoD（Definition of Done）这种专属名词来定义完成。至于敏捷软件开发宣言以及背后的十二项原则里面与完成有关的内容也是有不少，相信大家都比较熟悉，我就不再赘述了。

现在问题来了，为什么我们在敏捷中如此重视敏捷？

在我的这些年的敏捷经验中，我总结出来的有以下几个原因：

这个现象，简单来说就是“本周你问A你的这项工作完成百分比，他告诉你90%；一周后你再问，依然是90%”。

这种现象的原因，我相信大家都比较了解了，下面用一张图来表达。

在这种情况下，所谓的90% 完成，是毫无意义的，因为随着任务推进，你会发现没有完成的工作越来越多，如果不去深入了解，甚至会认为是不是研发在偷懒。

没有完成的工作是没有价值的

客户给钱买的，不是“开发到”一半的工作，而是“完整”可用的功能。在功能没有完成之前，我们认为该工作是没有价值的，故对外宣称的进度是10%、90%就毫无意义，因为没有价值，所以此时设定为0%是一个比较好的选择。

从价值考虑自己的进度，是一个不错的选择。

很难估算准确

一项工作完成了10%还是50%，是很容易区分；但如果要你区分15%还是18%，恐怕你就会有点抓狂。毕竟估算进度对程序员而言，难度仅次于“给变量命名”。

既然有这些问题的存在，“完成”又是如何解决的呢？

敏捷怎么做

敏捷采取了一个极为粗暴的方式：

1. 确定明确的完成的定义

2. 在你的工作完成之前，你的工作进度就是0%

敏捷做法的优势：

1.统一认知

DoD 的目的就是为了在开发团队、SM、PO、客户之间有一个共同的认知，避免大家由于对“工作完成”的理解偏差产生误解。

此点可参考父母问子女“作业做完了嘛？”时，你回答“做完啦”，然后父母一翻作业“什么做完了！还有错别字呢！”

如果你的父母跟你达成一致（当然也有可能是“打成一致”），那么下次父母再问你作业进度的时候，你的回答会不会更加合理一些？

2.减少研发被进度估算耽误的时间

如上文所说，这种估算对团队毫无意义，减少这部分无意义（无价值）的工作，有利于增加研发团队满足感。

3.反向推动研发团队对用户故事的拆解

只有完成的工作才能被认可，这将会在一定程度上引导团队为了更多的“完成”，从而将用户故事拆分到较小的颗粒度。

4.为研发团队提供隐性的buffer时间

当我们将未完成工作的进度定义为0的时候，整体进度是偏慢的。

在这种情况下，我们在无形之间降低其他干系人的预期，从而会有一个“隐形buffer”被制造出来，为团队创造价值提供支持。