TFS -产品待办事项的生命周期-谁改变状态？

Question

我不清楚产品待办事项的工作流/生命周期应该如何工作--特别是当涉及到谁应该更新状态以及应该何时更新时。

以前，我们只在任务级别使用TFS，因此任何必须发生的事情，程序员都会为任务提交代码，将其标记为“已完成”，然后作为测试人员，我会发现它被正确地完成并标记为“完全”，或者找到一些错误或不完整的实现，并将状态返回到“要做”。

现在我们已经建立了一个由特性、PBI和Bugs以及下面的任务组成的实际结构，但是我仍然不清楚一些事情。

例如:项目经理批准PBI，并将状态从新建更改为已批准状态。它被分配给一个sprint，程序员将其标记为提交，然后在下面编写一些任务。当他们完成他们的任务时，他们会标记他们已经完成了。

我(测试人员)如何知道我可以开始测试这个PBI呢？程序员应该像做的那样标记PBI吗？然后我测试它，如果它没有通过，我把它转回提交？如果它通过了，我就这样离开它吗？(我感到困惑的是，对于任务和bug是如何完成的，这与为PBI所做的不同)。

或者，我查看任务级别并看到所有标记为已完成的任务，如果它们通过了我的测试，则将它们更改为已关闭，或者如果它们没有通过，则更改为“关闭”。然后，我只将PBI更改为一旦所有任务测试都通过，并且所有任务都标记为已关闭？(我遇到的一个问题是，有时任务是如此特定于编程，以至于我不知道如何验证如何将它从“完成”更改为“关闭”)。

Answer 1

从技术上讲，“项目经理”根本不应该参与这一过程。

与积压中的所有内容一样，PBI由Product拥有。产品负责人对积压的内容以及其他人对所述内容的理解负有责任和责任。然而，产品负责人可能不会实际做任何事情，并可以委托给团队。

所以..。产品负责人和开发团队应该是唯一更改状态或编辑待办项的人。(规模上存在警告)。

具体情况：

1. 由于开发团队负责并负责完成任务，所以当整个团队都同意他们已经满足了国防部的要求时，他们就可以把事情做好。
2. 任何人都可以在待办事项的底部添加一些东西，但是只有Scrum团队才能改变它并移动它。
3. 产品负责人批准这项工作，咬下Scrum团队的任何成员都可以代理该批准并更改状态。
4. 在做完之后不应该有一个状态。
5. 整个团队(分析人员、编码人员、测试人员、操作)都在承诺状态下处理PBI。工作项一直保持提交状态，直到完成或放弃为止。

注意:您可以通过阅读Scrum：http://www.scrumguides.org/了解更多信息。