Ticket Workflow - HMS-Analytical-Software/SASUnit GitHub Wiki

Ticket workflow is the process from the posting of a requirement to its fulfilment or rejection.

Every ticket workflow starts with a new ticket of ticket type requirement which will be in the ticket status open.

A project manager picks a requirement ticket with status open, assigns himself as the owner of the ticket. He is now responsible for the evaluation of the requirements of the ticket.

Ticket status is open but assigned to the project manager. The ticket is being evaluated by the project manager who has to decide whether this ticket should be implemented and when.

• Defect reports are being evaluated for reproducibility.
• Enhancement request may have to be discussed with the creator and the project team for evaluation. Discussion should be documented in the ticket. It may be necessary to delegate parts of this evaluation to a developer. In this case the procedure described in the following steps is being followed by creation and implementation of corresponding task assignments.

In the case where a defect report cannot be reproduced or will not be fixed for other reasons or if the evaluation of the enhancement request turns out negative, the project manager sets the ticket status to closed - not planned and assigns the label rejected. The ticket will not be dealt with any further.

Otherwise he assigns a milestone to the ticket (see section milestone assignment). He thereby commits himself to complete the ticket in the timeframe defined by the milestone.

The project manager creates one or more tickets with the label task for an accepted requirement. Those tickets are initially in the status open. In order to manage the implementation in a timely manner, he assigns every ticket to a developer and assigns a developer milestone to it, if necessary (see section milestone assignment).

He documents the association between the requirement ticket and the corresponding task assignment tickets as follows:

• Use the task list in the requirement ticket to link the task assigment tickets.

In the further process of development, the task manager may add or change task assignments as needed. He may also add task assignments for special actions like developer peer reviews, integration tests, performance tests and so on.

As soon as the developer gets a new task assignment (or one he has already work upon and which has been rejected by the project manager), he analyses within one working day whether he is able to complete the task timely and according to the [quality guidelines](Quality Guidelines). He either accepts the assignment or rejects it (label rejected) and documents the reasons for his decision in the ticket.

If the developer accepts the ticket, he is now responsible for the completion of the assignment in time and quality. That means that he has to execute the task and the necessary developer tests. If he realizes that this is not any more possible for any reason, he documents the reasons in the ticket, sets its label to rejected and closes the ticket with closed - not planned.

As soon as the developer is sure that he has completed the task and the necessary development tests, he sets the status to closed - completed and thereby informs the project manager of the completion of the task assignment.

The project manager is responsible for the management and quality assurance of the ongoing development process for an assigned requirement. Depending on different situations, this might include the following actions:

• As soon as a task assignment has been completed, the project manager reviews the documentation, tests and code produced by the developer and evaluates them. If he has any findings, he documents them in the task assignment ticket in order that the developer fixes the findings.
• As soon as all task assignments for the requirement have been completed, the project manager does the final integration test and review and decides whether the requirements of the creator have been met. If this is the case, he sets the status of the requirement ticket to closed - completed. Otherwise he activates further development activities.

• If a task assignment has been rejected by the developer, the project manager works this situation out and changes the assignment or assigns it to a different developer.
• If the project manager comes to the decision that the timeline of the requirement ticket cannot be met, he documents this in the requirement ticket and changes the milestone so that the owner is being informed and can intervene.
• If the creator of the requirement ticket changes or enhances the ticket, the project manager reacts and decides how to work this out by discussion this with the creator or by changing the milestones of the requirement ticket and/or the task description or development milestones of the corresponding task assignments.
• If the project manager decides that further development is not reasonable at a certain point, he stops implementation by revoking the assignment of developers to all task assignments and setting their status to open. He then discusses the situation with the creator of the requirement and acts accordingly.
• If the project manager and the creator agree that further pursuit of the requirements is not reasonable, the project manager stops implementation by revoking the assignment of developers to all task assignments, setting their label to rejected and closes the task assigments with closed - not planned. He then sets the label of the requirement also to rejected and closes the rquirement ticket with closed - not planned. The process comes to an end.

All annotations, decisions and reasons for actions are documented as comments to the corresponding ticket. All changes to requirements or tasks are documented by direct changes to the text of the corresponding ticket. The difference of the change is automatically appended as a comment.

Back to Ticket Management Guidelines.