Avant les années 2000, le développement de logiciels se faisait principalement selon une approche Waterfall. Cela signifiait qu'un projet logiciel serait expédié après avoir traversé quelques longues étapes telles que l'analyse, le développement et l'assurance qualité, pour n'en nommer que quelques-unes. Cela a ralenti les cycles de développement des logiciels et, par conséquent, des décisions inappropriées ont été prises au début du cycle de vie, ce qui a conduit à des logiciels de mauvaise qualité ou inadaptés.
De nos jours, la plupart des grands projets sont développés de manière agile, en utilisant des philosophies telles que SCRUM ou Extreme Programming. Ces méthodologies favorisent le développement rapide de logiciels, généralement en raccourcissant les cycles et en les expédiant fréquemment.
Néanmoins, certaines industries comptent toujours sur Waterfall pour fournir des logiciels, car c'est toujours la meilleure approche pour atteindre leur objectif. Prenons l'exemple de l'aérospatiale. Si vous comptez lancer un satellite avec un code intégré, vous ne pourrez pas y déployer de mise à jour si le logiciel de mise à jour intégré est défectueux.
C'était aussi l'une des raisons pour lesquelles Waterfall était si populaire. L'expédition de logiciels coûtait plus cher qu'aujourd'hui, car il fallait généralement magnétiser une cassette, une disquette ou graver un CD avant de les expédier dans le monde entier pour les installer sur des ordinateurs qui n'auraient jamais accès à une connexion pendant leur durée de vie.
J'ai participé à de nombreux projets et aidé plus d'équipes à expédier des logiciels que je ne voudrais m'en souvenir. J'ai eu la chance de travailler avec des entreprises qui proposent des logiciels de qualité et d'autres qui ont du mal à maintenir le rythme en termes de qualité, de calendrier et de budget. J'ai remarqué que la clé pour proposer des logiciels de qualité et prévisibles ne réside pas dans la méthodologie que vous utilisez, car certains l'ont bien fait en Agile tandis que d'autres l'ont maîtrisé dans Waterfall. La clé du succès résidait dans leurs processus de développement, et certains n'en disposaient pas d'un écrit. Leur équipe produit se contentait de suivre un ensemble de tâches pour proposer de nouvelles choses de manière répétitive, ce qui leur permettait de contrôler où les choses fonctionnaient et d'améliorer celles qui ne fonctionnaient pas.
Ces processus étaient différents d'une équipe à l'autre, et le nombre d'étapes nécessaires à la réalisation d'une fonctionnalité n'était généralement pas le même. Mais tous ces processus avaient des caractéristiques communes quant à la façon dont leurs équipes abordaient le cycle de développement. C'est ce qu'ils n'ont pas fait.
Il est facile de se laisser emporter par une nouvelle idée et tout le monde veut passer à l'action immédiatement. Résister à cette tentation est difficile et souvent essentiel pour faire avancer les choses plus rapidement. C'est parfois difficile à comprendre, surtout si vous n'en êtes qu'aux premières années de votre carrière de développeur de logiciels.
Si vous y réfléchissez bien, la mise en œuvre d'une fonctionnalité dont la définition a nécessité une demi-journée et quelques jours de conception peut facilement prendre une semaine. Cela suit l'ordre naturel dans lequel les choses sont plus faciles à dire qu'à faire.
Les meilleures équipes passent du temps à analyser un problème et à définir une approche pour trouver une solution. Il existe un équilibre entre le montant que vous devriez dépenser pendant la phase de réflexion, et cela peut dépendre de la criticité du produit et du coût d'expédition d'une nouvelle version. Mais les bonnes équipes passent toujours du temps à concevoir une solution avant de commencer à implémenter une nouvelle fonctionnalité ou à corriger un bogue.
Nous sommes tous passés par là. Le propriétaire du produit dit qu'une fonctionnalité n'est plus pertinente, vous devez parcourir le code pour la supprimer, et quelques semaines plus tard, quelqu'un demande à ajouter à nouveau la fonctionnalité. Nous ne savons jamais quand le code qui est inutile aujourd'hui sera à nouveau nécessaire, et le commenter ou le laisser là semble être une bonne idée. Un code mort ou commenté ne peut pas faire de mal, non ? De plus, si nous laissons le code là, nous gagnons du temps en évitant de comprendre s'il existe d'autres dépendances.
Malheureusement, le code ancien ou commenté crée ce que l'on appelle souvent dette technique. À l'avenir, d'autres développeurs tomberont sur le code mort et cela les ralentira. Les fichiers s'agrandissent, le code sera plus difficile à lire et le chaos s'installe.
Il existe une meilleure alternative pour éviter d'éliminer une fonctionnalité fonctionnelle sans stocker le code quelque part. Avec un logiciel de contrôle de version moderne (par ex. cadeau), il est très facile d'identifier quand et quelles modifications ont été apportées, et de récupérer l'ancien code si nécessaire. Il y a une bonne raison pour laquelle des outils comme git mettent en évidence le nombre de lignes de code supprimées lors de chaque commit. Supprimer du code est aussi important que d'en ajouter un nouveau.
Personne n'en parle au collège ou à l'université, et personne n'en parle dans les nombreux cours de développement de logiciels qui existent. Mais les personnes qui se déploient en production l'apprennent régulièrement dès qu'elles commencent à travailler sur leur premier projet, et elles l'entendent souvent à leurs dépens...
Quand les choses tournent mal en production, le téléphone de quelqu'un sonne. Et je parie qu'il est plus difficile pour cette personne de réunir l'équipe du projet et de tout régler pendant le week-end qu'en semaine. Certaines personnes aiment même sortir du réseau le week-end, et bonne chance pour les rejoindre.
Il est plus facile d'expliquer à un responsable de produit pourquoi il n'y a pas de déploiement le vendredi ou avant les vacances que de résoudre un problème sans une équipe de développement fonctionnelle lorsqu'il se produit. Et croyez-moi, peu importe le nombre de tests que vous effectuez avant d'envoyer le code. Si vous déployez souvent, des problèmes se produiront une fois le code en ligne.
Je constate que de nombreuses équipes négligent l'automatisation des tests. Parfois parce qu'il y a un contrôle qualité manuel, d'autres parce qu'il n'y a tout simplement pas de calendrier pour développer les tests.
Les tests automatisés garantissent que les éléments fonctionnent correctement lorsqu'ils sont déployés et garantissent également que les nouvelles fonctionnalités n'endommageront pas l'ancien code. Vous pouvez sembler vous en tirer sans tests automatisés lorsque la base de code est petite. Cependant, le code ne vieillit pas bien, et Oncle Bob a écrit un réserver pour renforcer cette phrase.
Si vous ne développez pas de tests automatisés au fur et à mesure, les modifications seront plus difficiles à apporter, les utilisateurs auront du mal à rejoindre votre projet au fur et à mesure de son développement, les nouvelles fonctionnalités seront de plus en plus difficiles à déployer et, au final, il y aura tellement de bogues en production que votre rapport de bogue augmentera plus vite que vous ne pouvez déployer des correctifs.
Assurez-vous toujours que des tests automatisés sont effectués dès les premiers stades de l'effort de développement. Et si vous demandez « quelle quantité est suffisante », n'hésitez pas à vérifier mon article sur le sujet.
Beaucoup de choses se sont passées depuis les premières approches de l'intégration continue à la fin des années 90 (voir le célèbre ouvrage de Kent Beck Livre sur la programmation extrême, parmi d'autres publications de l'époque). Mais de nombreuses équipes n'adoptent toujours pas cette approche dès le premier jour et finissent par avoir des processus de déploiement manuels.
Le passage d'une fonctionnalité ou d'un correctif d'un dépôt de code à la production doit être un processus bien défini et automatisé. En plus, évidemment, d'éviter les erreurs humaines, cela donne confiance à l'équipe pour déployer souvent, ce qui permet aux propriétaires de produits d'avoir des commentaires réguliers sur la direction dans laquelle le produit va évoluer, améliorant ainsi ses chances de succès.
Une partie de cette question avait déjà été abordée lorsque nous avons expliqué pourquoi les tests automatisés sont importants, mais il ne s'agissait que d'une partie mineure du processus d'assurance qualité. Tests automatisés pour si assurez-vous simplement que le code est testé jusqu'à une certaine couverture et rien de plus.
Un bon processus d'assurance qualité garantit que le code a été vérifié et qu'il est valide. Ces étapes sont souvent appelées les étapes de vérification et de validation de la procédure d'assurance qualité.
Pour que cela soit mis en œuvre correctement, nous devons nous assurer que ce n'est pas la personne qui écrit le code qui le vérifie ou le valide. Le faire de cette façon permet d'éviter l'effet de vision en tunnel, qui empêche les gens de repérer leurs propres erreurs. Idéalement, la vérification (par exemple, la révision du code) devrait être effectuée par un autre développeur et la validation (par exemple, la démonstration des fonctionnalités) par le propriétaire du produit.
L'une des grandes avancées du Manifeste Agile était de placer « les personnes au-dessus des processus ». C'est en fait essentiel pour s'assurer que nous exploitons le plein potentiel de chaque membre de l'équipe de développement. Mais placer les personnes au-dessus des processus ne signifie pas qu'il ne devrait pas y avoir de processus du tout. Certaines personnes disent qu'elles n'ont pas de processus, mais après avoir passé un certain temps à travailler ensemble, elles ont certainement une façon de faire les choses. Ceci est défini en combinant des expériences personnelles et évolue à chaque itération jusqu'à ce qu'il se stabilise. C'est le processus naturel d'un groupe de compiler de nombreuses connaissances sur ce qui fonctionne et ce qui ne fonctionne pas pour lui.
Lorsque vous reprenez un processus auprès d'une autre équipe, vous saisissez en fait ce qu'elle a appris. Les processus existent parce que les personnes identifient les étapes ou les tâches les plus efficaces et dans quel ordre. C'est pourquoi les processus sont des connaissances. De plus, tous les bons processus évoluent et évoluent au fur et à mesure que les besoins évoluent. Mais si vous voulez concevoir le processus de développement de votre équipe ou de votre projet, le mieux est de commencer par définir ce que vous faites déjà, puis de vérifier avec cette liste si tous les points sont couverts.
Ici, à Imaginary Cloud, nous avons toujours cela à l'esprit lorsque nous créons une application Web ou mobile pour nos clients. Si vous développez l'un de ces produits numériques, nous serons ravis de vous aider ! Envoyez-nous un message ici!
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
