Test Driven Development

AmauryOrganisation d'équipe2 commentaires sur Test Driven Development

Je vous parlais récemment des tests unitaires. Je vous parlais entre autre de la difficulté d’imposer la discipline nécessaire à la réalisation de tests unitaires corrects et de leur maintien opérationnel.

Il existe une méthode de travail qui permet de forcer l’écriture des tests unitaires (tout au moins au début des développements). Il s’agit des développements guidés par les tests (ou Test Driven Development en anglais).
Cette méthode est toute simple à comprendre : Avant d’écrire un bout de code, on commence par écrire les tests qui vont vérifier la conformité du code.

Prenons l’exemple d’un code orienté objet. Imaginons que nous nous préparons à écrire une nouvelle classe.

  • On modélise l’objet, donc on connait ses méthodes publiques. On sait quelles entrées doivent produire quels résultats.
  • On écrit des tests pour vérifier les méthodes de l’objet.
  • On écrit le squelette de l’objet, avec juste les déclarations des méthodes.
  • On exécute les tests unitaires, qui tombent évidemment en échec.
  • On écrit le code de l’objet, en vérifiant que les tests passent un à un.

L’avantage avec cette manière de faire, c’est qu’au moment où le code est écrit, on est quasi-certain qu’il est conforme au comportement qu’on attend de lui. Pour peu qu’on ait pris soin de lancer régulièrement les tests unitaires au cours du développement, le code est rapide à valider.

Par contre, il va sans dire que si le TDD permet d’avoir des tests unitaires corrects pour de nouveaux développements, le problème reste entier pour l’évolution de code existant. La vigilance habituelle reste donc de mise, pour que les tests ne prennent pas la poussière. Mais il est possible de respecter cette démarche pour toutes les évolutions de code : On commence par modifier les tests unitaires existants, ou les compléter ; puis on effectue les développements qui valideront ces tests.

Mon expérience

Le TDD est ce que je qualifierais de vraie fausse bonne idée. En fait, j’ai vu plusieurs fois le même cheminement intellectuel être suivi par des équipes qui mettaient en place cette méthode :

Livre : Getting Real

AmauryOrganisation d'équipe4 commentaires sur Livre : Getting Real

Je vous ai déjà parlé de la société 37signals, au travers de ses outils Backpack et Basecamp. Je vais maintenant vous parler du livre qu’elle a publié en 2006 et qui contient toutes les règles de création et de gestion de projets web qu’elle applique en interne : Getting Real, The smarter, faster, easier way to build a successful web application.

Ce livre est disponible :

Le titre du livre est sûrement un gentil jeu de mots avec la très connue méthode Getting Things Done. Ce clin d’œil est une manière à peine déguisée de dire qu’il faut oublier toutes les méthodes existantes, faire table rase et suivre leur direction. Le livre décrit leur propre méthode agile, qui est censée s’appliquer à la réalisation d’applications web, mais peut être utilisée – au moins partiellement – pour d’autres types de projets ou d’organisations.

37signals

37signals a été fondée en 1999, exerçant une activité de web agency. Au cours des années, elle s’est fait connaître en publiant tout d’abord Basecamp, l’outil de gestion de projet utilisé en interne, puis le framework Ruby on Rails sur lequel Basecamp est basé. Depuis, 37signals a sorti plusieurs services en ligne, allant de la gestion de données jusqu’à la relation client, en passant par la messagerie de groupe. Leur blog d’entreprise, Signal vs Noise, qui parle aussi bien des outils édités par la société que de design et de développement web, est très connu et visité.

Livre : Managing Humans

AmauryOrganisation d'équipe5 commentaires sur Livre : Managing Humans

Je vais vous parler un peu d’un très bon livre, nommé Managing Humans, écrit par Michael Lopp et publié par Apress en 2007. Depuis 2002, il tient sous le pseudonyme de Rands le blog Rands in repose, dans lequel il parle de ses expériences en tant que manager d’équipes techniques. Et il en a des choses à dire, le bougre, après avoir travaillé pour Symantec et Netscape, entre autres.

Managing Humans - couverture

Le sous-titre du livre est assez explicite : « Biting and humorous tales of a software engineering manager ». Le livre est truffé d’anecdotes amusantes, de mises en situation réelles ou imaginaires, qui en font un ouvrage à part dans l’univers très fourni des livres dédiés à la gestion de projet et au management.
Personnellement, j’ai une affection particulière pour ce livre. Je l’ai acheté à sa sortie en 2007, alors que j’étais en train de créer mon entreprise. Je n’y ai pas trouvé de recette miracle, mais plein d’exemples de choses à faire ou ne pas faire ; je pense avoir évité plusieurs pièges dans la création de mon équipe grâce à ce livre.

Ne pas être un con

Le premier chapitre du livre se nomme « Don’t be a prick ». L’ensemble des 209 pages pourrait être résumé dans cette simple phrase. Ça paraît débile tellement c’est simple. Mais au cours de ma carrière, j’ai franchement rencontré tellement de personnes qui agissaient comme des gros cons, que ça mérite d’être souligné. Que ce soit par bêtise, inexpérience, indélicatesse, fainéantise, vanité ou parce qu’ils n’avaient rien à faire à ce poste, il est sidérant de voir combien de dirigeants sont inaptes à gérer les hommes et les femmes qui composent leurs équipes.

Le carquois du management

Rands utilise une métaphore assez intéressante. Il dit que nos compétences en management sont comme des flèches dans un carquois. Quand on rencontre un problème, on peut prendre la flèche appropriée, prendre un peu de recul, viser et tirer. C’est le titre qu’il a donné à la première partie du livre.

Les méthodes agiles

AmauryOrganisation d'équipe26 commentaires sur Les méthodes agiles

Cet article fait suite à ceux consacrés au cycle en V et au cycle itératif. Dans l’histoire des méthodes de gestion de projets informatiques, les méthodes agiles sont une évolution relativement récente qui tente de résoudre certains défauts des pratiques qui étaient en usage jusque-là.

Le manifeste agile

La définition de toutes les méthodes agiles est synthétisée par le Manifeste agile, qui a été rédigé en 2001 par plusieurs acteurs de ce domaine. Il distingue 4 valeurs fondamentales et 12 principes.

Les 4 valeurs

(traduction © Wikipedia et al)

  • L’interaction avec les personnes plutôt que les processus et les outils.
  • Un produit opérationnel plutôt qu’une documentation pléthorique.
  • La collaboration avec le client plutôt que la négociation de contrat.
  • La réactivité face au changement plutôt que le suivi d’un plan.
Les 12 principes

(traduction © Wikipedia et al)

  • Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  • Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  • Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
  • Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  • La méthode la plus efficace de transmettre l’information est une conversation en face à face.
  • Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  • Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Application concrète

Il existe plusieurs méthodes qui suivent l’esprit du manifeste. Elles ont chacune leurs spécificités, mais de manière globale elles œuvrent toutes dans les mêmes voies.

Les listes

AmauryOrganisation personnelle2 commentaires sur Les listes

Les listes constituent le « niveau zéro » de l’organisation. Quand j’utilise cette expression, ce n’est pas pour dire que les listes ne servent à rien, mais bien qu’elles sont la base de toute organisation, qu’elle soit personnelle ou collective. Vous ne pouvez pas espérer mettre en place une méthode de travail complète si vous n’êtes pas capable de gérer une simple liste de chose à faire.

Je vais détailler 3 types de listes : les listes de choses à faire (todo-list), les listes de bugs (buglist) et les listes de choses à vérifier (checklist).

Todo-list

Il s’agit du plus évident. Tout le monde, un jour ou l’autre, a noté quelque part une liste de choses à ne pas oublier ou de courses à acheter. Le premier pas en direction d’une organisation personnelle efficace est la tenue d’une liste de tâches. À chacun de faire de la manière qui lui semble la plus confortable, et en la matière il existe une quasi-infinité de recettes : utiliser un cahier ou un bloc-notes qu’on peut emmener partout avec soi, tout noter sur des post-it qu’on collera dans une pochette ou un classeur, utiliser la todo-list intégrée à notre logiciel de messagerie électronique, éditer des fichiers bureautiques (traitement de texte ou tableur), utiliser un wiki ou un système dédié à la tenue de todo-list.

Dans le cadre professionnel, il faut dissocier 2 types de todo-list :

  • Les listes de tâches que chaque employé doit tenir, et qui lui permettent de ne pas perdre le fil du travail qu’il a à réaliser. On est alors complètement dans le cas d’une liste que chacun est libre de tenir de la manière qui lui convient le mieux.
  • Les listes de tâches relatives à chaque projet. Celles-ci doivent être visibles par toutes les personnes ayant un rapport avec le projet. Il est important de savoir où le projet en est de manière globale ; c’est motivant pour tous les intervenants, mais c’est aussi nécessaire aux managers pour effectuer un suivi de l’avancement du projet. Il faut que les managers puissent modifier la liste de tâches, et que les personnes à qui elles sont assignées puissent indiquer la progression du travail.

De la modélisation à la réalité

AmauryOrganisation personnelleLaissez un commentaire sur De la modélisation à la réalité

La gestion de projet – et l’organisation en général – est une discipline très intéressante. On rencontre rarement deux fois la même situation. Entre les clients, les demandes fonctionnelles, les ressources disponibles, le facteur humain… les variables sont trop nombreuses. Et pourtant, on continue à chercher à modéliser les flux d’information en entreprise, on tente d’améliorer sans cesse la manière dont les projets naissent et vivent, on espère secrètement trouver la formule miracle qui fonctionnera à tous les coups et qui nous permettra de gérer les choses de manière optimale dans toutes les conditions.

Mais entre nous, franchement, on sait que ce n’est pas possible, hein ? Eh bien… c’est ce qu’on va voir.

Un modèle ?

D’après le dictionnaire, un modèle est une « représentation théorique d’un système d’éléments et de relations plus ou moins complexes ». Si la définition vous intéresse, vous pouvez toujours aller lire l’article consacré à la théorie des modèles sur Wikipédia. Un exemple : En électronique, on utilise des modèles mathématiques pour simuler le comportement de composants ; ces modèles ne sont pas « vrais » dans la mesure où ces composants ont une réponse différente de celle du modèle, mais cela permet à la fois de simplifier les simulations et de savoir vers quoi doit tendre le fonctionnement des composants réels.