处理用户故事

Question

我正试图加强处理功能请求的过程。目前，我们使用trello使用卡片来管理功能请求。他们一般都是这样的。

Card Title: Invite a friend
Card Description: Allow the user to send an invite.

然后我解释这个特性并开始编写代码来满足请求。有时，我不得不在编码过程中停下来，向客户或项目经理发出这样的问题：“这只是普通用户的问题吗?如果邮件已经存在，会发生什么情况?邀请页面的链接应该放在哪里?等等。”

我正在编写用户故事，它似乎会提前带来更多的对话，并帮助完成功能的规划阶段，但我觉得在编写代码之前至少还应该有一个步骤。

例如，我们正在开发一个允许教师和学生进行交流的网络应用程序。我们得到一个功能请求，允许用户发送一个邀请。这个特性有三种场景。

场景1用户故事

作为一名学生，我想:邀请我的同学:他们可以和我们的老师交流。

场景2用户故事

作为一个:学生，我想:邀请我的老师:这样:我们可以在申请中交流。

场景2用户故事

作为一名老师，我想:邀请我的同事:他们可以和他们的学生们在一起。

作为程序员/开发人员，在编写任何代码之前，将其作为计划阶段的一部分，最好的方法是什么？如何将这个用户故事分解成与开发人员相关的内容，并在实际编写代码时进行参考。我使用TDD，所以我通常会开始用我希望存在的代码编写测试，然后开始编写类和方法来满足我的测试。我能用一个用户故事做类似的事情吗？

Answer 1

听起来你在寻找BDD和Gherkin规范语言。gherkin语言是一种表达业务场景的方法，然后可以用来对代码级测试进行存根。一旦您有了测试存根，就可以开始使用更传统的TDD红色/绿色/重构样式方法来实现解决方案。

下面是一篇博客文章：https://medium.com/@SteelKiwiDev/how-to-describe-user-stories-using-gherkin-language-8cffc6b888df

有一些BDD框架可以用多种语言读取gherkin场景，所以您很有可能在开发人员满意的情况下开始工作。

Answer 2

嗯。我看了你的三个场景，我看到了一个让我担心的依赖:场景1似乎假设您已经交付了场景2，当这种情况发生在我身上时，我会寻找另一种方式来拆分这个故事。至少，这会让我问，“这三种情况到底有什么不同？”也许什么都没有。也许我只需要一个场景。

或者这里有一些不对称。一个人是否需要特殊的许可(授权)？邀请另一个人？这听起来像是与了解域和系统预期行为的人一起探索的东西。

假设系统需要特殊的授权规则。没问题。我写的第一个故事是允许每个人邀请其他人(荣誉系统)，然后为每个“有趣”的授权规则添加更多的故事。一旦任何人都可以邀请其他人，那么每一个额外的相关故事都会通过拒绝不应该允许的邀请请求来完善这个特性。这是有很多原因的，但是如果系统存在严重的安全/隐私问题，那么您可能需要改变这种情况，这样您就可以从“没有人可以邀请任何人”开始，然后每次添加一个权限。试图将更大的故事分解成更小的故事，这往往会让我对潜在的隐秘假设提出疑问。我们不想等太久才听到，“我们当然有授权政策.谁没有呢？”

对我来说，杀手的技巧就是举例说明。当我和任何人讨论一个故事时，我会毫不留情地描述一些例子来说明我目前对这个故事的理解。这样，另一个人就有机会听到我的榜样，告诉我我是怎么错的。那一刻让我了解到我需要建立一个正确的系统。我一遍又一遍地做，收集这些细节。我一直试图描述更简单、更简单的例子，这会促使另一个人“战斗”来添加重要的变体。几分钟之内我就知道了很多。在15分钟内，我几乎可以肯定地知道足够的开始，而没有走向完全错误的方向。然后我构建一些东西(不管TDD与否，不管对你有什么用)，把一些东西放在他们面前，然后得到更多的反馈。在例子中。再三。只是起作用了。

顺便说一下，这些示例可以成为自动测试，以驱动系统的行为。根据客户参与编写和完善这些示例的积极性，您可以任意自动化它们。请记住，这些例子90%的价值来自于谈话，而不是自动化。