文章目录
DevOps基础理论
在提到DevOps的时候都会提到敏捷和精益,敏捷和精益不是新的概念,它在很多行业中都已被广泛实践。下面便详细阐述一下敏捷和精益的背景及基础。
1.敏捷理论体系
敏捷,在企业实践过程中出现了各具特色的敏捷模型,如XP、TDD、DSDM、自适应软件开发、水晶系列、Scrum等。并在2001年2月中旬提出一种全新的软件开发价值观"敏捷软件开发宣言",其内容为:
我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立如下价值观:
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
也就是说,尽管右项有其价值,我们更重视左项的价值。
1. 敏捷的三大支柱
敏捷范围管理的主要特征在于,在一部分范围明确需求后(具备前期几次迭代的功能需求后),就开始架构设计具有不完全范围的解决方案。在迭代过程中,不断向产品的需求列表中添加新特性,并从客户那里收集反馈,以便更好地理解客户的想法,不断完善现有产品的功能,这是自适应生命周期的主要特征之一。
其中敏捷有三大支柱:分别是透明度、可检验、自适应。
- 透明度: 所谓透明度就是指团队内部不应该有秘密的小团队,不应该有秘密的日程,也不应该有其他什么秘而不宣的事情。透明度高、注重信息分享的团队工作默契程度高,效率会明显提高。
- 可检验:指的是在开发过程中经常性地停下手中的工作,对已经取得的成果进行检查,看看这些成功是否是自己期待的,想想有没有更好的方法来改进。
- 自适应:当团队或个体,有权利决定如何做、怎么做时,完成后发现未达到最终预期,便开始进行团队或个人中的自我调整,完成预期结果。这种调整和检验便形成了一个良好的循环,即自适应。
2. 敏捷的四大核心价值观
四大核心价值观是敏捷宣言中所传递出的重要信息,即:
- 个体和互动高于流程和工具:管理层习惯将管控体系想象成超级复杂的机器,并认为拥有完美的流程和工具就会带来美好的结果。其实不然,IT产品实现过程是无形的,是技术人员你的智慧、知识和经验创造的。敏捷提出,要更关注人的绩效和能力的提升,形成团队成员默契愉快的合作关系。
- 工作的软件高于详尽的文档:详尽的文档反而加重了项目的负担,但并不是文档没有意思,而是转换成另一种方式,比如:交给运维团队的操作手册使用录制视频等等。
- 客户合作高于合同谈判:要与客户建立长期的合作关系,愿意在项目开发过程中随时按照客户的要求进行更改。
- 响应变化高于遵循计划:在现在这个市场和环境的多变下,不能基于预测式的项目管理框架,因客户的想法是不断浮现出来的,我们应该使用一个自适应的生命周期,使我们的规划和计划逐步完善。
3. 敏捷的12条原则
四大核心价值观在实践中能够起到引导作用,但是具体实践的时候需要进一步细化,由此引入了12条原则,如下:
- 我们最重要的目标是通过持续不断地较早交付有价值的软件使客户满意。(关键在于开发期间和客户密切合作,产品管理是确保客户需求在开发期间能被正确理解的关键)
- 欣然面对需求变化,即使在开发后期也一样,为了获取竞争优势,敏捷掌控变化。(我们要乐于接受变更需求,因为每一项变更都离客户真正的需求更近了一步)
- 经常地交付可工作的软件,相隔几星期或一两个月,最好采用较短的周期。
- 业务人员和开发人员必须相互合作,项目进行中的每一天都不例外。
- 激发个体的斗志,以他们为核心搭建项目,提供所需的环境和支援,并加以信任,从而达成目标。(开发过程更是一种创造过程,在激发个人的斗志和创造力中,个体的自主性是关键因素。人在受到尊重并有权决定自己的工作方式时通常工作得更好。每次冲刺要设定团队明确的目标和范围,角色职责清洗,形成自组织)
- 不论团队内外,传递信息效果最好、效率最高的方式是面对面交谈(团队甚至客户,最好以一种面对面的交谈方式沟通,此沟通方式为"渗透式"沟通,如果无法和客户进行面对面,可借助现代工具,比如聊天群,并且在日常例会时同步任务进展和问题)
- 可运行的软件是进度的首要度量标准。
- 敏捷倡导可基础开发。责任人、开发人员和用户要能够共同维持开发步调稳定可持续。(每天上班打开不是真正的目标,实现产品交付才是目标,加班看似让流程变的更快,但事实上,会降低生产率并增加产品缺陷)
- 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
- 以简单为本,极力减少不必要的工作量。
- 最好的架构、需求和设计出自组织团队(一些前置、架构和设计是必要的。架构师和系统工程师是管理研发团队的一部分,不要成为"孤岛")
- 团队定期地反思如何能提高成效,并依次调整自身的举止表现。
2. 敏捷与DevOps
敏捷已成为DevOps非技术实践的标配。
1. DevOps文化转型
DevOps文化转型就是要改变人们的思维方式,从而改变组织的文化。成长型思维对理解敏捷和DevOps是十分有帮助的。
成长型思维:
- 快速失败
- 拥抱挑战
- 持续改进
- 基于持续反馈对规划不断调整
2. 以人为本
敏捷团队和DevOps团队要建立一种高度信任的工作框架。在此基础上人们的沟通非常顺畅,一起办公,一起开例会,的贡献都是透明的。
3. 聚焦客户价值
要着手于优先级最高的任务,让团队成员了解每次迭代的目标和范围,消除软件开发过程中的浪费,交付完成的系统,及时收集客户的反馈。
4. 挑战与对策
- 管理人员要有开放的心态,敏捷转型会涉及各角色工作方式的变化,如需求设计的变化、组织结构的变化、绩效引导的变化、组织文档的变化,这是一个系统工程,需要以上而下的推动力。
- 要想获得客户和业务部门的认可,冲刺期间的需求和解决方案尽量不要发生变更,变更的需求也要尽量纳入新的迭代,或者缩短迭代周期使用客户变更。
- 保持团队的专注度,避免外部事物对开发团队的频繁干扰。
- 要控制敏捷会议时间。
- 重承偌,维护与客户之间的承偌和团队成员之间的承偌。