敏捷故事和任务

Question

在设计后端系统时，您通常会为您的故事和任务提供什么样的粒度？

创建故事和任务的大多数示例通常以GUI应用程序为中心，故事是用户可以做的事情（例如，通过ISBN搜索书籍），每个任务都围绕启用此GUI功能。

在设计后端系统时，即一个没有用户界面但只是一堆与数据库，中间件等交谈的服务的系统，您如何提出任务和故事？

Answer 1

基本上，我会尝试将用户故事的大小保持在1到10个工作日的范围内。这让我无法将Mike Cohn称之为“Epics”或“Themes”的内容作为用户故事传递给开发人员，而另一方面则阻止我的用户故事如此具体以至于暗示解决方案（他们应该描述问题，不是应该如何解决的。）

就内容而言，我确保我的故事只包含商业价值 - 它从未描述 我应该如何满足需求，也不“需要”非用户域知识要理解。

很好的例子：作为一名内容管理员，我希望所有用户在撰写回复之前都必须登录才能拒绝他们发送垃圾邮件。

错误示例：将验证码添加到网站。

另一方面，任务是解决问题的步骤 - 它们描述了组件和组件。需要添加/修改的功能。这就是“Add Captcha”解决方案的用武之地。就尺寸而言，我尝试让每个任务的大小在每天1/2到2-3天的工作之间。

任务还包括一组适用于每个功能/要求/问题/错误的标准任务，例如：

• 文档
• 撰写测试用例
• 手动测试
• 编写自动化功能测试 等

希望这有帮助， 阿萨弗。

Answer 2

只要您拥有用户，用户故事就可以围绕用户可以做的事情。如果您为其他开发人员提供API，那么他们就是您的用户。事情将在那时变得更加技术化（即用户可以更新员工记录）

Answer 3

我将故事基于类的公共接口。对于任务粒度，我拍摄的工作时间为半天到两天。

Answer 4

用户/演员可以是系统，不一定是人。您的服务将具有API，预期输入和结果以及服务级别协议（非功能性要求）。所有这些都可以在故事卡中指定。

最重要的是，您的故事卡应指定验收标准。 Accpetance标准将有助于推动开发人员测试开发单元测试，自动功能测试和自动化性能测试。如果符合验收标准，则该卡将被产品所有者接受并批准。