如果我们采用用户故事，我如何说服我的团队不需要需求规范？

9

我们计划采用用户故事，以轻量级方式而不是繁重的SRS（软件需求规范）来捕获利益相关者的“意图”。但是，似乎他们虽然了解故事的价值，但仍然希望将故事“转换”为具有所有属性，优先级，输入，输出，来源，目的地等的SRS式语言。

用户故事从一开始就“消除”了对像正式SRS这样的工件的需求，那么拥有SRS的意义何在？如果我们采用用户案例来捕获系统的功能需求，我应该如何说服我的团队（顺便说一句，他们都是非常合格的CS人才-在教育和实践上都如此），SRS将被“消除”。（也可以捕获NFR等，但这不是问题的意图）。

所以这是我的“工作流程”论点：将初始需求捕获为用户故事，然后将其详细阐述为用例（需要以较低级别进行记录，即描述与UI原型/模型的交互，并且是可交付的文章）部署）。因此，从用户故事转到用例，而不是从用户故事转到SRS到用例。

你们目前如何在工作场所中捕获用户故事（如果有的话），以及您如何建议我为存在用户故事的情况下缺少SRS辩护？

— 博士
source

它不会在一天内发生，请采取轻松的方法

— Yusubov

如果您为软件服务提供商工作，那么当客户想要降低成本或服务提供商提出需要更多资金或两者都将提起诉讼时，可能不需要SRS来执行实施，而要做“责备游戏”。

— k3b

14

宝贝的步骤。继续编写SRS一段时间。然后召集会议，讨论它们是否仍能达到目的。有人还在读吗？花在他们身上的时间合理吗？是否还有另一个中间步骤会更轻量级？

您永远不会知道，您可能会发现自己错了。记住敏捷宣言，我们发现“通过综合文档工作软件”具有更多价值，但后者仍然具有价值。

但是我的猜测是，当他们看到用例与用户案例之间的联系紧密时，您会很快发现继续写沉重文档的愿望逐渐消失。

— 聚苯乙烯
source

2

@博士：你是对的。这几乎是原始的。这就是为什么您不会凭借任何逻辑，仅凭证据就无法赢得这场战斗。宝贝的步骤。

— pdr 2012年

2

我曾为那些面对变化，步履蹒跚的经理工作，这是他们的代言词，“只能做失败的事，所以我可以说我是对的”，这不是成功之路，因为它显示出对新方法论的根本缺乏理解管理层缺乏全面的支持，这对于成功的变革至关重要。从理论上讲，这听起来不错，但实际上，这是一个没有改变的借口，并宣称胜利是新方法无效而旧方法有效。因此，SRS得到了加强，故事将被标记为额外的工作，您将回到原来的状态。

2

我的经验不是很奇特，这是我从事该行业超过22年的经验，其中大部分是咨询工作。因此，在相同的时间内，与大多数人相比，我与更多的经理和决策者一起工作。我的观点是，这种“ 小步骤”方法是失败的方法，只有高层管理人员对变更的承诺以及变更背后的理念才能成功实施。如果他的同事不相信，让他们继续做他们想做的事情不会说服他们，那只会使我们仍然需要旧的方法，而新的方法会浪费时间。

1

@JarrodRoberson我只想补充一点，就是我的经历更能反映您的经历。有两类人，因此有两种类型的管理者，保守主义者和冒险者。保守派自然不愿改变和冒险。当他们找到一个可行的模型时，甚至坚持不懈地坚持下去。当强迫改变或强迫改变时，他们会下意识地破坏行为，试图采取行动。这就是为什么我唯一见过真正的敏捷采用工作是由冒险者领导的情况。

— maple_shaft

2

@maple_shaft：诀窍是继续前进。如果增量更改不起作用，则不必再次采取相同的步骤，请考虑为什么它不起作用...就像您可能仍然花费太多时间，编写了毫无意义的文档。现在我要承认，需要一个好的经理来思考这种方式，并且大多数人都会回到他们的舒适区。但是，按照完全相同的原理，这并不意味着唯一的选择就是彻底改变。坏经理会把它弄糟。

— pdr 2012年

6

史诗是占位符

在几乎所有的敏捷方法中，Epics的概念将与您对需求规范所需要的一样多，占位符就是您在该级别上所需要的。这些条目将被不断地进行优先级排序，如果需求长期处于低优先级甚至从未得到实现，那么任何更多的细节都将被浪费。对其进行文档编制和管理文档将完全浪费时间。YAGNI扩展到需求活动以及编码活动。

工具是您的朋友！

如果您使用适当的工具来收集和管理用户案例，则可以从中生成需求规范。需求规范无论如何都是时间工件文档，它不是活动文档，而是时间需求的快照。并且永远不会与现实同步。

自动生成工件

可以从适当的工具导出的用户故事比任何时候的静态工件文档都更有价值。我个人更喜欢使用Pivotal Tracker来跟踪用户故事，我甚至用Python编写了一套MoinMoin插件，以在Wiki中发布所有各种故事及其状态（其中包含有关故事的详细开发人员注释等），实时数据始终是比静态数据更好。

Wiki成为所有商店/需求及其完成状态和优先级的实时文档，并带有详细信息，评论和其他元数据。

比Sharepoint中庞大的Word文档要好得多，后者只是不断发送电子邮件，并且从未更新，从而确保每个人都有不同的版本并且与其他人不同步！

用户案例比用例丰富

用例比用例更有价值，因为他们说为什么。

用户故事格式：As a [ROLE] I [ACTIVITY] so that [WHY]比类似的用例The System [shall/shall not/may/must] perform [action]（其中的动作是流程图）更具表现力。

随着用户故事，你必须WHO想做一件事，你有什么他们想要做的（这可以指向复杂的任务更详细的示意图/文档），你拥有的最重要的部分为什么他们想要做的这个活动。

如果您有第一个，那么第二个是完全多余的，充其量只是噪音。Waterfall方法的传统形式需求规范在敏捷环境中没有地位。

到底

如果您的管理层不致力于改变，那么采用新的方法就不会成功。我曾为一家年收入超过100亿美元的公司工作，他们并没有采取简单的步骤来迁移到Agile / SCRUM，他们只是说，整个公司都在朝着这一方向前进，这是新的工作方式，这是当您开始接受新方法的培训时，这是我们将要使用的新工具，这是我们开始以这种方式做事的日期。它在不到一年的时间内为他们工作。我曾在较小的公司成功实施过此工作。

承诺

不管有什么变化，宝贝执行步骤都是失败的秘诀。这是管理层的一个代言词，他们静静地不同意，并且被动地积极地使您陷入失败。他们说我不相信这一点，所以我会让你做失败或不成功的事，那样他们就可以说他们尝试了，但没有成功，而且他们认为自己已经成功了一直很好。部分承诺最终会导致失败。

在您的情况下，他们可能会悄悄地不相信用户故事，并且经过一段时间后，他们会开始宣称是没有用的用户故事而不是SRS，并且将继续停止编写用户故事。，这只会导致您倒退而不是前进。

— ote
source

您会感到非常惊讶，用户故事由可以（并确实）根据需要导出的工具进行管理。但是，关注的问题似乎是将用户故事“翻译”为“系统应...”等SRS语言，而不是将其保留为用户故事。

— 博士2012年

1

好吧，如果挂断电话是“必须/必须/可以”的术语，那么您可能会和那些人随地吐痰。用户故事告诉WHO / WHAT，以及最重要的原因，为什么需要做一些事情，比那些静态用例要有用得多，而静态用例在大多数情况下都可以纠正。

2

-1：完全不同意大多数答案，但是指出并且SRS是“需求规范无论如何是一个时间工件文档，它不是活动文档”，这是错误的，这表明令人不安地缺乏理解SRS的用途或正确使用后的用途-通常仅在当今的旧式瀑布模型软件所中。

— mattnz

5

SRS一经发布即为无效文档。自1990年以来，我就写过它们。它们就像战争计划，永远无法幸免。而且他们永远不会跟上实际的实现，除非您有一个专门的作家团队不断地编辑事物，否则那是错误的，因为与不断变化的疏离和开发人员始终领先于文档，而并非总是如此告诉文档所有者发生了什么事。公司花了1000个小时的时间来编写类似的东西，而文件在开发开始时就被搁置并腐烂了。

3

@JarrodRoberson为您+1。实际上，mattnz也正确，因为SRS应该是一个实时文档，但是随后您遇到了几个关键的生产问题，这些问题使客户的需求发生了变化，同时处理了一个或多个分支版本的代码库，这些需求被误解了。业务分析人员，开发人员和质量检查人员……剩下的只是一个文档，它不是当前系统的真实反映，也不是用户需求的真实反映。用户故事被那些更关心客户而不是系统的公司真正采用。

— maple_shaft

0

我会尝试幽默。

从http://www.halfarsedagilemanifesto.org/开始

讨论一段时间（转移），
并讨论其中的冲突的真正含义（公开讨论），
然后过一段时间，转到您的组织（支点）
，检查SRS，以及在新项目设置中是否有意义。

然后，我将在（或可能在另一次会议中）讨论有关re：SRS方法更改的讨论，看看您是否还有更多共识。

归根结底，您还受到预算和为业务人员提供服务的限制，因此在某些方面您可能会更坚定所使用的内容，但这实际上取决于行业，公司规模，组织因素和许多其他因素。其他这样的因素。

— 迈克尔·杜兰特
source

5

要特别小心。仅在您的同事非常安全并且与他们之间有良好的关系时才能工作。如果您通过幽默来告诉他们错误和隐瞒，很多人会感到沮丧。

— MarkJ

-1

说服mgmt摆脱SRS并开始使用用户案例与说服mgmt采用敏捷本质上是相同的。关于敏捷的生产力优势，有令人信服的统计数据。一个例子是VersionOne在2013年会议上的演讲。显示此行业数据，如果它们是监听类型，则有机会。

— 乔
source

1

抱歉，答案不多。您说“显示统计信息”，甚至不提供链接。

— Jan Doggen

并写完整的单词和句子...

— jwenting