La valeur métier est-elle suffisante pour prioriser le backlog ?

((/dotclear/public/logos/scrumdesk-logo.gif|Logo ScrumDesk|L|Logo ScrumDesk))J’ai traduit ce billet de ScrumDesk ++[« Is business value enough for backlog prioritization ? »|http://www.scrumdesk.com/is-business-value-enough-for-backlog-prioritization/|en]++. Il a le mérite de montrer l’interdépendance des critères de priorisation. ScrumDesk est un outil agile de pilotage de projet, concurrent de ++[IceScrum|http://www.icescrum.org/]++ (par exemple).%%% > Les coachs Agile enseignent aux équipes à développer selon la __valeur métier__ qui doit être livrée en fin du sprint.%%% > %%% > Mais une valeur peut-elle constituée un indicateur de priorité ? Oui, mais pas à elle seule. Il y a beaucoup d’autres critères que nous oublions souvent de prendre en considération.%%% > %%% > Nous vous invitons à adopter une approche différente. Nous souhaiterions pouvoir calculer la priorité selon la valeur métier, mais en tenant également compte du risque et de l’effort. De cette façon, nous pouvons obtenir une priorité plus précise, autrement dit pas seulement basée sur une conjecture.%%% > %%% > ((/dotclear/public/traductions/SD-PriorityCalculation.png|Calcul de la priorité||Calcul de la priorité))%%% > %%% > Souvent, les Product Owners ne considèrent que la __Valeur Métier Positive__. Il s’agit de la valeur dont l’entreprise bénéficiera si la story est livrée. Mais il existe aussi une __Valeur Négative__ qui peut générer des pertes ; par exemple, il n’est pas logique de devoir se reconnecter lorsque vous passez d’une page à l’autre.%%% > %%% > Le facteur __Risque__ ne doit pas être oublié. Vous pouvez mettre en œuvre la gestion des risques de différentes manières ; par exemple, selon une échelle Haut->Bas ou en numérotant les niveaux de risque. Plus la story est risquée, plus la priorité est haute.%%% > %%% > Le facteur __Dépendances__ est le nombre de relations avec les autres stories. Plus il y a de dépendances, plus la priorité est haute puisque le problème semble être plus complexe.%%% > %%% > Le facteur __Effort__ rend la priorité non-linéaire. Ce qui est plus petit peut être fait plus tôt car cela peut être estimé beaucoup plus précisément. Les grosses stories sont typiquement des epics qui doivent par conséquent être mieux détaillées puisqu’elles ne sont pas prêtes pour être implémentées.%%% > %%% > ScrumDesk a mis en œuvre cette approche après avoir collaboré avec ses meilleurs clients. Nous avons appris à appliquer cette démarche dans l’élaboration de nos backlogs produits. Cela nous aide à confirmer notre intuition de la priorité lorsqu’on la compare à la priorité calculée.%%% > %%% > Nous prenons en compte cette priorité calculée dans l’estimation de l’__Importance__ de la story.%%% > %%% > ((/dotclear/public/traductions/SD-Priority1.png|Story 5401 : calcul de la priorité||Story 5401 : calcul de la priorité)) —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Agilité et Aspirine

((/dotclear/public/./.aspirine_s.jpg|Aspirine|L|Aspirine))Ce n’est pas facile en ce moment. Je travaille sur l’élaboration d’un __Backlog Produit__ avec le client, mais dans l’idéal ça aurait dû être fait il y a plusieurs mois au démarrage du projet. Personnellement, je m’heurte aux classiques (mais douloureux) problèmes suivants :%%% %%% – la __granularité des fonctionnalités__ : elle exige de descendre au niveau de la user story (pour les fonctionnalités importantes) mais le client ne comprend pas pourquoi il doit encore reformuler sous une autre forme (historique documentaire du projet) et pourquoi il ne pourrait pas le faire dans le cadre des ateliers de spécifications déjà lancés et planifiés…%%% %%% – la __multiplicité des acteurs__ : mes collègues sont responsables de certains ateliers fonctionnels et/ou techniques ; ils n’ont pas forcément connaissance de l’Agilité et encore moins du Backlog Produit qui apparaît par conséquent comme un n-ième document de travail… alors que ce doit être le document maître !%%% %%% – la __définition des critères de priorisation__ : le client a plus de facilité à estimer une priorité qu’à associer une valeur métier et je commence franchement à m’y perdre : est-ce que le niveau de priorité estimée par le client peut finalement correspondre à sa perception de la valeur métier ? est-ce que que le niveau de risque estimé par le fournisseur peut finalement correspondre à sa perception de l’effort ? je commence déjà à tordre le modèle (tiens ça me fait penser à la présentation « Agilité sous contraintes » de David Brocard).%%% %%% – la __localisation des équipes__ : pour l’instant, les équipes se trouvent toutes sur le plateau du projet chez le client, mais ça ne va pas durer… la situation cible c’est que les équipes de développement réintègrent rapidement leurs villes d’origine (j’ai de la chance, ça reste en France) selon le fameux modèle Front/Back : un Front Office « fort » à proximité du client pour recueillir, qualifier, spécifier le besoin et le support à la recette (bon ben autant dire le haut du cycle en V), des Back Office « réactifs » à distance du client pour la conception, le développement, les tests et l’intégration (bon ben autant dire le bas du cycle en V).%%% %%% J’ai un peu mal à la tête là, je vais aller prendre une aspirine :-)%%% %%% N’hésitez pas à me laisser un commentaire (prière de ne pas tirer sur l’ambulance).%%%

Livraison continue et Agilité

((/dotclear/public/photos/.jim-highsmith_t.jpg|Jim Highsmith|L|Jim Highsmith))Suite à un ++[tweet de Claude Aubry|http://twitter.com/claudeaubry]++ (merci !), j’ai traduit cet article de Jim Highsmith : ++[« Continuous Delivery and Agility »|http://www.jimhighsmith.com/2010/12/22/continuous-delivery-and-agility/|en]++. Il a le mérite de poser clairement les enjeux en termes de maturité des équipes à tous les stades de l’organisation (développement, opérations, management, …).%%% %%% > Livrer en continu est l’une des toutes dernières modes dans le développement logiciel ( »Continuous Delivery » par Jez Humble et David Farley). L’objectif des pratiques et des principes de livraison continue est d’encourager « une plus grande collaboration entre tous les acteurs impliqués dans la livraison du logiciel, ceci afin de livrer un logiciel à valeur ajoutée plus rapidement et de façon plus fiable (Humble & Farley) ». Livrer en continu est une extension des pratiques agiles qui livrent de la valeur aux clients très tôt et souvent. Comme le montre le schéma, cela associe un développement continu (développement itératif des fonctionnalités), une intégration continue (caractérisée par des tests automatisés globaux) et un déploiement continu (la capacité à déployer de nouvelles versions en production souvent)$$Note : la livraison continue couvre le cycle de vie entier et peut ne pas inclure le déploiement continu qui reste un choix d’organisation du client. Ceci est illustré dans le schéma par la flèche « livraison continue » qui ne va pas complétement jusqu’au bout du « déploiement continu ».$$.%%% > %%% > ((/dotclear/public/traductions/Strategic_Continuous_Delivery.jpg|Stratégie de livraison continue||Stratégie de livraison continue))%%% > %%% > À un niveau plus fin, Jez (via email) rappelle qu’il y a trois volets à la livraison en continu : le premier a trait à l’automatisation de la construction$$NdT : Build$$ du logiciel, des tests, du déploiement, de la migrations des données en base et de l’infrastructure; le deuxième concerne des pratiques telles que l’intégration continue, une bonne gestion de configuration et les tests; le troisième concerne les gens, en clair que tout le monde soit ensemble impliqué dans les tâches de livraison au travers de l’ensemble du cycle de vie du logiciel.%%% > %%% > Il y a deux problématiques qui sont liées au fait d’obtenir de la valeur métier à partir d’une démarche de livraison continue : l’impact de cette stratégie et l’agilité (ou adaptabilité). Tout d’abord, lorsque l’entreprise progresse vers la droite de l’axe horizontal du schéma, il devient vite nécessaire de faire des investissements supplémentaires et de baser l’organisation sur une démarche collaborative. Par conséquent, d’un point de vue valeur métier, les entreprises doivent évaluer l’impact stratégique de cette marge de progression. Bien que la livraison continue puisse réduire le coût ainsi que le risque (grâce à une plus grande automatisation), les avantages les plus importants sont obtenus par la livraison fréquente de nouvelles fonctionnalités logicielles. La question clé devient alors : « Comment pouvons-nous bénéficier de la livraison de nouvelles fonctionnalités mensuellement, hebdomadairement ou même quotidiennement ? ». En outre : « Comment notre organisation et nos processus doivent-ils changer? ».%%% > %%% > Dans les grandes entreprises, les applications informatiques concernent une grande variété de secteurs d’activité. Pour certaines applications, les avantages de la livraison continue peuvent être l’augmentation des recettes, tandis que pour d’autres cela peut être la réduction des coûts et des risques. En réfléchissant sur la mise en œuvre de la livraison continue à travers un portefeuille d’applications, les entreprises devraient commencer par celles qui ont le plus grand impact stratégique, celles disposant d’intéressantes perspectives d’accroissement des recettes.%%% > %%% > La deuxième problématique, lorsqu’on a les avantages de la livraison continue, c’est que l’organisation devient agile, autrement dit devient de plus en plus adaptable. De nombreuses entreprises semblent avoir du mal à démarrer avec Agile 101$$NdT : Jim Highsmith a baptisé “Agile 101”, l’approche qui consiste pour une organisation à apprendre les fondamentaux des pratiques et techniques Agile et à créer l’environnement propice à l’Agilité pour une équipe. L’idée est d’atteindre ce qu’il appelle « Adult Agility » (Agilité adulte).$$, l’approche agile fondée sur des règles (faites ceci, ne faites pas ça), qui est une première étape nécessaire en vue de devenir agile, mais qui ne reste qu’une première étape. Pour profiter de la réactivité rapide d’un environnement basé sur la livraison continue, l’ensemble de l’organisation, à la fois les équipes qui livrent et le management – doit être mûre pour effectuer les changements de processus nécessaires pour répondre rapidement, pour s’engager dans une démarche collaborative absolument nécessaire entre le développement et les opérations$$NdT : Support, Production, Exploitation, …$$ et pour adopter un état d’esprit basé sur l’exploration et l’adaptation.%%% > %%% > La livraison continue peut être la prochaine grande étape dans le fait de livrer rapidement de la valeur métier stratégique pour les clients, à moindre risque et peut être à moindre coût. Toutefois, cela ne se fera pas sans que le leadership$$NdT : je n’essaye plus de traduire ce terme en français, vu que le concept de leadership nous est étranger en France :-)$$ comprenne ses impacts potentiels au niveau stratégique et que l’organisation s’adapte nécessairement pour le mettre en œuvre.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Sushitron… le retour

Le 11 décembre, Florent Chavouet tenait une séance de dédicaces dans la librairie Mollat à Bordeaux. Ce fut l’occasion inespérée de lui exprimer mon admiration pour ses deux ouvrages « Tokyo Sanpo » et « Manabé Shima » ainsi que sa série sur les Sushis. Je lui ai demandé de dédicacer son dernier ouvrage à ma fille Jade avec un clin d’oeil au Sushitron.

Oyé, oyé ! si vous êtes éditeur à la recherche d’un jeune auteur talentueux et pleins d’idées ou pourquoi pas responsable de l’Office National du Tourisme Japonais, pensez à Florent Chavouet  et financez sa prochaine expédition !

Sushitron… le retour

Le 11 décembre, Florent Chavouet tenait une séance de dédicaces dans la librairie ++[Mollat|http://www.mollat.com/]++ à Bordeaux. Ce fut l’occasion inespérée de lui exprimer mon admiration pour ses deux ouvrages ++[« Tokyo Sanpo »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/02/14/Tokyo-Sanpo]++ et ++[« Manabé Shima »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/10/24/Manabe-Shima]++ ainsi que sa série sur les Sushis. Je lui ai demandé de dédicacer son dernier ouvrage à ma fille Jade avec un clin d’oeil au ++[Sushitron|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/07/18/Sushitron]++.%%% %%% [((/dotclear/public/lectures/.Mollat_s.jpg|Librairie Mollat à Bordeaux||Librairie Mollat à Bordeaux))|/dotclear/public/lectures/Mollat.jpg] [((/dotclear/public/lectures/.Florent-Chavouet-et-ses-crayons_s.jpg|Florent Chavouet et ses outils||Florent Chavouet et ses outils))|/dotclear/public/lectures/Florent-Chavouet-et-ses-crayons.jpg] [((/dotclear/public/lectures/.Florent-Chavouet-en-action_s.jpg|Florent Chavouet en action||Florent Chavouet en action))|/dotclear/public/lectures/Florent-Chavouet-en-action.jpg] [((/dotclear/public/lectures/.Florent-Chavouet-scan-Sushitron_s.jpg|Sushitron by Florent Chavouet||Sushitron by Florent Chavouet))|/dotclear/public/lectures/Florent-Chavouet-scan-Sushitron.jpg]%%% %%% Oyé, oyé ! si vous êtes éditeur à la recherche d’un jeune auteur talentueux et pleins d’idées ou pourquoi pas ++[responsable de l’Office National du Tourisme Japonais|http://www.tourisme-japon.fr/]++, pensez à ++[Florent Chavouet|http://florentchavouet.blogspot.com/]++ et financez sa prochaine expédition !%%%

Rétro Scrum – Coacher avec des métaphores

((/dotclear/public/photos/.photo-samuli-heljo_t.jpg|Samuli Heljo|L|Samuli Heljo))J’ai traduit ce billet très original de Samuli Heljo : ++[« Retro Scrum – coaching with metaphors »|http://www.samuliheljo.com/blog/retro-scrum-coaching-with-metaphors/|en]++.%%% %%% > « Je porte plusieurs casquettes », « coup de chapeau à l’équipe », « il a utilisé des tactiques de chapeaux noirs$$NdT : black hat = hacker$$ », ce sont des métaphores… nous les utilisons plus souvent que nous n’en n’avons conscience. En outre, nous avons ++[différentes façons d’apprendre|http://en.wikipedia.org/wiki/Learning_style|en]++. J’ai un style d’apprentissage très ++[visuel|http://en.wikipedia.org/wiki/Visual_learning|en]++, donc pour moi il est naturel de dessiner les choses et d’apprendre en comprenant l’ensemble avant de rentrer dans les détails. D’autres apprennent ++[en écoutant|http://en.wikipedia.org/wiki/Auditory_learning|en]++, mais en général, les métaphores aident les gens à comprendre de nouveaux concepts et de nouvelles idées.%%% > %%% > Selon Wikipédia : « La métaphore, c’est l’idée de comprendre une chose en parlant d’une autre. »%%% > %%% > Lorsque l’on coache, utiliser une belle métaphore fonctionne très bien. Étant donné que les gens essayent tout naturellement de comprendre de nouvelles informations en les reliant à leurs connaissances préalables, une métaphore appropriée peut être très efficace. En outre, en présentant de nouvelles informations dans de multiples contextes, il sera plus facile pour un apprenant de s’en rappeler plus tard. Voici un exemple d’application de Scrum à la métaphore de la cuisine présentée sous forme de rétrospective (je souhaitais aussi apprendre à utiliser Photoshop).%%% > %%% > [((/dotclear/public/traductions/.retro-scrum_m.jpg|Rétro Scrum||Rétro Scrum))|/dotclear/public/traductions/retro-scrum.jpg]%%% > %%% > « Scrum fonctionne comme une grande famille heureuse (l’Équipe Scrum) qui prépare un dîner (livraison d’une nouvelle fonctionnalité). La maman (le Product Owner) a écrit un menu (le Backlog du Produit) et demande au Papa et à sa fille (l’Équipe) de préparer la liste des courses (le Backlog du Sprint), acheter des aliments et préparer les plats (Sprint). Le fils aîné de la famille (le Scrum Master) gardera les enfants de la famille (il protège l’équipe) en dehors de la cuisine (la salle d’opérations$$NdT : War Room$$), s’assurera que la voiture fonctionne et que le père se concentrera sur la préparation des aliments plutôt que de boire de la bière. Cependant, la mère voudra vérifier que le menu est préparé correctement, donc elle vérifiera souvent les plats (la Revue du Sprint) et s’assurera que sa vision du dîner se concrétisera bien. Elle voudra probablement servir la nourriture dès que ce sera prêt, de sorte que les invités (les utilisateurs) n’auront pas à manger des hamburgers froids (livrer souvent). Le Papa et sa fille devront maintenir la cuisine propre (le Refactoring) et essayer d’éviter qu’il y ait du désordre (le Service technique). »%%% > %%% > Voilà :)%%% > %%% > L’image est disponible sur ++[Flickr|http://www.flickr.com/photos/samuliheljo/5110346513/|en]++ en taille ++[A3|http://www.samuliheljo.com/wp-content/uploads/2010/10/retro-scrum-a3.jpg|en]++ avec une ++[licence Creative Commons Attribution-NonCommercial-NoDerivs|http://creativecommons.org/licenses/by-nc-nd/3.0/|en]++.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Qu’est-ce-qu’une opération ?

((/dotclear/public/logos/logo_Harvard_Business_School.png|Harvard Business School|L|Harvard Business School))J’ai traduit l’article ++[« HBS Toolkit – Basic Operations Self-Instructional Workbook »|http://hbswk.hbs.edu/archive/1460.html|en]++ datant du 18/04/2000 et tiré de la __Base de connaissances de la Harvard Business School__. Une introduction très illustrée aux principes du cycle time, lead time et WIP.%%% > __Qu’est-ce-qu’une opération ?__%%% > %%% > Une opération représente tout processus qui prend des entrées et les transforme en résultats de plus grande valeur (on l’espère). Une usine de fabrication de voiture représente bien sûr une opération, mais également un hôpital, le service de traitement des réclamations d’une compagnie d’assurance ou une personne qui fait sa lessive. Ce cahier pédagogique de la Boîte à outils HBS introduit brièvement les concepts de base des opérations et illustre la façon dont une opération complexe peut être décomposée, décrite et cartographiée d’une manière qui la rend plus facile à comprendre et à améliorer.%%% > %%% > Nous donnerons les définitions et fournirons des exemples simples sur les concepts et termes suivants:%%% > – Temps de cycle (CT$$NdT : Cycle Time$$))%%% > – Goulet d’étranglement$$NdT : Bottleneck$$%%% > – Temps d’inactivité$$NdT : Idle Time$$%%% > – Travail En Cours (WIP$$NdT : Work-in-Process$$)%%% > – Tampons$$NdT : Buffers$$%%% > – Délai de fabrication (MLT$$NdT : Manufacturing Lead Time$$)%%% > – Cartographier une opération en utilisant le diagramme de flux du processus%%% > – Gérer les opérations pour une efficacité optimale%%% > %%% > __Temps de cycle__%%% > Le Temps de cycle est la durée qu’il faut en moyenne pour terminer une étape ou un ensemble d’étapes dans une opération. Dans notre exemple sur la lessive, le temps de cycle pour le lave-linge est de 30 minutes et le temps de cycle pour le sèche-linge varie de quarante-cinq minutes à une heure. Notez bien que le temps de cycle correspond à une durée moyenne.%%% > %%% > ((/dotclear/public/traductions/HBSWK_cycletime1.gif|Cycle Time||Cycle Time))%%% > %%% > Dans une laverie équipée de dix lave-linge, le temps de cycle pour une charge de linge unique serait de trois minutes (30 minutes divisées par dix lave-linge).%%% > %%% > ((/dotclear/public/traductions/HBSWK_tenwashers.gif|Ten Washers||Ten Washers))%%% > %%% > Il est important de prêter attention aux unités dont nous parlons. Si le sèche-linge est assez grand pour traiter deux charges de linge (et nous allons supposer que c’est le cas), le temps de cycle par charge de lave-linge représentera la moitié du temps de cycle par charge à sécher. Plus loin, nous parlerons aussi du temps de cycle pour le processus de lavage complet.%%% > %%% > ((/dotclear/public/traductions/HBSWK_units.gif|Units||Units))%%% > %%% > De nombreuses opérations ont des dépendances entre les étapes, c’est-à-dire des étapes qui ne peuvent être réalisées que lorsqu’une étape précédente est terminée. Vous pourriez mettre votre linge dans le sèche-linge avant le lave-linge, ou vous pourriez le plier avant de le mettre dans le sèche-linge, mais aucune de ces étapes n’est productive. Cette dépendance entre les étapes crée le besoin de bien gérer les opérations.%%% > %%% > ((/dotclear/public/traductions/HBSWK_fullprocess.gif|Full Process||Full Process))%%% > %%% > __Goulet d’étranglement__%%% > Si l’on considère un ensemble d’étapes dépendantes, il y a généralement une étape qui définit la vitesse à laquelle toute l’opération va s’exécuter. Cette étape est appelée le goulet d’étranglement parce que, tout comme un liquide sortant d’une bouteille, le goulet limite la vitesse de l’ensemble de l’opération. Supposons que le lave-linge et le sèche-linge puissent chacun traiter une « charge » de linge et que le temps de cycle de chaque étape soit comme suit :%%% > %%% > ((/dotclear/public/traductions/HBSWK_bottleneck1.gif|Bottleneck||Bottleneck))%%% > %%% > Maintenant, imaginez que nous avons beaucoup de linge à laver, de telle sorte que dès que nous avons mis notre première charge dans le sèche-linge, nous prévoyons de commencer notre seconde charge dans le lave-linge, et ainsi de suite. Une fois que notre « ligne de production » est pleine, quelle opération décidera (c-à-d limitera) la vitesse à laquelle nous pouvons faire notre lessive ? Le sèche-linge, car il sera toujours en train de sécher la première charge lorsque le lave-linge terminera son cycle sur la deuxième charge. Généralement, l’étape qui a le temps de cycle le plus long sera le goulet d’étranglement.%%% > %%% > ((/dotclear/public/traductions/HBSWK_bottleneck2.gif|Bottleneck||Bottleneck))%%% > %%% > Le goulet d’étranglement est souvent un sujet important à étudier pour l’amélioration de la capacité d’une opération, car si la capacité du goulet d’étranglement peut être augmentée, elle augmentera souvent la capacité globale, alors que augmenter la production d’une étape qui n’est pas un goulet d’étranglement peut n’avoir aucun effet. Dans notre exemple de lavage, si l’on peut sécher une charge de linge par jour en l’accrochant dehors, cela nous permettra de faire une charge supplémentaire de linge par jour. Si, toutefois, nous pourrions laver une charge à la main, cela ne nous permettrait pas d’obtenir plus de linge puisque notre lave-linge est déjà capable de produire plus de linge que ce que notre sèche-linge peut gérer.%%% > %%% > __Temps d’inactivité__%%% > Parfois, il vous suffit de faire une lessive, mais parce que les étapes du processus sont dépendantes, deux étapes (y compris le pliage) seront constamment inactives.%%% > %%% > ((/dotclear/public/traductions/HBSWK_idletime.gif|Idle Time|Idle Time))%%% > %%% > Puisque de nombreuses opérations sont capables de remplir leurs tâches plus rapidement que le goulet d’étranglement, cela n’aura pas souvent de sens de les faire fonctionner à pleine capacité. Si vous avez lancé le lave-linge et le sèche-linge non-stop toute la journée, vous pourriez accumuler des charges supplémentaires de linge mouillé attendant d’être séchées. Finalement, vous auriez pu arrêter le lave-linge pour laisser le sèche-linge rattraper le retard. Quand le lave-linge n’est pas lancé pendant une courte période pour chaque charge (en attendant que le sèche-linge ait fini), ou quand il est arrêté pendant une plus longue période plus tard dans la journée, ces temps d’arrêt sont appelés temps d’inactivité.%%% > %%% > __Travail En Cours__%%% > Le Travail En Cours, ou WIP, fait référence à des entrées qui sont encore en cours d’opération. Le linge toujours dans le lave-linge, le sèche-linge ou le pliage comptent comme du WIP dans notre exemple (comme le serait le linge à destination du lave-linge ou du sèche-linge). Le WIP est parfois traduit en termes financiers, mais sera généralement considéré dans d’autres unités (telles que les charges de linge) en mouvement dans l’opération. Dans notre exemple, une fois que la « ligne de production » est pleine, nous aurons toujours une charge, soit dans le lave-linge ou en attente d’être mise dans le sèche-linge ou encore une autre charge dans le sèche-linge. Nous aurons également une charge en train d’être pliée, mais étant donné que cette charge ne dépend de rien, cette étape sera quelquefois vide. En ignorant la possibilité que le pliage soit retardé par notre chargement et déchargement des machines, nous nous attendons à avoir une charge de linge en cours à l’étape de pliage pendant 30 minutes (le temps de pliage) sur les quarante-cinq minutes (temps de cycle de l’opération de lavage). Nous pourrions donc dire qu’il y a deux tiers d’une charge dans cette étape en décrivant le WIP de l’opération, ou 2+2/3 des charges de WIP au total.%%% > %%% > ((/dotclear/public/traductions/HBSWK_wip.gif|WIP||WIP))%%% > %%% > __Tampon__%%% > Parfois, une opération aura un espace de stockage où le WIP d’une étape va s’accumuler avant d’être traité par l’étape suivante. Il peut y avoir un grand nombre de raisons pour avoir un tampon. Supposons que nous ne voulons pas que le lave-linge soit lancé dans l’après-midi. Nous pourrions vouloir l’exécuter non-stop le matin pour obtenir autant de charges traitées que possible, mais nous aurions besoin d’espace pour les entreposer en attente que le sèche-linge rattrape le temps perdu. Dans les grandes opérations, un tampon peut être important afin de s’assurer que le goulet d’étranglement ne soit jamais en attente des entrées. Puisque c’est le goulet d’étranglement qui impose le rythme, la perte de production à cet endroit implique une perte de production pour l’ensemble de l’opération.%%% > %%% > ((/dotclear/public/traductions/HBSWK_buffers.gif|Buffers||Buffers))%%% > %%% > __Délai de fabrication__%%% > Le délai de fabrication, ou MLT, est la durée moyenne que prendra un nouvel ensemble d’entrées pour se déplacer tout au long de l’opération, en supposant que des mesures exceptionnelles n’aient pas été prises. Une charge de linge, par exemple, prendra un cycle (45 minutes) dans le lave-linge, y compris le temps d’inactivité, un nouveau cycle dans le sèche-linge (90 minutes au total), puis les deux tiers d’un cycle pour être plié (120 minutes). Du sac à linge à nettoyer jusqu’au pliage, cela prendra une moyenne de deux heures. Notez que, parce que pliage a lieu après notre goulet d’étranglement (le séchage), la charge n’aura pas à y séjourner pendant un cycle complet.%%% > %%% > ((/dotclear/public/traductions/HBSWK_leadtime.gif|Lead Time||Lead Time))%%% > %%% > L’exemple de la lessive est assez simple, mais dans une opération plus complexe il pourrait être difficile d’estimer le MLT en un coup d’œil. Il existe une formule simple, appelée Loi de Little, qui peut nous y aider. La Loi de Little énonce que :%%% > %%% > Délai de fabrication = Temps de cycle * Travail en cours%%% > %%% > Cette règle simple est utile si vous considérez le chemin que suivra un nouvel ensemble d’entrées (comme une charge de linge) pour passer à travers l’opération. Chaque fois qu’une unité de WIP est traitée à une étape, une nouvelle série d’entrées se présente. Chaque mouvement se produit une fois par cycle, donc multiplier le temps de cycle par le WIP nous donne notre délai de fabrication total.%%% > %%% > Dans notre exemple de lessive, nous avons un WIP de 2+2/3 de charges de linge. En multipliant 2+2/3 par notre temps de cycle de 45 minutes nous obtenons 120 minutes.%%% > %%% > __Cartographier une opération__%%% > Une méthode qu’un gestionnaire peut utiliser pour comprendre et améliorer une opération est de la cartographier. Par convention, nous cartographions des processus (tels qu’un lave-linge) avec des rectangles, les endroits où il y a du WIP ou des matières premières en attente avec des triangles, et nous indiquons les flux avec des lignes, en utilisant des flèches pour indiquer la direction. La capacité de chaque processus peut être ajoutée, si désirée.%%% > %%% > ((/dotclear/public/traductions/HBSWK_processmap0.gif|Process Map||Process Map))%%% > %%% > Une cartographie de départ de notre salle de lavage se présenterait comme suit:%%% > %%% > ((/dotclear/public/traductions/HBSWK_processmap1.gif|Process Map||Process Map))%%% > %%% > Les flux d’informations sont aussi importants pour comprendre comment fonctionne une opération. Ici, le flux d’informations est très simple; le lave-linge et le sèche-linge ont probablement chacun un signal sonore qui se déclenche quand ils ont terminés, ou peut-être sommes-nous tout simplement assez proches pour que nous puissions les entendre s’arrêter. Dans une opération plus complexe, cependant, les flux d’informations ne seraient pas aussi simples. Les flux d’informations sont généralement signalés sous forme d’une ligne en pointillée, afin qu’ils se distinguent facilement des flux physiques.%%% > %%% > ((/dotclear/public/traductions/HBSWK_processmap2.gif|Process Map||Process Map))%%% > %%% > __Utilisation d’outils de gestion des opérations__%%% > Supposons un instant que nous ne faisons pas notre propre lessive. Au lieu de cela, nous vivons chez nos parents et nous faisons la lessive de nos voisins le week-end pour nous faire un peu d’argent. Nous facturons 15 $ par charge, y compris le pliage. Jusqu’à maintenant, nous faisions six chargements par jour. Supposons que l’on envisage d’acheter un meilleur lave-linge ou un meilleur sèche-linge pour nous aider à faire plus d’argent. Nos parents sont prêts à nous aider, car ce sera leur nouveau lave-linge ou sèche-linge, mais cela nous coûtera encore 100 $. Le nouveau lave-linge ne nous prendra que 20 minutes pour faire une charge de linge, tandis que le nouveau sèche-linge ne nous prendra que 30 minutes. Que devrions-nous faire ?%%% > %%% > Eh bien, notre compréhension des goulets d’étranglement montre que l’achat du lave-linge n’a probablement que peu de sens. Le rythme auquel nous pouvons laver, sécher et plier le linge est imposé par l’étape la plus lente, le séchage. Considérons donc le nouveau sèche-linge. A quoi ressemblerait la nouvelle cartographie ?%%% > %%% > ((/dotclear/public/traductions/HBSWK_processmap3.gif|Process Map||Process Map))%%% > %%% > Maintenant, chaque processus a un temps de cycle de 30 minutes, ce qui suggère un temps de cycle de 30 minutes également pour toute la ligne de production. Dans la pratique, notre temps de cycle vaudra certainement plus, puisque nous utilisions sans doute notre temps d’inactivité dans le processus de pliage pour déplacer le linge dans et en dehors des machines, se reposer, etc. Mais par approximation, nous pouvons estimer que notre nouvelle capacité est environ 50% plus élevée qu’elle ne l’était auparavant, soit neuf chargements par jour. Ainsi, nous nous attendons à gagner une somme supplémentaire de 45 $ par jour, et nous serions en mesure de payer l’achat d’un nouveau sèche-linge au bout d’un seul week-end. Nous pourrions aussi vouloir vérifier certaines hypothèses, comme notre capacité à traiter trois charges supplémentaires par jour, mais du point de vue opérationnel, le nouveau sèche-linge semble un bon pari.%%% > %%% > __GLOSSAIRE__%%% > %%% > __Goulet d’étranglement__ : les ressources de production qui limitent la capacité de l’ensemble du processus. C’est généralement le matériel de production qui se trouve à l’étape disposant de la plus faible capacité globale, c’est à dire, du temps de cycle le plus long. Dans certaines situations, les ressources à l’origine du goulet d’étranglement peuvent être la main-d’œuvre disponible pour une étape donnée ou plusieurs étapes.%%% > %%% > __Tampon__ : stockage provisoire où du travail en cours peut être stocké entre les étapes d’un processus. Dans notre exemple de la lessive, un panier à linge entre les cycles de lavage et de séchage peut être considéré comme un tampon.%%% > %%% > __Capacité__ : le taux maximum de production d’un processus, mesuré en unités de production par unité de temps. L’unité de temps peut être une longueur, un jour, une minute, …%%% > %%% > __Temps de cycle (CT)__ : durée moyenne entre deux unités traitées. Elle est directement liée à la vitesse de production. Un processus avec une vitesse de production de 4 unités par heure a un temps de cycle de 15 minutes.%%% > %%% > __Temps d’inactivité__ : durée pendant laquelle aucun travail utile n’est réalisé.%%% > %%% > __Taille du lot$$NdT : Lot Size ou Batch Size$$__ : nombre d’unités d’un type particulier de produit qui sont produites avant le début de la production d’un autre type de produit.%%% > %%% > __Délai de fabrication (MLT$$NdT : parfois appelé Throughput Time$$)__ : temps dépensé par chaque unité dans le processus de fabrication. Cela inclut le temps passé à travailler activement sur chaque étape du processus aussi bien que le temps passé à attendre entre les étapes. Le concept du délai de fabrication s’applique au temps total passé dans tout processus dans lequel le début et la fin sont des événements bien définis. Nous pouvons parler de délais de fabrication/lead time, par exemple dans les services ou dans l’ensemble du processus de la commande à la livraison.%%% > %%% > __Opération, Système d’exploitation ou Processus__ : toute partie d’une organisation qui prend les entrées et les transforme en produits de plus grande valeur pour l’organisation que les entrées d’origine.%%% > %%% > __Processus__ : dans ce document, un « Processus » peut se référer au processus de production complet, comme faire une lessive ou la fabrication du pain, du début à la fin, ou à un segment de l’ensemble du processus, tels que le cycle de lavage ou le processus de cuisson.%%% > %%% > __Diagramme de flux du processus__ : décomposer un processus en composants discrets et le schématiser comme une série de petits rectangles (processus), de flèches (flux d’informations et de matériel) et de triangles inversés (stockage de marchandises).%%% > %%% > __Utilisation__ : ratio des entrées réellement utilisées sur la quantité d’entrées disponibles. L’utilisation du travail est le rapport entre le temps de travail effectif consacré au traitement et la quantité totale de temps de travail disponible. Les différences entre les deux peuvent être dues à l’inefficacité du processus qui mène à la perte de temps de travail, ainsi qu’à des déséquilibres dans les temps de cycle à chaque étape du processus qui mènent à de l’inactivité des travailleurs à quelques étapes alors que les autres travaillent . L’utilisation des capacités est le rapport entre la capacité réellement utilisée (c-à-d la sortie du processus) et la capacité totale disponible.%%% > %%% > __Travail en cours__ : nombre d’unités dans le processus à tout moment. Si le processus comprend des stocks tampons entre les étapes, le travail en cours est le nombre total d’unités en cours d’élaboration ainsi que le stock en attente entre les étapes. Les unités en stock sont généralement désignées comme du Travail en cours de fabrication, pour les distinguer des stocks de matières premières ou de stocks de produits finis.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.