前言
我们工作中衡量个人或者Team的吞吐量是使用正在进行的任务数还是用已完成的任务数？换句话说我已经完成了2个任务和我正在进行8个任务，哪个说明效率更高呢？
正文
最近在和一个团队讨论新的一次产品Release的Backlog的时候，发现团队很容易接受PO插入的新的User Story，从来都不说”No”，哪怕是询问插入任务的优先级都不会去做。作为ScrumMaster我很好奇，所以在团队的一次梳理会上我询问了Team一个问题”咱们团队每次迭代能够完成的User Story是多少?”,结果得到的答案是PO希望完成多少，我们会尽可能吃下来。这个回答让我惊讶不已。Team为什么会觉得有能力来多少吃多少任务呢？只是靠加班就能完成？我们的质量怎么保证？后来当迭代结束的时候我发现这个Team的大部分都完成了80%，真正100%完成的(完全符合DoD原则的)只有寥寥几个。
当团队在不停的开始新的任务的时候，他们真的能够保证最后在当次迭代完成（DoD）吗？很多时候他们无法保证，开发人员往往高估自己的编码能力，另一方面会觉得写完代码是他们的责任而测试质量是测试人员的工作。是否测试时间充足这并不是他们要思考的。当这种情况发生的时候，往往最后临近迭代结束的时候测试人员也会草草收场，在迭代结束的时候得到一众完成达到80%甚至更低的 DoD标准的Story，这个结果实际上就是拿质量作为牺牲，而Team并不认为这是不对的。
很多时候如果大家从研发/项目团队的角度看这个问题，肯定是我开始越多的功能越好，后续还会有测试来收尾，哪怕测试不全，也可以当客户问题来对待，最大的满足客户的功能个数才是满足客户需求。而如果从客户的角度看我更需要的是一个一个可以使用的完善的功能还是一堆完成一部分而我要陪着你测试的半成品呢？答案应该不言自明，肯定是每个交付的完整可用的功能更重要。
这件事引发我一个思考：越多真的越好吗？是什么时候开始我们更在乎开始而不重视完成的数量了？有时候我们在生活中会有类似事情发生，你喜欢看书，可能会在各种场合被推荐一些书籍，例如：公众号，名人自媒体等。你可以看看你的书架/kindle里面有多少书是你翻看过头几页后再就没有碰过的。这是否属于一种浪费呢？如果我们看完一本书在购买下一本这两种在一年之内哪种方式会给我们更多的知识积累呢？现实生活中你还有哪些已经开始却很久没有结束的事情了？
改进方法
说回实际工作，尝试减少团队单次迭代的User Story个数，例如从之前的8个减少到4个甚至更少。要求严格按照DoD完成每个User Story，之后查看是否仍有余力加入新的Story，可以根据情况1个1个的添加。目标是迭代结束时每一个Story必须是完成状态。用降低Team速率的这种方式来达到这个目的——让Team想办法找到提高完整任务产出的个数，而不是忙于开始足够多的任务。这正是敏捷12原则中的精髓所在:
- 可工作的软件是进度的首要度量标准。
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
让我们大家从现在无论是工作还是生活中，开始真正做到Stop Starting, Start Finishing.
