POUR Une nouvelle méthode pour améliorer les processus de développement

Transcription

1 KANBAN L IT POUR Une nouvelle méthode pour améliorer les processus de développement Laurent Morisseau Coach/formateur Scrum et Kanban, fondateur de Morisseau Consulting Préface de David J. Anderson Morisseau_I-II.indd I 30/05/12 09:20

2 Scrum Le guide pratique de la méthode agile la plus populaire 2 e édition Claude Aubry 304 pages Dunod, 2011 Illustration de couverture : Tilio & Paolo Fotolia.com Dunod, Paris, 2012 ISBN Morisseau_I-II.indd II 30/05/12 09:20

3 Préface Dunod Toute reproduction non autorisée est un délit. En 2004, je cherchais une nouvelle façon d aborder le changement dans les organisations de développement de logiciel. Je voulais améliorer l agilité, améliorer les méthodes que nous utilisions et faire cela sans rencontrer de résistance de la part des équipes réalisant le travail. J étais féru des cinq étapes du ciblage de la théorie des contraintes d Eli Goldratt. Le concept est simple : trouver le goulet d étranglement et l éliminer. Le goulet suivant émerge alors et peut être traité. Le processus est itératif et incrémental. Résoudre un problème à la fois. Il était nécessaire, pour utiliser l approche de Goldratt, de pouvoir modéliser le développement logiciel comme un problème de flux et d être capable de visualiser l invisible travail intellectuel du développement logiciel. J avais montré comment faire cela dans mon précédent livre, Agile Management for Software Engineering. J avais été inspiré par mon travail sur la méthode Feature Driven Development 1 et par celui de Donald Reinertsen. La théorie semblait simple : visualiser le travail invisible ; laisser les gens voir le flux (ou l absence de celui-ci) ; et avec cette perception d un problème autrement invisible, impalpable, les personnes impliquées parviendraient à un consensus sur ce qui doit être fait pour s améliorer ; des changements seraient apportés un goulet d étranglement éliminé ; les choses seraient améliorées et le goulet d étranglement suivant apparaîtrait alors aux yeux de tous ; et le processus se répéterait. Cela apporterait une approche itérative et incrémentale à l amélioration des processus de développement logiciel une façon réellement agile d améliorer l agilité. Son appel était irrésistible. Dans le même temps, j étais inquiet que nos méthodes traditionnelles de gestion de projet nous conduisent souvent à l échec. On nous demandait de tenir des promesses d engagements fermes sur le périmètre et sur le calendrier malgré beaucoup de risques et d incertitudes. L engagement sur le périmètre, le prix et la date de livraison créait, de mon point de vue, plus de problèmes qu il n en résolvait. Je voulais basculer sur une approche de prestation de service avec la promesse d un niveau de service plutôt qu une prise d engagement ferme sur chaque livrable. Agréger les risques sur l ensemble des demandes de service d une période de temps améliorerait la gestion de risques. 1. Développement Dirigé par les Fonctionnalités, une des premières méthodes agiles

4 IV Kanban pour l IT Cela nous permettrait d aller vers une prestation de service prévisible sans chercher à prédire précisément la livraison d un quelconque élément. L utilisation d un système tiré était parfaitement adaptée à cette approche. J étais également convaincu que les gens du métier et les clients apprécieraient davantage cette approche que celle à laquelle les autres fournisseurs les avaient habitués avec leurs contrats de prestation de service. Les services informatiques ayant des contrats de projets étaient, pour la plupart, l exception plutôt que la règle. En 2005, Donald Reinersten a eu, une fois de plus, une influence considérable sur la direction de mon travail et l émergence de ce que nous connaissons aujourd hui comme étant la méthode Kanban. Don a observé qu il y avait tellement de variation de cause commune dans la nature de notre travail qu identifier de manière fiable les goulets d étranglement avait probablement peu d effet de levier. J avais eu essentiellement de la chance lors de ma première tentative d utilisation des cinq étapes du ciblage. Je savais intuitivement que ce qu il me disait était correct. J en suis venu à réaliser que souvent la variabilité de cause commune est suffisamment importante pour que l identification fiable d un goulet d étranglement ne soit possible que dans seulement dix pour cent des cas. Plutôt que d utiliser le système Drum-Buffer-Rope de la théorie des contraintes pour gérer les goulets d étranglement, Don conseillait d utiliser l effet de levier plus important d un système kanban tiré issu de Toyota pour gérer la variabilité. Le bénéfice serait d améliorer la prédictibilité. Les systèmes kanban, comme tous les systèmes tirés, éliminent la surcharge et créent de la disponibilité. Ils contrôlent également la variabilité et rendent le flux plus prévisible. J ai donc décidé de faire évoluer mon approche itérative et incrémentale d amélioration de processus en utilisant des systèmes kanban plutôt que Drum-Buffer-Rope. En décembre 2006, mon équipe, au sein d une entreprise de Seattle, aux États-Unis, a mis en œuvre pour la première fois un système kanban tel que nous le connaissons aujourd hui. Ce qui s est passé ensuite n aurait pu être facilement prédit. Kanban a dépassé mes espérances. Il a en effet permis de rendre prévisible la prestation de service grâce à l innovation des classes de service, non connues des systèmes kanban Toyota. Il a également permis des changements itératifs et incrémentaux des processus avec une résistance minimale des personnes impliquées. Mais plus que cela, Kanban se révèle être une approche évolutive conduisant à des améliorations émergentes des processus ne pouvant être prévues à l avance. Ainsi les risques sont mieux gérés et une meilleure compréhension est partagée par toutes les parties impliquées - travailleurs, managers, clients, gens du métier, auditeurs, et autres parties prenantes. Depuis 2007, Kanban a fait écho à tous ceux qui ont fait l expérience de la résistance à l adoption de nouvelles méthodes, et tous ceux qui ont fait l expérience démoralisante de savoir qu un plan de projet les conduit à l échec. Une communauté grandissante, internationale s est formée. Le mot s est diffusé. Kanban a été adopté par des entreprises partout dans le monde. Beaucoup ont réalisé des bénéfices significatifs. Cela me fait donc grand plaisir qu un membre éminent de cette communauté internationale tel que Laurent rédige ce livre et introduise Kanban à un public francophone dans sa langue maternelle. Je connais Laurent depuis quelques années et

5 Préface V j ai le plus grand respect pour sa connaissance et sa maîtrise de Kanban. Avec cette couverture très complète et clairement expliquée de la méthode, j espère que vous aussi allez apprendre à mettre en œuvre Kanban et profiter des bénéfices que nous l avons vu apporter à d autres. David J. ANDERSON Seattle, États-Unis, le 26 février 2012 Fondateur de David J. Anderson & Associates, du Lean Software & Systems Consortium et du Lean-Kanban University Auteur du livre Kanban, Successful Evolutionary Cchange for your Technology Business, Blue Hole Press, 2010

6

7 Table des matières Préface Avant-propos III XVII Première partie Les concepts de la méthode Kanban Chapitre 1 Qu est-ce que le Kanban? Un peu d histoire Définir les termes du Kanban Dunod Toute reproduction non autorisée est un délit. 1.3 Définir l objectif du Kanban L objectif d un système kanban La capacité d un système kanban La méthode Kanban Les fondations de la méthode Les cinq pratiques de la méthode Kanban Kanban, une méthode non prescriptive Le développement en flux tiré Développer en flux Système «tiré» et système «poussé»? Développer en flux tiré

8 VIII Kanban pour l IT Chapitre 2 La place du Kanban Kanban et les autres méthodes L anticipation La maîtrise opérationnelle L amélioration La position de la méthode Kanban Kanban et cycle en V Kanban, une nouvelle méthode agile? L éligibilité de la méthode Kanban La conduite de projets La maintenance applicative de produit L activité de support Chapitre 3 Une démarche pour la méthode Kanban Le modèle PDSA Les phases d une démarche Kanban La phase «Concevoir» La phase «Mettre en œuvre» La phase «Étudier» La phase «Améliorer» Les cycles d implémentation Deuxième partie Le noyau de la méthode Kanban Chapitre 4 Définir le cadre du système kanban MyProjectStuff Scrum express Définir le cadre Les éléments constitutifs du système kanban La portée du système kanban Les objectifs du système kanban

9 Table des matières IX Chapitre 5 Analyser la nature de la demande Définir les éléments de travail Catégoriser les types d éléments de travail Définir l élément de travail Définir la bonne granularité de l élément de travail Définir la bonne taille de l élément de travail Cas aux limites des tailles d éléments Définir le flux de travail Cartographier le processus Processus générique vs processus spécifique Cas des processus trop compliqués Chapitre 6 Définir les règles du système kanban Définir les règles aux interfaces Définir les règles internes Qui applique les règles et s assure de leur suivi? Chapitre 7 Visualiser le système kanban Dunod Toute reproduction non autorisée est un délit. 7.1 Le management visuel Définir le management visuel Les leçons apprises de l agilité Visualiser les éléments par des cartes kanban Visualiser le flux de travail par un tableau kanban Le tableau kanban Les contrôles visuels Faire vivre le tableau kanban Chapitre 8 Définir les limites du système kanban Limiter le travail en cours Le passage aux limites La carte kanban dans l industrie La carte kanban dans l IT La mécanique des limites hautes La mécanique des limites basses

10 X Kanban pour l IT Visualiser les limites Où mettre les limites hautes? Définir les limites hautes Initialiser les limites hautes sur le travail en cours Initialiser les limites hautes aux interfaces Allouer de la capacité par type d éléments Limiter les files d attente Insérer une file d attente entre deux activités Mettre une limite sur une file d attente Définir la limite d une file d attente Chapitre 9 Définir les cadences du système kanban Définir les cadences La cadence en cycle en V La cadence en méthode agile Les cadences en Kanban L exception aux cadences Les cadences spécifiques du Kanban La cadence d injection des éléments dans le système La cadence de triage des files d attente La cadence de livraison des éléments Le juste à temps Chapitre 10 Mettre en œuvre le système kanban La réunion quotidienne Objectif de la réunion quotidienne Le format de la réunion quotidienne Gérer le mouvement des éléments La sélection d un élément Guide de sélection d un élément Gérer l affectation des éléments L affectation des éléments L affectation dynamique Affectation dynamique et management

11 Table des matières XI 10.4 Gérer le blocage des éléments Qu est-ce qu un blocage? Répondre à un blocage par la gestion des demandes Répondre à un blocage par la gestion de la capacité Répondre à un blocage par l ajustement des règles Anticiper un blocage en amont du processus Synthèse des tactiques pour gérer les blocages Gérer des anomalies internes au système Chapitre 11 Suivre au quotidien le système kanban Mettre à jour les indicateurs Suivi des temps sur des cartes de contrôle Temps de traversée et temps de cycle Les cartes de contrôle Suivi du débit Suivi du nombre d éléments dans le système Chapitre 12 Étudier un système kanban globalement saturé Étudier le système kanban Un système kanban globalement saturé La théorie des files d attente Dunod Toute reproduction non autorisée est un délit La loi de Little Définition de la loi de Little La loi de Little illustrée Un système disponible La loi de Little n est qu un modèle Chapitre 13 Étudier un système kanban localement saturé La théorie des contraintes Définir la théorie des contraintes Les types de contraintes Améliorer un système à contraintes Les cinq étapes de la démarche TOC Identifier les contraintes du système

12 XII Kanban pour l IT Décider comment exploiter la contrainte du système Subordonner le reste du système à la contrainte Élever la performance de la contrainte Recommencer à la première étape si la contrainte a changé Les limites de l approche TOC pour la méthode Kanban Chapitre 14 Étudier un système kanban variable Pourquoi la variabilité? Le système est variable La maîtrise statistique des procédés Utiliser la carte de contrôle Causes communes et causes spéciales Des limites pour réagir et investiguer Des limites pour être proactif sur les temps de cycle Analyse des cartes de contrôle étendues Suivre les tendances Les limites de l approche statistique pour la méthode Kanban Chapitre 15 Des limites trop hautes pour la capacité La cartographie de chaîne de valeur ajoutée Le Muda Les 3 Mus Le Muda Diminuer les limites des files d attente Jusqu où diminuer ces limites? Synthèse des modèles des chapitres 12 à Chapitre 16 Mesurer les impacts globaux des changements locaux Analyse du système Analyse de son équilibre global Analyse des temps moyens Exemples de diagrammes

13 Table des matières XIII 16.2 Analyse des impacts des changements Analyse des motifs Impact d un changement sur le diagramme de flux cumulé Chapitre 17 Identifier les comportements émergents Les modèles de conception Les files d attente Les classes de service Le coût du délai Description des classes de service Allouer de la capacité par classe de service Un tableau kanban à deux niveaux Les couloirs Les modèles de collaboration L équipe propriétaire du processus L équipe auto-organisée Le fourmillement L équipe fonctionnelle Fusion des petites équipes Chapitre 18 Acter les résultats du système kanban Définir la référence du système kanban Dunod Toute reproduction non autorisée est un délit La référence pour l engagement de service Définir le niveau de service Niveau de service et classe de service Package d engagements de service par classe La référence pour l amélioration continue Standardiser Chapitre 19 Ajuster les règles du système kanban Ajuster le processus Ajuster les limites kanban Pourquoi les ajuster? Comment gérer la diminution des limites?

14 XIV Kanban pour l IT 19.3 Ajuster les règles L approche TOC Le filtre de décision des ajustements Ajuster le management visuel Quand faire ces ajustements? Méthode Kanban et gouvernance IT Chapitre 20 Bilan de la démarche Kanban Les points clés de la démarche Kanban La phase de conception du système La phase de mise en œuvre du système La phase d étude du système La phase d amélioration du système Bilan de la démarche Enchaîner les cycles PDSA Affiner la démarche avec le modèle Cynefin La définition du modèle Cynefin La méthode Kanban dans le domaine simple La méthode Kanban dans le domaine compliqué La méthode Kanban dans le domaine complexe La méthode Kanban dans le domaine chaotique Troisième partie Étendre le noyau Kanban Chapitre 21 Étendre le Kanban Étendre le management visuel du Kanban Objectifs du management visuel L obeya Lean Concevoir l obeya Kanban Le flux d apprentissage Construire le management visuel Étendre le rôle de coach kanban Étendre la portée du système kanban Du temps de cycle au temps de traversée

15 Table des matières XV Un réseau de systèmes kanban Chapitre 22 Pour une meilleure organisation du travail Définition et caractéristiques Définition d un système complexe adaptatif Caractéristiques d un CAS CAS et Kanban Kanban et leadership Le système kanban a-t-il un impact sur les styles de management? Certaines habitudes managériales ont-elles un impact sur une démarche Kanban? Quel leadership pour prolonger l expérience Kanban? Thésaurus Références bibliographiques Webographie Bibliographie Index

16

17 Avant propos Dunod Toute reproduction non autorisée est un délit. Je travaille dans l IT depuis plus de quinze ans. Mon activité de coach agile m a permis de travailler en 2008 sur des projets dont les contextes ne se prêtaient guère à l agilité. Les obstacles rencontrés alors m ont amené à chercher une autre manière de répondre au besoin d agilité dans le développement logiciel. À cette époque, des blogs et des essais traitaient de développement en flux et proposaient une approche pour visualiser le travail et les tâches à réaliser tout en limitant le travail en cours. Passé le stade de l expérimentation de cette approche, j ai eu l opportunité d intervenir sur des projets majeurs et de mettre en place cette méthode qui se formalisait en empruntant le nom de Kanban, mot japonais utilisé pour décrire un système de production industriel. Si le concept était nouveau dans l IT, il était utilisé depuis des décennies dans l industrie. Kanban pour l IT est une méthode permettant aux équipes d améliorer leur processus de réalisation. Elle conduit à plus d agilité et permet un travail plus prédictible. Les retours d expérience de la communauté Kanban ont montré que la méthode peut être utilisée avec tous les cycles de développement logiciel, du cycle en V à Scrum. Elle complète ces approches plutôt qu elle ne les remplace. Avec ce livre, je souhaite vous faire partager ma compréhension, mon expérience et mes leçons apprises sur le Kanban. Il décrit les concepts de la méthode, la démarche pour l implémenter et détaille des pratiques du Kanban. Il ne remplace pas une application concrète dans votre environnement avec vos contraintes. Les objectifs de ce livre Ce livre est un guide pour tout agent du changement qui entame et mène une démarche Kanban dans le contexte de l IT. Cet ouvrage va lui permettre : de comprendre ce qu est le Kanban et de s assurer ainsi que cette méthode convienne à son contexte et à son organisation ;

18 XVIII Kanban pour l IT de pouvoir démarrer concrètement une telle démarche ; de savoir comment la mettre en place dans le temps ; d identifier la cible de l amélioration continue dans son cas particulier. À qui s adresse ce livre? Ce livre s adresse à tous ceux qui s intéressent au Kanban, qu ils soient chef ou directeur de projet, ScrumMaster, coach agile, manager, responsable méthode, DSI, développeur éclairé... Bref à tous ceux qui sont avant tout des agents du changement. Les novices y découvriront les concepts, des applications concrètes et une démarche en quatre étapes. Ceux qui ont une expérience Kanban y trouveront des pratiques avancées et des conseils utiles pour aller plus loin dans leur application quotidienne. Comment est structuré ce livre? Figure 1 Structure du livre. Le livre comporte trois parties. La première partie propose un tour d horizon du Kanban, du contexte aux définitions, sa position par rapport aux autres méthodes de développement logiciel, ainsi que la démarche de mise en œuvre. La deuxième partie décrit le noyau de la méthode Kanban. Son plan va suivre la démarche d implémentation, qui va de la conception d un système à son évolution. Sa lecture est de préférence linéaire pour suivre la logique d écriture.

19 Avant propos XIX La conception d un système kanban, la définition des limites kanban sur le travail en cours et la représentation visuelle des tableaux sont détaillées dans les chapitres 4 à 9. Ces chapitres doivent être lus avant d entamer une démarche Kanban. Les chapitres 10 et 11 ont pour objectif de permettre la mise en œuvre d un système kanban et proposent des réponses aux obstacles ou difficultés que l équipe va rencontrer au quotidien. Ces chapitres peuvent être lus au démarrage du premier système kanban. Les chapitres 12 à 16 donnent des pistes pour étudier un système kanban et mieux le comprendre. Pistes qui permettent d aborder la dernière partie d amélioration et d évolution du système kanban, des chapitres 17 à 19. Ces chapitres peuvent être lus après quelques semaines d expérimentation et nécessitent un bagage culturel méthodologique. La synthèse qui constitue le chapitre 20 clôture cette deuxième partie. La troisième partie propose d étendre le noyau de la méthode Kanban. Le chapitre 21 permet d identifier des pistes pour étendre la portée du Kanban, d abord son management visuel, puis le rôle de coach et enfin les réseaux de systèmes kanban. Les systèmes complexes adaptatifs abordés au chapitre 22 posent le cadre évolutif à l approche Kanban et abordent le style de management et le leadership qui le soutient. Cette dernière partie plus avancée est à destination de tous ceux qui veulent aller plus loin dans les pratiques. Le livre est écrit pour accompagner : la progression des concepteurs du système ; la pratique des membres de l équipe qui l utilisent ; l étude du système à destination de ce public ; la réflexion des coachs et des managers qui accompagnent la démarche. Dunod Toute reproduction non autorisée est un délit. La difficulté de parler du Kanban tient au fait qu il s agit d une approche d amélioration continue des processus qui peut être utilisée dans des contextes très variés d entreprises IT. Le discours est de fait généraliste. Le parti pris de ce livre est d illustrer les propos principalement au travers la transition de Scrum vers Kanban. Roman d entreprise Pour agrémenter la lecture du livre, imager les propos théoriques et les concepts, je vous propose de suivre une organisation fictive, travaillant sur des projets et avec des personnages imaginaires. Ce roman ne fait référence à aucun retour d expérience précis. Vous suivrez la mise en place de l approche Kanban dans cette organisation. Les dysfonctionnements des équipes, qui y sont décrits, ne sont pas là pour montrer les limites de telle ou telle méthode de gestion de projet mais pour illustrer le propos du livre. Les problématiques et les solutions en sont simplifiées. Les encadrés «Débriefing» expliquent les points importants et les choix des équipes de cette organisation.

20 XX Kanban pour l IT Mon expérience Au même titre que le roman, mes retours d expérience sont proposés sous les encadrés «Mon expérience». Ils rendent compte des difficultés ou des solutions issues du terrain opérationnel que j ai pu rencontrer. Remerciements Compléments en ligne Sur le site web associé à ce livre, vous trouverez les dernières informations relatives au livre, des articles complémentaires, des précisions, des mises à jour, ainsi que les formations et conférences de l auteur à l adresse Un grand merci à tous mes relecteurs qui m ont apporté un regard pertinent et constructif sur le contenu de ce livre. Ils m ont permis de l améliorer grâce à leurs questions et à leur exigence de qualité. Je remercie tout particulièrement Pierre FAUVEL, Claude AUBRY, Thierry MON- TULE, Philippe ENSARGUET, Guillaume LOURS, Dominique DE PREMOREL, François-Xavier MAQUAIRE, Dimitri BAELI, Pierre NEIS, Guillaume COLLIC, Joseph SOARES et Jean-Michel LEGRAND pour leur engagement dans ce projet et leurs encouragements. Je remercie également Nicolas DE LOOF, Jacques COUVREUR, Thierry CROS et Christophe HERAL pour leur contribution. Un grand merci à Alexis NICOLAS 1 : il est l auteur du paragraphe sur le Kanban et le leadership du chapitre 22. Je le remercie pour sa contribution à ce livre, ainsi que pour le passage du PDCA au PDSA. Je remercie chaleureusement David ANDERSON pour la préface de ce livre et son soutien. Merci à Yann PICARD DE MULLER pour la traduction de cette préface ainsi que sa contribution en tant que relecteur. Je remercie mon éditeur Jean-Luc BLANC de m avoir fait confiance pour ce premier livre. Un grand merci à Sylvie pour son soutien et sa patience pendant l écriture de ce livre. 1. Alexis Nicolas exerce une activité de conseil en organisation et management chez BNP Paribas.

21 PREMIÈRE PARTIE Les concepts de la méthode Kanban