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

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

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 337|回复: 0

敏捷是DevOps的本质

[复制链接]
来自- 广东广州

参加活动:0

组织活动:0

发表于 2018-9-22 09:30:22 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-22 09:36 编辑 % K. V( p/ J) r( v' {3 I
4 I9 L+ j. v% S4 M. a/ m" @
4 I% {; Q7 ?" H

9 ^; |+ I  h. L9 t* W+ x7 A
前言
' ^) ?( S2 {( W9 l- z
Scrum模式开发经验分享
1.png

) v  g9 c- K1 u

9 n1 J3 }" [2 N/ `  {. s$ Q' U8 F

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

0 K0 Y% ]( G3 \- h& y) y, X
& P# {1 \+ ?4 G- K, W
主要有四块内容——敏捷Scrum模式概貌、人员的分工、日常活动的细节、以及一些可能用到的简单工具。

2 ~* ~. z2 D& o# J# W
0 H7 F% O" I# E& h
现行开发模式及开发过程中痛点
% u  U9 p% w- h; W* F" \
敏捷模式概貌

/ Z# ]4 t7 a1 k6 g2 ~8 g
1.png
4 u4 P+ H3 o* V( c$ p; }

- ~5 g* W$ U2 B' [. I% |
Scrum已经用了很久,但为什么始终没有用到极致或者很火?
: [" ?( S" p. L  z% W& Q6 p

7 M/ z5 X' n: |3 L# C' M
  • 大家都在做大型系统,Scrum模式难度稍大,链条过长。需要开很多协调会议,沟通成本高。

    , s+ n" n6 o. W5 L) F3 Y7 y

0 X* N/ `/ I  i. d0 Q* w. ]
  • 微服务和容器化让团队规模发生转变,从以前几十人的大团队转变成现在六七人的小团队。

    ! j  \' {3 Z- @4 c$ Q6 O
4 K( o. W5 P+ R
  • 客户及运营的需求产生变化,从数月至半年的交付时间转变到几周至一月的交付时间,使得业务更倾向于快速迭代、快速交付和快速变更。
    6 M5 u0 l% l& [* I5 h. J" T! G6 t- v
; Y$ z; l+ s3 J
什么是Scrum

9 X7 s" m- s$ y" {' \
敏捷模式概貌
: M$ Z. |: x$ o: v
1.png

( J: ~" @  e( U4 A+ l: l% w% I

) u) o1 i% w! l1 E
上面这本书详细地介绍了敏捷,这里就不再赘述。先提几个问题:

  r0 T2 l0 k; h1 x  b  y+ I  d
$ x! i7 v! y+ u* p, k
需求主导:通常需求都脱离于团队之外,上司或老板突然下达一个指令并规定出时间,而自身的事情尚未完成,所以在开发上需求到底由谁来主导?

8 t0 k# l. {# G% j) Y3 b

/ q" l- d& m; ?
流程主导:很多公司都有一套流程来规范每个团队所做的事情,应该团队来主导流程还是公司主导流程?

* I6 R9 ?* [3 L- T' ~# J
# q3 v! g9 R* p! d' N
颠覆还是改进:敏捷是不是需要把以前的东西推翻?

0 N' r/ e+ k) i4 k, s
1.png
/ {6 h. j) }9 }6 [& S' W
3 F2 d" f9 R8 `
什么是Scrum?SRE、Scrum、DevOps之间的关联是什么?
' C3 M7 x: y) ]8 D- ~8 I

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

. j8 F1 J4 g* k9 \* U; V
% U4 ?8 C) S  P. X. Q
个人理解SRE更偏向于运维,涉及一些开放性的DevOps工具或开发工具,它离整体的软件开发交付还有一定距离。
$ ~1 {. M( Y* O% Q$ s' A; i0 E
5 @' E( X8 p% G, d
困境
$ ^5 z$ e- V' X: C
敏捷模式概貌

+ @: G! G# Z2 y2 W2 A
, b( U" [9 Q9 u; N
1.png

; |0 J; q/ k. V$ t

* ~: `  @. w3 V2 }$ _$ |5 r7 w
很多时候,大家觉得敏捷开发、DevOps的模式及理念很好,但很难落地实践,归根到底是需要做的事情太多。其实这个时候,无论是团队还是管理者,都需要停下来,做一些思考。

" a8 U4 p6 G! e3 H2 z. l6 x

& X4 c9 g5 \: y0 d8 u& G' W

7 c( i3 S+ D. @4 G5 y
自运营/服务模式
6 s4 e8 J5 u4 d+ E+ Q6 e, a$ e
敏捷模式概貌

/ G/ m- M6 Y$ I. M. [
1.png

2 [7 Y% f6 y8 `9 L  t% }
, ^7 @5 m7 W  @5 `0 e
N多业务团队并行,由产品或商务提出需求,但通常只有一句话。也会有一些业务分析师,把业务做好澄清后导入给团队,每一个团队产品体系里都要拆出自己理解的PRD,然后再自主规划版本,最后实施完成推送上线。

# B: n) i7 V: _8 z% g. g) J* ], }
0 ?% U) \3 P+ K8 o
需要强调的是,敏捷在运维模式下很难做许多个产品统一的测试联调。一些大公司为了某个功能,将所有的产品功能对齐,等全部功能出来后再联调、测试、最后才推到市场,这是很值得“敬畏”的事。因团队和内容数量庞大繁杂,因为团队的数量,涉及的内容已经很难这样去做了。
* {/ v$ m; W( p" G' c( h( ^
, [; k: b1 X! i8 L7 j( f* F" K
受团队数量和涉及内容的限制,最好的方式是谁最后上线,谁最后做整体测试,以此为约束。

: S* l& }9 ]0 P, v8 `& [  a
. j" ?: H/ z: N
团队构成

! ^5 ~2 D) a4 ?& w" |0 ]
敏捷模式概貌
; g* [. E. U2 G3 I& |+ K7 X4 Z5 }' K
1.png

+ C( T" j) U* t" L( p

. ?$ A. L9 q& [/ }, O$ x) S
上图即1-1-3-2模式,这是简单的实践做法。3 X" g" B2 |' I( d) c

  z# [( U$ E# J3 T" D. _

0 d. w( g) |" {. c' p
关键性角色包括:

8 o2 m6 c, t9 l# C

0 U, B; W) ^0 c/ H  B. s9 t2 e
产品、架构师、开发、测试。
" v4 c) @$ C7 i$ t" m$ L* L( N

) s& z7 H. C4 l- H0 E
找到合适的产品和架构是最重要的,开发和测试从哪来(如外包)其实并没有太大的关系。
3 y* d2 e" `' w

( Y; t) a& f1 U
沟通链条:

7 _" P: X5 H/ Z$ p# k; f9 Q& m
8 C6 I! }# [$ p8 B9 u  a4 Q' I
以前是产品→技术负责人→开发→测试,这样的顺序链条。但现在因团队人数的关系,所有的需求范围应该由产品直接对所有人进行沟通,以节省成本。
' H( ~+ U. |  u5 d
" \* b6 E  @: k7 }0 g
需求澄清要由产品来做,实现指导、实现方式则由架构师来做。产品决定做什么,架构决定怎么做,这是非常重要的一点。从而营造一种氛围:外部提出的只是需求,不是技术方案或实现,技术方案和实现要由团队的架构师去把握。
4 i8 L% v/ R3 \! v) c

/ w$ T% L! G; ?" v% O
在团队中,可能有一个测试,四个开发,或根本没有测试,取决于团队自身情况。
; d% C7 E, J5 y- J6 L; z+ h
1.png

/ u& N( D- e" X2 g$ \& N
2 ?) q* L9 z0 c5 p0 u6 D$ @& o
% V, J$ W+ T  r* l8 L0 y
公司规模较大,团队数量较多时要视情况而定是否做Scrum to Scrum,不同的PO在一起协调和澄清每一个产品或大的场景下的分工。注意:开协调会时,要把范围控制在少数人,而不是全员大会。
6 _3 U& k8 I) d: w; f7 X( C6 G

0 o$ p: M7 M2 p. f: n7 t7 ^
角色分工
$ S' @  n- D  r' s3 g; g
$ c) }+ \% A: p5 |+ G
角色分工之前已提过,但分完工之后,还是有很多人做了不该做的事情,如老板去做技术指导。
5 a, s8 O/ C( r- j
) V( x9 K" f0 O. }4 q# H, P% `
PO

% S) k: ~, S2 h
角色分工

/ D4 }7 c. a! \+ ?

% [/ G5 B0 `! P* |
1.png
+ i5 d$ U. m# f, ?' i

1 x) g0 I- A( _4 g' [; [( c
不想做好测试的开发不是好PO,也就是说,一个产品做不好测试,做不好开发,那也就没必要去做产品了。几个比较大的要求点:
. y! t, z* V- x. p& M7 Y. M5 g0 F& s5 l
  • Roadmap:需要做整个产品的Roadmap规划,至少要给出每个迭代有什么,有几个迭代,每个版本是什么样。
    5 |: @! J" r) _8 ~/ X
! ^8 Y/ _$ g( E/ O- R" R0 A+ k1 L
  • 迭代范围:产品要控制迭代范围,很多公司老板说什么就是什么,导致团队越做越混乱,所以产品经理要做好澄清,对外承诺的范围要掌握在手里。
    8 V4 N4 C& C5 m3 k" z, F% ^1 H

9 l0 u6 \* p* B& f/ }2 K2 Q
  • 产品生命周期计划、特性Demo、推广等等。另外还需跟架构师配合,沟通产品规划中每个迭代与技术产品相关的改进点。
    ; _/ ^% w" Q6 D7 K5 b
, p, ^$ g$ i3 M+ q
架构师
% B9 K/ @* ?# [% B$ v! C) m. X4 E
角色分工
; m' k7 |1 n, G: Q3 F  ?: @
1.png
) C: e- r6 k& K, R/ [! [7 p+ i# w

$ U# i( n" g6 s8 x/ x9 H! z) W
! G$ s/ W; i) ?( J4 b& |+ [7 B- p
架构师需要做好实现架构的设计以及相关成员的指导(如开发、测试),组织相关人员会议,做敏捷不代表不开会,甚至一些小团队内部之间的会议可能比原来的会议还要多。
5 m/ Y& e) C, {6 @+ d  O; R
开发

" J- A# N6 w% Z& a% m
角色分工
) n) M' b9 N$ R' k  g0 _
$ P2 ~: K5 U/ U8 w2 m2 U9 t4 I
1.png

+ b: K% d, e$ h1 E
: W* ~% p5 `. q/ k: y$ B
开发没有太多的变化,唯一要做的事情就是开发要把东西做出来进行展示,让代码尽快可见。
& i% C& z5 F; L0 ]

- J& p* \7 T0 ^
测试

& l. F3 A* T$ Y. e) r
角色分工

9 {* O, H6 }3 G- P) ?5 r
1.png

8 n7 Q0 I, Z1 z% {
3 H) i7 g$ \8 B7 \5 }1 O" R" S/ g
测试最大的问题是很多时候被抛离团队之外,因为测试总觉得自己是最后一环。很多公司以测试Case数量作为考核,这是对于测试人员最大的误区。
; c$ p  W: y. `+ l

$ v; K0 W4 ]: w2 w* y3 t0 |3 ?
理想中测试主要做测试设计,从设计角度来进行测试。测试驱动开发完善产品、弥补思考上的遗漏,同时很多公司的开发把测试当做助手,呼来唤去,是非常不对的。
8 V; c2 x7 ^. m

( x- q/ A" _4 I2 l. c' K  w
开发与测试的配合——模式转变
: H/ V6 D" J' r8 E
角色分工

1 U% Q7 ^0 E$ Y. s) E

7 R3 z4 B' W1 H! `, b- w% i0 q
1.png

' t* Z) x2 \; k' q
+ y9 H8 f( ~8 y; |  }% l1 U
模式上,开发和测试做一些转变。原来的模式中规划完成后,开发将产品开发出来,打包交给测试。
' p0 Z# h9 h) E

+ l# Q6 c9 L4 p6 e, `7 Q' ?
而新的模式下,测试从第一天就要参与其中,提前进行测试设计。
# A( G; H0 a' U' J( y4 P6 n8 X9 C
" X' y7 l1 M' ?; ]
开发与测试的配合——思维转变
6 a0 n' p. C$ z" k3 W
角色分工

0 n3 s) v) `2 W+ w; n# V1 q/ `

# T) N# h6 e4 x. ?! s
1.png

: y% ^; Q" U# B, e3 U  m9 j6 B

# {# o" \. e5 R1 ?# S8 l
开发与测试的沟通,需要整个团队进行磨合的。前面提到,测试从第一天就进行测试,不需要开发来进行信息传递,而开发更加不是测试的上游。

5 E4 M/ F) L* J8 ~8 Z: x
- _$ i/ R2 a( u' I
未来,开发和测试边界会越来越模糊,测试也需要把重复性的工作进行自动化。

$ S" I8 C+ J8 a8 I8 N

: J$ t2 x' f5 @0 G" z8 Q
角色缺失
6 Q7 t, M8 D! o) w/ i/ R
角色分工
9 T! a  {- {# L! V4 V% `
/ |+ l/ P1 u. y& Q; {
1.png
: ^4 D. S  Q( q7 u2 D$ f1 T9 i8 [

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

! E1 j$ T8 B2 {9 \3 r0 {
; w7 R6 c( G1 p0 }) M+ [

& J' ?+ J" h2 ]9 o
日常活动
# w: V# n3 u0 G' u

* v2 y1 U5 s: U1 o2 p* O5 H$ E3 t
Planning Game
' k7 w9 w( g' n
日常活动
4 l* @5 b. x* |" f" F
1.png

3 O7 e4 h% l: U5 m
. H; W! w" E4 D5 A( k6 V1 C
4 f! v% |" D! E5 K& j, R6 }2 |/ a
Planning Game以前的标准做法是给大家一副扑克牌,12358斐波纳契数列数字牌。现在我用Gitlab比较多,将Planning Game的所有内容列上即可,然后大家做大体迭代评估,而不是精细评估。

9 U) S3 j! _) Y1 u6 ]& S! V# u

- |6 P" w: b# f% H2 t+ Y6 D! E
有几点经验分享一下:
  d6 C( b8 t+ _3 _" }! P$ w* p6 A% G* b
5 h8 K9 O( b) V( ~) X( y1 t; K. {4 j
  • 第一点,要负责好对应的范围,不要在一个版本里面,将所有的大功能都选择上。当把一个版本里面的大功能选择完了之后实际上等于没有选择,因为范围越大,失控也越高。 选择一些小功能或不重要的功能,作为风险缓冲。

    " ~% j) \7 g9 `+ z# z* K9 h
9 c4 X# u8 z4 y$ [  M( |
  • 第二点,需要预留出技术改进的空间,什么时候做重构,什么时候做改进等等。
    : O, K- O, G* F+ l. z( x6 I; G+ z
( M5 J& e" {. k  u! U& x( X4 [
  • 第三点,迭代的周期,两个迭代出一个版本,最好是两周完成一个迭代。以版本而不是迭代做发布,预留出一周的时间做发布缓冲,并对下一个迭代进行规划。
    7 f2 ~. f) ]- Q: p& X2 A# F& a

1 E, c8 d/ M% v8 y8 t' B* {

% Z. t* G! P4 F- I3 x1 Z
Standup Meeting
) ^4 l) P! R& r% a2 X' J4 }
日常活动

: N  D$ J) j6 I
1.png
( W% D5 {8 K6 n8 I4 a
$ _$ _4 b! U/ ~, \4 L

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

9 y) T2 G) M' B1 V( \
6 y4 w; P8 C% e" a3 |& w9 o
需要强调的是,每个人做的事情是自主的,但需要架构师掌控好,有限度的做出选择。对于非常重要的事情,要选对的人去做,而不是随意去做。选择的纸条项目要控制在两个以内,具有难度的要让架构师去做设计。

* ~. z1 E. b. h' x: u
% O1 A6 _4 i7 f+ n
Review Meeting

( y% N" W: B: J

- h& W, b" g9 I. Z# K
日常活动

, i9 @: ~) a: Q% \  A& c7 m9 R$ u
  Z, i' C" T; |- c# ^7 g+ n3 y
1.png

- e* S6 S2 c, V# U* ~
9 e  r+ q* Q7 e6 C) M8 l
敏捷上开会还是比较多的,但内部要想办法有效率去开。Review meeting包括设计、代码、测试 Review等。大功能设计,可以去做从三分之一到二分之一再到完整的Review,这样可以减少返工率。
* ~2 F" H2 M! o9 |/ v- {6 q

5 q; s  |4 E  o8 N) k) U, F2 V
End to End Demo
' h3 ~# b) O  P# N8 V8 r
日常活动
- s' b& \5 Z3 J" C+ g* C0 n; U5 ]: _+ s
! L& B% {# ?4 q/ I  A" B
1.png

( _3 D* J3 f- c7 j: k. j
" M5 ]/ ~, j+ P, M
尽快做emo,越快越好,能跑场景即可。不要让产品最后才看到Demo,也不要等所有的东西都做完,同时团队成员注意现阶段不需要挑刺。

' y- S- ?2 `1 s

5 X1 u4 P8 A; {" C
DOD meeting
' {2 V! \: ?! X, E( P7 e) ]
日常活动

" C9 t& B4 B0 a, n
! B( s3 u9 o4 u1 d# r
1.png

8 V5 M/ u' @- [
9 C+ Z0 Z# F! T, C8 C/ J
DoD Meeting最好以迭代的方式,而不是版本方式。第一个迭代的DOD,要为下一个迭代做好风险控制。哪些是能做的,哪些是不能做的,哪些是需要自己做的,哪些要新增,都需要作出及时的调整。
6 Z' x3 U( A5 F6 p  f* i

6 O; @7 z9 G; q* j
Retrospect Meeting
6 ?0 R0 W$ E( o( Z" |
# \2 @0 q9 M( e. V8 m
日常活动
$ X3 i# g9 Y. ~. W/ T/ S* _5 E
6 f/ Q9 e  _; H4 f" h& a
1.png
- u5 x* `) d8 }# P; D2 W( L
8 u' e, b, o5 A8 l) V+ n+ Z
定期做回顾,通常的做法是拿便利贴写三点——对每个方向提三点。选择一个轻松的环境,每个人讲一些。而回顾会的意义不是批斗或者拍马屁,曾经有一次开发把产品经理批斗的很严重,产品经理反过来又把开发骂了一顿,以上做法都不可取。
3 p% ~3 }$ o- V( L/ X2 n

; q; i. ^# V) }% L" N
产品运营
9 Z+ |" H$ n% X- i( U- b3 Z, f7 O
日常活动
3 o. f0 x1 m* K
1.png

( @& W/ V- s. c3 g7 p+ e
5 J1 C: \& v/ j3 W# J
整个团队也要做一些产品运营,无论产品是对内或对外,包括客户支持、数据分析,以及对内对外的分享。

& `$ C, p/ n3 d; ~4 @. b- A: A' }
2 j' }1 G' l& [& @
PO的工具
7 E  C6 B6 m& D$ V
迭代版本范围的选择原则
' m% |: ~. w6 f/ I" X% u: |
PO的工具
$ I' ^6 R0 E: e' ]) S- |! R
' ]% @* [2 W3 J- [
1.png
4 a& ?& c* [5 ]% U2 \9 y
$ I# z9 Z5 K! v- E1 l8 h* u! I

8 E0 k5 c% k% V! B
每个迭代版本的选择,对于产品很重要。一句话概括这个版本的价值和目标最佳。要向团队成员澄清目标,否则团队成员可能不知道重点或优先级。
5 R! a3 i9 R( G3 H2 _' S
# s4 ~/ t5 w; `" O8 T. O
版本细节定义

0 n4 v7 _2 t+ e9 f) V$ R
- a* ?/ U7 v  i* o/ u  ~
PO的工具
9 i: L1 t; k. v. ?& A

! q: c7 c  G  B4 o) e
1.png

* E+ D+ b0 l1 e! U) W

: H' W8 _0 l* {: K/ r" Q
版本细节定义可以用鱼骨图表现,标注版本、周期,以及重要事项等。
) }5 j7 A/ k( A9 X$ ?

' S7 J- f8 p$ e5 h
Backlog/PRD管理

' U6 v- U# F; T, X( w+ N3 N
PO的工具

) a" o& U- U( a+ Q& F6 u* J

2 R/ J2 E. t0 W" s) B( T+ K
1.png

/ ]) T3 B9 p6 t; E: R0 I; e9 X, _' m
6 |5 G0 F3 g& @- I2 n
* S3 \2 l( }4 q3 |# }

2 \  {8 c9 Q+ _$ A( S
Backlog无需和代码绑定,在Wiki里进行管理即可。虽然Backlog很多时候只表现粗略的需求,但其好处容易与相关团队成员达成优先级别的一致。
7 Y2 E7 Z: e9 x0 S0 E  @7 K6 n
. H! h3 l  s, r# A' [3 I* e3 q
小公司做产品时容易忽略Backlog管理,想到哪做到哪。Backlog的定义详见PPT。

5 {; a6 W7 L" `! w7 n

3 F6 q& ?/ S8 j  t1 u
产品功能地图

  _8 V3 j/ v6 u# b) Z
PO的工具

# m% A8 p$ R+ X3 L

, B" u( K' y5 u% a1 v
1.png

' e& D& ]" p2 q/ s  ?6 [
产品要做功能地图,用脑图的方式归纳整理便于大家理解,另一个好处是便于开发和测试补充遗漏,如果运用好功能地图,会更好的沟通,以及做功能之间的相关性测试。
5 F. z8 N- R4 x1 S; j
" Q# s# D! R. a# ]: G- x" E
任务拆解与管理

) e9 A) B% n# b+ {7 E; z# g' |
) m2 y3 J- @$ ~) `7 r
PO的工具

5 U- k. p4 S) _) e  G3 ^' n
1.png

. v1 P: n* r4 i* K6 q& ]! M# w) k

) Z9 H; O; x8 {0 a3 L( }- G+ Y. U
任务完成后需要进行分解,用Gitlab的Issue方式去管理,每天站会时汇报工作进度,测试对完成的功能进行测试,细节需要讨论的,和测试提的BUG直接写到Issue上去即可。
  _$ R3 t: V  B- x% A$ ]0 a6 M+ }/ |
+ I( j- O- e! H5 E8 r! o
版本Release Note

  G( o" m. d% ]/ b) P. p
PO的工具
4 o( o$ {  q- V# Z) c
1.png
! z% z& f2 {4 N& ]2 W1 s- @. q4 D
$ {+ j1 P# i1 Q  @% ^, }1 {

2 T( \& y7 n: K" e6 a! P. [6 G
每个版本出来都要写上Release Note,不少公司更新迭代多个版本,但是连一个Release Note都没有。Release Note建议要写一下产品是否对其他产品依赖以及依赖的版本是什么。 之前犯过一个错误,出了版本后,由于产品已经出了多个版本,而之前依赖的下一产品版本是错误的,则导致现有产品的版本还是旧的。

2 j/ h! U1 }- I

, s# O) O2 x/ c5 \$ F4 q
内部版本定义规则
9 V3 ?5 Q7 R/ R
PO的工具

: |4 A* Z5 ^: z. p& f2 n" ?# [
1.png

% S' F* u6 ~' p! V

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

" x( }- M% i7 |. W' w

  Z; _' D0 K  g7 w) V/ u' v% b
总结* ~/ Y) I% R( ~7 k5 k* {  E2 }$ ~( Y

5 [3 Z: E/ `7 S& Q
Scrum模式开发经验分享

0 X  ^$ i* C( T6 r" U
1.png

1 F3 \/ p/ T+ K+ ?0 [+ H/ Y0 r# V
5 b& ~+ w) t6 Z  I" U4 z2 y' ~

* N6 p% ]8 f* c: f; m9 I, l7 V3 A4 L
最后,整个Scrum模式希望大家根据团队情况,来调整流程和开发模式。人是活的,流程是死的。没有明文禁止的,都可以改变和调整的。
  L% A! V, M4 I6 I: `
, |; G( d7 Q- P4 T/ H$ @" C' U

  d+ }3 C; Z: z原创:了哥(邱戈川)# t5 a' L$ s6 f

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2019-2-24 13:45 , Processed in 0.249981 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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