2

是否有任何正式/非正式的措施来比较已完成的功能与项目的初始需求。具体来说，我的目标是在项目早期识别出任何遗漏的需求。在阅读了许多敏捷/Scrum 方法论文章和书籍之后，一种方法是在“冲刺审查”期间进行需求审查，但我想知道是否还有其他技术/工具。

谢谢，

4

4 回答 4

3

是否有任何正式/非正式的措施来比较已完成的功能与项目的初始需求。

您要查找的单词是“完成标准”。在敏捷世界中，它比单词本身具有更深层次的含义。如果发现它缺失，它通常是敏捷组织中要修复的第一件事。下面（最后）是一篇文章的链接，该文章更详细地解释了它。

大多数敏捷团队使用用户故事作为他们的“初始需求”。用户故事将是您的初始要求，足以让团队开始工作。使用的衡量标准应该是大多数团队所说的“完成标准”。每个用户故事都应该有一个完成的标准。例如。为了将积压工作称为完成，这些事情列表需要完成。在设置这个时，我们不担心它会如何完成，只担心需要做什么。

在 Sprint Review 期间，团队将展示并讲述正在工作的软件，如果它符合完成标准，PO 应批准将其正式标记为完成。

当然，有时用户故事会更改完成标准，尤其是对于新团队或项目，但这是完全正常的，因为一个好的用户故事的标志是它是可协商的。完成标准在获得团队批准后可以稍作修改。团队很少不赞成这些，除非更改导致要完成的工作的复杂性急剧增加。

所以总结一下：

初始要求，即用户故事需要有一个“什么”需要完成的标准”。如果在 Sprint 期间遗漏和发现某些内容，PO 可能会在获得团队批准后更改用户故事的完成标准。

在 Sprint 评审期间，可以根据完成标准衡量工作软件，如果达到标准，则可以将用户故事称为完成。

http://scrumalliance.org/articles/105-what-is-definition-of-done-dod

于 2010-12-29T06:39:59.923 回答
1

在敏捷方法中，需求的变化是预期的并且被认为是健康的。对变化的反应被认为比遵循计划更重要。

冲刺审查是收集反馈和新要求的地方。可用性测试也有帮助。但最有帮助的是 QA 团队和/或实际用户大量使用该软件。

如果您碰巧使用 JIRA 和 GreenHopper 来管理您的需求（作为故事），您可能会发现搜索在特定日期之后创建的故事很有帮助。找到修改后的需求会更有趣。

于 2010-12-28T16:10:48.363 回答
1

软件是否完整？显然，完整性的真正基准是某人对软件应该做什么的想法。

试图衡量一个人的心理形象最终将具有挑战性，而且没有任何正式的方法能真正做到这一点。您唯一可以衡量的是他们给您的要求。您可以查看未解决的需求，但您永远无法衡量他们没有告诉您的内容之间的差距。

我从敏捷学派得到的信息是，衡量完整性有点浪费时间——这确实是个错误的问题。

例如，使用 scrum，您可以对所有需求进行优先级积压，然后开始处理列表。当金钱/欲望耗尽时……你停下来。

于 2010-12-28T16:11:59.153 回答
0

如果您按照您的暗示走敏捷/scrum 路线，那么通常您会希望将项目分解为小的离散工作单元。一个项目包含史诗（或者是史诗），史诗包含故事，故事包含任务。（理想情况下，一项任务应该是 4-8 小时的工作。某人可以在工作日内完成的事情。）

随着每个故事的完成，应该对其进行测试和验证。这通常不适用于任务，因为在故事的其他任务完成之前，用户通常无法测试单个任务。不能期望用户测试“编写将订单持久化到数据库的方法”，而是测试“当单击此按钮时，订单将持久化到数据库，并向用户显示更新的购物车以包含重新计算税费和运费。”

此测试/验证不是由开发人员完成的。应由负责产品/项目的人员或其代表进行验证。开发人员自然会按照他或她编写的方式对其进行测试，并期望它以这种方式工作。如果需求中有任何被误解的地方，那只会再次被误解。

由于每个故事都被验证为完整，因此这是朝着项目完成迈出的离散且可衡量的一步。（可以通过它涉及的任务数量以及因此完成的总工作量来衡量。）

请记住，任何此类测量都可能从一个 sprint 到下一个 sprint 发生变化。如果高层管理人员正在寻找一个单一的路线图，其中包含从整个项目到项目结束的完整步骤，他们可能会误解敏捷开发中的一个基本概念。后面的故事还没有完全定义。根据对直接故事所做的开发（和对当前故事所做的更改），它们可能涉及比最初估计的更多或更少的工作。

尝试处理流动故事和不断变化的需求概念的一种方法是不要考虑“项目”，而只是考虑史诗和故事。这些离散单元本身应该是完全可行和可测试的（尽管有些单元当然会有其他单元作为先决条件）。改变优先级可以随意移动故事。如果优先级发生变化，则不需要“搁置”“项目”，它的故事只是移动到积压中以代替其他故事。

这个想法是，管理层正在指导你下一步去哪里，而不仅仅是给你一个目的地列表，并希望你能以正确的顺序到达它们。

从这个意义上说，一个“项目”的“完整性”几乎完全失去了意义。“完成”多少取决于拥有产品/项目的人。他们可以随意添加或删除它，轻松转移优先级等。如果他们想知道“我们什么时候到达目的地 A？” 那么这取决于他们。您已经向他们估计了在此过程中每个步骤涉及多少工作，在您提供工作时，由他们来引导他们认为到达那里的最佳方向。

于 2010-12-28T16:08:57.510 回答