Archive
Mes quatre murs de mon bac à sable : Développement logiciel
- 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.
- 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.
- 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 ! 
- 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 !
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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 ?
- 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.
La PME et Agile, est-ce possible ?
Pour beaucoup de petites organisations en développement logicielles pensent que les méthodologies Agiles, ce n’est pas pour elles. Mais pourtant, beaucoup de ces petites organisations par leur manière de travailler sont très proches des la philosophie et des approches Agiles.
Car, pour être « Agile », ce n’est pas juste en implémentation une des nombreuses dérivations comme SCRUM ou Kanban. Mais c’est d’abord avoir une ouverture à la communication et la collaboration, ce qui est généralement par nature dans les petites organisations.
Car sans la communication et la collaboration, tant des membres d’une équipe de développement que la direction de l’entreprise sont les assises de la mise en place d’une ou plusieurs approches agiles dans une organisation.
Bien sûr, une petite organisation n’a pas toujours les moyens pour mettre en place les méthodologies Agiles dans son organisation. Il faut donc y aller progressivement. Il faut intervenir d’abord où il y a des problèmes. Là où ça fait mal comme on dit.
Par exemple, si vous avez un problème de qualité ou de solidité du code produit. Optez d’abord vers une approche qui vous permettra, comme Test Driven Developpement, d’adresser le problème.
Même chose pour la gestion du développement vous pourriez utilise une approche comme Scrum ou Kanban. Utilisez une approche chirurgicale au début pour corriger les problèmes petits à petits. Il n’est pas conseillé (je ne recommande pas) de faire de grand virage tout d’un coup. Vous n’oubliez pas, vous avez l’agilité d’une petite structure. Mais, une capacité moindre en cas de crash. La grosse structure bouge difficilement. Mais, elle a les budgets et les ressources pour se remettre sur pieds rapidement.
N’ayez pas peur de revenir en arrière pour mieux avancer. Les méthodologies Agiles, c’est bien ce n’est pas pour toutes les organisations. Même, les petites toutes comme les grandes sont incapable d’effectuer ce virage. Comme disait mon grand père, on est toujours plus intelligent après qu’avant. Il faut apprendre de ces erreurs et bien sûr, tenter de les corriger dans la nouvelle version.
Même si vous avez la capacité de faire les changements rapidement. Ne partez pas à la course les faire. Implémenter Agile, même dans une petite organisation. Il va avoir plusieurs impacts. Prenez le temps de les absorber.
¸Surtout, « être agile » ce n’est pas d’implémenter toutes les méthodes agiles. Mais, d’avoir des processus qui permettent de produire un logiciel efficacement, tant budgétairement et techniquement. Que toutes vos ressources sont utilisées à leurs pleines puissances.
Mais, surtout que les différents processus que vous implémentez au sens de votre organisation devront pour optimiser votre production des logiciels, mais aussi à chacun des membres de votre organisation
De cette manière, nous pourrons affirmer que les méthodologies Agiles, c’est aussi fait pour les PME tout comme pour les grandes. Ou encore, à la fin de cette réflexion, vous répondrez peut-être, que vous déjà Agile.
Vous avez peur de ne pas réussir, appelez-nous, on pourra vous accompagner pour effectuer cette continuité vers l’agilité.
Génération Agile
