https://www.developpez.net/forums/blogs/446565-demkada/ Developpez.com, le Club des Développeurs et IT Pro fr Fri, 11 Sep 2026 03:56:40 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.jpg https://www.developpez.net/forums/blogs/446565-demkada/ https://www.developpez.net/forums/blogs/446565-demkada/b724/agilite-code-developpeur/ Thu, 03 Sep 2015 20:09:20 GMT Pour un homme, être agile,... 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 ]]> demkada https://www.developpez.net/forums/blogs/446565-demkada/b724/agilite-code-developpeur/ https://www.developpez.net/forums/blogs/446565-demkada/b344/l-artisanat-logiciel/ Wed, 11 Mar 2015 23:00:58 GMT Dans mon billet précédent, ...
Dans mon billet précédent, je vous ai parlé de l'architecture logicielle et principalement des principes de base de la conception logicielle. Et nous avons vu que les deux indicateurs de qualité logicielle, les plus importants(La facilité d'utilisation et la maintenabilité) étaient les plus négligés car la plus part des architectes se limitent à la livraison de logiciels fonctionnels (Get It Done).


Et c'est tout là, la différence entre un industriel qui se contente de produire à la chaîne de manière répétitive des produits basés sur un modèle et un artisan qui use de son savoir faire pour créer des œuvres artistiques (Architecture des bâtiments, ..., Architecture des logiciels) et de ses fonctions cognitives pour s'améliorer au fil du temps. D'où le mouvement software craftsmanship.
Un artisan du logiciel est avant tout celui qui conçoit bien son logiciel, dans le sens de l'architecture logicielle bien sûr (Get it Right). D'où les quatre valeurs prônées par l'artisanat du logiciel:

• Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
• Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de la valeur.
• Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels.
• Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.
  

De ces valeurs que tout aspirant Artisan du logiciel doit respecter, Il ressort clairement l'envie de bien faire les choses, d'améliorer de façon constante, de partager le savoir faire et d’intégrer le client au cycle de vie du logiciel.


J'ai eu à lire sur de nombreux blogs des personnes qui disent qu'une entreprise a besoin d'industrialiser ses processus pour pouvoir produire et qu'un artisan n'a pas sa place au sein d'une entreprise, ces personnes ont entièrement raison, sauf que le but d'un artisan logiciel n'est pas de transformer une entreprise industrielle en entreprise artisanale mais plutôt de concevoir des logiciels dignes des plus grandes œuvres artistiques en:

• Affectant au mieux les responsabilités dans le code (Principe de responsabilité unique)
• Rendant le code le plus extensible possible (Principe d'ouverture/fermeture)
• Permettant aux objets de la même famille de se substituer mutuellement (Principe de substitution de Liskov)
• Limitant l'accès aux objets à des méthodes dont ils n'ont pas besoin (Principe de ségrégation des interfaces)
• Assurant que les dépendances entre les différents modules sont gérées par abstraction (Principe d'inversion des dépendances)
  

Ces différents principes (SOLID) énoncés par Uncle Bob visent à simplifier les techniques de conception logicielle et à rendre les logiciels conçus maintenables et compréhensibles.
Pour revenir sur l'industrialisation des processus de travail, il est évident que la deuxième valeur du manifeste de l'artisanat du logiciel qui vise à créer constamment de la valeur ajoutée passe par la mise en place des processus d'automatisation des phases de test et de déploiement de l’œuvre créée (logiciel) mais n'équivaut en aucun cas à industrialiser la phase de conception elle même.


Pour conclure, je dirai que l'artisanat du logiciel est l'art de bien concevoir des logiciels (Get It Right) grâce à un savoir faire et un apprentissage continuel et peut être considérer comme un complément technique à l'agilité.


-----------------------------------
Soucre: http://blog.kadary.me ]]> demkada https://www.developpez.net/forums/blogs/446565-demkada/b344/l-artisanat-logiciel/ https://www.developpez.net/forums/blogs/446565-demkada/b343/l-architecture-logicielle/ Wed, 11 Mar 2015 20:16:46 GMT Il y a plusieurs... Il y a plusieurs manifestations de l'architecture. Toute architecture est une construction, mais toute construction n'est pas de l'architecture. Pour qu'une construction, une construction mentale, matérielle, visuelle ou acoustique soit une architecture, il faut qu'elle remplisse certaines conditions.

Cette citation de Juan Gris, un artiste peintre montre la principale contrainte de toute architecture: le respect des principes liés au domaine d'application de la dite architecture.
Dans le cadre du développement logiciel, les conditions à remplir pour que votre conception soit considérée comme une architecture sont défini par la norme ISO/CEI 9126. Si le rôle d'un architecte logiciel est d'élaborer le plan de construction et de coder les grandes lignes d'architecture d'un système logiciel, sa phase de conception globale doit impérativement prendre en compte les indicateurs de qualité définis par cette norme. Ces indicateurs sont:

• La capacité fonctionnelle : La conformité des fonctionnalités du logiciel avec celles décrites dans le cahier des charges.
• La fiabilité : La faculté du logiciel à gérer correctement ses propres erreurs de fonctionnement en cours d'exécution.
• La portabilité : La possibilité de porter le logiciel sur des plates-formes (machines, systèmes d'exploitation, environnements) différentes.
• Le rendement / L'efficacité : La capacité du logiciel à exploiter au mieux les ressources offertes par la ou les machines hôtes.
• La facilité d'utilisation : La facilité d'apprentissage et d'utilisation du logiciel par les usagers.
• La maintenabilité : La simplicité de correction, de modification et d'extension du logiciel.
  

De ces six indicateurs, seuls les quatre premiers sont respectés par la plus part des architectes, et croyez moi, c'est uniquement la vision contractuelle du projet logiciel qui limite leur conception. En effet, il est clair qu'en appliquant ces quatre principes (Capacité fonctionnelle, Fiabilité, portabilité et Efficacité) au dépends des deux plus importants et plus compliqués à respecter, le contrat sera rempli, le client sera content, et même, il peut arrivé que l'utilisateur final soit aussi content après la recette (car ses cas d'utilisation marchent). En me basant sur la citation de Juan Gris suscité, je dirai que vous avez construit quelque chose qui marche, mais cette chose n'est pas de l'architecture. C'est le fameux Get It Done(GID) de la plus part des architectes.


Un architecte ne doit pas avoir comme référence le GID, mais plutôt le GIR (Get It Right). Le GIR passe par le respect inconditionnel des différents indicateurs de qualité définis par la norme ISO/CEI 9126 et par ricochet est le fruit d'une architecture basée sur l'humain. Il est évident que tout logiciel est conçu pour être utilisé et potentiellement évolué, L'utilisation et la maintenance (corrective et évolutive) sont en générale effectuées par des humains, autres que vous / votre équipe, d'où le concept de développement centré sur l'humain. Un projet de développement logiciel centré sur l'humain est un projet qui respecte les indicateurs de maintenabilité et de facilité d'utilisation et ne vous trompez pas, car pour réellement respecter ces indicateurs, il ne faut pas se limiter aux techniques de l'ingénieur classique qui vous mèneront directement au GID, il faut avoir le savoir faire, et le savoir être; et idéalement, il faut être un software craftsman.


Alors, vous me direz que tout ceci est beau, mais que la réalité reste le respect du contrat, et moi je vous dirai que vous avez raison. Et c'est tout là l'intérêt de ce post, maintenant que vous avez lu cet article, vous ferez désormais le lien entre qualité de code et conception logiciel, ce qui vous permettra de mieux penser vos estimations de budget.


Toutefois, vous devez savoir, qu'avec l’avènement de nouveaux paradigmes de programmation et principalement celui de la programmation orienté objet, des méthodes de conduite de projet par l'agilité, et de l'artisanat du logiciel, vous pouvez concevoir votre architecture GIR en respectant simplement les principes de bases du design objet. Ce qui fait qu'une bonne maitrise des trois types d'architecture: orientée objet, en couche et distribuée utilisés comme base de départ, peut faire le bonheur de tout architecte logiciel.

--------------------------------------------------
Source: http://blog.kadary.me ]]> demkada https://www.developpez.net/forums/blogs/446565-demkada/b343/l-architecture-logicielle/