mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge pull request #8930 from FelixYFZ/master
20180107 7 leadership rules for the DevOps age.md Translation Finished
This commit is contained in:
Vic Yu
GitHub
commit
773c4d8767
@ -1,124 +0,0 @@
|
||||
Translating by FelixYFZ 7 leadership rules for the DevOps age
|
||||
======
|
||||
|
||||
|
||||
|
||||
If [DevOps][1] is ultimately more about culture than any particular technology or platform, then remember this: There isn't a finish line. It's about continuous change and improvement - and the C-suite doesn't get a pass.
|
||||
|
||||
Rather, leaders need to [revise some of their traditional approaches][2] if they expect DevOps to help drive the outcomes they seek. Let's consider seven ideas for more effective IT leadership in the DevOps era.
|
||||
|
||||
### 1. Say "yes" to failure
|
||||
|
||||
The word "failure" has long had very specific connotations in IT, and they're almost universally bad: server failure, backup failure, hard drive failure - you get the picture.
|
||||
|
||||
A healthy DevOps culture, however, depends upon redefining failure - IT leaders should rewrite their thesaurus to make the word synonymous with "opportunity."
|
||||
|
||||
"Prior to DevOps, we had a culture of punishing failure," says Robert Reeves, CTO and co-founder of [Datical][3]. "The only learning we had was to avoid mistakes. The number one way to avoid mistakes in IT is to not change anything: Don't accelerate the release schedule, don't move to the cloud, don't do anything differently!"
|
||||
|
||||
That's a playbook for a bygone era and, as Reeves puts plainly, it doesn't work. In fact, that kind of stasis is actual failure.
|
||||
|
||||
"Companies that release slowly and avoid the cloud are paralyzed by fear - and they will fail," Reeves says. "IT leaders must embrace failure as an opportunity. Humans not only learn from their mistakes, they learn from others' mistakes. A culture of openness and ['psychological safety'][4] fosters learning and improvement."
|
||||
|
||||
**[ Related article: [Why agile leaders must move beyond talking about "failure."][5] ]**
|
||||
|
||||
### 2. Live, eat, and breathe DevOps in the C-suite
|
||||
|
||||
While DevOps culture can certainly grow organically in all directions, companies that are shifting from monolithic, siloed IT practices - and likely encountering headwinds en route - need total buy-in from executive leadership. Without it, you're sending mixed messages and likely emboldening those who'd rather push a _but this is the way we 've always done things_ agenda. [Culture change is hard][6]; people need to see leadership fully invested in that change for it to actually happen.
|
||||
|
||||
"Top management must fully support DevOps in order for it to be successful in delivering the benefits," says Derek Choy, CIO at [Rainforest QA][7].
|
||||
|
||||
Becoming a DevOps shop. Choy notes, touches pretty much everything in the organization, from technical teams to tools to processes to roles and responsibilities.
|
||||
|
||||
"Without unified sponsorship from top management, DevOps implementation will not be successful," Choy says. "Therefore, it is important to have leaders aligned at the top level before transitioning to DevOps."
|
||||
|
||||
### 3. Don 't just declare "DevOps" - define it
|
||||
|
||||
Even in IT organizations that have welcomed DevOps with open arms, it's possible that's not everyone's on the same page.
|
||||
|
||||
**[Read our related article,**[ **3 areas where DevOps and CIOs must get on the same page**][8] **.]**
|
||||
|
||||
One fundamental reason for such disconnects: People might be operating with different definitions for what the term even means.
|
||||
|
||||
"DevOps can mean different things to different people," Choy says. "It is important for C-level [and] VP-level execs to define the goals of DevOps, clearly stating the expected outcome, understand how this outcome can benefit the business and be able to measure and report on success along the way."
|
||||
|
||||
Indeed, beyond the baseline definition and vision, DevOps requires ongoing and frequent communication, not just in the trenches but throughout the organization. IT leaders must make that a priority.
|
||||
|
||||
"Inevitably, there will be hiccups, there will be failures and disruptions to the business," Choy says. "Leaders need to clearly communicate the journey to the rest of the company and what they can expect as part of the process."
|
||||
|
||||
### 4.DevOps is as much about business as technology
|
||||
|
||||
IT leaders running successful DevOps shops have embraced its culture and practices as a business strategy as much as an approach to building and operating software. DevOps culture is a great enabler of IT's shift from support arm to strategic business unit.
|
||||
|
||||
"IT leaders must shift their thinking and approach from being cost/service centers to driving business outcomes, and a DevOps culture helps speed up those outcomes via automation and stronger collaboration," says Mike Kail, CTO and co-founder at [CYBRIC][9].
|
||||
|
||||
Indeed, this is a strong current that runs through much of these new "rules" for leading in the age of DevOps.
|
||||
|
||||
"Promoting innovation and encouraging team members to take smart risks is a key part of a DevOps culture and IT leaders need to clearly communicate that on a continuous basis," Kail says.
|
||||
|
||||
"An effective IT leader will need to be more engaged with the business than ever before," says Evan Callendar, director, performance services at [West Monroe Partners][10]. "Gone are the days of yearly or quarterly reviews - you need to welcome the [practice of] [bi-weekly backlog grooming][11]. The ability to think strategically at the year level, but interact at the sprint level, will be rewarded when business expectations are met."
|
||||
|
||||
### 5. Change anything that hampers DevOps goals
|
||||
|
||||
|
||||
While DevOps veterans generally agree that DevOps is much more a matter of culture than technology, success does depend on enabling that culture with the right processes and tools. Declaring your department a DevOps shop while resisting the necessary changes to processes or technologies is like buying a Ferrari but keeping the engine from your 20-year-old junker that billows smoke each time you turn the key.
|
||||
|
||||
Exhibit A: [Automation][12]. It's critical parallel strategy for DevOps success.
|
||||
|
||||
"IT leadership has to put an emphasis on automation," Callendar says. "This will be an upfront investment, but without it, DevOps simply will engulf itself with inefficiency and lack of delivery."
|
||||
|
||||
Automation is a fundamental, but change doesn't stop there.
|
||||
|
||||
"Leaders need to push for automation, monitoring, and a continuous delivery process. This usually means changes to many existing practices, processes, team structures, [and] roles," Choy says. "Leaders need to be willing to change anything that'll hinder the team's ability to fully automate the process."
|
||||
|
||||
### 6. Rethink team structure and performance metrics
|
||||
|
||||
While we're on the subject of change...if that org chart collecting dust on your desktop is the same one you've been plugging names into for the better part of a decade (or more), it's time for an overhaul.
|
||||
|
||||
"IT executives need to take a completely different approach to organizational structure in this new era of DevOps culture," Kail says. "Remove strict team boundaries, which tend to hamper collaboration, and allow for the teams to be self-organizing and agile."
|
||||
|
||||
Kail says this kind of rethinking can and should extend to other areas in the DevOps age, too, including how you measure individual and team success, and even how you interact with people.
|
||||
|
||||
"Measure initiatives in terms of business outcomes and overall positive impact," Kail advises. "Finally, and something that I believe to be the most important aspect of management: Be empathetic."
|
||||
|
||||
Beware easily collected measurements that are not truly DevOps metrics, writes [Red Hat ][13]technology evangelist Gordon Haff. "DevOps metrics should be tied to business outcomes in some manner," he notes. "You probably don't really care about how many lines of code your developers write, whether a server had a hardware failure overnight, or how comprehensive your test coverage is. In fact, you may not even directly care about the responsiveness of your website or the rapidity of your updates. But you do care to the degree such metrics can be correlated with customers abandoning shopping carts or leaving for a competitor." See his full article, [DevOps metrics: Are you measuring what matters?][14]
|
||||
|
||||
### 7. Chuck conventional wisdom out the window
|
||||
|
||||
If the DevOps age requires new ways of thinking about IT leadership, it follows that some of the old ways need to be retired. But which ones?
|
||||
|
||||
"To be honest, all of them," Kail says. "Get rid of the 'because that's the way we've always done things' mindset. The transition to a culture of DevOps is a complete paradigm shift, not a few subtle changes to the old days of Waterfall and Change Advisory Boards."
|
||||
|
||||
Indeed, IT leaders recognize that real transformation requires more than minor touch-ups to old approaches. Often, it requires a total reboot of a previous process or strategy.
|
||||
|
||||
Callendar of West Monroe Partners shares a parting example of legacy leadership thinking that hampers DevOps: Failing to embrace hybrid IT models and modern infrastructure approaches such as containers and microservices.
|
||||
|
||||
"One of the big rules I see going out the window is architecture consolidation, or the idea that long-term maintenance is cheaper if done within a homogenous environment," Callendar says.
|
||||
|
||||
**Want more wisdom like this, IT leaders? [Sign up for our weekly email newsletter][15].**
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://enterprisersproject.com/article/2018/1/7-leadership-rules-devops-age
|
||||
|
||||
作者：[Kevin Casey][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://enterprisersproject.com/user/kevin-casey
|
||||
[1]:https://enterprisersproject.com/tags/devops
|
||||
[2]:https://enterprisersproject.com/article/2017/7/devops-requires-dumping-old-it-leadership-ideas
|
||||
[3]:https://www.datical.com/
|
||||
[4]:https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/
|
||||
[5]:https://enterprisersproject.com/article/2017/10/why-agile-leaders-must-move-beyond-talking-about-failure?sc_cid=70160000000h0aXAAQ
|
||||
[6]:https://enterprisersproject.com/article/2017/10/how-beat-fear-and-loathing-it-change
|
||||
[7]:https://www.rainforestqa.com/
|
||||
[8]:https://enterprisersproject.com/article/2018/1/3-areas-where-devops-and-cios-must-get-same-page
|
||||
[9]:https://www.cybric.io/
|
||||
[10]:http://www.westmonroepartners.com/
|
||||
[11]:https://www.scrumalliance.org/community/articles/2017/february/product-backlog-grooming
|
||||
[12]:https://www.redhat.com/en/topics/automation?intcmp=701f2000000tjyaAAA
|
||||
[13]:https://www.redhat.com/en?intcmp=701f2000000tjyaAAA
|
||||
[14]:https://enterprisersproject.com/article/2017/7/devops-metrics-are-you-measuring-what-matters
|
||||
[15]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ
|
||||
@ -0,0 +1,119 @@
|
||||
DevOps时代的7个领导准则
|
||||
======
|
||||
|
||||
|
||||
|
||||
如果[DevOps]最终更多的是关于文化而不是任何其他的技术或者平台，那么请记住：没有终点线。而是继续改变和提高--而且最高管理层并没有通过。
|
||||
|
||||
然而，如果期望DevOps能够帮助获得更多的成果，领导者需要[修订他们的一些传统的方法][2]让我们考虑7个在DevOps时代更有效的IT领导的想法。
|
||||
|
||||
### 1. 向失败说“是的”
|
||||
|
||||
“失败”这个词在IT领域中一直包含着特殊的内涵，而且通常是糟糕的意思：服务器失败，备份失败，硬盘驱动器失败-你得了解这些情况。
|
||||
|
||||
然而一种健康的DevOps文化取决于重新定义失败-IT领导者在他们的字典里应该重新定义这个单词将它的含义和“机会”对等起来。
|
||||
|
||||
“在DevOps之前，我们曾有一种惩罚失败者的文化，”罗伯特·里夫斯说,[Datical][3]的首席技术官兼联合创始人。“我们学到的仅仅是去避免错误。在IT领域避免错误的首要措施就是不要去改变任何东西：不要加速版本迭代的日程，不要迁移到云中，不要去做任何不同的事”
|
||||
|
||||
那是过去的一个时代的剧本，里夫斯坦诚的说，它已经不起作用了，事实上，那种停滞是失败的。
|
||||
|
||||
“那些缓慢的释放并逃避云的公司被恐惧所麻痹-他们将会走向失败，”里夫斯说道。“IT领导者必须拥抱失败并把它当做成一个机遇。人们不仅仅从他们的过错中学习，也会从其他的错误中学习。一种开放和[安全心里][4]的文化促进学习和提高”
|
||||
**[相关文章：[为什么敏捷领导者谈论“失败”必须超越它本义]]
|
||||
### 2. 在管理层渗透开发运营的理念
|
||||
|
||||
尽管DevOps文化可以在各个方向有机的发展，那些正在从整体中转变，孤立的IT实践，而且可能遭遇逆风的公司-需要执行领导层的全面支持。你正在传达模糊的信息
|
||||
而且可能会鼓励那些愿意推一把的人，这是我们一贯的做事方式。[改变文化是困难的][6];人们需要看到领导层完全投入进去并且知道改变已经实际发生了。
|
||||
|
||||
“为了成功的实现利益的兑现高层管理必须全力支持DevOps，”来自[Rainforest QA][7]的首席技术官说道。
|
||||
|
||||
成为一个DevOps商店。德里克指出，涉及到公司的一切，从技术团队到工具到进程到规则和责任。
|
||||
|
||||
"没有高层管理的统一赞助支持，DevOps的实施将很难成功，"德里克说道。"因此，在转变到DevOps之前在高层中有支持的领导同盟是很重要的。"
|
||||
|
||||
### 3. 不要只是声明“DevOps”-要明确它
|
||||
即使IT公司也已经开始拥抱欢迎DevOps,每个人可能不是在同一个进程上。
|
||||
**[参考我们的相关文章，**][**3 阐明了DevOps和首席技术官们必须在同一进程上**][8] **.]**
|
||||
|
||||
造成这种脱节的一个根本原因是：人们对这个术语的有着不同的定义理解。
|
||||
|
||||
“DevOps 对不同的人可能意味着不同的含义，”德里克解释道。“对高管层和副总裁层来说，执行明确的DevOps的目标，清楚的声明期望的成果，充分理解带来的成果将如何使公司的商业受益并且能够衡量和报告成功的过程。”
|
||||
|
||||
事实上，在基线和视野之上，DevOps要求正在进行频繁的交流，不是仅仅在小团队里，而是要贯穿到整个组织。IT领导者必须为它设置优先级。
|
||||
|
||||
“不可避免的，将会有些阻碍，在商业中将会存在失败和破坏，”德里克说道。“领导者名需要清楚的将这个过程向公司的其他人阐述清楚告诉他们他们作为这个过程的一份子能够期待的结果。”
|
||||
|
||||
### 4. DevOps和技术同样重要
|
||||
|
||||
IT领导者们成功的将DevOps商店的这种文化和实践当做一项商业策略，与构建和运营软件的方法相结合。DevOps是将IT从支持部门转向战略部门的推动力。
|
||||
|
||||
IT领导者们必须转变他们的思想和方法，从成本和服务中心转变到驱动商业成果，而且DevOps的文化能够通过自动化和强大的协作加速收益。来自[CYBRIC][9]的首席技术官和联合创始人迈克说道。
|
||||
|
||||
事实上，这是一个强烈的趋势通过更多的这些规则在DevOps时代走在前沿。
|
||||
|
||||
“促进创新并且鼓励团队成员去聪明的冒险是DevOps文化的一个关键部分，IT领导者们需要在一个持续的基础上清楚的和他们交流，”凯尔说道。
|
||||
|
||||
“一个高效的IT领导者需要比以往任何时候都要积极的参与到商业中去，”来自[West Monroe Partners][10]的性能服务部门的主任埃文说道。“每年或季度回顾的日子一去不复返了-你需要欢迎每两周一次的待办事项。[11]你需要有在年度水平上的思考战略能力，在冲刺阶段的互动能力，在商业期望满足时将会被给予一定的奖励。”
|
||||
|
||||
### 5. 改变妨碍DevOps目标的任何事情
|
||||
|
||||
虽然DevOps的老兵们普遍认为DevOps更多的是一种文化而不是技术，成功取决于通过正确的过程和工具激活文化。当你声称自己的部门是一个DevOps商店却拒绝对进程或技术做必要的改变，这就是你买了辆法拉利却使用了用过20年的引擎，每次转动钥匙都会冒烟。
|
||||
|
||||
展览 A： [自动化][12].这是DevOps成功的重要并行策略。
|
||||
|
||||
“IT领导者需要重点强调自动化，”卡伦德说。“这将是DevOps的前期投资，但是如果没有它，DevOps将会很容易被低效吞噬自己而且将会无法完整交付。”
|
||||
|
||||
自动化是基石，但改变不止于此。
|
||||
|
||||
“领导者们需要推动自动化，监控和持续的交付过程。这意着对现有的实践，过程，团队架构以及规则的很多改变，”Choy说。“领导者们需要改变一切会阻碍隐藏团队去全利实现自动化的因素。”
|
||||
|
||||
### 6. 重新思考团队架构和能力指标
|
||||
|
||||
当你想改变时...如果你桌面上的组织结构图和你过去大部分时候嵌入的名字都是一样的，那么你是时候该考虑改革了。
|
||||
|
||||
“在这个DevOps的新时代文化中，IT执行者需要采取一个全新的方法来组织架构。”Kail说。“消除组织的边界限制，它会阻碍团队间的合作，允许团队自我组织，敏捷管理。”
|
||||
|
||||
Kail告诉我们在DevOps时代，这种反思也应该拓展应用到其他领域，包括你怎样衡量个人或者团队的成功，甚至是你和人们的互动。
|
||||
|
||||
“根据业务成果和总体的积极影响来衡量主动性，”Kail建议。“最后，我认为管理中最重要的一个方面是：有同理心。”
|
||||
|
||||
注意很容易收集的到测量值不是DevOps真正的指标，[Red Hat]的技术专员Gardon Half写到，“DevOps应该把指标以某种形式和商业成果绑定在一起，”他指出。“你可能真的不在乎开发者些了多少代码，是否有一台服务器在深夜硬件损坏，或者是你的测试是多么的全面。你甚至都不直接关注你的网站的响应情况或者是你更新的速度。但是你要注意的是这些指标可能和顾客放弃购物车去竞争对手那里有关，”参考他的文章，[DevOps 指标：你在测量什么？]
|
||||
|
||||
### 7. 丢弃传统的智慧
|
||||
|
||||
如果DevOps时代要求关于IT领导能力的新的思考方式，那么也就意味着一些旧的方法要被淘汰。但是是哪些呢？
|
||||
|
||||
“是实话，是全部，”Kail说道。“要摆脱‘因为我们一直都是以这种方法做事的’的心态。过渡到DevOps文化是一种彻底的思维模式的转变，不是对瀑布式的过去和变革委员会的一些细微改变。”
|
||||
|
||||
事实上，IT领导者们认识到真正的变革要求的不只是对旧方法的小小接触。它更多的是要求对之前的进程或者策略的一个重新启动。
|
||||
|
||||
West Monroe Partners的卡伦德分享了一个阻碍DevOps的领导力的例子：未能拥抱IT混合模型和现代的基础架构比如说容器和微服务
|
||||
|
||||
“我所看到的一个大的规则就是架构整合，或者认为在一个同质的环境下长期的维护会更便宜，”卡伦德说。
|
||||
|
||||
**想要更多像这样的智慧吗？[注册我们的每周邮件新闻报道][15].**
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://enterprisersproject.com/article/2018/1/7-leadership-rules-devops-age
|
||||
|
||||
作者：[Kevin Casey][a]
|
||||
译者：[译者FelixYFZ](https://github.com/FelixYFZ)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://enterprisersproject.com/user/kevin-casey
|
||||
[1]:https://enterprisersproject.com/tags/devops
|
||||
[2]:https://enterprisersproject.com/article/2017/7/devops-requires-dumping-old-it-leadership-ideas
|
||||
[3]:https://www.datical.com/
|
||||
[4]:https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/
|
||||
[5]:https://enterprisersproject.com/article/2017/10/why-agile-leaders-must-move-beyond-talking-about-failure?sc_cid=70160000000h0aXAAQ
|
||||
[6]:https://enterprisersproject.com/article/2017/10/how-beat-fear-and-loathing-it-change
|
||||
[7]:https://www.rainforestqa.com/
|
||||
[8]:https://enterprisersproject.com/article/2018/1/3-areas-where-devops-and-cios-must-get-same-page
|
||||
[9]:https://www.cybric.io/
|
||||
[10]:http://www.westmonroepartners.com/
|
||||
[11]:https://www.scrumalliance.org/community/articles/2017/february/product-backlog-grooming
|
||||
[12]:https://www.redhat.com/en/topics/automation?intcmp=701f2000000tjyaAAA
|
||||
[13]:https://www.redhat.com/en?intcmp=701f2000000tjyaAAA
|
||||
[14]:https://enterprisersproject.com/article/2017/7/devops-metrics-are-you-measuring-what-matters
|
||||
[15]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ
|
||||
Loading…
Reference in New Issue
Block a user