2020-DevOps导论-Lec4-敏捷与精益

Lec4-敏捷与精益

1. 概述

  1. 精益与敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。
  2. Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益和敏捷软件开发里轻度重叠的三种不同风格。

1.1. 敏捷概述

  1. 术语敏捷软件开发出现于2001年。当时,来自软件开发界的十七位思想领袖聚集在美国犹他州的一个滑雪度假胜地,探讨软件开发如何取得成功。
  2. 此前,他们都各自创立了不同的新方法,如Scrum、XP和动态系统开发方法(DSDM)。
  3. 研讨会期间,他们总结出一些强大的共同观点,形成了软件开发如何成功的共有愿景,即后来人们熟知的《敏捷宣言》。

1.2. 敏捷宣言

  1. 我们正在通过亲身实践以及帮助他人实践,探寻更好的软件开发方法。通过这项工作,我们建立了如下价值观
    1. 个体和互动胜过流程和工具
    2. 可以工作的软件胜过详尽的文档
    3. 客户合作胜过合同谈判
    4. 响应变化胜过遵循计划
  2. 也就是说,虽然右项也具有其价值,但我们认为左项具有更大的价值。

1.3. 敏捷原则

  1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,要通过敏捷过程掌控变化。
  3. 经常地交付可工作的软件,比如相隔几星期或一两个月就交付,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  6. 不论团队内外,传递信息效果最好、效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  10. 以简洁为本,它是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自自组织团队。
  12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

2. 敏捷

  1. 虽然敏捷一词正式出现于2001年,但多数敏捷方法都是在20世纪80年代到90年代形成的。敏捷只是一个描述了共同特征的统称。凡遵循上述价值观和原则的方法或方式都可视为敏捷方法。
  2. 我们通过宣言可以了解2001年时的敏捷是什么意思,今天它的定义已经没有那么明确。
  3. 宣言的最初作者中,很多人希望这个术语会最终淡出历史,标志着敏捷价值观和原则已成为“我们开发软件的方式”。

3. 精益

  1. 精益起源于日本丰田公司的“TPS”(丰田生产方式),即助力丰田成为全球最成功汽车制造商的生产方式。实践证明,TPS的基本原则“丰田之道”几乎适用于所有行业,包括软件开发。
  2. 敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业,敏捷起源于软件开发。

3.1. 精益原则1-全局优化

  1. 局部的优化长期来说,会对系统整体优化不利。
    1. 专注于整体价值流:从概念到现金。从客户需求到软件部署。
    2. 交付完整产品:客户不要软件产品,他们要解决问题。完整的解决方案是由完整的团队构建的。
    3. 着眼长期:警惕导致短期思维和优化局部业绩的治理和激励体系。

3.2. 精益原则2-消灭浪费

  1. 浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下。
    1. 构建错误的功能:“没有什么比高效完成根本不应做的工作更无用。”
    2. 拒绝学习:我们有很多策略都干扰了我们学习,例如,只按计划行事、频繁移交、决策与工作分离等,而学习则是开发的精髓。
    3. 辗转现象:那些干扰价值顺利流动的做法,例如,任务切换、请求清单冗长、大堆未完成的工作等等,都只能达到事倍功半的效果。

3.3. 精益原则3-品质为先

  1. 如果在验证过程中总是能发现缺陷,那流程就有问题。
    1. 最终验证不应发现缺陷:所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷
    2. 采用测试先行的开发模式让流程具有防误机制:测试(包括单元测试、端对端测试和集成测试)必不可少,以此建立信心,保证系统在任何层次、在开发阶段任何时间点都始终正确无误
    3. 打破依赖:系统架构应当支持随时添加功能

3.4. 精益原则4-不断学习

  1. 规划工作非常有用。学习则必不可少。
    1. 可预测的性能来自于反馈:可预测的组织不会猜测未来并称之为计划;反之,他们会培养能力对未来做出响应。
    2. 保持选择方案:视代码为实验——使其具有容变性。
    3. 最后可靠时刻:在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策,也不要事后才做出决定!

3.5. 精益原则5-尽快交付

  1. 从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观,创建稳定、连贯的工作流。
    1. 快速交付、高质量和低成本是完全相互兼容的:以速度竞争见长的公司拥有很高的成本优势,他们可以交付优质的产品,而且对客户需求更为敏感。
    2. 排队理论同样适用于开发,而不仅仅是服务行业:专注于使用性会造成交通堵塞,反而降低了使用性。以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
    3. 管理工作流比管理进度表要容易得多:建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。

3.6. 精益原则6-人人参与

  1. 聪明、有创造力的人员的时间与精力,是当代经济的稀有资源和竞争优势的基础。获得公正薪资的人员在自主性、成长性和使命感等方面受到激励。
    1. 自主性:最有效的工作小组是半自治团队,有一个内部主管从头到尾负责完整、有意义的任务。
    2. 成长性:对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
    3. 使命感:将工作与价值挂钩。只有相信自己工作的意义,团队成员才会全心投入工作,实现这种使命。

3.7. 精益原则7-不断提高

  1. 结果不是重点——重点是培养人、发展体制,使之能够交付结果。
    1. 失败是个学习机会:即使是非常小的失败都会被深入调查并纠正的,做到一丝不苟的时候,才可能获得最可靠的性能。
    2. 标准存在的目的就是要被质疑和提高的:将现行的、最知名的做法纳入人人都遵循的标准,与此同时鼓励所有人质疑并改变标准。
    3. 使用科学方法:教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。

2020-DevOps导论-Lec4-敏捷与精益
https://spricoder.github.io/2020/07/02/2020-Devops-introduction/2020-Devops-introduction-Lec4-%E6%95%8F%E6%8D%B7%E4%B8%8E%E7%B2%BE%E7%9B%8A/
作者
SpriCoder
发布于
2020年7月2日
许可协议