123 Go je me lance en agile.. !

Un nouveau courant d’idées méthodologiques qui commence à émerger, c’est bien les méthodologies agiles. C’est bien beau, mais par où commencer! Voici notre réponse à cette question importante que nous allons essayer de vous donner des pistes des solutions durant cet article.

Nous aimerions bien vous proposer une recette magique. Une recette que vous pourriez, appliquer sans qui crainte de l’échec et qui va réussir à tous les coups. Mais, l’expérience de plusieurs années en informatique et en méthodologies de développement. Dont, avec les méthodologies agiles, nous a permis de comprendre qu’il faut faire attention avec ces soit disent « recette toute faite ».

Il faut repartir à la base des méthodologies agiles, les quatre principes :

• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide

Si une organisation, (une compagnie, une équipe de développement, etc.) décide de se tourner ou du moins regarde la possibilité de le faire. C’est qu’elle a identifié qu’elle a un problème quelque part. Et potentiellement, l’un qui touche c’est quatre grands principes.

Bravo, vous avez fait le premier pas. Car, en se lançant en agile, ou toutes autres nouvelles méthodes. Il faut gérer le changement. Il faut faire un constat.
Agile ne signifie qu’il faut tout changer dans votre organisation. Encore moins, que tout ce que vous faites déjà est en erreur. Agile chercher simplement à améliorer vos processus en apportant une nouvelle vision, une nouvelle approche dans la manière d’aborder un problème.

Lorsque nous implémentons agiles dans une organisation, il ne faut pas arriver avec un bulldozer qui détruira tout sur son passage. Il faut arriver avec de la minutie, du doigté, de la sagesse et surtout beaucoup de respect.
Nous disons toujours regardons ce que vous faites de biens, ce qui peut être amélioré, ce qui doit être changé et ce qui ne doit pas l’être.

Il y a une école de pensée dans les méthodologies agiles, qui veulent la mort des méthodes « wather falls » ou des approches mérisiennes (Mérise, P+, Macroscope). Nous pensons le contraire. Si certains éléments de ces méthodes en cascade fonctionnent chez vous. Continuez à les utiliser (ne changeons pas ce qui fonctionne.) Ajustons seulement la manière de les utiliser dans un contexte agile. Exemple, si vos clients sont confortable avec un dossier fonctionnel selon les la définition de P+. Continuer à les écrire sur cette base. L’adaptation agile qu’on peut faire, c’est de réduire son volume (le nombre de pages) et le média de production. Au lieu de l’écrire sur beau document imprimé sur 8 ½ - 11. Utiliser une version électronique qui contient des références web (pointeurs) vers des processus déjà documentés ou pourquoi pas un Wiki.

A l’inverse, si aucun de vos clients ne lit le plus petit dossier fonctionnel, à quoi sert donc à s’acharner des les produire. Utiliser peut-être un « cas d’utilisation UML » ou les « Story de Scrum ».

Il apporter des solutions aux problèmes, et surtout ne pas en créer de nouveau.
Après avoir fait le constat dans votre organisation, vous nous poserez sans doute les questions suivantes :

• Il doit exister une ou plusieurs méthodes structurées qui implémentent ces principes ?
• La quelle de ses méthodes, dois-je choisir ?

Il existe plusieurs méthodes, certaines plus structurées que d’autre.
• Scrum
• Extrême programming
• Lean
• RAD (Rapid Application Developpement)
• Et plusieurs autres.

Laquelle prendre dans cette liste, en prendre une ou toutes les prendre, me diriez-vous. Nous répondons toujours, la même chose. Un bon mélange de tout ça. Un petit soupçon de SCRUM pour sa structure et sa gestion d’équipe. La gestion des story pour documenter les processus d’affaires. Le « SCRUM matinal » pour assurer un bon suivi. Et le plus important, le cycle d’itération très court avec son fameux backlog.

Quelque graine d’extrême programming, avec son « pair programming » adapté à la bonne saveur de votre organisation. Peut-être pas 2 personnes assises devant l’écran. Mais, une redondance des expertises par exemple. Par l’approche, spécialiste et son assistant. Une personne possède une personne précise. Et en cas de son absence (ou non-disponibilité), le second peut intervenir à la place du principale.

Lean la gestion de la qualité des processus et des livrables. On veut livrer quelque chose, mais surtout quelque chose de qualité. Ainsi que son principe de juste d’attends.

N’oubliez pas, ce n’est pas une recette de cuisine. Une recette générique qu’on peut appliquer tous les organisations. Si on veut respecter les valeurs mêmes d’agrile, il faut trouver le moyen d’adapter cette recette, d’ajuster les saveurs pour réponse à notre besoin. Une méthode qui nous (nous et vous) à produire de meilleurs logiciels tant qualité du produit, en coût de développement qu’en temps de développement.

En conclusion, se lancer en agile, ce n’est pas une chose simple sans pour autant être complexe. Il faut prendre le temps de bien poser l’analyse. Ne pas avoir peur de se remettre en questions et surtout avec l’agilité de s’adapter en cours de routes.

Mais, surtout trouver une personne d’expériences (en méthodologie agile) avec la chimie passera .. ! et avec laquelle vous n’aurez pas peur de tout remettre en question. Y compris de ne rien changer .. !

Je sais, il semble que nous vous laissons sur votre faim, sans avoir bien répondu à la question. Et pourtant, oui nous y avons répondu .. ! Car, la seule solution à savoir comment on se lance en agile, c’est avec vous .. que seulement nous pouvons la trouver.. !

Agile c’est de pensée différemment, et parfois de donner des réponses qui ne semblent pas en être une.