Agile peut-il être accompli sans implication du client?


23

Je n'ai pas pu écrire un livre sur Agile. J'ai travaillé dans plusieurs boutiques qui appellent leur processus Agile. L'un des principaux points du développement Agile est l'implication régulière des clients. Après un sprint, le travail peut être présenté au client pour obtenir ses commentaires. Rincez et répétez.

Le problème que je rencontre est que de nombreux clients ne veulent pas être impliqués. Ils préféreraient de loin une approche en cascade. Rassemblez les exigences à l'avance, puis revenez lorsque vous avez terminé. D'après mon expérience, la cascade ne fonctionne pas. Les clients ne savent pas ce qu'ils veulent tant qu'ils ne le voient pas. Le dilemme de la cascade est en outre propagé par une grande communauté de développeurs qui souhaitent avoir toutes les exigences à l'avance. De cette façon, ils savent ce qu'ils construisent, ils peuvent architecturer en conséquence, et le client est à blâmer parce qu'ils ont «approuvé» lesdites exigences.

Suis-je incorrect? Agile peut-il fonctionner sans implication du client? Si oui, comment et comment surmontez-vous les problèmes dont j'ai discuté?


12
Ne laissez pas «agile» devenir votre marteau pour que tout le reste ressemble à un clou qui a besoin de vous cogner.
Patrick Hughes

1
D'après mon expérience, la préférence pour les approches en cascade est généralement due à un manque de compréhension du fonctionnement du logiciel ou de la conception. La bonne nouvelle est que l'Agile n'est pas le gros problème, c'est l'attitude / compréhension du client. La mauvaise nouvelle est l'attitude du client.
Ben Brocka

@BenBrocka: Ce n'est pas très surprenant, étant donné que c'est pour cela que Waterfall a été spécialement conçu. L'auteur a voulu écrire un article sur ce à quoi pourrait ressembler un processus de développement créé par quelqu'un qui ne comprend pas le développement de logiciels et pourquoi un tel processus ne peut pas fonctionner. Ainsi, il a spécifiquement inventé Waterfall comme exemple d'un processus conçu par quelqu'un qui ne comprend pas le développement de logiciels et qui ne peut pas fonctionner. De toute évidence, il n'est pas surprenant que cela plaise aux personnes qui ne comprennent pas le développement de logiciels, et ce n'est pas une surprise…
Jörg W Mittag

@BenBrocka:… que cela ne fonctionne pas. Ce qui est surprenant est la raison pour laquelle tout le monde aurait même envie d'utiliser un processus qui est spécialement conçu pour ne pas fonctionner. Je suppose que personne ne prend la peine de lire le journal.
Jörg W Mittag

1
@ JörgWMittag L'adoption réelle de Waterfall (qu'ils réalisent que c'est une cascade ou non) est principalement due au fait qu'il s'agit d'un modèle standard de décisions commerciales; le patron veut quelque chose, le subordonné le fait, le client est content, non? Bien sûr, cela ne fonctionne pas mais c'est un joli modèle simple pour de beaux esprits simples :)
Ben Brocka

Réponses:


17

Comment est-ce possible? La nature même de la technique dicte une sorte de boucle de rétroaction entre le client et le développeur.

Certaines parties de votre équipe peuvent cependant agir en tant que clients «proxy» (un processus similaire à «manger votre propre nourriture pour chien») afin que vous puissiez «faire semblant» d'être agile, bien que cela ne soit pas aussi satisfaisant que d'obtenir un client réel retour d'information.

Qu'on le veuille ou non, le client sera impliqué dans le processus de conception; c'est juste une question de combien ils veulent que le remaniement coûte (plus il est retardé, plus il est cher).

Étant donné que le client veut «Big Design Up Front», les aider à comprendre qu'il faudra plus de temps et d'efforts de leur part pour obtenir la bonne conception la première fois.


5
Certaines parties de votre équipe peuvent toutefois agir en tant que clients "mandataires" - d'après mon expérience, les testeurs ont créé des "mandataires" assez efficaces du type que vous mentionnez. Quand j'étais moi-même testeur, je faisais parfois semblant de porter un costume de client pour ainsi dire. Une telle mandatement ont des limitations si - par exemple QA gars se plaignent de combien de temps il faut pour installer le produit pourrait tout simplement se sentir de cette façon parce qu'ils le font tous les jours alors que le client , il fait une fois par an ou deux
moucheron

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).Pour qui est-il vraiment plus cher? La plupart des clients ne considèrent pas que vous payez votre temps pour mettre en place leur vision actuelle d'une solution. Parfois, ils ont juste un problème et n'ont aucun moyen de savoir quelle devrait être la solution jusqu'à ce que vous leur disiez ce que ce sera. À ce moment-là, si ce que vous leur avez dit ne résout pas réellement leur problème, c'est VOTRE FAUTE et non le leur. Comment est-ce leur faute si vous avez mal compris leurs vrais problèmes en premier lieu? suite ...
maple_shaft

suite ... pourquoi devraient-ils payer pour cela? Juste pour sauver la face du client et ne pas complètement perdre toute chance de recommencer, vous devez vous retourner et faire le travail gratuitement car ils exigeaient le contrat à prix fixe en premier lieu. C'est l'attitude la plus répandue et exactement ce que vit P.Brian.Mackey. Les clients renforcent ces négociations et lorsque vous n'êtes que l'une des 100 startups essayant de marquer le contrat, le gars avec le contrat Agile réaliste et équitable devra attendre à la fin de la ligne. C'est DUR là-bas en ce moment.
maple_shaft

@maple_shaft: De toute évidence, vous avez été brûlé par cela. Mais, comme pour tout, cela se résume à des choix. Agile existe parce que la cascade a ses problèmes et que les gens ne sont pas parfaits. Si le client a été informé des risques et veut quand même une cascade, c'est son choix. C'est également le choix du magasin de logiciels de décider s'il vaut la peine de risquer une cascade sur un client qui ne comprend pas les risques ou nie la validité de ces risques.
Robert Harvey

@RobertHarvey Même un mauvais client dans une mauvaise économie est toujours un client et il reste allumé pendant quelques mois. Les risques pour le client dans le cas que j'ai mentionné sont minimes et limités à savoir s'ils ont reçu la solution promise à temps. Le risque pour le magasin de logiciels dans ce cas est de savoir si ce client douloureux à l'arrière va nous aspirer.
maple_shaft

7

La réponse courte à votre question est «non». Voici des commentaires sur certaines parties de votre question. Pour être précis, la plupart des réponses sont basées sur mon expérience personnelle et mon observation.

D'après mon expérience, la cascade ne fonctionne pas.

Waterfall est une méthodologie solide pour fournir des systèmes de complexité variable. Il est regrettable qu'il ne soit pas bien présenté ou compris. Cela s'explique notamment par le fait qu'il ne fait pas assez d'argent en concurrence avec la méthodologie du jour qui continue d'apparaître. Vous serez peut-être surpris de savoir que de nombreux systèmes bancaires, d'assurance et de fabrication ont été construits uniquement en utilisant l'approche Waterfall et que beaucoup d'entre eux sont toujours en production aujourd'hui. Il est triste que l'industrie du logiciel soit davantage basée sur le battage médiatique que sur la science.

Les clients ne savent pas ce qu'ils veulent tant qu'ils ne le voient pas.

Ceci est un mythe. Un gros aussi. Cela peut être le cas dans la conception / mise en page de pages Web, mais pour le traitement des données commerciales, la plupart des utilisateurs veulent quelque chose qui fonctionne. Certains de ces utilisateurs utilisent toujours des écrans AS / 400 et des moniteurs 3270 CICS avec RVB et ils peuvent faire leur travail avec ces outils. En outre, ces mêmes utilisateurs acceptent les systèmes SAP et ORACLE ERP sans avoir leur mot à dire dans la conception de l'interface (et parfois dans la fonctionnalité). La plupart des utilisateurs professionnels adapteront même leurs habitudes de travail et leurs flux si le système produit la bonne fonction. Ici, l'accent est mis sur la fonction et non sur l'aspect. Les gens d'affaires comprennent très bien comment ils font leur travail dans 90% des cas.

Le dilemme de la cascade est en outre propagé par une grande communauté de développeurs qui souhaitent avoir toutes les exigences à l'avance. De cette façon, ils savent ce qu'ils construisent, ils peuvent architecturer en conséquence, et le client est à blâmer parce qu'ils ont «approuvé» lesdites exigences.

Vous ne pouvez pas reprocher aux développeurs de vouloir savoir ce qu'ils construisent, car ces développeurs veulent rentrer cuisiner à la maison et presser leurs chemises pour un autre exercice après avoir passé environ 3 heures à apprendre la prochaine technologie. qui remplacera leurs compétences actuelles! Le jeu du blâme ne fait de personne un gagnant. Pensez en termes de rôles et de responsabilités de chaque partie et l'image sera très claire.

En conclusion, les chefs de projet, les programmeurs et les concepteurs Web ne remplacent pas les analystes commerciaux qui devraient savoir comment collecter les exigences auprès des utilisateurs finaux quelle que soit la méthodologie.


3
+1 - Pour les concurrents "les clients ne savent pas". Il s'agit de différents domaines ayant différents types de clients. C'est pourquoi les agilistes ne peuvent pas comprendre les gens en cascade. Ils croient que vous ne pouvez dire ce que vous voulez que lorsque vous le voyez. Ce n'est pas vrai, mais c'est tout ce qu'ils voient de leurs clients. Bien que les promoteurs des cascades ne comprennent pas pourquoi vous ne pouvez pas obtenir la majorité écrasante des exigences à l'avance afin que la conception puisse prendre en compte tous les problèmes. C'est probablement parce que les gens en cascade ne traitent pas beaucoup avec des clients bon gré mal gré.
Dunk

1
@Dunk, merci pour votre commentaire. J'aime votre libellé "" bon gré mal gré!
NoChance

2

Ils ne veulent pas mettre de temps et s'ils ont le choix, ils préfèrent obtenir des logiciels gratuitement, mais vous allez toujours les facturer, non? Cela devient flou si vous développez un logiciel en interne pour votre entreprise. Ils pensent que le département informatique a été acheté et payé (employés salariés), ils pourraient donc aussi bien obtenir de vous autant de travail qu'ils le peuvent.

Vous pouvez être potentiellement agile. Obtenez toutes les spécifications et commencez à coder. Une fois que le client a interrompu le travail parce qu'il a juste pensé à quelque chose et que vous devez apporter des modifications et des retouches, vous êtes devenu un peu plus agile. Vous pouvez également effectuer les approbations au sein de votre équipe. Demandez à un membre de votre équipe de mettre un costume et une cravate et de faire semblant d'être le client.

Prendre un engagement de temps important à l'avance peut les effrayer. Suggérez de faire un sprint pour l'essayer. Donnez-leur ensuite la possibilité de se retirer. Vous pouvez toujours passer à une cascade pour le reste du projet. Suggérez également que différentes personnes de leur équipe pourraient faire l'examen et approuver si le temps est une contrainte pour la personne qui écrit le chèque.

À un moment donné, vous devez leur dire que vous ne pensez pas que la cascade fonctionnera. Demandez-leur s'ils sont satisfaits de cette approche et si oui, pourquoi n'ont-ils pas le dernier gars à faire ce projet?


2

Aucune méthodologie ne peut fonctionner sans la participation du client. Avoir l'approbation des exigences peut être dénué de sens comme je l'ai vu dans les projets auxquels j'ai participé. Votre problème va au-delà de la capacité de faire de l'Agile, vous devez éduquer votre client et vous assurer qu'il comprend à quel point il est important pour lui de participer.


2
N'est-ce pas une question de montant et de fréquence de participation du client et pas une question de tout ou rien?
JeffO

3
Un client qui refuse de participer souvent est, à mon avis, un client qui a besoin d'éducation. Il n'est pas rare que les experts commerciaux du client se retrouvent dans une position où ils doivent interagir avec la société de développement de logiciels tout en effectuant leurs activités quotidiennes et cela doit être résolu en parlant à leurs supérieurs.
Otávio Décio

2

Je pense que l'un des principaux avantages d'Agile est la possibilité d'obtenir des exigences plus détaillées pour chaque fonctionnalité dans son ensemble. Lorsque le client donne toutes ses exigences à l'avance, chaque fonctionnalité a tendance à être une idée vague, avec un peu de fonctionnalités définies. Agile oblige le client à revoir chaque fonctionnalité et à se concentrer exactement sur ce qu'il veut et comment la fonctionnalité s'intégrera dans une vue d'ensemble. Pour obtenir cette même quantité de détails (suffisamment de détails pour implémenter les fonctionnalités) dans la spécification, la cascade vous oblige vraiment à faire l'une des deux choses suivantes:

  1. Deviner. Mettez en œuvre jusqu'à ce que vous rencontriez quelque chose de vague, puis jugez comment vous pensez que la fonctionnalité serait mieux mise en œuvre. Ce n'est évidemment pas idéal, car cela conduit au "Attendez, ce n'est pas ce que j'ai demandé!" scénario.

  2. Mettez beaucoup plus l'accent sur la conception dès le départ. Essentiellement, lorsque le client vous lance sa spécification à moitié cuite le premier jour, prévoyez de passer par chaque détail avant d'implémenter quoi que ce soit. Demandez au client de clarifier tout ad nauseum au point où vous connaissez chaque détail de mise en œuvre pour l'ensemble du projet. Bien que ce ne soit pas parfait, c'est mieux que l'option 1. Vous pouvez toujours rencontrer des détails que vous n'aviez pas prévus, et cela peut même envoyer le client courir pour les collines, mais s'il ne veut vraiment pas être en communication pendant le développement et vous ne sont pas psychiques, c'est une nécessité. Il s'agit essentiellement d'une cascade et de tous les inconvénients associés, notamment d'être extrêmement difficile à exécuter correctement.

  3. Prenez la spécification à moitié cuite, mais demandez des éclaircissements au fur et à mesure. Travaillez jusqu'à ce que vous atteigniez une partie vague de la spécification, puis demandez au client de clarifier. Bien sûr, ce n'est pas ce que le client a demandé, mais s'il ne veut pas d'une application aussi trouble que la spécification et refuse de définir la spécification à l'avance, c'est la seule option qui reste. Il n'a pas tous les avantages d'Agile (comme l'approbation régulière des clients pour s'assurer que tout le monde est sur la même page), mais il vous permet d'obtenir les informations dont vous avez besoin pour développer. Étant donné que l'option 1 vous laissera probablement un produit inférieur à la moyenne, l'option 2 est inutile et frustrante pour le client (vous devrez probablement consacrer au moins deux fois plus de temps à la conception et à la collecte des spécifications si vous le faites entièrement à l'avance), ce n'est vraiment pas une si mauvaise option. La clé ici est d'être diligent dans la modification des délais et des prix à chaque changement qui survient. Si vous le faites correctement, vous constaterez peut-être que la majorité des pratiques Agiles sont compatibles avec cet arrangement, même si le client ne le sait pas. À mon humble avis, cela correspond vraiment à l'esprit d'Agile, dans la mesure où vous êtes censé adapter les méthodologies à votre arrangement particulier.

Si le client ne peut vraiment pas vivre avec les conséquences de l'une de ces trois options ou Agile à part entière, j'ai du mal à imaginer comment ce client pourrait vraiment valoir la peine.


Vous avez omis l'option 4. Vous prenez la spécification avec la grande majorité des exigences. Faites la conception (probablement itérative) avec les commentaires des clients. Implémentez et testez le code (probablement itératif). Tenir des revues de programme périodiques informant le client des progrès et des décisions. Ils donnent leur avis, vous intégrez leurs commentaires et vous passez à autre chose.
Dunk

Les situations que vous décrivez ci-dessus ne se produiraient qu'avec des équipes qui ne savent pas faire de la cascade. Oui, il est difficile de l'exécuter correctement. Agile est également difficile à exécuter correctement. Chaque fois que quelqu'un échoue à l'agilité, un agiliste jette une nouvelle règle qui n'a pas été suivie et prétend que c'est la raison de l'échec. Ce n'est jamais la faute de l'agile. Au moins, les partisans de la cascade admettent qu'il faut de bonnes personnes avec de bonnes compétences pour faire fonctionner la cascade.
Dunk

Votre option 4 est exactement ce que j'avais l'intention de décrire dans l'option 3.
Morgan Herlocker

Comment pourrais-je améliorer ma réponse? Je ne peux pas dire si vous êtes d'accord ou pas d'accord avec ce que je dis.
Morgan Herlocker

Vous pouvez l'améliorer en supprimant peut-être le mot à moitié cuit pour commencer. Supprimer la partie à ce sujet n'est pas ce que le client voulait. Supprimez la partie trouble des spécifications, etc. En cascade, la partie importante de la capture des exigences est d'obtenir les éléments architecturaux importants et ceux que le système doit absolument faire pour être utile à l'avance. Après cela, les changements ne sont généralement pas si importants. Croyez-le ou non, il y a et il y a toujours eu des itérations, formelles ou informelles, dans le développement des chutes d'eau. Bien avant l'agilité.
Dunk

1

Je pense que c'est difficile mais toujours possible. Je pense que l'idée de proxy de Robert fonctionne, mais il est nécessaire que le proxy passe autant de temps que possible avec le «vrai» client afin qu'il puisse voir les choses de son point de vue. De cette façon, le proxy peut déterminer quelles fonctionnalités sont vraiment importantes et avoir une idée de l'expérience utilisateur que le client attend / désire.

Mais à un moment donné, vous devrez montrer le logiciel au «vrai» client ...


0

Il est possible d'éviter de vrais clients, en fait parfois c'est nécessaire pour la réglementation. Habituellement, les clients des logiciels médicaux ne sont pas impliqués. Dans ces cas, d'autres entités peuvent remplacer le rôle client, par exemple l'équipe marketing peut être considérée comme le client.


0

Agile nécessite la boucle serrée pour remplacer la grande conception initiale qui est difficile - assez difficile, mais en fait cela peut être fait, l'agile n'est pas le seul moyen.

Vous voudrez peut-être trouver l'une des modifications d'Agile - il y en a beaucoup et on résout probablement ce problème spécifique, mais sinon, inventez le vôtre si vous pensez que vous le pouvez.

Tous ces processus ont été créés par des personnes intelligentes - et des personnes intelligentes peuvent faire fonctionner n'importe quel processus. Vous ne pensez pas que la cascade a été inventée parce qu'elle n'a jamais fonctionné pour personne? Cela a évolué parce que certaines personnes pouvaient le faire fonctionner, et d'autres ont regardé et ont dit "Je dois affiner cela et le nourrir à MON équipe qui ne semble pas produire aussi efficacement" - à ce stade, cela a probablement mieux fonctionné que ce qu'ils faisaient, mais si vous ne reconnaissez pas que tous les programmeurs ne peuvent pas résoudre tous les problèmes, cela peut vraiment vous dérouter pourquoi deux équipes utilisant le même processus peuvent avoir des résultats différents.

Le problème est que de nombreux processus nécessitent du talent pour les mettre en œuvre - nous parlons de talents aussi rares que les joueurs de sport professionnels parmi un groupe de tous ceux qui ont déjà pratiqué un sport - il est probable que la plupart d'entre nous n'ont jamais rencontré quelqu'un capable de faire les processus de merde comme la cascade fonctionnent et c'est pourquoi tant de gens pensent que cela ne peut pas réussir - ils ne l'ont jamais vu fonctionner.

Il faut beaucoup moins de talent pour faire fonctionner Agile, mais cela nécessite des investissements très spécifiques tels que faire en sorte que le client regarde constamment ce que vous faites pour que les erreurs ne puissent pas se propager, et des choses comme une refactorisation impitoyable pour que vous ne développiez pas. une dette technique que l’équipe ne peut résoudre au bout de quelques mois.


0

Définissez le client.

Est-ce une autre entreprise? Un autre individu?

Est-ce une autre équipe au sein de votre entreprise?

Est-ce un champion des produits au sein de votre entreprise?

Est-ce toi?

Tout ce qui précède est possible et tout à fait raisonnable selon les circonstances. Vous ne voulez pas prendre une seule vue dans le tunnel sur ce que c'est que d'être Agile, donc dire un NON définitif serait incorrect. OUI en revanche nécessite un peu de réflexion latérale.

Réfléchissez un instant au mot Agile . Le groupe très intelligent de personnes qui ont inventé le terme n'aurait pas pu choisir une meilleure métaphore pour le concept qu'ils essayaient de décrire. Quand vous dites Agilité , qu'est-ce qui vous vient à l'esprit? Être flotte de pied? Rapide à réagir peut-être? Rapide à adapter?

Réfléchissez maintenant à toutes les pratiques Agile communément acceptées et demandez-vous ce qu'elles apportent vraiment aux méthodes de développement logiciel considérées comme Agiles .

Je suis le client à toutes fins utiles pour mes projets solo. Je porte même parfois un vrai chapeau, quand je veux vraiment faire un changement mental distinctif dans mon rôle de client . Cela ne me rend pas moins agile que moi quand je suis au travail. Pour tout ce qui m'importe, mon chat peut être le manager. Il s'assure que je prenne une pause de temps en temps, et me rappelle d'éviter de devenir trop obsédé par une seule tâche. Vous préférerez peut-être utiliser votre fantaisie "Pomadoro Technique", mais je préfère la minuterie "Rascal" !! Le fait est que je travaille dans un processus strictement Agile chaque fois que j'écris du code pour moi-même. Je ne suis pas du genre hacker-come-cowboy, qui vit une vie de pics de développement sans fin et ne fait rien. J'aime concevoir mon logiciel, planifier le développement autour de mon travail et de ma vie personnelle, et le terminer d'une manière que je m'attendrais à faire si je travaillais pour un vrai client. Lorsque les choses interrompent mon emploi du temps, j'ajuste et priorise mon travail de projet en conséquence. J'utilise toutes les pratiques et techniques Agile standard que je peux appliquer en solo et je "livre" travailler le code pour moi-même (ou un ami ou un collègue à tester) aussi souvent que possible. Si tout cela n'est pas Agile, je vous demande ce que c'est?

Donc ma réponse est Oui , vous pouvez être un développeur de logiciels Agile, et vous pouvez appliquer une méthodologie Agile, et vous n'avez pas nécessairement besoin du client, ni même du gestionnaire. Vous pouvez travailler seul sur un projet et porter plusieurs chapeaux. Cependant, il n'est pas nécessairement idéal de supprimer ces autres rôles, car il est très utile de coopérer avec d'autres pour atteindre un objectif. Ils agissent comme une caisse de résonance pour vos idées, et ils nourrissent des exigences que vous pourriez autrement trouver difficile à générer de manière sensible par vous-même. L'autre rôle très important que le client et le gestionnaire remplissent est de vous garder concentré sur vos objectifs, sans ajouter sans cesse de fonctionnalités et affiner votre code au-delà de ce qui peut être strictement nécessaire.

Pourtant, si vous travaillez de manière disciplinée, en vous en tenant strictement à la méthodologie de votre choix et en appliquant des pratiques Agiles, et si, lorsque vous vous faites distraire, ou si vous changez d'avis (lorsque vous portez votre chapeau de client) et la conception ou la direction de votre produit prend un tour, si vous pouvez adapter votre emploi du temps et ajuster vos priorités comme vous l'imaginez, votre client vous attend, alors vous êtes Agile.

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.