【卓有成效的敏捷】读书笔记

《卓有成效的敏捷》必读！28个核心原则揭秘：为什么90%的敏捷实施都失败？这本书彻底颠覆你对敏捷的认知，教你如何通过检视调整、跨职能团队、短周期迭代等实战策略，真正实现软件开发的质量翻倍、交付提速！无论你是技术小白还是管理大佬，这本书都能让你避开敏捷陷阱，用科学方法打造高效团队。错过等于亏钱！

卓有成效的敏捷核心原则与实践
对《卓有成效的敏捷》的赞誉与致谢
敏捷开发的演进与实践价值
OODA循环与敏捷开发实践
Scrum失败模式与成功要素
跨职能团队构建与敏捷组织原则
分布式团队效能与个人发展策略
敏捷团队沟通与高效项目管理
垂直切片交付与技术债管理
大型项目协作挑战与敏捷质量测试原则
敏捷测试与需求开发核心要领
敏捷需求与交付的核心实践
CI/CD实践与敏捷领导力核心原则
组织支持与敏捷度量改进
敏捷预测与检视调整实践
受监管行业的敏捷实践与组合管理
多米诺变革模型与创新扩散
参考文献列表

卓有成效的敏捷核心原则与实践

有效的敏捷为何重要
敏捷的好处从何而来
关键原则：检视和调整
Scrum是什么
关键原则：从Scrum开始
不称职的产品负责人
产品待办事项列表细化不足
完成定义不清晰
每个sprint质量没有达到可发布水平
关键原则：搭建跨职能团队
关键原则：将测试人员整合到开发团队中
关键原则：通过自主、专精和目标来激励团队
关键原则：培养成长思维
关键原则：加强反馈循环
关键原则：修正系统，而不是处理个人
关键原则：通过培养个人能力来提高团队能力
关键原则：保持项目规模小
关键原则：保持sprint短小
关键原则：以垂直切片的方式交付
关键原则：管理技术债
关键原则：使缺陷检测的时间最短
关键原则：制定并采用完成定义
关键原则：将质量维持在可发布水平
关键原则：由开发团队编写自动化测试
关键原则：细化产品待办事项列表
关键原则：制定并使用就绪定义
关键原则：自动化重复性工作
关键原则：管理结果，而不是管理细节
关键原则：用指挥官意图明确表达目标
关键原则：关注吞吐量，而不是关注活动
关键原则：在关键敏捷行为上以身作则
关键原则：正向看待错误
关键原则：以量化的团队产能为依据制订计划
度量什么，就（只会）做什么
敏捷开发的原则就是缩短反馈循环
卓有成效的激励机制是自主、专精和目标的达成

对《卓有成效的敏捷》的赞誉与致谢

无论你是经理还是高管，无论你是刚开始转向敏捷还是期望改进敏捷，在这本书中你都会找到基于深入研究和广泛经验的实用建议。
这本书让软件组织领导者能够接触和关注敏捷开发的前沿的核心概念。
敏捷是一组实践手段，这组实践手段源自与业务紧密关联的工作成果，而不仅只是一套要执行的仪轨。
这本书的28个关键原则总结了过去40年软件产品开发中最有价值的经验教训，是非常宝贵的学习资料。
对于过去认为应该采用顺序生命周期开发方式的项目，例如需要精确预估时限，或者开发过程受到监管，敏捷方法（如果正确使用的话）能够发挥惊人效果。
这本书对技术型读者和非技术型读者都非常易读，能够使他们对敏捷达成一致的理解。
许多理想化的敏捷方法在面对复杂的现实情况时败下阵来。这本书是穿越敏捷实施迷宫的一盏非凡的指路明灯，它描述了要寻找什么（检视）以及如何应对所发现的情况（调整）。
令人耳目一新的是，这本书避免了敏捷教条，并解释了如何使用那些适合业务需要的敏捷实践。
人们常常（错误地）认为，采用敏捷就会失去可预测性，而不认为可预测性恰恰是敏捷所能带来的好处。
这本书全面介绍了如何卓有成效地实现敏捷并不断改进，使敏捷不仅仅停留在起步阶段。
这本书总结真实经验，将创建现代软件密集型系统的各个方面——技术、管理、组织、文化和人——汇集成易于理解、连贯、可操作的整体。
这本书教你如何将敏捷看作一组工具：在环境需要敏捷时有选择性地应用它们，而不是要么不用要么全用。
这是一本优秀的书，彻底回答了“为什么使用敏捷？”这个问题。
这本书是对敏捷这个20年的方法论的诚实审视，而且这可能是第一本直接针对软件组织领导者并告诉他们如何实施的书。
这本书代表了20年敏捷实施实践经验的巅峰。如同《代码大全》在20世纪90年代成为软件开发人员的权威手册一样，这本书将在接下来10年成为敏捷倡导者的权威手册。

敏捷开发的演进与实践价值

21世纪初期，软件行业领导者就敏捷开发提出了许多重要问题
敏捷最初的承诺言过其实了，多数敏捷实施令人失望，而且获得结果所花费的时间常常超出预期
使用现代敏捷开发为同时提高质量、可预测性、生产力和产量提供了机会
拥有高效IT组织的公司超标实现公司在盈利、市场份额及生产效率等方面目标的可能性是其同行的两倍
有选择地、合理地使用现代敏捷实践为高效软件开发以及随之而来的所有好处提供了一条行之有效的途径
大多数公司没有认识到敏捷实践的潜力，因为大多数敏捷实践的实施方式都不够高效
敏捷这个词已经成为一个涵盖无数实践、原则和理论的总称
本书讨论了公司关心而敏捷纯粹主义者常常忽略的主题
本书关注的是已经被证明有效的实践
敏捷开发的好处可不是由于用了敏捷这个词。它们源于那些敏捷要点的直观效果
短发布周期能帮助你更及时且以更低的成本修复缺陷、浪费更少的时间在无效需求或设计上
以小批量方式开展从需求到实现的开发工作提供了更紧密的反馈周期、更快且成本更低的错误检测和修复
频繁的结构化协作减少了沟通上的错误
一旦不再认为敏捷是不可分割的概念，就可以自由地单独实施敏捷实践
错判项目属于复杂域（但实际上是属于繁杂域）所带来的后果不如错判项目属于繁杂域（但实际上是属于复杂域）那般严重
保险起见，应该总是使用敏捷实践把项目作为复杂的问题处理

OODA循环与敏捷开发实践

OODA代表了观察（observe）、定位（orient）、决策（decide）和行动（act），通常被描述为“OODA循环”
OODA是一种系统化的方法，用于建立上下文、制订计划、执行工作、观察结果，并将所学到的内容融入下一次循环
观察现状，观察相关的外部信息，观察正在演变（浮现）的局势的各个方面，并观察局势正在演变的方面与环境如何相互作用
定位这一步提供了机会，使你能挑战假设，调整因文化差异与公司文化带来的盲点，进而更客观地解释观察得到的数据和信息
苹果却定位到一种完全不同的方式，专注于创建具有开创性用户体验的移动信息设备
决策这一步，你将基于定位所确定的选项做出决策
侵入并影响对手的OODA循环——这是在以不同的节奏运行
顺序方法需要大的预先规划、大的预先设计等，而OODA方法适时地完成大部分工作
顺序开发将不确定性视为风险，而OODA将不确定性视为机会
敏捷团队应该定期检视和调整所有事情——计划、设计、代码质量、测试、流程、团队沟通、组织沟通
Scrum是最规范的常见敏捷方法，它拥有由图书、培训产品和工具所组成的最大生态体系
Scrum是一套轻量级但结构清晰、高纪律性的团队工作流程管理方法
产品待办事项列表是Scrum团队可能交付的一组需求、进行中的需求、特性、功能、故事、功能增强和bug修复
团队在每个sprint结束时交付的功能被称为增量
团队聚在一起进行每日Scrum，专注检查sprint目标的进展
团队使用sprint评审中获得的反馈改进产品及过程和实践
产品负责人主要负责定义产品待办事项列表并对产品待办事项列表中的项目进行优先级排序
Scrum Master负责Scrum的实施，帮助团队和更大的组织理解Scrum理论、实践和通用方法

Scrum失败模式与成功要素

大多数无效实施都是“Scrum-but”，意思是，“我们在做Scrum，但我们没有使用某些关键实践。”
因为它已经是最小的了，所以真的不能移除Scrum的任意部分却仍能获得Scrum的好处。
完美的状态，不是无可增加，而是无可删减。
如果组织已经实施了Scrum却没有感受到它的显著好处，首先要问的问题是：“我们真的实施了Scrum吗，还是只实施了部分Scrum？”
初学者照本宣科地实施Scrum会更好。
公司应该将产品负责人视为Scrum团队最具影响力的角色并相应地优先安排这个角色。
细化良好的产品待办事项列表对敏捷项目具有决定性作用。
为了支持在每个sprint结束时让工作达到可发布状态，故事应该可以在单个sprint中完成。
每天举行每日Scrum，从而让团队成员有机会协同工作、寻求帮助以及彼此监督，是非常重要的。
当sprint的长度超过3周时，将更有可能滋生计划错误、sprint承诺过于乐观、拖延等各种问题。
以垂直切片的方式进行工作，支持更紧密的反馈循环并能更早交付业务价值。
严格的完成定义（definition of done，DoD）是维持高质量的重要支撑之一。
更为成功的敏捷团队不会等到sprint结束时才实现可发布的质量：他们在开始下个故事前会让每个故事达到可发布的质量水平。
除非给自己一个机会，从最初导致这个循环的规划和承诺错误中汲取教训，否则过度承诺和精疲力竭的恶性循环会持续。
不要容忍问题——做些事情解决它们。
你只需启动Scrum就好，不需要更多东西。
Scrum Master是避免这些失败模式的首要负责人。
对实施敏捷开发的团队或组织而言，第一要务是确保完全遵循规范地使用Scrum。
一个高纪律性的实践是人们倾向于渐渐远离的实践，除非有社会或结构性的支持来确保实践的发生。
每种失败模式都可以转换成一种成功因素。
一个成功的sprint会支撑Scrum的主要目标——交付可能带来最高价值的产品。
团队是敏捷开发生产力的基本单位——是高效的团队，而不是高效的个人。

跨职能团队构建与敏捷组织原则

高效团队在单一的，跨职能的团队中有两倍的可能开发和交付软件
团队必须能够对自己的大多数工作做决策，包括关于产品细节（需求）、技术细节和过程细节的决策
是否愿意为敏捷团队配备内部可以完成大部分决策的专家，这对敏捷实施是成败攸关的问题
缺乏足够的权力会引发几种情况，它们都是反生产力的
组织不愿意赋权给团队，让他们能够制定有约束力决策，这是敏捷团队和敏捷实施失败的另一个根源
真正的自管理团队不能从模子里刻出来，他们必须成长为自管理团队
知道组织足够信任团队并允许他们犯错，这会是一种巨大的激励
软件测试是一个非常深奥的知识领域。大多数开发人员不理解测试的基本概念
测试专家仍会增加价值
对软件开发工作，唯一重要的激励是内在激励
自主指的是指导自己生活和工作的能力——做什么，什么时候做，以及和谁一起做
成长的机会对开发人员比晋升、认可、薪资、地位、职责水平以及其他你可能认为更重要的因素更具激励作用
目标指的是理解为什么你做的事情很重要
一个自主工作、理解为什么工作而且持续改进的团队也会受到积极性的激励
致力于高效的组织会以全面的成长思维来看待软件项目的目的
让每个开发人员直接接触真实的用户——系统真正的使用者
将开发人员暴露给用户与“自主、专精和目标”的目标部分有着很强的相互促进作用

分布式团队效能与个人发展策略

人们良好的团队合作能力受沟通技能的影响
当在个人发展方向和角色之间取得平衡时，团队往往表现卓越
卓有成效的软件开发的一个原则是尽可能加强反馈循环
成员位置分散的团队减弱了反馈循环的效果
减弱反馈循环是我在分布式团队里看到的最大问题
分布式团队的最佳实践与敏捷团队的最佳实践总体上是相同的
信任的半衰期是6周
康威定律认为一个系统的技术架构反映了构建这个系统的人员组织的结构
将团队视为黑盒的管理准则支持管理者更多地作为设定方向的领导者
将软件质量维持在可发布水平是高纪律性的实践
为了让地理上分布的团队成功，强调正向看待错误的原则很重要
个人和互动高于流程和工具
最大化个人能力应该是任何旨在提升组织效能的计划的基石
支持员工发展挖掘了专精的激励力量
大多数软件从业人员的职业发展就像是弹球——逐个项目跳动
高素质软件从业人员需要在技术知识、软件开发实践知识和领域知识上具备很强的能力
专业发展阶梯为每个软件从业人员提供了一条稳步提高专精水平的清晰道路

敏捷团队沟通与高效项目管理

敏捷开发需要面对面的协作，因此无摩擦的沟通在敏捷开发中比在顺序开发中更为重要
明星员工和一般员工之间的差异90%可以归因于情商
RULER模型：察觉、理解、标识、表达和调节情绪
技术人员常常需要明确的指示和鼓励来调整他们的沟通风格以适应他们的听众
关键对话方法适用于利害关系很大、看法各异、情绪强烈的情形
你的脑袋里全是自己的问题，而且你有一整天去解决它。你老板只有7分钟的空闲，而且只记得住3个要点
团队发展模型的四个阶段：组建期、震荡期、规范期和执行期
项目越大，准时交付的概率越低、项目超支的概率越高、失败的风险也越高
项目越大，错误率（潜在缺陷率）就越高
项目越大，人均生产率越低
从各个方面看，交付速度比交付范围更重要
短sprint减少了中途需求，提升了对新需求的响应力
短sprint为顾客和利益相关者提供了更高的响应力
短sprint能建立起利益相关者的信任
短sprint通过频繁的“检视—调整”循环促进团队能力提升
短sprint能提升团队的责任感和团队成员的责任感
短sprint能鼓励自动化和带来更频繁的成就感
基于速度的计划使用故事点和速度共同来计划和追踪工作

垂直切片交付与技术债管理

垂直切片指的是在架构的每一层都做出修改，以渐进地交付功能或价值
垂直切片对非技术的利益相关者来说往往更易理解，更可感知，也更容易评估其业务价值
专注于水平切片的团队则可能一头扎进几个sprint才能交付的泥潭里，未能提供可观测的业务价值
垂直切片能将功能更快地推送到用户面前，从而能为功能的正确性提供更快的反馈
垂直切片需要贯穿所有技术层面的开发工作，因此它能促使团队一起检验设计和实现时做出的假设
技术债指的是过往积累的低质量工作对当下工作进展造成损害的现象
如果允许技术债不断累积而没有管理债务的计划，最终损害的将是团队的速度
技术债在技术方与业务方的交流讨论中是一个很好的隐喻
布鲁克斯法则：在软件开发后期，添加人力只会使项目开发得更慢
康威定律：一个系统的技术架构，反映了构建这个系统的人员组织结构
对大型敏捷项目来说，一个大型系统的理想架构应当能够支持将不同团队间的工作完全分割开
架构的基石：松耦合、模块化
避免使用单体数据库有助于实现团队分离
使用队列进行解耦或者时移的方式同样可以帮助实现开发团队间的松耦合
采用契约式设计来消除工作流中技术依赖带来的影响

大型项目协作挑战与敏捷质量测试原则

项目越大，对需求、架构、配置管理、质量管理/测试、项目管理、流程等非编码活动的需要就越多
最常见的挑战是需求，大型项目中最常出现协作问题的领域按频率排序为：需求、架构、配置管理/版本管理、质量管理/测试、项目管理、流程
使用评分卡评估大型敏捷项目，关键类别包括需求、架构、质量管理、测试、项目管理、配置管理与部署，得分应在7分以上以确保成功
从小项目开始向上演进，往往比做成大型项目再向下拆解更加容易
Scrum of Scrums（SoS）错误地推荐Scrum Master作为代表，而经验表明最常见的协作挑战源于需求，因此产品负责人参加协调会议作用更大
SAFe需要精心裁剪，落地时更倾向于工具集而非高度集成框架，推荐从Essential SAFe开始
缺陷检测和缺陷消除是一类特定活动的职责，即质量保障（QA）活动
运转良好的项目能最小化缺陷引入与缺陷检测之间的差距，从而更快、更低成本地交付
完成定义（DoD）应确保工作达到可发布水平，避免描述活动而非结果（如“代码已经经过评审”应改为“代码已经经过代码评审并得到认可”）
团队可能需要多种或多层完成定义，但需警惕“完成”并不真的意味着完成的风险
将质量维持在可发布水平能缩小缺陷差距，支持项目计划和追踪，避免技术债累积
返工包括bug修复、需求理解有误等，度量返工工作量是减少返工的有效方法
结对编程的产出与单独工作总和相当，但质量更高、速度更快，但多数开发人员不喜欢全面采用
敏捷测试强调开发人员做测试、测试前移、自动化测试，以及测试作为细化需求和设计的手段
开发团队应编写自动化测试，集成到构建/部署系统，并包含在故事点估算中
遗留环境测试自动化应从最常改动的代码开始，逐步补齐，而非追求稳定代码的覆盖率

敏捷测试与需求开发核心要领

开发人员对自己工作的质量负有主要责任，其中就包括测试工作
待办事项总是在接近sprint结束时才完成（这暗示测试工作是在编码之后发生而不是同时进行的）
对新的代码库来说，达到70%的单元测试覆盖率是有益且可行的目标
团队领导者需要与团队沟通，传达测试和质量保障与编码工作同等重要的信息
测试代码应该遵循和产品代码一样的代码质量标准
团队应该将阅读和维护测试套件视作开发过程中的必要工作
验收测试通常是在一个单独的QA环境里运行的，因为QA环境通常更稳定一些
在宣布sprint完成之前，请确保团队已经进行了足够的系统级别的测试
敏捷项目上最常见的挑战是好的产品负责人的缺失
需求变质带来的浪费与预先完整地定义需求可能带来的任何价值相比都要高
故事是一份可追溯的文档，用于记录业务人员和技术人员之间发生的对话
待办事项列表细化不充分可能给敏捷团队带来一系列的严重问题
团队可以根据这些要点制定自己的就绪定义，让待办事项在下次sprint计划会议之前得到充分的细化

敏捷需求与交付的核心实践

需求一直以来都是一个棘手的问题。敏捷在制定需求活动准则方面贡献了许多有用的实践，但这并未改变高质量需求的重要性。
在敏捷开发中，定义糟糕的需求带来的痛苦感被更频繁地分散到整个项目的进程中、分散到更小的功能增量上。
团队如果发现有误解用户故事的现象发生，就应该考虑投入专门的精力来提升团队的需求技能。
软件需求如今已是一门得到充分发展的学科，并且有很多好的技术实践。
敏捷开发强调的一个关键实践就是按照业务优先级从高到低的顺序进行功能交付。
一位有成效的产品负责人对应用、行业，以及对产品所服务的顾客群应该了如指掌。
一位有成效的产品负责人能理解要定义好适合于特定环境的需求，需要了解什么类型的细节，以及对细节掌握到何种深度。
一位富有成效的产品负责人能够帮助各位利益相关者明白，为了打造一款优秀的产品需要拥有不同的视角。
一位有成效的产品负责人能够在需要的时候做出决策。
T恤估算法是个有用的工具，它能帮你对粗粒度的功能基于大致的投资回报进行优先级排序。
在软件世界里，能够快速决定不做一件事情是有很大价值的。
故事地图是一个强有力的工具，它能帮你排列待交付故事的优先级顺序，同时还能保证一组故事可以形成连贯一致的功能。
故事地图是体现软件开发钟摆效应的一个绝佳例子：从最初完全的顺序开发，到早期的敏捷，现在钟摆又回到了一个更好的敏捷。
持续集成指的是开发人员应该频繁地向“中央仓库”提交代码，通常是每天提交好几次。
越接近交付和部署阶段的活动，越有自动化的必要，这样才能将它们交给计算机来完成。
自动化消除了不能给人带来成长的重复性工作，使人有更多的时间投入上游那些能带来成长的活动里。

CI/CD实践与敏捷领导力核心原则

为了做到完全的CI/CD，整个开发环境都需要自动化
使用CI/CD的一大好处，便是能够对不可接受的变更进行自动化检测和驳回
团队必须将保持系统处于可发布状态的优先级置于完成新工作之前
完成定义还必须包含有关单元测试、验收测试、回归测试、类生产环境部署，以及版本控制等验收标准
如果什么事情让你感觉痛苦，你就要更频繁地去做它，让痛苦感提前
缺陷能在引入的当下被很快发现，因此修复的成本降低了
发布变得非常简单，只需要点击一下按钮即可，再也不用害怕因为人为的错误而导致发布失败
高效的敏捷实施取决于敏捷与团队以及敏捷与领导者彼此之间的承诺
不要告诉人们该怎么做。告诉他们该做什么，他们会用结果使你惊喜
拒绝排优先级是领导力薄弱的表现
高效企业的目标应该是最大化吞吐量，而不是工作开始的快慢或活动的多少
培养成长思维——致力于在个人和组织层面持续改进
正向看待错误——接受每个错误并将其作为学习机会
修复系统，而不是处理个人
对团队效能最重要的影响因素是心理安全
高效的企业会度量其自身的产能，并依据该量化的、过去的历史表现来制订计划
领导者给团队施加压力，期望压力会产生业务紧迫感并促使团队进行合理的优先级排序

组织支持与敏捷度量改进

如果公司削弱了敏捷团队的努力，那么敏捷团队就不可能成功
公司打击团队的做法有很多，如责备团队犯错、不支持团队拥有自主性、不充分与团队沟通其目标，以及不允许团队持续成长等
如果公司通过建立整个组织内不责怪的文化、为团队配备所需的全部技能、给团队安排合适的工作量、定期向团队传达其目的以及支持团队持续成长等来支撑团队，团队可能会更成功
卓有成效的敏捷实施则应用度量，将定量数据纳入过程变更决策中，而不是仅仅基于主观意见进行决策
故事点是对工作项的规模和复杂性的度量
故事点一经指定，团队就不能根据实际进展情况改变故事点的估算
单个sprint的速度会波动，通常不能说明什么。平均速度随时间的变化趋势更能说明问题
即使所有团队都用故事点进行度量，将一个团队的速度与另一个团队比较也是没有意义的
返工占比（R%）是返工的工作量占新开发工作量的百分比
确保为团队优化引入一套平衡的度量，包括度量质量和客户满意，以便团队不会以牺牲其他同样或更重要的目标为代价来优化速度
卓有成效的敏捷实施专注于通过做得更好来跑得更快
Scrum不解决你的问题，但它能暴露问题的存在，以便你能看清楚问题是什么
软件生产力度量是一个敏感的话题。虽说度量不是完美的，也不是绝对可靠的，但这并不等于说度量没有用
限制在制品的作用是暴露等待时间，这是软件项目中浪费的一大来源
回顾的目的是审视sprint的进行情况，产生改进想法，评估在之前的回顾会议中确定并开始实施的改进项，以及制订下一个sprint中改进项的实施计划
如果你发现团队正在应付度量，将其作为一个正向看待错误的机会。从系统的角度看待这个行为，修复引起问题的系统

敏捷预测与检视调整实践

有效使用检视和调整要有点急性子。那些很能忍耐自己问题的团队最终会与这些问题纠缠很长时间而不做改进。
敏捷关注的是团队，而不是个人。团队层面的度量在文化上与敏捷更一致，而且也更高效。
敏捷开发的通常做法是先定下交付的时间表，然后再识别出能够在这个时间段内交付的最有价值的功能——其重点在于控制特性集的范围。
故事点之所以有用，部分归因于它们可以免受倾向性的影响。团队使用故事点来分配工作项的相对规模，而非直接估算工作量。
速度的另一个同样重要的用途是支撑预测。如果团队在过去3个sprint已经以可持续的步调工作并且每个sprint完成50个故事点（平均速度50），团队可以使用这个平均速度预测用多长时间交付全部功能。
置信区间是一个具体（且复杂）的统计计算，是对观测均值（平均值）接近实际均值的确信程度。
团队的速度绝不是纯粹用来做预测计算的工具，因为目标之一是帮助团队达到速度稳定。
使用将史诗作为详细工作预算的方法，当团队将史诗细化成详细故事时，不允许超过该史诗的55个故事点的预算。
公司需要长期预测，并不意味着它不能改变计划。
主要在复杂域运作的项目的主要关注点是进行探查以确定要解决问题的本质。
《敏捷宣言》描述的最初价值之一是客户协作。如果你是客户，而你的敏捷团队一直坚持你应当重新审视业务本身，而不是提供你要求的东西，你可能需要建议团队重新重视客户协作这条敏捷价值观。

受监管行业的敏捷实践与组合管理

早期敏捷极力强调灵活性，造成了这样的印象：敏捷实践不适合受监管行业，如生命科学和金融。
随着敏捷的成熟，结果证明敏捷实践在许多受监管行业中与其他任何地方一样有用和适用。
笼统地说，受监管环境的软件相关要求可以归结为：在文档中列明计划，按计划执行，用文档证明执行完毕。
生成文档的效率可能是在受监管环境中采用敏捷实践最重要的考量点。
敏捷实践并不会让受监管产品的工作更困难或更简单。有关敏捷实践的文档是更大的关注点。
美国联邦法规通常不要求特定的软件开发方法或生命周期。他们只要求企业选择一种方法、定义好方法细节并记录到文档中。
在不受监管的敏捷方法中，多数活动会非正式地进行文档化。对受监管环境中的敏捷方法，活动要更正式地进行文档化。
文档成本是受监管软件开发中的一个相当值得关注的问题，将敏捷边界概念应用到软件开发活动可能是有帮助的。
目标不是要敏捷。目标是使用可用的软件实践来最好地支持业务。
我们与一家实施了设计可追踪性的生命科学公司合作。我们分析了哪些开发流程要求是FDA强制的，哪些是公司监管部门要求的。我们能够消除三分之一的设计文档。
加权最短作业优先的概念源于唐·雷纳森在精益产品开发方面的研究，主要用于实施SAFe的项目上，但广泛适用。
延迟成本是一个不太直观的术语，它指的是特性可用之前的机会成本。
加权最短作业优先是一种启发式方法，其用途在于最小化一组特性的延迟成本。
加权最短作业优先的规则是优先交付平均延迟成本最高的特性。
精益的一个箴言是“停止开始，聚焦完成”。
从高层角度看，敏捷实施的直观方法似乎很简单，但它遗漏了成功推广所需的重要元素。

多米诺变革模型与创新扩散

成功的组织变革需要：愿景、共识、技能、资源、激励、行动计划
如果所有元素都具备，变革就能够成功。但是，如果任何一个元素缺失了，变革就无法成功。
缺乏愿景会导致困惑
缺乏共识会导致妨害
缺乏技能会导致焦虑
缺乏资源会导致挫败
缺乏激励会导致抵触
缺乏行动计划会导致拖沓
创新者（最早的采纳者）具有冒险精神并且渴望尝试新技术或实践
早期采纳者是组织中受人尊敬的“意见领袖”
后期采纳者需要更多支持，而大多数人都属于后期采纳者。
将指挥官意图应用于敏捷实施。设定愿景（并接受员工的反馈），然后让人们自由地解决细节问题。
敏捷是一种依赖于从经验中学习的经验性方法
检视和调整。敏捷是一种依赖于从经验中学习的经验性方法
通过自主、专精和目标来激励团队
修正系统，而不是处理个人
管理结果，而不是管理细节
正向看待错误，以便团队可以毫不犹豫地将错误暴露出来

参考文献列表

AAMI TIR45 2012: Guidance on the use of AGILE practices in the development of medical device software
Beck, Kent: Extreme Programming Explained: Embrace Change
Boehm, Barry: Balancing Agility and Discipline: A Guide for the Perplexed
Brooks, Fred: Mythical Man-Month
Cohn, Mike: Succeeding with Agile: Software Development Using Scrum
Cohn, Mike: User Stories Applied: For Agile Software Development
Conway, Melvin E.: How do Committees Invent?
Crispin, Lisa and Janet Gregory: Agile Testing: A Practical Guide for Testers and Agile Teams
DORA: 2018 Accelerate: State of Devops
Forsgren, Nicole, et al.: Accelerate: Building and Scaling High Performing Technology Organizations
Goleman, Daniel: What Makes a Leader?
Humble, Jez, et al.: Lean Enterprise: How High Performance Organizations Innovate at Scale
Jones, Capers: The Economics of Software Quality
Kotter, John P.: Leading Change
Lencioni, Patrick: The Five Dysfunctions of a Team
Martin, Robert C.: Clean Architecture: A Craftsman's Guide to Software Structure and Design
McConnell, Steve: Code Complete, 2nd Ed.
McConnell, Steve: Software Estimation: Demystifying the Black Art
Pink, Daniel H.: Drive: The Surprising Truth About What Motivates Us
Poppendieck, Mary and Tom: Implementing Lean Software Development: From Concept to Cash
Reinertsen, Donald G.: The Principles of Product Development Flow: Second Generation Lean Product Development
Rubin, Kenneth: Essential Scrum: A Practical Guide to the Most Popular Agile Process
Schwaber, Ken and Jeff Sutherland: The Scrum Guide
Sutherland, Jeff: Scrum: The Art of Doing Twice the Work in Half the Time
Westrum, Ron: A Typology of Organisational Cultures