mardi 18 novembre 2008

Agile et CMMI c'est officiel

Blog Pictures | acobox.comDepuis le temps que l'on en parle, David Anderson avait laissé entendre que c'était à l'étude mais je ne pensais pas que ça sortirait si vite. Et oui agilistes en herbe et papys des NTIC c'est fait fait, c'est officiel !!!Le SEI dans un rapport technique intitulé CMMI® or Agile: Why Not Embrace Both!, Technical Note (CMU/SEI-2008-TN-003 clarifie la position du CMMI par rapport aux pratiques Agiles: travaillons ensemble vers un meilleur développement logiciel !!!!
Merci à
Hillel Glazer (Entinex, Inc.)
Jeff Dalton (Broadsword Solutions Corporation)
David Anderson (David J. Anderson & Associates, Inc.)
Mike Konrad
Sandy Shrum

PS : si vous voulez le retour d'Alex ou les commentaires de QualityStreet

mardi 4 novembre 2008

Flash Spécial : les Agilistes écrivent de la documentation!

Free blog image | acobox.comL'article de Scott Ambler intituléNewsflash: Agilists Write Documentation! sur Dr. Dobb's Journal remet en cause les idées reçues autour de l'Agilité:
Oui lorsqu'on est Agile on écrit de la documentation.
Oui une équipe agile modèlise.
Oui un projet agile est structuré autour d'une architecture.
Je tiens à remercier Scott Ambler et Jon Erickson (du Dr. Dobb's Journal) qui ont gracieusement accepté ma requête pour pouvoir publier cette traduction.
La voici donc :

Pour ceux qui n'ont pas un compte slideshare, vous pouvez le voir ici.

lundi 3 novembre 2008

Développeur : l'artiste du 21ème siècle

Free blog image | acobox.comVendredi soir je surfais tranquillement sur Infoq lorsque j'ai vu une présentation intitulée The Lego Hypothesis. Les lego ayant bercés mon enfance, j'ai commencé à regarder la présentation du néo-zélandais James Noble. La présentation était intéressante sur plusieurs points : tout d'abord il nous présentait la naissance de l'ingénierie logiciel en 1968, puis la structure de gros programmes dans différents langages. Ce qu'il démontre c'est que nos programmes sont structurés comme des romans. Et là je ne peux m'empêcher de penser à cette notion qui me taraude depuis longtemps sur le processus de création et cette intuition qui fait que je pense depuis longtemps qu'un bon développeur est avant tout un artiste (ou un bâtisseur de cathédrales). De nombreux articles ont été écrits à ce sujet mais là on avait une 'preuve' formelle.
Finalement quand on écrit un programme on est le 'nègre' du notre client, essayant d'écrire sa biographie avec ses histoires (d'utilisateur). Or on n'imagine pas qu'une telle écriture se fasse d'un seul jet, que l'auteur après quelques heures de discussion se mette à écrire le roman qui sera lu une seule fois juste avant la publication.
Si on poursuit la métaphore on voit bien qu'il va falloir écrire des chapitres que l'on va faire relire au fur et à mesure à notre client pour vérifier qu'on reste bien conforme à ce qu'il attend. Qui a prononcé le mot 'itérations' ? ;o).
On peut surement améliorer le parallèle mais tout ceci montre avec évidence, s'il en fallait encore, la pertinence des méthodes agiles.

jeudi 30 octobre 2008

Quittons l'esprit Chimpanzé pour les Bonobos


Hier j'ai eu la chance de participer à un webinaire: "Are Agilists the Bonobos of Software Development?" animé par Linda Rising et organisé par l'ITMPI. Ce séminaire avait été présenté à Agile 2006 et on trouve une interview qui en reprend les principaux points sur InfoQ.

Elle y compare la culture des Chimpanzés (patriarcale, avec un mâle dominant organisée autour du rapport de force) et celle des Bonobos (plus douce et plus communautaire). Elle montre ensuite comment les pratiques agiles (notamment le pair-programming) relèvent plus de la culture Bonobo alors que les systèmes hiérarchiques eux sont plus chimpanzés. Il semblerait qu'appliquer les techniques bonobo permette un meilleur flot d'informations et une meilleure confiance en soi. Éléments qui manquent pour une féminisation du développement informatique.

Une présentation bien rafraichissante en ces temps de pluie et de brouillard.

lundi 27 octobre 2008

Qui apporte la glue technique sur un projet Agile ?


Un petit billet que m'a inspiré l'article suivant:
Who plays the role of technical producer on Agile teams?.

Ce n'est pas sans rappeler la conversation que j'avais eue avec Hervé. Lorsque je lis de nombreux articles sur l'Agilité et ses corolaires je me pose souvent la question "Mais qui s'occupe de l'aspect technique de l'introduction de l'Agilité dans l'équipe ?". On a des coaches agiles, des scrum masters, ... mais qui valide que l'équipe applique correctement le TDD ? Qui vérifie la qualité du code ?
Certains me répondront surement que c'est là la responsabilité de l'équipe et j'en conviens tout à fait. Mais si l'équipe doit, en plus d'apprendre à se gérer elle-même, mettre en oeuvre des bonnes pratiques qui sont tout sauf évidentes (le tests first par exemple, l'intégration continue, les mesures de qualité de code, l'analyse statique, etc.) elle ne s'en sortira pas bien. C'était d'ailleurs la conclusion d'Hervé (et je suis bien d'accord avec lui) : il faut un leader technique, pendant du coach agile, sur les projets agiles surtout dans les premières mises en oeuvre de l'agilité par une équipe.

En bref, pour paraphraser l'article du début, avoir le meilleur groupe de musique du monde ne suffit pas, il faut aussi un bon producteur.