实录丨不以敏捷开发为基础的DevOps都是耍流氓，你怎么看?

6月10日，数人云联合优维科技在北京举办了《DevOps&SRE超越传统运维之道》的线下沙龙活动，活动中了哥（邱戈川）以Scrum模式的角度切入本次主题，最后得出“不以敏捷开发为基础的DevOps都是耍流氓！”让咱们来看看了哥都分享了哪些内容吧。

前言

Scrum模式开发经验分享

Scrum出来已经好久了，不少原理性问题就不讲了。今天和你们主要分享一下Scrum实施过程当中的一些经验和对其的一些感觉。

主要有四块内容——敏捷Scrum模式概貌、人员的分工、平常活动的细节、以及一些可能用到的简单工具。

现行开发模式及开发过程当中痛点

敏捷模式概貌

Scrum已经用了好久，但为何始终没有用到极致或者很火？

你们都在作大型系统，Scrum模式难度稍大，链条过长。须要开不少协调会议，沟通成本高。

微服务和容器化让团队规模发生转变，从之前几十人的大团队转变成如今六七人的小团队。

客户及运营的需求产生变化，从数月至半年的交付时间转变到几周至一月的交付时间，使得业务更倾向于快速迭代、快速交付和快速变动。

什么是Scrum

敏捷模式概貌

上面这本书详细地介绍了敏捷，这里就再也不赘述。先提几个问题：

需求主导：一般需求都脱离于团队以外，上司或老板忽然下达一个指令并规定出时间，而自身的事情还没有完成，因此在开发上需求到底由谁来主导？

流程主导：不少公司都有一套流程来规范每一个团队所作的事情，应该团队来主导流程仍是公司主导流程？

颠覆仍是改进：敏捷是否是须要把之前的东西推翻？

什么是Scrum？SRE、Scrum、DevOps之间的关联是什么？

这里简单画了一个图。DevOps首先订制一个流程，用敏捷开发基础去作DevOps。并不是必定要用敏捷开发，能够尝试以快速迭代、快速交付的方式。

我的理解SRE更偏向于运维，涉及一些开放性的DevOps工具或开发工具，它离总体的软件开发交付还有必定距离。

困境

敏捷模式概貌

不少时候，你们以为敏捷开发、DevOps的模式及理念很好，但很难落地实践，归根究竟是须要作的事情太多。其实这个时候，不管是团队仍是管理者，都须要停下来，作一些思考。

自运营/服务模式

敏捷模式概貌

N多业务团队并行，由产品或商务提出需求，但一般只有一句话。也会有一些业务分析师，把业务作好澄清后导入给团队，每个团队产品体系里都要拆出本身理解的PRD，而后再自主规划版本，最后实施完成推送上线。

须要强调的是，敏捷在运维模式下很难作许多个产品统一的测试联调。一些大公司为了某个功能，将全部的产品功能对齐，等所有功能出来后再联调、测试、最后才推到市场，这是很值得“敬畏”的事。因团队和内容数量庞大繁杂，由于团队的数量，涉及的内容已经很难这样去作了。

受团队数量和涉及内容的限制，最好的方式是谁最后上线，谁最后作总体测试，以此为约束。

团队构成

敏捷模式概貌

上图即1-1-3-2模式，这是简单的实践作法。

关键性角色包括：

产品、架构师、开发、测试。

找到合适的产品和架构是最重要的，开发和测试从哪来（如外包）其实并无太大的关系。

沟通链条：

之前是产品→技术负责人→开发→测试，这样的顺序链条。但如今因团队人数的关系，全部的需求范围应该由产品直接对全部人进行沟通，以节省成本。

需求澄清要由产品来作，实现指导、实现方式则由架构师来作。产品决定作什么，架构决定怎么作，这是很是重要的一点。从而营造一种氛围：外部提出的只是需求，不是技术方案或实现，技术方案和实现要由团队的架构师去把握。

在团队中，可能有一个测试，四个开发，或根本没有测试，取决于团队自身状况。

公司规模较大，团队数量较多时要视状况而定是否作Scrum to Scrum，不一样的PO在一块儿协调和澄清每个产品或大的场景下的分工。注意：开协调会时，要把范围控制在少数人，而不是全员大会。

角色分工

角色分工以前已提过，但分完工以后，仍是有不少人作了不应作的事情，如老板去作技术指导。

PO

角色分工

不想作好测试的开发不是好PO，也就是说，一个产品作很差测试，作很差开发，那也就不必去作产品了。几个比较大的要求点：

• Roadmap：须要作整个产品的Roadmap规划，至少要给出每一个迭代有什么，有几个迭代，每一个版本是什么样。

• 迭代范围：产品要控制迭代范围，不少公司老板说什么就是什么，致使团队越作越混乱，因此产品经理要作好澄清，对外承诺的范围要掌握在手里。

• 产品生命周期计划、特性Demo、推广等等。另外还需跟架构师配合，沟通产品规划中每一个迭代与技术产品相关的改进点。

架构师

角色分工

架构师须要作好实现架构的设计以及相关成员的指导（如开发、测试），组织相关人员会议，作敏捷不表明不开会，甚至一些小团队内部之间的会议可能比原来的会议还要多。

开发

角色分工

开发没有太多的变化，惟一要作的事情就是开发要把东西作出来进行展现，让代码尽快可见。

测试

角色分工

测试最大的问题是不少时候被抛离团队以外，由于测试总以为本身是最后一环。不少公司以测试Case数量做为考核，这是对于测试人员最大的误区。

理想中测试主要作测试设计，从设计角度来进行测试。测试驱动开发完善产品、弥补思考上的遗漏，同时不少公司的开发把测试当作助手，呼来唤去，是很是不对的。

开发与测试的配合——模式转变

角色分工

模式上，开发和测试作一些转变。原来的模式中规划完成后，开发将产品开发出来，打包交给测试。

而新的模式下，测试从第一天就要参与其中，提早进行测试设计。

开发与测试的配合——思惟转变

角色分工

开发与测试的沟通，须要整个团队进行磨合的。前面提到，测试从第一天就进行测试，不须要开发来进行信息传递，而开发更加不是测试的上游。

将来，开发和测试边界会愈来愈模糊，测试也须要把重复性的工做进行自动化。

角色缺失

角色分工

其实这里把Scrum Master去掉了，由于不少人把Scrum Master变成了打杂。另外若是公司全员作敏捷，建议不要在公司层面定制流程，同一公司的不一样团队磨合程度又一，不少团队是靠人磨合出来的。

Planning Game

平常活动

Planning Game之前的标准作法是给你们一副扑克牌，12358斐波纳契数列数字牌。如今我用Gitlab比较多，将Planning Game的全部内容列上便可，而后你们作大致迭代评估，而不是精细评估。

有几点经验分享一下：

• 第一点，要负责好对应的范围，不要在一个版本里面，将全部的大功能都选择上。当把一个版本里面的大功能选择完了以后实际上等于没有选择，由于范围越大，失控也越高。 选择一些小功能或不重要的功能，做为风险缓冲。

• 第二点，须要预留出技术改进的空间，何时作重构，何时作改进等等。

• 第三点，迭代的周期，两个迭代出一个版本，最好是两周完成一个迭代。以版本而不是迭代作发布，预留出一周的时间作发布缓冲，并对下一个迭代进行规划。

Standup Meeting

平常活动

当团队比较小时，没有必要作的过重，虽然如今已经出了电子白板，我的的经验是用真实的白板操做性更好，更能体现哪些事情有关联依赖性，哪些人在作什么事。

须要强调的是，每一个人作的事情是自主的，但须要架构师掌控好，有限度的作出选择。对于很是重要的事情，要选对的人去作，而不是随意去作。选择的纸条项目要控制在两个之内，具备难度的要让架构师去作设计。

Review Meeting

平常活动

敏捷上开会仍是比较多的，但内部要想办法有效率去开。Review meeting包括设计、代码、测试 Review等。大功能设计，能够去作从三分之一到二分之一再到完整的Review，这样能够减小返工率。

End to End Demo

平常活动

尽快作emo，越快越好，能跑场景便可。不要让产品最后才看到Demo，也不要等全部的东西都作完，同时团队成员注意现阶段不须要挑刺。

DOD meeting

平常活动

DoD Meeting最好以迭代的方式，而不是版本方式。第一个迭代的DOD，要为下一个迭代作好风险控制。哪些是能作的，哪些是不能作的，哪些是须要本身作的，哪些要新增，都须要做出及时的调整。

Retrospect Meeting

平常活动

按期作回顾，一般的作法是拿便利贴写三点——对每一个方向提三点。选择一个轻松的环境，每一个人讲一些。而回顾会的意义不是批斗或者拍马屁，曾经有一次开发把产品经理批斗的很严重，产品经理反过来又把开发骂了一顿，以上作法都不可取。

产品运营

平常活动

整个团队也要作一些产品运营，不管产品是对内或对外，包括客户支持、数据分析，以及对内对外的分享。

迭代版本范围的选择原则

PO的工具

每一个迭代版本的选择，对于产品很重要。一句话归纳这个版本的价值和目标最佳。要向团队成员澄清目标，不然团队成员可能不知道重点或优先级。

版本细节定义

PO的工具

版本细节定义能够用鱼骨图表现，标注版本、周期，以及重要事项等。

Backlog/PRD管理

PO的工具

Backlog无需和代码绑定，在Wiki里进行管理便可。虽然Backlog不少时候只表现粗略的需求，但其好处容易与相关团队成员达成优先级别的一致。

小公司作产品时容易忽略Backlog管理，想到哪作到哪。Backlog的定义详见PPT。

产品功能地图

PO的工具

产品要作功能地图，用脑图的方式概括整理便于你们理解，另外一个好处是便于开发和测试补充遗漏，若是运用好功能地图，会更好的沟通，以及作功能之间的相关性测试。

任务拆解与管理

PO的工具

任务完成后须要进行分解，用Gitlab的Issue方式去管理，天天站会时汇报工做进度，测试对完成的功能进行测试，细节须要讨论的，和测试提的BUG直接写到Issue上去便可。

版本Release Note

PO的工具

每一个版本出来都要写上Release Note，很多公司更新迭代多个版本，可是连一个Release Note都没有。Release Note建议要写一下产品是否对其余产品依赖以及依赖的版本是什么。 以前犯过一个错误，出了版本后，因为产品已经出了多个版本，而以前依赖的下一产品版本是错误的，则致使现有产品的版本仍是旧的。

内部版本定义规则

PO的工具

不少时候咱们使用有两位版本号，有三位的、也有四位的、或者纯字母。经验上三位版本号会比较好理解，第一个是大版本号，不向下兼容；中间是Feature版本号，能够向下兼容；最后一个是Patch版本。后面“-”的版本是本身内部的测试版本或RC版本。

总结

Scrum模式开发经验分享

最后，整个Scrum模式但愿你们根据团队状况，来调整流程和开发模式。人是活的，流程是死的。没有明文禁止的，均可以改变和调整的。

了哥公众号：vipdocker