Scrum敏捷软件开发过程
Scrum敏捷软件开发过程
目录
?什么是敏捷软件开发？
?敏捷方法的项目计划
?敏捷项目管理和传统项目管理
?为什么使用敏捷？
?Scrum概述
?Scrum的角色
?Scrum实践和工作产品
?敏捷开发中的估计方法
?测试驱动开发
?Scrum应用
?支持工具和模版
?一些常见的误解
敏捷开发方法
什么是敏捷软件开发?
?敏捷软件开发是软件项目的一个概念框架.
?有许多建立在敏捷概念上的方法，如Scrum 和Extreme Programming (XP).
?与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型（指纯粹形式的）?最大限度地降低短期固定时间的迭代式软件的开发风险.
敏捷宣言（2001年）
?人和交互胜过过程和工具.
?Individuals and interactions over processes and tools
?可以工作的软件胜过完备的文档.
?Working software over comprehensive documents
?客户协作胜过合同谈判.
?Customer collaboration over contract negotiation
?随时应对变化胜过遵循计划.
?Responding to change over following a plan
敏捷过程的限制
?敏捷软件开发过程包含过程、原则、工具，和最重要的-人
?因此：诚信是基础
?没有过程能够对诚信进行有效地约束，诚信与否是有效实施敏捷过程的最大限制
使用敏捷方法的项目计划
敏捷项目管理和传统项目管理
?传统项目管理：
?事先对整个项目进行估计、计划、分析
?反对变更; 变更需要重新估计、重新规划
?严密的合同来减少风险, 如果改变需求要走CR流程.
?项目作为一个“黑盒子”，对客户与供应商的可视性差.
?产品化和测试阶段是分离的.
?文档和计划驱动的方法.
?软件交付时间晚, 意识到风险的时间晚.
?敏捷项目管理:
?对整个项目做一个粗略的估计,每一次迭代都有详细的计划.
?鼓励变化, 客户价值驱动开发.
?信任和赋予权力;合约使变更变得简单，增加价值.
?客户和开发人员之间是紧密的连续的合作关系
?每次迭代都产生可交付的软件
?专注于交付软件.
?第一次迭代就可交付能工作的版本，风险发现的早.
为什么采用敏捷? –预期的收益
?采用敏捷方法得当的话，可以：
?更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险.
?快速交付, 每次迭代都能交付可运行的软件.
?最高风险和最高优先级的需求，最优先进行开发.
?改善应对变更能力, 减少大量的重计划.
?改善项目沟通.
?更好的客户参与, 避免错误的假设.
?总之:
?提高了生产率; 减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明
确的目标.
?提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结束产生可以运行的软件.
?改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌”，稳定的工作量（可持续的步伐）.
敏捷方法何时有效？
?公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.
?敏捷方法对需求不完整以及经常变换的项目比较有效.
?项目可以划分成固定时间间隔的迭代, 并且可以冻结正在进行的迭代的范围
?公司和客户都有能力担当角色尤其是Product Owner 和Scrum Master.
?项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.
?团队成员能够以自组织的方式工作.
?项目的合同允许变更.
?固定价格的项目可以使用敏捷，但应当尽量避免。
?最好在按时间和材料付费或者按月付费的项目中进行使用
?变更项目的范围不需要高级管理层的批准.
Scrum 概述
Scrum 概述(1/3)
?Scrum是管理软件项目的一个轻量级的敏捷方法, 名字来源于橄榄球运动中的scrum 过程?简单，但高度的纪律性
?依赖迭代和增量的敏捷方法.
?Scrum 是一种工作管理的方法，不仅仅限于软件开发，可以用来管理其它活动.
?Scrum 不包含技术方法或实践.
Scrum 概述(2/3) –项目的阶段
?项目分成增量的迭代过程，在Scrum中称为迭代任务清单, 通常持续2-4周的时间.
?Sprint 的时间是限定好的; 不能从外部改变正在进行中的sprint持续时间和范围.
?每个sprint都可以产生可交付的迭代, 即测试过并具备文档的的功能点
?原则上, 当产品开发到一定程度时，如实现了足够的客户价值，项目可以在任何一个sprint后结束.
?如同任何项目，敏捷的项目有三个主要阶段：
?产品定义(规划); 运行Sprints 所需要的准备、规划、技术分析.
?执行Sprints (执行): 在增量时间段内实现需求(产品需求清单).
?结束: 准备最终发布，结束项目
Scrum 概述(3/3)
Scrum 的流程
1、将整个产品Backlog 分解成Sprint Backlog ，按照目前的人力物力条件可以完成的。
2、召开Sprint 计划会议，划分、确定这个Sprint 内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算，长度不超过8 小时。
3、进入Sprint 开发周期,每个Sprint 迭代周期为连续30 个日例日（2-4周）。在这个周期内，每天需要召开每日Scrum 简会，时间为15 分钟。在会议中每个团队成员仅就以下三点发言:自上次Scrum 会议后你做了什么?从现在到下次Scrum 会议的时间里你准备做什么? 你在工作中遇到了哪些困难?
4、整个Sprint 周期结束，召开Sprint 评审会议(Sprint review meeting)，将成果演示给Product Owner ，该会议限定时间为4 小时。
5、团队成员最后召开冲刺回顾会议( Sprint retrospective meeting) ，总结问题和经验，该会议限定时间为3 小时。
6、这样周而复始，按照同样的步骤进行下一次Sprint 。
Scrum角色、实践和工作产品
Scrum中的三种角色
?Product Owner- 产品所有者
?个人：代表所有的干系人
?Scrum Master:
?个人：负责指导过程的执行
?Scrum Team – Scrum团队:
?承诺完成工作，向干系人交付产品价值
Scrum 角色– Scrum 团队
?Scrum 团队是Scrum的中心角色，产品交付要依靠团队.
?Scrum 团队自我组织、自我管理
?Scrum 团队是职能交叉的，包含产品交付的所有角色:开发人员、测试人员、build managers, 文档编写, 界面设计人员.
?Scrum 团队中的角色是不分等级的; 不应当出现“我是开发人员我不作测试”.
?团队按照最有利于项目的原则来分担责任(如组件的所有权等).
?敏捷是建立在信任和授权的基础上，因此团队是自发组织的，组员选择自己的任务，而不是别人强制加以分配的.
?另一方面，Scrum团队有交付的责任，他们需要能够自我激励和对工作目标进行承诺.
?团队最佳规模：6-10 人
?主要职责
?参与迭代任务清单的创建
?执行为干系人创造价值的工作
?根据团队的承诺完成所需的各项任务
?将工作中的各项障碍迅速与Scrum Master 进行沟通
?全面参与所有的各项会议
?更新任务状态
?自发选择任务
?标识任务的完成
?标识发现的新的任务
?与其它团队共同进行工作
◆Scrum 角色– Scrum Master
?Scrum Master不是一个管理者，而是一个教练和推动者- Scrum团队是一种自发的组织，是自我管理的.
?Scrum Master的角色通常由项目组的成员担当，组长或者项目经理。Scrum Master 应当是项目中的成员.
?主要职责:
?评价过程的健康状况
?加强过程
?消除障碍
?促进过程改进
?支持团队开发
?Scrum Master 的主要工作是做决策、消除障碍，保证团队能顺利交付产品
?Scrum Master 还有如下责任
?与其它角色配合.
?训练团队，提高生产率.
?培训产品所有者和干系人，确保Scrum流程的执行
?确保一切工作按照既定的规范来运行.
?规划并进行必要的改进.
?推动会议的召开.
?维护障碍列表
?维护Scrum过程改进列表
?优秀的Scrum Master 应当是专注的,、有决心的、有领导才能.
◆Scrum 角色– Product Owner
?产品所有者代表投资方的利益，确保交付的产品与期望的一致（提供更好的投资回报).
?Product Owner决定产品具有哪些功能.
?Product Owner’s的主要责任是创建和维护产品需求清单, 即管理项目的范围.
?Product Owner不断的把产品需求清单按优先级进行排序，使得最重要的功能能优先实现.
?对于团队来说，只有一个需求集。所有的需求申请都归口到Product Owner
?管理商业价值（投资回报）
?Product Owner 还有如下责任:
?计划项目的发布，什么时间、向什么人等.
?对每次Sprint的结果进行评审和批准
?参与Scrum会议
?迭代计划会议
?团队进展跟踪会议
?迭代评审和回顾会议
?能够随时回答团队工作中产生的各项和产品/业务相关的问题
?Product Owner 的角色一般由客户担当，作为服务提供商的公司无法设定优先级.
Scrum 角色–客户与管理层
?客户和管理的角色是可选的，需要时才设立
?客户:
?是产品的最终用户
?通过Product Owner来设定对产品的期望
?把当前的业务传达给项目.
?管理层:
?公司高级管理层,代表公司在项目中的利益.
?通过Product Owner来传达公司的利益和优先级（priorities ）
产品需求清单Product Backlog
概论
?基本上，产品需求清单是为了实现产品的功能所需要的工作的列表，包括:
?功能方面的需求; 功能点.
?非功能方面的需求, 如性能改进.
?要修改的Bug; 上一版本的已知错误.
?新技术, 如支持新的操作系统或者平台.
?问题; 日后的不确定项, 如新的功能.
?产品需求清单是不断完善的.
?Product Owner 在项目进行过程中可以随时更新：增加、删除、修改功能，变更优先级等.
?下一次迭代中要包含较高优先级的需求.
?产品需求清单也可称为User Stories (用例) ，因为它们能够给产品的用户带来价值.
?在一次迭代中要能够实现产品需求清单，如果不能全部实现要进行分解.
构成
?Product Owner负责创建最初的产品需求清单，一开始是不完整的.
?最初的清单应当包含足够的需求.
?清单应当包含多少需求, 取决于定价模型(black-box, 更多的计划时间).
?产品需求清单来源于:
?客户; 标书, 需求规格说明等.
?Scrum团队的想法; 增强型新功能等.
?现有产品的迭代增量; 已知错误, 技术问题等.
?比较好的做法是Product Owner 、Scrum团队、客户/管理以及其它相关方（如相关的Scrum 团队）举行一次或者多次研讨会
?Scrum Master 或者Product Owner 来促成会议的召开，必须要有人来做.
?要有效率、要围绕主题、沟通良好、避免不同的假设，
?承诺并且共通合作，确定优先级.
估计
?Scrum团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单位Story Points (模糊的).
?也可采用人天或者人小时作为单位，但容易混淆：a) 实际的规模b) 时间的单位.
?精确的估计值可以在Sprint 规划时给出, 当前阶段没有足够的信息.
?规模的相对值才有意义.
?这个估计值有助于确定优先级;
优先级
?优先级是产品需求清单中的主要问题.
?优先级不但反映了客户的价值也反映了风险.
?产品所有者-PO 设定优先级.
?清单中的每一项的优先级是唯一的, 但可以对它们进行分类
?优先级可以在项目的任何时候进行更改; 如新的重要的功能可以直接给较高的优先级.
?确定优先级考虑：
?价值
?风险
?依赖关系
示例
版本发布计划
?在Scrum中,不是每个Sprints 都要发布一个版本.
?迭代的结果主要是要实现功能的演示, 不一定就是发布的版本.
?版本发布计划决定了每次迭代应当包含产品需求清单的哪些功能.
?根据现有的信息制定的项目总体的长期的计划.
?根据产品需求清单和团队的进度来决定(实施的范围/迭代, e.g. in Story Points).
?Scrum团队参与版本发布计划的制定; 架构、风险、依赖性决定了可行的实现顺序.
?版本发布计划很大程度上依赖于客户的时间表和发布周期，即什么时候客户的产品需要包含我们的模块（交付物）.
?版本发布计划不是一成不变的;每个迭代结束后都可以更改.
完成的定义
?当迭代任务清单上的任务都完成时，变为“已完成”状态
?定义“已完成”的含义是非常重要的, 例如:
?如何记录软件的变化.
?使用什么样的代码分析工具，发现的问题应当如何处理.
?进行了什么样的测试, 结果是如何记录的, 通过标准（如覆盖率、修正的错误）是什么.
?定义“已完成”意味着定义质量上的需求.
?“已完成”是0/1变量：完成或者未完成. 所有的任务（task)都完成了迭代任务才算完成.
?在第一个迭代开始之前应该定义好，因为它会影响工作量, 而且必须文档化，这样团队和产品所有者的理解是一致的.
?完成的范围随着团队的成熟程度会逐渐发生变化
完成的定义- Example
?完成的定义
?遵循编码规范
?能在模拟器上演示
?使用PCLint 进行静态代码分析
?具有EUnit 测试套件的通过率和执行率.
?或者使用结对编程，或者进行代码走查
迭代任务清单Sprint Backlog
总论
?迭代任务清单规划的主要目的是从产品任务清单中挑选高优先级的任务包含在下一次迭代中，即确定迭代的范围.
?至于能够包含多少产品任务清单中的任务取决于Scum团队能够承诺完成多少.
?承诺总是来自于内部，不能从外部强加.
?迭代不应当有空闲时间, 因此规划迭代范围时要保证工作量是稳定的(进度是持续的速度).
?依赖多个因素; 团队的能力, 技术的成熟度, 当前迭代增量的情况等.
?迭代的范围在迭代任务清单中描述; 团队设定优先级.
?产品所有者PO 定义每个迭代的任务说明（mission statement），目标(sprint goal)，使迭代更具有针对性，如. “实现一个可扩展的列表控件，其项目是可以选择的”
输入和输出
逻辑
?迭代任务清单规划是“铁三角”法则的另一个例子
?在Scrum, 边界是一个变量，因为:
?资源(Scrum团队) 是确定的.
?进度表（迭代的时间）是不能变的.
?质量是无法协商的
?团队在一个迭代内能完成的任务，可以用团队进度来衡量(Story Points / Sprint).
?如果可能的话利用同一个团队上个迭代的进度, “yesterday’s weather”.
规划会议
?召开迭代任务清单规划会议的目的是确定迭代的边界.
?时间是限定的, 最长时间是一个工作日(对持续4个星期的迭代, 迭代持续的时间越短，用在规划上的时间也应该越少.
?由Scrum Master推动会议.
?由于会议时间有限，Product Owner 和Scrum 团队都应该事前进行准备.
?前提: 产品需求清单是有效的（valid）; 最新的, 标注了优先级并且表述清楚.
?规划会议要解决两个问题:
?下次迭代要做什么.
?确定迭代的目标，包含产品需求清单上高优先级的功能.
?给Bug修改留一定的余地
?怎么样实现下次增量所需要的功能.
?改进设计以实现产品需求清单上的功能.
工作流程
?产品所有者向团队介绍起草的产品需求清单和迭代目标.
?产品所有者传达迭代的起止日期.
?Scrum 团队从产品需求清单中选取高优先级的功能作为迭代的任务，如果有必要，更新其规模估计.
?Scrum 团队改进架构和设计以便能够实现提出的产品需求.
?Scrum团队把产品需求清单的每一项划分成小的任务，并估算每个任务要花费的小时数.
?“扑克规划”方法是估算工作量的有效方法.
?Scrum 团队决定一个迭代中能够实现产品需求清单的多少功能
?产品所有者和Scrum团队明确了各自要承担的义务.
Sprint Backlog 示例
执行迭代任务清单
?执行迭代任务清单意味着团队在迭代期间自行开发.
?团队清楚要达到什么的目标以及怎样达到目标.
?每人每一时间只有一个任务
?团队是自发组织的；成员自己挑选任务, Scrum Master 提供指导并清除障碍.
?不能从外部改变迭代的范围或者迭代的周期.
?为了达到迭代的目标，团队可以增加、删除任务或者改变其优先次序.
?如果要重新设定迭代的范围时需要产品所有者的配合.
?迭代周期短，意味着工期紧; 应该把重点放在剩余的工作和风险的消除，要区分任务的优先级，重要的事情应当先做.
?迭代应当达到项目的质量要求(definition of “done”);没有独立的测试阶段.
迭代进度图- Burndown Chart
?Scrum 注重成果，它关心的是要花多少时间达到目标，而不是已经花费的时间;.
?团队能否在既定的时间达到迭代的目标,可以查看要完成产品需求清单的功能所剩余的工作?Remaining work = Estimate to Complete (ETC).
?描述剩余工作量和时间关系的图表称为Sprint Burndown图, 是Scrum中非常重要的控制方法(control measure).
?给Scrum团队和产品所有者提供直观的信息.
?术语burndown 表明Scrum团队在迭代过程中消耗剩余工作的能力; 迭代结束时其值为0.
?每个任务（task ）的工作量由Scrum团队来估计.
?每天都要进行估计，以便进行跟踪.
?可以使用电子表格或者专门的工具（如ScrumWorks ）
Scrum每日例会
小鸡和猪的故事
? A chicken and a pig are together when the chicken says, "Let's start a restaurant!“
?The pig thinks it over and says, "What would we call this restaurant?“
?The chicken says, "Ham n' Eggs!“
?The pig says, "No thanks. I'd be committed, but you'd only be invol ved!“
?In a Daily Sprint, only Scrum Master and Scrum Team are committed, and thus allowed to speak.
Others are only involved.
概述
?例会最长15分钟，在整个迭代过程中每天的同一时间召开.
?团队成员之间交流信息.
?了解项目的真实的进展情况
?交流风险和存在的问题.
?面对面的会议加强了承诺.
?Scrum Master 负责整个会议(会议地点,邀请等).
?其他人可以参与, 但只允许Scrum Master 和Scrum 团队成员讲话(小鸡和猪).
?例会之前团队要更新工作量估计，使进度表保持最新.
形式
?为使会议简短而富有成效，要遵循严格的规程
?每个成员向其他人汇报以下内容:
?上次会议以后所做的工作?
?下次会议之前要做的工作?
?工作中是否有什么障碍?
?如果出现其它的问题（如设计的问题），应当在会议后处理.
?纪录会议纪要，例如wiki.
?要养成良好的会议习惯
障碍
?基本上，任何阻止团队正常工作的，都可称之为障碍，例如:
?无法访问信息系统.
?所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确
?开发环境或者原型系统出现问题
?其他的任务分配：培训，售前支持
?缺乏必要的信息或者相应的知识
?对于团队提出的各项障碍，Scrum Master要以列表形式进行记录，
谁来清除障碍？
?每个人
?自我管理、自我组织的团队
?Scrum Master
?产品所有者
?管理层
?其他相关的干系人
?Scrum Master 负责确定障碍已经清除，不一定亲自自己清除
清除障碍
?某些障碍是浪费
?部分地完成工作
?额外的过程
?额外的功能
?任务转换
?等待
?缺陷
?清除障碍的过程是团队和组织学习的过程
浪费产生的原因
?多问几个“为什么”
?对于每个标识的障碍或者浪费，问一问“为什么”浪费会存在
?多问几个“为什么”，找到造成浪费的根本原因
迭代中的同步工作
?每次迭代不是小的瀑布项目
?而是，每件事情同时都做一点
迭代的非正常终止
?在Scrum中，结束正在进行的迭代是一种极端的行为，只有在万不得以的情况下才能这么做.
?有时候确实需要停下来重新规划，而不是一味的蛮干(banging your head against the wall).
?迭代终止可能由下面的人发起:
?Scrum团队,如果他们认为达不到目标或者目标不清楚.
?Scrum Master, 如果迭代没有进展, 或者无法克服某个困难.
?客户/管理层, 如果目标已经陈旧/过时(目标产品被取消，平台过时)，或者其它的原因(资源问题等).
?迭代终止以后, 启动新迭代的计划.
?导致迭代终止的原因不应该在新的迭代中再次出现.
?要考虑到合同方面的问题，如时间表的变更等.
迭代评审会议
概述
?迭代评审，在迭代结束后进行，展示迭代的成果(功能运行).
?确保成果与预期的一致，收集反馈
?为项目提供一个参考点，根据目前的位置计划下一期的旅程
?为下次迭代提供输入（改正、修改、新的想法 可以由产品所有者添加到产品需求清单.
?与其它Scrum 会议一样, Scrum Master 主持迭代评审会议, Scrum 团队负责演示.
?参加会议的其他人包括: 产品所有者Product Owner (必须参加) 、客户、管理人员, 以及其它感兴趣的人, 例如其他Scrum团队(注意保密协议的要求).
?评审会议的时间是固定的: 最长4个小时.
?评审会议应当是非正式的、创造性的，不用幻灯片等正式的东西.
迭代评审–流程
?在评审会议召开之前，团队要做好准备:
?有组织、有效地进行演示，不要超过4个小时.
?谁来演示，演示什么，怎样演示?
?计划准备的时间不要超过一个小时.
?迭代评审流程的一个例子:
?Scrum Master 介绍本次迭代的总体情况.
?目标和清单vs. 实际的结果, 如果存在差距，原因是什么.
?Scrum 团队简要介绍所涉及的技术问题，如架构及其变更.
?Scrum 团队演示已经实现的功能:
?演示并进行功能说明
?在场的人能够亲自尝试使用不同的功能.
?Scrum Master 推动自由讨论，集思广益.
?迭代评审应当是互动的; 有问题提出, 问题解答，并欢迎提出想法和建议.
迭代评审–可能的措施
?产品所有者根据评审的结果可能采取如下行动:
?更新产品需求清单，重新设定优先级:
?包含没有按计划实现的功能(进度比预期的要慢, 任务未完成).
?不在计划中当却已经实现的功能(进度比预期的快).
?迭代评审中出现的新的想法.
?与Scrum Master 一起解决团队的变动问题.
?要求把演示的功能，或者把上次迭代的功能，作为一个版本发布给客户.
?决定项目不再持续下去，不再进行迭代; 认为产品已完备.
?要求把产品需求清单授权给另外的团队来一起工作.
?… …
迭代回顾会议Sprint Retrospective
?回顾的目的是评价本次迭代并酝酿改进，使得下一个迭代进行的更好.
?类似于项目的最终评审，但经常举行.
?障碍列表具有很好的参考价值!
?Scrum Master主持召开, 持续半天, Scrum团队参加(产品所有者也可参加).
?简单流程:
?Scrum Master 总结本次迭代; 迭代任务清单, 重要的事情和决策, 预期的/实际进度.
?每个组员陈述迭代中那些方法进行的较好、哪些需要改进, Scrum Master 进行记录.
?对重要的问题计划相应的措施：团队自己解决, 或者提交给公司的管理层. Scrum方法应用
扑克Poker方法
敏捷开发中使用扑克Poker方法进行估计(1/3)
?尽管名字有好笑, 但却非常可靠和有效.
?可以来估算产品需求清单中每项的规模（规模估算: 用例点story point）以及迭代任务清单中任务的估计(工作量估算：人时).
?Scrum Master推动活动的进行, 一个以上的专家参与估算, 而且最好是项目团队中的人.
?估算时使用卡片：写有一系列的离散数据，如0, 1, 2, 3, 5, 8, 13, ? (无法估计).
敏捷开发中使用扑克Poker方法进行估计(2/3)
?前提条件: 提前准备好要估算的任务、User Stories等; 迭代任务清单和产品需求清单都已经起草好.
?对某个任务最有经验的开发者做一个简短的概述. 可以通过简短的讨论澄清任务的具体含义，找出存在的风险以及不确定性.
?各自对任务进行估计，所有的人将写有各自估计数据的扑克/卡片扣上。(单位事先进行约定：工时、事件点).
?大家同时把扑克/卡片翻过来.
?如果扑克/卡片上的数差距比较明显(如一个13，2个5，一个1), 就要讨论一下为什么会出现这么大的差距，估计值所基于的假定要进行澄清.
?如果差距较小(如三个8两个5) ，主持人帮助确定最终的估值.
?对于不确定性，估算数据中可以多包含一些余量.
?不断的重复该过程直到达成一致.
?将这些估值记录到相应的文档中(产品需求清单, 迭代任务清单).
敏捷开发中使用扑克Poker方法进行估计(3/3)
?为什么使用离散的数字?
?比使用任意数字更加容易进行估算.
?在整个项目中或者迭代中, 每个人估计值的错误会相互抵消掉.
?对每个任务, 16 小时是上限, 不确定性会随着规模的增加而增加.
?为什么要有“?”.
?将较大的任务进行分解，帮助更加精确的估计同时减少不确定性.
?为什么要“讨论并重复”?
?弄清不同的假设(利用重用代码或者重新编码) 和可能的误解 更为可靠的估计.
?对于那些偏离平均值的估计，即使由有经验的人给出的，也必须要有充分的理由. 测试驱动开发Test Driven Development
?什么是测试驱动？
?一种能够支持Scrum的敏捷实践方法，开发满足DoD的软件
?首先创建测试用例，然后开发软件通过测试(在开发代码前，首先编写测试代码) ?一种设计软件的方法，而不仅仅是一种测试方法
?所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护
?不需要测试的工作不需要完成
?所创建的测试用例通常替代详细的业务和技术需求定
?测试也有效地驱动设计，使设计更加趋向于可行的设计
?通常情况下需要自动测试的支持(EUnit, JUnit etc.).
?对于UI软件应用TDD方法有一定的困难
测试驱动开发– TDD
?测试用例的作用：
?确定所要完成的工作
?沟通工具
?产生一致的结果
?对软件开发提供一个安全的保障
Scrum的核心
?反馈
?检查
?接受
Scrum的应用
◆概述
?基本原则: 不能只挑自己喜欢的，不管其它的
?Scrum非常简单，为了有效地发挥作用，应当具备:
?所有的角色.
?所有的实践.
?所有的产品.
?Scrum 可以进行裁剪, 但应当明白裁剪对工程的影响→需要经验和仔细考虑.
◆大型/跨地域项目
?6到10人在同一房间进行工作时，Scrum能够发挥最大效用.
?Scrum也可应用在大型的跨地域的项目.
?一些指导原则:
?将大的项目分成多个团队，每个团队6到10人，有各自的Scrum Master.
?对跨地域的项目，尽量不要把一个Scrum团队分到多个地方，一个Scrum团队就在一个地方，有自己的Scrum Master.
?但是，如果团队的跨地域是不可避免的，可以使用网络工具远程召开Scrum例会.
?划分团队时，团队之间应该有一个“自然界面”，如为避免混乱，不同的团队负责产品的不同部分.
?对于整个项目/产品：一个产品/项目只能有一个产品所有者和产品需求清单.
?团队之间的协调利用Scrum of Scrums方法
◆Scrum of Scrums
◆固定价格的项目
?Scrum 不鼓励固定价格的项目
?每次迭代时进行项目预算, 产品需求清单可以根据当前的优先级进行调整.
?某些项目中, 客户需要我们对整个项目给一个报价或者预算.
?价格固定限制了灵活性(对变化的响应):
?如果价格和进度是固定的，那么整个项目的范围也是固定的(PB).
?必须对项目所有的迭代都进行详细的计划和规模估计.
?变更项目的范围，以及随之而来的预算/进度的变更需要提交CR.
?当然可以改变产品需求清单的优先级，或者不改变工作量前提下把其中的某一项换成另一项.
?仍然可以使用Scrum，并从中获益
支持工具和模版
一些常见的误解
?敏捷是拯救任何项目的银弹.
?敏捷方法只有运用得当才有效果.
?敏捷意味着ad-hoc hacking ，不需要任何文档.
?敏捷是有严格要求的，也是面向质量的
?根据沟通的需要产生相应的文档.
?敏捷只是开发者的问题
?基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.
?采用敏捷方法的开发组/项目不需要制定计划
?敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的.
?敏捷项目的范围可以随时改变.
?变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更?只对小项目适用
?在中型和大型的项目中一样取得了成功
敏捷开发各阶段的主要活动
项目生命周期
?主要包含三个阶段：
?产品定义(计划)：进行迭代所需要的项目准备、项目计划和技术分析
?迭代开发(执行)：在固定时间的迭代中实现需求（产品需求清单中的项目）
?结束：准备最终的发布，结束项目(ramp down)
产品定义阶段
?通常称为“Sprint Zero”
?也使用Scrum的实践，例如每日会议
SCRUM开发流程
SCRUM的基础知识 Scrum 是迭代的，增量型的流程。Scrum 构造的产品迭代周期为Sprints, 工作的迭代时间一般为一到四周。Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作——展示并取得相关的反馈，为下一Sprint 做好准备。Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。 Scrum 中的角色 在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster。 产品所有者（Product Owner）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者这一角色在许多企业中是由产品经理或产品市场经理担任。 开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。Scrum 团队通常包括五到十个成员，尽管团队大到15 个成员和小到3 个成员也有很好的收效。团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。开发项目包括15 个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。 ScrumMaster 的任务是以任何方式帮助整个团队取得成功。ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum 的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。ScrumMaster 和产品所有者不应是同一人；有时， ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。 除以上三个角色之外，还有其他对于项目成功作出重要贡献的人员：可能其中最重要的是经理。他们的角色在Scrum 中的发展, 他们仍保持了相当重要的位置——他们支持开发团队使用Scrum，他们为整个项目的开发提供知识，技术和各种必要的协助。在Scrum 中，这些人转化了以前“保姆”式的角色（布置任务，收取进程报告，和其他一些谨小慎微的管理方式），取而代之的是承担起更多的“指导“作用（指导职业发展，在职辅导培训，扮演魔鬼的代言人，协助铲除障碍，帮助解决问题，提供创新的建议和指导团队成员的技能发展）。为了能更好地实现这一变化，经理们需要改进他们的管理方式方法。
敏捷开发Scrum
https://www.sodocs.net/doc/5617049097.html, 个人管理－使用Scrum来敏捷自己 每个人都有自己的生活和自己的职业或事业，如果把经营个人成长作为一个项目来看，那么在这个个人管理项目中，我们每个人都是这个项目的管理者和执行者。 Scrum敏捷开发方法 如果你是一名开发人员，那么现在还不知道Scrum方法，那么你就out了。Scrum是一种现在普遍流行并且很好的一种基于管理为主的敏捷项目开发方法。我之前blog中全面概要的介绍了一下Scrum方法，如果你不熟悉的而又想了解下面内容，请你最好去去仔细看看我这篇文章《流程－从IT方法论来谈Scrum》，因为下面我将描述我们如何基于Scrum方法来进行个人管理项目的执行。 价值观 在Agile Software Development with Scrum一书中指出，Scrum的核心价值观是：承诺、专注、公开、敬重和勇气，它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则，这些价值观对个人管理依然非常有效。 1. 承诺（Commitment）：我们是否经常暗下决心，一定要戒掉游戏，一定要完成这 个任务，但是最后是不是仍旧还存在脑子里。如果你有这种现象，那么你需要做的就是自己对自己承诺，自己相信自己，如果自己都不能相信自己，那么谁又能相信你呢？ 2. 专注（Focus）：要事第一，对一件事情投入100％去做好 3. 公开（Openness）：有人说，能力就像怀孕一样，时间久了才能看出来，你个人 的学习、个人的Open都需要公开的表达才能让别人知道 4. 敬重（Respect）：三人行必有我师，空杯心态，尊重每一个人，向不同的学习
Scrum介绍(中文版)
Copyright ? 2010 https://www.sodocs.net/doc/5617049097.html, 专业的敏捷开发社区 Scrum 中文网 Scrum介绍 Scrum中文网 https://www.sodocs.net/doc/5617049097.html, 版权说明：本文部分资料及图片翻译自Pete Deemer 的Introduction to Scrum for Managers and Executives 以及Mike Cohn 的An Introduction to Scrum.
专业的敏捷开发社区 Scrum 中文网 许多企业面临的问题与挑战 ? 产品投放市场的时间太慢 ? 项目失败的比例高的离谱 ? 投资回报低，经常失败 ? 对变化与变更的响应，难度大且成本高 ? 客户体验及客户为导向很差 ? 软件质量不过关 ? 生产力需要大幅提高 ? 员工士气，动力及责任感很低 ? 需要普遍的微观管理 ? 人员流失率特别高 ......
专业的敏捷开发社区 Scrum 中文网 越来越多的企业开始使用Scrum 解决这些问题 ?Google ?IBM ?Nokia ?Siemens ?Philips ?Accenture ?Sun ?UbisoB ?Bleum ?SAP ? Microsoft ? Infosys ? Oracle ? Wipro ? Motorola ? Yahoo! ? Schneider ? Agilent ? Irdeto ? Double Click ? Autodesk ? Tencent ? Plenware ? Trendmicro ? Moody ’s ? StarCite
专业的敏捷开发社区 Scrum 中文网 哪些类型的项目已经在使用Scrum ?大型企业级软件项目 ?商业软件产品 ?消费者软件项目/大型网站 ?美国FDA批准的应用于X射线和MRI的软件 ?高可靠性系统（99.9999％以上） ?财务支付系统 ?智能家居项目 ?战斗机项目 ?大型数据库应用 ?嵌入式电信系统 ?手机项目 ?CMMI5级的组织 ?多地点同步开发 ?支撑和维护项目 ?非软件项目 ? ……
Scrum开发流程中的三大角色学习资料
产品负责人（Product Owner） 主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。 流程管理员（Scrum Master） 主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。 开发团队（Scrum Team） 主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。 Scrum流程图
//------------------------ 下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。 什么是Sprint？ Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。 如何进行Scrum开发？ 1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负 责的； 2、Scrum Team根据Product Backlog列表，做工作量的预估和安排； 3、有了Product Backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议）来从中挑选出 一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog； 4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任 务的工作量在2天内能完成）； 5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行Daily Scrum Meeting（每日站立会 议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）； 6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集 成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员； 7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）； 8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言， 总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
敏捷开发简介
敏捷开发简介 2009-04-21 17:46:34.0 来源:https://www.sodocs.net/doc/5617049097.html, 关键词：Scrum精益开发敏捷开发 在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷也已大行其道，受到许多资深项目管理者和开发人员的推崇。欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎所有的开发团队都在实施敏捷。 敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。下面我们就对敏捷开发做一个简单的介绍和讨论。 敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等。所有这些方法都具有以下共同特征，它们也是敏捷开发的原则和方法：1.迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周 期持续的时间一般较短，通常为一到六周。 2.增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使 用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化 和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。 4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候 集成，有些项目则每天都在这么做。 5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给 人。 简史 许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（IID）起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被IBM联邦系统部（FSD）和沃森研究中心（Watson Research Center）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿.罗伊斯（Winston Royce）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。 20世纪70年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在1976年，Tom Gilb在他的著作《软件度量》（“Soft ware Metrics”）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由IBM联邦系统部（IBM FSD）在1977至1980年完成。一些典型的敏捷做法，如使用8个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。 20世纪80年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型（Spiral model）。80年代初，在美国国防部发生
Scrum开发流程介绍
一、Scrum开发流程介绍 SCRUM 方法是由Ken Schwaber 和Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM 方法最初实践于Easel 公司(1993 年) ，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。SCRUM 提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master 、SCRUM Team 、Demo 等模式已被PLOP 作为组织和过程模式（Organizational and Process Pattern）的标准。 SCRUM 的基本假设是：开发软件就像开发新产品，无法一开始就能定义Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。Scrum 有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进，因此，SCRUM 非常适用于产品开发项目。 SCRUM 开发流程通常以1-6 周为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于每个周期后交付成果，团队每天用15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做scrum meeting。 SCRUM 较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。SCRUM方法的开发过程包括三个过程：(1) 计划和体系结构设计（确定性过程）Backlog；(2) Sprint（经验性过程）(3) 交付和巩固（确定性过程）SCRUM 过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint 期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。SCRUM 对过程的管理有很多独特的方法。SCRUM 在实践中大大提高了生产率（据软件生产率组织的Capers Jones 称可提高 6 倍）。 名词解释: 1、SCRUM Meeting:团队每天用15 分钟开会检视每个成员的进度与计划，了 解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做
Scrum开发流程最佳实践
1.角色分工、职责与义务 本流程内按不同的职责将人员划分为四个角色：PO（Product Owner），PD（Product Designer）和开发人员和架构组（Architect）。 1.1.PO的职责与义务 1)PO的职责为收集提出的需求并对其进行分析，输出产品为可以直接应用于产品设计与 开发的需求文档。 2)需求文档是产品设计与开发过程中针对产品功能的唯一参考文档。 3)需求文档应当包含产品设计和开发中需要使用到的全部功能性信息，包括且不限于主要 功能模块划分、详细用例描述、系统输入与输出数据的定义等等。 4)需求文档必须为针对客户需求进行分析总结的结果，其中对功能的描述应具有通用性， 而不应仅针对用户提出某些特定场景。 5)需求文档中所有的内容都应是确定的和无疑义的，应保证任何人通过阅读需求文档所得 出的理解是基本一致的。 6)任何在系统使用过程中可以录入的数据都不是需求的一部分。 7)对需求文档进行的任何修改都应留有历史记录，记录中应包含新增或修改的章节、修改 的内容、进行修改的时间和修改人的姓名。 8)PO对需求文档中的内容拥有最终解释权。 9)PO需要提供的文档如下： 必须提供的文档：需求文档 非必须的文档：辅助其他人员理解需求的参考资料（比如行业规范，网站上的介绍，宣传资料，自己做的图表等等） 1.2.PD的职责与义务 1)PD的职责为按照需求文档进行界面和用户体验设计，输出产品为界面设计及相关说明 文档。 2)界面设计中应当完整体现需求文档中描述的全部功能。 3)界面设计不但应包含正常流程的界面和用户体验设计，也应当覆盖异常流程。 4)在不同页面中相同类型的元素（如：按钮、表格等），其样式应保持一致。 5)界面设计应直接体现最终产品的静态显示效果。 6)界面设计如以原型或屏幕截图的方式提供，那么其中应提供一份对基本的使用流程及一 些功能上的重难点进行描述的说明文档。 7)PD对界面设计中用户体验及显示样式部分拥有最终解释权。
Scrum敏捷开发框架规范 中文版
Scrum指南 Scrum的权威指南: 游戏规则 2013年7月由Ken Schwaber和Jeff Sutherland开发并维护
目录 Scrum指南的目的 (3) Scrum的定义 (3) Scrum理论 (3) 透明性 (3) 检视 (4) 调整 (4) Scrum团队 (4) 产品负责人 (4) 开发团队 (5) Scrum Master (5) Scrum事件 (6) Sprint (7) Sprint计划会议 (8) 每日Scrum站会 (9) Sprint评审会议 (9) Sprint回顾会议 (10) Scrum工件 (11) 产品待办列表 (11) Sprint待办列表 (12) 增量 (12) 工件的透明性 (12) “完成”的定义 (13) 结束语 (13) 致谢 (13) 人们 (14) 历史 (14) 翻译 (14) ?2014 https://www.sodocs.net/doc/5617049097.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Scrum指南的目的 Scrum是用于开发和支持复杂产品的框架。这份指南包含了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织到一起的规则。Ken Schwaber和Jeff Sutherland创造了Scrum，Scrum指南也由他们撰写提供。他们是Scrum指南的后盾。 Scrum的定义 Scrum: Scrum是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。 Scrum是： ?轻量级的 ?容易理解的 ?难以精通的 自上世纪90年代初期以来，Scrum就已经应用于管理复杂产品的开发。Scrum不是开发产品的一种流程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和开发实践的相对功效（relative efficacy）显现出来，以便进行改进。 Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要。 Scrum的规则把事件、角色和工件组织在一起，管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。 实施Scrum的方案根据情况不同而不同，在这里不作介绍。 Scrum理论 Scrum基于经验型流程控制理论，或者称为经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法来优化可预测性和管理风险。 透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。 透明性 流程中的关键环节必须为那些对产出负责的人可见。要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。 例如： ?2014 https://www.sodocs.net/doc/5617049097.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
SCRUM框架及基本知识
1什么是SCRUM 一个轻量级的软件开发方法 Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程.。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。 一个简单的开发框架 图表 1 一个简单的开发框架 Scrum由三个角色，六个时间箱，四个工件组成： 三个角色： 1. 产品负责人（Product Owner） 2. Scrum Master 3. Scrum团队 六个时间箱: 1. Sprint 2. 发布计划会议（Release Planning Meeting） 3. Sprint计划会议（Sprint Planning Meeting）
4. 每日站会（Daily Scrum Meeting） 5. Sprint评审会议（Sprint Review Meeting） 6. Sprint回顾会议（Sprint Retrospective Meeting） 四个工件 1. 产品Backlog（Product Backlog） 2. 发布燃尽图（Release Burndown Chart） 3. SprintBacklog（Sprint Backlog） 4. Sprint燃尽图（Sprint Burndown Chart） 一个经历过时间考验的开发过程 Scrum最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。之后，Scrum成为领先的敏捷开发方法之一，目前世界上有超过500家公司在使用Scrum。 2Scrum三个角色及其职责介绍 每个Scrum团队包括3个角色：产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。产品负责人 产品负责人的职责： 确定产品的功能，负责维护产品Backlog。 决定产品的发布日期和发布内容。 为产品的投资回报率(ROI)负责。 根据市场价值确定功能优先级。 在每个Sprint开始前调整功能和调整功能优先级。 在Sprint结束时接受或拒绝接受开发团队的工作成果。 产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。 为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人
SCRUM敏捷开发基础及失败成功案例分析
S C R U M敏捷开发基础及失败成功案例分析 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998
什么是敏捷开发方法什么是SCRUM 有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。 那么，敏捷这个词到底由何而来呢在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发方法（例如：传统的瀑布开发方法）。在2001年，17位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发方法（Lightweight methods）。专家们给这类轻量级的方法学起了一个新的名字叫做敏捷，并发布了敏捷开发者宣言。 敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。 敏捷开发方法是这些轻量级方法的总称，它旗下有很多具体的开发过程和方法。主要的有：极限编程（XP）、特征驱动软件开发（FDD）、SCRUM开发方法等等。SCRUM开发方法是由Jeff Sutherland在1993年创立，Jeff也是制定敏捷宣言的17位专家之一。SCRUM借用了橄榄球运动中的术语——一个团队拿球向前冲。 严格的说，SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发方法。SCRUM是一个什么样的开发框架呢简单说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）组成。 ·角色（Role）：产品主管（Procuct Owner），他负责项目的商业价值；SCRUM师傅（ScrumMaster），他负责团队的运转和生产；以及自组织的团队。 ·会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。
敏捷开发scrum-燃尽图
“燃尽图”--保持项目可视性 “燃尽图解释与表示方法” 燃尽图，在Wiki上面没有单独的解释，只有在Scrum上面对其有基本的解释，燃尽图 燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。 A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule. 我找寻了几张燃尽图，比较具有代表性意义： 手工燃尽图 详尽“燃尽图”
中国原创的说法：燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。 燃尽图有多种表示方法与意义，每一个公司，每一个项目可能都不同，公司可以根据需要定制自己燃尽图，甚至进行特别的修饰与修改，但无论如何表示与修改，燃尽图具有一个共同的特点：就是可视性 “为什么需要燃尽图”? 上面展示的燃尽图的表示方法与意义，我们可以看到很多公司在实行敏捷过程都使用了这个燃尽图，显然这个燃尽图有它存在的合理与意义，在讨论这个意义之前，我们需要回答几个问题: 1.“燃尽图”到底谁会关注？ 2.“燃尽图”需要谁去填写？ 3.“燃尽图”应该如何填写？ 上面这三个问题留给读者先去思考，随着后面章节讲述，上面三个问题会得一解决，读者可以带着以上三个看这篇文章，希望在读完文章之后，读者会自己答复以上三个问题。 “燃尽图”展示了一种新的管理工作报告，他向管理者与利益相关展示了目前产品BackLog完成情况与整体进度，管理层与利益相关者可以很容易地通过燃尽图了解实时的进度以及细节，管理层更能够实时把握产品的进度并做出正确的决策，并且预计风险，同时随时调整计划。 传统的项目报告一般是固定，系统的，向管理者展示了项目的进展，完成百分比，以及遇到的问题，需要解决与补救的方法，而实际上在开发过程当中，又会有不断的需求加进来，这种传统的项目报告无法应对这种需求，导致往往项目执行者将项目的失败都归咎于需求的增加与变化，并且责备管理层不能做出正确决策。
scrum开发流程
Scrum开发流程 一、什么是Scrum? 开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。 Scrum 开发流程通常以30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与需求方于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于30 天后交付成果，团队每天用15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。 二、Scrum角色定义及名次解释 （一）有关Scrum的角色定义
（二）有关Scrum的名次解释 三、Scrum的过程简单介绍 1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的； 2、Scrum Team根据Product Backlog列表，做工作量的预估和安排； 3、有了Product Backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议）来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog； 4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）； 5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行Daily Scrum Meeting（每日站立会议），
Scrum流程(个人整理版)
?Sprint 计划会议1：原始需求者、产品负责人及团队一起，确定任务优先级，定出Sprint 目标和既定产品Backlog。?Sprint 计划会议2：团队将既定产品Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。?Scrum 每日例会：项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在15 分钟内。?Sprint 验收会议：由原始需求者或产品负责人断定实际所发布的功能是否与既定的Sprint 目标一致。 ?Sprint 回顾会议：项目团队分析Sprint中的成功经验和所遇到的障碍。 整个Sprint的周期（时间盒）确定为10天（两周），具体的时间安排为： ?Sprint会议（0.5天） ?开发（8天） ?验收&总结（0.5天） ?技术提升日（1天），自主学习技术 1、需求收集 1.1 需求的分类 需求可与分为业务团队的，也可以包括团度内部的，比如性能优化。 1.2 需求提交模板 ?–任务 ?–可用性问题（Bug） ?–性能问题 ?–概念想法 注意：即使是概念性的想法，目前技术上无法实现的想法都可以收集。
②优先级可从以下五种情况中选择 ?–特别的严重 ?–非常重要 ?–很重要 ?–普通 ?–低 注意：切忌将所有的任务的优先级都设置的非常的高，这里不提供非常紧急这样的表述。我们只会根据重要程度去执行任务，所以紧急的任务需要业务部门及需求方尽早的提出。 ③需求类型可以是两种类型 ?–详细需求 ?–毛坯需求 注意：我们的需求并不是要求一定要完整的，及时是一些非常毛坯的需求，也可以提交过来，毛坯的需求由产品负责人进行分析和梳理，暂不清楚的可选择搁置。 ④需求标题有自己进行书写，但是需要遵守的规范是采用动宾短语格式。 比如：―导出+CN酒店每天的PV、UV等流量数据‖ 注意：这里的需求内容一定是站长使用者角度是提出的，切勿出现专业的程序方面的表述：如添加一个导出的按钮。还有需要注意的是动词切忌使用大而宽泛的词，比如―管理‖，类似―管理关键词‖这样的需求是严格避免的，这样会使得要开发的内容变得没有清晰的边界。 ⑤详细描述需要按照用户故事的格式进行书写。具体用户故事格式的要求如下： 用户故事是从用户的角度来描述用户渴望得到的功能。需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素： ?角色：谁要使用这个功能。 ?活动：需要完成什么样的功能。 ?商业价值：为什么需要这个功能，这个功能带来什么样的价值。