Comment développez-vous des logiciels sans critères d'acceptation?
Comment développez-vous en collaboration un logiciel dans une équipe de 4 à 5 développeurs sans critères d'acceptation, sans savoir ce que les testeurs vont tester et avec plusieurs (2-3) personnes agissant en tant que product owner.
Tout ce que nous avons est une "spécification" sommaire avec quelques captures d'écran et quelques puces.
On nous a dit que ce sera facile, donc ces choses ne sont pas nécessaires.
Je ne sais pas comment procéder.
Information additionnelle
On nous a imposé une date butoir.
Le client est interne, nous avons un propriétaire de produit en théorie, mais au moins 3 personnes testant le logiciel peuvent faire échouer un élément de travail simplement parce qu'il ne fonctionne pas comme il le devrait et qu'il y a peu ou pas de transparence de ce qu'ils attendent ou ce qu'ils testent réellement jusqu'à ce qu'il échoue.
les propriétaires de produits ne sont pas facilement disponibles pour répondre aux questions ou donner des commentaires. Il n'y a pas de réunions régulières ni d'appels avec eux et les commentaires peuvent prendre des jours.
Je peux comprendre que nous ne pouvons pas avoir une spécification parfaite, mais j'ai pensé qu'il serait "normal" d'avoir des critères d'acceptation pour les choses sur lesquelles nous travaillons réellement dans chaque sprint.
Un processus itératif y parviendra bien, sans spécifications détaillées.
Créez simplement un prototype sommaire, demandez des commentaires au client, apportez des modifications en fonction des commentaires et répétez ce processus jusqu'à ce que la demande soit terminée.
La question de savoir si le client est suffisamment patient pour procéder de cette manière est une autre question. Certains clients et développeurs préfèrent en fait ce processus; puisque le client est toujours sur le terrain, il obtiendra (éventuellement) exactement ce qu'il veut.
Il va sans dire que vous n'allez pas travailler de cette façon avec un contrat à prix fixe ou à durée déterminée.
Si ce que vous dites est vrai et que les spécifications sont loin d'être suffisantes pour que vous puissiez même commencer (et vous êtes honnête dans cette évaluation), je recommande cette approche:
- Lisez les croquis et les spécifications "sommaires" qui vous ont été remis.
- Écrivez votre propre spécification à un niveau qui est juste assez pour que vous puissiez coder. Vous devrez peut-être faire une tonne de suppositions.
- Montrez vos spécifications au client pour examen. Notez les parties qu'ils aiment et obtenez plus d'informations sur les parties où ils pensent que vous vous êtes trompé.
- Répétez les étapes 2 et 3 jusqu'à ce que vous et le client soyez synchronisés.
- Vous avez maintenant une spécification adéquate.
Si votre client avait raison quand il a dit "ce sera facile", alors cet exercice devrait être un jeu d'enfant.
Si votre client s'est trompé et qu'il y a en fait toutes sortes de problèmes et de lacunes dans les exigences, votre projet de spécification illustrera rapidement le problème et leur communiquera qu'il s'est trompé (sans que vous ayez besoin de pointer du doigt ou d'argumenter) car il être juste devant eux et évident. En outre, votre spécification servira d'outil de discussion idéal pour résoudre ces ambiguïtés et servira d'enregistrement des décisions clés que vous réviserez avec leurs commentaires.
Le propriétaire du produit vous a remis un prototype; rendez-lui les meilleurs (jusqu'à ce que vous ayez terminé)
Il semble que l'on vous ait fourni un prototype papier pour démarrer le projet. Ce n'est pas un début terrible. Je vous suggère de communiquer au propriétaire de l'entreprise dans la même langue , en fournissant des prototypes progressivement capables.
Vos prototypes devraient commencer avec du papier, passer à des maquettes numériques, puis être construits avec des technologies "réelles".
Treehouse a un excellent guide pour cela, qui conclut:
La chose merveilleuse au sujet du prototypage avec un cadre est que le prototype devient souvent juste le vrai site parce que la structure et le style sont déjà en place. Il n'est pas nécessaire de recréer le site à partir de zéro s'il utilise le même framework.
Vous souhaiterez peut-être également fournir une spécification formelle, surtout si vous craignez toujours d'être blâmé pour un mauvais résultat. Mais vous obtiendrez probablement plus de commentaires des prototypes.
Respectez votre date limite
Notez que vos efforts ultérieurs ne seront pas tous des "prototypes" classiques, car ils ne seront pas jetables (ou des parties d'entre eux ne le seront pas). La dernière itération la plus performante que vous effectuez avant la date limite devient votre livrable.
Votre échéance est l'exigence la mieux définie que vous ayez. Ayez quelque chose de complet et de cohérent que vous pouvez livrer à temps.
Collaborez avec vos testeurs
Si ce processus lâche est une chose nouvelle pour votre entreprise, vos testeurs sont probablement encore plus à perte que vous, et peuvent chercher à vous des conseils. Vous devez obtenir un peu de leur temps au début du processus. Faites savoir à votre patron que vous essayez de l'aider à fournir un test significatif sans recevoir de critères d'acceptation formels.
Découvrez si les testeurs ont quelque chose de solide à fournir, comme une preuve de test, dans laquelle vous pouvez "revenir".
Essayez Testez la première conception
Comme vous n'avez pas d'exigences formelles, le développement de cas de test fournirait une certaine structure.
Obtenez une familiarité passagère avec Test First Design et/ou développement piloté par les tests et fournissez des conseils à vos testeurs sur le processus si nécessaire. Pour un projet rapide comme celui-ci, vous n'avez pas besoin de devenir expert dans le processus. Mais en utilisant une méthodologie éprouvée, vous réfléchirez bien sur vous et vos testeurs.
Respectez les normes, en particulier pour l'interface utilisateur
Vous n'avez pas d'exigences concernant l'apparence, mais vous avez un délai. Utilisez le travail de conception de quelqu'un d'autre pour minimiser le travail que vous devez faire pour créer un artefact d'aspect professionnel.
Choisissez une interface utilisateur standard pour votre site et ne la personnalisez que si/jusqu'à ce que vous y soyez invité. Je ne sais pas pour quelle plateforme vous développez, mais Bootstrap ou Google Material Design sont deux exemples.
Communiquez, mais ne harcelez pas
Je suggère d'envoyer un e-mail au propriétaire du produit par jour. N'envoyez plus que cela en cas d'urgence.
Si vous avez des questions, décrivez comment vous allez procéder si vous ne recevez pas de conseils. Par exemple:
Les utilisateurs de cette application devront-ils y accéder avec des appareils mobiles? En ce moment, nous supposons que ce sera un système de bureau/ordinateur portable uniquement.
Pas de panique
J'ai participé à de nombreux projets pour des gens qui ne connaissaient pas le terme "exigence". La plupart ont réussi. Les propriétaires de produits mains libres vous donnent la latitude de créer d'excellentes solutions.
Notez que certains propriétaires de projets dans ces projets étaient impossibles à satisfaire et se sont cachés derrière l'excuse "Je suis trop occupé pour ..." pour leur incompétence. Mais la plupart étaient "ravis" des résultats finaux.
n projet est l'acte de réduire l'incertitude jusqu'à ce que la certitude soit atteinte:
- Il y a toujours un certain degré d'incertitude au début. Parfois, c'est une petite ambiguïté dans les exigences. Parfois, c'est très sommaire. Vous devrez vous entraîner dans le cadre du travail.
- L'astuce consiste à réduire de manière itérative cette incertitude (en combinant l'analyse, la conception et la mise en œuvre), en affinant les user stories et en mettant en œuvre votre système.
- Les cas/scénarios de test et les critères d'acceptation devront être clarifiés de la même manière. Ils contribueront à réduire l'incertitude sur la qualité et l'exactitude (entre autres).
- Au final, une certitude suffisante est atteinte: le client obtient un produit testé qui correspond à ses besoins et peut être utilisé.
C'est le principe de l'élaboration progressive: les exigences, les critères et les résultats seront élaborés étape par étape, tout comme la compréhension par le client de ses propres attentes et exigences à travers son implication dans le processus de développement.
Est-ce un problème?
Plus les exigences initiales sont vagues, plus l'incertitude est élevée et plus le temps nécessaire pour effectuer les tâches est élevé. Il s'agit donc simplement de savoir qui fera le travail supplémentaire et qui paiera les coûts.
La réponse à ces deux questions devrait figurer dans le contrat. Ou fera l'objet d'une négociation. Et le client doit accepter une implication supplémentaire (l'argument principal sera "ordures entrantes, ordures sortantes", bien que je vous conseille fortement de le présenter de manière plus diplomatique ;-))
" Il n'y a pas de réunions régulières ". Eh bien, pourquoi ne pas commencez par planifier des réunions régulières alors? Le seul fait que vous ayez plusieurs propriétaires de produits garantit que votre projet ne sera PAS facile, car chacune de ces personnes aura des exigences contradictoires qui DOIVENT être discutées en personne avec toutes les parties prenantes présentes.
De plus, je vous recommande vraiment, vraiment, vraiment gardez un journal de décision détaillé. Au minimum, vous notez tout ce que quelqu'un a décidé, avec la date et une liste des personnes qui étaient présentes lorsque la décision a été prise. Encore mieux si vous pouvez écrire POURQUOI quelque chose a été décidé tel quel. Peu importe qu'il s'agisse d'un fichier sur votre PC, d'une page dans votre wiki intranet ou d'un bloc-notes sur votre bureau. Le journal vous protège, vous et le projet: lorsqu'un testeur dit qu'un élément "échoue", vous pouvez signaler qu'il a été décidé de cette façon avec ces personnes, et ce n'est pas votre problème mais entre elles et les testeurs. Si cela conduit à modifier les spécifications, c'est bien, mais à ce stade, ils ne peuvent pas s'attendre à respecter l'échéance qu'ils avaient en tête - ou ils doivent réduire la portée ailleurs.
Un projet sans exigences claires, manque de leadership, pas de définition du fait (DoD), personne prêt à être responsable de s'assurer que vous avez les informations dont vous avez besoin pour faire votre travail en temps opportun et répondre leur échéance est une recette pour l'échec du projet.
Le développement itératif n'est pas une mauvaise suggestion, mais il nécessite une coopération étroite entre les propriétaires de produits et les développeurs. Essayez d'attirer l'attention de quelqu'un en disant: "Nous savons que nous allons avoir des questions. Qui peut être régulièrement disponible pour s'assurer que celles-ci reçoivent une réponse afin que la livraison du projet ne soit pas retardée? Planifiez des moments réguliers avec quelqu'un pour évaluer les progrès et supprimer les obstacles. S'ils ne se présentent pas ou refusent, effectuez un suivi avec une correspondance écrite polie et documentez les retards ou les non-réponses. Si les propriétaires de produits ne peuvent pas être disponibles, demandez-leur de fournir un représentant qui peut l'être.
En outre, une autre caractéristique du développement itératif est que un changement dans les exigences nécessite un changement dans le calendrier. Vous ne pouvez pas vous engager à respecter un délai si vous ne peut pas développer une chronologie, et vous ne pouvez pas développer une chronologie si vous n'avez pas une bonne idée de ce qui doit être fait. Au lieu de demander dogmatiquement une spécification, examinez la spécification actuelle, documentez toutes les questions que vous ou l'équipe avez concernant le fonctionnement, planifiez du temps avec les propriétaires de produits pour en discuter et documentez les réponses. Lorsque vous avez terminé, vous aurez vos spécifications en fonction de leurs décisions, que vous pourrez ensuite faire accepter par les propriétaires de produits (par écrit). Le but d'une spécification est de lever l'ambiguïté et de créer un DoD, ce qui est exactement ce qu'une session de questions/réponses pourrait fournir. S'il y a opposition à une spécification, ne l'appelez pas une spécification.
Ne croyez personne quand ils vous disent que ce sera facile . Parfois, c'est aussi simple que cela puisse paraître, et je pourrais le croire si (et seulement si) Je connais suffisamment les propriétaires de produits pour avoir pleinement confiance que les exigences sont vraiment aussi simples qu'ils le disent, et les spécifications qui m'ont été fournies sont explicites (sinon, je planifie une session de questions/réponses et je les documente). J'ai été dans trop de situations où facile du point de vue des opérations est incroyablement difficile du point de vue du développement, ou vous pensez que vous avez totalement terminé et vous entendez les mots de désespoir ("Oh, au fait, nous avons oublié ..."). Exemple ... "Tout ce que vous avez à faire est de lire ces fichiers PDF à partir d'un référentiel de documents", qui, lors des tests d'acceptation, se transforment en "Oh, nous avons oublié que certains d'entre eux ont été lus") sur le côté d'une manière complètement incohérente, et certains ont la mauvaise taille de page définie, et certains ont besoin de ces trois pages en annexe, et nous avons tous besoin de les afficher de la même manière. C'est vraiment facile à corriger, non? ".
Le fait est que cela pourrait être vraiment facile, et une réunion rapide pourrait le confirmer, vous permettant de documenter toutes les hypothèses et d'obtenir la confirmation qu'elles sont exactes et correctes. Je recommande de se lever pour éliminer les obstacles à l'écriture d'un code de travail qui répond à leurs attentes, car peu importe si vous marchez sur les orteils, quelqu'un sera probablement malheureux à la fin de toute façon. Si vous persistez à obtenir des réponses aux questions et à irriter quelqu'un, ils l'oublieront lorsque vous livrez un excellent produit à temps et conforme aux exigences. Si vous ne parvenez pas à obtenir des éclaircissements et ne livrez pas, personne ne se souviendra qu'ils vous ont dit de ne pas les bug.
Sans spécification, vous avez un travail d'équipe. Devenez agile.
Asseyez-vous avec l'OP et étoffez une/quelques petites histoire (s) de départ. "Nous allons livrer juste cet écran, avec juste ce bouton qui va 'bing!'". Installez-vous sur certains AC. Livrez l'histoire. Démontrer l'histoire. Il s'avère que les boutons doivent être rouges. Soulevez un bug ou une nouvelle histoire. Livrez les boutons qui vont bang et bang. Etc.
Spécifiez et fournissez en collaboration de petites tranches verticales qui sont fréquemment démontrées.
Si le client ne veut pas travailler avec vous de cette façon, cherchez une issue.