敏捷开发中的Scrum流程

以下部分转载自：http://developer.51cto.com/art/200907/136850.htm

任何人力流程都离不开人来执行，所以在讲解Scrum流程之前，有必要先把Scrum中的角色讲一下。

一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆起什么名字呢？”，鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样？”，“我不这么认为”，猪说, “我全身投入，而你只是参与而已”

猪是全身投入项目和Scrum过程的人，有三种角色：产品负责人（Product Owner）、ScrumMaster、团队（Team）。

角色职责ProductOwner（PO）

• 确定产品的功能
• 决定发布的日期和发布内容
• 为产品的profitability of the product (ROI)负责
• 根据市场价值确定功能优先级
• 在30天内调整功能和调整功能优先级
• 接受或拒绝接受开发团队的工作成果

ScrumMaster

• 排除产品开发和产品负责人之间的障碍，确保产品负责人直接推动开发工作
• 教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标
• 激发创造力和放权，从而改善开发团队的环境
• 千方百计实践和工具，确保每个功能增量都具备潜在可交付行

• 向各方确保团队工作进展实时更新并高度可视

Scrum Team

• 具有不同特长的团队成员，人数控制在7个左右
• 确定Sprint目标和具体说明的工作成果
• 在项目向导范围内有权利做任何事情已确保达到Sprint的目标
  
• 高度的自我管理能力
• 向Product Owner演示产品功能

鸡角色并不是实际Scrum流程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使用户和利益相关者参与到过程中的实践。参与每一个评审和计划，并提供反馈对于这些人来说是非常重要的，管理者就属于鸡。

在知道Scrum的主要角色后，我们看看下图中的过程图：它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。

第一次听到以上术语的可能不能很好的理解backlog和spring之类的东西，大家不用着急，以后会慢慢对每一个过程进行仔细讲解。

以下将对一些术语进行简单介绍，以便大家现在开始逐步了解Scrum。

【Backlog】

Product Backlog

在项目开始的时候，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。

在下一篇我将着重讲解如何制定Product Backlog，怎么写故事，如何拆分和合并故事，以及如何确定优先级和进行估算。

Sprint Backlog

Sprint Backlog 是Sprint规划会上产出的一个工作成果. 当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务，工作量小于2天。Sprint backlog完成后，Scrum team会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrum team和Product Owner 协商，调整合理得工作量到Sprint中，以确保Sprint的成功实施。

【会议】

Sprint Planning Meeting（Sprint规划会）

根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司，客户就是市场，Product Owner扮演市场代理的角色。一个Product Owner需要一个确定产品最终目标的远景，规划出今后一段时间产品发展的路线图，以及根据对投资回报的贡献确定的产品特性。他要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。

当为一个Sprint定义好足够多的Product Backlog，并且排列好优先级后Scrum就可以开始了，Sprint规划会是用来细化当前迭代的开发计划的。规划会开始的时候，Product Owner会和Scrum team一起评审版本，路线图，发布计划，及Product Backlog。Scrum Team会评审Product Backlog中功能点的时间估计并确认这些估计尽可能的准确。Scrum Team会根据资源情况看有多少feature可以放在当前的Sprint中。Scrum Team按照优先级的高低来确定开发的先后是很重要的。

当Sprint backlog确定后，ScrumMaster带领Scrum Team去分解这些功能点，细化成Sprint的一个个任务. 这些任务就是细化的来实施这些功能点的活动. Sprint Planning的这个阶段需要控制在4个小时。

Daily Scrum Meeting（每日站会）

一旦计划阶段结束，30天周期的Sprint就开始了。ScrumMaster需要组织团队成员每天开站会. 这个会议是用15分钟的时间来让大家过一下scrum的状态。在会上，每个团队成员需要问3个问题：我昨天做了什么，今天做什么，遇到哪些障碍。谁都可以参加这个会议，但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观，用于发现任何新的依赖，定位项目成员的要求，实时的调整当天开发计划.

Sprint Review Meeting（Sprint评审会）

在Sprint结束的时候召开Sprint评审会. 这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给 Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的利益相关者参加。 业务，市场，技术都要做相关的评审。由Product Owner来决定Product Backlog中的哪些功能已经开发完成 。会议的下半部分，是由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。Sprint评审会结束后，新一轮的迭代又继续开始（中间最好修整半天或者隔个周末），迭代会一直继续，直到开发了足够多的功能去交付一个产品。

下面是自己的体会为原创。

首先的项目中还是需要PM参与管理，PM需要管理项目，协调外部的资源，为scrum团队解决比如环境，工期等问题。Scrum的核心是将客户最关心的业务首先交付给用户和项目干系人，如果由于工期原因导致项目部分功能不能如期交付，用户也可以使用这些已经开发完成的核心功能。对于一个sprint执行过程中，是不允许有任何的需求变更的。如果有会安排到下个sprint中。在sprint执行过程中，每天需要控制安排一个20分钟以内的会议，会议会讲三个内容，昨天干了什么，今天干什么，有什么问题需要解决（不深入讨论）。会后会针对这些问题在进行专门会议的讨论。sprint团队的人数不能太多，10个人以下包括QA，每日例会中QA提出的问题列为团队首先解决的问题，如果人数多的话需要拆分。同时一个sprint的任务属于整个团队如果某人因为私人问题离开或者是开发进度慢或其他问题，那么团队里面的其他成员需要帮助完成他的工作，比如QA离开，那么开发需要完成测试，如果不能保证权威性，可以利用截图等手段保证。一个sprint所交付的功能是功能上完整的，经过QA测试的，QA会提供测试报告。如果没有完成会放入下一个sprint。同时scrum team成员需要在一到两个sprint后，召开sprint总结会议，一般情况只有scrum team人员和Master参加，总结执行过程中的成功经验和教训，找到或解决team和队员的问题，注意此会议找到的作用更大，解决可以会后单独沟通，提高团队的整体效率。

下面是自己对于scrum场景的一些理解：

对于国内政府献礼类的项目或某些大型企业的项目我们经常遇到的用户需求朝令夕改，工期过短的问题，scrum并不能够适用，他无法代替加班甚至可能降低效率，如果这种情况，最合适的还是每日开会，然后干不完不能走的强制手段，而且目前国内项目很多都是这种情况，所以如果实施过程中需要具体提前评估，不要领导听了敏捷就认为可以解决加班问题，这个太荒谬了。注意一般一个sprint的计划做的内容是根据你团队有多少人*每天6小时或以下（不是8小时更不是12个小时）*sprint的天数和每个任务估计花费的时间综合算出来的，所以不可能解决加班问题，而且此方案预留了部分比如培训和其他项目的会议的时间。

需要工具辅助scrum团队，比如JIRA,Jenkins，LoadRunner,自动化测试工具等。

Scrun造成对队员的考核有时候不清晰。scrun对于队员的成员要求很高，首先是以团队是否完成作为考核标准的，功过都属于团队。这要求每个队员都从主观上有意愿完成这些任务，这些任务都是在plan里面承诺的，所以要尽力去完成。如果发现完不成队员主动加班，因为这个是自己承诺的。但是这种机制有可能造成某些队员滥竽充数，每一个Sprint都指望着其他队员替他完成工作，注意如果是新的队员加入，老队员一定有义务教他保证他可以独立工作，花费1-2个sprint让他熟悉是非常有必要的，这个不算滥竽充数的。scrum的队员中至少有3-4个人是乐于奉献的，他们是团队的承上启下的关键，最好是每一个成员都有主动承担的意识（这点很难）。新成员也要在进入团队初期养成发现问题即时解决，即时沟通的习惯。

sprint中的滥竽充数的人员的现象表现为：

1）一个问题解决很长时间，问他在哪被卡住了，他只能和你说一些表象，无法深入理解问题，其他人员也无法从沟通中得到任何的有用信息。

2）上班的时候无法专心工作，活没有干完就QQ聊天，上网页等。

3）你把他的问题拿过来之后，可能用了半小时就解决了，但是他已经花费了好几天并且没有向团队说明这个问题，直到你自己发现他。

4）当关心什么时候能够做完的时候，他无法回答你这个问题，即使是没有被卡住的问题

5）已经给了4-5个sprint还是无法接手工作

6）对于他的问题，你和他分享过你的解决方案，他说他已经按照这么做了，但是后来发现根本没有做。

对于以上的人员，我们需要在定期召开sprint总结会议上进行分析，团队成员可以在会上互相批评，会议安排在一个密室里面，注意保密性，分析问题的原因。如果是业务不熟，可以安排培训，如果是技术不理解，也可以安排培训。培训会放在下一个sprint当中。如果是主观上的问题需要和该人员进行沟通，适当时候可以由Master出面要求领导帮助沟通。如在未来2-3个sprint里面仍然无效，可以采用行政手段。

最后附上萌版的流程图：