Scrum敏捷开发管理办法.docx
《Scrum敏捷开发管理办法.docx》由会员分享，可在线阅读，更多相关《Scrum敏捷开发管理办法.docx（10页珍藏版）》请在冰豆网上搜索。
Scrum敏捷开发管理办法
Scrum敏捷开发管理办法
一、敏捷开发概念
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进、小步快走的开发方法。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
二、敏捷开发特征
开发方法要称之为敏捷，需要具备4个基本特征：
增量的、协作的、直接的、适应性强的。
增量”是指小版本、频繁发布。
“协作”是指客户和开发人员之间紧密沟通，经常工作在一起。
“直接”是指方法本身是容易学习和修改的。
“适应”是指能把刚刚发生的改变考虑进来。
三、敏捷开发宣言
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
虽然右项也很有价值，但是我们认为左项具有更大的价值
四、敏捷宣言遵循的原则
我们遵循以下原则：
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。
敏捷过程利用变化来为客户创造竞争优势。
经常性的交付可以工作的软件，交付的间隔可以从几星期到几个月，交付间隔越短越好。
在整个项目开发期间，业务人员和开发者必须天天都在一起工作。
围绕被激励起来的个体来构建项目。
给他们所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
可以工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。
责任人、开发人员和用户应该保持长期的、恒定的开发速度。
不断的关注优秀的技能和好的设计会增强敏捷能力。
简单——尽可能减少工作量的艺术至关重要。
最好的架构、需求和设计出自于自组织的团队。
每隔一定时间，团队都要总结如何才能更有效的工作，然后相应地调整自己的行为。
五、Scrum的定义
Scrum是一个轻量级的软件开发方法。
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。
在这个框架中，整个开发周期包括若干个小的迭代周期，每个迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。
在Scrum中，使用产品BackLog来管理产品或者是项目的需求，产品backLog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为Story。
Scrum开发团队从产品BackLog中挑选最有价值的需求进行开发。
Sprint中挑选的需求经过Sprint计划会议上的分析，讨论和估算得到一个sprint的任务列表，我们称为SpringbackLog。
在每个迭代结束时，Scrum团队将交付潜在的可交付的产品增量。
六、Scrum框架术语
类型
术语
解释
3个角色
PO（ProductOwner）
产品负责人，类似产品经理岗位
SM（ScrumMaster）
Scrum活动管理者或教练，类似项目经理岗位
ScrumTeam（团队）
Scrum团队
3个工件
产品backlog
（ProductBacklog）
产品特性列表，类似需求列表，产品特性计划会议后的输出
SprintBacklog
迭代任务列表，Sprint计划会议后的输出
燃尽图（Burn-downChart）
燃尽图，进度跟踪的图表工具
5个活动
产品Backlog梳理会议
（ProductBacklogRefinement）
产品特性计划会，类似产品范围规划活动
Sprint计划会议
（SprintPlanningMeeting）
Sprint计划会议，类似项目需求澄清、任务分解活动
每日站会（DailyScrumMeeting）
每日简会，类似日工作汇报活动
Sprint评审会议
（SprintReviewMeeting）
Sprint评审会，类似软件集成活动
Sprint回顾会议
（SprintRetrospectiveMeeting）
Sprint回顾会，类似项目回顾及反思总结活动
5个价值
1.承诺–愿意对目标做出承诺
2.专注–把你的心思和能力都用到你承诺的工作上去
3.开放–Scrum把项目中的一切开放给每个人看
4.尊重–每个人都有他独特的背景和经验
5.勇气–有勇气做出承诺，履行承诺，接受别人的尊重
Sprint
冲刺，指某一次迭代开发阶段
用户故事（UserStory）
用户故事，从系统各种用户的各自使用场景角度来描述的功能要求，类似需求规格说明
任务看板
任务墙，任务跟踪的白板工具
障碍列表
障碍列表，风险记录跟踪的工具
七、SCRUM理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。
经验主义主张知识源于经验,以及基于已知的东西做决定。
Scrum采用迭代、增量的方法来优化可预见性并控制风险。
Scrum的三大支柱支撑起每个经验性过程控制的实现:
透明性、检验和适应。
Scrum的三大支柱如下：
第一：
透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。
管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。
也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
第二：
检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。
在确定检验频率时，需要考虑到检验会引起所有过程发生变化。
当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。
幸运的是，软件开发并不会出现这种情况。
另一个因素就是检验工作成果人员的技能水平和积极性。
第三：
适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。
调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：
每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
八、Scrum开发模型
引用自《火星人敏捷开发手册》
九、Scrum的角色及职责
先来说一个故事：
一只鸡对一头猪说：
“我们合伙开家饭店吧！
”猪想了想，说：
“好啊！
那我们给这个饭店起个什么名字呢？
”鸡说：
“就叫【鸡蛋和火腿】好了！
”猪回答道：
“那还是算了吧，你要做的只是下几只鸡蛋，而我却把命都搭上了！
”
因此，我们把与开发相关的干系人分为两类，“猪”类人员和“鸡”类人员。
Scrum中，以下几个角色都是“猪”类人员，他们把所有的时间和精力都投入到产品的开发中，并对产品完全负责：
1、产品负责人
产品负责人（ProductOwner）的职责如下：
•为产品的ROI负责。
•确定产品的功能。
•决定发布的日期和发布内容。
•根据市场价值确定功能优先级。
•每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）。
•接受或拒绝接受开发团队的工作成果。
ProductOwner参与Scrumplanning。
2、ScrumMaster
作为TeamLeader和Productowner紧密地工作在一起，他可以及时地为团队成员提供帮助。
他必须:
•保证团队资源完全可被利用并且全部是高产出的。
•保证各个角色及职责的良好协作。
•解决团队开发中的障碍。
•做为团队和外部的接口，屏蔽外界对团队成员的干扰。
•保证开发过程按计划进行，组织DailyScrum,SprintReviewandSprintPlanningmeetings。
3、团队
负责产品的开发
•一般情况人数在5-9个左右
•团队要跨职能
（包括开发人员、测试人员、用户界面设计师等）
•团队成员需要全职。
（有些情况例外，比如数据库管理员）
•在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
•高度的自组织能力。
•向ProductOwner演示产品功能。
•团队成员构成在sprint内不允许变化。
•团队整体向产品开发负责。
一十、Scrum工件
1、产品Backlog
有优先级的故事列表，并估算故事点
2、SprintBacklog
当前Sprint要完成的任务列表，并估算工时
•团队成员自己挑选任务，而不是指派任务
•对每一个任务，每天要更新剩余的工作量估算
•每个团队成员都可以修改Sprintbacklog，增加、删除或者修改任务
3、发布燃尽图
直观反应当前发布剩余的工作量，以Sprint周期数和故事点数为单位。
4、Sprint燃尽图
Sprint燃尽图直观的反映了Sprint过程中，剩余的工作量情况，Y轴表示剩余的工作，X轴表示Sprint的时间。
随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量有可能呈上升态势。
一十一、Sprint过程
1、Sprint计划会议
•团队从产品backlog中挑选他们承诺完成的条目。
（做什么）
•创建SprintBacklog（怎么做）
•标识具体的任务并为任务做估算
•由团队协作完成，而不是ScrumMaster
•考虑了高层设计
2、Scrum每日站会
团队每天进行15分钟的检验和适应的会议称为Scrum每日站会。
每日站会上，每个团队成员需要汇报以下三个问题：
•昨天你完成了什么
•今天你将完成什么
•完成今天的工作有什么障碍或需要协助
汇报的对象是团队，不是任何一位领导（PO,SM,团队负责人）。
汇报的重点在于第3个问题，即提出问题，进而解决。
每日站会不是进度汇报会议，这个会议是为将产品backlog条目转化成为增量的人（团队）召开的。
团队承诺实现Sprint目标和完成产品Backlog条目。
每日站会是检验朝向Sprint目标的进程，如果有必要进行后续会议对Sprint中的下一步工作进行调整，目的在在于增加团队实现目标的可能性。
这是Scrum经验过程中的重要检验和适应的会议。
3、Sprint评审会议
Sprint评审会议用来演示在这个Sprint中开发的产品功能给ProductOwner.ProducOwner会组织这阶段的会议并且邀请相关的干系人参加。
•团队展示Sprint中完成的功能
•一般是通过现场演示的方式展现功能和架构
•不要太正式
•不需要PPT
•一般控制在半个小时
•团队成员都要参加
•可以邀请所有人参加
4、Sprint回顾会议
Sprint回顾会议上，全体成员讨论有哪些好的做法，哪些不好的做法，好的做法要继续发扬，共同确定一项需改进的点在下个迭代进行改进。
•团队的定期自我检视，发现什么是好的，什么是不好的，持续改进
•一般控制在2个小时
•每个Sprint都要做
•全体参加
•ScrumMaster
•产品负责人
•团队
•可能的客户或其它干系人
一十二、Scrum开发流程
A.我们首先需要确定一个ProductBacklog（按优先顺序排列的一个产品需求列表），这个是由ProductOwner负责的。
确定优先级从4个方面考虑：
1、获得这些功能可带来的经济价值；2、开发（可能还包含支持）新功能所需的成本；3、开发新功能所产生的学习和知识的量及重要性；4、开发这些功能所减少的风险。
B.ScrumTeam根据ProductBacklog列表，做工作量的预估和安排。
C.有了ProductBacklog列表，我们需要通过SprintPlanningMeeting（Sprint计划会议）来从中挑选出一批Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个SprintBacklog。
D.SprintBacklog是由ScrumTeam去完成的，每个成员根据SprintBacklog再细化成更小的任务（细到每个任务的工作量在2天内能完成）。
E.在ScrumTeam完成计划会议上选出的SprintBacklog过程中，需要进行DailyScrumMeeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时提出可能会遇到的障碍和风险，每个人回答完成后，要走到黑板前更新自己的Sprintburndown（Sprint燃尽图）。
F.做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员。
G.当SprintBacklog里的Story被完成，也就表示一次Sprint完成，这时，我们要进行SrpintReviewMeeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个ScrumTeam的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）。
H.最后就是SprintRetrospectiveMeeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。
阶段
参与人
事务
输出
开发调研
PO，SM，团队
讨论产品需求条目
问卷调查
分析
故事列表
工作量估算
SM，团队，（PO）
使用估算扑克估算故事点
确定故事的依赖关系
带估算的故事列表
发布计划会议
PO，SM
PO确定当前发布的时间和应该包含的故事
PO向各干系人公开发布规划
产品Backlog
Sprint计划会议
SM，团队，（PO）
PO确定最近1-2个Sprint的最优先级故事
团队从产品Backlog中的最高优先级故事中挑选承诺完成的条目
分解条目成为工作项
评估工作项工时（小时为单位）
SprintBacklog
Sprint
PO，SM，团队
按SprintBacklog产出软件产品
软件产品必须是潜在可交付的（经过完整测试，可运行，有完整用户文档）
潜在可交付的产品增量
Sprint评审会议
PO，SM，团队
团队向PO及相关干系人演示产品增量
收集意见，为下一个Sprint作准备
Sprint回顾会议
SM，团队，（PO）
对开发流程进行回顾，检查哪些方法是值得保留的，哪些是要废弃的。
更好的Scrum流程
一十三、Scrum团队评价
1、PO对Sprint交付成果接受性评价、团队成员自评
2、通过燃尽图分析团队速率（迭代内完成故事点）的提升
3、通过Leangoo分析团队平均完成任务小时数（有效时间可用率）的提升
升级会员 