Open Agile

La synthèse de cet article : Une équipe de développement identifie les exigences à un niveau élevé et au coup par coup, juste à temps pour chaque élément à développer. Avec une vision globale de l’objectif du projet.

Le développement Agile est idéalement visuel et doit être à la limite de l’acceptable, c’est-à-dire le strict minimum nécessaire pour permettre le développement et l’expérimentation pour procéder avec une efficacité raisonnable. La raison d’être est de minimiser le temps consacré à tout ce qui ne fait pas partie du produit final.

Le développement Agile peut-être confondu à tort par certains comme dépouillé de processus ou de règles. En d’autres termes que l’on réalise les choses au fur et à mesure . Cette approche n’est pas réellement Agile mais plutôt fragile !

Bien que le développement Agile est beaucoup plus souple que les méthodes de développement traditionnelles, le développement Agile n’est pas néanmoins exempt de rigueur et il est basé sur l’approche structurée (Lean Manufacturing) initiée par le groupe Toyota (leader de la productivité) – Remarque: Le travail de Toyota à été permis de créer la méthode « Lean Software Development » qui complète les méthodes Agile pour apporter la qualité tout au long du cycle de vie du projet. Je vous présenterais bientôt un billet sur cette méthode.

Je crois personnellement que les équipes de développement Agile peuvent créer de meilleurs produits s’ils ont une idée assez claire de l’ensemble des besoins avant de partir sur le développement, afin que les décisions de conception qui peuvent s’avérer erronées ne conduisent pas à l’équipe dans des impasses. Elle permet en complément des investissements plus raisonnables pour financer les projets.

Cependant, toutes les exigences identifiées au début doivent être vues à un niveau élevé et dans un format visuel, par exemple, comme un story-board de l’interface utilisateur. À ce stade, les exigences doivent être assez bien comprises pour déterminer les grandes lignes du produit et produire une première prévision du budget et rien de plus.

Idéalement, les équipes de développement Agile identifient les exigences à haut niveau dans des ateliers. Ils travaillent ensemble dans une grande collaboration de manière que tous les membres de l’équipe puissent comprendre les exigences. Il n’est pas nécessairement d’avoir des personnes avec des compétences particulières, comme un architecte comme dans des projets plus traditionnels, afin de recueillir les exigences indépendamment les unes des autres et de les formaliser par écrit. C’est une activité conjointe de l’équipe qui permet à chacun de contribuer et de comprendre ce qui est nécessaire.

XP (eXtreme Programming) applique des « pauses » aux exigences sous la forme de petites parties appelées « User stories ». Ils sont fondamentalement similaires au cas d’utilisation (Use Case), mais sont plus légers et plus simples par leur nature.

Une équipe de développement Agile visualise les exigences sur un tableau blanc et crée des sessions de story-board (séquences de captures d’écran, des visuels, des croquis, des wireframes ou des diagrammes de séquence) pour montrer à peu près à quoi ressembleront la solution et l’interaction de l’utilisateur dans la cinématique de la solution. Il n’existe pas de long cahier d’exigence ou des spécifications à moins qu’il y ait des zones de complexité qui le justifient réellement. Sinon, les story-boards sont tout annotés et seulement lorsque cela est nécessaire.

Une approche commune entre les équipes de développement Agile est de représenter chacune des exigences, cas d’utilisation ou de story board sur une carte et utiliser une T-card (une représentation visuelle très efficace de plusieurs story board) pour permettre aux scénarios d’être facilement déplacés pour permettre d’ajuster les priorités. Exemple de T-card :

Les exigences sont ventilées en très petits morceaux afin de parvenir à ce résultat; en fait, c’est la force des cartes de pouvoir réaliser cette ventilation en très petits morceaux. L’avantage par rapport à une documentation classique, c’est que cette approche est extrêmement visuelle et tactile, vous pouvez être debout autour du système de T-card et le tableau blanc pour discuter de l’avancé, des priorités et des questions.

La technique de la carte et du T-card est très utile quand le contexte métier ou la technologie n’est pas totalement maitrisée par l’équipe projet. Toutefois, quand l’équipe de développement à une expérience importante du métier et peut rapidement identifier le périmètre et les cas d’utilisation, il est préférable d’utiliser un tableau blanc et un appareil photo pour capturer les cas d’utilisation et les diagrammes de séquence. Les cartes restent néanmoins utiles pour se rappeler des différentes exigences nécessaires du projet et pour l’évaluation de la charge.

Les besoins évoluent, mais les délais sont fixes. Au cas où il serait nécessaire de changer les priorités ou d’ajouter de nouvelles exigences dans le projet, le responsable du projet doit retirer une charge comparable au montant de la nouvelle exigence avant de pouvoir placer la nouvelle carte dans le projet.

Les équipes traditionnelles de projet qui ne contrôlent pas le changement peuvent terminer le projet hors du champ initial avec le redoutable glissement de planning, une des raisons les plus communes pour quoi les projets de développement échouent.

Les équipes Agile, en revanche, acceptent le changement, en fait, ils s’attendent. Mais elles gèrent le changement en fixant les délais et la négociation.

Les cartes peuvent bien sûr être complémentées par une documentation appropriée (souvent nécessaire pour le client), mais toujours dans un principe de développement agile, il faut toujours documenter le strict minimum d’informations qui permettra à une fonction d’être développées et toujours ventilées en très petites unités.

Pour exemple, pour mes projets nous faisons avec l’équipe de développement des cas d’utilisation (CU), des diagrammes de séquence (DS), les visuels (UHM) un par un sur un tableau blanc, nous terminons une série en prenant des photos du tableau. Ensuite on transfère au client un par un les CU, DS et interface IHM. Une fois stabilisé, nous pouvons écrire le document (par exemple une spécification fonctionnelle), mais jamais avant que le développement du CU ne soit réalisé.

Utiliser Scrum est une bonne pratique pour la gestion des projets, les exigences (ou les fonctionnalités ou les cas d’utilisation, quelle que soit le mot que vous préférez utiliser) sont ventilées en tâches qui ne dépassent jamais plus de 16 heures (c’est-à-dire 2 jours de travail) et de préférence pas plus de 8 heures, de sorte que les progrès peuvent être mesurés objectivement sur une base quotidienne.

Une dernière chose et qui je pense devrait être certainement adopté de PRINCE2 (la méthodologie de gestion de projet pas agile du tout !), est l’idée de s’assurer que tous les besoins sont des éléments à fournir plutôt que des activités ou des tâches. Vous pouvez voir un produit et donner un « coup de pied dans les pneus », afin de juger de sa qualité et de son exhaustivité. Avec une tâche vous ne pouvez pas le faire.