任务生命周期

Question

你遵循什么样的任务生命周期？在您使用的工具中，是否将任务和bug混合在一起？一个典型的任务生命周期是：

• 未开始-输入但尚未开始
• 正在进行中的工作
• 完成任务时，异常状态为：
• 等待-等待某件事
• 取消-该任务不再需要，可能是由于需求的变化。

典型的bug生命周期可以是：

• 新-新进入
• 正在进行中-正在研究
• QA -通过测试
• 客户端评审-客户端正在检查的修复程序
• 为推广做好准备-为下一个版本做好准备
• 完全-发布到生产中，但有以下例外状态：
• 暂缓
• 重复不可复制
• 按设计工作

你的生命周期是什么？

Answer 1

我喜欢保持简单：

• 待定
• 处于危险中
• 在生产中
• 完成

当我在系统或Excel电子表格中列出这些任务时，我还为这些任务提供了非常特定的可视辅助颜色，如下所示：

​

每一次会议的详细意见：

Pending用于我仍然没有处理的任务，主要是因为它需要一些外部事件来启动它，比如某些批准，或者仅仅因为我不确定我是否会成功。

In Risk是为了完成我确实开始的任务，但是它们已经接近到期日了，我离完成它还差得很远。如果我得到太多的风险任务，我开始优先考虑他们，以使他们及时完成。

In Production是我正在从事的一项常规任务。它可能没有到期日，所以它永远不会有风险，或者如果我拖延太久，我设定了一个到期日，这个任务可能会变成风险。

完全几乎是不言自明的。

Answer 2

实际上，我们为不同类型的任务安排了一个生命周期。

• 开放式
• 工作
• 拒绝
• 将被测试
• 解析
• 闭

这适用于基于ITIL (用于管理信息技术(IT)基础设施、开发和操作的一组概念和策略)的任务：

• case
• change
• 依赖项(重新组合几个更改)
• 发布(重新组合几个依赖项)

不要忘记：

• 某些任务可能需要一个辅助任务生命周期：例如，在打开、处理等之前，REL (版本)必须首先是提交的。
• 认可生命周期可能伴随着某些任务:没有认可列表，就不能提交REL (版本)。

Answer 3

我们使用一个工具来混合bug和特性请求(但是我们相应地标记每个条目，这样我们就可以看到它是bug还是请求)。

因为我们有几个部门在执行任务，所以我们有更多的状态.我们不同的生命周期状态是：

• 指定(用于产品管理)
• 复制(用于测试，检查某些东西是软件问题还是客户的错误配置)
• 开发(面向开发人员)
• 用于测试/验证(用于测试离开)
• 文档(用于文档，例如将其包括在用户手册中)
• 实现并验证了(这是我们关闭任务的时候)
• 限制/拒绝/不可再生的