Bridgekeeper: “What is the velocity of an unladen swallow?â€
King Arthur: “An African or European swallow?â€
Bridgekeeper: “Huh? I don’t know that…â€
- Monty Python and the Holy Grail
One of the most important metrics of an Agile team is its velocity. (No, you don't have to give the receptionist a stopwatch and do laps around your office.) In project management terms, velocity is the amount of work that a team can complete in a specified period of time.
Bookmark/Search this post with:
Most of the agile software development methods explicitly or implicitly recommend the use of test-driven-development and generally development of the testable code. The reasons for the high testability demands are no secret. By the very definition of "agility", the agile project has to be ready and even embrace requirement and corresponding architecture changes. Every hardware engineer knows that it is easy to redesign the wired board only if all the components used are reliable and conform to the own specification. It holds true for the software world - it is easy to redesign the system only if its components are well tested.
There is little doubt that the code testability is a good thing, but how can you measure it? Is it possible to have a look at too classes and tell which one is more testable, than another? How to decide that the component is testable enough and doesn't need the further refactoring?
Score-based metric
Jay Flower proposed a score-based metric for testability.
Bookmark/Search this post with:
One of the simplest metrics that some managers are actually paying attention to is time at work, i.e. how much time or overtime each programmer spends in front of his workstation. This simplest metric might work for manufacturing-like tasks: when worker spends 50% more time at the production line, he is likely to produce 50% more goods (those typically he wouldn't be happy about it). However, the "more time – more goods" approach doesn't work for complex, intellectually intensive tasks like programming. Everyday every software developer has to write the code that never existed before. It is not just pushing the same buttons as yesterday; a programmer has to literally invent a new thing everyday. And invention needs a fresh mind.
Bookmark/Search this post with:
Measurement is fundamental to any engineering discipline and the planning of a software creation work is no different. Whenever you plan to make or renew a piece of software the most important metric as the workload size. Measure of size is important because knowing the amount of work to do and the team skills (i.e. velocity) you can easily derive the work costs and duration. Agile software development methods do strive against the overplanning and overdetalization.
Bookmark/Search this post with: