Ward Cunningham, le père du wiki, résume ainsi la notion de dette technique :

• Négliger la conception, c’est comme emprunter de l’argent.
• Refactorer, c’est comme rembourser la dette principale.
• Développer moins rapidement à cause de la complexité, c’est comme payer des intérêts.

Laisser s’accumuler la dette technique pour répondre rapidement à un besoin fonctionnel est une pratique assez courante dans le développement logiciel.

Malheureusement, la dette qui s’accumule épuise les ressources projets, et démotive les équipes. Lorsque la dette s’est effectivement accumulée, le travail d’un architecte est alors d’investir pour rembourser la dette principale (à plus ou moins long terme), et pour éviter que le système ne s’écroule sous la dette, et sous les intérêts.

Aujourd’hui, je m’entretiens avec Marc, ingénieur qualité sur un projet d’application web de gestion piloté par Scrum.

Ingénieur qualité et Scrum ? S’agit-il d’une chimère ?

Dans les méthodologies classiques, le terme ‘ingénieur qualité’ a un sens bien précis. Les habitués de ces méthodologies ne reconnaitrons d’ailleurs peut-être pas l’ingénieur qualité qu’ils connaissaient. Quant aux utilisateurs de Scrum, ils pourront éventuellement être quelque peu choqués par ce terme.

Qu’en est-il donc ? Pour le savoir, donnons la parole à Marc.

Lors du précédent billet, nous avions mis en œuvre la réduction des stocks de spécifications, de développements, et de tests.

Construire du logiciel de façon itérative nécessite cependant une phase importante d’apprentissage. Je vous propose donc de suivre cet apprentissage au travers d’une petite histoire.

Dans l’épisode précédent, nous avions livré une première fonctionnalité après 245 jours. Et nous nous étions mis au défi de livrer cette même fonctionnalité bien plus rapidement.

Adoptons maintenant une démarche Lean, et regardons de plus près l’organisation de notre production de fonctionnalités.

Que constatons-nous au niveau de notre chaîne de production de logiciel ?

Les stocks en attente dans notre projet sont causés par le plus fondamental des gaspillages : la surproduction !

Voici l’histoire d’un projet comme les autres qui livre une fonctionnalité somme toute simple après 245 jours de délai.

Pour savoir comment on en est arrivé là, commençons par le commencement.

Les tests unitaires sont devenus (ou redevenus) des éléments essentiels du cycle de vie de construction d’une application. Mais, comment mesurer précisément si les tests unitaires couvrent bien tous les cas possibles dans une application ?

Les méthodes agiles sont-elles faites pour moi ? Cette question, les consultants Neoxia se la voient poser de manière croissante chez nos clients.