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

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?

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.

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 :

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.

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

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.

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.

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?