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

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é?

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.

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.

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?

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.

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.

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 ...

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.

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.

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.