用户描述对我们的团队不起作用

这是我经常听到的一句话(转述):

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

用户故事是描述要完成的工作的一种方法。当人们不确定如何编写用户故事时，“作为某物，我想要某物，因此某物”的规范形式只是一个帮助人们开始编写用户故事的例子。这不是“规则”。

人们希望人们不要永远停留在初学者的水平，他们会很快适应轻量级需求的想法。这样他们就不需要那样的模板了。一个希望。

我提到的API团队可能会把客户端应用程序视为他们的“用户”。那太好了。用户故事之神不会被激怒。(我见过其中一些神。就上帝而言，它们相当成熟。)

哦，但你错了，戴夫!用户故事必须指定亚博vip9通道业务价值的故事。否则，它们就不是真正的用户故事。

好吧。我们想一下。单个工作可能为离散客户提供100%的“业务价值”，也可能不提供。亚博vip9通道单个工作可以为许多客户提供多种形式的价值的部分支持。当被修改的软件离客户有几个抽象层时，通常会出现这种情况，比如一个内部使用的API，或者一个遗留的后端应用程序。可能很难量化特定修改所提供的特定业务价值，但是如果我们选择，我们仍然可以使用用户亚博vip9通道故事来计划和跟踪工作。

又错了,戴夫!敏捷开发的“规则”是，我们要组成由全栈开发人员组成的跨功能团队，这样就不会有人在那些只有在全部组装好后才有价值的代码上工作。用户故事表示垂直的功能片段，每个片段为离散的客户类别提供100%的定义“价值”。否则，你就做错了!

当然，原则上你是对的。你就进去了实践，如果我们讨论的是使用相对最新技术的相对较小的组织(或联合组织)。

当人们谈到“全栈开发人员”时，他们通常指的是移动/web到web服务器到轻量级数据库(ORM包装的NoSQL或关系数据库)也许一个应用程序服务器。组建跨职能团队当然是可行的，该团队要包含所有相关技能，规模要足够小，能够顺利运作。学习CSS、HTML、JavaScript、Ruby|Python|PHP|Java| c#、构建工具、CI服务器、数据抽象库(如JPA或ActiveRecord)和一些框架都很容易。

但是有成千上万的开发人员在更大的组织中工作，在这些组织中，“栈”太深了，任何一个人都无法声称自己拥有“完整栈”的专业知识。一个跨职能的团队，要涵盖从移动设备到各种各样的遗留后端平台的所有基础，再加上一大堆第三方软件包，以及中间的所有管道，规模太大，无法顺利运作。在那种环境中，肯定有团队支持任何给定的垂直功能片断。在这种情况下，原则上是正确的并没有多大帮助。有时我们不得不考虑现实情况，尽管是理想情况。

关于用户故事需要记住三件事:

• 它们应该是对话的占位符，而不是全面的详细规范。用户故事并不是你要交付的产品，所以不要执着于试图完善它们。让他们光。如果有助于澄清意图，请引用补充文档。
• 任何格式都可以，提供故事答案(a)谁想要它?(b)它有什么好处?我们必须做什么(省了我细节吧)?(d)我们如何知道它何时完成?(作为一名从业者，我认为最重要的问题是“我们如何知道什么时候完成了?”如果不回答，它就会咬你。这也是"作为"公式中被省略的部分。只是说说而已。)
• 组织中的所有团队没有必要以相同的方式编写用户故事。毕竟，不同的团队做不同的工作。抵制官僚!