20170510

• 将某种软件开发过程强行施加在一个开放团队上，是无法奏效的。即使安排了积极、正确的领导，即使对过程进行裁剪以适应不同的场景，也并不能保证一定获得成功。从实际操作角度来看，及时准确地识别瓶颈，并逐一解决并适当固化过程，是一个切实可行的办法。
• 对于大型软件开发项目而言，采用一种可持续性步调（如每周工作40小时），与前期冲刺、后期疲惫的节奏相比，会有更好的经济效益。当然，有限的时间需要更高的效率，而不是简单工作时间的累积，甚至是无序地拉伸最长路径。
• 卡片墙并不是看板系统，仅是可视化控制系统，让团队以可视化的方式进行自组织和任务的自动分派，而没有对在制品工作项的数量进行限制，缺乏对于瓶颈的识别和处理。
• 看板方法的5个核心特性

• 看板方法是一种柔性策略，鼓励多样性。它允许你根据项目、团队的实际情况，对既有过程进行调整。它给予的是一种持续改进的原则，而不是某个固化的管理过程。看板方法设计的初衷，是为了尽量减小变革的初始影响，从而减小接纳变革的阻力。
• 实施看板方法，要先从寻求优化现有流程和改善组织文化入手。选择看板方法，是对组织能力、组织成熟度和组织文化的长期投资。不能简单把它视为一种快速解决问题的方法。

20170512

• 梳理目前使用的价值流，而不是简单拿出未被实施的公司规章。定义控制流的起点和终点，合理定义工作项（分类和粒度，无需管理人员的干预可独立完成），用卡片墙来可视化工作项的流动，在不同状态间设置合理的缓冲区和工作限额，电子跟踪系统也是不可或缺的。卡片除了工作内容外，要标明负责人、进入时间和预期完成时间，善于用不同的颜色和形状来区分卡片的类型和特殊状态（如缓冲等待）。
• 每日站立会议是敏捷开发过程的基础实践。在看板方法中，项目信息直观可见，只需重点关注受阻的工作项。
• 交付存在协调成本、事务成本，对影响范围内不同的人要实施不同的工作。
• 通过对承诺的兑现，在不同角色人员间建立信任。如持续发布稳定版本。
• 对于项目管理来说，可预测性有些绝对重要的地位。不能一味追求敏捷和质量而牺牲可预测性。
• WIP限额带来的积极压力会引发价值流上各方的讨论和协同，是一种健康的压力，是促成涌现持续改善文化的关键机制。
• 对不同紧急程度的任务，应给以不同的服务质量等级，在卡片墙上给以可视化标记。
• 在度量时，应关注前置时间、缺陷率、破坏性负载的数量（如缺陷，投诉引发的任务）
• 识别能力有限资源，寻求解决方案。对于非即时可用资源，与其持续等待，不如放入队列，然后去忙别的。
• 看板方法不是一种软件生命周期管理过程或者项目管理过程，是一种变革管理技术，是对现有过程的持续改进。
• 将受阻工作视为瓶颈是一种危险的做法，将导致错误的问题解决思路，应从消除特别致因变异角度来考虑。
• 软件过程管理的各种方法之所以可以提高效率，在于及早发现和避免错误，降低信息传递成本，避免工作重复发生（由于搁置和切换产生的重复），提升资源利用效率。