概览
自序
精益原则要求:
企业要将具有最大商业价值作为软件开发的方向
团队拥有自己的系统并持续不断的改进系统
管理层培训并支持团队工作
认可高品质的工作
目标将管理层和个人结合一起，达到“全局优化”
整个企业：整合企业、团队和个人以最佳状态合作
整个产品研发过程：不只是包括开发，也包括维护和集成
全部时间：不只是包括当前，也包括将来。我们需要为得到可持续的投资收益率而工作
引言
两种方式看待敏捷：
敏捷是一套价值观和信仰体系，实践者需要判定该如何应用敏捷
敏捷是一套实践理论，实践者需要证明敏捷具有良好的效果
实践者通常结合两者，信任敏捷宣言指令并运用Scrum或极限编程作为他们工作的基本原则，但这种工作方式会面临双重挑战，一个来自敏捷的根源、一个来自敏捷实践本身缺乏理论基础
原则和范式：
原则是一种综合的基本法则、学说或假设
范式是假设、价值观、信念和实践的组合，定义了如何评估现实状况，如何看待实际形势。它是一种世界观，描述了真理的特性
需要务实的方法去论证范式，并批判过程、团结协作
瀑布模型的核心理念：
敏捷的核心理念：
Scrum 一种最受欢迎的敏捷方法，基于精益原则产生，但软件行业对于精益的了解并不广泛，开发团队会因此失去精益可以提供的有潜力的开发指南。
精益的核心理念：
精益提供了这样一种管理范式：在合作的基础上，通过重视团队工作的过程- 该过程必须是使团队能够顺利完成任务的最好过程- 来管理团队。通过这种管理，过程不再是强加于团队的东西，而是被团队灵活应用、使他们工作更有价值和更令人愉快的东西
精益管理范式结合了概念、工具和实践，提供给双方（管理者和开发人员）一种合作方式去提高管理的可视性、管理的方向和团队的生产力
本书也吸收了部分来自非精益的实践原则，但这些非精益的实践原则在其他方面是与精益的中心原则“全局优化”保持一致
第一部分 拓宽视野
与实施执行阶段相比，许多项目实际上是在启动阶段耗费了更长的时间；因此，缩短启动阶段的时间是缩短产品上市时间的一个关键：
选择正确的开发产品或增值产品，最大限度的提高投资回报，是团队高效工作
从全局着眼，从项目的具体工作着手
为软件开发或软件增强功能部署开发人员
第一章 精益软件开发- 敏捷开发者指南
精益
丰田公司在汽车生产和汽车研发时所使用的丰田生产方法的名称
精益应用于组织的多个层级
业务部门：
不断优化和分解企业的增值需求
管理业务需求组合
发布计划
管理部门：
公司跨职能团队提供端对端交付增值任务的功能
管理价值流团队
帮助消除障碍
交付团队：
每天都在一起工作，并交付经过全面测试和集成的代码
学会如何交付业务增量需求
精通验收测试驱动开发和重构
精益思想的快速回顾
多数错误源于系统本身，因此必须对开发的系统加以改进
为了改进系统，必须尊重员工
过早开始会造成浪费。只在需要的时候完成需要做的事情，这就是所谓的”准时制“或JIT（Just in time）
精益思想通过消除开发过程中的延误来缩短产品的上市时间，使用JIT方法做事情比让大家一致忙碌更加重要
- 查找错误的根源
当错误产生时，我们一般倾向于批评责任人，实际问题的根源是这些人的合作方式问题
敏捷致力于提出好的方法去提供信息沟通的过程，同时不断减少错误的数量
改善沟通是敏捷的主要目标，但敏捷实践往往只强调了局部层面的沟通：团队内的沟通、团队间的沟通、团队与客户的沟通
敏捷实践没有提供贯穿整个企业的、沟通上级与下级的价值流
精益实践，重视端到端沟通的价值，提供了人人参与产品开发的环境，促使公司中不同层面的沟通更加频繁，强调了持续改进、全局优化、尽早交付与频繁交付
精益思想有助于消除由于浪费导致的延误
- 尊重人
尊重管理层和员工，在过程中允许灵活性、持续的改进过程、吸引和留住高素质员工
将复杂程度和返工工作量最小化
- 消除浪费与推迟决策
在适当的时间”最后负责人的时刻“做出决定：太早是你不能获得所需的足够信息；太晚会使你承担更高成本的风险
在需求与分析阶段推迟决策
敏捷方法指导我们去分析客户最重视的需求来处理软件开发项目，同时注意系统架构风险，哪些需求被忽略将会造成系统出现问题，如果有，这也是必须要注意的需求
在设计和编程阶段推迟决策
当需要处理客户模糊需求是，有两种方法：只关注最简单的需求，不去处理任何将来的需求；预计未来可能发生什么需求，为这些需求存在可能性的需求创建系统接口
还有一种替代方法称为”浮现式设计“，设计具体表现在3个方面：
利用设计模式过程的思想，创建灵活多变的应用程序体系结构
设计模式要实现的功能仅限制为当前的功能
编写代码之前编写自动化验收和单元测试，既提高了思维过程，又创建了测试工具
- 利用迭代开发最小化复杂程度与返工工作量
代码复杂的两大原因：编写多余的代码、编写紧密耦合的代码
迭代有助于发现客户的真正需求，防止开发无用的需求
浮现式设计能用”使用中的代码“去解耦”使用过的代码“，而不必增加开发过程中不必要的复杂性
- 创建知识
敏捷过程，分阶段做需求调研，只要发现客户的需求，就去创建这部分需求，快速地交付有价值的软件
产品开发3过程：发现客户需求、知道如何开发产品、开发产品
- 快速交付与频繁交付
延误代表了浪费，消除延误将实现更快交付，重点是为客户增加价值
当快速交付的好处便得显而易见时，以可持续方式去消除延误就成了一种必须
- 品质为先
劣质代码和难以理解的代码也会造成时间浪费
- 全局优化
精益思想来自一种规模化生产的状态，一大转变是放弃了优化每个步骤的理念，更加重视提升生产过程中的效率，即从生产周期开始到结束去优化整个价值流
优化每个步骤的问题在于，在每个步骤都有可能产生大量的库存（部分完成的工作），精益思想证明，单件流（即重视制造一件完整的产品）是一种比集中制造其所有组件更快、更有效的方法
快速-灵活-机动
- 重视时间
精益更重视缩短从提出概念到交付有价值的软件的整个过程的时间，而非如何利用资源
精益角度，如果我们坚持持续的改进过程，专注于更快的生产速度，那么制造成本就会降下来，以更少的错误和浪费获得更高的产品质量；但实际工作方法通常只注重降低成本
软件开发中的延误：
需求被提出到被证实正确，所花费的时间
代码被编写到被测试，所花费的时间
开发人员询问业务问题到得到解答，所花费的时间
- 准时制（JIT）的反思
在每个阶段真正需要之前，才去做分析、设计、编码和测试等具体工作，有助于找到阻碍项目过程的原因
价值流图
价值流是一组为客户增加价值的活动，从最初需求开始到价值的交付为止
价值流图包括画出价值流的过程图形，并利用这些图形来寻找浪费
价值流图的重点是改进从开始到结束的全部过程所花费的时间，同时项目在未来也要保持一定的速度（不能以未来发展为代价而走捷径）
价值流图好处之一在于清楚的显示全局的状况
运用价值流图获知造成问题的根本原因
例：”现状“价值流图
价值流分析着眼于大局，重视客户反馈，实施”将要“价值流图
精益超越敏捷
精益为敏捷实践在新的情况下的应用提供了指南
把重点放在开发时间上而非资源利用上
要重视全局优化，而不是试图让每个步骤都尽可能高效
敏捷通常只关注项目、团队、软件，缺乏远见；精益引领我们超越敏捷，关注整个企业，研究如何选择增值产品，以及如何在公司结构下组织团队工作
敏捷方法通常无法为这种情况提供帮助：系统缺乏良好结构而开发团队又必须为该系统工作
总结
精益为软件开发提供7项原则
尊重人、消除浪费、推迟决策、创建知识、快速交付、品质为先、全局优化
根本目标
快速-灵活-机动
把开发过程看做一个繁忙的生产流水线，凡慢下来流水线就导致浪费，浪费包括延误、错误、误解、等待资源，通过消除过程中的障碍，改进过程
为改进延误与浪费，价值流是图是一个重要的工具，用于分析过程
第二章 敏捷的商业案例
敏捷的益处
敏捷将通过一列方式，使企业和团队受益：
快速提升商业价值
帮助客户明确需求
促进基于知识的产品开发和更好的项目管理
激励团队和允许早起的失败（从失败中学习）
重视以产品为中心的研发
提高团队效率
- 快速提升商业价值
投资回报：客户越早开始使用产品，企业就越早收回投资
提高客户满意度：客户也愿意更早获得新的功能或改进的功能，使他们能更快的将产品投入使用
市场定位：维护或提升市场竞争力的最佳方式，先于竞争对手推出有价值的产品功能，使产品看起来更新颖，具有满足客户需求的能力
低风险：快速响应，缩短客户的反馈通道，尽早发现项目中的问题，及时修正产品或放弃产品，以减少企业的损失
更大的利润空间：更快收回投资成本、更快的发布产品，通过增量交付更小的版本，进一步降低成本
功能越早发布意味着每个人能够越早获得价值：利润、市场渗透、效用
- 帮助客户明确需求
基于客户所知道的那部分需求来启动系统开发，从客户的反馈中获得更清晰的需求，然后在重复这一过程
尽可能少的去开发不必要的功能，更重要的是能开发出一套相对简单的系统
- 促进基于知识的产品开发和更好的项目管理
没有进入项目测试阶段之前，不会知道代码质量究竟如何，通常会带来项目时间延后
短期计划周期
敏捷的神话之一是不用做计划，实际上需要不断的做项目计划，以较小增量或更多的人做计划
发布计划、迭代计划、每日计划，利用15%的时间做计划
为已知的事件做计划整体上比未知的时间做计划容易得多
测试改进开发过程及产品质量
一个精益原则：精益求精、不断提高
强烈推荐测试驱动开发任务的完成，为缩短开发并修复缺陷的周期时间，在开发过程早期就要开始做测试工作
无惧计划
精益-敏捷项目中，总有一种紧迫感，因为项目周期短，所有要与客户保持紧密联系一确保项目能够按截止日期完成
激励团队和允许早期的失败（从失败中学习）
早期发现问题，进行调整，避免浪费
重视以产品为中心的开发
没有从产品的分步发布中获得收益，在产品发布之前，必须完成全部生产过程的研发（这种情况并不少见）
客户能提供完美而清晰的需求（几乎不会发生）
管理层相信开发团队会开发出所需的产品，虽然该项目没有通过迭代进行控制（有时发生）
开发团队需要完成理解敏捷方法，没有学习曲线
提高团队效率
精益方法，从开始新项目前，先结束当前的项目并交付给最终用户
更快的开发当前项目，降低对关键人力资源的竞争，仅此一点就能提升团队的效率
总结
敏捷给团队和企业的六大益处：
快速提升商业价值
帮助客户明确需求
促进基于知识的产品开发和更好的项目管理
激励团队和允许”早期的失败“（从失败中学习）
重视以产品为中心的开发
提高团队效率
第三章 大局观
以达到企业级敏捷为目标
团队敏捷是必要的，但远远不够。企业级敏捷使企业能够比竞争对手以更快的速度为客户提供质量更高的产品和服务
企业需要应对外部的竞争、需要更好的了解市场、需要了解自身的缺点、需要掌握不断变化的技术、还需要了解任何可能对企业产生不利或积极影响的事情
达到企业级敏捷
企业级敏捷要求查看一个企业完整的价值流（交付软件解决方案的流程）
企业级敏捷清楚的表明了（通过市场机会、竞争威胁或业务需求来触发）贯穿产品部署和使用整个生命周期，致力于缩短项目周期时间，并消除在此过程中产生的浪费和延误
大多数敏捷专家主要关注团队本身或团队内部流程，主要精力在项目级别和团队面临的挑战上
技术方法，如设计模式和TDD会帮助团队完成开发工作
Scrum和其他敏捷方法使团队比以前更加有效，但同时也需要更多的指导以解决整个公司内部多团队协同的工作问题
精益思想就提供了所需的方法和指导，应对整个价值流面临的问题和挑战
如何为组织创造真正的价值
为了改进软件开发方法，必须解决几个重要领域的问题：
确定将要开发或升级的软件产品一定是对公司的盈亏底线影响最大的产品
企业资源与升级产品（项目）要相互匹配
管理项目是以最高质量和最快的速度去开发产品增强功能
组织软件开发团队，使其以最有效的方式协同工作
使用适当的软件工程方法，该方法技能支持项目管理，又能确保项目的长期可行性，并维持较低的开发成本
营造学习氛围，使过程不断改进
- 确定价值
什么样的产品将给企业带来最大的商业价值
什么时候企业或客户可以开始使用他们
从业务驱动观点来看，而不是从软件开发角度（我们的技术人员能做什么）
- 管理组织的资源
理想情况下，同一个人应该为一种产品工作，并贯穿整个生命周期
许多项目进行中，对资源的争夺太过激烈，以至于项目计划制定要基于资源的可用性或政治影响力，而不是基于可提供的商业价值
极端情况下，项目团队根本不存在，几个人临时凑一起，同时还会为其他项目工作
会导致很多问题：
人员被分配多多个项目，工作效率下降
我们要求项目准时启动和停止，以便人力资源在需要时被调用；项目不断的中止、重新启动，在加上信息等待，造成了生产力的巨大损失
受资源限制，真正的关键项目无法加速完成
管理项目：
一旦开始产品开发，并分配好资源，必须要有效的管理项目本身
使用适当的软件工程方法：
运用设计模式作出有品质的软件设计和运用自动化前置测试是两种需要开发团队理解和应用的必不可少的基本方法
只重视开发团队的开发速度其实是不够的，必须看到产品在全局中的作用- 在整个价值流中的作用
总结
从非敏捷开发到敏捷软件产品开发的转型，并不是孤立完成的。是在更大范围内- 企业层面的灵活运用
企业级敏捷需要着眼于整个组织的价值流，从最初的概念开始，到客户可以使用该产品为止
第四章 精益组合管理
项目面临的挑战
改进产品开发方法的过程中，软件开发是项目面临的一半挑战
另一半挑战来自要甄选出最重要的产品去开发
这种甄选的方法被称为”项目组合管理“
项目组合
- 项目组合管理
项目组合管理包括一个有规划的项目生命周期，组织使用项目生命周期来确定最大投资收益率的来源，然后定义计划去实现它
用户提出的需求越多，项目组合管理的规模就越大
项目组合越大，就越难管理，进而导致更多的延误
- 我们能使用批处理需求分析出现的延误吗
当分批处理需求时，先发布一个批次中最重要的需求，然后发布批次中次重要的需求，以此类推，直至批次最后一个重要需求被发布出去
- 我们能通过增加发布来避免出现的延误吗
增加产品的发布频率加速了构想和交付产品的时间
这种方法的好处是为企业提供了一份可预测系统实现的时间表，展示了快速交付产品的轨迹
如果构想到交付之前的时间过长，就表明了延迟，作者认为这种想法已经过时
精益组合管理
解决上述问题
目标：采用”快速-灵活-机动“的工作方式，同时选择的项目将给企业带来更大的商业价值
精益思想通过首先交付系统中最重要的功能，尽量减少项目中在制品库存
通过建立反馈机制和侧重价值而非注重提前计划一切事务的老方法，去关注软件开发中的风险
- 精益组合管理有效的原因
允许干系人和客户去定义和排列功能的优先级，为企业带来最高的投资收益率
精益组合管理方法是基于结果的验证方法
精益思想认为，集中思想提交产品最重要的功能，最大限度的提高团队工作效率（通过消除任务的切换和等候时间）和效果（工作产品的最重要部分）
- 确定计划发布
精益同敏捷，建议不去关注太超前的迭代计划，但需要早起做出的决定仍需尽早做出
不然会导致失败，随着对需求越来越多的理解，知识也被纳入了未来的增值规划中
未来的功能可以在迭代中提前被解构，作为计划发布功能的概念来表达，建立学习型组织，带来了在可预见的能力层面的功能描述的评估
- 使用增量交付现在系统
企业通过分阶段开发、商业价值驱动，实现系统的增量交付
增量交付还使企业能应对市场变化，抓住在转换项目过程中出现的商业机会
精益组合管理的益处
- 速度与质量
确定最小的可市场化的功能，更快速的交付有价值的软件
把价值交付和软件质量视为一种可持续的行为，并通过短周期信息的反馈回路不断改进
- 业务需求的视野
将功能和功能描述松散的映射一起，为描述项目愿景的业务解决方案或一个典型的项目章程
创建一个可视的图形，业务功能被列出来，用于排列优先级和衡量技术上需要付出的努力（这些工作必须被不断的权衡）
- 最小在制品数量
确保团队的工作总是聚焦在最高优先级的产品
关键资源在较小的任务块中更易于管理，这些资源是整个团队必须共享的资源
如果工作任务较小，可以将减缓对珍贵资源的争夺，使系统颠簸成本最小化
- 最大限度地减少中断
工作在小块任务中，中断也更容易处理
可以让项目经理的紧迫任务等到团队做完目前的小块工作后再去完成
规避了迫使团队不得不处理多任务的风险
精益组合管理方法
精益项目组合管理的基本方法是从业务功能的分类开始
需要跨职能、不断整合的敏捷团队在团队能力的基础上找出优先排列的工作任务
取得所有项目的所有业务功能后，可以制定产品开发计划
更短的计划周期
考虑不同阶段的时间，并缩短每个阶段的时间：
等到计划的平均时间
计划花费的平均时间
完成花费的平均时间
评估和跟踪进度
传统的项目组合管理通常是针对计划而不是针对创造的价值来跟踪项目进度，有可能项目前期是绿灯状态，后期就突然变成了红灯
精益思想，最优价值的状态指标是可工作的软件，构建规模较小、功能完整的功能件简化了持续集成的原则
避免了长期的集成周期循环和隐性障碍，是防止浪费的方式
通过建立业务功能的精益组合，集中划分优先级，清楚的看到商业价值与成本
团队指导如何为企业估算准确的项目支出，以确定最佳价值
评估使用像素点，由项目组合中功能百分比来确定
总结
精益生产方法管理项目产品组合优势：
精益组合的特征使业务人员和技术人员可以查看项目的投资收益率和所面临的技术风险
使规划人员可以分屏编入预算工作的经配比，并建立最佳工作方式
使项目工作量可被准确的估算，并顺利进入大型敏捷机构中
使企业能够签发一种可预测的版本计划，确立以业务为指导的交付技术解决方案的方式
让企业注重正确的工程实践，企业级敏捷便会实现，从而促进企业变革，加快产品上市时间，为企业带来竞争优势
精益的本质是“快速- 灵活- 机动”
能够通过生产流水线获得更高的价值，选取最小的可市场的功能
确保正在工作着的任务是我们能构建的最小功能，提高了工作效率、更迅速完成工作、降低工作进程、限制产能、消除延误及避免系统颠簸
提高工作效率，提高了产品质量并降低了项目成本
第二部分 精益项目管理
管理是把事情做正确，领导是做正确的事情。- 彼得.德鲁克
一个获得充分授权的组织应该是这样的：它的员工要具备知识、技能和工作热情，并且有机会通过个人的成功引领集体的成功。- 斯蒂芬.科维
超越Scrum
两种方法帮助团队超越Scrum：Scrum#（嵌入精益思想中的Scrum）和看板工程（直接针对工作流）
- 学习一种新方法
要想成为领域中的专家，需要再已经形成的知识的基础上，不断的添加新原则和新做法
这种更新可能成为某些固有方法路的负担，如果没有强大的技术支持，这些更新会让我们不知所措
精益- 敏捷的思维方法可以提供一些适当的更新指南，并使这种知识的更新没有为项目成员带来沉重的负担
敏捷的思维方法解决了在特定情况（环境）下出现的新问题和新做法
- 定义一种方法而不被其限制
过程曾仅被用于微观管理团队或被认为过于松散而对组织无用
团队会反对过程或是被刚性要求的过程吓倒，但缺乏过程也会使团队成员误入歧途
精益-敏捷是通过寻找一种能够支持开发团队良好运作的过程，来平衡过程或过程不足的极端情况
精益思想假定大多数错误都来自系统本身，为解决这些问题，关键要理解开发团队的工作方式，团队成员必须理解他们循序的过程，开发团队自己负责项目过程
当过程支配行动，而这种行动不适合实际情况时，开发团队就必须修改（完善）过程
- 定义过程
通过一下几项来平衡过程：
原则适用于所有的环境，而具体实践只在某些情况下适用
学习新知识时，人需要花时间去转变，也需要一定的速度来学习
当开发团队掌握了新的知识之后，就需要对过程定义进行更新，团队成员应该帮助客户进步，让它们能够从初学者逐渐变为专家
我们希望一个模型，可以让团队轻松上手，然后熟练掌握后又能进一步扩展开来，纳入更多的知识模型
不给新手过多负担，不给经验丰富的人太多约束
- 原则和实践为专业化打开了大门
用精益-敏捷方法建立一个用于从事软件开发的模型，它将结合基本原则、初期实践和思想过程，供团队用来扩大它们的知识面，并可将学习到的他人的经验教学纳入其中
- 知道你在哪里
学习新概念之前，应当纠正之前所学知识的谬误
稍后探讨行业中对Scrum错误的理解
- Scrum是一种框架
Scrum是构建有效敏捷开发过程的一种框架，基于一种概念，即软件开发必须通过响应开发过程中收到的反馈来控制
反馈频率越高对开发过程越有效
没有放之四海皆准的方法，因为每个团队和他们的工作领域、遇到的问题都不尽相同
必须学会学习，还必须摈弃观念上存在的条条框框
- 对Scrum的误解、不正确的观点和Scrum的局限性
Scrum新手的认知误区：
项目开展首次工作时没有做计划
（一些前期计划是必要的，第六章会详细说明）
Scrum中没有文档
（Scrum不会直接去解决这个问题，Scrum建议除非具有商业价值，否则不需要创建文档，这样消除了许多类型的文档，文档只存在于当这些文档对客户有益当的情况下，不要为了写文档而写文档）
Scrum中没有架构
（Scrum不会直接去解决这个问题，Scrum更多的是关于如何管理团队而不是定义团队应该做的工作）
作者认为不正确的Scrum观念：
Scrum的成功在很大程度上是因为由项目成员来定义如何做项目
团队要远离管理层
（第十一章提供了让管理层和项目成员一起工作的方法；精益知道管理层去支持项目团队，当团队创建自己的工作过程时，管理层为团队提供方向性指南
当团队仅仅局限于关注它们重视的问题时，管理层的存在就是一种必须
管理层是团队在项目改进过程中的合作伙伴）
产品是由产品开发人员靠拍脑袋想出来的
（产品牵头人引导开发人员去客户的真正需求）
当决定要开发何种产品时，即可从素材开始启动产品开发，发布计划就是选择发布的素材的过程
（发布计划就是选择要发布的素材的过程）
团队应该由通才组成
（极端片面，团队真正需要的是，能够以很短的时间组织起所需要的技能去完成工作，可共享的知识越多越好）
检查和修改是足够的
（检查与修改是良好的、必要的，但这种行为并不足够，除非它明确改进了团队工作的过程
必须要向他人学习或总结过往的经验，更好的模型是计划-执行-检查 PDCA，团队应该考虑重新学习遗忘掉的知识）
克服Scrum的局限性：
自组织团队能够超越其他团队改进软件开发的流程
（团队应该被自组织而不应该自我向导，持续改进的过程可以通过团队与管理层之间关系的改善获得加速）
每次迭代都需要向客户提供价值
（迭代需求并不总是为客户利益服务，当需要学习一些系统知识时，也可以通过迭代进行
不构建过度需求，会增加浪费，同时也要保持一种全局观）
切勿超越目前的迭代计划
可以使用Scrum-ofScrums协调不同产品团队间的工作关系
可以在无需自动验收测试或单元测试前置的前提下使用Scrum
（在最初创建Scrum时，是有着两项的，但为了大众更容易的掌握Scrum，这两项实践被删除了，其实很必须）
精益思想提供了必要的基础
- 将Scrum#-Scrum嵌入精益思想中
Scrum# 注入了精益思想的Scrum
- 引入看板软件工程
看板软件工程将更多的关注直接放到工作流的方法
看板基于下列观点：
软件开发有关创建和管理知识
软件开发过程可以用队列和控制回路及相应的管理来描述
通过系统的信息流有一定的代表性
看板与常用的敏捷方法不同之处在于：
软件开发团队中排队的队列很少
软件开发团队的中断是尽快完成功能开发，但没有时间箱的制约
从形成概念到产出消费品，在真哥哥价值流的过程中，看板让人一目了然，理想情况，客户启动价值流，产品经理和团队一起紧密合作，利用看板在过程中对在制品的数量加以限制
- 管理看板团队的工作
基于精益思想的看板方法将管理层包含在内，管理层可以参与团队工作的执行和跟踪
累计流程图（CFD，Cumulative Flow Diagram），描述了看板在系统中的整个流动过程，提供了一个衡量工作流程的重要步骤
宽线显示了流动中的障碍或阻塞，细线表明了在制品太少（有时也被称为”气泡“）
看板兼具以下两个工作流：
基于队列和可控制的回路来定义的工作流
在工作流的每个步骤中通过限制在制品数量来管理工作流
团队不断学习加快了工作过程的改进，原因如下：
看板减少了评估每个素材时的恐惧感，这对某些团队来说是一种风险，恐惧总是妨碍学习
看板明确一个团队过程而非一个个人过程，突出的是团队的表现而非个人的表现，可以减少遇到困难时的恐惧感
看板注重的是工作流过程如何被改进，而非责备某个个人
看板能够反映具体措施的实施情况，在开始时利用看板去反应具体的问题相比去反映那些更抽象或更个人的问题更容易
一个开放透明的过程使用管理者能够参与其中，并有机会去改进这一过程
选择方法
总结
Scrum#，将Scrum嵌入精益思想
Kanban，基于精益思想，通过直接管理在制品的价值流来改善产品的流通
第六章 迭代0：准备第一次迭代
为迭代1做准备
瀑布型项目，缺点是在项目开始前耗费了太多的精力去做准备工作
敏捷型项目，许多项目失败却是由于事先没有做好充分的准备
综合两种的优点，在项目开始时做好充分准备去有效的启动项目，使项目能递增的进行开发和交付，但也不要做太多准备，成为额外的负担
- 设置产品
产品牵头人要能清晰的描述企业的愿景，让团队明白企业的需求
在执行迭代前，要实现建立和评估精益组合及发布计划并使其可视化
分解和评估高层次计划，创建足够的素材并分解到任务当中，结构应该能够支持前瞻性
但并不需要过多的关注未来的任务，团队过多的关注未来的任务或风险时会带来很多不必要的分析工作并开发出很多不必要的功能
- 组建团队
精益表示，把工作限制在团队的能力范围之内，是让工作流有效运转的基本法则
在迭代0期间确立并组建团队，在精益-敏捷方法中分配已定义的角色：
管理每日站立会议与可视化控件（产品组合、路线图、发布计划、迭代待办事项）
如何管理项目障碍
如何确保项目开放、透明（在制品、障碍和状态）
创建测试计划：
包括单元测试、功能性测试、系统验收测试、用户验收测试
详细说明”完成“的定义：
素材阶段，团队需要标准化工作，详细说明”完成“的定义
应该有一份简单的文档用以描述团队优先将素材文档必须达到的可视化的质量步骤，包括所有相应文档的更新、可交付设计的更新、编码检查、架构复审和产品牵头人的最终验收
- 构建环境
迭代0尽可能的完成环境的构建准备工作：安装、配置和开发环境组建的校验，包括IDEs、可视化控件、测试工具和缺陷跟踪应用系统
迭代0期间，有专门团队负责执行技术支持（缺陷修复）工作，对构建测试环境也有帮助
- 搭建架构
为了设置开发标准，必须对依赖关系及其风险、架构目标文档做出高层次的定义
这些定义需要企业高层复查和签字，第十三章会进一步讨论
迭代0清单
总结：
迭代0是团队的一个设置阶段，为了启动迭代1和更多迭代计划而做的前期准备工作
迭代0的时间长短取决于团队和项目的需求
准备好：产品、团队、环境、架构，组建团队
第七章 精益- 敏捷发布计划
发布更改计划
- 评估过程
过程包括以下几方面：
过程定义的程度，即过程多大程度上被定义
可预测的程度，或者输出的随机性
反馈的程度，或者过程使用的反馈数量
过程定义的程度：
在确定的过程中，输出100%通过输入来决定；在随机过程中，输出是一种随机变量，会有不同值，以不同概率产生
明确定义的系统产出的输出范围是一个处于确定性与随机性之间的一个闭联集
可预测的程度：
将系统输出看成随机的、可变的，会比将结果标识为可预测的或不可预测的更加有用
输出分为3种形式：完全不可预测、宏观可预测、微观可预测
反馈的程度：
这一变量应该被添加到可预测程度和过程定义程度中
反馈可能是达到目的地最有效的方式，但决定如何及何时使用反馈，是经济学问题
透明度和持续的规划：
第四章把产品组合起来作为一个透明的焦点，企业可以按顺序发布最小可市场化功能
发布计划是一种可持续性的行为，对一份产品愿景进行不断分解，同时重视对企业有较高优先级（价值）功能的计划
发布计划始于产品牵头人提供愿景，产品牵头人为客户与企业决定价值优先次序
项目的预订日期的确定取决于团队开发速度的评估结果如何
为了有效的执行精益-敏捷发布计划，开发组织必须具有创建可视化控件（持续改进）的能力和决定开发速度的能力（开发每个迭代的素材点）
- 发布和提高
理想情况，每次迭代直接发布产品给客户
实际情况，可能因为集成先进行内部发布，或发布代码给客户去获得客户的反馈
为这些不是真正意义的发布，杜撰了一个词”拔高“
发布计划会议示例
通常步骤：
1 定义功能
2 排列功能优先级
3 使用最小可市场化特性分解功能
4 评估功能的价值
5 评估开发功能的成本
6 细化功能，重复该行为，知道使这项功能具备合理的清晰度和高层级的商业价值
7 按照日期或范围创建发布计划
通过适当方法可以帮助团队重视和规避风险：
工作在最重要的功能上
防止在最重要的功能完成之前去开发次重要的功能
最小化在制品的数量
8 计划拔高
一类拔高计划是查看里程碑，让软件优于真实发布的计划完成开发
没有为拔高设置的规则，理想的情况是跨所有开发平台去做集成，但由于存在不同的平台、不同的操作系统、不同的基础客户等，所以集成并不总是能完成
然而，拔高计划有助于我们针对大型、系统工作的一部分，研究最好的方式去获得反馈
会议动力：
1 为客户增加价值
2 迅速进入市场
特别说明
- 评估和风险
风险是附着在错误的评估上的，最糟糕的情况是评估到最后反而成了项目的障碍
重要的不是预测素材开发的优先级别，而是预测素材发布的先后次序，避免错误交付日期
- 帕累托定律与帕金森定律
精益软件开发与帕累托定律相似之处在于：80%的价值来自于20%的工作，20%的功能提供给客户80%的价值
帕金森定律：工作会不断扩展，直至所有的时间被用完；如果没有时间箱没有设置结束日期，就会如此
当多个产品经理竞争团队资源时，应用帕金森定律就特别危险，A经理重视团队的每件事情、B经理只关心什么时候A团队能来做他的工作
可以通过让团队在最短时间内遵循帕累托定律来中和帕金森定律的影响
总结
一个组织对可视化发布计划的维护以持续且有效的速度来驱动的，组织拥有一个有竞争力的武器- 关键战略和战术，对商业化价值的最大化进行不断的分析
交付组织积极参与发布计划的活动，并通过评估来实现企业级敏捷
第八章 企业团队的可视化控件和信息发射器
“不能衡量就无法提高”
“没有清楚的认知，就无法真正的改进”- 艾伦.沙络维
“过程不可视就无法工作”- 盖伊.比弗
可视化控件和信息发射器
Scrum环境中以下几个方面使用信息发射器：
产品愿景
产品需求列表/发布计划
迭代列表
向下燃烧图与向上燃烧图
障碍列表
可视化控件包括以下几方面：
信息传递可视化
真实反映（或者至少部分反映）团队正在使用的过程
描述工作过程的情况
用于控制工作过程
任何人均可查看
可视化控件和信息发射器，只是不同称呼，相同目标，精益思想中，“可视化控件”具有更多含义
除了能向所关心项目进展的人分享信息之外，也能反映管理层要参与项目进度的意图
当存在问题阻碍团队进程时，可视化控件会邀请管理层协助检查
在团队需要被干预的关键时刻，方便管理层能及时叫停并做出调整策略
可视化控件增加了可能性- 管理层可以实际干预过程来增加价值
精益-敏捷可视化控件
可视化控件存在于项目的所有层面：业务层、管理层、团队层
应该有助于让业务人员认识到价值是如何被创建的，并协助管理层和团队成员去高效开发软件
可视化控件的细节：
1 产品愿景
2 产品需求列表、发布计划、精益组合管理
优先级从左到右
3 迭代列表-单一团队、多个团队
遵循推迟承诺和准时制原则
单团队
多团队
精益-敏捷中，通过价值流向企业交付最大价值，在此基础上待完成的工作将被拉入进来
产品开发阶段整个过程包括3个阶段：发现、定义、构建
建立清晰的可视通路
4 素材点向上向下燃烧图
5 商业价值交付表
6 障碍列表
包含字段：
输入列表中的日期
障碍描述
障碍严重等级（障碍的影响是什么）
障碍会影响谁
采取的清楚障碍行动
用可视化控件管理依赖关系
好的可视化控件
特征：
需要极少的时间去学习使用这种工具
能够为团队指明接下来将要做些什么工作
能够为管理层指明团队正在如何做工作和正在做什么工作
总结
可视化控件是管理精益-敏捷软件开发工作中的一个关键组建
提供了一种低成本方法，让团队能够看清楚所在的为止
让管理层和客户能够看清开发工作的进度，向项目各个参与方提供项目的状态信息
能够让大家一起合作，解决团队面临的任何问题，以获得最高价值，将具有最高质量的产品推出市场
为团队和管理层提供了一种合作技巧，在获得正确结果的前提下，有助于管理层监控团队的进度
管理层用可视化控件、对团队的支持和方向性指导代替了命令和控制
本文只是描述了一些基本使用控件，可以视项目需要增删合适的可视化控件
第九章 精益-敏捷软件开发中的QA角色
质量保证（Quality Assurance，QA）指有计划的、系统的生产过程，为产品符合预期目的的实用性提供保障
质量控制（Quality Control，QC）确保产品或服务被设计和生产出来，满足或超越客户需求的做法
QA应该为防止缺陷负责，而不仅仅是发现缺陷，为达到这个目地，QA应该被移至开发周期之前，有助于团队避免大量的沟通错误，这些沟通错误会带来延迟、缺陷和浪费
在开发每个素材之前，团队与客户应该关注“如何得知工作已经完成？”，理想情况应该在编写代码之前进行测试，并且确保以最小的浪费来生产高品质代码
第十章 成为敏捷企业
持续改进不是说你要把事情做得多好-那只是工作的一部分。持续改进是移走那些妨碍你工作的事务，那些降低工作效率的事务。这就是持续改进的真谛所在
想去何处
目的地：
确定市场需求
快速响应市场变化
为市场开发软件- 高品质且重视交付最高价值的功能
开发的产品（内部与外部）要有长久的生命力、易于扩展和容易维护
做以下事情：
确认和定义开发最小可市场化功能
管理开发组织，使生产力最大化和迭代循环时间最小化，并且在此过程中开发出高品质软件
确保团队遵守精益原则，在约束因素范围内尽其最大的努力
雇用具有最高水平工程实践技能的团队（有能力开发出高品质的软件，包括测试驱动开发和设计模式）
采用持续改进过程的做法，变成一个学习型组织
企业驱动软件开发：
上述行为是基于业务驱动的组织所需要的，但还不足以让团队变得敏捷，企业还必须组织和领导团队为客户增加最大价值
如何到达
企业转型期普遍存在的问题：
团队没有很好的形成
团队成员不在一起办公
年度周期计划导致项目需要更长的时间去完成
大批需求杂乱无章的堆放在一起
项目经理和项目发起人争夺资源，而不是一起合作以实现投入收益最大化
自动化验收测试没有完成
在项目结尾才完成集成
代码质量依赖于程序员的个人能力
没有积极地寻找和消除问题的根源
过程的持续改进没有实施或没有价值
平衡调整片
改变大型轮船的过程非常困难，以个人力量去改变社会是一件困难的事情
一个平衡调整片就像一个个微舵，当移动船舵时，平衡调整片会创造一个低压区，使舵能够很容易的转动
平衡调整片可以让船员话很少的力气就能转动一艘巨型船只
如果要改变这个世界的话，必须寻找人生的平衡调整片，用微小的理想产生巨大的影响
转型时期的指南
考虑三个问题：
最容易清除的痛点是什么
转型过程中的文化态度是什么
转型过程中的尺度是什么
要点：
刚开始时计划做太多工作反而产生不良后果，即使所做的工作都有价值
人们经历转型，通常怀有某种程度的恐惧
人们始终要明白的是他们的工作范围
给转变做转型工作的团队再去增加关键性工作，可以导致人们放弃转型
我们应该寻找“平衡调整片”去协助平衡过渡，“摘低处的果实”，低付出、高回报
从何处开始
- 产品公司
生产产品供个人或其他公司使用，拥有定义良好的开发团队，但团队成员通常会同时参与多个项目
从最常见的地方入手以提高团队效率：如通过实施Scrum或看板
构建敏捷团队、改进选择产品增强功能的方式、计划管理者合作一起挑选最小可市场化功能
转型方法通常以团队为基础，使用精益思想做指导，从头开始工作
- IT 公司
降低运作项目的数量和定义良好的工作团队是一套组合行为，必须同时进行，以避免造成其他（Scrum）团队获得成功的同时，（非Scrum）团队遭遇挫败
重点关注对客户有价值的功能
- IT-产品公司
向其他公司出售服务
年度项目预算计划在这类机构具有很强生命力，学会如何构建更小的项目是关键
在开始的时候对计划管理者加以适当的培训
明确定义可能的最小可市场化功能、然后对最小可市场化功能按照投资收益率进行排序
各个团队工作在同样最小可市场化的功能中，从共同产品需求列表中将最小可市场化功能拉出来开发
跨职能团队的创造力将带来生产力的立即提升并带来即时收益，这种收益可以超过并抵消转型本身带来的混乱
持续过程改进的重要性
精益并不是关于专注企业转型的方法，而是一个让企业学习转型的过程
但是为了转型而转型的目标是不对的，转型的目地是提高生产力和投资收益率
团队需要研究如何改进过程并改善与其他团队的依赖关系
管理层需要不断的寻找一种方法去减少迭代循环的时间并提高产品质量
团队要学会去发现并改进过程，找到组织结构中的障碍，以便进行修正
总结
公司如何转型取决于所处的位置和需要克服的挑战
在已经存在的架构中，以它们的能力从业务需要的角度去推动开发，有助于到达转型的目地
第十一章 精益- 敏捷开发中管理者的角色
“管理是把事情做对，而领导是做对的事情”-彼得.德鲁克
"你必须管理系统，因为系统本身不能对自己进行管理"- W.爱德华兹.戴明
精益-敏捷管理
精益-敏捷重视价值流的管理和对人员的领导
构建环境
敏捷开发团队是一个完整且具有超强生产力的团队，需要有一个有利于成长的环境、健康的团队活力和良好的团队行为
需要一位具有良好视角、专注力与深刻理解需求的领导者
精益-敏捷中，管理者有两个重要的职责：
设定结果或团队预计要达成的目标
协助工作人员改进过程并安排工作区，以方便团队完成工作
精益-敏捷兼顾管理的办法
泰勒主义，一种趋向于指挥和控制风格的管理方法
当风险增加时，采用指挥和控制的管理方法（Command-and-Control）会让人觉得比较安全
精益思想提供了一种替代方法：对实现目标的工作和方法授权，但仍需要团队成员对结果负责
运用多种方法和工具将团队面临的调整可视化，运用这些方法和工具来解决项目问题
同时需要管理者注意，不要提供解决问题的方法，只是引导团队，防止团队掉入问题的深渊，避免浪费
在团队内部创建知识
精益-敏捷管理者必须再组织内部构建知识，并清楚的知道通过自己的方式催促团队工作将会产生不利的影响，短期、低效的战术违背了在价值流中优化工作的原则
精益-敏捷领导力应该在短期效率最大化的技能基础上防止管理者按照逻辑去推动工作分配
敏捷开发管理者要注意创建“教与学”的文化氛围，但违反了主流的战略管理思想：充分利用有技能的专家，分解任务并分配任务，是个人以最大效率完成工作
寻找根本原因
寻找根本原因，对症下药，确保解决方案能增加价值
精益思想指导我们我们首先查看价值流，并分配人员不断的去消除任何不增加价值的行为，从构思到产品交付使用的整个过程
敏捷软件开发不是无政府状态
可行的精益-敏捷转型战略是一个自上而下的领导过程和自下而上的实施过程
精益管理为我们设置了愿景和成果，同时培训团队并完善组织架构
缺乏管理等于缺少成功
Scrum的目的是让组织中的问题变得开放、透明，向组织提供了查看项目过程的工具，但不是修正问题的工具
精益-敏捷方法所信奉的管理层参与的原则，为解决许多标准敏捷方法不能解决的问题提出了深刻的见解
管理者必须看到，团队是如何被他们制定的那些制度所影响，使他们能够做出必要的改进
用精益思想提高管理
正常人的真实反应- 在关键时刻用熟悉的、过去的行为方式解决问题
管理者能有当前的成就，就是因为在关键时刻能够比其他人更具有处理危机的能力
管理者的其中一项任务，就是要教会被管理者的员工，充分授权给员工，使他们能够实现目标；项目进展顺利的时候，大多数管理者都能做到这些，但当关键时刻来临时，管理者很容易会跳出来，又采用管用的方式来解决问题
这造成了微观管理，并抑制了团队学习和设计解决方案的积极性
精益思想为管理者提供了一种方法去监控团队是否达到了所需求的结果并指导团队最终达到目的
总结
精益思想旨在帮助企业最大限度的完成高品质、高附加值的工作
利用精益和业务驱动原则将工作按照收益率大小排列，无论按照利润、销售额、客户重要性或其他因素，均由产品牵头人来决定
克制住“让员工保持忙碌”的冲动
排队理论的知识体系有助于提升针对优先级更改时跨职能团队快速重组的能力
第十二章 产品协调小组
让团队协同工作
- Scrum-of-Scrums
来自不同团队的成员定期召开会议，以促进合作、交流和分享需求
适用于管理一个具有共同目标的大型团队，不适合管理几个具有不同目标的小型团队
人的本性是先感兴趣自己的同事正在做的事情，其次是部门，再次是分公司，最后才到总公司
Scrum-of-Scrums 方法与这一本性相反，它假设来自松散团队的各个成员跨过所有团队为企业创建一个更大的蓝图，所有成员以这个蓝图为共同目标
- 协调小组面临的挑战
多个团队合作可能出现的问题：
整个团队的进度
需要多个团队来实现需求
团队之间的技术依赖
多个团队使用通用组件
需要一个团队修改代码去协助另一个团队的工作
团队的共享代码
一个团队拥有另一个团队所需的知识
产品协调小组
导致团队不能协同合作的根本原因：
视野过于狭窄，仅仅关注自身的需求；如果要想实现协同合作，那么团队需要改变从自身利益出发的视角
需要一个协作的架构，把基本的关注点放在企业的视角上
标出涉及团队问题的素材，并排列出开发的先后次序，它能把素材分配到最合适完成素材开发的团队，成这个协作架构为“产品协调小组”，团队的另一个产品牵头人
产品协调小组与Scrum-of-Scrums之间有很多相似和不同，协调小组工作重点是站在更高的角度-“全局优化”，是一个真正意义上的团队，由来自不同团队中的成员组成的，为了达到一个共同的目标而团结在一起
Scrum-of-Scrums是一个大局观的前提下，将团队的问题交给团队自己去解决
- 产品协调小组指南
由固定成员和轮值成员组织
固定成员：对于保持一致性和确保团队目标被理解是有用的
轮值成员：帮助产品协调小组不偏离开发团队的需求，识别需求
计划成员：来自开发团队和在迭代计划阶段参与产品协调小组的成员
- 目标
实现企业价值最大化
确定和协调如何让开发团队在技术上发挥最大的协同合作作用，特别是要找出通用组件，避免冗余开发，协助浮现式设计
验证拔高的计划
- 提供指导
为团队提供良好的个性化指导
可以作为团队实践的基础，也可成为知识管理或分享的方法
总结
团队间协同合作时遇到的挑战，自身利益是根本原因：团队应该（适度地）关注当前的需求和工作任务
产品协调小组，要拥有特有的企业视角和充分授权去关注团队的问题，是跨团队协调问题的产品牵头人
功能和Scrum-of-Scrums 类似，但目的各不相同
第十三章 精益-敏捷中的软件架构和设计角色
避免过度或过少设计
只开发在此刻需要的功能，当有新问题产生时，系统可以快速升级-来做开发
为了解决这个问题，需要开发人员做到一下几个方面：
快速编写代码
修改代码但不会破坏代码
能够安全修改代码
为改变而设计
有的开发人员只关注解决手头上的任务，而不是寻找一个综合的解决方案，当给开发人员时间去思考的时候，他们又会过度开发，以解决可能出现的问题
解决问题的关键在于，要意识到在开始阶段是不太可能做出正确决定的，必须编写可以改变的代码以满足变化的需求，但你还不可能知道需求将如何变化
编写高质量的代码使系统具备可更改的特性是解决问题的关键，同时要做全面的验收测试，使系统能够安全的升级更新；另外还需要管理层支持并鼓励开发团队去完成这些工作
适度准备，敏捷鼓励不过度设计，刚好够用，平衡
《设计模式解析：从一个全新的视角描述面向对象设计》
软件开发中的设计角色
设计能够让代码的更改变得简单，将改变对系统带来的影响最小化
通过：组合解耦（隔离）、封装和防止冗余达到
软件架构的目的不是尽可能多定义每项功能，而是妥善处理好功能之间的关联关系
遵循“准时制设计”原则，防止因为预测而过度设计
软件开发设计中的管理角色
管理层大多数情况下都会支持开发团队，同时提供开发愿景
所谓支持，是指在不给团队过多压力的前提下，协助团队了解什么需要团队做的工作、特别是什么时间应该开始构建自动化测试
但管理层并不是安静的接受开发人员想要做的任何事情，需要作出对开发工作的成本判断
同时相信开发人员作出的关于构建软件质量的判断
总结
软件设计的目的不是设计一个满足所有需求的软件框架
只是定义主要概念之间的关联关系
当出现新的需求或新的变更时，让系统作出的修改对系统本身的影响有限
第十四章 认识精益
“名字有什么重要的？玫瑰如果不叫玫瑰，但它依然会芳香如故”- 威廉姆.莎士比亚
丰田：首个伟大的精益实例
W.爱德华.戴明，伟大的质量改进体系的先驱者
丰田的生产方式（Toyotal Production System，TPS）就是基于戴明的想法而构建出来的
TPS 的根本就是要绝对的消除浪费，支持这套系统的两个支柱是：
准时制
自动化，或者说以人为本的自动化
准时制，指在生产运行过程中，必须在需要的时候按需要的量生产需要的产品
自动化要求过程平稳运行，当过程遇到问题，不能只是简单的解决问题，而要找出问题的根源所在
在戴明原理的基础上，丰田的生产方式新理论由3部分构成：如下图
精益重视用户价值，但其真正的含义要依赖具体情况而定
重点是向客户交付如客户所期望的（产品）价值，不必在开发之初就明确客户的需求，重点是学习和改进你对客户需求的理解
如丰田产品开发系统中常常会提及的一种做法是“多方案同步进行的开发工程”（Set-Based Concurrent Engineering，SBCE），一种降低风险的做法
精益的三个主体
精益“科学”（拉动原则、限制原理、流动性）
精益管理（管理层和开发团队一起工作）
精益知识管理工作（如何学习、指导和保持知识的生命力）
- 精益科学
准时制
使用原理：
少量队列和批量型号
限制在制品数量
少许法则（循环时间=在制品数量/产能，利特尔法则）
拉动管理
实际选项
- 精益管理
强调管理者对团队绩效应承担责任
远离事无巨细的微观管理，管理者教团队去执行一种新的过程，包括团队需要遵循的具体工作流出
管理者是领导者、教练和培训师
他们不是“公仆式的领导者”，而是以一种积极的方式去帮助团队，去引导
精益是一门已经构建好的科学体系，管理者提供一个机会去帮助员工学习这门科学，并将这门科学应用到事件中去
- 精益知识管理工作
包含一下内容：
A3s（由丰田公司开创的改善工具，采用一页纸格式解决问题的方法。通常用结构化方法把问题、分析、改正措施、以及执行计划囊括在一张A3纸上，格式图形化目视化，以取代冗长的书面报告，让报告者可以用五分钟清楚传达信息。）
Kaizens持续改进
工作后的检查和回顾
5Why分析法
价值流映射
来自精益-敏捷教练们的深刻见解
一次只关注一个项目
启动较少的项目
缩短批处理时间
寻找缺陷产生的根本原因
知道你在哪里：最小化可发布的功能
生产力及质量
跨职能团队
精益宣言：快速-灵活-机动
优化整个价值流
短队列、消除浪费（优先级、准时制、寻找根本原因）
下一步：获得更多的方法
www.netobjectives.com/lasd
用户兴趣小组
http://tech.groups.yahoo.com/group/learnagile
http://tech.groups.yahoo.com/group/leandevelopment
阅读书籍
其他资源
www.netobjectives.com/resources 咨询服务
总结
精益-敏捷软件开发是用比从前更低的浪费和成本，快速、优质的开发软件的方法
精益原则结合了科学、管理和知识管理工作
我们形成的终点并不是精益，这是一个持续的过程，持续改进意味着总是在寻求更好的转变
精益助力高效、快速的开发出最重要的功能组件，为客户增加价值并降低成本
附录A：团队评估游戏
扑克牌+改良版斐波那契数列
附录B：精益-敏捷软件的开发模型
精益思想的基础
以精益生产为基础的基本体系，大多来自爱德华.戴明作出的贡献
1 多数错误是系统性的
2 人们的本性是好的，都想把工作做好（以人为本）
3 当企业为客户提供了最大价值时，企业也实现了自身利益的最大化
精益生产带来了实现精益的可能性，通过员工的努力工作，结合管理者的指导与引领来实现持续的过程改进
- 观点
精益思想是戴明的知识体系与丰田所推崇的准时制的完美结合
1 看看时间，已经没多少资源可用了
2 使开发过程快速、灵活、机动
3 增加过程可见性
4 消除浪费的最佳方式是不开发不需要的功能
5 过程就是变革的基础
6 把过程的阻碍当作浪费看待
- 原则
原则（法律）
1 缩短周期时间，减少浪费并提升质量
2 当下面时段中耗费了过多时间时，会产生浪费和获得低品质的产品
当需要信息的时候和当你获得信息的时候
当你发生错误的时候和当你发现错误的时候
3 决策过早增加了浪费的风险
4 超额的在制品数量增加了风险和浪费
5 对流程的阻碍造成了浪费
6 并行项目数量增加而没有增加可为项目工作的资源，延长了项目的时间长度
7 参与多个项目，降低了人员的效率
8 大批量生产造成浪费
9 任务切换产生的系统颠簸会造成浪费
10 忽视风险会造成浪费
11 快速交付有价值的软件可以提高投资收益率
原则（指南）
1 全局优化
注意从概念到产品开发完成整个过程中缩短循环时间
不能花费总体的周期循环时间去做局部的改进
2 消除浪费
分配的工作要限制在能力范围之内
消除人员或信息等待过程中产生的延迟
消除从发生错误到错误被检测出来这个过程中的延迟
重视消除产生错误的根源
找到方法，消除阻碍团队进程的事物
使团队在一个时间段内只开发一个项目
3 构建知识
查看系统错误
遵循科学的方法找到改进过程的方法
挑选最重要的事情去工作
尽可能的定义出可行的工作流，将其作为变更的基准，这能够带来管理的可见行
4 品质构建
质量问题经常造成工作流上的延迟，消除这类延迟可以改进产品质量、提升交付速度、降低成本
5 推迟委托
在适当的时候作出决策
如果可能是决策可逆
6 快速交付
开发具有最小可市场化功能的产品增值功能
遵循指南，通过移除延迟来“消除浪费”
7 尊重员工
让具有丰富知识的员工常常感到挫败的事情是，提出的解决方案常常无人理会
通过改善管理系统去构建企业文化
制定过程持续改进的目标，员工将朝着这个目标去完成工作
- 态度
我们的态度是我们持有的信仰体系所产生的结果，会影响对所有事物的看法
1 管理者是最重要的，为团队设置目标，并允许团队以自己的方式去筹划该如何实现目标
2 要设定在尽可能短的时间里交付尽可能多的价值的目标
3 通过消除浪费移除延迟，提升产品品质和降低成本
4 要改正错误，不要让错误从你手边溜走，或者至少要把错误标识出来，待开发后期再去探寻产生错误的根本原因
- 知识
1 知识是经验教训的积累
2 如果测试和修复循环计划占用的时间很长，前期就不会有足够的时间做前置测试
3 只重视优化组件而不关注全局的目标会造成浪费
4 重视降低成本往往会带来低劣的产品质量，并需要话费更长的项目时间
5 只重视产品质量又可能造成项目需要更长的研发时间，从而交付给用户更低的价值
6 通过消除延迟来提升开发速度将缩短交付时间、提升品质、降低开发成本
7 实际的开发人员比管理者对系统有更大的认知能力
8 在制品通过表示系统经历过很多系统颠簸，在颠簸过程中的产物
- 实践
要有效的发挥实践的作用必须根据不同的环境运用不同的实践，确保运用的实践和环境兼容
运用原则指导实践在不熟悉的领域内的运用是一种创建新实践的好方法
1 运动价值流图找到延误
2 运用可视化控件管理项目
3 分阶段开发项目
4 持续的改进过程
5 将测试行为移到开发过程之前进行
6 挑选风险最小的素材进行开发（最大的风险就是开发不需要的功能）
7 使用最小可市场化功能来制定发布周期计划
8 跨职能团队完成一个项目后在转入另一个项目
9 进入“工作现场”（就是进入正在开发软件的工作之中）
只是一个开始
上述展示的模型只是一个开始，当将精益展开学习，模型将得到进一步的拓展
《产品开发流程的原则：第二代精益产品开发》
介绍了175条精益产品开发的原则，并按领域对原则进行了划分
- 经济上的考虑、排队队列、变化性、批次型号、在制品约束、流程控制、快速反馈、授权
《管理设计工场》
www.netobjectvies.com/lasd
敏捷项目管理图书
《有效的项目管理- 面向传统、敏捷、极限项目》
《精益-敏捷项目管理：实现企业级敏捷》
《敏捷回顾-让团队从优秀到卓越》
《项目管理敏捷方法》
《敏捷项目管理决策：平衡控制和敏捷性》
《敏捷职业发展：IBM的经验与方法》
《指导敏捷团队》
上面四本有，下面三本暂没有
