Donner des estimations pour des projets de grande envergure dans un environnement Agile.

Question

Mon entreprise vient d'obtenir sa première enquête sur un projet de développement à grande échelle et j'aimerais utiliser un processus Agile. Le client a une vision de l'application mais admet ouvertement avoir très peu d'exigences et reconnaît que nous devrons facturer à l'heure. Pour cette raison, je l'ai pratiquement convaincu d'adopter une approche Agile.

Le problème est qu'il veut un chiffre pour établir son budget. J'ai lu un certain nombre d'articles qui préconisent de ne pas renoncer à une estimation parce que le client va budgétiser ce chiffre et même si les exigences changent, le chiffre dans sa tête et dans les livres ne change pas.

J'ai lu qu'il y a plusieurs façons de prendre en compte la tarification dans le contrat, mais presque toutes (à l'exception d'une seule) intègrent un montant initial. Cela semble tout simplement violer l'ensemble des principes du développement Agile.

Ma question est donc la suivante : si vous êtes un atelier Agile, comment parvenez-vous à contourner ce cercle vicieux du développement Agile ?

Answer 1

Voici la question fondamentale.

Quand le client pensera-t-il qu'il a terminé ?

S'ils pensent avoir terminé en juin, alors vous mettez en place une équipe Agile. C'est 4-6 personnes pour 6 mois. C'est le budget. Essentiellement, vous faites la multiplication pour eux. équipe * taux * 6 mois.

S'ils pensent avoir terminé en grande partie en juin, mais qu'il y aura encore du travail par la suite, alors il est possible qu'il y ait 9 mois de travail. Encore une fois, vous ne faites que multiplier ce qu'ils pourraient faire eux-mêmes. équipe * taux * 9 mois.

S'ils pensent que vous serez leur équipe de développement dans un avenir proche, proposez-leur un prix qui leur permettra de mener à bien le projet jusqu'à la fin de l'année. équipe * tarif * 12 mois.

Puisque chaque version est une occasion de redéfinir les priorités, vous devez évaluer chaque version comme un travail distinct basé sur les éléments suivants sera être fait dans cette version. Puisque c'est leur schéma de priorité, ils contrôlent ce que vous construisez, ils contrôlent le budget, phase par phase.

Souvent, votre client veut vraiment savoir combien coûtera un ensemble de fonctionnalités particulier. Au lieu de demander cela, il demande le budget global (ce qui est stupide). Passez beaucoup de temps sur la première version pour montrer ce qu'ils obtiennent et combien cette première version coûtera.

Finalement, ils verront la vérité fondamentale.

Ils achètent les caractéristiques de la plus importante à la moins importante. . S'ils établissent correctement leurs priorités, ils peuvent arrêter de dépenser de l'argent à tout moment et avoir quelque chose d'utile.

Fait est un terme relatif. Certains projets sont "terminés" parce qu'il n'y a plus d'argent. D'autres sont terminés parce qu'il n'y a plus de temps. Il est rare (du moins dans le domaine du développement logiciel) qu'un projet soit terminé parce que nous n'avons plus rien à faire.

Answer 2

Dans ce cas, nous avons fourni une estimation pour la première partie du travail, puis nous avons laissé le client acheter d'autres sprints si nécessaire pour achever le travail au niveau souhaité.

Au fur et à mesure que vous développez le système et que vous intégrez le retour d'information du client dans les livrables du sprint, vous aurez tous deux une meilleure idée de la quantité de travail nécessaire, et donc des coûts impliqués.

Edit : Cool. Vraiment excellent ! Du fait que vous les avez convaincus d'une approche Agile, BTW bien joué !, il y a des chances que vous puissiez les convaincre de l'approcher d'un point de vue Agile en termes de fonctionnalités à mettre en œuvre. Peut-être que vous pouvez écouter ce " Introduction à Scrum podcast ". Vous pourrez peut-être les convaincre qu'ils n'auront probablement pas besoin de toutes les cloches et de tous les sifflets dont ils pensent avoir besoin pour le moment.

HTH

Santé,

Rob

Answer 3

Ecoutez, il y a un fait essentiel ici. On vous demandera d'estimer le coût, de conclure un contrat pour une date de livraison particulière et de vous engager à fournir un ensemble complet de fonctionnalités.

Vous ne pouvez pas faire les trois.

Pas "vous ne devriez pas" ou "il serait sage de ne pas" ; vous ne pouvez pas (à toutes fins pratiques). J'entends par là que la probabilité de réussir à faire les trois est extrêmement faible.

La meilleure réponse est de s'engager sur un coût et un calendrier, ainsi que sur un processus itératif avec des itérations rapides et un retour d'information régulier, puis de rédiger l'accord de manière à ce que ce qui est prévu dans l'accord ne puisse pas être modifié. fait sous le coût fixe et le calendrier est ce qui sera livré. Autrement dit, vous continuez à livrer de nouvelles fonctionnalités (et des modifications) jusqu'à ce que le temps et l'argent soient épuisés.

La vérité est que, même si vous do si vous vous inscrivez aux trois, le mieux que vous puissiez faire, c'est deux sur trois de toute façon. Autant être ouvert à ce sujet.

Answer 4

Voici comment un vieil entrepreneur du gouvernement que je connais l'a dit récemment : "Comme disent les prostituées, il faut d'abord les faire monter."

Cela ne répond pas à votre question, mais il est bon de s'en souvenir. S'ils refusent de monter sans numéro à l'avance (et ils ne le feront pas), vous devez leur donner un numéro.

Toute personne parrainant un projet de logiciel doit avoir une idée du type de retour sur investissement qu'elle va obtenir, afin de pouvoir évaluer si l'investissement en vaut la peine ou non. Un projet peut valoir la peine d'être réalisé s'il coûte 1 million de dollars et prend 12 mois. Il peut ne pas en valoir la peine s'il coûte 2 millions de dollars et prend 24 mois.

La vraie question est la suivante : pouvez-vous réaliser ce projet dans un délai et un budget qui permettent au client de réaliser un retour sur investissement approprié ? Si votre réponse à cette question est autre que "oui", le client ne devrait pas vous engager pour réaliser le projet. Sinon, il ne fait que dépenser de l'argent et lancer les dés.

Si votre réponse actuelle à cette question est "nous ne savons pas encore", alors ils ne devraient pas vous engager pour réaliser ce projet. Mais cela ne signifie pas qu'ils ne doivent pas vous engager pour savoir si le projet vaut la peine d'être réalisé. Un bon terme à la mode dans les cabinets de conseil pour cela est "exercice préliminaire de délimitation de la portée".

Le développement agile consiste à gérer une courbe en trois dimensions : l'argent dépensé, le temps de calendrier et l'ensemble des fonctionnalités. Il est évident que si le budget et le calendrier sont fixes, le jeu de fonctionnalités doit être variable. Vous ne pouvez pas savoir ce que el l'ensemble final de caractéristiques sera, compte tenu de ces contraintes. Mais vous puede savoir si a L'ensemble des fonctionnalités que vous serez en mesure de produire dans le cadre de ces contraintes se situe dans une fourchette que votre client jugera acceptable.

Vous pouvez le savoir, et vous pouvez le découvrir. C'est une chose que votre entreprise peut faire et que votre client ne peut pas faire. C'est un service que vous pouvez leur fournir et pour lequel ils devraient vous payer. Évitez la tentation de le faire gratuitement et de l'appeler un coût des ventes. Le cadrage d'un projet fait tout autant partie des services professionnels que le développement de logiciels. Vous ne faites pas cela pour conclure une vente, mais pour aider votre client à prendre une décision commerciale qu'il n'a pas encore suffisamment d'informations pour prendre.

Mais d'abord, tu dois les faire monter à l'étage.

Answer 5

Ces réponses sont vraiment excellentes. Je n'ai pas beaucoup d'expérience à partager, mais j'ai pensé à une analogie :

L'année dernière, ma femme et moi avons rénové notre cuisine. L'entrepreneur nous a proposé de facturer en fonction du temps passé et des matériaux utilisés, plutôt que d'établir un devis, car nous ne savions pas ce que nous allions découvrir en ce qui concerne la plomberie, les dommages au sous-plancher, etc. Nous avons accepté, car je travaille à domicile et j'étais disponible en permanence pour répondre aux questions. L'entrepreneur et moi avions de bons rapports, de sorte que lorsque quelque chose se présentait, il n'hésitait pas à frapper à la porte de mon bureau et nous en discutions. Les décisions étaient prises rapidement et le travail était fait comme je le voulais. Cela semble similaire à la priorité Agile sur Revue des clients fréquents .

En revanche, le cousin de ma femme est également en train de rénover sa maison. C'est un médecin urgentiste et il est no disponible sur place pendant la rénovation. Il a donc raconté avoir été régulièrement surpris par les entrepreneurs qui prenaient des décisions importantes sans le consulter ("Quoi ? Je ne voulais pas que cette baie vitrée soit condamnée ! Démolissez le mur et recadrez la fenêtre comme elle était avant !"). Cela est bien sûr douloureusement coûteux et fait exploser le calendrier. Ce n'est certainement pas Agile.

Ainsi, une façon de convaincre un client qu'un mode temps et matériaux fonctionnera peut être de lui assurer que vous ferez de fréquents rapports d'avancement pour obtenir son feedback. Je crois que c'est déjà une recommandation de base de la plupart des méthodologies Agile. Pour commencer, cela nécessite bien sûr que le client accorde sa confiance au consultant.

Comme ressource séparée, j'ai cherché et trouvé un livre sur ce sujet : " Estimation et planification agiles "par Mike Cohn. Lisez les citations élogieuses sur cette page, provenant d'un ensemble impressionnant d'experts Agile.