敏捷基础与 Scrum

本页以图示或版式为主，文字内容请对照课件原页查看。

• 项目工作按计划进行客户较少参与到项目中

本页以图示或版式为主，文字内容请对照课件原页查看。

• 客户必须等到项目结束后才能获得产品的最终交付
• 测试、部署阶段，投入的资金和人力成本已相当高，失败的代价大

• 开发团队识别并消除缺陷，防止它们落入客户手中中优先级

• 敏捷开发发展史20世纪50年代~60年代早期：军方成功使用IID（送代与增量开发方法）用于开发X-15超音速喷气机。在水星计划中，NASA在其软件开发中使用IID，包括时间盒、初始测试以及自上而下/余量开发的运用20世纪30年代：沃尔特 休哈特1970年：罗伊斯博士发表了（Walter Sherwart）提出用短周期项论文《管理大型软件系统的开目来改进质量的概念。他的方法被发》，他阐述了“瀑布”方法称为PDSA（计划-执行-学习-行动）本身的无效性，并建议若要项目成功，至少要迭代2次20世纪60年代：在一份内部报告中，IBM认识到了选代优化的价值告被束之高阁和优势，只是IBM如此庞大，该报20世纪70年代：IBM的联邦系统部和TRW公司用迭代方法完弹防御计划的命令与控制系统成1亿美元的项目，包括弹道导
• 20世纪90年代：杰夫•萨瑟兰和肯•施瓦布在融合了本田（生鱼片方法）使用的日本IID技术和《新的新产品开发2004年：敏捷联盟正式成立2010年：美国国防部要求在所有的IT项目上应用敏捷技术2015年：《Scrum指南》（Scrum ForDummies）出版2020年：《敏捷项目管理》（第3版）出版2001年：17位在DSDM、XP、Scrum、FDD，以及其他精益方法的这次会议的结果是“敏捷方法”术语领域专家聚在一起开会讨论IID的未来。

• 我们一直在实践中探寻更好的软件开发方法，
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• 敏捷12大原则（1）
• Our highest priority is to satisfy the customer through early and continuous
• delivery of valuable software.
• 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
• 尽早交付：尽早交付产品是获得反馈的最好办法。
• 持续交付：经由持续、规律地交付增量成果，持续地获得客户反馈与真实需求。
• 客户满意：完成创造客户最高价值的成果，是敏捷团队的终极目标。
• 产品分为一个个小功能，经由多次发布，陆续交付增量成果给客户，而不是等到所有功能
• 全部开发完毕再整体交付给客户。

• Welcome changing requirements, even late in development. Agile
• processes harness change for the customer's competitive advantage.
• 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮
• 助客户获得竞争优势。
• 无论是客户或是开发团队，都很难预测未来。因此，当原定计划无法为客户创造价值时，
• 敏捷团队还是要欢迎改变需求。
• 、 要直面改变，尽早修正，让价值最大化，损害最小化。

• Deliver working software frequently, from a couple of weeks to a couple of
• months, with a preference to the shorter timescale.
• 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
• 交付周期以2~4周为佳，最好不要超过6个月。
• 敏捷项目中，团队不是根据详尽的项目管理计划执行，而是根据客户的需求与价值排序执行。
• 因此，交付的时间间隔太长会导致无法实时根据客户需求调整开发，难以获得客户满意。

• Business people and developers must work together daily
• throughout the project.
• 项目实施过程中，业务人员与开发人员必须始终通力协作。
• 业务人员（PO）代表产品或成果的真正需求。
• 当业务人员与开发人员在项目进行中协同工作时，可以更
• 频繁地沟通。通过共享彼此的想法、文档及解决问题的方
• 法，业务人员真正看到过程和成果，可以尽早获得真正的
• 需求。

• 发团队人员能动性，使他们能够完成任务。
• Build projects around motivated individuals. Give them the environment
• and support they need, and trust them to get the job done.
• 要善于激励项目人员，给予他们所需的环境和支持，并
• 项目靠积极的个人来完成，敏捷团队是自组织的团队，
• 拥有可以完成项目的技能，通过激励和必要的授权，激

• 文档上的时间。
• The most efficient and effective method of conveying information to and
• within a development team is face-to-face conversation.
• 无论是对开发团队还是团队内部，信息传达最有效的方
• 面对面的沟通除了能获得最多的信息，可尽早充分地了
• 解需求之外，也意味着可以用语言沟通，减少花在编写

• 敏捷12大原则（7）
• Working software is the primary measure of progress.
• 可用的软件是衡量进度的首要衡量标准。
• 、 查看工作进度的最好方法就是看已经完成哪些成果。
• 敏捷团队在每个迭代展示成果，让每个人都知道项目最新进度。
• 客户也不会花了很多钱和时间，只看到进度和其他文档，到项目最后过知道完成的成果并
• 不符合需求。
• 迭代1送代2送代3

• Agile processes promote sustainable development. The sponsors，
• developers, and users should be ableto maintain a constant pace indefinitely.
• 敏捷过程提倡可持续的开发。
• 发起人、开发人员及用户都应该能不断地维持稳定的步调。
• 虽然敏捷团队即使到最后也要拥抱改变，完成为客户创造最高价值的成果，但并不表示客
• 户可以在任何时候做任何修改。
• 为了要让团队能持续以高效能的速度完成成果，发起人、开发人员及用户都应该能不断地
• 维持稳定的步调，共同在适当的时间做适应精细的规划，才能持续提交可用的增量成果。

• Continuous attention to technical excellence and good design enhances
• agility.
• 对技术的精益求精以及对设计的不断完善将提高敏捷性。
• 敏捷团队成员都应持续专注于追求卓越，以高度的敬业精神和高超的技术水平，完成符合
• 客户需求成果。
• 团队协同工作的平台和工具也都要随着时代的演进而精进，让团队更有效率与效能地完成
• 项目。

• 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
• Simplicity-the art of maximizing the amount of work not done--is
• 简洁而不是简单，它强调的是每个功能都是客户需要的、有价值的，并以最小成本在最短

• The best architectures, requirements, and designs emerge from self-
• organizing teams.
• 最佳的架构、需求和设计将出自于自组织团队。
• v 敏捷团队是自我组织的团队，自己管理自己。
• '敏捷项目管理没有明确的框架、需求及设计时间。
• 团队成员同心协力，一起以渐近的方式规划如何为客户
• 带来最大价值，然后开始思考如何共同完成这些成果。

• At regular intervals, the team reflects on how to become more effective, then
• tunes and adjusts its behavior accordingly.
• 团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
• 团队不但要持续交付有价值的成果，而且要在完成迭代工作后进行反思，讨论到目前为止项
• 目执行方式的经验与解决问题的知识，以作为团队持续改善的依据。
• 敏捷团队成员在项目进行过程当中，通过频繁地回顾团队工作状态，进行检讨并研究改善
• 行动，以增进团队工作效率与交付令客户满意的成果。

• 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
• 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
• 可用的软件是衡量进度的首要衡量标准。
• 对技术的精益求精以及对设计的不断完善将提高敏捷性。
• 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
• 敏捷过程提倡可持续的开发。发起人、开发人员及用户都应该能不断地维持稳定的步调。
• 项目实施过程中，业务人员与开发人员必须始终通力协作。
• 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
• 无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
• 最佳的架构、需求和设计将出自于自组织团队。
• 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获
• 得竞争优势。
• 团队要定期反省怎样做才能更有效，并相应地调整团队的行为。

• 敏捷是一种基于敏捷价值观、原则及实践的心态或做事情的思维，符合敏捷价值观

本页以图示或版式为主，文字内容请对照课件原页查看。

• Scrum是一种迭代的方法，它的核心是冲刺（Sprint）

• 产品负责人（PO-Product Owner）产品待办列表（PB-Product Backlog）
• V 敏捷教练/大师（SM-Scrum Master）冲刺待办列表（Sprint Backlog）
• 开发团队（Developmen Team）V 增量（Increment）
• V 冲刺评审会（Sprint Review Meeting）
• 冲刺回顾会（Spring Retrospective Meeting）
• 每日站会（Daily Standup Meeting）

• 3个角色-汇总产品负责人（Product Owner）：可以是公司的产品经理或委外公司的客持续频繁地与团队、相关方、业主及SM沟通；
• 根据相关方的期望和需求，排列出对相关方最有价值的产品代表列表决定团队工作的优先级，使团队完成的产品价值最大化
• 产品负责人开发团队开发國队（Development Team）：由一群跨职能的人员组成的自组织团队（5~9人），被充分授权团队成员T型人才（通用专家）团队成员根据他们的专长，自主挑选冲刺待办列表最上面的工作开发团队成员协同合作，交付项目可交付物
• 敏捷教练/大师（Scrum Master）：以仆人式领导团队，以敏捷方式完成项目过程中保证Scrum流程，确保团队遵循敏捷价值观、原则与过程。

• 3个角色-产品负责人（PO）
• 产品负责人（Product Owner）
• 用户故事在非Scrum环境中，有时也被称作客户代表。
• 理解客户和其他业务相关方的需求，并促进与开发团
• 队就这些需求展开讨论。
• 迭代计划对产品需求进行收集、优先级排序以及管理
• v 决定产品包含哪些功能和不包含哪些功能；
• 负责处理客户、业务相关方和开发团队间的认知差距；
• ' 每天与开发团队一起工作，帮助团队成员澄清需求；
• v 验收或拒绝团队在整个冲刺期间完成的工作；
• 还负责决定已完成的功能的发布的内容和时间。

• 在非Scrum环境中，有时也被称作引导者或团队教练。
• v 促进Scrum团队内部建立共识。
• 敏捷教练 （Scrum Master）
• 、 作为敏捷流程的教练和敏捷的提倡者，帮助团队
• v 帮助团队扫清障碍，并保护开发团队免受外部干

• 是创建产品的团队，开发团队成员具有不同的技能。
• 开发团队 （Development Team）
• 发、测试、集成和归档后变成可工作的功能所需要的全
• 具备多项技能（T型人才），每位开发人员应该掌握不
• 止一项技能，对于每项技能，应该有多位人员可以掌握，

• 3个角色-开发团队（DT）
• 自组织：
• ^ 自组织团队不必遵守来自他人的指令，团队拥有已开发的解决方案；
• 对工作方式拥有高度的控制权；
• v 控制权与职责相辅相成，确保了产品的成功；
• v 出现问题，团队首先在内部自行解决。
• 团队规模：
• 通常5~9人（Scrum团队有6位开发人员时，开发速度最快；Scrum团队有4~5位
• 开发人员时，成本最低；保持3~9人规模的开发团队能提高凝聚力）；
• 促进良好的沟通，花在协调上的时间少；
• 人员过多时，分解成Scrum of Scrums。

本页以图示或版式为主，文字内容请对照课件原页查看。

• 3个工件-产品待办事项列表（Product Backlog）
• v 包含功能性以及非功能性需求
• 故事C最上方的项目是最有价值的需求
• 故事DPO负责进行对优先级排序
• 每个Sprint开始之前要重新进行排序，以确定最重要的事项
• 随着项目的进行，可能新增、变更或減少条目
• 每个需求和变更都将反映在PB中，因此是动态的，不断完善的

• 扩展-DEEP原则Detailed appropriately，详略适当的在适当的时机做适当的分析与规划，一开始就规划的非常详细既不可能，也是一种浪费。
• 在产品待办事项列表上方，近期要做的任务才做细化，短期内不会进行的任务，先不做细化。
• Emergent，紧急涌现的”紧急涌入”是指产品待办事项列表先后顺序会随着项目的进行和风险状况而改变。它不是静态的而是持续变化的。
• 在新增任务或细化任务时，产品负责人会根据不断新涌入的各种信息，将产品待办事项列表中的任务重新排序。
• Estimated，可估算的产品待办事项列表中的需求都是估算过相对大小的，可以用"故事点数”或“理想时长”估算。
• 遵守滚动式规划的原则，越是上面部分的事项，优化级越高，也越详细，估算也越精确；越是在下面部分的事项，优先级越低，越粗略，估算的精确程度也越低。
• Prioritized，排序的产品负责人负责维护产品待办事项列表，所有在列表上的任务都是排好顺序的，越是靠上方越有价值，越要优先处理。
• 列表上方的任务必须是详细排序的，列表下方的任务，只需要概略排序。
• 任务的第1次发布阶段，只要详细排定第1次发布的用户故事顺序，不需要将后续的发布进行详细排序。

• 3个工件-冲刺待办列表（Sprint Backlog）
• v 这些用户故事来自Product Backlog，每次冲刺前，
• PO根据交付价值，将优先级最高的用户故事放入迭代
• 每个用户故事应该能够在当前的沖刺中被实现
• 每个用户故事都会被分解并关联到若干个子任务（Task）

• 3个工件-增量 （Increment）
• V 每个 Increment 都是之前所有的Increment
• 累加起来的，并经过彻底地验证，以确保整
• 4 口.合在一起的所有 Increment 都能工作
• 需要关注其是可工作的软件功能增量（必须
• 需要在Scrum Review会议上进行演示

• 完成的定义设计评审完成代码完成代码重构完成代码是标准格式代码已提交代码已检查最终用户文档已更新完成单元测试完成集成测试完成回归测试完成平台测试
• 完成的定义（Definition of Done）DoD是在待办事项被认为已充分开发，以被干系人接收之前/发布之前，整个转化一致同意完成的一系列条件/质量验收标准，在没开发之前，就先定义什么是“完成”DoD由产品负责人和开发团队共同确定可以在不同层面定义DoD，例如在发布规划时，是站在产品负责人或客户代表的立场，来定义什么是“完成”，用的是客户看得懂的商业语言；每次迭代的“完成”，是让开发团队了解开发工作的结果要求

• DoR指用户故事被认为已经充分理解并能开始构建，整个团队一致同意所需完成的一系列条件。
• 准备就绪的定义（Definition of Ready）
• 具有开发团队能够理解的足够多的细节信息，可以针对是否能够完成PB做出明智的决策
• 识别出依赖关系，不存在阻碍PB完成的外部依赖关系
• PB做过估算、足够小、很容易在一个迭代中完成
• 接受的标准清晰且是可以测试的（或者符合INVEST原则）
• 如果有性能标准的话，性能标准是已经定义并且可测试的
• 团队清楚在迭代评审中如何演示PB

• 5个伙式≥ 每日站会（Stand up每天15分钟站着开会只有团队成员、PO和SM可以发言会上说3件事：昨天完成哪些工作今天要做哪些工作要做的事情有哪些困难每日站会上提出的问题添加到停车场
• 沖刺（Sprint）冲刺是Scrum中关于“迭代”的术语。
• 冲刺是一个固定的工作时间段，也称为时间盒，计划的工作要在时间盒内完成V一般一个冲刺的时间盒为1~4周v 时间盒确保了工作不被中断或干扰计划的工作没在时间盒内完成怎么办？

• 5个仪式冲刺计划会时间：在每个冲刺开始时召开V 设定冲刺目标将用户故事分解为任务＜ 从产品待办列表中按优先级选择工作团队使用用户故事细化工作1~4周迭代完成v 团队成员主动认领Y PO、SM、团队成员，其他相关方视需要参加
• SPRINT评审冲刺评审会时间：在每个冲刺结束时召开v 展示已完成的工作项，相当于对已完成工作的验收获得反馈，让团队保持产品开发足够清晰（确保在正确的轨道上）Y 确定冲刺先后顺序（Spring Backlog）v PO、SM、团队成员，其他相关方视需要参加V PO或客户评审
• 冲刺回顾会V 时间：在每个冲刺结束时召开v 团队“自省”，回顾哪些地方做得好（或不好），应该如何改善，总结经验教训能让团队学习、改进质量和调整其Y 发起人、PO、SM、团队成员，其他相关方视需要参加

• 清晰、一致的理解。
• 用户故事是一种清晰、有效的定义产品需求的形式，它是对某个产品需求的简单描述
• 产品负责人负责收集和管理用户故事（确定优先级），但编写用户故事并不只是产品
• 负责人的责任，开发团队和相关方也应该参与其中，以确保整个Scrum团队对需求有

• 各知识领域中的敏捷-范围用户故事标题作为<角色＞，我想要<目标>，以便于<利益/商业价值>
• 验收标准当<用户角色><完成活动>时，允许/不允许发生的事用户故事的3C模式，使得Scrum团队能够创造客户价值。
• 通过将用户故事限制在一张索引卡（Card）上，我们鼓励通过对话（Conversation）实现对客户需求的共同理解（Confirmation）。
• 用户故事三要素（3C）Card（卡片）Conversation（交谈）Confirmation（确认）

• 各知识领域中的敏捷-范围标题 ＜帐户间转帐＞作为＜杰克＞我想要<在不同帐户间转帐＞以便于＜每个帐户都有正确的金
• 用户故事当我这样做时当我查看我的帐户余额时当我选择“转帐”选项时当我选择“转入”选项时当我选择“转出”选项时
• 这种情况会发生我看到转帐选项我在我想转帐的帐户中进行选择显示我的可用帐户和对应金额显示我的可用帐户和对应金额

• 用户故事的特征一INVEST原则
• Independent（独立的）：独立的用户故事可以减少排序优先级的干扰
• Negotiable（可协调的）：可协调的故事内容，有更改空间
• Valuable（有价值的）：依据客户的价值，决定排序优先级
• Estimatable（可估算的）：借由故事内容的描述，能够估算用户故事的工作量
• Small（小型的）：小到可以在一个选代内完成为原则
• Testable（可测试的）：一定要具备接收原则，以供项目团队测试去确认完成

• 各知识领域中的敏捷-范围
• 敏捷将用户故事根据其重要性，区分为4大类：
• "一定要〞（Must have） —最基本的，不能没有；
• “应该要”（Should have）——是重要的，应该要有；
• “可以要”（Could have）—— 在短时间内可以不要；
• “不需要”（Won'thave）——应该搁置，以后再说。

• 各知识领域中的敏捷-范围
• 优先级排序技术-Kano模型
• 在卡诺模型中，将产品功能/需求和服务的特性分为五种属
• 性：
• 魅力属性必备属性：当优化此需求，用户满意度不会提升；当不提
• 供此需求，用户满意度会大幅降低。
• 无差异属性期望属性期望属性：当提供此需求，用户满意度会提升；当不提供
• 尚未实现此需求，用户满意度会降低。
• 必备属性 元器蛋现 ＞ 魅力属性：用户意想不到的，如果不提供此需求，用户满
• 意度不会降低；但当提供此需求，用户满意度会有很大提
• 升。
• 反向属性反向属性：用户根本都没有此要求，提供后用户满意度反
• 而会下降。
• 无差异属性：无论提供或不提供此需求，用户满意度都不
• 会改变，用户根本不在意。