主流敏捷开发方法:Scrum 基础知识解释

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

人们在自己的工作中和处理问题时,应该像一个成熟的成年人一样,因此它并不涉及具体的软件开发技术和人员沟通、期望管理、问题冲突等管理技能,这些都需要其他相关理论和技能来补充。

new_page_1

Scrum概述

Scrum

来自英式橄榄球运动,本质含义就是一群人你推我搡地去抢球和控球。用球赛来类比确实是一个形象又合适的比喻,在赛场上尽管队员们努力按照既定计划推进,但是场上瞬息万变,不可能实时按照教练或者队长的指令亦步亦趋的去行事,只能靠平时训练中形成的素养见机行事,达成目标。

Scrum的核心思路

Scrum的核心思路,是首先承认我们的客户(或者我们的产品服务的用户)并不清楚自己的需求,并且人类的需求会不断变化(“requirements churn”:就是需求本身在不断地倒腾),所以我们默认需求是变化的需求,并且制定出一套策略能让整个组按照小功能快速开发,并且后续不断迭代。回归 Scrum 的英文含义:把开发就搞成一堆人在合力拼抢,把功能分成小块,快速开发和迭代。

实践框架

Scrum为软件开发管理只定义了一个高层次的、易于操作与遵循的非常小的实践集,Scrum避免了说软件团队应该如何开发软件,它坚持认为:人们在自己的工作中和处理问题时,应该像一个成熟的成年人一样,因此它并不涉及具体的软件开发技术和人员沟通、期望管理、问题冲突等管理技能,这些都需要其他相关理论和技能来补充。另外,如同其他项目一样,需要软件团队在其业务领域的专业能力来确保软件项目的成功。

Scrum价值观

  1. 承诺- 愿意对目标做出承诺
  2. 专注– 把你的心思和能力都用到你承诺的工作上去
  3. 开放– Scrum 把项目中的一切开放给每个人看
  4. 尊重– 每个人都有他独特的背景和经验
  5. 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重

以上价值观和敏捷宣言相互呼应,很多人都会忽略这些核心价值和核心思想,而是追求Scrum的一套开发流程或者开发框架。但流程框架这些都只是一个规范,不是每个团队都能直接硬套上去使用。需要有一定的调整,甚至结合其他开发方法一起使用,没有领悟敏捷开发思想是没有办法灵活使用Scrum的。

Scrum角色

Product Owner(产品负责人):

主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

Scrum Master(流程管理员):

主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

Development Team(开发团队):

主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

Scrum开发模型

12B1C4FC-CF9D-4BA4-9D92-2D74905617DD

new_page_1

(点击图片放大,按“F”键查看原图)

Scrum相应活动

产品待办事项列表梳理

  • 保持产品待办事项列表有序
  • 把看起来不再重要的事项移除或者降级
  • 增加或提升涌现出来的或变得更重要的事项
  • 将事项分解成更小的事项
  • 将事项归并为更大的事项
  • 对事项进行估算(按团队平均水平计算人时)

Sprint计划会议

在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。

Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多的工作量。

决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

总而⾔言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项。

每日Scrum会议

每日Scrum既不是向管理层汇报,也不是向产品负责⼈人或者ScrumMaster汇报。它是一个开发 团队内部的沟通会议,来保证他们对现状有一致的了解。

每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)

Sprint评审会议

所有Scrum会议都是限定时⻓长 的,Sprint评审会议的推荐时⻓长是Sprint中的每一周对应一个小时(译者注:⽐比如,一个Sprint 包含2个星期,则Sprint评审会议时⻓长为2个小时)。

团队会找到他们自己的方式来开Sprint评审会议。通常会演⽰示产品增量,整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。

Sprint回顾会议

在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在 的改进事项,为将来的改进制定计划。

Scrum团队总是在Scrum的框架内,改进他们自己的流程。这句话很重要。

满足条件

Scrum虽然十分热门,但是要成功,正确的实现它,并达到一定的效果,不是简简单单的一个命令就可以做到。特别是国内的一些传统企业,或者一些组织架构死板的公司,内部改造并不容易。当然也不是扁平化管理的初创公司就能很好的实现Scrum,人员素质,管理者经验的都是初创公司的短板。所以个人总结了要实现Scrum先要满足的几大条件。

理解思想

对Scrum的核心思想和理念真正深入的了解,而不是看中Scrum其管理流程的实现,需要结合敏捷方法的理论,从本质上了解为何Scrum要如此管理开发流程。

适配模型

熟悉Scrum提出的模型,遵循其规范的流程,但又不能被条条框框限定死,需要相关人员结合公司或者团队本身情况进行适当的调整,只要符合核心思想即可。这需要有一定智慧,知识和经验的人去了解公司业务,人员素质,再思考总结,才能制定出一套规范的开发流程,并将这套流程严格执行,这个过程甚至可能会改变公司架构。

人员素质

团队人员的素质是一个非常重要的,决定Scrum能否有效实施的条件,它包括自我管理,技术能力,知识积累,做事原则,思想智慧等,是一个综合素质的考量。关于人员开发素质的要求,可以参考极限开发XP的一些标准,来判断或者培养高素质开发人员。

有效协定

协定统一沟通的沟通方式,提高沟通效率。协定统一的版本控制方式,代码管理方式。引入统一的协助工具帮助流程流畅的执行和提高处理的效率。必要时可引入其他敏捷开发方法,相互配合使用。

参考资料

「创业技术之道」谈谈敏捷开发和Scrum

Scrum中文网(很好的一个网站,有比较规范和详细的文档)

 

作者:Frayne,个人网站:https://frayne.github.io/Agile/scrum.html

本文由 @Frayne 原创发布于人人都是产品经理。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。
1人打赏

评论( 0

登录后参与评论
加载中