具体描述
《精益开发实战:用看板管理大型项目》以瑞典国家警署开发的大型项目为例，讲述在大型项目中如何具体应用看板方法和精益原则，详细介绍了项目中面临的诸多挑战及其应对策略，以及得到的各种经验教训。书中内容共分为两大部分，第一部分是全书核心，介绍如何实际工作；第二部分是技术讲解，概要介绍了敏捷和精益原则，阐述第一部分提到的因果图等实践做法。
作者简介
Henrik Kniberg 资深敏捷教练、咨询专家，精益和敏捷原则的积极实践者，目前效力于瑞典的Crisp公司。在过去的10年间，Henrik曾为瑞典的3家IT公司担任过CTO，帮助过很多公司走上敏捷精益软件开发之路。Henrik是获认证的Scrum教练，与Scrum的联合创始人Jeff Sutherland共同进行培训和教练工作，并经常作为主讲嘉宾出席业内的各种国际性会议。除本书外，他还著有《硝烟中的Scrum和XP——我们如何实施Scrum》和Kanban&Scrum, making the most of both。现和家人居住在瑞典首都斯德哥尔摩，业余时间在两家乐队担任低音键盘手。
李祥青 七十年代生于湘西，长于西北。曾从事教师、工程翻译、计算机图书编辑等职，并编辑、翻译图书若干。七年前进入IT公司软件本地化团队，负责过本地化产品质量保证及软件本地化供应商管理，一年半后转至技术写作团队至今。喜欢音乐、读书、电影、网球等。另有合译作品《璀璨星途：迈克尔•杰克逊音乐历程全记录》即将面世。
目录信息
第一部分 我们如何工作
第1章 项目背景 3
1.1 时间线 5
1.2 我们如何切割大象 7
1.3 我们如何让客户参与进来 8
第2章 组织团队 9
第3章 每天出席鸡尾酒会 13
3.1 第一拨：功能开发团队每日立会 14
3.2 第二拨：不同专业角色的同步立会 15
3.3 第三拨：项目同步立会 17
第4章 项目进度板 19
4.1 我们的节奏 22
4.2 如何处理紧急问题和障碍 23
第5章 扩展任务看板 27
第6章 跟踪总体目标 31
第7章 定义“可供”与“完成” 35
7.1 可供开发 36
7.2 可供系统测试 37
7.3 两个定义如何提升团队协作 38
第8章 处理技术故事 41
8.1 示例1：系统测试瓶颈 42
8.2 示例2：版本发布前一天 43
8.3 示例3：7 米长的类 44
第9章 处理Bug 47
9.1 持续系统测试 47
9.2 立马修复Bug！ 49
9.3 为何要限定Bug 跟踪系统中的Bug 数量 50
9.4 Bug 可视化 51
9.5 预防Bug 重现 53
第10章 持续改进流程 57
10.1 团队回顾 58
10.2 流程改进研讨会 59
10.3 掌控改变速率 66
第11章 管理在制品 69
11.1 采用在制品限额 73
11.2 为什么在制品限额只适用于功能卡 74
第12章 捕捉并使用流程度量 79
12.1 速率（每周功能数） 79
12.2 为何不使用故事点 82
12.3 周期时间（每个功能所需时间） 83
12.4 累计流量 88
12.5 流程周期效率 90
第13章 Sprint 与版本发布规划 93
13.1 需求清单梳理 93
13.2 挑选前十个功能 94
13.3 为何将需求清单梳理工作移出Sprint 规划会议 94
13.4 规划版本发布 95
第14章 我们如何做版本控制 97
14.1 主干无垃圾 98
14.2 团队分支 99
14.3 系统测试分支 100
第15章 为何我们只用真实看板 103
第16章 经验教训 109
16.1 了解目标 109
16.2 不断实验 109
16.3 拥抱失败 110
16.4 解决真正的问题 110
16.5 拥有专职变革推动者 110
16.6 让人们参与进来 111
第二部分 技术详解
第17章 敏捷与精益概述 115
17.1 敏捷概述 116
17.2 精益概述 118
17.3 Scrum 概述 121
17.4 XP 概述 123
17.5 看板概述 125
第18章 缩减测试自动化需求清单 131
18.1 怎么办 131
18.2 如何每个迭代周期都提高测试覆盖率 132
18.3 第1 步：列出测试用例 132
18.4 第2 步：测试分类 133
18.5 第3 步：按优先顺序对列表进行排序 134
18.6 第4 步：每个迭代周期自动化若干测试 136
18.7 这能解决问题吗 138
第19章 用规划扑克估算需求清单大小 139
19.1 不用规划扑克进行估算 139
19.2 用规划扑克进行估算 141
19.3 特殊牌 143
第20章 因果图 145
20.1 解决问题，而不是解决症状 145
20.2 精益问题解决方法：A3 思维 146
20.3 如何使用因果图 148
20.4 示例1：发布周期长 149
20.5 示例2：上线版本有缺陷 153
20.6 示例3：缺乏结对编程 155
20.7 示例4：很多问题 159
20.8 实际问题：如何创建并维护因果图 160
20.9 陷阱 161
20.10 为何采用因果图 163
第21章 结语 165
附录 术语表：如何避免高深术语
· · · · · · (收起)
读后感
写的挺实在、基本无废话，介绍了在比较大的团队中采用敏捷开发的案例和实际经验：例如有分工的小组、人员交叉、多级看板、这些内容以前没有我在其他的书里看到。 敏捷本身并无定式，随时调整十分重要。重要的是不断反省、持续改进。
写的挺实在、基本无废话，介绍了在比较大的团队中采用敏捷开发的案例和实际经验：例如有分工的小组、人员交叉、多级看板、这些内容以前没有我在其他的书里看到。 敏捷本身并无定式，随时调整十分重要。重要的是不断反省、持续改进。
如副标题所示，这本书让我体会最深的是看板。 看板主要的好处有几个： 1. 确定优先级 优先级一目了然，如果老板，领导，产品，有新的想法需要插入时请先看看当前的任务列表。这个一定程度上确保任务不会被头脑发热的想法或者临时事务打乱。在当前的公司的官僚组织体系中，领导...
不得不说Henrik Kniberg的每一本书都又薄又好用。价钱不贵，看着不累，居然路子还对。这就有意思了。 有意思的是，他的每一本书也是一个真实的项目得出来的。所以，有很多话一说出来，经历过的人，都会深有感触，微微一笑吧。 在这一本中，他同样是用一个真实的PUST项目演绎。...
敏捷开发的执行和过程。敏捷开发的参与人员包括需求分析人员、开发人员、测试人员等。最核心的元素是看板，通过看板展示每个阶段的实际情况，看板的信息通过每日站会或阶段性会议来更新，同时团队核心人员也会通过一些其他的定期会议持续改进流程，以至提高工作效率。 ...
用户评价
对于那些试图在快速变化的市场中保持竞争力的领导者和架构师来说，这本书提供了一个近乎完美的蓝图。我最欣赏的是它对“慢下来才能快起来”这一悖论的深入挖掘。作者用数据和时间线的对比，清晰地展示了那些急于求成、跳过基础性建设的团队，在长期发展中是如何被那些愿意投入时间打磨流程和文化的团队远远甩开的。书中关于“减少等待时间”的量化指标设定方法，让我有机会为我们部门的关键路径设立了第一个清晰、可衡量的基准线。我过去一直模糊地感觉到流程中有延迟，但这本书提供了一种系统化的方法来发现并量化这种延迟的成本。它不仅仅是关于软件开发，它更像是关于“如何高效运转一个复杂系统”的哲学指南。阅读过程中，我多次停下来，拿起笔在旁边的笔记本上勾画我们自己的价值流图，这种即时的反馈和思考驱动，是这本书最强大的魔力所在。它让你从一个执行者，逐步转变为一个流程的设计师。
这本书的结构设计简直是教科书级别的典范，每一个章节的过渡都如同精心编排的乐章，层层递进，逻辑严密得令人拍案叫绝。我发现自己几乎无法放下这本书，因为后半部分的“规模化敏捷框架的取舍与定制”部分，完美地解答了我过去一年中在跨部门协作中遇到的所有痛点。作者对不同规模组织（从初创公司到大型企业）在应用精益原则时所需调整的“力度”和“角度”进行了细致入微的对比分析。其中关于“持续集成/持续交付管道的非技术性障碍”的论述尤其振聋发聩，它将原本被认为是技术问题的流程卡点，最终归结为组织结构和权责不清的深层矛盾。这提醒了我，很多技术层面的改进最终都要落脚到组织变革上。此外，书中对文档和沟通效率的平衡点的探讨也十分深刻，它指出过度文档化和零文档化同样是浪费，真正的精益在于找到那个“刚好足够”的平衡点。整体阅读体验是顺畅且高密度的信息吸收，绝对物超所值。
这本书的深度和广度实在令人惊叹，完全超出了我对一本技术类书籍的预期。它不仅仅是停留在理论层面的阐述，而是通过大量的实际案例，将复杂的问题拆解得清晰易懂。我特别欣赏作者在描述敏捷实践中的那些细微之处，比如如何在会议中引导沉默的团队成员发言，以及如何巧妙地处理范围蔓延的初期信号。这些都是书本上很少提及，但却是日常工作中至关重要的一环。读完后，我感觉自己像是获得了一套实战的工具箱，而不是一堆空洞的口号。特别是关于价值流映射的那几章，作者引入了一种非常直观的图示方法，帮助我立刻在脑海中重构了我们当前工作流程的瓶颈所在。这本书的行文风格流畅又不失严谨，即便是初次接触敏捷概念的读者也能迅速抓住重点，而对于资深从业者而言，其中蕴含的对流程优化和团队文化的深刻见解，无疑是一剂及时的清醒剂。它真正做到了将“理论”与“实战”紧密结合，让人读完后立即渴望应用到实际工作中去，而不是仅仅停留在“我懂了”的阶段。这种强烈的实践指导性，是很多同类书籍所缺乏的。
坦白说，我一开始拿到这本书时，还担心它会是又一本充斥着行业术语和陈词滥调的“速成宝典”。然而，阅读过程中的体验完全颠覆了我的初步判断。这本书的叙事方式非常人性化，它没有采用那种居高临下的说教口吻，而是像一位经验丰富的前辈在分享他多年踩过的坑和总结出的真知灼见。我特别喜欢它对“失败案例”的坦诚剖析，比如一个声称实施了Scrum，但实际上只是换了看板但节奏完全没变的团队是如何在六个月内耗尽士气的。这种对现实的刻画，让我感同身受，也让我对我们团队目前面临的困境有了更深层次的理解。书中的技术选型讨论部分也极其精妙，它没有指定“唯一的正确答案”，而是提供了一套评估框架，教你如何根据团队的规模、产品的成熟度和技术的栈来权衡不同的技术决策。这种开放式的思考引导，远比生硬的“照做即可”的指导更有价值。这本书更像是一本思维导图，它教会你的不是如何走某一条路，而是如何绘制自己的地图。
这本书给我带来的最大震撼在于其对“持续学习与适应”的强调，这已经超越了传统的项目管理范畴，触及了组织生命力的核心。作者非常巧妙地将心理学中的“心智模型”概念引入到软件开发流程中，阐释了为什么一个团队即便拥有最好的工具和流程，如果心智模型没有更新，也只会用新工具做旧事情。书中对于如何建立一个“不惧怕实验失败”的文化氛围的指导尤其具体和可操作，它提供了一系列会议结构和反馈机制的微调建议，这些建议非常注重人际动态和信任的建立，而不是冰冷的指标达成。我特别喜欢它在最后几章对“技术债务与业务价值”之间关系的阐述，它清晰地界定了何时应该为了快速交付牺牲部分技术完善度，以及何时必须停止并重构。这种基于商业价值的务实决策框架，让这本书具有了极高的实用价值，让我在面对管理层的压力时，也能提出基于数据和精益原则的有力论据。这本书绝对是值得反复翻阅，并在不同职业阶段带来新感悟的经典之作。
书中case主要是一个政府警用开发系统，作者以敏捷教练记述了看板的使用。这个大系统里面有两点挺有意思：一、他们有一个项目进度看板，以供每个人员了解项目进度；二、每日站会有很多轮，分别是传统意义的TEAM站会，需求站会以及测试人员站会，大家可以根据自己兴趣加入（这里和项目的TEAM人员有关，Role有PO，DESIGNER,TESTER，然后PO和TESTER各有一部分在TEAM中，其余的人专注于需求和集成测试）。可惜还是没有找到我想了解的看法在软件维护阶段的使用实例，吾乃将上下而求索 。
只看前面几章，看板很好，需要重读
以实例贯穿全书，说得很详细。我们目前也在使用看板，项目没书中说到大，用得比较浅，但给了我很大的启发和借鉴。
大半部分没看太懂。很多技术性的、流程化的统筹的内容。不过我现在知道什么是敏捷开发、scrum和sprint了~
项目总结写这么长真是辛苦了啊。
