“未完成工作”没那么糟糕

我偶尔会听到一些比较冒失的言论—在sprint结束时还遗留了未完成的工作是非常糟糕的，应该严格禁止。 我能理解未完成工作的危险性，也从不反对敏捷宣言中关于可工作软件的价值观，但是，我还是要说这个言论是错的。 真正危险的不是未完成的工作，而是未完成工作的不断累积。 我对未完成工作的定义是—在一个sprint结束时，已经开始但是还未完成的产品backlog条目。 比如，试想有一个团队的程序员小A已经完成了他的工作，并且在sprint的最后一天里还有那么几个小时的空余时间。作为一名优秀的团队成员，他还主动询问了其他成员有没有需要帮助的；而其他人也都很顺利不需要帮忙。 也许，小A会考虑从团队的待重构列表中找到一些活儿干—但是，这个列表是空的。甚至缺陷库也是空的。（这2种假设也许太极端，但是，我们还是要考虑到。） 这时，小A看了看产品backlog列表，然后挑出一个条目开工了。他当然知道在这个sprint中是完成不了这个条目的，但是，这个sprint剩下的几个小时能做的最有价值的事就是它了。 小A在接下来几个小时里开始思考backlog条目相关的特性—也许还会把他的想法画到白板上。 就这样这个sprint结束了，未完成的工作被搁置了下来。你也许会问，未完成的工作在哪里，没有嘛？错，它就再在小A的脑子里和白板上。 思考和打字一样是在工作。我无法想象一些人用貌似合理的言论来反对小A的行为。事实上，这些未完成工作的存在也是ok的。 我们依然有必要回答这个问题：可以允许多少未完成的工作呢？答案很简单：越少越好。 所以，尽管我反对“未完成工作是危险的”这个说法，但是我还是要强调一下，未完成工作的累积是非常危险的。当上面小A的情况反复出现时，团队可能会发现所有人都花了几个小时在未完成backlog条目上。 而对于团队来说，完成一个10小时的条目显然比完成硬拆成2个5小时的条目要高效。 假如你的团队在sprint结束时留有未完成工作，你得思考一下这是sprint对工作内容进行划分的产生的必然结果，还是说团队成员间应该加强协作来完成这个backlog条目，然后再转入下一个sprint。 用一个图表把每个sprint中未完成工作的时长标识出来，以便观察其变化趋势。另外，sprint回顾会议也是个很好的机会来讨论：未完成工作是否增加了，以及怎样应对它。   本文经授权翻译及转载，不得复制 原文链接：http://www.mountaingoatsoftware.com/blog/unfinished-work-at-the-end-of-a-sprint-is-not-evil