敏捷开发流程之Scrum:3个角色、5个会议、12原则

2020 年 2 月 06 日

敏捷开发流程之Scrum:3个角色、5个会议、12原则

一、Scrum 的定义和目的

Scrum 是一个用于开发和维护复杂产品的框架,是一个增量的、迭代的开发过程,目的是让开发人员像打橄榄球一样迅猛并充满激情,通过团队合作,提高工作效率。通过团队间的有效交互,为企业创造价值。

二、敏捷宣言

其实,在发表《敏捷宣言》之前,很多的敏捷实践都已经存在且使用了,比如:Scrum、XP、KanBan 等。之所以发表《敏捷宣言》,是因为这些实践都是在单打独斗地推进敏捷开发,而不是以一个联合体的形式,且没有一个统一的指导方针。所以 17 位敏捷联合创始人决定发表《敏捷宣言》,共同在全世界推进敏捷开发运动。下面是敏捷宣言的 4 句话:

1.png

三、Scrum 中的人员角色

3 个角色

Scrum 中的人员分为 3 个角色:产品所有者(Product Owner), Scrum Master,开发团队 (Team)。

  • 产品所有者:定义所有产品功能,决定产品发布的内容以及日期,对产品的投入产出负责,根据市场变化对需要开发的功能排列优先顺序,合理地调整产品功能和迭代顺序,认同或者拒绝迭代的交付。

  • ScrumMaster :ScrumMaster 不是项目经理,他没有分配任务的权力,没有考核的权力,没有下命令的权力,他指导项目组的成员按照 Scrum 的原则、方法做事情,领导团队完成 Scrum 的实践以及体现其价值,排除团队遇到的困难,确保团队胜任其工作,并保持高效的生产率,使得团队紧密合作,使得团队个人具有多方面职能的工作能力,保护团队不受到外来无端影响。

  • 开发团队:经典团队拥有 5-9 人,团队成员包含程序员、测试员、用户体验设计等等,团队关系在一个迭代中应该是固定的,个人的职能可以在新迭代开始时发生调整,团队自我组织和管理(自组织,自驱动),团队成员都全职工作。

四、Scrum 的开发流程

2.png

(图片源自网络)

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段,Scrum 将整个开发过程分为多次迭代(称为 Sprint,冲刺),一般为期 2~4 周,最常见的为 2 周。Scrum 并非以一段时间集中完成一个过程,而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成,每个迭代必须产生一个可以工作的软件。

4.1 五个会议

Scrum 整个开发过程分为五个会议:

1)待办事项整理会议(Backlog Grooming Meeting)

迭代计划会议开始之前 3 天召开,Product Owner 与 Scrum Master 必须参加,关键开发者或架构师需要参加;时间控制在 30 分钟到 1 小时。

由 Product Owner 将一批希望团队在下次迭代时实现的用户故事,按照实现顺序描述给在场的团队成员,Scrum Master 与在场成员分析用户故事,明确指出团队认为需求不明确的地方,Product Owner 现场记录,会后补全,Scrum Master 与架构师,还有在场成员分析用户故事需要包含哪些技术任务,Scrum Master 先把子任务建立,方便迭代计划会议的时候团队可以更准确地预估任务故事点。

会议结束时,Product Owner 确保在迭代计划会议开始之前团队提出的问题都能被解决,会议重点如果团队发现需要加强或是完善的地方,Product Owner 还有两到三天的时间可以补强,而不是浪费迭代计划会议的时间去做这件事情。

2)迭代计划会议(Sprint Planning Meeting)

产品负责人建立产品功能列表(Product Backlog)。产品功能列表是一组条目化需求,它必须从客户价值角度描述,并按优先级排序。

Scrum Master 召集相关人员召开迭代计划会,迭代计划会在每个迭代第一天召开,目的是选择本次迭代的 Backlog 和估算本次迭代的工作量。

产品负责人逐条讲解最重要的产品功能,开发团队共同估算 Backlog 所需工作量,直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题,但不干扰估算结果。队员认领任务(或由组长协商分发),独立或与别人一起完成任务;会议时间控制在 1-2 小时内。

3)每日站会(Standup Meeting)

团队内部利用每日立会来沟通进度,15 分钟结束,开发团队利用燃尽图来展示整体进度;如无特殊原因,迭代期内无变更,在每日站会上团队成员需要回答以下 3 个问题:

  • 昨天你做了什么?

  • 今天你将要做什么?

  • 你有需要帮助的地方吗?

这些都是团队成员的彼此承诺。

4)评审会(Retrospective Meeting)

小组向产品负责人展示迭代工作结果,产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加,ScrumMaster、产品所有者、团队,可能还有客户,时间控制在 1-2 小时内。

5)反思会(Retrospective Meeting)

在每个迭代后召开简短的反思会,总结哪些事情做得好,哪些事情做得不好。做得好的保留,不好的摒弃。会议得出这样的结论:开始做什么、继续做什么、停止做什么,一般控制在 15-30 分钟。

Scrum 是一套开发流程,是敏捷的一种,实施主要还是看人,强调是自组织、自驱动的,只有不断的在实际应用中仔细体会,才能理解 Scrum 的真谛,把 Scrum 用好。

4.2 12 原则

下面给出敏捷开发的 12 原则,这 12 原则作为敏捷开发对于软件开发流程的指导性纲领,也是对敏捷宣言进行了具有实际操作意义的解释,希望大家在实际应用中仔细体会。

我们遵循以下准则:

  • 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

  • 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

  • 要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

  • 项目过程中,业务人员与开发人员必须在一起工作。

  • 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

  • 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

  • 可用的软件是衡量进度的主要指标。

  • 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

  • 对技术的精益求精以及对设计的不断完善将提升敏捷性。

  • 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

  • 最佳的架构、需求和设计出自于自组织的团队。

  • 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

本文转载宜信技术学院网站。

原文链接: http://college.creditease.cn/detail/344

2020 年 2 月 06 日 10:30 166

评论

发布
暂无评论
发现更多内容

架构师训练营丨第一周丨学习总结

Frode

极客大学架构师训练营

week1.学习总结

个人练习生niki

食堂就餐卡系统设计

拈香(曾德政)

架构设计 极客大学架构师训练营

就餐卡系统UML图

漂泊者及其影子

极客大学架构师训练营

架构师训练营-作业 食堂就餐卡系统设计

netbanner

极客大学架构师训练营

就餐卡管理系统设计文档

倪惠华

架构方法之架构设计文档【总结】

小叶

架构设计

食堂就餐卡系统设计

molingwen

极客大学架构师训练营

架构师训练营总结

Coder

极客大学架构师训练营

架构师训练营-作业1-食堂就餐卡系统设计

紫极

极客大学架构师训练营 架构文档

架构师训练营 第一周总结

netbanner

极客大学架构师训练营

架构师到底是什么

molingwen

极客大学架构师训练营

缘起:被束缚的架构师

AIK

极客大学架构师训练营

食堂收费系统用例图

也良

练习1-1

闷骚程序员

架构师训练营第一周学习总结

梦行

极客大学架构师训练营

作业一:食堂就餐卡系统设计

梦行

极客大学架构师训练营

【架构训练Week01作业】Review

Rex

食堂就餐卡系统架构设计

子豪sirius

食堂就餐系统设计文档

云064

第一周作业

free[啤酒]

架构

架构师训练营第一周-总结

无心水

极客大学架构师训练营 UML

食堂就餐卡系统设计

努力努力再努力m

架构 极客大学架构师训练营

架构设计第一课

Dennis

第一周:食堂就餐卡系统设计

Alex

极客大学架构师训练营

week1-食堂就餐卡系统架构设计

暖丶冬

架构师训练营总结-1

River Tree

极客大学架构师训练营 个人总结

架构师训练营-第一周总结

+╮(╯▽╰)╭/>……

第一周:课程笔记及总结

Alex

极客大学架构师训练营

学习总结

倪惠华

食堂就餐卡系统设计

Darren

敏捷开发流程之Scrum:3个角色、5个会议、12原则-InfoQ