具体描述
产品特色
精益七大原则：消除浪费、增强学习、尽量延迟决策、尽快交付、授权团队、嵌入完整性、着眼整体
看板六大实践：可视化、限制、管理流程、制定明确规则、落实反馈循环、持续演进
SCRUM+看板：看板墙的设计，看板一日游
个人看板的应用：第一步为视觉化工作流程，第二步为半成品限额
持续改进
编辑推荐
根据精益（Lean）观念而来的精益软件开发俨然已成为软件开发项目的主流精神。通过看板方法（Kanban Method），精益理念可以落实到整个开发流程，
提高应变能力、减少无谓的资源及时间浪费，全力开发团队开发效能。
内容简介
本书作者从事软件开发多年，善于吸取敏捷和精益这两种开发方法的精髓，对看板的理解和应用具有实用而丰富的经验。他在本书中依托精益开发中的主流工具，介绍了看板的概念、遵循的基本原则、看板的适用范围和具体使用等。精益软件开发是当下软件开发项目的主流。看板可以使得精益理念落实并贯穿于整个开发流程，从而提高应变能力、减少无谓的资源及时间浪费、完全发挥团队的开发效能。本书适合所有软件从业人员（从项目经理到工程师）阅读，可以帮助他们从容应对千变万化的客户需求。
作者简介
李智桦，在软件开发领域已有多年的实践经验，他对信息及软件应用开发的热情和投入令人佩服，包括新兴的行动及云端开发技术的研究，近年来投身于敏捷、精益及看板方法的推广并担任讲师，本书可以让更多人了解这些软件开发及项目管理的实用方法并应用于工作领域之中，值得阅读！拥有超过30年的软件开发工作资历。从早期的大型银行系统到近年来专注于微软各项新技术的研究，是微软Windows Azure云端及其他新开发技术的指定讲师，担任多届TechDay、TechED等大型研讨会主场演讲。过去是资深的开发人员、大型系统及企业的总架构师，有长期同时带领多个团队的ScrumMaster大型项目经验。他对信息技术的热诚及坚持，至今仍对新技术的动手实操不遗余力，是少数拥有如此丰富资历、能讲、能教、随时能上手的信息界老兵。
李淳 Certified Scrum Master、Certified Scrum Product Owner，曾先后在用友、易车等公司任程序员、研发经理、架构师、产品经理，敏捷和精益倡导者，团队敏捷转型实践者，公众号“互联网plus管理新范式”（iPlusLeadership）维护人。代表译著有《软件需求（第3版）》
目录
第1章 精益软件开发 11-1 精益的由来 2
1-2 精益软件开发 3
1-3 精益软件开发七大原则 5
1-4 结论 27
第2章 看板方法 29
2-1 看板的由来 30
2-2 何为“看板方法” 30
2-3 看板方法四大基本原则（Foundational Principles） 32
2-4 为何要使用看板方法 39
2-5 哪些地方可以运用看板方法 45
2-6 结论 48
第3章 看板方法的六大核心实践 49
3-1 可视化目前的工作流程 50
3-2 限制半成品（WIP）数量 58
3-3 管理工作流程 65
3-4 让规则明确 69
3-5 落实反馈循环 71
3-6 由协作改善，经实验演进 72
3-7 结论 75
第4章 如何实施看板方法 79
4-1 看板墙的设计 80
4-2 Scrum 运作模式的看板墙设计 91
4-3 看板一日游 94
4-4 运行看板方法的简单规范 106
4-5 结论 111
第5章 个人看板：类项目管理 113
5-1 个人看板 114
5-2 制作第一个个人看板 115
5-3 个人看板与软件开发：类项目管理 124
5-4 结论 140
第6章 个人看板与生活：让生活与工作相得益彰 143
6-1 开始使用看板 144
6-2 生活与效能 148
6-3 个人看板进阶 156
6-4 结论 157
第7章 预测未来：减少变异性，增加可预测度 161
7-1 系统思考 163
7-2 内部变异 167
7-3 外部变异 174
7-4 结论 177
第8章 持续改进 179
8-1 看板方法的问题管理 181
8-2 运用看板方法自然形成简单的团体规范 183
8-3 没有银弹（No Silver Bullet） 186
附录 189
附录A 精益咖啡 190
附录B Scrum But 和 Kanban But 194
附录C 用户故事图谱：对付需求模糊的好帮手 199
附录D 敏捷开发需要哪些文件 203
精彩书摘
第1章精益软件开发
1-1 精益的由来
“精益”（Lean）这个词汇是约翰?克拉夫西克（John Krafcik）1988年在他的一篇文章 里率先提出来的，但他所称的精益制造（Lean production），指的是制造业的精益理论，而软件界的精益（Lean）则称为精益软件开发（Lean Software Development），它源自于波彭迪克夫妇（Mary Poppendieck 和 Tom Poppendieck）在 2003 年的著作《精益软件开发工具》（Lean Software Development：An Agile Toolkit），书中阐述了精益软件开发的七大原则，精益属于敏捷开发的成员之一。
敏捷软件开发（Agile software development）是从 1990 年代开始逐渐取代传统开发方法的一些新型软件开发方法，是一种应对快速变化需求的软件开发能力。相对于传统开发方法，敏捷软件开发最大的差异在采用迭代式的开发模式，而不是一次定江山的瀑布式开发模式，以及接受客户对需求合理的变更（让客户对需求做出不同优先等级的区分，并尽力去满足它）。
敏捷（Agile）一词起源于 2001 年初，敏捷方法发起者和实践者在美国犹他州雪鸟滑雪圣地的一次聚会，有 17 位当代软件代表人物共同签署了敏捷宣言，并成立了敏捷联盟。但在此之前，早在 1991 年麻省理工学院出版的“改变世界的机器”（The Machine That Changed the World）研究报告中，就已经把日本丰田公司的丰田生产方式系统（TPS）归纳成为一套精益生产（Lean Production）方法。
严格来说，精益（Lean）比敏捷（Agile）要早诞生许多年，但现在拥戴精益的人士也已经加入了敏捷联盟的阵营（见图1-1），虽然他们依然遵循着精益精神的七大原则而不是敏捷的四大宣言和十二项原则，但实质上他们都共同拥护敏捷式的开发方法及精益精神，二者并无抵触。
图1-1 敏捷伞下的两大阵营
1-2 精益软件开发
精益软件开发并没有具体的开发方法或步骤，而是一堆原则，原因是它认为没有所谓的最佳实践。“原则”具有较广泛的普遍性，能指导对某一学科的思考和领悟，而“实践”则是为执行原则而采取的实际措施，需要针对某一领域进行调整，尤其必须考虑到具体实施的环境。精益软件开发是由软件开发领导者，例如软件开发部经理、项目经理和技术领导者，而不是一般程序开发人员所创设的思想工具。
因为精益软件开发没有具体的实行方法，这会让你觉得它只是一些原则和教条，执行起来应该是最简单的，影响也不大，即便做错了也是无害。如果这么想的话就错了，因为“原则”所影响的是企业的文化层面，比起单纯的开发方法影响大得多了。
依照图1-2的区分，右边第二位隶属于精益开发体系下的看板方法（Kanban），是距离胡作非为（Do Whatever，“胡来”，也就是完全没有规范）最接近的敏捷开发方法。越往右侧的开发方法就表示规范越少，我们称为轻量级（light weight）的软件开发方法，越往左边的开发方法则是规范越多，相对于轻量级的开发方法有较多的约束，我们称为重量级（heavy weight）的开发方法，例如RUP（Rational Unified Process，统一软件开发过程）。
本章的主旨在于阐述如何将精益的精神由原则转换为适用于特定环境下的敏捷实践。说得更精确些，就是针对七大原则加以实践的诠释，目标是看板系统，尤其是依靠经验法则换来的经验知识 。
图1-2 依照规范的多寡由左至右排列各种开发方法
图1-3 在精益网络的时代，充斥着各式各样的对象
如图1-3所示，在没有使用过之前，实在很难判断是不是用错了组件？
1-3 精益软件开发七大原则
以下为精益软件开发的七大原则：
1. 消除浪费（Eliminate waste）
2. 增强学习（Amplify learning）
3. 尽量延迟决策（Decide as late as possible）
4. 尽快交付（Deliver as fast as possible）
5. 授权团队（Empower the team）
6. 嵌入完整性（Build integrity in）
7. 着眼整体（See the whole）
乍看之下，你可能觉得这些原则感觉上像口号一样，真的有用吗？让我告诉你，当你在绘制看板时（也就是将你的工作流程放到看板上成为一个或多个垂直字段时），你所依据的便是对这几条原则的了解程度。如果你觉得很陌生的话，下次改变看板外观时，一边看着这些行列一边思索是否需要改善哪里？改的原因是什么？想达成哪一条原则？多练习几次就熟了。记得一次只改善一个地方就好，这样比较容易看出是哪个异动所造成的结果，这一点跟改 bug 是一样的，一次同时修改好几个地方，就搞不清楚谁才是真正的元凶！
1-3-1 消除浪费（Eliminate waste）
何谓浪费？凡是对客户或产品不具备提升任何价值的行为，基本上都是一种浪费！
Bug 是第一大浪费
程序开发人员最大的浪费，便是在开发工作时制造一大堆 bug，然后再费尽心力把它解决掉。有趣的是，解决这些 bug 之后还能获得相当的充实感！反倒是很少有人会回过头来检讨这些 bug 实际上都是自己所造成的。会有这些 bug 产生，其实是软件的复杂性所造成的，是我们把程序写复杂了。而如何减少 bug 呢？就是想办法把程序写简单一点，只有很简单的程序，bug 才会相对减少。如果程序复杂了，最后便只能靠测试来守住质量，这一点也间接说明开发和测试实际上是一体两面，开发者必须负起减少 bug 的第一线任务，因为它才是最大的浪费。
现在的程序开发工作太复杂了
开发软件最重要的是知道要做什么，然后去做，就这样简单！
但经过岁月不断的累积之后，我们把这个过程变复杂了。是那些有智慧的学者不断地把经验奉献出来，针对各种不同问题提出解答（设计模式便是这样诞生的），智者怕我们重蹈覆辙便想办法把经验积累下来，原意是为了照顾后进，结果却是把开发工作越弄越复杂（HTML 的演进史就是这个缩影）。十年前的软件开发项目，经过十年后规格并没有太大改变，但我们却可以把它弄得越来越有学问，看起来越专业，专业到必须有相当的学习过程才足以开发十年前就能做到的事！程序在执行速度上变快了，但是在质量这一点上却始终没有太大的提升，原因是我们把自己弄复杂了，我们一再地把开发程序的门槛弄高了，而复杂所带来的最大罪恶便是浪费，所以消除浪费便成为近代工程师要学习的第一要务。
“简单”是对付 bug 的有效法则
想要减少 bug，就是把程序弄简单些让自己随时都能看得懂。开发软件时，bug 总是自动在过程中被隐含进来。通常，一知半解写程序是制造bug的最大元凶，这种 bug 最难以检测出来，再来则是逻辑思维被打断也是在写程序时很容易产生bug的时候。所以在进行工作分解时，最重要的是“简单化”，简单是减少 bug 的最佳处方。话虽如此，但很多时候软件开发就是这么复杂，该如何是好呢？
“错误的估算”便是一个简单不下来的原因。千万不要在没有做适度的拆解问题（工作项目）下进行时程的预估，因为那完全是在猜猜看！猜是人类最糟糕的预估了，最少也要有参考依据（有参考依据可以让预估准确许多，例如找到可以比较的案例），但是必须经过拆解成为较小的工作单元，参考才足以成立。所以在减少浪费的前提下，“先拆解再简单化”是开工之前（或是进行工时预估前）的必备动作，正确的拆解可以避开那些不必要的复杂性干扰。
项目经理（PM）习惯向开发人员要求预估需要多少开发时间，想借助工程师每个人的预估，然后合计起来，以得到团队的整体开发时程（当然再加上一点自己习惯性的保险时间）。这是一种将项目分解成多个区块，然后针对各个区块进行预估的作法。这样所估出来的工时乍看之下是会比较准确，但是却忽略了工程师本身所估算的数据本来就是基于一种猜测得来的数值，根本上就已经不准确了。所以，虽然已经经过拆解，但这是基于工程师个人的猜测而来，当然就没有太大的意义。
什么样的估算才比较准确呢？老实说，只有进行一段时间，有更深一层的了解后再来估算自然会准确许多。这种较准确的估算通常发生在项目进行五分之一到三分之一之间，这是一件耐人寻味的事，此时工程师对项目的把握度就可以大幅提升，这个时候的预估就可以接近于“承诺”了。
工程师的承诺与预估
项目开始时工程师无从参考比较，此时的工时估算应该只能说是猜测；一旦项目开始进行后，随着对项目的了解增加，通常工程师在开发工作进行到五分之一到三分之一之间，由于对任务越来越熟悉，自然就可以做比较有把握的预估，这个时候的估算就可以称之为“承诺”。
写程序想要减少 bug，专注（Focus）是最有效的良方。这里讨论的专注是指“短时间”的专注，而不是废寝忘食、长时间疯狂做某一件事的专注。短时间指的是 25 分钟的专心工作，这一点请参考蕃茄工作法 。
如何识别浪费？
丰田生产系统的策划人之一新乡重夫（Shigeo Shingo），他首创制造业的七种浪费类型，而波彭迪克夫妇则将它转换成软件业的七大浪费类型，对照如下表所示。
制造业七大浪费 软件业七大浪费
1 库存 半成品、部分完成的工作（Partially Done Work）
2 额外过程 额外过程（Extra Processes）
3 生产过剩 多余功能（Extra Features）
4 运输 任务调换（Task Switching）
5 等待 等待（Waiting）
6 移动 移动（Motion）
7 缺陷 缺陷（Defects）
判别是否浪费十分重要，它是你避免浪费的基础。接下来的说明虽然看起来冗长，但请务必读完，每个项目的最后会括号说明相对于看板方法的运用手法，譬如你不知道该如何建立看板的垂直字段或调整 WIP（半成品）值，即可参考以下的几条原则，将它们作为依据。
……
前言/序言
精益软件开发不同于一般的敏捷开发方法，它是属于文化层面的改革，它没有特定的方法或流程，有的只是产品开发的概念及原则，非常适合主管层级的敏捷开发思想。精益软件开发没有具体的开发方法，它只有指导原则，乍看之下很像励志的书籍，但它的影响却远远胜过所有的开发方法，因为它将直接影响企业的文化，这一点就比其他开发方法的影响要深远多了。无需讶异它的威力，因为它来自丰田产品系统 TPS（Toyota Production System）。“精益软件开发”没有规定实务性的做法，而是描述了更重要的实际流程定义、原则及价值观。原因是它一直认为很难有一种方法能够完全做到“敏捷”，而“原则”则具有较高的普遍性，因此一直到波彭迪克夫妇（Mary 和 Tom Poppendieck）的《精益软件开发工具》（Lean Software Development：An Agile Toolkit）一书出版，才有了比较明确的七大原则，就是我们所熟悉的消除浪费、增强学习、尽量延迟决策、尽快交付、授权团队、嵌入完整性、着眼整体等精益软件开发的七原则。
本书要描述的是在精益软件开发里独树一格的“广告牌方法”（Kanban Method），它是 2005 年由安德森（David J. Anderson）所创的一种渐进式的流程控制方法，它所依据的正是这七大精益原则。我把精益软件原则的说明放在开始的第一章，是希望读者能“由头到尾”体验在真实的情境下，如何依据这七个原则来做决定，让它成为你实施精益软件开发时的宗旨，而不至于失去敏捷的初衷。
真正引起我想写这本书的原因是，因为 Scrum 在迭代的任务板（Task board）上描述得太少了，实施 Scrum 的团队往往没有把任务板上的字段跟实际开发时的工作流程做正确的对照，以至于常常有各说各话的现象，也就是说任务板没有反应出正确的状况。当第一次看到广告牌方法的时候，我就立刻在自己所教的 Scrum 课程中将实施广告牌的方法隐含进来。说真的，这两个理论真是契合，我常常在课程中完全不提到广告牌方法，只是采用它绘制价值流程及半成品限额的理论，就成功地让广告牌方法运用在 Scrum 的开发流程中，学员们可能从头到尾都没有意识到我们正在实行广告牌方法。这一点果然如安德森所言，它是一种渐进式的改革方法没错！而且，实行广告牌方法所受到的阻力要比实施其他敏捷方法少很多，而且成效更佳，如果你怀疑的话，欢迎你继续往后看。
李智桦
用户评价
这是一本我一直期待入手的书，终于在朋友的推荐下拿到了。《精益开发与看板方法》，书名就足够吸引人了，它承诺了效率的提升和流程的优化。拿到书的当天，我就迫不及待地翻开，首先映入眼帘的是作者那流畅而富有条理的文字。他没有一开始就堆砌那些晦涩难懂的理论，而是从一个非常贴近实际的场景切入，仿佛我就是那个身处困境的项目经理，正努力想让团队的交付速度变得更快，客户的满意度更高。书中的案例分析尤其让我印象深刻，每一个都真实而生动，仿佛就在我的眼前上演。我能够清晰地看到，在一个又一个看似棘手的问题面前，精益和看板的原则是如何被巧妙地应用，最终化解僵局，迎来曙光。作者在解释看板的各个环节时，也做到了细致入微，从“可视化工作流”到“限制在制品数量”，再到“持续改进”，每一个步骤都讲解得通俗易懂，并且提供了许多实用的工具和技巧，比如如何设计一个有效的看板、如何识别瓶颈、如何进行有效的沟通等等。读完前面几章，我就感觉自己仿佛掌握了一套全新的工具箱，迫不及待地想把它应用到实际工作中去。这本书的价值，不仅仅在于理论的传授，更在于它提供的可操作性，这让我觉得非常物超所值。
评分我一直认为，在快速变化的软件开发领域，能够持续保持竞争力，关键在于不断学习和适应。而《精益开发与看板方法》这本书，恰恰是我寻找的那种能提供持续价值的宝藏。作者在书中不仅仅是在介绍精益和看板的原理，更是在传递一种思维方式，一种应对复杂性和不确定性的哲学。我尤其喜欢书中关于“识别和解决瓶颈”的章节。作者用生动的语言描绘了团队在开发过程中可能遇到的各种瓶颈，并提供了多种多样的识别方法和解决策略。这让我意识到，很多时候我们遇到的问题并非无解，只是需要换一个角度去看待。更让我惊喜的是，作者并没有将看板方法仅仅局限于软件开发，他还探讨了在产品管理、市场营销甚至个人工作效率方面的应用。这种跨领域的视角，极大地拓宽了我的视野，让我看到了精益和看板方法的普适性。书中最后一部分关于“文化建设”的讨论，更是点睛之笔。它让我明白，再好的方法，如果缺乏相应的文化支撑，也很难真正发挥作用。这本书所提供的，不仅仅是方法论，更是指导我们如何构建一个更加高效、更加人性化的工作环境的智慧。
评分当我拿到这本《精益开发与看板方法》时，我内心是充满好奇又带点审慎的。精益和看板，这两个概念在软件开发领域早已耳熟能详，但要真正理解并将其融会贯通，却不是一件易事。这本书的出现，恰好填补了我在这方面的知识空白。作者的写作风格非常独特，他没有采用那种枯燥乏味的理论讲解方式，而是通过大量的比喻和类比，将复杂的概念变得异常形象。读这本书的过程，就像在进行一场思维的探险，每一个章节都像是一个新的发现。我尤其欣赏作者对于“持续改进”这一核心理念的阐述。他深入浅出地解释了为何“一次性解决问题”并非长久之计，而是需要建立一种持续迭代、不断优化的文化。书中关于如何构建这样一种文化，以及如何鼓励团队成员积极参与改进过程的建议，让我受益匪浅。此外，书中对于“价值流”的分析也让我茅塞顿开。我之前总是陷在任务的细节中，而这本书让我看到了如何从全局视角审视整个产品生命周期，识别并消除那些不增值的环节。这不仅仅是对开发流程的优化，更是对整个组织效能的提升。这本书给我带来的，是一种全新的视角和思考方式，让我更加期待在实践中去验证这些理念。
评分说实话，我对《精益开发与看板方法》这本书最初的期待是很高的，但同时我也做好了心理准备，毕竟这类书籍往往充斥着理论和概念，真正能落地实践的内容并不多。然而，当我开始阅读这本书时，我的看法就彻底改变了。作者的叙述方式非常生动，他似乎是一位经验丰富的教练，在一步步引导着我，让我从一个旁观者变成一个积极的参与者。书中对于“消除浪费”的讲解，让我反思了许多过去在项目开发中习以为常的低效行为。比如，那些无休止的会议、过度的文档、以及不必要的返工，都被作者一一剖析，并提出了切实可行的改进建议。我特别喜欢书中关于“看板”的实际应用的部分，作者不仅介绍了如何设计和使用看板，还分享了许多在不同团队中遇到的挑战以及如何克服这些挑战的经验。这些内容非常接地气，让我觉得这些方法是可以被复制和推广的。更重要的是，作者强调了“以人为本”的理念，他认为精益和看板的最终目的是为了更好地服务团队和客户，而不是为了追求效率而牺牲人的价值。这种人文关怀，让这本书在众多技术书籍中显得尤为可贵。
评分《精益开发与看板方法》这本书，给我最直接的感受就是“清晰”和“实用”。作者的文笔如同流水般自然，将精益和看板这两个看似庞大的体系，拆解成了一个个易于理解的模块。我尤其欣赏作者在描述“限制在制品数量”（WIP Limit）时所下的功夫。他不仅仅是告诉读者“为什么”要限制，更是深入浅出地讲解了“如何”去限制，以及限制之后会带来哪些意想不到的好处。读到这部分时，我脑海中立刻浮现出自己团队目前的状态，以及如果实施WIP Limit，可能会发生的改变。书中还提供了许多图表和流程图，将复杂的概念可视化，这对于我这种视觉型学习者来说，简直是福音。我喜欢这种“纸上得来终觉浅，绝知此事要躬行”的阅读体验，这本书就像是一本操作手册，在指导我如何一步步构建更高效、更敏捷的开发流程。作者在书中反复强调的“透明化”和“反馈循环”，更是让我看到了改进的希望。过去，我们团队常常因为信息不透明而导致误解和延误，这本书提出的解决方案，让我看到了打破这些壁垒的可能性。
评分书不错，还在阅读中，????
评分书好，送货及时
评分书好，送货及时
评分质量不错，物流很快，满足要求
评分不错！
评分质量不错，物流很快，满足要求
评分书不错，还在阅读中，????
评分不错，挺有意思的书，值得一看
评分东西不错，价格合理，快递也很快，可以常来的！
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 book.coffeedeals.club All Rights Reserved. 静流书站 版权所有