在SCRUM方法中将项目的利益相关者分成两大类：Pigs角色与chickens角色，
pigs即为项目组的实际参与人员，Pigs在scrum中细分为三个角色：Scrum master、Product owner、Team，这三个对等地位的角色构成一个平衡的铁三角推动整个项目的进展。
chickens为项目组的外部人员，包括经理、最终用户等等。
Scrum master不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他在项目组承担了如下的细分角色：
（1）会议主持人
他负责主持四个主要的会议：策划会议、每日站立会议、迭代评审会议、迭代回顾会议。
（2）牧羊犬
他负责屏蔽项目组外部的干扰。
（3）雷锋
他给product owner、team提供帮助，帮助product owner确定需求、排定优先级，帮助team做估算、分解任务、完成任务。
（4）外交官
当项目组外部有人不理解项目组的工作时，他负责去解释说明，负责对外发布项目组的信息。
（5）教练
他指导项目组的成员按照SCRUM的原则、方法做事情，当出现偏差时，他去纠正，可以说他是精神教父、他也是警察（QA）。如果有项目组的成员不熟悉SCRUM的方法，他要去提供相关的培训。
（6）清道夫
他负责排除在项目进展中遇到的各种障碍，如果他没有能力或资源他可以协调项目组的其他成员一起来排除障碍。
SCRUM master.并非固定的由一个人承担，可以在一个团队中，有能力的、熟悉SCRUM的成员都可以担当SCRUM master。
Product owner是产品的负责人，或者讲是需求的负责人， 他在项目组承担了如下细分角色：
（1）领域专家
他是需求方面的专家，熟悉需求。他知道客户、最终用户、以及其他利益相关者对项目的真正需求是是什么。他负责编写用户需求、维护用户需求。
（2）需求决策人
哪个需求重要，哪个需求不重要，需求的优先级如何排列，在某次发布中要发布哪些需求是他来拍板的。他负责来平衡需求、进度与资源的关系。
（3）需求讲师
他负责在项目进展过程中给项目组的其他成员讲解需求的含义，对需求进行答疑。
（4）测试员
他负责编写每个需求的验收标准，功能测试用例。
（5）验收人
当项目组成员完成某个需求后，是product owner进行功能测试，进行验收，他认可后才能认为某个需求完成了。
Product owner可以来自于用户、客户、销售部、产品策划部门或者是开发部门的需求分析人员，无论是来自哪，需要满足如下的要求：
（1）Collaborative:易于协作、易于沟通；
（2）Representative:有代表性的，能代表用户、客户、市场的利益；
（3）Authorized:有授权，得到了用户、客户、市场等的授权，有对需求的决策权；
（4）Committed:尽责，能够认真的、尽职尽责的工作；
（5）Knowledgeable:在行，明白，熟悉需求；
以上的5项要求可以简写为CRACK，这是我们的理想，在现实中找这样的product owner有一定的难度。
Product owner是一个角色，并非指是一个人，可以是多个人，但是如果是多个人，这多个人要协调一致，对需求的理解与解释是一致的。
Team是技术的责任人，他们负责实现这个系统，他们是自我管理的，不需要外部的管理者来管理他们。在一个SCRUM团队中，一般整个团队（包含product owner，scrum master）不超过10人，team应该是一专多能的全才型选手，而不是那种专业化分工的团队，这样才能保证团队的效率比较高，也易于沟通。团队的成员一般都应该是专职的人员，不能兼职同时做多个项目。team承担了如下的细分角色：
（1）设计人员
对系统进行简单设计。
（2）实现人员
负责实现整个系统，并对系统执行单元测试，构建整个系统。
(3）管理人员
大家一起来估算、一起来选择任务、一起来跟踪进展情况。
Product owner定义了这个项目做什么，Scrum master从过程上保证了如何实现这个项目，Team从技术上保证了如何实现这个项目。
在SCRUM方法中明确要求了3个文档：
1 product backlog
2 sprint backlog
3 burn-down chart
Product backlog 中列举了本项目应该实现的需求，需求采用了用户故事的方式进行描述，用户故事是一句简短的采用用户熟悉的术语表达的需求，是用户讲给开发人员的故事，不是开发人员讲给用户的故事。既然是故事，就要有人讲，谁讲呢，是product owner来讲，每次讲时可能就有细节的不同，就要有变化，但是万变不离其宗，所以故事本身是有一定的弹性的。
故事可以有标准的格式，我称之为三段论式故事，哪三段呢？
1 用户角色
2 需要的功能
3 目的
比如，有这样一个故事：
作为一个家庭主妇，我需要一个30平米的餐厅，以便于我可以招待10位朋友来用餐。
用户角色是家庭主妇，30平米的餐厅是功能需求，招待10位朋友用餐是为什么需要这个功能。千万不要小看这个三段论式的故事，需要仔细琢磨每一段的作用。用户角色表明了是谁使用这个功能，如果一个功能没有明确的使用者，是否可以删除呢？如果一个用户角色不重要，是否这个需求的优先级比较低呢？目的说明了为什么需要这个功能，这个功能解决了什么问题，如果一个功能没有明确的目的，那是否可以删除呢？如果目的不太关键，这个需求是否可以优先级比较低呢？
优先级？没错，我多次提到了优先级，需求一定要分优先级！谁来划分需求的优先级？ Product owner！如何划分优先级？根据商业价值！根据对客户、对最终用户的商业价值来划分优先级。如何区分商业价值的大小呢？比如提问如果不实现此需求，如果晚实现此需求客户是否会不满意，是哪类人不满？不满意到什么程度？也有的专家提出了更专业的方法，其实没必要，如果product owner真的称职的话，相信他，可以凭经验划分出优先级。
是否仅仅描述了这样一句话就充分了呢？其实还有第四段，即用户故事的验收标准，或者叫用户故事的测试要点，这也是由product owner来完成的，product owner可以先完成前三段，在和team member的沟通过程中，逐步丰富完善验收标准。对于前面我们提到的那个故事，如果你实现了这样一个餐厅，比如是一个2米宽，15米长的餐厅，那位家庭主妇会如何想？哈哈，如果她心理健康的话，估计她立马让你跳楼！如果她心理不健康的话，她会跳楼的。当然在敏捷的方法中不会出现这种现象，在你开发的过程中，product owner会和你随时沟通交流的，在沟通中product owner还传达了这样的信息：
1我希望这个餐厅是5米*6米；
2我希望这个餐厅光线明亮；
3我希望这个餐厅靠近厨房；
4 ......
这就是验收标准！也可以换一种角度，从如何验收的角度的来描述：
1 我会量量这个房间是否是5米*6米的；
2 我会测测如果在这个房间里白天打扑克，不开灯的话，能否看到扑克的花色和点数；
3 我会测测从厨房到餐厅需要走几步；
4 ......
如果一个故事提不出来验收标准怎么办呢？不实现它，晚实现它，直到明确了验收标准。
到目前为止我们实际讲了在product backlog中包含了5段：
Product backlog = 需求 + 优先级
= 用户故事 + 优先级 + 验收标准
= 用户角色 + 功能 + 目的 + 优先级 + 验收标准
有的专家把验收标准单列出来，我认为验收标准是需求的一部分，只不过换了一种描述方式而已，所以还是作为product backlog的一部分吧。
前面我一直在提“功能”二字，没有提非功能的需求，如果有非功能的需求怎么办？两种处理办法，一是如果能明确到某个故事，就描述在故事的验收标准中，二是写一个“技术故事”，单列出来，提醒开发人员注意这些故事，这个故事未必是product owner提出的。
对于用户故事我们希望能达到如下的理想：
1）独立性。尽可能避免故事之间存在依赖关系，故事间存在依赖关系会造成划分优先级的困难，在安排开发顺序时需要考虑故事之间的依赖关系。
2）可协商性。故事是可协商的，故事是有弹性的，故事是需要讲的，不是必须实现的书面合同或者需求。
3）对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。
4）可预测性。开发者应该能够预测（至少大致猜测）故事的规模，以及编码实现所需要的时间。
5）短小精悍。一般一个故事在一个迭代周期内一定是可以实现的，而我们提倡短周期迭代。
6）测试性。所编写的故事必须是可测试的，能够定义出验收标准。
注意，这是理想！
Product backlog在项目进展过程中是会发生变化的，只有product owner有权来修改此文档。你可以用EXCEL文件来描述它，也可以采用一些敏捷项目管理的工具来帮助你维护，或者使用一些缺陷的跟踪工具如JIRA之类的，最直观的最朴素的办法是采用不干贴纸，直接贴在办公室的白板上，让大家都能随时看到！
Sprint Backlog就是任务列表，如果映射到传统的项目管理理论中就是WBS（work breakdown structure)，而且是典型的采用面向交付物的任务分解方法得到的WBS。
比如有一个Product backlog 条目为：
作为系统的合法用户，可以通过录入账号和密码登录到系统中。
为了实现此需求，team member识别出了的任务，进行了工作量的估计，进行了任务了领用，其结果记录为：
| 用户故事作为系统的合法用户，可以通过录入账号和密码登录到系统中。 | |||
| 任务 | 估计工作量 | 责任人 | 任务状态 |
| 1）单元测试程序编写 | 30分钟 | 郭靖 | 完成 |
| 2）界面设计 | 20分钟 | 黄蓉 | 进行中 |
| 3）密码校对算法设计 | 30分钟 | 郭靖 | 进行中 |
| 4）程序调试 | 30分钟 | 郭靖 | 未开始 |
此表格是有开发人员基于经验采用头脑风暴的方法大家一起分解得到的，里面列举的任务是为了实现该用户故事必须做的事情，按照简化的原则，可做可不做的任务则删除之。估计的工作量是由责任人自己估算的，任务的工作量合计应该不超过用户故事估算的工作量。如果任务拆分后发现工作量的合计远远大于用户故事估计的工作量，则可能需要对用户故事的工作量估算值进行修订。
Product owner负责基于商业价值挑选某次交付中应该包含的用户故事，而开发人员负责基于开发的风险、用户故事之间的依赖关系等挑选在某次迭代中要实现的用户故事。
Sprint Backlog可以采用Excel、白板或者敏捷的项目管理工具进行维护。
Burn down chart翻译为燃尽图或燃烧图，很形象，是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西，也因此很喜欢scrum这种方法，这些实践简单有效、经典！
燃尽图的样例如下：
横坐标为工作日期，纵坐标估计剩余的工作量，每个点代表了在那一天估计剩余的工作量，通过折线依次连接起所有的点形成为估计剩余工作量的趋势线。另外还有一条控制线，为最初的估计工作量到结束日期的连线，一般用不同的颜色画上边的两根线。
对此图的研判规则如下：
（1）如果趋势线在控制线以下，说明进展顺利，有比较大的概率按期或提前完工；
（2）如果趋势线在控制线以上，说明有比较大的概率延期，此时需要关注进度了。
注意，趋势线并非一直下行，也有可能上行，即发生了错误的估计或遗漏的任务时，估计剩余的工作量也有可能在某天上升了。
每天开完15分钟站立会议后，由scrum master根据进展更新燃尽图。第1个点是项目最初的工作量估计值，第2个点是第最初的估计工作量减去第1天已经完成的任务的工作量，依次类推计算后续的点。任务完成的标志是什么呢？准则如下：
（1）开发人员检测：所有的单元测试用例都通过；
（2）Product owner检测：Product owner通过了所有的功能测试；
燃尽图最好是张贴在白板上，让每个人项目组成员抬头就能看见，这样给大家一个明确的视觉效果，每个人随时都能看到我们离目标有多远。
燃尽图可以每天画，表示完成某个迭代的进展趋势，也可以某次迭代结束的时候画，表示完成整个项目的进展趋势，此时横坐标就是迭代的顺序号。
燃尽图和传统项目管理理论中的挣值图比较起来更加简单、直观，这种设计深得管理的精髓！度量的精髓！真是让人佩服！
在SCRUM方法中定义了4种会议活动：
Sprint planning
Daily meeting
Sprint review
Sprint retrospective
除去开发活动外这4种会议构成了scrum方法的核心活动。
这四种会议的要点如下：
1100
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
