不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

Posted 中生代技术

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了不以敏捷开发为基础的DevOps都是耍流流流流流流流氓相关的知识,希望对你有一定的参考价值。

数人云

构建灵动新IT,最轻量级PaaS平台,热点聚焦云计算前言技术,开源动态,实践落地等,让分布式技术走出象牙塔。



不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

上次活动小编分享了活动PPT,在后台回复“610活动”即可下载!


活动中了哥(邱戈川)以Scrum模式的角度切入本次主题,最后得出“不以敏捷开发为基础的DevOps都是耍流氓!”让我们来看看了哥都分享了哪些内容吧。

前言

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

Scrum模式开发经验分享

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


Scrum出来已经很久了,很多原理性问题就不讲了。今天和大家主要分享一下Scrum实施过程中的一些经验和对其的一些感受。


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


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

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

敏捷模式概貌


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

Scrum已经用了很久,但为什么始终没有用到极致或者很火?


  • 大家都在做大型系统,Scrum模式难度稍大,链条过长。需要开很多协调会议,沟通成本高。


  • 微服务和容器化让团队规模发生转变,从以前几十人的大团队转变成现在六七人的小团队。


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


什么是Scrum

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

敏捷模式概貌



不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


需求主导通常需求都脱离于团队之外,上司或老板突然下达一个指令并规定出时间,而自身的事情尚未完成,所以在开发上需求到底由谁来主导?


流程主导很多公司都有一套流程来规范每个团队所做的事情,应该团队来主导流程还是公司主导流程?


颠覆还是改进敏捷是不是需要把以前的东西推翻?


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


这里简单画了一个图。DevOps首先订制一个流程,用敏捷开发基础去做DevOps。并非一定要用敏捷开发,可以尝试以快速迭代、快速交付的方式。


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


困境

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

敏捷模式概貌



不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

很多时候,大家觉得敏捷开发、DevOps的模式及理念很好,但很难落地实践,归根到底是需要做的事情太多。其实这个时候,无论是团队还是管理者,都需要停下来,做一些思考。


自运营/服务模式

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

敏捷模式概貌



不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


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


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


团队构成

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

敏捷模式概貌



不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


关键性角色包括:


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


找到合适的产品和架构是最重要的,开发和测试从哪来(如外包)其实并没有太大的关系。


沟通链条:


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


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


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


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


角色分工


角色分工之前已提过,但分完工之后,还是有很多人做了不该做的事情,如老板去做技术指导。

PO

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

角色分工


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


不想做好测试的开发不是好PO,也就是说,一个产品做不好测试,做不好开发,那也就没必要去做产品了。几个比较大的要求点:


  • Roadmap:需要做整个产品的Roadmap规划,至少要给出每个迭代有什么,有几个迭代,每个版本是什么样。


  • 迭代范围:产品要控制迭代范围,很多公司老板说什么就是什么,导致团队越做越混乱,所以产品经理要做好澄清,对外承诺的范围要掌握在手里。


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


架构师

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

角色分工


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


开发

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

角色分工


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

开发没有太多的变化,唯一要做的事情就是开发要把东西做出来进行展示,让代码尽快可见。


测试

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

角色分工


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

测试最大的问题是很多时候被抛离团队之外,因为测试总觉得自己是最后一环。很多公司以测试Case数量作为考核,这是对于测试人员最大的误区。


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


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

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

角色分工


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


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


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

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

角色分工


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


未来,开发和测试边界会越来越模糊,测试也需要把重复性的工作进行自动化。


角色缺失

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

角色分工


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

其实这里把Scrum Master去掉了,因为很多人把Scrum Master变成了打杂。另外如果公司全员做敏捷,建议不要在公司层面定制流程,同一公司的不同团队磨合程度又一,很多团队是靠人磨合出来的。


日常活动


Planning Game

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

日常活动


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


Planning Game以前的标准做法是给大家一副扑克牌,12358斐波纳契数列数字牌。现在我用Gitlab比较多,将Planning Game的所有内容列上即可,然后大家做大体迭代评估,而不是精细评估。


有几点经验分享一下:


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


  • 第二点,需要预留出技术改进的空间,什么时候做重构,什么时候做改进等等。


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


Standup Meeting

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

日常活动


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


需要强调的是,每个人做的事情是自主的,但需要架构师掌控好,有限度的做出选择。对于非常重要的事情,要选对的人去做,而不是随意去做。选择的纸条项目要控制在两个以内,具有难度的要让架构师去做设计。


Review Meeting

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

日常活动


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


End to End Demo

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

日常活动


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


尽快做emo,越快越好,能跑场景即可。不要让产品最后才看到Demo,也不要等所有的东西都做完,同时团队成员注意现阶段不需要挑刺。


DOD meeting

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

日常活动


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


Retrospect Meeting

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

日常活动


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


产品运营

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

日常活动


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


PO的工具


迭代版本范围的选择原则

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

PO的工具


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


版本细节定义

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

PO的工具


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


Backlog/PRD管理

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

PO的工具


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


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


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


产品功能地图

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

PO的工具


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


产品要做功能地图,用脑图的方式归纳整理便于大家理解,另一个好处是便于开发和测试补充遗漏,如果运用好功能地图,会更好的沟通,以及做功能之间的相关性测试。


任务拆解与管理

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

PO的工具


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

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


版本Release Note 

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

PO的工具


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


每个版本出来都要写上Release Note,不少公司更新迭代多个版本,但是连一个Release Note都没有。Release Note建议要写一下产品是否对其他产品依赖以及依赖的版本是什么。 之前犯过一个错误,出了版本后,由于产品已经出了多个版本,而之前依赖的下一产品版本是错误的,则导致现有产品的版本还是旧的。


内部版本定义规则

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

PO的工具


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


很多时候我们使用有两位版本号,有三位的、也有四位的、或者纯字母。经验上三位版本号会比较好理解,第一个是大版本号,不向下兼容;中间是Feature版本号,可以向下兼容;最后一个是Patch版本。后面“-”的版本是自己内部的测试版本或RC版本。


总结

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

Scrum模式开发经验分享


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓


最后,整个Scrum模式希望大家根据团队情况,来调整流程和开发模式。人是活的,流程是死的。没有明文禁止的,都可以改变和调整的。



不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

扩展阅读




活动推荐

带着大家的期待,我们将《DevOps&SRE超越传统运维之道》话题在上海继续。

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

分享嘉宾

不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

张保珠/数人云架构师

演讲主题:《以金融行业为例,SRE之道下微服务的落地实践过程》


8年金融行业企业级应用开发及架构经验。

在数人云从事云平台产品设计研发,对微服务、分布式系统、容器化有深入研究。


不以敏捷开发为基础的DevOps都是耍流流流流流流流氓

匡云竹/优维科技高级解决方案架构师

演讲主题:《互联网金融的DevOps实践及案例分享》


曾就职于银行及互联网金融行业,具有多年的运维研发经验。负责企业的自动化运维建设及DevOps的推动和落地。

曾负责开发建设基于云端的自动化运维平台,对企业如何通过自动化实现DevOps转型有着丰富的实践经验。

获得CCIE安全、DevOps Master等认证。

现任优维科技高级解决方案架构师,负责互联网、金融、航空、制造业等多个行业的解决方案制定。

周炎/东方财富网业务运维负责人

演讲主题:《传统行业-运维人员如何应对企业DevOps转型》

先后就职于宝源、中技、东财从事业务运维、持续交付、DevOps落地改进等工作。

曾主导中技集团企业标准化运维、工具化运维体系的落地;

目前在东方财富网专注持续交付落地、业务监控等相关工作。

议程安排

  • 13:30-14:00     签到

  • 14:00-15:10     开场

  • 14:10-15:00     张保珠@数人云  《以金融行业为例,SRE之道下微服务的落地实践过程》

  • 15:00-15:50     匡云竹@优维科技  《互联网金融的DevOps实践及案例分享》

  • 15:50-16:40     周炎@东方财富网  《传统行业-运维人员如何应对企业DevOps转型》

  • 16:40-17:10     抽奖&自由交流

时间地点

2017年7月15日下午14:00-17:00

上海市徐汇区田林路192号1楼

活动奖品




点击这里报名活动!

↓↓↓

以上是关于不以敏捷开发为基础的DevOps都是耍流流流流流流流氓的主要内容,如果未能解决你的问题,请参考以下文章

Flink 流流关联( Interval Join)总结

Discord.js 将 mpeg 音频流流式传输到语音通道

实录丨不以敏捷开发为基础的DevOps都是耍流氓

Java转换流缓冲流流的操作规律和properties类整理

LiveNVR拉转Onvif/RTSP/RTMP/FLV/HLS直播流流媒体服务视频广场页面集成视频播放集成说明

Java 学习笔记 - IO篇:常见的流Stream通道Channl以及相互关系