Kad Dembele

Agilité, Code & Développeur

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!

76 comments

  • powigh
    powigh, 30 December, 2017 04:12 Comment Link

    buy cialis
    generic cialis 5mg
    http://cialiscbuynrx.com
    cialis 20mg rezeptfrei
    cialis

  • Agingbip
    Agingbip, 29 December, 2017 04:12 Comment Link

    cheap cialis online
    viagra onsale cialis pills
    http://cialisusmedsonline.com
    cialis soft online
    buy generic cialis

  • Arcarm
    Arcarm, 29 December, 2017 04:12 Comment Link

    generic viagra online
    where to buy viagra online
    http://genviagramrxonline.com
    fildena vs viagra
    generic viagra online

  • Shiell
    Shiell, 28 December, 2017 10:12 Comment Link

    cheap viagra online
    how long does it take for viagra to kick in
    http://genviagramrxonline.com
    no prescription viagra
    buy viagra online

  • Hypegefe
    Hypegefe, 26 December, 2017 07:12 Comment Link

    buy cialis
    buy brand cialis from supplier
    http://nrxcialismeds.com
    how long does cialis 20mg cialis
    cheap cialis online

  • faunda
    faunda, 26 December, 2017 06:12 Comment Link

    buy viagra online
    viagra e alcol
    http://viagranrxmedonline.com
    homemade viagra recipe
    buy viagra online

  • James
    James 13 December, 2017 03:12 Comment Link

    I gotta preferred this web web page it appears very valuable quite advantageous

  • Billiekew
    Billiekew, 1 September, 2017 01:09 Comment Link

    Some employees who examine books included in their everyday duties benefit businesses or firms, although some outsource their companies as freelance agents.

    Book Reviewers

    Visit the sites of organizations including Publishers Weekly, Kirkus Opinions or Library Newspaper to find out if they are hiring individuals to examine textbooks and create opinions to them. Permanent, full time staff are typically paid incomes and gains.

    Manuscript Authors

    For example, an editor may capture a mistake such as a character who's referred to as possessing brown hair later being called a red. Others act as freelance agents and acquire paid by the guide. Or, visit freelance websites, for example Elance, Expert and ODesk to discover accessible editor careers.



    Although it is not their primary job, librarians frequently are paid to see as part of their careers. Others work in library juvenile divisions and examine books aloud to youths. Full-time librarians are generally paid salaries, while parttimers are often settled by the hour.



    Most book publishers and businesses that produce book critiques require entrylevel writers to have a minimum of a bachelor's degree in journalism, communications, Language or even a related field. As an example, a qualification ever sold will help an editor who typically proofreads biographies or record books.
    writing a case study report
    hausarbeit schluss beispiel
    research paper topics on immigration in america

  • Billiekew
    Billiekew, 1 September, 2017 01:09 Comment Link

    *Conform to fix spelling, grammar and style policies in your English term paper. *Ensure that there's a stream from discussion to another location in your English term paper-writing. Continue to keep track of the sources and cite them properly while in the recommendations area. The writer desire to thank the amazing individuals for their decades of devotion and trust in-all our work, and all the productive pupils who've used our site.
    research paper writers online
    book report activities for middle school
    was schreibt man in einer trauerkarte reinВ 

  • music download sites free
    music download sites free 26 July, 2017 07:07 Comment Link

    I Subscribed

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.