aic准则和bic准则_用户故事准则

aic准则和bic准则

免责声明：这篇文章摘自内部Codurance文档，该文档用于帮助我们的学徒学习我们的工作方式。 我们都知道每个项目都是不同的，而且我们绝不能在任何地方应用完全相同的技术和实践。 但是，以下文字不仅作为基础，而且还是我们所有人涉及用户故事时的指南。 有很多关于用户故事的好书和帖子。 这篇文章绝不是该领域所有良好实践的总结。

用户故事是收集需求，就需要完成的事情达成共识以及向客户提供正在执行的工作的可见性的好方法。 它们还帮助我们根据在给定时间点添加的价值来确定要进行的工作的优先级。

以下是有关我们如何处理用户故事的一些准则。

捕获要求

创建用户故事的主要目的是了解需要做什么。 它们记录了应用程序需要提供的预期行为。 这是通过产品所有者（代表业务需求并负责优先级），业务分析师，QA和其他开发团队之间的密切协作来实现的。

用户故事生命周期

用户故事始于这种行为的想法。 此行为还必须与实现后将添加到业务的某些价值相关联。

最初，用户故事只是一个想法，并且仅具有描述预期行为的标题，没有详细信息。 例如，音乐播放器，报告固定收入交易，显示用户供稿。 产品负责人从业务中引出故事。 团队成员还可以与产品所有者合作，将故事添加到产品积压中。

产品负责人必须确定开发团队将在下一次迭代中处理的故事的优先级。 这是通过按重要性顺序将故事移至产品积压的顶部来完成的。 仅针对少数几个故事（并非全部）进行此操作。 在该时间点，待办事项顶部的故事具有最高的业务价值。

一旦对故事进行了优先排序，就应该对其进行完善。 此时，产品负责人将开始指定预期的行为。 他们将提供足够的细节，以便开发人员有足够的信息来开始实施该故事。

完善用户故事

一个故事必须具有以下内容：

1. 它为业务（或特定角色/角色）带来的价值
2. 预期行为的详细描述，如果适用，最好带有一些示例。
3. 接受标准意味着开发团队需要做的所有事情，以便产品所有者可以“接受”故事（同意故事完成）。

用户故事模板

用户故事的原始模板是：

As a <actor/role>
I would like to <desired action>
So that <business value>

我们首选的模板是：

In order to <get some value>
As a <actor/role>
I would like to <desired action>

后一个模板可帮助我们首先关注业务价值。 在许多情况下，使用默认模板时，我们能够完成前两个步骤，而很难完成第三个步骤。 不专注于第三步的问题是，我们最终可能会构建没有真正业务价值的功能。 首先要专注于编写业务价值，这迫使我们讨论故事的真实意义。

除了业务描述之外，故事还应尽可能多地举例说明。

最后一部分是验收标准。 在这里我们描述了预期行为的细节，包括边缘情况。 接受标准是产品所有者用来“接受”故事的条件。 验收标准是自动化测试的理想来源。

示例故事1：信用卡付款

In order to buy the items I need
As a customer
I would like to specify the credit card I want to use.

Acceptance criteria

* User must to have at least one item in the shopping basket in order to go to make the payment
* £2.00 fee should be added when amount to be paid is less than £10.00
* Accepted Credit Cards are: Visa, MasterCard, and American Express

示例故事2：播放列表

In order to easily find and listen to my favourite songs
As a music fan
I would like to organise my songs into playlists.

Acceptance criteria

* A playlist can be empty
* A song can be added to multiple playlists
* A song can only be added once to a playlist
* Playlists should have a unique name

Examples

| Playlist name | Songs                                 |
| Punk/Rock     | God Save The Queen, American Jesus    |
| Classic Rock  | Sultans of Swing, Sweet Child of Mine | 
| General       | Sultans of Swing, Censura             |

进一步阅读： 举例说明

将故事分解为任务

为了估算故事，开发人员应将故事分解为技术任务。 每个任务都应该反映一个很小且可衡量的工作。

示例故事2的任务：播放列表

假设我们正在使用前端的AngularJS和后端的Java，Dropwizard和MongoDB构建一个Web应用程序。

1. 定义前端使用的API。
2. 更改用户界面以捕获新的播放列表名称（请参见样机）
3. Dropwizard端点用于创建播放列表
4. 播放列表服务/存储库界面
5. MongoDB上播放列表的持久性
6. 用户界面更改，将歌曲添加到播放列表（请参见样机）
7. Dropwizard端点，用于将歌曲添加到播放列表
8. 将持久歌曲添加到MongoDB中的播放列表

项目7和8应该成为这个故事的一部分吗？ 简短的答案是否定的 。 尽管相关，但任务代表两个不同的概念：创建播放列表并将歌曲添加到播放列表。 下文提供了更多信息。

将故事分解为小故事

有时，我们知道我们仅需查看故事的名称或描述就需要将其分解为较小的故事。 例如：处理交易，音乐播放器等。什么类型的交易？ 我们有几种类型？ 他们有不同的规则吗？ 即使处理一次交易也可能是巨大的。 我们需要丰富数据吗？ 我们需要向不同的监管机构报告交易吗？ 交易来自单一来源吗？ 它们具有相同的格式吗？ 我们也可能有很多关于音乐播放器的问题。 我们正在播放本地存储的音乐吗？ 我们在流媒体吗？ 如果是，请问哪些来源？ 我们应该支持几种格式？ 我们是否应该能够快进，暂停和倒带？ 我们是否从先前停止的地方开始播放歌曲？ 我们是否显示有关正在播放的歌曲的任何信息？ 如果是，我们从哪里获得信息？

如您所见，我们的故事无法满足整个功能。 换句话说，处理交易和音乐播放器不是故事，而是故事。 功能通常被称为史诗，但是我们认为功能是一个更好的术语。

完善故事时，我们作为开发人员的职责是向产品所有者提出所有这些问题。 根据答案，我们应该创建代表不同行为的故事。

产品负责人不知道答案会怎样？

好吧，这里有几种可能性。 有时可以帮助产品所有者提供一些建议，并解释每个建议的成本/权衡。 有时，整个团队都可以集思广益，并从中选出一个。 但是，根据域的不同，开发人员可能没有足够的业务知识甚至无法提出建议。 在这些情况下，我们可以创建一个故事来表示正在讨论的行为并将其添加到待办事项中。 每当产品负责人得到答案时，她便会优先处理该故事或从待办事项中删除该故事。

估算值

关于估计，存在很大的争议。 但是，争论更多地是关于一般的估计，主要是大的前期估计（在Twitter上搜索#noestimates hashtag以获得更多信息。）

我们发现估算最高优先级故事的行为很有价值，主要是在团队不够成熟的情况下（未掌握系统中使用的所有技术，与企业的交流不是最佳的，缺乏业务领域等）

估算用户故事会迫使我们考虑为完成故事而需要执行的所有技术任务。 有了任务列表后，我们就可以开始单独估计它们了。 让我们来处理播放列表故事的任务：

1. 定义前端使用的API（2小时）
2. 使用者介面变更，以撷取新的播放清单名称（3小时）
3. 用于创建播放列表的Dropwizard端点（2小时）
4. 播放列表服务/存储库界面以添加播放列表（2小时）
5. MongoDB上播放列表的持久性（1小时）
6. 使用者介面变更，将歌曲加到播放清单（12小时）
7. Dropwizard端点，用于将歌曲添加到播放列表（2小时）
8. 将持久歌曲添加到MongoDB的播放列表中（1小时）
9. [添加]播放列表服务/存储库界面，用于将歌曲添加到播放列表（3小时）
10. [ADDED]创建新播放列表的通知事件（2小时）
11. [ADDED]通知事件，歌曲已添加到播放列表（2小时）

估计副作用

在尝试估算任务时，我们意识到我们忘记了一些任务（9、10和11），因此我们将它们添加了。 这个故事的预计总时数为32小时。 添加更多任务可以清楚地说明这个故事必须分为两个部分：创建播放列表并将歌曲添加到播放列表。

估计这个故事的另一件有趣的事情是，我们现在注意到，如果将我们的工作日算为只有5个生产小时（不间断的编码小时），那么这个故事大约需要6.4天。 对于用户故事而言，这太大了，这是将故事分为两部分的另一个原因。

小有多小？

考虑一下单一责任原则（SRP）。 是的，来自SOLID的那个。 我们的用户案例应代表一个单一，小型且可测试的概念。

作为指导原则，故事不应大于迭代的1/3（三分之一）。 这意味着，如果您要进行为期两周的迭代，则故事不应超过3天。 另一方面，任务不应超过半天（2到4个小时）。

尖刺

让我们以以下任务为例：

5. Playlist persistence on MongoDB (1 hour)

如果这是我们需要使用MongoDB的第一项任务，而我们过去从未进行过MongoDB持久化，则有可能我们并不真正知道我们需要做什么以及需要花费多长时间。 我们需要进行一些研究，甚至可能尝试一些尝试才能估计任务。

这就是峰值的用途。 尖峰是一个有时间限制的调查活动，其结果在记录调查结果以及故事和任务的改进（包括估计）。 一旦我们花了一两天的时间研究如何在MongoDB上安装，连接和存储数据，我们就可以更好地创建/调整任务并进行估算。

尖峰不应作为故事的一部分

尖刺是孤立地完成的，绝不作为故事的一部分。 如果故事取决于突发事件所进行的调查，则应当优先考虑突发事件，并且故事应保留在待办事项列表中。 一旦完成加标，就可以对故事进行细化并安排到下一个迭代中。

Spike是一种特殊的故事，其价值在于更好地了解可以实现什么或如何实现目标。

技术故事

通常，应避免使用它们。 我们应该只有提供商业价值的故事。 应该将技术任务添加到业务案例中。 这样做的原因是始终专注于为客户提供价值，而不是为架构和基础架构而疯狂。

何时使用技术故事

在项目开始时，技术故事很常见。 在开始工作之前，需要做好许多准备工作。 例如，持续集成，UAT /测试环境，源代码控制等。为了满足第一个故事，还需要进行大量的基础架构/架构工作。 例如，创建数据库，打包和部署应用程序等。除此之外，始终还需要满足非功能性要求。 例如：性能，安全性，日志记录等。

表达业务价值

技术故事不容忽视。 但是，在编写它们时，我们需要表达它们带来的业务价值。 例如保护用户数据，支持更多的并发用户，以更好的响应时间改善用户体验等。

表达技术故事的商业价值非常重要。 这使企业可以更好地理解为什么需要完成某些事情。 业务还可以分析不做某些事情的风险，并据此对它们进行优先排序。

技术与商业故事

只要有可能，我们就不应在业务案例中包含基础结构/架构任务。 例如，在创建客户的业务案例中，我们不应承担将数据库添加到集群的任务。

非功能性需求（如性能改进，缓存，群集，通信协议）应具有自己的技术故事。

投资

INVEST助记符是由Bill Wake创建的，以提醒用户故事质量高的特点，可以在Scrum积压或XP项目中使用它。

• 独立 ：用户故事应该是自包含的，其方式是不固有地依赖于另一个用户故事。
• 可以商量的：用户故事，直到它们成为迭代的一部分，都可以随时更改和重写。
• V aluable：用户故事必须为最终用户创造价值。
• èstimable：您必须始终能够估计用户故事的大小。
• 可缩放（小型）：用户故事不应太大，以致无法以一定的确定性来计划/任务/确定优先级。
• 牛逼 estable：用户故事或与其相关的描述必须提供必要的信息，以使测试开发成为可能。

有关INVEST的更多信息，请查看其维基百科页面

我们为什么要关心所有这些？

我们执行上述所有操作的原因有几个：

• 可见性：以较小的增量进行工作可以很好地了解已完成的工作，正在执行的工作以及尚待完成的工作。 任务和故事不断变化，在我们的Scrum面板中从TO DO到DONESwift浏览不同的通道。
• 反馈：业务和开发团队对事情的进展有不断的反馈。 这样既可以Swift做出React，又可以改变优先级。 如果某个故事出了问题，我们可能只会失去几个小时或几天的工作，而不会花费数周或数月的时间。
• 团队士气：当我们不断实现目标时，士气总是高涨 ，这意味着将任务和故事移到完成的位置。
• 敏捷性：小批量工作使我们能够经常部署，快速获得反馈并在必要时进行调整。
• 团队组织：定义清晰的故事和小任务，可以更轻松地拆分和并行化工作。

这篇文章是由Sandro Mancuso与Mashooq Badar合作撰写的。

翻译自: https://www.javacodegeeks.com/2015/03/user-story-guidelines.html

aic准则和bic准则