MSF for CMMI and Check-Ins

Question

 

I'm currently investigating MSF for CMMI and I'm unclear as to what work item types it is "acceptable" for a developer to check changes in against. Should there always be a Task a work item or can a developer check changes in directly against Requirements, Change Requests, Bugs, etc.? Are there any work item types that a developer should not check changes in against?

Answer 1

 

Hi William,

 

You can check-in changes against any work item. However, if you want to enforce traceability, you would want a hierarchy developed starting from a Requirement, say, of type Scenario. Then you would create your Tasks using "Add related work item", which automatically links both.

 

When you check you changes in, you can set the "Check-in Action" to Resolve or Associate. 

- For the Requirement work item I would recommend that you set it to Associate if you still plan to work against that Requirement.

- For Tasks, a best practice it trying to have each Changeset mapped to a single Task (which answers your question). Therefore you should try to close it in a single Check-in by setting the Check-in Action to Resolve. If the Task is too big it should be Split so you can keep track of your atomic changes to code.

 

The same applies for Bugs. If later you find a Bug connected to a Requirement, create a Bug linked directly to it. For associated Tasks that will implement the fixes to the Bug, link those to the Bug itself.

 

Notice that in MSF CMMI, Requirements, Bugs and Tasks all have the fields "Estimate", "Remaining Work" and "Completed Work". I personally like to track only Estimates in Requirements and Bugs, and leave the "Remaining Work" and "Completed Work" fields to be tracked only in Task. This allows you to neatly create a simple roll up report for both.

 

There are other ways of viewing this, so take my suggestions as the starting point to implement your own team practices.

 

Regards,

 

Clementino Mendonca - MSF Champion

http://blogs.msdn.com/clemmend/

 

Answer 2

Clementino,

 

Thanks, that is definitely along the lines I was thinking. So you would recommend that all check-ins are against Tasks but those tasks are linked up to the "driving force" behind the check-in?

 

William

 

Answer 3

Yes. That will allow you to link what's in production with the requirements. A typical link chain might be Production -> Build -> ChangeSets -> Tasks -> Requirements and/or Bugs.

 

As I mentioned before, there are other ways of seeing this. Kent Beck's view is that optionally "you can write small stories that eliminate the need for separate tasks. The cost of this approach is more work for the customer." (Extreme Programming Explained, 2nd ed.)

 

If you do it this way, the scenarios/stories should be small enough that you can manage metrics ("Estimate", "Remaining Work" and "Completed Work") within the Scenario or Requirement workitem itself, and you can link the ChangeSets directly to them.

 

I interpret the fields "Estimate", "Remaining Work" and "Completed Work" in a Bug work item from MSF CMMI as a rollup of the ones held by Task work items. The Bug workitem in MSF Agile does not have those fields: a Bug is just a record of an issue from which you might derive new Scenarios, or development and testing Tasks to implement the fix(es).

 

Regards,

 

Clementino Mendonca

http://blogs.msdn.com/clemmend

 

 

 

 

Answer 4

The process guidance says:

"Check in the code changes and the unit tests with the bug or development task. Checking in code changes should close the development task or resolve the bug and create a new changeset."

I believe the guidance+work item states/reasons imply that tasks are resolved when complete and closed after code review and check-in.

The add-in is incorrect and should close these tasks rather than resolve them.