Code Unit Test First

This practise is also known by many other jargons like Test Driven Development, Test Driven Programming, Test First Design etc.

What is the underlying objective is to let you know that you need to avoid writing a single line of code till you have not written to test it. It is nothing but saying in a broader term that if the requirements are not clear the project will go down the drain. Now take this saying from your QA and apply to coding process. If you doesn't know how to test what you are coding it is actually same as saying I doesn't know what I am coding.

So if you know what you are coding you will be able to write a brief test first. And that will make your coding requirement clear which will enable you to focus on writing only what is needed.

Follow these basic steps

1) Find out what you have to do.
2) Write a UnitTest for the desired new capability. Pick the smallest increment of new capability you can think of.
3) Execute the UnitTest. If it succeeds, you're done; go back to step 1, or if you are completely finished, deliver the project.
4) Fix the immediate problem: maybe it's the fact that you didn't write the new method yet. Maybe the method doesn't quite work. Fix whatever it is. Go back to step 3.

A key aspect of this process: don't try to implement two things at a time, don't try to fix two things at a time. Just do one.

When you get this right, development turns into a very pleasant cycle of testing, seeing a simple thing to fix, fixing it, testing, getting positive feedback all the way.

Guaranteed flow. And you go so fast!

Try it, you'll like it.

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...