1

我在一家维护一些产品的软件公司工作。

我们使用“bugtracker”来管理与相关产品相关的所有任务。

我们和 Scrum 一起工作，公司的套路基本是这样的：

  1. 客户联系支持并请求解决问题或实施功能。
  2. 产品的所有者按优先级顺序对任务进行分组，并将它们引导到 Sprint。
  3. 开发人员完成任务，最终需要填写一种“变更日志”。
  4. 测试人员确保开发人员的编码正确完成并结束通话。

这是我的问题：

开发人员不喜欢填写“变更日志”，通常会忘记填写。

这是我的问题：

谁应该完成“变更日志”？开发人员和测试人员？

这个“变更日志”在每个 Sprint 结束时发送给最终客户，主要用于以非技术性的方式解释在软件中已解决或实现的内容。

然后，谁应该做呢？开发人员和测试人员？

4

2 回答 2

0

这不是一个 Scrum 问题，它读起来像一个过程问题。我是否还可以说 Scrum 并不适合维护工作，在这种情况下您可能会更好地尝试看板？

也就是说，尽管 Scrum 不包含对变更日志工件的任何引用，但我想说确保更新变更日志是团队的责任（而不是任何一个开发人员或测试人员）。作为提醒，团队可能需要考虑将此要求添加到他们的“完成定义”中。

希望有帮助。

于 2013-02-05T11:59:01.853 回答
0

找出最适合您的团队的方法。开发人员/测试人员直接与客户交流似乎很奇怪。我希望这是最初与客户联系的支持团队的角色。

正如您在评论中所说，他们可能会拖拖拉拉，因为这不是他们擅长的，因此他们不喜欢这样做。

有几件事可以尝试：

  • 把每个人都放在一个房间里，然后说出来（如果人太多就行不通了——也许只是让部门负责人）。我们需要这个来完成，它没有完成，为什么不呢？谁知道如何解决这个问题？
  • 我不确定为什么客户甚至需要描述更改的内容 - 我正在描绘“我们如何修复它”的情况。谁在乎如何，只是它是固定的。我的意思是重新检查是否有必要 - 也许有一个更合适的替代品。
  • 尝试自动化它。如果客户确实需要手持说明如何修复它并且他们真正需要知道的是它已修复，也许您可​​以自动化您的错误跟踪工具，以便在该票关闭时通知报告问题的客户- 或者更确切地说，当它为客户部署并明显固定时。

最大的建议是不要让这成为指责游戏的情况。你的同事不是不讲道理的人——如果他们有抵抗力，那么也许这个过程太繁重了。对替代解决方案持开放态度。

仅供参考 - 这种问题可能会在 pm.stackexchange.com 上做得更好

于 2013-02-08T03:00:09.560 回答