07 | 业务敏捷：帮助DevOps快速落地的源动力
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
业务敏捷是推动DevOps快速落地的关键动力。在企业中，软件交付团队不断努力提高交付效率，但实际情况是业务需求不断变化，导致研发资源消耗在无法明确带来多少价值的需求上。随着企业推行DevOps时间的增长，业务部门和IT部门之间的鸿沟变得更加严重。因此，业务敏捷对于提升交付能力至关重要。文章提出了开发更少的功能、聚焦用户价值、持续快速验证的核心思想，并介绍了影响地图和卡诺模型的方法来帮助团队把握需求质量和优先级。文章强调了在快速迭代交付模式下，业务敏捷和交付能力的双重重要性。通过提升交付能力，业务可以以最小成本进行试错，快速交付新功能给用户，并根据用户和市场反馈调整方向。因此，业务敏捷和交付能力缺一不可。 文章中提到了业务敏捷的核心理念，包括对齐业务和开发目标、指标；把握安全、合规指标；及时对齐需求，减少无用开发；体现DevOps的价值；让开发团队开始接触业务，不单单是执行，调动积极性。这些理念对于企业实现业务敏捷和提升交付能力具有重要意义。 总的来说，本文强调了业务敏捷对于DevOps落地的重要性，以及在快速迭代交付模式下，业务敏捷和交付能力的相辅相成。通过聚焦用户价值、持续快速验证等核心思想，以及影响地图和卡诺模型的方法，帮助团队把握需求质量和优先级，文章为读者提供了实践业务敏捷的方法和理念。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(12)
- 最新
- 精选
Jxin
1.卡洛模型我们的产品团队也有在用，但很遗憾的是，收效甚微差距巨大，但我深知不怪我们的产品团队。因为作为2b的业务，产品的价值都是业务方提出或者评定的。然后这个价值评定就是笑话，风风火火搞一两个月的大项目，原本业务提出能接入xxx客户，带来xxx价值，结果接入廖廖无几。当站在最前面的一波人都是来搞笑的，你后面再怎么折腾也翻不起浪。深刻觉得业务方都停留在我觉得，而没真真走出公司站在市场，用客观的数据和长期经验来评定需求价值。 2.mvp前面还有个mvp，在最小可行产品出来前，应该要筛选最小价值产品（v=valuable）。挖掘追小价值产品方案，排优先级，然后再制定最小可行产品，去试验反馈改进升级。业务驱动往上再看一点是价值驱动。但这种模式偏爱短期价值，势必会导致长期价值的产品难以推行。但就当下而言还是比较适用的，因为变化太快，长期价值的风险系数太高，贴现率太低了，远不如短期价值来得靠谱。作者回复: 很有感触，最开始做持续交付的时候，感觉自己找到的银弹，花了大力气建立了持续交付体系，等到给老板汇报的时候却发现很难量化证明自己的价值。对于IT团队来说，面对的情况就是这么尴尬。一个需求扔过来到底有没有价值，没有人知道，IT团队只需要把需求如期完成上线，然后就没有然后了。这个需求的业务价值从来不会跟IT团队透传，所以除了无穷无尽的需求，IT团队很难找到价值认同点。即便到了现在，也是如此，业务方没人敢碰，所有的体系能力都是从产品经理接受需求的时间点开始，到需求交付上线位置，始终缺少业务层面的价值体现，这也是目前我在思考的问题吧。
2019-11-08320
leslie其实老师的课程提到一点：核心需求；经历过一些企业，和一些同行沟通过，如何梳理出真实的核心需求似乎是个典型问题或者说通病。 最核心最有价值的东西展现或挖潜出来才可能绕着去做：其实之前有学习极客时间里关于产品的课程，今天的课程中所提及的MVP的概念以及需求的价值，就像为什么DevOps是提升效率；当我们结合产品就会发现其中的核心理念是有所相通的。 进一步举例说明：产品经理为何很多时候和技术对立；可是如果是真正懂技术或技术转产品的会更加明白其中的方式方法。其实DevOps同样是一个产品：技术团队本身的产品。作者回复: 这个观点很新颖，很有启发，技术团队本身就是一个产品。产品思维和开发思维本身就是两种思维模式，这一点相信你也有所感受，如果产品人员懂技术最大的挑战就是两种思维模型并存，又不会互相干扰，实际上我见过很多技术人员做的产品，还是浓浓的工程师风格，但是用户不是工程师，所以这一点我觉得对于产品未来的发展也是一个挑战。
2019-10-2626
Eric Yi关于用户需求故事的拆分，再进入每一个迭代，能否举一个具体例子？这样会更好理解一点。作者回复: 你好，关于用户故事的拆分，比较经典的有9种方法，其实主要用到的还是工作流步骤拆分（核心流程/支撑流程），接口可变性拆分（分享二维码/链接/通知），主要投入拆分（典型平台接入/其他同类平台接入），业务可变性拆分（根据热门排序/销量排序），以及业务操作拆分(功能拆分，比如管理用户/邮箱/留言) 另外，关于用户故事，有一篇非常经典的文章推荐给你，虽然是全英文的，但是讲解的非常透彻，值得一读： [https://www.jpattonassociates.com/tag/product-discovery/](https://www.jpattonassociates.com/tag/product-discovery/)
2019-10-275
陈斯佳一切技术还是要围绕业务的需求来展开，作为后端的技术支持团队其实也可以主动影响业务需求的定义，从而适配之后整个开发流程。也许一个好的DevOps工程师就是一个业务和技术的翻译官吧作者回复: 我觉得翻译官的观点很有趣，我之前总说是桥梁，其实是一个道理。我老板之前问过我一个问题，当技术研究到一定阶段，下一步的方向和空间在哪里？他的观点就是业务。不是说技术不重要，但当你越参加高层的会议，就越发现讨论的都是业务数据，所以多留心业务方面总不是坏事哈。
2019-10-314
熊斌记得2015年我们公司负责推行敏捷开发的领导来培训敏捷，培训完毕后采用的是“自顶向下”的路径推行敏捷开发。 当时团队领导拿到需求后先拆分，将拆分后的需求写在纸条上面，贴在看板上让大家去领任务。 刚开始大家的积极性很高，每天有任务进度汇报，早上还有“站立会”。可是久而久之大家就疲惫了，没有人去关注看板上面的东西，也不再开站立会，又回到了原来的状态。 由此可见，知道容易，做到是很难的，尤其是在一个庞大的协作体系内。作者回复: 敏捷转型如果涉及到组织结构调整，那么也只能自顶向下来推了，说白了之所以疲惫了，两方面原因，要么是因为没有看到敏捷带来的好处，该半夜上线还是半夜上线，只不过迭代速度快了，压力大了，事儿多了而已；要么就是节奏绷的太紧张，没有劳逸结合，比如最简单的例子，每个迭代周期里面，有多少业务需求，有多少改进类需求，有多少技术预研需求，很多我猜都是120%的业务需求，那要如何坚持下去呢。
2019-10-282
iiiqueena感觉又把ACP的课上了一遍，不过老师你讲的挺好。作者回复: 感谢你的支持，加油，实践者
2019-10-28- Geek_62e3e7老师你好，关于需求拆分的粒度，之前阿里内部确实这么拆分过，然后对需求交付时间考核，大家就很聪明的把需求越拆越小，反而失去了度量的意义，这种情况你们内部有吗？如何解决这种问题2023-01-31归属地：浙江2
怀揣梦想的学渣文中讲到了用户价值，我理解的是，满足用户需求，提升用户满意度，就是用户价值的具体体现。我做过3年的面向通信公司的产品交付，做过2年面向制造业的产品交付，我的感受是，用户的心声需要一线人员收集，愿意主动分享需求的比较少，稍有阻力就不会反馈问题或者提需求，只会让乙方去猜测推测。 常见方法是留一个便捷的渠道让客户反馈需求。 我的方法是主动融入客户的群体，让客户把我这里当作树洞，对产品的不满随时可以骂过来，我去掉情绪话，总结梳理后，反馈给公司内部，并且将公司内部的进展同步给客户，让客户感受到被重视，让公司内部可以看到客户需求优先级。让客户看到自己扔来的石头有溅起水花，而非进入无底洞。 一些沟通中发掘的需求，需要和客户多一些细致的交流分辨优先级，分辨重要程度。并非客户经理喝酒可以搞定，也并非产品经理用复杂公式和先进流程可以分析出结果。 我印象比较深的一次产品交付，有国内主流厂家都去竞标，试用阶段，一家厂商因为曾经对客户的需求无回应，直接在试用阶段出局，我要交付的产品虽然是客户期望度比较高的产品，但我一直是抱着怀疑的态度先去探查客户真实的需求。和客户闲聊是发现，客户对A功能十分需要，并且每天都要用。但客户认为A功能是主流厂商产品默认有的，不需要单独提。但做从技术实现角度看，A功能必须额外准备其他资源才可以实现，在特定业务场景并不会标配A功能，只有在低端普通场景才会标配A功能。如果没有这些探查，整个产品团队会一致认为我们的产品是最符合客户需求的，并且会吐槽客户需求变化真多。客户也会一致认为这乙方真脑子冒泡，基础需求都不能理解，还要我们多轮去讲解，难道不能一次交流清楚。2023-06-01归属地：山东
Mr_Sun老师您好 关于您讲到的bizdevops 我有几点疑问 。1、如果让开发参与到业务过程影响开发效率问题怎么解决，如何平衡2、在用户使用产品过程中遇到的问题，是否需要开发一起协助解决，用户提出的工单解决流程具体如何优化更有效果，具体应该如何分配3、在实践中，运维人员在业务和敏捷中的比例应该怎么分配2022-04-24
atom992谈需求拆分的时候，是否可以结合DDD呢？如何结合？2020-12-18
