我们使用问题跟踪器来跟踪软件问题:错误,新功能,增强功能等。通常,解决问题的代码更改需要更新文档;例如用户手册,安装手册,测试程序等。通常,文档由不同的人员 - 技术作者,QA团队 - 完成,但实施者在解决时需要简要介绍所需的更改是有帮助的。问题已修复。
我想要一种轻量级的方法来鼓励这个工作流程,我想它可以在问题跟踪器中完成。我可以考虑一些选项:
当开发人员解决该错误时,克隆为针对“文档”组件的新错误,该文档总结了所需的文档更改。
在“已解决”和“已关闭”之间向工作流程添加“文档待处理”状态。
为问题添加自定义布尔字段,例如“需要更新文档”标志。
为包含建议的更新摘要的问题添加自定义文本字段。
每种选择都有利弊;例如#1将导致大量问题的创建,其中文档更新实际上只是工作流程中的又一步(#2)。另一方面,所有问题都不会有文档更新,需要通过工作流程。
您发现哪种方法可以有效跟踪这些文档更新?
答案 0 :(得分:0)
我会为文档输入一个新的更改请求,指定需要更新的内容,并将其链接到原始更改请求。这样,文档组就可以清楚地了解他们需要做什么,并避免不必要地纠缠两组的工作流程。我们还将具有多个更改的请求拆分为具有多个子级的父级,以允许我们更好地分配分配。这也有助于我们的测试小组,因为当管道发生重大变化时,它会获得源源不断的小变化而不会有大量的变化。
答案 1 :(得分:0)
为您的问题添加一个标志,指明需要进行文档更新。让您的技术作者访问您的问题跟踪系统,以便他们可以查看已标记的所有问题。如果他们不了解标记问题中提供的说明文档中需要更新的内容,他们可以与负责解决问题的人员进行交流。
这是一个流程变更,您需要让每个人都使用问题跟踪系统,以便正确完成。
答案 2 :(得分:0)
我认为您的自定义字段方法应该可以正常工作,但我们倾向于使用子问题作为运行文档工作流程的方法。基本上它对我们来说就是这样,
当开发人员处理问题并确定需要针对该问题编写新文档或现有文档需要更新(或甚至不确定)时,他修复了核心问题并创建了子问题链接到当前问题以完成文档,并附有相关说明并将其分配给正在做文档的人。
负责文件的人员解决了子问题,并通知家长问题受让人他已完成。
开发人员或PM验证一切正常并最终解决主要问题。
显然,这只是另一种做事方式,有很多优点和缺点。以前,我们过去常常让开发人员实现这个问题,对它进行评论(说“我已经修好了这个......”,重新分配给作者说“需要文档......”评论,作者会更新docs和close issue。