Versioning Scheme

There are various scheme for handling version number. But so far I haven't really encountered anything meaningful in any of the schemes. several days ago I encountered scheme which I really liked.

The scheme is a variant of Change Significance and is specifically aimed for API libraries, that is while I'm sure it can be extended to regular products, its basic semantics is for aimed for API's libraries.

and the semantics goes like this (using a four digit sequence):

• a change in the first number means the API has changed in a breaking manner.
• a change in the second number means there were additions to the API
• and a change in the third number means an that the internal behavior
• Last number is a sequential build number.

Let take for example NUnit, if NUnit will adopt this scheme. When upgrading from lets say 2.4.0 to 3.0.0, I would expect that some of my existing tests will need to be updated to reflect the changes. When upgrading from 2.4.0 to 2.5.0, I would expect to see some new abilities reflected in new API's (but my existing tests should still stay valid). And last, when updating from 2.5.0 to 2.5.1 there would be some internal changes in behavior that shouldn't affect me at all.

I really liked this one when I heard it, what do you think?

Read more »

Posted in: ALM,Random Thoughts,tips,tools

Signs of a Death March

A "Death March" project is a project which is destined to fail. The term "death march" in this context was discussed at length in Edward Yourdon's book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects.

I had the "pleasure" of leading a death march project and for me it was one of the most depressing experiences I had so far. In my case the death march was caused by the wrong decision to commit to an impossible schedule to get a funding for the project. We all knew the schedule was unrealistic but we thought that its better to get the money now and worry later. It goes against the notion of "Fail Fast" but at that time I was unaware of this notion. (Actually I've learnt about the whole death march thing only after the project was terminated).

Being inside a death march is not fun. I think that doing a death march has a huge negative effect on the people involved that usually outlast the project itself (if the team is lucky enough to survive this project). The funny thing is that I've seen companies that intentionally put their team into a death march in order to drive the team to achieve more. The logic behind that is that if you set a high enough goal and do your best to get there you will achieve more if you just aim and reach a reasonable goal. I feel that this logic is flawed on so many level that I don't know where to start.

Signs of a death March

I think that one of the biggest issue with a death march is that in many cases the participants are not even aware of doing it. In many cases people ignore the warning signs, waiting too long to take action. In that sense admitting the problem is half the solution.

Here are some signs of a death march

"Schedule is tight but if everyone works harder and things will go smoothly we can make it" - This is the first sign of trouble. The longer until the due date the more likely you are doing a death march. How many times does things goes smoothly? Isn't the team working hard now? Where did all the margins disappeared?

"We charted out most of the big things but some things are still missing" - Another sign meaning there is still work which is yet to be scheduled in. It also indicate that someone is does not even have the time to fully understand what is really necessary to get the release on time. Where will the time be taken to actually do the work? this time the closer it is to the due date the

"We don't see people working until 22:00 in fact not even until 20:00" - The project due date is in 4-6 months. Do we really expect people will work 12:00 hours a day until then? and if they do will the be effective at that for such a long period of time? 12 hours per day is not Sustainable Pace, If that's what will save the project the project is doomed.

"We are trying to cut everything that is not a must for the release" - Put differently "Its most likely we wont finish all the necessary work, I don't even want to think on the thing that are not absolutely mandatory"

"I'm really sorry, but something important came up" - The manager gives an excuse on why he cant attend the meeting which has been scheduled and accepted by him. Is it that important that it cant wait a couple of hours? or do you just have too much work as it is? and usually a stressed manager will most likely means a very stressed team.

 

And last, in most cases - you can just see in the eyes of the people involved that they lost their belief.

So what other signs have you encountered?

Read more »

Posted in: ALM,Random Thoughts,Self Improvment

Zephyr - Another Test management system

About a week ago I was approached by a guy from Zephyr company which develops

The World's Most Flexible Test Management System.

Apparently they stumbled upon this blog (which is about testing) and since they just release a new version of their software tool they thought it might be a good idea to let me review it and say a few words about it. Well since they asked so nicely, I took some time and looked into it. a moment of honesty, everything that follows is based on a very short and initial impression that I got from seeing their demo and browsing through there site. but anyway...

The Good

On the good side I must admit that on the visual side they look very good. The general look and feel of the tool are good and the ability to change skins (which I did find a little out of place) also has some added value.

2 things that I found worthy, is the inherent support for a distributed team, including an option of hosting the actual data on their servers which can be accessed through the web. The other is the extensive report system they seem to have. I was impressed both by the amount of out of the box reports, and by the technique in which one can dive deep from one report to another getting more and more details on the project.

The Bad

First there's the price, 65$ per person per month seems a little too pricey for my taste. Second, it seems to me that the Zephyr system tries a little too much to be a little of everything. Besides managing tests plan and test schedule it has a built it IM system and a place to store users information (which looked to me like some sort of address book). Last I didn't see any place for customizing Zephyr, it might be there but I couldn't see it mentioned anywhere.

And the Irrelevant

The really sad news for me was that yet again the Zephyr tool is clearly an "old school" product. It reflects no Agile concept whatsoever, on the contrary it generally encourage a command and control kind of system. It is build around a lead which defines the work and assign task to all other testers, the tasks are then put on a timeline (which looks a lot like a GANTT chart to me). If you ever thought about managing a testing using Agile concepts this tool is not for you.

In short Not that I have anything against the tool, but if you approach a blogger which is run by an AGILE consultant, do try to at least look a bit agile. Asking him to review a "waterfoolish" tool can be a bit out of context.

Read more »

Posted in: ALM,Test management,tools