Fabrice Aimetti

Nouveau blog : agilarium.blogspot.com

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

Tag - Agilité

Fil des billets

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.

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.

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

mardi, 5 juillet 2011

Kanban pour maîtriser le développement incrémental

Jeff PattonJ'ai traduit cette présentation de Jeff Patton : Using Kanban Techniques to Control Incremental Development. J'ai ajouté le slide #5 après avoir trouvé et visionné les vidéos du jeu de construction d'avions en papier.

Lien : Utilisation des techniques Kanban pour maîtriser le développement incrémental

Kanban pour maîtriser le développement incrémental


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

lundi, 4 juillet 2011

LEGO pour une simulation Scrum

Alexey KrivitskyJ'ai traduit un article d'Alexey Krivitsky : "Lego For Extended Scrum Simulation". Alexey y décrit un jeu de simulation qui a pour objectif d'apprendre aux gens à comprendre Scrum par la pratique en construisant une ville avec des legos... beaucoup plus élaboré que mon Scrum Police Lego Game :)

Lien : LEGO pour une simulation Scrum

LEGO-for-extended-SCRUM-simulation-FR

Feedback :


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

dimanche, 3 juillet 2011

5 arguments contre Kanban

Nick OostvogelsJ'ai traduit cet article de Nick Oostvogels : 5 arguments against Kanban.

Pas d'accord
(image by Saltatempo)

A chaque fois que vous songez à utiliser Kanban pour gérer vos flux de valeur, vous entendrez des arguments cinglants contre cette pratique. Ceci est normal et n'est pas lié à Kanban, cela arrive à chaque initiative de changement. J'ai compilé une liste de questions et d'arguments auxquels j'ai dû faire face lors de l'introduction de Kanban et je propose quelques moyens d'y répondre.

1. Il faudra plus de temps !

Les gens craignent que si l'on passe à un modèle de flux continu, sans timeboxes ou itérations, le travail prenne plus de temps au final. Après tout, la plupart des managers ont entendu parler de la loi de Parkinson qui stipule que le travail se développe de façon à remplir le temps disponible pour son achèvement.

C'est une préoccupation légitime. Une équipe moyenne aura des difficultés à se concentrer fortement autant qu'ils l'auraient fait dans un cycle itératif où il y a toujours une démo qui se prépare dans un proche avenir. Heureusement, il existe des moyens de travailler dans un flux continu et de toujours conserver une grande concentration. Par exemple, vous pourriez mettre en œuvre une cadence. Toutes les x semaines, nous faisons une démo à nos parties prenantes. Quoique vous ayez terminé à cette date, cela leur sera montré. Nos mesures seront utilisées pour définir les besoins. Si vos parties prenantes savent qu'en moyenne vous livrez 6 features par semaine, ils s'attendront à voir six features terminées lors de la démo hebdomadaire.

Une autre façon de stimuler la concentration est de visualiser la tendance de votre moyenne de lead time ou de temps de cycle. Lorsque le temps moyen est en hausse, quelque chose cloche et nous pouvons inspectez l'ensemble. Lorsque le temps moyen est en baisse, l'équipe est sur sa lancée et gagnera encore plus d'énergie en visualisant son travail.

Conclusion : des équipes très mûres garderont leur concentration d'après mon expérience. Nous pouvons aider des équipes de maturités basses et moyennes à se concentrer en utilisant des techniques telles que la cadence ou la visualisation.

2. Nous perdons notre capacité à planifier

Passer de l'estimation à la mesure déclenchera toujours cette réaction. Comment pouvons-nous prendre des engagements pour nos clients si nous n'avons pas d'estimation sur l'effort ?

La vérité c'est que rien n'a vraiment changé. En Agile, nous utilisons déjà la vélocité comme une mesure pour corriger notre planning. En Kanban, nous utilisons des mesures pour planifier.

Bien entendu, vous devez être en mesure d'extrapoler vos premières mesures pour créer un planning de livraison que vous pouvez régulièrement faire coller à la réalité. Il y a deux façons simples de faire cela. Découpez toutes les features de sorte qu'elles aient plus ou moins la même taille, ou attribuez-leur un poids relatif.

De cette façon, vous pouvez utiliser vos mesures de lead time moyen ou temps de cycle moyen pour calculer le temps nécessaire qu'il faudra pour terminer les fonctionnalités restantes de votre prochaine version.

3. Coûts élevés de refactoring de l'architecture

Si nous tirons une feature à la fois, personne n'aura le temps de penser à l'architecture du système et se contentera juste de construire au-dessus de l'existant.

Cet argument ne proviendra probablement pas d'une équipe Agile, car elle connaît déjà la faisabilité d'une architecture émergente. Ce n'est pas moins différent dans un modèle de flux que dans un cycle itératif. Des tâches techniques doivent être prévues dans chaque feature et le refactoring est un effort continu. Je ne dis pas que c'est facile, mais vous pouvez apprendre à le faire.


4. Les choses vont rester coincées, nous ne pouvons pas garder les limites de TAF[1]

Quand vous êtes porteur du message que seulement x features pourront être traitées et que les limites ne peuvent pas être dépassées, les gens commencent à paniquer. Ils savent par expérience que certaines features restent en cours pour une longue période parce qu'ils attendent quelque chose qui est en dehors de leur contrôle. L'idée de respecter la limite et de faire autre chose ne remet pas en cause nos croyances et la façon dont nous avons été élevés. Vous devez rester occupé tout le temps et faire de votre mieux !

Par contre ! Dans le cas d'un système à flux tirés comme Kanban, respecter les limites de TAF est une chose puissante. Si vous êtes coincé et ne pouvez pas démarrer une nouvelle tâche, un peu plus tard, le poste de travail aval va rester coincé aussi et ainsi de suite. Cela crée un problème immédiat pour l'ensemble du système, et ne se limite plus à vous seul. C'est sûr que les limites de TAF seront inconfortables au début, mais elles vont déclencher une action rapide ! Ensemble, vous allez trouver un moyen de désengorger le système et de terminer le travail, au lieu de simplement commencer une autre tâche et de ne rien finir.

5. Nos parties prenantes ne se soucient pas d'alimenter le flux

Elles veulent que toutes les features soient livrées aussi vite que possible.

Dans cette situation, allez à la cause racine. Pourquoi ne se soucient-elles pas de prioriser la file d'entrée ? Elles n'ont probablement pas vu la valeur que cela créait. Elles n'ont peut-être jamais eu la possibilité de changer et de s'adapter lorsque le développement commençait. Expliquez-leur que le planning est obsolète immédiatement après avoir été créé en raison de nouvelles idées, des changements de situation du marché, etc. Certaines features ne sont pas si urgentes que ça, tandis que d'autres peuvent devenir plus importantes. Être capable de changer rapidement le périmètre de votre prochaine version vous donne un énorme avantage concurrentiel parce que vous êtes en mesure de répondre aux attentes des clients avec plus de précision.

C'est la liste de mes cinq arguments contre Kanban et quelques options pour y répondre. Si en vous connaissez d'autres, je suis très intéressé.

Feedback :



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

Notes

[1] NdT : WIP = Work In Process - TAF = Travail à Faire

samedi, 2 juillet 2011

Un exemple de backlog produit sous forme tabulaire

Mike CohnJ'ai traduit ce billet de Mike Cohn : "A SAMPLE FORMAT FOR A SPREADSHEET-BASED PRODUCT BACKLOG".

Je veux montrer une façon très facile de mettre des user stories dans un backlog produit sous forme tabulaire. J'ai écrit ceci après avoir vu quelqu'un tweeter une capture d'écran d'un backlog produit que j'avais fait il y a 9 ans et je me suis dit : "Aïe, c'est obsolète par rapport à ce que je fais aujourd'hui...".

Comme vous le savez probablement, je suis un grand fan pour tout ce qui consiste à écrire le backlog produit sous la forme de user stories et à écrire des user stories sous la forme "En tant que, Je souhaite, Afin de". Par exemple : "En tant que voyageur habituel, Je souhaite vraiment être en mesure de me connecter à Internet en plein vol Afin de pouvoir mettre à jour mon blog tout en voyageant plutôt que d'avoir à tout enregistrer dans un fichier texte et mettre à jour mon blog plus tard." (pouvez-vous deviner où je suis pendant que j'écris ceci ?)

Ce que j'ai trouvé me permet de disposer d'un format de user story très facile à travailler sous forme tabulaire en utilisant les en-têtes de colonne. Nous aurons donc les en-têtes de colonne "En tant que", "Je souhaite" et "Afin de". Le contenu de chaque user story est alors clairement visible dans chaque ligne. Des colonnes supplémentaires peuvent être ajoutées pour des choses comme un identifiant unique, des commentaires, un statut et ainsi de suite. Dans cet exemple, j'ai également inclus une colonne pour le thème, un moyen de regrouper les stories. Vous pouvez le voir dans la capture d'écran ci-dessous. Vous pouvez cliquer sur l'image pour l'agrandir.

Backlog Produit


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

vendredi, 1 juillet 2011

Scrumban

Corey LadasJ'ai traduit ce célèbre article de Corey Ladas : "Scrum-ban". Ça date de 2008 et ça n'a pas vieilli. Que du bonheur !

Comme de plus en plus de gens s'intéressent aux idées Lean et à leur application dans la gestion des connaissances et des projets, il est utile de trouver des moyens pour que ce soit plus facile de démarrer ou d'apprendre quelques notions de base qui peuvent mener à une compréhension plus profonde un peu plus tard. Pour ceux qui sont curieux au sujet de Kanban dans un contexte bureau, il n'est pas rare de trouver des gens qui sont soit actuellement en train d'utiliser Scrum, ou qui ont une certaine perception de Scrum en tant que représentant de la pensée Agile. D'une façon ou d'une autre, les utilisateurs de Scrum composent une part importante de l'audience Kanban. Puisque Scrum peut être décrit comme une instance dans la langue que nous utilisons pour décrire les systèmes Kanban, il est également assez facile d'élaborer et de décrire des hybrides Scrum / Kanban. Cela peut être utile pour les équipes Scrum existantes qui cherchent à changer de taille ou améliorer leur capacité. Cela peut également être utile pour des nouveaux utilisateurs plus prudents qui trouvent un réconfort dans une méthode "établie"[1].

scrumban-001 L'idée d'utiliser un simple tableau de tâches avec des cartes ou des post-its est aussi vieille que l'Agilité elle-même. Une présentation simple est un workflow A faire -> En cours -> Fini. Les cartes représentent des items de travail à traiter dans le périmètre actuel. Des noms peuvent être associés aux cartes pour indiquer qui travaille sur quoi. Les équipes agiles ont eu recours à ce genre de méthode depuis longtemps, et quelques personnes ont remarqué dès le départ que cela avait une certaine ressemblance avec la notion de kanban dans les systèmes lean.

Bien sûr, divers outils électroniques existent qui remplissent ces fonctions, mais le simple tableau de tâches représente quelques principes Lean que je trouve à forte valeur ajoutée, simple technologiquement' parlant et d'un point de vue contrôle visuel. L'utilité d'une telle méthode simple de gestion de workflow, c'est qu'elle est facile à gérer, et plus important encore, elle est facile à changer. Se blottir autour d'un écran d'ordinateur, même très grand, ne peut en aucune façon remplacer l'interactivité tactile et sociale qui accompagne la manipulation d'un grand tableau de tâches. Peut-être qu'un jour ce sera le cas. Mais pas aujourd'hui. Les outils électroniques sont bons pour gérer des listes de choses, comme les backlogs et les bugs, et produire des rapports. Des outils simples peuvent constituer un concept difficile à expliquer aux fanatiques de technologie, mais c'est ensuite que l'on comprend leur valeur.

scrumban-002 Un problème avec le tableau de tâches et ses post-its, c'est qu'il n'y a rien pour vous empêcher d'accumuler une grosse pile de travail en cours. Le timeboxing, de par sa nature, établit une limite de TAF[2] sur ce qui peut être traité, mais il peut encore aller plus loin que souhaitable.

Si un kanban est un objet qui représente une demande de travail, et que notre tableau de tâches échappe à tout contrôle, quel est le véritable problème ? Le problème c'est que le kanban représente davantage qu'une simple demande de travail sur une carte, et mettre des post-its sur un tableau blanc n'est pas suffisant pour mettre en œuvre un système à flux tiré.








Un kanban est plus qu'une carte

Billet de 5 euros Dans une économie moderne, la production et la distribution de biens et de services rares sont régulées par un système monétaire basé sur les prix. Le monétaire peut être représenté par des billets de banque, qui ont peu de valeur intrinsèque, mais qui par convention, peuvent être échangés contre des biens et des services réels. L'existence d'un support neutre d'échange rend possible un système de calcul économique de la rareté relative de l'offre de biens dans une économie. Un tel système basé sur les prix est ce qu'on appelle un marché. Les marchés communiquent à leurs participants la valeur économique de la production et de la distribution.






Billet du Zimbabwe Un kanban représente une partie de la capacité de production de certaines économies internes proches. C'est un support d'échange pour les biens et les services fournis par les exploitants d'un système de ressources productives. L'offre de kanban en circulation est contrôlée par une fonction de régulation qui renforce sa valeur. Autrement dit, un kanban est une sorte de monnaie privée et le manager de l'atelier est la banque qui l'émet, à des fins de calcul économique.

Si vous allez encore plus loin dans l'analogie monétaire, alors vous pouvez dire que Kanban ne concernent pas du tout les post-its. Tout comme l'argent ne concernent pas les billets. Kanban traite des limites, la quantité en circulation. La façon dont cela est représentée dans une transaction est accessoire.

Une règle simple pour comprendre tout cela pourrait être :

Un post-it tâche sans limite n'est pas un kanban, de la même manière que la photocopie d'un billet d'un dollar n'est pas de l'argent.

Si vous utilisez un objet résistant comme une carte en plastique, alors c'est facile à gérer : contrôlez le nombre de cartes en circulation. Si toutes les cartes disponibles sont déjà en circulation alors la personne suivante qui vient en chercher un, devra attendre qu'une carte revienne. C'est le but même du système kanban. Toutefois, si vous utilisez un support jetable, comme des cartes ou des post-its, alors vous avez besoin d'un autre mécanisme pour réguler "l'offre argent". Dans notre cas, nous écrivons simplement la quantité de kanban en circulation sur le tableau de tâches, et nous allouons de nouvelles cartes en fonction de cette limite.

Cela signifie qu'un kanban dessert deux fonctions : il s'agit d'une demande pour faire quelque chose en particulier, mais c'est aussi la permission de faire quelque chose en général. Les gens, qui se forment à la pensée lean, ont beaucoup de mal avec cette deuxième notion de permission. Mais c'est précisément de cette manière là que vous pouvez "optimiser l'ensemble" ou "subordonner l'ensemble à la contrainte".

Croquant à l'extérieur, moelleux à l'intérieur

Tout comme un post-it non régulé sur un panneau de liège n'est pas un kanban, un planning d'itération timeboxé n'est pas un système à flux tiré. Aucune interprétation raisonnable du Lean ne consiste à construire une prévision d'un mois à moins que le temps de cycle pour chaque ordre de travail soit aussi d'un mois. L'équivalent d'un mois de trucs en cours de travail représente bien entendu une taille de lot beaucoup plus petite que 3 mois ou 18 mois, mais si votre backlog d'itération contient 20 items de travail, alors c'est encore 19 de trop pour que ce soit un système à flux tiré.

Néanmoins, il n'est pas difficile d'ajouter à Scrum quelques pratiques simples qui nous permettent d'obtenir quelque chose qui ressemble plus à un workflow lean. Le plus évident c'est de réduire la longueur de l'itération, même si cela n'est pas sans problème[3]. Comme nous le verrons, il est possible d'améliorer progressivement Scrum avec des fonctionnalités de plus en plus orientées flux tiré si bien qu'il ne restera plus à la fin que les vestiges du processus original. L'approche simple est de commencer avec des itérations à la mode Scrum et un processus de planification d'itération, puis de commencer à ajouter des fonctionnalités orientées flux tiré au processus interne de l'équipe.

scrumban-003 Une technique simple qui nous rapproche beaucoup plus de notre définition du kanban c'est de fixer une limite au multitâches pour chaque individu. Vous pourriez avoir un principe simple comme : préférez finir le travail plutôt que d'en commencer un nouveau, ou vous pourriez l'exprimer comme une règle qui dit : essayez de travailler sur un seul item de travail à la fois, mais si vous êtes bloqué, alors vous pouvez travailler sur un deuxième item de travail, mais pas plus. Dans notre exemple, cette règle nous donne une limite de TAF de 6.

Une autre technique courante est de prendre les tâches le plus tard possible. Certaines équipes vont pré-affecter l'ensemble des tâches connues lors de la planification de l'itération. Ce n'est généralement pas une bonne idée, parce que cela crée artificiellement un chemin critique. Attendre le "dernier moment responsable" pour assigner des tâches aux personnes maximise l'apprentissage et vous rapproche davantage d'un système à flux tiré.





scrumban-004 Ce n'est pas parce qu'un individu peut avoir plus d'un item de travail affecté dans le processus que cela signifie que tout le monde doit se voir affecter plus d'un item de travail dans le processus. Le problème avec notre règle sur le multitâches c'est qu'elle optimise localement sans prendre en considération l'ensemble. Une limite implicite sur le TAF total de 6 c'est devoir probablement tolérer encore trop de TAF pour nos trois personnes. Une limite de 4 sur 5 items de travail au total à un instant donné dans le processus permet encore de gérer des exceptions au multitâches, mais n'autorise pas cet évident dysfonctionnement qui consiste à ce que chacun porte deux items de travail. Ici, nous avons dépassé le stade de la règle sur les individus et nous venons en fait d'énoncer une règle sur les post-its/tâches elles-mêmes. Ca y est, nos cartes sont dans l'esprit du kanban.

Une autre amélioration que nous pouvons apporter à notre précédent tableau c'est d'ajouter une file d'attente "Prêt" entre le backlog et les travaux en cours. La file d'attente "Prêt" contient des éléments qui sont en attente dans le backlog, mais qui ont une priorité haute. Nous n'avons pas encore affecté de personne à ces tâches, mais dès que quelqu'un deviendra disponible, il pourra prendre l'une de ces tâches au lieu de choisir quelque chose en dehors du backlog. Cela nous permet de découpler le processus d'affectation des travaux du processus de priorisation des travaux, de plus il simplifie l'affectation. La file d'attente "Prêt" a aussi une limite kanban, et elle devrait avoir une limite faible, puisque son seul but est d'indiquer quels items de travail doivent être ensuite démarrés.

A partir de là, nous pouvons commencer à voir certains des mécanismes de flux tiré :

1.scrumban-005 2.scrumban-005a 3.scrumban-006

1. David termine une tâche et la déplace dans la colonne "fini".
2. David tire un nouveau kanban de la file d'attente "Prêt" et commence à travailler.
3. L'équipe répond à l'événement et sélectionne le prochain item de travail prioritaire pour le placer dans la file d'attente "Prêt".

À ce stade, nous exploitons désormais un kanban à flux tiré très simple. Nous avons toujours notre itération timeboxée et le cycle de planification, nous pourrions donc peut-être appeler une telle chose un système Scrumban !

scrumban-007 Maintenant que nous avons développé une sensation de capacité et de flux tiré, il est naturel de penser au flux. Avoir rompu notre nébuleux état "en cours" en états mieux définis peut donner plus de visibilité sur les forces, faiblesses et santé globale de l'équipe. Même des workflows Agile comme l'Extreme Programming ont des rôles et des états relativement bien définis, et un flux de travail fluide entre ces états est tout aussi important que la fluidité du travail à travers l'ensemble du processus.

Ici, nous avons décomposé l'état en cours en deux : Spécifier et Exécuter. "Spécifier" consiste à définir les critères nécessaires pour déterminer quand l'item de travail peut être considéré comme fini. "Exécuter" consiste à réaliser le travail nécessaire pour amener cet item de travail dans un état qui satisfasse ces critères. Nous avons réparti notre précédente limite de TAF de 5 entre ces deux états. Nous avons considéré que "Spécifier" prend moins de temps ici, soit une limite de 2. "Exécuter" consomme le reste de la limite, soit 3. Nous pourrions modifier cette répartition en fonction du temps et de nos variations de performance.

Puisque nous réfléchissons maintenant davantage en mode flux, ces détails supplémentaires du workflow nous invite fortement à utiliser un Diagramme de Flux Cumulé pour suivre les travaux et mesurer notre performance. Un simple burndown vous dira si vous êtes effectivement ou non en train de livrer de la valeur, mais pas vraiment sur les raisons. Le CFD[4] communique beaucoup plus d'informations supplémentaires sur le lead time et sur les stocks, ce qui peut permettre de diagnostiquer des problèmes ou même les prévenir.

En définissant un peu mieux notre workflow, nous pouvons aussi tenir compte d'une part de spécialisation fonctionnelle. Dans ce cas, on pourrait parler de spécialisation légère, c'est-à-dire le cas où certains d'entre nous préfèrent faire un type de travail plus qu'un autre, même si nous sommes capables de tout faire. Il est important de comprendre que ce genre de système à flux tiré autorise la spécialisation mais ne l'impose pas. L'équipe est propriétaire du travail et du workflow, et c'est à l'équipe de découvrir comment le faire avec efficacité.

scrumban-008 Si nous laissons la personne qui est la meilleure pour réaliser la plupart des tâches à "Spécifier", alors nous devrons également prévoir et coordonner le transfert de connaissances entre nous. Ajouter la colonne Fini de spécifier communique à l'équipe qu'un item de travail qui était auparavant dans l'état "Spécifier" est maintenant prêt à être tiré par quiconque souhaite le déplacer dans l'état "Exécuter". Le travail qui est toujours dans l'état "Spécifier" n'est pas candidat pour être tiré dans ce cas. Si le propriétaire d'un ticket dans l'état "Spécifier" veut le passer à quelqu'un d'autre en aval, il doit le mettre dans le buffer "Fini de spécifier". S'il ne veut pas le passer à quelqu'un d'autre en aval, donc le garder, il peut le mettre directement dans l'état "Exécuter", tant que la capacité le permet. Il se pourrait effectivement que l'état "Exécuter" soit plein, et que le seul travail possible soit de tirer un autre ticket de la file d'attente "Prêt" et de le déplacer dans "Spécifier".

Puisque nous avons ajouté une nouvelle colonne pour bufferiser ce qui est fini, nous avons également légèrement augmenté la limite de WIP. Le compromis c'est que l'augmentation du lead time lié à ce nouveau stock devrait normalement être compensée par la diminution du lead time en raison de l'avantage de la spécialisation. Nous avons également atténué l'impact de ce nouveau stock en partageant la limite de WIP avec l'état précédent. Cela a pour conséquence bénéfique de considérer le buffer "Fini de spécifier" comme un goulot d'étranglement à géométrie variable pour l'état précédent. Plus le travail s'empile dans le buffer "Fini de spécifier", moins vous pouvez traiter de travail en cours dans l'état "Spécifier", jusqu'à ce que ce ne soit plus possible du tout. Mais nous l'avons compris, ce n'est pas "juste par hasard".

Si nous autorisons la spécialisation dans le workflow et les transferts de connaissance qui en découlent, alors nous aurons aussi besoin de nous mettre d'accord sur les résultats attendus à chaque transfert de connaissances. Nous pouvons le faire en définissant de simples procédures standards pour chaque état. Ces dernières n'ont pas besoin d'être compliquées ou même exhaustives. Dans notre exemple, il s'agit de simples check-lists rédigées directement sur le tableau de tâches. Elles ont seulement besoin d'être suffisantes pour éviter tout malentendu entre les producteurs et les consommateurs. Ces standards sont définis par et pour l'équipe, et ses membres peuvent les changer autant que nécessaire, selon le principe du kaizen[5]. Les afficher sur un support tel qu'un tableau blanc ou un wiki renforce le sentiment de propriété partagée par l'équipe.

Scrumban niveau 2

Dans la version de base de Scrumban décrite jusqu'ici, la revue d'itération et le cycle de planification se déroulent typiquement comme dans Scrum. Mais comme notre processus de production a mûri, nous nous sommes aussi donnés des outils pour rendre le processus de planification plus efficace, plus réactif et mieux intégré au métier qu'il dessert.

Avec ce système à flux tiré, notre flux va se lisser au fur et à mesure que notre capacité s'améliore. Nous pouvons utiliser nos buffers inter-processus et diagrammes de flux cumulés pour montrer les faiblesses de notre processus et les opportunités de kaizen. Au fur et à mesure que nous nous rapprochons de la production, nous allons nous sentir de moins en moins concernés par le burndown et de plus en plus concernés par le temps de cycle, étant donné que l'un est la conséquence et l'autre la cause. Le lead time et le temps de cycle moyen vont devenir les principaux objectifs de performance. Si le temps de cycle est maîtrisé et que la capacité de l'équipe est équilibrée selon la demande, alors le lead time sera également maîtrisé. Si le temps de cycle est maîtrisé, alors les burndowns sont prédictibles et sans intérêt. Si les burndowns sont sans intérêt, alors le fait de se fixer des objectifs et déployer des efforts héroïques risqués devient inutile. Si les burndowns sont sans intérêt, alors les backlogs d'itération sont simplement des stocks pour planifier régulièrement et alimenter le système à flux tiré. En tant que tel, ces stocks doivent être le plus petit possible pour optimiser les coûts de planification.

Puisque l'équipe tire maintenant son travail depuis une petite file d'attente "Prêt" avant de le tirer dans l'encours, alors du point de vue de l'équipe, l'utilité du backlog d'itération c'est qu'il contient toujours quelque chose qui vaut la peine d'être réalisée ensuite. Par conséquent, nous devrions utiliser le mécanisme le moins coûteux qui saura satisfaire cette condition simple.

scrumban-009 Un mécanisme simple qui remplit l'objectif est de limiter la taille du backlog itération. Plutôt que de passer par le douloureux travail d'estimation du périmètre de chaque itération, fixez juste la taille du backlog qui tombera parfois à zéro en atteignant la fin de l'itération. C'est un calcul simple. C'est simplement le nombre moyen de choses livrées à chaque itération, qui à son tour est juste un multiple du temps de cycle moyen. Donc si vous avez 5 choses dans votre processus, en moyenne, et qu'il faut 5 jours pour finir quelque chose, en moyenne, alors vous finirez 1 chose par jour, en moyenne. Si votre durée d'itération est de deux semaines, soit 10 jours de travail, alors la taille de votre backlog d'itération sera de 10. Vous pouvez ajouter un ou deux si vous vous souciez de tomber en panne de travail. La communauté Scrum s'est un peu égarée sur ce point : il n'est jamais nécessaire d'estimer la taille particulière des choses dans le backlog. Il est uniquement nécessaire d'estimer la taille moyenne des choses dans le backlog. La plupart des efforts consacrés à l'estimation dans Scrum constituent un gaspillage.

Dans notre incarnation finale de Scrumban, la planification d'itération se tient toujours à intervalle régulier, synchronisée avec la revue et la rétrospective de l'itération, mais l'objectif de la planification est de remplir les cases disponibles, pas de remplir toutes les cases, et certainement pas de déterminer le nombre de cases. Ceci réduit considérablement les efforts et la cérémonie de planification de l'itération. Le temps consacré à estimer durant la planification de l'itération peut être réutiliser pour contrôler la qualité du travail qui arrive dans la file d'attente "Prêt". Si un item de travail est de mauvaise qualité alors il est rejeté, et les récidivistes devront menés une analyse des causes racines.

Sans les roulettes !

PapillonSi vous en êtes arrivé à ce stade dans votre évolution, vous devrez probablement réaliser que les mécanismes originaux de Scrum ne vous apportent plus grand chose. Scrum peut être utile pour aider les membres de l'équipe au départ à travailler ensemble pendant que vous mettez en place une solution plus optimisée. À un certain moment vous pouvez enlever le cocon et permettre au système à flux tiré de déployer ses ailes et prendre son envol.

La première étape au-delà de Scrum est de découpler les périodes de planification et de release. Il peut y avoir un période où vous regroupez les fonctionnalités à livrer, et une autre période qui consiste à regrouper les gens pour planifier. Si nous avons une méthode de planification au plus juste pilotée par les flux tirés, il n'y a vraiment aucune raison pour que ces deux périodes soient les mêmes. Votre équipe d'exploitation pourrait souhaiter livrer une fois par mois, et vos chefs produits pourraient souhaiter mettre en place une cérémonie de priorisation hebdomadaire. Aucune raison de ne pas s'adapter.

Une fois que vous avez brisé la timebox, vous pouvez commencer à construire au plus juste le backlog. L'Agilité implique une capacité à répondre à la demande. Le backlog devrait refléter aussi souvent que possible la compréhension actuelle que vous avez de la situation du métier. C'est-à-dire que le backlog devrait être piloté par les événements. La planification timeboxée d'un backlog n'est que ça, sauf que l'événement est une minuterie, et une fois que nous voyons les choses de cette façon, nous pouvons imaginer d'autres sortes d'événements qui nous permettent de répondre plus rapidement aux nouvelles priorités. Puisque notre système a déjà fait ses preuves sur du flux tiré, le fait d'augmenter notre réactivité ne devrait générer aucun coût supplémentaire et augmenter notre efficacité.

Le problème que nous essayons de résoudre est le suivant :

Le processus de planification du travail idéal devrait toujours fournir à l'équipe de développement la meilleure chose sur laquelle travailler ensuite, ni plus ni moins.

Une planification plus poussée n'ajoute pas de valeur et est donc un gaspillage. La planification timeboxée type Scrum prévoit généralement un backlog beaucoup plus grand que ce qui est strictement nécessaire pour récupérer l'item de travail suivant, et en tant que tel, il s'agit d'un stock inutile et donc d'un gaspillage inutile.

Le prochain événement que nous pourrions envisager pour planifier des activités de planification est le concept d'un point de commande. Un point de commande est un niveau de stock qui déclenche un processus pour commander de nouveaux matériaux. Au fur et à mesure que nous tirons des items du backlog vers le processus, le backlog va diminuer jusqu'à ce que le nombre d'items de travail restant passe en dessous du point de commande. Lorsque cela arrive, une notification est transmise aux parties responsables pour organiser la prochaine réunion de planification. Si notre backlog actuel est de 10, notre débit de 1/jour, et que nous avons défini un point de commande de 5, alors la planification sera réalisée une fois par semaine.

Une fois par semaine peut être raisonnable si les gens sont difficilement mobilisables ou s'ils ont besoin d'un peu de lead time pour prioriser. Toutefois, s'ils sont davantage disponibles, nous pouvons alors définir un point de commande inférieur. Si les planificateurs peuvent répondre dans la journée, alors peut-être pouvons-nous définir un point de commande à 2. Si le point de commande est 2, alors il n'y aura peut-être pas besoin de conserver un backlg de 10. Peut-être pourrons-nous réduire le backlog à 4... et réduire notre lead time à 6 jours dans le processus.

L'état final de cette évolution est le fait de tirer, ou de prioriser à la demande. Si les planificateurs peuvent prendre une bonne décision assez rapidement, et qu'il n'y a aucune économie d'échelle dans le fait de regrouper des décisions prioritaires, alors la taille du backlog ne doit être que de 1. Au moment où l'item de travail est tiré par l'équipe de développement, on signale à l'équipe de planification de commencer à sélectionner l'item de travail suivant. Si l'équipe de planification est assez rapide dans ses réponses, alors l'équipe de développement ne décrochera jamais. S'il y a une certaine variation ou retard dans la réponse, alors un backlog de 2 pourrait être nécessaire pour prévenir des décrochages. Mais 2 cela reste encore assez petit et lissé par rapport à 10, ou 20, ou 50... ce qui est quelque chose que j'ai vu plus souvent que je ne le voudrais.

Le même type de logique peut être appliquée à la période de livraison. Il y a une taille de lot optimale pour les livraisons et nous devrions d'abord essayer de la trouver, puis essayer de l'améliorer. Le résultat de nos efforts finira par être des fonctionnalités à la demande.

Même à ce niveau, nous avons encore un système kanban assez basique. A partir de là, nous pouvons ajouter la décomposition des items de travail (couloirs), ou la dépendance entre les flux si l'on change d'échelle. Avec une division du travail éclairée, c'est la façon dont nous pensons que le Lean montre la voie pour dimensionner l'Agilité au niveau de l'entreprise.


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

Notes

[1] Même si le concept kanban remonte au minimum à 40 ans

[2] NdT : WIP = Work in Process ; TAF = Travaux à Faire

[3] J'écrirai probablement quelque chose là-dessus dans un futur billet.

[4] NdT : CFD = Cumulative Flow Diagram = Diagramme de Flux Cumulé

[5] NdT : kaizen = amélioration continue

mercredi, 29 juin 2011

Ce dont le monde a besoin, c'est de plus de management lean

Mattias SkarinJ'ai traduit ce billet de Mattias Skarin : "What the world needs is more lean management".

- Quelle est la capacité de vos équipes ? (ce qui est régulièrement livré)
- Comment vous assurez-vous que cette capacité est en constante amélioration ?
- Quel travail avez-vous du mal à faire, et que faites-vous pour résoudre ce problème ?

Une des grandes illusions que nous a apporté la littérature sur le management, c'est que les managers gèrent les personnes. Ce sont des leaders, qui embauchent des gens talentueux pour faire le travail. Lorsque ces gens talentueux ont des ennuis, on attend d'eux qu'il trouve une force intérieure pour surmonter les problèmes d'eux-mêmes. S'ils ne le font pas, le manager intervient et s'en charge.

- Jeff n'a pas livré sa fonctionnalité à temps, il doit donc y avoir quelque chose qui ne va pas avec Jeff !
- Roger se plaint des spécifications de mauvaise qualité qu'il reçoit (il doit y avoir quelque chose qui ne va pas avec Roger, puisque pour Jeff c'est aussi le cas).
- Le manager a d'autres chats à fouetter que de s'occuper de résoudre les obstacles de l'équipe (personne au-dessus de lui ne lui a jamais demandé si les obstacles étaient résolus, mais évidemment, il doit y avoir quelque chose qui ne va pas avec ce manager).

Vous commencez à voir ce que je veux dire. Le problème, c'est que chaque problème est automatiquement transformé en un problème de personne. Mais "Qu'en est-il des compétences alors ?". Bien sûr, les compétences comptent pour beaucoup. Mais n'est-il pas un peu injuste de transformer tous les problèmes (problèmes de processus, problèmes de formation, ...) en problèmes de personnes ? Et lequel de ces problèmes a-t-il en réalité vraiment été directement créé par le système que pilote le manager ?

Donc, trouvons un meilleur moyen de gérer les choses :
- des managers qui comprennent comment le travail est fait, en observant le travail,
- des managers qui connaissent la capacité de leurs équipes,
- des managers qui posent des questions, quand la capacité diminue,
- des managers qui savent remettre en cause les hypothèses de départ, nous forçant à comprendre le problème avant de le résoudre,
- des managers qui font ça tous les jours.

C'est ce que j'appelle un manager Lean, une personne qui améliore la capacité de son organisation. Une personne qui va voir elle-même le travail réellement réalisé sur le terrain[1]. Cette attitude, cet état d'esprit, nous en redemandons... et moins de problèmes de personnes.


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

Notes

[1] NdT : Genshi Genbutsu !

lundi, 27 juin 2011

Atteindre la stabilité d'abord

Art SmalleyJ'ai traduit cet article de Art Smalley : Achieving Basic Stability.

Introduction

Le mode de production lean a considérablement élevé le niveau de compétitivité de nombreuses entreprises industrielles ainsi que le niveau de valeur livrée à leurs clients. Par ailleurs, cela a encouragé les nouveaux entrants à embrasser le lean dans des activités ne concernant pas la fabrication au sens industriel du terme, comme par exemple le développement de produits, les achats, la gestion de la chaîne logistique et l'ingénierie.

En dépit de ces succès, de nombreuses entreprises que je visite sont restées bloquées au stade de leurs efforts initiaux vers le lean. Elles essaient de créer un flux mais sans conviction. Il y a plusieurs raisons à ce manque de progrès. Les plus communes sont un manque de leadership, de ressources, ou d'engagement. Mais le piège que je vois le plus souvent est un manque de stabilité au départ dans les opérations de fabrication. Tout simplement, les processus ne peuvent pas fonctionner à cause d'éléments clés des équipements qui sont en panne.

Premiers combats de Toyota

Taiichi Ohno, l'architecte en chef du lean manufacturing, a développé les principes de base chez Toyota Motor Corporation au Japon entre 1950 et 1955. Pendant cette période d'apprentissage de cinq ans, Ohno réalisa des expériences dans les ateliers de production intensive qu'il gérait. Les concepts clés tels que le takt time[1], le flux, le travail standardisé, le changement rapide d'outils[2] et les mécanismes de base d'un système à flux tirés furent tous découverts et testés sous son contrôle.

Malheureusement, très peu a été écrit sur ce qu'a fait Ohno. Aujourd'hui nous entendons seulement parler des succès du lean et de la nature impressionnante du Toyota Production System. Les entretiens que j'ai eus avec des cadres de Toyota à la retraite m'ont conduit à adopter une perspective différente sur la difficulté à établir les bases du lean. Ces commentaires sont des réflexions typiques :

"Notre processus de changement rapide d'outils était absolument terrible, et prenait, où qu'on soit, un à deux postes[3] pour être terminé. Ensuite, la qualité de production n'a jamais été aussi bonne."

"Nos machines-outils à commande numérique étaient toutes en provenance d'Allemagne ou des États-Unis. Notre durée de fonctionnement tournait en moyenne autour de 50 à 60% au mieux, et nous avions beaucoup de mal avec la documentation étrangère et la livraison de pièces de rechange en provenance de l'étranger."

"Nous n'avons jamais eu les pièces dont nous avions besoin produites au moment où nous en avions besoin. Le matériel était rare, et il semblait que nous accordions toujours beaucoup trop d'importance aux mauvaises choses."

"Nos employés voulaient uniquement faire fonctionner une seule machine et travailler à leur propre rythme. Des montagnes de WIP[4] apparaissaient entre les processus étant donné que la vitesse des machines n'étaient pas du tout synchronisée sur le rythme de la demande clients (takt time)."

Les personnes qui déploient la démarche Lean devraient se sentir motivées par ces premiers combats menés chez Toyota. Personne n'a jamais dit que faire des améliorations/changements radicaux était un processus facile. Ce que Toyota a appris sur ce dur parcours, c'est qu'au début d'une transformation, vous avez besoin de beaucoup de stabilité avant de pouvoir réussir avec les éléments les plus sophistiqués du lean.

Étapes de mise en œuvre du Lean

Toyota a été réticent à publier ou même approuver ce qu'il considère être la bonne façon de mettre en œuvre le Lean. Leur réticence est normale compte tenu de notre tendance humaine inhérente à chercher un moyen facile de copier-coller des réponses d'ailleurs. Les cadres de Toyota ont toujours affirmé que le TPS/lean était un système de pensée et que ses pratiquants devenaient meilleurs lorsqu'ils "apprenaient en faisant".

Lorsqu'on insiste, cependant, les vétérans de Toyota précisent que certaines conditions préalables sont nécessaires pour que la démarche de mise en œuvre lean se passe en douceur. Il s'agit notamment d'y intégrer quelques problèmes concernant la disponibilité de l'équipement, le matériel disponible mais avec quelques anomalies, et une supervision poussée au niveau de la ligne de production. Et ce sont précisément ces problèmes auxquels je vois encore les industriels se heurter aujourd'hui.

Évidemment, si nous devions attendre que tous ces problèmes soient résolus, nous n'aurions jamais commencé. Le fait de mettre en œuvre des éléments lean éliminera certains de ces problèmes. Nous avons donc un problème de serpent qui se mord la queue : par où allons-nous commencer ?

Une piste provient de la façon dont Toyota travaille avec de nouveaux fournisseurs situés à l'étranger. Les consultants en production Toyota suivent généralement (mais pas de façon dogmatique) un framework permettant d'établir cette stabilité au départ, d'améliorer le processus, de rythmer le travail selon le takt time, de développer un système à flux tirés est de lisser la production. La mise en œuvre effective dépend du contexte courant et selon les propres mots de Ohno, 50 ans auparavant, qui conseille à tous de "commencer et cibler vos efforts sur votre besoin le plus crucial". Pour de nombreuses industries, cela signifie de travailler davantage sur la stabilité au départ avant d'essayer d'atteindre le flux de travail parfait.

La stabilité d'abord

Alors, c'est quoi la stabilité ? Au départ, cela implique une prédictibilité et une disponibilité constante en termes de main d'œuvre, de machines, de matériel et de méthodes - les 4Ms. Sous chacune de ces briques techniques de la fabrication, Toyota a tenté d'établir un processus cohérent et prédictible, avant d'aller trop loin avec les éléments que sont le flux et le takt time.

La raison est simple. Sans les éléments fondamentaux comme la disponibilité machine ou les ressources humaines en place, vous ne pouvez pas exécuter une ligne de production et atteindre un flux parfait ou rythmer selon le takt time. Par exemple, produire selon un takt time et atteindre un flux parfait requiert un niveau suffisant de disponibilité machine. La même chose est vraie pour le reste des 4Ms.

Comment savez-vous si vous avez suffisamment de stabilité dans les opérations concernées par le flux ? La réponse dépend de votre capacité à répondre à quelques exigences clés :

- Avez-vous une disponibilité machine suffisante pour produire la demande clients ?
- Avez-vous suffisamment de matériel sur place chaque jour pour répondre à vos besoins de production ?
- Avez-vous assez d'employés formés sur place pour gérer les processus en cours ?
- Avez-vous des méthodes de travail définies comme des instructions de bases ou des standards en place ?

Si la réponse à l'une de ces questions est catégoriquement "non", arrêtez-vous et réglez le problème avant de continuer. Tenter de produire exactement la demande clients avec des employés non formés, une supervision défaillante, ou un stock limité sur place est la recette qui mène au désastre.

Inversement, vous ne devriez pas tomber dans le piège d'utiliser ces questions comme des excuses pour ne pas avancer. Rappelez-vous, vous n'avez pas besoin d'une disponibilité parfaite pour répondre à la demande clients. Si, par exemple, le takt time de l'assemblage est de 60 secondes et que le temps de cycle du processus machine amont est de 30 secondes, alors vous n'aurez besoin que de quelques stocks pour agir comme tampon et un peu mieux que 50% de disponibilité pour commencer à établir un meilleur flux de production au rythme du takt time. Le même bon sens peut aussi s'appliquer aux autres 4 Ms. Si la ligne de production a besoin de huit personnes pour fonctionner et que vous n'avez constamment à disposition que six personnes formées pour faire le travail, alors vous avez un problème de stabilité au départ.

Atteindre la stabilité

Pour parvenir à la stabilité au départ, vous devez vous concentrer sur quatre éléments clés correspondant aux 4Ms.

1. Main-d'œuvre

En lean, la stabilité commence avec une main-d'œuvre bien formée. Heureusement, les employés ont tendance à très bien connaître leur travail, sinon nous aurions de très graves problèmes. Toutefois, Toyota, dans les années 1950, a appris quelques techniques de base pour superviser la production et sur la manière d'améliorer les compétences et les capacités des équipes. Plus précisément, ils ont adopté un programme de formation industrielle que les États-Unis ont utilisé pendant la Seconde Guerre Mondiale et qui s'appelle "La formation au sein de l'industrie"[5]. Ce programme est composé de trois modules de formation professionnelle dédiés aux superviseurs de production : les instructions dans le travail, les méthodes dans le travail et les relations dans le travail. Chaque module était un cours de dix heures dans lequel on enseignait des compétences pratiques en supervision.

Le module instructions dans le travail[6] enseignait aux superviseurs la façon de planifier les ressources appropriées dont ils auraient besoin dans la production, comment décomposer le travail pour rédiger les instructions et comment enseigner aux individus en toute sécurité, correctement et consciencieusement. Le module méthode dans le travail[7] enseignait aux superviseurs la manière d'analyser le travail et d'apporter des améliorations simples à l'échelle de leur domaine. Chaque activité était inspectée pour être améliorée si nécessaire. Les superviseurs apprenaient à se demander pourquoi une activité était réalisée d'une certaine manière, et si elle pouvait être éliminée, combinée avec autre chose, réarrangée, ou simplifiée. Le module relations au travail[8] enseignait aux superviseurs la manière de traiter les gens comme des individus et de résoudre les problèmes fondamentaux de l'homme liés à la production plutôt que de les ignorer.

Pris ensemble, ces trois modules aident les superviseurs à créer une routine, une discipline et un sens de l'équité dans les équipes. Cinquante ans plus tard, ces mêmes modules constituent la base fondamentale pour la formation des superviseurs et des équipes chez Toyota.

2. Machines

Vous n'avez pas besoin d'équipement avec une disponibilité parfaite, mais vous devez connaître votre demande clients, la capacité de votre processus et la production moyenne réelle.

Toyota utilise un document de base appelé la feuille de capacité du processus pour mesurer le potentiel de production réelle d'un processus durant un poste. Si vous avez la capacité théorique ainsi que la capacité constatée à satisfaire la demande clients, alors il n'y a pas de problème. C'est seulement quand vous n'avez aucune capacité constatée à répondre à la demande que vous avez un problème de stabilité sur les machines. Par exemple, si la demande clients est de 700 unités par poste et que votre production réelle est seulement de 500 unités malgré une capacité théorique de 1000, alors vous avez besoin de plus de disponibilité.

Dans de tels cas, Ohno a effectivement eu des gens debout devant la machine problématique sur l'ensemble des huit heures du poste pour régulièrement enregistrer la production réelle toutes les 15 minutes à 1 heure par rapport à la production planifiée. A la fin du poste, toutes les pertes et les raisons réelles associées étaient identifiées sur un diagramme de Pareto. De simples et rapides réunions étaient menées si nécessaire et des plans d'amélioration mis en place. C'est le respect par essence du "Genba" (terme japonais pour qualifier l'endroit où s'effectue réellement le travail) chez Toyota.

3. Matériels

En général, le but du lean est de réduire les gaspillages et de raccourcir le délai entre le moment où une commande est reçue jusqu'au moment où elle est produite. Normalement, cela nécessite la réduction des stocks dans la chaîne de valeur. Si vous souffrez d'une instabilité fondamentale, cependant, vous pouvez avoir besoin d'accroître les stocks à court terme dans certains endroits ou dans certains cas.

La raison c'est que pour certains processus, vous pouvez produire pièce à pièce ou de très petites quantités. Pour les procédés par lot, toutefois, une certaine quantité de stocks est nécessaire pour couvrir le moment où les autres processus sont en cours d'exécution, ou des outils sont changés.

La quantité de stocks dont vous avez besoin est composé de ce que Toyota appelle le stock du cycle de commande (la quantité de stocks nécessaire pour couvrir la demande moyenne et le lead time pour reconstituer le stock), le stock tampon (la quantité de stocks pour couvrir les variations qui pourraient exister dans votre flux aval ou dans la demande clients), et le stock de sécurité (la quantité de stocks pour couvrir les pertes comme les rejets ou les temps d'arrêt que vous avez actuellement). Il serait déraisonnable de pas tenir compte de ces stocks tampon et de sécurité dans un environnement instable, cela nuirait sérieusement à l'efficacité de ligne de production.

J'ai été frappé par deux conseils que l'on m'a donné sur ce sujet chez Toyota. Premièrement, tous les stocks ne constituent pas des gaspillages. Seuls les stocks au-delà ce qui est nécessaire pour exécuter le processus sont considérés comme un gaspillage. Deuxièmement, le stock existe souvent comme le symptôme d'un problème dans le processus. Résoudre le problème vous donne le droit de réduire le stock.

4. Méthodes

Enfin, atteindre la stabilité au départ nécessite d'avoir des méthodes standards pour la fabrication. Le point clé ici est la définition d'un standard. La définition normale est qu'un standard est une règle ou une façon de faire les choses. L'effet secondaire involontaire est que les gens ne sont pas encouragés à remettre en question ou à modifier la règle. "Nous le faisons de cette façon parce que c'est la norme dans notre entreprise" est une phrase que j'entends souvent.

La définition d'un standard chez Toyota est légèrement différente. Un standard est une "règle ou une base de comparaison". Un standard n'est rien de plus qu'un outil pour mesurer la manière dont nous faisons quelque chose et auquel se référer lorsque nous souhaitons changer quelque chose. La pensée Lean traite du changement des méthodes de travail afin d'éliminer les gaspillages et apporter des améliorations. Les standards sont ce que nous utilisons pour mesurer et comparer nos changements afin que nous sachions si la nouvelle voie est meilleure ou non.

Ce système de pensée basé sur l'amélioration est enraciné dans la tête de tous les employés de Toyota depuis le premier jour. Chacun est encouragé à faire des changements. Cependant, le changement n'est seulement mis en œuvre et maintenu que s'il bat l'ancien standard, c'est ce que l'on appelle à proprement parler le kaizen.

Résumé

Il y a beaucoup d'autres éléments de stabilité qui se cache sous chacun des 4Ms de Toyota. Par exemple, les méthodes peuvent être élargies afin d'inclure les cinq S, le contrôle visuel, le déjà célèbre tableau de travail standardisé et d'autres outils simples de gestion du travail. Et nous pourrions même ajouter un cinquième M pour Métriques. Le dernier point c'est que comme beaucoup d'entre nous aujourd'hui, Toyota s'est vigoureusement battu pour mettre en œuvre une démarche de production lean. Sur le chemin, Toyota a découvert que vous avez souvent besoin d'une bonne dose de stabilité au départ donc avant de pouvoir avancer sur les autres éléments du lean. Tout comme nous avons besoin de ramper et de marcher avant de pouvoir courir, les entreprises constatent souvent qu'elles ont besoin d'améliorer leur stabilité au départ avant de parfaire un système à flux tiré.


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

Notes

[1] NdT : Takt time = rythme auquel les produits doivent sortir du système pour satisfaire exactement la demande

[2] NdT : SMED = Single Minute Exchange of Die - la clé pour réduire la taille de lots de production

[3] NdT : Le travail posté est la forme d'organisation du travail où des équipes se relaient au même poste les unes après les autres. Une forme fréquente de travail posté est l'organisation en 3 × 8.

[4] NdT : WIP = Work-in-Progress ; TAF = Travail à Faire

[5] NdT : TWI = Training Within Industry

[6] NdT : Job instruction (JI)

[7] NdT : Job methods (JM)

[8] NdT : Job relations (JR)

samedi, 25 juin 2011

Rétrospective Soirée Devops, Scrum & Kanban du 24 juin 2011

Badge FSUG

What went well

  • Laurent Morisseau a ouvert le bal avec une introduction à Kanban illustrée par ses retours d'expérience dans trois projets significatifs qu'il a accompagné (migration et recette usine) et par une démarche circulaire en 5 étapes : 1°Identifier la valeur, 2°Identifier la chaîne de valeur, 3°Créer un flux continu pièce à pièce, 4° Établir un flux tiré et 5°Rechercher la perfection. Il a parfaitement lancé les deux sujets qui devaient suivre.
  • Dominica DeGrandis, associée chez David J Anderson & Associates, nous a fait un grand retour d'expérience sur l'amélioration d'une gestion de configuration grâce à Kanban. Beaucoup de messages sur l'humain.
  • Concernant notre présentation "Scrum & Kanban : tirer le meilleur des deux", Antoine Vernois et moi avons eu de nouvelles questions (par rapport à l'Agile Tour Toulouse 2010 et au Scrum Day 2011) : on a bien tous cogité ensemble, c'était agréable :) Ah oui, j'oubliais : ne soyez pas dogmatique, essayez par vous-même ! soyez agile !
  • Discussion intéressante avec Martin Sudmann sur l'utilisation de Scrum et Kanban chez PriceMinister.
  • Conversation à bâtons rompues avec Antoine et Xavier Warzee dans un bar de la capitale jusqu'à 1 heure du matin !

What went wrong

  • Batterie du HTC à plat, plus possible de prendre des photos !
  • Rentré à 2h à l'hôtel, levé à 6h30 et train à 7h30, arrivé à 11h à Bordeaux... grosse fatigue !

Puzzles

  • Qui veut sponsoriser le French Scrum User Group ? immergez-vous dans la communauté agile !
  • Laurent Lemoine, gamer chez multimondes.net ? j'attends l'ouverture du site.
  • J'ai invité Caroline Damour, Product Owner chez Vidal, à venir parler de son travail à l'Agile Tour Bordeaux 2012... viendra-t-elle ?
  • CDD ? Chaos Driven Development.
  • Difference between 2h meeting and 2h movie ? emotion... people are polite in meeting, they don't say what they think.

Lessons (re-)learnt

  • La démarche Lean est une démarche d'amélioration continue "petits pas".
  • Laissez vivre le système, mettez-le sous contrainte puis expérimentez au fur et à mesure.
  • Knowledge work is perishable.
  • Trust is essential, so increase level of trust for influencing change.
  • Good to have the what but would have been better to include the why to understand the bigger picture for flow.
  • Belonging to a team is a behavior.
  • Transparency = Trust - Vulnerability = Empathy.
  • Quality doesn't happen with 5 hours of sleep !
  • Tolerance for process exploration... brought understanding.
  • A focus on cutting costs actually results in higher costs.
  • Kanban : all the work is on the board.
  • Work item flows across different functions of all departments of the enterprise.
  • Management must create a way for improvements to occur, but it's not free.

Appreciations

  • Merci à Microsoft de nous avoir accueilli dans ses (superbes) locaux, il y avait un buffet !
  • Merci aux organisateurs : le French Scrum User Group, notamment Xavier Warzee.
  • Merci aux orateurs : Dominica, Laurent, Xavier (guest) et Antoine.
  • Merci aux participants : Caroline, Emilie, Oana, Alexis, Laurent, Luc, Christophe, Martin, Lucian, Gilles, Yannick, Mohammed, ... et tous les autres !

Links

Feedback :


Opéra Garnier Microsoft Programme de la soirée Devops, Scrum et Kanban Dominica DeGrandis et Xavier Warzee Laurent Morisseau et Xavier Warzee Démarche Kanban Chaîne de valeur Chaos Driven Development : Chicago, 1901 Méfiez-vous des hiboux la nuit ! 3 casquettes (Kanban, ScrumBan et Scrum))


Kanban signRetrouvez l'intégralité de mes rétrospectives sur le wiki Rétrospectives Agiles.

vendredi, 24 juin 2011

Il ne s'agit pas simplement de rester debout : les bonnes pratiques du Daily Stand-up Meeting

J'ai traduit cet article très détaillé de Jason Yip de la société ThoughtWorks, Inc. : "It's Not Just Standing Up: Patterns of Daily Stand-up Meetings".

Se tenir debout

1. Nous restons debout pour que la réunion reste courte

Le daily stand-up meeting (aussi connu sous le nom de "mêlée/scrum quotidien(ne)"[1], "regroupement quotidien"[2], "appel du matin"[3], etc.) est simple à décrire: l'équipe entière se réunit tous les jours pour une mise à jour rapide de l'état d'avancement des tâches. Nous restons debout pour que la réunion reste courte. C'est tout. Mais cette définition rapide ne vous aide pas vraiment à comprendre les subtilités qui distinguent un bon stand-up d'un mauvais.

Compte tenu de l'apparente simplicité du stand-up, j'ai été assez surpris la première fois quand j'ai vu que cela ne fonctionnait pas. Ce qui n'allait pas m'a immédiatement paru évident, mais j'ai réalisé que ce n'était pas aussi évident pour l'équipe. J'ai réalisé que mon équipe n'avait pas conscience des principes sous-jacents et des détails qui leur permettraient de diagnostiquer et de résoudre les problèmes liés aux stand-ups.

Les gens qui ont connu de bons stand-ups sauront généralement quoi faire quand les choses ne fonctionnent pas bien. Lorsque que les choses tournent mal, les participants qui débutent ne comprendront probablement pas ce qu'il faut faire. Une façon d'aborder ce problème est de prétendre que tout est une question de connaissances tacites et que les débutants ont juste besoin de participer à davantage de stand-ups qui se passent bien. Je crois, cependant, qu'il est beaucoup plus probable que, si on ne les aide pas, les débutants abandonneront purement et simplement la pratique du daily stand-up. Ce serait regrettable puisque des stand-ups bien exécutés ajoutent une valeur significative aux projets.

Je tente ici de communiquer certaines des connaissances tacites que j'ai pu acquérir sur les bénéfices et les conséquences de bonnes pratiques pour mener les daily stand-ups. Ces bonnes pratiques de daily stand-up meetings sont destinées à aider les nouveaux pratiquants ainsi qu'à rappeler aux pratiquants expérimentés ce qu'ils savent déjà en leur for intérieur.

2. Le thème sous-jacent est l'auto-organisation

Le thème sous-jacent aux daily stand-up meetings est l'auto-organisation. Ce n'est pas juste parce que l'auto-organisation conduit à une meilleure productivité, mais aussi, et peut-être plus encore, parce qu'elle génère un environnement de travail plus humain, respectueux et évolué. Bon nombre des problèmes qui surgiront durant l'exécution d'un bon stand-up sont liés à une mauvaise compréhension de cette motivation sous-jacente à l'auto-organisation.

L'auto-organisation n'est pas une vertu propre à une culture, qu'il s'agisse d'une équipe, d'une organisation, ou d'un pays. Si l'équipe entière ne s'engage pas à prendre la responsabilité de son propre succès, sa performance va forcément empirer.

3. Quel est le but d'un daily stand-up meeting ?

Si l'on fait la synthèse de plusieurs documents et références ([Anderson, 2002], [Beedle et al., 2000], [Cochango, 2006], [OrgPatternsStandUp], [Rising, 2002], [Rising et Janoff, 2002], [Wells, 1999]), les daily stand-ups doivent atteindre les objectifs suivants :

3a. S'engager ensemble

Prendre des engagements quotidiens les uns envers les autres, comme une équipe, est l'objectif le plus important des daily stand-ups. Partager les engagements est plus important que partager un état d'avancement. Cela ne veut pas dire qu'un observateur ne verra pas ressortir l'état d'avancement d'un stand-up, mais cela reste secondaire pour les membres des équipes qui s'engagent publiquement les uns envers les autres et qui identifient les obstacles qui les empêchent de respecter leurs engagements.

3b. Communiquer l'état d'avancement

L'objectif de ces réunions est de communiquer sur l'état d'avancement en termes d'architecture et de plan de production. [OrgPatternsStandUp]

Ce n'est pas le fait de communiquer sur l'état d'avancement qui différenciera les stand-ups des autres types de réunions d'avancement. Ce qui fait la différence c'est le mécanisme qu'utilise les stand-ups pour communiquer l'état d'avancement, à savoir les membres de l'équipe se synchronisent entre eux plutôt qu'avec leur manager. Actualiser quotidiennement l'état d'avancement permet également à l'équipe de réfléchir sur ce qu'elle va faire à un rythme quotidien, au minimum.

3c. Identifier les obstacles

Lorsqu'un membre de l'équipe partage un obstacle lors d'une réunion Scrum, l'équipe entière se penche sur ce problème. Parce que les membres de l'équipe travaille de concert vers un objectif commun, chaque membre de l'équipe doit coopérer pour atteindre cet objectif. Toute l'équipe s'approprie instantanément les problèmes de chacun des individus qui la composent. [Rising et Janoff, 2000]

Identifier et éliminer les obstacles le plus tôt possible permet à l'équipe de maintenir son rythme. Le stand-up en lui-même n'est pas destiné à éliminer les obstacles, mais plutôt à fournir un forum permettant aux personnes d'identifier les obstacles afin que les autres membres de l'équipe aient la possibilité de les aider.

3d. Donner la direction et se concentrer dessus

Pendant les daily meetings, le Scrum master prêtera attention à la priorité des items du backlog. C'est particulièrement utile pour les nouveaux membres de l'équipe, qui pourraient partir dans une autre direction. [Rising et Janoff, 2000]

Nous souhaitons que tout le monde aille dans la même direction. Le stand-up est utilisé pour rappeler cette direction continuellement à l'équipe.

3e. Construire une équipe

Si l'on va plus loin que les exercices artificiels de "construction d'équipe", des équipes efficaces sont construites en communiquant régulièrement, en travaillant et en s'entraidant. Ceci est également fortement lié au fait que les membres de l'équipe s'entraident sur la base des obstacles partagés. L'équipe est consciente des problèmes de chacun en particulier parce qu'elle en entend parler tous les jours (jusqu'à ce que le problème soit résolu). Cet environnement encourage les gens à identifier les problèmes et à aider les autres.

4. Les daily stand-up meetings efficaces génèrent un sentiment particulier

Techniquement, la réunion est un "daily stand-up" si tout le monde est debout et si la réunion a lieu tous les jours. Cependant, il y a une différence entre un bon stand-up et un rituel vide de sens.

Une ancienne description des daily stand-up meetings les appellent Daily Scrums [Beedle et al., 2000] en les associant volontairement au rugby. Le niveau d'énergie d'un daily stand-up n'est peut-être pas aussi élevé que celui d'une mêlée de rugby, mais cela doit rester énergisant. La rapidité et un haut niveau d'énergie servent l'objectif de concentrer l'équipe vers la bonne direction. Des réunions longues avec un faible niveau d'énergie ont tendance à perturber et même à pénaliser la journée.

De bons stand-ups reposent sur la solidarité. Si les gens sont démolis à chaque fois qu'ils remontent un problème, ils auront tendance à arrêter de le faire. Au-delà de l'élimination des obstacles, un stand-up n'apportant aucun soutien aux membres de l'équipe va à l'encontre de la dynamique de l'équipe. Dans ce cas, le stand-up devient plutôt un rituel craint par les membres de l'équipe [LaPlante, 2003].

Lorsque les choses vont bien, il n'y a plus vraiment besoin de faciliter le stand-up. Un bon stand-up doit être perçu comme étant auto-géré.

5. Les bonnes pratiques du Daily stand-up meeting

5a. Qui participe au daily stand-up ?

5a1. Tout le monde

Les gens et les représentants des divers services (par exemple le marketing, l'exploitation, la direction générale, la formation, etc.) souhaitent connaître et/ou contribuer à l'état d'avancement du projet. Communiquer l'état d'avancement dans de multiples réunions et reportings nécessite beaucoup d'efforts redondants.

Par conséquent

Remplacez une partie ou l'ensemble des réunions et des reportings par le daily stand-up. Toute personne qui est directement impliqué ou qui veut connaître la marche au jour le jour du projet devrait assister à l'unique et quotidien daily stand-up meeting.

Mais

Les gens qui ne sont pas directement impliqués peuvent perturber le stand-up. Cela veut donc dire qu'un autre forum serait encore nécessaire pour les questions hors du périmètre du stand-up.

Trop de gens dans la réunion peuvent provoquer des perturbations et/ou mettre mal à l'aise les gens dans le fait de partager les informations. Les daily stand-ups classiques seront commposés d'au plus 10 personnes. Pour des groupes de plus grosse taille, il est encore plus important de faire respecter la Politique des Cochons et des Poulets et Traitez le sujet à part afin de s'assurer que tous les contributeurs peuvent fournir les informations au moment opportun.

Le format du stand-up ne pourra - ne devrait - pas couvrir toutes les formes de reporting. Par exemple, l'état d'avancement de l'ensemble du projet serait mieux transmis à l'aide d'un Gros Graphique Visible[4] [Jeffries, 2004] tels qu'un burn-down, un burn-up, un diagramme de flot cumulé, etc.

5a2. Cochons et poulets

Un poulet et un cochon sont ensemble quand le poulet dit : "Créons un restaurant !".
Le cochon réfléchit et dit : "Comment appellerions-nous ce restaurant ?".
Le poulet dit : "Jambon & Oeufs !".
Le cochon dit : "Non merci, je serais personnellement engagé, alors que toi tu ne serais qu'impliqué !".
[Schwaber et Beedle, 2001]

Lors d'un stand-up, les observateurs peuvent perturber la communication au sein de l'équipe. Ces perturbations peuvent se traduire sous la forme d'interruptions ou simplement en participant et en fournissant des informations inappropriées. Si la perturbation est suffisamment grave, les membres de l'équipe soit ne prendront pas la peine d'utiliser le stand-up pour communiquer sur les problèmes du projet, soit créeront même une autre instance, soit ne communiqueront plus du tout.

Par conséquent

Instituer une règle où seules les "personnes engagées" participent et les "personnes impliquées" sont uniquement autorisées à observer. "Engagé" désigne toutes les personnes qui contribuent au fait de terminer l'itération courante (c'est à dire, les développeurs, les testeurs, les managers de proximité, etc.). En d'autres termes, les gens qui peuvent dire quelque chose qui affecte directement le backlog d'items/features/stories. "Impliqué" désigne les autres personnes qui peuvent être intéressés par l'état d'avancement de l'itération, mais ne contribuent pas directement à son achèvement. Cela peut être d'autres managers, les commerciaux, les développeurs d'autres projets, etc. Toutes les questions et les problèmes que se posent les "impliqués" peuvent être traités après la réunion (Traitez le sujet à part) ou communiqués dans une autre instance.

Mais

Trop insister sur la distinction entre les types de participants à la réunion risque de créer une relation d'adversité. Ce n'est pas que les observateurs ne sont pas autorisés à communiquer avec l'équipe, c'est juste que cette communication est généralement inappropriée pendant le daily stand-up.

5a3. Participer par procuration

Tous les membres de l'équipe doivent participer. Si pour une raison ou une autre, un membre de l'équipe ne peut pas participer en personne, le membre absent doit soit participer par téléphone, soit demander à un autre membre de l'équipe de reporter l'état d'avancement. [Cochango, 2006]

Si les membres de l'équipe se manifestent au stand-up uniquement quand ils le souhaitent, cela laisse entendre que l'engagement de l'équipe n'est pas important. Cependant, il y a des situations où un membre de l'équipe ne peut pas participer à la réunion pour une raison très légitime (par exemple, des problèmes personnels, des problèmes en production, etc.). Dans ces cas, nous voulons trouver un moyen pour que le membre en question puisse exprimer son engagement lors du stand-up.

Par conséquent

Les membres de l'équipe qui ne peuvent pas assister au stand-up en personne doivent trouver un moyen d'y Participer par procuration. Cela peut être sous la forme d'un représentant, en appelant au téléphone, en envoyant un e-mail récapitulatif avant. Une participation virtuelle vaut toujours mieux que pas de participation du tout.

Mais

Si les membres de l'équipe ne peuvent régulièrement pas participer au stand-up, cela peut indiquer que le stand-up a lieu à une heure ou dans un endroit qui n'est pas pratique pour toute l'équipe. Cela peut aussi signifier que le membre ne fait pas réellement partie de l'équipe, parce qu'il a d'autres responsabilités ou des problèmes relationnels avec l'équipe. Bien sûr, participer par procuration est également moins satisfaisant que réellement participer en personne.

6. De quoi parlons-nous lors du daily stand-up meeting ?

6a. Hier Aujourd'hui Obstacles

Certaines personnes sont bavardes et vont loin dans la narration. Certaines personnes veulent s'engager dans la Résolution de problème immédiatement après avoir entendu un problème. Les réunions qui prennent trop de temps ont tendance à avoir un niveau d'énergie faible et les participants qui ne sont pas directement liés à une longue discussion auront tendance à perdre leur concentration.

Par conséquent

Structurer les contributions selon le format suivant :

- Qu'ai-je accompli hier ?
- Que vais-je faire aujourd'hui ?
- Quels sont les obstacles qui m'empêchent d'avancer ?

C'est le nombre minimal de questions pour satisfaire les objectifs des daily stand-ups. Les autres sujets de discussion (par exemple, la conception, les rumeurs, etc.) devrait être reportés après la réunion.

Lasse Koskela propose une autre forme pour ces questions afin d'insister sur le fait que les membres de l'équipe ne doivent pas Reporter au Chef :

Chaque membre de l'équipe informe ses pairs :
À son tour, chaque membre de l'équipe fournit à ses pairs 3 informations :
1. Les choses que j'ai faites depuis la réunion d'hier
2. Les choses que je vais terminer aujourd'hui
3. Les obstacles pour lesquels j'ai besoin que quelqu'un intervienne pour les supprimer
[Koskela, 2006]

Si l'on reprend cela à la lumière de l'engagement, les questions peuvent être reformulées comme suit :
- Ai-je été capable de respecter mon engagement ?
- Sur quoi puis-je raisonnablement m'engager aujourd'hui ?
- Quels sont les obstacles qui m'empêcheront d'atteindre mes engagements ?

Je préfère cette forme pour sa clarté même si l'originale est plus simple.

Mais

La structure n'est pas aussi importante que les informations fournies par les réponses aux questions. Si l'information est fournie via une forme moins structurée, il n'est pas important de se conformer à une liste de contrôle. Au fur et à mesure que les équipes montent en maturité, vous pourrez ajuster la structure. Par exemple, j'ai tendance à ajouter une quatrième question : "Qu'est-ce qui pourrait aider ou empêcher les autres de respecter leurs engagements ?".

6b. Se concentrer sur le backlog

Certaines personnes trouvent qu'il est difficile de garder le contexte du projet à l'esprit quand elles contribuent. Les symptômes possibles sont que les participants quittent le stand-up sans avoir une idée claire de ce qui reste à faire pour l'itération et la release, et sans avoir d'affinités avec les problèmes soulevées lors du stand-up.

Il est beaucoup plus facile de comprendre le contexte du projet avec un pense-bête visible.

Par conséquent

Rappelez aux participants du stand-up de Se concentrer sur le backlog, où le backlog est simplement une liste de tâches et de fonctionnalités à réaliser. Par exemple, maintenez un radiateur d'information [Cockburn, 2001] (c'est-à-dire un Gros Tableau Visible) montrant l'état d'avancement de l'itération et de la release et tenez le stand-up à proximité. L'affichage sert évidemment de pense-bête sur ce qui reste à faire.

Mais

Se concentrer sur le backlog peut avoir comme conséquence de se concentrer plus sur les tâches que sur les personnes. Il y aura toujours des problèmes importants et subtils liés aux personnes et que vous ne découvrirez pas en vous concentrant trop sur l'état d'avancement des tâches.

6c. Tableau des obstacles

Les obstacles identifiés pendant le stand-up ne sont pas directement supprimés, autrement dit traités à un autre moment plus opportun.

Par conséquent

Les obstacles sont identifiés sur un Tableau des obstacles. Il s'agit d'un tableau blanc visible publiquement qui identifie les obstacles remontés et trace l'état d'avancement de leur résolution. Un Tableau des obstacles peut être mis à jour en dehors des stand-ups et sert plus immédiatement - et peut-être même dans un milieu moins agressif - à remonter les obstacles. Une erreur commune est de ne pas écrire assez grand pour permettre aux gens de lire les obstacles à distance.

Le simple fait d'écrire un problème, et donc de le reconnaître explicitement, est un moyen très fiable pour réduire la durée des conversations. Donc, même si tous ne se mettent pas d'accord sur le fait qu'un élément particulier soit un obstacle, cela vaut tout simplement le coup de l'écrire pour l'aborder après que la réunion soit terminée.

7. Quand et où se tiennent les daily stand-up meeting ?

7a. Même lieu, même heure

Nous voulons que l'équipe s'approprie le stand-up. Nous voulons aussi que les parties intéressées soient en mesure d'observer un stand-up pour éviter d'avoir à planifier une autre réunion d'avancement. C'est donc difficile si un membre de l'équipe est autorisé à changer le lieu ou l'heure du stand-up.

Par conséquent

Exécutez le daily stand-up au Même lieu, Même heure. N'attendez pas les retardataires, notamment les architectes et les managers. La réunion est pour toute l'équipe, pas pour une personne en particulier. Ceci est particulièrement important si vous Utilisez le stand-up pour démarrer la journée.

Certaines équipes plus strictes imposent une "amende" aux retardataires. J'ai tendance à me méfier de toute forme de mécanisme de punition et je préfère la discussion.

Mais

Même lieu, même heure n'est pas destiné à être aveuglément appliqué. La chose importante pour l'heure de début c'est qu'elle soit la plupart du temps uniforme et rarement replanifiée. Si la replanification est souvent nécessaire, cela peut indiquer que l'heure de démarrage doit changer. Si un lieu est particulièrement gênant à atteindre pour tout le monde, cela indique probablement que le lieu doit changer.

7b. Utiliser le stand-up pour démarrer la journée

Le daily stand-up meeting permet de se concentrer et de prendre conscience des problèmes en suspens. S'il a lieu en fin de journée, cette concentration et cette prise de conscience sont gaspillées.

Par conséquent

Utilisez le stand-up pour démarrer la journée. Avec la flexibilité des heures de travail flexibles, les membres de l'équipe n'arriveront pas tous au travail en même temps. Une pratique courante avec la "flexibilité des heures de travail", c'est d'utiliser des heures de travail communes. L'heure de début doit être fixée au début de ces heures de travail. De même, si les membres de l'équipe doivent arriver plus tard pour des raisons personnelles (par exemple, ils ont besoin de déposer les enfants à l'école), l'heure de début doit être fixée à un moment où chacun peut y participer.

Mais

Il y a généralement une tendance à ne pas travailler sur les tâches d'un projet tant que le stand-up n'a pas eu lieu. Si le Stand-up meeting démarre la journée... plus tard, le temps de relâche peut être significatif. Dans une certaine mesure, cela peut être simplement être utilisé comme une occasion de consulter ses e-mails, de remplir ses feuilles de temps, etc. mais il peut être intéressant de supprimer cette notion du stand-up en tant que rituel de "début de journée" en le planifiant plus tard dans la journée.

7c. Ne pas utiliser le stand-up pour démarrer la journée

Le stand-up a vocation à être le rituel permettant de se concentrer sur la journée à venir, surtout si vous Utilisez le stand-up au démarrage de la journée. Pour cette raison, les membres de l'équipe ont tendance à ne pas travailler sur les fonctionnalités jusqu'à ce que le stand-up ait lieu. Lorsque la réunion n'est pas réellement exécutée en premier, cette tendance peut avoir un impact significatif sur la productivité.

Par conséquent

N'utilisez pas le stand-up pour démarrer la journée. Planifiez le daily stand-up assez loin dans la journée pour qu'il ne soit pas associé psychologiquement au démarrage de la journée.

Mais

Si le daily meeting ne démarre pas la journée, alors il ne peut plus être utilisé comme un rituel partagé pour focaliser l'attention de l'équipe pour démarrer la journée. Selon l'équipe, ce prix ne vaudra pas l'apparente augmentation d'efficacité.

Quand il y a des nombreux projets utilisant les stand-ups, il est possible que plusieurs stand-up se produisent simultanément. Les observateurs intéressés par de multiples projets peuvent vouloir changer l'heure des stand-ups pour leur permettre d'être en mesure d'y assister. Cette situation est problématique car cela risque de frustrer le sentiment d'appropriation du stand-up par l'équipe si un observateur peut forcer un stand-up à s'adapter à ses horaires. Néanmoins, cela doit également être pris en considération pour décider de l'heure de début du daily stand-up.

8. Comment maintenir le niveau d'énergie du daily stand-up ?

8a. Regroupement

Le volume de la parole affecte aussi bien l'écoute que l'efficacité de la communication. La distance physique change le niveau du volume nécessaire pour bien communiquer. Certaines personnes n'aiment pas parler fort et cela les gênera de le faire.

Par conséquent

Le stand-up doit plus ressembler à un regroupement qu'à une réunion. S'il est difficile d'entendre quelque chose, rapprochez tout le monde. Au-delà de permettre un volume de parole plus confortable, être physiquement proche amène les participants à être plus attentifs. Être capable de se tenir physiquement plus proche est aussi une expression d'une plus grande confiance au sein de l'équipe.

Si le stand-up est une nouvelle chose, il est généralement suffisant de faire un signe de la main en disant "Venez". Si la taille du cercle a été établie pour un certain temps, pensez à expliquer les raisons pour lesquelles il faut fermer le cercle avant de le rétrécir.

Mais

L'équipe doit trouver un équilibre entre proximité et zone de confort personnel. Même dans une équipe très confiante, il y a un point à partir duquel les gens sont simplement trop près pour se sentir confortables. Les symptômes sont une tendance des participants à être tendus et/ou remuants.

8b. Debout

Certaines personnes sont bavardes et ont tendance à aller loin dans la narration. Certaines personnes veulent s'engager dans la Résolution de problèmes immédiatement après avoir entendu un problème. Les réunions qui prennent trop de temps ont tendance à avoir un faible niveau d'énergie et les participants qui ne sont pas directement concernés par une longue discussion auront tendance à perdre leur concentration.

Par conséquent

Exigez que tous les participants soient debouts. Utilisez la position debout comme un lien entre le physique et la préparation mentale. Un inconfort physique peut également rappeler aux participants que la réunion est trop longue. Un moyen simple d'encourager cela est de tenir la réunion à un endroit où il n'y a pas de chaises.

Mais

La position debout a tendance à écourter les réunions, mais elle ne garantit pas qu'elles seront écourtées selon une durée optimale. Les gens peuvent apprendre à gérer l'inconfort plutôt que d'avoir une réponse plus appropriée. Si les réunions ne sont pas trop longues et ne tombent pas dans le hors-sujet, la position debout est un rituel inutile.

8c. Quinze minutes ou moins

La plupart des gens vagabondent mentalement lorsqu'ils sont dans de longues réunions. Une longue réunion est une manière horrible de démarrer la journée et tue l'énergie de l'équipe. Une durée spécifique nous aide à nous rappeler à quel moment envisager de réduire la durée de la réunion.

Par conséquent

Maintenez les daily stand-up à Quinze minutes ou moins. En règle générale, après quinze minutes, l'esprit des personnes a tendance à vagabonder, ce qui n'aide pas à se concentrer.

Mais

Quinze minutes, cela peut même être trop long pour de petites équipes. En raison de cet effet d'esprit qui vagabonde, même pour les grandes équipes, quinze minutes est une bonne limite. Il est également possible d'avoir une réunion qui soit trop courte, où les participants n'ont pas encore d'idée précise de ce qui se passe, ni à qui en parler afin de le découvrir.

8d. Signaler la fin
Une fois que la dernière personne a parlé, l'équipe ne réalise pas immédiatement que la réunion est terminée. La prise de conscience progressive qu'il est temps de s'en aller ne termine pas la réunion sur une note positive et peut même contribuer à baisser le niveau d'énergie de l'équipe.

Par conséquent

Signaler la fin du stand-up avec une phrase bateau (par exemple : "Eh bien, bon appétit à tout le monde." [Gibbs, 2006, Signal]) ou équivalent.

8e. Chronométrer les réunions

Il est difficile de juger qualitativement si un stand-up est trop long ou non, surtout si sa durée augmente progressivement.

Par conséquent

Chronométrez les réunions et publiez les résultats. La plupart du temps, les participants ne réalisent pas l'impact de Raconter des histoires et ne sont pas préparés à Traiter le sujet à part, ou ne se sont pas préparés à la durée de la réunion. Rendez-le quantifiable.

Mais

Comme avec toutes les mesures, chronométrer des réunions ne devrait pas être effectué à moins qu'il y ait un véritable objectif à atteindre en raison d'un problème de niveau d'énergie. Une fois le but atteint, l'action de mesurer doit être abandonnée. Mesurer sans raison particulière conduit à la méfiance et l'indifférence aux mesures.

8f. Traiter le sujet à part

Certaines personnes veulent s'engager dans la Résolution de problèmes immédiatement après avoir entendu un problème. Les réunions qui prennent trop de temps ont tendance à baisser le niveau d'énergie de l'équipe et les participants qui ne sont pas directement concernés par cette longue discussion auront tendance à perdre leur concentration. Il est toujours important de reconnaître que d'autres discussions seront nécessaires pour résoudre le problème remonté. Certains personnes trouveront peut être ça gênant de faire respecter la structure du stand-up en interrompant la discussion.

Par conséquent

Utilisez une phrase simple et cohérente, telle que "Traitez le sujet à part", comme un rappel pour que ces discussions aient lieu en dehors du daily stand-up. Si la discussion est de l'ordre de la Socialisation, rien de plus n'est nécessaire. Si la discussion est de l'ordre de la Résolution de problèmes, le facilitateur (ou simplement l'équipe) doit s'assurer que les bonnes personnes sont désignées pour traiter la question plus tard.

Mais

Il y a une différence entre la Résolution de problèmes et Clarifier une question. L'information qui n'est pas comprise n'est pas utile. Jusqu'à quel point aller pour clarifier une question variera en fonction de la taille de l'équipe et si cela impacte la durée de Quinze minutes ou moins.

9. Comment pouvons-nous encourager des daily stand-ups auto-gérés ?

9a. Le dernier arrivé parle en premier

Lors d'un stand-up, les participants ont besoin de savoir qui est censé parler en premier. Laisser un facilitateur décider qui doit parler le premier, produit une force subtile mais contraire à l'auto-organisation. L'équipe doit savoir, sans intervention, qui parle en premier.

Par conséquent

Mettez-vous d'accord sur le fait que le Dernier arrivé parle en premier. C'est une règle simple qui offre également l'avantage supplémentaire d'encourager les gens à être ponctuel en arrivant au stand-up.

9b. Round Robin

Lors d'un stand-up, les participants ont besoin de savoir qui est censé parler ensuite. Laisser un facilitateur décider qui doit parler ensuite, produit une force subtile mais contraire à l'auto-organisation. L'équipe doit savoir, sans intervention, qui parle ensuite.

Par conséquent

Utilisez une règle simple comme un Round Robin [5] pour déterminer qui doit ensuite parler. Ce n'est pas grave si cela a lieu dans le sens horaire ou anti-horaire. Ce qui importe c'est que l'équipe mène la réunion, et non le facilitateur ou le manager.

9c. Se passer un objet

Avec des mécanismes d'ordonnancement simples et prédictifs (par exemple, le Round Robin), il est très facile pour les participants d'ignorer les autres jusqu'à ce que leur tour approche. On peut avoir tendance à penser à autre chose et ne pas prêter attention à ce que disent les autres.

Par conséquent

Introduisez un mécanisme d'ordonnancement imprévisible, comme lancer un objet (par exemple, une balle) pour déterminer qui doit ensuite parler. Disposer d'un objet pour prendre la parole simplifie également la décision pour savoir qui va parler en premier car ce sera la personne qui arrive à récupérer l'objet (ou la première personne à qui on lance l'objet).

Lancer quelque chose introduit un peu d'amusement dans le rituel du daily stand-up et se révèle ainsi un agent pour infecter les autres équipes qui observent.

J'ai appris cette bonne pratique sur un projet sur lequel j'étais avec Simon Stewart. Nous avons utilisé une petite balle de jonglage mais vous pouvez presque tout utiliser. D'autres équipes ont utilisé des ballons de rugby [Gibbs, 2006, Rugby] ou même des jouets en peluche [Mar, 2006].

Mais

Avec de plus grandes équipes, il peut devenir difficile de se rappeler qui a déjà parlé. Dans ce cas, il peut être plus facile de s'en tenir à des mécanismes plus simples comme le Round Robin. Selon la culture de l'organisation voire de l'équipe, lancer une balle peut être considéré comme non professionnel et peut créer une perception négative superflue du rituel sous-jacent.

9d. Prenez une carte

Lors d'un stand-up, les participants ont besoin de savoir qui est censé parler en premier et qui est censé parler ensuite. Laisser un facilitateur décider qui doit parler produit une force subtile mais contraire à l'auto-organisation. L'équipe n'a pas envie de Se passer un objet parce qu'ils ont généralement des tasses de café dans leurs mains.

Par conséquent

Demandez aux membres de l'équipe de tirer une carte qui a un certain nombre indiquant l'ordre dans lequel ils vont parler [Russell, 2006].

9e. Faites tourner le Facilitateur

Les membres de l'équipe font le Reporting à leur chef, c'est-à-dire qu'ils parlent uniquement au facilitateur de la réunion au lieu de le faire entre eux. Seul le facilitateur de la réunion est identifié et aborde les problèmes de processus liés au stand-up. Nous voulons que l'équipe s'approprie le stand-up et cela nécessite de supprimer toute dépendance à l'égard d'un facilitateur unique.

Par conséquent

Faites tourner le rôle du Facilitateur. Faites tourner le rôle chargé d'assurer que les personnes participent au stand-up et respectent les règles précisées plus haut.

Mais

Les équipes qui n'ont pas beaucoup d'expérience avec les stand-ups bénéficieront grandement d'avoir un coach expérimenté. C'est un plus si l'équipe est accompagnée pour une meilleure maîtrise du stand-up. Au bout d'un certain temps, le facilitateur en tant que tel ne sera plus nécessaire.

9f. Brisez le contact avec les yeux

Les membres de l'équipe font le Reporting à leur chef, c'est-à-dire qu'ils parlent uniquement au facilitateur de la réunion au lieu de le faire entre eux. Nous voulons que l'équipe s'approprie le stand-up et cela nécessite de supprimer toute dépendance à l'égard d'un facilitateur unique.

Par conséquent

Le facilitateur doit Briser le contact avec les yeux [Nicolette, 2006] comme une façon subtile de rappeler à l'orateur qu'il/elle doit s'adresser à l'équipe, pas à une seule personne. Une façon de procéder est de se déplacer [Shimp, 2006] de sorte que l'orateur ne peut pas voir le facilitateur.

10. Avoir une mauvaise sensation lorsque ça va mal

J'ai enduré des stand-up meetings réguliers trois ans. Mon patron (je vais l'appeler Wally) a rendu ces réunions plus douloureuses. Selon lui, la raison principale d'une réunion stand-up n'était pas d'augmenter l'efficacité ou d'embrasser XP[6] autant qu'il soit possible de le faire pour concentrer au maximum les interactions humaines sur ce qui était directement lié aux tâches de fabrication du produit ... En fait, pour Wally, le stand-up meeting (à 7 heures le lundi et à 17 heures le vendredi) était un test de loyauté visant à renforcer la relation employeur-employé. [LaPlante, 2003]

La sensation d'efficacité d'un stand-up repose sur la façon dont vous savez quand les choses vont bien. Les mauvaises sensations reposent sur la façon dont vous savez quand les choses vont mal. Il est important de remarquer que même si vous n'avez pas de mauvaises sensations, cela ne signifie pas pour autant que le stand-up se déroule bien. Cela signifie simplement que vous ne le "sentez pas".

La plupart des mauvaises sensations qui suivent sont liées aux bonnes pratiques précédentes. Pour celles qui ne le sont pas, les problèmes sous-jacents ont tendance à être plus subtils ou hors périmètre du daily stand-up, dans ce cas les gens devront venir avec leurs propres solutions.

10a. Reporting au chef

Les membres de l'équipe s'adressent à l'équipe. Ce n'est pas une réunion de "Reporting au ScrumMaster". [Cochango, 2006]

Les membres de l'équipe font face au manager ou au facilitateur de la réunion au lieu de faire face à l'équipe. Ceci indique que le daily stand-up est réalisé pour le manager/facilitateur alors qu'il est en réalité censé l'être pour l'équipe. Il y a différentes façons de briser cette dépendance : Faites tourner le rôle du facilitateur, Brisez le contact avec les yeux, changer la forme Hier Aujourd'hui Obstacles, Faites passer un objet pour prendre la parole, etc.

10b. Les gens sont en retard

Ceci est directement lié au fait qu'il s'agit du Même Lieu, Même Heure, mais cela peut aussi indiquer que le stand-up se déroule au mauvais moment ou au mauvais endroit.

10c. Le stand-up meeting démarre la journée... trop tard

Étant donné que le stand-up est vu comme une réunion qui lance la journée de travail, il arrive qu'aucun travail ne soit effectué avant le stand-up. Selon que le stand-up est mené plus ou moins tard dans la matinée, cela peut avoir un impact significatif sur les heures de travail. Donc N'utilisez pas le stand-up pour commencer la journée.

10d. Les observateurs interviennent

L'interruption régulière par des observateurs est très perturbatrice pour l'équipe et remet en question le postulat comme quoi le daily stand-up est principalement dédié à l'équipe. Ces interventions peuvent également menacer la durée des Quinze minutes ou moins. Appliquez la Politique des Cochons et des Poulets.

10e. Socialisation

L'un des objectifs du stand-up est d'augmenter la socialisation des membres de l'équipe. Cependant, le daily stand-up n'a pas vocation à permettre aux membres de l'équipe de "récupérer" des informations des uns et des autres sur des questions qui ne sont pas liées au projet. Il est difficile de donner des exemples puisque ce degré de socialisation (cohésion <-> perturbation) varie d'une équipe à l'autre. Le seuil peut être détecté à partir des comportements des participants qui ne sont pas directement impliqués dans la socialisation de l'équipe. Si le niveau d'énergie du daily stand-up reste élevée, alors c'est probablement de la cohésion d'équipe ; si le niveau d'énergie du daily stand-up chute, Traitez le sujet à part et proposez une autre tribune pour traiter le sujet en agissant comme un Refroidisseur [OrgPatternsWaterCooler].

10f. Je ne me souviens pas

"Ce que j'ai fait hier ? ... Je ne me souviens pas... Ce que je vais faire aujourd'hui ? ... Je ne sais pas..."

Les daily stand-ups sont des réunions. Comme toutes les réunions, les participants ont la responsabilité de les préparer. Dans ce cas, tous les participants sont tenus de connaître les réponses aux trois questions Hier Aujourd'hui Obstacles. On peut être plus indulgent sur le fait de ne pas savoir ce qui sera fait aujourd'hui, car parfois il n'y a en réalité rien de prévu spécifiquement sauf à aller chercher la tâche suivante de plus haute priorité dans la pile.

Un manque de préparation peut générer un rythme plus faible donc moins d'énergie. Cela risque aussi de pénaliser la durée Quinze minutes ou moins, ce qui réduit encore le niveau d'énergie.

10g. Raconter une histoire[7]

Au lieu de fournir une brève description d'un problème, le participant fournit trop de détails et rentre trop dans le contexte ce qui fait que les autres en arrivent à faire la sourde oreille. La règle générale est d'identifier les obstacles lors du stand-up et de discuter des détails après le stand-up. Cela peut se résumer par "Donnez le titre, pas toute l'histoire" ou Traitez le sujet à part.

10h. Résolution de problèmes

L'idée clé pour maintenir la durée des stand-ups à Quinze minutes ou moins est d'éviter de Raconter une histoire et ne pas être tenté par la Résolution de problèmes en séance. Traitez le sujet à part.

10i. Faible niveau d'énergie

Cela peut indiquer un ralentissement du rythme dû au fait de Raconter une histoire, d'être tenté par la Résolution de problèmes, etc. Dans ce cas, Traitez le sujet à part. Cela peut être simplement lié à la taille de l'équipe. Cela peut être lié au moment de la journée, ce qui invite à essayer d'Utiliser le stand-up pour commencer la journée et N'utilisez pas le stand-up pour commencer la journée.

10j. Les obstacles ne sont pas identifiés

Il peut y avoir plusieurs raisons pour lesquelles les obstacles ne sont pas soulevés. Ne pas se souvenir, ça dépasse le seuil de douleur, le manque de confiance liée au fait de soulever des problèmes (car les Obstacles ne sont pas supprimés, les Observateurs interviennent en blâmant le membre de l'équipe), etc. Selon le contexte, se contenter d'introduire les questions Hier, Aujourd'hui, Obstacles et appliquer la Politique des Cochons et des Poulets peut ne pas être suffisant. Passer par un Tableau des obstacles peut fournir un environnement moins agressif pour identifier les obstacles. Les Rétrospectives [Kerth, 2001] sont un moyen efficace de découvrir la raison profonde pour laquelle Les obstacles ne sont pas identifiés.

10k. Les obstacles ne sont pas supprimés

À l'exception d'un environnement où l'on blâme les gens, le plus sûr moyen d'empêcher les gens d'identifier les obstacles, c'est de ne pas les traiter/supprimer. Pour que cela devienne difficile d'oublier et/ou ignorer les obstacles, suivez-les publiquement sur un Tableau des obstacles.

10l. Les obstacles sont Uniquement identifiés lors du stand-up

Les stand-ups agissent comme un filet de sécurité. Au pire, un obstacle sera communiqué à l'équipe complète à une journée près. Cependant, le stand-up n'est pas destiné à arrêter d'identifier et résoudre des obstacles au cours de la journée. Introduire un autre environnement pour identifier les obstacles tel qu'un Tableau des obstacles peut vous aider. Sinon, les raisons sous-jacentes pourront être découvertes à l'aide des rétrospectives.

11. Si vous avez une bonne sensation, c'est que les choses se déroulent probablement bien

Espérons que ce document vous aura donné un aperçu des subtilités des bonnes pratiques des stand-ups ainsi que des indicateurs sur des problèmes communément observés. Dans tous les cas, il doit être clair que le daily stand-up ne consiste pas simplement à se tenir ensemble debout tous les jours.

Il est important de ne pas trop se soucier de ne pas avoir toutes les bonnes pratiques ou même d'avoir quelques mauvaises pratiques. Si tous les objectifs sont atteints et que vous avez une bonne sensation, tout se passe probablement bien. Après tout, il s'agit juste de rester ensemble debout tous les jours :)

12. Que disent les autres ?

Autant que je sache, il n'y a pas d'autres articles plus précis sur les bonnes pratiques des daily stand-ups même si les idées de base existent dans les documents référencés. Il y a quelques articles en ligne sur les mauvaises pratiques ([Miller, 2003], [Cohn, 2003]) même s'ils restent tous les deux de portée limitée.

13. Remerciements

Je tiens à remercier Ivan Moore et Alan Francis de m'avoir aidé à déterminer ce que je voulais exprimer, Owen Rogers pour certaines des bonnes pratiques, Susan Newton de m'avoir rappelé que les stand-ups devait être soutenus, James Ross et Rebecca Parsons pour certaines modifications, Brian Marick pour m'avoir suivi, toutes les personnes présentes lors de mon atelier PLoP 2004 (Dick Gabriel, Linda Rising, James Coplien, Lise Hvatum, Cecilia et Terje Haskins, Danny Dig, David Hecksel, et Ali Arsanjani), Bill Wake pour ses commentaires détaillés, toutes les personnes présentes lors de mon atelier PLoP 2006 (Ralph Johnson, Pau Arumi, David Garcia, Léon Welicki, Djamal Bellebia, Dirk Riehle, Hesham Saadawi, et Paddy Fagan), Karthik Chandrasekarial pour la photo du stand-up, et toutes les personnes avec qui j'ai participé à un stand-up.

14. Références

[Anderson, 2002] Anderson, D., "Morning Roll Call", The Coad Letter: Process, Issue 101 (August 2002), URL: http://bdn.borland.com/article/0,1410,29686,00.html
[Beedle et al., 2000] Beedle, M. et al., "SCRUM: An Extension Pattern Language for Hyperproductive Software Development", Pattern Languages of Program Design 4, N. Harrison, B. Foote, and H. Rohnert, eds., Addison-Wesley, 2000, pp. 637-651
[Cockburn, 2001] Cockburn, A., Agile Software Development, Addison-Wesley, 2001
[Cochango, 2006] "Daily Scrum Meeting", URL: http://scrumforteamsystem.com/ProcessGuidance/Process/DailyScrumMeeting.html
[Cohn, 2003] Cohn, M., "Toward a Catalog of Scrum Smells", October 2003, URL: http://www.mountaingoatsoftware.com/articles/ScrumSmells.pdf
[Gibbs, 2006, Leaderless] Gibbs, E., "Leaderless Standups", 10 August 2006, URL: http://edgibbs.com/2006/08/10/leaderless-standups/
[Gibbs, 2006, Rugby] Gibbs, E., "Passing A Rugby Ball in Standups”, 14 August, 2006, URL: http://edgibbs.com/2006/08/14/passing-a-rugby-ball-in-standups/
[Gibbs, 2006, Signal] Gibbs, E., "Signaling the End of a Standup", 7 August, 2006, URL: http://edgibbs.com/2006/08/07/signaling-the-end-of-a-standup/
[Jeffries, 2004] Jeffries, R., "Big Visible Charts", March 2004, URL: http://www.xprogramming.com/xpmag/BigVisibleCharts.htm
[Kerth, 2001] Kerth, N., Project Retrospectives, Dorset House, 2001
[Koskela, 2006] Koskela, L., "On Scrum and the curse of the three questions", May 7, 2006, URL: http://radio.javaranch.com/lasse/2006/05/07/1147034972559.html
[LaPlante, 2003] Laplante, Phillip A., "Stand and Deliver: Why I Hate Stand-up Meetings", ACM Queue, 1, 7 (October 2003) [Mar, 2006] Mar, K., "Controling the flow of daily meetings with a team mascot", 13 May 2006, URL: http://kanemar.wordpress.com/2006/05/13/controling-the-flow-of-daily-meetings-with-a-team-mascot/
[Miller, 2003] Miller, C., "Stand-up Meeting Antipatterns", 19 November 2003, URL: http://fishbowl.pastiche.org/2003/11/19/standup_meeting_antipatterns
[Nicolette, 2006] Nicollete, D., "Re: On Scrum and the curse of the three questions", May 8, 2006, URL: http://radio.javaranch.com/lasse/2006/05/07/1147034972559.html#comment1147110635098
[Rising, 2002] Rising, L., "Agile Meetings", STQE, May/June 2002, pp. 42-46
[Rising and Janoff, 2000] Rising, L. and N. Janoff, "The Scrum Software Development Process for Small Teams", IEEE Software, July/August 2000, pp. 2-8
[Russell, 2006] Russell, R., "The Daily Stand Up, Part 2", 30 May 2006, URL: http://www.robbyonrails.com/articles/2006/05/29/the-daily-stand-up-part-2
[OrgPatternsStandUp] "Stand Up Meeting", Org Patterns, 7 October 2003, URL: http://www.easycomp.org/cgi-bin/OrgPatterns?StandUpMeeting
[OrgPatternsWaterCooler] "The Water Cooler", Org Patterns, 18 November 2003, URL: http://www.easycomp.org/cgi-bin/OrgPatterns?TheWaterCooler
[Schwaber and Beedle, 2001] Schwaber, K. and M. Beedle. (2001) Agile Software Development with Scrum, Prentice-Hall
[Shimp, 2006] Shimp, D., "An Overview of ScrumMaster – Part 2", July 18, 2006, URL: http://www.netobjectives.com/podcasts/last20060719_podcasts.mp3
[Wells, 1999] Wells, D., "Daily Stand Up Meeting", Extreme Programming: A gentle introduction., 1999, URL: http://www.extremeprogramming.org/rules/standupmeeting.html

Feedback :



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

Notes

[1] daily scrum

[2] daily huddle

[3] morning roll-call

[4] Big Visible Chart

[5] NdT : algorithme d'ordonnancement notoirement utilisé pour la répartition de charges, aussi appelé le Tourniquet, voir http://fr.wikipedia.org/wiki/Round-robin_%28informatique%29

[6] NdT : eh oui, c'est l'eXtreme Programming qui a introduit le terme Daily stand-up meeting, voir http://www.extremeprogramming.org/rules/standupmeeting.html

[7] Story Telling

jeudi, 23 juin 2011

Le Corpus de Connaissances de l'Agile Certified Practitioner du PMI

J'ai traduit cet article de David Bulkin sur InfoQ : "PMI Agile Certified Professional Body of Knowledge".

Il n'y a pas de référence unique pour ceux qui cherchent à préparer le nouvel examen Agile Certified Practitioner du Project Management Institute (PMI-ACP); le PMI propose plutôt une liste de domaines de test, d'ouvrages de référence, qui, pris ensemble, constituent le corpus de connaissances pour la certification.

Ceux qui détiennent la certification Project Management Professional (PMP) ont le Guide PMBOK, beaucoup s'attendaient donc à un équivalent pour l'Agile.

"J'aurais supposé que si le PMI offrait une certification Agile, ils auraient un Agile BOK dédié", a déclaré Chris Bodgwic, un PMP.

Chris, et d'autres qui préparent l'Examen PMI-ACP, peuvent commencer par un aperçu sur le contenu de l'examen de la certification Agile du PMI. Il y a deux catégories, Outils et Techniques, et Connaissances et Compétences, représentant chacun 50% de l'examen. Le PMI définit également six domaines qui sont des groupes de travail pour les projets agiles. Mike Griffiths les a regroupé en un seul cube qui représente un schéma simplifié du corpus de connaissances du PMI-ACP.

Agile Certified Practitioner 1

Pour le contenu, le PMI propose une liste de dix ouvrages de référence qui sont représentatifs des connaissances évaluées lors de l'examen.
- Agile Retrospectives: Making Good Teams Great - Esther Derby, Diana Larsen, Ken Schwaber (Foreward) ISBN #0977616649
- Agile Software Development: The Cooperative Game – 2nd Edition - Alistair Cockburn ISBN #032148275
- The Software Project Manager’s Bridge to Agility - Michele Sliger, Stacia Broderick ISBN #032150275
- Coaching Agile Teams - Lyssa Adkins ISBN #032163770
- Agile Project Management: Creating Innovative Products – 2nd Edition - Jim Highsmith ISBN #032165839
- Agile Estimating and Planning - Mike Cohn ISBN #0131479415
- The Art of Agile Development - James Shore ISBN #059652767
- User Stories Applied: For Agile Software Development - Mike Cohn ISBN #032120568
- Agile Project Management with Scrum - Ken Schwaber ISBN #073561993
- Lean-Agile Software Development: Achieving Enterprise Agility - Alan Shalloway, Guy Beaver, James R. Trott ISBN #032153289

Ces livres sont bien connus de la communauté Agile et les thèmes de ces livres qui sont couverts par le Contenu de l'Examen de la Certification Agile du PMI représentent le corpus de connaissances du PMI-ACP.


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

mercredi, 22 juin 2011

Les Fondamentaux de Scrum : les sept questions de la User Story

Boris GlogerJ'ai traduit cet article de Boris Gloger : "Scrum Essentials: The seven Questions of the User Story"

Une User Story est obtenue en répondant à 7 questions.

Qui voudrait quoi, à quelle fin ?

En tant que Utilisateur / Rôle ("Qui ?")
Je souhaiterais avoir cette fonctionnalité ("Quoi ?"),
Pour en avoir l'utilisation suivante. ("A quelle fin ?")

Ou en l'exprimant à travers un exemple :

En tant que Athlète
Je voudrais avoir des ailes,
Pour atteindre l'objectif plus rapidement que mes concurrents.

Bien sûr, il reste encore quatre questions :
1. Où ?
2. Quand ?
3. Comment ?
4. Pourquoi ?

La question "Où ?"

La question "Où ?" se rapporte au contexte et donc, dans un sens plus large, aux contraintes. Où cette fonctionnalité doit-elle se situer dans mon application ? L'image doit-elle être affichée dans les profils ou doit-elle être incluse dans le système de navigation pour que ce soit plus facile pour le conducteur d'atteindre l'objectif ?

Du coup, en répondant à cette question "où ?", on peut également rapidement détecter s'il s'agit d'une fonctionnalité essentielle ou non.

La question "Quand ?"

La question "Quand ?" représente le moment. Quand réfère toujours à un instant donné. Cette question nous aide à comprendre à quel moment les fonctionnalités sont utilisées.

La question "Comment ?"

Ici, nous nous nous intéressons à la mise en oeuvre, la conception. La conception ne pose pas la question du "Pourquoi ?" mais recherche plutôt une solution quant à la façon dont une chose doit être réalisée. La question "Comment ?" traite de problèmes tels que l'ergonomie, mais aussi de la solution technique à ce problème.

La question "Pourquoi ?"

Pour en savoir plus sur l'utilisation de quelque chose, on se pose la question "A quelle fin ?". C'est déjà un sujet traité dans la User Story. La question "Pourquoi ?" s'interroge sur la raison. Cette question se rapporte à la User Story elle-même : pourquoi devons-nous implémenter cette User Story ? Parce que l'entreprise en tire une valeur métier, parce que nous devons nous mettre en conformité avec des exigences réglementaires, parce que nous devons respecter des délais, etc.


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

lundi, 20 juin 2011

La Certification Agile du PMI s'appelera "Agile Certified Practitioner"

Mike GriffithsJ'ai traduit ce billet de Mike Griffiths : PMI Agile Cert to be called "Agile Certified Practitioner".

Agile Certified Practitioner 0Il s'avère que la suggestion initiale de "Agile Project Practitioner" (PMI-APP) était trop proche de "App." qui renvoie trop à Application et même à une application de téléphone[1]. Donc, le nom sera désormais ACP pour "Agile Certified Practitioner".

Le calendrier pour les personnes souhaitant postuler est le suivant :
- 23 Mai : Lancement public.
- Mi-Juillet : Des participants pilotes peuvent s'inscrire aux examens dans les centres de tests Prometric.
- 15 Septembre : Démarrage des tests des programmes pilotes.
- 30 Novembre : Fin des tests des programmes pilotes.
- 1er Janvier : La première série de personnes qui ont réussi l'examen est informée.

Je reçois beaucoup de questions sur le contenu de l'examen, donc j'ai pensé présenter différentes manières de l'interpréter. Dans mon dernier billet sur le sujet, j'ai montré le modèle de la boîte pour associer les Domaines avec les Connaissances et Compétences (KS[2]), et les Outils et Techniques (TT[3]).

Agile Certified Practitioner 6

Voici une version avec les répertoires KS et TT :

Agile Certified Practitioner 1

Une autre façon de le visualiser est d'examiner les champs couverts.
Nous pouvons commencer avec le champ de la gestion de projet :

Agile Certified Practitioner 2

On y retrouve la vision mondiale par le PMI de la gestion de projet et que j'appelle le contenu du Guide du PMBOK v4.

Agile Certified Practitioner 3

Le Guide du PMBOK v4 n'est cependant pas un pur sous-ensemble de la gestion de projet, puisque des choses comme le Code d'Ethique, bien qu'intéressant pour un PM, n'est pas strictement de la gestion de projet. De même, il existe de nombreuses techniques de gestion de projet, comme la Théorie des Contraintes, qui ne sont pas pleinement adopté par le Guide du PMBOK.

Agile Certified Practitioner 4

Lorsque nous ajoutons les principes Agile et Lean, nous constatons un chevauchement important.

Agile Certified Practitioner 5

Agile et Lean sont tout aussi concernés par la Qualité et l'Estimation que le Guide PMBOK, mais leur approche est souvent très différente.

La dernière partie importante de la connaissance est le Leadership.

Agile Certified Practitioner 7

Le Leadership couvre des sujets comme la Vision, l'Ethique, l'Intelligence Émotionnelle, le Leadership Situationnel et le Leadership au service de l'équipe[4]. Bon nombre des concepts que les projets Agile emploient. C'est la combinaison de ces champs Gestion de Projet, Agile et Leadership qui constitue la base pour l'examen "Agile Certified Practitioner" et qui est représentée par l'ovale en pointillé rouge ci-dessous.

Agile Certified Practitioner 8

Dans ce modèle, nous pouvons cartographier toutes les Connaissances et Compétences (KS) et les Outils et techniques (TT) qui feront partie de l'examen, mais l'image devient assez vite surchargée, donc je ne présente qu'une vue partielle.

Agile Certified Practitioner 9

Quoi qu'il en soit, j'espère que le modèle de boîte et le diagramme de Venn fournissent des moyens de comprendre le contenu. Les annonces officielles du PMI sur le calendrier seront faites le lundi 16 mai. Comme toujours, j'attends vos questions et commentaires.


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

Notes

[1] NdT : phone app

[2] NdT : Knowledge & Skills

[3] NdT : Tools & Techniques

[4] NdT : Servant Leadership ; et hop, j'en profite pour faire un clin d'oeil au petit cochon pendu au plafond de Thierry Cros.

samedi, 18 juin 2011

Equipe feature

Craig Larman Bas VoddeSuite à la traduction de l'article "Avant qu'il existe un Management" de Mary Poppendieck, j'ai décidé de traduire l'article "Feature Team Primer" de Craig Larman and Bas Vodde qui abordent les concepts extrêmement intéressants d'équipes feature[1] et de domaines fonctionnels[2] décrits dans leurs deux livres Scaling Lean & Agile Development et Practices for Scaling Lean & Agile Development... que je viens d'ajouter à ma liste d'envies.

(c) 2010 Craig Larman and Bas Vodde - www.featureteamprimer.org

Introduction aux équipes features

Une équipe feature, comme illustrée à la figure 1, est une équipe multi-composants, multi-fonctionnelles et pérenne[3] qui livre de nombreuses fonctionnalités bout-en-bout à ses clients, mais une à la fois.

Figure 1 : équipe Feature

Equipe Feature

Les caractéristiques d'une équipe feature sont énumérées ci-dessous :

  • pérenne, les membres de l'équipe restent ensemble et forment un "noyau dur"
  • très performante, l'équipe réalise de nouvelles fonctionnalités au fil de l'eau
  • multi-fonctionnelles et multi-composantes
  • idéalement, colocalisée
  • travaille sur une fonctionnalité centrée sur le client et de bout en bout, en passant à travers tous les composants et toutes les disciplines (analyse, programmation, tests, ...)
  • composée de spécialistes se généralisant
  • dans Scrum, habituellement 7 ± 2 personnes


Appliquer des pratiques d'ingénierie modernes, en particulier l'intégration continue, est essentielle lorsque vous choisissez d'être une équipe feature. L'intégration continue facilite la propriété partagée du code, ce qui est nécessaire lorsque plusieurs équipes travaillent en même temps sur les mêmes composants.

Un malentendu fréquent : chaque membre d'une équipe feature doit connaître l'ensemble du système. Pas forcément, parce que :

  • L'équipe entière, et non chaque membre, doit avoir les compétences pour mettre en œuvre l'ensemble de la feature centrée sur le client. Il s'agit notamment de la connaissance des composants et de compétences fonctionnelles tels que les tests, la conception centrée utilisateur ou la programmation. Mais au sein de l'équipe, les gens continuent à être spécialisés ... de préférence dans de multiples domaines.
  • Les features ne sont pas réparties au hasard sur des équipes features. Les connaissances et compétences actuelles d'une équipe sont prises en compte pour décider quelle équipe va travailler sur quelles features.


Dans une organisation basée sur des équipes feature, lorsque la spécialisation devient une contrainte... l'apprentissage commence.

Une organisation basée sur des équipes feature exploite les avantages de la vitesse générée par la spécialisation, ceci tant que la cartographie des exigences correspond aux compétences des équipes.

Mais lorsque les exigences ne correspondent pas aux compétences des équipes, l'apprentissage est "forcé", rompant ainsi la contrainte de sur-spécialisation.

Les compétences d'une équipe feature s'équilibrent entre spécialisation et flexibilité.

Le tableau 1 et la figure 2 suivantes mettent en évidence les différences entre les équipes feature et les équipes composants plus traditionnelles.

Tableau 1 : équipes feature vs composant

Équipe featureÉquipe composant
optimale pour livrer la valeur métier maximale (a)optimale pour livrer le nombre maximum de lignes de code
se concentre sur des features à forte valeur ajoutée et la productivité du systèmese concentre sur l'augmentation de la productivité individuelle en implémentant des features "faciles" de faible valeur
responsable de la feature de bout en bout et orientée clientresponsable seulement partiellement d'une feature orientée client
démarche "moderne" d'organisation des équipes (b) — évite la loi de Conwaydémarche traditionnelle d'organisation des équipes — respecte la loi de Conway (c)
conduit à se concentrer sur le client, à de la visibilité et à de plus petites organisationsconduit à "réinventer" le travail et à des organisations sans cesse croissantes
minimise les dépendances entre les équipes et augmente la flexibilitéles dépendances entre les équipes génèrent des efforts de planification supplémentaires (d)
met l'accent sur la multi-spécialisationsmet l'accent sur l'hyper-spécialisation
propriété collective du code produitpropriété individuel du code
partage des responsabilités par l'équiperesponsabilités clairement portées par chaque individu
s'appuie sur du développement itératifaboutit à un développement "cycle en V"
exploite la flexibilité ; apprentissage large et continuexploite l'expertise existante ; au plus bas concernant l'apprentissage de nouvelles compétences
requiert des pratiques d'ingénierie qualifiées, les effets sont largement visiblesfonctionne avec des pratiques d'ingénierie bâclées, les effets restent localisés
fournit une motivation pour produire un code facile à maintenir et à testercontrairement à la croyance, génère souvent un code de faible qualité dans le composant
apparemment difficile à mettre en œuvreapparemment facile à mettre en œuvre

(a) Une optimisation différente peut donner l'impression à l'équipe feature qu'elle est plus lente, d'un point de vue local.
(b) Relativement "moderne" puisque les équipes feature ont une longue histoire dans le développement à grande échelle, par exemple chez Microsoft et Ericsson.
(c) Mel Conway a observé cette structure indésirable en1968, il ne la recommandait pas, en fait c'était même tout le contraire.
(d) Cet effort de planification supplémentaire est visible dans la plupart des "réunions de planification de releases" ou "trains de release"” et génère un management inutile.

Figure 2 : équipes feature vs composant

Equipes feature vs composant

Le tableau ci-dessous résume les différences entre les équipes feature et les projets traditionnels ou groupes feature.

Tableau 2 : Equipes feature vs Projets feature

Équipe featureGroupe/Projet feature
équipe stable dont les membres restent ensemble pendant des années et qui travaillent sur de nombreuses featuresgroupe temporaire de personnes créé pour une feature ou un projet
responsabilité partagée par l'équipe sur toutes les tâchesresponsabilité individuelle des membres sur "leur" partie et basée sur la spécialisation
équipe auto-géréecontrôlée par un chef de projet
génère une organisation horizontale simple (pas de matrice !)génère une organisation matricielle avec des pools de ressources
les membres sont affectés à temps plein (100%) à l'équipeles membres sont à temps partiel sur de nombreux projets en raison de leur spécialisation


La majorité des défauts des équipes composant sont explorés dans le chapitre "Feature Teams" du livre "Scaling Lean & Agile Development" ; la figure 3 en résume quelques-uns.

Figure 3 : quelques défauts des équipes composant

Quelques défauts des équipes composant

Ce qu'on ne voit pas parfois, c'est que la structure d'une équipe composant renforce le développement séquentiel (modèle de la "cascade" ou cycle en V) en générant beaucoup de files d'attente, des tâches de taille variable, des niveaux élevés de TAF[4], de nombreux passages de relais, une augmentation du multitâches et l'affectation partielle des ressources.

Choisir des équipes composant ou des équipes feature ?

Une organisation basée uniquement sur des équipes feature est idéale d'un point de vue valeur ajoutée livrée et souplesse. Valeur et souplesse ne sont cependant pas les seuls critères pour construire une organisation, et de nombreuses organisations finissent par conséquent en mode hybride, plus particulièrement pendant la transition des équipes composant vers des équipes feature. Attention : les modèles hybrides ont les inconvénients des deux mondes et peuvent donc être... douloureux.

Un motif fréquemment exprimé en faveur d'une organisation hybride est la nécessité de construire des infrastructures, des composants réutilisables, ou de nettoyer le code écrit au sein des équipes composant. Mais ces activités peuvent aussi être réalisées une organisation basée sur des équipes purement feature, sans établir d'équipes composant permanentes. Comment ? En ajoutant les besoins d'infrastructure, de composants réutilisables ou de travail de nettoyage dans le Backlog Produit et en le donnant tel quel à une équipe feature existante comme s'il s'agissait de feature centrée client. L'équipe feature réalise ces travaux pendant un certain temps - aussi longtemps que le Product Owner le permet - puis retourne au développement de features centrées client.

Evoluer vers des Equipes Feature

Différentes organisations exigent différentes stratégies de transition lors du passage d'équipes composant à des équipes feature. Nous avons l'expérience de nombreuses stratégies qui ont marché... et échoué dans un contexte différent. Une stratégie de transition sécurisée - mais lente - consiste à établir une seule équipe feature au sein de l'organisation basée sur des équipes composant. Une fois que cette équipe fonctionne bien, une deuxième équipe feature est formée. Cela continue progressivement selon un rythme adapté à l'organisation. Ceci est illustré à la Figure 4.

Figure 4 : transition graduelle d'équipes composant vers des équipes feature

Transition graduelle des équipes composants vers feature

Introduction aux domaines fonctionnels

On peut créer des équipes features sans problème mais quand leur nombre dépasse dix, soit environ une centaine de personnes, une structure supplémentaire est nécessaire. Les domaines fonctionnels fournissent cette structure et étoffent les concepts derrière les équipes feature. Un domaine fonctionnel est une catégorisation des exigences menant à des vues différentes du Backlog Produit.

Le Product Owner (PO) classe chaque item du Backlog Produit sous exactement une catégorie fonctionnelle, son domaine fonctionnel. Ensuite, il génère des vues différentes sur l'ensemble du Backlog Produit que l'on peut appeler un Backlog Domaine. Les Backlogs Domaines sont priorisés par Product Owner Domaine qui se spécialise dans une partie du produit et selon une perspective client. Chaque domaine fonctionnel comporte plsieurs équipes feature travaillant sur le Backlog Domaine, comme illustré à la Figure 5.

Figure 5 : domaines fonctionnels

Domaines fonctionnels

Les domaines fonctionnels permettent de dimensionner correctement les équipes feature. Dimensionner en structurant les équipes en fonction de l'architecture du produit est appelé domaines de développement. Le tableau 3 résume les différences.

Tableau 3 : domaines fonctionnels vs domaines de développement

Domaine fonctionnelDomaine de développement
organisé autour d'exigences centrées clientorganisé autour de l'architecture du produit
pas de propriété sur le code sous-systèmepropriété du code pour chaque sous-système
de nature temporaire ; devrait changer au cours de la durée de vie du produit, mais pas à chaque itérationtend à être plus figé sur la durée de vie du produit
on se concentre sur le client, en utilisant le langage du clienton se concentre sur l'architecture, en utilisant le langage technique


Finalement, un Product Owner Domaine est différent d'un Product Owner délégué qui travaillerait avec une ou deux équipes pour aider un Product Owner débordé. Un Product Owner Domaine a différentes responsabilités, se concentre et travaille avec (probablement) au moins quatre équipes, pas seulement une. Cela évite des situations d'optimisation localisée aux activités d'une seule équipe.

Conclusion

Les équipes feature sont des équipes stables qui travaillent sur des features complètes et centrées client. Ces équipes apportent des solutions vis-à-vis des habituelles optimisations locales et travaux de coordination supplémentaires liés aux organisations basées sur des équipes composant. Cependant, ces équipes features doivent elles aussi relever des défis.

Les différents domaines fonctionnels génèrent des vues centrées client sur la globalité du Backlog Produit et permettent donc de structurer et dimensionner les équipes feature à la taille voulue.

Références

Scaling Lean Agile DevelopmentScaling Lean & Agile Development - Chapitres :
- Introduction
- Systems Thinking
- Lean
- Queueing Theory
- False Dichotomies
- Be Agile
- Feature Teams
- Teams
- Requirement Areas
- Organization
- Large-Scale Scrum

Practices for Scaling Lean Agile DevelopmentPractices for Scaling Lean & Agile Development - Chapitres :
- Large-Scale Scrum
- Test
- Product Management
- Planning
- Coordination
- Requirements
- Design
- Legacy Code
- Continuous Integration
- Inspect & Adapt
- Multisite
- Offshort
- Contracts


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

Notes

[1] NdT : Feature teams

[2] NdT : Requirement areas

[3] Les membres d'une équipe features restent ensemble pendant des années, réalisant plusieurs features.

[4] NdT : WIP = Work in Progress - Travaux à Faire

jeudi, 16 juin 2011

Rétrospective "Le Lean, la Totale Productive Maintenance (TPM) pour tous"

Club Lean Aquitaine

What went well

  • Présentation très intéressante de l’activité d’AEROCAMPUS sur le Centre de Latresne par Marc PECHEUX. Le Centre de Formation de Latresne (CFLE) est repris par la région Aquitaine et devient AEROCAMPUS en septembre 2011. C'est une bonne nouvelle quand on sait que cette école était menacée de fermeture. AEROCAMPUS s'inscrit désormais dans la structuration d'un pôle européen de la maintenance aéronautique en Aquitaine. Il propose un cursus complet en maintenance aéronautique allant du bac au diplôme d'ingénieur.
  • Présentation intéressante d'un exemple d’optimisation des flux dans l’industrie pharmaceutique par Sophie BOISSON (BMS AGEN). J'ai bien aimé la lutte des opérateurs contre le progiciel SAP pour réajuster les stocks à la main 50 fois par mois...
  • Présentation très intéressante de la mise en pratique du Lean pour la prestation de service en maintenance industrielle par Eric SAINTCLAIR (AQMO Blanquefort) : management visuel, A3 de résolution de problèmes, ...
  • Bonne vidéo sur "Les métiers de la maintenance" dans la filière industrielle par Michel COURBATERE (GETRAG FORD)... valoriser ce métier par les jeunes pour les jeunes.
  • Compte rendu de l’AG de Montargis par Jean Pierre RENAULT, Président de l'AFIM : la maintenance c'est 2,5% de la production en valeur, c'est 45000 emplois dont 12000 cadres.
  • Ah oui, ma présentation "Devenir un Problem Solver" s'est bien passée, je pense être resté dans l'esprit de la conférence :)

What went wrong

  • La visite de l'AIA Floirac (Atelier Industriel de l'Aéronautique) a pris beaucoup plus de temps que prévu : 1 heure de retard dans le programme, donc 2 sujets de conférence annulés :
    • L’essentiel du Lean par Alain COUPETE (A2C)
    • Le lean et le développement durable en maintenance par Philippe KOCIEMBA (APAVE)
  • Problèmes de version Powerpoint sur le PC de l'amphithéâtre... heureusement, Alain avait son Mac pour convertir les documents pptx en ppt !

Puzzles

  • PART66 ? définit les exigences en matière de connaissances, de qualifications et d’expérience des personnels destinés à prononcer la remise en service d’un aéronef.
  • PerfoLean ? action collective, organisée pour la mise en place d'un plan d'actions Lean dans une vingtaine de PMI d'Aquitaine de tous secteurs d’activités.
  • TRS ? Taux de Rendement Synthétique.

Lessons (re-)learnt

  • "On se concentrera sur les échanges entre les services ou les personnes. C'est en effet aux interfaces que l'on observe généralement une déperdition d'efficacité dans les services." - Lean Services - Baglin & Capraro
  • "Les personnels sont les capitaux les plus importants de la société et le déterminant de la croissance ou de l’effondrement de l’entreprise." – Eiji Toyoda

Appreciations

  • Merci aux organisateurs : l’AFIM Aquitaine, A2C et Le Club Lean Aquitaine.
  • Merci au CFLE, ou plutôt AEROCAMPUS, de nous recevoir dans ses locaux.
  • Merci aux orateurs : Alain, Philippe, Marc, Sophie, Eric, Michel, Jean-Pierre.
  • Merci au Club Lean Aquitaine, et notamment à Jean-Pierre LESCURE, de m'avoir permis d'intervenir.
  • Merci aux participants, et à la prochaine fois !

Links

  • Site 2ADI (Agence Aquitaine de Développement Industriel)
  • Site A2C (Aquitaine – Amélioration Continue de la Compétitivité)
  • Site AFIM (Association française des ingénieurs et responsables de maintenance)
  • Site APAVE (La maîtrise des risques)
  • Site AQMO (Ingénierie de Maintenance)
  • Site BMS France (Laboratoire pharmaceutique Bristol-Myers Squibb France - BMS UPSA)
  • Site CFLE (Centre de Formation de Latresne)
  • Site Club LEAN Aquitaine (contribuer à l'amélioration de la compétitivité des entreprises aquitaines déjà engagées dans des démarches de "Lean Management" en facilitant l’échange des bonnes pratiques)
  • Site GETRAG FORD (Production de transmissions manuelles et automatisées)

Alain se bat avec le PC Une quarantaine de personnes dans l'amphi.


Kanban signRetrouvez l'intégralité de mes rétrospectives sur le wiki Rétrospectives Agiles.

- page 1 de 13