Simple Science

La science de pointe expliquée simplement

# Informatique# Génie logiciel

Mesurer le gâchis dans le développement logiciel

Cette étude traite des déchets dans le développement logiciel et propose des stratégies de mesure.

― 9 min lire


Le gaspillage dans leLe gaspillage dans ledéveloppement logicielaméliorer l'efficacité.Analyser et quantifier les déchets pour
Table des matières

Le développement de logiciels, c’est avant tout créer des logiciels qui marchent bien, répondent aux besoins des utilisateurs et sont faciles à entretenir. Cependant, durant le processus de développement, il y a des activités ou étapes qui n’aident pas vraiment à améliorer le produit final. Ces activités gaspillent du temps, des efforts et des ressources. Ce gaspillage peut arriver pour plein de raisons, comme construire les mauvaises fonctionnalités, une mauvaise communication ou des processus inefficaces. Si on ne s’en occupe pas, ça peut entraîner des problèmes comme une productivité ralentie et des délais manqués.

Réduire ce gaspillage est super important pour améliorer le fonctionnement des équipes, réduire les coûts, et s'assurer que les projets se terminent à temps. Par exemple, dans un gros projet bancaire où plusieurs équipes bossent sur différentes parties, si une équipe crée une fonctionnalité qui ne répond pas aux besoins du projet, ça peut causer pas mal de soucis. Cette fonctionnalité pourrait devoir être réécrite, ce qui fait perdre du temps et peut retarder tout le projet. Donc, identifier et éliminer le gaspillage dans le développement de logiciels est vraiment crucial pour une livraison réussie.

L’essor des logiciels open-source

De plus en plus d’entreprises choisissent les logiciels open-source (OSS) plutôt que les logiciels propriétaires parce que l’OSS est souvent perçu comme de meilleure qualité et plus innovant. Au fur et à mesure que l'utilisation de l'OSS grandit, il est aussi essentiel de regarder le gaspillage qui peut se produire dans ces projets. Savoir mesurer ce gaspillage est clé pour maintenir des pratiques de développement efficaces.

Ce document se concentre sur la compréhension des types de gaspillage dans le développement de logiciels, comment les mesurer, et regarde spécifiquement les projets OSS. En analysant les pratiques actuelles pour mesurer le gaspillage et identifier les lacunes, on peut proposer de nouvelles mesures qui aideront à calculer le gaspillage dans le développement de logiciels.

Questions de recherche

Pour guider l’étude, on a établi trois questions principales :

  1. Quels sont les différents types de gaspillage dans le développement de logiciels ?
  2. Comment peut-on mesurer ces types de gaspillage ?
  3. À quelle fréquence le gaspillage dans le développement de logiciels se produit-il dans les projets open-source ?

Répondre à ces questions donnera une vue plus claire du gaspillage dans le développement de logiciels et aidera à trouver des moyens d'améliorer les processus.

Types de gaspillage dans le développement de logiciels

Beaucoup d'études ont exploré le gaspillage dans le développement de logiciels et identifié plusieurs types. Les types courants incluent :

  • Construire la mauvaise fonctionnalité : Créer des fonctionnalités dont les utilisateurs n’ont pas besoin ou qui ne correspondent pas aux objectifs du projet.
  • Rework : Avoir à refaire du travail à cause d’erreurs ou de changements dans les exigences.
  • Temps d’attente : Retards causés par l'attente de retours ou d'approbations.
  • Communication inefficace : Malentendus ou manque d'informations claires entre les membres de l'équipe.
  • Travail partiellement terminé : Tâches commencées mais jamais finies.

En plus de ceux-là, d'autres gaspillages incluent des problèmes de gestion, une complexité inutile, et une mauvaise gestion du backlog.

Mesurer le gaspillage dans le développement de logiciels

Bien qu'on reconnaisse les divers types de gaspillage, beaucoup d'organisations n'ont pas de moyens formels pour le mesurer. Souvent, elles utilisent des indicateurs de productivité comme la vélocité (combien de travail est fait dans un temps donné). Il existe aussi des méthodes comme les diagrammes de flux cumulatif pour visualiser les progrès et identifier les lacunes dans le processus.

Cependant, mesurer le gaspillage directement permet d’apporter des améliorations plus spécifiques. Cette étude met en avant de nouvelles mesures pour quantifier le gaspillage, surtout dans les projets open-source.

Mesures proposées pour le gaspillage dans le développement de logiciels

Cette étude propose plusieurs nouvelles métriques pour aider à quantifier le gaspillage dans le développement de logiciels. Voici quelques-unes :

Forks obsolètes

Dans les projets open-source, un fork, c’est quand quelqu'un crée une copie d'un dépôt pour faire des changements ou ajouter des fonctionnalités. Un fork obsolète est celui qui ne contribue rien de précieux au projet original. En classant les forks en actifs, de secours, potentiellement obsolètes et obsolètes, on peut identifier quelles parties du projet ne sont pas utilisées efficacement.

Indice de diversification du projet

Cette mesure examine comment les forks contribuent au projet principal par rapport à ceux qui partent dans leur propre direction. Cet indice aide à identifier si les organisations construisent les mauvaises fonctionnalités ou explorent des chemins non liés.

Taux de rejet des demandes de tirage (Pull Request)

Les demandes de tirage (PR) sont des moyens pour les développeurs de suggérer des changements à un projet. Le taux de rejet des PR indique combien d’efforts passent à la trappe et aide à identifier les domaines où le processus de développement pourrait avoir besoin d'être amélioré. Si beaucoup de PR sont rejetées, ça suggère qu’il pourrait y avoir des problèmes de gestion ou de communication des contributions.

Indice d'inversion du backlog

Une bonne gestion du backlog est clé pour s'assurer que les tâches prioritaires sont terminées à temps. L’indice d'inversion du backlog suit les situations où des tâches de moindre priorité sont terminées avant celles de plus haute priorité, ce qui indique une mauvaise gestion des priorités et des ressources.

Taux de satisfaction des fonctionnalités

Ce taux évalue comment l’équipe livre à la fois des fonctionnalités et corrige des bugs. Il compare le nombre de fonctionnalités complétées au nombre de bugs résolus et aide à comprendre comment le projet est géré.

Mise en place de l'étude

Pour analyser ces mesures, l'étude a utilisé l'API GitHub pour rassembler des données de divers projets open-source. Au début, la recherche s'est concentrée uniquement sur les dépôts très populaires mais a ensuite été ajustée pour inclure ceux ayant au moins 50 000 étoiles afin de garantir une sélection représentative de projets actifs.

Critères de sélection

Seuls les projets qui ont été poussés au début de 2024, avaient des problèmes, des téléchargements, et existaient depuis un certain temps ont été sélectionnés. Certains types de projets comme les dépôts archivés ou modèles ont été exclus pour garder le focus sur les projets actifs.

Sélection des dépôts

Un total de dix dépôts a été choisi en fonction de leur popularité et de leur niveau d'activité. Ces projets représentent collectivement une variété de pratiques courantes dans le développement de logiciels open-source.

Résultats et observations

Les résultats de l'application des mesures proposées sur les projets open-source sélectionnés ont apporté des aperçus précieux sur la prévalence du gaspillage dans le développement de logiciels et l’efficacité des pratiques de gestion.

Distribution des forks obsolètes

Analyser la distribution des forks obsolètes à travers les projets a montré un mélange de contributions actives et inactives. Un plus grand nombre de forks actifs indique généralement un projet sain où les développeurs sont engagés, tandis que beaucoup de forks obsolètes peuvent signaler un potentiel de gaspillage.

Résultats de l’indice de diversification du projet

Les projets ont été examinés pour voir combien de forks contribuaient directement au projet principal par rapport à ceux qui divergeaient. Un indice de diversité élevé a montré que beaucoup de forks allaient dans différentes directions, ce qui peut indiquer un désalignement avec les objectifs du projet.

Analyse du taux de rejet des PR

L'analyse des demandes de tirage a révélé que plusieurs projets avaient du mal avec des taux de rejet élevés, ce qui suggère que des lignes directrices plus claires et une meilleure communication pourraient améliorer la qualité globale des contributions.

Aperçus de l'indice d'inversion du backlog

Les mesures d'inversion du backlog ont montré que certains projets avaient des problèmes significatifs de priorisation, indiquant un besoin de meilleure gestion pour s'assurer que les tâches les plus prioritaires sont traitées rapidement.

Évaluation du taux de satisfaction des fonctionnalités

Évaluer comment les projets équilibrent la correction des bugs avec la livraison de nouvelles fonctionnalités a donné des aperçus sur leur efficacité opérationnelle. Les projets avec des taux de satisfaction faibles avaient tendance à avoir plus de problèmes de backlog et de mauvaise gestion des tâches.

Conclusion et recommandations

Cette étude souligne l'importance d'identifier et de mesurer le gaspillage dans le développement de logiciels. En introduisant de nouvelles mesures, les équipes peuvent obtenir de meilleures idées sur leurs processus et prendre des mesures pour améliorer leur efficacité.

Stratégies d'adoption

Pour aider les équipes à adopter ces mesures, on recommande différentes stratégies en fonction de l'état du projet.

  • Pour les projets terminés : Des revues rétrospectives devraient examiner toutes les mesures pour fournir des aperçus sur ce qui s'est bien passé et ce qui pourrait être amélioré.

  • Pour les projets en cours : Suivre en continu les mesures aidera à identifier les tendances et les domaines qui nécessitent de l'attention avant que cela ne devienne de plus gros problèmes.

  • Pour les projets planifiés : Établir des pratiques de mesure tôt peut aider à fixer des repères et des objectifs qui guident le projet depuis le début.

Limitations

Bien que mesurer le gaspillage puisse apporter des aperçus précieux, il y a des défis. L'accès aux données de dépôt est essentiel. Si ces données ne sont pas maintenues ou disponibles, les mesures pourraient être trompeuses. De plus, la variété des projets pourrait entraîner des résultats différents, ce qui pourrait affecter la validité des conclusions.

Travaux futurs

À l'avenir, il est nécessaire d'élargir ces mesures pour couvrir plus de types de gaspillage dans le développement de logiciels et de collaborer avec des professionnels de l'industrie pour évaluer l'impact de ces métriques dans des projets réels. Cela peut aider à améliorer les pratiques de développement de logiciels et à assurer la livraison dans les délais des projets.

Source originale

Titre: Measuring Software Development Waste in Open-Source Software Projects

Résumé: Software Development Waste (SDW) is defined as any resource-consuming activity that does not add value to the client or the organization developing the software. SDW impacts the overall efficiency and productivity of a software project as the scale and size of the project grows. Although engineering leaders usually put in effort to minimize waste, the lack of definitive measures to track and manage SDW is a cause of concern. To address this gap, we propose five measures, namely Stale Forks, Project Diversification Index, PR Rejection Rate, Backlog Inversion Index, and Feature Fulfillment Rate to potentially identify unused artifacts, building the wrong feature/product, mismanagement of backlog types of SDW. We apply these measures on ten open-source projects and share our observations to apply them in practice for managing SDW.

Auteurs: Dhiraj SM Varanasi, Divij D, Sai Anirudh Karre, Y Raghu Reddy

Dernière mise à jour: Sep 27, 2024

Langue: English

Source URL: https://arxiv.org/abs/2409.19107

Source PDF: https://arxiv.org/pdf/2409.19107

Licence: https://creativecommons.org/licenses/by/4.0/

Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.

Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.

Articles similaires