Scrum敏捷开发简介

Scrum敏捷开发简介

目前的软件产品开发在管理上存在两种极端，一是过分强调过程的作用，在开发产品过程中注入大量管理活动，如诸多的产品评审、频繁的问题会议、严格的变更管理，低劣产品导致的缺陷跟踪等来提高开发过程的规范有序性。这种情况下，如果不根据具体情况来裁剪过程，导致大大提高开发成本，同时更抑制了员工的创新能力。这种情况的例子就是目前CMMI在很多公司僵化的实施。另一种极端是目前许多中小软件公司存在的一种没有开发规范，完全依赖员工的个人能力来开发产品，导致过程混乱、产品质量低劣，产品维护成本高及客户满意度低。能不能找到一个平衡点，能按一定的规范开发产品又能快速响应产品需求变化的开发模式呢？敏捷开发过程就是在这样的背景下应运而生。

特别声明:

如需转载此文，请给出本文来源:

作者：王友元

摘自：http://www.lypis.com

如不能这样做，请不要转载此文！

Scrum是与大家熟悉的极限(Extreme Programming,简称XP)编程异曲同工的一种敏捷开发方法。Scrum是一种迭代式增量软件开发过程，关注点是快速响应需求变化、早期识别并控制项目风险，确保产品按质按期交付。Scrum不仅仅用于软件的开发管理，它还可以用于软件维护团队或者作为做其他事情的计划管理方法。

   Scrum在英语的意思是橄榄球里的争球。那我们来看看橄榄球队有什么特点呢？橄榄球队有如下三个鲜明特点：一是团队目标明确；二是队员职责清晰；三是球队队员齐心协力。球队为了获得胜利，通过密切的配合完成一次次的Sprint(冲刺)。所以从我们大多数软件采用的迭代/增量开发模式行为来看，很象橄榄球的比赛模式。

Scrum敏捷开发结构示意图如下：

下面就Scrum涉及的主要角色、主要会议及主要产品作简要说明：

主要角色：

   l  产品负责人(Product Owner)：确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品的投资回报率（ROI）负责。产品负责人有点类似于我们很多公司的产品经理角色。

l  Scrum大师（Scrum Master）：是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队解决实施中的各种问题。Scrum大师与传统意义上的项目经理有点相似，但在Scrum定义中，Scrum Master主要承担领导、指导和教练工作。软件开发工作的性质决定了会有大量复杂问题的出现，Scrum Master无权直接命令开发团队做什么，但他有责任讲授怎样使用Scrum来处理项目中遇到的错综复杂的问题，并协助团队一起及时解决。

l  开发团队(Team)，一个跨职能部门的自我组织及管理的小团队，人数一般为5-9人，团队拥有交付可用软件需要的各种技能，如需求分析、设计、编码、测试等技能。

主要产品：

l  产品订单（Product backlog）：

在项目开始之前，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表我们称之为Product Backlog，是一个最终会交付给客户的产品特性列表，它们根据产品商业价值来排列优先级。如果是产品型的公司，Prodct Backlog由Product Owner根据市场分析及产品定位来确定；如果是项目型的公司，Prodct Backlog对应于客户项目合同的技术要求及客户故事（Story）得到。开发Team会根据Prodct Backlog来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和测试。对于那些以后将要实现的特性可以粗一些。

l  冲刺订单（Sprint backlog）：

Sprint backlog是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。需求开发的任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。

l  燃尽图（Burn down chart）:

燃尽图是看板的一种展现形式，是一个公开展示的图表，显示当前冲刺中未完成的任务数目、工作量等。

    看板有很多形式（如特性图、进度图、燃尽图等），目的是使Scrum团队通过看板能清晰的看到目前项目的开发状态，根据状态及时调整迭代Sprint计划。

主要会议：

l  Sprint规划会议：

Product backlog中包含了将要交付给客户的所有特性，并包含这些特性的优先级及每次迭代应完成的产品特性。Sprint规划会议主要讨论确定本次Sprint的开发任务（这类似于传统项目的启动和策划过程）。在Sprint规划会议中，Product Owner会和Scrum team一起评审产品版本，路线图，发布计划，及Product Backlog。Scrum Team评审Product backlog中功能点的时间估计并确认这些估计尽可能的准确。当Sprint backlog确定后，Scrum Master带领Scrum Team去分解这些功能点，细化成Sprint的一个个任务， 这些任务就是细化来实施这些功能点的活动。 Sprint计划会议一般控制在4个小时左右。

l  Sprint 评审会议：

Sprint评审会议主要包括对每次Sprint中重要工作产品的评审，如设计、代码、测试用例输出物等。评审的目的是确保团队开发的产品真正符合Sprint backlog的要求。

l  Sprint 总结会议：

在Sprint结束的时候需要召开Sprint总结会议， 这个会议类似于我们传统项目开发的里程碑会议，主要是讨论Sprint backlog的完成情况。相关的干系人如市场、技术、客户或代表需要参与Sprint总结会议。会议要确认本次Sprint backlog是否达成，另外还需要总结本次Sprint的经验教训，如做的好的，不好的及需要改进的方面。Sprint评审会结束后，新一轮的迭代又继续开始了。迭代会按计划次数进行，直到完成Product Backlog的全部内容并通过客户验收测试为止。

l  每日站立会议：

一旦Sprint计划会议结束，指定周期的Sprint就开始了。Scrum Master需要组织团队成员每天召开站立会议。 这个会议是用15分钟的时间来让大家描述一下scrum的状态。在会上，每个团队成员需要回答3个问题：昨天做了什么？今天准备做什么？遇到哪些问题？谁都可以参加这个会议，但只有Scrum团队成员有发言权。Scrum Master汇总这些问题并采取纠正和预防措施来解决这些问题。

结束语：

Scrum敏捷开发框架看似简单，但要有效实施并非易事。敏捷开发的目的是要“敏捷”，我们常说某个人“身手敏捷”，“思维敏捷”，意识是指动作快、反应快。会“武功”的人是多年的习武而成的；杂技团演员轻灵的表演的背后是无数汗水及艰辛！小孩是先学会走路才会奔跑的。同样，要使Scrum敏捷开发过程在企业有效的开展起来，需要Scrum团队掌握基本的知识和技能，如CMMI及PMBOK等方面的知识；需求分析、设计、编码、测试等方面的基本技能。Scrum在企业实施要产生效益，需要一个渐进的过程，从Scrum流程的建立、到团队对相关知识的理解、Scrum所需技能的修练等都需要时间。一个企业的产品开发团队逐步建立了好的开发和管理的习惯，按规矩做事，产品的质量及服务水平必然会得到有效提升。

----全文结束----

注===》若企业需要提供基于Scrum框架进行产品开发和管理流程的改进或培训的话，请与我们联系：

Email: service@lypis.com

TEL：0756-6882126

或访问珠海亮园企业管理咨询有限公司的网站www.lypis.com获取更多的信息！