敏捷世界中的需求

在最近的一个项目中，一个令人痛苦的地方是，要求不明确的故事最终被开发人员所接受。 然后花时间试图澄清缺失的部分，这意味着更少的时间来编写出色的代码，并且意味着开发人员最终不得不承受更大的压力才能完成工作。

现在，有很多原因使开发团队难以采用敏捷流程（无论是Scrum，看板，XP还是其他）。 我认为这是因为对Sprint的要求不够详细。 他们缺乏足够的规范。 这当然会带来其他问题，例如：错误的评估，工程质量下降，无法按时完成任务以及无法提供正确的功能。 如果听起来有些熟悉，请继续阅读。

在我们的案例中，我们确实有一个开发过程，该过程最好由我们使用的Sprint板泳道来概括：

• 准备发展 –故事在冲刺中，但没有人开始。
• 进行中 -开发故事的开发人员
• 代码审查 –通常有2个人进行代码审查。 我们擅长这一点。
• UX审核 – UX或产品人员将查看输出以确认同一页面上的所有人。
• 完成 –故事已合并，完成测试并准备发布。

发生不清楚的需求问题是因为在将故事传递给开发人员之前，流程没有对故事进行足够的审查。 我决定尝试通过为团队引入专门用于捕获需求的新流程来解决此问题。

我为此过程设定了一些目标：

• 它应该以JIRA为中心。 开发人员，分析师，产品负责人，销售线索应该能够从JIRA这一工具获得所需的一切。 是时候尽量减少Excel，Word，随机电子邮件，某人笔记本电脑上的会议笔记，并将所有重要信息放在一个共享的位置上。 它不一定必须是JIRA，也可以是Asana，Trello或您的团队正在使用的任何敏捷友好项目管理工具。
• 这些故事必须经过审查。 在将故事移交给开发人员之前必须满足严格的标准。 审核需要由关键技术人员来完成。 具有非技术背景的人提出一个想法很好–他们通常是这样做的人，因为他们离客户越近。 但是无论采用哪种想法，技术上都必须可行。 而且，如果需要对其进行调整，则最好尽早进行。
• 关键利益相关者必须进入需求捕获的关键阶段。 例如，UX设计方面的UX专业知识。
• 允许人们以异步方式工作。 现实情况是，故事发展需要在不同阶段拥有不同的关键人物。 需要促进这一过程的过程。

在一开始的时候…

因此，不是JIRA专家。 我首先创建了一个JIRA项目，可以在不影响现有项目的情况下进行操作。 然后，我着手尝试为需求捕获过程创建新的工作流。

JIRA状态

好的，因此每个工作流程都涉及通过各种状态移动问题。 我既查看了JIRA的现成状态（即JIRA附带的现成状态），也寻求了灵感，也因为我想尽可能地利用现有的行业规范。 因此，快速浏览后，我想到了一些我认为合理的状态：

• 想法 –这仅代表某个人的想法的脑筋。 可能只是一个句子，一段甚至是一张图片！
• 故事定义 –在这种状态下，人们期望可以接受标准和通常的故事内容。
• UX设计 -屏幕截图，线框等将由具有UX专业知识的人员添加，这将指导开发人员外观。
• 技术审查 –此步骤将在进行认真审核后进行。 如果没有足够的信息，技术审查将失败，并且该问题将被发送回“故事定义”状态以进行进一步的工作。 此步骤的其他两个重要功能：
  1. 如果需要，它提供了提供建筑建议的机会
  2. 它提示对该工作进行初步估算。 想法是真正捕获这是一件小，中还是大件作品。 估算总是可以改进的。
• 准备好进行开发 –此步骤表示技术审查已通过，故事准备就绪，可以开始冲刺，并由开发人员采用。

你们当中的观察者会注意到，需求捕获过程的最后一步是开发人员过程的第一步。 当问题最终与开发人员冲刺时，这是故意强调流程的分离和连续性。

工作流程

因此，下一步是将所有这些状态放入某种工作流程中。 下面的JIRA工作流程图可以最好地说明这一点。

需求工作流程

总体方向是：想法->故事定义-> UX设计->技术评论->准备开发。 关于上图，以下是要点：

1. 问题有可能在多个状态之间前进和后退。 例如，可以在“技术评论”中，然后返回到“故事定义”，再回到“技术评论”，再回到“故事定义”。 这里的想法不仅是在故事进入开发准备阶段之前进行一些审核，还使分析师可以收集有关可行性的一些技术问题，并让他们回答以帮助他们发展故事的定义。 关键利益相关者与捕获此问题的工作流程之间可能会有往返的因素。 值得再次强调的是，技术审查和故事定义阶段通常由两个不同的人来处理。 前者是技术专家，后者是产品专家。 该过程必须帮助他们共同努力。
2. 我添加了“暂停”和“封闭”阶段。 暂停适用于那些变得不那么重要但又无关紧要的故事。 不相关的只是关闭。 与仅删除它们相比，Closed阶段的优点在于，您可以记录已完成的工作以及未继续执行原始想法的原因。

新领域

接下来是添加更多字段。 其中一些来自团队的反馈。 很好 对流程做出贡献的人越多，买入就越多，新流程就越有可能运作。

• 业务驱动程序 –这里的想法是捕捉为什么我们要执行此JIRA？ 它是来自客户的内部想法还是什么？ 重要的是每个人都知道这一点，分析师，开发人员，主管等
• 验收标准 –正式指定验收标准的逻辑位置。
• 技术审查 –详细说明技术审查的逻辑位置。 这将包括关于开发人员应如何处理故事的体系结构建议。

检查点

如前所述，此过程的计划是使故事从简单的想法演变为正式同意的内容，然后由开发人员实施。 为了促进这种发展，我在关键阶段强制规定了关键领域。

• 必须先填写验收标准，然后才能进行技术审查
• 必须在故事离开技术评论之前填写故事要点。

要在JIRA中执行此操作：

1. 选择以编辑工作流程
2. 选择相关的过渡，然后选择视图验证器选项。
3. 选择验证器选项卡
4. 选择添加新的验证器
5. 选择“必填字段”。 选择要在过渡发生之前完成的字段

合适的利益相关者能站起来吗？

如前所述，此过程的目标是在合适的时间吸引合适的利益相关者。 进一步来说：

• 当JIRA进入UX Design时，它将分配给团队设计师
• 当JIRA进入技术评审时-它被分配给技术负责人。 我扮演这个角色，然后要么进行技术审查，要么将其分配给团队中的另一位高级技术人员。
• 如果问题未通过技术审查，而是返回到“故事定义”，则会重新分配给问题报告者。

为了在JIRA中启用自动分配，我在特定步骤中添加了“发布功能”，以自动分配JIRA问题以更正利益相关者。 此功能在工作流程中的任何转换都可用。 只需选择要自动分配的过渡即可。

故事，新功能还是改进？

JIRA提供了开箱即用的选项，可以在其中创建许多类型的问题：
故事，新功能，改进。 问题在于这里有一个主观性元素。 实施“允许用户重设密码”之类的内容对于一个人而言可能是一个故事，对其他人而言可能是一个新功能 ，甚至对坐在他们旁边的人来说也是一个改进 。 我决定在此过程中，将某些东西仅作为“新功能”或“想法”开始。 然后，它必须经历新的需求流程，完成后将被转移到Story或Epic。

这意味着，它可以更轻松地区分是开发阶段还是需求捕获阶段。 当某人在JIRA中搜索问题时，当他们看到一个Story或Epic时，他们立即知道它已经经历了需求收集过程，已经过审查，然后可以确信它真的可以进行开发了。 这对于积压整理非常有用，我认为积压整理在仅是调度过程而不是对要求公开的辩论时始终会更好。 积压的培训会议变成了对应该发生的事情的深入讨论，这只意味着整个开发团队都在漫长的讨论中。

板子

如上所述，我们已经有了一个开发者冲刺板。 该委员会运作良好。 我们每天在站立时在大屏幕上使用它。 对于需求捕获过程，我希望有类似的东西。 由于以下原因，我决定不更改现有的开发板：

• 它将有太多泳道（最少10分钟），甚至很难在我们的大型宽屏上看到。
• 开发过程和需求过程实际上是针对两组不同的人的。
• 开发板是Scrum板。 虽然我们的开发团队是Scrum和看板的混合体，但我们可以使用Scrum板，但是需求团队却无法做到。 在sprint结束时，所有内容都位于最右边的泳道中，并且发布已准备就绪。 董事会能够专注于开发并最终发布目标真是太好了。 而是要以可能以不同步伐发展的需求来使其杂乱无章。

因此，考虑到这一点，我专门为需求收集过程创建了一个新板。 使用以下泳道：

要求泳道。

过滤器为了避免为此板创建冲刺（它们将毫无意义），我将此板做成了看板。

我为团队产品方面的关键人员添加了过滤器。 他们是推动大多数需求的人。 这是为了帮助他们跟踪自己的工作，并向团队其他成员展示他们在做什么。

优先事项

我想出了另一个领域的想法，即优先考虑JIRA问题。 但是，为什么要重新发明轮子。 JIRA已经有一个优先级字段，该字段具有5个不同级别（按顺序）：

• 封锁者
• 危急
• 重大的
• 次要
• 不重要的

所以，想想，让我们使用它，如果我们需要第六，我们可以添加。 五个优先级确实应该足够了。 为了鼓励人们使用它们，我对级别进行了颜色编码，并将其颜色显示在JIRA板上。

这意味着任何时候只要讨论所有故事，优先事项就显而易见。 事情很容易重新排序。 可以在敏捷板上配置颜色编码。 我从团队那里得到了关于各种颜色应该有的好反馈！ 自然，我更新了现有的开发人员板以使用相同的方案。

最后的话

无论如何，仅此而已。 我相信，不管您在做什么，要获得最佳结果，您都需要一个良好的结构。 在软件中，这意味着您需要一个良好的过程。 每个人都需要知道他们需要做什么，优先事项是什么，并且结构应该使团队（始终是技能和背景的结合）尽可能容易地一起工作以提供最高质量产品。

翻译自: https://www.javacodegeeks.com/2016/05/requirements-agile-world.html