功能软件需求规范（FSRS）和敏捷开发[关闭]

Question

我正在学习如何使用敏捷方法领导一组开发人员参与 RoR 项目。我在网上找到了一些工具，例如 VersionOne 或 PivotalTracker，它们可以帮助您创建迭代、积压、故事等，因此您可以将工作与前端和后端分开，并使您的开发人员完全专注于特定任务。

我的问题是关于在您开始使用此敏捷工具、创建故事和迭代以及您的开发人员开始使其在每个工具上成长之前的步骤。我的疑惑是关于技术、功能和非功能软件需求规范的步骤，所以当你弄清楚之后，你就可以开始写故事了：

http://en.wikipedia.org/wiki/Non-functional_requirement。

是否有工具可以指导您如何成功地将网络应用（或移动应用）的想法转换为故事/迭代列表？某种状态、特征或功能（及其关系）的可视化表示，您可以在其中指定功能、非功能和技术规范，然后您可以创建故事？

非常感谢您提前付出的时间和耐心。

Answer 1

你必须在这里改变你的思维过程。

用户故事是最终用户的日常或商业语言中的一个或多个句子，描述了用户想要实现的目标 .例如

作为前台代表，我想订房间 快速预订。

如你所见

1. 从用户/角色（前台代表）的角度来看
2. 以目标为导向（快速预订房间）

但它们缺乏诸如各种流程（支付等）、验收标准、非功能性需求特定的细节（例如故事中的快速意味着什么？）。 您创建子故事以提供更多详细信息。

什么才是好故事？

投资：独立，N可谈判，V值得，E可估计的，S购物中心，T稳定的

---

是否有工具可以指导您如何成功地将网络应用（或移动应用）的想法转化为故事/迭代列表？

Rally 和 JIRA 等工具可让您组织故事、子故事、冲刺/迭代等。

某种状态、特性或功能（及其关系）的可视化表示，您可以在其中指定功能、非功能和技术规范，然后您就可以创建故事？

这些工具提供了丰富的文本编辑器来帮助我们编写故事。有时你有一个不适合作为故事的要求

• 用例
• 用户界面指南
• 业务规则列表等

那就写点别的吧。像 JIRA 这样的工具可以提供附件。

然后你就可以创作故事了吗？

** 故事应该是应该发生的第一个活动。这就是重点。这不是事后的想法。故事是迫使您从用户和目标的角度思考的方式，因此您正在编写软件来满足用户目标。 **

故事代表需求，而不是记录它们。 - 雷切尔 戴维斯

---

敏捷方法通过持续重构鼓励足够的架构。

sprint 交付团队通常包括所有必要的利益相关者，例如业务分析师、测试人员、架构师、dba、开发人员。他们共同负责完成故事/冲刺，并且在春季结束时，您将拥有一个生产就绪的可部署应用程序。想法是逐步添加功能。

正如您从团队组成架构师/主管中看到的那样，每个 sprint 也都参与其中。在团队的帮助下，他将为当前冲刺/迭代中的故事进行架构和设计（Just enough architecture，Emergent Design）。他们为第一个 sprint 选择的故事要么是高风险的，要么是具有重要架构意义的。

在设计方面，主要是集思广益，并以纸或黑板为基础。想法是尽可能使用代码作为参考文档，并通过结对编程等方式在团队中建立集体知识。

因此，您最终不会得到质量差的软件。实际上，您将拥有可以执行故事的最少代码库（您不是为将来的需求积累代码库，也不是很高兴拥有功能）。在某处我读到，只有 40% 的构建功能都被客户使用。