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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

敏捷是DevOps的本质

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

参加活动:0

组织活动:0

发表于 2018-9-22 09:30:22 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-22 09:36 编辑 ; M4 T5 u4 h1 I9 J. J" ~

3 G4 k: w, Q' p3 ^) w$ V) Q9 @( F, r' z$ a- {5 d
! h; ]  B! t% v
前言
4 r5 r1 N- J- X  Q
Scrum模式开发经验分享
1.png

  k0 K1 T" G7 M8 _6 q/ B

$ U( E( L! |9 s) A

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

& B- L) `3 o3 F$ D  U
$ {" @. @0 E5 Z; e
主要有四块内容——敏捷Scrum模式概貌、人员的分工、日常活动的细节、以及一些可能用到的简单工具。
# r1 L9 O4 M+ n
4 E& O3 [) K- U9 L4 h
现行开发模式及开发过程中痛点

2 ]/ n. g& i* \' c
敏捷模式概貌
' k7 G) z1 {) Y# w" l) Q
1.png

2 y) t& [7 k, z9 \: _! I2 J' h

- [# H$ Q6 Z: D; l' {$ o/ G
Scrum已经用了很久,但为什么始终没有用到极致或者很火?
8 X* n! ?% r: N
5 y4 B0 U# w; M! z4 p
  • 大家都在做大型系统,Scrum模式难度稍大,链条过长。需要开很多协调会议,沟通成本高。
    ' u1 u' x* r( _# Y

! t7 E4 N7 h. M* w
  • 微服务和容器化让团队规模发生转变,从以前几十人的大团队转变成现在六七人的小团队。
    & a: w+ Y2 t* R! ~$ M( n7 }% |

$ ^& z# I( R2 x9 J& v- G
  • 客户及运营的需求产生变化,从数月至半年的交付时间转变到几周至一月的交付时间,使得业务更倾向于快速迭代、快速交付和快速变更。

    3 W2 c% b6 B. ~1 L
* x  e( H  h. Y+ |9 Z7 m" w
什么是Scrum
" B" G8 m( d4 S
敏捷模式概貌

0 P0 H$ _; v) n; C! O/ f- l
1.png
6 @- y' A/ S3 N- I& v! v1 U
  ~. ^1 o" y6 @; R
上面这本书详细地介绍了敏捷,这里就不再赘述。先提几个问题:

) A3 G1 \0 A& i( _0 Y

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

" A; a1 h/ |3 T& ]) D3 m

! m4 O" J  H7 ~7 V5 E# V
流程主导:很多公司都有一套流程来规范每个团队所做的事情,应该团队来主导流程还是公司主导流程?
$ K# }# M6 _$ c; b7 ~3 M

) D4 B1 E2 g; i2 D* }7 n
颠覆还是改进:敏捷是不是需要把以前的东西推翻?

% c4 C. V% K3 O) j* y: [
1.png
$ e& k9 v/ B) ^# P% h6 t
3 d5 G& r$ w* u: G
什么是Scrum?SRE、Scrum、DevOps之间的关联是什么?

! P  r4 [" e1 ~  u6 K, \! d

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

" v" g/ y, h4 Z1 ~

( d/ ?) o! Z$ ]7 T6 w1 S
个人理解SRE更偏向于运维,涉及一些开放性的DevOps工具或开发工具,它离整体的软件开发交付还有一定距离。

5 i$ B! K2 |3 N! I. b0 D1 Y

4 a8 f: T2 z+ w
困境

2 `. [3 i, _/ U/ k' ]
敏捷模式概貌

( ^( n# ~. ?5 g( z: c% I8 s- s: ?( n

2 n& ^$ f5 C! e: D) I7 a* s3 V
1.png
3 p, D, g' p: q  Z3 ~

  W, L4 C1 }! U) W. F- l
很多时候,大家觉得敏捷开发、DevOps的模式及理念很好,但很难落地实践,归根到底是需要做的事情太多。其实这个时候,无论是团队还是管理者,都需要停下来,做一些思考。
% u0 T1 S; @- f4 z4 ?6 `
! Y: g+ j3 K; U
6 ?' r3 |& c; u. q1 U# f
自运营/服务模式

8 `! Y: _9 N, |! P
敏捷模式概貌

4 v' L% l/ R& A
1.png

" p& m8 p; U- n6 f# T

2 Q) S, U0 }0 {
N多业务团队并行,由产品或商务提出需求,但通常只有一句话。也会有一些业务分析师,把业务做好澄清后导入给团队,每一个团队产品体系里都要拆出自己理解的PRD,然后再自主规划版本,最后实施完成推送上线。
, t' R- `4 r+ L% @6 k/ G

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

5 E& V( T& Y# P+ X2 X& q
. Q$ l" b$ M: U, z
受团队数量和涉及内容的限制,最好的方式是谁最后上线,谁最后做整体测试,以此为约束。
& {. x2 E2 q/ N+ [' ^5 ~( _% m  y

: ?1 @& B2 \5 @( {# O
团队构成

  s6 U7 g8 h+ A
敏捷模式概貌
& a$ w8 R. B: S3 Z
1.png
1 T, h0 \: v$ D1 c7 _+ a7 \
% I; _& M, e( ^  H0 ]& Y
上图即1-1-3-2模式,这是简单的实践做法。
9 p% [" Z; @& n6 k2 s" T

. F1 ?9 q9 H# Y6 u4 }

+ e2 Y: v5 K% {0 v) B
关键性角色包括:
3 r( _* g" B' r) {2 g. q0 h
, {3 _: t( i7 p$ p7 \& B
产品、架构师、开发、测试。

1 m" D  J9 t* R* Q+ Q) B) [

9 Y* N' X0 j+ N
找到合适的产品和架构是最重要的,开发和测试从哪来(如外包)其实并没有太大的关系。
4 s" j8 b8 `% g

* R& O& ?3 z; [/ F& Q  j, o
沟通链条:
4 L9 U) x1 N" l& f- J
7 g/ m. _! m8 [: @7 N; J. M
以前是产品→技术负责人→开发→测试,这样的顺序链条。但现在因团队人数的关系,所有的需求范围应该由产品直接对所有人进行沟通,以节省成本。
; B" b  J1 q& {4 C" f

/ l( g" P- x7 r7 @/ ]
需求澄清要由产品来做,实现指导、实现方式则由架构师来做。产品决定做什么,架构决定怎么做,这是非常重要的一点。从而营造一种氛围:外部提出的只是需求,不是技术方案或实现,技术方案和实现要由团队的架构师去把握。
# w2 O( Y9 F2 G/ [# J
# C5 ?% W7 \, g4 f, ]$ T
在团队中,可能有一个测试,四个开发,或根本没有测试,取决于团队自身情况。
: o2 ?- L0 W4 ^. F( E: Y
1.png
5 N% {0 w$ _! C
3 ]+ P- k; W4 |% b

, c. k$ S! g; J* z3 v+ M7 A* U
公司规模较大,团队数量较多时要视情况而定是否做Scrum to Scrum,不同的PO在一起协调和澄清每一个产品或大的场景下的分工。注意:开协调会时,要把范围控制在少数人,而不是全员大会。

( ]# R! [( [& J5 J4 G
: |6 x1 c, y% d
角色分工

/ _/ F8 ]% F& y. I, x8 o, |

0 a, ~, M) {0 w& T- A" D( l) J/ K8 R
角色分工之前已提过,但分完工之后,还是有很多人做了不该做的事情,如老板去做技术指导。

2 j9 o2 m: M3 d3 Y; D. s5 h* P
2 a/ D( G) v7 a* V2 c5 C
PO

- V% e" I$ u( ]$ I
角色分工

9 P: e( T) [" d
3 o! @# ^2 r6 v, F4 X( g2 H
1.png

; q! x1 j1 W& m$ v. t) r
4 Y  l  x, x$ T* v+ N& T- U
不想做好测试的开发不是好PO,也就是说,一个产品做不好测试,做不好开发,那也就没必要去做产品了。几个比较大的要求点:

/ h+ M7 [, a+ y$ q7 `0 x
  • Roadmap:需要做整个产品的Roadmap规划,至少要给出每个迭代有什么,有几个迭代,每个版本是什么样。
    6 ~2 \3 u0 P3 u6 `: O8 \
* |, a7 J& D* v" b$ Z% H. j" {
  • 迭代范围:产品要控制迭代范围,很多公司老板说什么就是什么,导致团队越做越混乱,所以产品经理要做好澄清,对外承诺的范围要掌握在手里。
    2 J4 p) U4 i' k6 c$ z' y4 g4 p  r

5 k: x8 t* |% D9 c1 g
  • 产品生命周期计划、特性Demo、推广等等。另外还需跟架构师配合,沟通产品规划中每个迭代与技术产品相关的改进点。
    2 k3 G  P- }. b1 E7 G
0 o! x. S" x% i* `
架构师

+ V% ]% |* w* w) C  I
角色分工
% N" S. S1 H4 M" B1 X! ?: x
1.png

$ v4 l- ^- O! R1 U" g

+ J4 n) ^$ S9 V! e) r7 c" o' `& `

' c' U# [. I' G' S; X9 |$ e
架构师需要做好实现架构的设计以及相关成员的指导(如开发、测试),组织相关人员会议,做敏捷不代表不开会,甚至一些小团队内部之间的会议可能比原来的会议还要多。
4 o1 z& d2 X8 V+ T- O* x* @8 D
开发
2 G1 v  R/ f2 s  I# J
角色分工

) x' Z7 l5 R1 N# I
7 [! l% B7 V7 B7 z$ p0 G3 r
1.png

# _' V) `5 }7 ]  H) U3 A1 T# ^. I
( @1 m- g) K; e, E% `" H
开发没有太多的变化,唯一要做的事情就是开发要把东西做出来进行展示,让代码尽快可见。
6 v4 E2 m# N2 d, Z! M
3 p3 v2 F1 r5 `( D  H
测试
2 B# W7 [( Z1 _* P, |; X
角色分工

* Y5 v9 b% q2 h
1.png

* ^+ p& L, v  C' N6 F
) L6 j- c. C* f& c6 f) o* H5 |" Q
测试最大的问题是很多时候被抛离团队之外,因为测试总觉得自己是最后一环。很多公司以测试Case数量作为考核,这是对于测试人员最大的误区。
/ m. y) y# p& n& K2 o3 m0 `

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

- Q- d. @+ o; D4 J4 b

# l: K' O& o' S. |
开发与测试的配合——模式转变
% h$ N1 _% A  l, o
角色分工
& h+ A9 U3 M  h$ d7 N" _5 n
/ O  {6 |9 O- I; m
1.png

( p, d# \1 D& |# T# G3 H

$ o. H: H- L7 o. W; a
模式上,开发和测试做一些转变。原来的模式中规划完成后,开发将产品开发出来,打包交给测试。

$ N1 ~9 ~! ~4 |( X# q

# V# p& t+ x- S) U* Z& A$ n4 Y* _
而新的模式下,测试从第一天就要参与其中,提前进行测试设计。

3 G. _1 b- z# Z& U. i
" x) t. L! _' N( C
开发与测试的配合——思维转变
: R+ Z4 L8 T% R5 f
角色分工
4 S$ m: {# R/ c! K3 J
8 v$ Z+ S- Q! u% B1 x8 V% z; B
1.png

3 C. t3 Y1 h/ x2 @5 @* k9 k8 u( ~! O

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

0 q& S) ?0 J! d  G
# o, L# \6 E. o7 W9 U$ {* E
未来,开发和测试边界会越来越模糊,测试也需要把重复性的工作进行自动化。
) \& W; i/ n6 q/ C! T" Q+ v- M) z
% V+ M3 H4 p9 F8 H% B
角色缺失

3 D; y; Y4 L6 ~/ c
角色分工

0 Y/ [$ b, b: ?. R, O' T
7 \; |. D4 r9 k3 a  l/ V
1.png

& j+ r4 O. n& T- \- X

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

! e2 D4 o% |6 |% _0 n
0 v8 m7 j" i, P% ~+ I& H0 M
# ^; y% ?+ J. j
日常活动

% P( O: T5 ~9 R& H' v
' B2 S4 x9 W! a6 L7 @+ v0 z! @& H; [
Planning Game

8 }8 k2 X& H# l, I8 ^/ h2 F; k
日常活动
6 h  \4 p6 M9 A4 d& h; r# [
1.png

* f7 B, R0 v& J$ B5 f7 O
6 M7 f& Z$ ?  F* R

/ K$ V1 D# c* P; J6 Q4 J
Planning Game以前的标准做法是给大家一副扑克牌,12358斐波纳契数列数字牌。现在我用Gitlab比较多,将Planning Game的所有内容列上即可,然后大家做大体迭代评估,而不是精细评估。
2 }6 {. [  J1 C7 @" c+ n
/ Q8 X( r3 \9 D4 K7 s
有几点经验分享一下:
$ i, G, D9 |; T0 o& p

1 _4 U7 a  M- R. w' D" ]" J3 B
  • 第一点,要负责好对应的范围,不要在一个版本里面,将所有的大功能都选择上。当把一个版本里面的大功能选择完了之后实际上等于没有选择,因为范围越大,失控也越高。 选择一些小功能或不重要的功能,作为风险缓冲。
    " s* t6 v3 D. C. I& _8 `4 U; k
4 c/ f) C  b; j) V5 K8 a
  • 第二点,需要预留出技术改进的空间,什么时候做重构,什么时候做改进等等。
    # u9 z+ P3 B6 Y2 _1 m/ {" s8 `1 k
. S  x  b8 _9 ], O! A0 n
  • 第三点,迭代的周期,两个迭代出一个版本,最好是两周完成一个迭代。以版本而不是迭代做发布,预留出一周的时间做发布缓冲,并对下一个迭代进行规划。
    0 P8 d/ O$ R8 ~' r7 F" H* X
  o' `3 N1 p2 [
4 X7 ?, }" Z8 f+ h( L; E
Standup Meeting

0 J' n5 _$ \8 Z( Y5 o) I
日常活动

& y7 u6 Y+ ^9 ?: x  ]! g5 r- k
1.png
( E0 p/ [: d$ {, \

3 I- T6 g4 s/ `, X/ e% x7 F
2 o. e' P, l7 }) U
当团队比较小时,没有必要做的太重,虽然现在已经出了电子白板,个人的经验是用真实的白板操作性更好,更能体现哪些事情有关联依赖性,哪些人在做什么事。

0 E+ H2 B9 @4 ]
  w- [5 \: T5 ^. r2 ^
需要强调的是,每个人做的事情是自主的,但需要架构师掌控好,有限度的做出选择。对于非常重要的事情,要选对的人去做,而不是随意去做。选择的纸条项目要控制在两个以内,具有难度的要让架构师去做设计。
, }7 F6 Z, l9 {4 s1 F0 @: d) c

( }) A, Q9 N9 q! C9 F0 M
Review Meeting
( o" u& a) a0 V3 {' p7 S! R
. G. P9 `9 r* |" S7 }% b  A
日常活动

: K" t- v! B+ J" J+ Q7 H+ o
1 H) E* b( t8 H( d% g/ r3 {' j
1.png
: B. H% x3 U% K
1 K# e5 F7 U& f. K: e
敏捷上开会还是比较多的,但内部要想办法有效率去开。Review meeting包括设计、代码、测试 Review等。大功能设计,可以去做从三分之一到二分之一再到完整的Review,这样可以减少返工率。
: ~0 D; y1 |; R; l! H7 [4 Y0 k, w
9 N3 ~& o$ V* b0 N5 ?8 O
End to End Demo
) h3 V' Y# j* X" @5 N9 V
日常活动

3 J( R( Z/ V! J8 W4 F
: n/ b/ m, T9 q$ s  S$ H/ |
1.png

) Y  g; ]* h- c& a

; q; [2 z1 m8 N; ~# F5 }; N
尽快做emo,越快越好,能跑场景即可。不要让产品最后才看到Demo,也不要等所有的东西都做完,同时团队成员注意现阶段不需要挑刺。
1 j3 m! X0 C: C% M4 z- z: x& t7 o

, [0 _) g/ w3 s- ]7 U* u
DOD meeting
) F0 A* N) w% g3 l
日常活动
% N/ {) D( c4 ]( Z* F3 O/ J  Q
. T* @! ^" f0 W6 a/ \" B# i. O
1.png

0 w! P0 o- c5 J* `5 e
  l: W. G, j9 ]6 n5 h- v
DoD Meeting最好以迭代的方式,而不是版本方式。第一个迭代的DOD,要为下一个迭代做好风险控制。哪些是能做的,哪些是不能做的,哪些是需要自己做的,哪些要新增,都需要作出及时的调整。

, I$ ?4 K; O$ F% l5 E) r

4 @' x: _/ r/ X1 \5 R
Retrospect Meeting

( k5 _% V- @3 I0 y2 L0 ~. s( Q
! a. f, G5 C+ h6 z7 ~
日常活动

5 K5 A8 k6 V+ c6 J2 f# U5 b

6 C' o" X$ M0 c* b2 N+ o3 I
1.png
9 Q) Q/ a8 Y! n$ r8 y% M$ V
) _( v2 I" u- n$ J1 u
定期做回顾,通常的做法是拿便利贴写三点——对每个方向提三点。选择一个轻松的环境,每个人讲一些。而回顾会的意义不是批斗或者拍马屁,曾经有一次开发把产品经理批斗的很严重,产品经理反过来又把开发骂了一顿,以上做法都不可取。
7 r6 U& Z& P1 F* n
& \5 a1 D# P. ~
产品运营
1 N$ o- `1 {1 ]- o3 f
日常活动
% J+ y7 a1 J8 _7 j4 I
1.png
, c1 W7 O/ T$ H+ F9 V) Z3 {

/ O1 n1 ^& z) A1 U% l. e
整个团队也要做一些产品运营,无论产品是对内或对外,包括客户支持、数据分析,以及对内对外的分享。
0 m& T* n" m* J8 d# I
  I: C- k4 O4 y8 m! Q1 w& |) i# H
PO的工具
/ R3 n4 |" t, L- J
迭代版本范围的选择原则

; I( r* k$ B- {- _3 k3 S
PO的工具

# e' n( K! |: \9 p! i1 I- p! a

, A7 _5 i8 ^3 Q; M7 B5 d
1.png

% x4 r& s' l7 M5 c; U! T# F& h% A
  a" G3 y, W7 |1 L9 {0 A
# n4 C  N5 p1 ?* D& ]  b: X
每个迭代版本的选择,对于产品很重要。一句话概括这个版本的价值和目标最佳。要向团队成员澄清目标,否则团队成员可能不知道重点或优先级。

  [4 j' S: e) F5 P3 C" r" `

( k6 f" v. f: E; a! x
版本细节定义
4 L5 h8 C( g8 A& l# @' g5 `8 m
' H0 @* G5 Y% b- X: d
PO的工具

5 ?. f5 A5 y4 l3 x

6 w# W9 l" z1 O# A8 Z
1.png

3 X8 J/ P3 A% m% f$ ~6 G$ c
; Y" m' O& V+ U6 p6 y& m; c
版本细节定义可以用鱼骨图表现,标注版本、周期,以及重要事项等。

3 K/ k$ {. v6 L

5 V6 W4 {9 o" N$ T, q% y
Backlog/PRD管理
# r0 x3 g- L! L
PO的工具
- h" [' [, y8 F' R, |0 g
6 H* G6 I/ L% z# |; X! Z
1.png

# K8 k! V* [" P4 Q* O* h& w$ S
3 n5 e" Q% F' v5 j4 x

  h3 w4 U0 C. A* V7 Z# C9 E% a) J

' }6 o. ?6 [. ]9 \9 ^
Backlog无需和代码绑定,在Wiki里进行管理即可。虽然Backlog很多时候只表现粗略的需求,但其好处容易与相关团队成员达成优先级别的一致。
3 k( Y1 J7 T3 C1 `

2 l' L& O6 B/ u) W9 |6 U7 p$ _) A
小公司做产品时容易忽略Backlog管理,想到哪做到哪。Backlog的定义详见PPT。

  {; @8 g2 ?/ C/ N( B
( N8 {+ G( F# a( ~0 j' c2 J. \5 O, j
产品功能地图
1 ^! m: G& t; t
PO的工具

* T" }5 B. F4 j, W5 J5 ^
0 z& s7 e- T: A2 p
1.png
9 I7 q% ^$ g* S8 f# |$ b  Y# N
产品要做功能地图,用脑图的方式归纳整理便于大家理解,另一个好处是便于开发和测试补充遗漏,如果运用好功能地图,会更好的沟通,以及做功能之间的相关性测试。

& D! S$ ~- m) f+ Z

: Y; x5 |) v/ P( a5 W! s* |" ?2 q
任务拆解与管理
+ A" _# F$ Z% k, v$ a# M8 k
0 W. a8 K5 ?5 u  [) ]3 n8 M
PO的工具
* }" c* W1 U$ L9 G; x9 a& Y
1.png

- v! n- O# c8 Q4 w+ Z8 ]) D3 r

1 i- X6 @% u  ]' h6 b; D
任务完成后需要进行分解,用Gitlab的Issue方式去管理,每天站会时汇报工作进度,测试对完成的功能进行测试,细节需要讨论的,和测试提的BUG直接写到Issue上去即可。
' C- @& e8 G2 ]" Y
% V( N5 ~% @$ r; {6 T" m
版本Release Note
* `& t, N1 R6 J9 @" q- f4 }
PO的工具
- K/ J, P& g$ J2 b8 L% d) c6 r+ s
1.png
& _# P1 |" N: H. @3 B$ D

' x# w( k5 g* c* k1 \1 S, |4 E
; C2 T, M' c8 B1 p9 V
每个版本出来都要写上Release Note,不少公司更新迭代多个版本,但是连一个Release Note都没有。Release Note建议要写一下产品是否对其他产品依赖以及依赖的版本是什么。 之前犯过一个错误,出了版本后,由于产品已经出了多个版本,而之前依赖的下一产品版本是错误的,则导致现有产品的版本还是旧的。

5 h$ A+ i9 q4 i0 `2 h
, g% ~9 j0 k% Y; B
内部版本定义规则
) ]7 o8 n5 ~; L! k5 z4 q5 ?; ~. I
PO的工具

/ I3 x. u- ?! ]1 w
1.png

# p2 Y, R! C" Q5 E, b* O. |$ \
) ]' B% {, u& a9 R& E- C9 \" R
很多时候我们使用有两位版本号,有三位的、也有四位的、或者纯字母。经验上三位版本号会比较好理解,第一个是大版本号,不向下兼容;中间是Feature版本号,可以向下兼容;最后一个是Patch版本。后面“-”的版本是自己内部的测试版本或RC版本。
# h+ x/ C7 J/ u9 o. F

' S7 p! f) ?- ^* w
总结6 o/ @# n6 H) p6 l5 m

* E9 T9 z, Q8 Z3 G: _! g. {
Scrum模式开发经验分享
& |6 P- s& ~' f$ Y$ n
1.png

% q4 ~$ l, L/ Q+ u

0 z" ~% O% z; z( T- q5 ]4 n) q2 {
% B; a3 k" M9 C4 T
最后,整个Scrum模式希望大家根据团队情况,来调整流程和开发模式。人是活的,流程是死的。没有明文禁止的,都可以改变和调整的。

: a: D$ ]3 F) i) k. M
# S" M9 ~# h/ w! s/ \

3 l4 V0 x/ n0 l" k- k7 n原创:了哥(邱戈川)) ^5 x0 z, B; `

本版积分规则

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

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

Baidu

GMT+8, 2019-4-25 00:21 , Processed in 0.239599 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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