请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 2008|回复: 0

敏捷是DevOps的本质

[复制链接]
发表于 2018-9-22 09:30:22 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-22 09:36 编辑 , q( Y, z+ D. L/ f$ U" ~& _
2 f1 P3 e6 y5 |8 S( [
1 t6 {0 q2 I+ Q  t0 D1 k* D+ x) I

8 j6 Z* f! Q( N/ [0 N" F
前言

  _1 C7 d1 l7 l( f! x/ z
Scrum模式开发经验分享
1.png

8 s/ w, H- _1 i) k' w5 W& w

3 t! V3 o  J5 V1 J) L. x/ v
. l. i7 }, T; Y; F$ n* I' {- ]
Scrum出来已经很久了,很多原理性问题就不讲了。今天和大家主要分享一下Scrum实施过程中的一些经验和对其的一些感受。

- `. R9 e* T7 ^

2 o8 \) x: |/ |- @$ @$ _
主要有四块内容——敏捷Scrum模式概貌、人员的分工、日常活动的细节、以及一些可能用到的简单工具。
8 _9 E% f0 P% N3 B: J6 N

$ \7 Y3 `5 Z+ t# U
现行开发模式及开发过程中痛点

& h1 ~- C4 r- J; C; E6 S$ O4 m8 s9 m7 L
敏捷模式概貌
6 a( c0 i- l4 h( v3 `+ x: L' |
1.png
! |5 a6 ~2 R: q1 k% h( y* h

0 v- P. [) ?1 R- A( h, o
Scrum已经用了很久,但为什么始终没有用到极致或者很火?

+ _. F( `# e! Y! L  W6 k

1 `) {5 _" Z$ e& u, N5 A# J) {' ?
  • 大家都在做大型系统,Scrum模式难度稍大,链条过长。需要开很多协调会议,沟通成本高。
    3 V5 _' F5 |% M) d. Y
. T1 w8 W3 e" f6 Q1 u& G
  • 微服务和容器化让团队规模发生转变,从以前几十人的大团队转变成现在六七人的小团队。
    2 I- K0 b& K1 m" y7 Q% x! m- E# R

1 d& F; _  B( N0 N* v0 }: C/ B; X, k0 I3 C1 ^
  • 客户及运营的需求产生变化,从数月至半年的交付时间转变到几周至一月的交付时间,使得业务更倾向于快速迭代、快速交付和快速变更。

    1 b! Q6 ?8 A0 ~

. |  T5 ?& T9 N' h
什么是Scrum

: M& U* t; {7 j
敏捷模式概貌

, W+ J/ G! [" |* {/ z$ c1 F  @
1.png

0 T& s8 ]/ T7 r# |9 q
9 H7 {1 d- \0 C* E! W' V2 k
上面这本书详细地介绍了敏捷,这里就不再赘述。先提几个问题:

+ p/ @! {( N4 `6 t4 t& Q

4 C: T  Y# s+ T) ?& U
需求主导:通常需求都脱离于团队之外,上司或老板突然下达一个指令并规定出时间,而自身的事情尚未完成,所以在开发上需求到底由谁来主导?
, Q! u3 D5 y+ V
$ \+ P2 T$ f, }2 O7 z
流程主导:很多公司都有一套流程来规范每个团队所做的事情,应该团队来主导流程还是公司主导流程?
  q, _# Y; \* }% w
+ ]" R0 G. d1 V% T
颠覆还是改进:敏捷是不是需要把以前的东西推翻?
& H3 l$ M" U8 r' i3 F! Q
1.png

) k5 P- n' ]9 W3 i" ]) ^) p

1 B  a6 ?9 k: c
什么是Scrum?SRE、Scrum、ITILxf.com" target="_blank" class="relatedlink">DevOps之间的关联是什么?
$ f9 q9 Z8 p& ^& V
" Z" a1 u4 j7 c
这里简单画了一个图。DevOps首先订制一个流程,用敏捷开发基础去做DevOps。并非一定要用敏捷开发,可以尝试以快速迭代、快速交付的方式。
( j5 V, K8 a4 v. v) g4 r6 k* \
. l' C) P  g2 }" Q* R7 d
个人理解SRE更偏向于运维,涉及一些开放性的DevOps工具或开发工具,它离整体的软件开发交付还有一定距离。
0 o: W' d2 V9 I6 B$ s3 R3 \. Q
0 |/ n6 C8 H7 z% J; {; M  C3 n
困境

, O1 p7 |; ~, V9 J- }0 r6 ?5 V: F
敏捷模式概貌

0 K+ x+ f9 j: b5 Q" ?

' v. I* q5 ^$ `2 K" m0 r( v8 v
1.png

- c, K: N3 T1 n+ S- b5 L8 d# f) [4 o
$ Z: Y% F0 s# A! M
很多时候,大家觉得敏捷开发、DevOps的模式及理念很好,但很难落地实践,归根到底是需要做的事情太多。其实这个时候,无论是团队还是管理者,都需要停下来,做一些思考。

# C* x0 @& c& p# e; w4 G
5 Z2 p$ I) ]7 o" M; c
' u- T! q0 e! [' }0 M( N1 h" k
自运营/服务模式
4 @7 K3 }4 ]# [9 M, F. h
敏捷模式概貌

2 \1 P% l; N+ [" a& {6 G
1.png

# Y% A1 C1 [: t: H% S
  g; B: v+ h7 {- x
N多业务团队并行,由产品或商务提出需求,但通常只有一句话。也会有一些业务分析师,把业务做好澄清后导入给团队,每一个团队产品体系里都要拆出自己理解的PRD,然后再自主规划版本,最后实施完成推送上线。
2 G0 G* r2 n4 [, N' F" |
1 Y0 D6 q  O) S# u8 f
需要强调的是,敏捷在运维模式下很难做许多个产品统一的测试联调。一些大公司为了某个功能,将所有的产品功能对齐,等全部功能出来后再联调、测试、最后才推到市场,这是很值得“敬畏”的事。因团队和内容数量庞大繁杂,因为团队的数量,涉及的内容已经很难这样去做了。

1 s" j" F& ~5 }! O8 G8 F

- C& ?- ]5 {, k6 X
受团队数量和涉及内容的限制,最好的方式是谁最后上线,谁最后做整体测试,以此为约束。
; ?  c2 H/ l9 |) ?' d. E

& ~/ J& t) T: M% X$ D/ z
团队构成
7 F% u- M1 s8 A' I
敏捷模式概貌

0 \, m2 l! p+ {) Y
1.png

" w- D0 ^4 I) c
+ J2 q2 K6 U% S) ?
上图即1-1-3-2模式,这是简单的实践做法。
$ Z& @/ P6 I/ Q0 Z% B6 n& F6 l
" T% i9 I  g6 T6 C- z6 K
- m5 x" a! N3 U
关键性角色包括:

6 B! R  S  `" i

& O# C1 ]7 `# n
产品、架构师、开发、测试。
: t" x1 h+ a6 W, N% {) L+ P

1 x9 I) k- T! C+ e
找到合适的产品和架构是最重要的,开发和测试从哪来(如外包)其实并没有太大的关系。

& f7 |' }+ B7 h4 Q* A/ w1 R9 d

$ a) z$ y1 I# }+ z+ S
沟通链条:
3 v  z7 p9 }0 n/ N* f( z# e& r* |. D

/ G( L" u$ Y  V& V1 p  G  ^, M& `
以前是产品→技术负责人→开发→测试,这样的顺序链条。但现在因团队人数的关系,所有的需求范围应该由产品直接对所有人进行沟通,以节省成本。

/ f5 _3 |8 U; b  [. @. B5 t: D& Z; `

7 S* h. P$ B) V" u+ d% v; V
需求澄清要由产品来做,实现指导、实现方式则由架构师来做。产品决定做什么,架构决定怎么做,这是非常重要的一点。从而营造一种氛围:外部提出的只是需求,不是技术方案或实现,技术方案和实现要由团队的架构师去把握。

- T/ v7 [" c$ a: X1 v! p

: `+ m/ ?7 v7 e3 ?9 y/ B4 C$ [. T
在团队中,可能有一个测试,四个开发,或根本没有测试,取决于团队自身情况。
; M  k. \+ `5 Y. W9 Q, V7 d$ `5 {
1.png

! o! v4 e* _0 T+ F  O4 E8 K
! T, y+ K+ C4 j8 c/ c: Q

4 G) w% r- X0 J# s, Z# |+ K5 S
公司规模较大,团队数量较多时要视情况而定是否做Scrum to Scrum,不同的PO在一起协调和澄清每一个产品或大的场景下的分工。注意:开协调会时,要把范围控制在少数人,而不是全员大会。
6 b% d* O. n, I: O8 y: X3 `
% K. ?* e" t, B4 Y! @; a( ~
角色分工
8 ?7 C3 @1 Q4 {6 @( Q

% U( s/ F% A) a1 \- x  a# P
角色分工之前已提过,但分完工之后,还是有很多人做了不该做的事情,如老板去做技术指导。

) g: A( m: m  J& Y

6 p) {! A; e9 P) G& D% Y, c8 l9 D, U
PO
8 x( ?2 n7 E# U1 J( }! A
角色分工

* u: C8 f7 U! ^% s+ }

$ M% J& ~% V  m
1.png

  J3 o; ~) @7 }8 R, j9 A

" P7 @/ F$ P& ?1 K
不想做好测试的开发不是好PO,也就是说,一个产品做不好测试,做不好开发,那也就没必要去做产品了。几个比较大的要求点:

8 w7 v0 H% e! t  ?2 ?
  • Roadmap:需要做整个产品的Roadmap规划,至少要给出每个迭代有什么,有几个迭代,每个版本是什么样。

    9 q0 k/ N6 T% r& R0 H
# n, d1 g, E# a
  • 迭代范围:产品要控制迭代范围,很多公司老板说什么就是什么,导致团队越做越混乱,所以产品经理要做好澄清,对外承诺的范围要掌握在手里。
    # K5 g. M! l" d7 N

5 _3 T: `$ ?2 J. j) I% _4 p( k' ]6 ~; h
  • 产品生命周期计划、特性Demo、推广等等。另外还需跟架构师配合,沟通产品规划中每个迭代与技术产品相关的改进点。

    ( H, t: p. K  s+ U
- a& S" }3 ~1 ~
架构师
4 N' a8 z* d( p+ H5 v1 Y; b7 W
角色分工

9 t& e( Q) L  Y: t
1.png
0 U  D! j  z- q+ M+ x$ A

2 i, Q9 \  `$ f: C* E
/ I# x& H9 A! i; F
架构师需要做好实现架构的设计以及相关成员的指导(如开发、测试),组织相关人员会议,做敏捷不代表不开会,甚至一些小团队内部之间的会议可能比原来的会议还要多。
/ s9 [# A4 x# m3 y' k/ q6 T8 D
开发

- p: t: Q; K) N9 V( d( q( z
角色分工

- ]4 ?/ J# a% x- ~1 U; M: O* U5 B
: \* a/ t. }% z" I9 a3 @8 z
1.png
5 f, @2 x# }( H$ G
$ O4 ?4 a5 }0 _9 S0 E5 @% |0 E$ T4 s
开发没有太多的变化,唯一要做的事情就是开发要把东西做出来进行展示,让代码尽快可见。
) D- N( d3 @1 k6 d0 J  p

0 t+ ]2 s3 R% [8 i" @6 u% T8 l' e0 M
测试
' P( |: B! Y2 l" y# [3 W6 [2 V
角色分工
; v( E& T/ z8 Z% i
1.png
* _. Y) W9 a* ^/ o

1 O2 C0 u; [7 N0 f5 h
测试最大的问题是很多时候被抛离团队之外,因为测试总觉得自己是最后一环。很多公司以测试Case数量作为考核,这是对于测试人员最大的误区。
1 b/ r/ n- [. i3 Y. B4 n& A
3 F* ^3 e) M6 K# t9 O+ D% ?: g
理想中测试主要做测试设计,从设计角度来进行测试。测试驱动开发完善产品、弥补思考上的遗漏,同时很多公司的开发把测试当做助手,呼来唤去,是非常不对的。

, ?5 l& h6 i2 v/ r
& f, d5 F! e: M
开发与测试的配合——模式转变

. [( c5 @) O7 t7 l1 [6 y5 O
角色分工

7 i$ O4 ^1 W+ R% N

3 _+ Y' t6 ]2 W# a  i$ w7 v6 p2 y
1.png
3 n* F7 W# u, o# n! [# Q

4 j& |( q! Z0 O7 ?; o7 N
模式上,开发和测试做一些转变。原来的模式中规划完成后,开发将产品开发出来,打包交给测试。

7 j4 u' {  w! ?, q+ h& L+ [
4 Z$ _( V! H- H/ _- r
而新的模式下,测试从第一天就要参与其中,提前进行测试设计。

8 m5 U' c) {$ p7 l/ K; p% X$ W
! P- J/ X, \- ?, U% r9 `
开发与测试的配合——思维转变
7 F$ k9 Y+ h; `4 o% x% w0 `
角色分工

3 d* C  P, @: k5 X! E( Q6 [

. g2 |4 i: A) U% [
1.png
+ m- h& J; d3 i6 Z/ k+ I
) f, V" {1 }8 w7 @
开发与测试的沟通,需要整个团队进行磨合的。前面提到,测试从第一天就进行测试,不需要开发来进行信息传递,而开发更加不是测试的上游。
% F  ~+ p& U1 X& g6 C7 s+ }

8 q; q8 ~0 X" g: X& D
未来,开发和测试边界会越来越模糊,测试也需要把重复性的工作进行自动化。
! m- ^; c3 K& }4 \

; ^0 O+ P" `# C& O
角色缺失
6 n$ X$ t4 L4 }. u- v9 C
角色分工

& B( e% a9 L, P

2 V& ~7 \4 a. @- h/ x5 A3 d' L
1.png
: \# ?  Q4 \6 L, {$ u9 ?& q  c

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

) @# V! g  @% o3 w2 L3 \
9 B, z1 a8 f1 i# f; M, B; N0 b7 J
, ]6 ^+ Y/ W- _7 ?% y1 @- V% ]
日常活动
: S1 G+ y# X6 ^& m3 P

$ O: P, p8 k- i/ J& @
Planning Game

- k) N3 E8 Z/ o0 I' U  P& R
日常活动
$ R1 {+ G6 A, {/ \  |0 ]
1.png

3 |* I) `( g0 T1 i# J! h
" j- U2 V0 Z$ q5 G8 E8 G

" P' O' [5 n9 k
Planning Game以前的标准做法是给大家一副扑克牌,12358斐波纳契数列数字牌。现在我用Gitlab比较多,将Planning Game的所有内容列上即可,然后大家做大体迭代评估,而不是精细评估。
+ K( N( s* \: C5 B8 g7 i- }, `) F

9 _9 P$ ^% D  X3 n  c) S
有几点经验分享一下:
4 M- n! w4 ?3 B, [4 W5 F% Z2 d
+ f& F: B* L" Y! A
  • 第一点,要负责好对应的范围,不要在一个版本里面,将所有的大功能都选择上。当把一个版本里面的大功能选择完了之后实际上等于没有选择,因为范围越大,失控也越高。 选择一些小功能或不重要的功能,作为风险缓冲。

      f+ n% R& n4 _) O4 m% j

6 A) `$ s7 d  H3 k5 V- r9 K0 t
  • 第二点,需要预留出技术改进的空间,什么时候做重构,什么时候做改进等等。

    ) D( B) y3 B! ~8 I- g3 q
; b' h6 V- F% s  T
  • 第三点,迭代的周期,两个迭代出一个版本,最好是两周完成一个迭代。以版本而不是迭代做发布,预留出一周的时间做发布缓冲,并对下一个迭代进行规划。
    / D  V! x: W6 p* @! b

$ L- A2 m9 Q) r' t4 x
" i2 p2 c6 W$ w) l. S2 |
Standup Meeting
/ ^9 `& h. z) P6 I
日常活动
, P8 y( S; q: n7 B
1.png

) [/ S2 r1 h5 @; \5 b& s; b7 o; q0 N

$ Q  u; {$ n" C# L% a7 s

" S2 i0 n( w- x5 f. i% L; l+ I$ |6 w
当团队比较小时,没有必要做的太重,虽然现在已经出了电子白板,个人的经验是用真实的白板操作性更好,更能体现哪些事情有关联依赖性,哪些人在做什么事。

; d+ B: S2 a+ N; X

' K7 [, r5 p* g3 d( ?, `
需要强调的是,每个人做的事情是自主的,但需要架构师掌控好,有限度的做出选择。对于非常重要的事情,要选对的人去做,而不是随意去做。选择的纸条项目要控制在两个以内,具有难度的要让架构师去做设计。
, O2 \0 l9 r0 z. J" R9 u" q  z
9 v# P; K: Z# J/ x: @" |: t
Review Meeting

& N# Z8 O, s+ [6 f, o

6 `" b2 C% c# u& R1 r- I
日常活动
# D' I+ X" s2 W
. R, |) S- ^. v4 N2 Z% X
1.png
! |, a8 ?0 t, s" f9 S

7 _" H3 h. o: B- O% L3 Y6 [" i, h
敏捷上开会还是比较多的,但内部要想办法有效率去开。Review meeting包括设计、代码、测试 Review等。大功能设计,可以去做从三分之一到二分之一再到完整的Review,这样可以减少返工率。

* A* u9 F6 i# B' T# V! A  @
1 _5 M6 i: R& v- l
End to End Demo
% y2 E. U- E9 `% `( ^: {: P, V3 m7 m( M
日常活动

* Q3 C7 [$ l, b

$ l! Q6 H9 N; ~- q. {' ]
1.png

; B( U* P- Y8 N! @; g6 J0 f
, L- @- D! f$ U. ~5 a! t! p# Z( X
尽快做emo,越快越好,能跑场景即可。不要让产品最后才看到Demo,也不要等所有的东西都做完,同时团队成员注意现阶段不需要挑刺。
! l5 t3 H: s0 I; i; n5 k+ J

. _* W4 u# p1 K: N' b, l& b/ y3 g8 [# _
DOD meeting
! m) o8 c+ b9 l# H& P
日常活动

+ }+ j% [% p- m# u% o* P9 n
$ Q5 m% h& }8 `/ ?
1.png

- _- K7 E) k& T- g. O

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

: @& z: H) B1 c. I9 C& k" {
$ G8 y4 |  B% O6 s
Retrospect Meeting
$ ]( [9 B4 I, v4 `  }
2 g& Z) f/ B/ \7 {
日常活动

" T7 j* e- V9 X$ y9 J& o
: w" C8 |( _* ~! r  B+ t$ |
1.png
6 ^( U  Z4 F+ h/ y- ?

* U& C3 |" u. m: d% W- {/ `
定期做回顾,通常的做法是拿便利贴写三点——对每个方向提三点。选择一个轻松的环境,每个人讲一些。而回顾会的意义不是批斗或者拍马屁,曾经有一次开发把产品经理批斗的很严重,产品经理反过来又把开发骂了一顿,以上做法都不可取。
! g* ]' W% {- I3 C/ |/ B) R, c' d

1 ?$ J1 {0 P8 L' R
产品运营

8 [) a4 n+ g5 j- c+ H, J4 }! b  l
日常活动

0 m" G( s& ?% k9 x% s- w
1.png

/ i" @7 e. {0 i6 d

2 d) [8 A0 N5 {! _% |
整个团队也要做一些产品运营,无论产品是对内或对外,包括客户支持、数据分析,以及对内对外的分享。

3 [& z5 T/ L7 P+ K% L  \9 \* r$ h
) h# P7 c3 F2 [7 ~
PO的工具

/ s( g7 E/ L; Y) H1 |! \
迭代版本范围的选择原则

3 D6 p  o2 V) J9 ^/ W+ I
PO的工具

3 y- J; E* }7 k4 D0 ?% F

  \' `9 A+ M- C
1.png

2 u7 q& C1 M7 Z4 Q$ e  @( s
3 k; b: M( f3 m4 ^" p7 y
4 M2 t% O3 g( x7 a% P
每个迭代版本的选择,对于产品很重要。一句话概括这个版本的价值和目标最佳。要向团队成员澄清目标,否则团队成员可能不知道重点或优先级。

6 @" u( U3 e4 A1 |
; u) t% H7 V2 j' k, i
版本细节定义

+ ^+ x- s" P: f# [: S+ x2 h/ s
1 C  K3 Q9 \( Q/ y" Z
PO的工具
6 G& |5 ~; {5 ]6 l0 w9 ~
0 x1 k0 [4 t% h, T1 k6 M6 f9 u% I
1.png

5 v% j) Y- m9 s6 W, e
& B: _! L% C, R. Z6 X
版本细节定义可以用鱼骨图表现,标注版本、周期,以及重要事项等。
2 K3 O. B8 W' a) d, l# q

+ |& K/ h8 i' i. O$ m
Backlog/PRD管理

+ p$ b5 y( e' `- N
PO的工具

" o8 z& H( ]! Z5 ?
8 Y8 {% [+ C* t1 H3 N% A9 U/ h: D8 N& |
1.png
2 y" z& n  b/ |$ Z* ^  H7 D0 p

5 D! g1 N! a# {% @. l( S
9 F* W( X5 I) l

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

: a( z$ v, I! ?% i

2 V* N8 k1 t& }$ l& Y$ c
小公司做产品时容易忽略Backlog管理,想到哪做到哪。Backlog的定义详见PPT。
8 U/ s! b2 {) e* `& ^/ T
! y+ F' D; @* z5 [5 q
产品功能地图

0 Y. }* _$ ~0 Y' ?
PO的工具

6 _2 j! H0 Q9 m7 D+ y

9 k6 v& e6 t4 g3 S
1.png

) U- n2 P+ J4 {$ A. p6 e9 Z; B
产品要做功能地图,用脑图的方式归纳整理便于大家理解,另一个好处是便于开发和测试补充遗漏,如果运用好功能地图,会更好的沟通,以及做功能之间的相关性测试。
# e  K- ]$ H6 P( z1 B

4 p6 S) e. e7 Z1 o8 d
任务拆解与管理

/ u, \5 E( C  M

7 U9 z. {3 D7 X. ?6 }- T
PO的工具

, K6 q: X5 f/ b8 p/ K% ^/ J
1.png
, Z8 T  Y; l4 m9 A+ \1 \0 n# a

+ t: ]% Q- W5 d, C/ p: S! q
任务完成后需要进行分解,用Gitlab的Issue方式去管理,每天站会时汇报工作进度,测试对完成的功能进行测试,细节需要讨论的,和测试提的BUG直接写到Issue上去即可。

9 W, }$ Q# Z: R! y& y6 v
+ s0 ?& o+ _. C
版本Release Note

4 n/ O# a# }* o/ I+ H
PO的工具

( s- y7 e/ I6 A. p" _& `9 Y
1.png
" _; P" ?2 \  y  s
! a  R* f  p% n$ z
7 ?, w9 q6 J$ z" [- k# k( y
每个版本出来都要写上Release Note,不少公司更新迭代多个版本,但是连一个Release Note都没有。Release Note建议要写一下产品是否对其他产品依赖以及依赖的版本是什么。 之前犯过一个错误,出了版本后,由于产品已经出了多个版本,而之前依赖的下一产品版本是错误的,则导致现有产品的版本还是旧的。
$ V# p5 f# |' ~! v2 m
+ E" f$ l. P' I: H) V
内部版本定义规则
% ~, L1 v4 ~; W- ^3 T# \! j
PO的工具

6 k' X9 o/ z) z5 B" V+ P4 B, }
1.png

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

$ j9 K8 w, w* P+ V2 j2 y5 S
5 m, ?  H7 u5 `. b0 }; U. @0 U
总结6 s/ b' o, I/ f- X- J$ z
6 X+ S3 \; Y' h' H" v
Scrum模式开发经验分享

; i5 R; @( i" q& _
1.png
2 c; a1 c8 T9 u' r5 }+ K

8 V% [" B) y- ~0 L. G$ o
. X0 V+ R2 z% a) N) }
最后,整个Scrum模式希望大家根据团队情况,来调整流程和开发模式。人是活的,流程是死的。没有明文禁止的,都可以改变和调整的。

, u9 E. q' f1 a6 o
( ^- {+ b! s- J6 Z1 G0 u
8 A7 w, u1 Y3 H, ^  l
原创:了哥(邱戈川)
  s3 I3 a7 C8 x  u




上一篇:新鲜出炉2017年的 DevOps 报告
下一篇:DevOps创始导师首次访华内容全曝光-传播最正统的理念和方法
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 04:10 , Processed in 0.139626 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表