Que proposez-vous dans les deux premières itérations d'Agile?

22

Si je comprends bien, l'idée avec les méthodologies Agile est que vous livrez quelque chose de fonctionnel et que vous le livrez souvent. L'application prend sa forme finale incrément après incrément.

Mais dans les premières itérations, vous pourriez construire le cadre ou les fondations sur lesquelles l'application reposera, c'est donc quelque chose d'important mais non visible pour les utilisateurs.

Qu'est-ce qui est livré au client dans ces premières itérations? Comment montrez-vous les progrès dans la bonne direction lorsque vous créez du code d'échafaudage?

JohnDoDo
la source
2
La construction d'un cadre ou d'une fondation doit être une décision prise le plus tard possible dans le projet.
JeffO
@JeffO: que voulez-vous dire le plus tard possible? Pouvez-vous développer cela en une réponse?
JohnDoDo
5
Idéalement, cela ne devrait pas du tout être une décision. Un cadre ne doit pas être créé, il doit émerger de manière organique à la suite d'une refactorisation. Aucun «bon» cadre (pour ma propre définition subjective de «bon») n'a jamais été conçu à partir de zéro, ils ont été extraits après coup des applications existantes ou basés sur d'autres cadres qui l'étaient.
Jörg W Mittag
7
@JohnDoDo construire une fondation à l'avance suppose que vous savez quelles seront les exigences de votre application avant même qu'elle n'existe. Chaque fois que j'ai vu des gens faire cela, ils se sont retrouvés avec quelque chose de rigide et très difficile à travailler. Plus souvent qu'autrement, les utilisateurs de ce «cadre» finissent par le combattre plutôt que de l'embrasser.
Stefan Billiet

Réponses:

15

Il est typique d'avoir des sprints de 2 semaines.

Pour moi, le premier sprint ou 2 aura probablement moins de caractéristiques "visibles" que les sprints ultérieurs pour cette raison exacte (pour une description ténue de "moins").

Cela étant dit, cela ne devrait certainement pas vous prendre 2 semaines pour construire l'intégralité de votre échafaudage et rien dans l'interface utilisateur visible pour le montrer.

Peut-être que vous n'avez pas étoffé chaque élément d'échafaudage dans le premier sprint ou 2. Peut-être que les pièces peuvent attendre et être ajoutées plus tard.

Peut-être que votre premier sprint a "Créer une page Web X avec des données factices" afin que vous puissiez obtenir quelque chose de brillant à montrer à votre client. Et puis le prochain sprint a "Changer la page Web X pour utiliser les données de la base de données".

ozz
la source
6
+1 pour le dernier paragraphe - c'est une bonne idée de commencer le développement avec un prototype destiné à la validation de l'utilisateur.
Konamiman
4
"Peut-être que votre premier sprint a" Créer une page Web X avec des données factices "afin que vous puissiez obtenir quelque chose de brillant à montrer à votre client.": IMO cela dépend du client et de l'échelle de temps du projet: Pour un projet de 2 mois, un client peut vouloir voir quelque chose en 1 semaine ou 2. Pour un projet de 18 mois, on peut trouver OK pour obtenir une première démo en 1 ou 2 mois. Dans tous les cas, alors que certains clients peuvent aimer voir une page factice, d'autres peuvent vouloir voir quelque chose de plus significatif et avoir l'impression que vous perdez leur temps. Je pense que vous ne pouvez pas généraliser.
Giorgio
4
+1, mais toujours, gardez toujours à l'esprit le secret de l'iceberg lorsque vous montrez des pièces d'interface utilisateur à votre client joelonsoftware.com/articles/fog0000000356.html
Doc Brown
1
@MatthewFlynn - Scrum peut ne pas avoir de véritable phase de "conditions requises", mais cela ne signifie pas qu'il existe des exigences ZERO ou de la documentation disponible. Je n'ai jamais été impliqué dans un projet où un client a dit "allez-y et commencez à construire et nous le découvrirons en cours de route". Je pense qu'il y a un terme pour cela. Habituellement, il devrait y avoir une sorte de phase d'élicitation d'un projet qui comprend une discussion et un accord sur ce qui va être livré. J'ai présenté des prototypes pendant le pitch de vente
hanzolo
1
@hanzolo - Un projet très réussi sur lequel j'ai travaillé récemment impliquait la mise en œuvre d'une solution pour faire face à une nouvelle exigence légale qui faisait partie de la Loi sur les soins abordables. Les exigences de base étaient connues, oui, mais il n'y avait rien dans la voie d'un prototype ou d'une conception en place quant à ce que pourrait être la solution. L'équipe de projet (qui comprenait des analystes commerciaux) l'a compris dans le contexte des sprints. Au mieux, les BA parleraient à des gens d'affaires d'histoires un ou deux sprints avant le reste de l'équipe, mais c'était tout ce avec quoi nous devions travailler. Cela a bien fonctionné.
Matthew Flynn
13

Le Manifeste Agile suggère que le logiciel de travail est plus précieux que la documentation complète, et le cadre Scrum prend cette notion pour suggérer que la livraison d'un logiciel de travail testé avec une valeur commerciale est une exigence à chaque sprint.

Pourquoi? Eh bien, entre autres, les concepteurs et les développeurs sont souvent victimes de passer beaucoup de temps sur des articles YNNI (vous n'en aurez jamais besoin). Malheureusement, ces cadres dont vous parlez sont souvent un gros handicap dans ce domaine. Les développeurs commencent à intégrer toutes les choses que le framework POURRAIT avoir à supporter et tout à coup, vous avez 3 mois et vous n'avez rien de valeur commerciale à montrer. Ensuite, il s'avère que le cadre ne prend même pas vraiment en charge ce dont ils ont besoin.

L'approche suggérée consiste donc à construire uniquement ce qui est réellement nécessaire maintenant et à le fournir maintenant.

Cela ne signifie PAS que vous ne pouvez pas construire de pièces réutilisables et autres, vous le faites toujours pour répondre à un besoin actuel. De plus, cela ne signifie pas que vous devez porter complètement des oeillères pour ce qui s'en vient - ne construisez pas des choses de sorte qu'il soit impossible de les changer / les améliorer plus tard. Mais la clé est de toujours offrir une valeur commerciale.

Il y a souvent des éléments clés qui doivent absolument être établis avant que quoi que ce soit puisse être livré, comme la mise en place d'environnements et autres. Pour ces choses, beaucoup d'équipes trouvent utile d'avoir un "Sprint 0" dans lequel les bases sont posées. Le sprint 0 peut être un peu plus long que vos autres sprints, en ce sens qu'il n'est pas appliqué à votre backlog de produit ou à un burn-down, mais il doit toujours être limité dans le temps à une durée raisonnable.

Matthew Flynn
la source
8

Qu'est-ce qui est livré au client dans ces premières itérations?

Ce qui a la plus grande valeur commerciale pour l'utilisateur. Par exemple, si les applications ont des règles métier complexes, la ou les premières itérations contiendront uniquement les règles métier encodées sous forme de code. Le client doit être satisfait tant que vous disposez du code pour ces règles commerciales. (Le problème de persuader réellement le client d'accepter une telle chose est complètement différent.) Par exemple, vous pouvez montrer aux experts commerciaux du client vos tests unitaires / d'acceptation qui expriment ce que le domaine doit faire et que le code le transmet avec un résultat vert. Ou encore mieux, faites aider les experts commerciaux à créer ces tests.

Il est également question de

vous pourriez construire le cadre ou les fondations

Je pense que c'est beaucoup plus important que ce qui est réellement livré. Il y a une grande chose pour Evolutionary Design , qui dit que vous devez créer l'architecture au fil du temps au lieu d'essayer de la créer au début. Quant à la fondation, cela signifie généralement une sorte de base de données ou de cadre d'interface utilisateur. Dans ce cas, il y a l'idée de "Une bonne architecture est celle qui vous permet de reporter des décisions importantes ." Et choisir une base de données ou une interface utilisateur est une décision importante. Par exemple, vous pourriez être bien avec juste un stockage en mémoire pour les données au lieu d'essayer d'utiliser DB dès la toute première itération.

Euphorique
la source
3

Ce que nous essayons de faire est de fournir dans les premières itérations l'application la plus simple possible (une version bonjour du monde de ce que nous livrons). Nous voyons 3 avantages importants en cela:

  • Configurez la procédure de livraison (toujours l'une des parties les plus difficiles à mon humble avis) (obtenir les environnements, les serveurs en place, mettre à jour la sécurité pour cet environnement). Comme nous livrerons souvent, il est important de faire les choses le plus tôt possible.
  • Donnez aux utilisateurs un premier aperçu de l'apparence de l'application. Cela aide les utilisateurs et les développeurs à comprendre ce qu'ils veulent et dont ils ont vraiment besoin.
  • Ayez une idée de base sur l'apparence de l'architecture de l'application (l'application doit couvrir les «couches» ou composants de base de l'application).
user99561
la source
"Mettre en place le processus de livraison" est beaucoup plus difficile que les gens ne le pensent.
Frank Shearar
Oui, ça l'est. C'est pourquoi vous devez le faire le plus tôt possible.
user99561
2

Mais dans les premières itérations, vous pourriez construire le cadre ou les fondations sur lesquelles l'application reposera, c'est donc quelque chose d'important mais non visible pour les utilisateurs.

C'est faux, car vous n'avez pas besoin de construire un framework que vous utiliserez à l'avenir. L'idée est de ne construire que ce qui est nécessaire (voir aussi YAGNI ).

Dans le sprint zéro, vous devez vous préparer au vrai travail. Beaucoup de gens discutent de ce qui devrait être fait dans ce sprint, mais à mon avis, c'est fini lorsque vous pouvez commencer à travailler sur les éléments du backlog. Cette étape comprend la configuration des PC, la définition du processus de construction, la sélection des cadres, etc.

Lorsque vous avez terminé avec le sprint zéro (ou l'itération zéro), vous pouvez commencer à travailler sur votre application. Prenez les éléments du backlog et terminez-les un par un. Après avoir terminé la première itération, vous allez avoir quelque chose d'utile. La première itération comprend généralement certaines des fonctionnalités les plus importantes.

Qu'est-ce qui est livré au client dans ces premières itérations? Comment montrez-vous les progrès dans la bonne direction lorsque vous créez du code d'échafaudage?

Après zéro itération, vous n'avez évidemment rien à livrer. Le livrable vient après une itération. Il contient des fonctionnalités que vous avez définies pour l'itération.

Si votre question est "comment choisir ce qui entre dans l'itération X?", Jetez un œil à ces vidéocasts (vidéos pour l'itération 0 A et une partie de B).

BЈовић
la source
+1 pour avoir été le seul à mentionner l'itération zéro
crad
Je ne considère pas la définition du processus de construction et la sélection des tâches de frameworks pour le sprint zéro. Comment savoir de quel framework vous avez besoin si vous ne savez pas quoi construire? Je limite toujours le sprint 0 au strict minimum. Obtenez les PC des personnes et trouvez un espace où elles peuvent s'asseoir. Découvrez à qui vous devez parler de l'entreprise. Organisez une première réunion de planification. J'applique YAGNI au reste.
user99561
@ user99561 Les cadres sont de grandes décisions, et généralement difficiles à modifier. Par exemple, vous devez savoir si vous allez utiliser gtest ou cppunit pour les tests unitaires avant de commencer à écrire du code. Le changer plus tard va être une énorme douleur dans le cul et beaucoup de temps perdu.
BЈовић
@ BЈовић: Oui, les cadres sont de grandes décisions, c'est pourquoi vous devriez reporter la décision. Il est inutile de décider d'un framework si vous ne savez pas ce qui doit être développé et à quoi ressemblera l'application et l'architecture. Vous devez décider du cadre à utiliser au dernier moment possible. Sinon, vous courez définitivement le risque de devoir le changer.
user99561
@ user99561 Si vous ne savez pas ce qui doit être développé, vous ne pouvez même pas commencer :) Les exigences et les user stories doivent être écrites, sinon l'itération 1 ne peut même pas démarrer.
BЈовић
2

Vous pouvez livrer à peu près tout ce que vous voulez. L'idée de construire l'infrastructure est tout simplement fausse / pas agile / non durable.

Par exemple: la construction d'une application Hello World entièrement fonctionnelle peut être construite en quelques heures. L'installation d'un serveur (même temporairement) dans le cloud ou en tant que machine virtuelle peut se faire en quelques heures.

Ce sont assez pour commencer à se développer . Ensuite, si vous avez besoin de CI, vous pouvez ajouter une histoire CI, si vous avez besoin d'un serveur physique, bien sûr, ajoutez une histoire pour cela.

Mais commencez à livrer le jour 1 et ne vous arrêtez jamais!

Sklivvz
la source
1

Les premières itérations, en particulier la 1ère, contiendront ou devraient au moins prévoir des pics architecturaux, qui incluent un certain temps de découverte et peut-être un certain prototypage architectural.

Comme vous l'avez dit, généralement, il existe des exigences structurelles qui peuvent ne pas signifier grand-chose pour l'intervenant / le client, mais qui doivent former une plate-forme ou une orientation de modèle solide. Vous ne pouvez pas contourner cela car vous ne pouvez pas commencer à construire B tant que A n'est pas terminé.

Une partie de l'approche Agile consiste à fermer le client afin que la documentation ne soit pas nécessaire car tout ce que vous avez à faire est de prendre le téléphone / envoyer un e-mail, et c'est prévu. Les attentes des clients doivent être définies de manière appropriée et tout travail effectué doit être très concis et NÉCESSAIRE . Pas de placage à l'or, pas de "vous pourriez en avoir besoin", etc. Construisez ce dont vous avez besoin en A pour passer à B.

Selon la façon dont vous attaquez le projet, vous ne pouvez construire que les bases requises pour terminer un certain module.Ainsi, lors de la réunion de planification du sprint, vous définirez les plans du sprint actuel en fonction des priorités définies par le client, en fonction de ce qui est nécessaire pour ce sprint, il peut y avoir des exigences fondamentales, c'est donc ce qui entre dans le sprint 1. Une fois le 1er sprint terminé et A a été construit, puis prévoyez de terminer B.

Si vous avez convenu d'un calendrier avec le client, tant que vous respectez cet accord, le client ne se souciera probablement pas de ce que vous faites le 1er ou le 2e. Vous pouvez toujours leur montrer les résultats des tests unitaires, mais si vous dites que nous aurons quelque chose à voir après le sprint 2 (ou 3), et que vous livrez, cela établira une forte priorité. On s'attend à ce que les clients soient raisonnables autant que les développeurs et les deux travaillent vers le même objectif. Un projet terminé qui répond aux besoins du client et fonctionne comme prévu. Tellement inquiétant qu'il n'y ait rien à voir après le sprint 1 est un point discutable car le client veut juste s'assurer qu'après le sprint 20, le projet sera terminé (-ish).

hanzolo
la source