7 gaspillages dans le développement de logiciels Lean et comment les éviter

La pensée Lean Process donne la priorité à l'éradication et à la réduction de la compilation des déchets. Malgré l'approche « lean » adoptée par les grandes entreprises, certaines pratiques standard de « gaspillage » persistent en raison de leur « nature évidente ». La nature qui est profondément gravée dans les pratiques humaines et organisationnelles est têtue jusqu'à ce qu'elle adopte une approche stricte.

Qu'est-ce qu'un déchet ?

Tout ce qui nécessite des ressources/du temps ou des efforts, mais qui ne produit pas de résultats pertinents en termes de performances ou d'augmentation des revenus est appelé « gaspillage ».

En fin de compte, la procédure de «réduction des déchets» est conçue et guidée pour augmenter la productivité et les résultats de l'équipe.

Cependant, maintenant que le développement logiciel Lean est l'ancêtre de l'agilité, nous pouvons adopter ces sept principes de réduction des déchets sur l'ingénierie et le développement logiciel pour produire des produits et services efficaces, réduire les coûts et accélérer la mise sur le marché des produits.

1. Travail partiellement terminé

Si le travail précédent n'est jamais redémarré, cet effort a été inutile.

Tout travail jusqu'à ce qu'il soit terminé/terminé n'ajoute rien à la proposition de valeur du client ; ainsi, cela fait perdre du temps et remet en question la maintenance du code s'il est mis en attente.

Un exemple contemporain est lorsqu'un client nécessite une modification ou des fonctionnalités supplémentaires sur un produit. L'entreprise s'engage à les terminer d'urgence; l'équipe de développement doit arrêter le travail en cours et agir sur les exigences. Sur la même page, si le travail précédent n'est jamais redémarré, cela a été un gaspillage d'efforts.

ou alors

Documentation non codée : les exigences sont détaillées en détail mais ne sont jamais mises en œuvre.

Comment réduire ces déchets ?

• L'accent doit être mis sur la « finition » et pas seulement sur le « démarrage » d'un projet.
• Réduire les durées d'occupation des travaux en cours.
• Arrêtez d'attendre les spécifications détaillées de chaque exigence jusqu'à ce que l'équipe soit prête à mettre en œuvre les efforts (ce ne sera alors pas une cause perdue).

2. Processus supplémentaires

Tout processus ajouté ou documentation non lue qui ne transmet pas de valeur pratique et prolonge inutilement le calendrier ou la réalisation du marché du produit est un gaspillage.

Cependant, les politiques commerciales imposent souvent de tels documents, avec une paperasserie considérable mais jamais lue. Ces efforts sont extravagants.

Exemples typiques :

• Documentation inutilement détaillée.
• Gestion supplémentaire ou planification sans exécution.

Comment le réduire ?

Les organisations peuvent faire la différence entre ce qui est une cause/un effort perdu et ce qui apporte de la valeur à la table, l'accent doit être mis sur la production de résultats significatifs et canaliser les efforts pour faire plus de travail de « qualité » en limitant le travail de « quantité ».

3. Fonctionnalités supplémentaires

Toute fonctionnalité ou fonctionnalité de faible valeur ajoutée pour/par le client mais non demandée/ne contribuant pas à l'augmentation des revenus est un gaspillage d'efforts.

Les entreprises commettent cette erreur de développement lorsqu'elles ajoutent des fonctionnalités qui ne seront pas beaucoup utilisées ou exercées ; cette nouvelle fonctionnalité reste en effet inactive et augmente la complexité de l'application.

La règle du logiciel 80/20 joue un rôle important : 80 % des utilisateurs n'utilisent que 20 % de ses fonctionnalités. Par conséquent, l'accent devrait être mis sur la qualité de ces 20 % de fonctionnalités afin de fidéliser les utilisateurs existants.

Les codes supplémentaires ont leurs inconvénients :

• Augmente la complexité de l'application.
• Peut créer un point de plantage potentiel de l'application.
• Nécessite des efforts ultérieurs inutiles dans le suivi et la maintenance tout au long du cycle de vie du produit.

Comment réduire ces déchets ?
Concentrez-vous sur le développement itératif, ce qui signifie que lors de la version initiale du produit, créez des fonctionnalités principales robustes qui définissent l'USP de votre application.

Concentrez-vous sur sa fonctionnalité et validez l'apprentissage de l'évolution continue du produit. De plus, continuez à créer des fonctionnalités appropriées en fonction de votre analyse de marché, du comportement des consommateurs et des commentaires.

4. Changement de tâche

Affecter des personnes à plusieurs tâches lorsqu'elles ne sont pas à l'aise avec cela et entrave leur processus existant peut prendre une grande partie de leurs journées. Le moyen le plus efficace de terminer une ou deux tâches spécifiques est d'en terminer une à la fois.

Lors du passage d'une tâche à l'autre, il y a un petit coût de temps pour fermer celle existante et donner de l'élan à l'autre, c'est ce qu'on appelle un changement de contexte, et si vous vous attendez à une transition constante de l'une à l'autre, ces changements de contenu s'accumulent, ce qui retarde le "résultat" ou "délai de livraison".

Comment le réduire ?

Simple-Une chose à la fois.

• Réduisez le changement de contenu.
• Minimisez les interruptions ou les distractions.
• Reportez celles qui ne sont pas importantes.
• Allouez les ressources comme un projet à la fois.

5. Attente/Retards

Les dépendances d'approbation doivent être chronométrées principalement pendant la feuille de route du produit ; si un intervalle de temps spécifique n'est pas alloué, soyez prêt pour des réponses et des commentaires différés. Les retards empêchent également le consommateur de se rendre compte de la valeur réelle du produit. Mais, en tant que développeurs ou concepteurs, vous devez attendre l'approbation du travail effectué ; ainsi, vous ne pouvez pas éviter complètement le laps de temps.

Que pouvez-vous faire pour réduire cela ?

• Choisissez/attribuez quelque chose en attendant les commentaires existants.
• Prévoyez du temps pour la saisie et la révision.
• Envisagez des appels rapides, des conversations en face à face plutôt que d'envoyer les modifications par e-mail.
• Rétroaction régulière.

6. Mouvement

Si des équipes de développement ou de recherche ont été éparpillées avec des informations acquises et ne les ont pas marquées/étiquetées de manière appropriée, cela peut prendre une éternité pour dissiper la confusion et l'abandon. Si des informations sont égarées à chaque fois qu'un livrable est remis ; cela entravera considérablement les résultats.

Comment le réduire ?

• Étiquetez les devoirs ou les ressources acquises.
• Réduisez les délais de rétroaction.
• Collaborations en face à face.

7. Défaut

Quantité de déchets causés par le défaut = (Impact du défaut) x (Temps pendant lequel il n'est pas détecté)

En raison de sa complexité, le développement de logiciels crée des défauts inévitables, mais le problème se pose lorsqu'ils sont prolongés dans l'exécution et la fixation ou que le coût encouru dans la fixation ou le retravail a un impact. De plus, des erreurs de code et des bogues majeurs peuvent potentiellement affecter et entraver l'ensemble du cycle de vie du produit et le rendre vulnérable aux menaces de sécurité, entraînant des millions de pertes de revenus.

Que pouvez-vous faire pour réduire cela ?

• Essais immédiats.
• Intégration constante.
• Test du produit et publié dès que possible.