中国速度之二神山建设(4):全能运维,召之即来,来之即战 - 行业资讯

内容DevOps案例深度研究第4期 – 火神山雷神山 DevOps实践研究战队（本文只展示部分PPT及研究成果，全程视频请移步文末）
本案例内容贡献者：赖泽薇、张扬、邓茜芸、韦一、刘德权、候利涛、冯利娟、常相宇、张力、韩丰、陈浩
IDCF指导老师：王立杰、许舟平、姚冬、徐磊

（图片来源于网络）

一、中国速度，为瀑布站台

我们看一下火神山雷神山建设的整体过程，它是典型的瀑布模式。主要体现在阶段定义清晰、顺序串行开展，前期规划驱动，交接棒式进行，上一个阶段的输出是下一个阶段的输入。由于前期在时间、范围和成本方面做了强力的约束，那么在进行中不接受变化，因为变更代价巨大。

在上世纪60年代软件危机爆发之后，软件行业继续找到一种科学体系化的方法来进行软件开发，最早的瀑布模型就是来自于工业制造和建筑建造的模式。

但是为什么在我们的软件领域，要从起初瀑布模式往敏捷模式演进？因为软件开发不确定性更多，需要快速应对变化的需求，业界对研发模式方面也在不断地探索，如何提升效率、提高软件质量。常见的几个模型有瀑布、螺旋、迭代、敏捷。

其特点主要表现为：

瀑布式开发：顺序开展、文档驱动。要求每一个环节的工作尽可能充分讨论、论证，减少施工风险，减少返工。
螺旋开发：开始将瀑布开发的模式进行粒度的拆分，将整个开发过程划分为一个个阶段，在每个阶段引入风险分析。它是风险驱动的方法体系，在每个阶段之前，都必须进行风险评估，使软件在无法排除重大风险时有机会停止，以减小损失。但螺旋开发更倾向于是增量开发方式，它将整个软件功能的开发拆分为多个可控的阶段，最终的软件交付还是在最后一步。
迭代式开发：在螺旋开发之上出现了先保证能用，再想办法让它好用。不要求每一个阶段的任务做的都是做到尽善尽美，而是根据优先级来交付高价值的功能。以最短的时间构建一个 MVP，交付给客户之后，再通过客户或用户的反馈，逐步进行完善。
Scrum框架：是一个包含增量和迭代的框架。强调固定周期、固定节奏、强调团队协作，强调质量、强调成果可发布，能快速被验证。

那么我们如何选择这些模型和框架？

其实对于简单域，我们更推荐瀑布模式。因为需求明确、范围清晰、周期确定的情况下，瀑布也可以很快。只需要强有力的执行计划、不断提升技术，自动化一切，有效的沟通，团队赋能就可做到快速交付，而无需反复验证确认。

但是有个问题是，软件开发往往是一个繁杂或者复杂的过程，因为需求是不断变化的。尤其是对于创新型的业务应用，在一开始的时候只是一个商业想法，构建业务应用也是为了快速验证这个想法是否可行，这是一个不断假设和验证的过程。在这样的场景下，敏捷模式是更合适的。

其实我们很多人都忽略了敏捷宣言的最后一句话，往往最后一句话也是最重要的。这句话是“也就是说，尽管右项有其价值，我们更重视左项的价值。” 它想表达的是尽管瀑布价值有其价值，但是我们更重视敏捷开发的价值，这是一种价值观的取舍。所以很多时候瀑布和敏捷会存在融合。