完善敏捷操作模型
经过Alok Uniyal，哈利Keir休斯, 2019年8月|报告| 9分钟阅读|通过电子邮件发送本文|下载
现有的银行不适合敏捷的工作方式和现代软件开发操作。孤立的组织结构和低效的应用程序开发成为阻碍。为了提高软件开发效率、提高质量和降低风险，敏捷性和更快的开发必须成为新的规范。在这个由六部分组成的系列的第二篇文章中，我们将讨论一家领先的银行如何重新配置其操作模型，使其自包含的、跨功能的产品团队拥有所有权和自主权来“计划、构建和运行”创新软件解决方案。
介绍
2016年，一家领先的全球银行利用DevOps改变了其IT业务。在18个月的时间里，软件发布频率增加了40%以上，测试工作减少了70%。
在本系列的第一篇文章中，DevOps被定义为一种能够快速、敏捷地开发软件和可伸缩、可靠的操作的方法1．我们还总结了这种方法的好处。
本文介绍了传统操作模型的重新设计方式，以便Devops团队可以集中在一起进行贴心地工作。所有软件交付团队中的对话，IT运营人员和业务利益相关者必须大大变化，以确保敏捷操作模式成功2．
这一切是如何开始的
每一次DevOps转换都必须确保对IT环境的更改与总体业务目标保持一致。这些目标会成为团队领导者努力实现的改变的催化剂。
本行设想三个目标来催化它转型：
- 通过直接节约和吸收逆风实现显著的成本优化
- 其质量和服务稳定性的大量提高
- 关键绩效指标提高10%以上
该银行开发了六种能力来推动其转型
前两个能力——操作模型重新设计和企业敏捷性——是本文的重点。
需要重新设计运营模型
大多数现有的银行不适合灵活的工作方式和DevOps。在传统的组织结构中，技术工程师和其他IT角色根据业务线分组。这些业务流由用于构建和运行应用程序的服务功能支持(参见图1)。
图1.产品和服务传统上由多行业务管理的应用程序提供
通过这种设计，产品或服务（例如付款）通过多个业务组管理的应用程序提供。这种劝阻团队之间的合作，鼓励他们形成孤岛。团队觉得他们必须在自己之间提高障碍，以彼此沟通（称为“支持模型”）。
该银行招募了Infosys支持重新思考其南美操作的操作，以便它可以支持应用程序生命周期管理的Devops模型，并重新定义15个业务关键服务（覆盖100多个应用程序）。
根据Gartner的研究，组织变革是让DevOps蓬勃发展的关键:“与人相关的因素往往是最大的挑战——而不是技术。”3.
在银行，整个操作模式是重新配置的，敏捷是其新DNA的主要设计原则。
新的，改进的操作模型
新的操作模式充分利用了Devops。
随着人们在一个单位和删除筒仓中带来，Devops需要将软件开发与技术操作结合起来的软件开发实践来缩短开发生命周期。业务目标与过程的每个阶段紧密对齐。功能，修复和更新以循环方式交付，每种变化都会在它之前提高。该迭代反馈回路确保快速反馈，质量保持前部和中心。
重新设计的核心原则是，简单地说：“你跑了什么，你跑了！”每个大约15人的小型Devops团队都是创建的。
图2.在敏捷操作模式中，自治团队提供产品或服务
在图2中，每行业务都有多个敏捷团队，称为豆荚，支持函数集成到日常活动中。
这些独立的交叉功能产品团队具有完整的所有权和自主权，“计划，建立和运行”为业务创新解决方案。支持人员不再具有票务系统和操作级别协议等障碍。相反，他们是Devops团队的一部分。通过积极参与申请的生命周期，支持人员在团队的成果中拥有共同所有权，这鼓励合作和最终责任。
什么是豆荚？
- 自给自足和自我可持续的敏捷团队，拥有自主权来构建和运行其产品或服务，以及其性能的完整问责制
- 跨功能和跨技术资源集体努力实现Sprint和释放目标（Sprint和释放是与敏捷工作方式相关的术语）
- 由10-20人组成，具体取决于所提供的应用程序或服务的复杂性和数量
- 通过业务开发、测试和操作的全包结构，以无缝的方式驱动DevOps模型
- 与在多个项目或应用积压工作的多个项目团队相比，团队在单一的集成产品积压上工作
图3。由15人组成的多样化和熟练的团队交付与敏捷工作方式一致的产品
这些敏捷的、多技能的、自我管理的团队每天为了共同的目标一起工作。
对业务结果的关注从敏捷团队开始就根深蒂固。这允许产品所有者以一种具有商业意义的方式交付DevOps的价值，在持续的基础上细化团队对客户价值的理解，以发展能力，并进一步支持组织变革4.．
由于团队包括业务和技术的人，因此工作流程和沟通变得更加透明。对产品或服务的内在理解也会发展。
在一系列Sprint中建立和将所有内容固定在一起加速客户反馈并降低摩擦，成本和风险。
操作 - AS-服务作为新的正常
开发和运营在传统的操作模型中不重叠。一个团队设计，开发和测试应用程序或服务，另一组的个人管理运营和基础架构组件。
使用操作即服务(Operations-as-a-Service, OaaS)，软件环境将自动部署到生产环境中。OaaS还监视和维护系统，在需要时应用补丁和安全更新。
通过新的敏捷操作模型到位，操作工程师（参见图3）执行由传统模型中的运行和运营团队管理的任务和活动。
敏捷团队的集成产品积压会带来监测，事件解决，问题调查和配置管理等任务。然后，产品所有者优先考虑操作工程师完成的这些任务。
成熟的敏捷团队
一个成熟的团队是高度敏捷的，主要是通过产品所有者展示高层次的业务参与。这种水平的协作是不容易实现的，个人可能需要好几个月才能学会有效地一起工作。
银行利用纪律处分敏捷框架来帮助促进这一工作文化。此框架为团队级别提供了轻量级指导的蓝图。随着目标和目标在整个过程中是透明的，队伍被驱使成功。每个Sprint的进度通过KPI统称来统称，例如增加部署频率，增加的部署成功率和恢复（MTTR）的更快平均时间。
在银行企业内的敏捷团队中提供了Kanban和Scrum交付方法，团队可以选择最合适的交付方法 - 甚至是多个交付模型的组合（例如，扰流）。
操作模型如何发展？
精心挑选的银行员工和Infosys的敏捷DevOps专家组成了项目部署团队。每个团队成员都具有专业知识、经验和转变银行文化的敏捷性元素，能够适应复杂的环境。
图4。银行工作人员遮蔽了Infosys团队学习和优化敏捷方式的工作方式
基于各自的知识领域选择了外部团队：敏捷教练，Devops自动化专家，测试自动化专家，KPI顾问和服务管理专家。每个领导人或专家都是由自己的工作流程任务，帮助银行成员通过遮蔽和在职学习来学习绳索。
这种结构使转换能够快速进步并注入整个团队的新方法。该团队的扩展成员也很快就讨论了新的工作文化。这最终帮助维持转型帖子Infosys退出。
操作模型中的真正敏捷性需要Devops哲学来扎根。这被证明为合作和交叉功能思维，必须嵌入日常活动中。
在公司内部支持长期转型的公司内，还必须有愿意失败，并在公司内的主要利益相关者。不幸的是，由于Devops转型开始（该系列中的第5条描述了这一点，这不是银行的情况。
Devops不是对运营模式的一次性重新思考，而是一种连续提高文化和能力的变化。
考虑到这一点，不要创建一个单独的Devops团队，与组织的其他部分分开工作。孤岛应在其内删除孤岛，因为DevOps推出，并且商业领导应该投入过程的结果5.．
下一篇文章查看此操作模型中使用的Devops工具框架。介绍了Devops作为实践的概念，以及渐进式Devops工具，可提高代码审查质量。
参考
- https://www.infoworld.com/article/3215275/what-is-devops-transforming-software-development.html
- https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/beyond-agile-reorganizing-it-for-faster-software-delivery.
- https://www.gartner.com/smarterwithgartner/the-secret-to-devops-success/
- 同i
- https://blog.turbonicic.com/blog/on-technology/implement-devops.
