Paramètres de développement de logiciels et rapports

la chose clé au sujet des mesures est de savoir ce que vous utilisez pour. Les utilisez-vous comme un outil d'amélioration, un outil de récompense, un outil de punition, etc. On dirait que vous prévoyez de les utiliser comme un outil d'amélioration.

le principe numéro un lors de l'établissement de mesures est de garder l'information pertinente afin que la personne qui la reçoit puisse l'utiliser pour prendre une décision. Très probablement, un cadre supérieur ne peut pas dicter le micro-niveau de si vous avez besoin plus de tests, moins de complexité, etc. Mais un chef d'équipe qui peut le faire.

par conséquent, je ne crois pas qu'une mesure de couverture de code va être utile à la gestion au-delà de l'équipe individuelle. Au niveau macro, l'organisation est probablement intéressée par:

• coût de livraison
• delivery timely of delivery
• étendue de la livraison et qualité externe

interne la qualité ne sera pas élevé sur leur liste de choses à couvrir. C'est la mission d'une équipe de développement de préciser que la qualité interne (maintenabilité, couverture des tests, code d'auto-documentation, etc.) est un facteur clé dans la réalisation des trois autres.

par conséquent, vous devriez cibler les mesures à des cadres supérieurs qui couvrent ces trois tels que:

• vitesse globale (il est à noter que la comparaison de la vitesse entre équipes est souvent artificielle)
• portée prévue et réelle atteinte dans les délais convenus
• nombre de défauts de production (éventuellement par habitant)

et de mesurer des choses comme la couverture de code, la complexité de code, coup 'n' paste score (code répétition en utilisant flay ou similaire), la longueur de la méthode, etc au niveau de l'équipe où les destinataires de l'information peut vraiment faire une différence.

une métrique est une façon de répondre à une question sur un projet, une équipe ou une entreprise. Avant de commencer à chercher les réponses, vous devez décider quelles questions vous voulez poser.

questions typiques comprennent:

• Quelle est la qualité de notre code?

• est l'amélioration de la qualité ou dégradant au fil du temps?

• comment productif est le de l'équipe? Est-il améliorer ou dégradants?

• quelle est l'efficacité de nos tests?

• ...et ainsi de suite.

chaque question nécessite un ensemble différent de paramètres pour répondre. Recueillir des mesures sans savoir quelles questions vous voulez des réponses est au mieux une perte de temps et au pire contre-productif.

Vous devez également être conscients qu'il est un "principe d'incertitude" au travail-à moins d'être très prudent, la collecte de mesures modifiera le comportement des gens, souvent de manière inattendue et parfois préjudiciable. Cela est particulièrement vrai si les gens croient qu'ils sont évalués sur les paramètres, ou pire encore, ont les paramètres liés à un système de récompense ou de punition.

je recommande la lecture de Gerald Weinberg de la Qualité des Logiciels de Gestion de Vol 2: Première Commande de Mesure . Il va il explique que le plus important est souvent ce qu'il appelle "la mesure D'ordre zéro", c'est - à-dire demander aux gens leur opinion sur la façon dont un projet se déroule. Les quatre volumes de la série sont chers et difficiles à obtenir, mais ils en valent la peine.

Logiciel d'écriture

• que faut-il optimiser?

CPU(s), mémoire(s) de l'utilisation, de la mémoire cache(s) d'utilisation, l'utilisateur utilisation du temps, la taille du code au moment de l'exécution, la taille des données au moment de l'exécution, la performance graphique, les performances d'accès aux fichiers, accès réseau, les performances, l'utilisation de la bande passante, le code de la concision et de lisibilité, l'utilisation de l'électricité, (comte de) distinctes appels d'API utilisées, (comte de) distincts des méthodes et des algorithmes utilisés, peut-être plus.

• combien faut-il optimiser?

il doit être optimisé le minimum raisonnable (sauf dans les domaines où le dépassement des critères d'acceptation est souhaitable) requis pour réussir les tests d'acceptation, faciliter la maintenance, faciliter la vérification et répondre aux exigences de l'utilisateur.

("... pour l'entrée légale / illégale de données d'essai et d'événements d'essai légaux/illégaux dans tous les États d'essai à toutes les données d'essai requises volumes et volumes de demande de test pour tous les scénarios d'intégration de test actuels et futurs.")

• pourquoi le montant minimum raisonnable?

parce que le code optimisé est plus difficile à écrire et coûte donc plus cher.

• quel leadership est requis?

normes de codage, structure de base, critères d'acceptation et conseils sur les niveaux d'optimisation requis.

Comment mesurer le succès de l'écriture logicielle?

• coût
• Temps
• Réussite à l'essai de réception
• mesure dans laquelle les essais de réception qu'il est souhaitable de dépasser sont dépassés
• approbation de l'utilisateur
• facilité d'entretien
• facilité de vérification
• degré d'absence de sur-optimisation

Quel coût/moment ne devrait pas être pris en compte dans l'évaluation de la performance globale de programmeurs ?

• perte de temps et de coûts en raison des changements apportés aux exigences (y compris l'architecture)
• coût/temps supplémentaire encouru en raison de lacunes dans les plates-formes/outils

mais ce coût / temps devrait être inclus dans l'évaluation performances globales de l' équipes (inc architectes, gestionnaires).

Comment mesurer le succès des architectes?

autres mesures plus:

• les cas d '"évitement précoce" sont affectés par des lacunes dans les plates-formes/outils
• degré d'absence de changements dans l'architecture

C'est un peu une note en marge de la question principale, mais j'ai eu une expérience très similaire à Paul Stephensons réponse ci-dessus. Une chose que je voudrais ajouter à cela concerne la collecte de données et la visibilité des mesures.

dans notre cas, le directeur du développement était censé rassembler un tas de données provenant de divers systèmes disparates et distribuer des résultats métriques individuels une fois par mois. Cela ne se produisait pas souvent, car cela prenait beaucoup de temps et il était très occupé.

Les résultats de ce programme sont:

1. développeurs mécontents, car les primes de performance étaient basées sur des mesures et les gens ne savaient pas comment ils s'en sortaient.

2. saisie de données dans différents systèmes.

si vous empruntez cette voie, vous devez vous assurer que toutes les données métriques peuvent être rassemblées. automatiquement et est facilement visible pour ceux qu'elle affecte.

une des approches intéressantes qui fait actuellement l'objet d'une certaine publicité est Kanban . Il est assez Agile. Ce qui est particulièrement intéressant, c'est qu'il permet une métrique de "travail fait" d'être appliquée. Je ne l'ai pas encore utilisé/rencontré dans la pratique réelle, mais je voudrais travailler à obtenir un flux kanban-ish allant à mon travail.

comme je l'ai dit dans Quelle est la fascination avec les mesures de code? , voici les statistiques:

• populations différentes , ce qui signifie que la portée de l'intérêt n'est pas la même pour le promoteur ou pour le gestionnaire
• trends toute mesure en elle-même est dénuée de sens sans sa tendance associée, afin de prendre la décision d'agir sur elle ou de l'ignorer.

nous utilisons un outil capable de fournir:

• beaucoup de micro-système de mesure de niveau (intéressant pour les développeurs), avec des tendances.
• beaucoup de règles avec multi-niveaux (de l'INTERFACE utilisateur, de Données, de Code) analyse statique des capacités
• lots de règles d'agrégation (ce qui signifie que ces nombreux paramètres sont condensés en plusieurs domaines d'intérêts, adéquat pour un niveau de population plus élevé)

Le résultat est une analyse qui peut être percé en bas, de haut niveau d'agrégation domaines (sécurité, architecture, pratiques, de la documentation ...) tout le chemin vers le bas pour quelques lignes de code.

Le retour de courant est:

• les gestionnaires de projet peuvent se défendre très rapidement lorsque certaines règles ne sont pas respectées et faire leur note globale significativement plus faible.
  
  Chaque étude doit être adaptée à chaque projet de bizarreries.
  
  L'avantage est la définition d'un contrat où les exceptions sont reconnus, mais des règles à respecter sont définis.
• les niveaux supérieurs (Département Informatique, partie prenante) utilisent les notes globales comme un élément de leur évaluation des progrès réalisés.
  
  Ils examineront de plus près d'autres éléments. basé sur les cycles de livraison: Combien de fois pouvons-nous itérer et mettre une application en production?, combien d'erreurs avons-nous eu à résoudre avant cette version? (en termes de fusions, ou en termes d'environnement de pré-production pas correctement mis en place), quelles rétroactions immédiates sont générées par une nouvelle version d'une application?

:

quelles mesures sont utiles à quelles parties prenantes, et à quel niveau d'agrégation

à haut niveau:

• les mesures (d'analyse statique) sont en fait le résultat d'agrégations métriques de bas niveau, et organisées par domaines.
• D'autres mesures (suite) orienté vers l'exploitation ", basé sur le cycle de libération de l'application, et non juste sur l'analyse statique du code) sont prises en compte
• le ROI réel est atteint par d'autres actions (comme six-sigma études)

au niveau inférieur:

• l'analyse statique est assez (mais doit englober multi-niveaux des applications, avec parfois multi-langues de l'évolution)
• les actions sont pilotées par les tendances et l'importance
• l'étude doit être approuvée / appuyée par tous les niveaux hiérarchiques pour être acceptée/appliquée (en particulier, le budget pour le remaniement qui s'ensuit doit être validé)

si vous avez un bagage/des connaissances maigres, alors je suggérerais le système que Mary Poppendieck recommande (que j'ai déjà mentionné dans cette réponse précédente ). Ce système est basé sur trois mesures holistiques qui doivent être prises comme un tout:

1. Durée du Cycle
   • du concept du produit à la première version ou
   • de la requête principale à la requête principale déploiement ou
   • de la détection de bogue à la résolution
2. Business Case Realization ( sans cela, tout le reste n'est pas pertinent )
   • P & L or
   • ROI or
   • objectif d'investissement
3. Satisfaction De La Clientèle
   • p.ex. Score net du promoteur

le niveau d'agrégation est produit/projet et je crois que ces mesures sont utiles pour tout le monde (les développeurs ne doivent jamais oublier qu'ils n'écrivent pas de code pour le plaisir, ils écrivent du code pour créer de la valeur et doivent toujours garder cela à l'esprit).

peuvent utiliser (et utilisent effectivement) des mesures techniques pour mesurer la conformité aux normes de qualité qui sont intégrées dans la Définition de Fait (comme "pas d'augmentation de la dette technique"). Mais la haute qualité n'est pas une fin en soi, c'est juste un moyen d'atteindre cycle court (pour être une entreprise rapide) qui est la véritable cible (avec la réalisation de L'analyse de rentabilisation et la Satisfaction du client).

fait intéressant, je viens de terminer la lecture PeopleWare , et les auteurs découragent fortement les mesures individuelles étant rendu visible aux supérieurs (même les gestionnaires directs), mais que les mesures agrégées devrait être très visible.

en ce qui concerne les mesures spécifiques au code, je pense qu'il est bon pour une équipe de connaître l'état du code à l'heure actuelle, et de connaître les tendances affectant le code à mesure qu'il mûrit et grandit.

la question n'est évidemment pas axée sur .NET, mais je pense que le produit .NET NDepend a fait beaucoup de travail pour définir et documenter des mesures communes qui sont utiles.

la section de la documentation sur les mesures est éducative lire, même si vous ne faites pas .NET.

les mesures de logiciel ont été avec nous pendant une longue période Et comme meilleur I ne peux rien dire à ce jour a émergé individuellement ou collectivement c'est capable d'Orienter les projets pendant le développement. L'écrou de le problème est que nous voulons utiliser les mesures objectives et ces peut seulement mesurer ce qui est arrivé, pas ce qui se passe ou va se produire.

au moment où nous avons mesuré, analysé et interprété certains série de paramètres nous réagissons à des choses qui avoir déjà mal parti, ou très occasionnellement, bien parti. Je ne veux pas sous-estimer l'importance d'apprendre de des données objectives mais je ne veux soulignez qu'il s'agit d'une réponse réactive et non proactive.

L'élaboration d'un "indice de confiance" pourrait être une meilleure façon de surveiller que le projet soit sur la bonne voie ou qu'il se dirige vers des problèmes. Essayer le développement d'un système de vote où un nombre raisonnable de des représentants de chaque domaine d'intérêt du projet sont invités anonyme de vote leur la confiance de temps. La confiance est votée dans deux domaines: 1) les choses sont sur la bonne voie 2) les choses continueront d'être sur la bonne voie de retour sur la piste. Il s'agit de mesures purement subjectives prises par les personnes les plus proches de la "action." Introduisez les résultats dans un graphique de type Kanban où les colonnes représentent les sections de vote et vous devrait avoir une assez bonne idée de l'endroit où concentrer votre attention. Utiliser question 1 évaluer si la direction a réagi cycle de vote précédent de manière appropriée. Utilisez la question 2 pour identifier où la direction devrait se concentrer ensuite.

cette idée est basée sur chacun de nous ayant un niveau de confort au sein de notre propre domaine de responsabilité. Notre niveau de confiance est un produit de l'expérience, des connaissances au sein de notre domaine d'expertise, le nombre et la gravité des problèmes de nous sommes confrontés, la quantité de temps que nous avons pour accomplir notre des tâches, la qualité de l'information, nous travaillons avec et tout un tas d'autres facteurs.

MBWA (Management By La marche Autour) est souvent présenté comme l' l'un des outils les plus efficaces que nous avons - c'est une variante de celle-ci.

cette technique n'est pas très utilisée au niveau de équipes individuelles parce qu'elle ne reflète que l'humeur générale de l'équipe. Un peu comme utiliser la montre de quelqu'un pour leur dire temps. Toutefois, aux niveaux supérieurs de la direction, elle devrait: être très instructif.