Scrum要素

第一部分： 敏捷力的介绍

起初：瀑布方法

瀑布方法：需求收集-》设计-》编码-》测试，开发的流程正是从一个阶段流向下一个阶段带着项目向下冲，不可阻挡。BDUF（Big Design Up Front，大设计前置）在开始之前先进行完美化（perfecting）设计，能够早点捕获错误和缺陷，从而降低项目全过程成本。软件产品是复杂系统，而不是静态物件，毫无经验数据只能设计出致命的栏系统，在出问题前把事情搞得一团糟，谁也不知道会有什么后果，

加入敏捷实践者行列：

BDUF的关键问题在于，它自认为对未来了如指掌。其实唯一不变的就是编 。拥抱变化，视变化为成长的良机而非障碍。敏捷团队会做一点点需求收集，一点点设计，编码和测试，最后交付一点点价值给客户。敏捷迭代（在scrum中被称作sprint）。敏捷开发是一种整体流程，即测试、设计、编码和需求收集是完全整合彼此依赖的流程。这需要团队、产品负责人和客户通过持续不断地沟通过程，建立起对需求深入细致的共同理解。不管是采纳scrum、精益、极限编程，还是糅合多种敏捷方法论创建自己的混合方法，都要：边做便测试，及早且频繁地交付产品，文档边做边写，打破筒仓构建跨职能团队，敏捷方法的核心思想在于迅速交付商业价值，体现为可工作的软件，还要以定期增量的形式持续地交付价值。

敏捷价值观与原则：

敏捷价值观：

• 个体与互动高于流程和工具：干活的人最清楚该如何完成工作。各种敏捷工具、方法论和流程的选择非常多，应该尽力做到都尝试一遍。

• 工作的软件高于详尽的文档：实际上敏捷团队为规划和文档工作所花费的时间、精力远多于传统团队，因为计划需要不断地进行细化和更新。

• 客户合作高于合同谈判：相关各方就像是一群合伙人，齐心协力地在规定时间和预算范围内努力构建最有价值的系统。降低客户风险，不是靠前期担保方式转嫁风险给承包商，而是依靠流程中客户的持续参与。

• 相应变化高于遵循计划：检验和适应，成为敏捷这回事，就是要创建一个灵活的流程，它可以预见并且欣然接受变化。

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。：项目的事实优先级是让脾气古怪的经理满意，而不是客户，优先级等于官僚主义，等于组织一致性。把客户放在第一位，承诺将持续交付价值，能给交付流水线带来核查和平衡，还能组织人和组织滑向服务组织而非客户的行为模式。

欣然面对需求的变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程需要掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成绩，并依次调整自身的举止表现。工作流中包括回顾会议，展现定期检验和改进工作方式所产生的巨大效益，并以此方式证明迭代开发的价值。

敏捷力的商业案例

早交付，频交付：到底交付什么，为何要这样做（尽可能快的收回成本）。

第二部分：Scrum

Scrum历史简述：

一种整体型或橄榄球方式，以团队为单位通过来回传球的方式向前推进。模型能让团队紧密结合，表现起来就像一个人，希望借此可以创建出跟天才的超级程序员一样强大的团队。scrum简单来说是一个自由的国度，你可以使用任何你欣赏的东西。

Scrum角色：

Scrum只承认三个互不相同的角色，产品负责人、scrum master和团队成员。

产品负责人的责任在于：帮公司得到最高投资回 ，做法是指引团队做最有价值的作业，并远离不那么有价值的作业。是唯一有权要求团队做事以及改变列表条目优先级的人。需要和干系人密切地合作，判别需要何时构建何物，从而交付出最多业务价值。要能够有效地推动项目向前以及负责最终能交付出业务价值，你得写用户故事和接收测试，按业务价值划定用户故事优先级，决定接下来开发哪一个用户故事，提供快速反馈等等，作为项目的幕后推手，你必须得以可见、畅所欲言以及客观的形象出现。

ScrumMaster ：Scrum master不是团队的老板，而是通过影响力获得的领导力。scrum专家和谏言者，教练，障碍推土机，引导者。

团队成员：干活的人权力最大，做具体实现工作的团队成员们，同样也要负责估计实现特性需要的工作量。产品负责人可以决定故事的顺序，但完成特性或任务需要多少时间是开发人员说了算。团队大概5~9人。Scrum中的每人的工作都一样–帮助团队交付他们在当前sprint承诺的故事。负责交付用户故事，做所有的开发工作，自组织地交付用户故事，支配估算流程，支配如何干活的决策，避免与我无关。

Sprint周期：

Sprint规划会议标志着sprint的开始，第一部分目标是选择一组交付物作为当前sprint的承诺，这是软对负责人按照优先级顺序逐个地介绍他希望团队在当前sprint完成的那些故事，确保大家对预期结果有一致的理解，第二部分是团队要罗列出交付用户故事所需完成的所有任务，一周的sprint适合开2小时的会，而一个四周的sprint开4个小时的会应该也够了。sprint的中期调整只有团队有权发起。任务估算：任务小时；任务点；任务数。任务估算的目标是在团队偏离原计划的时候能够及早发现，这样还来得及采取行动。

Scrum日会，站立会议，每天的适合团队的时间来召开并且只有开发团队的人员可以参加，同时简要。已完成的内容，期望完成的内容，导致慢下来的障碍。

故事时间：目标在于保持列表顶部随时都有一批已被充分理解的小故事。

Sprint评审：收集干系人看到产品实物的反应。进而对产品列表和发布安排进行调整。

回顾会议：在迭代的最后举行回顾会议，找出1-2件可以改进的实事，指定行动计划，实现这些改变。回顾的基本议程：准备阶段，收集数据，洞察问题，确定方案，结束。

Sprint的异常终结：当Sprint由好转坏时

燃尽图用于显示迭代中的剩余工作量。

Scrum工件：

产品列表：产品预期交付物的累积清单。这包括了特性、缺陷修复、文档变更和任何值得创建的东西。每个东西大都称之为用户故事或故事。故事都是按照优先级排序。产品负责人拥有列表，同时必须借助于业务干系人、客户和团队成员的紧密合作才能做到。展现形式是墙或电子表格。

Sprint列表是团队当前sprint的任务清单。和产品列表不同，寿命只存货一个sprint时间。

信息辐射器：用传统方式把信息展示给团队所有成员。

燃尽图：描述了剩余工作 随时间变化的轨迹。纵坐标绘制剩余工作量，横坐标是时间。发布燃尽图和Sprint燃尽图。

燃耗图：已完成故事点随时间的变化的情况，是团队速率的可视化指示器。

任务版：任务分为：代办，办理和已办。带泳道的任务版，每个用户故事都有自己的用到，故事相关任务则对应地从左到右列于板上。演变式任务版。

完成之定义：需要设立大家公认地完成的定义。

用户故事：

用户故事是产品列表的基础构建。关注人们需要使用软件替他们做的那些事。

作为某类用户，我想做某事，从而创造出某些价值/达成某目标。

达成对用户故事的共识后便应该写验收标准了，根据标准写出自动化测试，甚至是在功能实现之前。

用户故事、交谈和接收标准结合起来组成完整的需求规格说明书。

用故事大小值估计工作量：

查明下段路程只需做记录当前这一段行程要花多少时间即可。数据到手后利用相对大小来判断下段行程进行有效的预测。

生成估值的真正目标是要提供进度的可预测性度量。生成估值就是为了要支撑业务决策，而业务决策最终将创造更多价值。

故事点是用来度量完成故事所需工作量的相对大小值。速率是平均每个sprint所完成的故事点数量。

团队估算游戏：第一部分集体排队每人选择一个故事卡，然后可以移动也可以直接插入卡片，第二部分，在故事卡上方放置一张斐波那契卡片，然后交给下一个玩家。

速率不能当作绩效指标使用，它是为了提高进度可预测性从而产出更高价值。

第三部分：辅助性实践

发布规划：

发布规划是为产品发布挑选故事（特性、功能增强、缺陷修复等等）的流程，以及应该何时进行发布。固定范围，固定日期，固定的日期且固定范围。项目管理周期中著名的铁三角—-速度、成本和范围。速度是指构建和发布系统所需的时间，成本通常受项目上人头数的影响，范围涉及所包含的故事数量。用户角色人物：

用户的古怪行为模式将是软件可用性的克星。

设计角色人物的一些重要原则：面向目标建立角色人物，他们想要做什么明确，给他们取名字，选嗜好，竭力让他们显得真实。收集需求过程中记录真实用户的性格特征，合并真人的性格特征形成组合图像。

大致分为：首要角色人物，满足了他的需求才到其他人的需求。负面角色人物，不会使用系统的人，所以不要为他们设计。

绘制故事地图：

绘制故事地图是一种组织用户故事的方式，能够提供比传统产品列表更丰富的上下文，也有助于进行发布规划。故事地图是二维的，不仅指示了故事的优先级，也指出了它们彼此的关系和用户更高层的目标，地图能帮助团队理解故事是如何组装起来形成可发布产品的。

纸上原型：

把用户看到的所有界面都要用纸张做出来，直到完成操作为止。用户不可以向计算人或引导者问问题，这个测试就是为了看看应用自己能否干得了活。

项目微章程：

微章程就是明确记载了项目关键信息的概要文档。项目伊始只不过是一个想法，而微章程就是有效捕获想法的一种方法。基础型微章程包含如下元素：代 ，使命宣言，愿景宣言，电梯演讲，商业价值，客户和用户，度量指标，里程碑，资源，风险，权衡。

重构：

最好的架构、需求和设计出自自组织团队。重构就是在不改变代码外在行为的前提下，对代码做出修改，以改进程序内部结构的一种有纪律的方法。

测试驱动开发：

通过测试先行可以把注意力集中于开发人员需要让代码展现的外部行为，再进行重构 。

结对编程：

驾驶员——导航员结对；乒乓结对；测试驱动开发结对编程游戏。要自己发现适合自己的方式。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92564 人正在系统学习中