读《阿里DevOps实战手册》之敏捷开发梳理总结

在以往工作经历中,总是遇到各种各样的问题

产品需求过于简单,漏洞百出,线上处处留坑,异常场景考虑欠缺

技术架构复杂不统一,不同团队维护多种架构,开发风格多样,开发质量无检测,无review code

测试耗时,业务场景不熟悉,测试难点问题重复出现,不能自动化测试

产品,研发,测试不是一个整体,项目串联无质无序

1 DevOps核心理念

DevOps是以快速交付价值,给与开发最大自由度,负责开发和运维的全部过程。在监控、故障防控工具,功能开关的配合下,可以在保障用户体验和快速交付价值之间找到平衡点。

1.1 DevOps核心理念之松管控和强卡点

读《阿里DevOps实战手册》之敏捷开发梳理总结_第1张图片

松管控:应用 Owner可以完整定义这个应用的各种规则,比如如何发布,如何测试,如何进行资源、环境 配置等。我们有通用构建和自定义构建,可以给开发最大自由度。最后是“轻发布,重恢复”。在每一个应用维度,开发可以随时使用流水线来交付代码,而并不需要特别的限制,仅仅需要思考的是如果出问题,我们应该如何快速恢复。

强卡点:代码审核和质量红线;代码安全检查、规约检查;发布、封网窗口等。还有所谓“变更三板斧”:可灰度、可监控、可回滚。这些卡点是为了保障所有开发工程师步调统一,交付合格的产品。

1.2 DevOps核心理念之应用中心

读《阿里DevOps实战手册》之敏捷开发梳理总结_第2张图片

DevOps是应用为中心。应用信息其实可以归纳为CMDB(Configuration Management Database配置管理数据库)中的一种数据。它对于研发人员天然是亲切的,它可以直接对应一个服务,一个代码库。以代码为起点,我们又可以串联流水线、环境、测试、资源。最外围是工具链:监控、DB、运维、中间件等等。

2 DevOps实践之敏捷开发

随着5G、人工智能、IOT等新技术的迅猛发展,企业的业务都将构架在软件和互联网之上。软件交付能力成为企业的核心竞争力,随着市场竞争的加剧,企业对研发效能的期望越来越高。然而新技术、新业态的不断涌现,又使企业的业务变得越来越复杂,各个团队之

间的协作也越来越困难,企业的研发效能呈现降低趋势。“期望”与“现实”之间产生了巨大的“Gap”,正是我们要努力的方向。

读《阿里DevOps实战手册》之敏捷开发梳理总结_第3张图片

2.1 敏捷开发之效能问题

局部效率 ≠ 高效交付 ≠ 持续高效  

高效交付 ≠ 业务成功

读《阿里DevOps实战手册》之敏捷开发梳理总结_第4张图片

精益和敏捷的方案是需要解决上面的三个问题:

● 从局部效率到高效交付,我们需要做到:顺畅高质量交付。

● 从高效交付到持续高效,我们需要做到:持续地顺畅高质量地交付。对于代码设计和质量的长期维护和提高,持续工程能力的积累,持续交付实践的实施等。

● 从高效交付到业务成功,我们需要做到:持续地顺畅高质量交付有效价值。

2.2 精益敏捷实践之实践框架

精益敏捷研发实践框架分为三层,

第一层是战略和目标,主要包含用户诉求、愿景目标和战略规划。第二层是产品规划层,这里需要业务、产品、技术之间的敏捷协

作,将战略和目标层的业务诉求形成业务诉求条目后录入业务需求池,然后通过业务设计、产品设计、产品交付等环节,交付有效价值,并根据业务验证结果,建立业务反馈进行调整,最终达成业务结果。
    第三层是团队交付层,在这一层需要产品和技术团队高效协作,持续澄清,开发和验证需求,并通过自动化交付流水线和持续交付机

制实现快速交付需求。

实现精益敏捷研发,需要做到以下四步

读《阿里DevOps实战手册》之敏捷开发梳理总结_第5张图片

2.2.1 第一步需要打通端到端的业务价值流

从用户的需求到用户问题解决这一全过程,而不是中间的某一个阶段。这就需要我们的业务、产品、技术进行协作。

读《阿里DevOps实战手册》之敏捷开发梳理总结_第6张图片

业务、产品、开发、测试和运维在内的端到端交付过程。打通端到端的业务价值流必须做到:用户价值驱动,即每一个流动单元体现的都是具有用户价值的业务需求;前后职能拉通,即拉通业务、产品、开发、测试等各个职能一起来看整个链路,始于用户问题的提出,终于用户问题的解决

读《阿里DevOps实战手册》之敏捷开发梳理总结_第7张图片

产品规划层:需要聚焦端到端的流动效率,并形成价值反馈闭环。而在团队交付层:需要聚焦快速交付业务需求,并保证交付质量

团队交付层:需求从“产品规划层”流转到“等待开发”这个阶段的时候,需要“指派”给开发团队。需求进入开发团队后,开发同

学会把它拆分为“任务”,比如说按照“前后端”会拆分为“前端任务”“后端任务”;只有当所有“任务”开发完成后,满足“提交测试”要求了,才“提测”。

2.2.2 第二步快速高质量交付

读《阿里DevOps实战手册》之敏捷开发梳理总结_第8张图片

从阶段“业务讨论”开始到“已发布”都需要有明确的准入规则。

举两个具体的例子,

第一个是从“产品”流转到“开发”的规则:

● 开发、测试和产品达成一致,定义明确的验收标准。

● 大需求,需拆分为工作量在两周以内的需求卡片。

● 与关联方确认相关计划;识别大的技术风险并定义应对方案。

● 涉及三位及以上开发人员的需求,指定需求负责人,负责协调进度。

注:在软件研发过程中,大多数的时间浪费不是协作上的等待,而是做了很多无价值的需求,以及需求不停地返工。因此发生在软件开发之前的需求澄清工作至关重要。

其典型形式是:“在什么情况下,做什么操作,会得到什么结果”。基于具体的实例,更加便于沟通中的双向确认,保证理解的一致和场景覆盖。

第二个是从“开发”流转到“测试”的规则。

● 通过持续集成开发完成后,部署在测试环境;

● 开发对照验收标准Case进行了自测。

● 通过 Show Case。

验收测试驱动开发,确保高质量的准入准出

读《阿里DevOps实战手册》之敏捷开发梳理总结_第9张图片

需求进入开发团队的队列(等待开发)后,业务、开发和测试立即通过实例化,用结构化的方式生成需求的验收标准。

在开发实现这些需求的同时,QA团队会将这些需求实例会转化成测试用例,并把部分测试用例自动化,做到功能实现和自动化测试开发同步完成。

需求实现完成后,QA团队会用处理好的测试用例来验收这些需求。甚至可以将部分测试用例提前给到开发人员,让开发提前进行自测。

注:从“业务讨论”到“已发布”每个环节都需要有一个明确的准入准出规则,研发,产品,测试可以根据实际情况去定义自己的规则,这些规则不是一成不变的而是需要持续更新、持续迭代。

2.2.3 第三步度量反馈和持续改进

期望产品交付过程是可被度量的,同时可驱动交付团队持续改进。

读《阿里DevOps实战手册》之敏捷开发梳理总结_第10张图片

根据产品规划时明确的业务目标和要解决的用户问题,去验证业务目标是否已达成,用户问题是否已被解决,然后做相应的优化和调整。

读《阿里DevOps实战手册》之敏捷开发梳理总结_第11张图片

左半部分,团队属于小瀑布的开发模式。“迭代”前期,团队集中设计、编码,引入缺陷,但并未即时地集成和验证。缺陷一直掩藏在系统中,直到项目后期,团队才开始集成和测试,缺陷集中爆发。

小瀑布模式下,交付质量差,带来大量的返工、延期和交付质量问题。该模式下,产品的交付时间依赖于何时缺陷能被充分移除,当然不能做到持续交付,也无法快速响应外部的需求和变化。并且这一模式通常都导致后期的赶工,埋下交付质量隐患。

右半部分,团队开始向持续交付模式演进。在整个迭代过程中,团队以小粒度的需求为单位开发,持续地集成和测试它们,即时发现和解决问题。缺陷库存得到控制,系统始终处于接近可发布状态。这一模式更接近持续发布状态,团队对外的响应能力随之增强。

缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存,让系统始终处于接近可发布状态,保障了持续交付能力和对外响应能力。

读《阿里DevOps实战手册》之敏捷开发梳理总结_第12张图片

使用“周期时间控制图”来度量“交付效率”。如上图所示,横轴代表日期,竖轴是天数,一个一个蓝色的点代表已经发布的需求。期望这些蓝色的散点进行如下分布。

1. 纵向上向下集中——需求交付周期和开发周期越短,业务响应能力及其可预测性越高。

2. 散点密度提高——散点密度越高代表发布频率越高,发布的能力就越强。

3. 横向上更均匀分布——横向上的需求分布是均匀的,代表是持续交付的。在度量一个研发团队的交付效率时,看这些散点分布的趋势是否是往下走的,如果是往下走的,说明交付效率在变好。此外,还会看“控制线”,在上图中,看到这个研发团队的周期控制线是 13 天,这表示 85% 的需求周期时间都要小于13天,这也代表了该研发团队的交付效率。

2.2.3.1 可行动的效能度量体系

读《阿里DevOps实战手册》之敏捷开发梳理总结_第13张图片

包含需求响应周期、持续发布能力、交付吞吐率、交付过程质量、交付质量等五组指标。这五组度量指标内容又被归纳为三个维度,即流动效率、资源效率和质量保障。其中,持续发布能力和需求响应周期这两组指标反映价值的流动效率;映资源效率;交付过程质量和对外交付质量这两组指标共同反映质量水平。用六个字 来概括这三个维度就是:又快、又多、又好。有了度量标准之后,还要建立效能反馈和改进闭环,才能更好地提升研发效能。

2.2.3.2 效能反馈和改进闭环

读《阿里DevOps实战手册》之敏捷开发梳理总结_第14张图片

通过日常反馈,质量和交付效能的反馈,并定期进行复盘分析,形成流程操作、基础设施、代码与设计、交付及测试守护和人员技能等五个方面的改进行动,然后持续反馈、分析和改进。

2.2.4 第四步规模化实施

有了以上三步,其实还不够,我们需要赋能整个企业或组织,进行规模化实施。

2.2.4.1 单产品多交付团队场景

读《阿里DevOps实战手册》之敏捷开发梳理总结_第15张图片

在产品规划层,具有一个产品线看板, 管理业务需求的端到端价值流,并将准备好的需求分配给负责任的开发团队(指派给交付团队 1 或交付团队 2)。在交付团队层,有两个独立的交付团队,他

们的操作其实跟单产品线单交付团队时并没有不同。只需要接受业务需求,分解开发任务,管理需求的开发和交付过程,快速交付。

2.2.4.2 多产品多交付团队场景

读《阿里DevOps实战手册》之敏捷开发梳理总结_第16张图片

有三层看板。第一层是公司级业务运营看板,关注公司战略的落地,如各业务线的投资组合,各业务单元的目标和关键结果,跨业务线的协作和组合创新等。第二层是产品线看板,主要关注产品需求价值流,如端到端需求流动过程,目标反馈闭环等。第三层是交付团队层,主要关注团队快速交付需求,如高质量快速交付,效能反馈闭环等。

可以看到每条产品线都对应多个不同的交付团队,如果各个产品线之间没有任何“交叉”就比较简单了,操作方式类似前面提到的“单产品线多交付团队”模式。但是也可能出现“跨业务线协作”,这就需要在产品规划层进行拉通。比如在这个例子中“生活业务线产品” 的某个功能可能要依赖“中台业务线产品”的某个功能,生活业务线的产品经理就需要将开发需求“指派”到“交付团队 14”,让“交付团队 11”和“交付团队 14”协作完成需求的开发。

3 总结

读《阿里DevOps实战手册》之敏捷开发梳理总结_第17张图片

敏捷研发实践的三层框架:目标层、产品规划层、团队交付层。最重要的是精益敏捷研发的四个步骤:打通端到端价值流;快速高质量交付;度量反馈和持续改进;规模化实施。

你可能感兴趣的:(案例分享,java,Java,基础篇,devops,运维,产品设计)