早期,软件开发并没有真正归属于特定的管理范畴。然后出现了 瀑布模型,它表明软件开发可以通过应用程序创建或构建所需的时间长度来定义。
那时,创建、测试和部署软件通常需要很长时间,因为在开发过程中没有检查和平衡。结果是软件质量差,存在缺陷和漏洞,并且未能按时完成。重点是软件项目的长期、冗长的计划。
瀑布项目一直与 三重约束 模型相关联,该模型也称为项目管理三角形。三角形的每一边代表项目管理三重约束的一个组成部分:范围、时间和成本。正如 Angelo Baretta 所写,三重约束模型“认为成本是时间和范围的函数,这三个因素以定义和可预测的方式相关……[如果]我们想缩短进度(时间),我们必须增加成本。它还认为,如果我们想增加范围,我们必须增加成本或进度。”
从瀑布模型过渡到敏捷开发
瀑布模型源于制造业和工程,在这些领域,线性流程是有意义的;你在建造屋顶之前先建造墙壁。同样,软件开发问题也被视为可以通过规划来解决的问题。从开始到结束,开发过程由路线图清晰地定义,该路线图将引导最终产品的交付。
最终,瀑布模型被认为是软件开发的有害且违反直觉的模型,因为通常情况下,直到项目周期的最后才能确定价值,并且在许多情况下,项目都失败了。此外,客户直到项目结束才能看到任何可用的软件。
敏捷开发采用不同的方法,它不再计划整个项目,不再承诺估计的日期,也不再对计划负责。相反,敏捷开发假设并拥抱不确定性。它围绕着响应变化而不是匆忙过去或忽视变化的需求而构建。相反,变化被认为是满足客户需求的一种方式。
敏捷价值观
敏捷开发受敏捷宣言管辖,该宣言定义了 12 项原则
- 满足客户是首要任务
- 欢迎不断变化的需求,即使在开发后期也是如此
- 频繁交付可用的软件
- 开发人员和业务人员必须协同工作
- 围绕积极主动的人员构建项目
- 面对面沟通是传达信息最有效和最高效的方法
- 衡量成功的主要标准是可用的软件
- 敏捷流程促进可持续开发
- 坚持不懈地关注技术卓越和良好的设计
- 简洁至关重要
- 最佳架构、需求和设计来自自组织团队
- 定期反思工作,然后调整和改进行为
敏捷开发的四个 核心价值观 是
- 个体和互动胜过流程和工具
- 可用的软件胜过全面的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
这与瀑布模型的僵化计划风格形成对比。在敏捷开发中,客户是开发团队的成员,而不仅仅是在开始时(制定业务需求时)和结束时(审查最终产品时,如瀑布模型中)参与。客户帮助团队编写 验收标准,并在整个过程中保持参与。此外,敏捷开发要求整个组织进行变更和持续改进。开发团队与其他团队(包括项目管理办公室和测试人员)合作。完成什么以及何时完成由指定的角色领导,并由整个团队协商同意。
敏捷软件开发
敏捷软件开发需要适应性计划、迭代开发和交付。许多软件开发方法、框架和实践都属于敏捷的范畴,包括
- Scrum
- 看板(可视化工作流)
- XP(极限编程)
- 精益
- DevOps
- 特性驱动开发 (FDD)
- 测试驱动开发 (TDD)
- 水晶方法
- 动态系统开发方法 (DSDM)
- 自适应软件开发 (ASD)
所有这些方法都可以单独或组合使用,用于开发和部署软件。最常见的是 Scrum、看板(或称为 Scrumban 的组合)和 DevOps。
Scrum 是一个框架,团队(通常由 Scrum Master、产品负责人和开发人员组成)在该框架下以跨职能和自我指导的方式运作,以提高软件交付速度并
为客户带来更大的商业价值。重点是以较小的 增量 进行更快的迭代。
看板 是一种敏捷框架,有时称为工作流管理系统,可帮助团队可视化其工作并最大限度地提高效率(从而实现敏捷)。看板通常由数字或物理板表示。团队的工作在板上移动,例如,从“未开始”到“进行中”、“测试”和“已完成”,随着工作的进展而变化。看板使每个团队成员都可以随时查看所有工作的状态。
DevOps 价值观
DevOps 是一种文化、一种心态、一种软件开发或基础设施的方式,以及一种构建和部署软件和应用程序的方式。开发和运维之间没有隔阂;他们同时工作,没有孤岛。
DevOps 基于另外两个实践领域:精益和敏捷。DevOps 不是公司内的职位或角色;它实际上是组织或团队对持续交付、部署和集成做出的承诺。根据 Gene Kim,《凤凰项目》和《独角兽项目》的作者,有三种“方式”定义了 DevOps 的原则
- 第一种方式:流动原则
- 第二种方式:反馈原则
- 第三种方式:持续学习原则
DevOps 软件开发
DevOps 不是在真空中发生的;它是一种灵活的实践,在其最真实的形式中,是围绕软件开发和 IT 或基础设施实施的共享文化和心态。
当您想到自动化、云、微服务时,您会想到 DevOps。在一次 访谈 中,《加速:构建和扩展高性能技术组织》的作者 Nicole Forsgren、Jez Humble 和 Gene Kim 解释说
- 软件交付性能至关重要,并且对组织成果(例如盈利能力、市场份额、质量、客户满意度和实现组织和使命目标)具有重大影响。
- 高性能者实现了吞吐量、稳定性和质量的水平;他们不会为了实现这些属性而进行权衡。
- 您可以通过实施精益、敏捷和 DevOps 剧本中的实践来提高绩效。
- 实施这些实践和能力也会对您的组织文化产生影响,而组织文化反过来又会对您的软件交付绩效和组织绩效产生影响。
- 为了了解如何提高绩效,还有很多工作要做。
DevOps 与敏捷开发
尽管 DevOps 和敏捷开发有相似之处,但它们并不相同,有些人认为 DevOps 比敏捷开发更好。为了消除混淆,重要的是深入了解本质。
相似之处
- 两者都是软件开发方法论;这是无可争议的。
- 敏捷开发已经存在 20 多年了,而 DevOps 是最近才出现的。
- 两者都信奉快速软件开发,并且它们的原则都基于如何在不损害客户或运营的情况下快速开发软件。
区别
- 两者之间的区别在于开发之后会发生什么。
- 软件开发、测试和部署在 DevOps 和敏捷开发中都会发生。但是,纯粹的敏捷开发往往在完成这三个阶段后就停止了。相比之下,DevOps 包括持续进行的运维。因此,监控和软件开发也是持续的。
- 在敏捷开发中,不同的人员负责开发、测试和部署软件。在 DevOps 中,DevOps 工程角色负责所有事情;开发就是运维,运维就是开发。
- DevOps 更常与削减成本联系在一起,而敏捷开发更常与精益和减少浪费联系在一起,并且敏捷项目核算和最小可行产品 (MVP) 等概念是相关的。
- 敏捷开发侧重于并体现经验主义(适应、透明和检查),而不是预测性措施。
敏捷开发 | DevOps |
---|---|
来自客户的反馈 | 来自自身的反馈 |
较小的发布周期 | 较小的发布周期,即时反馈 |
专注于速度 | 专注于速度和自动化 |
不适合业务 | 最适合业务 |
总结
敏捷开发和 DevOps 是不同的,尽管它们的相似之处导致人们认为它们是同一个事物。这对敏捷开发和 DevOps 都是一种损害。
根据我作为敏捷实践者的经验,我发现组织和团队从高层次上理解敏捷开发和 DevOps 是什么,以及它们如何帮助团队更快、更高效地工作,更快地交付高质量的产品,并提高客户满意度,这非常有价值。
敏捷开发和 DevOps 绝不是对立的(或者至少意图不是如此)。在敏捷革命中,它们更像是盟友而不是敌人。敏捷开发和 DevOps 可以排外地和包容地运作,这使得两者都可以在同一空间中存在。
3 条评论