Andy Hunt: Uncomfortable with Agility: What has Ten+ Years got us?

La propriété fondamentale de l’agilité est l’aptitude au changement, la capacité d’évoluer en utilisant le feedback comme moteur de cette évolution.

Nous découvrons de meilleures façon de travailler … tels sont les premiers mots du manifeste agile. Ils ne disent pas “nous connaissons”. Alors pourquoi l’agilité a si peu évolué ces 12 dernières années ? Nous restons ancrés sur XP et Scrum, peut-être un peu mâtiné de Lean…

Andrew Hunt revient sur ce que signifie être agile, et non “faire agile”. Une présentation qui retourne au coeur de l’état d’esprit agile, par l’un des auteurs du manifeste.

Note de lecture : Practices of an Agile Developer, par Venkat Subramaniam & Andrew Hunt

Note : 3 ; Le petit frère simplet du « pragmatic programmers »

Tout a-t-il été dit sur le développement agile ? Si l’on est en droit d’en douter, la lecture de ce livre nous laisse penser le contraire. Car, franchement, à la lecture de cet opuscule on ne voit rien de neuf. Donc, je suis déçu, et étonné d’être déçu en ayant constaté qu’Andrew Hunt avait cosigné ce livre ! Au-delà d’une introduction et d’une conclusion destinés à parler de la migration vers l’agilité (mais sans propos utiles, je dois dire), le texte se compose de 7 chapitres :

  • Begining agility : Donne des pistes sur le « par où commencer », et comment se comporter au sein de projets agiles.
  • Feeding agility : Aborde les points sensibles, les « accélérateurs agiles », destinés à faire passer les projets à la vitesse supérieure.
  • Delivering what users want : Aborde le point crucial de la réalisation du projet par rapport à la demande utilisateur ; comment prioriser et comment obtenir du feedback.
  • Agile feedback : Aborde spécifiquement l’aspect retour d’expérience, comment mesurer les progrès et estimer la qualité et la pertinence de ce qui est réalisé.
  • Agile coding : Traite des pratiques liées au codage. Ces pratiques se rapprochent de celles de l’extrême programming.
  • Agile debugging : Ce chapitre se focalise sur la recherche des anomalies, mais aussi sur la façon d’en garder trace et de les capitaliser.
  • Agile collaboration : Donne des indications sur les façons d’interagir au sein d’une équipe de développement, mais aussi hors de cette équipe de développement.

L’ouvrage, bien Que découpé en chapitres est essentiellement constitué d’un ensemble d’items, traités de façon similaires : tout d’abord les auteurs énoncent l’anti-pattern (illustré d’une icône représentant un diable). Il s’en suit une discussion sur le sujet pour expliquer le bien fondé d’opérer différemment. Les auteurs énoncent ensuite une contre-proposition (illustré d’une icône d’ange). L’item se termine par deux paragraphes : le « what it feels like » expose les conséquences du changement opéré, tandis que le « keeping your balance » donne les pours et contres de l’item, en mettant l’accent sur les facteurs défavorisant qui peuvent être rencontrés.

En conclusion, ce court opuscule de 170 pages n’est guère une lecture indispensable. Bien au contraire, on lui préfèrera son grand frère, le « Pragmatic Programmer ».

practices-agile-dev-pragprog

Référence complète : Practices of an Agile Developer – Venkat Subramaniam & Andrew Hunt – Pragmatic Bookshelf 2006 – ISBN : 0-9745140-8-X

Practices of an Agile Developer: Working in the Real World

http://www.goodreads.com/book/add_to_books_widget_frame/097451408X?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The Pragmatic Programmer: From journeyman to master, par Andrew Hunt & David Thomas

Note : 9 ; Think! About your work; Book of the year (ex-æquo) 2002

Pensez! Mais pensez à la façon dont vous travaillez! Tel pourrait être le credo des auteurs de ce livre. Cet ouvrage ne traite pas de processus de développement logiciel à proprement parler, il expose plutôt une façon de se comporter et d’appréhender le développement logiciel au quotidien.

L’activité de développement logiciel est-elle un travail systématique décrit par des règles rigides? A cela les auteurs répondent: non! Ils abordent d’ailleurs le travail du développeur d’avantage comme l’activité d’un artisan que comme un travail d’ingénierie. Bien loin d’être un parallèle défavorable, il faut y voir une valorisation de notre travail, quand pour chaque problème il faut chercher une solution réfléchie, pragmatique et adaptée. Certains l’auront déjà compris, c’est d’agilité dont nous parlons ici ! Publié en 2000, il ne s’agit pas là d’une adhésion tardive à un effet de mode, mais au contraire le fruit de réflexions de « véritables croyants ». D’ailleurs Hunt et Thomas sont parmi les signataires originaux de l’agile alliance.

Le livre se découpe en 8 chapitres qui regroupent au total 70 « tips » (il y a un aide mémoire avec le livre).

Chap 1 : Pragmatic philosophy. On nous enseigne ici les lignes directrices de l’agilité : le « juste assez », l’entropie du logiciel, …

Chap. 2 : Pragmatic approach. Ce chapitre traite des tactiques de réalisation : la « balle traçante » ou le langage du domaine, par exemple.

Chap. 3 : Basic tools, traite de l’environnement, outils d’édition, de build ou de génération de code. Bref, c’est pour l’usine logicielle !

Chap. 4 : Pragmatic paranoia (là, c’est pour moi) nous enseigne l’anticipation des comportements erronés.

Chap. 5 :Bend or break, traite de conception (donc de patterns) et de sa bonne mise en œuvre.

Chap. 6 : While you are coding évoque tout ce qui gravite autour de l’implémentation : les tests, le refactoring, etc…

Chap. 7 : Before the project, car il ne faut pas confondre vitesse et précipitation ! On parle ici de spécifications, mais aussi des travers qui peuvent en découler.

Chap. 8 : Pragmatic projects, évoque la dimension stratégique du projet : la gestion des tests, le cycle itératif, etc…

Ne vous y trompez pas: ce livre ne vous expose pas comment programmer. Il existe pour cela d’autres ouvrages dédiés aux langages de programmation, par exemple. Une partie (importante) du texte est toutefois dédié à des aspects de conception générale: programmation défensive, méta programmation, architecture MVC.

Mais pour moi l’intérêt principal du livre n’est pas là. Son intérêt principal est de nous montrer que la responsabilité d’un ingénieur de développement ne se limite pas à écrire du code. Notre responsabilité est de livrer un développement dont nous pouvons être fiers, de qualité et répondant aux réels besoins utilisateur. Un travail que nous pourrions même signer: fruit d’une élaboration sérieuse, robuste, bien écrit et convenablement documenté. Un travail professionnel, réalisé par un vrai professionnel, un “pragmatic programmer”.

Ai-je oublié de vous dire que je recommande fort chaudement cet excellent ouvrage ? Mais notez au passage le vocabulaire plutôt riche employé dans le texte, qui peut en rendre la lecture légèrement difficile.

pragmatic-programmer

Référence complète : The Pragmatic Programmer: From journeyman to master – Andrew Hunt & David Thomas – Addison Wesley 2000 – ISBN: 0-201-61622-X

The Pragmatic Programmer: From Journeyman to Master

http://www.goodreads.com/book/add_to_books_widget_frame/020161622X?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on