Stop Starting Start Finishing

前言摘要

在工作中衡量个人或团队效率时，我们常面临一个问题：是根据正在进行的任务数量，还是已完成任务数量来衡量吞吐量？例如，完成2个任务与进行中的8个任务，哪个更能反映效率？

正文摘要

一个团队在讨论产品Release的Backlog时，总是容易接受新的User Story，从不拒绝或询问优先级。我发现，尽管团队表示能完成项目所有者希望的任务量，但最终往往只有少数任务能100%满足完成标准（DoD）。这种现象使我思考，团队在开始新任务时，是否真的能确保在迭代结束时完成任务，并且保持质量。

开发人员经常高估自己的编码能力，而忽视测试的重要性，导致测试人员在迭代末期仓促完成任务，以低于DoD标准的成果结束。从研发团队的角度，开始越多功能似乎越好，但客户更关心的是能否得到完整、可用的功能，而非半成品。我意识到，在生活中我们也常开始很多事情而不去完成，如购书后仅阅读几页就弃之不顾。

改进方法摘要

在实际工作中，我建议减少团队每次迭代的User Story数量，并严格按照DoD完成每个任务。如果有额外能力，再考虑逐一添加新的Story。目标是迭代结束时每个Story都是完成状态。这种方法实际上是敏捷12原则的体现，即：可工作的软件是进度的首要度量标准，我们的目标是通过持续交付有价值的软件来满足客户。因此，无论在工作还是生活中，我们应该开始做到：停止启动新事物，开始完成已经开始的事物（Stop Starting, Start Finishing）。

传统企业的智能化IPD（产品集成开发）转型

了解更多

想要了解更多内容？

查看原文：Stop Starting Start Finishing

文章来源：

Bruce Talk

扫码关注公众号