There are two clear phases for most projects. Before you deliver/ship, and after you deliver/ship.
For a new project everything should be marked as a Task BEFORE you deliver the first time.
Once you have delivered something then all subsequent works items can be marked accordingly:
New functionality should marked as New Feature
Enhancements/improvements to existing functionality should marked as Enhancements
Bug reports obviously marked as Bugs
Tasks can still be created but usually site before New Features, Enhancements, Bugs as sub-tasks
One tool should be used to manage all item types with appropriate workflow. Using different tools makes no sense as only data fields and workflow vary by item type (e.g. Bug, Requirement, Enhancement).
First of all, this may depend on the organization you live in and the tool you are using. Normally, your organization should define the glossary for your development process, and as part of that, the meaning of the different types of issue or work items.
We in our company use 3 different tools depending on the type of problem to tackle:
Polarion for doing requirements engineering and the whole following workflow.
JIRA for doing mostly issue tracking with a lots of possibilites to tune it.
Trac for mostly developing projects with a more simple workflow.
The definitions we gave the different work item types (Polarion) or issues (JIRA) are:
Defect: Denotes an error found in a test. Typical relation is child-of Test.
Issue: Something that may be a defect, a change request or something different later. Has to be qualified first, and then will be solved by creating a defect or change request from it.
Change request: Defines some change to application demanded by a customer, has normally implications to scope, budget, ... Will often be resolved by creating requirements from it, which will then be specified by use cases, ...
Requirement: User, system or technical requirement, that will be implemented by a use case later.
Use case: Specification of a functionality that the application has to fulfill.
Task: Task of a person to do on some of the result oriented work items or issues.
We cluster all work item types in 2 sections: - result oriented: the work item itself stands for the result. Types are: requirement, use case, component, test case, change request, ... - process oriented: the work items stands for the action to do. Types are: defect, issue, task, ...
So to summarize it:
Find your glossary that helps you.
Define the scope you will address and include only work item types or issues that fall into that scope.
Define a workflow for all of them, and keep that as simple as possible.
Define the allowed relations between work item types, that help you track the solution.
I've been considering this for my workplace as well. I've been thinking that it's better to have types and sub-types, customized to the "phase" of the artifact, instead of a long list of top-level issue types:
Development (i.e. pre-production)
Work element: A collection of work elements and tasks; a work element can be categorized as a feature, phase, or deliverable
Task: A unit of work which can be reasonably estimated at not-more then 80 hours effort and assigned to a specific individual; can be categorized as development, analysis, documentation or non-software task
Defect: A mistake by the programmer
Production
Incident: A disruption to expected service; can have a many-to-one relationship with defects
Defect: Something which is preventing the artifact from achieving its intended purpose (two sub-types)
Implementation defect: artifact does not conform to specifications
Requirement defect: specifications do not produce desired outcome
Change request: A change to the specifications
New feature: An increase of the scope of the software
Enhancement: An improvement to the quality of the software (performance etc.)
Adaptive: A change due to external environmental conditions (ex. changing databases etc.)
Request for service: A request for previously agreed service to be provided (password reset etc.)
Non-software task: An action item that makes no change to the software (documentation, user training, data migration etc.)
This seems to map fairly well for the needs of various departments while remaining pretty simple. For example, we would record all defects, NST's and adaptive work as operational expenses, while new features and enhancements would be capital expenditures. Since we've been trying to use Semantic Versioning, defects, enhancements and adaptive maintenance would be typically be considered patch software changes, NST's wouldn't show up at all, and new features would be minor software changes (major is reserved for a change that prevents backwards compatibility or a total rewrite). Some of the breakdowns (ex. implementation vs. requirement defects) are useful when gathering statistics.
Change proposals I think are best handled outside of this scope (they typically require analysis, then requirements which eventually create the specifications that do make it into this), though release & deployment scheduling should integrate quite well. Ideally the change order would be referenced if an item is modified.
发布评论
评论（3）
大多数项目都有两个明确的阶段。在您交付/发货之前，以及在您交付/发货之后。
对于新项目，在第一次交付之前，应将所有内容标记为任务。
一旦交付某些内容，则可以相应地标记所有后续工作项目：
应该使用一种工具来管理所有项目类型适当的工作流程。使用不同的工具没有任何意义，因为只有数据字段和工作流程因项目类型（例如错误、要求、增强）而异。
我希望这对您有所帮助。
There are two clear phases for most projects. Before you deliver/ship, and after you deliver/ship.
For a new project everything should be marked as a Task BEFORE you deliver the first time.
Once you have delivered something then all subsequent works items can be marked accordingly:
One tool should be used to manage all item types with appropriate workflow. Using different tools makes no sense as only data fields and workflow vary by item type (e.g. Bug, Requirement, Enhancement).
I hope this helps you.
首先，这可能取决于您所在的组织和您正在使用的工具。通常，您的组织应该为您的开发过程定义术语表，并作为其中的一部分，定义不同类型问题或工作项的含义。
我们公司根据要解决的问题类型使用 3 种不同的工具：
我们给不同工作项类型 (Polarion) 或问题 (JIRA) 的定义是：
我们将所有工作项类型分为 2 个部分：
- 以结果为导向：工作项本身就代表结果。类型有：需求、用例、组件、测试用例、变更请求……
- 面向流程：工作项代表要执行的操作。类型有：缺陷、问题、任务……
总结一下：
First of all, this may depend on the organization you live in and the tool you are using. Normally, your organization should define the glossary for your development process, and as part of that, the meaning of the different types of issue or work items.
We in our company use 3 different tools depending on the type of problem to tackle:
The definitions we gave the different work item types (Polarion) or issues (JIRA) are:
We cluster all work item types in 2 sections:
- result oriented: the work item itself stands for the result. Types are: requirement, use case, component, test case, change request, ...
- process oriented: the work items stands for the action to do. Types are: defect, issue, task, ...
So to summarize it:
我也一直在为我的工作场所考虑这一点。我一直认为最好是根据工件的“阶段”定制类型和子类型，而不是一长串顶级问题类型：
开发（即预生产）
<生产
这似乎很好地映射了各个部门的需求，同时保持相当简单。例如，我们将所有缺陷、NST 和适应性工作记录为运营支出，而新功能和增强功能将资本支出。由于我们一直在尝试使用语义版本控制，缺陷、增强功能和自适应维护通常会被视为补丁 软件更改，NST 根本不会显示，新功能将是次要 软件更改（主要保留用于防止向后兼容或完全重写的更改）。收集统计数据时，一些细分（例如实现与需求缺陷）很有用。
我认为最好在这个范围之外处理变更提案（它们通常需要分析，然后是最终创建规范的需求），尽管发布和发布是可行的。部署调度应该很好地集成。理想情况下，如果项目发生修改，将引用变更单。
I've been considering this for my workplace as well. I've been thinking that it's better to have types and sub-types, customized to the "phase" of the artifact, instead of a long list of top-level issue types:
Development (i.e. pre-production)
Production
This seems to map fairly well for the needs of various departments while remaining pretty simple. For example, we would record all defects, NST's and adaptive work as operational expenses, while new features and enhancements would be capital expenditures. Since we've been trying to use Semantic Versioning, defects, enhancements and adaptive maintenance would be typically be considered patch software changes, NST's wouldn't show up at all, and new features would be minor software changes (major is reserved for a change that prevents backwards compatibility or a total rewrite). Some of the breakdowns (ex. implementation vs. requirement defects) are useful when gathering statistics.
Change proposals I think are best handled outside of this scope (they typically require analysis, then requirements which eventually create the specifications that do make it into this), though release & deployment scheduling should integrate quite well. Ideally the change order would be referenced if an item is modified.