产品经理-需求分析-用户故事-敏捷开发 详解 一张图帮你了解Scrum敏捷流程

产品经理-需求分析-用户故事-敏捷开发 详解

用户故事是从用户的角度来描述用户渴望得到的功能。
一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
As a <Role>, I want to <Activity>, so that <Business Value>.

用户故事的六个特性INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
独立性,可协商性,有价值,可以估算性,短小,可测试性
一个好的用户故事应该遵循INVEST原则。

=========================

一张图帮你了解Scrum敏捷流程

=========================

什么是用户故事？

用户故事是从用户的角度来描述用户渴望得到的功能。
一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

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

英文：

As a <Role>, I want to <Activity>, so that <Business Value>.

中文：

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

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

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

Ron Jeffries的3个C

关于用户故事，Ron Jeffries用3个C来描述它：

卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。

交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

用户故事的六个特性- INVEST

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

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

独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

==================================

1、用户故事；为什么要有一条用户故事？一定是说明问题，提出解决方案，明确解决效果。要用简洁的语言，说对有用有价值的需求，是外在的行为。 2、用户故事的模版；角色定义（我是谁）+期待（我要什么？）+原有/目的（我为什么会这样）
3、开发工程师的疑问咬文嚼字，对故事一定要在语言上进行提炼要对开发工程师宣导用户故事中创造的价值 4、检验用户故事的标准（教材中也有提到的五点）独立的可协商的有价值的小的，可在一轮迭代中完成的可测试的 5、关于用户故事的几句有用的话可测试的用户故事，是否明确了有极限值和边际成本验收条件中是否包含了新的用户故事描述是否从用户的角度中进行

在我们的开发工作中一共有两类东西要开发，一种是数据，一种是操作。

所谓数据，就是比如要编写一个CRM，其中有“用户、角色、权限”这三种东西，就是要管理的数据，这里权且记下用户有“3个史诗故事”要管理。

所谓操作，就是对用户，应该有增、删、改、查、加入角色……这些称之为操作，这里权且记下对用户，用户会有“5个用户故事”。

下面是我们的实际项目的局部截图，课本是史诗，蓝色是故事带括号和加号的是两个合并的故事，箭头是增强请参考上篇故事分类：

史诗都是名词，都是要被管理的核心信息，而且是用户可以理解的信息；

故事都是动词，都是用户平日里使用软件产品所进行的业务操作；

最后一个小贴士是每个史诗故事平均有7个左右的故事，少于4个要怀疑是不是史诗，多于10个要怀疑是不是应该拆分新的史诗了。

故事板安排技巧

故事板的一般概念就不多说了，无外乎几个栏目：待开发-开发中-待测试-测试中-待发布-发布之类的，大同小异。

一个技巧则是“开发中”这一列一定要窄，含义是不要同时开发多个故事，最好结束几个再开几个。目的是不要所有故事开始了却都没有结束，导致最后无法交付。

这也使得跟进人不会太忙乱于多个故事，可以一个一个介绍，一个一个评审。

独立性（Independent）——尽可能让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制订计划、确定优先级和工作量评估都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。 可协商性（Negotiable）——用户故事的内容要是可以协商的，用户故事不是合同。一张用户故事卡片上只是一个简短的描述，不包括太多的细节。具体的细节在沟通阶段提出。如果一张用户故事卡片带有太多的细节，实际上会限制和用户的沟通。 有价值（Valuable）——每个用户故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事，并不是一个契约，而且可以进行协商的时候，他们将非常乐意写下故事。 可评估（Estimable）——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划。 规模小（Small）——一个好的故事要尽量维持小规模，至少要确保在一个冲刺周期中能够完成。用户故事越大，在安排计划、工作量评估等方面的风险就会越大。 可测试（Testable）——一个用户故事要可以测试，以便确定它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。

=============================
产品负责人
产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨组织、Scrum 团队和团队成员个体的不同而有所不同。

产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：

清晰地表述产品待办列表项；
对产品待办列表项进行排序，使其最好地实现目标和使命；
优化开发团队所执行工作的价值；
确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及
确保开发团队对产品待办列表项有足够深的了解。
产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。

产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。

为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另一套需求开展工作。

=======================
开发团队
开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。
开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应能最大化开发团队的整体效率和效用。

开发团队具有下列特点：
他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

开发团队的规模
开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master 角色不包含在此数字中，除非他们同时也参与执行 Sprint 待办列表中的工作。

=======================
Scrum Master
Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。

Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

Scrum Master 服务于产品负责人
Scrum Master 以各种方式服务于产品负责人，包括：

尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
找到有效管理产品待办列表的技巧；
帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
理解在经验主义的环境中的产品规划；
确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
理解并实践敏捷性；以及，
按要求或需要引导 Scrum 事件。
Scrum Master 服务于开发团队
Scrum Master 以各种方式服务于开发团队，包括：

在自组织和跨职能方面给予开发团队指导
帮助开发团队创造高价值的产品；
移除开发团队工作进展中的障碍；
按要求或需要引导 Scrum 事件；以及，
在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。
Scrum Master 服务于组织
Scrum Master 以各种方式服务于组织，包括：

带领并指导组织采纳 Scrum；
在组织范围内规划 Scrum 的实施；
帮助员工和利益攸关者理解并实施 Scrum 和经验产品开发；
引发能够提升 Scrum 团队生产率的改变；以及，
与其他 Scrum Master 一起工作，增加组织中 Scrum 应用的有效性。
SCRUM 事件
Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是规定的，不能缩短或延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。

Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint 不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。

=======================
Sprint
Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。

Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。

在 Sprint 期间：

不能做出有害于 Sprint 目标的改变；
不能降低质量的目标；以及，
随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会澄清和重新协商。
每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于完成某些事情。每个 Sprint 都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品增量。

Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一个月的成本上。

Sprint 计划会议
Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共同协作完成的。

Sprint 计划会议是限时的，以一个月的 Sprint 来说最多 8 小时为上限。对于较短的 Sprint，会议时间通常会缩短。Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议的目的。Scrum Master 要教导 Scrum 团队遵守时间盒的规则。

Sprint 计划会议回答以下问题：

接下来的 Sprint 交付的增量中要包含什么内容？
要如何完成交付增量所需的工作？
话题一：这次 Sprint 能做什么？
开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来的 Sprint 可以完成什么工作。

在Sprint 计划会议中，Scrum 团队还草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。

话题二: 如何完成所选的工作？
在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定如何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待办列表项加上交付它们的计划称之为 Sprint 待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 计划会议中，开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint 中能够完成。在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工作在 Sprint 计划会议和 Sprint 期间按需进行。

产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。如果开发团队认为工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在 Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释他们将如何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。

Sprint 目标
Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指引，使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标为开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个连贯一致的功能，也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

=======================
每日 Scrum 站会
每日 Scrum 站会是开发团队的一个以 15 分钟为限的事件。每日 Scrum 站会在 Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队协作和性能。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。 开发团队借由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每天，开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结束时开发出预期中的增量。

会议的结构由开发团队设定。如果会议专注于达成 Sprint 目标的进展，开发团队可以采用不同的方式进行。一些开发团队会以问题为导向来开会，有些开发团队会基于更多的讨论来开会。以下为示例：

昨天，我为帮助开发团队达成 Sprint 目标做了什么？
今天，我为帮助开发团队达成 Sprint 目标准备做什么？
是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？
开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。 Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。 每日 Scrum 站会是开发团队的内部会议。如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。 每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。

=======================