DevOps “改稻为桑” 重塑企业IT交付能力

稻：瀑布式软件开发模式。  桑：敏捷和DevOps

背景介绍

某大型制造企业的IT部门一直采用传统的瀑布式软件开发模式。尽管这种模式已经存在多年,但随着业务需求的快速变化和市场竞争的加剧,它显得越来越力不从心。部门领导Michael认识到,必须转向敏捷和DevOps的新方式,才能提高IT交付的效率和响应速度,支撑企业的业务发展。

然而,IT部门内部存在着一些资深员工,他们长期习惯了瀑布式的工作方式,并且担心DevOps转型会影响到他们的地位和利益。这些人员包括资深程序员William、资深运维工程师Daniel,以及几位项目经理Jacob。他们一直以来都在部门内占据重要地位,对内部事务也有很大发言权。

改革阻力重重

在Michael开始推动DevOps转型的时候,立即遇到了来自部门内部的强烈反对。William等人认为,现有的瀑布式模式虽然有一些问题,但毕竟已经运行多年,大家都已经习惯了。他们担心DevOps会带来大量的新工具和流程,需要大家学习适应,会增加工作负担。同时,他们担心自己多年积累的"人脉"和"经验"会因为新模式的引入而贬值。

于是,这些人开始采取各种手段来阻碍改革。比如,他们故意拖延关键信息的沟通和分享,制造信息孤岛;在会议上不断提出各种质疑和异议,试图扰乱改革进程;甚至利用内部关系网络,在背后搬弄是非,让一些员工对改革产生怀疑。

Michael意识到,要实现IT部门的DevOps转型,就必须设法说服这些顽固分子,让他们理解改革的必要性和好处。但这并不是一件容易的事情。

坚持推进改革

面对如此强大的阻力,Michael并没有放弃。他意识到,要让整个团队真正理解和接受DevOps,单凭自己的思想很难说服大家。于是他决定采取更为细致入微的方式,去了解每个人的顾虑和诉求。

Michael首先找到William,耐心地与他交流。他解释说,DevOps并非要完全颠覆现有的做事方式,而是要在保留一些有价值的瀑布式做法的基础上,融入更多的敏捷理念和自动化工具。这不仅可以提高交付效率,还能让开发和运维的协作更加紧密。对于William担心的"人脉"和"经验"贬值问题,Michael表示,只要大家主动学习适应新模式,这些宝贵的资产反而会得到更好的发挥和应用。

对于Daniel等资深运维工程师的顾虑,Michael则强调DevOps不会削弱运维的地位,反而会让他们在新的模式下发挥更重要的作用。运维工程师将不再仅仅是被动地响应变更需求,而是要与开发团队密切协作,参与整个应用生命周期的管理。这不仅可以提高系统的可靠性,也让运维工程师在交付过程中发挥更大的影响力。

通过这种一对一的交流,Michael逐步消除了部门内部人员的顾虑和担忧。他不仅耐心地解释改革的意义,还承诺会尽量保护员工的利益不受损害。

团队共建新模式

在Michael的不懈努力下,原本坚决反对改革的William、Daniel等人,逐渐开始转变态度。他们意识到,DevOps确实能带来一些积极的变化,而且只要自己主动适应,反而可以在新模式下获得更多的发展机会。

于是,Michael开始组织全体员工,共同探讨和制定DevOps转型的具体方案。他们成立了由各方代表组成的工作小组,充分吸纳员工的意见和建议。在小组的协调下,IT部门逐步制定出了切实可行的DevOps实施计划,涵盖了流程优化、工具选型、人员培训等各个方面。

在实施过程中,Michael始终保持高度透明,确保每个人都能清楚地了解改革的进展和成果。他还鼓励大家主动参与,并给予适当的激励和支持。渐渐地,原本对改革持怀疑态度的员工也开始主动投入其中,为实现DevOps转型贡献自己的力量。

最终,经过近一年的共同努力,IT部门顺利完成了从瀑布式到DevOps的转型。新模式不仅提高了软件交付的效率和质量,也增强了部门内部的协作氛围。原本反对改革的人员,现在也成为了DevOps实践的积极支持者。

结语

这个案例生动地展示了企业IT/DevOps部门在推动组织变革时会面临的重重阻力,以及领导者如何通过细致入微的沟通和协调,最终说服并团结全员,共同完成转型。关键在于领导者要充分理解和尊重员工的顾虑,并耐心地一一化解。只有在团队的共同努力下,企业IT部门才能顺利从传统模式转向敏捷和DevOps,提升自身的竞争力。

---

<图书推荐>

2024年发布的一本关于DevOps企业级持续集成与持续交付实战记录！