个人中心
文章发布
退出
作者热门文章
- Java锁的逻辑（结合对象头和ObjectMonitor）
- 还在用饼状图？来瞧瞧这些炫酷的百分比可视化新图形（附代码实现）⛵
- 自动注册实体类到EntityFrameworkCore上下文，并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
25
4
。
2020年 基于我司业务形态，我开始实行敏捷项目管理。以敏捷为道，Scrum为法，迭代为术，禅道作器，大张旗鼓的搞了2年敏捷开发。随着时间推移，问题出现在2022年，当时我们已经完全按照Scrum的模式在运作着10个项目，以及项目团队。我们基于禅道提炼了如：任务准期率、任务准交率、计划偏差率等指标。但是其中一项指标成了我们10个团队的核心痛点，即：需求交付周期。我们在2022年年底复盘的时候发现全年下来，需求交付的平均周期为40天，也就意味着一个需求从登记到禅道到关闭的平均周期是40天。这是我们无法接受的，也是业务部门（内部甲方）无法接受的.
问题出在我们的发布与迭代是 强关联 的，我们的迭代是2周一次，然后一个迭代就发布一次，也就是说一个需求在理论上最快发布周期是21天(3周)，这里说的是理论值如下图:
。
除非刚好，提出需求的那天正好是迭代开启的头一天，那样可以做到14天，但是那种情况太极限了。另外也不是刚刚提出需求，下个迭代就可以安排开发。所以普遍性来说，算上排期，一个需求平均交付周期在这种模式下最快就只能做到21天.
但是，不可接受的事情是我们10支项目团队，平均需求交付周期是40天，甚至比21天还要多2周。一个经典的案例是用户需求增加一个Excel导入导出的功能，问我们要多久。我们开发人员评估的工时是2小时，但是客户问我们什么时候能用上，我们回答却是2周以后。用户不理解，我们也不理解。至此，如何将迭代与发布脱钩，就成了我研究的课题.
摆在我们面前的有两条路线可以选择一条是SAFe，一条是DevOps。 由于我们在2020~2022年期间先后取得了Scrum Master 和 PMI-ACP的认证。所以思维定式上会去靠拢SAFe， 完全实行SAFe对人员的要求很高，转型也很痛苦。因此，我只采用了SAFe中的“发布火车”这一重点实践。 固定每周2、4 为发布周期。 在试行2个月后，研发人员抱怨声音越来越大，抱怨的主要原因是开发人员根本跟不上。其实这里所谓的跟不上，经过我后面的调研不是指开发能力不行，而是对代码没有 基于需求 做主分支管理。至此，我开始研究另外一条路线：DevOps .
写在前面：实施DevOps两个月之后，我将需求平均交付周期从原来的40天，成功的缩短到了 23天 ， 并且后续任然有信心降低到 15天内 .
。
我入手的第一本书籍是《DevOps实践指南》。说实话，这本书把我整的有点懵逼。书中讲了很多运维人员和开发人员的实操案例。虽然我本身具备10年的.Net开发经验，但是我现在本职工作是项目经理，这对我来说并没有解决我的核心痛点。也可能是我们目的性太强，造成了我耐不住性子去读这本书。不过，这本书在我小白阶段的时候，至少跟我说清楚了什么是：DevOps?
早期在百度搜索DevOps，多数解释就是：开发运维一体化，打通开发与运维之间的部门墙之类的。其实，这只是狭义的DevOps的理解。通过潜伏到各种微信群中，听到各种大佬对DevOps的解释，有的说是 工具链 ， 有的说是是 流水线 ， 有的说是实现 自动化， 有的说是实现 CI/CD（ 持续集成/持续部署） .
这种浑浑噩噩的阶段，直到读完《DevOps实践指南》才慢慢好转，那么究竟什么是DevOps？
我认为现在最好的定义是： 研发效能。 特别是这个“效能”，不是研发效率，效率指的是团队的产能，速度。 而效能是这个“能”字是指的： 赋能 。 这样才解释清楚，在广义的DevOps是怎么适配到IT的研发场景。紧接着问题又来了，怎么个赋能法才叫DevOps？还是没说清楚什么是DevOps？我们先把这个问题先放一下，先来回答另外一个问题：什么是敏捷?
其实，在我入门敏捷的时候，也具有同样的困惑，什么是敏捷？是Scrum？是Xp？还是水晶？ 后来明白了，符合 敏捷宣言 的都是敏捷.
。
。
再回到前面那个问题，什么是DevOps ？如何为研发效率赋能？是否也有类似敏捷宣言这样更具体的解释，答案是有的《DevOps实践指南》给出了DevOps 三大原则： 流动、反馈、持续学习 。 简单来说符合 流动、反馈、持续学习的就是DevOps，并且DevOps自身也在不断进化更新.
可是，还是有点抽象。这个持续学习还好理解，无论是理论指导实践，还是实践完善理论，持续学习始终是向上的攀升的正确途径.
那么剩下的两个问题:
1，流动是什么?
2，反馈是什么?
带着这两个问题我又分别入手了《价值流动》、《敏捷无敌之DevOps时代》这两本书.
关于《价值流动》我之前写过另外一篇读后感，这里不做赘述，总之该书解释清楚了流动的是啥，如下图:
| 描述 。 |
交付物 。 |
|
| 特性 。 |
为推动业务结果而增加的新价值；对客户可见 。 |
新的业务价值 。 |
| 缺陷 。 |
为修复影响客户体验的质量问题 。 |
质量 。 |
| 风险 。 |
致力于解决安全、隐私和合规风险 。 |
安全、治理、合规 。 |
| 债务 。 |
软件架构和运维架构的改进 。 |
消除未来交付的障碍 。 |
。
到这里我的问题更多了，前面我们要解决的问题是如何将迭代与发布脱钩？ 如何将需求交付周期从40天降下来？我们通常认为的需求就是上表中的 特性 ，这里一看不但需求对应的特性没有 透明化 ， 另外的缺陷、风险 和债务也是不透明的。但是总而言之，一句话：当前我是看不见需求的流动， 这也就解释了为什么我潜伏微信群的时候，有大神解释DevOps 就是 流水线 ，流动的东西就是上面的 四大流动项.
上面解释清楚了什么是流动，以及流动的是什么。那么转换成为行动任务就是，打造一套体系让流水线，实现可视化、透明化。这让我们想起了考ACP的时候的 “价值流图” 有异曲同工之妙.
就像木桶定理一样，决定一个木桶能装多少水，取决于那么短板。 无论是特性、缺陷、风险、还是债务。对应的是四条处理流程（流水线），而将这个流程以进行 可视化 ，就能发现过程中的短板，并加以改善。根据我浅薄的理解，我悟到这里，算是对“流动”有了一个较为具体的认知.
那么反馈又是什么？ 基于我对敏捷的认知，反馈就是以最小可行产品实现快速上线，获得用户反馈，并立即优化调整。通过阅读《敏捷无敌之DevOps时代》之后，我有新的理解。通过各种工具建设对 观测指标 进行提炼 ， 对各项指标进行治理形成反馈 ， 并利用这些反馈进行改进和优化，从而形成犹如 PDCA 的正向循环.
所以，这里又说明白了为什么我潜伏在微信群中，大佬说DevOps是 工具链 .
。
。
说到工具链，不得不说我们潜伏微信群时候，大佬的另外一个解释： 自动化 。 前面讲的基于四大流动项，可以打造四条流水线。那么流水线除了做价值流图分析过程短板以及等待浪费以外，还可以针对流程本身进行 提速 。 这里我们可以简单的映射一下现实生活中的工厂， 手动流水线 和 自动化流水线 .
至于怎么自动化，说来也简单。就是把重复劳动的事情交给机器去做，现实生活中的流水线不也是这样的吗？这里对于解决了哪些重复劳动不做篇幅（PS.前期在B站一搜DevOps，老是出来一堆工具的实操教程，一直给我整的挺懵逼。） 。
这里再回头说一下，发布与迭代怎么脱钩，通过我对这些DevOps工具的了解，接触到了 CI/CD .
CI (Continuous Integration)：持续集成。它涉及将开发人员的代码频繁地集成到共享存储库中，并使用自动化构建和测试工具对代码进行验证.
CD (Continuous Delivery/Continuous Deployment)：持续交付/持续部署。它涉及自动化地构建、测试和部署应用程序以实现快速且可靠的交付.
本身，CI/CD 概念并不复杂，为什么我们前面用发布火车团队反应这么大呢？ 前文中也有描述，没有基于需求创建分支这是其一，创建分支缺乏管理，无法有效的实施持续集成、持续部署这是其二.
通过建设CI/CD，基于需求创建分支，配合工具使用。做好的功能通过测试，就发布。不再等到迭代结束再发布，一下子就把需求交付与迭代脱钩了，我们的交付周期也很快的从40天降低到了30天内.
写到这里，我再提炼几个关键词： 流动、反馈、持续学习、透明化、可视化、自动化、工具链、流水线，CI/CD.
到这里，还不是DevOps建设的全貌，接下来就要大刀阔斧的动起来了~！ 。
。
前面已经讲过，由于在团队内部实行“发布火车”，造成的团队各种抱怨。为了达成共识，这次我选择了外来和尚念经。由于市场上也有不少的成熟的DevOps解决方案，我先后组织了4场“解决方案供应商" 线上交流会，让团队对DevOps有了一致的认知，也成功勾起了大家对组织改善的意愿.
这里我规划了三条建设路线同步进行:
其一，是 工具链 。包括：禅道18.0、GitLab、SonarQube、Jenkins、Selenium、Jmeter、K8s、Docker、Zabbix、WebFunny 。
其二，是 流程与规范 ，包括：项目管理流程、需求管理流程、缺陷管理流程、敏捷运作机制、禅道使用规范、.Net编码规范、JAVA编码规范、GtiLab使用规范、持续集成规范、持续部署规范、测试管理规范、制品管理规范、服务器监督管理规范、应用系统监督管理规范.
其三，是 过程性指标与结果性指标 。包括：需求总数、需求从登记到设计周期、需求从设计到评审周期、需求从开发到提测周期、需求从测试到发布周期、代码提交次数、部署频率、部署成功率 等指标.
紧接着趁热打铁，直接把DevOps转型当做项目来做，发起了对DevOps的立项:
项目背景:
数字运营中心是敏捷型交付组织，具有边设计边生产边实施、用户需求多且变更频繁、软件使用过程中需要快速响应等组织特性。随着部门业务量的倍速增长，管理复杂度不断增加，同时需要更精细化的观测指标进行管控，产品设计、项目管理、软件开发、质量测试等过程缺乏规范性，尤其对细节管理需要实现过程与结果透明化，需要一套适合自己的面向企业服务的 软件生产管理体系与工具 ，同时拉通各个职能角色，使软件生产业务数据透明可视；缩短需求生产周期，降低开发成本，进而实现开发运维一体化，提升管理效率.
项目目标:
目标1：需求平均交付周期从40天降低至25天.
目标2：需求按期交付率从90%提升至95%.
目标3：人均需求交付数从1.5提升至1.8.
目标4：软件发布一次成功率实现透明化，并提升至80% 。
项目收益:
投入180人天，获得约14人编制的产能，计算如下:
数字运营中心以70人为基准，当前月度人均交付需求数为1.5。 通过建设DevOps研发效能体系，预计产能提升至月度人均交付需求1.8.
通过计算可知:
当前产能：70*1.5=105 。
目标产能：70*1.8=126 。
提升产能：126-105=21 。
释放同等人力：21/1.5=14人，以人均薪资1万元计算，约 每月降本14万元 ， 全年降本168万 .
项目蓝图:
。
。
再回到一开始的问题，我们通过建设蓝图里的一系列工具，成功实现了基于需求做代码版本的主分支管理，实现了一周2发布的频次。自此也完成了发布与迭代脱钩，虽然目前DevOps研发效能这个项目还没有完全结束。但是我们已经成功实现了交付周期从原来40天缩短到了23天。大致成果如下图:
。
。
。
。
最后此篇关于《敏捷无敌之DevOps时代》读后感的文章就讲到这里了,如果你想了解更多关于《敏捷无敌之DevOps时代》读后感的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。
25
4
0
我想通过添加一个带有 transition = 0s 的类但更改颜色来使用 jQuery 运行 CSS 动画，然后立即删除该类(使用原始 transition = 2s)它逐渐变为原始颜色。 下面是我
最近两年，互联网+的概念可谓十分火爆。所谓“互联网+”，其实质就是把互联网大平台和各行各业进行有机结合，建立一个新的商业生态，对于传统企业来说，互联网+的第一步就是有一个企业网站，将自己推广出去
每天我都更喜欢 Postgres，今天我发现了函数“age”。它不仅选择年份，还选择月份和日期。太棒了! 46 years 10 mons 18 days 现在我想知道是否有一个函数可以定义“年”、“
我正在 秒 内从服务器接收数据，我想将其转换为最新数据。 但我收到的秒数不是自 UNIX 纪元 01/01/1970 以来，而是 01/01/2000。 通常我会使用: SimpleDateForma
如果在 matlab 中使用可变时间步长求解器，例如 ODE45 - 我将为输出定义一个时间跨度，即 times = [0 50]，matlab 将返回不同时间步长的结果介于 0 和 50 之间。 但
因此，System.currentTimeMillis 以 UTC 时区返回毫秒。 DateTime.getmillis 是否与我所知道的几乎所有图书馆都一样，因为纪元总是在 UTC 中？ joda-
Hadoop 2.0 引入了 YARN，取代了 Job Tracker 和 Task Tracker 的任务。 YARN 由资源管理器(调度器、应用程序管理器...)、节点管理器和应用程序管理器组成。
在 ViewModel 和 one activity multiple fragments 概念时代，Activity 与 Fragment 中放置 Toasts、Snackbars 有什么建议。 很
许多 Android 讨论都集中在(显然是著名的)Fingerpaint 示例上: https://stackoverflow.com/a/16650524/294884 我从哪里得到它，与 Andr
在(最终)向我的 Facebook 应用程序添加一些分析并意识到英语在我的用户语言列表中排名靠后后，我开始研究 official docs on internationalization . 但是，文
我是一名优秀的程序员,十分优秀！