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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 523|回复: 0

敏捷是DevOps的本质

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

参加活动:0

组织活动:0

发表于 2018-9-22 09:30:22 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-22 09:36 编辑 ! p7 j1 K6 D" N0 w

; g5 Q& T& M% @* p' s  t6 @3 ]4 u+ f) O( F

2 J) W- G$ z$ |7 Y! Y
前言
$ A6 ~- m. [+ S
Scrum模式开发经验分享
1.png

+ u- ~" B' u9 \6 L% ~
4 d! A0 h5 ^* k3 a' ^$ \6 p

1 `9 s! @. c5 T0 ]; x  U
Scrum出来已经很久了,很多原理性问题就不讲了。今天和大家主要分享一下Scrum实施过程中的一些经验和对其的一些感受。
& u! `  N" A# Z! }

1 n* b  t. |2 j# |
主要有四块内容——敏捷Scrum模式概貌、人员的分工、日常活动的细节、以及一些可能用到的简单工具。

- y9 \5 B* G- ]4 O
  m1 f  E' H. C' `9 B  l
现行开发模式及开发过程中痛点

. ^' [1 I* R" Y( n8 J! a( U
敏捷模式概貌
. @9 T: L+ }, |/ s1 r+ W( K
1.png

9 n2 z- G3 O8 q  V3 J. I7 m

# y0 |% D: Q! E1 \  V( s3 K2 m: g
Scrum已经用了很久,但为什么始终没有用到极致或者很火?

( s  E' \' |+ k# @/ z# M6 w/ m

# z2 I/ C# d0 X5 d( A+ L; m
  • 大家都在做大型系统,Scrum模式难度稍大,链条过长。需要开很多协调会议,沟通成本高。
    + {3 g" i, T& _- ^! ^. B7 M
9 P% ^+ N8 w7 Y( ?: M" U; z
  • 微服务和容器化让团队规模发生转变,从以前几十人的大团队转变成现在六七人的小团队。
    ! G$ `, n! d$ a2 n/ {  A/ d( G

& O4 K. B3 j4 R  ~. W/ A1 X+ a
  • 客户及运营的需求产生变化,从数月至半年的交付时间转变到几周至一月的交付时间,使得业务更倾向于快速迭代、快速交付和快速变更。

    # Y' ?, b( U9 S2 Z

% n  A* Y" A, v
什么是Scrum

' r4 f% N4 }. U7 O. x
敏捷模式概貌

' X8 i+ t, I  E7 r
1.png

& O/ R. Q- }4 Y9 w4 u

% s+ H. ^3 j( V2 w; b
上面这本书详细地介绍了敏捷,这里就不再赘述。先提几个问题:

2 h, t) `( L' @2 z$ B
( g" g1 A# s, Z) n; M
需求主导:通常需求都脱离于团队之外,上司或老板突然下达一个指令并规定出时间,而自身的事情尚未完成,所以在开发上需求到底由谁来主导?

1 r5 z; d) }4 U9 f! W% J! l, `, V

5 |# Q( x; j# x. z0 @; b9 D; P  t: u
流程主导:很多公司都有一套流程来规范每个团队所做的事情,应该团队来主导流程还是公司主导流程?
, Q0 Z% E' K, K% s' i
8 {$ {- G7 {4 ?; _5 E: [; B& w
颠覆还是改进:敏捷是不是需要把以前的东西推翻?

  a7 o( Z: `1 Z! E
1.png
% k) p0 C- @& [
! D( \" Y& A$ O. x1 p: y( M
什么是Scrum?SRE、Scrum、DevOps之间的关联是什么?

) @' h, @: Q" j3 d
( R, ~0 O! w/ |) g2 z4 p$ q( H
这里简单画了一个图。DevOps首先订制一个流程,用敏捷开发基础去做DevOps。并非一定要用敏捷开发,可以尝试以快速迭代、快速交付的方式。
; T9 d/ I* a$ m+ ~7 c
" z$ a7 l. y9 y
个人理解SRE更偏向于运维,涉及一些开放性的DevOps工具或开发工具,它离整体的软件开发交付还有一定距离。

" c( y. A% Z, x" X, Q2 H

  ]  G" U+ v( N, Z  O; r
困境
& i3 _' ]% J; t) N6 T
敏捷模式概貌

! K+ f$ X7 d' _
, ?- g* U" Y2 V' F7 z/ i, E3 h! o
1.png

0 ]3 @/ s2 `& f8 s6 c9 U
+ G4 i5 M3 }) G6 Q1 O1 }
很多时候,大家觉得敏捷开发、DevOps的模式及理念很好,但很难落地实践,归根到底是需要做的事情太多。其实这个时候,无论是团队还是管理者,都需要停下来,做一些思考。

4 u, Q% A5 q1 y- b8 G8 _. G" g

9 ~2 Y/ l5 g8 C: @) y7 d3 D

" ~7 v* E& [5 _. ^/ b) B
自运营/服务模式
, y1 c( a6 x0 Y
敏捷模式概貌

; g1 @0 w. Z) q% q4 a
1.png

7 V3 {% e# y& O* p$ W# A3 v

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

2 {$ X) G1 X' S; T1 Y
4 r  o2 N8 |# o
需要强调的是,敏捷在运维模式下很难做许多个产品统一的测试联调。一些大公司为了某个功能,将所有的产品功能对齐,等全部功能出来后再联调、测试、最后才推到市场,这是很值得“敬畏”的事。因团队和内容数量庞大繁杂,因为团队的数量,涉及的内容已经很难这样去做了。
! s/ v4 J- q; D3 |) S- Q
* @" i, q0 V3 B
受团队数量和涉及内容的限制,最好的方式是谁最后上线,谁最后做整体测试,以此为约束。

/ |% n' N! n) w! U3 w" _; _

9 \6 L4 `' W* n5 j
团队构成
9 k! [3 J& H- M3 c
敏捷模式概貌

2 ?7 h- X3 x+ ?' A/ D1 p! r: J
1.png
" M. U" E' N$ h

( w1 L5 Y; |& L% m! u4 l5 v
上图即1-1-3-2模式,这是简单的实践做法。
% _; }! W8 F# J& a# B5 g

: _) q8 {. E' A8 B; q
- y" s4 g( K7 m( r; p
关键性角色包括:
0 Y+ e3 T7 z! V) _0 [+ c& P' H- c

1 b( Z- M0 v8 E4 \% S
产品、架构师、开发、测试。

$ Y: n" ?' @: ]+ K3 h3 i7 Y
6 n7 D$ O% }: s" t
找到合适的产品和架构是最重要的,开发和测试从哪来(如外包)其实并没有太大的关系。

" O, N8 o* Q8 k3 p$ o

- m/ [  H; u5 C2 F' p7 O
沟通链条:
& D  ?) @6 r2 w1 Y
5 g/ [6 r9 E' @; E( [
以前是产品→技术负责人→开发→测试,这样的顺序链条。但现在因团队人数的关系,所有的需求范围应该由产品直接对所有人进行沟通,以节省成本。

- R* z4 g, ~2 v: x

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

' P- G- l# ?% F. p
9 T2 n3 n8 l7 E. ~- b
在团队中,可能有一个测试,四个开发,或根本没有测试,取决于团队自身情况。

* R- i8 }- t' Z  ^6 _* f
1.png
( B: a) T) i& v' [7 H3 o* l6 d" L

8 D4 m! o+ M7 Q/ i4 L; C  ~
; ]7 R/ Y6 a+ Q; m6 M( B4 ^( ]
公司规模较大,团队数量较多时要视情况而定是否做Scrum to Scrum,不同的PO在一起协调和澄清每一个产品或大的场景下的分工。注意:开协调会时,要把范围控制在少数人,而不是全员大会。
& _/ p8 P/ E% Y) e

" |& e% G/ F. ^0 \" U
角色分工
% q6 o$ }! v1 @% C

! x8 L4 v7 Z9 z7 r+ t4 j
角色分工之前已提过,但分完工之后,还是有很多人做了不该做的事情,如老板去做技术指导。

, \) D# U5 g# N' [& c
0 [3 E/ f0 Q( L, i6 G! u
PO
% J) e; ~. W+ |" Y) m& t* U3 p( F
角色分工
7 o, P% R$ y5 n" W) D3 W/ M

$ d. T8 H( c# U: ^! ^
1.png

* d/ G6 t- Q  R6 z) T
, v# q: L, C! B# q
不想做好测试的开发不是好PO,也就是说,一个产品做不好测试,做不好开发,那也就没必要去做产品了。几个比较大的要求点:
9 M& ?& H2 n6 }' A4 Q
  • Roadmap:需要做整个产品的Roadmap规划,至少要给出每个迭代有什么,有几个迭代,每个版本是什么样。
    # F/ c. i% a7 @: n; E! Q9 c

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

    3 R4 N& U) Q) d! B

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

    ! R4 p$ W( I3 O% h( V4 i
2 Z" z1 {4 d/ p
架构师

* Q. k& N" _1 A+ i) p$ ]7 {
角色分工
. R8 @" f) d. K5 ?" _( Z4 K
1.png

1 x' J+ H. i! `: ~; a' d9 t/ K
$ T5 w+ q2 p" I; o" j

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

5 r7 u* Y+ a3 ]
开发

3 V# t5 m$ R/ O6 ]8 k
角色分工

! ^" _- z# t5 Y
4 ?. g8 B* l$ d0 W
1.png
! y% z; n% R. b, Y( B5 `/ _
! `3 G8 m) ^+ m4 P0 G
开发没有太多的变化,唯一要做的事情就是开发要把东西做出来进行展示,让代码尽快可见。
( ^  o2 J6 X: s+ p. j  `" k: ]

, I- m. _0 d& o7 [9 F2 K; @+ |# K
测试

3 A6 }$ H8 [7 b& y
角色分工
) a- j0 N: a3 b6 m) S
1.png
& V! n6 y$ e9 w4 P3 ~
3 F3 W: C% t' c& E2 y
测试最大的问题是很多时候被抛离团队之外,因为测试总觉得自己是最后一环。很多公司以测试Case数量作为考核,这是对于测试人员最大的误区。

! K7 u6 [( ~5 h1 R* q: h5 ?

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

! U; D- R( O: S0 l# H
* z( C. z9 @9 o2 b5 r4 M% J5 }
开发与测试的配合——模式转变

+ U( p/ q# J2 I% K9 l
角色分工

5 T  L' w: I) k9 z* j' G# {6 y! d
& }+ J. O0 W/ l; l- Y4 `: C* H
1.png
7 X7 A5 L9 U6 Y+ {+ Z0 ~
  p% `0 ~4 U& ?; R. z2 ~
模式上,开发和测试做一些转变。原来的模式中规划完成后,开发将产品开发出来,打包交给测试。

4 w  N0 s6 z" I" Z: l  Y

3 t# Z2 S% e/ H  q0 m% V
而新的模式下,测试从第一天就要参与其中,提前进行测试设计。
2 \* R& j$ |; V1 S5 S3 o

& Y  m0 V3 R9 O/ q
开发与测试的配合——思维转变

# H8 e# w4 ?; S$ _% }2 C- b5 U
角色分工

( E/ a7 I$ F+ |& v1 O; X
, v! [! R1 X0 ]4 ]" ~6 }- Z
1.png
) T5 _* l+ x6 h

: i) M0 L3 m0 x: K* `6 S+ ]8 Q
开发与测试的沟通,需要整个团队进行磨合的。前面提到,测试从第一天就进行测试,不需要开发来进行信息传递,而开发更加不是测试的上游。

+ x1 \; e2 b& B- g4 X# ?3 S4 @
/ A% T( U8 P* M# U
未来,开发和测试边界会越来越模糊,测试也需要把重复性的工作进行自动化。

6 n# _) P# y; ]! \( c

5 ?* N8 `1 A" w7 H  A0 w: `
角色缺失
' f0 M& s7 G. F8 z5 }! T
角色分工

- ~8 p6 x/ o( x
" A+ |' K4 U" ]0 t$ N9 g7 W- G! u
1.png

3 J  d" [2 n+ i) J) V, c% l- I

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

/ X* \( L% B7 ~" K" h
: `+ x, G. V$ W% L
- E8 g" z: R6 f+ W9 x  x. y
日常活动
. A- T. q: S! ?( G
6 s/ x, b2 {4 |4 w3 r) Y: y
Planning Game
  V8 n3 W$ X# H  B3 P/ e0 [( U( m
日常活动
9 t+ _& E* l" g
1.png

- x! |7 `% x/ A8 @/ c  [4 F2 K$ i
* O3 v: ]. q( d' I
% \6 C. C! Q2 P# g
Planning Game以前的标准做法是给大家一副扑克牌,12358斐波纳契数列数字牌。现在我用Gitlab比较多,将Planning Game的所有内容列上即可,然后大家做大体迭代评估,而不是精细评估。

7 V; e  c: u' L4 n
* F  Q) x- P% o! z, I8 h
有几点经验分享一下:
: [1 g# f  b# r' R* I7 D5 j% Z
" q0 @6 }$ M6 t( p0 b9 S5 ~
  • 第一点,要负责好对应的范围,不要在一个版本里面,将所有的大功能都选择上。当把一个版本里面的大功能选择完了之后实际上等于没有选择,因为范围越大,失控也越高。 选择一些小功能或不重要的功能,作为风险缓冲。

    5 B3 D4 C& Y7 A, D* Q( {

" c0 X1 P: p: E1 g3 a6 y2 t* G$ c
  • 第二点,需要预留出技术改进的空间,什么时候做重构,什么时候做改进等等。

    # d9 m4 w3 C, o: s. g
! v, h/ _  e5 S- d
  • 第三点,迭代的周期,两个迭代出一个版本,最好是两周完成一个迭代。以版本而不是迭代做发布,预留出一周的时间做发布缓冲,并对下一个迭代进行规划。
      p' ]' ]3 w% l' ^. m. l- d1 |

! V3 P' m2 l: W% i

8 F' E9 X0 y! g) R# P! M, ~4 e
Standup Meeting
7 [9 g2 i+ V: Z2 ^! X( C7 K
日常活动
4 Y+ G9 e+ N- |+ p
1.png

7 L3 o& ^" a& }# }( X

' c6 w8 k/ v% P# d
+ t  K) v! I) O1 Q2 X! v6 s4 W
当团队比较小时,没有必要做的太重,虽然现在已经出了电子白板,个人的经验是用真实的白板操作性更好,更能体现哪些事情有关联依赖性,哪些人在做什么事。

/ t3 h, |5 P! K4 c, E- ^2 q
- f+ ?6 m$ N8 C2 \5 Q" p/ J  G
需要强调的是,每个人做的事情是自主的,但需要架构师掌控好,有限度的做出选择。对于非常重要的事情,要选对的人去做,而不是随意去做。选择的纸条项目要控制在两个以内,具有难度的要让架构师去做设计。

1 U3 O8 f  j* ]5 C
$ E. \- ?; H! ]# c! \
Review Meeting
! b3 H+ d; O- X

( K1 ]9 t( \. O# @( e$ a
日常活动

: Z7 R, o1 ]& ~8 w/ b4 z" }

5 \5 L$ ]0 ~. W
1.png

2 A$ Y5 B% L2 c  _1 i2 b
% U; M: R: z1 s: {- k* x. F
敏捷上开会还是比较多的,但内部要想办法有效率去开。Review meeting包括设计、代码、测试 Review等。大功能设计,可以去做从三分之一到二分之一再到完整的Review,这样可以减少返工率。

; K4 s7 D% P* h# V9 m
9 s9 c! j6 _, T1 i4 G, Z
End to End Demo

% a5 `+ T. e3 N% S& r- ^1 c
日常活动

. s' U* `2 H2 _5 e, P
2 J% {" `; X- Z1 E  n) u$ ]& f
1.png

! k; A9 Q2 h- n7 G5 y" d6 z% `

7 s% N# V( D2 P" k, C# S. X, B
尽快做emo,越快越好,能跑场景即可。不要让产品最后才看到Demo,也不要等所有的东西都做完,同时团队成员注意现阶段不需要挑刺。
" X0 p$ p" C; F

0 `+ B7 v4 Y( v. Q
DOD meeting
: R% U* U" t& E' \! Z
日常活动

2 p4 i  Z9 Q* p1 I& ~5 i; f. l

7 x% t# q5 \$ C8 p
1.png
9 n& R- r' j6 ]$ x. G
. I% T5 O* Y$ [6 T
DoD Meeting最好以迭代的方式,而不是版本方式。第一个迭代的DOD,要为下一个迭代做好风险控制。哪些是能做的,哪些是不能做的,哪些是需要自己做的,哪些要新增,都需要作出及时的调整。
% E6 A" K8 e# {: w
0 J+ {/ X1 n3 Z# f, ?9 S7 h' V
Retrospect Meeting
' F( [0 D: S5 O

! r4 G4 T/ W4 u- N4 I" V' ^
日常活动

- v( I7 d4 D* o
- r+ N$ p4 \  y# ]8 N" v5 W5 J
1.png

5 O& H  @' p7 L: g& d) ^

# M3 A, \4 N. @) M0 ]4 Y
定期做回顾,通常的做法是拿便利贴写三点——对每个方向提三点。选择一个轻松的环境,每个人讲一些。而回顾会的意义不是批斗或者拍马屁,曾经有一次开发把产品经理批斗的很严重,产品经理反过来又把开发骂了一顿,以上做法都不可取。
; A# k) B$ v8 u
$ @9 w6 E& u* c# T1 L, k
产品运营
3 R- P- v. ~5 Q+ d* n) n
日常活动

: I; K0 ~# R$ ]
1.png

) U$ ?- e: x) v5 g

( x+ y; s$ ~2 n/ |
整个团队也要做一些产品运营,无论产品是对内或对外,包括客户支持、数据分析,以及对内对外的分享。
! f- Z0 W6 v2 G1 i5 v; [
' G. K! v  q- b6 U! |- T
PO的工具
, c% ?1 [2 ~: z
迭代版本范围的选择原则

0 X) {1 m% P/ w- b$ }
PO的工具

+ k# `- l/ c8 x0 m: v3 D2 }9 O4 n; O

& k, V4 p. C9 P$ Z& p2 z9 T
1.png

6 G+ }  j% j, \5 r! Y

9 f2 A+ R) [4 r+ f5 V* y- B
- X9 {. d' n3 L* s1 U8 O# Y
每个迭代版本的选择,对于产品很重要。一句话概括这个版本的价值和目标最佳。要向团队成员澄清目标,否则团队成员可能不知道重点或优先级。
& K! }4 ]% y0 |5 E9 i  U  Q

$ b* U, W) \# G% b9 t
版本细节定义
0 m" n" c& r0 _' F6 G+ M; W; e. r

# c$ G/ a% q1 I6 b5 K
PO的工具
# s( ]- U+ u$ n. v; Y. p' p/ k" h

0 D  B0 Z$ ]% B$ ]* _2 c. v
1.png
8 ?/ I% J& L  u) g( s' u  N
, _$ g; q, k0 c. t
版本细节定义可以用鱼骨图表现,标注版本、周期,以及重要事项等。
" Q7 r4 ^2 k+ U; x& t" V
  L$ y0 i7 t; E
Backlog/PRD管理
# k- e' D& N* d0 K  ^; A) }
PO的工具
, s0 r& O! w. Q, R/ K2 Z
8 X9 S2 p0 z1 \0 c: l9 B) Y
1.png
' {/ A5 C( }8 P/ L! c1 ?

2 \; X; n2 @7 Z6 U! r) v

0 i7 w( \. M0 U( k9 W: A0 k! R* u

' z6 k4 o$ n0 A# y' K+ X$ Q$ I. t3 k
Backlog无需和代码绑定,在Wiki里进行管理即可。虽然Backlog很多时候只表现粗略的需求,但其好处容易与相关团队成员达成优先级别的一致。

) J# ~" [1 \! p1 K$ p0 s4 r
5 R( l- H- {" b5 K4 m: t
小公司做产品时容易忽略Backlog管理,想到哪做到哪。Backlog的定义详见PPT。

' i2 u( f! Y) ?- i
% K8 \% s( c' T9 d
产品功能地图

) d0 Z/ X2 L# m/ u
PO的工具

* p  Z* n6 e' u: F

1 s% E, n! S9 A8 d0 J/ ]8 N
1.png
8 S3 ]( U, \) I1 n
产品要做功能地图,用脑图的方式归纳整理便于大家理解,另一个好处是便于开发和测试补充遗漏,如果运用好功能地图,会更好的沟通,以及做功能之间的相关性测试。

' J) f3 p; p' m5 W

( j; B7 I  O, v! v, @# f+ R, \1 {
任务拆解与管理

1 D5 ?8 t, |& L0 w% @
) q) ?6 R+ D! Y* P4 |+ ], d
PO的工具
0 s; m6 D0 O3 [
1.png

& J& W! a: q) |% ^) v
, c0 H, M- m0 W
任务完成后需要进行分解,用Gitlab的Issue方式去管理,每天站会时汇报工作进度,测试对完成的功能进行测试,细节需要讨论的,和测试提的BUG直接写到Issue上去即可。

- r4 t4 D! J; h+ o( L; ^5 B

( R5 O& S- a3 ]: ?
版本Release Note
1 Y& P1 y% r6 a: u, E
PO的工具

/ W7 C' \; K  a
1.png
4 Q+ P) G# Z: M

  P1 {# M% C* e9 W3 j2 s: D) h( d: \$ x
4 _  n" W5 O  L, M; C4 ]0 b* h/ {
每个版本出来都要写上Release Note,不少公司更新迭代多个版本,但是连一个Release Note都没有。Release Note建议要写一下产品是否对其他产品依赖以及依赖的版本是什么。 之前犯过一个错误,出了版本后,由于产品已经出了多个版本,而之前依赖的下一产品版本是错误的,则导致现有产品的版本还是旧的。

" R* h- z2 j: l9 k4 `' y/ T3 V
  t2 t, S, c- r% d" U5 H
内部版本定义规则
; x- H- {9 p, O9 z
PO的工具
/ ?6 P2 m6 ~& {! P2 B
1.png
) @' F+ ^- ^& a9 ~+ `3 Q
% |4 w% S' |: e1 l, t( G5 L
很多时候我们使用有两位版本号,有三位的、也有四位的、或者纯字母。经验上三位版本号会比较好理解,第一个是大版本号,不向下兼容;中间是Feature版本号,可以向下兼容;最后一个是Patch版本。后面“-”的版本是自己内部的测试版本或RC版本。

4 d/ M! n" w+ j' E5 A: |

# M. m8 d& Q  X8 O3 J: D& _
总结9 t3 q. b& N" l) `2 `' j
! Y1 X) q! a! P, i
Scrum模式开发经验分享

$ F; L9 z0 E8 u+ e
1.png
( G8 n8 u+ u2 L; C/ D) D

  B. x4 }- l' C

0 Z, `( U& I8 O0 I+ t' f
最后,整个Scrum模式希望大家根据团队情况,来调整流程和开发模式。人是活的,流程是死的。没有明文禁止的,都可以改变和调整的。

! K& }0 E+ k% t  @: z% ~( M% i
7 C/ A, y3 @$ z5 \: N& |

8 E: W( C! q( y- K( @& Y原创:了哥(邱戈川)% B3 f; b% f( ~% }4 J

本版积分规则

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

Baidu

GMT+8, 2019-6-17 23:08 , Processed in 0.248972 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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