|
|
EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
在开始之前还是先来做个对比：3 s2 W0 X5 a6 d8 T& L) K6 Q8 x# E
5 f# e' t+ g5 S; w 通过以上对比，我们发现，每一种研发过程模型都是在一定的历史背景下形成的，而且有各自的使用场景。当下“互联网+” 已深入人心，软件行业也在适应时代变化要求，做出适应性变革：如何接纳并响应变化、加快研发速度、持续交付软件价值乃是当务之急！近年来敏捷研发过程已得越来越多地得到世界各地软件公司特别是中小型创业团队的亲睐，让我们以审视的态度一起来看看敏捷研发到底是怎样的？汲取精华，打造属于我们自己的敏捷研发体系！
) v4 w/ w0 G0 Y5 b
8 D' v% @8 F9 `# ?# A, x$ p
敏捷(Scrum)是什么？
u% N+ T8 Z) n) x1 n4 F8 j3 T9 ?敏捷Scrum是目前国际公认的优秀管理实践! 近年来尤其在创业团队非常受欢迎！1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。
0 ~9 Z2 [. Z4 H R; BScrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄 球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。其实我们经常看到足球、篮球、乒乓球等运动教练都会有这样的冲刺迭代计划，而运动员们在场上在计划的基础上灵活机动地做出迅捷的冲刺。
: Y) X6 t1 _; h. E& r- ^9 C软件公司何尝不是这样呢？研发团队leader先做好迭代规划，排好需求功能开发优先级，调度各种资源，制定开发计划；开发中研发团队各就其职，每日反馈开发进度，根据实际情况灵活修整计划，最终给出软件产品。5 P2 ^* A- V$ L3 v& Q) u
2 [# B& h: u" F0 V
Scrum敏捷过程主要内容4 H% g( K( t" i4 z2 Y
★ 3个角色
9 z4 P) u2 g/ |* F产品负责人（Product Owner）：负责产 品需求的提炼、条目化、优先级排序。* n1 S" n6 ]; I* f3 g2 l* p7 D% B/ _
Scrum Master：负责 维护Scrum方法的秩序，并协助解决非 技术问题
# ^, k- r9 O% Z5 S: MTeam（团队） ：以“自组织”的相对扁平方式进行管理，负责完成开发工作。9 }7 P/ ~- F$ i
★ 4个活动短会# a9 C* j- Z ?9 w- ]: _' c
Sprint计划会议：团队Sprint中要完成的工作
5 `' ?* s1 t- N3 ^/ ]! c每日站会：昨天做了什么， 今天要做什么，遇到了什么困难2 y7 O0 J2 b& G6 M9 B% Q) q2 K
Sprint评审会议：小组向产品负责人展示迭代工 作结果、产品负责人给出评价和反馈、是否成功交付评价任务完成情况？
( [6 X. A! ]7 }4 W! TSprint回顾会议：在每个迭代后召开简短的反思会，总结哪些事情做的好，哪些事情做的不好 ？制定改进计划
! H7 s2 {+ p3 P* N! b★ 1个看板(敏捷日常跟进)
" L& ^4 c& M3 ^- s, P, ]! D: H看板简单说就是把所有计划、正在工作的内容（UserStory），张贴到一个划分为用户故事、计划中、进行、结束等栏位的板状空间中，一般建议使用实物板。 见下图：; B- x9 d9 q/ D5 d% k
0 k8 i: F# J& |4 L1 ~5 d
敏捷Scrum6个原则/ D; J- s. f- e% s. \7 r8 v
a. 快速迭代
9 W: w$ l4 v; b8 X2 d% k相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。
! y7 J3 w% h/ i7 |1 q3 Lb. 让测试人员和开发者参与需求讨论) P: ?' S, R, X( g
需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。
/ {0 J% c. U0 h" w& O2 sc. 编写可测试的需求文档
- e& k( ^0 `" p! c开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。5 F8 V& i% `8 f7 O7 @
d. 多沟通，尽量减少文档
' w# r* I( P3 o- _2 v任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。良好高效的沟通的重要性再怎么强调也不过分。, @6 D( c3 Y! }+ m8 i
团队要确保日常的交流，面对面沟通比邮件强得多。
8 r% ]! h, L- K u6 P% de. 做好产品原型
5 `9 o; O. r- F' }. N F建议使用草图和模型来阐明用户界面及交互。并不是所有人都可以理解一份复杂的文档，但人人都会看图，效果立竿见影。3 Q+ D' Z' {; }: l( z
f. 及早考虑测试
* R% @# X: {! Q; @) Z; E. C' H3 t0 w及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。 敏捷价值观
7 b9 \2 a8 q# `" [; g8 W& ]承诺 – 愿意对目标做出承诺
5 j6 C/ ]/ t C! J9 S专注 – 把你的心思和能力都用到你承诺的工作上去
& t# j4 F; `7 p% r1 U开放 – Scrum 把项目中的一切开放给每个人看2 y+ n H) |& k L8 L& O/ \0 \
尊重 – 每个人都有他独特的背景和经验6 i9 E P: H8 R) z# o" E
勇气 – 有勇气做出承诺，履行承诺，接纳建议8 E& P% [' H1 L+ z
共勉
5 |) a* Q/ s0 C只有适合团队的敏捷方法才是好的敏捷方法！5 G2 g) T, G* Q) v e
千里之行，始于足下！, u$ M: w' Y a
% Z5 o3 a) w) w% m4 {3 A
|
|
/1 
发表于 2021-10-13 13:44
收藏
淘帖
支持！
反对！