Et si les méthodologies Agiles étaient une arnaque !

1. L’introduction

L’autre jour en faisant de la veille, je suis tombé sur la question « Les méthodes agiles sont-elles une arnaque ? »  Sur un des forums du site de http://www.developpez.com. J’ai aimé l’idée et dans les prochaines lignes. Je vais poser, avec vous, la réflexion pourquoi ou comment ces méthodologies Agiles ne sont pas une arnaque. Mais, qu’elle pourrait l’être ou semble l’être avec une mauvaise utilisation.

Je sais, je vous préviens ! Je vais prôner pour ma paroisse, après tout, c’est normal. J’aide et j’accompagne les  organisations dans leur bonne utilisation des mêmes méthodologies Agiles. Cependant, à l’opposée, je suis aussi quelqu’un de pragmatique. En conséquence, j’essaie toujours de regarder les deux côtés de la médaille. Tant le bon que le mauvais.

Mon objectif est simple. Je veux vous aider à apporter quelque lumières pour mieux les comprendre ces méthodologies Agiles et justement de vous éviter certains pièges biens emballés

2. D’abord qu’est que c’est ça les méthodologies Agiles

2.1.  Le manifeste

D’abord, à  la base de méthodologie agile, c’est un manifeste de principes et de valeurs qui doivent découler l’ensemble des méthodologies. Je vous réfère à ce lien qui explique correctement ce qu’est le Manifeste Agile.

2.2.  Pourquoi on dit, « Les méthodes agiles » au pluriel.

On appelle les méthodologies Agiles toujours au pluriel. Car, il existe plusieurs méthodes qui découlent des valeurs. C’est quelque part le contrant qui se sont donné plusieurs signataires de ce manifeste  et qui étaient aussi les auteurs de plusieurs de ce méthode dite « Agiles »

2.3.  Les méthodes qui en découlent de ce manifeste.

Il existe plusieurs méthodes, il suffit d’effectuer petite recherche sur Internet, avec les noms des premiers signataires. Vous trouverez rapidement des noms de méthodes comme Scrum, Extrem Programming (XP), Lean Software, etc.. !

3. Ça vient d’où tout ça !

3.1.  Un peu d’histoire.. !

Comme nous le raconte cette petite histoire (en anglais) : http://agilemanifesto.org/history.html, c’est durant une fin de semaine de ski .. ! (Oui, les programmeurs font aussi parfois du sport)  que 17 personnes (expert en informatique et en méthodologies) ont posé la réflexion sur comment on pourrait résoudre les problèmes fréquents en informatique. Surtout en développement de logiciels.

Donc, parfois, sortir du quotidien, on peut arriver à faire de belles réflexions.

Ils ne sont pas arrivés sur une seule méthode. Mais sur des valeurs et des principes nécessaires pour qu’une méthode puisse aider l’équipe de développement à produire un logiciel de qualités et surtout qui correspond aux vrais besoins de l’utilisateur payeur.

Comme beaucoup d’entre nous, ces experts avaient vécu plusieurs projets qui n’avaient pas atteint l’un ou l’autre de ces objectifs. Ils voulaient avoir des  outils pour y arriver. Personne d’entre nous ne veut qu’après des mois, voir des années de labeurs soit travail sont mis sur une tablette. Nous faisons de l’informatique pour voir le « Wow » dans les yeux des utilisateurs finaux.

3.2.  Développer un logiciel, c’est notre travail

Pour un programmeur, faire le développement d’un logiciel, c’est son pain quotidien.  C’est donc normal pour lui d’identifier certain héritant ou choses qui ne fonctionnent pas. C’est aussi que plusieurs grands passeurs, surtout provenant du monde l’ingénierie (ceux qui bâtissent des ponts, des grands bâtiments) ont tous voulu créer une méthode qui serait idéalement infaillible pour arriver à livrer un projet en informatique en temps et argent. La fameuse équation!

Après tout, c’est le but de tout projet, informatique ou pas ..! Mais, avec l’expérience, on s’est vite aperçu que certains approchent de nos amis constructeurs de ponts. Ne fonctionnaient pas toujours dans notre contexte.

La science de l’ingénierie civile est une science qui date des lunes, les Romains construisaient des points! Mais, l’informatique, c’est encore tou jeune. Et parfois, certaines comparaisons. Ne fonctionne pas !

Donc, c’était tout à fait normal que des gens qui c’est leur métier de construire des logiciels sont mis à réfléchir sur l’art et le comment on pourrait le faire justement pour améliorer ce qui à nos yeux ne fonctionnait pas.

3.3.  La quête de l’impossible.

Car, pour la plupart (on le  souhaite tous), nous voulons construire un logiciel qui sera utilisé par le plus grand nombre possible d’utilisateurs. Mais, pour ce faire, il doit correspondre  aux besoins du plus grand nombre possible d’utilisateurs.

Mais, comment arriver à faire cette quête de l’impossible. Plusieurs y avaient réfléchi avant nous. Néanmoins, ils l’ont fait en apportant des processus parfois trop complexes, et qui parfois font dévirer de notre objectif simple de livrer un logiciel fonction et qui correspond aux besoins du client.

Les programmeurs, en général, on aime les choses simples et efficaces… À la limite, on est un peu tartinait paresseux. Donc, les processus complexes et compliqués. Ce n’est pas pour nous. Nous voulons faire les choses simplement et efficacement. Et pourquoi pas, dans la joie et le bonheur ..!

4. Si ça serait une vraie arnaque

4.1.  Définition

J’aime bien la définition (surtout la note) de l’Office québécois de la langue française d’une arnaque :

Définition

Technique de violation de la sécurité informatique, qui consiste à amener une entité autorisée à se livrer, à son insu, à un acte préjudiciable pour elle-même ou pour son organisation, en lui laissant croire, à tort, qu’elle est en communication avec le système informatique.

Notes

La mystification vise, le plus souvent, à obtenir de l’information pour laquelle aucun accès n’a été accordé, en amenant l’utilisateur légitime détenant cet accès privilégié à fournir son mot de passe.

La mystification vise, le plus souvent, à obtenir de l’information pour laquelle aucun accès n’a été accordé, en amenant l’utilisateur légitime détenant cet accès privilégié à fournir son mot de passe.

4.2.  Ramenons-nous dans un contexte de développement logiciel.

Une arnaque serait un processus ou procédé qui permettrait de charger inutilement du temps où des efforts à un client pour en fin de compte pour lui livrent un logiciel complètement inutile ou encore qui ne correspond pas du tout à son besoin.

Donc, un travail qui irait complètement à l’inverse du principe 1 des méthodologies agiles :

« Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée. »

Ou encore plus simple, faire des travaux qui n’aident en rien à l’objectif premier  qui est de produire un logiciel de qualités. Exemple ne pas faire de la documentation. Car en Agile on n’en fait pas. Pourtant, c’est faux, j’ai d’ailleurs répondu à cette question dans cet article « On documente, quoi, quand et comment ? »

5. Cette invention vient des programmeurs, mais… !

5.1.  Tout le monde le sait

Les programmeurs on vient tous de mars ou a peut-être tout près. J’en ai vu aussi quelques Vulcains.  C’est magique voir bizarre notre travail. On veut faire penser une machine qui ne connait que zéro et des uns. Et qui ne sait que faire des additions, soustractions et multiplications.

C’est fou, je le sais. Mais, nous avons choisi de travailler pour vous aider à bien utiliser ce petit monstre en vous créant d’outils pour mieux interagir avec lui. Donc, c’est normal que parfois, traduite de 0 et 1 en français c’est aussi un travail fou. C’est donc normal parfois d’avoir de la difficulté d’arriver aux buts. Donc, parfois entre 2 lignes de codes, on réfléchit aussi à trouver la meilleure manière de faire les choses.

5.2.  C’est vrai aussi !

L’ensemble pour ne pas dire tous, les cosignataires du manifeste et aussi auteurs de méthodologies de développement, ont été programmeur expert sur des grands projets informatiques. Et de manière sur avant d’autant certain, on mise en œuvre à plus d’une reprise aussi les approches qu’ils préconisent. Ce n’est pas que de belles théories, c’est aussi des années de pratiques en seins de grandes organisations.

Avoir une méthode  pour un projet de 2 personnes d’une durée d’une semaine. Ça ne veut rien dire. Mais, en avoir une qui a fait ses preuves sur des projets majeurs avec de grandes équipes.

5.3.  Ils ont signé le manifeste, mais leurs méthodes existaient avant.

L’ensemble de ces programmeurs était de plusieurs grandes méthodes qui existaient de plusieurs années. À titre d’exemple, la fameuse méthode Scrum, les premiers travaux qui ont commencé dès 1991.

Je vous ne ferais pas l’historique de toutes les méthodes des signataires du manifeste.  Mais, disons simplement qu’ils n’avaient pas écrit la fin de semaine d’avant.

6. Pourquoi les gens pensent que c’est une arnaque

Lorsqu’on n’est pas un spécialiste de l’informatique. Certains travaux nécessaires à la production d’un logiciel, sont d’une nature très complexe voir impossible à comprendre pour les non initier. Ouvrir un fichier de code, ce n’est pas à la porter de tout le monde.

C’est pour cela que les processus classiques ont voulu offrir des outils de communications ..! Parfois, tellement contraignant qu’il en devenait de carcan plutôt que la facilité.

6.1.  Les programmeurs sont leurs coins.

C’est vrai ! Mais, si vous voulez faire quelque chose d’important, voire parfois complexe. Vous allez avoir besoin de toute votre concentration. En étant dans notre coin, c’est en plein ce que vous recherchons d’avoir notre pleine concentration.

C’est aussi un travail qui se fait en individuelle qu’en équipe. Donc, parfois, être ensemble, c’est utile.

6.2.  L’absence de documentation. est-ce vraiment « VRAI »

J’aurais aimé qu’on me donne 100$ à chaque fois qu’une personne m’affirmait qu’en Agile on ne fait pas de documentation, je serais surement riche ..! Mais, j’ai toujours répondu, pensez-vous vraiment que quelque part sur terre, on peut faire un projet d’informatique d’entreprise sans faire une ligne de documentation ?

C’est vrai que le manifeste dit « Des logiciels opérationnels plus qu’une documentation exhaustive ». Cependant, il ne dit pas, « Pas de documentation ». Il faut parfois savoir lire au-delà des mots. Car, en Agile, on fait de la documentation lorsque c’est nécessaire et que cela nous aide à atteindre l’objectif de livrer le meilleur logiciel pour notre client.

6.3.  Des mauvaises pratiques qui amènent des arguments pour l’arnaque

6.3.1.     De faux praticiens Agiles qui affirment.  « Pas de documentation.. »

Malheureusement, l’une de ces pires mauvaises pratiques, c’est justement d’affirmer qu’on ne fait pas de documentation. J’en ai rencontré malheureusement beaucoup trop, des informaticiens, un peu mal intentionnés, qui se servaient des « Approches Agiles » pour esquiver certains travaux, dont la documentation et le suivi, pour pouvoir livrer le projet comme eux voulaient le faire.

Dire qu’ils sont praticiens agiles, c’est gens là, s’en est presque un crime. Car avec les méthodologies Agiles, on ne cherche pas à dire ce qu’il ne faut pas faire. Mais, ce qu’il serait recommandé de faire. On cherche le meilleur moyen d’y arriver.

En conséquence, faire de la documentation, de la bonne documentation à temps et avec le format ou médias, là c’est de respecter les principes agiles.

6.3.2.     Ils sont enfermés dans un coin.

Oui, l’équipe doit être dédiée au travail, et même parfois, être regroupée dans un même secteur. Mais, ce n’est surtout pas un vase clos. Ils doivent avoir des outils pour communiquer leur avancement comme le product backulog et le product burndown.

De plus, vous avez une personne, « product Owner » qui doit être aussi votre représentant dans cette belle équipe. Son rôle aussi est de communiquer avec vous, de vous mettre en relation avec ce qui se fait.

Et n’oubliez pas, construire un logiciel, ça demande un grand nombre d’heures de travail. Donc, s’ils sont acharnés à leur travail. Ils pourront y arriver plus facilement.

7. Le but dans tout ça

Le but se résume facilement en citant le premier principe du manifeste : « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »

7.1.  D’abord et avant tout mieux servir vous le client !

Oui, nous sommes de passionner, parfois même des bidouilleurs. Mais, détrompez-vous, on veut vous servir au mieux. C’est notre but ultime. Parfois, certaines autres méthodes oubliaient ce dernier détail.

Parfois, servir un client, ce n’est pas toujours facile. Nous parlons souvent 2 langages qui ne se ressemblent pas.  Donc, c’est pourquoi il faut se ramener aux valeurs de bases de la communication et surtout se rappeler pourquoi qu’il faut prendre le temps de communiquer.

C’est si facile de partir dans les grandes élocutions, de grands écrits.. Si tout ce qu’on fait ne vous aide pas à mieux vous servir. Tout ça ne sert à rien. C’est vous qui payez en bout de course. Vous devez en avoir pour argent.

Toutefois, cette quête de bons services ne sert à rien, si tout le monde, vous aussi, vous ne faites pas d’effort dans ce processus de communication pour nous aider aussi à bien vous servir.

7.2.  Deuxième, mettre les meilleures pratiques logicielles à votre service

Ils existent plus d’une pratique logicielle. Mais, parfois, il faut savoir utiliser la bonne et surtout ne pas avoir de changer en cours de route si on se rencontre qu’elles ne convient pas.

De plus,  d’un autre côté en utilisant la ou les meilleures pratiques vont nous aider à vous construire le meilleur logiciel.

C’est aussi simple que choisir de prendre un tournevis pour enlever une vis. Au lieu du marteau. On y arrivé avec le marteau. Mais, avec certains dommages.

7.3.  Et bien sûr vous livrez le meilleur logiciel pour répondre à votre besoin

C’est promis on va faire les efforts pour répondre à votre besoin. Mais, en échange vous devez-nous-l’exprimé au mieux possible. C’est donc une responsabilité partagée avec vous aussi.à

8. En terminant, l’arnaque ?

8.1.  Oui, et si les programmeurs se servent de ce chapeau pour ne pas respecter les règles de l’art

Dans le meilleur des mondes, il y a aussi des gens qui veulent profiter du beurre, de l’argent du beurre et le sourire de la fermière. C’est triste, c’est aussi la vie.

Donc, ce n’est pas parce que vos ressources ou vos consultants utilisent les méthodologies agiles. Que vous devez fermer complètement les yeux. C’est aussi votre devoir.

8.2.  Oui, et si vous ne vous impliquer pas dans le projet !

C’est votre logiciel, c’est pour vous qu’on nous allons le construire. C’est donc normal que vous impliquer selon vos capacités.

Si vous décidez de donner un chèque en blanc, je suis sûr que vous en aurez pour votre argent.. Ironie!

8.3.  Oui, et si vous engagé n’importe qui pour faire n’importe quoi !

Mon père m’a dit tant qu’il a vécu, chacun son métier, et les vaches seront bien gardés. C’est la même chose en informatique. Il faut engager les bonnes personnes pour faire le bon travail.  Ce n’est pas vrai qu’un informaticien peut tout faire. La plupart d’entre nous sont spécialistes.

C’est bête de vouloir prendre un mécanicien automobile pour lui faire réparer un moteur d’une machine dans une usine. Il pourra peut-être y arriver. Mais, si vous avez engagé un mécanicien de machine fixe pour réparer votre machine fixe. Le travail en saura d’autant meilleur.

C’est exactement la même chose en développement logiciel.

8.4.  Mais surtout, ce n’est pas pour tout le monde et tous les projets !

Les méthodologies agiles fonctionnent pour beaucoup de projets et d’organisations. Mais, ce n’est pas fait pour tout le monde.

Ça va vous demander une certaine ouverture d’esprit, une implication que voudrez être prêt faire. Voir changer complètement vos processus et encore plus.

Donc, si vous n’êtes pas prêts. Prenez donc 2 secondes pour y réfléchir.

D’autant, si vos méthodes fonctionnent bien dans votre organisation. Vous n’en avez peut-être pas besoin. Parfois, le super marteau pneumatique et automatique pour clouer des super clous. C’est peut-être inutile dans une usine qui fabrique des cabanes oiseaux donc la productivité est pleinement efficace.

9. En conclusion

Par fois, la meilleure pratique avec les meilleures intentions du monde dans de mauvaises mains. Donne parfois n’importe quand.  Soyez avertis. Les méthodes agiles entre de mauvaises mains peuvent devenir une arnaque, c’est sûr!

Mais, bien utilise et comprise, par vous et vos équipes de développement, elles pourront surement vous aider à atteindre  le fameux objectif de livrer le meilleur logiciel en temps, en argent et surtout en respect de vos besoins.

L’arnaque, je ne pense pas si c’est utilisé dans de bonnes conditions.

Le TDD, vous aimez, vous avez essayé … Mais ..!

  1. Mise en contexte

Les approches TDD (Test Driven Developpement) et ATDD (Acceptente  Test Driven Developpement) sont des outils que toutes organisations qui veulent se tourner les méthodologies Agiles devraient utiliser.

C’est une approche qui est bien documentée et il existe beaucoup de formations qu’on peut suivre qui va vous expliquer l’art et la science sur le comment faire des tests automatisés de vos développements logiciels.

Aux files des années, j’ai vu plusieurs organisations ont voulu se lancer en lisant cette bonne documentation et envoyant leurs ressources faire les formations. Elles ont aussi beaucoup de temps à mettre en place les outils tel que NUnit ou Ms-Tests, JUnit .. ou autre framework de tests.. Mais, le “Mais du titre” malgré les efforts, le temps et même l’argent. Vous n’en avez pas fait le succès tant recherché.

Conséquence, vous avez arrêté d’en faire. Car, vous n’y voyez plus votre profit à l’exercice.

  1. La transformation, elle n’est pas facile à faire

Mais, la vie et aussi en informatique. Il faut parfois faire une bonne préparation. Même si l’approche est bien documentée, je le reconfirme. Il faut mettre en place des choses, voir faire des ajustements dans vos environnements avant d’ajouter cette suite d’outils dans votre arsenal.

Imaginer que vous toujours utiliser le langage Cobol dans un environnement central. Mais, du jour au lendemain, vous décider de passer à un environnement Web genre ASP.NET en C#. Il ne suffira pas de former, au langage C#, vos ressources. Ils devront apprendre une toute nouvelle manière de programmer. Mais, vos architectes devront aussi penser différemment leurs désignes d’applications. 

C’est la même chose, lorsqu’on veut de se lancer dans les approches de type TDD. Il y a des devoirs à faire. Il faut aussi apprendre à nos programmeurs à faire des tests. Toutes les formes de tests et pas seulement ceux automatisés. Car, avant de faire des tests automatisés, il faut savoir bien tester et surtout savoir qu’est-ce que c’est un test.

Ils devront aussi apprendre à programmeur leurs classes, leurs fonctions. Autrement dit, revenir à la base des techniques de programmation. Car, un vrai test, ça doit tester une seule chose. Et dans nos livres d’initiation à l’université, une fonction devait aussi faire une seule chose.

C’est la même chose au niveau du design Les classes doivent avoir cette d’être dite testable. J’attends par testable, qu’elle soit simple à construire le code qui fera le test de la fonction et des fonctions.. Le temps normal d’un test unitaire automatisé devrait être quelque secondes (2-5 secondes. Voir généralement, moins d’une seconde.

Donc, il faut aussi penser un design pour facile à tester. J’ai déjà vu des classes que pouvoir faire un des  tests automatisés avec elle. Il fallait mettre plusieurs heures de travail, pour automatiser la création du test et je ne parle du grand nombre des lignes de code qu’on doit écrire. On vient presque être obligé de faire un test fonctionnel pour ce qui devait être à l’origine un test unitaire.

  1. On fait comment ?

Bravo, vous avez décidé de poursuivre ! Mais, vous voulez savoir comment on fait ?

La première étape, je crois que vous l’avez fait, c’est-à-dire donner une formation sur l’art du test automatisé. Ils sont heureux , (je vous le souhait et je l’espère) d’avoir fait cette formation. Mais, malgré qu’ils aient un bel outil entre les mains.

Il faut passer à la prochaine étape, mettre le cadre d’utilisation de ce nouvel outil. Ce n’est pas parce que vous avez choisi d’utiliser cette approche qu’il faut l’utiliser partout d’un premier temps.  Je recommande d’abord le faire sur un petit projet. Comme dit si bien, l’expression, l’expérience s’acquièrent avec le temps.

Voir peut-être, permettre d’abord seulement à certaines ressources de l’utiliser dans un petit projet ou partie d’un projet. Trop souvent, les organisations veulent faire ce virage en grande vitesse, et ce, n’est pas toujours une bonne idée.

Profitez-en pour définir sur quoi , ils seront utilisés. Car, les tests automatisés ne convient pas à tout et pour tout. Vous n’aurez peut-être pas tous les gains d’une intégration complète. Mais, la partie où ils seront utilisés vous apportera d’un premier temps la rentabilité tant recherchée.

  1. Plus qu’un framework générique

L’autre chose importante qu’il faut réfléchir. C’est que parfois nous avons besoin plus les outils d’un framework générique. Un framework générique comme son nom l’indiquent,  sont conçus pour faire un travail générique.

Donc, parfois, lorsqu’on veut lui faire un travail plus particulier ça demande une connaissance particulière. Mais, pourquoi faire évoluer cette solution générique vers une solution plus particulière qui répondra à vos besoins.

Exemple, vous testez souvent des dates de transactions qui doivent être validé dans des conditions que vous pouvez généraliser. Pourquoi ne pas vous en faire un kit de tests prédéfinis.

En établissant cette suite de tests, vous pourrez facile vous assurez de leurs qualités. Mais aussi, facilité le travail de vos programmeurs.

  1. En conclusion

Choisir de faire un passage aux tests unitaires automatisés n’est pas une chose simple. Elle doit se faire en plusieurs étapes tout comme toutes les transitions vers une méthodologie Agile.

Elle aura des impacts partout dans votre développement logiciel. Mais, si vous persister que vous faites les bons choix et que vous avez un bon accompagnement. Je crois qu’avec le temps, vous en ferez un succès.

L’architecture Agile et la documentation.. Est-ce possible ?

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

1. Introduction

Souvent lorsque nous parlons des Méthodologies Agiles,
l’un des premiers éléments qui sont souvent cités. C’est qu’on ne fait pas de
documentation. Pourtant on doit en faire, c’est nécessaire. Je vous ai donné
les premières bases de la documentation ici dans cet article On documente quoi et comment.

Mais, lorsqu’on réussit à convaincre les gens, que la
documentation est nécessaire. Il y a encore trop souvent, une de ces grandes
parties délaissées de la documentation. C’est bien la documentation de
l’architecture. Pourtant, c’est la base de notre logiciel.

Soyez prévenu, choisir de documenter son architecture. Ce
n’est pas un choix facile. Car, il y a plusieurs approches. Mais, la seule et
unique règle que nous vous recommandons, c’est la simplicité et l’efficacité
doit primer sur tout le reste.

De plus, peu importe votre choix d’outils pour documenter
votre architecture, c’est très important. Il doit produire une documentation
vivante et partageable facilement.  Et pourquoi pas, être écologique en
priorisant une solution électronique de vos documents.

2. Pourquoi documenter l’architecture, c’est bien qu’une question de choix

La phase de l’architecture de notre logiciel est l’une des
plus importantes, tout au long de notre processus de développement logiciel.
Elle a pour but d’apporter la vision tant sur le travail à accomplir que sûre
qu’ont les orientations possibles de notre logiciel.

Mais la meilleure manière de partager et de présenter cette
vision, surtout au-delà de la période  de développement. C’est faire de la
documentation de l’architecture, et peu importe le format, elle sert essentiellement
à communiquer durant le développement aux membres de votre équipe qui mettront
en œuvre cette vision.

L’autre point important pour lequel nous faisons de la
documentation, c’est pour la partie d’entretiens du cycle de vie de notre
logiciel. Un logiciel en moyen passera entre 75%-80% du temps en mode
entretien. Souvent, l’équipe qui fera cet entretien sera différente de celle
qui l’aura développé. Donc, il risque fort qu’il n’ait plus personne pour
raconter l’histoire des décisions qu’on a prises dans les différents travaux
d’architecture et d’analyse.

C’est facile de voir un beau modèle objet ou de données,
qu’en on la personne qui l’a conçu pour l’expliquer. Mais, imaginer que la
personne n’est plus dans l’organisation pour expliquer ces choix. Il peut
arriver que certains morceaux soient plus difficiles à comprendre.

En fin compte, faire ou non, la documentation c’est bien
une question de choix, de choix sur le comment on va la faire. Mais aussi,
jusqu’à où on va la documenter.

2.1. Juste assez, juste nécessaire

La règle qui régit ma pratique est juste assez pour la
compréhension des équipes qui vont nous suivre. Mais aussi nécessaire à garder
l’historique ou l’histoire de décisions qui ont été prises dans les différentes
étapes de la conception. La responsabilité de l’architecture, c’est de trouver
des solutions, avant qu’ils ne surviennent !

Autrement dit, ce qui est nécessaire pour comprendre le
processus décisionnel et le résultat obtenu. Donnez aux équipes l’information
qui leur sera utile pour continuer à maintenir ce que vous et votre équipe a
mis en œuvre. Il faut répondre  au pourquoi et comment on prit cette décision.

3. La documentation de la modélisation, UML pourquoi ou pourquoi pas!

L’un des outils qui sont souvent utilisés en modélisation,
c’est bien UML. C’est un excellent outil pour présenter la modélisation tant
objet que donnée.

Mais parfois, cette forme de modélisation n’est pas
toujours accessible à tout le monde. Elle est plus destinée aux personnes plus
techniques. Pour ma part, je l’utilise pour discuter avec les programmeurs ou
autres gens techniques.

Apprendre UML, malgré qu’une la connaissance peut
s’apprendre dans les livres ou assit dans une classe de formation. Il reste
toujours que le reste de la connaissance s’apprend uniquement par l’expérience.

Donc, malgré les nombreuses qualités d’UML, et je suis
loin d’en faire le procès ici, il ne correspond pas à tous les besoins et n’est
pas destiné à tout le monde.

A titre d’exemple, un diagramme de classe pour expliquer
le contenue d’un logiciel à client qui ne connait pas la modélisation objet, je
ne suis pas sur qu’il va comprendre quelque chose.

Il faut donc trouver un outil, un langage que toutes les
personnes impliquer dans la discussion vont comprendre. Et au besoin, pourquoi
pas d’inventer votre en cas de besoin.  Dessiner vos propres diagrammes, un
formalisme que tous les gens vont comprendre.

Et bien sûr, server aussi d’UML avec les gens qui le
comprennent ou encore si c’est plus facile pour vous. Mais, n’oubliez pas
l’objectif c’est de communiquer et de partager

4. Une documentation plus écrite ou en mode texte

Le premier réflexe que plusieurs personnes quand on parle
de documentation. C’est d’ouvrir un traitement de texte  (Genre Microsoft
Word). Mais, parfois, écrire un texte  pour tout détailler. Ça ne correspond
pas au besoin que vous devez combler.

Certaines choses se décrivent bien dans un texte. Mais
d’autres pas. Il faut savoir quand et comment, il faut  le faire dans un texte
ou avec un autre moyen.

De plus, il ne faut pas oublier que la plupart du temps,
un texte est un complément aux autres composantes qui documentent l’application.
Donc, il ne faut pas chercher à tout écrire ce qui est déjà dit d’une autre
manière  dans un autre outil.

J’ai trop souvent vu que les gens écrivaient en mode texte
un cas d’utilisation ou autre chose qui se décrivait par lui-même. Plus tôt, se
limiter que simplement décrire les cas limites ou l’interaction avec d’autres
cas.

Fixer la limite du texte ou de sa portée n’est pas une
chose facile, certaines règles s’appliquent. Mais c’est aussi un peu un art et
une science.

4.1 L’art et la science de la documentation.

Savoir limiter la portée d’un texte est  tant un art
qu’une science. Mais, de manière simple, je dis souvent d’écrire en mode texte
ce qui n’est pas évident au premier regarde des autres composantes de
documentations. Surtout si vous n’êtes pas là pour donner les explications
manquantes. Dans le cas contraire, ajouté du texte qui permettra à votre
lecteur de bien comprendre.

Un petit truc de métier, lorsque je ne suis pas sur de la
facilité de la compréhension. Je présente le diagramme ou le texte à une
personne qui n’a pas ma connaissance et je lui demande de m’expliquer ce qu’il
comprend. Généralement, je limite ce petit exercice à 3-5 minutes pas plus.
S’il n’est pas capable de m’expliquer, c’est qu’il manque de l’information ou
encore que mon diagramme est trop complexe.

5. Conclusion

En conclusion, faire la documentation de l’architecture
d’un logiciel ce n’est pas une chose facile à bien faire. Mais, ce n’est pas
pour autant qu’il ne faut pas la faire.

C’est  un défi qu’il faut relever. Car, un logiciel et son
architecture aura une vie beaucoup plus longue qu’on peut l’imaginer lors de sa
conception. C’est donc la documentation qui l’un de ces maillons qui, je crois,
vous permettra de rendre agréable toute la vie de votre logiciel. Tant durant
son développement que durant son entretien.

Il ne vous reste plus qu’à trouver  votre besoin en
documentation et comment le combler!.

Présentation d’une conférence à la communauté RéseauTIQ d’Action TI.

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Nous sommes heureux de vous annoncez que nous avons été invités par le groupe RéseauTIQ d’Action TI à présenter une conférence sur l’architecture logicielle en contexte de projets Agiles.

Le Groupe RéseauTIQ (Action TI) invite régulièrement des experts en à venir présenter un exposé sur divers sujets entourant les meilleures pratiques de l’industrie du logiciel.

C’est donc dans ce contexte que M. Bruno Larouche fut invité à venir présenter une conférence sur l’architecture logicielle à cette communauté. Comme l’expertise est, son expertise était au niveau de l’architecture logiciel et surtout l’Agile Modelling. Il a choisi de présenter une conférence sur la mise en œuvre des bonnes pratiques Agiles dans les phases d’architectures logicielles. Cette conférence fut (ou sera)  présentée au groupe RéseauTIQ de  Montréal le 27 novembre 2011.

Pour avoir plus de détail sur la présentation, je vous inviterais à vous diriger vers l’adresse suivante : «De l’idée à la mise en œuvre: L’architecture logicielle en mode Agile »

Mes quatre murs de mon bac à sable : Développement logiciel

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

  1. Introduction

Combien de fois, j’ai attendu dire par des clients ou d’autres personnes, même des professionnels de l’informatique. Qu’il suffisait de mettre beaucoup de programmeurs ensemble pour produire un bon logiciel et parfois, en sous-entendant qu’on pourrait aussi le fouetter de temps en temps, s’ils accumulaient un peu de retard.

Mais aux jours d’aujourd’hui, il ne suffit plus de mettre une gang de programmeurs ensemble. Construire un logiciel aujourd’hui c’est un autant un art qu’une science. Un groupe de programmeurs peuvent faire un excellent travail. Mais, il leur faut un terrain de jeux, un environnement de travail qui leur permettra de mettre efficacement leurs compétences en action.

Qu’est-ce que ça demande de plus ? C’est une question qu’on me pose souvent. Lorsque, je réponds à cette question. J’utilise souvent l’apologie du bac à sable. Un bon bac à sable bien construit, les enfants peuvent y jouer tout en sécurité. C’est un peu à cette image qu’il faut construire l’environnement des programmeurs. En leur donnant tant les outils que l’environnement (le mur et le sables), ils pourront exercer leur travail de programmation au mieux.

  1. Le premier mur celui l’analyse fonctionnelle

Le premier mûr, j’avoue aujourd’hui, c’est lui le moins oublié. D’autant que la formation de nos programmeurs d’aujourd’hui fait partie de la formation de base dont ils reçoivent tant nos Cégeps que nos universités.

  1. L’analyse fonctionnelle, c’est quoi ?

Mais, avant de vous parler de l’importance de l’analyse fonctionnelle, je vais d’abord définir ce que c’est. Pour moi, l’analyse fonctionnelle c’est d’abord le processus qui permet de répondre à la question:  « c’est quoi ce va faire le système à construire ? » ou plus simplement, décrire le comportement attendu par l’application à la fin du processus de développement.

C’est aussi de définir le processus qui permettra de comprendre les différents scénarios d’utilisations possibles (positif). Ceux que l’utilisateur pourra faire. Ainsi que les limites ou le cadre de ces scénarios.

Il est aussi important de définir les scénarios impossibles. Un marteau ne coupe pas une planche de bois. C’est la même chose pour un logiciel. Il ne fait pas tout. Ça serait trop le fun ! 😉

  1. L’importance de l’analyse fonctionnelle

Une règle bien simple pour se rappeler l’importance de faire ou non un dossier fonctionnel. La règle, c’est simple si c’est plus compliqué qu’un « hello word » et qu’on ne peut résumé le « Détail » du traitement et des scénarios en 2 phases que tout le monde va comprendre, on fait un dossier fonctionnel.

Il ne faut pas oublier que le dossier fonctionnel, ne sert pas seulement au développement du logiciel ou de la fonction du logiciel. Il est aussi utile pour la maintenant, les essaies et comme documentation initiale.

Mais d’abord et avant tout, c’est un contrat qui lit l’équipe de développement avec le demandeur de ce logiciel, le client. Qu’il soit externe ou externe à l’organisation ou à l’équipe, il le lit. C’est lui qui permettra de définir si ce qui a été demandé a été bien livré. !

Donc, sans ce mur, nous ne serons pas par où entrer !

  1. Le deuxième mur, l’autre pendant de l’analyse, celle organique ou logicielle

L’autre mu qui a aussi toute son importance, c’est bien l’analyse organique. Mais avant de définir l’importance, je vais définir c’est quoi.

    1. La définition, ça manche quoi en hivers

Ça mange quoi en hivers cette analyse organique. Mais, c’est justement c’est qui nous empêche d’avoir en hiver. L’analyse fonctionnelle nous a dit quel genre de maison et comment elle serait divisée. Mais c’est l’analyse organique qui nous dira comment les murs seront faits et surtout comment commander les matériaux nécessaires pour construire cette maison.

J’allais oublié, en informatique nous ne construisons pas de maison. Mais des logiciels, et parfois des logiciels pour aider à la construire c’est tout… hi hi !

Vous trouvez mon apologie drôle, mais pourtant elle dit vrai. Il faut aussi définir comment sera fait l’ensemble des morceaux de notre logiciel. C’est le plan détaillé de toutes les cloisons, le filage et la tuyauterie de notre maison.

C’est aussi à cette étape qu’on va prendre les décisions sur l’art et le comment on va faire les choses. Qu’ont déterminé si on va se construire des gabarits ou des modèles pour pouvoir récupérer le travail ou encore le simplifier.

Construire un logiciel, c’est bien plus qu’écrit du code dans un langage de programmation.

    1. Est-ce qu’on ne peut pas en faire !

On me dit souvent, mais programmeur sont bons et ont beaucoup d’expérience. Donc, pas besoin de faire cette étape. Mais parfois, il faut savoir où sera la cuisine ou la salle de bain, pour savoir comment passer les files ou les tuyaux.

Vos ouvriers, les programmeurs, sont peut-être très compétents. Mais parfois, il faut avoir plus que la vision de la pièce qu’on construit.

Les programmeurs d’aujourd’hui sont des bons intégrateurs ou de bons assembleurs. Mais il faut parfois, voir souvent leur donner un bon plan. Imaginez vouloir assembler un meuble IKEA sans le manuelle d’instructions. C’est presque impossible, vous risquer d’avoir un résultat incertain ou encore avoir des pièces en trop. C’est la même chose avec logiciels.

Donc, faire une maison ou une meuble IKEA sans plan, pas pour moi. A la limite, j’accepterais un plan partiel plutôt que de ne pas en avoir du tout.

    1. C’est qui le fait

Donneriez-vous à votre meilleur ouvrier le travail de construire le plan du pont qui servira à faire passer des camions. C’est la même chose pour ce travail. Ça demande un professionnel de l’analyse organique. Je vous reviendrais prochaine avec ce profil dans un autre billet.

  1. le troisième mur, les tests unitaires automatisés.

Allez, je vous propose un petit jeu. Je vous donne procédure de 10 étapes et à chacune d’elle vous devrez valider le résultat. Jusque-là c’est facile.

Complexifions ce petit jeu, je vous demande de refaire 100 (cent) fois, voir 1000 (mille) cette même procédure. Et à chaque fois, le résultat des étapes peut changer aléatoirement. Je suis sûr que vous me direz que c’est compliqué et que le risque d’erreurs de tout genre est grand, et vous aurez raison.

C’est pourtant ce qu’on demande à un programmeur de faire pour valider son travail.

  1. L’ordinateur c’est bien faire !

Un ordinateur c’est bien essentiellement quatre grandes taches, addition, soustraire, multiplier et comparer un résultat.

Le plus drôle de l’histoire, c’est aussi ce qu’on demande généralement dans un test unitaire. Donc, pourquoi ne pas demandé à l’ordinateur de le faire pour nous. C’est la réflexion que plusieurs informaticiens on fait lorsqu’ils ont développé les outils de tests unitaires automatisés.

  1. La qualité d’un bon logiciel

La qualité d’un bon logiciel passe par la qualité de ces tests unitaires, mais aussi par leur exécution. Nous savons qu’il est difficile de bien répéter un très grand notre de fois la même procédure sans risque d’erreurs.

Nous savons aussi que l’ordinateur c’est bien faire cette tache. Donc, pourquoi ne pas lui faire faire. D’autant, ce n’est pas parce que les tests exécutés la semaine passée se sont terminés avec succès. Que le résultat ne sera pas différent aujourd’hui avec toutes les modifications qu’il y a eu dans le code.

Avec les tests unitaires automatisés, on peut relancer plusieurs tests, même ceux qu’on pense que le nouveau code. Vous serez peut-être surpris.

Un test unitaire automatisé, c’est un peu comme testé le pilier du pont, tout au long de la construction, et ce, avant que les gros camions passent dessus.

  1. le dernier pour compléter le carré, le gestionnaire de sources.

Faites-vous des backups d’un document important sur lesquelles vous travaillez ? Normalement, oui ! (Sinon vous devriez !).. Imaginez donc, travaillez sur plusieurs documents (fichier de codes sources) en simultanés et surtout par plusieurs personnes.

C’est impossible, pourtant c’est se qu’on fait à tous les jours avec nos fichiers de code. Il y a plusieurs stratégies et plusieurs outils, du simple partage réseaux jusqu’à l’outil qui fait la gestion des sources.

  1. La gestion des sources

La gestion des sources, c’est l’art de prendre une copie des fichiers, mais aussi de conserver les différentes versions. Jusque-là, on peut le faire avec plusieurs répertoires, voir plusieurs disquettes.

En plus, il est intéressant de savoir ce qui a été modifier et surtout par qui, pour le cas, qu’on ne comprendrait pas la démarche de la modification. Ce cas, il ne suffit pas avoir seulement 2 versions du fichier.

Imaginez, une application moyenne d’aujourd’hui, c’est grosso modo 500 voir 1000 et plus fichiers. Donc, savoir à quelle version on est rendu .. Disons simplement que c’est trop compliqué sans outils.

Vous comprendrez aussi, que conserver des dizaines de copies, le volume de données stockées devient rapidement important. C’est pourquoi que nous avons besoin d’un outil qui le fera pour nous. D’autant que les outils de gestion de sources modernes gèrent l’historique des versions en conservant seulement le différentiel. La partie qui a été modifiée, le fichier sont construits en appliquant les modifications sur le fichier de référence

  1. Pour vivre sans !

Vivre sans, c’est possible .. Mais à, mais yeux, on n’a pas justification valable. Car, il y a de bons produits open source et même des sites web qui offre ce service.

Ce n’est pas la qualité de votre personnel ou de vos processus qui peuvent justifier l’absence d’un outil dans votre environnement de développement logiciel.

A titre d’exemple, même les projets que je suis le seul développeur, j’utilise un outil de gestion de sources. Donc, pourquoi pas vous ?

  1. La conclusion

En conclusion, développer un logiciel, c’est bien plus que d’écrire du code qui va répondre aux quelques notes qu’on avait prises pour dire ce que ça ferait.

Si ça était si facile, tout le monde le ferait et nos grandes écoles (collèges et universités) ne forceraient pas pour l’enseigner. Il n’aurait pas non plus des gars comme moi qui prônent l’idée et pour certain en écrive des livres sur le sujet.

Tenez-le pour dit, sans c’est 4 murs indispensables à la construction d’un bon logiciel. Vous allez m’entende argumenter longuement et avec beaucoup d’acharnement.

Vos ressources sont compétences, donnez leur un bon environnement de travail et surtout de bons outils. Ils ne pourront qu’en être meilleurs et davantage concentrer sur le vrai travail de développement logiciel.

Êtes-vous des “Pig” ou des “Chicken” ?

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Cette petite apologie est souvent utilisée dans les méthodologies Agiles pour donenr une explication sur la motivation et l’implication des membres d’une équipe.

À l’origine, l’histoire racontait qu’un Porc (Pig’s) et un Poulet (Chicken) ont eu l’idée de démarrer ensemble un restaurant spécialise dans les déjeuners. Les deux voulaient offrir quelque chose qui venait d’eux.

Le poulet décida d’offrir des oeufs avec lesquelles, on pouvait en faire plein de choses. Le porc, quant lui proposa d’offre du bacon ou jambon. L’offre du poulet avec ses oeufs était presque illimitée. Car, chaque jour, il pondait un nouvel oeuf. Quant à lui, le porc mettait sa vie en danger. Car, il devait donner une partie de son corps pour produire le bacon ou le jambon. Ce qui a pour conséquence directe de mettre sa vie danger. Donc, un don pour ce dernier, n’est pas illimité.

Certain auteur, lorsqu’ils font référence à cette petite histoire, associe souvent le concept du don de soit à don sans limites. Pour ma part, je ne crois pas qu’il faut mettre sa vie en danger pour vraiment s’impliquer dans un projet. Ces auteurs, sous entende parfois que les programmeurs doivent s’impliquer sans limites, presque en mettant leurs vies de côté pour la dédier à leur projet.

Il y a plusieurs façons de s’impliquer. Un peu à l’image du poulet qui prend un risque réduit, en donnant quelque chose qui ne lui appartient plus une fois sortie de son corp. Ou comme un porc, intelligent. Qui donne, oui, mais en prenant soins de ne pas mettre sa vie en danger.

Car on peut bien vouloir donner, s’impliquer dans un projet, si on est mort. Cela ne fera pas grande différence. Donc, l’implication doit se faire aussi selon nos capacités et nos limites. Tous ne peuvent pas donner tout. Le poulet voudrait peut-être, lui aussi donner du bacon ou du Jambon. Mais, il en est incapable.

Dans un projet informatique, car, c’est bien ce qu’on parle ici, il ne faut pas rester juste observateur.. Pas juste en donnant des oeufs et puis sans aller. Il faut s’impliquer à mener à bien le projet pour laquelle on s’est engagé. Si on donne des oeufs, pourquoi préparer les recettes qui vont avec.

C’est notre premier devoir, pour ne pas dire le seul, de tout mettre en oeuvre pour que notre travail soit fait dans l’excellence de nos capacités. Trop souvent, l’échec ou le succès d’un projet, qu’il soit tout petit jusqu’au plus grand, passe par l’implication que les gens y mettrons. C’est souvent pourquoi on utilise toujours cette expression ou comparaison du Pigs’ et du Chiken pour expliquer l’implication qu’on doit tous avoir dans nos activités.

Moi, j’ai choisi depuis longtemps, pour ne pas dire depuis toujours, d’être “PIG” sans pour autant y laisser ma vie ! Ce ne fût pas toujours un succès. Mais, à chaque fois que je regarde derrière mon épaule ! Je suis fier de ce que j’ai fait !

Donc, êtes-vous un Pig ou Chicken (un cochon ou poulet) dans votre projet, ou peut-être dans le prochain, le serez-vous autres choses. C’est à vous de décider .. Mais, si vous croyez au succès de votre projet .. il faut ou faudra peut-être devenir un plus Pig’s que Chiken.. Si vous ne l’êtes pas déjà.

Bon succès à vos projets.. !

Un logiciel c’est comme un cube Rubik

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Un logiciel c’est comme un gros cube Rubik. Drôle comme image, vous me direz. Pourtant quand les personnes impliquées dans un processus de développement logiciels voient le logiciel  comme si il y  avait une seule des faces de notre cube.

Souvent le client va regarder, son besoin en fonction de ses connaissances et de ses capacités. C’est donc dire qu’il regarde le cube en ne voyant qu’une seule face (ex. le bleu. Deux faces (bleu et la jaune) s’il possède aussi une compétence plus technique.

Le programmeur qui regarde le même logiciel, même si peut-être, il regarde lui aussi le même cube Rubik, lui, il voit peut-être une autre face, la verte. Il voit peu peut-être tout le code qu’il devra écrire pour mettre en œuvre ce logiciel. Si on est chanceux, il sera capable de voir lui aussi, un peu de la face jaune. Afin qu’il est un certain langage comment avec le client.

L’analyse a sa vision qui se limitera peut-être  à la face blanche. C’est-à-dire la vision fonctionnelle de l’application avec  un peu de bleu pour bien comprendre le besoin du client.  Si par chance, notre analyse possède un background de programmeur, il pourra aussi voir une partie de la face verte.

L’administrateur de réseaux ou l’administrateur de bases de données, lui verra peut-être la face Rouge pour l’ensemble des problèmes techniques, de sécurités ou de ploiement qu’il pourra avoir à adresser avec l’arrivée de cette nouvelle application.

Le dernier et non le moindre,  le chargé de projet quant à lui va voir parfois orange pour tous les problèmes de planifications, gestions de ressources ou autres problèmes administratifs.

Comme vous voyez, chacun à sa vision du même cube Rubik et en plus, comme c’est un cube Rubik, imaginé toutes les combinaisons de couleurs qu’on peut faire en mélangeant les couleurs par des mouvements de gauche ou de droit, de haut et de bas.

Donc, construire un logiciel avec les visions de chacun. Ce n’est pas une « job » facile. D’autant, si personne ne prennent conscience qu’il y a plusieurs faces à notre cube et que tous gardent leurs visions. Nous avons un problème.

Il faut prendre en main, prendre le temps de le tourner pour voir les autres faces. Prendre le temps de regarder les autres faces s‘est important. C’est important de faire cette prise de conscience. Malgré que nous pouvons avoir une vision exacte notre face, qu’il en existe d’autres.

C’est souvent une source de problèmes. Voir les vues différentes, mais surtout les comprendre. C’est un défi important. Donc, construire un logiciel. C’est un bien comme un cube Rubik, il faut manipuler longtemps  tant le cube que chacune des faces pour bien comprendre tout ce que nous devrons mettre en œuvre. Et parfois, regarder les autres faces, car nous pourrions découvrir d’autres couleurs.

Le cube Rubik, c’est l’ensemble de ses faces, avec l’ensemble de ses possibilités. J’espère que la prochaine fois que vous entreprendrez un projet informatique, vous prendrez 2 minutes pour faire tourner votre cube, juste au cas que nous n’aurez pas la même vision de celui-ci des autres participants du projet.