可见，项目经理、开发经理、开发人员拥有了 Kanban，也就拥有了和谐与快乐！ 那么 Kanban 到底是什么呢？我们先来看看这张表格吧：  image
实际这些 WIP 卡片上都带有一些文字描述，包括：标题、描述、优先级等信息。 需要注意的是，Selected、Develop、Deploy 下方有一个数字，该数字表示此阶段中最多可以放置的 WIP 数量。例如，在 Selected 中最多只能放 2 个 WIP；在 Develop 中（包括它的子阶段）最多只能放置 2 个 WIP。这里的数字只是一个示例，具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”，减 1 表示大家需要协作，例如：4 人的团队，WIP 上限是 7。 也许有人会提出，为什么没有 Test 阶段？—— 这个可以有，这里只是一个示例而已，你不妨自行加上去。 对于多个项目而言，可以在这张表格中添加更多的泳道（行），每一行相当于一个项目，所有的项目进度清晰明了。 好！继续我们的 Kanban，有意思的事情即将发生！ 
开发人员（架构师与程序员）可对 Selected 中的需求进行工作量评估，可采用投票的方式进行，最终给出一个合理的评估值，整个估算过程，项目经理无需参与，主要是开发人员共同完成。 开发经理可以对任务设置一个“分值”，这个分值可直接影响到后续的绩效考核，所以对大家来说，这个分值是公开可见的，谁做的多，谁做得少，一目了然。当然，开发人员也可以主动承担具有更具挑战的任务（为了锻炼自己，也为了多拿点钱），但任务分配的决定权始终在项目经理手中。  现在假设 A、B 两个任务已经分别被不同的开发人员处理了，那么这些任务就应该移动到 Ongoing 中，同时，产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。  image
 image 部署人员就可以将 A 从 Done 中移动到 Deploy 中，表示部署人员正在做这件事情。同时，做完了 A 任务的开发人员可以再做其它新任务，只需从 Selected 中移动到 Ongoing 中，移动这件事情不是开发人员随意操作的，而是有项目经理负责的。产品经理发现 Selected 中只有一个 D，就可以考虑放入一些新的需求了。  image 此时，部署人员遇到了问题，发现 A 部署的时候总是报错，跑不起来了。同时，其他开发人员也完成了 B 任务。  image 完成了 B 任务的开发人员本来是可以做新需求的，但项目经理发现 Develop 中只能放 2 个任务，所以肯定是后面的阶段出现了问题，导致整个流程受阻了。项目经理可以灵活调度人力资源，集中火力解决现在所遇到的问题。  image 所以项目经理不得不放弃新的任务，去让开发人员去帮助部署人员来解决问题。此时，其他的开发人员还在进行 C 任务。  image 部署的问题还没来得及解决，此时 C 任务也完成了，同时，产品经理也放入了新的 K 需求，确保 Selected 这个水池是装满水的。  image 整个部署问题看起来比较搞人，所有的开发人员全都上阵了，集中更多人的智慧，解决这个棘手的问题。此时，产品经理不能放入更多的需求，由于此时 Selected 已经满额了。其实，开发人员面对太多的需求时，往往都会倍感压力，身心憔悴。  image 看来这个部署问题，确实够折腾的，连产品经理都过来了凑热闹了。但他或许不懂技术，但多个人多个头脑吧，正所谓“当局者迷，旁观者清”，最终经过大家的努力，肯定会攻克这座碉堡！  image 几天之后，Kanban 流程依旧是稳定的，大家分工协作，人力资源合理利用。大家是一个团队，目标就是把项目做好，不会因为自己的事情做完了就闲置了。 我们不妨将这张表格贴到墙上去吧！让每个员工都可以看到，让过路的老板们也可以看到我们的辛苦努力，这确实是一种非常好的项目管理方法！  天地会珠海分舵注：本文来自黄勇的博客，本专题已经获得作者黄勇的转载授权。 著作权归作者所有 |
|
|
