Estimation des coûts logiciels dans la gestion de projet agile

introduction

L'une des choses les plus difficiles à faire dans le développement de logiciels est de déterminer combien de temps et combien il faudra pour livrer un nouveau produit logiciel. Cela devrait-il être si difficile ? La réponse n'est pas simple.

L'estimation des coûts des logiciels est intrinsèquement difficile et les humains sont terriblement mauvais pour prédire les résultats absolus. Il n'y a pas deux projets identiques ; chacun est unique dans ce qu'il se propose d'accomplir et unique dans la myriade de paramètres qui forment son existence. Souvent, ce qui semble être un problème simple en surface est beaucoup plus difficile ou techniquement difficile à mettre en œuvre dans la réalité. Et, sans aucun doute, il y aura des "inconnues" avec le projet qui ne pourront être identifiées que lorsqu'elles se présenteront.

De plus, il n'y a pas deux personnes identiques, que vous soyez un client, un développeur ou un utilisateur. Nous venons préchargés avec notre propre ensemble de connaissances, d'expériences, de valeurs, d'attentes, d'attitude face au risque et de capacité d'adaptation.

L'écriture de logiciels de bonne qualité est le pain quotidien des ingénieurs seniors. créer des produits logiciels géniaux peut être une entreprise beaucoup plus difficile, pour toutes les personnes impliquées.

Mais lorsqu'il s'agit de logiciels, la compréhension de la durée et du coût est essentielle pour prendre des décisions commerciales stratégiques et cela est vrai que vous créiez une startup, réalisiez une nouvelle opportunité commerciale ou permettiez à votre entreprise de mieux performer. Le timing, le retour sur investissement et les avantages fournis peuvent faire, ébranler ou défaire votre entreprise. Vous vous demanderez : Qu'obtenons-nous pour notre argent ? Pouvons-nous prévoir nos coûts ? Combien coûtera la création du produit que nous voulons ? Quand pouvons-nous lancer ? Aurons-nous un produit de qualité pour notre investissement ? Va-t-il grandir avec notre entreprise ? Cela apportera-t-il de la valeur commerciale ?

Alors, comment procédez-vous pour estimer la taille, la durée et le coût d'un projet ? Explorons l'estimation des projets Agile et les coûts de développement de logiciels, et comment nous le faisons chez Toptal.

Tarification et estimation des contrats traditionnels

Traditionnellement, en utilisant des pratiques non Agiles, les projets logiciels ont cherché à fixer les fonctionnalités ou la portée et à laisser le temps et le coût être une variable. Cela pose des problèmes :

1. Comment savez-vous que la fonctionnalité que vous fixez au début d'un projet est vraiment la fonctionnalité qui sert le mieux votre entreprise ou vos clients ? Le plus souvent, la fonctionnalité ou la portée changeront, c'est pourquoi nous entendons parler de « glissement de portée », le résultat des besoins souhaités identifiés tout au long du cycle de vie d'un projet et déterminés comme nécessaires ou obligatoires

2. Lorsque le coût devient une variable, nous perdons le contrôle du retour sur investissement (ROI) que nous cherchons à atteindre. L'augmentation des coûts est souvent le produit de risques non identifiés ou d'exigences changeantes, ce qui signifie que nous devons ajouter des membres à l'équipe pour effectuer plus de travail dans le même laps de temps ou garder les membres de l'équipe plus longtemps. Ni l'un ni l'autre n'est souhaitable

3. Lorsque le temps est une variable, nous perdons le contrôle de la position sur notre marché. Peut-être que nous manquons une date importante pour l'industrie ou que nos concurrents sortent leur produit avant nous, perdant ainsi tout avantage concurrentiel que notre projet aurait pu avoir.

Il existe de nombreux autres résultats de temps et de coût variables, qui sont souvent négatifs et indésirables.

Bien sûr, de nombreux clients et organisations cherchent à réparer les trois composants de ce « triangle magique ». Malheureusement, c'est presque impossible à réaliser de manière réaliste. Il y a trop d'éléments qui concourent à perturber cet idéal, qui aboutissent finalement à des produits qui ne répondent pas à un besoin, mettent trop de temps à profiter à ses clients ou coûtent trop cher pour réaliser une valeur commerciale.

Contrats agiles pour les projets logiciels

Le coût est un produit du temps et des personnes (membres de l'équipe). Ajoutez plus de temps, et vous ajoutez des coûts pour employer des personnes plus longtemps. Ajoutez plus de membres à l'équipe et vous augmentez le coût pour offrir la même valeur commerciale. Les choses que nous voulons vraiment éviter. C'est pourquoi les principes Agile croient qu'il faut fixer le temps et les membres de l'équipe et permettre à la portée d'être la composante variable.

Qu'est-ce qui sonne le mieux et augmente la confiance des parties prenantes, le coût fixe ou le coût variable ?

Bien entendu, il est important qu'un produit tienne ses promesses et réponde aux besoins de ses clients. Il ne sert à rien de dépenser un temps et une somme d'argent exacts si, en fin de compte, vous avez un produit que personne ne veut ou ne peut utiliser efficacement.

Les contrats Agile se concentrent donc sur les éléments suivants :

• Forfaits de travail à prix fixe - L'ensemble du projet est divisé en "mini" versions logiques qui contribuent au résultat complet du produit. Chaque version est un package de travail dont le prix est fixé en conséquence. Au fur et à mesure qu'un lot de travaux est terminé, les futurs lots de travaux sont réestimés en fonction de ce que nous avons appris du précédent. Cela évite les contingences inutiles et permet de définir un niveau de re-priorisation et de fonctionnalités nouvelles/révisées par le client.

• Résiliation anticipée - Cela permet au client de chercher à mettre fin au projet plus tôt si une quantité suffisante du produit a été livrée et qu'il n'y a pas de retour sur investissement supplémentaire à réaliser en conservant une équipe de projet qui ne continuera à générer que des gains marginaux. Cette clause est généralement autorisée à tout moment et est valable tant que l'équipe de projet et le client ont maintenu une relation de collaboration étroite, de confiance et de travail. L'avantage pour le client est que le projet se terminera plus tôt, ayant fourni toutes les fonctionnalités précieuses nécessaires pour rendre le produit viable. En retour, le fournisseur reçoit 20 % de la valeur restante du contrat et compense le risque de fidélisation du personnel.

• Changements flexibles - Le changement est un thème très présent dans les veines de la livraison de logiciels Agile. Nous nous attendons à ne pas savoir tout ce dont nous avons besoin pour faire d'un produit un succès dès le départ. Nous encourageons donc le changement, sur la base de données et de commentaires pertinents, pour nous assurer que le bon produit est livré. À la fin d'une itération, les modifications peuvent être remplacées par d'anciennes fonctionnalités qui ne sont plus jugées nécessaires ou prioritaires. Tant que le changement est de valeur égale, il n'y a pas de coût supplémentaire. Si le changement est de valeur inférieure, un travail supplémentaire peut être identifié ou extrait de l'arriéré restant. Cette clause est valable tant que l'équipe de projet et le client ont maintenu une relation de collaboration étroite, de confiance et de travail tout au long du projet.

• Travail supplémentaire - Tout au long de la vie d'un projet, d'autres fonctionnalités peuvent être identifiées qui ne seraient pas réalisables dans le cadre du contrat à prix fixe existant. Pour ce scénario, soit des lots de travaux supplémentaires nouvellement tarifés peuvent être ajoutés à la fin du projet, soit revenir au temps et aux matériaux.

• Estimations échelonnées - Il existe deux manières d'échelonner les estimations dans un contrat de projet Agile : une plage de durée ou une plage de fonctionnalités. Une plage de durée permet d'estimer que le projet ou le lot de travaux prendra 12 à 16 semaines pour un ensemble de portée donné. Cependant, l'ajout de durée augmente les coûts car vous gardez les membres de l'équipe de projet plus longtemps, ou cela signifie qu'ils ne peuvent pas être libérés pour travailler sur d'autres projets de développement. Chez Toptal, nous préférons répartir les fonctionnalités sur une gamme de points d'histoire, en gardant la portée comme variable mais en promettant de fournir un niveau minimum de valeur au client dans le délai fixé du lot de travaux ou du projet global.

Il convient de rappeler que vous pouvez toujours ajouter plus de portée plus tard. Vous avez peut-être commencé à générer des revenus, vous avez augmenté le nombre d'utilisateurs ou réduit les coûts. Quoi qu'il en soit, il est beaucoup plus facile de demander plus d'argent et de temps si vous avez déjà démontré un retour ou une amélioration et que vous apportez une valeur commerciale.

Notre approche des coûts et de la tarification des logiciels

Chez Toptal, nous travaillons en étroite collaboration avec nos clients et nos ingénieurs pour utiliser des techniques qui favorisent la confiance des parties prenantes dans la durée et les coûts du projet. Nous nous efforçons d'élaborer et d'adapter en permanence la planification d'un niveau initial élevé jusqu'à des détails plus granulaires lorsque cela est approprié et nécessaire pour éviter le gaspillage et permettre un changement géré.

Les étapes suivantes sont suivies dans l'élaboration d'un devis et d'un projet au forfait :

1. Portée initiale de haut niveau

Au début d'un projet, nous en savons moins sur son résultat final. C'est une folie d'imaginer qu'il est possible de savoir exactement de quelles fonctionnalités nos clients et utilisateurs ont besoin dès le départ.

Donc, nous commençons avec une charte de projet et un ensemble de fonctionnalités « épiques » de haut niveau qui guident la direction du projet, sur la base d'une vision et d'objectifs solides.

une. Définition de la vision et des objectifs Que devons-nous construire ? Que devez-vous atteindre et quels sont vos objectifs commerciaux ? La compréhension de ces questions nous permet de fixer l'échelle du projet. Vous avez besoin d'un prototype pour tester une idée, un concept ou une technologie initiale ? Vous avez identifié une proposition claire qui a été testée sur votre marché et êtes-vous prêt à construire votre premier Produit Minimal Viable (MVP) ? Ou faites-vous évoluer votre entreprise ou votre produit existant pour le faire passer au niveau supérieur ?

b. Caractéristiques « épiques » de haut niveau Sans entrer dans trop de détails, vous souhaiterez définir les caractéristiques dont votre produit dispose pour répondre aux besoins de vos clients. Il s'agit d'une « liste de courses » structurée qui décrit les éléments nus de votre produit ; ceux-ci sont souvent appelés "User Stories" ou épopées

c. Analyse MoSCoW L'analyse MoSCoW est une technique qui, en termes simples, aide à identifier ce qui est vraiment nécessaire pour rendre le produit viable et ce qui est agréable à avoir. Ceux qui sont identifiés comme un "Must" satisfont ce qui encouragera les utilisateurs à s'engager et à adopter votre produit. Ces fonctionnalités identifiées comme « devraient » surprendront et raviront vos clients, mais pourraient être construites plus tard. Les éléments «pourraient» n'ajoutent souvent aucune valeur commerciale significative, peuvent ne pas augmenter le rendement et sont la plus basse de vos priorités. Les fonctionnalités "Won't" pourraient bien être importantes un jour mais sont hors de portée pour cette itération de projet. Cependant, les identifier maintenant peut aider à garder à l'esprit l'échelle et la taille potentielles du produit pour l'avenir.

2. Proposition

Pour prendre une décision sur l'opportunité d'aller de l'avant avec un projet, il est nécessaire de baser cette décision sur des données bien informées : coût et durée. Ce sont les minimums que vous devez vous poser : que faudra-t-il pour créer le produit que nous voulons ? Quand pouvons-nous lancer ? Cela correspond-il à notre stratégie commerciale et à nos finances ?

Avec les détails ci-dessus, nous sommes en mesure de fournir une proposition. Nos ingénieurs sont triés sur le volet pour les exigences spécifiques du projet et travaillent avec un chef de projet pour dériver au moins une solution technique, une durée estimée qui fournit la portée connue et un coût estimé pour mener à bien le projet.

Comme nous l'avons mentionné précédemment, au début d'un projet, nous savons moins ce qui sera livré. Nous gardons délibérément les fonctionnalités et la portée vagues, car faire autrement suggère que nous savons exactement ce qui est requis. Une estimation à ce stade serait la moins précise, mais donne des indications sur l'opportunité de poursuivre le projet.

La proposition est le premier outil d'élaboration de la durée et du coût d'un projet. Une fois qu'une proposition est acceptée, nous pouvons aller de l'avant pour fournir un devis à prix fixe.

3. Planification des versions

Le prochain niveau d'élaboration de l'estimation consiste à créer un plan de publication qui fournira une gamme de fonctionnalités dans un délai donné. Nous dérivons cela d'une liste de fonctionnalités, de la taille du projet, de la rapidité avec laquelle notre équipe peut développer un logiciel de qualité qui répond aux attentes d'un client et des techniques de gestion du risque d'incertitude.

une. Backlog de produit Le backlog de produit est simplement une liste ordonnée d'"Epics" ou de "User Stories" qui représente les fonctionnalités requises pour un produit. Cette liste commence sa vie comme les épopées discutées précédemment, mais entre l'équipe de projet assignée, le chef de projet et le client, nous les décomposons maintenant en éléments plus significatifs. Chacun des éléments représente une partie de la valeur commerciale pour le client. Nous n'entrons pas plus dans les détails à ce stade, nous n'avons pas besoin de connaître les critères d'acceptation, nous n'avons pas besoin de savoir si un bouton est bleu ou vert, nous avons juste besoin de savoir qu'il y a un bouton qui permet certaines tâches être réalisé.

b. Estimation Maintenant que nous avons notre liste de fonctionnalités décrites comme des histoires d'utilisateurs, l'équipe estime ces éléments discrets de fonctionnalités à l'aide d'une technique appelée "Planning Poker". Il s'agit d'une technique utile qui garantit des résultats rapides et fiables basés sur l'opinion d'experts et un dimensionnement analogue. Planning Poker attribue un nombre convenu à chaque élément représentant sa taille et sa complexité. C'est ce qu'on appelle un point d'histoire. D'autres techniques et tailles d'estimation Agile, telles que les "jours idéaux", sont disponibles.

La fin de ce processus déterminera la taille du projet et les dépendances entre les fonctionnalités. La taille est déterminée en additionnant tous les points d'histoire des éléments du backlog de produit. Si ce nombre est égal à 120, alors la taille de notre projet est de 120 points d'histoire.

c. Priorisation Maintenant que nous avons un carnet de commandes et une taille pour le projet, nous sommes en mesure de le prioriser avec le client. Il s'agit vraiment d'identifier ce qui est le plus précieux pour le client afin d'obtenir les résultats souhaités. L'élément en haut de la liste est considéré comme le plus important, le deuxième élément est moins important que le premier, et ainsi de suite dans la liste. Aucun élément ne peut être aussi important qu'un autre, la priorité de chaque élément a une importance ou une valeur relative par rapport à chacun des autres éléments.

Cette approche de la priorisation est une étape importante dans la planification d'un projet logiciel. Nous savons désormais ce qui est important pour le client et dans quel ordre réaliser les travaux, en prenant soin des dépendances, pour livrer un produit à la hauteur des attentes.

ré. Planification des versions À ce jour, nous avons déterminé ce que nous pensons être le produit et sa taille.

Maintenant, nous déterminons combien de temps il faudra pour livrer un produit libérable. Le client et l'équipe, y compris les concepteurs, les ingénieurs, les testeurs, le scrum master et le chef de projet, travaillent ensemble pour identifier ce qui peut être réalisé et la rapidité avec laquelle le travail peut être effectué pour créer un plan de publication.

Le plan de version donne également un aperçu de la façon dont le projet s'alignera sur les plans stratégiques d'un client.

Et enfin, ce plan garantit que l'équipe de projet a une lumière directrice qui ouvre la voie et définit un point final logique au développement.

Avant de commencer, nous nous assurons que nous comprenons la définition convenue de « terminé ». Il s'agit d'un ensemble donné de critères qu'un client acceptera comme complets et répond également à toutes les exigences techniques pour être considéré comme livrable.

Pour prendre un scénario de base, nous prenons le nombre total de points d'histoire que nous avons obtenus en dimensionnant notre carnet de commandes et le divisons par la vitesse anticipée de nos équipes. (La vélocité NB est normalement exprimée sous la forme d'une plage, mais pour plus de simplicité, nous utiliserons un seul nombre ici.) Nous travaillons par itérations de deux semaines afin que notre vélocité soit reflétée par ce que nous pouvons accomplir dans un cycle de deux semaines avec le disponible capacité de l'équipe. Si nos points d'histoire totalisaient 120 et que nous prévoyions de terminer 20 points par itération, la durée totale de développement serait de 12 semaines ou 6 itérations. Nous ajoutons à cela un sprint 0 de 2 semaines et un sprint de préparation de release de deux semaines. Au total, la durée de notre projet est de 16 semaines. Il existe des techniques que nous pouvons utiliser pour aider à créer un tampon de risque approprié dans notre planification, dont nous parlerons plus tard. Mais en bref, nous utilisons le tampon pour gérer le risque d'incertitude et parvenir à un accord minimum sur les points d'histoire attendus à livrer. Le résultat pourrait être une gamme de 90 à 150 points d'histoire livrés, 90 étant le minimum acceptable pour créer un produit viable.

Alternativement, si le projet doit être achevé à une date donnée, disons dans 10 semaines, l'équipe déterminera quelle quantité de l'arriéré peut être achevée dans ce délai. Si nous prévoyons 20 points d'histoire par sprint, plus le sprint 0 et un sprint de publication, nous viserons 60 points complétés d'ici la fin du projet. Encore une fois, nous chercherions à gérer le risque en ajoutant un tampon approprié, ce qui pourrait se traduire par un objectif de 45 à 75 points d'histoire terminés et prêts à être publiés. Les 45 points d'histoire s'aligneraient sur le minimum acceptable pour fournir un produit viable et précieux. Il s'agit d'un scénario dans lequel vous pourriez vous attendre à ajouter un membre de l'équipe pour augmenter la vitesse, le cas échéant.

Bien sûr, tout ce qui précède est soutenu par une communication et une collaboration de bonne qualité entre toutes les parties afin d'élaborer un plan de version réalisable, réaliste et acceptable pour le client.

4. Contrat à prix fixe

Une fois qu'un plan de livraison est convenu, nous sommes en mesure de créer un devis pour un contrat de projet à prix fixe. Comme mentionné précédemment, il est conseillé de garder la durée et l'équipe du projet fixes et la portée variable.

Le devis pour un contrat à prix fixe est livré avec un énoncé des travaux et un calendrier de paiement convenu.

Tant qu'il y a confiance, communication, collaboration et volonté d'entrer dans l'esprit d'un projet logiciel Agile, toutes les étapes ci-dessus nous permettent de fournir un devis avec un degré de confiance réaliste qu'un projet sera livré à temps et sur budget. Bien sûr, il y aura des occasions où un projet sera livré en avance ou en retard et nous traitons ces variations avec la plus grande transparence.

Techniques d'estimation

La planification et l'estimation agiles sont soutenues par un certain nombre de techniques qu'une équipe de développement peut utiliser pour gagner en confiance dans leur taille, leur effort, leur durée et leur coût. Voici quelques-uns de ceux que nos équipes utilisent pour estimer la taille et le coût d'un projet logiciel.

Estimation de la taille

La taille du projet est vraiment une appréciation de sa portée, de sa complexité, de ses dimensions, de son risque et de son ampleur. Pour utiliser une analogie, il s'agit de comprendre si nous construisons la Tour Eiffel ou la Grande Muraille de Chine. La tour Eiffel est une structure haute, lourde et complexe construite dans un environnement urbain serré. La Grande Muraille de Chine est une structure relativement simple, mais longue et solide, qui s'étend sur plusieurs kilomètres de terrain vallonné.

Bien qu'il s'agisse de grands projets à réaliser, leur portée, leur complexité, leurs dimensions, leur ampleur et donc leur taille sont différentes.

Il est important de gérer les attentes avec des estimations. Ce ne sont jamais des prédictions, des engagements ou des garanties. Lorsque nous discutons de la taille totale, de la durée totale et du coût total, nous travaillons toujours dans des fourchettes, afin d'atténuer les risques, l'incertitude et les inconnues.

Les histoires qui représentent les caractéristiques de votre produit sont dimensionnées et estimées individuellement à l'aide de points d'histoire ou de jours idéaux. Le nombre total de ces unités définit la taille totale du projet.

Points d'histoire

Les story points sont une unité de mesure qui exprime la taille globale d'une user story. La taille d'une histoire, lorsqu'elle est estimée, comprend tous les aspects de la conception, de l'ingénierie, des tests, de la révision du code, de l'intégration, etc.

Chaque taille d'un étage est relative à un autre étage. Ainsi, par exemple, l'histoire A peut être dimensionnée comme un point, l'histoire B comme deux points et l'histoire C comme trois points. Ici, l'étage C est au moins trois fois plus grand que l'étage A et au moins deux fois moins grand que l'étage B.

Si les histoires suivantes dans notre backlog de produit ont les tailles associées :

La taille totale du projet est de 12 points d'histoire.

Jours idéaux

Il s'agit d'une mesure de taille exprimée en jours. Il supprime le concept de frais généraux tels que les interruptions, les activités de planification agiles, la lecture des e-mails et d'autres activités hors projet. Il se concentre uniquement sur le temps qu'il faudrait si vous deviez travailler sur quelque chose en continu sans interruption, plutôt que sur le temps écoulé du début à la fin.

En règle générale, lors d'une estimation à un niveau élevé lorsque nous en savons le moins sur un projet, nous estimons en jours idéaux car il s'agit d'un concept plus facile à corréler avec l'histoire et l'expérience passées qu'un nombre abstrait tel qu'un point d'histoire. Surtout lorsque les histoires à un niveau élevé sont plus épiques dans la nature avec peu de détails et contenant éventuellement des éléments supplémentaires lorsqu'elles sont décomposées à une date ultérieure.

Lors d'une estimation à un niveau plus granulaire, disons une histoire dans un backlog de produit établi, l'une ou l'autre approche peut être utilisée et sera décidée par l'équipe d'ingénierie. Les deux approches présentent des avantages et chaque équipe aura sa préférence.

Techniques d'estimation

Estimations partagées Les estimations ne sont pas effectuées isolément. Ils sont exécutés en collaboration par toute l'équipe d'ingénierie et incluent la conception, la base de données, le serveur, l'interface utilisateur frontale, l'assurance qualité et d'autres experts interfonctionnels. Cela évite les problèmes de ne pas prendre en compte tous les aspects du travail nécessaire pour terminer une fonctionnalité et garantit que personne n'a le fardeau ou le malheur de surestimer ou de sous-estimer la taille d'une fonctionnalité. L'équipe combinée aura tous un point de vue qui pourra être discuté et convenu.

Estimations analogues C'est là que nous considérons deux caractéristiques discrètes et décidons que l'une est relativement plus petite ou plus grande que l'autre. Nous pouvons regarder une histoire donnée et convenir qu'elle est de petite taille, et si nous utilisons des points d'histoire, nous pourrions lui donner une taille de deux. Le prochain étage pourrait être considéré comme grand par rapport au premier, et nous lui donnerions une taille de cinq. Cela suggère qu'une grande est au moins deux fois la taille d'une petite entité.

Nous continuerions cet exercice avec toutes les histoires. Une fois terminé, nous pouvons alors disposer côte à côte toutes les petites, moyennes, grandes et très grandes histoires et recouper notre dimensionnement pour nous assurer qu'il y a un niveau d'uniformité dans notre estimation.

Planning Poker Beaucoup a été écrit sur le Planning Poker ; Je l'ai également mentionné dans mon blog précédent. L'une des meilleures ressources pour le comprendre est ici.

Essentiellement, il combine l'opinion d'experts, l'analogie et la collaboration d'équipe en un seul processus simple, rapide et fiable.

Il réunit plusieurs experts les plus aptes à construire un devis basé sur une expérience technique et métier, un dialogue animé et une justification solide.

Rapidité

La vélocité est une mesure de la capacité d'une équipe à faire le travail dans une itération (ou sprint) donnée.

Il est exprimé sous la forme d'une plage, par exemple, de 23 à 32 points d'histoire par sprint, en particulier au début de la vie d'un projet. Généralement, c'est parce qu'à moins que la même équipe n'ait déjà travaillé sur le même problème, il est difficile de décrire exactement quelle sera la vélocité de l'équipe. Remarquez, nous nous référons à la vélocité d'une équipe et non à celle d'un individu !

Nous utilisons la vélocité pour planifier nos versions et adapter nos plans et modules de travail au fur et à mesure que nous progressons dans un projet, ce qui nous permet d'ajuster nos prévisions d'achèvement régulièrement et avec précision tout au long de l'exécution.

Au départ, on est obligé de définir une plage de vélocité avec très peu de données. Nous pouvons utiliser des valeurs historiques si l'équipe et l'espace du problème sont les mêmes, ce qui est souvent le moins probable. Nous pouvons exécuter une itération pour avoir une idée de la vitesse d'une équipe travaillant réellement sur le projet, mais cela est coûteux et ne fonctionne pas si des décisions doivent encore être prises pour accepter de démarrer un projet. Ou, nous pouvons faire une prévision.

La prévision d'une vitesse implique de prendre la valeur d'un sprint d'histoires et de les diviser en tâches qui sont exécutées pour terminer l'histoire. Nous estimerions le nombre d'heures que chaque tâche prendra, ce qui comprend la conception, le développement, les tests, etc., et évaluerons la capacité de l'équipe dans un sprint donné. Une capacité de 70 % pour une équipe non encombrée est une bonne base de référence. Ainsi, dans une situation simple, si le nombre total d'heures disponibles pour l'équipe est :

• 4 membres de l'équipe * deux semaines * 40 heures par semaine = 320 heures
• Multiplié par notre capacité de 70 % = 224 heures
• Additionnez toutes les tâches de fonctionnalité et arrêtez de compter à 224
• Prenez toutes les fonctionnalités terminées, additionnez leurs points d'histoire et vous obtenez votre vélocité, disons 36
• Appliquez 20 % de chaque côté pour obtenir une plage du plus bas au plus haut, pour arriver à une vélocité estimée de 29 à 43 points d'histoire.

La vitesse varie généralement au cours des deux à quatre premières itérations, puis se stabilise dans une petite plage de points. Ainsi, là où notre fourchette initiale avant le sprint un était de 29 à 43, au sprint quatre, elle peut atteindre un plateau de 34 à 38. Cela nous donne alors une plus grande confiance dans la prévision de notre date d'achèvement finale.

Plans tampons pour le risque et l'incertitude

Tous les projets logiciels s'accompagnent d'un niveau d'incertitude. Cette incertitude diminue à mesure que nous avançons dans le projet et que nous en savons plus sur notre technologie, notre environnement, nos performances et les besoins du client et des utilisateurs.

Nous atténuons cette incertitude ou ce risque avec un tampon dans le calendrier, qui tient compte d'une marge d'erreur dans notre estimation et des inconnues que nous ne pouvons pas déterminer avant le début du développement.

En règle générale, il existe deux types de tampons : fonctionnalité et planification. Comme on définit souvent un prix fixe pour une date de livraison fixe, il est préférable d'utiliser le Feature buffer.

Cette approche nous donne une stratégie crédible d'atténuation des risques et donne au client confiance dans ce qu'il doit s'attendre à voir comme un résultat une fois le projet terminé.

Tampons de fonctionnalités

Avec un tampon de fonctionnalités, nous prévoyons que nous fournirons un ensemble donné de fonctionnalités, mais que nous compléterons idéalement un autre ensemble de fonctionnalités. Cela devrait refléter au moins l'ensemble de fonctionnalités minimum que le client considère nécessaire pour lancer un produit viable, mais davantage peut être livré dans les délais si toutes les diverses influences internes et externes le permettent.

Ainsi, un client peut décider que les fonctionnalités les plus prioritaires du backlog de produit, totalisant jusqu'à 100 points d'histoire, sont les plus importantes. Ils peuvent ensuite envisager des fonctionnalités supplémentaires qui ajoutent jusqu'à 30 points supplémentaires. L'équipe planifiera donc sur la base de la livraison de 130 points d'histoire, le minimum de 100 étant achevé à la fin de la date d'achèvement prévue pour le contrat à prix fixe donné.

Quelques réflexions finales

Agile peut être un concept très difficile à saisir et à adopter pleinement. Cela n'est pas moins vrai lorsqu'il s'agit de gérer des sujets sensibles tels que le prix, la portée et la durée. Malheureusement, je sais de première main que les clients exigeants veulent que tout soit réglé à l'avance et sont impatients de blâmer le fournisseur lorsque tout commence à se dégrader. De même, je connais des fournisseurs qui s'obstinent, deviennent insensibles et ne répondent pas aux besoins des clients. Adopter une voie Agile repose fondamentalement sur la confiance, de bonnes relations et une excellente communication. Celles-ci doivent être des valeurs détenues par les deux parties afin de maintenir un projet sain pour le bénéfice, la satisfaction et le succès égaux pour toutes les personnes impliquées. Garder un esprit ouvert et une attitude constructive envers la collaboration et la négociation est le meilleur moyen d'éviter que les relations ne tournent mal.

J'ai travaillé avec des clients qui avaient du mal à adopter la nature adaptative d'Agile et à renoncer à une attitude de commandement et de contrôle. C'est dur de lâcher prise et de mettre toute sa foi et sa confiance dans une équipe qu'on ne connaît pas. Souvent, les clients peuvent souhaiter créer toutes les exigences à l'avance en tant que spécification de ce qui sera livré. Cela leur donne un sentiment de confiance que la portée d'un projet est bien définie. Mais finalement, cela ne se concrétise pas comme une approche réussie. Si nous sommes limités à la portée et aux exigences irréalistes d'un contrat, les problèmes surgissent très rapidement.

Nous savons, en adoptant cette approche dans les méthodes traditionnelles, que la portée change, que des inconnues sont découvertes ou que ce que nous pensions que le client voulait n'est plus vrai ou loin de la vérité. Adopter une approche adaptative de la tarification, de la planification et de la portée permet aux clients d'identifier véritablement leur produit comme étant exactement ce dont leur marché a besoin. Cela permet à un fournisseur d'être réactif, imaginatif et efficace aussi. Exploiter la collaboration entre le client et le fournisseur lors de la négociation du contrat est essentiel.

Les fournisseurs doivent être honnêtes et les clients doivent être réalistes quant à ce qui peut être réalisé dès le départ. Un fournisseur qui promet des objectifs irréalistes et augmente ensuite les coûts peut remporter le contrat initial, mais perdra bientôt la faveur d'un client mécontent. Trop souvent, les relations se brisent en raison d'un manque de confiance entre les parties. La confiance doit être établie dès le départ et maintenue tout au long d'un projet. Un fournisseur doit être flexible et coopérer avec l'évolution des besoins. Les clients en veulent toujours plus ; c'est une conséquence naturelle de faire des affaires. Il doit y avoir un échange de valeur égal et bénéfique entre les deux parties. Quant aux clients, ils cherchent à créer de la valeur pour leur entreprise. Pour les fournisseurs, ils doivent chercher à créer de la valeur en établissant des relations durables avec les clients. Le respect des valeurs et des principes directeurs du Manifeste Agile est une base solide pour nouer des relations solides, équilibrées et durables.

Sommaire

J'espère que cela vous a donné un aperçu de la planification, de l'estimation et de la définition d'un prix pour un projet logiciel Agile. Toutes les approches et techniques ci-dessus sont conçues pour renforcer la confiance dans une équipe et pour renforcer la confiance dans l'esprit des clients quant au temps et à la quantité qu'il faudra pour créer un produit logiciel. Et en fin de compte, pour renforcer la confiance dans la prise de décision d'aller de l'avant.

Suivez ces directives et vous serez sûr de trouver un itinéraire satisfaisant pour donner vie à votre produit logiciel.