第二部分 从何处开始
第5章切入点
绿地项目 棕地项目
记录型项目-侧重于“做的正确”例如 ERP 人力 财务系统
交互型系统-侧重于“做的快速”例如商务 办工系统
DevOps可以有效解决这个矛盾。
1：从最乐于创新的团队开始
2：扩大DevOps的范围
（创新者、早期采用者、早期从众者、晚期从众者、落后者）避免使用“大爆炸”的方式遍地开花。
第6章理解、可视化和运用价值流
做什么工作？谁来做？采取什么措施改善流程
确定团队，价值流图可视化，创造客户价值。
工作项包括指标：前置时间、处理时间、%C/A（有效率，完成时间和精确的总花费时间的百分比（%C/A）。该指标反映了价值流中的每个步骤的输出质量）
组建专门的转型团队（不是开发团队）-负责实现明确定义的、可度量的、系统级的目标
转型团队拥有共同在目标、小跨度在改进计划、为非功能性需求预留20%，减少技术债务，提高工作可视化，
用工具强化预期行为，共享工作列表、统一工具
第7章设计组织结构
软件开发团队的结构对软件产品在架构肯成果有着巨大的影响。
职能型-专业、响应慢、价值目标不透明,有助于促进职业发展和技能发展,运维部门通常采用这种组织结构（即服务器管理员、网络管理员和数据库管理员等都被划分成单独的小组）
矩阵型-组织复杂，多领导,试图结合职能型和市场型;
市场型-扁平，存在冗余,注重快速响应客户需求.由多个跨职能的部门组成（例如市场营销部门和工程技术部门等），整个组织可能往往存在冗余现象;
以市场为导向的团队不但要负责特性开发，而且在整个应用生命周期中还要负责测试、安全、部署和生产环境的运维。
这些跨职能团队可以独立运作——能够设计和开展用户实验，构建和交付新特性，在生产环境中部署并运行服务，不依赖于其他团队就能修复任何缺陷，从而加快行动的步伐,
“两个比萨原则”保持团队规模小型化
Ticketmaster的首席技术官Jody Mulkey说：“在过去近 25 年的时间里，我一直用美式橄榄球比赛来比喻Dev和Ops。其中，Ops是防守组，试图阻止对方得分；Dev则是进攻组，其目标是尽全力得分。
而有一天，我突然意识到这个比喻并不恰当，因为Dev和Ops从来没有在同一时间出现在球场上，他们实际上不属于同一个团队!”。
他继续说道：“我现在用的比喻是，Ops是进攻内锋，Dev则负责重要位置（如四分卫或外接手）。Dev的工作是持球冲锋，Ops的工作则是保证Dev有足够的时间向前冲。”
第8章运维、日常开发
运维联络人模式-用较少的人帮助更多的团队
共享服务，提高开发生产力，运维人员融入服务团队，分配运维联络人。
以支持工程团队创新和速度为先，可以依赖工具，但不能依赖我们的劳动力。