敏捷Scrum精髓实践集核心免费入门学习教程培训讲义

本免费讲义包含美国Scrum联盟的Certified Scrum Master培训（即CSM认证）公开课培训的核心内容，方便大家预习和复习Scrum实践，更好地了解敏捷开发是什么。本讲义遵循Scrum Guide 2016和美国Scrum Alliance官方CSM认证学习目标(learning objective) 2017版。参考了上海优普丰敏捷学院的Vernon Stinebaker(史文林)、Bill Li(李国彪)、Jacky Shen (申健)对本教材讲义的贡献。内容与CSM认证考试题库中测试题目的学习目标大致相同。

敏捷是什么？

Resolve complexity and uncertainty with continuous and fast feedback to create ability responding to changes with low cost, so that achieve better effect

利用持续、快速反馈来破解复杂性和不确定性，建立用较低成本来响应变化的能力，从而达到更好的效果

4条敏捷宣言和12敏捷原则给出了更为具体的解释。

image

什么是Scrum

Scrum是基于试验性过程（经验主义）的框架，用来解决不确定问题和维护复杂产品。试验性过程的三个支柱分别是Transparency 透明、Inspection 检验、Adaptation 适应。

Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time……It is iterative and incremental…… (from Mike Cohn)

Scrum 作为一种敏捷过程让我们关注于在最短时间内交付最高价值……它是迭代和增量式的……

Scrum的出现借鉴了《新的新产品开发方式》、精益思想、时间盒、SmallTalk面向对象编程中的模块化概念等。

Scrum起源

1986年，竹内弘高和野中郁次郎在哈佛商业评论上发表论文《The New New Product Development Game》，文章首次提到了将Scrum工作方式应用与产品开发，他们指出：

“传统的接力式的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”(Rugby)的方法——团队作为一个整体前进，在团队的内部不断传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。”

1993年，Jeff Sutherland在 Easel公司定义了用于了软件开发行业的Scrum流程

1993年，Ken Schwaber受哈佛商评论文影响，用Scrum方法拯救了一个濒临失败的项目。

1994年，Ken Schwaber建立了“控制混乱”网站。

1995年，Jeff Sutherland应邀将哈佛商评的文章转发给正在创立极限编程的Kent Beck

1995年，Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。

2001年，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。

2001年，Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

2002年，Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。

更多Scrum历史考古，参见 http://www.jackyshen.com/2017/08/02/is-your-Scrum-lean-enough

预定义过程与经验性过程

Command and Control 命令控制 Plan in details 详细计划 Enforce the plan 强制按计划 “Control” change “控制”变化

vs.

Learn as we go 边前进边学习 Change happens 变化会发生 Embrace change 拥抱变化 Inspect and Adapt 检视和调整

Scrum框架3355概览和Scrum术语

Scrum的3个角色

Development Team 交付团队的使命和特征

• 3 – 9 people 3 – 9 人

• Cross-functional 跨职能

  • All skill set in different functional areas; 具备不同的职能

  • No sub teams; 没有子团队

  • T-shape talent (generalized specialization); “T” 型人才，通用的专才

• Full-time(100% Dedicate) 全职投入

  • Membership changes only between sprints; sprints之间方可换人

  • Sit together; 坐在一起

• Self-organized 自组织

  • No management title; 没有管理者头衔

  • Whole team accountability; 全员责任制

  • Team takes most of the project work; 团队承担大部分微观管理工作

• Decide how much work to take on in a sprint 决定迭代的工作容量

• Deliver Product Increments in every sprint 每个迭代交付产品增量

• Responsible for HOW & quality 对“怎样做”和交付质量负责

• Manage Sprint backlog and track the progress 管理Sprint Backlog并跟踪进度

• Figure out the best way to work together as a team 找到团队内部合作的最佳方法

• Collaborate with other teams and parties 与其他团队及相关方协作

• Make continuous self improvements 持续自我改进

Product Owner 产品负责人的特征和职责

• One person, not a committee; “一”个人, 而非一个委员会

• Authorized to make decisions on WHAT; 被授与产品（“做什么”）决策权

• Drives product success; 驱动产品走向成功

• Provide leadership on product; 提供产品领导力

• Represent project to the stakeholders; 面向干系人代表团队

• Represent stakeholders to the team; 面向团队代表干系人

• Collaborates with everyone; 和所有人合作

• Ideally taken by real user; 理想情况下是真正的用户来担任

• Creates the Product Vision; 建立产品愿景

• Start with “Why”; 从“为什么”开始

• Defines the feature of the product (the “What”); 定义产品功能（“做什么”）

• Ensure the readiness of sprint input; 确保迭代输入准备好

• Responsible for Return of Investment (ROI); 负责最大化投资回报

• Orders/Prioritizes Product Backlog to best achieve goals according to the feedback; 根据反馈，为最好地实现业务目标将产品Backlog排定优先顺序

• Decides on Release date and content; 决定版本发布日期和内容

• Be committed to collaborate and be available to team; 愿意投入到合作中并且在需要时被团队找到

• Accept/reject work results; 接受或退回工作成果

ScrumMaster 团队敏捷教练的特征和职责

• Represents project to the management; 面向管理层代表团队

• Represents management to the team; 面向团队代表管理层

• No management title or power – CANNOT make decisions on behalf of the team; 没有管理头衔和权力 – 不代表团队做出决定

• Coaching the team and PO rather than being a player; 更多是一个教练

• Authorized to be a sheep-dog; 被授权的‘牧羊犬’

• Change agent of team and organization; 团队和组织变革的代理人

• Listens much more than tell; 听多于说

• Is a servant leader with influence; 是一个具备影响力的仆人式领导者

• Teach Scrum to everyone；向大家布道Scrum

• Role model of enacting Scrum values, principles, practices and framework; 彰显Scrum价值观、原则、实践和框架的模范

• Protects the team; 保护团队

• Help to remove impediments and wastes; 移除障碍和浪费

• Coaches and grows team on practices to continuous improvements; 教练和培养团队的实践，帮助持续改进

• Facilitates collaborations; 引导大家的协作

• Improves effectiveness of change in the organization ; 提升组织变革的效果

SM Candidate 候选者特征

开放心态，积极探索，愿意分享和帮助他人。经历过转型或至少了解组织政治生态，善用权力但不渴望权力。中等偏上的技术和产品知识水平。具备沟通能力和意愿包括影响力。从性格像限看，友善或表现型偏多

Open mind, active exploring, willing to share and help others. Experienced in transformation or at least understand political ego-system of organization, be good at using power w/o eager to that. Above average level of technology and product knowledge. Have communication and influencing skill. More of extroversion.

ScrumMaster Common Focused Area ScrumMaster常见的关注领域

• Team

  • Ceremonies & Meetings Facilitation 引导仪式和会议

  • Learning & Team Development 学习和团队发展

• PO

  • PB Refinement 需求待办清单的梳理

• Tech

  • Continuous Integration 持续集成

  • Decoupling 解耦

• Organizational

  • Cross-team collaboration 跨团队协作

  • Coaching upper management 对管理层进行教练

  • Increase Transparency 提高透明性

Scrum的3个工件

Product Backlog 产品Backlog

• An ordered and emerginglist of features fulfilling the Product Vision 一份动态的有序列表，包含了符合产品愿景的各种功能

• And other things providing value to the user 以及其他为用户带来价值的工作

• A healthy product backlog must be “UPERFORM”: 一个健康的product backlog应当满足UPERFORM原则：

  • Unified, 唯一的

  • Pull-based, 拉动式

  • Emergent, 动态的

  • Revealed, 公开的

  • Feature-sliced, 纵切的

  • Ordered, 已排序

  • Ready, 准备好

  • Measurable, 可度量

• Open to all but ultimately groomed by the PO; 对所有人开放但最终由PO维护

• Focus on ‘WHAT’ brings users the biggest value; 关注于“什么“带给用户最大的价值

• The best Product Owner starts with “WHY”; 最优秀的PO从“为什么”开始

Sprint Backlog 迭代待办项列表

• The Product Backlog items selected for this Sprint plus the plan for delivering them 为本Sprint所选择的PBI以及交付所选PBI的工作计划之和

• Extension and subset of the product backlog 产品Backlog 的延伸和子集

  • The set of work to achieve the Sprint Goal 为实现Sprint目标所要完成的工作集合

  • JIT (Just In Time) design in considered 涵盖‘恰到好处’的设计

  • Breaks large work down into smaller pieces (PBI -> SBI) 将大块的工作分解为更小的单元 (PBI -> SBI)

  • Focuses on ‘HOW’ team is going to get the work done and deliver the value in one sprint 关注于“怎么做”的问题：如何在一个sprint内完成工作以交付价值

• Owned by the Development Team 被开发团队拥有

• • Team selects items from the product backlog they can commit to completing and creates the sprint backlog 团队从product backlog中选取他们可以承诺完成的项目并创建sprint backlog
• • Collaboratively, not done alone by the ScrumMaster 协作完成，不是由ScrumMaster负责
• • A visible tool for the team to manage itself during the sprint 一个可视化的工具让团队在sprint内部自我管理

Sprint Goal 迭代目标

• The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. 迭代目标是本迭代中通过实现PB来达成的目标

  • It provides guidance to the Development Team on why it is building the Increment. 向团队提供构建该增量的理由（why）

  • It is created during the Sprint Planning meeting. 在Sprint Planning会议上产生

  • The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. 给予团队一些在功能实现上的灵活性

Visible Task Board Kanban 可视化任务墙看板

• Task board is a common visible tool to manage sprint backlog 任务板是一个常见的用于管理sprint backlog的可视化工具

  • Self-organized: Individuals or small groups sign up for work 自组织：团队成员或小分队自己领取工作

  • • Team decomposes PBI to SBI 团队一起将PBI分解为SBI

    • Team decides SBI granularity 团队决定合适的SBI颗粒度

    • Work is not assigned 没有一个人主导任务的分配

    • Sign up for new work after one work is done 完成一项任务才认领另外一项任务

    • Based on priority and try to reach fully DONE on a PBI 按照优先级，努力使一个PBI尽早完全完成

  • Team tracks remaining work of the Sprint, daily 团队每天跟踪Sprint中剩余的工作

  • Any team member can add, delete or change the sprint backlog item (SBI) 任何团队成员可以添加，删除或变更sprint backlog事项 (SBI)

  • Work for the sprint may emerge sprint内的工作有可能动态涌现

  • Visible to the world，对全世界可见

  • Update in real time，随时更新

  • Represents the current progress toward the Sprint Goal， 直观展示Sprint目标完成的进展

  • Work visibility management tool, 工作可视化管理的工具

Sprint Burn Down Charts 迭代燃尽图

• Sprint Burn Down Charts Sprint 燃尽图是一个可选的可视化工件，用来管理Sprint Backlog，并帮助团队自己跟踪进度和暴露风险

  • Updated in real time 随时更新

  • Represent the amount of work remaining，度量Sprint剩余工作的总量

  • Different approaches to creating burndown charts，燃尽图有不同思路

  • Estimated remaining efforts，剩余工作量估算

  • Tracking DONE only，跟踪已完成项

Potentially Shippable Product Increment (PSP) 潜在可交付产品增量

• The sum of all the Product Backlog items completed during a Sprint and the value of increments of all previous Sprints 当前Sprint所完成的PBI，以及之前所有Sprint的增量价值之和

• Potentially releasable and meet the Definition of Done 潜在可交付，并符合完成的定义

• Must be in useable condition regardless whether the Product Owner decides to release it 必须是可用的产品，不管PO是否决定对外发布

Scrum的5个活动

Sprint 迭代

• Scrum projects make progress in a series of “sprints” Scrum项目由一系列“sprint”组成

  • Analogous to Extreme Programming iterations 借鉴了极限编程中的“迭代”

• Typical duration is less than a calendar month at most, or even shorter 不超过一个月的日历时间, 建议1~2周

• A constant duration leads to a better rhythm 通常是定长的，有利于产生更好的交付节奏

• Sprint ends only when the time-box expires 只有当时间盒到期时，Sprint结束

• Product is developed according to DoD within a Sprint 根据DoD定义，全部相关工作在sprint内完成

• Not to change Sprint Goal; 不去改变Sprint的目标

• Not to change Sprint length during a Sprint; 不改变当前运行中的Sprint的长度

• Can a Sprint be terminated? Sprint可以被中止吗？

• Yes 可以

  • Product Owner can cancel the Sprint if business circumstances require 出于业务需要，Product Owner可以取消Sprint

  • Team can discuss with Product Owner to see how to handle, if they are unable to accomplish anything 如果无法完成任何东西，团队可以和PO协商应对

• Go back to Sprint planning — any “not done” work performed should be put back to Product Backlog 重新做Sprint计划－所有还”未完成的工作”放回产品Backlog

• **Very rarely done! **罕有发生！****

  Sprint Planning Sprint计划会议

  Timebox: max 8 hours for 1 month Sprint

  时间盒：1个月的Sprint最长8小时

  Part I SELECTION 第一部分 选择 Define the Sprint Goal 定义迭代目标 Select the Product Backlog Items the team can commit to complete 选择团队可以承诺完成的迭代待办项

  Part II PLANNING 第二部分 计划 Decide how to achieve the Sprint Goal 决定如何实现迭代目标 Create the Sprint Backlog 创建 Sprint Backlog Estimate the Sprint Backlog Items 估算迭代待办项

  • Part I

    • 参与者: Product Owner/Development Team/[ScrumMaster]

    • 输入: Healthy Product Backlog 健康的产品Backlog

    • 输入: Latest Increment 最新版本的增量

    • 输入: Velocity of the Development Team of this Sprint 团队这个Sprint的速率

    • 输出: Crafts a Sprint Goal with Selected Product Backlog Items 根据所选择的产品Backlog事项制定Sprint目标

  • Part II

    • 参与者: Development Team/[Product Owner]/[ScrumMaster]

    • 输入：Capacity of everybody of this Sprint 团队这个Sprint所有人的工作容量

    • 输出: Plan on how to meet the Sprint Goal (Sprint Backlog) 如何实现Sprint目标的工作计划(Sprint Backlog)

    • 输出: Mutual agreement on the Sprint Goal 大家对Sprint目标形成共识

  Daily Scrum 每日站会

  • Parameters，参数

  • • Daily，每日

    • Same time same place, 同一时间同一地点

    • 15-minutes，15分钟

    • Stand-up，站立

    • 参与者: Development Team, [ScrumMaster], [Product Owner]

  • Inspect & adapt on Sprint progress for Sprint Goal, 为达致Sprint目标检视进展和调整计划

    • Not for specific problem discussion and solving，不讨论和解决具体问题

    • Other people can be invited to observe，其他人可以受邀来旁听

    • Only team members, ScrumMaster, Product Owner, can talk 只有团队成员，ScrumMaster和Product Owner可以说话

  • Helps avoid other unnecessary meetings 帮助避免其他不必要的会议

  • 每个人回答三个问题

    • What did I get DONE yesterday to help DT meet Sprint Goal? 昨天我完成了什么，以便帮助交付团队达成迭代目标？

  • • What will I get DONE today to help DT meet Sprint Goal? 今天我要完成什么，以便帮助交付团队达成迭代目标？

    • Are there any impediments slowing/blocking my progress to meet Sprint Goal? 有什么障碍影响我的进度和迭代目标吗？

  • This is NOT status for the ScrumMaster, it is broadcast in front of peers for self-management 不是向ScrumMaster汇报状态，而是向所有组员的广播，属于自管理的一部分

  Sprint Review Sprint 评审

  • Inspect & adapt on the Product and Product Backlog 检视和调整产品和产品Backlog

  • Team presents what it accomplished in the sprint that PO should accept timely 团队展示Sprint的成果，PO应当尽早验收

  • Product Owner explains what have been accepted as “Done” work and what have been rejected as “ not done” work 产品负责人表明哪些“完成”的工作被接受了，哪些“未完成”的工作被退回了

  • Typically takes the form of a demo of new features or underlying architecture, obtain feedback and discuss on future adjustment to optimize value 经常以Demo新功能（及其依赖的架构）的形式，获取反馈和讨论接下来要做的工作，从而持续优化价值

  • Informal，非正式

  • • 4 hours max time-box for 1 month Sprint 1个月的Sprint时间盒最长4小时

    • No slides 不要用幻灯片

    • Least Preparation 尽量不要准备

  • Whole Scrum team participates 全Scrum团队参与

  • Invite all stakeholders and interested parties 邀请所有干系人及感兴趣的人士

  Sprint Retrospective 迭代回顾

  • Inspect & adapt on how we work (people, relationships, process, tools…) 对我们如何工作(人、关系、过程、工具等)进行检视和调整

  • Continuous improvement on process, 对过程的持续改进

  • Timebox: 45min for 1 week Sprint 时间盒：每1周的Sprint花费45min

  • Whole Scrum team participates，全Scrum团队参与

  • Other interested parties are welcome by invitation，欢迎其他感兴趣的受邀人士

  • In a safe environment，在安全的环境中进行

  • One popular format: 3 Question format，一个流行的形式：三个问题

    • Start doing，开始做什么？

    • Stop doing，停止做什么？

    • Keep doing，继续做什么？

  • 输出: Improvement Action Plan for next Sprint 下一个Sprint的改进行动计划

  Scrum的5个价值观

  • ****勇气****Courage：因为我们不是单打独斗,我们能够感受到⽀持,⽽且掌握更多的资源。这一切赋予我们勇⽓去迎接更大的挑战。

  • ****开放****Openess：在团队合作中,大家都会表达我们做得如何,以及遇到的障碍。我们发现将担忧说出来是⼀件好事,因为只有这样才能让这些担忧及时得到解决。

  • ****专注****Focus：由于我们在⼀段时间内只专注于少数几件事情,所以我们可以很好地合作并获得优质的产出。我们能够更快地交付有价值的事项。

  • ****承诺****Committment：由于对⾃己的命运有更⼤的掌控,我们会有更坚定的信念去获得成功。

  • ****尊重****Respect：因为我们在一起工作,分享和成功失败,这有助于培养并加深互相之间的尊重,并帮助彼此成为值得尊重的人。

  • People personally commit to achieving the goals of the Scrum Team.

  • The Scrum Team members have courage to do the right thing and work on tough problems.

  • Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

  • The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.

  • Scrum Team members respect each other to be capable, independent people.

  Scrum团队

  Scrum三大角色，合起来称为Scrum团队。

  在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）, Scrum Master(SM)和交付团队(DT)。

  我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的交付团队，对应到龙舟赛的划桨团队，团队必须协调一致，作为一个整体前进，在这样的环境下单打独斗，各自为政没有任何胜算。

  打造自组织团队的三个约定

  完成的定义 Definition of Done (DoD)

  当产品代办事项列表条目或者增量被描述为“完成”的时候,每个人都必须理解“完成”意味着什么。虽然这在不同的 Scrum 团队之间会有巨大的差别,但是团队成员必须对完成工作意味着什么有相同的理解,这样才能保证透明性。这就是 Scrum 团队的“完成” 定义,用来评估产品增量在什么时候完成，并且没有妥协质量。

  DoD这个定义是团队对产品负责人的承诺，是团队当前能力的体现。可以用来指导开发团队了解在 Sprint 计划会议的时候他们能选择多少产品代办事项列表条目。每个 Sprint 的目标都是交付遵循 Scrum 团队当前的“完成的定义”的潜在可交付产品增量。

  开发团队在每个 Sprint 交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。每个增量都附加于之前所有增量并经过充分测试,以此保证所有的增量都能工作。

  随着 Scrum 团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。

  需要注意的是，如果在每个迭代，我们对“完成”的标准要求过低，那么这会导致在每个迭代，我们都会遗留一些完成外的工作，完成外的工作持续累计会增加项目的风险，有可能导致产品负责人决定发布的时候，产品却因为累积了过多的完成外的工作而无法发布，以致于我们还需要一个额外的Sprint来使它稳定。

  准备好的定义 Definition of Ready (DoR)

  当PO拿出Product Backlog请团队拉动工作时，团队是否能否立刻开始，抑或充满疑惑，似懂非懂？有些戏精工程师就在迭代根据自己的理解胡乱做，待到验收的时候产品负责人和客户大叫“这不是我要的！”

  于是DoR这个定义（也称“就绪的定义”）正式产品负责人对团队的承诺，是团队能够开工的保证。团队有权利要求PO提供这个检查清单中的必需内容，不然的话就先不开始这个工作。

  DoR一般包括：每个PBI和用户故事应当具备背景和目标、足够理解的信息、已估算、已排序、已记录下验收条件测试用例，界面原型草图，乃至浏览器兼容性列表等等。

  团队工作约定 Team Working Agreement

  也称团队纪律。自组织团队中每个人如何协作配合？就像乔布斯在《The Lost Video》中提到的，打造团队就是要明确目标，然后建立一个容器，让大家互相争吵、碰撞、打磨，于是丑陋的石头也会变成漂亮的石头。

  大家之间磨合的约定和规则是符合现实的，外人不能也无法给出一个传统的流程强迫大家遵循，一定是大家提出、大家认可，大家才能执行下去。

  这些工作约定可以显式化张贴出来，也允许更改。比如每个迭代回顾会的时候，SM可以引导大家对Working Agreement进行更新。一般内容中包括：开站会时间、用什么工具IDE、持续集成轮流负责、讨论时不准玩手机、一次只有一个话题、先不评判别人的想法等等。

  敏捷估算

  Absolute Estimation 绝对值估算 number with a ‘unit’, like MD/Hours, Line of Code etc 带有”单位“的数字，例如人天/小时，代码行数等

  vs.

  Relative Estimation 相对值估算 number WITHOUT a unit: number of times we compare one against another 不带单位的数字：一个数字与另一个数字的对比

  Why Relative Estimation 选择相对估算的理由

  Estimation == Best Guess Accuracy over Precision Accuracy vs. Effort of estimation Work Effort ≠ Time

  用户故事

  什么是用户故事？

  用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

  1. 角色-Who：谁要使用这个功能。

  2. 活动-What：需要完成什么样的功能。

  3. 商业价值-Why：为什么需要这个功能，这个功能带来什么样的价值。

  用户故事通常按照如下的格式来表达：

  英文：

  As a [who], I want [what] , so that [why].

  中文：

  作为一个<角色>, 我想要<活动>, 以便于<商业价值>

  举例：

  作为一位招聘者，我想要发布一个职位信息，以便于应聘者能够看到和投递该职位。

  需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

  Jeff Paton升级Ron Jeffries的5C

  卡片（Card） – 用户故事一般写在小的报事贴卡片上。卡片上可能会写上故事的简短描述，工作量估算等。 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。 确认（Confirmation）- 通过验收测试用例确认用户故事被正确完成。 构建(Construction) – 团队通过技术手段实现这个用户故事的要求和功能。 后果(Consequence) – 交付给用户真正使用，并获取反馈。

  优秀用户故事的六个特征- INVEST原则

  INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

  一个好的用户故事应该遵循INVEST原则。

  独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

  Scrum检查清单

  你的团队和组织中，Scrum与敏捷做的怎么样啊？可以用这个Scrum Checklist来做个免费的自我评估吧。