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
