迭代开发用例

我所阅读的有关用例的几乎所有内容都集中于描述需要添加到产品中的内容。 敏捷开发说“首先使它工作，然后使其更好”。 这意味着改变软件使用户能够做他们已经可以做的事情的方式 。 您如何管理增量改进的需求？

迭代开发和增量改进

迭代开发是您迭代发布软件的过程-逐渐改进的小版本软件。 人们通常只考虑首先启用最有价值的功能，然后再考虑下一个最有价值的功能 。

如果您的产品是新产品，那就很好。 最终（或很快！）您将达到一个下一个最有价值的改进，即不添加新功能，而是使现有功能更有价值 。

一切都是升级

在之前有关组织迁移项目和迁移项目 需求的几篇文章中，我写了关于迁移是如何用词不当的说法。 一切都是迁移。

我在较早的文章中的观点是，您使用“新”解决方案解决的问题不是新问题。 您的客户当前以不同的方式解决它们。 迁移项目的相关问题是您的用户正在改变他们解决问题的方式。

[作为一个小问题，如果不了解这种区别，可能会导致您基于错误的问题陈述进行项目 。]

通过迭代开发为产品提供增量改进时，就是在升级软件。 您正在将用户从他们的旧解决方案迁移到他们的新解决方案。 碰巧的是，您正在替换自己，因为您将它们从旧版本迁移到新版本。

一个对我个人而言有吸引力的可行策略是，在其他人开始之前不断创新， 扰乱您的市场 。 使用这种方法，您有意重新发明您的解决方案，从而使其他人难以创新。 这是一种策略性地制定路线图的好方法。

您的市场将会改变 。 很快 您是想对竞争对手做出反应，还是在您踩脚时让他们紧跟其后？

“新” Twitter的回响仍未解决，许多Twitter的竞争对手紧随其后-其中一些竞争对手直到现在才意识到Twitter一直是竞争对手，而不仅仅是“平台”。 新的Twitter并没有真正改变人们使用Twitter的方式，只是使其（明显）变得更好。

避免胎儿炎

与让用户使用您的软件完成更多工作相比，何时才更有价值的是改进您的软件已启用的功能？ 凯西塞拉利昂向我们介绍的概念featuritis ，想法太多 太多 。

在一篇有关病毒性产品管理的文章中，我建议通过改善软件质量，您可以利用利他主义的机制，人们将以此推销您的产品。 例如，我建议改善软件的可用性，以此来突破病毒临界点。

关键思想之一是使其对用户更好，使产品对公司也更好。

管理“改进”要求

现在我们都同意，有必要使软件更好（如果您不同意，请在下面的评论中注释），问题变成了“ 如何 ？！”。

用例可用作您的需求架构的基石。 有时， 用户案例比用例要好 ，但用例却非常敏捷 。 当您开始一个项目时，您想采用一种由外而内的方法来定义该项目的范围，或更具体地说，是要定义您要在路线图中解决的问题的范围 。 本文将以用例的语言进行讨论，但是在使用用户案例时也适用相同的概念和方法。

在将用例确定为“下一个最有价值的功能”之后，可以将其添加到sprint的待办事项列表中。 然后，实施团队会提供有关用例“太大”的反馈，您必须将其分解。 重要的是， 不要以仅解决一半问题的方式拆分用例 。

您也不应该交付“不良”产品。 事实上，理想的方式引入新的功能是能够satisfice ，而不是介绍你的第一次迭代的“完美”的解决方案。 使您的第一个解决方案“足够好”。 现有技术的一部分定义为“足够好”，但请放心，这与“您可能做到的最好”并不相同。

从上面总结一些关键要素说明了您将要面对的最终现实：

1. 用户所面临的每一个问题*已经得到解决，您只是在提供更好的解决方案。
2. 向产品添加更多功能的收益递减，最终会产生负面影响。
3. 首次发布给定功能只会“足够好”。 这留下了改进的空间。

* 是的，您可以将“问题”定义为“现有解决方案不够好” –但是您仍然会停留在同一地点，那么为什么要麻烦呢？

最终，改进已发布内容的价值将大于发布新内容的价值。

你是做什么？ 您将 再次 实现相同的用例 。

如果您的产品是软件即服务（SaaS），则您绝对应该以这种方式考虑问题。 变得更好是SaaS产品经济学中所隐含的持续改进目标 。

回顾用例

不要与用例的重用相混淆， 重新审视用例是为了重新审视（ 旨在改进）产品中已经存在的实现。 这是一个移植项目的一种特殊情况-你从旧的解决方案，新的和改进的解决方案迁移用户。

您可能正在迁移到相同的过程，其性能可能比以前的版本要快。 或者您可以在不影响流程的情况下改进流程（提高可用性，交互设计，视觉设计等）。 通常，“使之变得更好”的用例改进工作只会对流程产生较小的影响。 您的用户仍然在做同一件事，他们只是在享受更多，或者更有效地进行操作。

在对用例进行切片以使其适合单个sprint时，您可以在第一个发行版中为单个用户角色设计它们 ，因为您要等到下一个发行版才能满足不同用户角色的期望。 在这种情况下，您的非功能性要求，约束或接受条件将有所不同。 您的用例在外观上相同时也可能有所不同（详细信息）。 也可以使用相同的方法解决这种常见情况。

找到那个旧的用例（从几个迭代之前开始），并将其放回积压中。 记住，敏捷是关于对话，而不是工件。 如果您需要为用例添加解释，因为您的团队将注意力集中在“已经在工作”这一事实上，那么请添加一个限定词，以使其变得“更好”。 然后进行对话，并说明如何使其变得更好。

设计是实施的一部分吗？

一些团队进行组织，使设计人员（在这里解决设计代码的架构师和设计接口的设计师）成为实施团队的一部分。 其他公司则将设计师视为利益相关者，为产品经理和产品所有者提供指导和意见。

当团队外部要求“新设计”时，应通过工件和/或澄清，将该设计指南作为对实施团队的投入的一部分。

当团队要求“新设计”时（设计师是团队的一部分），请向团队表达新的接受标准。 请注意，如果将它们视为良好需求 ，则这些需求必须是可衡量的 需求 。

摘要

有时候，您可以做的最有价值的事情就是改善用户体验，以实现产品已经体现的功能。 到那时，再次使用相同的用例，并用新的约束，非功能性要求和接受标准进行更新。

参考： 业务分析| JCG合作伙伴 Scott Sehlhorst 提供的迭代开发用例 | 产品管理| 软件需求博客。

翻译自: https://www.javacodegeeks.com/2012/09/use-cases-for-iterative-development.html