Les grands projets logiciels sont difficiles
Les grands projets logiciels sont souvent retardés, dépassent leurs budgets et, dans certains cas, échouent complètement. Il est difficile de les réussir. Si un projet est respecté dans les délais, dans les limites du budget, entièrement fonctionnel et d'une qualité satisfaisante, il est considéré comme réussi. Ce type de succès est rarement obtenu. Un flux constant de nouvelles techniques et méthodologies offre l’espoir de résoudre les anciens problèmes. Et pourtant, les problèmes liés aux projets logiciels ne semblent pas disparaître. La plupart de ces nouvelles techniques renforcent le mystère entourant le développement de logiciels, ce qui alimente à son tour une industrie non réglementée de « coachs agiles ». Les dirigeants sont souvent frustrés de constater que, malgré l'utilisation de certaines de ces nouvelles techniques, bon nombre de leurs projets informatiques dépassent toujours le budget ou échouent. Je vais montrer que quatre mesures suffisent pour résoudre ce problème.
Métriques agiles valides
La prévisibilité des projets peut-elle être améliorée ? Les longues périodes de correction des bugs peuvent-elles être évitées ? Peut-il y avoir une meilleure façon ? Est-ce possible sans plonger dans les détails techniques ? OUI!
Je vais vous montrer qu'en utilisant ces quatre mesures, vous pouvez améliorer la base des décisions de projet, accroître la transparence de l'avancement du projet et réduire les taux d'échec des projets. Ces mesures peuvent également être facilement comprises par les dirigeants non techniques. J'ai passé 30 ans dans l'informatique, examiné des centaines de projets logiciels et appris beaucoup auprès d'autres experts. J'ai conclu que la plupart des organisations pourraient connaître plus de succès en utilisant seulement quatre indicateurs simples.
Tout d’abord, il est important d’utiliser valide métrique. De nombreuses mesures inappropriées sont fréquemment promues, telles que le comptage des lignes de code, les points d'histoire et la taille des t-shirts, mais celles-ci conduisent généralement à de mauvaises décisions de gestion, car les mesures sur lesquelles les décisions sont basées ne sont pas fiables. Pour réussir, vous devrez baser vos décisions sur des mesures valides, cohérentes, universelles et injouables ; et quatre suffisent.
Avec seulement ces quatre indicateurs, vous pouvez avoir une idée de la portée, des ressources, du calendrier et de la qualité. Leur utilisation contribuera également à réduire certains risques courants liés aux projets logiciels. Vous aurez bientôt la réputation de mener à bien des projets logiciels.
Ces quatre mesures contribueront grandement à aider les responsables informatiques à garantir que leurs projets sont livrés avec succès, quelles que soient les techniques qu'ils adoptent (agile, agile à l'échelle, kanban, cascade). Pour tout type de logiciel (application métier, améliorations, maintenance, logiciel système, systèmes embarqués), se concentrer uniquement sur ces quatre indicateurs fonctionne vraiment :
1. Portée
La taille n'est pas tout ce qui compte dans un logiciel, mais c'est le cas. le facteur le plus important sur des projets logiciels. Quelle est réellement la taille de votre projet ? Vous avez besoin d'une mesure cohérente avant de commencer (pour l'estimation), pendant le projet (pour le contrôle) et après (pour l'analyse comparative). Mesurer la taille est possible. Cela peut être fait en utilisant la mesure standard d'ingénierie (ISO) universellement applicable, valide, cohérente et ouverte pour la taille du logiciel. COSMIQUE points de fonction. La première métrique est donc :
Métrique #1 : taille fonctionnelle en points de fonction COSMIC (CFP)
2. Productivité
À quelle vitesse créons-nous le logiciel ? Aurons-nous fini à temps ? Si nous connaissons la taille et surveillons le résultat fourni par mois (ou par sprint), nous pouvons prédire si nous sommes sur la bonne voie.
Métrique #2 : CFP livré par mois
3. Qualité
S'il y a trop de bugs, nous ne pouvons pas publier le logiciel, nous devons donc garder une trace de la qualité tout au long. Comment vérifions-nous la qualité au fur et à mesure de notre développement ?
Métrique #3 : Défauts (trouvés et créés) par CFP
4. Ressources
Combien cela coûtera-t-il ? De combien de personnel technique aurons-nous besoin ?
Métrique #4 : Coût par CFP
Ce n’est pas tout ce qu’il faut faire pour gérer des logiciels. Il existe de nombreux autres facteurs importants qui influencent ces mesures, tels que : les conditions de travail, les outils, le soutien de la direction, la complexité, la confiance de l'équipe, la collaboration et la compétence du personnel. Néanmoins, en se concentrant uniquement sur ces quatre indicateurs, les responsables techniques et non techniques de toute organisation peuvent augmenter le taux de réussite de leurs projets.
Dans la plupart des cas, il est également utile de suivre certaines mesures connexes, telles que :
- Changement de périmètre en cours de projet en CFP.
- Potentiels de défauts par CFP et tests par CFP.
- Défauts trouvés par heure de test unique
- Défauts corrigés vs défauts trouvés chaque mois/sprint.
- ROI ajusté au risque
COSMIC Function Points – La norme moderne de génie logiciel pour les logiciels de mesure
Au cœur de cette recommandation se trouve la mesure de la taille en points de fonction COSMIC. Consultez notre introduction au CFP. Compter les CFP est une compétence qui peut être acquise en quelques jours. La documentation standard est ouverte, le manuel est téléchargeable gratuitement et est disponible sur https://www.cosmic-sizing.org. Il existe même un examen de certification pour garantir que vous mesurez correctement. Pour ceux qui souhaitent raccourcir et accélérer le processus, une estimation CFP peut être générée automatiquement à partir des exigences en utilisant ScopeMaster.
Si vous souhaitez en savoir plus sur la manière de gérer plus efficacement les projets logiciels et d'utiliser ces métriques efficacement, veuillez entrer en contact.
Résumé
Voici un récapitulatif de ces quatre indicateurs clés pour gérer des projets logiciels réussis :
- Portée: Taille fonctionnelle en points de fonction COSMIC (CFP)
- Productivité: CFP livré par mois
- Qualité: Défauts (trouvés et créés) par CFP
- Ressources: Coût par CFP
Colin Hammond est consultant en assurance de projet et créateur du premier analyseur au monde d'exigences logicielles pour l'assurance qualité et l'estimation automatisées. https:///www.scopemaster.com
Mesures agiles utiles supplémentaires
Qualité
- Mesures de complexité du code (McCabe)
- Couverture des tests unitaires
- Fréquence de déploiement
- Taux de correction des défauts
- Défauts trouvés et corrigés à chaque étape
Portée
- CFP affecté par des exigences de performance non fonctionnelles
- Changement de périmètre par mois (% du total CFP)
Indicateurs pour les leaders non techniques
La plupart des mesures logicielles ne conviennent pas aux dirigeants non techniques. On ne peut pas s'attendre à ce que le directeur financier comprenne la terminologie et les nuances des taux de couverture des tests agiles à grande échelle, basés sur les risques, les niveaux de complexité du code, les points d'histoire, les tailles de t-shirts, etc. Pourtant, l'ensemble de la salle de conseil doit être capable d'avoir une conversation sur les logiciels. investissement qu’ils peuvent tous comprendre. Ce qu’il faut, c’est un ensemble universel et valable de mesures qui informent de manière fiable les dirigeants non techniques. Je présenterai seulement quatre mesures valides qui peuvent fournir un langage commun aux dirigeants à utiliser dans le contexte des décisions d'investissement en logiciels et qui contribueront à une plus grande réussite des projets.
