代码之家 › 专栏 › 技术社区 › cd491415

我们如何在敏捷中收集和记录非功能性需求

requirements agile

-1

cd491415 · 技术社区 · 7 年前

我知道在瀑布中,它们是在SDLC的早期阶段收集和记录的,我相信是第一阶段。因此,在开发和测试甚至开始之前,都会捕获和记录它们。

如果我理解正确的话,用户故事应该用可接受的标准来编写,这些标准可以捕获非功能性需求。但在敏捷中,我们选择项目,创建项目,然后马上开始工作。

1 回复 | 直到 7 年前

1

2

Daniel 7 年前

首先,为了回答您的问题,我必须清楚,没有任何敏捷框架或方法试图定义团队可能需要做的一切(特别是Scrum),因此添加团队认为有用的额外工件或实践没有错,只要它们不与定义的实践相矛盾。

完成的定义

done的定义包含了质量标准,这些标准应该应用于所有待办事项。通常情况下,这包括“代码的n%单元测试覆盖率”、“代码和配置更改已经过同行评审”和“所有自动回归测试已经运行并通过”。我有时会看到更广泛的非功能性需求,如“没有任何更改会导致应用程序加载时间超过X毫秒”。

产品租赁

好的,最后一个。并非所有待办事项都必须是用户情景。如果您有一个可操作的非功能性需求(设置服务器、重新配置防火墙、团队需要转换为IDE的新版本),那么没有什么可以阻止您为此创建backlog项。这不是一个用户故事,但没关系。我要提醒的是,大多数团队都会发现积压工作(backlog)中作为用户案例的项目数量与他们有效交付价值和适应沿途变化的能力之间存在关联,所以不要得意忘形。但我更希望看到一个团队在他们的待办事项中加入一个非美国的内容,而不是试图把这些内容当作用户故事,比如“作为防火墙,我想更新,所以我们不会h@XX0rD“<-我看到的真正积压的东西。

最后一点:请记住,在敏捷中,我们努力适应变化,所以不要担心第一次就让DoD或架构文档变得完美。它可以随着你的学习而改变。