用户故事不适用于我们的团队

我经常听到以下这句话(解释):

“我们的团队不支持面向客户的应用软件。 我们为SOA环境支持一套内部使用的API。 因此,我们不能使用用户故事。

用户故事是描述要完成的工作的一种方式。 当人们不确定如何编写用户故事时,规范形式“作为我想要的东西,这样的东西”仅是帮助人们入门的一个示例。 这不是一个“规则”。

人们希望人们不会永远保持初学者水平,他们很快就会对轻量级需求的想法感到满意。 然后,他们将不再需要类似的模板。 一个希望。

我提到的API团队可以将客户端应用程序视为其“用户”。那很好。 用户故事之神不会被激怒。 (我遇到了其中一些神。正如神所走的那样,它们相当醇厚。)

哦,但是你错了,戴夫! 用户故事必须指定故事的商业价值 。 否则,它们不是正确的用户故事。

好的。 让我们考虑一下。 一件作品可能会或可能不会为离散客户提供100%的“业务价值”。 一件作品可以为许多客户提供多种形式的价值的部分支持。 当要修改的软件离客户几层抽象层时(例如内部使用的API或旧版后端应用程序),通常是这种情况。 量化特定修改所提供的特定业务价值可能很困难,但是如果我们选择的话,我们仍然可以使用“用户故事”来计划和跟踪工作。

再次错了,戴夫! 敏捷开发的“规则”是,我们组成由全栈开发人员组成的跨职能团队,以便没有人从事一点零碎的代码,而这些零碎的代码只有在它们全部组装后才能提供价值。 用户案例代表功能的垂直层面,每个案例为离散的客户类别提供100%的已定义“价值”。 否则,您做错了!

当然,原则上您是对的。 在实践中 ,您也是正确的,只要我们所谈论的是一个使用相对最新技术的相对较小的组织(或联合组织)。

当人们谈论“全栈开发人员”时,他们通常指的是从移动/网络到Web服务器到轻量级数据库(NoSQL或封装在ORM中的关系数据库),也可能是应用服务器。 组建包含所有相关技能且规模足够小,可以平稳运作的跨职能团队当然是可行的。 学习CSS,HTML,JavaScript,Ruby | Python | PHP | Java | C#,构建工具,CI服务器,诸如JPA或ActiveRecord之类的数据抽象库以及几个框架,完全可以在一个大脑中进行。

但是成千上万的开发人员在较大的组织中工作,那里的“堆栈”太深,以至于任何人都不能声称拥有“完整堆栈”的专业知识。 一个跨职能的团队规模太大,无法正常运行,它涵盖了从移动平台到各种旧式后端平台的所有基础,再加上整个第三方软件包的动物园。 在这种环境中,肯定会有团队支持任何给定的垂直功能片段。 在这种情况下,原则上正确无济于事。 尽管理想的情况下,有时我们还是必须考虑现实。

用户故事要记住的三件事:

  • 它们只是作为对话的占位符,而不是详尽的详细说明。 用户故事不是您要交付的产品,因此请不要着迷于完善它们。 保持它们轻盈。 包括对补充文档的引用(如果有帮助的话)。
  • 只要故事能回答(a)谁想要它,任何格式都可以。 (b)有什么好处? ©我们必须做什么(但请注意其他细节)? (d)我们如何知道何时完成? (作为一名从业者,我建议最重要的问题是“如何知道何时完成?”这是一个如果没有回答就会咬你的问题。这也是“作为一个”公式中省略的一个问题。只是在说’。)
  • 无需组织中的所有团队都以相同的方式编写用户故事。 毕竟,不同的团队从事不同的工作。 抵抗官僚!

最初发布在 www.leadingagile.com