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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 764|回复: 0

敏捷是DevOps的本质

[复制链接]
发表于 2018-9-22 09:30:22 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-22 09:36 编辑 & |' H8 E5 q' B5 u' L
" b; ]3 \( D$ }  Y! T% N
+ d& k/ w( [  p2 @3 l. ?2 q
6 G4 Y1 d3 G# |' H2 {
前言

3 i5 S5 T& h, s/ f* e) U
Scrum模式开发经验分享
1.png
: }! K3 j1 ~, n5 j' `0 {

/ {7 |4 ]: u  l7 U* N- Y
# q' j4 Z* G2 A2 v0 G- U
Scrum出来已经很久了,很多原理性问题就不讲了。今天和大家主要分享一下Scrum实施过程中的一些经验和对其的一些感受。

/ K' P" ]9 ~% J

- B% P3 d# D% E3 m6 U$ k9 D8 Q+ [8 V
主要有四块内容——敏捷Scrum模式概貌、人员的分工、日常活动的细节、以及一些可能用到的简单工具。
# x% G6 M6 P0 q0 y7 l
5 L9 e# C; o6 {1 I8 l& v2 l( X
现行开发模式及开发过程中痛点
% [- z' W/ r, S7 ^5 E( s# T! a
敏捷模式概貌
3 z0 X: L8 W8 g* k& |* l0 }& X- `
1.png
; V8 w2 O+ J6 |3 ?) M7 S

$ v9 w8 c4 A/ N! {% E- r
Scrum已经用了很久,但为什么始终没有用到极致或者很火?
: v5 O) M. T+ `7 y. p4 t) m
, @; C* O2 b$ _
  • 大家都在做大型系统,Scrum模式难度稍大,链条过长。需要开很多协调会议,沟通成本高。
    4 u( A, J* s* t( o

& `) }: Z, E* h3 X; I; k
  • 微服务和容器化让团队规模发生转变,从以前几十人的大团队转变成现在六七人的小团队。
    : H  X  e) v5 L7 T
0 F7 t& W+ T$ z* d( T
  • 客户及运营的需求产生变化,从数月至半年的交付时间转变到几周至一月的交付时间,使得业务更倾向于快速迭代、快速交付和快速变更。
    2 C: u  z: H2 A. a
- d$ _3 n0 q% q& M: ?
什么是Scrum

* l; R9 v( N/ {" ]4 |( i! k5 [. u
敏捷模式概貌
) @1 w  @6 w6 g; @5 Z0 d
1.png

, w, H# P8 i  _( B9 y0 P3 j

+ n& r4 Y: o+ x1 u( j
上面这本书详细地介绍了敏捷,这里就不再赘述。先提几个问题:

( b. B$ q* G" @

* g7 f( p8 t! b4 T0 L0 G& l$ n
需求主导:通常需求都脱离于团队之外,上司或老板突然下达一个指令并规定出时间,而自身的事情尚未完成,所以在开发上需求到底由谁来主导?

* U% A8 P  m3 `0 _0 c  e

4 o+ q# _5 g, F" ^# f
流程主导:很多公司都有一套流程来规范每个团队所做的事情,应该团队来主导流程还是公司主导流程?

% r: P1 N7 ]' S' @9 o

. @( e& J5 D+ w, I3 z  I& ^
颠覆还是改进:敏捷是不是需要把以前的东西推翻?
$ c& i# T6 j- E+ K# P
1.png
& O( {% \; F0 j! k& ^9 \
- B$ h+ B, L- w4 d0 N7 Z* ?, I% K
什么是Scrum?SRE、Scrum、DevOps之间的关联是什么?
! h. Q6 j/ j  q  p9 B% A
/ ~1 J6 d9 d5 J& m' ?
这里简单画了一个图。DevOps首先订制一个流程,用敏捷开发基础去做DevOps。并非一定要用敏捷开发,可以尝试以快速迭代、快速交付的方式。
/ @7 g* A5 Z, p% Q6 o
% Q# N* c% v9 ]1 P, G& ~
个人理解SRE更偏向于运维,涉及一些开放性的DevOps工具或开发工具,它离整体的软件开发交付还有一定距离。

2 s4 C" Z5 ~3 B! U* K
$ o9 L) X( n, s# w
困境

: g$ Q2 q$ r% }* V; F
敏捷模式概貌

9 f- z: W9 b! ^4 `
. v& B. Y4 C4 n7 x) l' R  \
1.png

' [! B; q2 d! @3 U9 `
: \, [3 J6 r- r4 z% k& [
很多时候,大家觉得敏捷开发、DevOps的模式及理念很好,但很难落地实践,归根到底是需要做的事情太多。其实这个时候,无论是团队还是管理者,都需要停下来,做一些思考。

5 G$ Z2 |; Y% r( q7 }( a
9 u7 l2 e* b: d+ y

: k: y8 v: R+ O; a8 I8 O
自运营/服务模式

0 _2 `% D' Z7 I
敏捷模式概貌

, J. Z8 v; Q+ Y1 b) |
1.png
4 V  P3 f3 q* h2 P* E

( y- b9 I( L; }8 X3 i
N多业务团队并行,由产品或商务提出需求,但通常只有一句话。也会有一些业务分析师,把业务做好澄清后导入给团队,每一个团队产品体系里都要拆出自己理解的PRD,然后再自主规划版本,最后实施完成推送上线。

: a% X7 L/ |% l/ Z
  J- Y# A5 V7 Q1 g; d2 J  N
需要强调的是,敏捷在运维模式下很难做许多个产品统一的测试联调。一些大公司为了某个功能,将所有的产品功能对齐,等全部功能出来后再联调、测试、最后才推到市场,这是很值得“敬畏”的事。因团队和内容数量庞大繁杂,因为团队的数量,涉及的内容已经很难这样去做了。

4 D  ]0 Q! X% a- b% i
1 N+ Z$ S* O% e5 B% ~! E+ t3 K" ^
受团队数量和涉及内容的限制,最好的方式是谁最后上线,谁最后做整体测试,以此为约束。

$ ]/ h( x8 `! l: @6 d

& C. F) }2 ^+ I3 P; l. {" O
团队构成
2 o& X" \6 r! j2 E  `. k' U
敏捷模式概貌

4 G" k2 z4 e9 ~/ Q
1.png
) U: \( A5 r2 q" K

6 s" _/ K" f5 ^9 o- A% P7 }
上图即1-1-3-2模式,这是简单的实践做法。+ X+ x- _4 X0 u8 |" D2 P- {
( I8 l' }9 ^3 F7 e
/ ?2 E- L4 E4 `- t
关键性角色包括:

  r' `7 G. M7 F5 D* }) v: x
5 u2 S+ T$ t4 X! Z  m6 g
产品、架构师、开发、测试。
" {* C; N% w: x

- b6 h* b3 j2 w% w. N
找到合适的产品和架构是最重要的,开发和测试从哪来(如外包)其实并没有太大的关系。

1 V4 K/ E$ X7 m6 O6 X/ J& R* `

" B6 E1 O) q# S/ b3 N( Y6 c  J" T
沟通链条:

6 q( Q; U, Y" e' ?+ z: p& W

0 X6 z; E2 K$ A! n3 g& f
以前是产品→技术负责人→开发→测试,这样的顺序链条。但现在因团队人数的关系,所有的需求范围应该由产品直接对所有人进行沟通,以节省成本。
% P. Z; c6 y  G1 C4 J

" n6 K% u0 E* \: W6 E; L
需求澄清要由产品来做,实现指导、实现方式则由架构师来做。产品决定做什么,架构决定怎么做,这是非常重要的一点。从而营造一种氛围:外部提出的只是需求,不是技术方案或实现,技术方案和实现要由团队的架构师去把握。

  I0 }7 g- y) h. g  a. f4 ^
- D8 |, H1 f0 `/ C+ `
在团队中,可能有一个测试,四个开发,或根本没有测试,取决于团队自身情况。
+ d- p: d3 ?  c( P) r/ n& M' z4 U# o
1.png
9 E8 r* O9 {9 q7 ^% ^+ r5 h6 L
& @0 }( M) F8 [# r

! [7 ~4 x' S/ l( l4 V2 T9 ~& \
公司规模较大,团队数量较多时要视情况而定是否做Scrum to Scrum,不同的PO在一起协调和澄清每一个产品或大的场景下的分工。注意:开协调会时,要把范围控制在少数人,而不是全员大会。

1 @+ T2 h, s% o3 S) `; m6 M) B; `/ R* W
" z: x- e( `* X# z
角色分工
; u# I! c( [8 `  U" l# ~
" {1 ?; b/ H7 V$ A
角色分工之前已提过,但分完工之后,还是有很多人做了不该做的事情,如老板去做技术指导。

& k2 L$ q  c3 p. U6 g) {: L

% h8 \) a  \7 @+ E% n2 H0 U5 e
PO

: U  L2 O+ C* K( B
角色分工

! y  s2 i8 J: n, y0 g
6 y" V9 m; j& ^# H+ {  u% a
1.png

0 G! q6 V* D5 a0 z0 R% P- V: ~6 J
% H% z; p, u1 ^
不想做好测试的开发不是好PO,也就是说,一个产品做不好测试,做不好开发,那也就没必要去做产品了。几个比较大的要求点:

9 s' W3 ]3 t# i  X/ f8 B- K
  • Roadmap:需要做整个产品的Roadmap规划,至少要给出每个迭代有什么,有几个迭代,每个版本是什么样。

    0 r2 I! O& z, x1 N
/ k( Z- s, r" s5 M' S
  • 迭代范围:产品要控制迭代范围,很多公司老板说什么就是什么,导致团队越做越混乱,所以产品经理要做好澄清,对外承诺的范围要掌握在手里。

    1 R4 D- J  N) `+ v2 ?

7 E* ~5 d, U9 `7 m; m
  • 产品生命周期计划、特性Demo、推广等等。另外还需跟架构师配合,沟通产品规划中每个迭代与技术产品相关的改进点。
    $ p/ A) p7 y1 I7 H) ?! G

: c. g1 {3 R; B. T* _2 o: x) r
架构师
& X) i) X' G& P% s( {$ T
角色分工

3 y. S  k8 g* ~) @
1.png
; z0 }+ c* S: I- L
. ]- J  ]! q. g5 d- W5 G

4 g& d6 L, B. M" D0 M4 |. D
架构师需要做好实现架构的设计以及相关成员的指导(如开发、测试),组织相关人员会议,做敏捷不代表不开会,甚至一些小团队内部之间的会议可能比原来的会议还要多。

/ ]0 a  c- q2 ?: B! `
开发

) L/ h6 a) T/ U+ |- e9 Q6 C" \
角色分工

  G6 J, j1 j# x6 b/ u( f( \; \
! o1 M( H* B" ]8 l' ^0 D+ q9 y
1.png

2 {4 A$ W; u5 ?5 @8 t# ^8 C) A7 r

: g+ N' Q: Q: `- Y5 A8 R
开发没有太多的变化,唯一要做的事情就是开发要把东西做出来进行展示,让代码尽快可见。
. S; k/ `9 k' N8 r' g" s

6 @, I) q% m# a6 _$ l/ @
测试

: B, w. j5 V8 T; D2 K: j
角色分工

, N/ U8 P2 U/ X( O2 ?
1.png
$ U0 p9 Z7 i% k2 y- z
+ ]8 p  s/ i- {* T( l
测试最大的问题是很多时候被抛离团队之外,因为测试总觉得自己是最后一环。很多公司以测试Case数量作为考核,这是对于测试人员最大的误区。
& D" o8 i& b; b: h# m5 v" x7 y
/ g. M! g0 I/ S# C
理想中测试主要做测试设计,从设计角度来进行测试。测试驱动开发完善产品、弥补思考上的遗漏,同时很多公司的开发把测试当做助手,呼来唤去,是非常不对的。

2 p* Q, f+ A" V' t- v
3 K! e7 x1 l' v; e3 I8 N" [- N) X" Q
开发与测试的配合——模式转变
$ p2 ^; K% R, @4 y# P9 n/ V9 t
角色分工
5 `( y0 B9 g7 W- _9 l
8 M$ ]$ q8 J. X5 n% c" U& r
1.png

) t9 }7 x3 ^& k$ U

. N/ v" e3 K& a" P( O5 o, h# l5 W- n. q
模式上,开发和测试做一些转变。原来的模式中规划完成后,开发将产品开发出来,打包交给测试。
! U. q+ a7 h! `# k4 l5 M

, R0 b" S: x% \* c
而新的模式下,测试从第一天就要参与其中,提前进行测试设计。

7 `" V& v& G# ?  y

6 a0 O) s! w: e9 H0 O, Y, T# u/ D- h- `
开发与测试的配合——思维转变
4 j) ~$ t! W. t
角色分工
, m& d+ k6 o7 I6 B  b
: }4 [. |8 M' G, Y- i: Z# ]& E( f
1.png

1 ]: J) I5 V) d4 ^
0 C# Z9 u8 D4 a+ b! ?7 p! X' ~
开发与测试的沟通,需要整个团队进行磨合的。前面提到,测试从第一天就进行测试,不需要开发来进行信息传递,而开发更加不是测试的上游。
/ S8 {, O6 f7 \( }# u7 j
- g% q2 }9 ?' I9 W5 @- m/ {& G3 F# I
未来,开发和测试边界会越来越模糊,测试也需要把重复性的工作进行自动化。

3 Y1 c& V( H/ c1 v( |

, R6 _) K9 f4 p' e( |
角色缺失

4 H2 _7 g$ I4 L( q" z
角色分工

% T: k$ x6 E6 o6 t& r3 E# G
; w* M* j) v% Y/ `
1.png

' f# c5 `1 A0 G; R% i( y
! t9 U9 D; Z5 j! E
其实这里把Scrum Master去掉了,因为很多人把Scrum Master变成了打杂。另外如果公司全员做敏捷,建议不要在公司层面定制流程,同一公司的不同团队磨合程度又一,很多团队是靠人磨合出来的。

+ m5 W$ D! T: _3 P) J

) t: \0 l" V( P, V1 E

# T" l! s8 t* F; g
日常活动
+ U& n/ r9 V, r; x
7 o! t* V* m; I- H/ U
Planning Game

5 v9 G" e( q, F/ G
日常活动
7 y* J  V8 z: z# S% U
1.png
: u2 k- X, |: J! A, r& W# x6 k

- |. v. R; a6 ~: Q

( n, c2 l! l- ^8 G- x' _, N
Planning Game以前的标准做法是给大家一副扑克牌,12358斐波纳契数列数字牌。现在我用Gitlab比较多,将Planning Game的所有内容列上即可,然后大家做大体迭代评估,而不是精细评估。
0 R$ W8 d( h8 n1 I4 G
% ~" O0 H+ \; N! o8 q# ?9 Q
有几点经验分享一下:
; }( O7 v1 l' E: _4 }
+ M. _# Z* r" C: K
  • 第一点,要负责好对应的范围,不要在一个版本里面,将所有的大功能都选择上。当把一个版本里面的大功能选择完了之后实际上等于没有选择,因为范围越大,失控也越高。 选择一些小功能或不重要的功能,作为风险缓冲。

    5 i+ [9 _3 N  ]1 A

6 _3 z1 M; ]1 t9 @: l& z
  • 第二点,需要预留出技术改进的空间,什么时候做重构,什么时候做改进等等。
    + t* f% o) e7 ?! X7 N$ v
" K  h# [% N" o/ n
  • 第三点,迭代的周期,两个迭代出一个版本,最好是两周完成一个迭代。以版本而不是迭代做发布,预留出一周的时间做发布缓冲,并对下一个迭代进行规划。

    $ \8 Q) i: m( V& o/ F

& {$ w( c2 ~8 y4 V* E: E
& o  x" {/ l8 v8 w
Standup Meeting
5 ^) T. K, s; ]6 B" d) ^# |( F" V, x
日常活动
" ]6 h1 y, p! ~, l
1.png
3 M9 J$ f( L* c2 `0 {- f$ z  F' h

9 F. W" p) S/ }  y

; K/ u  E' e: f4 x5 A
当团队比较小时,没有必要做的太重,虽然现在已经出了电子白板,个人的经验是用真实的白板操作性更好,更能体现哪些事情有关联依赖性,哪些人在做什么事。
2 E4 a6 f& P, H, ]2 R+ G8 a
$ Y. l. Z( S/ w! w3 N3 \6 r
需要强调的是,每个人做的事情是自主的,但需要架构师掌控好,有限度的做出选择。对于非常重要的事情,要选对的人去做,而不是随意去做。选择的纸条项目要控制在两个以内,具有难度的要让架构师去做设计。
7 \! u9 t8 L! X' q. v1 }

$ y" I, Q: N7 S% u. Z1 V6 T8 G
Review Meeting

- r- m+ g5 ^8 ^7 q% b& g

% ?" @7 s, y. T. n
日常活动
5 s) G# R+ W1 g* h/ v: A

( X' M" E! Q& E. }+ K
1.png
, c4 R$ ]* d5 q: T. {
% P4 n! H) O1 j/ b* D' b
敏捷上开会还是比较多的,但内部要想办法有效率去开。Review meeting包括设计、代码、测试 Review等。大功能设计,可以去做从三分之一到二分之一再到完整的Review,这样可以减少返工率。
: Y# Z7 X' E5 y4 {/ @% h8 e
& ~( E  y/ ?1 w. B- x
End to End Demo

: g% ], p% K3 M3 f! A+ r
日常活动

: X9 S& C) [1 d) b  }) [. Z, ?
4 K% p5 \4 v! b# V) h
1.png

6 A/ R. Z/ o3 p6 L/ A
7 L: H. @; E8 G% g: M; a
尽快做emo,越快越好,能跑场景即可。不要让产品最后才看到Demo,也不要等所有的东西都做完,同时团队成员注意现阶段不需要挑刺。
9 B& [6 K9 j" J

4 \3 U2 N6 t5 Q0 ~" [( s
DOD meeting

% e* }1 o1 j, c' ]. F! D6 X
日常活动
9 U, c6 Y& x+ B! V2 x% d
2 c/ b6 L/ p  q4 R( G
1.png

8 }# g6 m# }2 p- t# [
8 W# I# v/ v: {( ]  [9 A
DoD Meeting最好以迭代的方式,而不是版本方式。第一个迭代的DOD,要为下一个迭代做好风险控制。哪些是能做的,哪些是不能做的,哪些是需要自己做的,哪些要新增,都需要作出及时的调整。

0 R- K/ S* S0 r! b2 Z: z) E  x

1 d9 _/ o1 L; P1 t2 R
Retrospect Meeting
$ i: m! L7 ?7 l6 Y& O
" H( C+ T5 R& ~6 B" b3 e  y
日常活动

) H- Z% B6 _& ^6 y3 x6 ~6 \" k

/ l! L/ l+ `, ~3 O' j3 N0 i# B% t
1.png
" u" `- V6 |+ O$ c. M9 H

/ \1 Z+ c8 r% R/ _
定期做回顾,通常的做法是拿便利贴写三点——对每个方向提三点。选择一个轻松的环境,每个人讲一些。而回顾会的意义不是批斗或者拍马屁,曾经有一次开发把产品经理批斗的很严重,产品经理反过来又把开发骂了一顿,以上做法都不可取。

* G9 t( T3 b* T
3 s+ h6 h4 Z5 d" Z
产品运营

% L9 w, |; \# C1 M4 q. f+ w
日常活动
- O, e+ x( j- E2 O" j% s, F" z
1.png
8 Q$ m' j- r/ u4 z0 J
/ C  e3 r0 T; i( S+ z
整个团队也要做一些产品运营,无论产品是对内或对外,包括客户支持、数据分析,以及对内对外的分享。

8 m. f# `4 I& _9 u' \% J
9 _. P0 U* c& H1 ~
PO的工具

: q3 ]% B/ ^) M, Y6 ~3 T% S: Z
迭代版本范围的选择原则

% c3 |- O6 x: e; J
PO的工具
2 k+ C  i3 w+ I  l" D0 W
" Y; F  S1 @" ]" q' S9 s
1.png

" E3 y4 S! w+ Y) ~1 B3 M7 a
/ F$ a  Y! U. n; `* _8 n
- ?. m4 Y& M$ P; u5 l0 N
每个迭代版本的选择,对于产品很重要。一句话概括这个版本的价值和目标最佳。要向团队成员澄清目标,否则团队成员可能不知道重点或优先级。
/ ]- n# k# u( c, ]7 Q: _
  O# w2 j/ c4 F6 _( i) J" f& h
版本细节定义

* r' V1 D: b3 W+ v

; y/ d0 i) X8 t
PO的工具
$ c/ `" R# U6 R+ Q

0 \  v- h) z" }5 {9 |' h
1.png
, @$ Y9 I+ l7 [! d4 P+ \# R& o
% U0 u: U8 o6 \# _$ P3 N- N
版本细节定义可以用鱼骨图表现,标注版本、周期,以及重要事项等。
( y( p/ e, h' |* ?+ O) J

9 q1 j* ?+ U8 A$ e& g7 B
Backlog/PRD管理
- n& X* @7 C$ I- T
PO的工具
$ i+ |& v" |' m8 t3 s0 W* @+ W

0 a, _4 M" z7 D9 _# t
1.png

0 f! [/ B5 y+ ?' R

/ V) A/ Q" n: U( X1 S+ j
) O& t6 R, s8 k3 @2 m6 ?2 A& z
( g5 m4 R, O2 A8 l7 \7 `2 J
Backlog无需和代码绑定,在Wiki里进行管理即可。虽然Backlog很多时候只表现粗略的需求,但其好处容易与相关团队成员达成优先级别的一致。

1 n) k6 j8 E5 H. f) `
! [9 H6 l- F' V9 A2 W
小公司做产品时容易忽略Backlog管理,想到哪做到哪。Backlog的定义详见PPT。
; F+ S- W3 V9 H

8 y6 Q: y7 s2 G, B( c& q
产品功能地图

( e6 t7 d3 B! H/ T( `# O6 [
PO的工具

) A# d8 b/ A) l3 o9 U

4 i5 L: K7 }% `, b
1.png
( j  C8 ]2 B' O
产品要做功能地图,用脑图的方式归纳整理便于大家理解,另一个好处是便于开发和测试补充遗漏,如果运用好功能地图,会更好的沟通,以及做功能之间的相关性测试。

+ Z& G8 r4 k+ d* l4 I
# |" s/ ~7 k) L5 Q3 R
任务拆解与管理

4 ~' u6 \! T% i6 a$ i- g

1 K1 b9 o* s) N" {' }3 v# u6 Y
PO的工具
& B7 ]3 ~, g) z3 ]0 |. \) E5 Q
1.png
; R- O$ e% h# i: Z# c8 Z0 G. a

* O" [% m2 @* z; Z/ G
任务完成后需要进行分解,用Gitlab的Issue方式去管理,每天站会时汇报工作进度,测试对完成的功能进行测试,细节需要讨论的,和测试提的BUG直接写到Issue上去即可。

1 p/ j2 Y; ]: }: o9 y7 E$ N! e' z
8 ^" Q- @- j6 _4 c  [/ D% t
版本Release Note
7 r: m% i4 ], O6 c  g
PO的工具
. G1 }- ?6 D; _3 g$ h5 }
1.png

2 p& a5 c& E: }: Y6 q" w' h
( u; r- M. I& _
7 O; v3 d+ ?: b7 b" m" ~+ j- j
每个版本出来都要写上Release Note,不少公司更新迭代多个版本,但是连一个Release Note都没有。Release Note建议要写一下产品是否对其他产品依赖以及依赖的版本是什么。 之前犯过一个错误,出了版本后,由于产品已经出了多个版本,而之前依赖的下一产品版本是错误的,则导致现有产品的版本还是旧的。

/ C; E  f2 U7 U5 ^
, j: Z& J$ T% Y- y  g: i  N
内部版本定义规则

) K/ `/ i( ?3 t  S+ L
PO的工具

$ {3 l$ ^* z7 y2 M4 S+ d9 `0 }
1.png

% a' t" R4 }% G( {8 A8 O# X
! {* x1 \& w" l' @( e0 P
很多时候我们使用有两位版本号,有三位的、也有四位的、或者纯字母。经验上三位版本号会比较好理解,第一个是大版本号,不向下兼容;中间是Feature版本号,可以向下兼容;最后一个是Patch版本。后面“-”的版本是自己内部的测试版本或RC版本。

2 n# _. C9 p+ d( T: c$ z

" {2 V% ]* O) @9 u! i
总结2 S8 ?7 E8 p  w7 E3 e
9 {9 y/ Q( j6 e
Scrum模式开发经验分享

3 A2 |: ^" R4 J2 y3 X2 R
1.png

4 T3 ^' w/ T) K5 e$ x

9 e+ ]: n' T' n& J& b
& n; ~9 N: _5 S1 W: \
最后,整个Scrum模式希望大家根据团队情况,来调整流程和开发模式。人是活的,流程是死的。没有明文禁止的,都可以改变和调整的。
2 A$ s! o. {3 L9 _
5 n; V! T1 I  U! F3 J: A- E! L6 @

) R3 e2 w% M0 E, }原创:了哥(邱戈川)
, Q3 @! P4 H% Z+ @6 f

本版积分规则

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

Baidu

GMT+8, 2019-9-23 06:58 , Processed in 0.211062 second(s), 25 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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