Thanks to Jeremy D. Miller I just discovered a place that is worth a web surf: Process, People, and Pods. Fred George started to blog less than a month ago and, in a few articles, he described the very nature of agile software development.
From agility inner secret to encounters of the third kind (of developers) and path to development wisdom, we go through all what we would like to tell about our jobs if we knew the words for that.

Oh, and did I tell you about the pods? You should really read those ones too!

XP Day France, manifestation consacrée à XP et à l'agilité, va voir sa 2ème édition se dérouler les 2 et 3 mai prochains.

Pour diverses raisons personnelles, je n'y serai pas mais je relaie ici l'information car, suite à ma participation au 2ème SIGMA Toulouse, je suis de plus en plus convaincu que de tels évènements auraient intérêt à se multiplier si les professionnels du logiciels ne veulent pas rester englués dans des approches datant d'une époque révolue.

Je suggère donc à tous ceux qui ont la possibilité de s'y rendre, qu'ils soient chefs de projet, manager ou simple développeur de ne pas manquer le rendez-vous. Ils auront une occasion unique de dialoguer avec des personnes qui peuvent vraiment leur apporter une vision différente et efficace d'envisager leur pratique professionnelle.

Un excellent billet de Claude Aubry sur les notions de "Maîtrise d'ouvrage" et "Maîtrise d'oeuvre" dans un monde agile me donne l'occasion de parler d'un syndrome assez fréquent dans le monde du développement logiciel : celui de l'emprunt abusif à d'autres disciplines.

Wikipédia l'explique très bien : MOA et MOE sont des termes empruntés au secteur des Travaux publics.

Alors, pourquoi ont-ils débarqués dans le logiciel ?

Hier, je parlais de l'article de Valtech Mag sur le chef de projet agile et de l'utilité d'une telle notion. Le hasard a fait que je lise ce soir un billet de Tom Looy sur le DDR : "Développement Dirigé par la Responsabilité" (ou ADD : Accountability Driven Development en version originale).
Le hasard faisant, selon la formule, toujours bien les choses, Tom Looy apporte une réponse à une des questions que je me posais : qu'est-ce qui pousse les gens à encore raisonner en termes de chef de projet là où il n'y en a plus forcément besoin ?

Ideal Day, Story Points, Load Factor, Velocity... Lots of concepts for a simple goal : predicting the amount of work that will get done for a given date. Anybody who went through this kind of measurement system probably tried to grasp its validity. Dave Churchville wonders "How long is an ideal day ?" in calendar time. Ed Gibbs rebounds on the difficulty that people have with story points when time units come more naturally.

I'm no exception. I used plain story points for a while but I recently started to trick this tool to get (I hope) a better matching between the developer estimates and the amount of work units.

I love metaphors on project management. I just read a good one by Tom Looy : "How Long is a Piece of String?". You can get an estimate by looking at it but you will get a more accurate value by measuring it with a ruler. Estimating is not an easy job, especially when it comes to predicting when a piece of software is done. In the early stages of a software project, when you can barely estimate and certainly not measure anything, fixing scope, cost and dates is impossible.

Years ago, I was appointed software project manager for the first time. Being a software developer, I intuitively knew that I should be careful with scope, cost and dates issues. I was reluctant to draw a full gannt chart too early in the project because I suspected that people would rely too heavily on it. The projects director I was reporting to told me : "This is not a way to run a project. You must list every task for the project, estimate them and put them in the chart then you will get a release date. From there you will start tracking the team progress". I complied with the order.
Any experienced project manager obviously knows what happened : as the first tasks were not completed on time, the release date started to slip.
The estimates were indeed very bad. Half of the developers had just graduated from university and relying on their estimates was the worst thing to do but the rookie project manager didn't know that.

Now imagine this project is a big black box with 3 levers...

Au cours d'une récente discussion sur xp-france au sujet du recrutement de membres d'une équipe XP a été inévitablement évoqué la question de l'utilisation de tests techniques au cours de la procédure de recrutement.
Je reviens ici sur cette pratique qui me parait essentielle car elle permet d'en dire bien plus long sur une personne que la stricte évaluation des compétences techniques.

Dans un billet récent, Claude Aubry rapporte l'existence de plusieurs articles sur l'agilité dans l'édition de juin 2006 de 'Software Test & Performance'. Un de ces articles, signé Dean Leffingwell, décrit les méthodes agiles du point de vue de l'activité de test. Cet article est de bonne qualité, ou presque. Dans la toute dernière partie, celle où l'on décrit le passage de la théorie au monde réel, il y est raconté à quel point il est impossible de tout tester dans chaque itération et que certains aspects du logiciel ne peuvent, en fin de compte, n'être testés qu'à la fin lors d'une itération dite de "durcissement".
S'il est vrai que la dernière itération peut avoir un statut particulier (le RUP parle, par exemple, de phase de transition), on peut légitimement se demander si les activités de test et de correction de bugs décrites dans cet article y ont véritablement leur place. J'ai abordé ce point en commentaire sur le billet de Claude Aubry mais, en réfléchissant un peu, je me suis dit qu'il y avait matière à creuser un peu plus le sujet.

Dave Churchville talks about things you should care about when planning bug fixes. I totally agree with his point. On one hand, it does not make sense to implement more and more features without fixing serious hazards first. This is sometimes called creeping featuritis. On the other hand, stopping any shipping till every bug is fixed can make more harm than good : a buggy software can provide more value to the user than no software at all.
I must confess that I had not fully understood the arguments in his first post. Indeed, one of the biggest misconception in software development is that bugs don't need to be prioritized just like any other feature.
That being said, it is a wise decision to let the business, the customer or the product owner, decide if the development team should implement new features or fix a few more bugs. Now the problem is : does the business have enough information to make a good decision ?