传统团队的一个常见组织方式是按照功能模块划分团队成员，明确分离职责，这也会变相增长交付周期。这样的团队通常倾向于按照功能模块来组织半成品任务，而不是按照可以交付价值的完成品来组织任务。习惯按照功能模块来组织开发的团队通常会阶段性得“联调”，不同模块的人带着自己的代码合在一起调试，由于缺乏频繁地集成，这种联调活动的时间经常不可控。团队在大部分时间内通常只拥有一大堆半成品，后续的测试和验收活动没有办法进行，而只能等到团队在某一刻组装出一个完整的功能后才能测试，因此交付周期也会比较长。

　　因此，如果我们的需求都是按照软件的功能模块划分，而不是按照面向用户的价值来划分的，那么我们在交付用户价值这一目标上，一开始走错了路。采用用户故事能够把需求以用户能够理解的价值来组织，这一点是我们缩短交付周期的一个重要基础。

　　我们的状态墙能够揭示需求的交付周期。让我们来看看这样几个场景。

　　如果我们的需求是按照软件的功能模块划分的，那么通常单个模块的编码完成往往不可测。例如有的团队喜欢将web应用的上层页面部分和下层数据库逻辑部分划分到不同的模块组，一个用户的需求也会拦腰切成两截，一部分交给上层团队完成，一部分交给下层团队。单个团队的任务完成都不能开展这个需求的测试，于是这些任务会堆积在“待测试”这一栏。

　　如果我们的需求很大，以至于开发人员要花费很长的时间（超过1周）才能完成开发，那么这个需求会在“开发中”这一栏停留很久。大家可以猜到，当一个人同时进行多个任务时，这些任务也会比它们单个依次被开发时在“开发中”这一栏停留更久的时间。

　　任何一栏中的任务其实都是半成品，只有完成测试，交付到用户手中的需求才是完成品。状态墙上的每一栏都好比一个存放着各种零件的仓库，每一栏中的卡片越多，停留的越久，说明当前半成品的库存越多，是该得到团队的认真关注的时候了。状态墙将每个阶段的半成品数量可视化呈现出来，让虚拟的数量通过卡片这种物理介质的数量得以呈现。

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

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

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

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

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

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

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

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

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

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

　　3、总结

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