Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Les fonctions supplémentaires comme la paperasserie et les fonctions peu utilisées par les clients sont du gaspillage. Le changement de personnel entre les tâches est un gaspillage. L’attente d’autres activités, équipes ou processus est un gaspillage. Le réapprentissage nécessaire pour terminer le travail est un gaspillage. Les défauts et la baisse de qualité sont du gaspillage. Les frais généraux de gestion qui ne produisent pas de valeur réelle sont des déchets.
Une technique de cartographie de la chaîne de valeur est utilisée pour identifier les déchets. La deuxième étape consiste à pointer les sources de gaspillage et à les éliminer. L’élimination du gaspillage doit se faire de manière itérative jusqu’à ce que même les processus et procédures apparemment essentiels soient liquidés.
Amplifier l’apprentissageModifier
Le développement de logiciels est un processus d’apprentissage continu basé sur des itérations lors de l’écriture du code. La conception de logiciels est un processus de résolution de problèmes impliquant les développeurs qui écrivent le code et ce qu’ils ont appris. La valeur du logiciel est mesurée dans l’aptitude à l’utilisation et non dans la conformité aux exigences.
Au lieu d’ajouter plus de documentation ou une planification détaillée, différentes idées pourraient être essayées en écrivant du code et en construisant. Le processus de collecte des exigences des utilisateurs pourrait être simplifié en présentant des écrans aux utilisateurs finaux et en obtenant leurs commentaires. L’accumulation de défauts devrait être évitée en exécutant des tests dès que le code est écrit.
Le processus d’apprentissage est accéléré par l’utilisation de cycles d’itération courts – chacun étant couplé à un refactoring et à des tests d’intégration. L’augmentation du retour d’information via de courtes sessions de feedback avec les clients aide à déterminer la phase actuelle du développement et à ajuster les efforts pour les améliorations futures. Au cours de ces courtes sessions, les représentants des clients et l’équipe de développement en apprennent davantage sur le problème du domaine et trouvent des solutions possibles pour le développement futur. Ainsi, les clients comprennent mieux leurs besoins, sur la base du résultat actuel des efforts de développement, et les développeurs apprennent à mieux satisfaire ces besoins. Une autre idée dans le processus de communication et d’apprentissage avec un client est le développement basé sur les ensembles – cela se concentre sur la communication des contraintes de la future solution et non des solutions possibles, favorisant ainsi la naissance de la solution via le dialogue avec le client.
Décider le plus tard possibleModifier
Comme le développement de logiciels est toujours associé à une certaine incertitude, de meilleurs résultats devraient être obtenus avec une approche basée sur les ensembles ou les options, retardant autant que possible les décisions jusqu’à ce qu’elles puissent être prises sur la base de faits et non d’hypothèses et de prédictions incertaines. Plus un système est complexe, plus il faut y intégrer une capacité de changement, ce qui permet de retarder des engagements importants et cruciaux. L’approche itérative favorise ce principe – la capacité à s’adapter aux changements et à corriger les erreurs, qui pourraient être très coûteuses si elles étaient découvertes après la sortie du système.
Avec le développement basé sur les ensembles : Si un nouveau système de freinage est nécessaire pour une voiture, par exemple, trois équipes peuvent concevoir des solutions au même problème. Chaque équipe se renseigne sur l’espace du problème et conçoit une solution potentielle. Lorsqu’une solution est jugée déraisonnable, elle est coupée. À la fin d’une période, les conceptions survivantes sont comparées et l’une d’entre elles est choisie, peut-être avec quelques modifications basées sur l’apprentissage des autres – un excellent exemple de report de l’engagement jusqu’au dernier moment possible. Les décisions relatives aux logiciels pourraient également bénéficier de cette pratique afin de minimiser le risque lié à une conception initiale importante. De plus, il y aurait alors plusieurs implémentations qui fonctionneraient correctement, mais qui seraient différentes (au niveau de l’implémentation, en interne). Celles-ci pourraient être utilisées pour mettre en œuvre des systèmes tolérants aux pannes qui vérifient l’exactitude de toutes les entrées et sorties, à travers les multiples implémentations, simultanément.
Une approche agile du développement logiciel peut faire avancer la construction des options pour les clients, retardant ainsi certaines décisions cruciales jusqu’à ce que les clients aient mieux réalisé leurs besoins. Cela permet également de s’adapter plus tard aux changements et d’éviter des décisions coûteuses liées à la technologie. Cela ne signifie pas qu’il ne faut pas planifier – au contraire, les activités de planification doivent se concentrer sur les différentes options et l’adaptation à la situation actuelle, ainsi que sur la clarification des situations confuses en établissant des modèles d’action rapide. L’évaluation des différentes options est efficace dès que l’on se rend compte qu’elles ne sont pas gratuites, mais qu’elles offrent la flexibilité nécessaire à une prise de décision tardive.
Livrer le plus rapidement possibleEditer
À l’ère de l’évolution rapide des technologies, ce n’est pas le plus gros qui survit, mais le plus rapide. Plus vite le produit final est livré sans défaut majeur, plus vite le feedback peut être reçu, et incorporé dans l’itération suivante. Plus les itérations sont courtes, meilleurs sont l’apprentissage et la communication au sein de l’équipe. Avec la vitesse, les décisions peuvent être retardées. La rapidité permet de répondre aux besoins actuels du client et non à ceux d’hier. Cela leur donne l’occasion de retarder leur décision sur ce dont ils ont réellement besoin jusqu’à ce qu’ils acquièrent de meilleures connaissances. Les clients apprécient la livraison rapide d’un produit de qualité.
L’idéologie de la production juste à temps pourrait être appliquée au développement de logiciels, en reconnaissant ses exigences et son environnement spécifiques. Pour ce faire, on présente le résultat nécessaire et on laisse l’équipe s’organiser et se répartir les tâches pour accomplir le résultat nécessaire pour une itération spécifique. Au début, le client fournit les données nécessaires. Cela peut être simplement présenté sous forme de petites cartes ou d’histoires – les développeurs estiment le temps nécessaire à la mise en œuvre de chaque carte. Ainsi, l’organisation du travail se transforme en un système d’auto-approvisionnement – chaque matin, au cours d’une réunion, chaque membre de l’équipe passe en revue ce qui a été fait hier, ce qui doit être fait aujourd’hui et demain, et demande à ses collègues ou au client de fournir les informations nécessaires. Cela exige la transparence du processus, ce qui est également bénéfique pour la communication au sein de l’équipe.
Le mythe sous-jacent avec ce principe est que la hâte engendre le gaspillage. Cependant, la mise en œuvre du lean a fourni que c’est une bonne pratique de livrer rapidement afin de voir et d’analyser la sortie au plus tôt.
Habiliter l’équipeEdit
Il y a eu une croyance traditionnelle dans la plupart des entreprises sur la prise de décision dans l’organisation – les gestionnaires disent aux travailleurs comment faire leur propre travail. Dans une technique de lean, les rôles sont inversés – on apprend aux managers à écouter les développeurs, afin qu’ils puissent mieux expliquer les actions à entreprendre, ainsi que fournir des suggestions d’amélioration. L’approche lean suit le principe agile « construire des projets autour d’individus motivés et leur faire confiance pour faire le travail », en encourageant les progrès, en attrapant les erreurs et en supprimant les obstacles, mais sans faire de microgestion.
Une autre croyance erronée a été de considérer les gens comme des ressources. Les gens pourraient être des ressources du point de vue d’une feuille de données statistiques, mais dans le développement de logiciels, ainsi que dans toute entreprise organisationnelle, les gens ont besoin de quelque chose de plus que la liste des tâches et l’assurance qu’ils ne seront pas dérangés pendant l’accomplissement des tâches. Les gens ont besoin de motivation et d’un objectif supérieur pour lequel travailler – un objectif dans la réalité accessible, avec l’assurance que l’équipe peut choisir ses propres engagements. Les développeurs doivent avoir accès au client ; le chef d’équipe doit apporter son soutien et son aide dans les situations difficiles, et veiller à ce que le scepticisme ne ruine pas l’esprit de l’équipe. Respecter les gens et reconnaître leur travail est une façon de responsabiliser l’équipe.
Construire l’intégrité dansEdit
Le client doit avoir une expérience globale du système. C’est ce qu’on appelle l’intégrité perçue : la façon dont il est annoncé, livré, déployé, accessible, l’intuitivité de son utilisation, son prix et la façon dont il résout les problèmes.
L’intégrité conceptuelle signifie que les composants séparés du système fonctionnent bien ensemble comme un tout avec un équilibre entre flexibilité, maintenabilité, efficacité et réactivité. Cela pourrait être atteint en comprenant le domaine du problème et en le résolvant en même temps, et non de manière séquentielle. Les informations nécessaires sont reçues par petits lots – et non en un seul gros morceau – de préférence par une communication en face à face et non par une documentation écrite. Le flux d’informations doit être constant dans les deux sens – du client aux développeurs et inversement, ce qui permet d’éviter la grande quantité stressante d’informations après un long développement en vase clos.
L’une des voies saines vers l’architecture intégrale est le refactoring. Plus on ajoute de fonctionnalités à la base de code originale, plus il devient difficile d’ajouter d’autres améliorations. Le refactoring consiste à garder la simplicité, la clarté, le nombre minimum de fonctionnalités dans le code. Les répétitions dans le code sont des signes de mauvaise conception du code et doivent être évitées. Le processus de construction complet et automatisé doit être accompagné d’une suite complète et automatisée de tests pour les développeurs et les clients, avec les mêmes versions, la même synchronisation et la même sémantique que l’état actuel du système. À la fin, l’intégrité devrait être vérifiée par des tests approfondis, garantissant ainsi que le système fait ce que le client attend de lui. Les tests automatisés sont également considérés comme faisant partie du processus de production, et par conséquent, s’ils n’apportent pas de valeur ajoutée, ils doivent être considérés comme des déchets. Les tests automatisés ne devraient pas être un objectif, mais plutôt un moyen d’atteindre une fin, plus précisément la réduction des défauts.
Optimiser le toutEdit
Les systèmes logiciels modernes ne sont pas simplement la somme de leurs parties, mais aussi le produit de leurs interactions. Les défauts dans les logiciels ont tendance à s’accumuler au cours du processus de développement – en décomposant les grandes tâches en tâches plus petites, et en normalisant les différentes étapes du développement, les causes profondes des défauts devraient être trouvées et éliminées. Plus le système est important, plus le nombre d’organisations impliquées dans son développement est élevé et plus les parties sont développées par des équipes différentes, plus il est important d’avoir des relations bien définies entre les différents fournisseurs, afin de produire un système dont les composants interagissent de manière fluide. Au cours d’une période de développement plus longue, un réseau de sous-traitants plus solide est bien plus bénéfique que l’optimisation des profits à court terme, qui ne permet pas d’établir des relations gagnant-gagnant.
La pensée allégée doit être bien comprise par tous les membres d’un projet, avant d’être mise en œuvre dans une situation concrète et réelle. « Think big, act small, fail fast ; learn rapidly » – ces slogans résument l’importance de la compréhension du terrain et la pertinence de la mise en œuvre des principes lean tout au long du processus de développement logiciel. Ce n’est que lorsque tous les principes lean sont mis en œuvre ensemble, combinés à un fort « bon sens » en ce qui concerne l’environnement de travail, qu’il existe une base pour le succès du développement de logiciels.