读《精益开发实战-用看板管理大型项目》

书很薄，花了一个小时就读了一遍，但书中包含的内容蛮多的，如果有过敏捷开发经验的话，会有种感同身受的感觉。如果没有的话，会有些吃力，尤其是讲到为什么这样而不是那样的时候，感受不会很深。

这本书回答了我几个一直困惑的问题：

作者提到，如果要做流程改进，他们用了一个官僚一点的做法，提交一份流程改进提案。我倒觉得是一个不错的提议。有的时候，团队中的人的能力和对敏捷精益的理解水平不同，当你要提出一个提议的时候，就会难以得到其他同事的认同。如果有这么一份流程改进提案来把下面几个问题讲清楚是非常不错的：

作者建议在制品限额只考虑功能卡，不包括技术卡和Bug。因为技术卡不会造成下游的负载过重，反而是有助于消除下游瓶颈。Bug一般都很小，很紧急，不会花费太多时间。

但我觉得还是有必要限制下技术卡的数量，把技术卡分散在不同的迭代中。

在制品限额的精髓是：努力完成一件事，而不是努力开始做另一件事。

作者建议用功能卡数量来度量速率，可以用燃尽图可视化。

计算从“Ready for Dev” 到 ”Ready for UAT“的时间。因为这段时间是团队可控的。

并且，作者提到了Little’s Law.

在一个稳定的系统 L中，长期的平均顾客人数，等于长期的有效抵达率，λ，乘以顾客在这个系统中平均的等待时间，W；或者，我们可以用一个代数式来表达：L = λW。¹

换成软件开发中的场景就是（假设这些功能要一起上线）：

每个功能的平均周期时间（6周） = 正在开发的功能总数（30） / 每周完成的功能数量（5）

如果想缩短每个功能的周期时间，最简单的办法是减少正在开发的功能总数

最好移出去，因为需求梳理非常耗时间。再者，每个会议只有一个主题是不错的选择。

精益和敏捷是两组具有高度兼容性的价值观和原则。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
   
也就是说，尽管右项有其价值，
我们更重视左项的价值。