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?
la source
Réponses:
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.
la source
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:
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.
la source
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.
Jusqu'à modification par un ordre de modification.
Le canal de communication est l'ordre de changement. Impact sur le budget et le calendrier.
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.
Sauf pour les ordres de modification. Qui modifient Y et la date limite.
«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.
la source
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:
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.
la source
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.
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.
Si vous savez ce qu'ils veulent, allez le construire.
Vous ne pouvez pas perdre sur celui-ci. Construisez-les comme bon vous semble.
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.
la source
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.
... et bien sûr, l'équipe de développement avant-gardiste essaie de travailler de manière agile, malgré ce qui précède:
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?
la source
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!
la source
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é.
la source