什么是敏捷开发(Scrum)?
进入我的博客阅读体验更好哦!博客文章链接:什么是敏捷开发(Scrum) (lxq.icu)
何为Scrum
Scrum是一个轻量级框架,它可以帮助人们、团队和组织通过针对复杂问题的自适应解决方案来产生价值。其作为一种包含迭代和增量开发原则的简单开发方法,越来越多的被用于如今的项目开发管理中。
Scrum为何能脱颖而出?
一个段子看传统管理方法的缺陷
下面是猪和鸡打算合伙开店却不欢而散的一段对话:
🐔:猪猪,咱们合伙开个餐厅吧。
🐷:行,不过餐厅卖什么呢?
🐔:就卖火腿和鸡蛋吧。
🐷:!!!我要割肉你却只要下蛋,我不干。
段子其实体现的就是付出与收益不平等的问题,类比到项目开发中,鸡就是项目经理,猪就是项目成员。项目经理不参与具体的开发却往往掌握较大的权利,可以频繁且随意的更改需求或增加任务,使得需要全力投入的项目成员苦不堪言。不仅项目组达成不了共识,而且组员常常疲于奔命,应付了事。这样开发出的项目或许不会延期,但质量却得不到保证。
Scrum所具有的优势
Scrum不同于传统的开发模式,其主打的就是自组织,是一种能积极调动项目开发人员自主性的同时兼顾项目的透明性和效率的管理模式。Scrum通过在项目经理和项目开发人员间引入一个称为“Scrum Master”的角色,有效地解决了项目经理在项目开发中权利过大的问题,增大了项目开发人员的话语权。同时Scrum还使用迭代的工作方式,一方面在组内进行定期总结,另一方面在组外进行定期汇报使得项目兼具效率、质量以及透明性。
从职位设置看Scrum
在Scrum中,参与项目的主要有三种角色:
- Product Owner——主要指项目经理,当然也包括一些利益相关方
- Scrum Master——项目总管,一般从项目开发人员中选择
- Developers——项目开发人员
三者中项目经理听取客户的需求和建议并对项目开发提出要求;项目总管一方面与项目经理就任务增加与否或需求变更与否进行协调,另一方面在开发组内为项目开发成员设置目标,保证项目推进;而项目开发人员负责按质按量地完成自己的任务并进行周期性的总结。
这样的职位设置避免了项目经理频繁且随意的更改需求和增加任务。项目组可以按照自身的实际情况推进项目,而项目总管的存在又保证了项目的稳步进行。
从流程看Scrum
Scrum的整个流程如下图所示:

下面对图中涉及的概念进行逐一解释:
-
Sprint
Sprint是Scrum中的一次迭代周期。正如现代神经网络中常常用iteration来表示一次训练,Scrum使用Sprint表示一次的工作流程。一般来说一个Sprint持续1-4周。
-
Product Backlog
Product Backlog是待办清单或者说任务清单。清单中带有任务的优先级,列出了改进产品所需要的内容。它是Scrum团队承担工作的唯一来源。
-
Sprint Planning
顾名思义,Sprint Planning就是迭代的,可改进的工作计划。
-
Sprint Backlog
Sprint Backlog是Product Backlog经由Sprint Planning指导下形成的开发清单,相较Product Backlog其更加具体。
-
Daily Scrum
Daily Scrum通常是一场15分钟左右的旨在分享工作进度和解决工作障碍的简短会议。
-
Increment
Increment的中文解释是增量。可以这么说,增量是实现产品目标的基石。每个Increment都是之前所有Increments的补充,并经过彻底验证,既作为项目已完成的一部分又作为项目未完成部分的经验和指导。
-
Sprint Review
在Sprint Review中Scrum团队向主要利益相关方展示工作成果和讨论产品目标的进展情况以确定未来的调整方向。
-
Sprint Retrospective
顾名思义,Sprint Retrospective是一种周期性的回顾,目的是改进工作计划以提高质量和效率。
了解完具体的概念后其实整个流程也就不难理解了:
Product Owner(项目经理及利益相关方)通过任务清单对项目组提出要求,项目组根据工作计划形成开发清单,每天通过简短的会议分享工作进度和解决工作障碍。1-4周后验收工作进度,将完成的工作作为增量并通过向Product Owner展示工作成果来确保项目透明性。之后通过回顾会议调整工作计划,以此为一个周期不断循环。
Scrum的价值
初步了解了Scrum,不难得出:相较传统的管理模式,Scrum在调动成员积极性、透明性和质量等方面表现得确实非常优秀。Scrum社区从五个方面阐述了Scrum的价值:

它们分别是:
- 迎难而上
- 统一目标
- 达成共识
- 相互尊重
- 开放态度
从Scrum理论重新认识Scrum
也许你会认为Scrum过于简单了,但如果你了解Scrum理论你就会知道:
Scrum是一种机制、一种框架而非解决策略。Scrum框架故意不完整,只定义了实现Scrum理论所需的部分,但这也恰恰保持了其灵活性。Scrum是建立在使用它的人的集体智慧之上的。Scrum的规则不是为人们提供详细的说明,而是指导他们的关系和交互。
同时,Scrum用启发式的方法取代了程序化的算法方法,它尊重人和自组织,以处理不可预测性和解决复杂问题。可以这么说,Scrum实现了经验主义的科学方法。
Scrum的风险管理
Scrum作为一个简洁的轻型开发框架并没有明确提出风险管理流程,其风险管理往往是以一种隐性的方式进行的,甚至说Scrum为了保持其轻量的特性特意回避了风险管理——一个对项目管理来说一个至关重要的部分。最典型的就是缺少对风险管理的量化指标。Risk management analysis in Scrum software projects就指出在实际应用中Scrum的风险管理实际和Scrum是分离的,在Scrum中集成传统实践来确保有效的风险管理是十分重要的。
笔者认为Scrum的风险管理很大程度上是依赖每次迭代周期后的review所带来的透明性,虽说Scrum不至于一点风险管理都没有(例如燃尽图(burndown chart)其实就是在跟踪整个项目过程,本身隐含了风险管理的目的),但缺少量化的具体的风险管理也许也是限制Scrum开发规模的主要原因。
燃尽图(Burndown Chart)
在此既然提到了Scrum中为数不多的(当然也是做的非常不错的)图形化管理细节——燃尽图,那么这里就仔细说说何为燃尽图。
首先,燃尽图作为一种Scrum框架追踪项目进度的可视化图表来说非常简单也非常容易理解,但这并不代表其存在就是没有必要的。一图胜千言的例子无时无刻不存在于如今信息化社会之中,用文字、语言沟通来追踪项目进度远不如图表来的直观。也正是因为燃尽图的简洁,Scrum团队可以每天使用它作为工作进度的度量标准。
一般来说,燃尽图应该包括:
- X轴——时间
- Y轴——剩余工作量
- 虚线——计划工作曲线
- 实线——实际工作曲线
一个典型的燃尽图:

请注意,Y轴可以是不同的计量单位(比如上图就是以一个用户故事[一项任务]为一个单位,还可以以剩余工作需要的时间[例如小时]作为单位)而不同单位也有其相应的优缺点(以上图用户故事为单位举例,用户故事可以直观的看出剩余任务的数量,但是不同任务的难度可能是不一样的,有可能导致对工作进度的错误估计)
除此之外,如何认识燃尽图也是至关重要的。经验丰富的Scrum团队通过燃尽图往往一眼就能看出项目进度如何,下面举几个例子。更多的燃尽图类型可以参考Understanding the Scrum Burndown Chart (methodsandtools.com)
还不错的燃尽图:


糟糕的燃尽图:


Scrum在实践中的改进方向
正如前文所说,Scrum是一种机制、一种框架而非解决策略。Scrum框架故意不完整,只定义了实现Scrum理论所需的部分,但这也恰恰保持了其灵活性。具体到实践中Scrum是如何被改良以适应多变的应用场景的呢?Why and how is Scrum being adapted in practice: A systematic review一文分析了925个实践样本从九个方面阐述了Scrum的改进方向:
- Performance——更高的项目要求
- Context——灵活性
- Architecting——调整架构设计
- Juxtaposition——并置(与其他框架组合[例如与CMMI组合])
- Distributed Development——分布式开发
- Managerial Extensions——管理扩展(在项目中加入公司总体战略,集成协调管理工具)
- User Experience——用户参与
- Size Scaling——规模扩展
- Security——安全性(风险管理)
笔者认为,若要探寻下一个或下一代的框架,经由实践改进的Scrum或许会给我们一些启发。
Reference
- Scrum Guide | Scrum Guides
- Risk management analysis in Scrum software projects - Tavares - 2019 - International Transactions in Operational Research - Wiley Online Library
- Understanding the Scrum Burndown Chart (methodsandtools.com)
- Why and how is Scrum being adapted in practice: A systematic review - ScienceDirect