通过状态墙，我们可以计算出每一个需求的交付周期大概是多久。状态墙上一个用户故事从放到“待开发”这一栏，到它被移动到“完成”这一栏，这一个时间段是需求的整个交付周期的其中一段，也是很重要的一段。通过优化从“待开发”到“完成”的这一个过程，我们可以缩短需求的交付周期。通过比较需求的交付周期和客户对交付周期的要求，我们可以量化之间的差距，然后指导我们的改进。

　　在我们理解了状态墙是如何呈现一个需求的交付周期后，我们就不难理解瀑布方法是如何让交付周期变长的。在瀑布模型中，全部开发完成之后才会进行测试工作，相当于所有的任务卡片都堆积到“待测试”状态之后，才开始逐一测试。所有开发完成的半成品，都会留存在“待测试”这一仓库中，一直等到所有开发活动结束的那一刻。

　　当出现库存堆积的时候，就是我们需要改进的时候。如果“待测试”这一栏有太多的任务卡片，那么就说明我们的测试活动没有跟上。有可能是我们的测试环境出了问题，或者是我们的测试人员人力不足。如果太多的卡片位于“测试完成”状态，说明我们的发布和最终交付过程出了某些问题。如果“待开发”这一栏中任务过多，说明我们的计划有可能超出了当前团队的开发能力，或者说反映了开发人员的不足。也有一种情况，那就是“待开发”这一栏空了很久，这可能说明了另外一个问题，那就是我们的分析师的分析速度匹配不上团队的开发能力。一个良好的团队，必然是各种角色协调配合，并行工作，同时他们之间的任务衔接也能够比较流畅。

　　2.4 迭代产能的度量，计划及其他

　　团队在每个迭代所能完成的工作量，通常被成为迭代的velocity（速度），是衡量团队每迭代产能的一个指标。这个指标能够帮助团队进行制定迭代计划。根据团队估计任务工作量的方法不同，迭代的velocity的单位也可能不同（例如故事点数）。通常，我们只需要在迭代结束的时候，数一数状态墙上完成的任务工作量就可以了。

　　当我们经历了若干个迭代以后，通常团队的迭代速度会趋于稳定，我们在做下一个迭代的计划的时候，会参考以往迭代的数据。如果上个迭代完成了15个点，那么下个迭代我们通常也

　　会计划15个点左右的工作量，将这些卡片放到“待开发”这一栏中。也就是说，每个迭代结束时，我们都会对状态墙进行更新，将即将到来的迭代的卡片放到墙上，并且将一些处于半成品状态的卡片进行适当的调整。

　　前面提到，状态墙上可能由三种卡片，除了需求，还可能有bug和技术任务。测试人员每次在迭代中测出一个bug，就会将bug写成卡片，放到“待开发”这一栏。当bug不多的时候，团队可以在不太影响原有计划的情况消化掉这些bug，确保软件的质量持续地得到保证。如果bug太多，则需要做一些计划，将bug分散到几个迭代里去消化。然而到这个时候，团队可能更需要及时反省一下为什么会出现这么多bug的原因了。

　　另一类技术任务也需要和bug以及需求卡片一起被考虑到迭代计划中去。通常技术任务包括诸如搭建持续集成环境、准备测试环境、重构这样的任务。它们虽然不直接给用户带来价值，但是却是保证软件质量、确保团队效率的重要因素。比如重构类的任务，对于工作在遗留系统上的团队来说可能是需要一直考虑的事情，为了保障新的需求的顺利实现，可能需要有计划地重构之前的一些遗留代码。

　　bug和技术任务耗费团队成员的时间资源，但是不直接产生用户价值。如果我们衡量团队每个迭代的总体生产能力，需要在计算迭代速度时考虑这三类任务。但是如果我们只考察团队每迭代交付的用户价值的量的大小，那么就不应该包含技术任务和bug。当一个团队在迭代中花了过多的时间在技术任务上，或者修复bug上，那么团队就需要回顾反省一下其中的原因，是否是团队的基础设施太差，或者是团队在开发时过于粗心导致太多的bug，抑或是其他的一些原因。

　　3、总结

　　在本文中我们从项目管理中常常出现的一些问题着手，分析了其中的一些原因，然后介绍了如何采用状态墙（看板）来可视化任务管理。在敏捷项目中，状态墙作为一种有效的迭代任务管理工具，已经被广泛地使用。团队利用状态墙这样一种简单的工具，将迭代开发中的日常工作透明实时地跟踪管理起来，能够帮助团队及时发现问题，消除浪费，快速地交付用户价值。希望这些文字，能够对渴望尝试敏捷、改善任务管理和日常运作的团队带来一些帮助。