敏捷开发中如何使用看板方法创造价值

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

看板方法起源于丰田精益，最核心的理念就是减少浪费。而精益生产分析技能在敏捷中的体现，就是“价值流程图”工具，可以帮助我们识别 7 大浪费，减少浪费就是在增加价值。7 大浪费如下，可用 WIDETOM 来便于记忆：

W - 等待 waiting 
I - 库存 inventory 
D - 缺陷 defect 
E - 额外流程 extra processing 
T - 运输 transportation 
O - 过度生产 over-production 
M - 动态 motion

让我们带着减少浪费的想法，引出和思考敏捷其中的三个概念，看是如何与看板当中的概念相结合的。

概念一：WIP（work in progress）在制品限制

理想的WIP是，5名团队成员WIP为5，即每名团队成员同时只做一个任务。这样有助于：

创造专注高效的工作环境。WIP通过限制团队成员，让团队成员更专注的做当前的任务，避免工作时间碎片化，每一次被打断，都需要浪费时间来重新找回思路，往往结果就是一天都很忙，但是产出不尽如意，容易失误产生 bug。因为多任务的切换，会造成恐怖的 20% 到 40% 的工作浪费，这是跟随 WIP 的指数增长的曲线。

实践敏捷尽早反馈的原则。周一同时开展 3 个任务，周三同时完成，产品经理和测试的反馈时间周期，每个任务都为 3 天。如果换成每天完成 1 个任务，每个任务的反馈时间周期都为 1 天。产品经理、测试和开发，团队中的各个角色，可以更均衡的工作产出，避免前期开发后期集中或者压缩测试时间，能够更稳健的长久的进行敏捷实践。也可以用更低的开发成本拥抱变化，来实现更高的产品价值。

（看板中的 WIP 在制品限制）

概念二、Pull 拉动式生产

拉动式生产，即下游自由选择完成职责范围内的任务，而非上级安排给下级，组长安排给组员等等。那谁来拉动，推进任务，答案就是自组织团队中的每一个成员。

拉动式能够避免产生，任务堆积库存产生的浪费。假设一个常见的开发情景，团队成员因为能力不同，任务复杂度不同，任务的完成时间很难按照理想时间卡点完成，进而造成，某些成员头上有多个未完成任务，某些成员已经没有任务可做，任务堆积在某个成员身上，形成整个协同开发流程的小瓶颈。这种瓶颈可能出现在团队中的产品经理、架构师、设计师、开发、测试、运维等各种角色成员身上。

如何解决卡时间点协同的问题？当任务不是分配，而是团队成员空闲时自己领取新任务，就自然而然的解决了。任务的自领取，还可以强化责任心，做自己感兴趣的任务，有更强的自驱力，和自身能力匹配的新技能学习。有些公司还喜欢通过加班完成，但这也违背敏捷可持续的原则，和信用卡透支一样，未来都需要偿还更多的利息。

如何保证团队成员领取，自己能够胜任的任务。首先敏捷中相信和不抛弃每一个成员，他们都能最大化发挥自身的价值，自组织团队。然后，敏捷中提倡 T 型人才，高可通用性。这样可以达成更低的任务依赖复杂性，每个人都可以胜任每一个任务，而不是卡在架构师、运维等关键节点。

减少库存产生的浪费，同理在 DevOps 当中的单件流(one-piece-flow)概念，云计算的 Serverless，都能看到减少库存浪费的影子。