Environnement de développement : Comment démarrer le projet parfait?

Par Christian Belisle

Un projet commence toujours avec l’identification d’un besoin, suivi d’une négociation. Trop souvent, on néglige que pour assurer le succès d’un projet, la collaboration entre équipe technique et client est cruciale. 

Tel que le mentionne le Manifeste Agile “la collaboration avec les clients plus que la négociation contractuelle”. Chez Done, on favorise l’écoute et l’ouverture d’esprit. On tente de bien saison les problématiques et besoins clients avant tout.  De là, on développe le projet parfait. 

Le projet est accepté, les exigences sont claires; mais par où commencer pour réaliser le développement?

Un réflexe naturel est de tout préparer d’avance pour qu’on puisse programmer sans rencontrer d’embûche relative aux environnements technologiques. C’est donc à ce moment que l’équipe fait une table ronde et prend des décisions selon ses connaissances et son niveau de confort avec les outils. Un choix est fait pour chacune des composantes de l’architecture (base de données, serveur, etc.) et il y a même un membre plus expérimenté que les autres qui propose des librairies qui permettront de développer plus rapidement. Pourquoi utiliser tel pour tel outil? Parce que nous en aurons peut-être besoin plus tard dans le projet…

Nous semblons avoir un coffre à outils complet qui nous permettra de faire face à toute éventualité! Mais est-ce qu’un garagiste aura besoin des mêmes outils qu’un menuisier? Poussons l’analogie en nous demandant : est-ce qu’un menuisier qui participe à la construction d’une maison aura besoin des mêmes outils que son collègue qui fabrique une table haut de gamme avec des motifs?

Malheureusement, dans le développement logiciel, ce n’est souvent qu’à un stade avancé du projet que l’équipe s’aperçoit que les outils ou librairies qui ont été choisis au départ peuvent couvrir beaucoup plus de fonctionnalités que nécessaire. Le prix à payer? Une lourdeur (et parfois même une lenteur) de l’application qui peut parfois demander un investissement de temps important afin de couper ce qui n’est pas nécessaire.

Un réflexe naturel est de tout préparer d’avance pour qu’on puisse programmer sans rencontrer d’embûche relative aux environnements technologiques. C’est donc à ce moment que l’équipe fait une table ronde et prend des décisions selon ses connaissances et son niveau de confort avec les outils. Un choix est fait pour chacune des composantes de l’architecture (base de données, serveur, etc.) et il y a même un membre plus expérimenté que les autres qui propose des librairies qui permettront de développer plus rapidement. Pourquoi utiliser tel pour tel outil? Parce que nous en aurons peut-être besoin plus tard dans le projet…

Nous semblons avoir un coffre à outils complet qui nous permettra de faire face à toute éventualité! Mais est-ce qu’un garagiste aura besoin des mêmes outils qu’un menuisier? Poussons l’analogie en nous demandant : est-ce qu’un menuisier qui participe à la construction d’une maison aura besoin des mêmes outils que son collègue qui fabrique une table haut de gamme avec des motifs?

Malheureusement, dans le développement logiciel, ce n’est souvent qu’à un stade avancé du projet que l’équipe s’aperçoit que les outils ou librairies qui ont été choisis au départ peuvent couvrir beaucoup plus de fonctionnalités que nécessaire. Le prix à payer? Une lourdeur (et parfois même une lenteur) de l’application qui peut parfois demander un investissement de temps important afin de couper ce qui n’est pas nécessaire.

apprendre de nos erreurs et donc, choisir les composantes de notre application

La quatrième valeur du Manifeste Agile nous rappelle que “l’adaptation au changement plus que le suivi d’un plan”. Donc, pour être « agile”, il ne faut pas être réticent aux changements, il faut constamment s’adapter.

La mentalité du choix en fonction du besoin est très répandue et promue lors de transitions Agiles. Nous attendons d’avoir besoin de sauvegarder nos données avant de faire le choix de la base de données, puisqu’il y aura peut-être un détail important à prendre en compte qui fera qu’on choisira une option plutôt qu’une autre.

Chez Done, la polyvalence est importante au sein de l’équipe. C’est pourquoi n’importe quelle tâche peut être réalisée par chacun des membres de l’équipe. Il est donc possible qu’un collègue moins expérimenté doive faire ce choix technologique. Nous comptons sur l’entraide et la collaboration des pairs, et nous tenons pour acquis qu’il demandera de l’aide si nécessaire. On s’assure que cette personne a pris le temps de lire la documentation, qu’elle se sent en confiance pour faire le travail toute seule, etc. Et le résultat? À la fin du sprint, la nouvelle technologie a été intégrée au code source de notre application d’une manière plaît normalement à tout le monde!

On garde en tête que les choix technologiques ne sont pas toujours visibles et évidents, ce qui fait qu’un mauvais choix peut passer inaperçu et entraîner des pratiques de développement particulières pour pouvoir réussir à écrire du code qui sera compatible. Lorsqu’on fait face à ce genre de problème, on tente d’y faire face rapidement, de minimiser les impacts et aussi, de faire en sorte que notre collègue en retire un apprentissage important. 

Encore une fois, la conséquence est un investissement de temps qui peut parfois rester incognito pendant longtemps. Il faudra qu’un développeur ait l’esprit assez critique pour remettre en question la décision initiale avant de s’apercevoir que des heures de travail ont été passées à essayer de contourner une problématique qui était simplement prise pour acquis. Plus le projet est avancé, plus cette quantité d’heures peut être importante. Qu’en pensera le propriétaire du produit (Product Owner) qui gère le budget?

Décider en équipe et optimiser notre environnement

Tel que mentionné dans le manifeste Agile, “les individus et leurs interactions plus que les processus et les outils”. Il faut donc savoir favoriser les interactions avec les membres de l’équipe plutôt qu’utiliser des outils lourds de prise de décisions. On doit utiliser le savoir de tous à profit.

Voici quelques trucs qui permettent de developper un environnement de travail optimal à la réalisation de projet :

  • Tirer profit des connaissances de toute l’équipe;
  • Éliminer les tâches manuelles et répétitives (autant que possible);
  • Prendre pour acquis que tous n’ont peut-être pas la même configuration;
  • Documenter le développement en pensant aux futurs développeurs ou à l’éventuelle mise en production de l’application.

Intéressons-nous à chacun de ces points un par un…

Tirer profit des connaissances de toute l’équipe

Si nous sommes responsables de choisir un outil ou une composante, il est primordial de mettre notre ego de côté et de discuter ouvertement de notre cheminement vers la décision finale. Inversement, le reste de l’équipe se doit de contester les choix faits pour s’assurer qu’un piège n’est pas en train de se dresser qui engloutira de précieuses heures de travail tout au long du projet. Il revient donc à tous de prendre la responsabilité de cette intégration, même si ce n’est pas tout le monde qui pourra y participer.

Ce point est particulièrement important pour ne pas tomber dans une dynamique de pointage de doigt qui peut diviser l’équipe et en faire sentir plusieurs incompétents. Nous travaillons tous ensemble pour nous entraider!

De plus, il est possible qu’un collègue ait des connaissances approfondies au sujet de la technologie sur laquelle notre choix s’est arrêté. Le partage d’information est alors une étape cruciale qui permettra d’avoir une montée en compétence globale pour que tout le monde sache non seulement dans quoi ils s’embarquent pour la durée du projet, mais aussi comment travailler de manière optimale avec cette nouvelle pièce du puzzle qu’est notre produit en développement.

Des trucs et astuces tirés d’expériences passées peuvent être échangés au cours des discussions, ce qui est beaucoup plus utile et rapide qu’une étude approfondie de la documentation. C’est en parlant ensemble qu’on pourra alors éviter des pièges et qui sait, peut-être même travailler en paire avec celui ou celle qui connaît déjà la technologie. Les avantages sont importants : un processus de développement optimal, un échange d’information et des éclaircissements sur les points moins clairs, sans oublier une meilleure qualité du produit final. C’est à prendre en compte si des personnes externes au projet contestent la pertinence d’avoir deux personnes travaillant sur la même tâche.

Pendant qu’un de nous deux travaille sur l’intégration, l’autre peut en profiter pour rédiger une page documentant quelques pistes qui permettront au reste de l’équipe de pouvoir savoir où commencer pour construire avec cette nouvelle technologie.

Éliminer les tâches manuelles et répétitives

En parlant de pièges, combien de fois un programmeur devra-t-il déployer une version de l’application sur l’environnement de test pour s’assurer que les bogues sont réglés? Une fois l’application stabilisée, le propriétaire de produit voudra sans doute la présenter aux parties prenantes du projet en faisant une démonstration. Il faudra alors déployer l’application dans un autre environnement. Oh! Un oubli de notre part et la configuration du mauvais environnement est utilisée. La démo ne fonctionne pas et cette heure prévue à l’agenda de gens possiblement surchargés vient d’être perdue, minant le moral du propriétaire de produit et du reste de l’équipe.

Pourtant, les déploiements sont faits fréquemment et le processus devrait être maîtrisé par tous! Ce n’est qu’un exemple de situation désastreuse qui peut arriver durant un projet de développement, mais qui aurait pu être évitée en s’occupant d’une tâche simple mais répétitive dès le début.

C’est pourquoi il ne faut pas prendre à la légère ces étapes manuelles qui peuvent nous sembler anodines, mais qui comportent leur lot de risques. Il vaut mieux investir un peu plus de temps au commencement pour mettre en place des processus automatisés. Bien sûr, ça implique un peu plus d’efforts initiaux vu l’ajout de tâches de développement à ce qui aurait pu être seulement de la configuration d’infrastructure. Les bénéfices directs sont facilement mesurables en constatant les heures sauvées en termes de tâches manuelles, mais la porte est également ouverte à d’autres avantages auxquels on ne pense pas toujours.

Par exemple, un script qui roulera toutes les nuits peut simplement appeler un des processus automatisés, ou une interface utilisateur peut être créée rapidement (à usage interne, donc ce n’est pas nécessaire de s’attarder sur la beauté) pour permettre à certaines personnes, qui ne sont pas impliquées dans le développement, de déployer le logiciel dans l’environnement qu’elles utilisent. Ce sont beaucoup de possibilités qui ne demandent pas beaucoup d’efforts de développement, mais qui peuvent sembler insurmontables si nous n’avons pas bâti itérativement nos petits outils internes.

Prendre pour acquis que tous n’ont peut-être pas la même configuration

Combien de fois les programmeurs entendront-ils la phrase suivante durant leur carrière?

« Oui mais ça ne fonctionne pas sur mon ordinateur, et seulement sur mon ordinateur… »

Chaque fois qu’une composante logicielle est intégrée au projet, cette réalité doit absolument faire partie des premières hypothèses. Si la décision d’utiliser un outil difficilement configurable est prise, il faut inévitablement s’attendre à faire face à un environnement de développement qui n’a pas la même configuration (ou version) que les autres. C’est alors qu’une investigation peut hypothéquer un développeur, peut-être même deux pendant plusieurs heures, voire plusieurs jours.

La meilleure approche pour éviter ce genre de problématique est de bien définir dès le départ les différents environnements qui devront être soutenus par le logiciel. Dans le cas d’une application Web, la suite de tests automatisés pourra alors être construite pour être exécutée dans plusieurs navigateurs. Non seulement les tests nous permettront d’éviter des problèmes de régression au fur et à mesure que les fonctionnalités s’ajoutent, mais l’équipe sera aussi sûre que des problèmes ne surgiront pas sur des navigateurs qui ne sont pas utilisés aussi fréquemment dans le processus de développement.

Dans le contexte des applications client-serveur, la portion serveur du logiciel ne doit pas être négligée. Comme l’application complète doit pouvoir être exécutée sur les postes des développeurs, les différences de configuration peuvent amener deux fois plus de problèmes. À moins de réinitialiser les ordinateurs des programmeurs à chaque nouveau projet, il suffit d’avoir développé quelques applications pour avoir des traces du passé qui reviennent nous hanter. Un outil que nous avons oublié de mettre à jour, ou une configuration spéciale qui nous était nécessaire il n’y a pas si longtemps, peut causer son lot de problèmes. Et la cause n’est pas toujours évidente à trouver…

L’arrivée de conteneurs et d’outils comme Docker peut nous aider grandement à éviter ce genre de situation. Au lieu d’avoir une image complète de l’ordinateur qui oblige le développeur à perdre ses personnalisations à chaque réinitialisation, il est maintenant possible de construire un fichier qui définit une image de conteneur à partir de plusieurs logiciels préconfigurés.

L’utilisation de ce fichier par le reste de l’équipe permet de garantir que tous utilisent le même environnement, sans interférer avec les personnalisations de chacun. Une fois le projet terminé, nous pouvons simplement l’effacer de notre ordinateur. Et si nous devions faire des modifications quelques mois plus tard? Il suffirait de rebâtir l’image à partir de ce fichier et nous retrouverions le même environnement que nous avions, sans installer et désinstaller nos outils de développement.

Il suffit d’investir un peu de temps pour l’apprendre, mais notre vie de développeur devient tellement plus simple!

Documenter pour le futur

La documentation est souvent la bête noire des tâches de l’équipe. En effet,  créer une documentation facile à utiliser n’est pas chose simple, et une documentation que personne ne consulte est inutile.

Le Manifeste Agile nous rappelle que “des logiciels opérationnels plus qu’une documentation exhaustive”. Ainsi, pour créer la documentation nécessaire, il faut, en premier lieu, construire un logiciel facile d’utilisation et de là, penser au futur, et avoir créer la documenter adéquate. 

Lorsqu’un nouveau membre se joindra à l’équipe, quelles sont les étapes (qui ne sont pas déjà automatisées) par lesquelles il devra passer pour être prêt à développer? Chacune de celles-ci devrait être documentée dans un endroit centralisé afin de ne pas avoir à assister son installation et rencontrer toujours les mêmes problèmes.

La même stratégie s’applique pour le moment où notre logiciel passera en production et sera accessible par tous ses utilisateurs. Si ce n’est pas nous, les programmeurs, qui participons à cette étape cruciale, il faut s’assurer que le responsable est suffisamment à l’aise avec les tâches à réaliser.

C’est en ayant documenté le développement ici et là, tout au long du projet, que nous pouvons éviter d’avoir à nous mettre dans la peau d’une personne externe pour écrire pendant de longues heures et courir la chance d’oublier des points importants. 

Chez Done, on tente non seulement de bonifier la documentation un peu à chaque sprint pour en faire une révision finale à la fin du projet, et on favorise souvent l’intervention d’un spécialiste UI/UX afin de réduire le besoin de documentation. Ça nous évite de se faire réveiller à trois heures du matin parce que l’administrateur système ne sait plus quoi faire dans son processus de déploiement…

La recette est simple…

Le secret pour un environnement de développement parfait? Il suffit de ne pas se compliquer la vie! N’hésitez pas à impliquer le reste de l’équipe dans sa mise en place et aussi à participer activement lorsque vos collègues ont la charge de s’en occuper. Dans tous les cas, vous pourrez en retirer un apprentissage important et vous assurer de préparer le terrain pour passer les prochaines semaines (ou les prochains mois) sans anicroche.

Pour ceux qui souhaitent avoir une vue plus imagée d’un démarrage de projet parfait, je vous invite à consulter le document infographique d’Éric De Carufel.

Besoin d’aide?

Pour toutes questions, n’hésitez pas à nous contacter. L’expertise de nos équipes multidisciplinaires, nous permet d’accompagner les entreprises qui souhaitent développer les compétences de leurs équipes de développement. Pour en savoir plus sur la formation et le coaching technique, cliquez ici.

Bon projet!

Autres articles qui pourraient vous intéresser

Custom Software Development | Done Technologies

Pourquoi ai-je envie de recommencer à programmer depuis que je suis Product Owner?

Imaginez que vous êtes le Product Owner d’une application de Sudoku : vous seriez probablement capable de décrire les règles du jeu à votre équipe de développement et de lui fournir comme condition de succès, une grille résolue à partir d’une grille de départ valide. Mais il serait plus difficile de spécifier une grille de départ...
Votre partenaire de solutions logiciels sur mesure | Done Technologies

Développement sur mesure, la promesse d’une idée qui marche…

Chercher une solution informatique à un problème simple ou complexe, ou encore chercher à obtenir plus de gains dans le cadre d’un processus d’affaires, c’est une quête normale pour toute entreprise, petite ou grande. La plupart des entreprises identifient plusieurs solutions potentielles mais celles-ci ne répondent pas nécessairement exactement à leur besoin, ou encore plusieurs...

La méthode du rubber duck debugging ou l’art de résoudre un problème quand on est programmeur

Lorsque vous écrivez du code pour un logiciel, s’il y a bien une chose dont un programmeur est certain, c’est qu’à un moment donné il se retrouvera bloqué. Ce genre de situation arrive tout le temps et n’importe quel programmeur pourra vous le confirmer. Peu importe votre expérience que vous soyez débutant ou vétéran, vous...