Note de lecture : Surviving Object-Oriented Projects, a manager’s guide, par Alistair Cockburn

Note : 7 ; Beaucoup de clairvoyance et de clarté dans l’illustration de cas réels, une pertinence du texte qui résiste mais s’est érodée avec le temps.

Ce livre est rédigé de façon pragmatique, c’est probablement pourquoi il ne compte que 200 pages, volume au delà duquel il faut planifier du temps pour lire entièrement l’ouvrage. L’auteur s’est attaché à décrire comment une organisation pouvait basculer vers l’objet, les stratégies possibles et comment mettre le maximum d’atouts de son coté. Les cas de figure sont abondamment illustrés de cas de figure réels, aussi bien en succès qu’en échecs. Mais voyons plus avant son contenu. Les 200 pages de son contenu sont réparties sur 8 chapitres, mais il faut aussi évoquer les 40 pages d’annexes.

Le premier chapitre est un rappel des concepts de base de l’objet : encapsulation, polymorphisme, etc.. Rien de vraiment original, surtout en 98 où l’objet est quand même un acquis. Mais le propos a le mérite d’être clair.

Le second chapitre est plus original, car il reprend de manière très succincte 11 projets avec leurs facteurs clés de succès, d’échecs ou simplement de difficultés. Chaque cas est exposé sur moins d’une page avec un cartouche caractérisant le projet. En synthèse de ce chapitre l’auteur expose les avantages et les coûts liés aux projets objet. Le contenu est original et reste intéressant, même maintenant.

Les 40 pages du chapitre 3 sont dédiées aux choix et au setup du projet. Quel type de projet doit-on choisir pour faire son premier projet objet ? Avec quelles personnes et surtout avec quel langage ? Certains des points évoqués font largement sourire aujourd’hui. Comme par exemple la question d’un nouveau venu « périphérique » : Java. Aujourd’hui c’est surtout avec ce regard historique que l’on lira ce chapitre dont le propos a perdu de sa pertinence au fil du temps.

Au chapitre 4, on discute méthodologie et plus exactement ce que l’auteur appelle « big-M » versus « little-m » methodologies. Le big-M, ce sont les vrais processus, alors que les little-m ce sont les notations dérivant vers des méthodes/processus d’usage de ces notations. L’auteur exhorte d’abandonner le little-m et de se consacrer au big-M en statuant sur le choix d’un « big shop » ou « small shop » methodologies. Ce qui deviendra plus tard sa « cristal family of methods ». Même si l’auteur conseille de ne pas faire trop lourd, on reste quand même dans la logique rôles / activités / outils, sans compter le plan, les milestones, etc.. On reste assez loin de l’agilité quand même.

Justement, le très long chapitre 5 (près de 50 pages) est exclusivement consacré aux aspects itératifs et incrémentaux des projets. L’auteur y explique par le menu la différence entre les deux et l’avantage des les combiner et compare l’utilisation de ce mode à une « correction de trajectoire ». Cette lecture reste pertinente, même aujourd’hui.

Par comparaison, le chapitre 6 est très court, car il ne compte que 10 pages. L’auteur y évoque les phrases qu’il aurait souhaité de ne jamais entendre. Ce que j’appelle de mon côté les tartes à la crème. Certaines de ces idées reçues sont passées de mode (du moins je crois) mais d’autres ont la vie dure… On passe un bon moment à passer cela en revue !

Le chapitre 7 traite le cas des gros projets et se focalise spécifiquement sur les facteurs de réduction de risque. Là encore, il s’agit d’une lecture qui ne se démode pas.

Le dernier chapitre revisite l’un des cas exposé au premier chapitre et montre comment un échec aurait pu être évité à la lumière des éléments exposés dans le livre.

N’oublions pas non plus l’annexe A, la plus importante qui reprend sous forme de patterns, les stratégies de réduction de risques. Pas mal.

Le livre mérite sans contestation possibles son titre. Il accuse par pas mal de facettes le poids des ans. Il devient difficile de le conseiller, surtout quand de l’excellente littérature agile peut vous montrer la voie. Quelques chapitres méritent le détour, même aujourd’hui. Mais on en est plus à considérer les projets orientés objet comme de la technologie d’avant-garde…

surviving-oo-projects

Référence complète : Surviving Object-Oriented Projects, a manager’s guide – Alistair Cockburn – Addison Wesley / Object Technology Series 1998 – ISBN: 0-201-49834-0

Surviving Object-Oriented Projects


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

Et pourtant c’est l’été…

Nous entrons en zone estivale, parait-il !

L’heure pour moi de faire le point et de passer en régime d’été. Attention “régime d’été” ne signifie pas “silence radio” !

Pour ma part…

Pour ma part, ces derniers mois ont été un peu chargés. Entre autre parce que j’ai changé de boulot. Je n’aurait pu quitter le précédent comme un voleur, et le suivant commençait à me mobiliser avant même d’avoir définitivement posé mes valises. Je vais maintenant consacrer mon temps à l’accompagnement agile, avec des choses connues et maitrisées à mettre en oeuvre et aussi d’autres moins connues… Bref, de quoi être enthousiaste, mais c’est aussi moins de confort.

Ah oui, j’allais oublier : une formation coaching que je vais suivre avec Véronique Messager très bientôt.

J’ai quand même bien mérité un petit break, et je vais le prendre !

Et aussi un peu de préparation

Je serais à l’Agile Tour Bruxelles sur la fin d’année, peut-être aussi sur une ou deux autres conférences. Ce sera au moins une nouvelle session à caractère participatif à préparer. Donc l’été sera aussi studieux.

Du côté du Scrum User Group, le programme de l’an prochain n’est pas encore établi, il faut dire que le Scrum Gathering occupe une partie d’entre nous (mais pas moi). Mais en toute logique, nous devrions commencer à nous en occuper dès maintenant.

Sur le blog

Je suis fermement décidé à ne pas laisser une semaine sans post, congés ou pas. Les divers évènements vont se tarir après la semaine prochaine, donc il y aura encore quelques retours ici même dans la dizaine de jours qui vient, puis il faudra attendre Septembre. J’en profiterais pour rattraper certains retards de ce côté remontant à plusieurs mois !

Au minimum, je livrerais ici une note de lecture par semaine, peut-être plus. Mais elles auront un petit goût archéologique, car je vais remonter des choses un peu anciennes. On reprendra les choses plus type en Septembre. Ne débranchez pas, ça peut quand même vous intéresser et le passé éclaire parfois le présent.

Pour ce qui est des citations, je vais bien sûr continuer à les dispenser.

Toujours sur le blog: en finir avec…

Je vous avez asséné l’an dernier ma série de l’été: en finir avec… avec ses 3 premiers opus (ici le premier, le second et le troisième). J’avais d’ailleurs conclus cette série par un lightning talk donné à Nantes.

Je suis fermement décidé à la reprendre. je ne vais pas m’engager sur un nombre de posts, mais j’aimerais en faire 3 entre maintenant et mi-septembre. Chacun d’entre-eux représente pas mal de boulot, cela dit, et c’est l’été, je le rappelle …

A très bientôt, donc.

Scrum Boat 2013, dernière partie (en images)

Retour au Scrum Boat !

Dans un premier post, je vous avais montré quelques images de la première partie de soirée ; passons à la suite.

Courte pause avant le second atelier.

scrumboat2013-Break02

La poupe du navire est un endroit très apprécié, on a plutôt de la chance avec la météo aujourd’hui…

ScrumBoat2013-Break06

Sure le premier pont, on est désormais plus en mode “networking” qu’en Open-Space. Cela fait aussi partie des raisons pour lesquelles on vient aux rendez-vous du SG.

ScrumBoat2013-Pont1

Premier atelier de seconde partie : SOS Titanic, avec Philippe Houssin et Xavier Warzee

ScrumBoat2013-SOS_Titanic01

Le soleil rasant complique terriblement la prise de vue. J’ai aussi passé pas mal de temps à échanger sur cette seconde partie, donc moins de photos !

ScrumBoat2013-SOS_Titanic03

Voir Philippe Houssin à l’oeuvre, c’est toujours assez impressionnant. Ou comment le physique donne des informations sur le mental…

ScrumBoat2013-SOS_Titanic05

Parallèlement, Michel Zam nous proposait une session sur l’expérience utilisateur avec le DDD.

ScrumBoat2013-UXDDD02

Assistance curieuse et attentive ici aussi

ScrumBoat2013-UXDDD03

Pendant ce temps, en bas ça picole sec !

ScrumBoat2013-Picole01

Fini les ateliers, on lève l’ancre. Une ballade sur la Seine pour terminer la soirée : l’air est doux, la nuit éclairée de mille feux. Quoi d’autre ?

ScrumBoat2013-NightCall02

Ah oui, peut-être aussi un verre de Champagne !

ScrumBoat2013-NightCall04

Les fresques du quai de Seine

ScrumBoat2013-Fresques02

Le Musée d’Orsay

ScrumBoat2013-NightCall06

Dernière vue sur la Seine

ScrumBoat2013-NightCall08

Scrum Boat 2013, 1ère partie (en images)

Tu d’abord reportée, nous avons crains un moment être dans l’impossibilité de tenir notre Scrum Boat. Finalement, cela a tenu. Il faisait beau mais pas trop afin de ne pas étouffer dans la péniche. Les ateliers étaient prêts, ainsi que le buffet et la bonne humeur. Enfin les participants étaient au rendez-vous. Bref, tous les auspices étaient réunis !

scrumboat2013-accueil07

Un petit cocktail attendait les participants à l’arrivée. On va commencer les ateliers bien chauds, c’est bien.

scrumboat2013-accueil02

C’est l’heure, mise en place des ateliers !

scrumboat2013-dour03

Bertrand Dour et son frère nous proposaient “le petit poucet”.

scrumboat2013-dour05

Avec une assistance très nombreuse, pas nécessairement facile pour ce genre d’atelier

scrumboat2013-Dour06

Dans l’assistance, Alexis et bien d’autres habitués.

scrumboat2013-Dour08

Faute de cailloux, nous autre agilites avons des post-its !

scrumboat2013-Dour09

… Beaucoup de post-its !

scrumboat2013-Dour11

Oana nous proposait un atelier illustrant le “A3 problem thinking”

scrumboat2013-Oana06

L’affluence n’a hélas pas permis à tout le monde de participer activement. Ca fait toujours plaisir de voir et revoir Dragos, Elisabeth et les autres…

scrumboat2013-oana03

Au programme, du lancement d’avions en papiers !

scrumboat2013-Oana07

Ensuite, il faut améliorer !

scrumboat2013-Oana11

Et pour cela reconstruire une nouvelle série d’avions en papier

scrumboat2013-Oana16

Le A3, qui fait plus qu’un A3 résume les mesures d’améliorations.

scrumboat2013-Oana19

Et c’est reparti pour une nouvelle série de lancers !

scrumboat2013-Oana25

Sur le pont numéro 1, l’open-space rassemble un petit groupe de réflexion

scrumboat2013-OpenSpace02

Pour être honnête, nous pensions intéresser un peu plus de monde avec l’open-space. Pas grave.

scrumboat2013-OpenSpace04

Je n’étais pas seul à faire la couverture photo. Saluez la performance de la prise de vue faite à l’envers au-dessus de l’épaule. Je suis moi-même surpris du résultat, il me faut l’avouer.

scrumboat2013-Photographe01

La première série d’ateliers vient de s’achever, à très bientôt pour la suite.`

Note de lecture : La pratique du Lean Management dans l’IT, par Marie-Pia & Christian Ignace, Régis Medina & Antoine Contal

Note : 8 ; Comprendre l’application du Lean à l’informatique. Vraiment.

Il ne faut pas se leurrer : comprendre le Lean, c’est difficile. On nous parle de la maison Toyota, d’un certain nombre de pratiques, le tout cimenté avec des mots Japonais … Très bien. Mais ça reste très flou. Et comme de plus, le Lean passe pour être un peu l’aristocratie de l’agilité, ça ne fait pas très bien de dire qu’on a pas pigé ! Ce que l’on appelle parfois le « Lean Software Development » n’aide pas non plus tant que ça. Difficile de comprendre en quoi cela est différent de nos pratiques actuelles.

Il y a peu de textes qui m’ont permis de prendre conscience de la nature du Lean. En fait, il n’y en a que deux. Le premier est le « système Lean » de Womack et Jones, mais il portait sur l’application du Lean à la production. Le second est celui-ci !

On dit que l’on apprends mieux quand on nous raconte des histoires. C’est ce que font les auteurs ici. Au long des 11 chapitres complétant les 240 pages de cet ouvrages, ils nous enseignent par l’exemple les pratiques Lean au service de l’IT.

En Lean, tout part de la valeur et c’est ce que les auteurs abordent au premier chapitre. S’il ne s’appuie pas sur des exemple il expose efficacement les deux facettes de la valeur (on oublie souvent que pour le Lean il y en a deux) et les sources de gaspillage.

Le chapitre 2 « un idéal de fonctionnement » poursuit sur cette description du Lean qui reste ici encore un peu théorique en décrivant la « maison Toyota ». Un grand classique, serait-on tenté de dire, mais présenté avec une grande clarté. Même si je vois le sujet abordé pour la 3 ou 4ème fois, j’ai eu l’impression de voir la lumière s’allumer…

Le chapitre 3 « la pratique du Lean » est à lire et à relire, tel un kata que l’on répète afin de s’imprégner du message sans qu’il ne soit plus besoin d’y réfléchir. On n’y évoque pas seulement les différentes pratiques, mais aussi de la façon dont elles s’articulent, par où on commence… Une vingtaine de pages de pur enseignement.

Notre premier cas pratique arrive au chapitre 4, avec la gestion d’incidents. On y part d’une situation à laquelle on applique une démarche Lean. On expose celle-ci, notre plan d’action. Puis on déroule celui-ci avec ses découvertes ses progrès etc.… Le tout abondamment illustré est parfaitement limpide.

L’amélioration venant de la répétition, nous abordons un nouveau cas client au chapitre 5, une équipe support plus précisément. Si le chapitre 4 avait mis en pratique certains concepts comme le lead time ou le bac rouge, le chapitre 5 permet de voir plus précisément le PDCA.

De la réparation de la valeur, on passe à la création de valeur au chapitre 6 qui aborde la question du projet. D’autres outils sont illustrés ici comme l’Obeya room, la voix du client ou encore la résolution de problèmes (bien que le A3 soit mis de côté) ou encore le takt time. On le voit, un chapitre bien rempli !

C’est à la mise en flux que se consacre le chapitre 7. Parmi les thèmes qui y sont abordés, on trouve la restauration de la confiance avec le client et le management visuel.

Le chapitre 8 est entièrement consacré à l’un des piliers du Lean : le Kaisen, c’est à dire l’amélioration continue. C’est dans le cadre de l’amélioration de l’expérience utilisateur que le sujet est abordé. On y croise chemin faisant le modèle des 5 attentes client du Lean. Aspect déjà largement abordé dans les autres chapitres, le « go & see », prends une large part ici. Les concepts de « get out of the building » et d’expérimentation nous sont plus familiers dans la littérature Lean Startup mais ils figurent aussi au programme.

Il aurait été difficile de traiter pour cet ouvrage d’éluder le sujet de l’agilité. D’autant qu’Antoine et Régis sont parmi les plus anciens praticiens de l’agilité de l’hexagone car ils ont débuté avec XP dans les années 90 ! Lean y est présenté comme une approche permettant de doper la mise en œuvre de l’agilité avec XP et Scrum.

Le chapitre 10 est une occasion de reprendre de la hauteur. On y passe en revue les pratiques essentielles du Lean et ce qu’elles apportent.

Déployer le Lean ne se fait pas d’un coup de baguette magique. C’est au contraire un chemin difficile. Les auteurs évoquent leur expérience de la chose et les différents biais par lesquels cela peut être fait.

La pratique du Lean Management dans l’IT est un texte qui se lit très bien. Ne soyez pas surpris de le boucler dans la semaine. La plupart des chapitres racontent une histoire, une introduction du Lean dans un contexte particulier avec les actions menées par les coaches. Mais lecture aisée ne signifie pas texte creux ou chemin facile. De nombreuses pratiques sont mises en œuvre, beaucoup de concepts sont expliqués et nécessitent de revenir sur le contenu.

J’ai coutume d’aller écouter Régis et Antoine quand j’en ai l’occasion. Les sujets qu’ils présentent sont riches et intéressants. Mais comme disent les jeunes : on prends cher ! Les coaches Lean qui ont écrit cet ouvrage ont un très haut niveau de maturité, ils nous montrent le chemin et nous laissent comprendre que nous avons encore beaucoup à progresser en plaçant la barre très haut. Cela aussi nous vient du Lean. Et cela peut nous aider à progresser mais aussi nous décourager. C’est probablement le prix à payer.

La discrétion avec laquelle ce livre est sorti ne doit pas en occulter la valeur. Il a raté de peu mon classement du “book of the year”. C’est un texte de haut niveau dont la matière est illustrée avec talent par des cas réels et le déroulement d’une véritable transformation. Ne le ratez pas !

pratique-lean-IT

Référence complète : La pratique du Lean Management dans l’IT, agilité et amélioration continue – Marie-Pia Ignace, Christian Ignace, Régis Medina & Antoine Contal – Pearson France 2012 – ISBN : 978-2-7440-6544-6

La pratique du Lean Management dans l'IT


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

Done or done-done ?

  • T’as finis ton US ?
  • Ouais, ça y est, c’est bon !
  • Donc, t’es done ?
  • Oui, elle est “done” !
  • On peut la mettre en prod ce soir ?
  • Ah ben non, y’a encore des trucs à faire …
  • Donc, elle est pas “done” ?
  • Ben si, le dev est terminé. Mais il reste des trucs à faire, mais c’est pas moi. Elle est pas “done-done"…

Le concept de "definition of done” de Scrum est souvent interprêté comme une licence à ne pas aller jusqu’au bout de l’action (la mise en production, même seulement “potentielle”) mais comme un niveau d’accomplissement:

  • Developpement terminé.
  • Acceptance tests terminés.
  • End user tests / beta testing terminé.
  • Qualification opérationelle terminée.

Ce n’est pas le cas. Ce n’est pas de cela dont Scrum Parle quand on parle de “definition of done”. Le “done” de Scrum signifie toujours que mon développement peut être déployé en production sans autre forme de procès, que je le fasse effectivement ou pas !

image

Cela signifie simplement qu’en fonction de l’organisation, le paquet-cadeau pourra contenir différentes choses :

  • Une documentation utilisateur.
  • Un audit de conformité au plan d’urbanisation.
  • Une formation utilisateur.
  • Un outillage de monitoring pour les équipes de production
  • etc…

Votre imagination peut être sans limite, mais il en ira alors de même du coût de votre “definition of done” !

image

Mais on voit les équipes abdiquer par rapport à ce critère et inventer des niveaux de “done” intermédiaires ! Pourquoi ?

le plus souvent parce que les organisations font peser sur elles des contraintes de fonctionnements qui ne leur permettent pas d’avoir le contrôle sur toute la chaine jusqu’à la mise en production.

  • Ce peuvent être des cellules de test séparées, avec des plannings indépendants du projet et générant ainsi du délais.
  • Très souvent, sont concernées les équipes de productions, avec leurs propres plannings de mise en production transverses à de nombreuses équipes.
  • De manière générale tout ce qui créé des silos dans l’entreprise est un frein à avoir un véritable “done” !

Impuissants face à ces choix d’organisation, les équipes Scrum préfèrent s’adapter et aligner leur définition de terminé à ce qu’ils peuvent réellement contrôler, donc le périmètre de leur équipe. Mais cela ne corresponds pas à un réel accomplissement. Ce “terminé” va juste prendre la poussière sur une étagère avant d’être testé / qualifié, etc… et ensuite seulement être réellement utilisé !

image

Cette définition de terminé est un leurre. Il nous donne (peut-être) bonne conscience. Mais surtout il dissimule les lacunes du système !

Ne faites pas cela ! Conservez, augmentez même la visibilité des lacunes du système ! N’abdiquez pas sur la définition de terminé : ce doit toujours être un produit qui peut être passé en production, là tout de suite, maintenant !

N’oubliez pas que d’autres vont plus loin encore dans l’appréhension du done : en Lean Startup, même si cela n’est pas explicitement exprimé ainsi, on est “done” quand on a eu le feedback des utilisateurs et qu’on en a tiré les leçons !

Le constat mis en évidence est souvent douloureux, peut paraitre insurmontable, mais c’est le véritable chemin qui vous reste à parcourir pour arriver à un réel processus agile.