Note : 7 ; Suite de l’opus précédant…

Le précédant ouvrage des Poppendieck nous avait accoutumé aux pratiques Lean, celui-ci passe en quelque sortes, une seconde couche. Les principes sont à nouveau passés en revue, mais ici on consacre un chapitre par élément (et non par principe) important. Leur mise en valeur s’effectuant essentiellement à l’aide de cas d’exemples, non seulement pour introduire chaque chapitre, mais aussi pour illustrer celui-ci tout au long.

• Value : La valeur est au centre des principes Lean, non seulement pour délivrer les fonctionnalités apportant le plus de valeur et ce régulièrement (itérativement), mais en délivrant celle-ci le plus rapidement possible en optimisant la chaine de valeur et en focalisant les équipes sur les activités qui délivrent cette valeur.
• Waste : C’est aussi en focalisant les équipes sur les activités liées au produit final que l’on élimine le gâchis, mais aussi en éliminant les produits semi-finis ou en éradiquant le « hands-off » ou passage de relais formels entre deux équipes. Parmi les 7 origines du gâchis on trouvera également les fonctionnalités inutiles, les défauts, les délais, le réapprentissage et le « task switching », tous symptômes qui peuvent être éliminés à la racine.
• Speed : La théorie des files d’attente est au centre des préoccupations de rapidité. Ici l’attention est portée sur les temps de cycle, et le moyen le plus efficace pour les raccourcir : l’élimination des temps d’attente

• People : Le moyen de rendre plus efficace une équipe est de lui confier sa propre destinée! C’est aller plus loin que la simple “responsabilisation”. L’équipe ainsi autodirigée trouve son accomplissement dans son propre travail. Fini la motivation par les bonus et autres salaries variables…
• Knowledge : Créer de la connaissance, apprendre en faisant. C’est résumer un peu rapidement l’esprit de la chose, mais ici il est question de “set based design” et de refactoring, au final de différer les décision jusqu’au moment où l’on a appris suffisamment d’éléments pour opérer une décision judicieuse et non à priori.
• Quality: Ce point est abordé de manière peu convaincante dans l’ouvrage, sauf peut-être quand sont évoqués les 5 “S”: Sort, Systematize, Shine, Standardize et Sustain. Bien entendu y sont aussi évoqués les tests. La catégorisation des tests qui est proposée est à mon avis très pertinente.
• Partners : Cette partie traité des partenariats, des contrats et de l’externalisation. Lean approche cette question par le “win win” et les contrats à long terme.

La grande qualité de cet livre sont les histories qui servent d’exemples aux différentes questions abordées. Beaucoup de points restent hélas un peu abstraits, et malgré la qualité du texte, on en est toujours à se demander à la fin: “mais comment implémenter Lean dans le monde du développement logiciel ?”.

Référence complète : Implementing Lean Software Development, From concept to cash – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series 2006 – ISBN : 0-321-43738-1

http://www.goodreads.com/book/add_to_books_widget_frame/0321437381?atmb_widget%5Bbutton%5D=atmb_widget_1.png

Note: 8 ; L’anti-taylorisme tel que nous l’enseigne l’industrie !

Le « Lean Développement » dont Mary Poppendieck est l’une des figures de proue est l’adaptation au monde du développement logiciel du mouvement « Lean production » issue de l’industrie, pratiqué notamment chez 3M et Toyota. L’ouvrage n’hésite d’ailleurs pas à illustrer les concepts évoqués par des exemples tirés de l’histoire de ces 2 sociétés (et d’autres).

Le Lean Développement, comme la plupart des méthodes agiles, ne propose pas un cadre prescriptif pour la construction logicielle, mais un ensemble de 7 principes et de 22 pratiques.

• Eliminer le déchet : c’est l’un des principes fondamentaux du Lean développement (et des méthodes agiles en général). Il s’agit de se débarrasser de ce qui est inutile et ne participe pas à la chaîne de valeur, en utilisant deux outils que sont le repérage du gâchis et le « value stream map ».
• Amplifier l’apprentissage : le développement d’un système informatique n’est pas une activité de production, mais un travail de développement (comme son nom l’indique), où la découverte et l’expérience jouent un rôle prépondérant. Ce principe est supporté par des outils tels que le feedback, les itérations, la synchronisation des acteurs et le « set based développement » qui privilégie la communication basé sur les contraintes (qui permet de laisser les options ouvertes) plutôt que celle basée sur les choix (qui ferme ces options).
• Décider aussi tard que possible : Ne pas s’enfermer dans le choix de certaines options tant que l’on peut garder les options ouvertes ! Ce principe est soutenu par des outils tels que « l’option thinking », le « dernier moment raisonnablement possible » par l’utilisation d’abstraction d’interfaces ou de paramètres lors de la conception

• Délivrer aussi rapidement que possible : cette pratique dont le nom est auto explicite s‘appuie sur des outils tels que le « pull system », où le travail est tiré, choisi au moment où l’on peut l’effectuer plutôt que d’être assigné à l’avance de façon autoritaire ; une approche directement héritée des « kanban » , la « théorie des queues », le « coût des délais ».
• « Team empowerment » est un des fondements des méthodes agiles, mais aussi de ce que l’on appelle parfois le « Toyotisme ». Il s’agit ici de descendre le pouvoir de décision au niveau de ceux qui réalisent le travail, une approche servant-based management en rupture totale avec le taylorisme. 
• L’intégrité : Ce principe se décline en « intégrité conceptuelle » dans laquelle les principes centraux du système fonctionnent de façon cohérente, et en « intégrité perçue » dans laquelle le système assure le bon équilibre entre fonctionnalités, ergonomie, fiabilité et critères économiques.
• Voir l’ensemble : ce principe nous invite à améliorer le processus de développement en le considérant dans sa globalité plutôt que par optimisations locales, en utilisant des outils tels que les mesures ou les contrats.

Cet ouvrage est à mon avis hautement instructif, pratique et éclairé, il considère le développement logiciel comme une activité exploratoire, donnant la part belle à l’initiative, à l’organisation émergente et au leadership, par opposition aux processus prescriptifs, gérés par le contrôle de la conformité aux plans. Le texte rompt l’idée préconçue que le processus de développement doit être identique au processus de production et que le taylorisme est la réponse ultime de l’organisation, alors même que cette illusion a pris fin depuis plus d’un demi-siècle.

Ce livre n’évite aucun sujet épineux et traite même des aspects contractuels de la réalisation de projets, qui est un sujet hautement problématique des méthodes agiles. Les apports de la logistique industrielle que nous offrent les auteurs sont originaux et particulièrement instructifs, le plus souvent en rupture avec les idées préconçues que nous pouvons avoir sur le sujet.

La compacité du texte (186 pages) sera, j’espère, un argument supplémentaire pour vous décider à en aborder la lecture. A dévorer sans réserve !

Référence complète : Lean Software Development, An agile toolkit – Mary Poppendieck & Tom Poppendieck – Addison Wesley / ASD series 2003 – ISBN: 0-321-15078-3

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