cc讲故事
在当今的敏捷开发方法中，有许多漂亮而简单的想法非常有效。 还有一些不是。 就像将所有需求定义为“ 用户故事”一样 。
我不喜欢这个名字。 故事是您在让孩子上床睡觉之前告诉他们的东西，而不是您用来构建复杂系统的有价值的信息。 我不喜欢大多数团队用来编写故事的格式。 而且我不喜欢他们如何使用它们。
有时您需要故事，有时您需要需求
敏捷的“规则”之一是故事必须小 -足够小以适合索引卡或便签。 它们的目的太短了，因为它们应该是占位符，提醒您在准备使用它们时与客户进行对话：
它们不是必需的。 它们不是用例。 他们甚至不是叙事。 它们比这简单得多。故事仅供参考。 它们是团队应该进行的工作的一两个简单的直线描述。
对于团队来说，这不足以实现和发布可运行的软件的细节，故事的意图也不是。 故事是占位符，用于详细讨论需求。 客户负责在团队其他成员需要时提供可用的需求详细信息。
詹姆斯·肖尔
敏捷的艺术-故事
根据迈克·科恩（Mike Cohn）在他的《 敏捷的成功》中的描述 ，短篇小说迫使团队将重点从写作功能转移到谈论功能。 团队之所以想这样做，是因为这些讨论比写下来的内容更重要。
但是，这个想法可能（而且经常是）走得太远。 当然，大多数人已经了解到不可能为所有前期工作编写正确，完整，全面的需求规范。 但是很多时候，将自己限制为一行或两行占位符对于您希望稍后填充的内容没有任何意义。
有些需求不是客户意图的高级表达，可以在对话中充实并进行演示以验证您的想法是正确的。 它们是需要逐行遵循的规范，或者是规则或公差，这些规范或公差以对您早日了解的重要和必要的方式约束您的设计和实现。
某些要求，特别是在技术或科学领域，从根本上很难理解，而且出错的代价也很高。 您希望获得尽可能多的信息，因此开发人员（包括客户）有机会研究问题并思考问题，共享想法，提出问题并获得答案，探索选择方案并提出实验和方案。 在开始尝试解决错误的问题之前，您需要并且需要将这些内容记下来，并尽可能直截了当。
还有其他时候，您已经进行了对话–您被授予了一个简短的窗口，与非常了解他们需要什么以及为什么的人在一起。 您可能不会再与相同的人获得相同的机会。 因此，最好在您还记得他们说什么的时候写下来。
简短的摘要故事（稍后进行详细介绍）或详细的要求尽早制定-不同的问题和不同的情况需要不同的方法。
Connextra模板：作为{用户类型}，我想要{something}…
故事开始时是开发团队需要完成的简单，自由形式的工作描述，例如“仓库库存报告”。 但是现在， Role-Feature-Reason模板（也称为Connextra模板/格式） （因为有人在2001年提出了该模板/格式 ）是告诉我们都应该编写用户需求的方式。
作为{用户类型}，我想{做某事}，以便{原因}
这怎么发生的？ 又为什么呢？
据迈克·科恩（Mike Cohn）（帮助普及该模板的人是他的书和课程）所述，有一些理由应该以这种方式编写故事 ：
原因1重要的事情，我很想说神奇的事情发生在第一人称需求中……
原因2
具有故事的结构实际上有助于产品所有者确定优先级。 如果产品积压是一堆杂乱的事情，例如：
- 修复异常处理
- 让用户预订
- 用户想看照片
- 显示房间大小选项
…依此类推，产品负责人必须更加努力地了解该功能是什么，谁从中受益以及功能的价值。
原因3
我听到一个论点，认为使用此模板编写故事实际上会抑制故事的信息内容，因为文本中包含很多样板。 如果您发现的话是正确的，则请在演示故事的方式中对其进行更正……[这不是使用此模板的原因，但如果使用它，则是解决方法}。
试图使每个需求都适合此模板会带来一系列问题：
用户故事格式笨拙且笨拙。 “作为___，我想要___，所以我可以____。” 概念很好–应该始终对“为什么”需要任务进行解释，以确保最终结果满足实际需求。 但是我见过很多口头体操，他们试图将一个简单而明显的要求变成“
“用户故事 ”证明了，尽管敏捷说了什么，但这并不总是最好的方法。塔莉亚·福禄
敏捷不起作用的6个原因
许多其他人也遇到过类似的问题：
VersionOne的Steve Ropa（“ 为什么我不喜欢用户故事模板 ”）与不了解或没有正确遵循核心敏捷思想和实践的团队合作……
但是他们擅长的是确保每个故事都以____我能________的格式表达。 无论故事是什么，他们都找到了一种将其插入模板的方法。 这就是事情开始崩溃的地方。 使故事适合模板的需求比实际故事的内容更为重要。 …模板已成为正式的大门。 当我第一次了解故事时，我对故事的理解是，它们将自然语言带回有关软件打算做什么的对话中。 如果我们仅将其替换为“故事模板”，我们该如何远离正式的“应有清单”和需求文档？
Gojko Adzic说 ，机器人遵循标准化的故事模板会导致故事“语法正确，但完全错误”：
这样的故事是假的，误导性的，只会造成伤害。 它们没有提供良好讨论或优先次序的背景。 它们无非是功能性任务分解，以不同的形式包装，以通过对花了两天时间进行一些愚蠢的认证课程的人员的审查，并为组织提供了一些假装的安慰，使它们现在实际上是敏捷的。
一切都与客户有关
我们还被告知，用户故事必须以客户为中心 ，从客户的角度出发，并始终描述客户关心的内容 。
该论点建立在两个中心思想的基础上：
- 开发团队必须始终清楚地交付客户价值 。 从项目开始，团队就应该交付客户可以看到，触摸，探索和响应的工作功能。
- 客户/产品负责人必须能够理解每个需求，这意味着每个需求都必须以他们的语言和他们关心的东西为准。 （这是敏捷开发中的“客户/产品负责人”想法有什么问题的另一个示例-一个人可以负责定义项目中完成的所有事情。）
专注于交付客户价值几乎没有余地
非功能性需求和约束 ，这对构建任何实际系统都至关重要，并且不强调开发人员团队为交付高质量系统并最大程度降低技术风险而需要做的重要设计问题和技术工作。
在开发人员应如何处理非功能性要求和约束，开发人员将技术要求隐藏在客户故事中或试图将自己的技术和体系结构要求转变为最终成为客户样式的故事方面 ，这导致了许多不必要的混乱和分歧对客户或开发人员都没有意义。
诸如安全性 ，可维护性和可支持性之类的秘密技术要求尤其是一个问题– 横切关注点对客户没有意义，而是贯穿于团队所做的所有工作的基本约束，并且他们是如何做到的，而不仅仅是在一个Sprint中完成工作。
就像使用通用模板的想法一样，将客户放在第一位的想法也很合理：将开发团队和客户紧密联系在一起的一种方法，以及一种确保为工作付费的人能够真正实现他们所要求的方法的方法对于。 但是坚持认为这是必须对每个需求进行框架化的唯一方法，这会带来不必要的问题和风险 ，并使团队的工作比原先要艰苦的。
不要为用户故事而烦恼-尽其所能
坚持认为必须以相同的方式定义每个开发团队需要做的所有工作是任意的，不必要的和错误的。 就像UML时代那样，我们得知必须通过用例来捕获需求。 任何人都记得它试图使用粘液和气泡对功能规格进行建模是多么愚蠢且毫无意义吗？
团队应使用适合自己情况的任何格式，并根据问题和情况的要求提供尽可能少的详细信息。 有时候，我宁愿使用经过仔细考虑和审查的定义明确，详细记录的规则和方案，或者是向客户展示并迭代改进的原型，而不是局限于一小部分2行用户故事，希望我能找到一个了解每个需求的人，以便在团队需要它们时填写详细信息。
在敏捷2013年大会上，杰夫·帕顿（Jeff Patton） 在关于敏捷需求和产品管理的 演讲中明确指出，故事模板是初学者应使用的工具，以学习如何提出问题。 就像初学滑雪者的“雪犁”技术一样，一旦知道自己在做什么，就可以扔掉。 他的建议是“使用您需要的任何东西来捕获需求：图片，幻灯片，笔记，验收测试”。 在同一个会议上，斯科特·安伯勒（Scott Ambler）重申“故事还不够。 它们只是一种工具，一种使用情况视图。 还有很多选择”。
不必担心故事，史诗和主题 -或主题和史诗 （敏捷社区不能全都同意主题 是什么，史诗是什么 ，无论如何都没关系）。 在需要时添加详细信息。 摆脱不必要的细节。
不要陷入罗曼·皮克勒（Roman Pichler）所说的“ Story Mania ”：
一些产品所有者和团队非常喜欢用户故事，以至于一切都表达为故事。 这要么导致一些比较奇怪的故事，要么就是捕获用户界面设计，复杂的用户交互和技术要求的故事； 或这些方面都被忽略了。像任何技术一样，用户故事编写也有其优势和局限性。 我发现特别适合捕获产品功能以及正确应用非功能需求的故事。 但是用户界面设计和复杂的用户交互可以通过其他技术更好地描述，包括设计草图，模型，场景和情节提要。 因此，可以使用其他技术来补充用户故事，而不必只使用故事。
甚至有些提出“用户故事”最初想法的人都同意， 并非所有事情都可以或应该作为故事来完成 。
以最佳方式捕获需求。 保持要求尽可能轻巧，清晰，自然。 如果您有需要处理的重要技术要求，请将其写下来，不要担心将它们扭曲到某种任意的客户故事中，因为有人告诉您，这是“要做到”的事情。敏捷”。
让我们停止讲故事并完成一些工作。
翻译自: https://www.javacodegeeks.com/2013/12/stop-telling-stories.html
cc讲故事