第一节 敏捷软件开发
敏捷早于devops
适用于DevOps的软件工程方法
·DevOps，开发运维一体化。
·DevOps思想，部分起源于一些运维工程师借鉴敏捷软件开发思想。
·DevOps的早期活跃分子很多来自敏捷社区。
·当前公认的适合于DevOps的软件过程方法是敏捷软件开发（包括Scrum、eXtreme Programming、Kanban等），尤其是敏捷软件开发中的Kanban（看板）方法。
·Scrum
·eXtreme Programming（XP）：极限编程
·Kanban
敏捷软件开发介绍
·2001年，17位软件开发领域的领军人物在美国发布了敏捷宣言，之后敏捷软件开发作为一个软件开发模式和价值观在全球软件开发人员中广为传播。
·现在敏捷软件开发已经成为主流软件开发方法。
·敏捷软件开发是当前公认的应对模糊需求、快速变化需求的最佳软件开发方式。
敏捷软件开发宣言
我们一真在实践中探寻更好的软件开发方法
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
需求文档
测试文档
设计文档
架构文档
敏捷软件开发历史
敏捷 精益
Lean Startup（精益创业）
敏捷软件开发知识体系
第二节 看板（Kanban）方法
看板历史
看板方法，由David Anderson创立。
看板（Kanban）（大写字母“K”开头）方法指的是自2006-2008年间在Corbis公司涌现的渐进增量式的过程改进方法学。
Kanban有时也指具体的看板实践或工具，这时可以配合其它敏捷方法使用。
看板（kan-ban）（小写字母开头）是一个日语词汇，英文字面意思是“信号卡”（signal card）。
在2018年4月9日发表的12thAnmual State of Agile中，受访者中采用Kanban方法的占5%，结合其它敏捷方法把Kanban当做一个实践的占65%（排在所有敏捷实践的第8位）。
看板方法的核心实践
1.可视化工作流程。
2.限制进行中的工作（WIP，work-in-progress）。
可视化工具一白板
使用白板，物理白板（信息辐射器）。也可以使用电子系统（电子冰箱），但大多数团队不使用。
放在团队成员非常容易看到的地方，比如研发团队所在房间墙上。
可视化是敏捷软件开发非常重要的一个实践和优势，在12thAnnual
State of Agile中，在采用敏捷带来的好处中Project Visibility排在第二位（66%）。
看板例子
·使用白板
·1、为每个工作项建立一个记事贴
·2、用列映射团队工作流
·每列标识工作流的一个部分（每个团队不同）
·应当包含工作所有阶段，从工作进入到工作离开团队
·PDCA（Plan-Do-Check-Act），检视并调整
·通过可视化工作流，可以看到
·工作状态
·潜在的问题，工作是否有阻塞，或者有人员闲置
一旦所有的工作显示在白板上，信息传递给所有人，可以极大的降低沟通交流成本。
白板上的记事贴一工作项
常见的属性为
·工作项描述
·电子系统中的唯一标识
·完成期限
·谁在处理这个工作项
·工作类型（比如bug或者常规工作）
尽可能保证每个工作项的工作量不要偏差太大（比如都在3人天左右）
从卡片上你可以
·看到工作项的进展状态
·能够决定下一步如何处理
限制在制品
在制品（WIP，Work in Progress）是同时进行中的工作数量。
减少在制品使其快速流过整个工作流，可以使前置时间缩短。
·前置时间是指处理一个工作项从开始到结束所经过的时间。
限制每列中卡片的数目。
硬币传递游戏说明限制在制品原理（1）-规则
4个人（共8人）围着桌子坐下来，其他人分别选择一个坐下的同事站在其身后，并掏出手机打开计时器。
有20枚硬币。每个人要把所有硬币翻一遍，然后传递给下一个人。当所有人都翻过所有硬币之后，他们就完成了工作，并交付给了客户。
“我来作为客户，为整个工作流计时。我会记录两个时间，一个是第一枚硬币到达我这里的时间，一个是所有20枚硬币到达我这里的时间。"
我们会玩三轮这个游戏，第一轮的规则是每个工人需要把所有20枚硬币翻完后传递给下一个工人；第二轮每次翻5枚硬币；第三轮每一批次翻1个硬币。
硬币传递游戏说明限制在制品原理（2）-结果
硬币游戏分析
我们不再关注是否每个工人的工作都是最有效率的；关注团队。
在最后一轮中，前置时间是最短的，但每个工人的工作时间都延长了，从个人来看效率下降了，但整个团队的效率最高。
经验法则如下：
·在制品规模高会有工作闲置（有一些硬币没有人翻，在等人）
·在制品规模低会有人要闲置（人等工作）
在制品规模大小可以不断调整到团队适应的情况。
取中间值
1.可视化工作流程。
2.限制进行中的工作（WIP，work-in-progress）。
看板示例
第三节 精益
精益思想（Lean）
精益起源于日本丰田公司的“TPS”（丰田生产方式）。
敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业，敏捷起源于软件开发。
精益软件开发原则：
·消除浪费、增强（不断）学习、尽量延迟决定（因为早期得到的消息较少，延迟可以使决定的正确性提高）、尽快发布（交付）、下放权力（给团队授权）、内置完整性（客户对产品体验的一致性）、全局优化
识别浪费、消除浪费
任何不能为客户增加价值的行为即是浪费：
·创建不必要的功能和产品
·需求管理不当（重复的工作、低价值需求、bug修复速度慢）
·返工Rework（已交付工作没有正确完成，质量问题）
·不必要的复杂解决方案（超出需求的复杂方案）
·过度认知负担（技术债务、有问题的工具、遗留代码缺乏优化等）
·心理压力（团队人员冲突、士气低落、上级压力等）
·等待/多任务（互相等待、不断进行工作内容切换）WIP
·知识丢失（人员变动、知识孤岛）
·无效沟通（大团队、不完全、不足够的沟通）可视化Kanban
·（Sedano，Todd &Ralph，Paul & Peraire，Cecile.（2017）.Software Development Waste.）
总结
- 敏捷软件开发是2000年后出现的一种新的研发方法，它能够很好的应对快速变更、模糊的需求。
- 敏捷软件开发知识体系包含价值观、原则、方法、实践和工具。
- Kanban可以作为一种敏捷方法，其核心实践为可视化看板、限制在制品。
- Kanban也经常作为一种实践和工具，成为其它敏捷方法的一部分。
- 精益是一种和敏捷对应的价值观。精益软件开发是精益思想在软件开发领域的应用，其中发现浪费、消除浪费是很重要的一种原则。
Anderson, David J.(April 2010). Kanban: Successful Evolutionary Change for Your
Technology Business. Blue Hole Press. ISBN O-9845214-0-2.
Marcus Hammarberg and Joakim Sunden.2014. Kanban in Action (1st ed.). Manning
Publications Co., Greenwich, CT, USA.
Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile
Toolkit. Addison-Wesley Professional. ISBN 978-0-321-15078-3.
Sedano, Todd & Ralph, Paul & Peraire, Cecile.(2017). Software Development Waste.