问题跟踪：什么类型的问题（即任务，新功能）？

Question

从头开始新项目时，使用问题类型（即新功能，错误，任务）的最佳做法是什么？

示例：

• 新的发展点：任务还是新功能？
• 改进：增强任务？

辅助问题：“任务”类型可以扮演什么角色？

感谢您的回答， 阿兰

Answer 1

大多数项目有两个明确的阶段。在您交付/发货之前以及交付/发货之后。

对于新项目，所有内容都应标记为任务在您第一次交付之前。

一旦您交付了，就可以相应地标记所有后续工作项目：

• 新功能应标记为新功能
• 现有功能的增强/改进应标记为“增强功能”
• 错误报告明显标记为错误
• 仍然可以创建任务，但通常是在新功能，增强功能，错误作为子任务之前的站点

应使用一个工具来管理具有适当工作流程的所有项目类型。使用不同的工具毫无意义，因为只有数据字段和工作流程因项目类型而异（例如，Bug，要求，增强）。

我希望这会对你有所帮助。

Answer 2

首先，这可能取决于您所居住的组织以及您使用的工具。通常，您的组织应为您的开发过程定义词汇表，并作为其中一部分，定义不同类型的问题或工作项的含义。

我们公司使用3种不同的工具，具体取决于要解决的问题类型：

• 进行需求工程的Polarion以及整个后续工作流程。
• JIRA主要进行问题跟踪，并有很多可能性进行调整。
• Trac主要用于开发具有更简单工作流程的项目。

我们给出的不同工作项类型（Polarion）或问题（JIRA）的定义是：

• 缺陷：表示测试中发现的错误。典型的关系是测试的孩子。
• 问题：可能是缺陷，变更请求或稍后不同的东西。必须首先获得资格，然后通过创建缺陷或更改请求来解决。
• 变更请求：定义客户要求的应用程序的一些更改，通常会影响范围，预算，......通常会通过创建需求来解决，然后由用例指定，...... < / LI>
• 要求：用户，系统或技术要求，稍后将由用例实施。
• 用例：规范应用程序必须实现的功能。
• 任务：一个人对某些面向结果的工作项或问题的任务。

我们将所有工作项类型分为两部分：   - 结果导向：工作项本身代表结果。类型包括：需求，用例，组件，测试用例，变更请求，......   - 面向过程：工作项代表要采取的行动。类型包括：缺陷，问题，任务，......

总结一下：

• 找到可以帮助您的词汇表。
• 定义您要解决的范围，仅包括属于该范围的工作项类型或问题。
• 为所有这些工作流程定义工作流程，并尽可能简化。
• 定义工作项类型之间允许的关系，以帮助您跟踪解决方案。

Answer 3

我也一直在为我的工作场所考虑这个问题。我一直在想，最好有类型和子类型，根据＆＃34;阶段＆＃34;的工件，而不是一长串的顶级问题类型：

开发（即预生产）

• 工作要素：工作要素和任务的集合;工作元素可以归类为功能，阶段或可交付
• 任务：一个工作单元，可以在不超过80小时的工作量下合理估算并分配给特定的个人;可分为开发，分析，文档或非软件任务
• 缺陷：程序员的错误

<强>生产

• 事件：预期服务中断;可以与缺陷建立多对一的关系
• 缺陷：阻止工件达到预期目的的东西（两个子类型）
  • 实施缺陷：工件不符合规范
  • 要求缺陷：规格未产生预期结果
• 变更请求：更改规格
  • 新功能：增加软件的范围
  • 增强功能：改进软件的质量（性能等）
  • 适应性：由外部环境条件引起的变化（例如，更改数据库等）
• 服务请求：提供先前约定服务的请求（密码重置等）
• 非软件任务：不对软件进行任何更改的操作项（文档，用户培训，数据迁移等）

这似乎很好地映射了各个部门的需求，同时保持非常简单。例如，我们会记录所有缺陷，NST和自适应工作作为运营费用，而新功能和增强功能将是资本支出。由于我们一直在尝试使用Semantic Versioning，因此通常会将缺陷，增强功能和自适应维护视为 patch 软件更改，NST不会显示完全没有，新功能将是次要软件更改（主要保留用于防止向后兼容或完全重写的更改）。在收集统计数据时，一些细分（例如实施与需求缺陷）非常有用。

我认为更改提案最好在此范围之外处理（它们通常需要分析，然后需要最终创建做进入此规范的规范），尽管发布＆amp;部署调度应该很好地集成。理想情况下，如果修改了项目，则会引用变更单。