敏捷用户故事的共享开发任务

Question

我的团队将在即将到来的项目中使用。敏捷工具让我按照这样的层次组织用户故事和任务：

Epic >特性>用户故事>任务/错误

假设我正在为高中生和顾问设计一个学生组织(俱乐部)管理系统。学生和顾问可以加入俱乐部，担任官员，组织活动，发送通知等。

让我们以公告功能为例：

用户故事：

• 作为一名学生，我想看看我所在的俱乐部的公告，这样我就知道时间表的变化了。
• 作为一名顾问，我想看看我所在的俱乐部的公告，这样我就知道时间表的变化了。
• 作为一名顾问，我想给我所参加的俱乐部发通知，这样我的学生就会知道时间表的变化。
• 作为一名行政长官，我想向所有的学校俱乐部发出通知，这样我就能让他们意识到日程安排上的冲突。
• 等

如果我们假设这些是写得很好的用户故事(可能不是这样)，当我的开发团队和我坐下来将这些项目分成开发任务时，我会感到困惑。我们可以用单个开发任务覆盖几个用户故事的部分内容。例如，我们有一个工具，它通过定义公告的属性为从UI到DB的所有层生成CRUD操作。因此，几个“发送”和“读取”用户故事的部分在一个开发步骤中完成。

据我所读，每个用户故事都应该独立于其他用户，这是有意义的。但是我们的每个用户故事都共享"Generate和DB“任务，因为这是我们创建基本级别UI的方法(在我们定制它之前)。我不应该为每个用户故事编写一个"Generate和DB“任务。太多冗余了。但是我不知道如何编写一个"Generate和DB“任务，这个任务必须在启动任何用户故事之前完成。

我对我们的许可制度也有类似的混淆。我们有不同的帐户类型，如“学生”、“顾问”和“管理员”，它们都可以访问公告页面，但在页面中有不同的功能(我在上面的用户故事中捕捉到了这个想法)。我们可以将权限系统编写成模块化的，以便它可以用于其他功能，但我不知道在哪里编写任务来创建“模块化权限系统”。

我想这整个用户故事让我困惑了。是的，它对于捕获系统的功能是很好的，但是当涉及到思考开发任务时，我似乎不能把我的头围绕在它上面。任何建议都会很好。

TL;DR:我为一个用户故事所做的一些编程可以在我们的项目的其他地方用于其他用户故事(权限系统等)。我如何为用户故事编写/组织任务来说明这种可能性？

Answer 1

我不应该为每个用户故事编写一个"Generate和DB“任务。太多冗余了。但是我不知道如何编写一个"Generate和DB“任务，这个任务必须在启动任何用户故事之前完成。

你没有。

你按照高级用户的需要写你的用户故事--你已经做了那么多了。

然后选择要首先处理的用户故事(特性)。此时--考虑到产品的当前状态--您将决定如何最好地实现此特性。然后，您将完成实现该功能所需的最低技术工作。然后转到下一个用户故事。

这可能会得到以下结果：

• 我们坐下来做用户故事1，并确定它需要一个数据库。因此，我们实现了数据库，然后是功能。
• 我们坐下来做用户故事2，并确定-嘿-我们已经有了数据库，所以现在我们只需要扩展UI。

或者在您的示例中，它甚至可能得到如下结果：

• 我们坐下来执行发送通知。我们构建一个带有文本框和发送按钮的UI，该按钮生成一个表单post。后端，什么都没发生。凉爽的。用户故事完成。
• 现在我们坐下来执行接收通知..。我想是时候开始对他们做点什么了。

这个过程的全部目的是阻止您试图预先设计整个程序，并允许您在软件当前的状态下，就如何实现下一件事情做出明智的决定。这与尝试在开始任何一个任务之前将所有的故事分解成技术任务是直接不相容的。

因此，您只设计解决方案，一旦你拿起故事和你的设计演变你的设计一次一个功能。一旦你开始研究一个故事，你会如何(甚至是否)记录你的技术设计，这取决于你。

如果两个开发人员同时获取两个故事，并且他们都共享技术要求，这就告诉您您不能并行地完成这些工作，所以请选择一个，让另一个开发人员做其他一些事情。

这里的目的是实现简单的解决方案，并在新的需求出现时修改您的设计。

最重要的是，记住:这不是一门科学。

Answer 2

假设您输入每个sprint时都有一个优先顺序的故事列表，并且每个故事被分解成单独的技术任务，那么所有开发人员在开始第二个最高优先级的故事之前，都应该处理优先级最高的故事的任务。因此，当您开始处理第二个优先级时，“Generate和DB”任务应该已经作为第一个故事的一部分完成了。因此，如果在sprint计划期间，您发现一个技术任务在多个层之间重复，那么将该任务归因于优先级最高的任务，这样它将首先完成。

如果您的团队习惯于在sprint开始后重新安排故事优先级，您可能会发现在每个故事中包含重复的技术任务并记录其他故事使用它的任务是有好处的。

它可能有助于进入从一份技术任务清单，而不是一份故事清单工作的心态。