29 | 向前一步:万人规模企业的DevOps实战转型案例(上)
该思维导图由 AI 生成,仅供参考
- 深入了解
- 翻译
- 解释
- 总结
微软在DevOps转型中的实践经验展示了其在管理实践和文化层面的变革。通过组织架构调整和全功能团队构建,微软成功提升了交付效率并推动了研发与运维的融合。他们赋予团队自治的能力,将计划分为短期和长期目标,并注重用户行为数据的度量。此外,微软避免从大型团队开始入手,而是专注于中型团队,通过持续细小的改进帮助团队做得更好,建立了有效的持续改进循环。这些实践为企业在DevOps转型中的管理实践和文化变革提供了有益的借鉴和启示。文章还提到了基于特性维度的开发和交付,这一趋势在DevOps领域日益受到关注,未来的发展也将朝着这个方向发展。基于特性维度的开发和交付需要关注需求管理、分支策略、发布和价值追踪策略等方面的实践和思考。这一点值得业界深入思考和探讨。
《DevOps 实战笔记》,新⼈⾸单¥59
全部留言(9)
- 最新
- 精选
- 陈斯佳efficiency不等于effective。快,不一定对,方向很重要。有一个对方向不断矫正的反馈机制更重要。
作者回复: 有一本书叫做《Effective DevOps》,不是一般想象中的那种DevOps书籍,而更多的把视角落在的组织和人的层面上。在公司时间久了,就会发生一家公司能不能实现DevOps,跟工具的关系是最小的,人和流程,以及思维定式才是最大的问题。就好比两个老板要约一个会议,都是跟自己手下人说,你去找那边的老板约时间,那边的老板时间不妥当,也会让他的手下同步回来。其实想想,为啥两个老板不直接聊下呢,是因为没有工具吗,微信可方便的很呀,而这就是很多问题的根源所在吧。
2019-12-267 - leslie最近一直在整理笔记,然后整理的过程中发现了自己的问题以及后续应当去做的努力。报了几门程序开发的课程-强化一下自己的代码功力。 老师现在一篇文章从看完到简单梳理差不多要1小时左右。今天的课程非微软的部分案例场景在上次大会听过-填鸭似的听了2天,真心觉得比上班还累啊。大企业的转变在某些方面都有些类似的,还是对于今天的课程做点补充吧。 1.建立面向交付的特性团队:这个循序渐进的过程,不过有个核心的前提-领导必须有强大的前瞻性和做事情的魄力,否则这件事情真实落地确实很难; 2.自组织敏捷团队-保证团队目标的一致性和互相的配合度:需要相当严格和规范的制度与监控配合; 3.团队转型从中型团队入手-其中包含两种形式:第一种中型企业的核心小型团队,第二大型企业的中型团队;两种方式都能去找到问题且较小的代价一步步去做一些事情。 以上是对于今天课程的理解和总结:案例挺好挺有代表性的,幸好我今年学的课程够多,不然要开始听不懂了。谢谢今天的分享,期待后续的分享。
作者回复: 我也补充一点,面向特性的交付团队,这个跟软件架构也有关联,很多公司不是不想按特性交付,而是软件架构决定的交付的节奏一定快不了,这也是为什么很多人在讲微服务的原因,当然拆服务不是个盲目的事情,我只想说康威定律真的是在很多地方都有印证,而逆康威定律也一样有效。
2019-12-264 - 小谢同学老师可否解释下具体什么叫特性?这个概念如何定义?谢谢
作者回复: 你好,我的理解,特性是从用户交付的视角来看待的需求。一个特性就是对用户有价值的最小功能,一般对应到用户故事级别。
2019-12-303 - 连飞微软裁掉了测试,让用户来测试。从win10开始,bug数剧增,系统不稳定度剧增。还好意思提devops呢。2023-02-03归属地:上海
- idiot文中提到微软的指标不包括缺陷数量,但是scorecard那个图里又包括各种#bugs,怎么理解?2021-05-28
- Ethan“想在不改变流程的前提下,实现企业的 DevOps 转型是不现实的。” 这句话怎么理解? 我的理解:不再强调一次性整体交付,把 设计、开发、测试、部署 这几个是独立的研发过程阶段,而是强调 敏捷性(缩短一次交付周期,快速多次交付),把 设计、开发、测试、部署 看做一次交付的实施阶段。不知道这么理解对不对。2021-04-08
- Ethan“想在不改变流程的前提下,实现企业的 DevOps 转型是不现实的。”2021-04-08
- 丁乐洪开发转DevOps架构,容易吗?2020-03-29