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