解释产品待办事项与任务之间的区别

我已经遇到过几次挑战，希望有人可以提供一些参考，培训或建议，以帮助您解释产品待办事项与TFS中的任务之间的区别。

我了解并已经说明，产品待办事项是“什么”，任务是“如何”。我还解释了PBI是要求，而Task是如何满足要求。

当我解释这一点时，我反复遇到空白的凝视和头部抓挠。看来我所解释的软件工程师无法区分。对他们来说都是一样的。

我相信我的另一个挑战是，我无法有效地说明为什么区分这一点很重要。

“产品积压项目”确实是What，需要构建的功能。该任务描述了到达那里需要采取的步骤。

许多团队不习惯分解为任务，他们只是按照规范的要求进行构建。对于这些人来说，很难将他们视为两个独立的事物。

也许一个简单的轶事会有所帮助：

请参阅产品待办事项作为假期购物清单上的物品。也许是“帐篷”，“钓鱼竿”，“准备旅行的汽车”。

“帐篷”项目的任务是“描述帐篷要求”，“在线比较帐篷”，“从有户外经验的朋友那里获得建议”，“去户外商店”，“购买帐篷”，“在后院安装帐篷以验证完整性”，“旅行包装帐篷”

钓鱼竿的任务非常相似，但是“准备汽车旅行”的任务可能非常不同：“检查所需路线上各州/国家的要求”，“购买安全背心”，“替换急救中过期的物品”套件”，“检查备用轮胎”，“与车库预约安排以检查引擎”，“去车库接受引擎检查”，“去国家机构购买公路通行证”，“检查汽车保险”

这清楚地将产品所有者想要的东西与他们需要做什么的问题分开了。除非产品所有者当然已经分解为产品待办事项列表上的可操作项目，否则您还需要与他们进行交谈。

正如我所说，对于许多开发人员来说，他们认为自己已经掌握了足够的信息并且知道该怎么做，他们不想将“将什么分解为怎样”的步骤进行分解，他们一到达那里就可以到达那里。当您开始与他们讨论跟踪冲刺进度，改进估算，跟踪在冲刺计划中遗忘的工作以及其他与专业改进有关的项目时，请他们和他们的团队如何知道他们可以在哪里改进以及如何改进他们知道他们真的完成了。当他们能提出一个无需创建任务就能工作的系统并且可以正常工作时，那很好，但是实际可行的机会很小。

在尝试使用TFS和敏捷工具之前，您的团队需要了解所有这些工作原理。最好的方法是让它们与纸板一起工作，这在所有人的工作地板上都可见。稍后，当您对该过程有了更好的了解后，使用这些工具将有所帮助。如果不了解，这些工具将不会有太多用处，并且会遇到很多阻力。

我认为Jesse提供了一个很好的答案。我只是想尝试使其变得更好，更简单（如果可能的话）：）产品待办事项项（或用户案例，如果您愿意的话）通常是这样写的：

作为新客户，我想注册我的详细信息，以便我了解新产品的发布

在开发人员中，这可能会转换为：

1. 创建注册表
2. 将注册数据写入数据库
3. 发送电子邮件给新客户以确认他们的注册

这三个项目是任务。

希望能有所帮助。

-使其尽可能简单而不是简单（爱因斯坦）

这是我们的滚动方式：

PBI：

• 是要求即“什么”
• 是你与客户谈论的话题。
• 这也是冲刺的每日项目更新（DPU）上显示的内容。....再次是因为DPU面向客户。
• 客户将根据预算和预算进行讨论和参考。
• 可能包含一项或多项任务。
• 以业务为导向，并以客户能够理解的业务/领域风格语言进行描述。
• 用户验收测试（UAT）中经过测试并接受的内容

任务：

• 是实现PBI的一项工作（要求）
• 与您谈论的不是客户
• 没有出现在DPU上，因为您没有与客户谈论它们
• 估计，但估计已汇总到PBI中
• 是一个孩子，只有一个条件。
• 可以使用技术术语来描述（通常是）
• 内部测试并通过测试签名
• 未被客户孤立接受或测试（他们不知道它们是否存在）

当被问到时，我倾向于提供这个：

一个PBI或Story不仅仅是一个人可以解决的事情。

一项任务只能由一个人执行。