Développement de logiciels épurée

De David J.Anderson.David J.Anderson est l'auteur de trois livres, leçons dans la gestion agile : Sur la route à Kanban, qui a été publiée le en 2012, Kanban : Modification évolutionnaire réussie de votre entreprise de technologie, [1] qui a été publiée le en 2010, et, gestion agile du software engineering institute : Appliquant théorie des contraintes pour les résultats d'entreprise, [2] qui a été publiée le en 2003.Il faisait partie de l'équipe qui a créé la méthode de développement logiciel Agile, développement basé sur la fonctionnalité, à Singapour entre 1997 et 1999.Il a créé le MSF for CMMI Process Improvement, et lui Co- créé la note technique de le chargement du software engineering institute, « CMMI et d'agile : Pourquoi pas étreinte les deux ! » Il était un fondateur de la société épurée de systèmes (http://www.leansystemssociety.org).Il est Président Épurée de Kanban - University Inc., un apprentissage accrédité et l'organisation de normes de qualité proposant l'apprentissage de Kanban via un réseau des partenaires dans le monde et de lui conduit un apprentissage de gestion et une entreprise de conseils internationaux, David J.Anderson & Associates Inc.(http://www.agilemanagement.net) qui aide les entreprises technologiques à améliorer leurs performances à travers de meilleures stratégies de gestion et de prise de décision.

Novembre 2011, en novembre 2012 mis à jour.

Anderson décrit le développement des logiciels Lean.

S'applique à

Lean, développement logiciel, gestion de projet, Team Foundation Server

• Introduction

• Lean et Agile

• Lean au-delà d'Agile

• Définition du développement logiciel Lean

• Valeurs

• Principes

• Pratiques

Le terme « Lean Software Development » (Développement logiciel Lean) a été utilisé pour la première fois à l'occasion d'une conférence organisée par l'initiative ESPRIT de l'Union européenne, à Stuttgart, en Allemagne, en octobre 1992.Indépendamment, l'année suivante, en 1993, Robert « Bob » Charette a proposé le concept de « développement logiciel Lean » dans le cadre de son travail visant à explorer les meilleures méthodes de gestion des risques dans les projets logiciels.Le terme « Lean » date de 1991, proposé par James Womack, Daniel Jones et Daniel Roos, dans leur ouvrage The Machine That Changed the World: The Story of Lean Production[3]. Ce terme anglais décrit l'approche de gestion utilisée par Toyota.L'idée que le Lean peut être appliqué dans le développement logiciel a été établie très tôt, seulement 1 à 2 ans après que ce terme ait été utilisé en association avec des tendances dans les processus de fabrication et la technologie industrielle.

Dans leur 2e ouvrage publié en 1995, Womack et Jones[4] ont défini les cinq piliers principaux du Lean Thinking.Il s'agissait de :

• Valeur

• Flux de valeur

• Fluide

• Pull (Extraction)

• Perfection

C'est devenu la définition par défaut pour la méthode Lean, pendant presque toute la décennie suivante.Il a été suggéré que la recherche de la perfection passe par l'élimination des déchets.Bien qu'il y ait 5 piliers, c'était le 5ème, la poursuite de la perfection via l'identification systématique des activités inutiles et leur élimination, qui a réellement correspondu aux attentes d'un large public.Lean est devenu presque exclusivement associé à la pratique de l'élimination du gaspillage jusqu'à la fin des 1990 et au début des années 2000.

La définition du concept « Lean » de Womack et de Jones n'est pas universellement partagée.Les principes de management de Toyota sont beaucoup plus subtils.Le terme anglais « waste » (déchets) est décrit de façon plus riche avec trois termes japonais :

• Muda : littéralement « déchets », mais impliquant une activité sans valeur ajoutée

• Mura : signifie « inégalité » et interprétée comme « variabilité du flux »

• Muri : signifie « surcharge » ou « caractère déraisonnable »

La perfection s'obtient via la réduction des activités sans valeur ajoutée, mais également via le lissage du flux et l'élimination de la surcharge.En outre, l'approche de Toyota a été basée sur un respect fondamental des personnes et fortement influencée par les enseignements de l'assurance qualité du 20ème siècle et les experts de contrôle de traitement statistique tels que W.Edwards Deming.

Malheureusement, il y a presque autant de définitions du mot « Lean » que d'auteurs ayant écrit sur le sujet.

Lean et Agile

Bob Charette a été invité, mais n'a pas pu assister à la réunion de 2001 à Snowbird, Utah, où le manifeste pour Agile Software développement[5] a été créé.Malgré le fait d'avoir manqué cette réunion historique, le développement de logiciel Lean a été considéré comme l'une des nombreuses méthodes Agile en matière de développement logiciel.Julien Highsmith a consacré un chapitre de son ouvrage de 2002[6] à un entretien avec Bob sur le sujet.Plus tard, Mary et Tom Poppendieck ont commencé à écrire une série de 3[7,8,9] ouvrages.Au cours des premières années du 21ème siècle, les principes Lean permettaient d'expliquer pourquoi les méthodes Agile étaient meilleures.Lean a expliqué que les méthodes Agile contenaient moins de gaspillage et produisaient donc un meilleur résultat économique.Les principes Lean ont été utilisés comme « donateur d'autorisation » pour adopter des méthodes Agile.

Lean au-delà d'Agile

Ces dernières années, le développement logiciel Lean a réellement émergé comme sa propre discipline associée à, mais pas spécifiquement, un sous-ensemble du mouvement Agile.Cette évolution a commencé grâce à la synthèse des idées du développement produit Lean et aux travaux de Donald G.Reinertsen[10,11] and ideas emerging from the non-Agile world of large scale system engineering and the writing of James Sutton and Peter Middleton[12].j'ai également synthétisé le travail d'Eli Goldratt et W.Edwards Deming a développé un focus sur le flux plutôt que sur la réduction des gaspillages[13].Réclamé par Reinertsen vers 2005, j'ai introduit l'utilisation des systèmes kanban qui limitent les travaux en cours et planifie de nouveaux travaux uniquement lorsque le système est prêt à les traiter.Alan Shalloway a ajouté ses opinions sur le développement logiciel Lean dans son livre de 2009 sur le sujet[14].Depuis 2007, l'émergence du Lean comme une nouvelle force dans la progression de la profession de développement de logiciels s'est concentrée sur l'amélioration des flux, la gestion des risques, et l'amélioration de la prise de décision (management).Le système Kanban est devenu un facteur important pour les initiatives Lean dans les travaux liés à l'informatique.Il s'avère qu'un focus orienté sur le flux et non sur l'élimination des déchets s'avère être un meilleur catalyseur pour l'amélioration continue dans les activités de travail intellectuel telles que le développement logiciel.

Définition du développement logiciel Lean

La définition du développement logiciel Lean est difficile car il n'existe aucune méthode ou processus de développement logiciel Lean spécifiques.Lean n'équivaut pas à un processus logiciel personnel, à un modèle V, un modèle en spirale, un EVO, un développement piloté par les fonctionnalités, une programmation extrême, un Scrum ou un développement piloté par les tests.Un processus de cycle de vie de développement logiciel ou un processus de gestion de projet peut être considéré comme « Lean » s'il respecte les valeurs et les principes du développement logiciel Lean.Ceux qui anticipent une recette simple qui peut être suivie et intitulée Développement de logiciel Lean seront déçus.Vous devez façonner ou personnaliser votre propre processus de développement de logiciels en comprenant les principes Lean et en adoptant ses valeurs principales.

Il existe plusieurs courants de pensée dans le développement logiciel Lean.Le plus grand, et mener discutablement, école est la société épurée de systèmes, qui inclut Donald Reinertsen, Julien Sutton, Alan Shalloway, Bob Charette, Marie Poppendeick, et David J.Anderson.Travail de Marie et de Tom Poppendieck développé avant la formation de la société et de ses charge par credo séparément, de même que le travail de Craig Larman, de Haut Vodde[15,16], et, récemment, de Julien Coplien[17].Accès de cet article soient largement représentant du point de vue épurée de société de systèmes comme exprimé dans son credo et de fournir un résumé et un résumé de leurs idées.

Valeurs

La société épurée de systèmes a publié son credo[18] aux 2012 conférence[19]épurée de logiciel et de systèmes.Il s'agit sur un ensemble de valeurs publiées une année précédemment.Ces valeurs sont les suivantes :

• Accepter la condition humaine

• Accepter que la complexité et l'incertitude soient naturelles dans le travail intellectuel

• Travail vers de meilleurs résultats économiques

• En activant de meilleurs résultats sociologiques

• Rechercher, adopter des idées d'une large gamme de disciplines

• Une communauté basée sur des valeurs améliore la rapidité et la profondeur des modifications positives

Accepter la condition humaine

Le travail des connaissances tel que le développement logiciel est effectué par les êtres humains.Nous, humains, sommes fondamentalement complexes et, bien que nous soyons des penseurs logiques, nous sommes également influencés par nos émotions et certaines caractéristiques inhérentes qui ne peuvent pas être ignorées.Notre psychologie et neuropsychologie doivent être prises en compte lors de la conception des systèmes ou des processus dans lesquels nous travaillons.Il faut également s'adapter à notre comportement social.Les humains sont fondamentalement émotifs, sociaux et tribaux, et nos comportements changent avec la fatigue et le stress.Les processus réussis sont ceux qui adoptent et s'adaptent à l'état humain plutôt que ceux qui essaient de le refuser et supposent un comportement logique (semblable à celui d'un ordinateur).

Accepter que la complexité et l'incertitude soient naturelles dans le travail intellectuel

Le comportement des clients et les marchés sont imprévisibles.Le flux de travail via un processus et un ensemble d'employés est imprévisible.Les erreurs et les corrections requises sont imprévisibles.À de nombreux niveaux du développement de logiciel, il existe un hasard inhérent ou un comportement apparemment aléatoire.Le but, les objectifs et la portée des projets ont tendance à évoluer pendant qu'ils sont remis.Une partie de ces incertitudes et variabilités (bien qu'initialement inconnues), est prévisible dans le sens où elles peuvent être étudiées et mesurées et les risques gérés, mais certaines variabilités sont impossibles à prévoir à l'avance et ne peuvent pas être correctement anticipées.Par conséquent, les systèmes Lean Software Development doivent pouvoir réagir aux événements qui sont en train de se produire, et le système doit pouvoir s'adapter aux circonstances qui évoluent.Par conséquent, n'importe quel processus de développement logiciel Lean doit exister dans une infrastructure qui permet l'adaptation (du processus) aux événements de déroulement.

Travail vers de meilleurs résultats économiques

Les activités humaines telles que le développement logiciel Lean doivent être concentrées sur la production de meilleurs résultats économiques.Le capitalisme est acceptable lorsqu'il contribue à la fois à la valeur de l'entreprise et l'avantage du client.Les investisseurs et propriétaires d'entreprise méritent un retour sur investissement.Les employés et les ouvriers méritent un taux de rémunération juste à la hauteur de l'effort de travail fourni.Les clients méritent un bon produit ou un bon service qui présente les avantages promis à un juste prix.De meilleurs résultats économiques impliquent l'apport d'une valeur supplémentaire au client, à un coût plus faible, tout en gérant le capital déployé par les investisseurs ou les propriétaires de manière la plus efficace possible.

Contribuez à de meilleurs résultats sociologiques

De meilleurs résultats économiques ne doivent pas être obtenus aux dépens de ceux qui réalisent le travail.La création d'un lieu de travail qui respecte les personnes en acceptant la condition humaine et qui fournit les méthodes de travail qui respectent la nature psychologique et sociologique des individus est essentielle.La création d'un lieu d'excellence est une valeur essentielle pour la communauté Développement logiciel Lean.

Principes

La communauté Lean Software & Systems semble accepter certains principes qui privilégient les processus de développement de logiciels Lean.

• Suivez l'approche Thinking & Design

• Les résultats émergents peuvent être influencés par l'architecture du contexte pour un système adaptable complexe

• Respect des personnes (dans le cadre du système)

• Utilisez la méthode scientifique (pour piloter les améliorations)

• Encouragez le leadership

• Générez la visibilité (dans le travail, le flux de travail et l'exploitation du système)

• Réduire le temps de flux

• Réduire le gaspillage pour améliorer l'efficacité

Suivez l'approche Thinking & Design

Dans les documents relatifs à la méthode Lean, cela est souvent appelé « optimiser l'ensemble », ce qui signifie qu'il s'agit de la sortie du système entier (ou du processus) que nous souhaitons optimiser et que nous ne devons pas optimiser par erreur des éléments dans l'espoir que l'ensemble soit optimisé, comme par magie.La plupart des praticiens pensent que le corollaire selon lequel l'optimisation des parties (optimisation locale) mènent à des résultats suboptimaux est vrai.

Une approche Lean Systems Thinking & Design nécessite que nous prenions en compte les demandes effectuées par les parties prenantes externes, telles que les clients, et le résultat requis par ces parties prenantes.Nous devons étudier la nature de la requête et la comparer avec la capacité de notre système à y répondre.La demande inclut une « demande de valeur » que les clients acceptent de payer et un « échec de demande » qui est généralement retravaillé ou une demande supplémentaire provoquée par un échec d'approvisionnement en demande de valeur.L'échec d'une demande prend souvent deux formes : le retravail d'une demande déjà traitée et de services ou d'une assistance supplémentaires en raison d'un échec lors du traitement d'une demande de valeur.Lors du développement logiciel, la demande d'échec correspond généralement à des demandes de résolutions de bogue et des demandes de prise en charge de client ou une fonction d'assistance technique.

Une approche de conception de systèmes nécessite que nous suivions également l'approche Plan-Do-Study-Act (PDSA) pour la conception et l'amélioration des processus.Ouest, Edwards Deming a utilisé les termes « étude » et « fonctionnalité » pour évoquer l'étude de la philosophie naturelle du comportement de notre système.Ce système se compose de notre processus de développement de logiciels et de tous les personnes qui y participent.Il aura un comportement observable en matière de délai de production, de qualité, de quantité de fonctionnalités ou de fonctions fournies (désigné dans la documentation Agile par le terme « velocity(rapidité) », etc.Ces métriques présenteront la variabilité et, en étudiant le moyen et la distribution de la variation, nous pouvons mieux évaluer de notre capacité.Si cela est incompatible avec la demande et les attentes des clients, le système devra être remanié pour répondre de manière satisfaisante.

Deming a également enseigné que la fonction est influencée à 95 %par la conception du système, et uniquement 5 % est fourni par les performances des personnes.En d'autres termes, nous pouvons respecter les personnes en ne les blâmant pas pour un décalage de la capacité par rapport à la demande et en remodelant le système pour leur permettre de réussir.

Pour comprendre la conception du système, nous devons avoir une connaissance scientifique de la dynamique de la capacité du système et de la manière dont elle peut être affectée.Les modèles sont développés pour prévoir la dynamique du système.S'il y a de nombreux modèles possibles, plusieurs modèles populaires sont couramment utilisés : la compréhension des coûts économiques ; les coûts dits de transaction et de coordination liés à la production de produits ou services ayant une valeur ajoutée pour le client ; la théorie des contraintes (la compréhension des goulots d'étranglement ; et la théorie des connaissances approfondies) ; l'examen et la reconnaissance de la variabilité en tant que commune à la conception du système ou spéciale et externe à la conception du système.

Les résultats émergents peuvent être influencés par l'architecture du contexte pour un système adaptable complexe

Les systèmes complexes présentent des conditions de démarrage et des règles simples qui, lorsqu'elles sont exécutées de manière itérative, produisent des résultats émergents.Il est difficile ou impossible de prédire les résultats émergents en fonction des conditions de démarrage.L'expérience informatique « The Game of Life » est un exemple de système complexe.Un système adaptable complexe intègre une « conscience de soi » et une méthode de réflexion interne lui permettant de déterminer dans quelle mesure son ensemble actuel de règles lui permet d'atteindre un résultat souhaité.Le système adaptable complexe peut ensuite choisir de s'adapter (pour modifier ses règles simples) pour combler l'intervalle entre les résultats actuel et celui souhaité.The Game of Life adapté de telle façon que réécrire les règles pendant le jeu serait un système adaptable complexe.

Dans les processus de développement logiciel, les « règles simples » des systèmes adaptatifs complexes sont les stratégies qui composent la définition de processus.Le principe essentiel ici est basé sur la croyance que le développement de logiciels et de services n'est pas une activité déterministe, et par conséquent un processus défini qui ne peut pas s'adapter ne sera pas une réponse appropriée aux événements imprévus.Par conséquent, le processus conçu dans le cadre de notre pensée de système et approche de conception doit être adaptable.Il s'adapte via la modification des stratégies dont il est composé.

L'approche de Kanban quant au développement de logiciel Lean utilise ce concept en traitant les stratégies du système d'extraction kanban comme des « règles simples » et les conditions de démarrage sont que le travail et le flux de travail sont affichées, que le flux est géré à l'aide d'une compréhension des dynamiques du système, et que l'organisation utilise une approche scientifique pour comprendre, proposer et implémenter des améliorations de processus.

Respect des personnes

La communauté Lean adopte la définition de Peter Drucker à propos du travail intellectuel qui indique que les ouvriers sont des intellectuels s'ils sont bien plus informés sur le travail qu'ils effectuent que leurs patrons.Cela donne l'impression que le personnel est mieux placé pour prendre des décisions sur la façon d'effectuer le travail et de modifier les processus pour améliorer l'exécution du travail.La voix du travailleur doit être respectée.Les ouvriers doivent être autorisés à s'organiser eux-mêmes pour terminer le travail et pour obtenir les résultats souhaités.Ils doivent également être autorisés à suggérer et à implémenter des possibilités d'amélioration de processus ou « événements kaizen », comme ils sont appelés dans les ouvrages consacrés à la méthode Lean.Créer des stratégies de processus explicites afin que les travailleurs sachent que les règles qui les contraignent sont un autre moyen de les respecter.Des règles bien définies encouragent l'auto-organisation en supprimant les craintes et le besoin de courage.Le respect des personnes en leur donnant du pouvoir et en leur attribuant un ensemble de stratégies explicitement déclarées va de pair avec la principale valeur en termes de respect de l'homme.

Utiliser la méthode scientifique

Utilisez des modèles pour comprendre les dynamiques de la façon dont le travail est effectué et la façon dont le système de développement du logiciel Lean s'exécute.Observez et étudiez le système et sa capacité, puis développez et appliquez les modèles pour prévoir son comportement.Collecter des données quantitatives dans vos études et utilisez ces données pour comprendre comment le système fonctionne et prévoir son mode de modification lorsque le processus change.

La communauté Lean Software & Systems utilise des méthodes statistiques, telles que des graphiques de contrôle de processus statistiques et des histogrammes d'analyse spectrale des données brutes pour le délai de production et la rapidité pour comprendre les capacités du système.Ils utilisent également des modèles tels que : la théorie des contraintes pour comprendre les goulots d'étranglement ; le système de connaissances approfondies pour comprendre la variation qui est intégrée à la conception du système par rapport à celle qui est influencée par l'extérieur ; et une analyse des coûts économiques sous la forme de tâches effectuées pour coordonner, installer, fournir ou nettoyer simplement après la création d'un produit ou de services importants pour le client.D'autres modèles entrent en vigueur, tels que la véritable théorie d'option, qui cherche à appliquer la théorie d'option financière à partir de la gestion des risques financiers dans la prise de décision réelle.

La méthode scientifique suggère : nous étudions ; nous pré-supposons des résultats à partir d'un modèle ; nous perturbons le système en fonction de cette supposition ; nous vérifions si la perturbation a produit les résultats prévus par le modèle.Dans le cas contraire, nous contrôlons nos données et réexaminons l'exactitude de notre modèle.L'utilisation des modèles pour piloter les améliorations des processus permet de passer d'une activité superstitieuse basée sur l'intuition à une activité scientifique.

Encouragez le leadership

Leadership et gestion ne sont pas identiques.La gestion est l'activité de conception des processus, de création, modification et suppression des stratégies, de prise des décisions stratégiques et opérationnelles, de collecte des ressources, de fourniture des finances et des fonctions et de communication d'informations sur le contexte, telles que la stratégie, les objectifs et les résultats voulus.Le leadership concerne la vision, la stratégie, la tactique, le courage, l'innovation, le jugement, la représentation et beaucoup d'autres attributs.Le leadership peut provenir et doit provenir de n'importe quelle personne appartenant à une société.Les petites actions de direction des ouvriers créeront une cascade d'améliorations qui fourniront les modifications nécessaires pour créer un processus de développement de logiciel Lean.

Générez la visibilité

Le travail des connaissances est invisible.Si vous ne voyez rien, il est (presque) impossible de remédier à la situation.Il est nécessaire de générer la visibilité dans le travail en cours et dans le flux de ce travail via un réseau de personnes, de compétences et de services jusqu'à ce qu'il soit terminé.Il est nécessaire de créer une visibilité dans la conception du processus en recherchant des méthodes pour visualiser le flux du processus et en explicitant les stratégies du processus explicites pour permettre à chacun de voir et considérer les choses.Lorsque tous ces éléments sont visibles, l'utilisation de la méthode scientifique est possible, et les conversations sur les améliorations potentielles peuvent être collaboratives et objectives.L'amélioration des processus de collaboration est presque impossible si le travail et le flux de travail sont invisibles et si les stratégies de processus ne sont pas explicites.

Réduire le temps de flux

Traditionnellement, les professionnels du développement de logiciels et les universitaires qui étudient la conception de logiciels se concentrent sur la mesure du temps passé sur une activité.La communauté de développement de logiciels Lean a découvert qu'il peut être plus utile de mesurer le temps calendaire véritablement écoulé pour traiter quelque chose.C'est généralement appelé Durée de cycle et généralement qualifié par les limites des activités effectuées.Par exemple, la durée de cycle entre l'analyse et la préparation du déploiement tient compte du temps écoulé total consacré à un élément de travail, tel qu'un récit utilisateur, pour l'analyse, la conception, le développement, le test de plusieurs façons et la mise en file d'attente pour le déploiement dans un environnement de production.

Vous concentrer sur le temps de travail impliquant un flux via le processus est important pour plusieurs raisons.De plus longues durées de cycle ont montré leur corrélation avec une croissance non linéaire des taux de bogues.Par conséquent, des temps de cycle plus courts garantissent une qualité supérieure.Cela est contre-intuitif. En effet, il semble ridicule que les bogues puissent être insérés dans le code pendant la file d'attente et que personne n'y touche.En général, la profession de génie logiciel et les universitaires qui l'étudient ont ignoré cette durée d'inactivité.Toutefois, la preuve empirique suggère que le temps de cycle est important pour la qualité initiale.

Alan Shalloway a également abordé le concept du « travail induit ». Selon lui, un retard dans l'exécution d'une tâche peut entraîner beaucoup plus d'efforts que si elle avait pu être exécutée.Par exemple, un bogue trouvé et résolu immédiatement peut prendre environ 20 minutes pour être corrigé, mais si ce bogue est trié, est mis en file d'attente, puis patiente plusieurs jours ou semaines pour être résolu, il peut impliquer plusieurs heures de correction.Par conséquent, le temps de cycle comprend le travail supplémentaire « induit ».Comme ce travail est évitable, en termes Lean, il doit être considéré comme du « gaspillage ».

La troisième raison de se concentrer sur les temps de cycle est une raison économique.Chaque fonctionnalité, fonction, ou récit utilisateur a une valeur.Cette valeur peut être incertaine, mais néanmoins, elle existe.La valeur peut varier avec le temps.Le concept de valeur variant au fil du temps peut être exprimé de façon économique en tant que fonction de bénéfice de marché.Lorsque la fonction de bénéfice de marché pour un élément de travail est comprise, même si la fonction indique une incertitude quant à la diffusion des valeurs au modèle, il est possible d'évaluer un « coût de retard ». Le coût du retard permet de favoriser la réduction du temps de cycle.

Avec certains éléments de travail, la fonction de bénéfice de marché ne démarre pas jusqu'à ce qu'une date dans le futur.Par exemple, une fonctionnalité destinée à être utilisée le jour férié du 4 juillet aux États-Unis n'a aucune valeur antérieure à cette date.La fait de raccourcir la durée de cycle et d'être capable de prévoir cette durée avec une certaine certitude est toujours utile dans un tel exemple.Idéalement, nous souhaitons démarrer le travail de sorte que la fonctionnalité soit livrée « juste à temps » et pas forcément avant ou après la date souhaitée, car la livraison tardive implique des frais de retard.La livraison juste-à-temps garantit que l'utilisation optimale a été faite des ressources disponibles.Une livraison rapide implique que nous puissions avoir travaillé sur autre élément et implicitement avoir subi un coût d'opportunité de délai.

À la suite de ces trois raisons, Lean Software Development cherche à réduire les temps de passage et d'enregistrer les données qui permettent de prévoir les temps de passage.L'objectif est de réduire la demande d'échec des bogues, les déchets provenant de la surcharge liée au délai de résolution des bogues, et d'optimiser la valeur produite en évitant les coûts de retard et les coûts d'opportunité de retard.

Réduire le gaspillage pour améliorer l'efficacité

Pour chaque activité à valeur ajoutée, il existe une étape de configuration, de nettoyage et de livraison qui sont nécessaires, mais n'ajoutez pas la valeur de votre propre chef.Par exemple, une itération de projet qui développe un incrément de logiciel fonctionnel requiert une planification (une activité de configuration), un environnement et éventuellement une branche de code dans le contrôle de version (collectivement appelé la gestion de la configuration et également une activité de configuration), un plan de version et l'exécution de la version réelle (une activité de livraison), une démonstration au client (une activité de livraison), et éventuellement un changement d'environnement ou une reconfiguration (une activité de nettoyage.) Dans termes économiques, la configuration, le nettoyage et les activités de livraison sont des coûts de transaction lors de l'exécution du travail à la valeur ajoutée.Ces coûts (ou charges) sont considérés comme des déchets dans le système Lean.

Toute charge liée à la communication peut être considéré comme une perte de temps.Les réunions visant à déterminer l'état du projet et à planifier le travail ou assigner le travail aux membres seraient considérées comme des frais de coordination en langage économique.Tous les coûts de coordination sont des déchets dans le système Lean Thinking.Les méthodes de développement logiciel Lean cherchent à éliminer ou réduire les coûts de coordination par l'utilisation de la colocalisation des membres d'équipe, de réunions en face à face rapides telles que les réunions debout, et de contrôles visuels comme les card walls.

La troisième forme de déchets courante dans le cadre du développement logiciel Lean est la demande d'échec.L'échec d'une demande est une charge sur le système de développement logiciel.L'échec d'une demande correspond généralement à un retravail ou à de nouvelles formes de travail générées sous l'effet d'une mauvaise qualité.Les formes de demande d'échec les plus courantes lors du développement logiciel sont les bogues, les erreurs de production et les activités de support technique faisant suite à un échec d'utilisation correcte du logiciel.Le pourcentage de travail en cours correspondant à une demande d'échec est souvent désigné en tant qu'échec de chargement.Le pourcentage de travail à valeur ajoutée par rapport à la demande d'échec est une mesure de l'efficacité du système.

Le pourcentage de travail à valeur ajoutée par rapport à l'ensemble du travail, y compris les coûts de coordination et de transaction sans valeur ajoutée, détermine le niveau d'efficacité.Un système sans coûts de transaction et de coordination et sans charge de défaillance est considéré comme efficace à 100 %.

Traditionnellement, les sciences de la gestion occidentale ont enseigné que l'efficacité peut être améliorée en augmentant la taille de lot du travail.En général, les coûts de transaction et de coordination sont fixes ou n'augmentent que légèrement avec une augmentation de la taille de lot.Par conséquent, des lots de travail plus conséquents sont plus efficaces.Ce concept est appelé « économie d'échelle ». Toutefois, dans les problèmes de travail de connaissances, les coûts de coordination ont tendance à accroître de manière non linéaire avec la taille de lot, alors que les coûts de transaction peuvent souvent afficher une croissance linéaire.Par conséquent, l'approche du 20ème siècle classique sur l'efficacité n'est pas appropriée pour les problèmes de travail liés aux connaissances comme le développement logiciel.

Il est préférable de se concentrer sur la réduction des surcharges tout en conservant de petites tailles de lots pour améliorer l'efficacité.Par conséquent, l'efficacité de la méthode Lean repose sur la réduction des déchets.Les méthodes de développement logiciel Lean sont concentrées sur les méthodes de planification rapide et économique, les charges faibles liées à la communication et les mécanismes de coordination à charges faibles efficaces, tels que les contrôles visuels dans les systèmes kanban.Elles encouragent également les tests automatisés et le déploiement automatisé pour réduire les coûts de transaction de la livraison.Les outils modernes destinés à réduire les coûts d'installation et de démontage d'environnement, tels que les systèmes de contrôle de version et l'utilisation de la virtualisation, contribuent également à améliorer l'efficacité de petites séries de développement logiciel.

Pratiques

Le développement logiciel Lean ne prescrit aucune pratique.Il est plus important de démontrer que les définitions de processus réelles sont alignées avec les principes et les valeurs.Toutefois, plusieurs méthodes sont fréquemment adoptées.Cette section fournit une vue d'ensemble de certains d'entre eux.

Organigrammes cumulatifs

Les organigrammes cumulatifs font partie en standard de la création de rapports Team Foundation Server depuis 2005.Les organigrammes cumulatifs tracent un graphique en aires d'éléments de travail cumulatifs dans chaque état d'un flux de travail.Ils comportent un grand nombre d'informations et peuvent être utilisés pour dériver le cycle de vie moyen entre les étapes d'un processus, ainsi que le taux de débit (ou « rapidité »).Les différents processus de cycle de vie de développement logiciel produisent des signatures visuelles différentes sur les diagrammes de flux cumulatifs.Les praticiens pouvez apprendre à identifier les modèles de dysfonctionnement dans le processus affiché dans le graphique en aires.Un processus vraiment « Lean » affiche des zones de couleur distribuées de façon uniforme, en augmentant doucement à un rythme régulier.L'image apparaîtra lisse sans étapes en escalier ni de blocs de couleur visibles.

Sous leur forme la plus basique, les organigrammes de flux cumulatifs servent à visualiser la quantité de travail en cours à une étape donnée du cycle de vie de l'élément de travail.Cela peut être utilisé pour détecter des goulots d'étranglement et pour observer les effets de « Mura » (variabilité dans le flux).

Contrôles visuels

En plus d'utiliser les organigrammes cumulatifs, les équipes de développement logiciel Lean utilisent des cartes physiques ou des projections de systèmes de visualisation électroniques pour afficher le travail et observer son flux.De telles visualisations aident les membres de l'équipe à observer le travail en cours s'accumuler et leur permettent de voir des goulots d'étranglement et les effets de « Mura ». Les contrôles visuels permettent également aux membres de l'équipe de s'organiser pour choisir le travail et collaborer ensemble sans planification, intervention ou direction de gestion spécifique.Ces contrôles visuels sont souvent appelés « murs de cartes » ou parfois (de façon erronée) « panneaux kanban ».

Systèmes Kanban virtuels

Un système kanban est une pratique adoptée de la production Lean.Elle utilise un système de cartes physiques pour limiter la quantité de travail en cours à un stade donné du flux de travail.De tels systèmes limités par le travail en cours créent une « récupération » où les nouvelles tâches sont démarrées uniquement lorsqu'il existe des kanban libres indiquant que ces tâches peuvent être « récupérées » dans un état particulier et que le travail peut continuer dessus.

Dans le développement logiciel Lean, les kanban sont virtuels et souvent dessinés en définissant un nombre maximal pour une étape donnée dans le flux de travail d'un type d'élément de travail.Dans certaines implémentations, les systèmes électroniques effectuent le suivi du kanban virtuel et fournissent un signal lorsqu'un nouveau travail peut être démarré.Le signal peut être visuel ou se présenter sous la forme d'une alerte tel qu'un courrier électronique.

Les systèmes Kanban virtuels sont souvent combinés à des contrôles visuels pour fournir un système Kanban virtuel visuel qui représente le flux de travail d'un ou de plusieurs types d'éléments de travail.Ces systèmes portent souvent le nom de « panneaux kanban » ou « systèmes kanban électroniques ». Un système kanban virtuel visuel est disponible en tant que plug-in pour Team Foundation Server, appelé Visual WIP[20].Ce projet a été développé en tant que projet open source par Hakan Forss, en Suède.

Petites tailles de lot / Flux monobloc

Le développement logiciel Lean nécessite que le travail soit effectué par petits lots, souvent désignés sous le terme d'itérations ou d'incréments ou que les éléments de travail circulent indépendamment, ce qui est désigné sous le terme de « flux monobloc ». Le flux monobloc requiert une stratégie de gestion de configuration sophistiquée pour autoriser la livraison du travail achevé alors que le travail inachevé n'est pas distribué par erreur.Pour cela, il s'agit généralement d'utiliser des stratégies de branche dans le système de contrôle de version.Un petit lot de travail est généralement considéré comme un lot qui peut être effectué par une petite équipe de 8 personnes ou moins en moins de 2 semaines.

Les petits lots et les flux monoblocs requièrent de fréquentes interactions avec les entrepreneurs afin de compléter le journal des travaux en souffrance, la file d'attente ou le travail.Ils doivent également pouvoir être libérés fréquemment.Pour permettre l'interaction fréquente avec des dirigeants et une livraison fréquente, il est nécessaire de réduire les coûts de transaction et de coordination des deux activités.Un moyen courant pour y parvenir consiste à utiliser l'automation.

Automation

Le développement logiciel Lean prévoit un niveau élevé d'automatisation pour générer un flux monobloc de manière économique, encourager la qualité élevée et réduire l'échec de la demande.L'utilisation des tests automatisés, du déploiement automatisé et des fabriques de logiciel pour automatiser le déploiement des modèles de design et la création de sections de code source répétitives peu variables seront des opérations banales dans les processus de développement logiciel Lean.

Événements Kaizen

En matière d'approche Lean, le terme kaizen signifie une « amélioration continue » et un événement kaizen est l'acte d'appliquer une modification à un processus ou outil qui se solde en définitive par une amélioration.

Les processus de développement logiciel Lean utilisent plusieurs activités différentes pour générer des événements kaizen.Ceux-ci sont répertoriés ici.Chacune de ces activités est conçue pour stimuler une conversation sur les problèmes qui affectent défavorablement la fonction et, par conséquent, la capacité à livrer en fonction de la demande.L'essence du kaizen dans le travail de connaissances est que nous devons provoquer des conversations à propos des problèmes entre groupes de personnes de différentes équipes avec des compétences différentes.

Réunions standup quotidiennes

Les équipes de développeurs de logiciels (souvent jusqu'à 50) se rencontrent généralement devant un système de contrôle visuel, tel qu'un tableau blanc en affichant une visualisation de leurs travaux en cours.Ils décrivent les dynamiques du flux et les facteurs affectant le flux de travail.L'accent est mis particulièrement sur le travail bloqué en externe et sur le travail retardé en raison des bogues.Les problèmes liés au processus sont souvent mis en évidence au cours de plusieurs réunions.Pour y remédier, un plus petit groupe peut rester après la réunion pour discuter du problème et pour proposer une solution ou pour traiter la modification.Un événement kaizen suivra.Ces réunions spontanées étaient souvent appelées cercles de qualité spontanés.De telles réunions spontanées sont au cœur d'une véritable culture kaizen.Les directeurs encourageront l'émergence des événements kaizen après les réunions debout quotidiennes pour entraîner l'adoption du concept Lean dans leur organisation.

Rétrospectives

Les équipes de projet peuvent prévoir des réunions régulières afin de réfléchir sur les performances récentes.Ces réunions ont souvent lieu lorsque les livrables de projet spécifiques sont terminées, après les incréments de développement, appelés itérations, ou les sprints de développement logiciel Agile.

Les rétrospectives utilisent en général une approche anecdotique de la réflexion en posant des questions comme « qu'est-ce qui s'est bien passé ? », « que ferions-nous différemment ? » et « que devons-nous cesser de faire ? »

Les rétrospectives produisent généralement un journal des travaux en souffrance des suggestions pour des événements kaizen.L'équipe peut ensuite en classer par ordre de priorité pour l'implémentation.

Révisions des opérations

Une révision des opérations est généralement plus importante qu'une rétrospective et inclut des représentants d'un flux de valeurs entier.Il est courant pour 12 services de présenter des données objectives et quantitatives qui indiquent la demande qu'ils ont reçue et reflètent leur capacité de faire face à la demande.Les révisions des opérations sont généralement effectuées chaque mois.Les principales différences entre une révision des opérations et une rétrospective résident dans le fait que les révisions des opérations couvrent un ensemble plus large de fonctions, en général un portefeuille de projets et d'autres initiatives, et utilisent les données objectives et quantitatives.Les rétrospectives, en comparaison, ont tendance à se limiter à un projet unique ; elles impliquent quelques équipes seulement (l'analyse, le développement, et le test, par exemple) et sont généralement de nature anecdotique.

Une révision des opérations provoque des discussions sur les dynamiques affectant les performances entre les équipes.Une équipe génère peut-être la demande d'échec qui traitée par une autre équipe ?Cette demande d'échec provoque peut-être des perturbations et fait que la deuxième équipe ne peut pas tenir ses engagements par rapport aux attentes ?Une révision des opérations offre la possibilité de discuter de ces problèmes et de proposer des modifications.Les révisions des opérations produisent généralement un petit journal des travaux en souffrance des événements kaizen potentiels qui peuvent être classés par ordre de priorité et planifiés pour une future implémentation.

Un processus de développement logiciel Lean a quelque chose d'unique.Un processus peut être considéré comme « Lean » s'il est clairement aligné sur les valeurs et les principes du développement logiciel Lean.Le développement logiciel Lean ne prescrit aucune pratique, mais certaines activités sont devenues courantes.Les organisations Lean cherchent à encourager le kaizen via la visualisation du flux de travail et du travail en cours et la compréhension de la dynamique de flux et des facteurs (tels que les goulots d'étranglement, la disponibilité non instantanée, la variabilité et le gaspillage) qui l'affectent.Les améliorations en termes de processus sont suggérées et justifiées comme des méthodes permettant de réduire les sources de variabilité, d'éliminer le gaspillage, d'améliorer le flux, ou d'améliorer la livraison de valeur ou les gestion des risques.Ainsi, les processus Lean Software Development évolueront toujours et seront toujours adaptés à l'organisation dans laquelle ils évoluent.Il ne sera pas naturel de copier simplement une définition de processus d'une organisation à une autre et de s'attendre à ce qu'elle fonctionne dans un contexte différent.Il sera également peu probable de retourner dans une organisation après quelques semaines ou quelques mois et de constater que le processus utilisé est identique à celui qui a été observé antérieurement.Il évoluera toujours.

Une société qui utilise un processus de développement logiciel Lean peut être qualifiée de « Lean » si elle génère seulement de faibles quantités de déchets de ces trois formes (« mura », « muri » et « muda ») et si elle fait preuve d'amélioration grâce à une gestion efficace des risques.Dans la méthode Lean, la recherche de la perfection s'apparente toujours à un voyage.Il n'existe pas de destination.Les véritables organisations Lean sont toujours à la recherche d'améliorations.

Le développement logiciel Lean est encore un domaine émergent et nous pouvons nous attendre à ce qu'il évolue au cours de la décennie à venir.

1. Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

2. Anderson, David J., « Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results », Prentice Hall PTR, 2003

3. Womack, James P., Daniel T.Jones and Daniel Roos, The Machine That Changed the World: The Story of Lean Production, 2007 updated edition, Free Press, 2007

4. Womack, James P, et Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2nd Edition, Free Press, 2003

5. Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Mary et Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

8. Mary et Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

9. Mary et Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

12. Sutton, James and Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005

13. Anderson, David J., « Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results », Prentice Hall PTR, 2003

14. Shalloway, Alan, et Guy Beaver et James R.Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009

15. Larman, Craig and Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010

17. Coplien, James O.et Gertrud Bjornvig, Lean Architecture: for Agile Software Development, Wiley, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/