标签：sticky 级别 专业知识 release name rgb 验收 协助 ref
如今敏捷开发是越来越火，人人都在谈敏捷。人人都在学习Scrum和XP,柯南君的朋友“远哥”是一位项目leader。柯南君与远哥促膝长谈。远哥也毫不避讳。知无不言言无不尽。把自己对Scrum的理解和自己工作中的经验积累与柯南君分享，在这里柯南君取代远哥与大家分享一些经验。
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先。我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程。它会指导我们用规定的环节去一步一步完毕项目的开发；而这样的开发方式的主要驱动核心是人，它採用的是迭代式开发；
我们大部分人都学过瀑布开发模型（见备注），它是以文档为驱动的，为什么呢？由于在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发者都是根据文档进行开发的。一切以文档为根据；而敏捷开发它仅仅写有必要的文档，或尽量少写文档。敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
备注：
① 在这里儿。给大家普及一下基础知识的，什么是软件开发模型？对于开发模型知识点，要掌握软件生命周期的概念、各种开发模型的特点和应用场合。
主要是的开发模型有瀑布模型、增量模型、螺旋模型、喷泉模型、V模型、高速应用开发模型、构件组装模型、敏捷方法和统一过程等。
迭代是指把一个复杂且开发周期非常长的开发任务，分解为非常多小周期可完毕的任务。这种一个周期就是一次迭代的过程；同一时候每一次迭代都能够生产或开发出一个能够交付的软件产品。
前面说了敏捷它是一种指导思想或开发方式。可是它没有明白告诉我们究竟採用什么样的流程进行开发，而Scrum和XP就是敏捷开发的详细方式了。你能够採用Scrum方式也能够採用XP方式；Scrum和XP的差别是。Scrum偏重于过程，XP则偏重于实践，可是实际中，两者是结合一起应用的，这里我主要讲Scrum。
1、什么是Scrum？
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum。我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完毕它，你一定会感到很兴奋的。
而Scrum就是这种一个开发流程，运用该流程。你就能看到你团队高效的工作
2、 IT方法的採用率对照
软件开发中有非常多过程方法能够使用。下图为Forrest Research 2009年调查的方法採用率对照，当中能够看到Scrum方法明显占有优势。本篇我将从IT方法论的角度来谈Scrum。
3、Scrum与CMMI
暂无
4、Scrum的特点
① 是一个敏捷开发流程
② 以团队为基础
③ 要求迅速变化情况下迭代和增量开发
④ 改善交流并最优化合作
⑤ 检測开发过程障碍并将其去除
⑥ 最大化生产率
⑦ 适用于单一的项目到整个组织
⑧ 能让參与者对工作贡献赶到惬意
5、Scrum中的角色
1）Scrum Master——项目负责人、项目经理
① 保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。
② 与 Product Owner 一起将投资产出最大化，他确保全部的利益相关者都能够理解敏捷和尊重敏捷的理念。
2) Team——开发者、測试人员、美工设计、DBA等全职能性团队
① 团队负责交付产品并对其质量负责，团队与全部提出产品需求的人一起工作。包含客户和终于用户。并共同创建 Product Backlog 。
② 团队依照大家的共识来创建功能设计、測试 Backlog 条目交付产品。
③ 自组织地完毕项目开发，使用一切可行手段保证进度和质量
3) Product Owner——产品负责人、产品经理、运营人员
① 从业务角度驱动项目，传播产品的明白愿景，并定义其主要特性。
② Product Owner 的主要职责是确保团队仅仅开发对于组织最重要的 Backlog 条目，在 Sprint 中帮助团队完毕自己的工作，不干扰团队成员，并迅速提供团队须要的全部信息。
4） User——终于用户、运营人员、系统使用人员
① 非常多人都可能成为终于用户，比方市场部人员、真正的终于用户、最好的领域专家。也可能是因其专业知识而被雇佣的资讯顾问。
② 终用户会依据自己的业务知识定义产品，并告知团队自己的期望，提出请求。
5） Manager——管理层、投资人
① 管理层要为 Scrum 团队搭建良好的环境，以确保团队可以出色工作。必要的时候，他们也会与 Scrum Master 一起又一次组织结构和指导原则。
6） Customer—— 户、系统使用人员、运营人员
① 客户是为 Scrum 团队提出产品需求的人，她会与组织签订合同。以开发产品。
② 一般来说，这些人是组织中的高级管理人员，负责从外部软件开发公司购买软件开发能力。
③ 在为内部产品的公司中，负责批准项目预算的人就是客户。
6、Scrum流程
备注：
① Scrum的核心在于迭代。整个过程仅仅有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级。以便将最具价值的功能安排在下一个迭代中完毕。团队的责任是开发软件功能，他们是自组织团队，团队全部成员对每一次迭代和整个项目共同负责，不单做考核。Scrum Master则须要对Scrum过程负责，向全部项目參与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益。还需督促 全体成员遵从Scrum规则和实践。
② 启动Scrum项目所需的最简约计划包含：一份愿景及产品Backlog。愿景描写叙述项目开发原因和预期目标。
愿景可能描写叙述商业运作方式将发生哪些改变，主 要特性和功能怎样为客户创造收益。以及对市场的预期影响。
产品backlog将定义交付愿景时，系统应满足的功能性和非功能性需求，它需事先划分优先级并经过初始预估（预估的目的是了解每一个需求自身及相对与其它需求的规模）。
③ 在Sprint第一天召开sprint计划会议，这个会议分为两部分，计划会议1由PO、SM和Team參加，主要是从产品backlog中挑选出须要放 到当前sprint下的既定产品backlog，然后由SM、Team參加计划会议2，把既定产品backlog的故事拆分成任务进行估算，PO也能够一 起參加这个部分来了解详细的开发细节。sprint周期在spirnt计划会议2正式開始。开发过程中，团队每天召开每日站会（Daily Scrum），沟通团队成员间工作进度和进行任务协调。Sprint周期结束时。须要召开Sprint评审会议，由团队向产品负责人和其它利益相关者展示当前sprint周期内的产品开发情况。
产品负责人依据团队这次 Sprint 所公布的版本号，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。评审会议结束后会进行回想会议，通过总结以往的实践经验来提高团队生产力。
7、Scrum 中的产出物
1） Product Backlog——Backlog 待开发项，积压的任务。
① 产品 Backlog 包含了全部须要交付的内容，其内容依据业务需求的价值顺序排列，每一个 Backlog 的优先级是能够调整的。需求是能够增减的，因此产品 Backlog 将依据不断增长来持续驱动维护。
② Product Backlog不是制定一次就完了的，它是动态的，须要持续的被修订。可能会出现故事的添加、删除和改动、合并或者拆分不论什么一个Backlog的目标都是：它应该足够短、级别足够高，无特殊情况不须要改动。如果Backlog改变了，那么我觉得你应该如果你的 Backlog错了，而不是需求变更了。
变更需求通常意味着Backlog太长或者太具体，比方把复杂算法和逻辑也写入了backlog中了。要不就是写 的太含糊不清了。须要花费太多的时间推測它到底讲的是什么。
③ prodcut Backlog有什么用？
产品backlog依据用户价值罗列全部即将在产品中开发的功能，通过简洁的展示须要实现的功能，我们能够对项目进行规模上的估算，确定公布计划和迭代计划。
产品backlog能够帮助我们对将要做的事情有个总体的认识，以及能够知道我们如今的状态。假设没有backlog，我们将不知道如今和将来产品做成什么样子，因为对产品目标的不明白，当然也不知道什么时候能够公布产品，或者公布的产品能给客户带来什么价值。
④ 谁提供product backlog的需求？
产品负责人与客户近期，他最清楚产品应该做什么样子，所以product backlog应该由Product Owner来制定。
里面的需求由产品负责人或者客户制定，有时候Team里的需求分析人员能够和产品负责人或客户一起定义需求。制定后，由Scrum master和Team协助产品负责人修订并进行初始评估，里面的需求在sprint计划会议将进行更进一步的讨论。
⑤ 什么时候会改动product backlog？
假设一个列表太长或者内容陈旧，product backlog的浪费远大于价值本身，所以我们必须不断的维护产品backlog。
产品backlog由产品负责人提供，与Team进行规模估算时。可能会拆分合并或者加入删除故事。初始预计也由Team进行评估提供预计值。
产品全部者一般会向开发小组提出自己确定的优先级顺序，而小组也可能会请产品全部者依据他们对主题的评估对这个顺序作出少量调整。
怎么写故事?
一般依照轻量级的故事来进行描写叙述需求。用户故事是最主要的设计单元。它是从系统用户或者客户的角度出发对功能的一段简要描写叙述。用户故事的形式非常自由，没有什么强制性的语法。可是，依照大致符合这样一个形式来考虑 用户故事是比較故意的：“作为【用户的类型】，我希望能够【先这样做，然后那样做，就应该得到...的结果】以便【业务价值】。”以这种模作为样例，能够得到一个用户故事说：“作为购书者，我希望能够依据ISBN来找到一本书，以便能更快的找到正确的书。”在做用户故事时，须要注意每一个用户故事用的是用户的语言，它仅仅描写叙述一个功能（feature），并且每一个用户故事的开发周期不要太长（1－5天）我们不须要一開始对全部的故事都进行具体的描写叙述，但计划放在下一个sprint中的故事应该比較清楚。
⑥ 一般依照轻量级的故事来进行描写叙述需求。
用户故事是最主要的设计单元，它是从系统用户或者客户的角度出发对功能的一段简要描写叙述。用户故事的形式非常自由，没有什么强制性的语法。
可是，依照大致符合这样一个形式来考虑 用户故事是比較故意的：“作为【用户的类型】，我希望能够【先这样做。然后那样做。就应该得到...的结果】以便【业务价值】。
”以这种模作为样例，能够得到一个用户故事说：“作为购书者。我希望能够依据ISBN来找到一本书，以便能更快的找到正确的书。”在做用户故事时，须要注意每一个用户故事用的是用户的语言。它仅仅描写叙述一个功能（feature），并且每一个用户故事的开发周期不要太长（1－5天）
====================================================================================================================================
备注：
拆分故事：注意在这里不要把故事拆分到任务。故事是能够交
付的东西。是产品负责人所关心的。而任务是不可交付的东西。
优先级：经济价值、开发成本、依赖关系、新知识、风险。
⑦ ID为一个唯一标识，确定后最好固定不变，在其它工作或者文档中想引用故事就使用这个ID来引用 Name2到10个字，通过简单的描写叙述来说明故事，假设要非常多字才干表达这个故事。那非常有可能这个故事太大，或者不清楚 重要性 这个优先级决定了sprint选择的故事，优先级越高的越早实现 初始估算 这个由Team来依据故事描写叙述内容来估算，产品负责人解说完故事后，Team对不清楚的进行询问。大概了解后进行粗略估算。从估算的角度出发，故事不应该太短。但也不能太过于具体，不须要把具体的规则和算法写进去。
How do demo 从用户视角，从操作层面进行解说这个故事怎样通过软件来演示，也能够作为一个简单的測试用例了。重要性高的backlog条目都要填写”怎样演示“。
Notes相关信息、解释说明和对其它资料的引用等。一般都很简短。
⑧ 怎么拆分故事？
故事非常大时，我们将非常难对它进行预计。
假设故事预计在N次迭代后才进行。那么大的故事非常正常。但假设预计预计在接下来的迭代中进行，那么我们就 可能会对大的故事进行拆分。非常大的故事基本上都能进行拆分，仅仅要确定每一个小故事莹然能够交付业务价值即可。注意在这里不要把故事拆分到任务，故事是能够交 付的东西，是产品负责人所关心的，而任务是不可交付的东西。产品负责人对它并不关心。任务是在sprint计划会议上拆分的。
切割用户故事： 1 依照用户故事所支持数据的边界来切割大型用户故事（比如导入GBQ文件、Excel等） 2 有些时候。能够从主用户故事中除去对例外或错误条件的处理（相当于用户的基本路径和扩展路径），从而把一个大型用户故事变小很多 3 依照操作边界切割，把大型用户故事切割成独立的建立、读取、更新和删除操作（比如预算二次导入。或者新增时须要向导、规则而比較复杂时也能够单独成一个故事来描写叙述） 4 考虑去除横切考虑（比如安全处理、日志记录、错误处理等），为用户故事建立两个版本号：一个具备对横切考虑的支持，还有一个不具备这样的支持 5 考虑功能性需求和非功能性需求隔离到不同的用户故事，从而切割大型用户故事（性能）在拆分故事时，我们有时也须要考虑组合故事的场景，如 把bug列入产品backlog时，能够把多个类似的bug组合成一个故事。 ⑨怎么评定优先级
最简单的方法就是问问客户最希望在下一个迭代中最想看到的是哪一些功能。从考虑的因素来看，我们能够从下面4个因素来考虑： A 获取这些功能带来的经济价值，价值越高的优先级越高。 B 开发成本带来的影响。
比如可能2个月后因为使用新技术仅仅须要2周，而如今做须要2个月，这时能够考虑把优先级放低一些获取新知识的重要性。 C 在开发中会不断的产生一些项目和产品的新知识，及早了解和开发这些新知识能够降低不确定性，所以这类功能优先级会高些故事之间会存在依赖关系，这时候被依赖的优先级会更高，须要先完毕开发这些功能所降低的风险。
D 在开发过程中。会出现进度风险、成本风险、技术风险等，对于风险越高价值越大的我们须要首先处理，对风险高价值低的要尽量避免。能够通过下面图查看确定功能优先级时综合考虑风险和价值的关系
2）Sprint Backlog——Sprint 本意为“冲刺”，指迭代周期，长度一般是一至六周。
在 Sprint 開始前。定义本次 Sprint 要讨论的“Sprint Backlog”。从中产生本次 Sprint 要完毕的 “已定 Product Backlog”。
已定 Product Backlog Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。
目标：定出 Sprint 目标，确定全部任务。
备注：
① sprint计划会议1 产品负责人和团队一起，在先前评估的成果基础上，定出 Sprint 目标和既定产品Backlog。【目标】 定出 Sprint 目标和既定产品 Backlog 【会议准备】 邀请与会者：产品负责人、Scrum Master、团队全部成员 已按优先级排列产品 Backlog 中各项问题 已评估 Backlog 中的各项问题 把产品 Backlog 公开给会议中的每一个人，保证其可被获取 预期团队中有哪些人已明白会缺席（如度假） 保证房间环境适合小组讨论 每一个人都能够获取上次 Sprint 评审会议和 Sprint 回想会议的结果 Sprint 时间表已经安排 Sprint 计划会议 1 的时间安排 Sprint 计划会议 2 的时间安排 Sprint 的第一天已确定 Sprint 的最后一天已确定 Scrum 每日例会的时间安排 Sprint 评审会议的时间安排 Sprint 回想会议的时间安排 （可选）为既定 Backlog 准备图钉板:一个至少 2x2 米的图钉板、卡片和贴纸、荧光笔 （可选）用作计划纸牌的卡片 会议进程（4 小时） 把 Sprint 时间表公开给全部人 把 Sprint 评审会议的结果公开给全部人 把 Sprint 回想会议的结果公开给全部人 产品负责人向团队产品阐述产品远景 产品负责人和团队一起确定 Sprint 目标 假设 Backlog 里有问题遗漏：产品负责人有权限往 Backlog 里加入问题 假设产品 Backlog 全然未被评估：选择 Backlog 中您觉得是最小用例的问题，并指派其工作量为 2 个Story Point。以这个最小用例的工作量标准，分配 Backlog 中其它问题的 Story Point 假设 Backlog 中的一些问题尚未被评估：依据其它问题工作量，评估这些问题的 Story Point 量 假设产品 Backlog 中的各项还没能合理地按优先级排序:产品负责人对产品 Backlog 中的各项按优先级排序 产品负责人和小组成员相互认可这 Sprint 目标和既定产品 Backlog 【会议结果】 为 Sprint 计划会议2的进行准备好既定产品 Backlog sprint计划会议2 在 Sprint 计划会议 2 中。团队将既定产品 Backlog 中的每一项细化成多个任务。每一个任务完毕的时间限定在一天内。 【目标】 确定全部任务。生成 Sprint Backlog，确认 Sprint 目标
3） User Story、Task——用户故事、任务
用 User Story 来描写叙述 Sprint Backlog 里的项目，User Story 是从用户的角度对系统的某个功能模块所作的简短描写叙述。
一个 User Story 描写叙述了项目中的一个小功能，以及这个功能完毕之后将会产生什么效果，或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完毕为宜。
假设 User Story 太大。可能会导致对它的开发横跨几个 Sprint，此时就应该将这个 User Story 分解。
为了可以及时。高效地完毕每一个 Story，Scrum 团队会把每一个 Story 分解成若干个 Task。每一个Task 的时间最好不要超过8小时。保证在1个工作日内完毕，假设 Task 的时间超过了8个小时，就说明Task的划分有问题。须要特别注意。
障碍 Backlog——问题列表，积压的待处理事务。
列举了全部团队内部和团队相关的和阻碍项目的进度的问题。Scrum Master 须要确保全部的障碍 Backlog 中的问题都已分配并能够得到解决。
注意： 通用会议规则
基本要求
会前准备
会议推进
会议输出
让团队坐在一起！
团队建设
每日立会（Daily Standup Meeting）——建议下班前開始
会议目的
构成部分
基本要求
会议输出
会议过程
每一个人三个问题：
假设任务不能在一天成。把这任务细分成多个任务。假设任务能够在一天内完毕。把任务状态设为“正在处理”。假设任务状态已经是“正在 处理”，询问是否存在阻碍任务完毕得问题。——明天做什么？
注意事项
任务板
任务板有4列：
在 Sprint 规划会议中，或是在进行当前 Sprint 中，收集全部特定 Backlog 条目须要完毕的新任务，并将它们放入该列。
=
燃尽图（Burn Down Chart）
Release 燃尽图：记录整个Scurm项目的进度，它的横轴表示这个项目的全部Sprint， 纵轴表示各个Sprint開始前。尚未完毕的工作，它的单位能够是个（Story 的数量），人天等。
Sprint 规划会议——第一部分（上午）
会议目的
基本要求
构成部分：
持续时间：在 Sprint 中，每周该会议占用时间为 60 分钟，在早上召开该会议。这样还有可能在同一天召开 Sprint 规划会议的第二部分。
会议输出
会议过程
流程检查：询问团队是否能高速回答下列问题，仅仅须要简要回答就可以：“我们能 在这个 Sprint 中完毕第一个 Backlog 条目吗？”假设能得到肯定的回答，那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目。——接下来，歇息一下。在歇息后，对下一个 Backlog 条目展开上述流程。
结束流程：
注意事项：不要改变 Backlog 条目大小，不要估算任务。
Sprint 规划会议——第二部分（下午）
会议目的
基本要求
构成部分：
注意事项：不要估算任务，不要分配任务。
会议输出
会议过程
当团队明白知道自己应该怎样开发该功能后。就能够转向下一个 Backlog 条目了。在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。
这能帮助团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。
持续时间：在 Sprint 规划会议第一部分完毕后，召开该会议。能够将午餐作为两次会议的一个更长久的歇息。可是要在同一天完毕 Sprint 规划第一部分，在 Sprint 中，每周该会议占用时间为 60 分钟。
估算会议——依据项目情况合并到 Sprint 第二部分会议
会议目的
基本要求
构成部分：
注意事项：
会议过程
持续时间：该会议时间限制为不超过90分钟。
假设 Sprint 持续时间长于一周，那么每一个 Sprint 举行两次估算会议比較合适。
会议输出
扑克牌估算（Planning Poker）
详细步骤：
常见问题
1、为什么任务要分给组而不是个人？
答：由于怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能非常了解。
2、为什么不让最后领任务的人自己估算？
答：由于他非常可能由于不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。
3、为什么不让师傅估算大家採纳。他不是最厉害吗？
答：师傅的想法经常是徒弟们理解不了的，比方为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对比自己的实现方法和师傅差异的过程。
Sprint 评审会议（Review Meeting）——依据项目须要举行
会议目的
基本要求
构成部分
会议输出
持续时间：90分钟，在 Sprint 结束时进行。
会议过程
注意事项：
会议目的
构成部分
基本要求
注意事项
会议输出
持续时间：90分钟，在 Sprint 评审会议结束后几分钟開始。
会议过程
每一个团队成员（包含 Scrum Master）在每张即时贴上写上一个重要的事件。
8、最后说一下 Scrum的核心价值观
标签：sticky 级别 专业知识 release name rgb 验收 协助 ref
原文地址：http://www.cnblogs.com/ljbguanli/p/6994549.html
