Comment développez-vous des logiciels sans critères d'acceptation?

Comment développer 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 propriétaire du produit.

Tout ce que nous avons, c'est une «spécification» sommaire avec des captures d'écran et quelques points de balle.

On nous a dit que ce serait facile, donc ces choses ne sont pas nécessaires.

Je ne sais pas comment procéder.

Information additionnelle

On nous a donné une échéance difficile.

Le client est interne, nous avons en théorie un propriétaire de produit, mais au moins trois personnes qui testent le logiciel risquent d’échouer un élément de travail simplement parce que cela ne fonctionne pas comme il le devrait et qu’il ya peu ou pas de transparence quant à ce qu’ils attendent. ce qu’ils testent jusqu’à ce qu’il échoue.

les propriétaires de produits ne sont pas facilement disponibles pour répondre aux questions ou donner leur avis. Il n'y a pas de réunions ou d'appels réguliers avec eux et les retours peuvent prendre des jours.

Je peux comprendre que nous ne puissions 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 à chaque sprint.

Un processus itératif y parviendra bien, sans spécifications détaillées.

Créez simplement un prototype sommaire, demandez les commentaires du client, apportez des modifications en fonction de ces commentaires et répétez ce processus jusqu'à la fin de l'application.

Que le client soit assez patient pour le faire de cette façon est une question différente. Certains clients et développeurs préfèrent réellement ce processus; comme le client est toujours actif, il obtiendra (éventuellement) exactement ce qu'il veut.

Il va sans dire que vous n'allez pas travailler de cette manière avec un contrat à prix fixe.

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 vous recommande cette approche:

1. Lisez les croquis et la spécification "sommaire" qui vous a été donnée.
2. Ecrivez vos propres spécifications à un niveau suffisant pour pouvoir coder. Vous devrez peut-être faire une tonne de suppositions.
3. 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é.
4. Répétez les étapes 2 et 3 jusqu'à ce que vous et le client soyez synchronisés.
5. Vous avez maintenant une spécification adéquate.

Si votre client avait raison lorsqu'il a dit "ce sera facile", cet exercice devrait être un jeu d'enfant.

Si votre client s'est trompé et qu'il existe en fait toutes sortes de pièges et de lacunes dans les exigences, votre brouillon de spécification illustrera rapidement le problème et leur indiquera qu'ils se sont trompés (sans que vous ayez à pointer du doigt ou à argumenter) car être juste en face d'eux et évident. En outre, vos spécifications constitueront un excellent outil de discussion pour résoudre ces ambiguïtés et serviront à enregistrer les décisions clés au fur et à mesure que vous les réviserez avec leurs commentaires.

Le responsable du produit vous a remis un prototype. remettez-lui les meilleurs (jusqu'à ce que vous ayez terminé)

On dirait que vous avez reçu un prototype en papier pour démarrer le projet. Ce n'est pas un début terrible. Je vous suggère de communiquer avec le propriétaire de l'entreprise dans la même langue , en fournissant des prototypes de plus en plus performants.

Vos prototypes doivent commencer avec du papier, des maquettes numériques, puis être construits avec de «vraies» technologies.

Treehouse a un excellent guide pour cela, qui conclut:

Ce qui est merveilleux avec le prototypage avec une structure, c'est que le prototype devient souvent le véritable site, car 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 doit utiliser le même framework.

Vous voudrez peut-être également fournir une spécification formelle, surtout si vous continuez à craindre de vous faire reprocher un mauvais résultat. Mais vous aurez probablement plus de retours des prototypes.

Respecter votre délai

Notez que vos efforts ultérieurs ne seront pas des "prototypes" classiques, car ils ne seront pas jetables (ou des parties d’eux ne le seront pas). La dernière itération, la plus performante, que vous complétez avant la date limite devient votre produit livrable.

Votre délai est la condition la mieux définie. Avoir quelque chose de complet et 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 à une perte que vous êtes, et peuvent chercher à vous pour des conseils. Vous devez obtenir une partie de leur temps tôt dans le processus. Dites à leur supérieur que vous essayez de les aider à fournir un test significatif sans recevoir de critères d’acceptation formels.

Découvrez si les testeurs ont quelque chose de ferme à fournir, comme une documentation de preuve de test, dans laquelle vous pouvez «revenir».

Essayez Test First Design

Étant donné que vous n'avez aucune exigence formelle, le développement de cas de test fournirait une structure.

Familiarisez-vous avec Test First Design et / ou avec le développement piloté par les tests et guidez vos testeurs sur le processus, le cas échéant. Pour un projet rapide comme celui-ci, vous n'avez pas besoin de devenir un expert du processus. Mais utiliser une méthodologie éprouvée aura des effets positifs sur vous et vos testeurs.

S'en tenir aux normes, en particulier pour l'interface utilisateur

Vous n'avez pas d'exigences concernant l'apparence, mais vous avez une date limite. Utilisez le travail de conception de quelqu'un d'autre pour minimiser le travail que vous devez faire pour créer un artefact de qualité professionnelle.

Choisissez une interface utilisateur standard pour votre site et ne la personnalisez que si / jusqu'à ce que vous y soyez dirigé. Je ne sais pas pour quelle plate-forme vous développez, mais Bootstrap ou Google Material Design en sont deux exemples.

Communiquer, mais ne pas harceler

Je suggère d'envoyer un email 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 procéderez si vous ne recevez pas de conseils. Par exemple:

Les utilisateurs de cette application devront-ils y accéder avec des appareils mobiles? À l'heure actuelle, nous supposons qu'il s'agira d'un système destiné uniquement aux ordinateurs de bureau / portables.

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 sans contact vous donnent la latitude nécessaire pour élaborer d'excellentes solutions.

Notez que certains propriétaires de ces projets étaient impossibles à satisfaire et se cachaient derrière l'excuse «je suis trop occupé pour…» pour leur incompétence. Mais la plupart ont été «ravis» des résultats finaux.

Un projet consiste à réduire l'incertitude jusqu'à l'obtention de la certitude :

• Il y a toujours un certain degré d'incertitude au début. Parfois, les exigences sont un peu ambiguës. Parfois, c'est très sommaire. Vous devrez vous entraîner dans le cadre de votre travail.
• L'astuce consiste à réduire de manière itérative cette incertitude (en combinant analyse, conception et implémentation), en affinant les user stories et en implémentant votre système.
• Les cas / scénarios de tests et les critères d'acceptation devront être clarifiés de la même manière. Ils contribueront à réduire les incertitudes sur la qualité et la correction (entre autres).
• À la fin, une certitude suffisante est atteinte: le client obtient un produit testé qui répond à 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, de même que le client comprendra mieux ses propres attentes et exigences à travers son implication dans le processus de développement.

Est-ce un problème ?

Plus les exigences initiales sont grandes, plus l'incertitude est grande et plus le temps nécessaire à l'exécution des tâches est long. Il s’agit donc simplement de savoir qui fera le travail supplémentaire et qui paiera les coûts.

La réponse de 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 "Des ordures", mais je vous conseillerais vivement de le présenter de manière plus diplomatique ;-))

" Il n'y a pas de rendez-vous réguliers ". Pourquoi ne pas commencer par planifier des réunions régulières ? 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 de garder un journal de décision détaillé . Au minimum, vous écrivez tout ce que quelqu'un a décidé, avec la date et une liste des personnes présentes lors de la prise de décision. Encore mieux si vous pouvez écrire POURQUOI quelque chose a été décidé ainsi. Peu importe qu'il s'agisse d'un fichier sur votre PC, d'une page de votre wiki intranet ou d'un ordinateur portable sur votre bureau. Le journal vous protège, ainsi que le projet: lorsqu'un testeur dit qu'un élément «échoue», vous pouvez indiquer que c'est ce qui a été décidé de cette façon avec ces personnes, et que ce n'est pas votre problème, mais entre elles et les testeurs. Si cela conduit à un changement des spécifications, alors 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 en réduire la portée ailleurs.

Un projet sans exigences claires, un leadership lâche, aucune définition de ce qui est fait (DoD), personne prêt à être tenu responsable pour s'assurer que vous disposez des informations dont vous avez besoin pour effectuer votre travail à temps et dans les délais impartis, c'est une recette pour le projet échec.

Le développement itératif n’est pas une mauvaise suggestion, mais il nécessite une coopération étroite entre les propriétaires du produit 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 les réponses sont données afin que la livraison du projet ne soit pas retardée? Planifiez des heures régulières avec quelqu'un pour examiner les progrès et éliminer les obstacles. S'ils ne montrent pas ou refusent, faites un suivi avec votre correspondance écrite et polie et documentez les retards ou les non-réponses. Si les propriétaires de produits ne peuvent pas être disponibles, demandez-leur de vous fournir un représentant.

Une autre caractéristique du développement itératif est également qu'un changement dans les exigences nécessite un changement dans la chronologie. Vous ne pouvez pas vous engager à respecter une date limite si vous ne pouvez pas élaborer de calendrier, et vous ne pouvez pas développer de calendrier si vous n'avez pas une bonne idée de ce qui doit être fait. Au lieu de demander dogmatiquement une spécification, passez en revue la spécification actuelle, documentez toutes les questions que vous-même ou l'équipe avez concernant son fonctionnement supposé, programmez du temps avec les propriétaires du produit pour en discuter et documentez les réponses. Une fois que vous avez terminé, vous aurez vos spécifications basées sur 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 les ambiguïtés et de créer un DoD, exactement ce qu'une session de questions-réponses pourrait fournir. S'il y a opposition à une spécification, n'appelez pas cela une spécification.

Ne croyez personne quand on vous dit que ce sera facile . Parfois, c’est aussi simple que cela puisse paraître, et je pourrais le croire si (et seulement si ) je connaissais assez bien les propriétaires du produit pour pouvoir me faire une confiance totale dans le fait que les exigences sont aussi simples qu’elles le prétendent, et les spécifications que j’ai été fournis sont explicites (sinon, je programme une session de questions / réponses et la documente). J'ai été dans trop de situations où la facilité d'opération est incroyablement difficiledu point de vue du développement, ou si vous pensez que vous avez totalement terminé et que 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 dans un référentiel de documents", ce qui, lors des tests d'acceptation, devient "Oh, nous avons oublié que certains d'entre eux ont été lus de manière totalement incohérente, et la taille de certaines pages est mal définie et d’autres nécessitent l’ajout de ces trois pages, et nous avons besoin qu’elles affichent toutes la même chose. C’est très facile à corriger, non? ".

Le fait est que cela pourrait être vraiment facile et une réunion rapide pourrait confirmer cela, vous permettant de documenter toutes les hypothèses et d'obtenir la confirmation qu'elles sont exactes et correctes. Je vous recommande de vous lever afin de lever les obstacles à la rédaction d'un code fonctionnel qui réponde à leurs attentes, car peu importe si vous marchez ou non, quelqu'un sera probablement malheureux au final. Si vous persistez à vouloir obtenir des réponses à vos questions et que vous énervez quelqu'un, il l'oubliera lorsque vous livrerez un excellent produit dans les délais impartis. 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 déranger.

Sans spécification, vous avez un travail d'équipe. Go Agile.

Asseyez-vous avec le PO et développez une / quelques petites histoires de départ. "Nous allons livrer uniquement cet écran, avec juste ce bouton qui va" bing! "". Installez-vous sur certains AC. Livrer l'histoire. Démontrez l'histoire. Il s'avère que les boutons doivent être rouges. Relevez un bug ou une nouvelle histoire. Livrer les boutons qui vont bang et bang. Etc.

Spécifiez et distribuez de manière collaborative de petites tranches verticales qui sont fréquemment démontrées.

Si le client ne travaille pas avec vous de cette manière, cherchez une issue.

J'ai passé plusieurs emplois à faire des projets tels que vous les avez décrits. Tant que le bon de commande sait quelles décisions de conception vous prenez et pourquoi vous devez les prendre, tout devrait bien se passer. Si, en revanche, ils ne comprennent pas les décisions de conception, vous devez les appuyer au moins pour obtenir un document de test d'acceptation utilisateur écrit.

Avant de pouvoir écrire du code, vous avez besoin d’une spécification détaillée et vérifiable. C'est un fait et il n'y a pas moyen de le contourner.

Si personne d'autre ne souhaite écrire cette spécification, les développeurs doivent l'écrire. Donc, vous obtenez une spécification incomplète. Vous le transformez en une spécification complète (ce qui signifie "voici ce que je vais implémenter, sauf si quelqu'un d'autre me dit de ne pas le faire"). Vous remettez cette spécification aux parties prenantes et leur donnez une chance de la modifier. Seule une chance de modifier la spécification - ne pas la spécifier, par exemple en disant "je ne l’aime pas de cette façon". À ce stade, il s'agit de votre spécification, ou ils peuvent fournir une spécification différente, mais pas supprimer la spécification.

Il peut être judicieux d’obtenir un bref aperçu de vos collègues qui pourraient améliorer les spécifications. Mais de toute façon, vous avez une spécification, vous écrivez le code en conséquence, les testeurs testent en conséquence. Et vous avez fait votre travail: vous aviez une spécification et l'avez implémentée. Si la spécification n’est pas ce que le client souhaite, c’est la responsabilité du propriétaire du produit ou du client qui ne se soucie pas d’écrire une bonne spécification.