Scrum dans un projet de coût fixe

Scrum ne remplace pas d'exigences appropriées, ni même d'avoir des versions ou des jalons majeurs occasionnels. Au contraire, cela vous donne un moyen de garder votre équipe productive et concentrée, et évite les effets secondaires de gaspillage du temps d'un processus de cascade.

En fait, l'un des principaux avantages d'un processus agile comme Scrum est qu'il vous fait «échouer rapidement et fort» sur les zones problématiques de votre projet. Si, après quelques sprints, votre équipe ne peut toujours pas estimer efficacement le temps et les ressources nécessaires à la mise en œuvre d'une caractéristique particulière, il peut être utile de repousser les exigences de cette zone - elles devront peut-être être clarifiées, simplifiées, ou mis au rebut complètement. Cependant, dans un processus de cascade traditionnel, ces "caractéristiques de problèmes" peuvent souvent être repoussées à la dernière minute possible, ce qui entraîne la mort habituelle et la délivrance dans laquelle la plupart des projets se développent.

Cependant, le rôle du propriétaire du produit est encore plus critique dans les équipes utilisant Scrum qui disposent d'un ensemble d'exigences. GAUCHE à leurs propres appareils, la plupart des équipes de développement se concentreront sur les fonctionnalités les plus intéressantes / amusantes / geek (API de service, la mise en cache, la recherche), et laissez les trucs «désordonnés» comme le processus de paiement, UX Design et I18N jusqu'à la dernière minute. . Une voix utilisatrice forte est essentielle pour s'assurer que les fonctionnalités essentielles à l'utilisateur final reçoivent leur juste part d'attention.

J'ai travaillé dans un environnement où nous avions un coût fixe et des projets à temps fixe. Nous sommes passés à une méthologie Scrum-Esque à partir d'une méthodologie de cascade / vmodel. Scrum peut très bien fonctionner dans des projets de coûts / horaires fixes car le concept est que le client est mis en contrôle, mais pour que cela fonctionne, vous devez être capable de déterminer quelque peu de savoir quel travail est requis et ce qu'il va coûter (temps, argent , Ressource). Et il s'agit d'une station de situations où Scrum dans un candidat idéal.

Vous décomposez la liste de souhaits Wishy-Washy / Exigences / Screenshots dans des produits livrables tagibles. Par exemple. Un client peut dire "je veux de l'ecommerce, avec PayPal", vous devez casser cela dans des produits livrables réels. "1. Enregistrement du client et connexion, 2. Catalogue de produits, 3. Sac shopping, 4. Paiement, 5. Acquéralisation de la commande". À ce stade, il est toujours impossible de déterminer combien de temps il faudra et nous devons livrer tout ce qui précède afin de compléter le projet (c'est-à-dire que vous ne pouvez pas avoir de commerce électronique sans paiement). Alors rompre à nouveau, et encore une fois, jusqu'à ce que vous ayez des produits livrables granulaires, Genreally Delverable en quelques heures, peut-être des jours, mais certainement pas des semaines, par exemple xxx

et ainsi de suite, il peut être fait très vite, et vous pouvez maintenant probablement deviner combien de temps il faudrait ToDo X (OFC, je risquai de cascuser encore plus loin, ajoutez davantage de texte descriptif pour décrire le travail requis, tel que les données persistantes pourraient avoir besoin, la Données dans ces structures, comment les données seront ajoutées, aller plus loin, vous pourriez même déshériter les états de début et de sortie requis).

Une fois que vous êtes allé, vous remarquerez que certaines fonctionnalités et des dépendants sur d'autres, vous ne pouvez pas avoir une fonctionnalité de pagination sur un catalogue, à moins que vous n'ayez un catalogue pour commencer, et La cataglogique nécessitera que la CMS screesn d'ajouter et d'éditera les éléments d'édition, etc., etc., etc. Soulignez ceux-ci «Impossible de vivre sans fonctionnalité» dans tout l'outil que vous utilisez, ce qui forme le projet de base, et dans un jour ou deux, vous avez une bande de fonctionnalités qui Peut être développé un peu autonome, avec des coûts, qui, lorsqu'ils sont ajoutés, apportent le coût du projet. Et maintenant, le client est responsable, ils décident que Thay souhaite ajouter une fonctionnalité et augmenter le coût, refroidir, leur après-vente.

Tout ce qui précède n'est évidemment qu'une petite partie de ce que Scrum ou tout processus agile est.

Je ne pense pas que le contrat de prix fixe avec le fluage de portée et un processus de Scrum sont incompatibles. Vous devez juste être d'accord avec votre client comment cela fonctionnera. Si vous créez votre arriéré initial avec votre client, vous pouvez l'estimer, vous pouvez l'utiliser comme base du coût et de l'horaire à prix fixe. Vous pouvez même accepter un taux de «X» Story Points est égal à «Y» Coût et «Z». »Au début.

Vous faites ensuite la chose de Scrum normale, que le client affecte des histoires à l'itération actuelle, etc.

Au fur et à mesure que le client s'engage dans l'étendue Creep, vous travaillez avec eux pour ajouter le "fluage" comme des histoires d'utilisateurs à l'arriéré. Chaque fois que vous ajoutez une nouvelle histoire, indiquez que pour chaque X points ajoutés à l'arriéré, ils devront augmenter le coût par Y et le calendrier de Z, ou ils devront abandonner des points d'histoire de la valeur égale. Comme ils choisissent ce que vous travaillez chaque itération, les points qu'ils abandonnent (si c'est le choix) seront les caractéristiques les moins précieuses. Lorsque votre planification s'épuise, vous serez laissé avec un arriéré des fonctionnalités les moins importantes qu'ils peuvent choisir de vous déposer ou de vous donner un nouveau contrat à la fin.

L'astuce, bien sûr, est d'être utile pour estimer les coûts et le calendrier de chaque histoire / tâche; -)

Le projet pourrait être divisé en parties plus petites et les taux fixes pourraient être attachés à ceux-ci. Les autres phases du projet pourraient ensuite être ajustées.

Vous devez être capable de vendre le processus agile contre vos concurrents. Si un client a des antécédents de projets d'offre fixes qui ont été livrés à temps, aux spécifications et aux coûts, pourquoi perdraient-ils leur temps à prendre des offres d'autres développeurs?

Pour moi, la réponse courte sur le prix agile et fixe est que vous ne pouvez pas le faire, du moins pas avec une portée fixe.

Je sais que certaines personnes vont dire " ce n'est pas vrai, nous le faisons " mais, avec tout le respect due, je ne pense pas qu'ils font vraiment agile et que je vais expliquer pourquoi. En réalité, l'explication est assez simple: le prix fixe implique une portée fixe et repose sur la prévisibilité dans laquelle Agile est tout au sujet de la portée variable, de la gestion de la portée et de l'adaptation. Un prix fixe avec une portée fixe est fondamentalement l'opposé d'agile.

Avec une approche agile, le prix fixe vous donne un certain nombre d'itérations pour une taille d'équipe donnée. Pendant ces itérations, le client sera en mesure d'avoir l'équipe de construire d'abord les caractéristiques les plus précieuses et de maximiser la valeur commerciale générée. Toute l'idée est alors de cesser d'itération lorsque le coût d'une itération est supérieur à la valeur générée. Voici comment fonctionne agile.

Alors, lorsque les gens disent qu'ils font un prix fixe avec une portée fixe d'une manière agile, ils introduisent réellement certaines contraintes qui ne sont pas vraiment compatibles avec la théorie agile - comme faire une estimation initiale d'un ensemble donné de caractéristiques et de geler ces Caractéristiques et estimations - et ils perdent des avantages importants d'Agile (à moins d'avoir une connaissance parfaite des technologies et du domaine commercial et de les maîtriser suffisamment pour tout prédire, mais je connais peu de projets comme celui-ci).

Voici de toute façon une bonne compilation de divers contrats agiles: 10 contrats pour votre prochain logiciel agile Projet qui pourrait être utile. Mais je pense qu'ils nécessitent tous une éducation des clients, en particulier celle utilisée pour un prix fixe avec une portée fixe (et des livraisons en retard).