Défis de l'approche Agile sur les projets gouvernementaux


24

Une discussion Agile précédente ici avait de bonnes réponses spécifiant ce qui est essentiel au succès de la mise en œuvre de la méthodologie Agile dans le développement de logiciels. La plupart des points étaient des défis organisationnels et de gestion typiques, mais un point m'inquiète et c'est que le client doit être impliqué tout au long du processus.

Le client est la seule chose que vous ne pouvez pas contrôler de manière réaliste, peut-être que votre modèle commercial vous conduit à des travaux sous contrat avec le gouvernement, par exemple lorsqu'un contrat intensément strict oblige l'entreprise à:

  • Fournir des fonctionnalités X exactement comme demandé

  • Les demandes de fonctionnalités seront jetées sur un mur, ne nous dérangez pas, nous ne voulons pas l'entendre.

  • Il n'y a aucun concept de priorité des fonctionnalités dans l'esprit du client, elles sont toutes importantes ou nous ne les aurions pas demandées.

  • Le projet ne coûtera ni plus ni moins que Y indépendamment des dépassements ou des délais.

  • Délai absolu, strict, définitif et non négociable pour la livraison complète de tous les travaux.

Nous n'avons jamais travaillé avec un tel client auparavant, mais l'argent du projet est tout simplement trop bon pour être abandonné. Nous avons besoin de ce travail.

Je suis venu ici et j'ai travaillé HARD pour changer les processus à l'intérieur pour aller vers le développement Agile et ici je ne sais pas comment concilier où ce projet s'intègre dans notre nouveau processus. Je n'ai jamais eu le luxe d'une gestion ouverte et ouverte qui m'a fait confiance pour diriger l'équipe de développement et les processus sur cette voie et maintenant que nous sommes ici, je ne peux pas honnêtement me dire que ce projet se fera vraiment dans un Manière agile. J'ai l'impression que la direction m'a fait confiance pour ouvrir la voie et que je les ai laissés tomber parce que cette situation dans laquelle nous nous trouvons maintenant appelle clairement à Waterfall. J'ai peur de perdre leur confiance si je reviens en arrière maintenant.

D'autres réponses comme celle- ci disent qu'Agile est impossible avec ce type de client, êtes-vous d'accord? Avez-vous été dans une situation similaire et avez-vous réussi? Quelles stratégies avez-vous mises en œuvre pour réussir Agile?


2
J'ai totalement besoin de répondre à cela lorsque j'aurai plus de temps. J'ai en fait appliqué des techniques agiles sur des projets de contrats avec le gouvernement et travaillé sur une équipe agile au sein du gouvernement. Mais hélas, mon script de compilation / test / distribution est presque terminé. Je reviendrai plus tard.
Thomas Owens

@ThomasOwens J'espérais que vous le feriez ... S'IL VOUS PLAÎT revenir et fournir une réponse lorsque vous en aurez l'occasion!
maple_shaft

1
"Le projet ne coûtera ni plus ni moins que Y indépendamment des dépassements ou des délais" - vous n'avez alors travaillé sur aucun projet informatique pour le gouvernement britannique? ;)
Cocowalla

Réponses:


9

Je pense que la première chose à réaliser est qu'il y a une différence entre être agile et être agile. Déployer lentement des techniques et des caractéristiques agiles - les équipes interfonctionnelles, la planification adaptative, la livraison évolutive / incrémentielle, les itérations temporelles et même l'introduction de concepts de Lean sont très différentes de l'introduction de la programmation extrême, Scrum ou Crystal.

Vous mentionnez explicitement l'implication du client. Oui, de nombreuses méthodologies Agile nécessitent une implication du client, mais cela n'est pas obligatoire pour être agile. Dans chaque programme lié au gouvernement / à la défense, j'ai toujours eu un chef de programme ou de projet qui était le point de contact avec le client. Cette personne devient la «voix du client». Cela peut être ralenti lors de la téléconférence, du courrier électronique ou de l'appel et de la clarification, mais vous pouvez avoir une seule personne (ou un groupe, si vous avez également des adjoints au PM) qui est le représentant client de votre équipe. Certes, ce n'est pas tout à fait la même chose. Mais n'est-ce pas agile d'être flexible et de réagir au changement?

Vous mentionnez également quelques concepts clés: des exigences prédéfinies, des demandes de fonctionnalités «jetées par-dessus le mur», un manque de hiérarchisation car «elles sont toutes importantes» et des projets à coût fixe et / ou à calendrier fixe. Chacun de ces éléments peut être traité de différentes manières.

Si vous pensez que vous avez toutes vos exigences à l'avance, il y a de fortes chances que ce ne soit pas le cas. Les exigences changent. Ce n'est pas parce que vous avez une spécification «terminé et signé» qu'elle est gravée dans le marbre. Étant donné le document sur les exigences dont vous disposez, saisissez-les comme vous vous sentez à l'aise et / ou de la manière spécifiée par le contrat et livrez les exigences, la conception et l'architecture. De plus, voyez si vous pouvez traiter ce sont des documents vivants (un document de conception que j'ai vu aujourd'hui au travail est étiqueté comme la révision G, ce qui signifie qu'il s'agit de sa 8e mise à jour). Demandez combien vous pouvez laisser en tant que TBD dans une itération donnée et combien doit être raffermi maintenant - il pourrait y avoir des concessions mutuelles.

Soyez agile avec votre documentation. Ne dupliquez pas les efforts entre «ce que veut votre équipe» et «ce que veut le client». Par exemple, si votre client souhaite une spécification de configuration logicielle traditionnelle et que votre équipe souhaite utiliser des user stories, essayez de vous adapter à un SRS traditionnel et utilisez des éléments d'action et une liste d'éléments d'actions roulants au lieu de user stories afin de ne pas perdre de temps formulant à la fois "le système doit ..." et "doit pouvoir le faire". Cela prend cependant de la discipline de la part de l'équipe pour s'adapter aux différences entre les projets. Capturez les problèmes dans les réflexions.

Une fois que vous arrivez au développement, vous pouvez exécuter 5 ou 6 itérations, puis inviter votre client à votre installation pour voir un sous-ensemble de votre implémentation. Rincez et répétez ce processus. Ce n'est pas l'implication constante exigée par certaines méthodologies, mais vous avez l'avantage d'une grande visibilité. Si votre client dit non, au moins vous avez essayé. S'ils disent oui, vous pouvez les éclairer sur leur agilité. Sur un projet sur lequel j'étais, le client a visité le site tous les quelques mois (3-5 mois, généralement). Ils nous regardaient passer les tests d'AQ, ils discutaient des préoccupations avec les ingénieurs et les affaires avec le bureau du programme / projet. C'était l'occasion pour tout le monde de se retrouver sur la même longueur d'onde.

Les tests et la maintenance se déroulent de la même manière que sur les autres projets agiles. Créez vos procédures de test et documentez les défauts de la manière appropriée, suivez les mesures par obligations contractuelles et documentez les résultats des tests. Si vous voulez suivre TDD, allez-y. L'intégration continue est une autre bonne idée. Pendant les réunions sur l'état du projet, votre chef de projet peut utiliser ces informations pour dire "nous avons mis en œuvre N exigences, faire passer M tests, X tests réussissent" et mettre à jour l'état et la situation du projet aux personnes disposant de l'argent.

En parlant d'argent, nous avons le problème des coûts fixes et / ou des horaires fixes.

Traiter avec un horaire fixe est assez simple. Compte tenu de vos besoins, vous savez combien d'itérations vous pouvez effectuer. Votre charge de travail pour chaque itération est à peu près figée en termes de fonctionnalités à implémenter, tester et intégrer. Cela peut être difficile, mais il n'est pas impossible de diviser les fonctionnalités et de les affecter à des itérations à l'avance. Cela revient à mon point sur l'invitation du client - si vous avez un an et utilisez des itérations de 2 semaines, invitez peut-être le client tous les trimestres (et invitez-les tous les trimestres) et montrez-leur les résultats des travaux précédents. Faites-leur voir votre ordre de priorité des exigences, vos plans futurs et la façon dont vous allez planifier.

Gérer un budget fixe est similaire. Vous savez combien de temps vous avez, combien de ressources vous avez pour le projet, combien elles coûtent et donc combien d'heures chacun peut travailler par itération. C'est juste une question de s'assurer que tout le monde garde une trace de cela attentivement. Si votre entreprise peut supporter le coût des heures supplémentaires, allez-y. Sinon, assurez-vous que tout le monde travaille la durée appropriée et utilisez de bonnes compétences de gestion du temps et de boxe pour garder tout le monde productif. Des heures plus productives sont ce dont vous avez besoin pour réduire les coûts - fournir plus de documents et de logiciels à valeur ajoutée sans les frais de réunions et les frais généraux.

En fin de compte, il ne s'agit pas nécessairement d'être Agile, mais d'appliquer les choses qui rendent Agile bon et d'être agile. Être en mesure de répondre aux changements des exigences, être en mesure de fournir des logiciels fréquents même si le client ne le souhaite pas, produire uniquement une documentation à valeur ajoutée (avec tout ce que vous êtes contractuellement obligé de produire), etc.


Si j'ai raté quelque chose, faites le moi savoir. J'ai touché les points majeurs auxquels je peux penser.
Thomas Owens

Hou la la! Merci pour l'explication longue et détaillée, certains des points que vous développez ont également été mentionnés dans les réponses précédentes. Cela me fait me sentir bien dans tout. Sur SRS vs. User Stories, nous avons déclaré dans notre offre de proposition que nous suivions les méthodologies Agile. Si tout va bien s'ils n'ont aucune objection à cela, les user stories seront un livrable satisfaisant. suite ...
maple_shaft

... Je pense que notre manager serait le meilleur client. Nous espérons développer des logiciels hautement composants et faciles à ajouter pour des gouvernements ou des institutions supplémentaires. Si je considère cet aspect, le client est vraiment l'entreprise elle-même et le logiciel est le produit qu'ils posséderont et qu'ils seront libres de vendre à qui ils veulent. Le respect des obligations contractuelles du gouvernement devient simplement une base pour la hiérarchisation des user stories dans l'arriéré. De plus, j'adore l'idée de les inviter à consulter les résultats trimestriellement. Merci!
maple_shaft

@maple_shaft Malheureusement, je ne peux pas parler du côté commercial, du programme ou du contrat. Je suis au courant des différentes obligations contractuelles et des choses que j'ai dû faire ou des documents que j'ai dû produire pour les remplir, mais je n'ai été qu'un ingénieur et je n'ai jamais été impliqué dans le projet ou le programme. Vous avez certainement besoin de relations commerciales et juridiques sur ce contrat et de vous assurer que vous pouvez faire ce que vous avez l'intention de faire.
Thomas Owens

11

Oui, l'agilité n'est pas appropriée pour un tel projet, car il semble que les exigences soient déjà faites et fixées dans la pierre, probablement le résultat d'années d'analyse par des consultants coûteux, des réunions de commissions et des compromis politiques. Waterfall fonctionne bien si le client est tellement discipliné qu'il peut vous dire par écrit exactement ce qu'il veut. Ils peuvent avoir tort, mais au moins vous l'avez par écrit, et vous serez payé si vous livrez cela. (Cela ne dit rien sur la satisfaction des clients, bien sûr. Il y a de fortes chances que vous livriez quelque chose dont ils n'ont pas réellement besoin.)

Agile a été créé pour résoudre un problème que vous n'avez pas: le risque dû à l'incertitude des exigences.

Il est vrai que le client peut demander des demandes de changement, mais vous suivez l'un des deux chemins suivants:

  1. L'argent était si bon que vous savez que vous pouvez absorber X quantité de nouvelles fonctionnalités à différentes étapes du projet et toujours sortir sans perdre votre chemise, ou
  2. Vous indiquez clairement au client dès le départ qu'en raison de la négociation d'un prix serré, chaque nouvelle demande de fonctionnalité générera un ordre de modification avec un prix qui devra être approuvé par lui, accompagné d'un bon de commande (ou modification de le bon de commande d'origine) pour que vous puissiez le mettre en œuvre. L'ordre de modification indiquera tout impact sur la fonctionnalité ou le calendrier. S'ils disent que la date limite ne peut pas être déplacée, alors les ordres de modification deviennent exponentiellement plus chers à mesure que le projet progresse, car il est plus coûteux de changer des choses plus tard.

La relation semble beaucoup plus amicale dans la situation # 1, mais le fait est qu'il est assez rare de trouver des services d'achat qui ne vous serreront pas sur le prix, donc la plupart du temps vous êtes dans la situation # 2. Cela signifie que la relation est conflictuelle, mais si vous voulez survivre dans les affaires, vous devez réussir à gérer la relation tout en maintenant votre position. C'est une grande partie du travail du chef de projet.

On dirait que vous pourriez être dans la situation n ° 1, ce qui est bien. J'imagine que les marchés publics sont le seul endroit où ils ne se soucient pas de l'argent, car, après tout, ils ne dépensent pas leur argent, ils dépensent votre argent.


>> ils ne dépensent pas leur argent ... Mais ils dépensent un budget sur lequel ils n'ont aucun contrôle et une capacité très limitée de rediriger même si les ordres de modification sont approuvés. Obtenir plus d'argent dans le budget de l'année prochaine pour les changements de base nécessaires pour la livraison de cette année n'est pas un endroit agréable à vivre selon mon expérience.
DaveE

10

... des travaux sous contrat avec le gouvernement, par exemple lorsqu'un contrat extrêmement strict oblige l'entreprise à:

Première. C'est strict. Mais ce n'est pas inflexible. Cela nécessite simplement une attention aux détails et une longue, longue chaîne d'ordres de modification.

Les agences gouvernementales sont en fait agiles d'une manière lente et inefficace. Vous devez rédiger (et négocier) des ordres de modification formels et détaillés à tout moment.

Fournir des fonctionnalités X exactement comme demandé

Jusqu'à modification par un ordre de modification.

Les demandes de fonctionnalités seront jetées sur un mur, ne nous dérangez pas, nous ne voulons pas l'entendre.

Le canal de communication est l'ordre de changement. Impact sur le budget et le calendrier.

Il n'y a aucun concept de priorité des fonctionnalités dans l'esprit du client, elles sont toutes importantes ou nous ne les aurions pas demandées.

C'est difficile à contourner. Même les entreprises non gouvernementales qui dépensent beaucoup d'argent pour l '"analyse des besoins" ne veulent pas qu'on leur dise qu'une grande pile plate et fumante d'exigences non grevées par les informations de priorité et de compromis est incomplète. Ils ont payé beaucoup d'argent pour répondre à toutes les exigences. Comment voulez-vous plus d'informations?

C'est un problème difficile.

Le projet ne coûtera ni plus ni moins que Y indépendamment des dépassements ou des délais.

Sauf pour les ordres de modification. Qui modifient Y et la date limite.

Délai absolu, strict, définitif et non négociable pour la livraison complète de tous les travaux.

«non négociable» n'est généralement pas vrai. C'est négociable. C'est juste douloureux de négocier.

La partie importante de la négociation avec les agences gouvernementales est le fait que vous avez besoin de «preuves de niveau avocat» pour vos changements de coûts et d'horaires. Quelques présentations techniques soignées avec une belle diapositive PowerPoint ne sont pas des "preuves". Vous avez besoin de beaucoup de documentation pour plaider votre cause.

Les gens du gouvernement doivent fournir des preuves irréfutables qu'ils ont fait tout ce qui était en leur pouvoir pour rendre cela aussi bon marché et efficace que possible. Ils savent que chaque décision est rejouée dans la presse publique et examinée avec le recul.

La complexité du développement de logiciels et l'aspect «quart-de-lundi» du travail du gouvernement après coup, les rendent réticents à apporter des modifications au contrat sans preuves accablantes.

Cela rend difficile une approche correctement Agile.

«Les individus et les interactions sur les processus et les outils» sont difficiles. Vous ne travaillez pas avec un individu, mais avec un représentant du gouvernement dont le travail est limité par le processus.


+1 pour Jusqu'à modification par une demande de changement . Les exigences fixes sont une erreur, et c'est certainement le cas avec les marchés publics lorsque la portée peut être énorme
Cocowalla

7

Dans un projet comme celui-ci, ils ont lié la portée, les ressources et le temps. La seule chose qu'il vous reste à gérer est la qualité. Alors...

Vous n'allez pas tirer le meilleur parti d'une approche agile que vous pourriez autrement, mais vous pouvez faire de votre mieux pour atténuer les risques liés à la qualité et être en mesure d'informer le client des problèmes plus tôt que tard.

Soyez donc aussi agile que possible:

  1. Passez en revue les exigences et priorisez-les le mieux sur le risque technique. Définissez les exigences prioritaires comme votre backlog.
  2. Parcourez le backlog des sprints - concevez, testez et codez les fonctionnalités du sprint. Il vous manque une interaction avec le client, donc le document des exigences doit représenter le client pour cette activité.
  3. Invitez le client à chaque revue de sprint - il peut dire non, mais il peut dire oui. Et vous obtiendrez des commentaires plus tôt que tard.

Si vous commencez à courir dans le délai imparti, vous pourrez montrer ce qui a été fait et peut-être qu'à ce moment-là, le client, sachant qu'il n'obtiendra pas tout, établira une priorité suffisante pour vous dire ce qu'il veut. Vous devriez également effectuer les tâches les plus risquées, ce qui signifie que les tâches à l'heure limite sont les plus faciles à entasser pendant les heures supplémentaires.


1
Merci c'est vraiment un bon conseil! Prioriser les risques techniques et éventuellement faire de mon manager le "client" tout au long du processus. J'aime l'idée de retirer les histoires d'utilisateurs difficiles et difficiles du premier. Le raisonnement pour ce faire est solide avec un délai strict.
maple_shaft

3

Je pense que ce type de client n'est pas la norme. Vous avez affaire à un groupe qui a déjà demandé des projets similaires, alors il sait exactement ce qu'il veut. Vous ne mentionnez jamais que leurs spécifications vont changer.

Fournir des fonctionnalités X exactement comme demandé

J'ai de la chance si je fournis vaguement la fonctionnalité X comme suggéré et que je suis prêt à la changer à tout moment.

Les demandes de fonctionnalités seront jetées sur un mur, ne nous dérangez pas, nous ne voulons pas l'entendre.

Si vous savez ce qu'ils veulent, allez le construire.

Il n'y a aucun concept de priorité des fonctionnalités dans l'esprit du client, elles sont toutes importantes ou nous ne les aurions pas demandées.

Vous ne pouvez pas perdre sur celui-ci. Construisez-les comme bon vous semble.

Le projet ne coûtera ni plus ni moins que Y indépendamment des dépassements ou des délais. Délai absolu, strict, définitif et non négociable pour la livraison complète de tous les travaux.

C'est difficile si vous n'avez jamais construit de projet pour le gouvernement. Si vous avez des antécédents, vous pourrez peut-être déterminer si vous pouvez livrer. Cela ne signifie pas qu'ils ne paient pas bien (ils sont connus pour avoir payé 50 $ pour un marteau de 10 $) ou qu'ils ont des attentes déraisonnables. Avec ces spécifications, un membre de votre équipe doit agir en tant que client et approuver le travail par rapport aux spécifications. Même si vous avez trouvé une faille et les avez suppliés de modifier les exigences, ils ne le feront probablement pas.


2

Malheureusement, ce que vous avez décrit est le point de vue typique du client sur la façon dont un projet logiciel doit être abordé. Cela ne veut pas dire que le client est déraisonnable; après tout - n'est-ce pas ainsi qu'on exécuterait la construction d'autre chose (une maison, par exemple?). Cela étant dit, je n'offre pas vraiment plus que ce que nous savons tous déjà. Ce que vous demandez, c'est ... est-il possible d'appliquer des pratiques agiles dans cette situation?

J'ai l'avantage de terminer un projet qui est semblable à bien des égards à la situation que vous décrivez, c.-à-d.

  1. Date limite fixe (dans la pierre, venez l'enfer ou les hautes eaux).
  2. Document d'exigences fonctionnelles ("la Bible"). Sans surprise insuffisant.
  3. Rôles traditionnels: Project Manager, Business Analyst.
  4. Utilisateurs professionnels faiblement engagés (pouvez-vous dire "pas de sponsor produit"?).

... et bien sûr, l'équipe de développement avant-gardiste essaie de travailler de manière agile, malgré ce qui précède:

  1. Itérations de 2 semaines;
  2. Debout;
  3. Rétrospectives;
  4. Programmation en binôme;
  5. TDD;
  6. Intégration continue.

Est-ce que tout cela a un sens à distance pour les entreprises? Non. Deux mois avant l'échéance, les itérations jusque-là soigneusement observées et les réunions de planification sont abandonnées dans une frénésie de poulet-sans-tête-itis.

Les réponses que d'autres ont fournies ci-dessus sont à des degrés plus ou moins élevés. À mon avis, l'agilité (qu'elle soit "agile" ou "agile") se fait "de façon pernicieuse" lorsque nous transigeons. À mon avis:

Il n'y a pas de compromis, ni d'agilité.

L'esprit même de l'agilité consiste à aller droit au but, à éliminer les déchets, à être brutalement honnête avec soi-même. Il est désormais bien documenté et indéniable que l'estimation de logiciels sur de grands projets est au mieux un pari. N'est-il pas de notre devoir, en tant que professionnels du logiciel, d'en informer les clients potentiels? Si les clients ne veulent pas accepter que nous soyons les experts, n'est-ce pas notre devoir professionnel de partir?


1

Quand j'ai commencé à travailler là où je suis maintenant, je me suis retrouvé à poser la même question que vous posiez souvent. Il y a quelque chose à dire pour la cascade avec les marchés publics. Ironiquement, l'agile est maintenant devenu un mot à la mode auprès des clients du gouvernement (qui fonctionnent de manière réaliste en cascade), nous nous retrouvons donc encore plus à mettre en œuvre un processus agile avec un client fondamentalement inflexible.

Nous avons un système qui a été décrit comme "Scrummerfall" "Agilefall" ou "A mess", mais à bien des égards, nous avons lentement pu adopter un processus de plus en plus agile car ce projet (gargantuesque) a progressé au fil des ans . L'une des façons dont nous l'avons fait consiste essentiellement à retrouver des canaux de communication avec les UTILISATEURS de notre système, par opposition à nos CLIENTS. Nos clients sont un département étouffant dirigé par des fonctionnaires nommés qui ne toucheront jamais à nos logiciels dans leur vie professionnelle et ne veulent pas le comprendre. Nos utilisateurs sont du personnel gouvernemental régulier sur le terrain qui tente d'accomplir une tâche importante. Pour nous, la clé pour établir une boucle de rétroaction de communication qui nous a permis d'être aussi agiles que nous était la nécessité de l'UAT (User Acceptance Testing).

À un stade précoce de notre projet, il a été décidé qu'un groupe représentatif D'UTILISATEURS RÉELS de divers bureaux de notre vaste client gouvernemental serait réuni ICI et nous aurions quelques semaines de temps avec eux pendant qu'ils parcourraient une série de tester des scripts pour tester notre logiciel. Tout comme une chose informelle, l'équipe des exigences a transformé cette fois-ci un moyen inestimable d'obtenir des commentaires des utilisateurs finaux réels. Pendant ce temps, l'équipe de test UAT au sein du gouvernement a travaillé à travers sa bureaucratie pour avoir de plus en plus d'influence sur le processus des exigences formelles de son côté, y compris les ordres de modification. Le résultat final est que les BA comme moi agissent en tant que propriétaires de produits intégrés dans les équipes Scrum et sont en mesure d'obtenir un temps inestimable avec des clients réels qui nous permettent de fonctionner de manière très agile.

De toute évidence, il y a beaucoup de problèmes, et nous ne sommes toujours pas vraiment agiles, mais nous sommes suffisamment agiles pour avoir été présentés comme un exemple de projet agile majeur utilisant effectivement cette méthodologie dans le secteur des marchés publics.

Pour résumer: utilisez votre expérience d'évangéliste agile au sein de votre propre organisation pour infiltrer votre client. Passez un processus d'apprentissage avec eux, établissez un partenariat basé sur la confiance avec les personnes clés de leur côté et travaillez AUTOUR du processus formel et ossifié d'exigences qu'ils ont inévitablement en place. Vous serez remercié par les gars sur le terrain qui doivent réellement utiliser ce que vous développez!


0

Vous supposez que les exigences sont bien écrites et vous pensez qu'elles signifient ce qu'elles pensent qu'elles signifient. Les allers-retours du processus agile aideront à garantir qu'ils obtiennent ce qu'ils voulaient en plus de ce qu'ils ont demandé.

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.