Mis à jours 20 mars 2022 Vous devez augmenter le processus agile avec un ensemble de disciplines et de technologies pour obtenir la pleine valeur de la méthodologie agile.
Si vous dirigez ou participez à un processus de développement agile et que vous avez choisi un modèle agile comme la méthode Scrum, vous disposez d’un processus fondamental pour aider les propriétaires de produits à répondre aux besoins des clients, et les équipes sur l’obtention de résultats. Vous avez défini les responsabilités de l’équipe, défini et planifié une structure de réunion, et disposez d’un outil de collaboration agile pour gérer l’arriéré.
Tous ces structure, processus et 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 est-il suffisant pour fournir un bon logiciel de travail ?
La réponse est non. Vous devez augmenter le processus agile avec un ensemble de disciplines, souvent soutenues par la technologie, pour obtenir la pleine valeur de la méthodologie agile. Autrement dit, pour exceller avec la méthodologie agile dans votre entreprise.
Parmi les questions à traiter sont :
- Quelles sont les considérations techniques à prendre en compte pour garantir que les outils de collaboration agile puissent prendre en charge les principales pratiques du cycle de vie du développement logiciel (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 rationalisé pour pousser les changements dans les environnements de production et autres environnements informatiques ?
Vidéo associée : Comment le développement agile fonctionne vraiment ?
Définir et gérer la dette technique dans le développement Agile
Le développement Agile nécessite souvent de nombreux compromis lorsque vous tentez d’obtenir une « histoire utilisateur » ou user story. Les compromis de fonctionnalité sont souvent débattus dès la rédaction de l’user story points ou d’autres mesures.
Une fois qu’une user story est validée, l’équipe de développement doit prendre des décisions techniques judicieuses concernant sa mise en œuvre. Ces décisions nécessitent des compromis de mise en œuvre même lorsque des normes technologiques strictes sont mises en place. Ces compromis créent une dette technique qui doit être réparée ou améliorée plus tard.
La dette technique peut ne pas être visible pendant le processus de développement. Elle peut être pilotée par l’usage lorsque le comportement de l’utilisateur expose une limitation technique dans la mise en œuvre. Elle peut être pilotée par les performances ou l’évolutivité. Elle peut également être influencée par le cycle de vie de tous les composants logiciels sous-jacents nécessitant des mises à niveau.
C’est une responsabilité critique pour les développeurs d’une équipe agile d’enregistrer leur dette technique. Pour les petits problèmes, cela peut se faire dans le code avec des commentaires « todo » qui peuvent être adressés au développeur suivant lorsqu’il travaille sur ce code. Les problèmes de code les plus importants qui nécessitent un refactoring doivent être détaillés dans le backlog. Les besoins en termes de 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, peuvent être mieux capturés en tant qu’épopées.
Les équipes agiles disciplinées trouveront des moyens de hiérarchiser la dette technique. Lorsqu’on dirige des programmes agiles, on demande aux propriétaires de produits de consacrer au moins 30% de leur arriéré à la dette technique. Cette cible est basée sur une moyenne de 20 à 30% que les fournisseurs de logiciels facturent sur les contrats de support, mais la cible peut être plus faible pour les nouvelles applications – et beaucoup plus élevée pour les anciennes.
Vous pouvez adresser la dette technique à plusieurs niveaux :
- Pour les plus grands problèmes de cycle de vie d’application, il est souvent préférable de programmer une ou plusieurs versions pour effectuer ces mises à niveau. En outre, il est conseillé d’exécuter ces mises à niveau dans un cycle de vie des versions qui n’introduit 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 lorsqu’il est difficile de trouver des causes profondes.
- Dans une version, le propriétaire du produit travaille avec l’équipe pour identifier la dette technique qui affecte le plus les utilisateurs, qui a le plus d’impact sur la productivité des développeurs ou qui expose d’autres risques. Ceux-ci sont ensuite classés par ordre de priorité et doivent être détaillés en tant qu’usagers dans l’arriéré.
- Dans une seule user story, l’équipe peut recommander des critères d’acceptation afin que la dette technique sous-jacente puisse être traitée.
Des équipes agiles hautement disciplinées 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 fréquemment posées par les responsables du développement Agile est de savoir comment intégrer les pratiques d’assurance qualité dans le processus de développement Agile, en particulier pour les équipes utilisant la méthodologie Scrum. L’implication d’être “fait” à la fin du sprint implique que l’assurance qualité peut exécuter de nouveaux tests fonctionnels et des tests de régression dans le sprint. Mais, ce n’est pas facile quand la durée du sprint est courte et que les développeurs veulent coder tout le temps jusqu’à la démo.
Il n’est pas facile de mettre en place un système d’Assurance Qualité lorsque la hiérarchie des responsabilités entre Assurance Qualités et développement a été brouillée par l’émergence de tests unitaires, d’automatisation et de pratiques de développement pilotées par les tests. En outre, les tests ont de nombreuses pratiques, notamment les API de test, les fonctionnalités, les données, les interfaces mobiles, la sécurité des applications, les performances et l’évolutivité. Tous ces tests peuvent être difficiles à réaliser ou même à justifier quand on s’attend à ce que l’agilité aidera à commercialiser de nouvelles capacités plus rapidement.
Il est donc important que les dirigeants agiles rappellent à tous que la méthodologie agile doit apporter des capacités de qualité sur le marché de manière plus sûre. Pour ce faire, le développement d’applications nécessite une pratique d’assurance qualité qui soit conforme au risque, définit les responsabilités entre les développeurs et l’assurance qualité, et exige que les tests soient planifiés dans le processus de développement agile.
Pour organiser les tests sur les pratiques de développement, tenez compte du moment où des tests peuvent être introduits dans le processus de développement. Par exemple, dans un processus de la méthode Scrum :
- Les tests initiaux des user stories devraient commencer au moment de leur développement. Mais, il est important que les développeurs essaient de compléter les histoires à haut risque et celles 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. Selon le temps nécessaire pour effectuer des tests fonctionnels et de régression, les développeurs doivent programmer un blocage de 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 de code et les tests de performance peuvent être programmés pour s’exécuter sur le code complété dans le sprint précédent. Un dernier groupement de tests devrait être planifié avant que le code soit publié en production.
Pour effectuer tous le contrôle qualité et les tests souhaités dans les contraintes de temps des versions de sprint, il faut une bonne quantité d’automatisation. Les cas de test développés pour les fonctionnalités développées durant 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 performances. Les vigoureuses équipes se mesurent à la couverture des tests et au pourcentage de cas de tests automatisés.
Identifier une norme de ramification de code
Une pratique de développement agile fondamentale est la capacité à coder la version, ramifier le développement en plusieurs pistes d’activité, et regrouper le code en vue de sa diffusion dans des environnements de test et de production séparés.
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 ce qui était considéré comme des pratiques avancées de gestion de code source. Les équipes agiles hautes performances savent comment utiliser ces outils pour améliorer l’efficacité et permettre un processus de développement flexible pour différents types d’activités de développement.
Le principe de cette flexibilité réside dans la possibilité de ramifier et de fusionner le code. Une branche fournit plusieurs pistes de développement pour différents besoins opérationnels 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 les branches quand cela a du sens. Les équipes de développement ont souvent des agences standard pour prendre en charge du développement, des tests et de la production. Mais, elles peuvent aussi créer des branches épisodiques pour prendre en charge de :
- développement de fonctionnalités, où une fonctionnalité est développée dans sa propre branche puis fusionnée lorsqu’elle est terminée.
- correctifs lorsqu’un problème de production doit être résolu et déployé sans incorporer n’importe quel code en cours de développement.
- mises à niveau de composants ou d’architectures qui nécessitent une quantité importante de modifications de code et où les tests peuvent être effectués dans des branches distinctes jusqu’à ce que la version de production soit prête.
Instituer des révisions de code pour améliorer la qualité et la collaboration des développeurs
Un autre aspect de l’utilisation des outils de gestion de code source comme Git est de formaliser les révisions de code. Dans Git, les développeurs travaillent généralement dans une branche ou une fonction de développement et enregistrent les modifications du code si nécessaire ou suivant des stratégies. Une fois terminé, le développeur génère une demande d’extraction pour déplacer ces modifications d’une branche de développement ou d’une branche d’entité vers la branche de test. Un deuxième développeur peut ensuite fusionner la requête de tirage dans le test.
Ce processus de collaboration permet aux développeurs d’effectuer des révisions de code avant de fusionner des branches. Bien que les révisions de code puissent aider à identifier les codes incorrects ou ceux qui ne répondent pas aux normes, elles permettent 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ù on veut que les membres de l’équipe partagent des responsabilités et où on veut que les développeurs seniors conseillent les juniors pour qu’ils deviennent des contributeurs plus productifs.
Implémenter l’intégration continue et la livraison continue
La prochaine étape à réaliser par les équipes de développement agile pour améliorer la qualité et l’efficacité de leur processus consiste à automatiser la façon dont le code est regroupé et livré aux environnements d’exécution.
Historiquement, de nombreuses applications ont été construites et livrées avec des étapes manuelles : les développeurs exécutent une étape dans un environnement de développement intégré (IDE), puis empaquettent l’élément de sortie (output) en utilisant des scripts. Ils transfèrent le fichier 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 fournir le code à l’environnement d’exécution cible. Ce processus manuel est à la fois sujet aux erreurs et inefficace pour les équipes opérationnelles et technologiques souhaitant déployer fréquemment des modifications dans les environnements de production.
La solution consiste à automatiser ces étapes. Lorsque l’équipe de développement et des opérations collaborent pour améliorer l’agilité et la stabilité opérationnelle, une pratique devops apparaît. Les principales pratiques de devops comprennent :
- L’intégration continue (IC), où les branches sont fusionnées fréquemment et le processus de création d’application est automatisé.
- La livraison continue (LC), où le logiciel est poussé vers un environnement d’exécution sélectionné en appuyant sur un bouton.
L’intégration et la livraison continues (IC/LC) nécessitent des tests automatisés. IC/LC font partie d’une stratégie de gestion des versions que chaque organisation devrait établir 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 (tous les jours ou même plus fréquemment) doivent franchir la dernière étape du déploiement continu.
Utiliser Agile pour piloter l’automatisation et l’amélioration des processus
Cela peut sembler magique d’avoir cette pratique d’automatisation et de collaboration en place, mais les sociétés de développement n’atteignent pas ces résultats du jour au lendemain. Elles sont développées au fil du temps et généralement en réponse à des problèmes commerciaux.
La meilleure façon de commencer est de réfléchir à l’impact sur la clientèle de la mise en place de ces solutions. Articuler les besoins d’automatisation et de collaboration en tant qu’un user story et hiérarchiser son déploiement sur le backlog comme s’il s’agissait d’un projet de développement de logiciel. Ensuite, vous pouvez commencer à mettre en œuvre ces solutions et développer une feuille de route pour les améliorations futures.
