看板方法这本书刚好和公司推行的敏捷开发，项目中实施看板管理相一致，具有与实际项目做参考的作用。
本书开头就讲述项目的变革不应该颠覆式变革，而是应该深入到项目中，采用看板系统，梳理出项目的价值流图，根据流图中的各个工作项进行渐进式变革。
看板系统它的核心是价值流，也就是工作流图。对于这点有两个要点：1，是有效的工作项，对于无效的工作项，是没有价值。个人认为对于写日报，写周报就是属于无效的工作项。2.是需要流动的，从项目开始到结束，卡片都是在项目中实时流动的，具有流动行性才能反应出项目的真实情况。
看法方法的第三章：一种成功秘诀。个人认为从第四章开始的后部分都是围绕着成功秘诀的6大方面进行展开描述的。
一种成功秘诀：
1.关注于质量
2.减少进行中的工作项
3.频繁交付
4.根据交付速率来平衡需求请求量
5.对项目进行优先排序
6.消除变异性的根源，提升可预测性。
书中对关注于质量，提出5大具体的措施：1.要求开发人员编写测试代码2.代码检查。可以采用结对编程，同行评审，代码走查等方式进行。3.协作式分析和设计。对于这一点个人认为非常比较重要。遇到问题不建议一个人蒙头思考，而是依靠团队的力量一起分析。而对于项目的开始的设计来说更为重要，需要团队人员一起讨论。4.使用设计模式进行开发。开发人员在开发过程中有没有有意无意的使用到设计模式。很能体现开发人员到技术技能。个人认为尽可能多采用设计模式开发，站在前人的基础上开发，有更多的质量保障。5.采用静态代码分析工具分析代码，也能提高质量。
减少进行中的工作项并频繁的交付。
减少在制品的数量或缩短迭代的开发长度将对初始质量产生重大的影响， 在制品的数量与初始质量成非线性的关系。同时工作的项目越多，各个项目的质量就越低了。
2周的迭代时间比4周的迭代要好，1周的迭代又好于2周的迭代
频繁的交付。个人认为是：用户的软件一直在用户与开发人员中沟通和交流中，用户知道情况，了解进展，用户也就放心，从而信任我们。
对于一种成功秘诀的后三种情况，还没有阅读到，暂时分享这么多。
