Le Lean Software Development est un paradigme qui décrit un ensemble idéal théorique de circonstances pour la création de logiciels. Il est important de considérer le développement logiciel Lean comme l’une des nombreuses théories de développement logiciel, chacune avec ses avantages et ses inconvénients. Lors de l’utilisation du modèle de développement logiciel Lean, il y a sept points cruciaux à comprendre : éliminer le gaspillage, amplifier l’apprentissage, prise de décision tardive, livraison rapide, responsabilisation de l’équipe, renforcement de l’intégrité et visualisation de l’ensemble.
L’élimination des déchets est à la fois un objectif d’économie de temps et d’argent. En réduisant la quantité de code excédentaire et de fonctionnalités superflues dans le développement logiciel Lean, l’équipe de développement logiciel économise de l’argent et fournit un code plus précis à l’utilisateur final. Ainsi, les programmes créés à l’aide du modèle Lean Software sont moins gourmands en ressources et plus ciblés.
L’amplification de l’apprentissage dans le développement logiciel Lean fait référence au concept d’utilisation de cycles courts entre les phases de test. En théorie, cela fournit un retour d’information plus constant aux ingénieurs, ce qui permet d’identifier les problèmes plus tôt dans la chaîne de développement. Les utilisateurs finaux sont inclus dans ces phases, s’assurant que les versions bêta du programme répondent à leurs besoins.
La prise de décision tardive permet une flexibilité supplémentaire dans le calendrier de conception, permettant de prendre des décisions uniquement une fois que le nombre maximum de faits a été collecté. Par exemple, décider avant de commencer le développement que le programme X devrait avoir les fonctionnalités A, B et C peut sembler une bonne idée, jusqu’à ce que les tests sur le terrain révèlent que ces fonctionnalités ne peuvent pas être terminées à temps. Dans le développement logiciel Lean, la décision d’inclure A, B et C serait retardée jusqu’à ce qu’il soit certain que cela soit réellement possible.
La livraison rapide fait référence à une préférence pour fournir à l’utilisateur final un modèle bêta fonctionnel le plus rapidement possible – éventuellement lorsque le programme est terminé à 85 à 90% – et continuer à corriger et à mettre à niveau ce modèle pendant la durée de vie du programme. Cela contraste avec le fait d’attendre que le programme soit terminé à 100 % et de le livrer ensuite. En théorie, cela permet à l’utilisateur final de tirer plus de vie du programme, tout en permettant à l’équipe de développement de recevoir des commentaires supplémentaires sur les modèles bêta fonctionnels.
L’autonomisation de l’équipe signifie donner à l’équipe plus d’autonomie pendant le processus de programmation. En conséquence, ils s’investiront théoriquement davantage dans le projet. De plus, cela signifie leur fournir un accès aux clients, en faisant correspondre plus étroitement les attentes à la livraison réelle.
Enfin, la construction de l’intégrité et la vision d’ensemble se concentrent sur la visualisation du programme comme une seule unité. Comparez cela avec d’autres systèmes, qui considèrent un programme comme un patchwork de différents systèmes. Cette façon de penser « vue d’ensemble » fournit théoriquement un produit plus complet, car toute l’équipe est sur la même longueur d’onde lorsqu’il s’agit du produit fini.