Open Agile

Les projets à base de développement Agile sont livrés en plusieurs petits morceaux, des petites livraisons, des livraisons incrémentales et itératives.

Dans les projets de développement traditionnel, le cycle de vie (simplifié) se compose de l’analyse, le développement et les tests – tout d’abord, toutes les exigences sont recueillies pour l’ensemble du produit, ensuite les éléments du logiciel sont développés, une fois terminé, le produit est entièrement évalué et tester avant sa livraison.

Méthode en cascade

En développement Agile, le cycle de vie et d’analyser, développer, tester, analyser, développer, tester, et ainsi de suite. Réaliser chaque étape pour chaque fonction, une fonction à la fois.

Méthode itérative

Les avantages de cette approche itérative du développement sont :

• Réduction des risques: Permet d’avoir une visibilité de ce qui est achevé à un moment précis du projet.
• Augmentation de la valeur : livrer rapidement à des avantages, être en mesure de livrer le produit quand il est considéré comme assez bon, plutôt que de devoir attendre tous les éléments destinés à être livrés,
• Plus de souplesse / agilité: on peut choisir de changer de direction ou d’adapter les prochaines itérations sur la base ce qui a été développé et sur l’utilisation du logiciel.
• Une meilleure gestion des coûts: si, comme tous les trop nombreux projets de développement de logiciels, vous courez après le budget, une certaine économie peut-être apportée par la méthode Agile.

Pour cette approche et pour être pratique, chaque fonction/caractéristique doit être pleinement développé, dans la mesure où elle est doit être livré, avant de passer à la suite.

Une autre pratique consiste à faire en sorte que chaque fonction/caractéristique soit développée par ordre de priorité, pas nécessairement dans un ordre logique par rapport au logiciel. Plutôt selon des critères de priorités client et de fonctions de haut niveau indispensable au logiciel. Dans le cas contraire, vous pourriez manquer de temp, pour avoir passé du temps sur des fonctions de moindres importances.

Construire les fonctionnalités du logiciel « importante, mais peu technique » est également souhaitable pour la même raison.

Ce n’est que lorsque vous avez terminé tout ce que vous devait avoir comme fonctions, que vous pouvez passer à ce que vous devriez avoir comme fonctions, et ensuite passer à ce que vous pourriez avoir comme fonctions. Sinon, vous pourriez obtenir une situation où vos premières caractéristiques sont fonctionnellement très riches, alors que du côté logiciel les caractéristiques sont de moins en moins sophistiquées avec le temps qui passe.

Essayez de garder votre produit backlog (terme lié à la méthode Scrum) ou votre liste de fonctionnalités pour qu’elle s’exprime en termes de cas d’utilisation, de scénarios utilisateur, ou caractéristiques – pas en tâches techniques.

Idéalement, chaque point de la liste doit toujours être quelque chose qui a une valeur pour l’utilisateur, et toujours vue comme un livrable plutôt qu’une activité pour pouvoir « taper dans les pneus » et de juger de la complétude, la qualité et prêt à livré.

Ce sont les caractéristiques importantes du développement itératif. Ils sont essentiels si vous prévoyez de délivrer dans les délais fixés – un des 10 principes clés du développement 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 :

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.

Ceci est un des contrastes frappant avec un projet de développement traditionnel, où un des premiers objectifs est de capturer toutes les exigences connues et leur champ d’application et que toute modification doit être suivie d’une conduite du changement.

Traditionnellement, les utilisateurs sont éduqués qu’il est beaucoup plus coûteux de changer ou d’ajouter des exigences pendant ou après la phase de développement du logiciel. Certaines sociétés citent quelques statistiques impressionnantes destinées à effrayer les utilisateurs. Il devient donc impératif d’inclure tout ce qu’ils peuvent penser – en fait tout ce qu’ils ont toujours rêvé !

Et qui plus est, il est important de le faire lors de la première version du logiciel, parce que nous savons tous que la phase 2 est toujours difficile à obtenir, une fois approuvée 80% des dépenses ont été réalisés de la phase 1.

Ironiquement, les utilisateurs utilisent seulement une infime partie de tout logiciel, plus ou moins 20%. Mais de nombreux projets commencent leur vie avec une portée pléthorique. En partie, parce que personne ne sait réellement qu’elles seront les 20% du produit qui seront réellement utilisés par l’usager. De même, même si les exigences sont soigneusement analysées et traitées en priorité, il est impossible de penser à tout, les choses changent, et les choses sont comprises différemment par des personnes différentes.

Le développement Agile travaille sur un principe complètement différent. Le développement Agile fonctionne sur le principe que les besoins apparaissent et évoluent. Quelques que soient les analyses et conceptions que vous faites, ce sera toujours le cas parce que vous ne pouvez pas vraiment être sûr de vous jusqu’à ce que vous utilisez le logiciel. Et le temps que vous avez passé en phase d’analyse des besoins et de conception, les conditions extérieures ont peut-être changé.

Donc, si vous pensez que personne ne peut réellement imaginer ce que sera la solution finale en début de projet – il est intrinsèquement difficile, voire pratiquement impossible, de construire la bonne solution en utilisant une approche traditionnelle de développement.

Les méthodes de projet traditionnelles combattent le changement, avec des processus de contrôle du changement visant à minimiser et à résister au changement dans la mesure du possible. En revanche, les projets de développement Agile acceptent le changement, en fait, ils l’attendent et l’évaluent. Parce que la seule chose qui est certaine dans une vie, c’est le changement.

Il existe différents mécanismes dans le développement Agile pour gérer cette réalité. Dans les projets de développement Agile, les besoins sont autorisés à évoluer, mais le calendrier est fixe. Donc, pour inclure un nouveau besoin, ou pour modifier une exigence, l’utilisateur ou le directeur de produit doit retirer du projet une charge de travail comparable afin de tenir compte de ce changement.

Ainsi, l’équipe peut continuer à se concentrer sur les délais, et le produit permet d’évoluer dans la bonne direction. Toutefois, il faut aussi présupposer qu’il y a suffisamment de fonctions optionnelles prévues dans le projet pour permettre ces changements, cela doit se faire sans compromettre fondamentalement le produit final.

Mais qu’est ce que l’entreprise pour attendre de ses équipes de développement ? Délivrer le logiciel dans les délais et le budget prévus dans le contrat, et bien sûr avec une qualité acceptable. Tous les professionnels du développement sont bien conscients que vous ne pouvez pas de manière réaliste résoudre tous ces facteurs et espérer répondre aux attentes. Quelque chose doit être variable pour la réussite du projet. En développement Agile, il existe toujours un champ d’application (ou des caractéristiques du produit) qui est variable, le coût et le calendrier ne doivent pas l’être.

Bien que la portée d’un projet de développement Agile est variable, il est reconnu que seule une fraction d’un produit est réellement utilisée par ses utilisateurs et donc une partie des fonctionnalités d’un produit n’est pas vraiment indispensable. Pour pratiquer cette philosophie de travail, il est impératif de commencer le développement par le noyau, et par la suite avec les cas d’utilisation qui ont la priorité la plus élevée, en s’assurant qu’ils sont livrés dans les temps.

Dans cette méthode, nous favorisons le CRI (Conception – réalisation – Intégration) par itérations. Chaque itération terminée, peut-être livrée pour que le client final puisse valider le contenu de l’itération. Cette méthode permet rapidement d’avoir un état des lieux de la charge consommée et celle restant pour satisfaire au besoin.

Une équipe de projet de développement Agile doit inclure tous les membres de l’équipe qui doivent prendre des décisions, et les rendre dans les temps.

La participation active des utilisateurs est un des principes clés. L’utilisateur ou le représentant de l’entreprise doit être étroitement associé sur une base quotidienne.

L’équipe de projet doit être habilitée à prendre des décisions afin de s’assurer qu’il est de leur responsabilité de livrer le produit et qu’ils en ont la propriété. Toute interférence avec l’équipe du projet est perturbatrice et réduit leur motivation à livrer.

L’équipe doit travailler ensemble à établir et préciser clairement les exigences, définir les priorités, être d’accord avec les tâches nécessaires pour fournir les besoins, et estimer les charges.

Il peut sembler opportun de se passer d’un niveau de l’équipe au début du projet. Il est tentant d’avoir seulement un sous-ensemble de l’équipe pour commencer (genre le directeur de produit et l’architecte) , car cela est beaucoup plus efficace.

Toutefois, il s’agit d’un principe-clé pour moi ! Faire participer l’ensemble de l’équipe dès le début du projet. Cette méthode assure la participation et l’engagement de toute l’équipe de projet dès le départ, quelque chose qui paie par la suite.

Lorsqu’un défi se pose tout au long du projet, l’équipe se sent un réel sentiment d’appartenance. Si cela peut sembler couteux. Il faut y penser dès la négociation avec le client et lui faire comprendre l’importance.

Un projet c’est avant tous des hommes avant même les méthodes, une équipe soudée est souvent plus importante qu’une méthode de projet, car elle se sent impliquée.