Fabrice Aimetti

Nouveau blog : agilarium.blogspot.com

Aller au contenu | Aller au menu | Aller à la recherche

lundi, 10 février 2014

Blog déplacé

Bonne année 2014 ! En 2014, je rassemble tous mes blogs sur fabrice-aimetti.fr

dimanche, 11 septembre 2011

Nouveau blog, wiki et microblog

blogspot-logo.png wikispace-logo.pngtwitter-logo.png
Je vous informe de quelques changements :

  • mon blog officiel sera désormais ici : Agilarium, ce qui devrait m'épargner certains efforts en termes d'hébergement et de maintenance du site ;
  • je transfère progressivement mon wiki Traduction Agiles vers l'espace dédié au wiki Agilarium, pour les mêmes raisons que citées précédemment mais aussi parce que je souhaite publier mes travaux de traduction à un seul endroit ;
  • veuillez également noter que je passerai de plus en plus par Twitter @Agilarium pour annoncer la sortie des billets et des traductions.

lundi, 8 août 2011

Comment cartographier votre chaîne de valeur ?

Jim BensonJ'ai traduit ce billet de Jim Benson : "How To: Mapping Your Value Stream".

Lorsque nous construisons notre kanban, pour nous-mêmes ou bien pour une équipe, nous devons d'abord construire notre chaîne de valeur[1]. Une chaîne de valeur est simplement la liste des étapes que vous suivez pour créer de la valeur. Lorsque nous construisons un kanban, le travail circule tout au long de la chaîne de valeur, ce qui permet de visualiser notre flux.

Avant de commencer

Il y a quelques astuces rapides à connaître sur une chaîne de valeur :

1. La chaîne de valeur doit correspondre aussi fidèlement que possible à la réalité.
2. La chaîne de valeur doit être détaillée, de façon nécessaire et suffisante, pour voir et comprendre votre workflow.
3. Puisque votre compréhension et votre contexte changent, votre chaîne de valeur va également changer.

Ces trois astuces sont juste des phrases. Des mots comme chaîne, flux et valeur sont très difficiles à cerner. Ils changent, ils évoluent. Avec l'astuce n°1, nous souhaitons cartographier la réalité aussi fidèlement que possible. Mais nous n'arriverons jamais à parfaitement cartographier une bonne fois pour toute notre workflow.

Au début : démarrez en ayant à l'esprit les extrémités du kanban

Qu'êtes-vous en train de faire ?

Lors d'une réunion, vous pouvez :

- discuter d'un sujet à fond
- soulever des actions à mener
- planifier un futur ensemble de tâches

A la maison, vous pouvez :

- déléguer les corvées
- planifier des vacances
- construire une terrasse

Pendant les heures de travail, vous pouvez :

- créer des documents
- manager le personnel
- construire le tronçon d'un avion

Ces neuf activités peuvent avoir des états finaux très différents.

Par exemple, si nous écrivons un compte-rendu, l'état final sera "Publié".

L'autre extrémité... votre backlog... que l'on baptise généralement "Backlog" ou "Prêt". C'est là où votre chaîne de valeur démarre. Donc, pour notre chaîne de valeur de publication d'un compte-rendu, notre backlog ressemblera à :

Extrémités du Kanban

Etape suivante : complétez les blancs

Entre le début et la fin, il y a création. Par quelles étapes passez-vous pour créer quelque chose? Si l'on remonte le temps à partir de l'état "Publié", nous pourrions avoir Assemblage, puis Définitif, puis Second tirage puis avant cela Premier tirage.

Exemple complet de chaîne de valeur

Cela commence à ressembler à une chaîne dans laquelle chaque chapitre spécifique du compte-rendu peut circuler. L'équipe peut désormais suivre chaque chapitre au fur et à mesure qu'il se déplace vers sa bonne fin de rédaction.

Eléments importants à retenir

1. Votre chaîne de valeur est votre meilleure estimation quant à la façon dont votre travail se passe réellement.

Pour certaines équipes, la chaîne de valeur décrite ci-dessus fonctionnera très bien. Elles produiront probablement un compte-rendu à partir d'un modèle qui sera mis à jour ou personnalisé, car la chaîne de valeur suggère un processus très ordonné, sans surprises ou sans constantes réécritures. D'autres équipes auront une chaîne de valeur qui visualisera plus les activités de rédaction, de réorganisation du document, ou les personnes impliquées.

2. Votre chaîne de valeur va changer.

Comme mentionné ci-dessus, votre chaîne de valeur va changer au fur et à mesure que comprenez mieux comment vous travaillez. Vous n'avez pas besoin de vous asseoir pendant un mois pour élaborer une cartographie parfaite de votre chaîne de valeur. Faites une première version et commencez à travailler. Vous pourrez affiner au fur à mesure du workflow. Les différentes phases des projets peuvent nécessiter des flux de valeur très différents. Ne tombez pas dans le piège du processus rigide.

3. Votre chaîne de valeur est tolérante aux erreurs.

Si vous déplacez un post-it à droite et que quelque chose change entre-temps et vous fait revenir en arrière vers la gauche, ce n'est pas un problème. C'est la réalité. Vous avez vraiment fait passer un chapitre du "Premier tirage" vers le "Deuxième tirage", les circonstances ont changé et le chapitre s'est ensuite redéplacé vers l'état "Premier tirage".


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] value stream

vendredi, 5 août 2011

Envisager Lean et Kanban pour la Gestion de Portefeuille

Jason YipJ'ai traduit ce billet de Jason Yip : "Exploring Lean and Kanban for Portfolio Management".

J'ai récemment animé une discussion sur le Kanban pour la gestion de portefeuille pour la Limited WIP Society à Sydney. Avec le recul, étant donné le nombre de concepts inconnus soulevés, je me demande s'il n'aurait pas été plus utile de faire une présentation avant que la discussion commmence. Dans tous les cas, afin d'être prêt la prochaine fois, j'ai créé une carte heuristique que je pense utile de partager avec vous (cliquez dessus pour l'agrandir) :

Kanban pour la Gestion de Portefeuille


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

jeudi, 4 août 2011

Comment savez-vous que vous êtes une organisation Lean ?

Mattias SkarinJ'ai traduit ce billet de Mattias Skarin : "How you know you are a Lean organisation".

Vous pouvez embrasser le Lean de différentes manières. Vous pouvez utiliser des outils Lean, vous pouvez vous former au Lean et vous pouvez embrasser les valeurs du Lean (le Système de Production Toyota, "TPS" pour être exact).

Mais comment savez-vous que vous êtes une organisation Lean ?

1. Vous définissez la valeur du point de vue du client final

Jetez un oeil à vos produits et posez-vous la question : apportent-ils de la valeur à nos clients finaux ? Si non, pourquoi ? Nous pouvons aller très loin pour élaborer des produits, mais c'est lorsque nous entrons dans la tête de nos clients, que nous comprenons leurs problèmes et leurs défis, et que cette lumière nous guide à travers le flux de valeur, que nous créons d'excellents produits.

2. Vous avez défini un processus/flux de valeur pour livrer cette valeur

Vous ne pouvez pas améliorer ce que vous ne comprenez pas. Donc savoir à quoi ressemble le processus constitue la première étape. Une cartographie du flux de valeur, un tableau kanban peuvent être des outils pour en apprendre plus. Le point essentiel est de comprendre que tout changement réalisé sur ce flux de valeur est plus facile à vendre si toutes les personnes impactées peuvent le voir. Y compris abandonner des objectifs fonctionnels au bénéfice de ce flux de valeur.

3. Le management réduit continuellement le Lead time du flux de valeur

Il y a plusieurs points subtils à considérer :

(1) Implication du management. En comprenant comment le travail est effectué, il est possible de l'améliorer. Nous devons passer moins de temps en réunions à discuter de l'état de l'organisation et plus de temps pour l'améliorer.

(2) Valeur. Quelle est la valeur ajoutée du travail réalisé par le management ? S'il améliore le flux de valeur, il diminue notre délai de mise sur le marché[1] ainsi que l'obsolescence des stocks de conception.

(3) Confiance. Si le management est impliqué dans l'amélioration de l'état de l'organisation, il contribue à bâtir une relation de confiance avec les gens.

(4) Durabilité. Les gens vont et viennent. Comment pouvons-nous nous assurer que les améliorations ne vont pas simplement s'arrêter parce que l'une des personnes clés nous quitte ? Pour contrer cela, nous devons maintenir les compétences nécessaires pour améliorer notre flux de valeur. On peut le faire en les développant au niveau du management et en l'intégrant naturellement dans la formation des managers.

(5) Perfection. Combien de fois n'ai-je pas vu des organisations cesser de s'améliorer une fois qu'elles avaient atteint la première place sur le marché ? Un département informatique qui ignore des améliorations potentielles parce qu'il considère désormais être "assez bon" ? Maintenir le point (1) est la chose la plus difficile à faire. Si nous éliminons constamment les délais de mise en route[2] pour traiter un lot, que nous continuons à nous former sans retenue, nous supprimons alors la nécessité de traiter de grands lots de travaux dans le flux. Et nous pouvons alors vraiment donner au client ce qu'il veut, quand il le veut.


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] Time to market

[2] NdT : voir SMED ou Single Minute Exchange of Dies

mercredi, 27 juillet 2011

Protéger l'équipe est à double tranchant

Mike CohnBon, tout le monde est en train de dormir, j'en profite pour lire le billet de Mike Cohn : "Protecting the Team Cuts Both Ways" et le traduire.

Il y a un dicton Scrum communément accepté qui dit que l'un des devoirs du ScrumMaster consiste à protéger l'équipe. L'exemple habituel est que le ScrumMaster doit protéger l'équipe d'un Product Owner trop agressif. Il n'y a rien de mal dans cet exemple et de nombreuses équipes ont réellement besoin d'être protégées de leur Product Owner qui désire toujours plus de fonctionnalités, ce qui peut pousser une équipe à sacrifier la qualité. Cependant, un bon ScrumMaster protège également l'équipe d'un problème qui peut être encore plus nuisible : la complaisance.

Après avoir atteint très tôt et facilement certaines améliorations avec Scrum, certaines équipes sont satisfaites d'elles-mêmes. Elles cessent de chercher d'autres améliorations. C'est aux ScrumMasters de ces équipes de les protéger de ce sentiment de complaisance.

Ainsi, un bon ScrumMaster devra parfois se dresser devant un Product Owner agressif et lui dire : "Ce n'est pas le moment de pousser cette équipe plus loin. Ses membres travaillent aussi dur qu'ils le peuvent et si on les pousse plus loin, ils vont probablement tout bâcler." Mais mon conseil pour les bons ScrumMasters, c'est que pour chaque fois où ils disent cela, ils devraient plus tard dire autre chose au Product Owner, du style : "C'est le moment. L'équipe est reposée. Ses membres sont prêts. Voyons voir ce qu'ils peuvent faire. Il est temps de les pousser encore plus loin."

Si vous êtes un ScrumMaster, n'oubliez pas de protéger votre équipe de ces deux types de problème.


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

lundi, 25 juillet 2011

Le type C de Scrum expliqué

Serge BeaumontJ'ai traduit ce billet de Serge Beaumont : "Type C Scrum explained" parce que j'avais eu beaucoup de mal à comprendre cette notion dans l'article "New New Product Development Game" de Hirotaka Takeuchi et Ikujiro Nonaka... et pour tout vous dire je ne me souvenais pas non plus de la façon dont Jeff avait présenté ce slide lors de sa formation ScrumMaster.

Ce billet est issu d'une discussion avec Jeff Sutherland lorsqu'il était notre hôte chez Xebia.

Un bon schéma vaut mieux qu'un long discours, mais un schéma peut aussi compliquer les choses. Justement, l'une des choses que je n'avais pas saisi était le type C de Scrum, et tout ce dont je disposais était un article de Jeff et une image qui est généralement utilisée pour visualiser les types A, B et C. Je réalise maintenant que c'est cette image qui est à l'origine de ma mauvaise compréhension du type C...

C'est censé être la forme la plus avancée et difficile de Scrum, et Jeff nous a expliqué comment le type C fonctionnait chez PatientKeeper[1]. Le type C est en fait un Scrum dans un Scrum dans un Scrum, ou comme Jeff l'a schématisé, des roues à l'intérieur de roues.

L'image que l'on connaît bien se trouve ci-dessous : notez que le type C est représenté comme un chevauchement d'ovales de la même taille. Alors, est-ce que ce sont simplement des sprints qui se chevauchent ?

Scrum ABC

En réalité... pas du tout. Le type C est quelque chose de complètement différent.

Il y a un parallèle avec l'image qui est généralement utilisée pour présenter la mêlée quotidienne[2], où la mêlée quotidienne est un petit engrenage, qui tourne une fois par jour, en prise avec un engrenage plus grand, qui lui tourne une fois par mois. Désormais, je dessine le type C comme un empilement de ces engrenages : la mêlée quotidienne, le cycle hebdomadaire, le cycle mensuel et le cycle trimestriel (du moins, c'était l'ensemble des cycles utilisés chez PatientKeeper).

Les items du backlog sont assignés à l'un de ces cycles en fonction de leur priorité et de leur urgence. Il y a la priorité critique[3], où tout le travail concerne la résolution d'un problème critique. Puis il y a des éléments du backlog de haute priorité qui doivent être livrés cette semaine, puis des éléments "ordinaires" pour le cycle mensuel, des changements et des améliorations plus stratégiques pour le cycle trimestriel.

Un membre de l'équipe travaillera sur les items du backlog dans cet ordre : le travail critique d'abord, puis les items hebdomadaires, puis les items mensuels, et enfin les items stratégiques. Jeff explique qu'il s'agit d'une subtile incitation pour les membres de l'équipe : s'ils terminent les éléments de haute priorité, ils leur restent du temps pour, comme Jeff l'a dit, "les choses vraiment intéressantes" : s'asseoir, faire une pause et réfléchir à comment améliorer le produit, pour qu'il soit encore meilleur techniquement et fonctionnellement.

Donc, l'image pour le type C devrait en réalité être celle-là :

Type C Wheels Half

Je n'ai jamais pratiqué le type C, mais je suppose que le plus gros défi est de s'assurer que les choses à court terme ne compressent pas le temps restant pour traiter les items à long terme. Je ne pense pas qu'attribuer un item à l'un des cycles devrait être trop compliqué.

J'espère que vous avez maintenant moins de difficulté à comprendre le type C. En tout cas, cette nouvelle façon de le visualiser me convient tout à fait...


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] Jeff Sutherland était Directeur Technique (CTO - Chief Technology Officer) chez PatientKeeper en 1997

[2] Daily Standup

[3] hold-the-line

dimanche, 24 juillet 2011

Pourquoi les startups sont agiles et opportunistes - Faites pivoter votre modèle économique

Steve BlankBon, j'ai encore craqué (merci la météo) sur un billet de Steve Blank : "Why Startups are Agile and Opportunistic – Pivoting the Business Model".

Les startups sont le moyen de trouver l'ordre dans le chaos.[1] Steve Blank

La semaine dernière, lors d'une réunion du conseil d'administration d'une startup, j'ai observé comment son jeune PDG s'y prenait pour annoncer les mauvaises nouvelles. "Notre stratégie actuelle ne fonctionne pas. Nous n'arrivons pas à développer l'entreprise. Chaque vente nous oblige à prendre le client par la main et cela prend beaucoup trop de temps pour conclure l'affaire. Mais je crois que je sais comment y remédier." Il a pris une profonde inspiration, son regard a fait le tour de la table du conseil d'administration et il a ensuite procédé à une reconfiguration radicale de la gamme des produits (reconditionner les produits plutôt que les reconcevoir) et un changement dans la stratégie de vente, en se concentrant sur un segment de clientèle différent. Certains des investisseurs juniors ont littéralement pété une durite. "Nous avons investi dans la stratégie que tu nous avais vendue." D'autres investisseurs ont suggéré d'ajouter de nouvelles fonctionnalités aux produits, d'autres encore ont suggéré de virer le Responsable des Ventes. J'ai alors remarqué que l'investisseur principal s'est juste assis confortablement pour écouter la suite.

Finalement, une fois que le tour de tout le monde est passé, l'investisseur principal, aux cheveux gris, s'est tourné vers le fondateur et a dit : "Si tu fais ce que nous te disons de faire et que tu échoues, nous te virons. Si tu fais ce que tu penses être juste et que tu échoues, nous te virons aussi. Mais au moins tu auras exécuté ta stratégie et pas la nôtre. Suis ton intuition et fais ce que tu penses que le marché te dit. C'est la raison pour laquelle nous avons investi sur toi." Il s'est tourné vers les autres investisseurs et a ajouté : "C'est pour ça que nous signons les chèques et que les entrepreneurs dirigent l'entreprise."

La recherche du modèle économique[2]

Une startup est une organisation constituée pour trouver un modèle économique reproductible et évolutif[3].

Les investisseurs de la startup parient sur un PDG pour trouver le modèle économique reproductible et évolutif.

Business Model 1

Contrairement aux histoires qu'ont lit dans la presse quotidienne, les entrepreneurs qui bâtissent des entreprises prospères ne le font pas du premier coup. Cela arrive seulement une fois que c'est fait et qu'ils ont raconté leur histoire. Le monde réel est beaucoup, beaucoup plus compliqué. Et beaucoup plus intéressant. Voici ce qui arrive vraiment.

Observer, Orienter, Décider et Agir

Qu'ils utilisent un processus formel pour trouver un modèle économique comme le Développement Client ou simplement par essais / erreurs, les fondateurs d'une startup sont intuitivement à la recherche d'un moyen d'optimiser leur modèle économique. Ils peuvent établir leur modèle économique de façon formelle ou ils peuvent conserver les pièces dans leur tête. Dans les deux cas, les fondateurs qui réussissent, observent d'abord que quelque chose ne fonctionne pas dans leur modèle économique actuel, s'orientent sur la base de ces nouvelles informations, décident quelle partie de leur modèle économique doit changer et ensuite agissent sans aucune hésitation.

Bus Model

C'est un stratège de l'US Air Force, le colonel John Boyd, qui a en premier décrit cette boucle itérative Observer, Orienter, Décider et Agir (OODA). Le modèle de Développement Client que j'ai décrit et enseigné est la version entrepreneuriale de la boucle OODA de Boyd.

Faites pivoter le modèle économique

Qu'advient-il lorsque le leader de la startup reconnaît que le modèle économique initial ne fonctionne pas comme prévu ? Dans les startups traditionnelles, c'est à ce moment-là que le Responsable des Ventes ou du Marketing se fait virer et que l'on commence à chercher les coupables. En revanche, dans une start-up qui suit le processus de Développement Client, c'est lorsque les fondateurs réalisent que quelque chose ne va pas avec le modèle économique (parce que le chiffre d'affaires ne décolle pas). Ils décident de ce qui doit changer et agissent en conséquence pour reconfigurer certaine(s) partie(s) de leur modèle.

Le Pivot

Le processus de Développement Client suppose que bon nombre des hypothèses initiales prises dans le cadre de votre modèle économique seront probablement mauvaises, il propose donc une boucle d'itération pour les corriger. Eric Ries a proposé un nom pour cette boucle dans l'itération du modèle économique : le Pivot.

L'une des conséquences positives du Pivot pour l'équipe d'une startup, c'est de se rendre compte que l'insuffisance de chiffre d'affaires n'est pas de la faute des départements Ventes, Marketing ou Ingénierie, et que la solution n'est pas de virer les gens mais bien de reconnaître qu'il y a un problème avec les hypothèses prises dans le cadre du modèle économique initial.

Les types de Pivots

Vous "Pivotez" quand vous modifiez une partie fondamentale du modèle économique. Cela peut être aussi simple que de reconnaître que votre produit se vendait au mauvais prix. Cela peut être plus complexe si vous découvrez que la cible de vos clients ou utilisateurs doit changée ou que l'ensemble des fonctionnalités est mauvaise ou que vous devez "reconditionner" un produit monolithique en une famille de produits ou que vous avez choisi les mauvais canaux de vente ou que votre programme d'acquisition de nouveaux clients a été inefficace.

Scalable Startup

Si vous établissez votre modèle économique, il sera plus simple de découvrir comment le Pivoter en listant les différents possibilités de changement. Il y a beaucoup de livres pour vous aider à comprendre comment bâtir un "Plan B", mais les grands entrepreneurs (et leurs conseils d'administration) reconnaissent que ce processus doit se faire rapidement et continuellement.

Agir dans un contexte Chaos + Vitesse + Pivots = Succès

Contrairement à une grande entreprise rentable, les startups sont contraintes par leurs liquidités disponibles. Si une startup ne trouve pas un modèle économique rentable et évolutif, elle fera faillite (ou pire se retrouvera dans la "Terre des morts-vivants", se maintenant péniblement au seuil de rentabilité). Cela signifie que les PDGs de startups sont continuellement en train de regarder s'ils ont besoin de faire un Pivot pour trouver un meilleur modèle. S'ils croient qu'un Pivot est nécessaire, ils n'hésitent pas à faire les changements. La recherche d'un modèle économique rentable et évolutif pourrait nécessiter qu'une startup fasse plusieurs pivots : certains ne seront que de petits ajustements, et d'autres seront des changements majeurs.

En tant que fondateur, vous devez vous préparer à penser de façon créative et indépendante parce que, la plupart du temps, les conditions sur le terrain vont changer si rapidement que votre modèle économique initial, sur lequel vous avez passé beaucoup de temps à réfléchir, deviendra rapidement obsolète.

Résumé

Les startups sont intrinsèquement chaotiques. Les changements rapides dans le modèle économique sont ce qui différencie une startup d'une entreprise bien établie. Les Pivots sont l'essence de l'entrepreneuriat et la clé de la réussite d'une startup. Si vous ne pouvez pas pivoter ou ne pas pivoter rapidement, vous risquez d'échouer.

Pivotez.

Leçons apprises

- Une startup est une organisation constituée pour trouver un modèle économique reproductible et évolutif.
- La plupart des modèles économiques des startups sont initialement mauvais.
- Le processus d'itération pour rechercher et trouver le meilleur modèle économique s'appelle le Pivot.
- Les Pivots doivent se produire dès que possible, rapidement et souvent.
- Lorsqu'ils investissent en amorçage, les micro-fonds d'investissement et les "super angels" savent que les entreprises sont encore à la recherche d'un modèle économique (ils comprennent la notion de Pivot).
- La plupart du temps, lorsqu'une startup cherche à lever un premier ou second tour institutionnel, les investisseurs en capital-risque s'attendent à ce qu'un modèle économique évolutif ait déjà été trouvé.
- Les Pivots sont la raison pour laquelle les startups doivent être agiles et opportunistes, et pour laquelle leurs cultures sont différentes des grandes entreprises.

Feedback :

  • Je remercie Ronan Amicel pour sa relecture de l'article traduit et ses propositions.

Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] Startups are the search to find order in chaos.

[2] Business Model

[3] scalable

jeudi, 21 juillet 2011

Priorisation Agile

Mike GriffithsJ'ai traduit ce billet de Mike Griffiths : "Agile Prioritisation".

Toutes les méthodes agile utilisent des systèmes de priorisation. Même si la terminologie varie - Scrum parle par exemple d'un "backlog produit", FDD d'une "liste de features" et DSDM d'une "liste d'exigences priorisées" - le concept reste le même. Le projet fonctionne grâce à une liste hiérarchisée d'éléments pour lesquels on peut discerner une valeur métier.

La priorisation est nécessaire car elle permet d'adapter le périmètre pour satisfaire les objectifs budgétaires ou calendaires, tout en conservant un ensemble utile de fonctionnalités (Version Minimale Commercialisable[1]).

Priorisation agile 1

La priorisation fournit également un cadre pour décider s'il faut et quand intégrer les changements. En demandant au métier "Dites-moi une chose qui est plus importante qu'une autre ?" puis en insérant ce nouveau changement à l'endroit approprié dans la liste des travaux priorisés, il est possible d'intégrer les changements.

Priorisation agile 2

Ça vaut la peine d'expliquer que même si les méthodes agiles offrent une grande flexibilité grâce à la capacité d'accepter les changements de dernière minute, ils ne peuvent pas plier les lois du temps et de l'espace. Donc, si le budget et le calendrier de votre projet prévoit de consommer entièrement le périmètre actuel, alors ajouter un nouveau changement va inévitablement forcer une feature de priorité inférieure à passer en dessous de la limite de ce que nous comptons livrer. Donc, oui, nous pouvons accepter les changements de dernière minute ... mais seulement aux dépens des éléments de plus faible priorité.

Une unique liste des travaux priorisés simplifie également la visibilité sur le reste à faire. Au lieu de séparer les demandes de changement, corrections d'anomalie et nouvelles features, les gens obtiennent une vue complète et claire du reste à faire en les combinant dans une seule liste priorisée. Beaucoup d'équipes passent à côté de ce point en conservant des budgets pour les demandes de changement et les corrections d'anomalie. Cela trouble la vélocité ; une unique liste priorisée du travail à faire, indépendamment de l'origine de ce travail, offre une meilleure transparence et un meilleur axe de négociation.

Derrière chaque système de priorisation se cache une personne qui priorise

La manière dont nous allons obtenir les priorités (et utiliser un système de priorisation) varie d'une méthode à l'autre - et parfois d'un projet à l'autre - en se basant sur ce qui fonctionne pour l'entreprise. Un système de priorisation simple consiste à étiqueter chaque élément avec "Priorité 1", "Priorité 2", "Priorité 3", etc. Bien que simple, le problème avec ce système est que tout a tendance à prendre la "Priorité 1" - ou qu'au minimum trop de choses sont étiquetées "Priorité 1" pour être réellement efficace. Il est rare qu'un représentant du métier demande une nouvelle fonctionnalité et dise qu'il s'agit d'une Priorité 2 ou 3, car il sait qu'une faible priorité peut passer en dessous de la limite. Les priorités "élevée", "moyenne" et "basse" subissent le même sort. Sans une raison argumentée et partagée de ce qui définit une priorité "élevée", nous nous retrouvons avec un trop grand nombre de priorité "élevée" et donc avec un manque de véritable priorité.

DSDM a popularisé le système de priorisation MoSCoW, qui tire son nom des premières lettres de ses étiquettes "Must..."[2], "Should..."[3], "Could..."[4], "Wouldn't"[5]. Avec MoSCoW, il est plus facile d'argumenter. Les "Must-have" sont des exigences fondamentales pour la viabilité du système ; sans elles, le système ne fonctionne pas ou n'a aucune valeur. Les "Should-have" sont des exigences importantes ; par définition, nous en avons besoin pour que le système fonctionne correctement ; si elles sont absentes, alors le produit se révèlera probablement coûteux ou lourd à utiliser. Les "Could-have" apportent une valeur ajoutée tangibles, et les "Wouldn't-have" sont des exigences dûment enregistrées mais qui auront peu de chances d'être traitées[6].

Une approche que j'ai vu bien fonctionner est de donner des billets de Monopoly aux sponsors du produit, égalant le budget du projet, et en leur demandant de les répartir parmi les features du système. C'est utile pour obtenir une priorité générale sur les composants du système mais ne poussez pas trop loin son usage en cherchant à l'appliquer à des activités perçues comme ayant une fable valeur ajoutée comme la documentation, donc réservez son usage aux features métier.

Si vous n'avez pas de billets du Monopoly à disposition, la méthode des 100 points, initialement créée par Dean Leffingwell et Don Widrig pour les cas d'utilisation, peut être utilisée à la place. C'est un système de vote où l'on donne 100 points à chaque partie prenante qu'elle peut utiliser pour voter en faveur des exigences les plus importantes. La façon dont ils distribuent les 100 points les concerne : 20 ici, 10 là ou alors carrément 100 sur une seule exigence si c'est leur seule priorité.

Le Modèle de priorisation des exigences, créé par Karl Wiegers, est une méthode mathématique plus rigoureuse pour calculer la priorité. On évalue le bénéfice, la perte, le coût et le risque sur une échelle relative de 1 à 9 (faible vers élevé) pour chaque feature proposée. Les clients évaluent le score du bénéfice à disposer de la feature, le score de la perte à ne pas en disposer. Les développeurs évaluent le coût pour produire cette feature et le risque associé à sa production. Après avoir enregistré les scores de toutes les features, la priorité relative de chaque feature est calculée en considérant le pourcentage pondéré de souhait de chaque feature. Pour plus de détails et un lien vers un exemple, voir First Things First: Prioritizing Requirements de Karl ; pour une analyse plus complète des modèles mathématiques sur la priorisation des exigences, jetez un coup d'œil à l'article US-CERT.

Pas de système comme système

A la fin de la journée, c'est la priorité des features qui compte, pas le système de priorisation utilisé. Parfois, arbitrer sur le système de priorisation peut nuire en prenant trop de temps à en discuter. Pour cette raison, je suis personnellement fan de tout simplement demander au métier de lister les features par ordre de priorité. Pas de catégorie 1, 2, ou 3 ; pas de élevé, moyen ou bas; pas de must-have, etc. mais plutôt une simple liste (dans Excel ou un outil agile de gestion des exigences). Cela supprime les catégories sur lesquelles les gens ont tendance à faire une fixation et à débattre et focaliser les discussions sur les priorités.

Conclusion

Faites preuve de créativité par tous les moyens et essayez différents systèmes pour que le métier s'engage à établir les priorités. Il n'y a pas de moyen unique et parfait pour systématiquement affecter une priorité ; essayez plutôt de diagnostiquer les problèmes survenant dans le processus de priorisation, que ce soit un "manque d'implication" ou "trop de priorité 1", puis expérimentez des approches telles que les billets de Monopoly, MoSCoW ou une simple liste pour vous aider si les problèmes ne peuvent pas être résolus par le dialogue. L'objectif est de comprendre comment les features interagissent les unes par rapport aux autres plutôt que d'attribuer une étiquette. En maintenant une liste flexible d'exigences priorisées et en ayant la possibilité de revisiter les priorités, nous maintenons l'objectif de l'agilité de livrer l'ensemble des features de plus haute valeur ajoutée dans le temps et le budget disponibles.

A l'origine, j'ai écrit cet article pour Gantthead.com, paru en avril 2011 ici.


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] Minimum Marketable Release

[2] NdT : Viable

[3] NdT : Essentiel

[4] NdT : Confort

[5] NdT : Luxe

[6] NdT : on dit même qu'il s'agit de la zone d'optimisation budgétaire du client

mercredi, 20 juillet 2011

Créer une pression positive autour des releases

Logo Agile In ActionJ'ai traduit ce billet de Simon Baker : "Create positive pressure around releases".

Si vous travaillez sur le déploiement d'une release importante, la pression monte au fur et à mesure que la date de livraison approche pour toutes les personnes impliquées. Dans cette situation, pour l'équipe technique chargée de la livraison, la pression est presque toujours négative si rien n'est fait. Le temps s'écoule, le battement du tambour devient de plus en plus rapide et l'équipe est fouettée pour ramer plus vite, un peu comme les galériens dans Ben Hur.

Ce type de pression crée une spirale négative. Les gens se fatiguent et commettent davantage d'erreurs, ce qui crée encore plus de travail et ajoute encore plus de pression. Il pourrait y avoir un héros qui sauve la journée, mais cette situation qui dégénère ne fait pas ressortir le meilleur des gens. Au contraire, elle détériore les relations entre l'équipe et ceux qui exercent cette pression. Cela établit un précédent pour la performance de l'équipe et entaille son enthousiasme. La pression est une réalité. Elle peut améliorer les performances à court terme, mais sur le long terme elle doit être mesurée sinon c'est une pente glissante qui mène à une très mauvaise situation.

Plutôt que d'insister auprès de l'équipe pour que tout soit fait dans les temps, le client a l'opportunité de créer une véritable pression positive au sein de l'équipe. Pensez à la vision, cet objectif commun et à ce sentiment de propriété partagée du produit. Ce produit qui est le bébé de tout le monde, canalisez cette passion et cette énergie. Créez un sentiment d'excitation autour de la release en éveillant la curiosité sur la performance de ce nouveau produit sur ​​le marché et sur les bénéfices que l'entreprise pourra en tirer. La curiosité est une chose puissante. Faites-en un moteur pour l'équipe[1].


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] NdT : elle le mérite bien !

mardi, 19 juillet 2011

Aucune stratégie d'entreprise ne survit au premier contact avec un client

Steve BlankJ'ai traduit ce billet de Steve Blank : "No Business Plan Survives First Contact With A Customer – The 5.2 billion dollar mistake.".

Avec 5,2 milliards de dollars, Iridium a été l'un des plus grands et audacieux pari de création d'entreprise[1] jamais réalisé. Conçu en 1987 par Motorola et essaimée en 1990 en tant que société distincte, Iridium prévoyait de construire un système de téléphonie mobile qui pourrait fonctionner n'importe où dans le monde. Ce système devait couvrir chaque ville, village et pouce carré de la terre, des navires au milieu de l'océan arctique, en passant par les jungles de l'Afrique jusqu'aux sommets des montagnes reculées de l'Himalaya. Et Iridium comptait le faire sans construire un seul relai de téléphonie mobile.

Comment ? Avec une stratégie d'entreprise[2] venue d'ailleurs. D'abord, l'entreprise a acheté une flotte de 15 fusées provenant de la Russie, des États-Unis et de la Chine. Ensuite, elle a construit 72 satellites sur une chaîne de montage et utilisé les fusées pour les lancer en orbite à 800 kilomètres d'altitude. Là-haut ces satellites se sont comportés comme des relais de téléphonie mobile capables de fournir une couverture téléphonique à n'importe quel endroit sur la planète. Sept ans après sa fondation, ses satellites et ses stations au sol étaient en place. Ce fut un tour de force technique.

Iridium Network
Réseau de satellites de Iridium

Mais en 1998, neuf mois après que le premier appel téléphonique ait été effectué, Iridium se plaçait sous la protection du chapitre 11 de la loi sur les faillites[3]. Ce fut l'un des plus retentissants échecs de création d'entreprise enregistrés jusqu'alors. Qu'est-ce qui a mal tourné ?

Nous pensons avoir identifié un problème sérieux

Lorsqu'initialement Iridium fut conçu au sein de Motorola en 1987, la couverture téléphonique mobile était très éparse, les appels n'étaient pas fiables et les coûts à la minute étaient rédhibitoires. Les téléphones mobiles étaient de la taille d'un panier repas et coûtaient des milliers de dollars.

Motorola Dynatac 8000x ~1987
Motorola Dynatac 8000x ~1987

Quand elle essaima en tant que société distincte en 1990, la stratégie d'entreprise de Iridium se basait sur certaines hypothèses concernant les clients potentiels, leurs problématiques et les produits nécessaires pour les résoudre. Toutes ces hypothèses étaient fondées sur le contexte de l'industrie du téléphone mobile en 1990. Iridium a également fait d'autres hypothèses sur les différents types de canaux de ventes, les partenariats et le modèle de revenus dont elle aurait besoin. Elle a ensuite modélisé tout ça dans un ensemble de prévisions financières avec une "taille de marché" estimée à 42 millions d'ici 2002 par divers cabinets de conseil marketing. Lorsqu'elle a lancé ses satellites dans l'espace, Iridium a vraiment cru qu'elle faisait tourner une planche à billets.

Une stratégie d'entreprise figée dans le temps

Mais au cours des 11 années qu'il a fallu à Iridium pour passer du concept au lancement, l'innovation dans les téléphones et les réseaux mobiles s'est développée à une vitesse incroyable. Au moment où Iridium s'est lancé, il y avait beaucoup d'endroits sur la planète où les services de téléphonie mobile étaient indisponibles. Aujourd'hui, les entreprises traditionnelles en téléphonie mobile assurent une couverture dans les parties les plus importantes du monde. Les prix pour les services locaux et internationaux en téléphonie mobile ont baissé de façon spectaculaire. La taille d'un combiné de téléphone mobile a rétréci et peut maintenant tenir dans votre poche.

En revanche, lorsque le service Iridium devint disponible, son téléphone satellite était plus gros qu'une brique et faisait à peu près le même poids.

Iridium 9500 Satellite Phone
iridium-9500 satellite phone ~1999

Pire, on ne pouvait pas téléphoner avec le mobile de Iridium à partir des voitures, des bureaux ou des autres bâtiments, les téléphones devaient en fait être utilisés à l'extérieur pour une connexion directe avec les satellites. Quant au prix, c'était la goutte qui faisait déborder le vase. Au lieu des 50 centimes par minute d'un téléphone mobile normal, les appels par Iridium coûtait 7$ la minute, sachant que les utilisateurs devaient en plus payer 3000$ pour le combiné.

Au cours des onze années qui se sont écoulées depuis, le marché potentiel de Iridium a quasiment diminué chaque jour qui passait. Par contre, les hypothèses du modèle économique[4] de Iridium, elles, restaient figées comme en 1990. Iridium était mort à l'arrivée alors qu'elle se destinait à être le service de masse de la téléphonie mobile lorsqu'elle s'est lancée.

Aucune stratégie d'entreprise ne survit au premier contact avec un client

Le résultat a été un classique échec de création d'entreprise, au sens large. Iridium s'est entêté à suivre les hypothèses initiales de sa stratégie d'entreprise comme si elle avait passé un point de non retour. Ses erreurs ? Premièrement, en 1990, l'entreprise pensait qu'elle connaissait déjà la problématique de ses clients, et donc qu'elle connaissait déjà la solution à construire.

Deuxièmement, étant donné que Iridium connaissait la solution, elle s'est engagée dans un processus de développement en cascade[5] pendant 8 ans. Le développement en cascade est une méthode séquentielle de développement d'un produit (cahier des charges, conception, implémentation, vérification, déploiement). Cette méthode est pertinente dans un marché où le problème du client est connu et où tous les besoins du client et les fonctionnalités des produits peuvent être spécifiés à l'avance. Par contre, c'est la mort assurée sur un marché qui évolue rapidement. Le développement en cascade a donc freiné la capacité d'Iridium à écouter, apprendre, tester et s'adapter aux besoins changeants des clients sur un marché en évolution rapide.

Troisièmement, sa stratégie d'entreprise n'incluait pas les notions d'apprentissage et de découverte. L'idée d'itération était impensable. Sa stratégie d'entreprise était donc un document statique. Ce qui était formidable pour lever des fonds, pour communiquer dans les écoles de commerce et les grandes entreprises, mais complètement obsolète lorsqu'il a fallu la confronter aux réalités du marché de la téléphonie mobile en mutation constante. Lorsque la société s'est lancée, elle s'est heurtée à une diminution des clients et des marchés qui ne correspondaient pas à sa stratégie d'entreprise et ses projections financières, sans pour autant avoir la capacité de changer son modèle économique. Un processus de découverte et de validation de la clientèle, mené en parallèle du développement produit, aurait permis de réaliser plus tôt que le marché ne se développait pas en la faveur d'Iridium. Au lieu de ça, la direction d'Iridium était confortablement en train d'exécuter son plan initial.

Tout s'est écroulé d'un coup

Lorsqu'on ajoute à ce qui a été dit précédemment, l'orgueil de l'entreprise d'avoir levé des milliards de dollars, le fait qu'aucun adulte du conseil d'administration de Iridium ou de Motorola n'ait demandé "Est-ce que cela encore un sens ?", on aboutit à ce désastre. Au lieu des 42 millions de clients prévus initialement dans sa stratégie d'entreprise, Iridium a simplement eu un pic de 30 000 abonnés. La société a brûlé ses 5,2 milliards de dollars parce qu'elle est tombée amoureuse de la technologie, qu'elle a succombé au développement en cascade de produits et qu'elle n'a jamais pris la peine de sortir de l'immeuble, de sortir la tête de ses feuilles de calcul et de se demander "Qu'est-ce que veulent les clients aujourd'hui ?".

En 2000, de nouveaux investisseurs ont racheté les satellites Iridium et son réseau pour 25 millions $, soit un demi pour cent du capital investi. Aujourd'hui, la nouvelle entreprise dessert quelques 300 000 clients dans une série de marchés de niche incluant les soldats américains appelant leur foyer à partir de zones de combat, les responsables de plateformes pétrolières et les chasseurs de gros gibiers.

Une politique de développement de la clientèle, de conception du modèle économique et de développement Agile aurait pu complètement changer la donne.

Leçons apprises

- Les stratégies d'entreprise sont la principale cause de la mort prématurée des entreprises nouvellement créées.
- Aucune stratégie d'entreprise ne survit au premier contact avec un client.
- Des marchés en mutation constante requièrent le développement itératif d'un modèle économique continue en fonction du client.
- Votre capacité à lever des fonds n'a aucun lien avec l'adoption de votre produit par les clients.

Feedback :

  • Je remercie Ronan Amicel pour sa relecture de l'article traduit et ses propositions.

Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] startup

[2] business plan

[3] NdT : permet à une entreprise en difficultés financières de continuer à fonctionner normalement, tout en lui laissant le temps de chercher un accord avec ses créanciers.

[4] business model

[5] Waterfall

lundi, 18 juillet 2011

Le Jidoka ce n'est pas juste "la qualité intrinsèque"

Jason YipJ'ai traduit ce billet de Jason Yip : Jidoka is not just "built-in-quality".

Parfois, les gens utilisent les termes "qualité intrinsèque" ou "arrêtez et réparez" à la place de jidoka et je me suis rendu compte que ce n'était pas exact.

Le jidoka n'est pas seulement le fait d'arrêter ​​le processus et de notifier immédiatement les problèmes. Il inclut également le concept de séparation du travail de l'être humain et de la machine. En fait l'idée d'utiliser des machines pour libérer les êtres humains. Les machines travaillent pour nous, nous ne travaillons pas pour elles.

Si nous considérons l'aspect arrêt et notification, cela ne concerne pas vraiment ​​les arrêts automatiques et les indicateurs visuels. C'est beaucoup plus critique, on parle de gens qui voient les problèmes et qui tirent les cordons des andons[1], de gens qui interprètent ce qui se passe réellement.


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] Ndt : voir Andon (gestion)

dimanche, 17 juillet 2011

Les 14 points de Deming

David JoyceJ'ai traduit ce billet de David Joyce : "Deming’s 14 Points". Je trouve incroyable que Deming ait réussi à observer, expérimenter et théoriser tant de choses... et que nos qualiticiens ne nous parlent que de la roue PDCA ! Chacun de ses 14 points tape juste et fait (très très) mal... en fait on n'a pas progressé d'un iota, c'est navrant.

Les 14 points de W. Edwards Deming sont les fondements de la transformation de l'industrie. L'adoption et la mise en œuvre des 14 points constituent un message fort comme quoi le management a bien l'intention de poursuivre les activités de l'entreprise, de protéger les investisseurs et les emplois. Un tel système fut à la base des leçons données au top management japonais à partir de 1950.

Les 14 points s'appliquent partout, pour de petites organisations aussi bien que pour des grandes, aux services aussi bien qu'à l'industrie. Ils s'appliquent aussi bien à toute entité au sein d'une entreprise qu'à ses fournisseurs.

Pendant que vous lirez ces 14 points, demandez-vous s'ils s'appliquent encore aujourd'hui, soit au sein de votre organisation actuelle, soit au sein des organisations dans lesquelles vous avez récemment travaillé. Les réponses pourraient être surprenantes.

1. Des objectifs stables

Créez une stabilité dans les objectifs d'amélioration continue de vos produits et services, avec un plan pour devenir compétitif et pour poursuivre les activités de l'entreprise.

Deming point 1Le management a deux préoccupations. L'une traite de diriger l'entreprise au jour le jour. L'autre porte sur l'avenir de l'entreprise.

Le management doit avoir les idées claires sur ces questions ; que faisons-nous et pourquoi le faisons-nous ?

La réponse à ces questions nécessite d'avoir certaines connaissances et de regarder vers l'avenir. C'est la différence entre la vision à court terme et la vision à long terme ; la tortue et le lièvre.

La capacité à traiter les problèmes futurs exige d'avoir des objectifs stables et la véritable volonté de s'améliorer.

Créez une stabilité dans les objectifs d'amélioration continue de vos produits et services, allouez des ressources pour répondre aux besoins à long terme plutôt qu'uniquement à une rentabilité court terme, avec pour objectif de devenir compétitif, poursuivre les activités de l'entreprise et offrir des emplois.

Poursuivre les activités de l'entreprise exige que les leaders passent du temps sur l'innovation, la recherche et la formation. Ils doivent constamment améliorer la conception de leurs produits et services.

L'objectif est une intention, un but, une vision d'une situation future souhaitée. Pour avoir un objectif stable, on doit d'abord avoir un objectif.

2. Une nouvelle philosophie

Nous sommes entrés dans une nouvelle ère économique, créée au Japon. Le management doit se réveiller devant ce défi, doit apprendre ses nouvelles responsabilités et prendre le leadership du changement.

Deming point 2L'amélioration ne s'arrête jamais. Le système est capricieux, imprévisible, il aura des impacts différents sur les individus d'un mois sur l'autre. C'est pourquoi vous avez besoin d'amélioration continue, cela ne peut jamais finir puisque le changement ne finit jamais.

Les demandes et les goûts des clients changent très vite, et la concurrence sur le marché croît à un rythme rapide aujourd'hui.

Henry Ward Beecher a déclaré : "La philosophie d'un siècle est le sens commun du suivant." ; nous devons accepter de nouvelles philosophies selon les tendances du marché et les révolutions technologiques.

Apprendre et adopter une toute nouvelle philosophie, celle de la coopération au bénéfice de tous.

Le management doit se réveiller devant ce défi, il doit apprendre ses nouvelles responsabilités et prendre le leadership du changement.

Nous sommes dans une nouvelle ère économique, créée au Japon. Nous ne pouvons plus vivre avec des niveaux de retard, d'erreurs, de matériels défectueux et de fabrication défectueuse communément admis. Aujourd'hui, nous ne pouvons plus accepter les niveaux d'erreur qui étaient encore tolérés hier. Les produits et les services défectueux représentent un coût pour le système.

Seul le management est en mesure de faire quelque chose pour la grande majorité des erreurs. La transformation du style de management occidental est nécessaire pour enrayer le déclin continu de l'activité et de l'industrie.

Cela fait partie des tâches du management d'éliminer les obstacles qui empêchent les personnes de faire leur travail correctement.

3. Arrêtez d'être dépendant aux contrôles de masse

Éliminez la dépendance aux contrôles pour atteindre la qualité. Éliminez le besoin de contrôle de masse en construisant la qualité intrinsèque au produit d'abord.

Deming point 3Vous ne pouvez pas économiser de l'argent si vous êtes plus préoccupé par l'argent que vous ne l'êtes par la qualité.

Arrêtez d'être dépendant aux contrôles de masse pour atteindre la qualité. Les contrôles de masse ne sont pas fiables. Le contrôle rassure, mais c'est faux.

Vous ne pouvez pas contrôler la qualité, et pourtant nous avons des organisations utilisant l'ISO et les audits comme un moyen de prouver la qualité.

Les contrôles de routine reviennent à la même chose que planifier les défauts, reconnaître que le processus n'est pas correct ou que les spécifications n'ont pas de sens. Le contrôle a lieu trop tard, est trop inefficace et coûteux.

Demandez plutôt des preuves statistiques que la qualité intrinsèque existe.

La qualité ne provient pas des contrôles, mais de l'amélioration du processus. Améliorez le processus de sorte que les défauts ne soient pas générés dès le départ. Ceci élimine le besoin des contrôles de masse.

Éliminez la nécessité de recourir à des contrôles de masse, puisque votre démarche pour atteindre la qualité passe par la construction de la qualité intrinsèque au produit d'abord. Exigez la preuve statistique de l'amélioration de la qualité.

Vous ne pouvez pas économiser de l'argent si vous êtes plus préoccupé par l'argent que vous ne l'êtes par la qualité.

4. Mettez fin à la politique d'achat au plus bas prix

Mettez fin aux pratiques d'attribution des contrats sur la seule base de l'étiquette du prix. Cherchez plutôt à minimiser le coût total. Privilégiez un fournisseur unique pour chacun des articles et une relation à long terme basée sur la loyauté et la confiance.

Deming point 4Sans mesures adéquates de la qualité, les entreprises se dirigent vers le soumissionnaire offrant le prix le plus bas, par conséquent, le résultat est de faible qualité et de coût élevé.

Le prix n'a aucun sens sans mesure de la qualité achetée.

Mettez fin aux pratiques d'attribution des contrats sur la seule base de l'étiquette du prix. Exigez plutôt des mesures significatives de la qualité par rapport au prix.

Réduisez le nombre de fournisseurs pour le même article, en éliminant ceux qui sortent des statistiques ou autres preuves de qualité.

L'objectif pour les deux parties est de travailler ensemble en minimisant les variations de qualité pour l'augmenter, de minimiser le coût total (et non simplement les coûts initiaux) pour les deux parties.

Ceci peut être atteint en sélectionnant un fournisseur unique pour chacun des articles, sur la base d'une relation à long terme basée sur la loyauté et la confiance.

Cela conduira à une amélioration continue entre les deux parties et, par conséquent, vous obtiendrez des fournitures de qualité à coûts réduits. C'est pourquoi les constructeurs japonais sont si étroitement liés à leurs fournisseurs.

Nous dépensons souvent beaucoup de temps et d'argent pour trouver de meilleurs fournisseurs et passer rapidement de l'un à l'autre pour finalement opérer de légers gains financiers. Au lieu de demander que les fournisseurs se concurrencent uniquement sur le prix, pensez sur le long terme. Les directeurs des achats ont un nouvel emploi et ils doivent l'apprendre.

Aujourd'hui, de nombreux organismes se contentent simplement d'externaliser vers le fournisseur le moins cher, et multiplient souvent le nombre de fournisseurs au sein de la même entité métier ou projet.

5. Améliorez chaque processus

Améliorez constamment et perpétuellement le système de production et les services, pour améliorer la qualité et la productivité, diminuant ainsi les coûts.

Deming point 5Améliorez constamment et perpétuellement le système de production et les services pour améliorer la qualité et la productivité, diminuant ainsi les coûts.

Acceptez que rien ne soit jamais assez bon. Améliorez sans cesse tous les processus de planification, de production et de service.

L'amélioration n'est pas un projet avec une date de fin. Pensez plutôt amélioration continue et perpétuelle.

Instaurez l'innovation.
Chacun doit chercher continuellement des problèmes afin d'améliorer toutes les activités de l'entreprise, d'améliorer la qualité et la productivité et donc de constamment diminuer les coûts.

Trouver ce qui cloche n'est pas une amélioration. Boucher des fuites n'est pas une amélioration. Ne regardez pas les résultats ou les défauts, regardez plutôt ce que produisent les défauts.

Il devrait y avoir une formation permanente sur les gaspillages et une amélioration continue de la qualité dans chaque activité, cela augmenterait de façon continue la productivité.

Il incombe au management de travailler en permanence sur le système (par exemple la conception du travail, le travail à planifier, l'amélioration des outils, la supervision, la formation continue). Il n'y a aucun point d'arrêt dans le processus de gestion de la qualité.

Le système de l'entreprise et les services doivent continuer à croître indéfiniment, afin de rattraper le marché concurrentiel.

6. Instaurez la formation sur le lieu du travail

Instaurez des méthodes modernes de formation sur le lieu du travail.

Deming point 6Fournissez apprentissage et développement aux personnes. Instaurez la formation sur le lieu de travail, la formation pour développer de nouvelles compétences.

Les gens apprennent de différentes manières. Le processus de formation doit être totalement reconstruit.

Lorsqu'ils se forment, les gens doivent comprendre en quoi consiste leur travail et pourquoi il faut le faire.

La formation doit être faite sur le lieu de travail, c'est-à-dire l'apprentissage par la pratique ; rentrez dans les problématiques du travail, expérimentez des méthodes de travail et de nouvelles idées, étudiez les résultats et visez la perfection.

Un employé formé génère plus de productivité et de qualité qu'un employé non formé, donc tenir des sessions de formation améliorera considérablement la qualité de la personne et contribue aussi directement à une meilleure performance à l'égard de la qualité du produit.

Instaurez des méthodes modernes de formation sur le lieu de travail pour tous, y compris pour le management, pour faire un meilleur usage de chaque employé.

De nouvelles compétences sont nécessaires pour s'adapter aux changements d'outils, de méthodes, de techniques, de conception des produits et des services.

7. Instaurez le leadership des personnes

L'objectif du management devrait être d'aider les individus à faire un meilleur travail. Le management a besoin d'être rénové.

Deming point 7Le leadership est requis, pas le contrôle.

Le leadership a besoin d'être rénové, le travail des managers est d'aider les individus.

Adoptez et instaurez le leadership vise à aider les individus à faire un meilleur travail.

Adoptez et instaurez des principes pour l'amélioration du leadership.

Le management ne doit plus être fondé sur la culture absolue des chiffres mais sur la qualité. L'amélioration de la qualité provoquera automatiquement l'amélioration de la productivité.

Le management doit s'assurer que l'analyse et les mesures sont prises sur la base des rapports d'anomalies, des conditions du système, des mauvais outils, de procédures opérationnelles floues, des changements et de toutes conditions nuisibles à la qualité. Vous ne pouvez pas déléguer la qualité, c'est une route qui mène à l'échec assuré.

Le principe de base est que c'est le travail des managers de coacher leur personnel et d'améliorer le système :

- Premièrement, ils doivent passer du temps au travail à renforcer l'engagement de l'organisation envers ses clients et la qualité.
- Deuxièmement, ils consacrent du temps à s'assurer que le personnel qui effectue le travail a tout ce qu'il faut pour être en mesure de servir le client.
- Troisièmement, quand ils ont une décision à prendre au sujet de ce qui précède, ils cherchent à obtenir plus d'informations pour fonder leurs décisions. Il n'y a pas de réflexe automatique, ils apprennent plutôt à acquérir la connaissance.

8. Chassez la peur

Chassez la peur afin que chacun puisse travailler efficacement pour l'entreprise.

Deming point 8Faites disparaître les craintes afin que tout le monde puisse travailler efficacement pour l'organisation.

Construire la confiance. La coopération et la collaboration exigent des valeurs et des relations différentes de celles utilisées dans la méthode obsolète qu'est le contrôle-commande.

Les personnes ont peur du changement, toute tentative pour améliorer les choses conduira à une peur de l'inconnu.

De nombreuses organisations sont dirigées par la peur ; la peur de ne pas obtenir sa prime, la peur de ne pas pouvoir réussir son évaluation annuelle ou d'être en dessous des échelles de notation annuelle.

Pour atteindre une meilleure qualité, les individus ont besoin de se sentir en sécurité. Nous devons éliminer la peur afin que chacun puisse travailler efficacement pour l'entreprise. La peur va disparaître au fur et à mesure que le management s'améliore et que les employés développent une confiance dans le management.

Maîtriser notre peur fait partie d'au moins 8 des 14 points.

9. Brisez les barrières

Brisez les barrières entre les départements. Les gens travaillant dans les services de recherche, de conception, de vente, de technologie et de production doivent travailler en équipe.

Deming point 9Brisez les barrières et les silos entre les départements. En d'autres termes construisez un système.

Traditionnellement, les silos deviennent des royaumes indépendants, chacun essayant de maximiser ses propres chiffres.

Les gens travaillant dans les services de recherche, de conception, de vente, de technologie et de production doivent travailler en équipe pour être capable de prévoir tous les problèmes liés à la production, aux produits ou aux services.

A moins que le personnel se mette à travailler ensemble dans un esprit de coopération, chaque domaine va essayer de faire ce qui est le meilleur pour lui-même, plutôt que ce qui est bon pour l'organisation. Coopération et non compétition : tout le monde gagne si le système gagne.

10. Éliminez les slogans

Éliminez l'utilisation de slogans exhortant les employés à atteindre le zéro défaut et de nouveaux niveaux de productivité.

- Éliminez les quotas au travail. Remplacez par le leadership.
- Éliminez le management par les objectifs. Remplacez par le leadership.
- Éliminez le management par les chiffres, les objectifs chiffrés. Remplacez par le leadership.

Deming point 10Éliminez les slogans, les avertissements et les objectifs exhortant les employés à faire bien du premier coup, à atteindre le zéro défaut et de nouveaux niveaux de productivité. Une telle pression ne peut uniquement générer que des réactions d'hostilité.

Des posters affichent ce que les gens ne peuvent pas faire.

Des posters et des slogans sur les murs indiquent "Faites bien du premier coup" ; qui peut faire bien du premier coup, lorsque le sujet sur lequel doit travailler la personne est déjà mauvais ?

Les causes vont au-delà du pouvoir des employés, puisque la majorité des causes de faible qualité et de faible productivité sont générés par le système.

Si le système a été construit autour de la qualité, alors il fera bon du premier coup, de sorte que le slogan sera dénué de sens.

Assurez-vous de remplacer les quotas de travail par un leadership efficace et des méthodes efficaces. Remplacez le management (par objectifs, chiffres et objectifs chiffrés) par un leadership efficace.

11. Éliminez les objectifs chiffrés fixés arbitrairement

Éliminez les normes de travail qui prescrivent des quotas aux employés et des objectifs chiffrés pour le management. Les responsabilités du management doivent évoluées d'une culture unique des nombres à celle de la qualité.

Deming point 11Les objectifs chiffrés n'accomplissent rien.

Traditionnellement, on a plus de règles sur la quantité que la qualité.

Les coûts que vous générez en accordant plus d'attention aux nombres qu'à la qualité sont énormes, il en résulte des coûts élevés à rechercher et résoudre les erreurs. Cet argent dépensé ne produit rien.

Concentrez-vous sur la qualité plutôt que sur la quantité de produit. Supprimez les obstacles privant les employés de leur droit d'être fiers de leur travail. Les managers doivent se concentrer sur la qualité, plutôt qu'absolument sur des chiffres.

Remplacez tout par un leadership utile qui permette d'atteindre l'amélioration continue de la qualité et de la productivité.

Un système d'amélioration continue génère une production de meilleure qualité à moindres coûts. L'accent est mis non pas sur la quantité mais sur la façon dont vous réussissez à bien faire.

12. Autorisez la fierté au travail

Supprimez les obstacles qui privent les employés et les managers de leur droit d'être fier de leur travail. Cela signifie, par exemple, l'abolition de la note annuelle au mérite et du management par objectif.

Deming point 12Supprimez les obstacles et les barrières qui privent les employés et les managers de leur droit d'être fiers et d'avoir du plaisir dans leur travail. Cela implique l'abolition de la notation annuelle au mérite (évaluation de la performance) et du management par objectif, à l'origine des conflits et de la compétition.

Ces barrières à la fierté (un besoin humain fondamental) génèrent entre autres un moral bas et de l'absentéisme.

Nous avons besoin de gens qui soient fiers de leur travail et non pas qui soient capables de bien se classer.

Encore une fois, les responsabilités des chefs d'équipe, managers, directeurs et dirigeants doivent passer d'une culture absolue du nombre à celle de la qualité.

Pourquoi fixer des objectifs aux employés et chercher à les classer dans l'entreprise, insuffler un esprit de compétition au sein de cette organisation. Nous voulons de la collaboration et non de la compétition.

Impliquez les employés, à tous les niveaux, dans le processus d'amélioration. Fournissez aux employés les méthodes, le matériel et outils appropriés. Les managers travaillent sur le système qui fait obstacle à la performance.

13. Encouragez la formation

Instaurez un programme énergique de formation et d'auto-amélioration.

Deming point 13Instaurez un programme énergique de formation et encouragez l'amélioration pour chacun.

Une organisation n'a pas juste besoin de gens qui soient bons ; elle a besoin de personnes qui s'améliorent par la formation.

La formation ne doit pas être un sujet relié à leur travail.

L'auto-amélioration maintient en éveil l'esprit des gens. Le point 6 concerne la formation au travail, le point 13 fait progresser l'esprit des gens.

Les progrès dans votre positionnement concurrentiel ont leurs racines dans la connaissance. Aucune organisation ne peut survivre juste avec des gens bons, elle a besoin de gens qui s'améliorent.

14. Engagement du top management et mise en action

Engagez tout le monde dans le travail de transformation de l'entreprise. La transformation est l'affaire de tous.

Deming point 14Engagez tout le monde dans l'entreprise pour accomplir le changement.

Développez une masse critique qui puisse provoquer le changement ; une masse critique incluant le top management.

Créez une structure de management qui prendra une part active et consacrera du temps au renforcement des 14 points et sur l'engagement de l'organisation envers ses clients et la qualité.

Les managers doivent consacrer du temps à s'assurer que les employés disposeront de tout ce qu'il faut pour être en mesure de servir le client. Ils utilisent des données et des connaissances réelles obtenues du point de vue du client pour prendre des décisions.

Sans une telle structure, vous n'obtiendrez aucun bénéfice viable sur le long terme.

Résumé

Les 14 points ne sont pas un supermarché dans lequel vous faites vos courses. Deming prévoyait que vous utilisiez les 14. Ils constituent une véritable philosophie.

"Le moyen de ne pas dépendre du contrôle de masse (point 3) est d'améliorer continuellement le processus (point 5), pour ce faire vous aurez besoin de fournitures de qualité (point 4), trouver un fournisseur de qualité prendra du temps (point 1), vous aurez donc besoin d'adopter la philosophie (point 2)." Lloyd Dobbins

"Nous voulons que les gens travaillent ensemble, mais il est difficile de le faire sans les points 8, 9, 10, 11 et 12. Lloyd Dobbins

Les 14 points s'appliquent partout, des petites organisations aux grandes, des services à l'industrie. Ils s'appliquent également à toute entité au sein d'une entreprise.

"Les 14 points ont tous un seul but : permettre aux gens de travailler avec joie et fierté." Deming

Source : CC-M Productions, Inc. 7755 16th Street, NW Washington, DC 20012 ManagementWisdom.com (800) 453-6280wbob@cc-m.com

Source : Vanguard http://www.systemsthinking.co.uk/home.asp

Source : Vanguard Scotland http://www.systemsthinkingmethod.com/

Source : Illustrations par Pat Oliphant http://www.managementwisdom.com/freilofdem14.html


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

vendredi, 15 juillet 2011

Raccourcir la queue de release

Jim HighsmithJe rentre de la plage et je tombe sur ce billet de Jim Highsmith : "Shortening the Tail" que j'ai traduit dans la foulée en attendant l'apéritif dînatoire :)

Raccourcir la queue de releaseDans mon livre Agile Project Management, j'ai écrit un court chapitre sur un indicateur de performance que j'ai appelé "raccourcir la queue de release". J'aime utiliser cet indicateur, la longueur de la queue de release, car elle est facile à calculer et en dit beaucoup sur la mise en œuvre de l'Agile dans une organisation. Ce n'est pas un joli indicateur qui ne vous donne aucun élément de décision[1], comme par exemple le nombre de développeurs qui participent à un séminaire de refactoring, mais un véritable indicateur qui vous permet d'en apprendre plus et qui se concentre sur un point clé du développement et du test logiciel en Agile. C'est aussi un indicateur qui peut aider une organisation à se rapprocher de la la notion de Livraison Continue[2].

La queue de release est la période qui s'étend entre le "la soupe de code"[3] (le vrai gel de code[4] reste rare) ou "gel des fonctionnalités"[5] et le déploiement effectif des fonctionnalités. C'est la période pendant laquelle les entreprises font tout ou partie des activités suivantes : bêta-tests, tests de non régression, intégration de produits, tests d'intégration, documentation, corrections d'anomalies. La pire "queue de release" que j'ai rencontrée était de 18 mois - du gel des fonctionnalités à la livraison du produit - et la plus grande partie du temps était consacrée à la QA. Régulièrement, je rencontre des sociétés de logiciels dont la queue de release est de 4 à 6 mois pour un cycle de version de 12 mois. Après, il y a d'autres sociétés, et un nombre croissant dans le logiciel, qui ont optimisé leurs processus pour obtenir une queue de release de longueur zéro, elles réalisent vraiment une Livraison Continue et un Déploiement Continu[6]. Utiliser l'indicateur longueur de la queue de release, en particulier pour les produits ou les applications qui disposent d'un grand patrimoine de code, peut aider les organisations à mesurer leur progrès vers un Déploiement Continu.

Il y a plusieurs années, j'ai travaillé avec une organisation qui avait une queue de release de 6 mois dans un cycle de version de 12 mois et la queue devenait progressivement de plus en plus longue à chaque nouvelle version. La queue de release était passée de 4 à 6 mois au cours des 3 derniers cycles de version. La société s'était fixée l'objectif d'atteindre une queue de 1 mois et a travaillé avec assiduité pour atteindre cet objectif au fil du temps.

Raccourcir la queue de release est un moyen simple, un indicateur puissant pour mesurer les progrès vers l'agilité. L'objectif des équipes agiles est de produire des logiciels déployables à chaque itération, mais la plupart sont loin de cet objectif, surtout si des équipes héritent de patrimoines de code conséquents et anciens. Pensez à tout ce qu'une entreprise peut avoir à faire pour réduire une queue de six à trois mois puis à un mois puis finalement à un jour. Elle devra apprendre à faire de l'intégration continue pour l'ensemble de ses produits. Elle devra améliorer son niveau de tests automatisés pour conduire des tests de non régression et d'intégration dans chaque itération. Elle devra améliorer le niveau de tests unitaires automatisés faits par ses développeurs pour réduire les temps de test à la fin des itérations et des versions. Elle devra impliquer ses clients beaucoup plus tôt dans le processus de développement, en n'attendant pas jusqu'au dernier moment pour les bêta-tests. Elle devra intégrer des spécialistes de la documentation dans l'équipe et produire de la documentation en continu pendant les itérations. Elle devra investir dans le refactoring systématique pour réduire la dette technique et donc réduire le temps consacré aux activités de tests et de corrections d'anomalies.

Vous pouvez probablement penser à d'autres choses que l'entreprise devra faire. Chacun de ces éléments contribuera d'une certaine façon, grande ou petite, à la réduction de la longueur de la queue de release en nombre de jours ou de semaines. Pour les gros produits, la queue de release ne sera jamais nulle, mais elle pourra être de petite taille. Pensez juste au désavantage concurrentiel dont souffre une entreprise quand sa queue de release est de 18 mois, voire 6 mois. Cela signifie que pendant les 6 ou 18 mois précédant la livraison, aucun changement dans l'environnement concurrentiel ne pourra être incorporé dans ses produits. Si la Livraison Continue semble un trop grand pas en avant, commencez sur cette voie en réduisant d'abord la longueur de la queue des versions de votre produit, petit à petit la Livraison Continue ne vous semblera plus aussi inaccessible.


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] Vanity metric

[2] Continuous Delivery

[3] code slush

[4] code freeze

[5] feature freeze

[6] Continuous Deployment

jeudi, 14 juillet 2011

Appliquer Kanban aux processus informatiques (5)

J'ai traduit ce cinquième et dernier billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 5). Globalement, j'ai pris beaucoup de plaisir à traduire cette série d'articles, que je dédie à Xavier, mon ScrumMaster préféré au boulot et qui souffre en ce moment de Scrumbanite aiguë... y a pas de vaccin :)

Cet article est le cinquième et dernier d'une série qui décrit les bases de Kanban et son application dans les processus informatiques :
- La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l'industrie.
- La deuxième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un service helpdesk (fictif).
- La troisième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un projet de déploiement de PC (fictif).
- La quatrième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un projet de développement logiciel (fictif).

Dans chacune de ces histoires, la mise en œuvre de Kanban est réussie et il y a des améliorations positives sur une période de temps assez courte. Ce dernier article aborde brièvement certains des défis auxquels il faut faire souvent face et le concept d'amélioration continue. Contrairement aux articles précédents de la série, celui-ci n'a pas d'illustrations, donc je m'excuse d'avance auprès des membres qui préfèrent lire plus d'images que de texte (George * tousse *).

Mettre en œuvre Kanban

Les histoires fictives narrées dans les articles précédents ont toutes suivi un thème commun, l'amélioration réussie du processus en faisant face à peu voire pas de défis. Toutefois, pour ceux d'entre nous qui travaillent dans le monde réel, nous sommes tous conscients qu'aucun projet ou processus ne peut être lancé sans rencontrer de difficultés. Même si s'attaquer à tous les défis potentiels - que l'on pourrait relever dans l'environnement de chaque lecteur - va bien au-delà de mes compétences et de la portée du présent article, il y a deux défis auxquels la plupart d'entre nous devront faire face dans la mise en œuvre de Kanban dans les environnements informatiques.

Changer les habitudes

En plus des défis qui consistent à définir nos processus et à tenter de standardiser des tâches qui sont souvent des exceptions, appliquer un processus Kanban va également nous obliger à remettre en question certaines habitudes bien ancrées. L'idée de limiter la quantité de travail en cours (WIP) dans une étape peut sembler bonne lorsque vous la lisez dans un article, mais en fait se soumettre à des limites est très difficile au début. Les divers styles de management ont tendance à se concentrer sur le temps passé à travailler ou sur le nombre de tâches qu'une personne a terminées et, dans ce cas, s'arrêter de travailler pendant une étape est apparenté à croiser ses pieds sur son bureau et faire une sieste.

Kanban nous oblige à faire face à ces systèmes de mesure et à corriger certains des défauts auxquels ils mènent dans nos processus. Plutôt que de mesurer à quel point une personne travaille dur pendant une étape, nous allons mesurer la façon dont nous livrons à travers le processus entier. Plutôt que de mesurer le nombre d'heures travaillées par une personne, on peut mesurer le nombre d'heures de travail que nous avons gagnées dans le processus. Là où l'ancien système de mesures se demande pourquoi nous n'empilons pas plus de travail entre les étapes de Développement et de QA, Kanban nous oblige à remettre en question la façon dont nous pouvons améliorer le débit ou diminuer le taux de rework[1]. Des habitudes bien ancrées sont difficiles à changer. Au lieu de directement remettre en cause ces croyances, nous allons commencer par modéliser le processus et les tâches qui y circulent. Il y a quelques défis à relever dans ce processus de modélisation, mais une fois que la visualisation est en place et que vous commencez à impliquer les autres dans le fait d'améliorer cette visualisation et donc le suivi des tâches, beaucoup de ces défis vont disparaître. La capacité à voir le flux des tâches s'écouler à travers le processus répond au besoin de nombreuses personnes, en offrant une visibilité et un aperçu du processus qui, auparavant, étaient dirigés par l'estimation et des conjectures occasionnelles.

L'informatique ce n'est pas une chaîne de fabrication industrielle

Un autre défi fréquent que l'on rencontre avec Kanban c'est que, tirant son origine de l'industrie[2], on considère du coup qu'il n'est pas approprié pour un environnement informatique. C'est un argument très largement opposé à Kanban (et aux principes du Lean en général), et il a été solidement réfuté dans un grand nombre d'industries. L'idée que des pratiques ou des connaissances d'une industrie ne peuvent pas être utilisées pour améliorer notre compréhension dans d'autres types d'industrie, semble un peu égoïste, surtout lorsqu'on ajoute qu'un domaine est trop spécialisé pour apprendre quelque chose des autres. Si tel était vraiment le cas, les progrès médicaux réalisés grâce au programme spatial n'auraient jamais eu lieu, pas plus que des centaines d'autres concepts et idées qui ont traversé les frontières de l'industrie pour générer de nouvelles idées ou produits dans d'autres types d'industrie.

Parfois l'argument est formulé de manière plus nuancé, en citant la différence entre les usines de fabrication produisant des pièces identiques et en série et les tâches en constante évolution dans un environnement informatique. Passez quelques minutes sur votre moteur de recherche préféré et vous trouverez des exemples dans un certain nombre d'industries, y compris le développement logiciel, où Kanban a non seulement été mis en œuvre avec succès, mais a montré le chemin vers l'amélioration continue et d'autres pratiques ayant des racines dans les chaînes de fabrication industrielles. Bien que cela ne soit pas une réponse formelle ou philosophique, je ne vois pas pourquoi on passerait du temps à formuler une preuve logique pour quelque chose de si facilement observable.

Appliquer Kanban n'est pas sorcier, mais il exige de la réflexion et du temps. Heureusement, il y a des communautés entières de gens qui sont prêts à répondre à vos questions, à faire appel à des experts et à proposer de bons livres.

Pourquoi Kanban

Les articles précédents ont illustré la mise en œuvre de Kanban dans des environnements fictifs, mais nous n'avons pas passé beaucoup de temps à expliquer comment ou pourquoi il fonctionnait comme cela. Les articles n'ont pas donné de détails sur les méthodes utilisées par les équipes pour identifier des zones d'amélioration ou la façon dont ces améliorations ont été traitées. Opérer des changements dans des processus réels peut être aussi simple que nos histoires mais parfois un peu plus difficile. Ce que Kanban nous offre, c'est un outil qui nous aide à localiser les points chauds[3] sur lesquels concentrer nos efforts pour obtenir le plus grand effet de levier.

Au fur et à mesure que nous mettons en œuvre Kanban, nous commençons à réaliser les tâches d'une manière cohérente. Cette cohérence améliore notre vitesse d'exécution parce que nous pouvons faire des hypothèses sur les tâches que nous recevons ; elles répondent à un certain niveau de conformité et partagent un certain ensemble d'exigences et de caractéristiques. Cela réduit le nombre de fois où nous étions amenés à retourner sur les étapes amonts, à router les tâches vers de nouvelles étapes exceptionnelles, ou à inventer des processus à la volée. L'acte en lui-même de créer le tableau Kanban nous aide à trouver ou à construire cette cohérence, et réduit encore davantage le temps perdu à déterminer où les tâches devaient être routées ou à connaître leurs statuts actuels. Le tableau fournit une vue haut niveau des tâches ou des groupes de tâches se déplaçant à travers le processus, faisant clairement apparaître les goulots d'étranglement et les remous dans le flux, ceux-là même qui ne sont pas visibles de l'intérieur du processus. L'analyse des causes racines des goulots d'étranglement nous montre les endroits où mener une amélioration locale sur une étape qui peut directement entraîner une amélioration du processus dans son ensemble.

Amélioration continue

Le terme "Amélioration Continue" est apparu dans plusieurs articles et le concept est présent dans chacun d'eux. Le principe de l'amélioration continue est de faire de petites et progressives améliorations à un processus qui, sur le long terme, permettront d'obtenir de grosses économies et des améliorations sur la qualité. Des améliorations individuelles sont obtenues par la recherche et l'analyse d'un gaspillage dans le processus (tels que le gaspillage de matériel, le mouvement et les risques de sécurité) ou de plusieurs gaspillages dans une seule étape du processus (tels que la détection des défauts dans l'article concernant le développement de logiciels). En déterminant la cause racine de ce(s) gaspillage(s), et en effectuant des petits ajustements sur le processus pour réduire ou éliminer ce gaspillage, les objectifs ou les méthodes d'amélioration deviennent utilisables. En éliminant lentement mais sûrement les gaspillages dans nos processus, nous améliorons la qualité, les coûts et le rythme de notre processus.

Kanban soutient ces efforts d'Amélioration Continue en fournissant un flux cohérent et la visualisation de notre processus. La visualisation et la standardisation du processus permet de rendre davantage visible les exceptions et les goulets d'étranglement, nous donnant des pistes claires d'amélioration. Une fois que les améliorations ont été réalisées, le tableau Kanban peut alors nous montrer la manière dont ces changements ont affecté et amélioré le processus dans son ensemble, si ces améliorations ont permis de découvrir de nouveaux problèmes, ou si elles ont échoué à résoudre le problème à la racine.

Coûts et Qualité

Bien que Kanban nous fournisse la capacité à localiser les problèmes et à améliorer le processus, ce qui permet de réduire nos délais de livraison, il ne fournit pas nécessairement des outils pour réduire les coûts ou améliorer la qualité. Bien que nous ayons vu la qualité et les coûts améliorés dans nos articles fictifs, cela a été souvent été une conséquence de l'amélioration du temps de cycle en éliminant un goulot d'étranglement. Cependant, Kanban nous fournit quelques indications qui peuvent être réutilisées. Comme avec le temps de cycle, si nous voulons améliorer la qualité ou les coûts, nous devons utiliser notre processus et localiser où nos problèmes de coûts et de qualité apparaissent et nous concentrer sur ces zones.

Exemple d'amélioration continue

Par exemple, si nous souhaitons nous concentrer sur la qualité, nous pouvons créer des standards définissant le niveau de qualité dans notre produit final et commencer à tester leur respect. Pendant les tests, nous pouvons suivre les cartes (ou lots) qui échouent sur le test de qualité et qui génèrent du rework (article 3) ou qui sont abandonnées et ensuite remplacées suite à un travail supplémentaire. En utilisant la fréquence d'apparition des problèmes et les coûts générés pour produire une tâche avant que chaque problème de qualité soit trouvé, nous pouvons créer une répartition des coûts assez simple pour déterminer nos plus grosses opportunités d'amélioration. Dans certains cas, nous pouvons constater les problèmes de qualité en dehors de notre processus, dans d'autres processus, et nous devons donc conduire les tests le plus tôt possible dans notre processus pour réduire les efforts investis avant que les problèmes soient découverts.

Qualité / Délais / Coûts : le tout ensemble, svp

En informatique, nous citons souvent le triangle coûts / qualité / délais aux personnes qui s'attendent à avoir les trois ensemble sans aucun travail ou investissement supplémentaire. En utilisant l'exemple ci-dessus, on pourrait facilement remplacer la qualité par les coûts et construire une méthode simple pour trouver les meilleures opportunités de réduction des coûts. Mais étant donné que les gaspillages impactent souvent plus d'un sommet du triangle, on peut choisir d'améliorer nos temps de cycle, la qualité ou les coûts et du coup améliorer les autres.

Il n'est pas rare dans le monde de l'industrie de diminuer les problèmes de qualité, de délais et de coûts suffisamment pour améliorer la capacité de 25 à 50%, et ceci sans embaucher de nouveaux employés ou acheter de nouveaux équipements. En informatique, on compte souvent sur la technologie pour améliorer les choses, mais la technologie est quelque chose que n'importe lequel de nos concurrents peut acheter et la disponibilité est dictée par le marché, et non par nos besoins. Pour prendre de l'avance sur nos délais et nos concurrents, pour passer des vacances tranquilles ou pour obtenir des augmentations qui soient au-dessus du taux d'inflation annuel, nous devons aller au-delà de ce que les fournisseurs offrent et créer une meilleure qualité de service et un meilleur engagement de l'entreprise. Réduire les coûts, améliorer la qualité et réduire les délais de livraison impactent la dernière ligne du bilan de fin d'année et améliorent l'efficacité du reste de l'entreprise. Et dans le cas où une entreprise est moins intéressée par l'efficacité et plus intéressée par le nombre d'heures sur l'horloge, des améliorations successives peuvent aussi constituer d'excellentes expériences sur les CVs.

Plus d'opportunités

Il y a beaucoup d'autres possibilités pour Kanban que celles décrites dans mes autres articles, et il existe de nombreux autres articles de fond. Les trois exemples contenus dans les articles précédents ont été choisis pour exposer une grande variété de problèmes :

- Un helpdesk qui gère un nombre inconnu de tâches à la demande, chacune composée d'un ensemble complètement différent de sous-tâches
- Un processus de déploiement de PC semblable à une chaîne de fabrication, mais nécessitant deux personnes pour s'occuper des multiples étapes d'un processus qui n'est utilisé que tous les 1 ou 2 ans.
- Un processus de développement logiciel qui définit ses propres tâches à partir d'un sous-ensemble de features.

On peut espérer que ces trois exemples soient assez proches de nos contextes respectifs pour que nous puissions avoir des idées sur la façon d'y appliquer Kanban. Je vous donne d'autres idées :

- Un concepteur de rapports peut définir un processus commun de conception, développement, modification et déploiement de rapports et commencer à traquer les inefficacités qui enlisent le processus.
- Un administrateur de base de données peut commencer à regarder les mécanismes de file d'attente des transactions et créer une visualisation de type Kanban du processus pour aider à éliminer les goulots d'étranglement en concentrant ses efforts d'amélioration du processus dans son ensemble.
- Un administrateur système peut concevoir un processus de mise à jour de la planification de chacun des domaines fonctionnels et commencer à boucler sur la liste complète des domaines à travers ce processus, chaque fois qu'il réduit le travail ou le temps mis en œuvre dans l'évaluation de nouvelles options technologiques ou dans la mise en œuvre des correctifs et de la maintenance.

Remerciements

Je tiens à remercier tous ceux qui m'ont aidé à relire et modifier ces articles. Au cours de leur publication, j'ai pris à chaque fois un peu d'avance pour finir la rédaction de l'article avant qu'il soit publié et l'aide de plusieurs membres a été inestimable :

- Tim (Riverguy) et David (Thirster), qui ont détecté quelques erreurs critiques dans les tout premiers articles
- Erik (Emtucifer), qui a relu de façon très approfondi le premier article
- Fionnuala (Remou) qui a relu les articles suivants, et a sauvé l'un de mes articles de la mort
- Ted (onpnt) pour avoir relu (ou avoir fait semblant de relire) chaque article et avoir régulièrement fourni des retours positifs.

A propos de l'auteur
Eli Weinstock-Herman Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] NdT : rework = du travail à refaire.

[2] NdT : Kanban a été déployé à la fin des années 50 dans les usines Toyota.

[3] NdT : en Agile on dit "faire émerger les problèmes."

mercredi, 13 juillet 2011

Appliquer Kanban aux processus informatiques (4)

J'ai traduit ce quatrième billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 4).

Cet article est le quatrième d'un ensemble d'articles qui décrit les bases de Kanban et son application dans les processus informatiques :
- La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l'industrie.
- La deuxième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un service helpdesk (fictif).
- La troisième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un projet de déploiement de PC (fictif).
Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s'appliquant à votre propre contexte.

Dans la quatrième partie de cette série "Appliquer Kanban aux processus informatiques", nous allons suivre une équipe de développement logiciel. Ils appliquent actuellement un processus qui a été baptisé le modèle sashimi, un modèle en cascade modifié avec recouvrement des phases : exigences, conception, développement et tests. Cet exemple se concentre sur l'utilisation de Kanban pour améliorer et affiner un processus actuellement utilisé plutôt que d'exécuter un processus de conversion complet.

Bienvenue à la société GHI

GHI est une petite société de développement qui se spécialise dans la construction et l'intégration de systèmes d'inventaire et de valorisation des stocks dans le B2B et le B2C. Un des défis qu'ils ont choisi de relever est le suivi et le reporting d'activités. Étant donné que leurs produits nécessitent de grands développements côté logique métier et administration et très peu côté interface utilisateur, le client ne peut pas voir la façon dont le produit évolue. Améliorer les mécanismes de suivi et de reporting fournira au client de plus amples informations sur la façon dont le projet progresse, augmentant ainsi leur niveau de confiance à la fois dans la solution et dans la société. Cette dernière estime que l'amélioration de cette confiance n'affectera pas seulement la relation avec ce client, mais améliorera également son image sur le marché et avec d'autres clients potentiels.

État courant

Le processus actuel de l'équipe commence par le recueil des exigences de haut niveau et la construction de l'architecture générale, sans aborder aucune des règles métier. Une fois le squelette développé, l'équipe se concentre sur le fait de mener de façon itérative le recueil des exigences et la construction des plus petits modules nécessaires pour ajouter la chair au squelette. La conception globale du système suit une approche N-tier, avec des couches définies pour l'accès aux données, la logique métier, la séparation des processus de transaction et de traduction pour chaque système externe et une interface utilisateur limitée. Cette démarche itérative permet de découvrir plus avant la logique métier et les exigences pendant le développement. Cette approche modulaire permet également de développer en pilotant par les tests des parties du système sans disposer des vrais systèmes tiers donc sans exiger que la solution soit complète. Ce pilotage par les tests permet également au personnel technique du client et aux analystes métier d être impliqués et de relever d'éventuelles contradictions au plus tôt.

On a demandé à l'équipe de fournir une meilleure visibilité et des indicateurs clairs qui puissent être partagés avec le client. Bien que de nombreux membres de l'équipe sont intéressés pour essayer des méthodes Agile, comme Scrum ou XP, l'équipe décide qu'appliquer Kanban à leur processus initial constituera un faible changement du point de vue du client. Une fois que l'équipe disposera d'une meilleure visibilité et de meilleurs indicateurs, elle a bien l'intention de réévaluer le potentiel d'utilisation de Scrum ou de tout autre méthode Agile, mais elle perçoit qu'un changement progressif sera acceptable pour les clients là où un changement de processus complet ne le sera pas.

Dans le cadre de ses efforts continus, l'équipe est également à la recherche d'un moyen d'améliorer sa vitesse de livraison. La plupart des membres de l'équipe approuvent le fait qu'un développeur supplémentaire permettrait d'accélérer leur processus de livraison d'au moins 15%, mais ils ne seront pas en mesure de défendre le recrutement d'effectifs supplémentaires sans disposer d'indicateurs convaincants permettant de légitimer leurs demandes.

Définir le processus

Suite à plusieurs longues réunions, l'équipe a élaboré son processus comme une série d'étapes clairement définies qui suivent des cycles, en se concentrant de manière itérative sur de plus petits morceaux.

Pt 4 Sashimi
Processus en cascade itératif (Sashimi)

Bien que le processus suivi soit presque fractal dans son exécution, chaque passe détaillée de plus en plus finement suit une série d'étapes :

Reste à faire : travaux non encore bien déterminés qui doivent être conçus et développés
Exigences : recueil d'exigences métier ou système tiers pour une tâche ou un module
Conception : application des standards de conception, de modélisation et d'exigences externes pour concevoir la tâche ou le module
Développement : développement selon la conception et les exigences
Test : test des développements terminés pour détecter les défauts* et valider l'alignement aux exigences
Revue client et acceptation : groupes de revue des tâches avec le personnel technique, les analystes métier ou les services tiers

L'équipe compte actuellement un chef de projet, cinq développeurs et une personne pour la QA. Une fois défini son processus, l'équipe a décidé que l'un des développeurs serait en charge de l'architecture (exigences et conception), le chef de projet sera responsable des étapes client et de la priorisation du reste à faire (avec l'aide de l'architecte), le reste des développeurs et la personne QA prendront en charge le développement et les tests. L'architecte sera également responsable d'une partie du développement si l'équipe prend de l'avance sur les exigences et la conception.

*Les défauts sont des imperfections du produit qui apparaissent en situation de production ou d'exploitation normale. Des exemples de défauts dans l'ingénierie logicielle sont du code mal saisi, un référencement incorrect des variables et d'autres erreurs techniques. Les problèmes au niveau des exigences sont par exemple des options manquantes dans les filtres de recherche, une mise en page incorrecte d'un formulaire et d'autres éléments directement liés au client.
Exemple : le client n'exigera jamais explicitement que la fonction de validation ne bloque pas le serveur, donc une erreur dans une fonction de validation qui bloque le serveur est classée dans la catégorie défaut.

Tableau visuel 1

A des fins de visualisation et de suivi, l'équipe découpe plusieurs étapes en sous-étapes. Les étapes d'exigences et de conception ont été définies comme une série de trois sous-étapes, la dernière étape étant une étape "prêt" qui indique que les tâches peuvent être sélectionnées et commencées par les développeurs. Le développement a été découpé en deux sous-étapes, une étape "en cours" et une étape "terminé". Les éléments de la sous-étape "terminé"" sont mis à disposition pour être sélectionnés et testés par la QA.

KanbanPt4 VisBoard 4a
Le premier tableau visuel

L'équipe utilise un grand tableau blanc magnétique pour son tableau Kanban. Au lieu d'utiliser des couloirs pour visualiser les travaux en cours, l'équipe a créé des emplacements spécifiques sur le tableau pour les tâches et pour la photo de chaque membre de l'équipe. Par exemple, lorsque l'architecte de l'équipe recueille les exigences pour une tâche, il place sa photo dans la colonne exigences avec la tâche sur laquelle il travaille actuellement. Le chef de projet a donné une série de timbres d'animaux colorés aux membres de l'équipe pour estampiller les tâches qu'ils terminent, permettant au reste de l'équipe de suivre facilement qui a travaillé sur une tâche donnée. Cela permet à la personne de la QA ou à un développeur qui prend la suite de communiquer facilement avec le développeur d'origine sans faire appel à des mécanismes complexes de traçabilité.

KanbanPt4 VisBoard 4b
Limites Kanban

Les limites Kanban ont été définies en fonction du nombre de personnes affectées à chaque étape et de quelques approximations sur la quantité de travail attendue à chaque étape sans que les étapes avales du processus manquent de travail. Les étapes d'exigences et de conception sont limitées à trois tâches pour trouver un équilibre entre conserver des informations fraîches sur les exigences et fournir suffisamment de travail pour l'étape de développement. La étapes de développement possèdent une limite de cinq tâches pour permettre à l'architecte d'avancer et de développer de petites tâches lorsque la limite est atteinte pour les exigences et la conception. L'étape de QA est limitée à une seule tâche, tirée à partir des tâches de développement terminées. Cela permet à la personne QA de terminer une série de tests sans être perturbée par de nouveaux développements déployés en cours de tests. La file d'attente des éléments en attente de la revue clients n'est pas limitée car le chef de projet a déjà des réunions hebdomadaires avec le client pour discuter des tâches terminées. La file d'attente permet au chef de projet de sélectionner des ensembles de tâches terminées et d'en discuter avec les participants, ou d'envoyer des rappels assez tôt pour s'assurer que les bons participants seront présents à la réunion.

Exécuter le nouveau processus

Initialement, le processus est un peu brut puisque l'équipe tente de terminer les tâches qui dépassent les limites à travers le flux. L'architecte commence à s'acclimater à un rôle qui exige de consacrer plus de temps avec des tableaux blancs et moins avec un éditeur de code. Le chef de projet commence à opérer la transition de la gestion des flux de tâches dans le processus vers la gestion des priorités et l'amélioration des communications avec le client.

Après quelques semaines, le processus est plus fluide. Le chef de projet priorise les tâches dans la file d'attente, parfois en impliquant l'architecte pour s'assurer que les exigences de conception sont prises en compte. L'architecte sélectionne les tâches prioritaires en haut de la pile, recueille des exigences plus détaillées de la part du client, et construit une conception globale qui intègre les exigences et les aligne avec la conception de haut niveau. Lorsque les étapes d'exigences et de conception atteignent la limite Kanban, l'architecte passe à l'étape de développement et soit aide les développeurs soit sélectionne une petite tâche de développement qu'il finira lui-même. Les développeurs sélectionnent des tâches de l'étape d'architecture et les implémentent. Après avoir terminé une tâche, ils la déplacent dans la sous-étape "fini" et soit aident l'un des autres développeurs soit sélectionnent une nouvelle tâche. Lorsque l'étape de développement atteint sa limite Kanban, les développeurs sans tâches attribuées se déplacent en amont du processus pour aider la personne QA à tester afin de supprimer les obstacles. La personne QA teste chaque tâche, à la recherche d'anomalies ainsi que pour vérifier l'alignement avec les exigences clients et la conception interne.

KanbanPt4 VisBoard 4b QA
Les tâches de QA retournent au développement ou passent à la suite

Après avoir testé une tâche, la personne QA soit la renvoie dans la colonne de développement pour être corrigée soit la déplace dans la file d'attente. Renvoyer une tâche aux développeurs causera souvent l'atteinte ou le dépassement de la limite Kanban pour le développement. Le développeur qui prend la suite et qui atteint ce point d'arrêt, soit aide à continuer les tests soit sélectionne la tâche renvoyée pour corriger les problèmes en suspens.

Première révision

Dans le cadre de la définition du processus initial, l'équipe a convenu d'examiner et de réviser son processus régulièrement. Pendant les premières semaines, le chef de projet a recueilli des statistiques de haut niveau pour mesurer le débit du processus et fournir des informations pour la réévaluation du processus. L'information détaillée comprend des statistiques sur la fréquence des tâches renvoyées par l'étape de test, le nombre de fois où l'architecte ou les développeurs sont amenés à se déplacer en aval du processus pour aider à débloquer les obstacles, et une estimation générale de la façon dont le client réagit lors chaque réunion hebdomadaire.

Évaluation

Il y avait un certain nombre de tâches partiellement terminées lorsque l'équipe a commencé et ils attendaient l'étape de QA pour se stabiliser. Malheureusement, cela n'a pas eu lieu, et afin de maintenir un flux régulier de tâches, les développeurs sont souvent aller en aval du processus pour aider la personne de la QA à traiter son backlog. Les quelquefois où les développeurs ont eu des journées exceptionnelles, la QA a presque immédiatement bloquée, nécessitant plusieurs développeurs pour aider à traiter le backlog.

Le rôle d'architecte requiert moins de temps que prévu, conduisant l'architecte à développer environ 50% de son temps. Cela exige, pour quasiment chaque tâche réalisée par l'architecte, un débogage et une correction par l'un des développeurs et réduit encore un peu plus l'efficacité du processus en forçant quelqu'un, peu familier avec les exigences et le code de la tâche concernée, de dépanner rapidement et d'apporter les corrections.

Changements de processus

Initialement l'équipe croit que la plus grande limitation pour accomplir des tâches est la main-d'œuvre et qu'augmenter le nombre de développeurs conduirait à une augmentation directe du nombre de tâches qu'ils réalisent chaque semaine. Toutefois, après avoir travaillé pour obtenir un processus plus raffiné et mesurable, ils ont constaté que l'ajout de développeurs offrirait peu ou pas d'avantages parce que la contrainte actuelle sur leur processus est le goulot d'étranglement sur la QA. S'ils augmentent le débit de cette étape, alors le processus entier sera beaucoup plus fluide et générera un débit plus élevé, puisque la QA sera en mesure de tirer des tâches de la zone de développement plus rapidement.

L'équipe a pris en compte plusieurs idées pour accroître la main-d'œuvre à l'étape de test, y compris l'embauche d'une personne supplémentaire pour la QA et même utiliser l'architecte à temps partiel sur la QA au lieu de le faire développer. Après avoir discuté de plusieurs options, un membre de l'équipe a suggéré d'utiliser l'architecte et tout développeur disponible pour construire des tests automatisés. La théorie est que l'automatisation de certains des tests ne réduira pas seulement la quantité de travail pour la personne QA, mais réduira aussi le nombre de tâches qui sont renvoyées par la QA au développement pour débogage et correction. L'équipe a décidé d'essayer cette idée parce qu'elle ne nécessite pas de dépenses supplémentaires et qu'il y a peu d'impact négatif d'avoir l'architecte travaillant sur les tests unitaires au lieu d'aider à terminer les travaux de développement en respectant la limite Kanban.

KanbanPt4 VisBoard 4c
Tableau Kanban révisé avec des étapes supplémentaires

Le tableau Kanban a été modifié pour inclure une sous-étape de création de tests en plus des exigences et de la conception. L'architecte est responsable de la construction d'un certain nombre de cas de test pour chaque tâche à définir. Lorsque les limites de la zone exigences sont atteintes, l'architecte travaille sur la construction. Cela garantit que les tâches en cours ont des tests automatisés et qu'au fur et à mesure que le temps passe, la couverture augmente pour tester l'intégration des modules et tout risque d'effets de bord ou de lacunes lors de l'intégration des modules conçus ensemble.

La limite pour l'étape de développement sur le tableau est augmentée et une petite zone est créée pour les tâches renvoyées par la QA. Ces tâches sont traitées avec une priorité plus élevée que les tâches de la zone d'exigences pour s'assurer que la plupart des tâches seront corrigées et terminées avant que tout nouveau travail démarre. Pour aider à augmenter l'efficacité des développeurs à corriger ou déboguer le code écrit par d'autres, une nouvelle revue de code est mise en place. Chaque fois qu'une tâche est terminée, le développeur revoit le code avec un ou plusieurs des autres développeurs pour s'assurer qu'il est simple, commenté où il faut et qu'il suit les standards existants. Ce processus est relativement rapide et réduit les coûts et le temps supplémentaire consommé lorsque quelqu'un d'autre dépanne les tâches réalisées initialement par quelqu'un d'autre.

Analyse finale

Bien que l'équipe continue à réévaluer et réviser son processus selon une fréquence de quelques semaines, elle a déjà réalisé un certain nombre d'améliorations par rapport à son processus original et à la première version des limites de Kanban.

Flux de processus

L'équipe n'a pas révisé ses priorités, exigences ou processus de conception, de sorte que ces étapes continuent à travailler de la même manière qu'avant l'application des limites Kanban. Le nouveau processus de création de tests unitaires pour les tâches a été lent pendant la première semaine, mais comme l'architecte a acquis une expérience avec le framework de tests, le processus de construction de tests est devenu plus fluide et a commencé à donner du temps pour construire des tests sur les modules déjà terminés. Au fur et à mesure que les développeurs terminent leurs tâches, ils regardent en premier la file d'attente des "corrections" provenant de la QA pour voir si des tâches sont en attente d'être déboguées ou corrigées. Cela met donc la priorité sur les tâches précédemment commencées et assure que les nouvelles tâches ne sont démarrées que lorsque la zone à corriger est vide. Le nouveau framework de tests unitaires a donné aux développeurs un moyen rapide de tester leur travail avant de déclarer qu'il est terminé et leur a également fourni des informations d'une toute autre dimension sur les exigences métier et de conception. Les tests unitaires ont également réduit le nombre de tâches correctives sur lesquelles les développeurs doivent travailler parce qu'ils signalent la plupart des défauts que la QA avait l'habitude de trouver auparavant.

L'étape de QA est devenue beaucoup plus rapide et il semble probable que la personne QA aura besoin d'un second boulot bientôt, l'équipe des 4 développeurs a été maintenue mais la QA a subi deux "périodes de sécheresse" la semaine précédente puisqu'elle était en avance sur les développeurs. Le nombre moyen de tâches retournées a été considérablement réduit, avec seulement environ 5% des tâches retournées pour dépannage là où plus de 50% étaient autrefois retournées. L'étape QA évalue et utilise aussi des tests automatisés pour s'assurer qu'aucun défaut n'a été négligé et le gain de temps, lié au fait de ne pas avoir à construire des tests et ne pas avoir à les passer manuellement pour chaque tâche, est énorme.

Avec l'étape de QA terminant l'évaluation des tâches plus rapidement, la file d'attente des éléments à revoir par le client croît à un rythme beaucoup plus rapide. Le chef de projet commence à avoir des difficultés à couvrir le tout en une seule réunion hebdomadaire, car le nombre d'éléments terminés a augmenté et se révèle un peu compliqué à traiter dans le format de réunion actuel. Des modifications des méthodes de communication sont susceptibles de survenir dans un proche avenir pour aider à gérer le flux croissant des tâches accomplies. Les mesures globales du débit des tâches et l'estimation des dates de fin sont plus cohérentes et ne varient pas énormément par rapport à avant. Alors que les indicateurs ont reflété l'amélioration du processus, la variation ou la plage des valeurs s'est considérablement restreinte.

Succès

L'équipe a seulement travaillé sur son processus quelques mois, mais elle a déjà commencé à voir des améliorations positives et elle envisage déjà des pistes pour son prochain cycle d'amélioration. Voici quelques-uns des succès qu'elle a déjà obtenus :

- Augmentation de la productivité : le rythme global de développement a augmenté par rapport au rythme constaté avant mise en œuvre de Kanban
- Augmentation de la confiance : l'amélioration de la vitesse de développement, l'utilisation d'outils automatisés et de nouveaux indicateurs ont tous contribué à l'amélioration de la confiance du client
- Clarté de la vision : la définition du processus et le tableau Kanban ont donné à l'équipe une meilleure vue de leur processus et un moyen de comparer avec d'autres méthodologies
- Estimation de la variabilité réduite : la capacité à mesurer le débit et de meilleures estimations ont permis à l'entreprise de mieux évaluer le moment d'approcher de nouveaux clients potentiels
- Mesurabilité : de bons indicateurs fournissent un outil important pour continuer à améliorer le processus et évaluer si des améliorations potentielles ont amélioré le processus ou non
- Support à la formation : des améliorations dans le processus ont contribué à diminuer les coûts et fournir un argument pour consacrer ce temps à se former, pour aider à conduire de futures améliorations ou empêcher la société de se lancer sur une technologie qui n'offrira pas ce qui est demandé

Dans le prochain article, nous conclurons cette série en 5 parties, "Appliquer Kanban aux processus informatiques", avec des idées issues d'autres domaines de l'informatique. Nous allons également discuter de certains processus non-humains pour lesquels Kanban peut être appliqué, ainsi que quelques brèves informations sur certains des autres concepts qui ont été abordés dans la série (tels que l'amélioration continue).

A propos de l'auteur
Eli Weinstock-Herman Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

mardi, 12 juillet 2011

La 5ème pratique fondamentale de Kanban

Karl ScotlandJ'ai traduit cet article de Karl Scotland : "The Fifth Primary Practice of Kanban" suite à une réponse de Colin Garriga-Salaün (facilitateur d'équipes agiles chez Yaal) au message Scrumban paru sur le Groupe Yahoo du French SUG.

J'ai récemment écrit ce que je considérais comme étant les quatre pratiques fondamentales d'un système Kanban pour le développement de logiciels :

1. Cartographiez la chaîne de valeur
2. Visualisez la chaîne de valeur
3. Limitez les travaux en cours (WIP)
4. Établissez une cadence

Durant les discussions qui ont suivi sur l'amélioration continue dans un système Kanban, j'ai décidé qu'il manquait une cinquième pratique fondamentale :

5. Réduisez les éléments dans le Kanban

J'ai d'abord appelé cette pratique "Éliminez le Kanban", mais j'ai vite été persuadé que c'était probablement trop sensationnel et par conséquent potentiellement source de confusion ou d'erreur. L'intention de cette pratique est qu'une fois qu'un système Kanban est en place, l'équipe devrait constamment chercher à l'améliorer en créant un environnement où le travail s'écoule naturellement. Il y a une citation de Rother et Shook, je crois, qui dit "laissez le flux s'écouler là où vous pouvez, tirez le travail là où vous devez". En s'efforçant de réduire le nombre d'éléments dans le système kanban, une équipe évoluera vers un environnement où ses membres seront davantage auto-organisés et où le travail pourra mieux s'écouler. Ceci peut être atteint soit en diminuant les limites de WIP, soit en réduisant fortement le nombre d'étapes distinctes.

Feedback :


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

lundi, 11 juillet 2011

Appliquer Kanban aux processus informatiques (3)

J'ai traduit ce troisième billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 3). Le sujet de ce billet m'a clairement rappelé mon année passée au service informatique des pompiers de la Gironde avec la maintenance du parc PC des 80 centres de secours. Ca m'aurait bien aidé à l'époque... :)

Cet article est le troisième d'un ensemble d'articles qui décrit les bases de Kanban et son application dans les processus informatiques :
- La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l'industrie.
- La deuxième partie donnait un aperçu de Kanban et la façon de l'utiliser dans un service helpdesk (fictif).
Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s'appliquant à votre propre contexte.

Dans la troisième partie de cette série "Appliquer Kanban aux processus informatiques", nous explorons l'utilisation de Kanban pour gérer un projet fonctionnel court terme. Cet exemple se concentre sur l'utilisation de Kanban pour créer un processus transparent pour suivre le flux des équipements à travers un certain nombre d'étapes complexes, sans générer de coûts supplémentaires pour le logiciel de suivi, de processus complexes et de formation, ou même d'efforts en double. Une meilleure uniformité et qualité des processus de déploiement permettront également d'améliorer l'efficacité et les délais de dépannage mais aussi d'assurer un niveau de documentation élevé par rapport aux standards en termes de gestion de logiciels et de licences.

Bienvenue sur le projet annuel de déploiement des PC de la société DEF

La société DEF est une PME disposant actuellement d'environ 1000 PC et portables déployés. Son service informatique fonctionne comme la plupart des services de cette taille, c'est-à-dire avec un haut niveau de management individuel, des liens solides dans l'équipe et un personnel relativement restreint pour couvrir une grande variété de rôles. Sur les 15 personnes, seulement deux vont travailler sur le déploiement des PC et on leur a donné toute liberté pour s'organiser et effectuer leur travail. L'équipe exige un reporting sur l'état d'avancement qui soit clair et simple afin d'éviter que leur travail acharné devienne un projet invisible. Par ailleurs, il y a un espace de stockage limité pour les équipements non déployés, l'équipe aura donc besoin de bien gérer le nombre d'équipements non déployés ainsi que les commandes de nouveaux équipements.

L'équipement et les tâches

Le déploiement annuel de PC doit tenir compte de l'équipement suivant :

- 160 nouveaux PC à déployer
- 40 nouveaux portables à déployer
- 120 PC et 10 portables à mettre à jour et à redéployer

Une image logicielle est disponible pour installer de base un système d'exploitation et un ensemble de pilotes sur chaque PC, en réduisant la variabilité de la procédure d'installation initiale. Des tâches comme l'enregistrement sur le domaine réseau, l'installation de logiciels utilitaires,bureautiques, ... doivent devenir le standard d'installation, mais il y aura bien sûr également quelques installations personnalisées de logiciels selon l'utilisateur final ou son rattachement à une entité. Mettre à jour un PC existant passe par les mêmes étapes, avec cependant l'ajout d'une tâche d'audit pour vérifier le passage d'un ancien mode d'utilisation à un nouveau. Si on se base sur l'historique, il est clair que l'un des problèmes les plus perturbants est lorsque l'on doit repasser sur un système (rework*) pour installer un logiciel manquant ou modifier une mauvaise configuration, l'équipe a donc décidé d'ajouter certaines vérifications au processus pour limiter ces risques.

*Le rework est le nom du processus qui consiste à terminer un élément et le renvoyer à travers une partie du processus pour corriger une étape de production incomplète ou ratée. Dans le cas du déploiement d'un PC, cela pourrait être un logiciel non installé pendant le processus de configuration, de mauvaises permissions allouées, ou toute une douzaine d'autres éléments qui nécessiteraient qu'un technicien revienne sur un PC déjà déclaré "déployé" afin de finir le travail. Les coûts de rework comprennent les coûts liés au fait d'exécuter une seconde fois une étape, de ré-exécuter les étapes suivantes une seconde fois, de basculer de son travail actuel sur l'élément qui nécessite un rework, et les retards liés au fait de terminer les travaux en cours par rapport à l'estimation initiale ou au délai initial.

Première version du tableau visuel

Après avoir discuté des exigences et des étapes du processus, les techniciens ont créé un processus commun à tous les équipements :

- Réception : le nouvel équipement et l'équipement à redéployer qui n'ont pas encore été "étiquetés"
- Stock : le nouvel équipement et l'équipement à redéployer qui ont été "étiquetés"
- Image : installer l'OS de base, les pilotes et l'image logicielle
- Analyse personnalisée : construire une liste des logiciels client et/ou des paramètres spécifiques pour l'utilisateur final concerné
- Bureautique : installation et configuration initiale des logiciels bureautiques et installation des templates spécifiques à la société
- Utilitaires : installation d'un ensemble standardisé d'utilitaires pour le dépannage informatique et l'audit
- Installation personnalisée : installation des configurations personnalisées
- Audit : exécution du premier audit du PC et mise à jour des liens d'affectation pour un PC redéployé
- Déploiement : déploiement de l'équipement pour l'utilisateur final

Pour gérer les PC à travers ce processus, l'équipe a inventé un "système d'étiquetage" de l'équipement. Les techniciens ont conçu un formulaire check-list copié et mis à jour pour chaque PC. Le coin supérieur droit du document devient la carte Kanban, tandis que le reste est une check-list qui sera utilisée pour vérifier l'étape précédente de chaque étape du déploiement au fur et à mesure que l'équipement progresse dans le processus. Par le passé, l'équipe avait déterminé qu'il y avait en moyenne 5% de rework nécessaire pour pallier une configuration ou un logiciel manquant.

Pt 3 Tag
Exemple de formulaire avec carte Kanban prête à détacher

Au lieu d'inclure une étape de QA à la fin de son processus de déploiement, l'équipe a choisi de commencer par vérifier la tâche de chaque étape précédente. En vérifiant le plus tôt possible, l'équipe espère réduire le besoin d'un long processus de QA, réduire la quantité de rework, détecter et corriger le plus tôt possible pour prévenir la répétition tardive des tâches (par exemple exécuter le logiciel d'audit). Des cases à cocher "Fait" et "Vérifié" sont mises à disposition sur chaque ligne du formulaire.

Maintenant que les tâches ont été définies, l'équipe initialise son premier tableau visuel avec du ruban et des étiquettes sur un tableau de liège. Les punaises seront utilisées pour positionner les cartes Kanban liées à chaque pièce d'équipement dans l'étape appropriée du tableau.

KanbanPt3 VisBoard 1
Tableau Kanban avec quelques cartes

Les limites Kanban à chaque étape sont basées sur l'espace de travail disponible et sur le souhait de conserver un flux lissé de l'équipement dans le processus. L'équipe a décidé que, pour trouver un juste équilibre entre la régularité du flux (petites limites) et l'efficacité des installations menées en parallèle (grandes limites), elle définirait des limites basées sur les temps d'installation des logiciels pour s'assurer que les étapes les plus longues soient correctement dimensionnées et ne génèrent pas de retards pour les étapes ultérieures. Copier l'image, installer les logiciels bureautiques et exécuter l'audit nécessitent peu d'intervention humaine mais beaucoup de temps, tandis que l'Analyse personnalisée, le Déploiement et les deux étapes restantes d'installation des logiciels nécessitent un niveau élevé de participation et d'attention de la part de l'installateur.

Créer un reporting

Il y a un certain nombre d'exigences et de facteurs à prendre en compte pour établir le reporting lié à ce processus. En se basant sur les exigences et les souhaits exprimés par le responsable informatique, l'équipe a produit la liste suivante des points devant faire l'objet d'un reporting :

- Avancement : basé sur le concept d'un burndown (lien mort), le tableau d'avancement affiche les progrès réels et une date de fin prévisionnelle
- Délai déstocké -> déployé : un graphique simple pour montrer le temps de déploiement réel par rapport à la moyenne et aux années précédentes
- Satisfaction des utilisateurs : un couple de barres horizontales qui affiche le nombre de livraisons réussies à la date prévue et le nombre de déploiements incomplets (rework)

KanbanPt3 Spreadsheet
Feuille de calcul et graphiques associés pour le reporting hebdomadaire

Pour générer ce rapport, il faudra mettre à jour la feuille de calcul chaque fin de semaine avec le nombre de PC réellement terminés, incrémenter (le cas échéant) la quantité totale dans une deuxième cellule et indiquer le nombre de PC qui n'ont pas respecté la date de livraison cible dans une troisième cellule. Les projections sont automatiquement mises à jour sur la base d'une équation définie dans le tableur et l'information réactualisée dans les graphiques. Un simple copier/coller des graphiques dans les documents en fin de semaine permet de produire le nouveau reporting hebdomadaire.

Analyse finale

Pendant l'exécution du processus de déploiement, l'équipe a légèrement modifié les limites Kanban ainsi que le mécanisme de reporting, mais elle n'a pas eu d'importants changements à apporter à son processus. Compte tenu de la transparence des travaux, elle a pu rester sur la bonne voie et déployer les équipements à un rythme régulier. Au fur et à mesure qu'elle a ajusté le rythme du processus, elle a commencé à planifier les commandes de nouveaux PC pour que cela coïncide mieux avec la consommation des stocks, lui permettant d'augmenter la taille de ses commandes, de bénéficier de meilleurs devis concernant l'achat des équipements, sans pour autant manquer de travail entre les commandes. Un reporting final a été réalisé à partir des graphiques tirés des rapports hebdomadaires et des informations supplémentaires concernant la réduction des dépenses et du travail.

Flux du processus

Tout nouvel équipement ou équipement remasterisé était affecté à un utilisateur et étiqueté avant de démarrer quoique ce soit. Ceci a empêché qu'apparaissent les problèmes survenus au cours des années antérieures, tels que les mauvaises affectations, les doubles affectations et les réaffectations avec les mauvais logiciels. Le processus a également fourni un inventaire précis des équipements disponibles à tout moment, permettant ainsi de répondre aux questions immédiatement plutôt que de demander à quelqu'un de se rendre dans l'espace de stockage et d'effectuer un inventaire. Une communication au plus tôt avec l'utilisateur final sur la date à laquelle l'équipement serait disponible, a réduit la difficulté à déployer les PC qui étaient prêts, les utilisateurs finaux étant préalablement avertis, ceux-ci pouvaient aider à mieux définir leur disponibilité, avec comme conséquence de réduire la replanification des installations comparativement aux années antérieures. La vérification immédiate des étapes antérieures et les limites Kanban ont favorisé un flux lissé des équipements dans le processus, en fournissant les bases d'un temps de cycle plus cohérent et reproductible. Une meilleure estimation de la durée du processus de déploiement (disponibilité des stocks) a permis de réaliser des économies budgétaires directes, tout en permettant à l'équipe d'augmenter la taille de ses commandes et de profiter de meilleures économies pour la même quantité d'équipements. Enfin, le mécanisme de reporting créé par l'équipe était assez simple pour que le responsable informatique soit capable de l'utiliser lors de chaque réunion de département, sans devoir passer la nuit précédente dessus pour tout préparer.

Succès

Voici quelques-unes des succès de l'équipe :

- Visibilité 100% : visibilité dans le processus et l'inventaire à tout moment, sans effort supplémentaire consacré au suivi des techniciens ou au comptage à la volée de l'équipement
- Moral amélioré : réduction de la confusion et de la négativité des utilisateurs finaux dans l'attribution des équipements en se basant sur des communications claires et un véritable processus d'affectation
- Gains de temps : aucun rework est synonyme de gain de temps dans le processus de déploiement, ainsi que dans la suppression des interruptions que causaient le rework
- Gains financiers : une meilleure estimation et une meilleure gestion des stocks a permis d'augmenter la taille des commandes sans nuire aux délais de réalisation
- Marketing bon et peu onéreux : le processus simple pour générer les rapports a non seulement apporté un gain de temps, mais a aussi produit des métriques assez simples pour qu'elles soient réutilisées lors des réunions managériales avec une publicité positive sans pour autant exiger plus de temps et d'efforts de la part du responsable informatique
- Productivité accrue : en se fondant sur la cohérence du processus, l'amélioration des estimations, la réduction du niveau d'interruption constatée sur les précédentes années, l'ensemble du processus prenait moins d'heures de travail à dérouler
- Amélioration mesurable : les statistiques identiques sont suivies attentivement pendant l'exécution du processus et permettent de constater en fin d'année les améliorations au niveau de l'équipe et du département.

Les succès énumérés ici couvrent aussi bien des aspects durs (financier) que mous (moral) et ne couvrent probablement pas l'ensemble des succès qui auraient pu être obtenus dans une version non-fictive de cette histoire. En un mot, le processus a pu s'exécuter de façon plus facile, plus efficace et plus prévisible, ce qui a généré au niveau de l'équipe un certain nombre d'améliorations mesurables par rapport aux années antérieures. Ce même processus sera réutilisable dans les années à venir, et peut désormais être utilisé comme une base pour de nouvelles améliorations ou pour permettre de porter les efforts sur l'amélioration d'autres processus puisque celui-ci se déroule simplement et en douceur. Même si utiliser un système Kanban pour un processus temporaire n'est pas fréquent, il démontre sous un autre angle la façon dont il peut être utilisé pour "apprivoiser" des processus de travail complexes et promouvoir l'amélioration globale du processus.

Dans le prochain article, nous explorerons l'utilisation de Kanban par une équipe de développement logiciel qui cherche à livrer et maintenir un ensemble de produits. Bien qu'il existe déjà beaucoup de comptes-rendus réels de la part de personnes appliquant Kanban au processus de développement logiciel, le développement est une activité notoire d'un département informatique et je serais négligent si je n'apportais pas ma touche personnelle sur la façon dont Kanban peut être utilisé par une équipe de développement.

A propos de l'auteur
Eli Weinstock-Herman Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

samedi, 9 juillet 2011

Appliquer Kanban aux processus informatiques (2)

J'ai traduit ce deuxième billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 2).

Cet article est le deuxième d'un ensemble d'articles qui décrit les bases de Kanban et son application dans les processus informatiques. La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l'industrie. Les articles qui suivront explorent différents scénarios pour vous aider à trouver des idées s'appliquant à votre propre contexte.

Dans cette deuxième partie de cette série "Appliquer Kanban aux processus informatiques", nous explorons un helpdesk et la manière dont Kanban peut aider à améliorer son image, ses métriques, son moral, sa réactivité et ses délais d'exécution. Les exemples de tableaux et de processus donnés dans cet article ne sont pas destinés à être pris tel quel dans vos processus d'entreprise, mais plutôt pour créer un système basé sur Kanban et l'appliquer dans un cadre fictif. Kanban est une philosophie et non pas un ensemble figé de processus, donc s'il vous plaît rappelez-vous que ce n'est qu'un exemple de la façon dont il pourrait être appliqué dans les cas fictifs décrits.

Bienvenue au helpdesk de l'entreprise ABC

Je raconte l'histoire fictive d'un helpdesk de l'entreprise ABC qui a décidé de mettre en place un système Kanban pour définir et améliorer ses processus. Les détails de leur processus, les décisions qui furent prises au fur et à mesure et les méthodes utilisées pour communiquer et mesurer l'atteinte de leurs objectifs, doivent être considérés comme des exemples et non des règles. Alors que certaines entités peuvent procéder en une seule étape pour passer de leur processus actuel à Kanban, ce type de transformation instantanée est risqué, surtout si l'entité en question ne dispose pas d'un processus réaliste et bien défini.

L'année dernière

L'année dernière, le département informatique de l'entreprise ABC a commencé à être en sous-effectif et à prendre du retard dans ses travaux. La pression financière a forcé la société à retarder les nouvelles embauches pendant plusieurs mois. Malgré ses efforts, le helpdesk a accumulé les retards sur les demandes de support. Grâce au travail acharné et aux heures supplémentaires, l'équipe a réussi à maîtriser son travail et a cessé de prendre du retard, mais le délai moyen entre une nouvelle demande et la tâche associée terminée a continué à être mesuré en semaines. L'augmentation du nombre de demandes de statut et des tâches signifiait que les gens étaient souvent en train de travailler sur dix à quinze tâches simultanément, ils jonglaient même avec des tâches basiques comme la connexion de nouveaux téléphones ou la commande de nouveaux équipements si bien que les utilisateurs finaux estimaient que le département informatique ne se souciait tout simplement pas de leurs problèmes.

État courant

Quelques mois plus tard, l'entreprise ABC a effectué de bons recrutements et les heures supplémentaires ont commencé à diminuer. Les membres du département informatique font de nouveau des horaires réguliers et ils sont fiers de la façon dont ils ont réussi à résister. Malheureusement, ce sentiment de fierté ne dépasse pas les murs du département informatique, et les utilisateurs ont une vue très différente. Les utilisateurs finaux croient encore que le département informatique prend trop de temps pour traiter les demandes et que "ne pas prendre de retard" est différent de "traiter la demande le jour même" et l'équipe de direction se demande si les nouvelles embauches ont été efficaces ou même nécessaires, car ils ne voient pas d'améliorations dans les délais ou la qualité de résolution. L'entreprise ABC a une bonne équipe, ils vont donc probablement regagner leur réputation, le temps de résolution des demandes va un peu diminuer, les utilisateurs vont commencer à oublier cette mauvaise période et les dirigeants pourraient même considérer que les embauches ont servi la performance de l'équipe. Cependant, puisque nous sommes des "étudiants" de l'amélioration, nous ne pouvons pas permettre à l'équipe de se contenter de penser qu'elle n'est "pas aussi en retard que par le passé" ou "pas aussi mauvaise que par le passé".

Définir l'état courant

Avant de tenter d'améliorer le processus, nous devons savoir quel est le processus et déterminer comment il fonctionne. Notre objectif initial sera de définir comment le processus du département informatique fonctionne, y compris les étapes qu'il suit pour terminer le travail et surtout quelle est l'unité de 'travail' réelle. A ce stade, nous n'essayons pas de comprendre comment résoudre leurs problèmes ou de déterminer où se situe les goulots d'étranglement, nous essayons simplement de décrire et de définir les processus et les tâches. Dès le départ, nous allons donner aux membres de l'équipe un rôle de supervision, ainsi nous nous ferons sûrement une idée précise du processus.

Après avoir analyser les processus, nous avons constaté que :
L'entreprise ABC accepte des demandes des clients venant de plusieurs origines différentes, email, téléphone, conversations et une application de gestion de tâches sur le web. Une fois ces demandes reçues, trois choses peuvent arriver : soit la demande est saisie dans l'appli. web, soit la personne qui prend l'appel/l'email/etc. traite immédiatement la demande, soit elle est enregistrée de façon temporaire (post-it, liste de choses à faire dans un email client). Lorsqu'une tâche est terminée, il n'y a pas de processus de suivi afin de s'assurer qu'elle répond aux besoins du demandeur et on ne prend pas le temps de créer la tâche dans l'appli. web si cela n'avait pas été fait préalablement.

Tableau visuel 1

Après avoir défini les processus avec l'équipe, nous avons suffisamment d'informations pour partager notre premier tableau visuel. D'après nos observations ci-dessus, nous savons qu'il y a déjà un certain nombre de processus suivis par les gens, nous voulons donc faire aussi simple que possible pour commencer. Notre objectif initial est d'amener les gens à commencer à utiliser ce nouveau processus et qu'ils soient à l'aise avec. Si nous essayons d'élaborer un nouveau processus qui résout tous les problèmes avec de nombreux niveaux de reporting, nous finirons avec quelque chose qui ressemble au système informatique déjà en place et manifestement pas utilisé de façon cohérente. En démarrant simplement, nous pouvons faire évoluer le tableau et le nouveau processus pour mieux répondre aux besoins de l'équipe, plutôt que d'essayer de créer un processus détaillé et "tordre" l'environnement pourqu'il soit conforme au processus.

Dans l'esprit de garder les choses simples, nous avons bâti ensemble notre premier tableau Kanban en utilisant un tableau blanc, un peu de ruban et quelques post-its.

KanbanPt2 VisBoard 1
Premier tableau visuel de l'entreprise ABC complété avec les post-its des tâches actuelles

Note : un autre choix fréquent est d'utiliser des tableaux magnétiques, expérimentez et ne vous enfermez pas dans une seule idée de solution.

Créer une demande

Lorsqu'un membre de l'équipe reçoit une nouvelle demande, il doit remplir un post-it et le placer dans la file d'attente "Travail en attente". Un exemple est placé sur le tableau, avec plusieurs piles de post-its vides et des fournitures pour écrire. L'exemple comporte des champs pour le nom du demandeur, la date à laquelle la tâche a été reçue, la personne qui a pris la demande et une brève description de la demande ou de la tâche. Nous avons maintenant suffisamment d'informations pour identifier des tâches distinctes sur le tableau, déterminer combien de temps il a fallu pour les terminer, trouver la bonne personne si nous avons des questions au sujet de la demande initiale et communiquer avec l'utilisateur final à propos de sa demande. Le processus de création de la demande doit prendre moins d'une minute et le point d'entrée (post-it) est assez simple pour être rédigé tout en parlant au demandeur.

Traiter une demande

Lorsqu'un membre de l'équipe commence à travailler sur une demande, il déplace le post-it correspondant de la colonne "Travail en attente" vers la colonne "Travail en cours". Chaque membre de l'équipe a son couloir sur le tableau pour organiser les post-its et montrer clairement qui travaille actuellement sur une tâche donnée. Une fois la tâche terminée, elle est déplacée vers la colonne "En attente retour client" pour indiquer que le membre de l'équipe tente de contacter l'utilisateur final afin de s'assurer que celui-ci est satisfait ou pour lui communiquer de nouvelles modifications ou instructions. Une fois que c'est fait, la tâche est déplacée vers la colonne "Terminé". Lorsque l'utilisateur final est présent lors du traitement de la demande, par exemple lors de l'installation d'un logiciel ou la mise en place d'un projecteur, la tâche peut passer directement de la colonne "Travail en cours" vers la colonne "Terminé". Quand un membre de l'équipe termine une tâche, il écrit la date de fin sur le post-it de la tâche.

A partir de là, nous laissons un peu de temps à l'équipe pour s'habituer à ce nouveau processus. Chaque matin, nous vérifions le tableau et l'après-midi nous observons la manière dont l'équipe procède et si quelqu'un a éventuellement besoin d'aide pour utiliser le tableau (ou de façon moins passive, nous circulons pour rappeler aux gens d'utiliser le tableau). A la fin de la semaine, nous récupérons les tâches dans la colonne "Terminé" et nous saisissons les dates de début et de fin dans un tableur. En nettoyant la colonne "Terminé" à intervalles réguliers, nous donnons également à l'équipe une mesure visuelle et même un objectif pour la semaine à venir.

Un peu plus tard, on peut proposer d'autres idées concernant le moment opportun pour supprimer des tâches de la dernière colonne. Le but est d'obtenir une vision claire à un niveau élevé de la façon dont les choses fonctionnent correctement ou non. Un autre choix serait donc de supprimer chaque jour les tâches qui datent de plus de sept jours, de sorte que la colonne "Terminé" montre la valeur du travail effectué sur la semaine.

Modifications du processus et limites de Kanban

Après plusieurs semaines d'utilisation du tableau, l'équipe a pu recueillir les réactions des gens et commencer à travailler sur les prochaines étapes. A présent, l'équipe a pris l'habitude de ce processus et doit normalement l'utiliser de manière cohérente. L'équipe a commencé à utiliser le tableau pour rechercher de nouvelles tâches à traiter, répondre à une question d'un utilisateur final sur le statut d'une demande, et les dates de début et de fin vont commencer à donner une image claire des délais de résolution actuels.

Jusqu'à maintenant, l'objectif a été que l'équipe utilise le tableau et nous n'avons pas mis de limites sur la façon dont les tâches sont sélectionnées, sur le nombre de tâches parallèles sur lequel travaille quelqu'un, etc. Cela a permis à l'équipe de s'engager et de visualiser sa situation actuelle, même si c'est la pagaïe. C'est le bon moment pour commencer à améliorer le tableau et introduire des améliorations au processus.

Revoir les étapes du processus

Après avoir parlé à l'équipe et examiné les post-its sur notre tableau actuel, l'équipe a décidé de modifier le tableau en ajoutant un endroit pour les "Tâches escaladées". Cette modification a été une idée de l'un des membres de l'équipe pour nous aider à mieux suivre les tâches qui ont été escaladées aux Administrateurs systèmes et au Développement afin qu'ils ne prennent pas de place dans la colonne "Travail en cours", nous ne voulions pas les perdre en les sortant complètement du tableau. Pour l'équipe de l'entreprise ABC, cette demande avait du sens, nous l'avons donc ajouter au tableau.

KanbanPt2 VisBoard 2
Tableau visuel de l'entreprise ABC avec une nouvelle étape d'escalade des tâches

Le helpdesk de l'entreprise ABC utilise un tableau qui définit les processus en termes de statut de la tâche. Bien que ce soit une méthode commune, ce n'est pas le seul moyen de prendre en considération les tâches. Vous pouvez essayer d'autres choses qui peuvent correspondre au cycle de vie des tâches à travers les compétences fonctionnelles (développeur, technicien, administrateurs systèmes), les départements ou les phases (analyse, conception, réalisation, qualification, tests utilisateurs, fin). Il y a toutes sortes de départements informatiques organisés de manière différente et ce qui fonctionne pour l'entreprise ABC peut ne peut être la solution pour vous.

Les limites de Kanban

L'une des caractéristiques importantes d'un tableau Kanban, c'est l'idée de limiter la quantité de travail en cours dans le processus. Dans un environnement industriel, nous pourrions utiliser les capacités des équipements pour nous aider à calculer des chiffres pour chaque étape du processus, mais dans notre environnement informatique nous n'avons rien d'aussi évident. Nous pourrions passer des semaines à essayer de trouver des équations ou des chiffres parfaits, mais nous allons simplement choisir arbitrairement quelques chiffres fondés sur le nombre de personnes de l'équipe. Si ces chiffres ne fonctionnent pas parfaitement, alors nous pourrons les ajuster un peu plus tard et expérimenter de nouveau pour trouver notre zone de confort.

Nous allons également attribuer à chaque membre une colonne "principale" où ils ont l'habitude de travailler. Puisque les limites de Kanban imposent un nombre maximal de tâches autorisées dans chaque étape du processus, il y aura des moments où des pans entiers du tableau seront bloqués. Par exemple, si la personne responsable de la colonne "En attente retour client" est surchargée ou en congé maladie, l'ensemble du département sera bloqué parce que la colonne "En attente retour client" est pleine. Lorsque cela arrive, les gens quitteront leur colonne "principale" pour aider à éliminer les goulots d'étranglement.

KanbanPt2 VisBoard 3
Tableau visuel de l'entreprise ABC avec des limites définies

Traitement des tâches

Le dernier changement sur notre processus concernera la manière de répartir les tâches et la manière dont elles se déplacent à travers le tableau. Jusqu'à présent, nous n'avons pas contraint la manière ou le moment auquel les gens choisiront de travailler sur certaines tâches plutôt que d'autres, ou comment prioriser les nouvelles tâches. Un des concepts importants de Kanban est de tirer les tâches à travers le processus au lieu de les pousser. A chaque étape, les membres de l'équipe choisissent une tâche de l'étape précédente pour travailler dessus et ceci dans les limites imposées par la colonne concernée. Pour permettre d'identifier les tâches qui sont prêtes à être sélectionnées, nous avons ajouté une sous-colonne ombrée à chaque colonne. Pour la colonne "Travail en attente", la sous-colonne ombrée contient les prochaines tâches prioritaires, et pour les autres colonnes il s'agit plutôt d'une sous-colonne "Terminé".

Les tâches terminées comptent systématiquement dans les limites affectées à chaque colonne, donc si le processus se détraque alors le flux de tâches va progressivement se transformer en embouteillage. Au fur et à mesure que les membres de l'équipe vont remplir leurs colonnes amont, ils devront basculer sur les colonnes avales pour aider à résoudre le problème. Ceci garantit que lorsque survient une situation complexe, elle est immédiatement traitée au lieu d'autoriser que tout le monde soit mis sur la touche. Cela garantit également que même les pires situations sont traitées d'une manière opportune et que les délais de résolution sont constamment améliorés.

Analyse finale

L'équipe a un fait un certain nombre de gains grâce à ce nouveau processus, ce qui a également ouvert la porte à l'amélioration continue et au fait de restaurer une bonne image de l'équipe au sein de l'entreprise.

Flux de processus

Initialement, les personnes travaillaient sur plusieurs tâches à la fois, diluant leur concentration et perdant à chaque fois du temps quand ils passaient d'une tâche à l'autre. En l'absence de priorisation, il n'y avait aucune garantie sur l'instant où une tâche serait sélectionnée par un membre de l'équipe, les tâches pouvaient même être égarées ou complètement oubliées. La communication à l'utilisateur final était incohérente et les tâches escaladées étaient rarement communiquées ou suivies, les solutions complexes mises en œuvre n'étaient généralement pas expliquées et généraient des tâches supplémentaires à traiter.

KanbanPt2 VisBoard 4
Progression dans le temps du tableau visuel de l'entreprise ABC

Un membre de l'équipe a été affecté à la gestion de la communication avec les utilisateurs finaux. Ce membre de l'équipe est responsable du suivi des demandes avec les utilisateurs finaux, de vérifier le statut des tâches escaladées, de répondre aux demandes de mise à jour des statuts des tâches en attente et d'accompagner les utilisateurs sur des changements ou des solutions complexes. Les nouvelles tâches sont priorisées en fonction du niveau de gravité et de la durée passée dans la file d'attente, elles sont empilées dans une file d'attente dédiée pour que le prochain technicien disponible les traite. Les membres de l'équipe se concentrent sur l'exécution d'une tâche unique à la fois et lorsqu'elle est terminée, ils la transmettent immédiatement à des fins de reporting et sélectionnent la prochaine tâche de plus haute priorité dans la file d'attente. Un calcul statistique de distribution est réalisé chaque semaine pour obtenir le nombre de jours écoulés entre la réception et la résolution des tâches, ce résultat est utilisé comme une métrique par l'équipe et pour les objectifs hebdomadaires.

L'équipe a réalisé des gains sur leurs tâches en attente avec moins d'interruptions, moins d'allers-retours coûteux entre les tâches, et en étant capable de dédier un membre de l'équipe pour la communication avec les utilisateurs finaux. Les utilisateurs finaux reçoivent des communications plus régulières et les estimations de délais sont à la fois plus constantes et plus précises. Le reporting à la direction indique que le nombre total de tâches en suspens diminue alors que le délai total entre la réception et la résolution des tâches a été réduit en termes de variabilité et de durée.

Succès

Voici quelques-uns de nos succès :

- Résultats mesurables : nous avons réduit le délai entre la réception et la résolution des tâches, et pour les prochains mois ce délai va continuer à se raccourcir jusqu'à ce que le backlog ait été traité et que nous ayons trouvons notre nouveau rythme.
- Améliorations mesurables : nous avons non seulement mesuré les résultats, mais nous avons pris une photo avant de changer le processus, ce qui signifie que nous avons maintenant des chiffres précis sur la façon dont nous avons amélioré les choses jusqu'ici.
- Statut en un coup d'œil : le tableau visuel permet d'évaluer rapidement l'état d'avancement du département, les problèmes potentiels, l'ensemble du flux de travail ou le rythme.
- Objectifs du département : des mesures précises sur les délais de résolution servent de bon indicateur clé sur la performance du département et fournissent une excellente mesure pour les objectifs annuels.
- Estimations rigoureuses : davantage de données et un processus lissé ont permis de réduire la variation dans les temps de résolution et d'estimer les tâches de façon beaucoup plus précise.
- Moral : faire participer les membres de l'équipe dans la définition de leur propre processus, essayer des idées qu'ils proposent, leur permettre d'expérimenter participent à l'augmentation du moral et du respect, ce qui augmente à terme la productivité, réduit le turnover et rend l'environnement de travail beaucoup plus agréable.
- Productivité accrue : le travail est maintenant exécuté plus efficacement en raison de la réduction des allers-retours entre les tâches, des recherches d'information, des interruptions pour mise à jour du statut et du manque de priorisation.

Les avantages décrits ci-dessus sont directement liés à l'application de Kanban dans un environnement général. Dans le cas de l'entreprise ABC, nous pourrions probablement ajouter d'autres gains plus spécifiques à leur environnement, si ce n'était pas une société fictive. Peut-être le plus gros gain est-il que le département fonctionne maintenant à partir d'un tableau blanc. Quelqu'un a récemment déclaré que les tableaux blancs, de par leur nature, invitaient les gens à écrire dessus ou à modifier leur contenu, tandis qu'un papier imprimé invite plutôt à la lecture seule. En quoi est-ce pertinent ? Aucun processus n'est parfait et un processus figé dans la marbre est un processus qui ne se développe pas pour répondre au mieux aux besoins de leur entreprise. En engageant les membres de l'équipe, en expérimentant et en définissant le processus sur un support modifiable, on encourage l'équipe à continuer de faire des suggestions et à continuer à essayer d'améliorer le processus et le département.

Dans le prochain article, nous explorerons l'utilisation d'un processus Kanban temporaire pour gérer un projet fonctionnel court terme. Alors que Kanban est souvent appliquée aux grands processus comme une ligne de fabrication ou un département entier, il y a des avantages à également l'utiliser pour des projets de petites tailles voire jetables. Dans cette prochaine histoire, nous examinerons l'utilisation d'un tableau kanban pour aider à gérer un projet annuel de réapprovisionnement de PC.

A propos de l'auteur
Eli Weinstock-Herman Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

jeudi, 7 juillet 2011

Appliquer Kanban aux processus informatiques (1)

J'ai traduit ce billet de Eli Weinstock-Herman : Applying Kanban to IT Processes (Part 1).

Cet article est le premier d'une suite décrivant les fondamentaux du Kanban et son application dans les processus informatiques. Ici, on donne un aperçu de Kanban et la façon dont il est utilisé dans l'industrie. Les articles qui suivront explorent différents scénarios pour vous aider à trouver des idées s'appliquant à votre propre contexte.

Récemment, j'ai vu une augmentation du nombre d'articles dans les communautés de développement et de gestion de projet Agile et qui vantent les mérites de Kanban, en montrant la valeur que Kanban a permis d'apporter lorsqu'il est utilisé avec des méthodes Agile. La plupart de ces articles se concentrent fortement sur l'aspect visualisation (Visualiser des projets agile en utilisant des tableaux Kanban par exemple), certains font même ressortir quelques autres avantages de Kanban, ou se contentent simplement de revendiquer que Kanban est un "marteau d'argent à la recherche d'un clou". Dans la communauté informatique, il semble que cela soit fortement orienté gestion de projets logiciels et développement, mais Kanban est applicable à de nombreux autres domaines de l'informatique.

Qu'est-ce-que Kanban ?

Kanban est un terme japonais signifiant "tableau visuel" ou "enseigne" et est un outil pour réduire le temps de cycle[1] d'un processus, permettant d'accroître la visibilité dans le flux des processus et de réduire la quantité de travail en cours[2]. En tirant le meilleur parti de cette visibilité, nous pouvons voir où le flux de travail stagne, se bloque en créant des goulots d'étranglement ou en réduisant l'efficacité des étapes amonts. Kanban est utilisé dans le Lean Manufacturing pour disposer d'une meilleure visibilité du processus et de son état d'avancement, pour réduire les gaspillages (et les coûts), et pour aider à atteindre une capacité de production juste-à-temps[3].

Le signal Kanban

À son stade basique, Kanban est un système de signalisation qui indique aux étapes amonts d'un processus de production qu'il y a une exigence ou une demande client pour faire X.

Kanban Simple Picture

Dans un processus de fabrication, la commande client est convertie en une ou plusieurs cartes qui représentent les exigences de production permettant de satisfaire la commande. Chaque carte ou symbole définit le produit à fabriquer et la quantité nécessaire. La carte est communiquée au responsable de l'entité concernée qui va répondre à la demande de production. Si ce responsable a un tableau visuel pour afficher la file d'attente des commandes ou la capacité disponible, il placera la carte reçue dans l'emplacement vide suivant, sinon il met à jour le tableau. Selon la complexité du processus, la réception ou l'exécution du signal Kanban pourra déclencher des signaux supplémentaires dans les étapes amonts du processus ou vers le personnel chargé d'amener le matériel nécessaire à la réalisation de l'étape de production. Chaque étape a un nombre limité d'emplacements sur le tableau qui définit le nombre maximum de cartes qui peuvent cohabiter à un point du processus à un instant donné. Cette limite Kanban contraint la quantité de travail et le nombre d'éléments en cours de travail et empêche que le travail non fini ou les demandes s'accumulent.

Kanban Cards

Limiter la quantité de travail en cours dans le processus à une petite valeur maîtrisable, nous permet de continuer à utiliser pleinement nos ressources (dans ce cas, les machines et les opérateurs), tout en réduisant la quantité de travail partiellement terminé et en attente d'être terminé. L'application de limites Kanban à un processus nous aide à commencer à réduire la variabilité du temps de production d'un produit, ainsi qu'à supprimer la nécessité (et la tentation) de différer la priorité du travail lors de chaque étape. Bien que cela puisse sembler ralentir les temps de réponse lorsqu'une commande prioritaire arrive, cela accélère en réalité son traitement parce que nous n'avons pas besoin de réorganiser nos ressources pour abandonner 47 tâches en suspens partiellement démarrées. Nous positionnons tout simplement la commande prioritaire dans la file d'attente de la dernière étape (si un emplacement est disponible) et nous laissons le signal remonter à travers les étapes précédentes de manière classique. Puisque nous avons déjà une quantité limitée de travail en cours, nous sommes en mesure de traiter de nouvelles demandes rapidement, sans interrompre les items sur lesquels nous nous sommes déjà engagés.

En supprimant les files d'attente de travaux non terminés et la repriorisation entre chaque étape, nous avons réduit la quantité de non-valeur générée par les opérateurs et amélioré à la fois la précision et (généralement) le délai estimé et communiqué au client. Nous avons également réduit le nombre des changements de priorité parce que nous terminons chaque tâche avant de passer à la suivante, au lieu d'aller et venir entre plusieurs commandes en suspens. La suppression des changements de priorité inutiles constitue une économie immédiate, car ils n'apportent aucune valeur directe au client, la diminution des délais de livraison[4] améliore notre réactivité pour le client final et la diminution des changements de priorité ainsi que du temps consacré au fait de recommencer à travailler sur une tâche[5] augmente notre capacité sans coûts additionnels.

Visualisation et Métriques

Visualiser les demandes à chaque 'poste de travail' en utilisant un tableau réel est un bon moyen de communiquer à travers le groupe et de gérer votre Kanban. Si votre tableau n'a que 3 emplacements pour les 'cartes' alors vous ne pourrez pas prendre plus de 3 demandes. Les personnes situées aux étapes amonts et avales, peuvent voir les progrès réalisés ainsi que la potentielle capacité excédentaire (rien à faire) à votre étape. Le tableau n'est pas seulement une méthode pour gérer vos tâches, mais aussi un outil de communication instantanée, vous permettant de vous concentrer davantage sur le fait de réaliser votre travail plutôt que de faire du reporting et de mettre à jour les métriques des tableaux de bord.

Initial Example Board
On finit 2 unités/jour, soit environ 14 jours pour traiter une nouvelle commande

Un autre avantage majeur des méthodes Kanban apparaîtra avec la création initiale du tableau visuel. Outre le fait de définir clairement les opérations ou les étapes de production, les tâches actuelles sur le tableau, les demandes actuelles et les travaux en cours vont commencer à mettre en évidence les goulots d'étranglement. Au fur et à mesure que le temps passe et que le système kanban vous oblige à réduire ce backlog, les goulots d'étranglement vont continuer à devenir de plus en plus évidents, montrant les étapes où des améliorations directes auront un impact sur le délai de livraison pour l'ensemble du processus. Dans de nombreux systèmes, lorsqu'une étape n'a plus rien à traiter dans un système Kanban, les personnes affectées à cette étape remontent à l'étape précédente pour aider à terminer les tâches en suspens. Des règles simples ou une réorganisation de l'équipe actuelle peuvent continuer à donner des gains de performance au fur et à mesure que le tableau nous permet de visualiser et détecter les problèmes de ralentissements, les hoquets de production ainsi que les étapes potentiellement sans travail en cours.

Kanban Example Board
On finit 2 unités/jour, soit environ 5 jours pour traiter une nouvelle commande

La communauté du lean manufacturing a des centaines d'exemples de tableaux visuels, mais j'en profite plutôt pour vous donner ici quelques liens sur des articles concernant le développement logiciel Agile. Les tableaux Kanban ne sont pas coûteux et, à mon avis, devraient toujours commencer par un tableau réel avant d'être enfoui dans une solution logicielle (si vous le faites).

- Article "Lean Software Development in Small Teams (lien mort)" - Tableau blanc et aimants
- Article "Evolution of a Kanban Board" - Tableau blanc et post-its
- Article "Visualizing Agile Projects with Kanban Boards" - Copieusement illustré et beaucoup d'informations
- Article "The Kanban Story - Kanban Board" - Résultat final (et simple !) pour un exemple concernant le développement logiciel

Une recherche sur Internet vous donnera de nombreux exemples supplémentaires dans une variété d'environnements.

Appliquer Kanban dans un département informatique

Maintenant que nous avons une idée sur la manière dont fonctionne Kanban, nous pouvons commencer à explorer comment l'appliquer à des processus informatiques, que ce soit dans des environnements administratif, support et développement logiciel. Initialement l'idée d'appliquer Kanban dans un environnement non industriel peut sembler difficile... les exemples couvriront donc un large éventail de situations possibles. En explorant plusieurs exemples de réalisations, nous pourrons avoir un aperçu ou de nouvelles idées sur la façon d'appliquer ces concepts (et voir les avantages qui en résultent) dans nos environnements informatiques respectifs.

A propos de l'auteur
Eli Weinstock-Herman Eli a plus d'une dizaine d'années d'expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l'administration de bases de données, l'architecture et l'intégration de systèmes industriels, l'administration de systèmes, ... dans plusieurs secteurs industriels, en passant par l'éducation et l'industrie pour aller jusqu'au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l'amélioration des processus, le codage, la qualité, l'administration de systèmes, les pratiques de développement et l'architecture logicielle.

Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] Temps de cycle : le temps que cela prend de traiter une commande de sa réception à sa livraison

[2] Travail En cours : produits incomplets actuellement en cours de traitement dans le processus ou attendant de (ré-)entrer dans le processus pour être terminé. Travail non fini.

[3] NdT : JIT = Just In Time

[4] NdT : lead times

[5] NdT : rework

- page 1 de 15