标签：
使项目管理的工作可视化。
注：
1.下图是我们真实工作中的看板照片。
2.由于物料与办公场地大小的限制，所以我们把本来是两个看板的内容贴到了一块板子上——上面是组内版本开发的看板，下面是对合做伙伴系统的联调工作的看板——以下在做介绍时只以内部版本开发为例做介绍。
从上到下，整个看板分为三个部分：标题、紧急通道、正常通道。
在图中的红色向右指向的箭头那一行是紧急通道，由于紧急的工作是比较少的，所以我只规划了一小条，而把大部分空间留给了正常工作的通道。
标题从左到右分别为工作的各个阶段——这里的工作阶段如何划分是要看具体的项目情况的，我这个项目的划分为：
最左边是Backlog：即为当前尚未开始的工作。
紧挨着Backlog的是Ready：在这里的工作是已经决定在当前迭代中实现的。
然后是Develop：这个开发阶段又分为doing和done两个。
然后是Test：表示测试中。
再然后是两个预发布：这里把预发布分成两个阶段是为了做报表时统计方便（后面会讲到报表）。
这里没有发布阶段，原因是发布阶段并不在我的职权范围之内，无法直接操作那个阶段的工作。
一般认为在Ready和Develop之间还应该有一个“分析”阶段，实际上我们的看板一开始的确是有这个阶段的，但后来去掉了，主要是因为：1.系统已是运维阶段，需要通常不大，不需要专门的分析团队；2.有这个阶段的时候，基本上是经理在做这个工作，很少其它组员做这个工作，而经理自己是可以直接分析好需求再拿到Ready的，而没有必要单独有一个分析阶段。
总之，工作的各个阶段是由项目的管理团队来设计的，而且也不是一成不变的。
在Develop和Test两个部分的标题上还有一个数字，这个数字表示在这个阶段的工作数量限制，这里注意：
1.阻塞的工作并不计数——在这个板子中阻塞的工作上贴了一个粉红色的小纸条。
2.紧急通道中的工作并不计数。
3.开发中和开发完成两个阶段是共用一个工作数量限制的（如果还有“分析中”和“分析完成”则也是要共用一个工作数量限制的）。
卡片是一项可独立交付的工作——团队经理（可能是产品经理、项目经理或研发经理）需要把工作尽量拆分到比较小的单位，但需要可独立开发、测试及发布。
卡片上的内容通常有：各阶段处理人员（可以有处理时间），卡片拿到Ready中的日期（即开始日期）、卡片拿到预发布当天的日期（结束日期【实际上要到发布才算结束，但因发布团队是单独的，不在我的团队内，所以直接以预发布做为工作结束】）、预测工作量（后续会说到如何预测工作量）。
一、在Backlog中的工作应该是已经拆分后的，可以独立开发、测试及交付的——但如果项目比较大，或项目需要比较复杂，需要有一个“分析”阶段的情况下，则工作可以在分析阶段之后再拆分为可独立交付的。
二、在Backlog中的工作通常也是要进行分类的，例如：可分为“正常需求”、“有工期或资源限制的需求”、“内部持续改进工作”；或分为“需求”、“系统问题”、“内部优化”等等——这个工作我们并没有做，读者自己看是否需要做吧。
三、把工作从Backlog拿到Ready：这个工作要产品经理来做，通常这个原则一般是越重要的，越先实现（但在需求量比较大的情况下，如果一直挑重要的做，则会有不重要的东西一直不会做安排，所以我们后来修改了一下看板，如下图。其实不修改看板也是可以的，只要完全由产品经理自己人为控制即可）。
四、后续的工作完全采用“拉”的方式来运行——“拉”的方式的意思是，由下一个阶段的工作人员主动去前一个阶段拿工作，这与传统的工作方式是相反的（传统的工作方式通常是上级指派工作，而不是自己领任务）——研发人员从Ready中拉工作到“研发中”，实现完成之后，再把卡片拿到“研发完成”，测试人员从“研发完成”中拉工作到Test阶段，在测试完成之后把卡片移到预发布。
1.细心的读者可以想到：这里把开发阶段分为“开发中”和“开发完成”两个部分的原因就是为了服务于“拉”这种工作方式（必须要对“开发完成”有一个可视化的表示，测试的同事才可以知道应该拿哪些工作过来）。而在后续的所有统计中，我们还是把开发阶段做为一个整体来统计的。
五、在拉取工作到自己的工作阶段时需要注意“工作数量限制”，如：下面的图中，研发阶段最多限制为8个工作，则“研发中”和“研发完成”的工作加起来最多不能超过8个。
1.这里安排“工作数量限制”的原因是控制交付的速度，以及控制性能瓶颈。
2.首先，我们要有一个共识，即：“在一个敏捷的团队中，我们希望每个成员都可以做各个阶段的工作（如果一个成员只能做其中一个阶段的工作，那么这个成员的价值就会小于通职的成员）”。所以，在我的团队中，我并不控制工作的分工，即：测试同事可以“拉”Ready的工作来做开发，开发的同事也可以“拉”取“开发完成”的工作来做测试。
3.而在实践中，每个阶段的工作速度是很难平衡的。在我的团队中的现象是“开发的速度要快于测试的速度”，这样的情况下，如果我们没有一个“工作数量限制”，那么就会出现有大量的工作积压在“开发完成”阶段中。
4.为了避免工作的积压，我们通常有两种做法：a.经理人为控制，当开发完成的工作过多时，指派一部分开发人员参与到测试的工作中；b.增加“工作数量限制”，让团队成员自发的控制，发现研发阶段的工作数据已经饱和的情况，则转到其它阶段的工作。我们选择让组员自发的控制方式。
5.这样就达到了我们控制工作流速的目的：当一部分阶段的工作过快时，资源自动转移到其它阶段去。
六、关于阻塞的工作：所谓阻塞的工作是指由于某些外部原因导致暂停的工作（例如：需要与另外一个系统做联调，但对方系统有问题需要修改，则暂时这个工作就要暂停一段时间），这类工作我们是用一个纸条标示一下这个工作阻塞的原因，待阻塞结束之后再把线条去掉（这里实际上是有一个问题的，即：在统计工作时长的时候，阻塞的时间是没有很好的办法统计的，因为工作往后流的时候并没有阻塞的痕迹）。
七、补充一点：当测试发现BUG时，工作还是留在测试阶段的，开发的同事直接参与到这里来修改问题，而不是把卡片退回去。当BUG过多时，也会产生阻塞，这时就需要开发把资源倾斜到测试阶段来，解决这部分工作量的累积——但这种并不是外部原因造成的工作阻塞，所以并不贴工作阻塞的标记。
紧急的工作其实不多的，但是一旦发生就需要马上处理——紧急的工作通常可能是：系统问题、非常紧急的需求——这里的工作方式就不是以“拉”为主了，而是团队主管主动推动工作的进展，直接指派工作。
这里不再多说了。
对于工作量的预测，通常是对相关系统逻辑越熟悉、并且设计能力越强的人的预测是越准的，理论上是不需要团队共同决策的。但少量精英做决策的工作方式并不利于团队成员的进步，所以我们通过打下图这种预测卡来一起评估工作量。
卡片的样式如下图：
一、有多个数字卡和一个问号卡及一个热咖啡卡。
二、“问号”卡代表对这个工作完全没有概念，无法评估工作量。
三、“咖啡”卡代表“我已经很累了，需要休息一下，所以不对这个需求做评估了”。
四、数字卡代表“我对这份工作的预估量”，数字越大，代表工作量越大（或工作比较复杂）。
五、这里的数字本身的意义并不明确（即：1并不代表是1天，也不代表是1小时），而是由打牌的人自己把握，打牌次数越多，团队成员对数字的意义就越趋于一致——之所以并不明确具体的意义是因为：不同人做同一个工作其工作时间也是不一样的（有的人1小时搞定，而有的人三天也未必搞得定）。
六、这里的数字越大，数字的差距越大，原因是：越大的工作或越难的工作，其评估的准确度也是越低的。
工作方式是这样的：
一、每周一次工作沟通会议。
二、让最了解工作内容的人先介绍工作，大家有疑问的这个时候都可以提出来。
三、每介绍完一项工作内容之后开始打牌。
四、打“问号”牌的人数超过三个，就要重新沟通这项工作——我们有20多个人一起打牌——如果组比较小，则建议每个人都要理解工作。
五、出牌前不可让其它人看到，待所有人都选好牌之后一起出牌。
六、如果有人打出的数字过大或过小，就要说一下原因——可能某些人的想法错误或设计复杂——沟通之后要重新打牌。
七、如果大家的想法差不多，但打的牌不一样，则说明大家对这个数字的理解不一样，此时取多数人的数字或大致的平均数即可。磨合一段时间之后对数字的理解就会趋近。
我们这里会做两个报表（下面我只列出图表，而不贴数字上来）。
我们并不画一般项目管理上的燃尽图或燃起图，因为对于我们这种运维阶段的项目，工作是持续性的，没有燃尽的说法。
第一张图表如下图所示。
这里的横轴是“日期”，纵轴是“累计工作数量”，每条折线就是各个阶段的累计工作量的增长趋势。
由于我们的规则是“工作”只能从左往右移，而不能返方向移动，所以这个图中的折线绝对不会下降。
这个图是用来分析工作瓶颈所在以及直观看到工作速度的，但这个分析在这里描述比较麻烦，所以就不讲了，如果以后有强烈的需求，我可以再写一篇文章来描述这个图的分析。
第二个表如下图所示。
这个表的横轴是工作持续的天数，柱的高度是工作的数量。
这个表可以每个版本做一个，或一直累积。
历史的数据结合“预估的工作量”可以用于分析团队的战斗力（团队未来承接需求的能力）。
内容不少，但我文采不行，只是流水账式的记了一下。
完全凭记忆写的这篇，所以肯定会有什么漏掉的，以后想到了再补上去或再写其它的文章来做补充。
标签：
原文地址：http://www.cnblogs.com/naturemickey/p/4424590.html
