Les histoires d'utilisateurs sont trop élevées et trop conceptuelles, la direction s'attend à ce que les développeurs remplissent les blancs

Je suis employé dans une entreprise très brillante avec une véritable intention de faire XP. La communication est bonne et la direction est ouverte à des discussions constructives mais en raison de contraintes de temps pressantes, certaines choses sont considérées comme trop RUP pour être discutées.

Pour le moment, je suis un peu troublé par le volume de changement qui devient nécessaire lors de la mise en œuvre des histoires. Je crois que beaucoup de ces découvertes (qui prennent du temps et des efforts bien sûr) sont la responsabilité des auteurs (clients, utilisateurs finaux et propriétaires de produits) et non des développeurs. Pour résumer, les user-stories sont trop conceptuelles et ne font que transmettre l'intention sous-jacente mais manquent de détails (en particulier les pré-conditions et post-conditions, la pertinence pour d'autres histoires, les dépendances, etc.). On s'attend à ce que le développeur remplisse les blancs à sa seule discrétion en raison du fait que les développeurs XP sont à la fois concepteurs et analystes. Le problème est qu'un grand nombre de ces blancs sont découverts après que certaines hypothèses erronées ont fait leur chemin dans le temps et le code d'évaluation, car des complexités supplémentaires apparaissent comme prévu initialement. Même alors, trouver la bonne chose à remplir prend du temps qui est - à divers degrés - considéré comme un écart par rapport aux estimations initiales.

Je cherche un moyen constructif de transmettre ces implications à la direction d'une manière qui ne me présenterait pas comme quelqu'un qui essaie de compliquer inutilement les choses. Je suis nouveau et je n'ai pas encore acquis beaucoup de crédibilité.

Vos idées sont les bienvenues.

Étroitement lié et donne en quelque sorte une réponse: à combien de détails sur une user story un développeur peut-il s'attendre?

L'astuce n'est pas d'éviter qu'il y ait des blancs. L'astuce consiste à remplir ces blancs le plus tôt possible dans le processus de développement.

Vous avez raison de dire que si les développeurs font des suppositions, ils auront toujours tort et cela coûtera plus de temps à redévelopper le logiciel plus tard. Mais, également, si les hommes d'affaires sont censés faire une conception complète dès le départ alors qu'ils ne savent pas vraiment ce qu'ils veulent, la même chose se produira.

C'est une grande partie du travail d'un développeur de comprendre ce que veut le client, alors qu'il ne le sait souvent pas vraiment.

Posez d'abord des questions. Lorsque les réponses que vous obtenez semblent insatisfaisantes, créez un prototype. Montrez au client ce qu'il demande et laissez-le vous dire que ce n'est pas ce qu'il veut vraiment. Commencez avec un prototype papier, puis passez à un prototype HTML, sans code derrière. Faites ensuite le plus petit développement dont vous avez besoin pour produire un produit qui fonctionne presque et montrez-le-lui. Laissez les éléments délicats aussi tard que possible dans le processus.

Cela peut sembler long en soi, mais, par rapport au redéveloppement d'un produit supposé fini, ce n'est pas le cas.

Aussi, gardez les histoires aussi petites que possible. Invariablement, ce que l'entreprise veut, c'est une épopée, quelque chose qui peut être décomposé en de nombreux livrables. C'est mieux parce que vous n'aurez pas trop développé quand ils regardent le candidat à la version finale et crient "Oh non, ce n'est vraiment pas ce que nous recherchions."

Même alors, trouver la bonne chose à remplir prend du temps qui est - à divers degrés - considéré comme un écart par rapport aux estimations initiales.

Cela ne me semble pas très "XP".

Je ne suis en aucun cas un expert XP, mais AFAIK l'idée XP est d'adapter continuellement vos spécifications et votre estimation chaque fois que vous recevez des retours du processus. Et le processus consiste à «analyser un peu - concevoir un peu - coder un peu - tester un peu - puis obtenir les commentaires des utilisateurs pour corriger vos fausses hypothèses le plus tôt possible. Vous pouvez également essayer d'obtenir des commentaires des utilisateurs encore plus tôt , par exemple , après avoir conçu certaines parties de votre logiciel (comme l'interface utilisateur), sur une feuille de papier ou un tableau blanc et en avoir discuté avec un utilisateur ou un client . Je ne pense pas que la "méthode XP" interdit une telle approche simplement parce qu'elle a " Histoires d'utilisateurs".

Voici un bel article sur la façon d'obtenir des commentaires plus tôt en utilisant des spécifications. Je pense que ce type de pensée est indépendant de la "méthodologie", et les arguments qui y sont présentés vous aideront dans votre débat avec la direction.

Pour résumer, vous êtes dans la situation suivante:

1. Tu es nouveau.
2. Le projet (je suppose que vous parlez d'un projet en cours) a des contraintes de temps pressantes.
3. Le développeur devrait remplir les blancs à sa seule discrétion.
4. La société dans laquelle vous travaillez a l'intention de pratiquer XP. Cependant, les user stories ne semblent pas être appliquées d'une manière qui cadre avec la méthodologie XP. D'un autre côté, " le développeur devrait remplir les blancs à sa discrétion ".

Réfléchissez au point 4: Mon opinion est que les pratiques agiles doivent être adaptées aux besoins et à la culture d'une entreprise / équipe (et non l'inverse). Identifiez où l'entreprise s'en tient à la méthodologie XP et où elle s'écarte. C'est le fondement d'une approche constructive de vos préoccupations.

En raison de 1 et 2, vous n'êtes actuellement pas en bonne position pour vous demander si l'entreprise applique XP de manière raisonnable. Entamer une discussion avec la direction vous posera très probablement comme quelqu'un qui " complique les choses ". Cependant, vous pouvez commencer à discuter de vos préoccupations avec vos collègues développeurs. Vous trouverez peut-être des développeurs qui pensent comme vous. Il y a peut-être un développeur senior qui transmettra ensuite vos préoccupations à la direction. Mais ne vous attendez pas à ce que les choses changent rapidement, surtout pas dans le projet actuel. Cependant, le projet vous donnera une bonne occasion de collecter plus de données, ce qui ajoute plus de substance à une approche constructive.

Passons maintenant au point 3: je pense que les bonnes histoires d'utilisateurs sont rédigées en collaboration par les clients / utilisateurs finaux / propriétaires de produits et développeurs. Faites preuve d'initiative: cherchez une occasion de demander directement aux auteurs des récits d'utilisateurs. Si cela n'est pas possible, demandez à un développeur senior ou à la direction comment traiter les questions ouvertes auxquelles les auteurs des user stories doivent répondre. Vous pouvez peut-être au moins avoir une correspondance écrite. Étant donné que vous devez remplir les blancs à votre discrétion, votre choix devrait être d'impliquer activement les clients / utilisateurs finaux / propriétaires de produits.

À un moment donné, vous avez suffisamment réfléchi et observé la manière dont votre entreprise applique XP (ou les pratiques agiles en général). Peut-être qu'un certain temps s'est déjà écoulé et que vous n'êtes plus perçu comme un greenhorn. Votre implication active avec le client a peut-être montré des effets positifs. Peut-être que le prochain projet commence déjà. Peut-être que vous avez également déjà une sauvegarde d'autres développeurs. Peut-être que vous découvrez que la façon dont cela fonctionne n'est pas mauvaise du tout. Le fait est que vous aurez alors suffisamment d'idées pour transmettre vos préoccupations à la direction, sur la base d'une expérience réelle et de données au sein de votre entreprise.

Franchement, les user stories ne devraient pas avoir beaucoup de détails. "Je veux que le logiciel fasse X, pour répondre aux besoins commerciaux de Y" devrait être suffisant. Après tout, vous ne voulez pas que les gens d'affaires dictent comment le faire - vous êtes l'expert du logiciel et des meilleures pratiques.

Cela dit, les développeurs doivent également demander : "comment pensez-vous que cela fonctionnera?", "Que se passe-t-il lorsque cela interagit avec la fonctionnalité Z?". Les développeurs ne font pas d'exigences, ils font l'implémentation.

Il semble également qu'il y ait trop d'écart entre la mise en œuvre et l'évaluation. Les parties prenantes devraient examiner des prototypes, du code à moitié fait tous les quelques jours. Cela vous permet d'obtenir des commentaires avant d'aller trop loin dans les mauvaises herbes.

Si on vous demande d'estimer une histoire qui vous semble incomplète, faites savoir que vous avez des questions sur l'histoire et que vous ne pouvez pas donner une estimation correcte avant de répondre à ces questions.

Ensuite, posez vos questions et assurez-vous que les réponses font partie de l'histoire.

Si vous êtes obligé de donner une estimation même si vos questions ne reçoivent pas (toutes) de réponse, vous pouvez choisir de refuser de donner une estimation ou d'indiquer clairement que vous supposez les pires résultats possibles pour les blancs restants de votre estimation (ce qui fera probablement de votre estimation une valeur aberrante élevée).

Ce que vous faites n'est pas un mode de développement agile. Au lieu de cela, vous travaillez avec de faibles exigences de qualité. Il est faux qu'un mode de développement agile ne consiste pas à spécifier des exigences.

Au lieu de cela, ils doivent d'abord spécifier autant que possible et, si nécessaire, les modifier ultérieurement. Ensuite, vous divisez votre travail en parties et l'implémentez en itérations. Après chaque itération, vous avez quelque chose de fini.

La différence avec le développement de la cascade est dans le développement de la cascade, tout est mis en œuvre avec les exigences initiales et changé à la fin.

Il semble que les développeurs soient complètement retirés de la création des user stories. Vous attendez-vous simplement à pouvoir les lire comme une spécification détaillée et à les construire correctement la première fois? Si vous pouviez le faire, vous n'auriez pas besoin d'XP ni d'aucune autre méthodologie agile.

Quelqu'un devrait poser des questions si l'histoire est trop vague. Où se déroule le test d'acceptation ?

Les histoires d'utilisateurs sont censées changer. Vous devez y faire face.

Bien qu'un développeur puisse écrire une histoire / des exigences détaillées, je n'en ai pas vu beaucoup qui sont bons dans ce domaine. nous sommes bons pour signaler les problèmes, suggérant de meilleurs flux mais en tant que contribution à un cas déjà bien écrit.

Ont travaillé sur des produits nouveaux et existants et dans les deux cas, les exigences étaient de seulement 5 lignes et nous devions remplir les blancs et faire un document «compréhensif» ou plus élaboré.

Les projets ont beaucoup mieux progressé que nous avions notre propre service professionnel qui a aidé à cela (ou dans un cas, un vice-président qui est intervenu car il n'y avait personne d'autre disponible). Quoi qu'il en soit, c'est une perte de temps à développer (à moins qu'aucun retour ne revienne et que la date limite n'ait pas changé). donc ma suggestion: demandez plus de détails, fournissez plus, demandez des commentaires limités dans le temps à vos hypothèses et à votre documentation et déclarez que cela risque d'être retravaillé et retardé si vous n'obtenez pas ces informations avant la date x.

Quelle que soit la méthodologie de développement, si tout ce que vous utilisez pour définir les exigences fait que le développeur émet des hypothèses, il doit être renvoyé au côté commercial. J'ai souvent une bonne idée de la réponse que je préfère, alors je bosse les choses comme ceci:

XYZ n'est pas clair pour moi. Cela signifie-t-il ABC? Ou est-ce que je manque quelque chose? (Supposons que XYZ est l'exigence, supposons que ABC est l'hypothèse que je voudrais faire en tant que développeur)

Il faut beaucoup moins de temps pour clarifier les choses avant de faire de mauvaises hypothèses que de refaire. Les développeurs qui font des suppositions sur les exigences sans obtenir la confirmation que leur supposition est bonne ont tendance à être de mauvais développeurs et ils coûtent cher à leur entreprise. Si un mauvais manager ne vous permet pas de faire marche arrière, expliquez-lui combien cela coûte plus cher en termes de temps et d'argent. S'il insiste encore, alors faites ce qu'il dit et quand il échouera UAT, la prochaine fois que vous voudrez faire quelque chose, rappelez-lui combien il était coûteux de ne pas vous laisser faire. S'il n'écoute toujours pas, trouvez un meilleur patron.

L'autre valeur de donner un coup de pied en arrière est que, progressivement, l'entreprise apprendra ce dont vous avez besoin et vous donnera de meilleures exigences.

En tant que développeur,

J'ai besoin de bien comprendre les spécificités d'une user story,

afin que je puisse l'estimer et le mettre en œuvre en toute confiance.

En d'autres termes, vous devez poser des questions jusqu'à ce que vous compreniez les détails de l'histoire. Cela se fait dans la planification des itérations et sert de point de décision: si vous ne pouvez pas l'estimer, vous ne pouvez pas le construire.