Développement de logiciels allégés - Lean software development

Développement de logiciels
Activités principales
Paradigmes et modèles
Méthodologies et cadres
Disciplines de soutien
Les pratiques
Outils
Normes et corpus de connaissances
Glossaires
Grandes lignes

Le développement logiciel au plus juste est une traduction des principes et pratiques de fabrication au plus juste dans le domaine du développement logiciel . Adapté du Toyota Production System , il émerge avec le soutien d'une sous-culture pro-lean au sein de la communauté Agile . Lean offre un cadre conceptuel solide, des valeurs et des principes, ainsi que des bonnes pratiques, issues de l'expérience, qui soutiennent les organisations agiles.

Origine

Le terme développement logiciel lean trouve son origine dans un livre du même nom, écrit par Mary Poppendieck et Tom Poppendieck en 2003. Le livre réaffirme les principes traditionnels du lean , ainsi qu'un ensemble de 22 outils et compare les outils aux pratiques agiles correspondantes. L'implication des Poppendieck dans la communauté de développement de logiciels agiles , y compris des exposés lors de plusieurs conférences Agile, a permis à de tels concepts d'être plus largement acceptés au sein de la communauté agile.

Principes Lean

Le développement au plus juste peut se résumer en sept principes, très proches dans leur concept des principes du lean manufacturing :

  1. Éliminer les déchets
  2. Amplifier l'apprentissage
  3. Décidez le plus tard possible
  4. Livrer le plus vite possible
  5. Responsabiliser l'équipe
  6. Construire l'intégrité dans
  7. Optimiser l'ensemble

Éliminer les déchets

La philosophie Lean considère tout ce qui n'ajoute pas de valeur au client comme un gaspillage ( muda ). Ces déchets peuvent comprendre :

  1. Travail en partie fait
  2. Fonctionnalités supplémentaires
  3. Réapprentissage
  4. Le changement de tâche
  5. Attendre
  6. Transferts
  7. Défauts
  8. Activités de gestion


Pour éliminer les déchets, il faut être capable de les reconnaître. Si une activité peut être contournée ou si le résultat peut être atteint sans elle, c'est du gaspillage. Le codage partiellement terminé finalement abandonné au cours du processus de développement est un gaspillage. Les fonctionnalités supplémentaires telles que la paperasse et les fonctionnalités qui ne sont pas souvent utilisées par les clients sont des déchets. Faire basculer les gens entre les tâches est un gaspillage. Attendre d'autres activités, équipes, processus est du gaspillage. Le réapprentissage nécessaire pour terminer le travail est un gaspillage. Les défauts et la qualité inférieure sont des déchets. Les frais généraux de gestion ne produisant pas de valeur réelle sont du gaspillage.

Une technique de cartographie de la chaîne de valeur est utilisée pour identifier les déchets. La deuxième étape consiste à signaler les sources de déchets et à les éliminer. L'élimination des déchets doit avoir lieu de manière itérative jusqu'à ce que même les processus et procédures apparemment essentiels soient liquidés.

Amplifier l'apprentissage

Le développement logiciel est un processus d'apprentissage continu basé sur des itérations lors de l'écriture de 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 en termes d'aptitude à l'emploi et non de conformité aux exigences.

Au lieu d'ajouter plus de documentation ou de planification détaillée, différentes idées pourraient être essayées en écrivant du code et en construisant. Le processus de collecte des besoins des utilisateurs pourrait être simplifié en présentant des écrans aux utilisateurs finaux et en obtenant leurs commentaires. L'accumulation de défauts doit ê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 associé à une refactorisation et à des tests d'intégration . L'augmentation des commentaires via de courtes sessions de commentaires avec les clients aide à déterminer la phase actuelle de 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 un développement ultérieur. Ainsi, les clients comprennent mieux leurs besoins, sur la base des résultats existants 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 des ensembles - il 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écidez le plus tard possible

Comme le développement de logiciels est toujours associé à une certaine incertitude, de meilleurs résultats doivent être obtenus avec une approche basée sur des ensembles ou sur des options , en 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 la capacité de changement doit y être intégrée, permettant ainsi de retarder des engagements importants et cruciaux. L'approche itérative promeut ce principe – la capacité de s'adapter aux changements et de corriger les erreurs, qui pourraient être très coûteuses si elles étaient découvertes après la sortie du système.

Avec un développement basé sur des 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 découvre l'espace du problème et conçoit une solution potentielle. Comme une solution est jugée déraisonnable, elle est coupée. À la fin d'une période, les conceptions survivantes sont comparées et une 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 logicielles pourraient également bénéficier de cette pratique pour minimiser le risque induit par une conception initiale importante. De plus, il y aurait alors plusieurs implémentations qui fonctionnent correctement, mais qui sont différentes (en termes d'implémentation, en interne). Ceux-ci pourraient être utilisés 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 mises en œuvre, simultanément.

Une approche de développement logiciel agile peut accélérer la création d'options pour les clients, retardant ainsi certaines décisions cruciales jusqu'à ce que les clients aient mieux compris leurs besoins. Cela permet également une adaptation ultérieure aux changements et la prévention de décisions coûteuses liées à la technologie. Cela ne signifie pas qu'aucune planification ne doit être impliquée - au contraire, les activités de planification doivent se concentrer sur les différentes options et s'adapter à la situation actuelle, ainsi que clarifier les 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 offrent la flexibilité nécessaire pour une prise de décision tardive.

Livrer le plus vite possible

À l'ère de l'évolution rapide de la technologie, ce n'est pas le plus gros qui survit, mais le plus rapide. Plus tôt le produit final est livré sans défauts majeurs, plus tôt les commentaires peuvent être reçus et intégrés à la prochaine itération . Plus les itérations sont courtes, meilleurs sont l'apprentissage et la communication au sein de l'équipe. Avec la rapidité, les décisions peuvent être retardées. La vitesse assure la satisfaction des besoins actuels du client et non ce qu'il exigeait hier. Cela leur donne la possibilité 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. Ceci est réalisé en présentant le résultat requis et en laissant l'équipe s'organiser et diviser les tâches pour accomplir le résultat requis pour une itération spécifique . Au début, le client fournit les informations nécessaires. Cela pourrait ê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 système d'auto-traction - chaque matin lors d'une réunion debout , 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 les contributions nécessaires de ses collègues ou le consommateur. Cela nécessite une transparence du processus, ce qui est également bénéfique pour la communication en équipe.

Le mythe sous-jacent à ce principe est que la hâte fait du gaspillage . Cependant, la mise en œuvre Lean a prévu que c'est une bonne pratique de livrer rapidement afin de voir et d'analyser le résultat au plus tôt.

Responsabiliser l'équipe

Il existe une croyance traditionnelle dans la plupart des entreprises concernant la prise de décision au sein de l'organisation - les gestionnaires disent aux travailleurs comment faire leur propre travail. Dans une technique d'entraînement , les rôles sont inversés - les managers apprennent à écouter les développeurs , afin qu'ils puissent mieux expliquer les actions qui pourraient être entreprises, ainsi que fournir des suggestions d'améliorations. L'approche lean suit le principe agile « construire des projets autour d'individus motivés [...] et leur faire confiance pour faire le travail », encourager les progrès, détecter les erreurs et éliminer les obstacles, mais pas la micro-gestion.

Une autre croyance erronée a été la considération des personnes comme des ressources . Les gens peuvent être des ressources du point de vue d'une fiche 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 simple liste des tâches et l'assurance qu'ils ne seront pas dérangés pendant l'achèvement des tâches. Les gens ont besoin de motivation et d'un objectif plus élevé pour 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 soutien et aide dans les situations difficiles, ainsi que 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é dans

Le client doit avoir une expérience globale du système. C'est ce que l'on appelle l'intégrité perçue : comment elle est annoncée, livrée, déployée, consultée, à quel point son utilisation est intuitive, son prix et dans quelle mesure elle résout les problèmes.

L'intégrité conceptuelle signifie que les composants séparés du système fonctionnent bien ensemble dans un équilibre entre flexibilité, maintenabilité, efficacité et réactivité. Cela pourrait être réalisé 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 en petits lots - pas en un seul gros morceau - de préférence par communication en face à face et non par documentation écrite. Le flux d'informations doit être constant dans les deux sens - du client aux développeurs et inversement, évitant ainsi la grande quantité d'informations stressante après un long développement isolé.

L'une des voies saines vers l'architecture intégrale est la refactorisation . Au fur et à mesure que de nouvelles fonctionnalités sont ajoutées à la base de code d'origine, plus il devient difficile d'ajouter de nouvelles 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 mauvaises conceptions de 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 développeur et client, ayant les mêmes versions, synchronisation et sémantique que l'état actuel du système. À la fin, l'intégrité doit ê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'ajoutent pas de valeur, ils doivent être considérés comme des déchets. Les tests automatisés ne doivent pas être un objectif, mais plutôt un moyen d'atteindre une fin, en particulier la réduction des défauts.

Optimiser l'ensemble

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 standardisant les différentes étapes de développement, les causes profondes des défauts doivent être trouvées et éliminées. Plus le système est grand, plus il y a d'organisations impliquées dans son développement et plus de pièces sont développées par différentes équipes, plus il est important d'avoir des relations bien définies entre les différents fournisseurs, afin de produire un système avec des composants en interaction fluide. Sur une période de développement plus longue, un réseau de sous-traitants plus fort est bien plus bénéfique qu'une optimisation des profits à court terme, qui ne permet pas de relations gagnant-gagnant.

La pensée Lean doit être bien comprise par tous les membres d'un projet, avant de la mettre en œuvre dans une situation concrète et réelle. « Pensez grand, agissez petit, échouez rapidement ; apprenez rapidement » - ces slogans résument l'importance de comprendre le domaine et la pertinence de mettre 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 .

Pratiques logicielles Lean

Les pratiques de développement logiciel Lean, ou ce que les Poppendieck appellent « outils » sont légèrement reformulés par rapport aux équivalents originaux du développement logiciel agile . Voici des exemples de telles pratiques :

Étant donné que le développement logiciel agile est un terme générique pour un ensemble de méthodes et de pratiques basées sur les valeurs et les principes exprimés dans le Manifeste Agile, le développement logiciel lean est considéré comme une méthode de développement logiciel agile.

Voir également

Les références

Lectures complémentaires