Un périmètre fixe + un délai fixe + un contrat à prix fixe peuvent-ils jamais être conçus pour fonctionner avec «agile»?


32

Certains projets que nous exécutons en interne utilisent Scrum, tout en étant "tout résolu" pour le client. Nous rencontrons un succès mitigé de notre part (le client apprécie la visibilité du graphique de burndown). Les types de projets sur lesquels nous travaillons peuvent-ils être exécutés avec succès en utilisant les méthodes agiles?


17
Une portée fixe + un délai fixe + un contrat à prix fixe peuvent-ils être mis en œuvre?
Carson63000

4
N'est-ce pas une façon de reformuler: "Rapide, bon ou pas cher. Choisissez deux"?
Matthieu M.

3
N'est-ce pas fixé un antonyme d'agile?
Matt Ellen

Réponses:


10

Eh bien, j'ai principalement travaillé dans des environnements "agiles" (bien que nous n'utilisions pas le jargon), et j'ai fait des choses à coût fixe. Généralement, cela revient à un coût plus élevé, car aucune entreprise ne peut se permettre de tout faire gratuitement, et les exigences changent et évoluent à mesure que le client détermine plus clairement ce qu'il veut.

Les exigences initiales pour la partie à coût fixe doivent être effectuées beaucoup plus soigneusement que dans un environnement itératif typique, ce qui rend le processus un peu moins itératif. La partie «plus» du contrat peut être plus itérative, à condition que nous ayons rempli la partie des coûts fixes de manière plus ou moins satisfaisante pour le client.


71

Je voudrais poser une contre-question:

Une portée fixe + un délai fixe + un contrat à prix fixe peuvent-ils être mis en œuvre, point final ?

Le dicton "bon / rapide / pas cher - choisissez deux" n'est pas seulement une blague d'ingénierie stupide. Chaque chef de projet digne de ce nom connaît le Triangle de gestion de projet :

Triangle de gestion de projet

Vous nous dites que le coût, la portée et le calendrier sont tous fixes. Cela ne laisse aucune marge de manœuvre ou d'erreur. Aucun . Vous pouvez choisir de voir la «qualité» comme un attribut, mais ce n'est pas un «vrai» attribut, il ressemble plus à un méta-attribut dérivé des autres attributs (coût / portée / calendrier).

Le problème est que cela ne se produit jamais en réalité tant que votre projet est planifié et exécuté par des humains.

  • Les exigences et les spécifications ne couvrent jamais tous les cas de bord, sauf s'ils ont été rédigés dans les moindres détails par des architectes et des designers qualifiés, auquel cas le projet est déjà à moitié fait; et même alors, il y a toujours une possibilité d'erreur.

  • Des coûts inattendus surgiront, entraînant des dépassements budgétaires. Un abonnement a expiré. Un fabricant a cessé de prendre en charge un produit que vous utilisez et vous devez en trouver un nouveau. Un entrepreneur horaire a augmenté son taux sous la menace d'un départ. Toute votre équipe vient de se mettre en grève, exigeant une augmentation de 10% et une semaine de vacances supplémentaire.

  • Les horaires glissent. Des problèmes imprévisibles surgissent; ce composant graphique que vous utilisez depuis 5 ans consécutifs n'est pas compatible avec Windows 95, que votre client utilise toujours. Un bug obscur dans Windows 64 bits provoque de graves problèmes d'interface utilisateur et vous passez près d'une semaine à le rechercher et à développer une solution de contournement (cela m'est réellement arrivé). Votre développeur principal a été renversé par un bus et vous devez aller recruter et en former un nouveau. Votre date de livraison estimée est toujours erronée. Toujours.

    Voir la loi de Hofstadter :

    Loi de Hofstadter: Cela prend toujours plus de temps que prévu, même si vous tenez compte de la loi de Hofstadter.

Les méthodes agiles consistent à jongler avec le coût, le calendrier et la portée. La plupart du temps, il s'agit spécifiquement de jongler avec la portée et parfois le calendrier , c'est pourquoi vous commencez avec des histoires d'utilisateurs nébuleuses et planifiez des révisions au lieu de versions complètes. Différentes méthodologies utilisent une terminologie différente mais ce sont toutes les mêmes prémisses de base: des versions fréquentes et un rééquilibrage de la planification et de la portée avec chaque version.

Cela fait aucun sens avec un projet qui est (ou prétend être) soit portée fixe ou horaire fixe.

Si un attribut de projet (coût / portée / calendrier) était fixé, je vous dirais qu'il pourrait ne pas convenir aux méthodologies agiles.

Si deux attributs de projet sont fixes, votre projet n'est certainement pas adapté aux méthodologies agiles.

Si les trois attributs sont fixes, votre projet va probablement échouer. S'il est effectivement expédié, alors soit le calendrier d'origine a été massivement truqué, soit le client a réussi à se faire des illusions en pensant que vous aviez réellement livré ce qui avait été promis.

Si ce contrat est toujours sur la table, je vous invite à le rejeter. Et si vous l'avez déjà accepté, que Dieu ait pitié de votre âme.


4
+1 pour la loi Hofstadters. Je vais le citer lors de la prochaine session d'estimation.
Chris Buckett

2
Notez que si "fixe" ne signifie pas vraiment fixe (comme implicite dans le commentaire de la réponse de Todd), cela change quelque peu le paysage, et le succès du projet dépendra en partie de faire en sorte que tout le monde se mette d'accord sur la définition réelle du mot "fixe" (ou "doit" ou "requis" ou quel que soit le verbiage spécifique dans le contrat). Si la portée est vraiment "fixée si nous avons le temps" , alors elle commence à ressembler beaucoup plus à un projet agile. :)
Aaronaught

2
Je soupçonne que c'est ainsi que la direction a travaillé avec le client.
Chris Buckett

3
Les projets à calendrier / portée / prix fixes peuvent fonctionner (je les ai faits), ils nécessitent simplement des exigences très solides, une très bonne estimation et comme vous le dites, ces choses sont très difficiles en réalité. +1 pour une explication claire de la façon dont Agile est fondamentalement contradictoire à l'ensemble du mécanisme de prix fixe, bien que l'un concerne les compromis (intelligents) et que l'autre exclut la possibilité de tout échanger.
Jon Hopkins

3
Juste le montant des votes positifs sur cette réponse montre combien de personnes travaillent dur dans le désordre Agile + à prix fixe.
porteur de l'anneau

18

J'adore cette citation:

«Scrum est idéal pour les portées variables à date fixe ou pour les portées fixes à portée fixe (qui augmentent toujours). Si vous faites une portée fixe à date fixe, je recommande la cascade ou la RUP, qui vous achèteront quelques mois pour chercher un nouvel emploi. »~ Michael James


6

Bien sûr, tant que votre barre de qualité est remarquablement basse. Je crois au vieux triangle de fer du "délai de livraison / qualité / prix" où vous pouvez en choisir deux, mais l'autre flotte. Il semble que vous ayez fixé le délai de livraison et le prix (ainsi que les fonctionnalités), donc la seule chose qui peut donner est la qualité.

Cela dit, si vous utilisez un tableau déroulant et que les éléments les plus prioritaires sont exécutés en premier, il peut être acceptable d'avoir une poignée des éléments les plus importants dans le délai spécifié pour le montant monétaire spécifié. À tout le moins, votre client verra que vous contrôlez quelque peu le processus, avec un livrable à la fin de chaque itération et il a la capacité de dire ce qui est le plus important.

Sinon, je pense que s'engager sur une durée, un ensemble de fonctionnalités et un prix fixes est imprudent et entraînera des efforts héroïques entraînant une qualité inférieure et un code moins maintenable. Agile n'est pas de la poussière de fée magique.


2
C'est à peu près ainsi que nous l'avons géré avec notre client - laissez le champ d'application glisser et ajoutez-le dans la prochaine version. Leurs principaux motivateurs sont la date limite et le prix. Nous n'aimons pas laisser la qualité glisser - comme cela et les autres commentaires le notent, nous sommes pleinement conscients du triangle - le côté commercial a le travail amusant de sensibiliser le client à cela aussi.
Chris Buckett

0

Le prix fixe / délai fixe / portée fixe peut être fait au moins aussi agile qu'il peut l'être en cascade.

En cascade, les estimations de temps sont inexactes et les détails finissent par être mis en œuvre différemment des spécifications d'origine. En d'autres termes, la date limite / portée ne peut être connue exactement à l'avance.

En agile, vous pouvez faire un sprint zéro pour générer un backlog d'histoires utilisateur et faire des estimations. Ensuite, acceptez de répondre aux histoires de valeur pour un prix fixe, dans un délai fixe. La portée est fixée en fonction des histoires de valeur que vous avez l'intention de réaliser, et aucune promesse n'est faite concernant les histoires d'utilisateurs.

En d'autres termes, vous promettez de livrer ce qui compte et évitez de faire des promesses concernant des décisions de conception spécifiques qui ne sont pas liées aux revenus / économies / etc. que le projet est censé livrer.


Vieux, mais ... cela pourrait être fait infiniment mieux en Agile qu'en Cascade, et les chances ne changeraient pas. Zéro va toujours être zéro. Si une seule tâche sur une seule histoire rencontre un seul événement qui modifie le coût ou l'effort, vous avez échoué.
EKW

0

Je suis d'accord avec Bruce dans une certaine mesure. Bien que je ne sois pas trop familier avec la cascade ou le RUP, je ne peux donc pas commenter cela.

Ce que j'ai lu récemment, et j'ai trouvé très bien dit, c'est que même dans Agile, nous négligeons la planification. Une session de planification approfondie une fois qu'une itération est excellente - non, c'est essentiel - mais il en va de même pour la planification tout au long de l'itération.

Je travaille dans l'industrie du divertissement, où les choses changent constamment. L'équipe a besoin d'un certain degré de clémence / flexibilité qui lui permettra de «replanifier» les histoires au milieu du sprint afin de s'aligner sur les nouveaux objectifs ou les objectifs révisés.

J'aime l'idée d'une planification continue, car trop souvent, les développeurs diront au propriétaire du produit de s'en aller lorsqu'ils travaillent sur des histoires au milieu du sprint. C'est excellent si votre équipe travaille sur des histoires qui sont toujours valables et que votre propriétaire de produit n'est qu'une nuisance. Mais dans certains cas, les histoires deviennent redondantes PENDANT le sprint, et il est impératif pour le propriétaire du produit de repérer cela, et pour l'équipe de se réaligner avec les objectifs / histoires modifiés - n'est-ce pas de cela qu'il s'agit?


2
si vous faites une planification constante, alors Scrum n'est vraiment pas pour vous. Kanban pourrait être plus approprié à essayer. Mais ce que vous dites à propos de l'agilité est juste.
gbjbaanb
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.