扫码阅读
手机扫码阅读

Stop Starting Start Finishing

265 2024-02-22

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。

查看原文:Stop Starting Start Finishing
文章来源:
Bruce Talk
扫码关注公众号
文章摘要

前言摘要

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

正文摘要

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

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

改进方法摘要

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

想要了解更多内容?

查看原文:Stop Starting Start Finishing
文章来源:
Bruce Talk
扫码关注公众号