Comment intégrer des métriques objectives dans les performances de l'équipe de développement d'applications (et pourquoi vous voudriez)

De nombreux cadres supérieurs qui ont traversé une transformation d'une organisation de développement de logiciels traditionnelle à une organisation avec des équipes Agile auto-organisées, comprendre qu'il s'agissait d'un exercice nécessaire pour s'assurer que la valeur est délivrée plus rapidement à leur environnement commercial en constante évolution. Où la survie des entreprises est souvent le résultat direct de la fourniture de nouvelles fonctionnalités utilisateur plus rapidement que la concurrence, ces managers sont généralement contents d'avoir vécu ça, mais ils reconnaissent également que l'adoption d'une méthode de travail Agile n'est pas une solution miracle ou une garantie de succès.

”Bien que le concept d'équipes auto-organisées sonne bien, ils doivent encore être gérés dans le contexte de l'ensemble de l'organisation, sa mission, vision et stratégie.”

La haute direction doit prendre des décisions concernant les budgets, investissements, recrutement, Que faire, et quoi ne pas faire. Ils doivent décider des orientations stratégiques, les cibles et les objectifs, le modèle opérationnel mais aussi suivre les progrès et apporter des corrections si nécessaire.

Ce que nous voyons sur le marché, c'est que les organisations ont du mal avec ce dernier, et cela est dû en grande partie à un manque d'informations de gestion objectives. De nombreuses équipes Agiles utilisent des métriques de progression qui ont du sens dans leur équipe, mais qui ne peuvent pas être agrégées en informations de gestion utiles. pourtant, il est important de comprendre la performance des équipes Agiles, car ils apportent de la valeur à l'entreprise et à ses clients. Nous constatons que les entreprises opèrent à différents niveaux de maturité en ce qui concerne le contrôle qu'elles ont sur leurs équipes de développement d'applications. La question est: à quel niveau de maturité se situe votre entreprise?

Un modèle bien connu pour examiner la maturité des processus est l'intégration du modèle de maturité des capacités. (CMMi) modèle. Ce modèle évalue les processus de développement sur 5 différents niveaux (voir figure).

Niveaux de maturité CMMi
La source: https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

C'est un bon principe et peut également être utilisé pour évaluer le contrôle sur les équipes de développement Agile. Le modèle de maturité du contrôle agile (ACMM), sur la base des niveaux CMMi, permet à la haute direction de comprendre le niveau de contrôle de leurs équipes agiles et la valeur qu'elles apportent. Le tableau suivant montre comment IDC Metri considère les différents niveaux de maturité du contrôle Agile.

Faibles niveaux de maturité (0, 1 et 2)

La plupart des organisations sont actuellement au niveau 0 ou 1. Ils ont traversé la transformation, et les CIO et autres cadres supérieurs ont reçu des conseils de coachs Agile et d'autres consultants sur la façon dont ils devraient gérer la nouvelle organisation où les équipes auto-organisées ont beaucoup de pouvoir pour décider, et le métier travaille très étroitement avec les équipes pour créer de la valeur. pourtant, au niveau 0 ou 1, vous n'avez aucune idée de la valeur créée pour le budget dépensé, et comment cela se rapporte à la concurrence. Par ailleurs, la prévisibilité est faible et il est difficile de gérer les interdépendances entre les équipes et de prévoir quand certains logiciels seront prêts. Les équipes externes sont engagées en fonction du temps et des matériaux (taux horaires) et non basé sur la sortie (rapport qualité prix maximum).

Niveaux de maturité élevés (3, 4 et 5)

Au fur et à mesure qu'une organisation atteint un niveau de maturité plus élevé, la haute direction prend de plus en plus le contrôle. Les métriques objectives sont affichées dans des tableaux de bord à jour, leur permettant de prendre des décisions fondées sur des faits. Cela apporte de nombreux avantages, comme par exemple:

  • La capacité de démontrer aux parties prenantes que vous (le CIO et le cadre supérieur) est maître de la performance et de la création de valeur des équipes Agiles.
  • Concentrez-vous sur la création de valeur réelle en améliorant la productivité et la rapidité de livraison, tout en améliorant la qualité du produit.
  • Des mesures objectives sont utilisées pour comprendre quelles sont les équipes les plus performantes et quelles sont les équipes les moins performantes. Ensuite, les raisons pour lesquelles cela peut être étudiée et des actions d'amélioration peuvent être menées.
  • La précision de l'estimation des coûts logiciels s'améliore considérablement, car les données de l'organisation et des équipes peuvent être utilisées pour calibrer les modèles paramétriques.
  • Les indicateurs avancés se traduisent par une prévisibilité accrue des équipes, éliminer les retards de calendrier ou de coûts.
  • Basé sur des mesures objectives et une suppression ciblée des violations critiques, le risque dans le portefeuille d'applications diminue considérablement tandis que la qualité, la maintenabilité et les niveaux de coûts s'améliorent.
  • Les métriques basées sur les résultats peuvent être utilisées dans la contractualisation des équipes Agile, permettant aux organisations de sélectionner l'équipe qui offre le meilleur rapport qualité-prix (productivité multipliée par le taux moyen) au lieu du moins cher qui peut ne pas être productif du tout.

Et il y a bien d'autres avantages.

Dans la figure suivante, les améliorations de productivité typiques que nous avons observées sont présentées, où 0% est la moyenne du marché pour des équipes/applications comparables.

Être une fonction coûteuse, Les équipes de développement agiles doivent être gérées pour s'assurer que la valeur est optimisée pour l'investissement. Mais, comment mesurer la valeur? Lorsque les responsables informatiques sont aux prises avec ce défi commun, IDC Metri a préparé une check-list pour vous aider à piloter et mesurer la performance de vos équipes. Cliquez ici pour télécharger la check-list.

 

Harold Heeringen – Consultant principalHarold Heeringen

Harold van Heeringen est diplômé de l'université de Groningue (les Pays-Bas) en économie d'entreprise en 1997 après quoi il a travaillé pour le fournisseur de services informatiques Sogeti pendant 17 ans en tant que consultant senior métriques logicielles/estimation des coûts logiciels. Dans 2015, il a rejoint le fournisseur de services de conseil en sourcing et de benchmarking Metri, où il travaille en tant que consultant principal et chef de pratique pour les services d'intelligence informatique, y compris Estimation & Services de mesure de la performance et de gestion agile de la valeur. En plus de travailler chez IDC Metri, il est actif dans plusieurs organisations à but non lucratif actives dans cet espace. Harold a été président de l'International Software Benchmarking Standards Group à but non lucratif (ISBSG) de 2011 jusqu'à 2019 et est toujours administrateur actif du conseil d'administration. Harold est également membre du conseil d'administration de Nesma, l'organisation internationale spécialisée dans la mesure de la taille fonctionnelle et l'estimation des coûts. À Nesma, il est responsable des partenariats internationaux et de la coopération. Harold est l'un des délégués Nesma dans l'équipe qui a créé le corpus de connaissances sur l'estimation des coûts logiciels (SCEBoK). Harold publie régulièrement des livres blancs, blogs et articles sur les métriques logicielles, estimation du coût, gestion agile de la valeur, mesure du rendement, analyse comparative et sujets connexes.