Mis à jours 20 mars 2022 Vous devez maîtriser le processus agile avec un ensemble de disciplines et de technologies pour obtenir toute la valeur de la méthodologie agile.
Si vous allez diriger ou participer à un processus de développement agile et que vous avez sélectionné un modèle agile tel que la méthodologie scrum, vous disposez d’un processus fondamental pour vous aider à aligner les propriétaires de produits sur les besoins des clients et les équipes à fournir des résultats. Vous avez défini les responsabilités de l’équipe, défini et planifié une structure de réunion et un outil de collaboration agile pour gérer les arriérés.
Toute cette structure, ce processus et cette collaboration aident les équipes de toutes sortes à s’exécuter. En fait, les pratiques agiles sont appliquées à de nombreuses autres disciplines non techniques telles que le marketing agile.
Alors, le processus agile lui-même est-il suffisant pour fournir un bon logiciel fonctionnel ?
La réponse est non. Le processus agile doit être complété par un ensemble de disciplines, souvent assistées par la technologie, pour obtenir toute la valeur de la méthodologie agile. Autrement dit, il faut exceller avec la méthodologie agile de votre entreprise.
Parmi les problèmes à résoudre, il y a :
- Quelles considérations techniques faut-il prendre en compte pour s’assurer que les outils de collaboration agiles peuvent prendre en charge les pratiques de cycle de développement de logiciel clé (SDLC) ?
- Comment une équipe qui développe des logiciels s’assure-t-elle que les applications sont prêtes pour la production et disposent d’un processus simplifié pour intégrer les modifications dans la production et d’autres environnements informatiques ?
Définir et traiter la dette technique dans le développement agile
Le développement agile nécessite souvent de nombreux compromis pour tenter de créer une histoire d’utilisateur. Les compromis de fonctionnalité sont souvent débattus dès le départ lors de la rédaction de l’histoire de l’utilisateur ou user story, en particulier lorsque les équipes utilisent des pratiques d’estimation agile pour estimer les points de l’histoire ou d’autres mesures.
Une fois l’histoire d’utilisateur engagée, l’équipe de développement doit prendre des décisions techniques éclairées concernant sa mise en œuvre. Ces décisions nécessitent des compromis de mise en œuvre même lorsque des normes technologiques strictes sont en place. Ces compromis créent une dette technique qui doit être corrigée ou améliorée ultérieurement.
La dette technique peut ne pas être visible pendant le processus de développement. Elle peut être causée par l’utilisation lorsque le comportement de l’utilisateur entraine une limitation technique à la mise en œuvre. Elle peut être causée par les performances ou l’évolutivité. Il peut également être causé par le cycle de vie de tout composant logiciel sous-jacent nécessitant une mise à niveau.
Il est essentiel pour les développeurs d’une équipe agile d’enregistrer la dette technique. Pour les petits problèmes, cela peut être résolu dans le code en ajoutant des commentaires qui peuvent être utiles lorsque le prochain développeur utilise ce code. Les problèmes de code plus importants nécessitant une refactorisation doivent être détaillés dans l’arriéré. Les besoins du cycle de vie des applications, tels que la mise à niveau de l’architecture logicielle sous-jacente et des composants pouvant nécessiter plusieurs modifications de code et des tests supplémentaires, pourraient être capturés sous forme d’épopées.
Les équipes agiles disciplinées trouveront des moyens de hiérarchiser la dette technique. Lorsque je dirige des programmes agiles, je demande aux propriétaires de produits de consacrer au moins 30% de leur arriéré à la réduction de leur dette technique. Cet objectif est basé sur une moyenne de 20 à 30% que les éditeurs de logiciels facturent pour les contrats de support, mais cet objectif peut être inférieur pour les nouvelles applications et beaucoup plus élevé pour les anciennes.
Comment traiter la dette technique ?
Il est possible de traiter la dette technique à plusieurs niveaux :
- Pour les problèmes de cycle de vie des applications plus volumineuses, il est souvent préférable de planifier une ou plusieurs versions pour effectuer ces mises à niveau. De plus, je vous conseille d’exécuter ces mises à niveau dans un cycle de publication ne présentant aucune fonctionnalité nouvelle ou modifiée. Cela permet aux équipes de test d’identifier plus facilement les problèmes liés à la mise à niveau et d’éviter les complications lorsque la recherche des causes fondamentales peut être difficile.
- Dans une version, le propriétaire du produit collabore avec l’équipe pour identifier la dette technique qui affecte le plus les utilisateurs, celle qui a le plus d’impact sur la productivité des développeurs ou celle qui expose d’autres risques. Elles sont ensuite classées par ordre de priorité et doivent être répertoriées comme des user stories dans le carnet de commandes.
- Dans une expérience utilisateur unique, l’équipe peut recommander des critères d’acceptation afin de traiter la dette technique sous-jacente.
Les meilleures équipes agiles mesurent la dette technique et créent des indicateurs lorsque la dette dépasse les niveaux acceptés.
Activer l’assurance qualité dans le développement agile
L’une des questions les plus courantes que posent les responsables du développement agile est de savoir comment intégrer les pratiques d’assurance qualité (QA) au processus de développement agile, en particulier pour les équipes utilisant la méthodologie Scrum. A la fin du sprint, une implication dite « terminée » signifie que QA puisse exécuter de nouveaux tests fonctionnels et tests de régression au sein du sprint. Mais, ce n’est pas facile lorsque la durée du sprint est courte et que les développeurs souhaitent coder jusqu’au moment de la démonstration.
L’ajustement à l’assurance qualité n’est également pas facile lorsque la hiérarchie des responsabilités entre l’assurance qualité et le développement s’est estompée avec l’émergence des tests unitaires, de l’automatisation et des pratiques de développement pilotées par les tests. En outre, les tests ont de nombreuses pratiques, notamment les tests de API, des fonctionnalités, des données, des interfaces mobiles, de la sécurité des applications, des performances et de l’évolutivité. Tous ces tests peuvent être difficiles à réaliser ou même justifier lorsque l’on s’attend à ce qu’agile permette de commercialiser plus rapidement.
Il est donc important que les dirigeants agiles rappellent à tous que la méthodologie agile doit permettre d’apporter des capacités de qualité pour commercialiser en toute sécurité. Pour ce faire, le développement d’applications nécessite une pratique d’assurance qualité qui corresponde aux risques, définit les responsabilités entre les développeurs et le contrôle qualité, et exige que les tests soient programmés dans le processus de développement agile.
Le moment d’introduire les tests
Pour aligner les tests sur les pratiques de développement, déterminez à quel moment dans le processus de développement les tests peuvent être introduits. Par exemple, dans un processus Scrum :
- Les tests initiaux des user stories doivent commencer au fur et à mesure de leur développement. Mais, il est important que les développeurs essaient de compléter les articles à haut risque et ceux qui nécessitent plus de tests plus tôt dans le sprint.
- Des tests supplémentaires sont généralement effectués à la fin du sprint. En fonction du temps nécessaire pour effectuer des tests fonctionnels et de régression, les développeurs doivent planifier un gel du code plusieurs jours avant la fin du sprint pour tester et résoudre les problèmes signalés.
- Les tests de sécurité, l’analyse du code et les tests de performance peuvent être planifiés pour s’exécuter sur le code complété dans le sprint précédent. Une dernière série de tests doit être planifiée avant la publication du code.
Effectuer tout le contrôle qualité et les tests souhaités dans les délais prescrits pour la publication des sprints nécessite une bonne automatisation. Les scénarios de test développés pour les fonctionnalités développées dans ce sprint doivent être automatisés et ajoutés aux tests de régression. Un sous-ensemble de ces tests doit être réutilisé pour les tests de performance. Des équipes solides se mesurent sur la couverture de test et sur le pourcentage de cas de test automatisés.
Identifier une norme de branchement de code
Une pratique de développement agile de base est la capacité de version du code, le développement de branches en plusieurs pistes d’activité et le code de package à publier dans des environnements de test et de production distincts.
Les outils se sont considérablement améliorés au cours des dernières années et de nombreuses équipes ont appris à utiliser des outils tels que Git pour des applications considérées auparavant comme des pratiques avancées de gestion de code source. Les équipes agiles de hautes performances savent comment utiliser ces outils pour gagner en efficacité et permettre un processus de développement flexible pour différents types d’activités de développement.
Cette flexibilité permet notamment de créer des branches et de fusionner du code. Une branche fournit plusieurs pistes de développement pour différents besoins de l’entreprise, où les développeurs peuvent travailler sur des copies indépendantes du code. Les équipes de développement peuvent utiliser un mélange de branches permanentes et épisodiques, et fusionner des branches quand c’est nécessaire. Les équipes de développement disposent souvent de branches standard pour prendre en charge le développement, les tests et la production. Mais, ils peuvent aussi créer des branches épisodiques pour :
- Le développement de fonctionnalités, où une fonctionnalité est développée dans sa propre branche, puis fusionnée une fois terminée.
- Les correctifs, lorsqu’un problème de production doit être corrigé et déployé sans incorporer de code en cours de développement.
- Les mises à niveau de composants ou d’architecture nécessitant une quantité importante de modifications de code et pouvant être testées dans des branches distinctes jusqu’à ce qu’elles soient prêtes pour une version de production.
Mettre en place des révisions de code pour améliorer la qualité et la collaboration des développeurs
Un autre aspect de l’utilisation d’outils de gestion de code source tels que Git consiste à formaliser les révisions de code. Dans Git, les développeurs travaillent généralement dans une branche de développement ou de fonctionnalités et développent le code selon les besoins ou en fonction de stratégies. Une fois l’opération terminée, le développeur génère une demande d’extraction pour déplacer ces modifications hors d’une branche de développement ou d’une branche de fonctionnalité vers la branche de test. Un autre développeur peut alors fusionner la demande d’extraction dans les tests.
Ce processus de collaboration permet aux développeurs d’examiner le code avant de fusionner des branches. Bien que les révisions de code puissent aider à identifier le code défectueux ou le code qui n’est pas conforme aux normes, c’est aussi un moyen d’effectuer un transfert de connaissances pour s’assurer que le code est lisible et compréhensible par un collègue. Ceci est particulièrement important dans le développement agile où les membres de l’équipe doivent partager les responsabilités et où les développeurs plus expérimentés doivent conseiller les développeurs débutants pour devenir des collaborateurs plus productifs.
Mettre en œuvre l’intégration continue et la distribution continue
La prochaine étape des équipes de développement agiles pour améliorer la qualité et l’efficacité de leurs processus consiste à automatiser la manière dont le code est empaqueté et livré aux environnements d’exécution.
Historiquement, de nombreuses applications étaient créées et fournies avec des étapes manuelles : les développeurs exécutent une étape dans un environnement de développement intégré (IDE), puis conditionnent la sortie à l’aide de scripts. Ils transfèrent le fichier par FTP vers un référentiel où un membre de l’équipe des opérations, après avoir reçu une demande de modification approuvée, effectue plusieurs étapes pour transmettre le code à l’environnement d’exécution cible. Ce processus manuel est à la fois source d’erreurs et inefficace pour les équipes commerciales et technologiques qui souhaitent apporter fréquemment des modifications dans les environnements de production.
Alors, la solution consiste à automatiser ces étapes. Lorsque l’équipe de développement et des opérations collabore pour améliorer l’agilité et la stabilité opérationnelle, une pratique de devops entre en jeu. Les principales pratiques de devops constituent :
- Intégration continue (CI), où les branches sont fusionnées fréquemment et le processus de construction de l’application est automatisé.
- Distribution continue (CD), où le logiciel est envoyé dans un environnement d’exécution sélectionné en appuyant sur un bouton.
L’intégration et la distribution continues (CI/CD) nécessitent des tests automatisés. CI/CD fait partie d’une stratégie de gestion des versions que chaque organisation devrait mettre en place dans le cadre de son processus de développement agile. Les organisations de développement les plus avancées qui souhaitent déployer le code très fréquemment (quotidiennement ou même plus fréquemment) passent à l’étape finale du déploiement continu.
Utiliser agile pour automatiser et améliorer les processus
Mettre en place cette pratique d’automatisation et de collaboration peut paraître une meilleure solution, mais je peux vous assurer que les organisations de développement ne parviennent pas à ces résultats du jour au lendemain. Ils sont développés au fil du temps et généralement en réponse à des problèmes d’entreprise.
La meilleure façon de commencer est de réfléchir à l’impact de la mise en place de ces solutions sur les clients. Articulez les besoins en automatisation et en collaboration en tant que user story et hiérarchisez son déploiement sur le backlog comme s’il s’agissait d’un projet de développement logiciel. Ensuite, vous pouvez commencer à mettre en œuvre ces solutions et à élaborer une feuille de route pour les prochaines améliorations.
