Je ne sais pas si vous le jugeriez élégant, mais Watts Humphrey a écrit un livre entier intitulé Personal Software Process qui était tout au sujet de la mesure de votre propre productivité. Il a décrit les paramètres des entrées comme le temps passé à votre bureau par rapport aux interruptions, le temps passé à travailler sur différents types d'activités du cycle de vie du logiciel, les défauts par quantité de code. Il y a un rapport technique qui donne la version courte à:
http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm
Si vous voulez regarder quelque chose comme la qualité d'un code de développeur, Chidamber & Kemerer a proposé plusieurs mesures pour le code orienté objet.
Mesures pour le code orienté objet
- profondeur de l'arbre d'héritage,
- nombre pondéré de méthodes,
- nombre de fonctions membres,
- nombre d'enfants, et
- couplage entre objets.
En utilisant une base de code, ils ont essayé de corréler ces mesures à la densité de défauts et à l'effort de maintenance en utilisant une analyse covariante. Des études ultérieures ont fait une analyse similaire sur des centaines de projets Java Source Forge pour déterminer leurs caractéristiques par rapport aux métriques CK et certaines métriques supplémentaires proposées plus tard.
Mesures générées dans le contexte des révisions de code
Les défauts peuvent être classés selon de nombreux critères:
- gravité: (majeure, mineure, cosmétique, enquête / inconnue),
- type (logique, faute de frappe, orthographe, violation de la norme de codage, etc.),
- confinement origine / phase (exigences, conception, code, etc.).
Il existe également des taux de préparation et d'inspection (temps par réviseur, temps par ligne de code) et des densités de défauts (par KLOC (milliers de lignes de code), par minute de temps d'inspecteur / réviseur).
Le traçage de ces valeurs par rapport aux cartes de contrôle peut nous montrer si nous sommes dans les limites du processus (par exemple, une équipe qui inspecte 200 lignes de code qui ne trouve aucun défaut dans un groupe qui compte en moyenne vingt-cinq défauts par KLOC pourrait être défectueuse).
Autres métriques
D'autres paramètres qui pourraient aider à inclure ceux pour
Limites de l'analyse
Il existe d'énormes limites sur la valeur des mesures. Les bogues corrigés par développeur peuvent signifier presque n'importe quoi, et lorsque vous commencez à punir ou à récompenser cette mesure, je parie que les bogues deviendront plus nombreux et granulaires, et le mélange de bogues difficiles à faciles corrigés changera également au fur et à mesure que l'équipe choisira la cerise dans le courir pour avoir le plus.
Il y a aussi une certaine distraction et potentiellement une perte de concentration et de plaisir qui peuvent survenir avec une mesure intrusive. Vous ne pouvez pas devenir beaucoup plus élégant (et émotionnellement chargé) qu'un poète du lac comme Wordsworth qui a dit:
Sweet is the lore which Nature brings;
Our meddling intellect
Mis-shapes the beauteous forms of things:--
We murder to dissect.
Bien que les logiciels ne soient pas exactement de la nature, donnez-moi une certaine latitude car je pensais que je n'aurais jamais pu utiliser quoi que ce soit du cours de littérature anglaise du secondaire.
L'agilité peut être considérée comme une réaction à un gros processus centralisé. Parfois, ce mode de travail pouvait nécessiter tellement d'efforts analytiques que la capacité à atteindre le débit lors de la création de logiciels avait pratiquement disparu.