内容简介：实录丨不以敏捷开发为基础的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
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
An Introduction to Probability Theory and Its Applications
William Feller / Wiley / 1991-1-1 / USD 120.00
Major changes in this edition include the substitution of probabilistic arguments for combinatorial artifices, and the addition of new sections on branching processes, Markov chains, and the De Moivre......一起来看看 《An Introduction to Probability Theory and Its Applications》 这本书的介绍吧!
