Scrum敏捷项目管理

用户故事不是必需的

敏捷方法的创建也是对大量无用的需求文档(无论是文本的还是使用建模技术(如UML))的反应。但是,过去的所有值都不应在需求活动中丢弃。在他的书中“敏捷软件要求”,Dean Leffingwell解释了用户故事与用例和软件规范之间的区别。

尽管用户案例完成了以前由软件需求规范,用例等完成的大部分工作,但它们在许多微妙而关键的方式上却存在实质性差异。

  • 它们不是详细的需求规范(系统应做的事情),而是意图的可协商表达(它需要做类似的事情)。
  • 它们简短,易于阅读,并且开发人员,利益相关者和用户可以理解。
  • 它们代表可以在几天到一周的时间内开发的有价值功能的小增量。
  • 相对容易估算,因此可以快速确定实现功能的工作量
  • 它们不是装在笨拙的大型文件中,而是以列表的形式进行组织,可以在发现新信息时更轻松地进行排列和重新排列。
  • 它们在项目开始时并未详细介绍,而是在及时的基础上进行了详细说明,从而避免了过早的专一性,开发的延迟,需求清单以及对解决方案的过度约束。
  • 它们几乎不需要维护,也可以在实施后安全丢弃。
  • 用户故事以及此后快速创建的代码用作文档的输入,然后也逐步进行开发。

资源: 敏捷软件要求, Dean Leffingwell, Addison-Wesley

Scrum用户故事

在敏捷采用历史的最初阶段,一些团队虽然可以完全放弃过去的实践,例如书面要求或系统文档,但会误读“工作软件胜于完整的文档” statement of the 敏捷宣言。在他们看来,用户故事和工作软件应该是唯一产生的工件。这种态度可以在短期内加快软件开发过程,但从长远来看也有一些缺点。

用户故事不是目标,而是可以用来开始与产品所有者和用户进行对话的工具。用户故事的初始简单格式–作为(角色),我想要(某物)以便(收益)–应该用其他信息扩展,例如测试接受标准或非功能性要求。编写良好的工作软件可以被认为是必需软件,但缺乏一些长期维护的关键信息,例如性能预期。 用户案例和其他格式,例如用例 或BDD补充技术,应用于完整表达软件要求和规范。

1对用户故事的评论不是必需的

  1. 要记住的一个关键点是,用户故事反映了对目标系统的期望(问题空间),而系统需求则反映了系统供应商对未来系统的参与度(解决方案空间)。就目标而言,这显然是不同的。

评论被关闭。