moyennes de l'industrie pour le temps consacré à l'entretien


17

Un manager a récemment annoncé qu'il passait beaucoup trop de temps à corriger des bugs. Je pense qu'il pense que nous devrions écrire du code parfait tout le temps (tout en respectant ces délais impossibles bien sûr!) Et cela m'a fait me demander quelle était la moyenne du temps passé par l'industrie à corriger les bogues v à écrire du nouveau code.

Quelqu'un a-t-il des mesures sur le temps passé à corriger les bogues contre le développement de nouveau code? Ou existe-t-il une analyse empirique du temps de correction des bogues pour l'industrie dans son ensemble? Est-ce que 50% des bogues dépensés sont trop réparés, ou à peu près? Que diriez-vous de 20% ou 33%?

Je suis heureux d'accepter des preuves anecdotiques issues d'une expérience personnelle, car cela ferait partie de certaines statistiques ici auxquelles je pourrais comparer nos performances.


9
votre manager semble très ignorant. Lecture suggérée pour des cas comme celui-ci: Faits et erreurs du génie logiciel par Robert L. Glass, en particulier "Fait 43. La maintenance est une solution, pas un problème." Un article de Wikipédia mentionne 80% des efforts consacrés à la maintenance des logiciels
GNAT

3
Quel est le vrai problème? Vous avez un problème de qualité? Votre processus est-il vraiment inefficace? Ou votre manager souhaite-t-il simplement que le logiciel ne coûte pas si cher?
kevin cline

@gnat: votre commentaire est la meilleure réponse
kevin cline

@kevincline thanks - commentaire converti en réponse
gnat

La maintenance ne consiste pas seulement à corriger des bugs (défauts) et son montant varie considérablement pour les projets individuels (= pas de réponse définitive). Il me semble que vous avez des problèmes de qualité.
MaR

Réponses:


13

Un manager a récemment annoncé qu'il passait beaucoup trop de temps à corriger des bugs.

Ci-dessus semble très ignorant. Lecture suggérée pour des cas comme celui-ci: Faits et erreurs du génie logiciel par Robert L. Glass, en particulier "Fait 43. La maintenance est une solution, pas un problème."

Un article de Wikipédia mentionne 80% des efforts consacrés à la maintenance des logiciels.

mon manager fait ressembler le PHB de Dilbert à un génie :)

Hm donné ci-dessus, je prendrais également des efforts pour analyser si toutes les demandes que vous faites sont des bogues .

D'après mon expérience, il était beaucoup trop fréquent que des demandes d'améliorations ou de nouvelles fonctionnalités soient soumises en tant que bogues. Les bons gestionnaires font participer leurs programmeurs à la découverte de cela - les mauvais gestionnaires, enfin, continuent de se plaindre de trop de temps à corriger les bogues .


2
Correction de bugs! = Maintenance! La correction de bogues signifie que vous avez codé des erreurs dans le système et qu'elles doivent être corrigées afin de restaurer une fonctionnalité correcte . Par maintenance, j'entendrais toutes les tâches telles que les corrections de bogues, les améliorations de l'évolutivité, la migration du matériel et les améliorations des performances, etc. Jusqu'à 40 à 50% des efforts consacrés à la maintenance semblent globalement raisonnables pour un système d'entreprise de taille moyenne.
Apoorv Khurasia

Avez-vous des chiffres pour les différentes classes de bogues? De toute évidence, si vous obtenez un grand nombre de bogues de haute priorité, "show stopper", il peut y avoir un cas où le processus de développement a besoin d'un peu de travail pour déterminer la source, mais si tout cela n'est pas si grave. Aussi, comme le dit gnat, beaucoup d'entre elles peuvent être des demandes d'amélioration.
Stevetech

Votre citation de l'article de wikipedia est fausse! Il dit que "80% des efforts de maintenance sont utilisés pour des actions non correctives" , mais il ne dit rien sur le temps de maintenance par rapport à la conception ou au codage ou à d'autres travaux.
Tobias Knauss

9

La première question à se poser est de savoir si votre "correction de bogue" corrige réellement des bogues de codage ou autre chose. La correction des bogues de code réels devrait être relativement faible dans la plupart des cas tant que vous avez une bonne base de code. Si vous travaillez avec une mauvaise base de code, une correction étendue des bogues est inévitable.

Cependant, au cours de la mise en production d'un programme, vous trouverez des exigences non documentées, une activité utilisateur inattendue, des anomalies de données, des incompatibilités matérielles, des problèmes d'installation et d'autres problèmes qui ne sont pas strictement des bogues de code. Souvent, les gestionnaires et les utilisateurs considéreront ces problèmes de support / maintenance de production comme des bogues car ils nécessitent généralement des modifications de code.

J'ai également rencontré des gestionnaires qui regroupaient ce qui aurait dû être qualifié de demandes d'amélioration mineures en tant que bogues. Souvent, ceux-ci sont entrés dans un système de suivi des bogues ou de rapport de problèmes et cela peut rendre vos statistiques de "bogues" plus élevées qu'elles ne le sont réellement.


Ce que vous décrivez est ce que nous avons, mais cela ne change rien :(
gbjbaanb

8

Cela dépend de la quantité de code dont vous disposez, de sa durée, etc.

Le temps consacré à la correction des bogues dans les logiciels devrait être chargé en amont sur les 6 à 12 premiers mois de publication, mais à mesure que le temps approche de l'infini, le temps consacré à la maintenance par rapport au temps consacré au développement initial dépassera 100% - c'est exactement ainsi que les choses travail.

Bien que je n'ai pas de statistiques précises (Code Complete le fait, mais je ne peux pas vous dire exactement quelle page / section), d'après mon expérience, environ 40% du développement (parfois jusqu'à 60%) est consacré à la maintenance. Il est évident que plus vous libérez de code, plus vous aurez de temps de maintenance. Les bogues ne sont pas toujours fonctionnels et résultent autant de l'incertitude que de défauts de programmation.


0

si vous utilisez un bon traqueur de billets (tel que Jira d'Atlasian) et que vous avez passé du temps à entrer toutes les différentes catégories, les histoires d'utilisateurs, les niveaux d'urgence correctement et avec l'accord de vos coéquipiers, puis à calculer ces métriques (et plus) sont incroyablement faciles.

Lors d'un projet précédent, nous avons utilisé Jira pour gérer nos listes de bogues / tâches / tâches, et à la fin, cela nous a montré que la principale cause de retards et de problèmes s'est avérée être des pratiques de gestion inefficaces.

Curieusement, lorsque ces informations ont été publiées, nous avons soudainement dit que nous n'utiliserions plus Jira et qu'un nouveau produit serait introduit pour le remplacer.

Entre-temps, toutes les demandes de transfert de données via Jira devaient être envoyées à l'équipe de gestion, et notre accès direct a été supprimé.

Ce qui n'a pas été remarqué, c'est que dans le cadre du calcul des statistiques, l'équipe de développement a demandé à Jira de piquer des données vers un crochet Web, et ce crochet Web a été utilisé pour transmettre des données à un point final sur certains serveurs internes, où nous avions du code qui a créé ces rapports automatiquement.

Nous avons commencé à surveiller le hook Web, et nous avons constaté que même si nous avons dit que Jira n'était plus utilisé, il est resté très longtemps en vie plus longtemps (plus de 6 mois pour être exact) et les abus massifs de la haute direction étaient tout simplement rampant avec une mauvaise utilisation.

Bien sûr, cela ne doit pas être quelque chose d'aussi complexe que Jira.

Si vous voulez une solution à faible rendement, vous pouvez utiliser une feuille de calcul google-docs et l'API de notification GDocs pour suivre les tâches / tickets / bugs / demandes de fonctionnalités, etc.

GDocs lui-même peut désormais publier des crochets Web et toutes sortes de choses.

Ajoutez à cela Git et / ou Github et certains hooks qui se déclenchent lorsque le code est validé dans votre référentiel, et vous avez un système de brassage domestique raisonnablement efficace, qui peut enregistrer une quantité surprenante de données.

En général, cependant, sur 100% de la durée de vie naturelle d'un produit, la répartition entre le développement et la maintenance est généralement de 20/80, la majeure partie du coût du cycle ALM (Application Lifetime Management) est absorbée par les coûts de maintenance et d'assistance.

Il n'y a rien de tel que de passer trop de temps à corriger les bogues, car il n'est tout simplement pas possible d'écrire du code sans bogue.

De bonnes politiques de test et d'intégration continue réduiront le défaut, mais vous ne l'éradiquerez jamais complètement.

Quiconque croit autrement (à mon humble avis) n'a pas suffisamment de connaissances pour porter un jugement précis ou est aveugle (le cas le plus courant) à quel point il est difficile d'écrire un logiciel.

Si votre manager est prêt pour cela, et certains le sont, alors vous voudrez peut-être lui suggérer de vous accompagner pendant une journée, afin qu'il puisse voir exactement ce que vous faites et comment vous le faites.

Iv'e a travaillé dans quelques entreprises où ce type de travail était activement encouragé, avec du personnel de niveau supérieur qui suivait du personnel de niveau inférieur, et vice versa, cela peut être une très bonne expérience d'apprentissage pour les deux parties impliquées.


2
"Il n'y a rien de tel que de passer trop de temps à corriger les bugs" - quelle charge de merde. Si vous passez suffisamment de temps à corriger des bogues que votre entreprise ne respecte pas parce qu'elle ne peut pas rester compétitive sur le marché (parce que vous corrigez des bogues plutôt que de faire des choses), vous passez trop de temps à corriger des bogues ...
Telastyn

Et l'alternative? - Vous ne passez pas assez de temps à corriger les bogues, et votre application se bloque, brûle et votre concurrent prend toutes vos habitudes, vous poussant efficacement hors du marché. L'astuce (et la partie la plus difficile de tout cela) est de trouver un équilibre acceptable.
shawty

1
Non, je suis d'accord, mais ce sont mes propres opinions qui s'expriment là-bas, parce que je crois vraiment en ces jours, l'art du bon débogage devient un art perdu. Nous sommes trop nombreux à nous fier beaucoup trop à des choses comme les tests unitaires, qui à mon humble avis fournissent trop de fausses sécurités. Je ne dis pas que le test unitaire devrait être aboli, mais je dis qu'il n'y a plus suffisamment de bonnes pratiques de débogage et de correction de bogues effectuées à cause de cela. C'est à son tour conduit les gestionnaires (comme décrit ci-dessus) à croire que la correction de bugs n'est pas nécessaire, et en conséquence, nous ne le faisons vraiment pas (encore une fois à mon humble avis).
shawty

2
les tests unitaires et le débogage sont différents arts utilisés pour différents problèmes. Bien que la résolution du problème «notre code est-il correct» prévienne-t-elle mieux le problème «pourquoi mon code est-il cassé»? Toutes choses étant égales par ailleurs, je préfère que les gens soient bons à faire du code correct plutôt qu'à identifier les causes profondes.
Telastyn

1
Maintenant, vous avez mon accord total sur ce point. C'est un triste fait que dans l'industrie d'aujourd'hui, de nombreux programmeurs ne le traitent que comme un autre travail de 9 à 5, où ils pointent, frappent le code jusqu'à l'heure du domicile et pointent. À l'époque, les développeurs étaient très fiers d'écrire du code bon, solide et bien testé et ont passé du temps à y réfléchir avant de s'approcher d'un clavier, vous en voyez très peu de nos jours.
shawty
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.