La simplicité est la sophistication suprême
The Transfer Pattern
Je poursuis mon voyage dans le passé avec le “transfer pattern", écrit avec Frédéric Paulin et présenté à la conférence EuroPLOP (ne riez pas) c’est à dire l’European Pattern Language Of Program en 1998. Ce fut ma première participation à une conférence “patterns". Ce fut aussi la première présentation d’un pattern en conférence par un Français, apparemment !
Le Transfer Pattern adresse le problème de la communication asymétrique entre deux frameworks devant s’échanger des données, mais s’appuyant sur des systèmes de types différents, tout en optimisant les recopies d’objets.
Des systèmes de types différents ? Ben oui, c’est le C++ d’avant la standardisation…
Comité : Un groupe de personnes incapables de faire quoi que ce soit par elles-mêmes qui décident collectivement que rien ne peut être fait !
Note de lecture : Extreme Programming Installed par Ron Jeffries, Ann Anderson & Chet Hendrickson
Note : 8 ; La mise en pratique réelle et concrète d’un projet XP.
La littérature ne manque pas, concernant l’extrême programming. Aussi, il peut être difficile d’y faire son choix. Le mien s’est arrêté sur « Extrême Programming Installed ». En effet, celui-ci se distingue des autres ouvrages par son coté résolument pratique, intégrant les retours d’expérience au texte. Les auteurs ont en effet partagé le même projet, ils nous font profiter de l’expérience issue de leur collaboration, ainsi que de projets XP antérieurs. Il est souvent difficile de se faire une idée concrète de la mise en œuvre d’un processus décrit non par le menu, mais par ses principes. Ici, les auteurs nous livrent des extraits de dialogues, des exemples de « user stories », des « minutes » d’une séance de test-first design et des exemples de tests unitaires, entre autre choses. Autre point intéressant : le livre répond clairement à certaines questions souvent laissées sans réponses : qui écrit les jeux de tests d’acceptation, qu’en est-il des erreurs provenant non des classes elle-même, mais de la collaborations entre classes, etc.. On regrettera cependant les prises de positions parfois “élitistes”, la pire d’entre elle étant le choix d’expliquer des choses en Smalltalk, qui ne peut être guère considéré comme un standard du marché. Le XP doit sortir de sa position de dédain envers le monde extérieur !
Ce livre, relativement succinct, comme tous les volumes de la « XP series » d’Addison Wesley, avec ses 240 pages ne compte cependant pas moins de 34 chapitres ! Seuls 23 d’entre eux (175 pages) constituent la partie principale de l’ouvrage, les 11 derniers sont considérés comme des « bonus tracks ». Celles-ci rassemblent des techniques particulières alternatives qui furent marquantes au cours du projet. Pour ma part, je retiendrais « It’s Chet’s Fault », où comment couper court aux stériles recherches de coupables afin d’aller vers l’avant. Les 23 chapitres principaux ne sont pas organisés de façon chronologique comme on aurait pu s’y attendre, mais par principes et techniques d’XP, considérant les valeurs fondamentales de la méthode comme acquises.
Finalement, plus que “Extreme Programming explained”, j’ai trouvé que cet ouvrage, par son coté vécu et le retour d’expérience qu’il relate, était le mieux à même de faire comprendre l’essence de l’Extreme Programming. Le style est vivant et le propos concret, c’est tout ce dont on a besoin pour se faire une idée de la méthode. Une lecture critique est cependant nécessaire, car le propos souvent dogmatique est quand même gênant.
Référence complète : Extreme Programming Installed – Ron Jeffries, Ann Anderson & Chet Hendrickson – Addison Wesley / XP series 2001 – ISBN: 0-201-70842-6
Computer addicts never die, they just go offline.
Panorama des méthodes agiles en 2006
Je vous propose à nouveau un peu d’archéologie et de nous replonger en cette année 2006.
Cette présentation faite lorsque j’étais chez Valtech nous présente le paysage des méthodes agiles à cette époque qui nous parait déjà si éloignée…
http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=http://b.scorecardresearch.com/beacon.js?c1=7&c2=7400849&c3=1&c4=&c5=&c6=
A solid process lays the foundation for a healthy culture, one where ideas are evaluated by merit and not by job tittle.
Note de lecture : Kanban and Scrum, making the most of both – Henrik Kniberg & Mathias Skarin
Note : 7 ; L’une des meilleures références pour comprendre le Kanban, pour les praticiens de Scrum
La lecture de ce bref ouvrage avait deux objectifs pour moi : étrenner mon Kindle DX (mais je n’en parlerais pas ici) et rédiger une note de lecture sur la version française pour le French SUG.
Ouvrir un nouveau texte signé Henrik Kniberg était forcément pour moi un moment fort attendu, tellement le livre précédent était excellent. Mon premier réflexe est de voir la taille du livre : 128 pages d’une couverture à l’autre pour la version française, contre 122 pour la version originale. Ça va. Cette fois, Henrik s’est associé à Mathias Skarin, également consultant chez Crisp. La table des matières montre une répartition remarquablement symétrique : 50 pages nous viennent d’Henrik Kniberg et traitent de la comparaison de Kanban et de Scrum sur 16 chapitres. La seconde partie, rédigée par Mathias Skarin, est une étude de cas. Elle couvre également 50 pages sur 16 chapitres. On aura bien sûr compris que ces chapitres sont très courts, chacun couvrant 3 pages en moyenne !
Kanban et Scrum, s’ils peuvent être complémentaires, se distinguent fortement l’un de l’autre. Scrum se focalise sur l’itération, lui donnant un périmètre au départ et s’organisant de façon à ce que celle-ci aboutisse positivement en suivant l’avancement des tâches et en acquièrant du fedback à la fois au cours de l’itération et à sa fin. Kanban en revanche ignore pratiquement le concept d’itération, et se focalise sur le flux des tâches, sur les limites d’accumulation de celles-ci aux différents stades d’avancement et en organisant le travail des différents membres de l’équipe en fonction des goulots d’étranglements pouvant apparaître.
Note de lecture : Software Project Survival Guide, par Steve McConnell
Note : 5 ; Une approche seulement à demi itérative plutôt décevante
Steve McConnell fait partie des auteurs que je lis systématiquement, ce faisant j’ai fort peu de chances d’être déçu. C’est hélas le cas ici ! Pour « survivre » McConnell nous propose d’adopter le « stagged delivery », sorte d’approche à mi-chemin du mode itératif « time-boxed », sans toutefois lui être équivalent. Sans être à coté de la plaque, on sent que ce livre est antérieur aux publications sur les approches agiles : ici, on s’appuie beaucoup sur de la formalisation, je serais curieux de voir si l’auteur maintiendrai aujourd’hui ses positions, ou si il intègrerait ce nouvel éclairage. Au final, l’approche est assez proche du RUP, sans s’en réclamer. On reste sur sa faim.
L’ouvrage, en lui-même, est divisé en quatre sections principales :
- The survival mind-set : Cette partie nous amène à prendre con science de plusieurs facteurs: quel est notre niveau de maturité actuel ? Quelles sont les compétences nécessaires et les facteurs clés de succès des projets.
- Préparations : Cette section balaye les disciplines d’ingénierie des projets: gestion des exigences, architecture, assurance qualité, etc. L’auteur expose ici des vues particulières : utilisation intensive de prototypes dans la capture des exigences, gestion et contrôle des changements explicites via des CCBs, etc.
- Succeeding stage by stage: On suit ici les phases de réalisation du projet. C’est certainement un des aspects les plus “vieillots” du texte, où l’on parle conception détaillée, précédent l’implémentation, elle-même précédant d’abord les tests puis le déploiement.
- Mission accomplished: Cette partie indispensable couvre la rétrospective de projets.
Autant j’ai pu être ébloui par « Rapid Development » et son incroyable richesse, autant celui-ci m’a déçu. Evidemment tout est relatif, le contenu reste extrêmement pertinent et Steve McConnell reste un auteur très solide, ce qui justifie cette note franchement moyenne.
Référence complète : Software Project Survival Guide – Steve McConnell – Microsoft press 1998 – ISBN: 1-57231-621-7
A Pattern Language for User Information Feedback
Prenons notre machine à remonter le temps, voici un papier que j’avais soumis à la conférence Pattern Language Of Program 1999, à Urbana Champaign. Curieusement le sujet prédominant de cette conférence était une méthode sur le point d’être publiée : Extreme Programming.
Il n’est pas sûr que je publierais la chose ainsi aujourd’hui. Mais je n’ai rien retouché à ma prose, vous laissant ainsi la possibilité de la critiquer à loisir. Lâchez-vous !
Voici également le lien vers ce papier dans Issuu


