对书的归纳总结就不多写了，其他书友已经贡献了很多笔记。这里结合实际工作，谈谈自己的理解：
工作流
一、工作分类：
工作来源于各个业务项目，可分为需求、变更、BUG。
Ø 需求：新的业务；
Ø 变更：原有业务更改；
Ø BUG：不解释。
二、工作汇总：
将各个项目的工作汇总到一起，无论任务大小、难易程度，统统汇总、避免遗漏，防止暗箱操作（此处不是怀疑人品好吧，纯粹是为了规范化操作）。
三、工作把关：
此处需要业务主管和开发主管合作，或指定专门的把关人、既要了解项目又要了解开发。
把关主要做：
Ø 识别任务的重要性、紧急程度等（BUG也有轻重缓急不是吗），以便把有限的资源投入到重要的工作当中，简单点说要做正确的事。
Ø 评估工作量，以人天为单位。当然不可能完全准确，但是也不能太粗糙，否则怎么指导计划呢。工作量评估方法各家可能都不一样，本人基本靠经验，在这就不献丑了。
Ø 编排开发计划，依据就是以上两点。有了开发计划，又可以作为修正项目推进计划的依据。此外，开发计划应所有团队公开透明，减少沟通成本。
PS：开发计划可以把所有工作都按顺序排进去，也可以只排一个固定周期如一个月，但是接下来一个星期必定要细化（也就是下周计划细化到每一天每个人，下面讲到），余下的则指定到某某周即可，毕竟那么长时间的计划不可能没有任何变动，变动不可怕，贵在坚持维护。
PS：此步骤异常重要，因为不仅涉及工作的安排，还涉及不同团队之间的沟通是否良好。毕竟，业务团队希望速度快、质量高，而开发团队资源有限、某个周期内业务团队输出的工作量必定大于开发团队可接受的工作量（土豪公司忽视，可以囤点人以备不时之需>_<），产生点矛盾在所难免。所以说，良好沟通异常重要。
四、控制流入：
开发团队使用KANBAN跟踪每周计划，何人何事何时，一目了然。重点来了：
Ø 每周计划必须要以开发团队的产能为基础，不管开发计划上有多少，都得按产能来输出到每周计划，不可强求。至于产能的评估，本人参考循证式日程规划（《软件随想录》）。
Ø 待办、在办、已办：按顺序一个个来吧，不要同时做几件事（多线程的脑袋除外）。我们的口号是：一次只做一件事，做好每一件事。
PS：什么？one-piece-flow？好吧，我觉得好像差不多是这个意思。
Ø 设计、编码、测试：每项工作需要遵守的详细开发过程，这里不细说了。
PS：如果设计、编码、测试分属不同责任人，则应视为三项工作，且可能不在同一周里完成，比如本周设计、下周编码等等。
Ø 日清周结：每天的工作每天完成，完不成咋办？加班>_<。每周的工作到周末必须完结。注意：完结不是说必须完成，而是说要明确当前什么状态、还有需要工作量、是加班还是安排到下周？不能有在制品且没有任何说法。
关于每周计划调整：
能不调整最好不要调整。当然，实在有变化，那也得把关人审核通过才行，而且要将原有计划中相同工作量的工作调换出来。
PS：紧急的BUG当然等不及计划，这就要有特殊通道，当然也是需要把关人审核，否则就有可能滥用。
五、部署：
自动化，这个不说了。能简单尽量简单，最好是一键式自动更新，前提是发布出来的东西质量一定要有保证。怎么保证？我们现在是苦逼的手动模式...Anyway,质量好就行。
PS：开发团队要理解业务，业务团队和运维团队才会更轻松。
其他：
Ø约束点：
程序员能力总是会分三六九等，复杂的工作交给牛逼的程序员地球人都知道。重点是，你不能眼巴巴指望着那些大神，或者等着菜鸟变大神，你得主动。所以就得有一套程序员的培训考核体系，应该如此如此（此处省略一千字...）。
Ø文化：
PDCA。
最后，不管是工作流、自动化、管理等等等等，都需要有内部系统作为支撑，否则你懂的。没有怎么办？有钱就买，没钱就自己开发（推荐）。
