1. 从精益、敏捷、到 DevOps

什么是精益（LEAN）

指导思想：用最少的时间和资源消耗，生产出高质量的产品

瀑布模式

线性的开发流程，将软件开发划分为一系列阶段

瀑布的来源：就像水流一样，一旦落下了就没办法回头，类比开发过程，上一阶段完成后，才能进入到下一阶段

瀑布模式的局限性

缺乏灵活性

按照固定顺序的线性的开发模式，每个阶段都有明确的开始和结束时间。 这种刚性的开发流程无法适应快速的需求变化和灵活性要求

长时间交付周期

要求在进入下一个阶段之前完成上一个阶段的所有工作，导致项目的交付周期长。 如果需求发生变化或者出现问题，则可能需要回到前面的阶段

高风险

测试和部署通常在开发的最后阶段进行，这意味着问题只能在开发结束后才会被发现，这导致修复问题的时间成本会很高，增加了项目失败的风险

缺乏协作和沟通

不同团队的成员在不同阶段工作，他们之间的沟通和协作比较少，导致信息传递不畅、问题未能及时发现和解决

无法快速响应市场需求

需要等整个项目的完成才能交付产品，无法及时响应市场需求的变化，在快节奏的市场环境中，容易出现无法满足用户需求的情况

敏捷开发模式

敏捷是基于精益的思想衍生的，即在 IT 里应用“精益”的思想

• 敏捷开发是促进开发和测试持续迭代的一种实践方法
• 把开发过程拆分成 N 个敏捷开发周期（迭代周期），每个周期为 2-8 周时间
• 每个开发周期结束之后，随即交付
• “小步快跑”的开发模式

敏捷十二大原则

• 最高目标是，通过尽早和持续地交付有价值的软件来满足客户
• 欣然面对需求变化—即使在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
• 要不断的交付可用的软件，周期从几周到几个月不等，而且越短越好。
• 项目过程中，业务人员与开发人员必须在一起工作。
• 激发个体的斗志，给他们以所需要的环境和支持，并相信他们能够完成任务。
• 不论团队内外，最有效的沟通方法就是面对面的交谈可工作的软件是衡量进度的首要指标。
• 敏捷过程倡导可持续开发。发起人、开发人员和用户要能够 长期维持稳定的开发步伐。
• 对技术的精益求精以及对设计的不断完善将提升敏捷性。
• 要做到简洁，即尽量最大可能减少不必要的工作，这是一门艺术。
• 最好的架构、需求和设计出自于自组织团队。
• 团队定期地反思如何能提高成效，并相应地协调和调整自身的行为。

瀑布模式 VS 敏捷模式

敏捷的生命周期总结

敏捷项目管理

• RoadMap
• kanban
• TODO List
• 用户故事和主题
• 故事点和估时
• 燃尽图
• 甘特图
• 迭代会、站会

敏捷常见误区

• 理解和文化误区：敏捷=管理
• 缺少专业的敏捷教练或 Scrum 教练，一般由项目管理者兼任，导致敏捷工具变成管理手段
• 身兼数职导致都做不好
• 过于敏捷的进度管理：用 DDL 倒推做项目计划
• 重视进度，忽视质量，留下大量技术债

Scrum

Scrum 是一种敏捷开发框架

• 每日站会，产品迭代会都是 Scrum 的内容
• Daily Scrum、Sprint Planning、Sprint Review 分别表示每日站会、迭代计划会、迭代回顾会

Scrum 教练职责

• 每日站会
• 迭代计划会、回顾会
• kanban 管理
• One-One
• 内部咨询
• 生成报告
• 消除障碍，特别是沟通障碍
• 团队文化：鼓励、积极性
• 琐事：修电脑、工作环境、下午茶时间

敏捷开发下的运维

运维要稳定 研发要快速迭代

• 不堪重负：面对开发团队越来越多的发布次数要求，自身不堪重负
• 周末加班、通宵发版：盲目增加工作时间来提高发布次数
• 稳定性开始下降：受到工作时长、环境、团队文化的影响，线上稳定性开始出现下降
• 开始建立部门墙：运维团队 Leader 开始建立部门墙，美其名曰保证发布质量而刻意降低发布速度