demkada

Pour un homme, être agile, c'est être habile à changer rapidement la position de son corps. De cette habileté constatée le plus souvent chez les adeptes des sports de combat sont nées plusieurs allégories, notamment, les méthodologies de gestion de projets par l'agilité. Cette métaphore montre l'objectif initial visé par ces méthodologies, C'est à dire, rendre le cycle de vie d'un projet le plus habile possible afin qu'il puisse s'adapter rapidement à des situations changeantes.

Comprenez bien par là que les méthodes agiles sont applicables et appliquées dans d'autres domaines que l'informatique (même si leur origine se trouve dans l'informatique). Elles sont tout aussi applicables à la conception d'un avion chez Airbus, d'une voiture chez Peugeot que d'un logiciel chez Microsoft, et malheureusement, le constat global est qu'il y a encore de nombreuses personnes, organisations, et projets qui appliquent les méthodologies agiles sur leur projet sans pour autant tenir compte du paradigme agile relatif à leur domaine d'activité. Dans ce billet, je vais revenir aux sources et présenter l'importance qu'a un développeur dans les méthodologies agiles appliquées à la conception de logiciels.

Le logiciel étant notre domaine d'activité, et qui parle de logiciel à un développeur parle forcément d'un projet de conception de logiciels et de nos jours, les besoins sont très changeants/évolutifs en cours de développement d'un logiciel, et pour faciliter cette gestion des besoins oscillants, les responsables informatiques ont décidé de mettre en place un framework qui a fait ses preuves dans le monde de l'agilité en informatique: SCRUM.(Super, on utilise SCRUM, du coup, notre logiciel est agile).

Rétro: Pour ceux qui ont suivi, du paragraphe précédent ressort cette phrase: SCRUM est un framework de gestion de projets logiciels par l'agilité(? ? ?). Jusqu'à présent, je vois que vous n'avez pas encore suivi, je reprends: SCRUM est un framework de gestion de projets logiciels par l'agilité. ( à ceux qui ont compris)

Pour les autres, SCRUM à lui seul ne créera jamais, au grand jamais une dynamique agile dans un projet informatique, le seul but d'une méthodologie comme SCRUM est de rendre le processus de gestion du cycle de vie du logiciel agile par un pilotage fluide et non le logiciel lui-même. En somme SCRUM, comme toutes les autres méthodologies de gestion de projet informatique par l’agilité (je pense à RUP, Kanban...) est juste un ensemble d'outils de gestion de projets. Autrement dit, c'est de l'agilité de haut niveau et il est indispensable, certes, mais ce n'est pas une fin en soi.

Entrons maintenant dans les choses les plus importantes. Qui dit logiciel dit code, et qui dit code dit développeur (ce que j'appelle LCD) d'où ma définition de l'agilité dans un contexte de développement logiciel, (cette définition n'engage que moi, à vous de vous faire votre opinion).

Une équipe de développement logiciel/une organisation informatique est agile si et seulement si les méthodologies de pilotage permettant la mise sur le marché d'un produit sont agiles (Scope organisationnel) et le processus de conception des produits est lui-même agile (Scope technique). Les deux sont complémentaires, l'un ne sert pas à grand-chose sans l'autre. Vous pouvez lire ici un de mes anciens billets à ce sujet.

Maintenant que nous avons une vision plus claire de la gestion de projets logiciels par l'agilité qui est plutôt d'ordre organisationnel, le paradigme agile, technique dans ce même contexte de développement logiciel, est quant à lui relatif au design du code est à la seule charge du développeur.

Oooh, le développeur, ce ninja des temps modernes, mais avant de parler de ce phénomène, parlons avant de la relation qui le lie au scope organisationnel quand on parle d'agilité.

En effet, pour arriver à un logiciel fonctionnel (notez la mise en gras de ce mot), on passe par une étape plus ou moins longue d'expression des besoins, en d'autres termes des spécificités fonctionnelles. Haah oui oui, le logiciel est fonctionnel si et seulement s'il répond aux besoins fonctionnels. Or, une fonctionnalité n'est rien d'autre qu'un concept abstrait, la seule chose de vraie dans la réalisation d'une fonctionnalité est le code source qui permet de concrétiser ce concept d'une irréalité absolue. Et imaginez qui pisse ce code source... en tout cas, ce n'est pas l'épicier du coin.

Allons de la base selon laquelle on souhaite mettre en place une organisation agile (full agile, je veux dire), l'expression des besoins, leur analyse, et leur intégration dans les sprints suivent une méthodologie agile (merci SCRUM), le processus de conception technique, de codage doit impérativement être agile.

Merci à ceux qui ont lu ce billet jusqu'à ce niveau, cela me touche énormément, et j'espère bien qu'il vous aidera à affiner votre vision de l'agilité dans le monde des logiciels. Toutefois, si vous n'êtes pas développeur, continuez votre chemin, allez-vous amuser ailleurs, car les sections suivantes ne pourront être comprises que des initiés.

Alors, c'est quoi cette histoire de programmation agile?
Ici je vais vous présenter des méthodologies considérées comme matures et qui sont censées être connues de tout développeur (mais qui ne le sont malheureusement pas). certaines équipes expérimentées développent en interne leur propre politique technique d'agilité, si ce n'est pas votre cas, les méthodologies présentées ici pourront être un début pour votre future organisation agile.

L'objectif initial de souplesse des méthodes agiles a engendré plusieurs conséquences dans la vie d'un logiciel, notamment la réduction du TTM (Time To Market) avec à chaque release une nouvelle valeur ajoutée aux itérations précédentes, et cette réduction du TTM n'est possible qu'avec un code source ingénieux. En d'autres termes, pour avoir un TTM réduit, il est indispensable d'avoir un code source compréhensible, maintenable, évolutif et fiable. Pour ce faire, vous devez être rigoureux sur vos sprints, décisifs et surtout réactifs. Car sans ces qualités, vos sprints ne pourront jamais se terminer à temps et vous serez toujours pollués par des résidus des sprints précédents.

Pour vous aider à développer un code agile, je vais vous présenter les deux méthodologies agiles orientées technique, les plus connues qui vous permettront d'avoir des logiciels bien faits et fonctionnels: (Attention, c'est ma mixtape personnelle, essayez la et vérifiez son impact sur vos résultats)

Le RAD (Rapid Application Development):
Le développement rapide d'application est une méthodologie comme SCRUM, mais beaucoup moins complète que ce dernier. Imaginons que vous utilisez SCRUM pour la gestion du projet avec des releases toutes les deux semaines, dans ce cas, chaque développeur peut démarrer chaque Sprint en RAD. L'importance du RAD dans ce cas de figure est de pouvoir prototyper rapidement deux ou trois solutions au début du Sprint. Ces prototypes serviront de solutions de départ pour le reste du sprint.

Cas Pratique:
Je suis développeur, au début du sprint ma user story est de développer la fonctionnalité "My Feature". Pour cela, la toute première tâche de cette user story doit impérativement être de prototyper une ou plusieurs solutions de départ. Ce prototypage doit prendre en compte les éventuelles études d'impact, et autres études. Et comprenez bien que c'est juste une solution de départ (Mais pour être impeccable, cherchez en au moins deux qui tiennent la route). Cette étape de prototypage ne doit en aucun cas dépasser deux jours hommes pour un sprint de deux semaines et le prototype obtenu peut être un bout de code fonctionnel ou tout simplement une organisation structurée d'idées (avec bien sûr une préférence pour du code). Si jamais, vous sentez à la fin du deuxième jour que vos prototypes ne tiennent pas la route, remontez l'information au DSM le lendemain avec un panneau help et faites intervenir toute l'équipe pour qu'elle vous aide à trouver votre solution de départ.

Pour conclure, documentez-vous bien sur le RAD, et essayez de l'appliquer à chaque début de sprint pour trouver votre solution de départ en deux jours, et au pire des cas en trois jours (avec l'aide de l'équipe), passer ce délai, sans point de départ sérieux, votre sprint a de fortes chances de tomber à l'eau. Enfin, l'avantage d'avoir plusieurs solutions de départ est de pouvoir changer rapidement de solution au cas où l'on se trouverait face à un mur ou même de mixer plusieurs solutions de départ, et si vous arrivez à faire ces changements en milieu de sprint, c'est la preuve irréfutable que votre code est assez habile pour s'adapter rapidement.(+1 pour la maintenance)

L'Extreme programming :
Yes! je l'ai eue ma solution de départ, en plus en un jour homme . Whaou la chance ! non, non, c'est le talent.
Allez trêve de plaisanteries, une fois votre solution de départ en poche, il ne reste plus qu'à faire du XP sur le reste du sprint. Une fois de plus, je vous laisse vous documenter sur cette méthodologie aux pouvoirs incroyables. La seule pratique de l'extreme Programming qui d'ailleurs est l'une des plus minimes et que je mettrais en avant dans cet article est la simplicité. Pour un programmeur extrême, la simplicité est la clé de sa réussite. Plus une solution est simple plus, elle est facile à mettre en place, et plus le TTM est réduit.

Cas Pratique:
En supposant qu'au lendemain du second jour, j'ai mes solutions en poches, je choisis celle qui tient le plus la route, je la teste, je l'affine, je l'adapte, je la teste, je la passe à un collègue pour revue, je la remanie, je l'étends, je la teste, je la passe à un collègue pour revue... en respectant les principes du design objet (si vous faites de la POO bien sûr). Jusque-là, tout va bien, et en plein milieu, du sprint, je me trouve face à un mur dû à:

• un problème de ma solution de départ, alors, je la reconsidère et je l'adapte à l'aide de mes solutions de secours (en choisissant toujours la solution la plus simple).
• un problème indépendant du code (un problème dû à l'environnement d'exécution, aux outillages, ...), alors je le contourne/résous avec du code: J'ai récemment rencontré un problème lors d'un sprint causé par une incompatibilité des versions d'une librairie open-source sur mon serveur d'application (mon code utilise une version supérieure et le serveur une version antérieure, fournie d'office par le serveur). L'erreur courante du développeur est de chercher à rendre sa librairie compatible avec le serveur, cela passe souvent, par des désinstallations et des réinstallations de nouvelles librairies. Or, ce n'est pas au développeur de s'occuper du serveur d'applications en plein milieu de sprint, il se pollue son sprint en cherchant à changer la logique interne du serveur. A mon avis, cette voie est la plus compliquée qui puisse exister et peut être fatale pour un sprint. C'est comme si on vous mettait en face d'une porte que vous avez fabriquée, montée sur un mur blindé et que l'on vous demandait de vous rendre de l'autre côté du mur sachant évidemment que vous avez perdu votre clé. Est-ce que votre réaction sera de prendre une pioche et de foncer dans le mur ou alors de chercher à fabriquer une nouvelle clé à la porte que vous avez fabriqué vous-même? (Les plus intelligents diront prendre une pioche et foncer sur la porte). Il paraît évident qu'il serait plus simple et plus rapide de modifier son code et d'avancer sur son sprint, et si vous jugez vraiment nécessaire de modifier la configuration interne du serveur, faites part de cela au Product Owner pour les prochains sprints.

Sur ce, je termine mon aparté sur la pratique de la simplicité (sachez que XP met en avant 12 autres pratiques toutes aussi importantes les unes que les autres) et je vous encourage fortement en tant qu'aspirant développeur agile à vous documenter sur ces méthodologies, car elles forment la base pour tout logiciel agile.

Bonne chance à tous pour vos sprints car un développeur qui rate son sprint est dans le même état que Lionel Messi qui rate sa finale de league des champions!

-----------------------------------
Soucre: http://blog.kadary.me