Now we have hierarchy in our Work Item, we can take things to another level. The Hierarchy implies a relation between these Work Items, so it is natural to think that when one’s is evolving, it impacts its surroundings.
For instance, you have a Change Request that has three child Tasks:
- The Request becomes Active when at least one of the tasks turns to Active.
- The Request will becomes Resolved when all the Tasks will be Closed.
- The Request will be Closed when everything will be integrated, tested and validated by the testing team.
What is important here is that the Change Request is assigned to the Team Leader of the evolution to realize, each Task are assigned to developers. When a developer starts working on a Task, he switches its state from Proposed to Active. This field change will trigger an alert that will result in the activation of the owner Change Request, and the Team Leader will get an email to inform him that the Change Request is finally starting (because one of his Work Items was changed by someone else)!
This is just a simple example of what we can do, but we can imagine things more complicated, that would be real time saver for team management and communication.
The "Models" we’ve implemented so far are:
Project Management
The project management model ensures the synchronization between the states of the Change Request and Bug Work Items. A Change Request can contains zero or many Change Requests or Bugs. A whole project can be organized is a hierarchical way, and you know easily what is still planned, in progress, realized, closed, and that at a macro or micro level!
Synchronization rules are simple:
-
A parent is Proposed if all its children are Proposed.
-
A parent is Active if at least one of the children is Active.
-
A parent is Resolved if all its children are Resolved.
-
A parent is Closed when all its children are Closed.
Change Request
This model is made of a Change Request that contains one or many Tasks. The rules are:
-
The Change Request becomes active when at least one of its children Task becomes Active.
-
It turns to Resolved when all the Tasks are Closed.
-
It turns back to Active at least one Task was reactivated because of a test that failed.
-
It turns to Closed if all validation and tests was successfully accomplished.
Bug
This model has two cases:
a) A simple bug, it will contain one child Task that will be assigned to the developer.
b) A complex bug, it will contain a Change Request using the "Change Request" model to develop the fix.
The first case follows the same logic than the "Change Request" model, but with only one child Task. The second case is an instance of the "Change Request" model.
Task development
Code reviews are a must for us, and for a given category of developers we want to validate the code before it is checked-in. This model takes care of that. The Task Work Item has a child Review Work Item in a Proposed state. When the developer has finished its code, he switches the state of the Task from Active to Review Pending. This state transition will activate the Review, and the code reviewer will be aware it’s time to make it! If the review failed, the Work Item will turn back to Proposed, putting automatically the Task in Active state. If the review succeeds, the code reviewer will pass the Review Closed, which will automatically set the Task’s state to Pending Check-in (a developer can’t set this state). The developer then will be able (thanks to a check-in policy) to check his code in, and the Task will turn to Closed.
These descriptions of models are a simplification of what we’re really doing right now.
Things were tricky to design at first, but once the main models with the main cases were done, the implementation went smoothly, and the day-to-day utilization is now really intuitive.
Profiles
