5 敏捷，瀑布和需求变化 有没有人遇到过这样的问题，即定义为“敏捷”的项目因需求变更而超支？我正在进行一个开发项目，该项目在Sprint中运行了四个星期，但是这些Sprint之间总是存在变化。那么，它仍然被定义为敏捷吗？我觉得这有点像敏捷流程-敏捷流程的要求应在冲刺开始时定义，并在冲刺结束时进行审查。我说得对吗？请让我知道您的经历。 10 agile requirements
4 如果我们采用用户故事，我如何说服我的团队不需要需求规范？ 我们计划采用用户故事，以轻量级方式而不是繁重的SRS（软件需求规范）来捕获利益相关者的“意图”。但是，似乎他们虽然了解故事的价值，但仍然希望将故事“转换”为具有所有属性，优先级，输入，输出，来源，目的地等的SRS式语言。 用户故事从一开始就“消除”了对像正式SRS这样的工件的需求，那么拥有SRS的意义何在？如果我们采用用户案例来捕获系统的功能需求，我应该如何说服我的团队（顺便说一句，他们都是非常合格的CS人才-在教育和实践上都如此），SRS将被“消除”。（也可以捕获NFR等，但这不是问题的意图）。 所以这是我的“工作流程”论点：将初始需求捕获为用户故事，然后将其详细阐述为用例（需要以较低级别进行记录，即描述与UI原型/模型的交互，并且是可交付的文章）部署）。因此，从用户故事转到用例，而不是从用户故事转到SRS到用例。 你们目前如何在工作场所中捕获用户故事（如果有的话），以及您如何建议我为存在用户故事的情况下缺少SRS辩护？ 9 agile requirements user-story requirements-management
3 使用维基来满足需求 我正在研究改善需求管理的方法。当前，我们在网站上发布了Word文档。不幸的是，（据我所知）我们无法查看从一个修订版到下一个修订版的更改。我非常希望能够做到这一点，就像使用Wiki或VCS（或两者，就像Wiki在bitbucket上一样！）。 而且，每个文档都描述了开发人员在给定的截止日期之前预期会遇到的变更。在任何地方都没有记录到的累积应用程序功能集合，因此，在尝试快速修复旧版应用程序时，有时很难区分错误和（设计不良）功能。 所以我有一个想法想要得到反馈。关于什么： 使用Wiki，以便我们可以跟踪谁更改了什么时间（主要是查看自上次查看以来是否进行了任何编辑）。 每个产品只有一个Wiki页面，而不是每个截止日期只有一个Wiki页面，以跟上产品的所有功能，而不是应实施的更改。这样，我可以查看页面的特定版本，以查看应用程序在给定时间点应执行的操作，并且可以查看 自上次发布以来对页面的更改，以在下一个截止日期之前实现要求。 Waddayathink？ 9 documentation project-management wiki requirements