如果这一简单的规则能够严格被遵循，那么当我们看到一个人的名字出现在多张卡片上的时候，我们就知道这个人此刻可能忙着在多个任务之间切换，而每一个任务都将不会在估计的时间点内完成。如果我们看到有人的名字没有出现在任何卡片上，那么他目前大概处于休息状态。团队内的每个人的名字都应该对应在一个小纸条上，如果你此刻
工作在某个任务上，那么就将自己的名字贴到相应卡片上，如果此刻没有工作在该任务上，就将自己的名字移去。
51Testing软件测试网 S gOR Z3I;r 我们在领取“待开发”状态栏中的卡片时，保证每次每人只领一张卡片，不要多领，完成了这张卡片之后，再回来领下一张。当一张卡片被认领之后，我们就会对这张卡片进行跟踪，在站会上谈论它的完成情况，谈论实现过程中碰到的问题。当它的进度和估计的可能偏差较大时，我们能够及时而不是在最后一刻察觉到，提供需要的帮助，确保它能够顺利完成。这样一种方式让我们能够将注意力集中到小粒度的需求（例如用户故事）上，更多地关注这些用户故事的流动速度。而当每个小的用户故事能够顺畅地流动起来时，整个项目的交付也得到了保障。51Testing软件测试网 \0@ Z
eF
51Testing软件测试网R9@0SF(k0x(E ])B+o 当然这一实践并不能自动保证团队内不再出现多任务并发、拖延、或者做和任务无关的其他事情等问题。可能有些人在做一个用户故事的过程中，突然中断去做了一些其他事情，但是
~4SF%Yny$AEz4h0r7O9b8K"J`B0 却没有及时在状态墙上更新自己的状态。重要的是团队要有实现交付目标的共同愿景，能够透明地暴露问题，并且善于利用状态墙来发现和改进自身的问题。对于不成熟的团队，这可能需要一个转变的周期。51Testing软件测试网0OS b;|x"e.o
51Testing软件测试网!HQ S6U"}*vX 如果一个团队的职责共享较好，代码被所有人集体拥有，每个人都被鼓励熟悉和工作在代码的不同部分，那么在这样的团队内便不太会出现把一大块任务事先就明确给某一个人的情况。相反，所有人的工作事先不具体确定，大家会更容易形成某一时刻只领取一张卡片的情况，避免同时工作在多个任务上。实际上，状态墙的使用也可以帮助团队走向职责共享之路，只需要在大家领取任务的时候有意地给人们分配一些之前没做过的内容，同时安排好有经验的人与其结对工作，一段时间之后，团队内的人便会逐渐体会到和之前只是专注在一个模块内不同的工作方式。51Testing软件测试网-j U N`*h vb{T0|#O
/B3^r!k#|#uC^ m w1y1t0 2.3 如何减少半成品库存，缩短交付周期
ng;VZ,| [:^ r051Testing软件测试网,n(]0F4y1Q? 一个需求的交付周期（leadtime）是从它被识别到最终交付给用户手中所耗费的时间。交付周期越短，意味着客户从提出想法到能够在软件中实际使用到这个点子的时间越短。从客户的角度来看，更短的交付周期意味着自己的软件能够对市场变化的更快地响应，因而获得更强的竞争力，同时也意味着能够更快地验证自己的想法。
"z&N SY!u2bt6ZZ g'i0Kp v$urI0 任务管理的粒度太大会直接导致交付周期变长。最极端的情况是将属于某一模块的任务在一开始就全部分给负责这个模块的人，所有这个模块相关的修改都由他来实现。在一个按模块划分职责，每个人只负责自己具体模块的团队里，通常这个模块的负责人会实现这个模块的所有修改。不然，就是将一个可能需要做2周到一个月的任务分给某个人。或者更好一点的情况是，单个任务本身不大，但是会将相关联的任务成批地分配给某个人。如果你的团队内也是采用大篇的“规格说明书”等word文档来组织需求的，那么就要小心，这种问题很可能在团队内已经存在。整个团队没有小粒度频繁交付的概念，习惯了大批量长时间地交付方式。由于批量大，所以估计常常不准，而且时间跨度长，中间也会有更多地干扰因素出现，这些都导致任务不能在开始承诺的时间点交付。开发周期长同样导致测试活动的滞后，极端地滞后就演变为所有开发工作完成之后才能进行测试，这就是我们熟悉的瀑布模式。最终的影响就是需求的交付周期会很长。51Testing软件测试网v s,`vZ6eee
w9x'H/M M)g0 传统团队的一个常见组织方式是按照功能模块划分团队成员，明确分离职责，这也会变相增长交付周期。这样的团队通常倾向于按照功能模块来组织半成品任务，而不是按照可以交付价值的完成品来组织任务。习惯按照功能模块来组织开发的团队通常会阶段性得“联调”，不同模块的人带着自己的代码合在一起调试，由于缺乏频繁地集成，这种联调活动的时间经常不可控。团队在大部分时间内通常只拥有一大堆半成品，后续的测试和验收活动没有办法进行，而只能等到团队在某一刻组装出一个完整的功能后才能测试，因此交付周期也会比较长。51Testing软件测试网4Zn8l jRVm/}
| kE/w D*i0 因此，如果我们的需求都是按照软件的功能模块划分，而不是按照面向用户的价值来划分的，那么我们在交付用户价值这一目标上，一开始就走错了路。采用用户故事能够把需求以用户能够理解的价值来组织，这一点是我们缩短交付周期的一个重要基础。51Testing软件测试网k8V oV.S:`[
6cg$AFOr$K e0 我们的状态墙能够揭示需求的交付周期。让我们来看看这样几个场景。
;vWK n|051Testing软件测试网-@*G2C-CH*A 如果我们的需求是按照软件的功能模块划分的，那么通常单个模块的编码完成往往不可测。例如有的团队喜欢将web应用的上层页面部分和下层数据库逻辑部分划分到不同的模块组，一个用户的需求也会拦腰切成两截，一部分交给上层团队完成，一部分交给下层团队。单个团队的任务完成都不能开展这个需求的测试，于是这些任务就会堆积在“待测试”这一栏。51Testing软件测试网#w
W)^,~*UBT#A
9N a eh9m3Iv;b8Q0 如果我们的需求很大，以至于开发人员要花费很长的时间（超过1周）才能完成开发，那么这个需求会在“开发中”这一栏停留很久。大家可以猜到，当一个人同时进行多个任务时，这些任务也会比它们单个依次被开发时在“开发中”这一栏停留更久的时间。51Testing软件测试网L0K;q X1a}
51Testing软件测试网(i Y\#d?[)X,U 任何一栏中的任务其实都是半成品，只有完成测试，交付到用户手中的需求才是完成品。状态墙上的每一栏都好比一个存放着各种零件的仓库，每一栏中的卡片越多，停留的越久，就说明当前半成品的库存越多，是该得到团队的认真关注的时候了。状态墙将每个阶段的半成品数量可视化呈现出来，让虚拟的数量通过卡片这种物理介质的数量得以呈现。
] a"E&P \ WR0
