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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

敏捷是DevOps的本质

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

参加活动:0

组织活动:0

发表于 2018-9-22 09:30:22 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-22 09:36 编辑 + b3 `0 m9 {4 f; J7 l# f- v2 `

& P' ~' U, W  d6 S% m- v. Z9 Y9 x, G4 l! i: Y/ }8 Q) K) v* y$ u5 e
# q$ b% r1 C( L4 b3 m! L
前言
8 s- O! X- p) I  }- _
Scrum模式开发经验分享
1.png
6 s% F  ~! I: Z- a2 g! `
  ~6 U1 q% x  Z, T# a
2 ^; }# }5 A, X
Scrum出来已经很久了,很多原理性问题就不讲了。今天和大家主要分享一下Scrum实施过程中的一些经验和对其的一些感受。

; U. L0 j  _6 y5 i6 }& X
! h, _: a3 I/ x5 j* I4 o
主要有四块内容——敏捷Scrum模式概貌、人员的分工、日常活动的细节、以及一些可能用到的简单工具。
' C5 X8 T6 A4 C; ~- F' b0 M0 q' ~

+ K* Q/ E, w0 z5 v. Q
现行开发模式及开发过程中痛点

" K& t& ?. o3 e- B6 h, G% I$ d  p# z
敏捷模式概貌
" |& k2 D; R. p
1.png
/ a- t  I6 W( d. J3 `9 W- h
# z) G: G2 I. M
Scrum已经用了很久,但为什么始终没有用到极致或者很火?

6 f6 I- s; A5 I: t( S7 G

2 l3 B2 }6 H) V5 z! @
  • 大家都在做大型系统,Scrum模式难度稍大,链条过长。需要开很多协调会议,沟通成本高。

    ) x. F1 y8 o9 _5 S) ?% l

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

    + y3 m5 u% n, ~- G( @
" ]7 Z8 s) l* l  e
  • 客户及运营的需求产生变化,从数月至半年的交付时间转变到几周至一月的交付时间,使得业务更倾向于快速迭代、快速交付和快速变更。
    8 ]) X5 n) y# g- L9 z, f

3 s2 M4 i' s0 {- l' Y6 Q8 j
什么是Scrum
! W7 z: v  y; j* Z' [
敏捷模式概貌
: P9 q0 W) ^9 D5 G6 ^5 e" ^
1.png
4 ~4 g0 D6 m  J6 S

) _9 t) N$ T3 P7 h, p
上面这本书详细地介绍了敏捷,这里就不再赘述。先提几个问题:

8 D8 r8 x! y! p- a5 F5 O

( S$ _* h0 ~5 h/ ]6 O9 H0 A) X
需求主导:通常需求都脱离于团队之外,上司或老板突然下达一个指令并规定出时间,而自身的事情尚未完成,所以在开发上需求到底由谁来主导?
1 b. W$ X8 u2 }8 a9 _9 H  z# d+ X

- M( m4 U% i5 y) c) X( g% y# @
流程主导:很多公司都有一套流程来规范每个团队所做的事情,应该团队来主导流程还是公司主导流程?
9 r3 W3 s0 |9 r' i; i5 a
. c8 D* p, R1 X3 w
颠覆还是改进:敏捷是不是需要把以前的东西推翻?

  p: ^: A& f# l3 K: q
1.png
' R7 [5 D; s) U3 k

, i; H( `2 m! u* a8 }
什么是Scrum?SRE、Scrum、DevOps之间的关联是什么?
# b% [% j2 l) S

5 i- m0 A8 T: L5 u' o0 M8 t0 H
这里简单画了一个图。DevOps首先订制一个流程,用敏捷开发基础去做DevOps。并非一定要用敏捷开发,可以尝试以快速迭代、快速交付的方式。

4 V) v! i5 p& S$ V0 m1 N) D
* W  ?& u! a" U' _
个人理解SRE更偏向于运维,涉及一些开放性的DevOps工具或开发工具,它离整体的软件开发交付还有一定距离。
) Y' d! ?" @; Y, k, o

* y7 G: C5 V" H- G
困境

7 g2 s3 A7 b9 A8 {' R2 ?, y+ b
敏捷模式概貌
8 w5 {& g8 I- v2 R! L7 {: `6 t
5 D. a( h! I. N
1.png
/ V7 p' m9 j& t8 f# Y  e: u
  q+ o% E# A# U+ n
很多时候,大家觉得敏捷开发、DevOps的模式及理念很好,但很难落地实践,归根到底是需要做的事情太多。其实这个时候,无论是团队还是管理者,都需要停下来,做一些思考。

/ `, n$ t, c* P! S# K

( G2 F+ `0 s  K; g
, a5 f7 S) Y" H
自运营/服务模式

# b/ R& ?5 J9 H) X4 l* l: r5 z
敏捷模式概貌

3 ~1 E+ o% f5 h' Q% Z1 c( C2 [
1.png
; G6 E: \6 _/ C/ N. k6 z/ L8 F$ A

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

5 O5 Y4 s3 W! C. f! n/ j
* [' u: _7 {# K  v
需要强调的是,敏捷在运维模式下很难做许多个产品统一的测试联调。一些大公司为了某个功能,将所有的产品功能对齐,等全部功能出来后再联调、测试、最后才推到市场,这是很值得“敬畏”的事。因团队和内容数量庞大繁杂,因为团队的数量,涉及的内容已经很难这样去做了。

8 b  e+ `9 \! _5 {5 ^+ ^, M

! T( c. \/ a9 G3 G9 Y' e. F$ M
受团队数量和涉及内容的限制,最好的方式是谁最后上线,谁最后做整体测试,以此为约束。
; N: A" @4 s" X7 ~' z

3 Q4 K- O4 M1 s) L3 y0 B
团队构成

5 a: ]! R/ {9 `- K# g; i% f
敏捷模式概貌

6 ?1 p" V* x! v  Y5 R* C) L
1.png
% P7 {; J# Y1 C8 b

3 r3 X0 B/ m) r
上图即1-1-3-2模式,这是简单的实践做法。& b* z9 C% t. ~2 p! o
1 c, M( J( [. b

! Q  f% L! _( o$ c
关键性角色包括:
# L" i6 a7 w  p5 T# _1 x/ s2 y

8 p: N4 S2 B" I2 M$ P6 Y, w& D0 F
产品、架构师、开发、测试。

! m9 e# i* U1 \

; T- m. C6 E$ e& H
找到合适的产品和架构是最重要的,开发和测试从哪来(如外包)其实并没有太大的关系。

" [8 Y* q3 ^" U5 g; x$ M

3 j4 e; Q0 N9 J0 R
沟通链条:

  a5 _. ^# z3 F! \9 y

1 I* ?% V+ n6 V& s4 R0 Y+ M
以前是产品→技术负责人→开发→测试,这样的顺序链条。但现在因团队人数的关系,所有的需求范围应该由产品直接对所有人进行沟通,以节省成本。
  Q$ p: q! C1 C" H0 J5 @! U
1 Z$ D5 ?/ H8 d5 X, r- R
需求澄清要由产品来做,实现指导、实现方式则由架构师来做。产品决定做什么,架构决定怎么做,这是非常重要的一点。从而营造一种氛围:外部提出的只是需求,不是技术方案或实现,技术方案和实现要由团队的架构师去把握。
- C- X2 g! r% ?; `- S* q1 M# M
+ \: b$ o: |3 u7 |& J
在团队中,可能有一个测试,四个开发,或根本没有测试,取决于团队自身情况。
7 n, a# c, v9 m, ?/ w6 H
1.png

/ i) J% ~2 h" Q1 U8 z3 a
1 r# |. j8 p' e0 S! a% i$ x. B; g

) I4 s# U( ]; W
公司规模较大,团队数量较多时要视情况而定是否做Scrum to Scrum,不同的PO在一起协调和澄清每一个产品或大的场景下的分工。注意:开协调会时,要把范围控制在少数人,而不是全员大会。
; r% v- O, V+ v: H
* n/ M! m0 y% ~3 d
角色分工

, J* q' Q! Y+ B/ i

5 U$ ^! z0 W6 }* m0 A! x! _
角色分工之前已提过,但分完工之后,还是有很多人做了不该做的事情,如老板去做技术指导。

* o( [3 `1 ^8 @. u# S' X
% n* a$ K! U  |4 @6 X
PO
/ ^. X* _( R+ h- `( H( M* X2 @5 B- Q
角色分工
/ E  k- M- Q: @4 W' X( U# u

2 E  }+ w) t* t# c
1.png

( [; u( E* P  M: i5 z

9 S5 E+ R/ `7 M4 l- W- F; z  Q" U
不想做好测试的开发不是好PO,也就是说,一个产品做不好测试,做不好开发,那也就没必要去做产品了。几个比较大的要求点:

# O; T9 D$ E6 V7 @; R8 D
  • Roadmap:需要做整个产品的Roadmap规划,至少要给出每个迭代有什么,有几个迭代,每个版本是什么样。

    - P0 _* f0 i( c# R. x7 m

; k: ^% f$ l: k; P$ A9 Q" r
  • 迭代范围:产品要控制迭代范围,很多公司老板说什么就是什么,导致团队越做越混乱,所以产品经理要做好澄清,对外承诺的范围要掌握在手里。
    8 M' n! }7 _$ s$ g( y4 G9 l

2 |# z. ]* x( z
  • 产品生命周期计划、特性Demo、推广等等。另外还需跟架构师配合,沟通产品规划中每个迭代与技术产品相关的改进点。
    , b# ]  m  z  G4 t

* g- |- a% S; {" U; K" W
架构师
8 P8 d2 a& _6 x
角色分工
  x9 q9 B2 b" W
1.png
* T4 O4 Q7 [3 s
' `% `4 U) g; m; H" G7 J) i
! n( H+ a8 `6 q# i) Y4 v
架构师需要做好实现架构的设计以及相关成员的指导(如开发、测试),组织相关人员会议,做敏捷不代表不开会,甚至一些小团队内部之间的会议可能比原来的会议还要多。
2 l# H% ]2 _1 x' W$ H& S1 d
开发

9 T5 j9 G; m# {* i
角色分工

# g2 E& Y: e- t, r
: t7 i4 {. r: r& V! Z; q* {
1.png

, V: b! b4 R# l

, u% o0 R0 m4 S  a- O$ y
开发没有太多的变化,唯一要做的事情就是开发要把东西做出来进行展示,让代码尽快可见。

! x& o2 v' m: a$ G7 W& g
8 B5 u! Z! t3 B% p* u4 ^' Q+ H
测试
- G' o8 R1 r/ z% ~2 |& X
角色分工
8 x+ j$ a1 j$ H  r. S6 o9 _
1.png
# R8 @& \8 N6 m0 q! E. u8 c& o

' S* l3 y9 D1 I2 ~4 N# m
测试最大的问题是很多时候被抛离团队之外,因为测试总觉得自己是最后一环。很多公司以测试Case数量作为考核,这是对于测试人员最大的误区。
4 ]  d& s* ]; p

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

8 P! o% t. e6 F
! `1 i9 M! `# E  ^
开发与测试的配合——模式转变

9 l0 A/ w* N& ?
角色分工

8 P! O/ @9 v" S: e* {" H6 Z! `

3 \1 O2 I- J+ f, a+ e. m" Q
1.png
( U6 R# {) b7 }: f$ t5 e
& w, t6 e* `8 z
模式上,开发和测试做一些转变。原来的模式中规划完成后,开发将产品开发出来,打包交给测试。

6 b. t4 N" |( d+ i4 Z- R. f

' v& x+ ^1 w( _* t
而新的模式下,测试从第一天就要参与其中,提前进行测试设计。

6 C0 _3 x; d3 ?% V8 z5 I, |

+ z9 L4 f4 K) S# R/ ~
开发与测试的配合——思维转变
; I+ X/ L& k7 S) s
角色分工

0 ]: a. C6 a( T! G# h4 z+ \* L
2 k" n3 H! M1 r. ^3 T
1.png
6 |9 X, X& I* _
4 w& \: M4 @6 |" |- c4 J( J! M( d
开发与测试的沟通,需要整个团队进行磨合的。前面提到,测试从第一天就进行测试,不需要开发来进行信息传递,而开发更加不是测试的上游。
% M% |4 K4 j6 b

, M' d5 a/ A" u5 |; _0 U7 i# |
未来,开发和测试边界会越来越模糊,测试也需要把重复性的工作进行自动化。
& G5 [" ?. ]  q4 d$ ^& E; B$ @2 y# j

3 [" [2 O+ x( _5 i+ P6 X
角色缺失
- \" V4 }' m8 {' q1 M2 t
角色分工
4 b- v! {- G" S
3 x1 U$ i9 K1 z. _2 U
1.png
8 k3 V  C, z% t5 ]: }9 V( `
5 C. t; P& j1 Q0 q$ }/ b; c
其实这里把Scrum Master去掉了,因为很多人把Scrum Master变成了打杂。另外如果公司全员做敏捷,建议不要在公司层面定制流程,同一公司的不同团队磨合程度又一,很多团队是靠人磨合出来的。

( _2 W- @# u7 j0 p- r& k
, z. u" J, ^! `9 d# Q

5 ?. U1 m' J3 {9 x4 {  W
日常活动

- B: d7 K. ]2 }6 Y

3 C" ]4 e* W' K2 W) O9 n2 D5 L7 {
Planning Game

# E( G, O5 z( Z0 Y0 E! e7 ~% C, l
日常活动

- V0 H& a5 {! d% M& ]! {
1.png
! Z3 n; H9 |# J9 {, s7 Z) k& E9 z
9 v5 {% n+ G7 _) d/ I3 w
' c. O0 p$ K" a/ o8 G
Planning Game以前的标准做法是给大家一副扑克牌,12358斐波纳契数列数字牌。现在我用Gitlab比较多,将Planning Game的所有内容列上即可,然后大家做大体迭代评估,而不是精细评估。
  ?; @9 \" m) R/ f+ x/ J/ e3 L

* {$ z6 U5 H0 b5 ^7 g8 F8 [
有几点经验分享一下:
  S4 S/ X; H+ F8 ~* W0 N0 B
6 w) `( O/ W1 A4 t! ^. l
  • 第一点,要负责好对应的范围,不要在一个版本里面,将所有的大功能都选择上。当把一个版本里面的大功能选择完了之后实际上等于没有选择,因为范围越大,失控也越高。 选择一些小功能或不重要的功能,作为风险缓冲。
    ! B  `8 B2 @$ @' f) Z- g

0 Y& ?1 W$ W/ l1 u4 o+ @
  • 第二点,需要预留出技术改进的空间,什么时候做重构,什么时候做改进等等。

    : c8 W9 S3 U- B

  Q& X; f" J4 {
  • 第三点,迭代的周期,两个迭代出一个版本,最好是两周完成一个迭代。以版本而不是迭代做发布,预留出一周的时间做发布缓冲,并对下一个迭代进行规划。
    ) R7 z7 \; n, E) p3 z, \

& \2 _5 r9 X& ~5 r  \5 z
8 W* T/ ^' g) f
Standup Meeting
  U% c/ y' g# L. E! Z
日常活动

" Y/ b5 F# W. d4 G, X/ \
1.png

5 d" M) i" M9 r7 D7 {5 N3 z* q- e
! S' C# ?  m' \' y6 W+ R

& r7 G4 I: Q2 d$ U$ R& ~0 R* p
当团队比较小时,没有必要做的太重,虽然现在已经出了电子白板,个人的经验是用真实的白板操作性更好,更能体现哪些事情有关联依赖性,哪些人在做什么事。

8 s4 S+ a1 \4 T

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

1 C# [/ J+ F/ }
$ E( }2 o9 w3 Q4 r3 y! s7 G% ^; T
Review Meeting
3 @$ n+ W3 I( R

. u; M. s% u* O4 t
日常活动
( Q6 ]5 B* d$ M. O6 X

) D; B+ u8 S* n% D8 B" h" q
1.png
  G6 R* N4 x: w

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

$ r1 Q! w4 c! [9 ?6 d5 n3 ^5 L
0 {* L0 B7 S8 d! H9 }& H( Y
End to End Demo

. x0 Z* Q( R  ^, n
日常活动

1 K* h+ W* I' b0 Z6 i

! t5 }8 N+ E/ w1 r/ z9 v
1.png

5 i0 Z! B6 M0 d2 T2 x
# s7 R7 ^; g: w/ P8 c$ \0 [+ P
尽快做emo,越快越好,能跑场景即可。不要让产品最后才看到Demo,也不要等所有的东西都做完,同时团队成员注意现阶段不需要挑刺。
' ~6 P6 [$ y# I9 S1 O
: e8 T  Q0 l' {7 a
DOD meeting
. \( f! Q) u' _- l
日常活动
/ T) d/ R' l0 e  Q+ ?: f" }

' u, C2 }4 E' M( E
1.png
* ?, x# n3 d* E' {

6 C9 O# d- O: W9 h3 M9 j; L7 x
DoD Meeting最好以迭代的方式,而不是版本方式。第一个迭代的DOD,要为下一个迭代做好风险控制。哪些是能做的,哪些是不能做的,哪些是需要自己做的,哪些要新增,都需要作出及时的调整。

' S+ [  D8 u7 z# v4 g

2 i! R4 V' U) j9 J1 h& L% C; ^+ U
Retrospect Meeting

: l( ?0 _% B  S3 C' K
! b- g. U( b# l
日常活动
8 y/ N) M, I/ L4 {, p
# y, ]! _/ @$ n8 U' d
1.png
1 X+ ^  ]2 d) s  @
, M7 K( ^$ s; ?; V& x( O; R( m3 V
定期做回顾,通常的做法是拿便利贴写三点——对每个方向提三点。选择一个轻松的环境,每个人讲一些。而回顾会的意义不是批斗或者拍马屁,曾经有一次开发把产品经理批斗的很严重,产品经理反过来又把开发骂了一顿,以上做法都不可取。

4 k0 ]+ e6 ^9 ?3 |8 v5 f

8 K6 P; Z: N! v# f- r
产品运营

" \8 r5 D; p8 C2 `  }
日常活动

: w6 t- {- y9 H
1.png

8 q# E. O2 k) i! `4 a
+ C: ?; |- A! d6 j; q2 {9 G' W
整个团队也要做一些产品运营,无论产品是对内或对外,包括客户支持、数据分析,以及对内对外的分享。
- p+ a3 Y& Q- ~; x4 ~

0 W$ R) T. K/ A0 s1 S+ c
PO的工具
- }! q  l! G" r; w7 Q3 M
迭代版本范围的选择原则

+ `0 d3 |! s6 H" ^+ I4 y0 J0 Q
PO的工具
$ d  G4 U8 c) ~7 Y" j
6 T* n; R- Z! M/ l
1.png

8 s, |/ N( i- x8 Z( ~+ `3 w
! v8 p/ _$ @8 T0 j: {* D3 U

* f- b2 N- i  u
每个迭代版本的选择,对于产品很重要。一句话概括这个版本的价值和目标最佳。要向团队成员澄清目标,否则团队成员可能不知道重点或优先级。
" j7 Y0 a& j0 D% B

( q9 |; z9 B5 ?/ u$ d$ ~/ s
版本细节定义
9 O. Q7 N& [9 `4 k  `) k& b3 Y

5 I. [0 c( D2 _8 @' M5 L
PO的工具
3 G9 M; O! w: }/ L8 g  s0 k4 G

- F7 P9 C; X) b4 x1 p3 `+ _- F
1.png

. y9 v( [0 v; }1 R' e8 ~
& s/ x0 X% x' q2 k! c2 M4 ]0 G
版本细节定义可以用鱼骨图表现,标注版本、周期,以及重要事项等。

5 |" l1 V  V2 a! }0 ~4 e" [

7 _( C' w2 L& D. z% r
Backlog/PRD管理
2 `6 y# H7 J7 D* a/ v$ u) e
PO的工具
9 Q7 O6 ~( _, f$ _0 F7 U

. x6 m* T) `) F
1.png
. G) ?( x$ ?. s$ l  D4 F
3 C1 Q8 [0 z$ H$ [

: P* ~" W+ [1 x; a7 Z5 _
9 Z3 C* O2 i3 s' T" T
Backlog无需和代码绑定,在Wiki里进行管理即可。虽然Backlog很多时候只表现粗略的需求,但其好处容易与相关团队成员达成优先级别的一致。
# g1 C& q6 G8 n1 e0 W! ?9 |% E: ?

  ]4 Q* c# x! `4 R* P2 L3 V, h/ d, E
小公司做产品时容易忽略Backlog管理,想到哪做到哪。Backlog的定义详见PPT。

' f( e' H0 x" s8 ?4 J% m

# z' \2 ^% z$ Q# w2 z, i: m
产品功能地图

+ D; W' w# a9 _" _' w/ L2 N
PO的工具
7 |7 r5 c3 y2 I& c, V

( u% R' c$ r9 ?3 k0 F1 t
1.png

9 q5 n, y, u2 d8 l+ N9 ?  B8 r& g
产品要做功能地图,用脑图的方式归纳整理便于大家理解,另一个好处是便于开发和测试补充遗漏,如果运用好功能地图,会更好的沟通,以及做功能之间的相关性测试。
; X/ a$ B& \" K" C9 {2 [9 k

; u" o9 }6 E5 j7 e3 H
任务拆解与管理
4 r% r$ w2 t+ t0 v
$ M! k6 C; v$ U3 j
PO的工具

6 |0 i/ V5 N9 O3 d$ q
1.png

* O0 L1 ]. U0 g- W, H2 Q
: p. e3 L9 i$ E( z4 Z
任务完成后需要进行分解,用Gitlab的Issue方式去管理,每天站会时汇报工作进度,测试对完成的功能进行测试,细节需要讨论的,和测试提的BUG直接写到Issue上去即可。

8 O( R8 O6 N' W% ^0 Q. g8 @
* d' n3 ]8 R* N9 K: ?  k9 X
版本Release Note

9 A- t! x" ^0 X. \) O1 \, f
PO的工具

. c$ R; B6 S; n) H' p- t
1.png

3 ~- @. g4 B& |2 k, O/ l7 f

( g- H; l$ k! r: H, V* e
% \6 ?% i+ d5 d4 T5 s
每个版本出来都要写上Release Note,不少公司更新迭代多个版本,但是连一个Release Note都没有。Release Note建议要写一下产品是否对其他产品依赖以及依赖的版本是什么。 之前犯过一个错误,出了版本后,由于产品已经出了多个版本,而之前依赖的下一产品版本是错误的,则导致现有产品的版本还是旧的。

) R$ a3 |4 ~# t' s, z8 a' o/ q
* \/ W( r/ b2 g$ a4 V1 ^- F# M7 J
内部版本定义规则

. O5 D! |8 X$ |
PO的工具
/ E3 F$ {, ~6 m$ v
1.png
! M6 h- ^: @1 [4 P; W, i) h+ X
: a+ G+ b2 m! B% j( Y! h
很多时候我们使用有两位版本号,有三位的、也有四位的、或者纯字母。经验上三位版本号会比较好理解,第一个是大版本号,不向下兼容;中间是Feature版本号,可以向下兼容;最后一个是Patch版本。后面“-”的版本是自己内部的测试版本或RC版本。
) l/ w  e: R6 c7 {1 w' R; _* J6 Q
4 G$ V) c: @- @' y1 z
总结
3 ?8 r0 x$ K  e* R7 K
! \; }' ^5 s" y( A
Scrum模式开发经验分享

& x$ R9 b8 q+ u
1.png
1 |: l8 v& c3 c* s& e+ `' _

$ h( K" S! @1 M+ B, ]
& ~& {% [3 |# L6 ]) s2 k- r! s
最后,整个Scrum模式希望大家根据团队情况,来调整流程和开发模式。人是活的,流程是死的。没有明文禁止的,都可以改变和调整的。

) J  x* c5 L8 G( I& r( W/ J% T" }2 _" T  \% O" v- v

( }: x+ }- @8 w1 C) Y原创:了哥(邱戈川)
, r3 M. ^7 N* B3 f$ z

本版积分规则

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

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

Baidu

GMT+8, 2018-12-15 20:02 , Processed in 0.277963 second(s), 34 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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