Continuous Builds

Continuous Build is a very vital aspect of Agile Methodology. It helps you recover quickly and allows bugs to be discovered early. It also put focus on Continuous Integration which is a entirely different subject altogether.

The concept of Continuous build implies that the code should be checked out from the repository often and the test should be carried out frequently to ensure that the builds are stable. The interesting aspect of this is to let all stake holders know that no bugs are getting committed into the build. The purpose of Continuous Builds can be achieved only if your code has high test coverage.

Carrying this task manually can be a big pain so if you rely on tools like JUnit to provide testing automation CB can be achieved fairly easily with the help of other tools like Hudson, Continuum etc.

These tools provides lot of Metrics and information, mainly about the changes in repository (CVS / SVN etc) since the last build. Who did the commits and for what reasons. Whom to notify if the build fails etc.. And these are important business directives for any project. As you can read all quality manuals and they will say bugs point out early in the project life cycle can save big bucks later..

Hudson and Continuum are two open source software which are very light weight and can be setup for most of the projects very quickly.

Agile for Quality Assurance

Today I will talk about one of the most difficult topic faced by any Project Manager, you got it I am talking about Quality Assurance. Matrix and Number is agile are quite tricky and have to be dealt separately than a normal Project Matrix. I faced it when my company was preparing for CMMi L5 audit and the auditor didn't knew how to deal with a Agile project. He kept asking stupid questions and I kept giving him Agile answers and after rounds of audit I realize how to fix the problem. Here what you can do but before that let me explain Agile Matrix which can be really really useful to calculate.

Iteration: One iteration is a few set of days under which team will try to achieve predetermined set of goals. One iteration can be anywhere between 1 week to 4 weeks. A standard meaningful iteration will be of 2 weeks . Depending upon your overhead you can stretch or suppress the iteration.

Velocity: Velocity is a quantitative unit which is calculated in person work hour and reflect the amount of work team has either done or planned to do in one iteration.

Assuming the estimates are done by Planning Poker or any other estimation methodology when you sum up all the numbers of units for all stories you have included to finish in the current iteration you will get Estimated Velocity.

When you add up all the available man hours for the team members participating in that iteration you will get Available Velocity.

When you add up all the estimated units of work in the stories considered done (100% done and not 99% or less) you will get Actual Velocity. Now thats strange why we cannot considered the estimates of the stories which are almost done and the answer is very simple, you will not deliver a story to the client unless it is 100% done and not when it is almost done. So what you cannot deliver to the client it is not considered done.

This post will continue with further details...