Comment avez-vous signé un contrat pour un projet Agile ? (pas comment vous pensez le faire, comment vous l'avez fait)

Question

Pour exécuter un projet Agile, il faut d'abord un contrat. Pas de contrat - pas de projet ! Pas de projet - pas d'Agile, de SCRUM ou quoi que ce soit d'autre !

Le contrat, s'il s'agit de projets de moyenne ou grande envergure, doit comporter des déclencheurs de sécurité bien définis. En d'autres termes, les clients veulent être sûrs que si nous convenons de terminer un projet en temps = T, avec un budget = B et une portée = S, nous ne nous retrouverons pas avec un temps = T×2, un budget = B×3 ou une portée = S/2.

D'autre part, en tant qu'entreprise qui livre le produit, nous ne voulons pas que le projet se termine de manière inattendue. Par exemple, si après une itération, le client dit : "Maintenant, je vois que c'est tout ce dont nous avions besoin. Nous nous arrêtons maintenant" et que le projet était prévu pour 2 mois supplémentaires, cela signifie que nous avons des personnes sans travail planifié. Si 3 à 6 personnes ne posent pas de gros problèmes, 15 à 25 peuvent en poser de réels !

Pourtant, je n'ai pas trouvé d'exemple réel d'un contrat comportant des éléments de sécurité qui permettraient au projet d'être exécuté de manière totalement agile (déclaré ou non au client comme tel). Le discours standard que je trouve sur de nombreux forums - parler au client, lui expliquer que c'est une façon de travailler beaucoup plus productive, etc. ne convainc ni moi ni ma direction. Ce n'est pas que nous ne croyons pas que l'agilité est en fait une meilleure façon de faire les choses. C'est juste que les lacunes dans les déclencheurs de sécurité sont si évidentes qu'aucun de nos clients n'y croit ET nous ne les aimons pas non plus (les lacunes, pas les clients ;) ).

S'il vous plaît, pas de "ça marcherait probablement de cette façon ". - J'en ai lu des tonnes. Seulement intéressé par "Pour nous, cela a fonctionné de cette façon". . Pas de doutes, sautez toutes les infos confiantes qu'il contient.

P.S. Pour autant que je sache, l'approche itérative standard, axée sur les fonctionnalités, suggère que le client paie après chaque itération (nombre d'itérations) et que le client et l'exécutant du projet puissent arrêter le projet après n'importe quelle itération sans en dire beaucoup sur les conséquences, plutôt que de dire "ça échouerait de toute façon, donc le plus tôt sera le mieux" (ce qui est correct, mais pas très utile lors de la signature du contrat).

Answer 1

Je travaille dans le gouvernement.

Nous avons récemment mené une procédure de passation de marché pour le développement de logiciels et avons sélectionné trois fournisseurs pour travailler sur un projet Agile. Quelques notes :

1. Nous étions déjà sûrs à 75 % de vouloir mener un projet Agile, car nous savions que nos exigences étaient ambiguës et qu'il s'agissait d'un projet web destiné au public et comportant un élément de conception important. Je dirais donc qu'il est très utile que votre client connaisse la méthode Agile et y adhère dès le départ, même s'il ne la pratique pas en interne. Notez que l'acceptation d'Agile se développe dans (certains) cercles gouvernementaux, donc cela peut devenir plus facile.

2. L'une des mesures de protection que nous avons utilisées a consisté à engager un maître SCRUM très expérimenté (indépendant) pour travailler pour nous et gérer les tâches de gestion de projet logiciel au nom de notre chef d'équipe / architecte / responsable de l'ergonomie. Nous avons passé beaucoup de temps à trouver cette personne, et l'avons sélectionnée parmi trois excellents candidats. Cela a coûté cher mais en valait la peine.

3. Une fois que nous avons sélectionné nos fournisseurs et convenu de leurs rôles (conception, front-end, back-end), nous avons rédigé un rapide protocole d'accord décrivant notre intention d'aller de l'avant, le budget probable du projet, la taille probable de l'équipe de chaque fournisseur, l'engagement d'avoir un contrat complet signé avant la fin du mois, et un accord sur le temps et les matériaux dans l'intervalle.

4. Ensuite, nous nous sommes lancés dans une session de planification technique et de dimensionnement et nous avons fait avancer cet aspect des choses. Aucun travail de développement ou de conception n'a été effectué pendant cette période, mais nous avons fait beaucoup de dimensionnement et d'estimation de haut niveau.

5. À la fin du mois, nous avons établi des contrats pour chaque fournisseur (l'un d'eux était en retard, mais ce n'était pas grave). Un fournisseur a proposé des exemples de contrats que nous pourrions utiliser, l'un basé sur le paiement par tiers du projet, l'autre sur l'achèvement des sprints. Je pense qu'en fin de compte nous avons opté pour l'achèvement des sprints (facturés mensuellement), en utilisant une partie du langage suggéré par le fournisseur dans la section des paiements de notre modèle de contrat standard.

Dans l'ensemble, nous étions d'accord avec cette approche (bien que nous reconnaissions un certain risque) parce que nous ne pensions pas qu'il y avait une quantité énorme de risque technique réel dans l'ensemble du projet, et parce que nous avions une grande confiance dans le processus d'approvisionnement et dans les fournisseurs que nous avions sélectionnés.

En fin de compte, ce projet a été très réussi, et nous avons depuis commencé à utiliser SCRUM en interne pour d'autres projets. Je pense que le fait d'avoir une excellente équipe a été la clé. Nous avions confiance dans les fournisseurs, non seulement parce qu'ils étaient capables de faire le travail, mais aussi parce qu'ils correspondaient bien à l'idée qu'ils se faisaient du travail en équipe et que les rôles de chacun étaient bien définis (c'est-à-dire qu'ils n'étaient pas en concurrence pour le même argent).

Si nos vendeurs n'avaient pas été aussi bons, nous aurions eu quelques réserves supplémentaires quant à la conclusion d'un tel contrat, mais la gestion des marchés publics est presque autant un art qu'une science, et nous savions que nous avions choisi l'équipe qui avait la meilleure attitude parmi un groupe d'autres répondants de grande qualité.

Depuis, nous avons reconduit les trois contrats pour une deuxième année de développement. Même si je dirais que tout ne se passe pas aussi bien cette fois-ci (nouveau maître SCRUM, composition différente de l'équipe), il s'agit toujours d'un excellent projet auquel participer.

Vous pouvez également trouver ceci intéressant : Externalisation Agile .

Answer 2

Comme je travaille principalement sur des applications intranet, cela ne m'a pas posé trop de problèmes. Cependant, je réalise souvent des applications pour d'autres départements et parfois, surtout lorsque le projet est important, nous signons un protocole d'accord (MOU) concernant la portée du projet, sa durée (prévue) et son coût. Comme je travaille de manière agile, aucun de ces éléments n'est fixe, ce qui est souvent difficile à expliquer aux autres départements qui n'ont jamais travaillé de cette manière. En général, j'inclus une description du processus lui-même - quelques paragraphes - expliquant que le projet est une entreprise coopérative entre eux et moi, et que nous déterminons ensemble quand nous avons terminé.

Au moment où le protocole d'accord est effectivement rédigé, j'ai déjà investi un certain nombre d'heures dans le projet pour découvrir quelles sont les exigences (celles-ci sont traitées à un taux horaire standard). Sur cette base, ainsi qu'une estimation de ma vitesse et de la similitude avec les projets précédents, je donne une estimation générale du temps et du coût des fonctionnalités requises - en expliquant à nouveau que le coût réel est déterminé par les fonctionnalités que nous mettons réellement en œuvre et le temps que cela prend réellement. Cela demande une bonne dose de confiance, mais comme nous avons travaillé ensemble pour développer les exigences, j'ai généralement cette confiance avec les personnes avec lesquelles je traite directement. J'essaie souvent de ne pas mentionner l'estimation réelle dans le protocole d'accord, mais je l'inclus si le responsable insiste. J'essaie de leur donner un chiffre budgétaire.

D'après mon expérience, une fois que le projet est lancé et que vous commencez à apporter de la valeur au client, celui-ci est rarement mécontent. En général, il demande (et paie) plus que la portée initiale du projet. Souvent, nous convenons tous deux que certaines des fonctionnalités initiales ne sont pas nécessaires, mais je m'y attends toujours. Après tout, ils n'ont aucun moyen de savoir avec certitude ce dont ils ont vraiment besoin avant de voir les choses en fonctionnement. Le plus souvent, nous abandonnons certaines fonctionnalités et en ajoutons d'autres en fonction du développement réel. Je suppose que si nous ne le faisions pas, il n'y aurait aucun intérêt à utiliser les méthodes agiles.

Je pense que la question clé est la confiance. Je suggérerais de travailler avec un nouveau client sur de petits projets ou de diviser explicitement un grand projet en petits projets pour développer la confiance. Une fois que le client et vous savez que vous pouvez vous faire confiance pour construire le bon produit avec les bonnes fonctionnalités, je pense que le risque - et il y en a toujours un - que le client se retire brusquement est minimisé.

Answer 3

Les seuls projets agiles sur lesquels j'ai travaillé étaient soit des projets internes, soit des projets en temps et matériel (T&M), soit des projets de paiement par cycle.

Le problème est, comme vous l'avez souligné, qu'il y a un risque qu'un projet échoue/se termine prématurément. Cependant, n'est-ce pas la même chose que pour n'importe quel projet ? Si vous optez pour le T&M, vous prenez tous les risques, si vous optez pour le prix fixe, le client prend tous les risques. En optant pour le paiement par cycle, vous prenez la plupart des risques, mais vous en transférez de petites parties au client, un cycle à la fois. Il se trouve que ni vous ni le client ne voulez prendre le moindre risque, c'est pourquoi vous avez posé cette question.

Le problème, c'est que prendre des risques, c'est ça le business, plus vous prenez de risques, plus le profit est grand quand ça marche, mais aussi plus la perte est grande si ça ne marche pas. Si le risque est trop grand pour vous, la seule solution est de trouver quelqu'un d'autre qui pourra vous décharger de ce risque, mais vous devrez le payer. Si ni vous ni le client ne sont prêts à prendre ce risque, il n'y a probablement que deux solutions :

1. Demandez à un riche imbécile de garantir le risque (c'est-à-dire de souscrire une assurance).
2. Répartissez le risque entre plusieurs personnes jusqu'à ce que le risque que chacun prend soit si faible qu'il est acceptable.

Je pense que cette deuxième option est ce qui rend les contacteurs si populaires. Parce qu'il est facile de se débarrasser d'eux, ils finissent par prendre le risque d'un arrêt prématuré du projet. Comme le risque est réparti entre un certain nombre d'entre eux, le risque est réparti à un niveau acceptable. Ils vous factureront plus qu'un employé en raison du risque supplémentaire, mais c'est ce que vous obtenez en essayant d'éviter le risque vous-même.

Answer 4

La dernière chose que vous voulez sur un projet agile est une portée fixe (généralement ce qui est contenu dans un contrat sur un projet traditionnel en cascade). Ce que vous voulez, c'est un accord sur un calendrier fixe avec une équipe de taille fixe travaillant sur un backlog de produit priorisé.

Si vous forcez votre partenaire commercial à définir une portée fixe lors de l'initiation, il fourrera tout ce qu'il peut imaginer dans le contrat. Non pas parce que cela a de la valeur, mais parce qu'il sera difficile de faire des changements plus tard et qu'ils pourraient en avoir besoin.

On peut fournir une estimation de haut niveau pour un ensemble de fonctionnalités demandées par le partenaire commercial. Cependant, l'équipe, composée d'informaticiens et d'un propriétaire de produit, accepte que le champ d'application et les priorités changent et puissent changer facilement au cours de la mise en œuvre des fonctionnalités. En se concentrant d'abord sur les fonctionnalités les plus importantes, l'équipe devient axée sur la valeur et non sur le plan. Si un élément disparaît de la liste, c'est qu'il est de moindre valeur et qu'il a été remplacé par un élément que l'équipe a jugé plus important.

Un contrat à portée fixe contraint l'équipe à prendre des décisions sur la portée au moment où elle connaît le moins les fonctionnalités. En se concentrant sur les priorités et en permettant aux priorités et à la portée de s'adapter entre les itérations, on s'assure que ce qui est livré a de la valeur.

Au lieu de signer un contrat à portée fixe avec l'entreprise, participez à un camp d'entraînement agile avec votre partenaire commercial. Le cours devrait présenter le processus agile et le rôle du propriétaire du produit. Si l'entreprise accepte l'approche agile, vous êtes prêt à commencer le développement. Construisez votre backlog de produit, classez-le par ordre de priorité, fournissez une estimation de haut niveau, établissez un plan de publication et d'itération et commencez à fournir de la valeur.

La façon dont nous avons exécuté la relation est d'envoyer d'abord le partenaire commercial au camp d'entraînement agile. Ensuite, nous avons formé le partenaire commercial à devenir un propriétaire de produit. Ensuite, nous avons construit le backlog, fourni une estimation de haut niveau, fixé la taille de l'équipe et délimité le développement dans le temps. En deux semaines, le premier logiciel fonctionnel a été présenté. À partir de ce moment, le partenaire commercial a été impliqué et a compris l'intérêt d'apporter des changements au fur et à mesure qu'il en apprenait davantage. Toute discussion sur un contrat à portée fixe a été rapidement oubliée.

Answer 5

La façon dont nous gérons cela est assez productive.

Nos clients achètent essentiellement des itérations. Les clients signent un contrat disant "X itérations de 2 semaines". Il y a un processus d'éducation du client (comme c'est le cas pour tous les projets agiles sur lesquels j'ai travaillé) pour aider le client à se familiariser avec le processus de planification et l'idée que ce qu'il obtient réellement à la fin du processus de développement n'est pas concret au début du projet MAIS qu'il contrôle ce que sera le résultat final.

Notre équipe travaille ensemble depuis près de six mois, nous avons une base technologique solide que nous avons développée nous-mêmes pour minimiser les risques. Nous avons une idée assez précise de notre capacité permanente en termes de vélocité, ce qui nous aide à prévoir le nombre d'itérations nécessaires pour atteindre le résultat souhaité par le client.