我的看板之旅

初探看板

为什么我们启动了看板

• 对于过程改进来说，做任何事情，都是要有目的和背景。
  我们是一个初创公司，规模比较小，研发共有5个团队，每个团队成员5-10人。
  我们没有什么流程，需求一般通过面对面沟通，有个小论坛会对大的需求，进行一些讨论，然后进行开发，开发之后的代码放在SVN中维护，之后测试发布。
  随着业务的发展，我们要扩大团队规模。是把原来小团队扩大成大团队，还是新组建团队？
• 经过讨论决策，决定保留小团队的管理模式
  随着新队伍的增加，我们研发管理上的一些问题接踵而至。比如对外交付的产出物不明确、研发的进度无法获知、项目风险高… …
  创业公司投入于研发管理上的经费一般都不会太多，甚至可以说是没有，用一个工具或者探索一个管理流程，首先谈的就是“性价比”。要花大精力去尝试、大价钱去购买的东西，都是耍流氓。
  于是想到了看板。

看板的适用性

• 看板系统很适合很多不愿意做太多改变，但又希望做改变的公司，作为起步阶段实施的系统.
• 它很容易上手，也很直观，性价比也高。

所以，个人感觉，对我们这样的创业公司，其实蛮适合做看板管理。于是我们花小钱，买了大白板，各种颜色的便签纸。

再探看板

刚开始启动看板的时候，我们做的很简单：

• 我们设置了几种状态变迁：待分析、开发中、测试中、已发布、待上线、关闭。
• 就是把重要的需求进度可视化出来；
• 每天大家在看板前更新进度。

对于需求方，通过看板，很清楚地知道，我的需求现在进度怎样了。
对于相关方，我想了解目前的研发进展，来看板前看看呀，亲。
慢慢地，我们遇到了问题。临时紧急任务怎么办？在看板上看不出哪些是紧急任务。

我们的第一次改进

于是在那个迭代回顾会上，我们第一次对看板的设计做了回顾，识别了以下的问题列表：

• 临时的紧急任务，如何识别？
• 当任务遇到某一障碍要暂停时，怎么办？
• 当任务要取消时，怎么办？

-看看，没有一劳永逸的事情，任何事情都要讲究“持续改进”
于是，我们对看板进行了重新的设计，制定了看板公约：

• 正常的任务，用黄色便签表示；
• 紧急的任务，用红色便签表示；
• 开辟障碍栏，把障碍单独列出来跟踪，当任务遇到障碍时，写蓝色的便签贴在原便签上，并做好序号标记。

我们把公约打印出来，贴在看板的右上角，于是，看板开始变得花花绿绿起来，因为公约很简单，大家一看就知道。
现在感觉看板内容丰富一些了，一眼就能看出哪些任务遇到障碍，需要及时协调跟进的，障碍的处理进展等，大家感觉都不错。

我们的第二次改进

随着两周一个迭代的节奏慢慢顺畅，我们固定了需求的更新周期，并加入了简单的度量。
最直接的，就是生产率。我们生产率计算很简单，就是计算每个迭代团队交付的需求数。
渐渐地，我们又发现了新问题。
我们发布的版本越来越多，现场问题也接踵而至，我们必须要分出人力出来去做现场问题定位。
我们代码不断增加和变更，有些原来为了赶上线时间而定的临时方案等也需要重构，那么就需要投入人力去做重构。
这样，我们的生产率就变低了，从原来的10个/迭代，变成了现在大概7个/迭代。
怎么分解这些多样化的任务？在看板中怎么体现？
于是我们进行了头脑风暴，做了如下改进：

• 
  
• 引入了泳道，作为划分工作的界限；
• 修改了看板公约：
  

• 70%的人力，用来做需求；
  
• 20%的人力，做重构
  
• 10%的人力，处理现场问题

假设我们有7个需求任务在进行中，那么最多的重构任务（任务量相当）我们只会安排2条；
现场问题按需分配，因为有设置一个缓冲时间，所以现场问题来的时候，一般会以紧急任务的形式展示。
一个迭代之后，我们发现之前头脑风暴的比例有点太理想了，于是我们又调整了分配比例。
慢慢地，我们不知不觉中，把正在努力地实践着看板，前方等待我们的，会有更多的惊喜和惊奇，拭目以待。
- 不知者无畏，越深入，越敬畏，记录此文，聊表纪念我们的看板之旅。