DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

07 | 业务敏捷:帮助DevOps快速落地的源动力

石雪峰 2019-10-26
你好,我是石雪峰,今天我要跟你分享的主题是业务敏捷,那么,我们先来聊一聊,什么是业务敏捷,为什么需要业务敏捷呢?
先试想这样一个场景:你们公司内部成立了专项小组,计划用三个月时间验证 DevOps 落地项目的可行性。当要跟大老板汇报这个事情的时候,作为团队的负责人,你开始发愁,怎么才能将 DevOps 的价值和业务价值关联起来,以表明 DevOps 对业务价值的拉动和贡献呢?
如果朝着这个方向思考,就很容易钻进死胡同。因为,从来没有一种客观的证据表明,软件交付效率的提升,和公司的股价提升有什么对应关系。换句话说,软件交付效率的提升,并不能直接影响业务的价值。
实际上,软件交付团队一直在努力通过各种途径改善交付效率,但如果你的前提是需求都是靠谱的、有效的,那你恐怕就要失望了。因为,实际情况是,业务都是在不断的试错中摸着石头过河,抱着“宁可错杀一千,也不放过一个”的理念,各种天马行空的需求一起上阵,搞得软件交付团队疲于奔命,宝贵的研发资源都消耗在了业务的汪洋大海中。但是,这些业务究竟带来了多少价值,却很少有人能说得清楚。
在企业中推行 DevOps 的时间越长,就越会发现,开发、测试和运维团队之间的沟通障碍固然存在,但实际上,业务部门和 IT 部门之间的鸿沟,有时候会更加严重。试问有多少公司的业务方能够满意 IT 部门的交付效率,又有多少 IT 团队不会把矛头指向业务方呢?说白了,就一句话:如果业务不够敏捷,IT 再怎么努力也没用啊!所以,我觉得很有必要跟你聊一聊有关需求的话题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • leslie
    其实老师的课程提到一点:核心需求;经历过一些企业,和一些同行沟通过,如何梳理出真实的核心需求似乎是个典型问题或者说通病。
         最核心最有价值的东西展现或挖潜出来才可能绕着去做:其实之前有学习极客时间里关于产品的课程,今天的课程中所提及的MVP的概念以及需求的价值,就像为什么DevOps是提升效率;当我们结合产品就会发现其中的核心理念是有所相通的。
          进一步举例说明:产品经理为何很多时候和技术对立;可是如果是真正懂技术或技术转产品的会更加明白其中的方式方法。其实DevOps同样是一个产品:技术团队本身的产品。

    作者回复: 这个观点很新颖,很有启发,技术团队本身就是一个产品。产品思维和开发思维本身就是两种思维模式,这一点相信你也有所感受,如果产品人员懂技术最大的挑战就是两种思维模型并存,又不会互相干扰,实际上我见过很多技术人员做的产品,还是浓浓的工程师风格,但是用户不是工程师,所以这一点我觉得对于产品未来的发展也是一个挑战。

    2019-10-26
    3
  • Jxin
    1.卡洛模型我们的产品团队也有在用,但很遗憾的是,收效甚微差距巨大,但我深知不怪我们的产品团队。因为作为2b的业务,产品的价值都是业务方提出或者评定的。然后这个价值评定就是笑话,风风火火搞一两个月的大项目,原本业务提出能接入xxx客户,带来xxx价值,结果接入廖廖无几。当站在最前面的一波人都是来搞笑的,你后面再怎么折腾也翻不起浪。深刻觉得业务方都停留在我觉得,而没真真走出公司站在市场,用客观的数据和长期经验来评定需求价值。

    2.mvp前面还有个mvp,在最小可行产品出来前,应该要筛选最小价值产品(v=valuable)。挖掘追小价值产品方案,排优先级,然后再制定最小可行产品,去试验反馈改进升级。业务驱动往上再看一点是价值驱动。但这种模式偏爱短期价值,势必会导致长期价值的产品难以推行。但就当下而言还是比较适用的,因为变化太快,长期价值的风险系数太高,贴现率太低了,远不如短期价值来得靠谱。

    作者回复: 很有感触,最开始做持续交付的时候,感觉自己找到的银弹,花了大力气建立了持续交付体系,等到给老板汇报的时候却发现很难量化证明自己的价值。对于IT团队来说,面对的情况就是这么尴尬。一个需求扔过来到底有没有价值,没有人知道,IT团队只需要把需求如期完成上线,然后就没有然后了。这个需求的业务价值从来不会跟IT团队透传,所以除了无穷无尽的需求,IT团队很难找到价值认同点。即便到了现在,也是如此,业务方没人敢碰,所有的体系能力都是从产品经理接受需求的时间点开始,到需求交付上线位置,始终缺少业务层面的价值体现,这也是目前我在思考的问题吧。

    2019-11-08
    1
  • 陈斯佳
    一切技术还是要围绕业务的需求来展开,作为后端的技术支持团队其实也可以主动影响业务需求的定义,从而适配之后整个开发流程。也许一个好的DevOps工程师就是一个业务和技术的翻译官吧

    作者回复: 我觉得翻译官的观点很有趣,我之前总说是桥梁,其实是一个道理。我老板之前问过我一个问题,当技术研究到一定阶段,下一步的方向和空间在哪里?他的观点就是业务。不是说技术不重要,但当你越参加高层的会议,就越发现讨论的都是业务数据,所以多留心业务方面总不是坏事哈。

    2019-10-31
    1
  • Eric Yi
    关于用户需求故事的拆分,再进入每一个迭代,能否举一个具体例子?这样会更好理解一点。

    作者回复: 你好,关于用户故事的拆分,比较经典的有9种方法,其实主要用到的还是工作流步骤拆分(核心流程/支撑流程),接口可变性拆分(分享二维码/链接/通知),主要投入拆分(典型平台接入/其他同类平台接入),业务可变性拆分(根据热门排序/销量排序),以及业务操作拆分(功能拆分,比如管理用户/邮箱/留言)
    另外,关于用户故事,有一篇非常经典的文章推荐给你,虽然是全英文的,但是讲解的非常透彻,值得一读:
     [https://www.jpattonassociates.com/tag/product-discovery/](https://www.jpattonassociates.com/tag/product-discovery/)

    2019-10-27
    1
  • iiiqueena
    感觉又把ACP的课上了一遍,不过老师你讲的挺好。

    作者回复: 感谢你的支持,加油,实践者

    2019-10-28
  • 熊斌
    记得2015年我们公司负责推行敏捷开发的领导来培训敏捷,培训完毕后采用的是“自顶向下”的路径推行敏捷开发。
    当时团队领导拿到需求后先拆分,将拆分后的需求写在纸条上面,贴在看板上让大家去领任务。

    刚开始大家的积极性很高,每天有任务进度汇报,早上还有“站立会”。可是久而久之大家就疲惫了,没有人去关注看板上面的东西,也不再开站立会,又回到了原来的状态。

    由此可见,知道容易,做到是很难的,尤其是在一个庞大的协作体系内。

    作者回复: 敏捷转型如果涉及到组织结构调整,那么也只能自顶向下来推了,说白了之所以疲惫了,两方面原因,要么是因为没有看到敏捷带来的好处,该半夜上线还是半夜上线,只不过迭代速度快了,压力大了,事儿多了而已;要么就是节奏绷的太紧张,没有劳逸结合,比如最简单的例子,每个迭代周期里面,有多少业务需求,有多少改进类需求,有多少技术预研需求,很多我猜都是120%的业务需求,那要如何坚持下去呢。

    2019-10-28
收起评论
6
返回
顶部