看板方法手记

看板方法的创作背景

1. 软件开发团队经常存在过载的现象，这对软件开发者带来了深深的伤害，反过来也伤害了商业组织；

作者期望寻找一种双赢的软件开发模式、能够带来可持续的步调，既有利于软件从业者，也有利于商业组织；

2. 团队中导入新技术总是不可避免的遭遇阻力；

变革阻力最小的方法，从团队当前状况出发，逐步改善的变革引导方式；

累积流图

为什么敏捷方法比传统方法产生更好的经济效益？

用约束理论来解释：通过消除一个有一个瓶颈来不断演化发展出一个新过程，是最好的方法。

软件开发生命周期的工作流程建模，建立一个可视化跟踪系统，识别并设法减少瓶颈因素，直到不再对效能产生约束，当新工作“流”经系统时，跟踪其状态的变化便可识别瓶颈。

看板方法的价值

1. 看板方案的各种设计元素，为质量和过程提供了可见性，迅速暴露价值流中影响效能的问题，发现最值得改善的杠杆点；

2. 更容易把用户、团队、中层和高层协调到同一个目标上。

看板方法的特性

1. 可视化工作流程。

2. 限制进行中的工作

3. 度量和管理流动

4. 明确过程策略

5. 使用模型来识别改进机会。

6. 根据延迟（机会）成本进行工作项的优先级排序。

7. 通过服务分类来优化价值。

8. 通过产能分配来管理风险。

9. 鼓励工艺和过程创新。

10. 定量化管理。

成功秘诀

第一步专注质量：偏向于研发内部的、更容易单方面控制并施加影响立竿见影的。

第二步优先级排序：可控制性逐渐降低，上下游群体进行合作的要求逐步加强。

第三步消除变异性提高可预测性：减少某些类型的变异性，必须进行行为改变，而要求人们改变行为很困难。

（优先挑选不需要进行行为改变而能为人们所欣然接受的变异性问题）

策略

1. 减少进行中的工作

2. 频繁交付

3. 根据交付速率来平衡需求请求量

4. 进行优先级排序

5. 消除变异性的根源，提升可预测性

方法

1. 开发人员编写单元测试代码，使单元测试代码自动化，以供自动化的回归测试

2. 以小批量进行，每天至少花30分钟进行代码检查

3. 以小批量的方式每天召开协作式的分析与设计建模会议

4. 设计模式

5. 现代开发工具

运营需求估算产生的资源浪费

1. 不再进行估算，保证交付期在25天之内

2. 超过15人天的需求立项处理，15天以内的需求归属于系统维护需求；

3. 限制在制品数量

4. 接收一些可能会混入的大型需求

v 质量低下是软件开发中最大的浪费。
v 减少在制品即进行中的工作项数量，能够高产品质量。
v 高质量能够增进与下游合作伙伴如运维部门等之间的信任。
v 频繁发布能够增进与上游合作伙伴如市场营销部门等之间的信任。
v 可以通过拉动系统，根据交付速率来平衡需求请求量。
v 拉动系统能够暴露瓶颈所在，并在非瓶颈处产生富余时间。
v 如果没有良好的初始质量，交付上也缺乏可预测性，那么优先级排序几乎毫无价值。
v 降低变异性能够减少看板令牌、减少在制品数量，最终体现为平均前置时间下降。
v 富余时间能够使更多的改进机会成为可能。
v 过程改进能够带来更高的生产率和更好的可预测性。

富余时间

直觉上，人们认为必须要消除富余时间。因此，在根据交付速率来平衡需求请求量而限制在制品数量后，

人们会倾向于通过调整资源来平衡生产线，使得每项资源都被充分有效地利用起来。

虽然这么做看起来也许效率很高，也符合20世纪管理会计的典型做法，但它会阻碍改善文化的发展。

为了能够得到持续改善，需要具备富余时间。为了具备富余时间，就必须允许价值流保持不平衡，允许有一项瓶颈资源存在。

以提高资源利用率为目的的优化，是不可取的。