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

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?

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

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.

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.

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

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

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!

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