Le projet est accepté, les exigences sont claires; mais par où commencer pour réaliser notre 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.

Nous avons appris de nos erreurs, choisissons donc les composantes de notre application au besoin.

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

Comme la polyvalence est importante dans notre équipe, 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 nous tenons pour acquis qu’il demandera de l’aide si nécessaire. Mais cette personne a pris le temps de lire la documentation. Elle se sent en confiance pour faire le travail toute seule. 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 qui ne plaît pas à tout le monde!

Si nous nous en apercevons rapidement et que nous faisons face au problème dans un court délai, l’impact est minime et ce collègue pourra en retirer un apprentissage important. Mais les choix technologiques ne sont pas toujours aussi 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.

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écidons en équipe et optimisons notre environnement

Alors quelle est la recette pour un environnement de développement qui nous permettra de réaliser ce projet de façon optimale? Il faut :

  • 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. Il faut évidemment trouver un équilibre pour ne pas trop documenter, et pour ce faire, il faut penser au futur.

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. Préférez-vous bonifier la documentation un peu à chaque sprint pour en faire une révision finale à la fin du projet? Ou vous 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 produit par mon collègue Éric De Carufel:

Document infographique – Comment réussir le démarrage du projet parfait?

Bon projet!

 

Billet précédent

Pyxis reconnue par le Professional Training Network (PTN) de Scrum.org

Billet suivant

Être une fille dans un monde de développeurs

Christian Belisle

Dans le domaine du développement logiciel depuis 2000, Christian s’est toujours démarqué comme quelqu’un qui apprend rapidement et qui reste toujours à l’affût des nouveautés technologiques. Grâce à son expérience, il est en mesure de s’adapter facilement aux différents défis qui s’offrent à lui.

C’est en 2006 qu’il a eu la chance de suivre un cours de formation sur Scrum avec Pyxis Technologies et ce fut le début d’une longue relation avec l’Agilité. Depuis ce temps, il porte une attention constante à la recherche de méthodes de travail optimales, qu’elles soient de nature technologique ou organisationnelle. Lorsque les bases du projet sont établies, il sait s’investir corps et âme dans la livraison de produits exceptionnels.

Ayant joint l’équipe Pyxis en 2016, Christian souhaite de tout son cœur pouvoir améliorer le monde, une itération à la fois.

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *