Où en êtes-vous en matière d’Agilité? - Logient

Agilité + DevOps

De nombreuses organisations ont fait le saut d’un mode de gestion Waterfall vers une pratique Agile. Ces équipes se sont mises à livrer des minimal viable product (MVP), soit des fragments ou fonctionnalités d’un projet, livrés plus fréquemment, et générant une valeur en production plus rapide pour le client. Du coup, il est possible d’avoir de la rétroaction du client tout au long d’un projet, de s’aligner à ses attentes et aussi de s’ajuster en continu. Les clients n’ont pas toujours la compréhension finale de ce qu’ils veulent, et cette culture d’Agilité leur permet de se questionner sainement, parfois de changer d’orientation au niveau de la définition du produit, et même, de s’adapter au marché, qui évolue en même temps. Il faut savoir que l’Agilité n’est pas une méthodologie, c’est une culture avec différentes saveurs : Scrum, Kanban, Lean, SAFe, DAD, etc.

Les nouvelles pratiques en matière d’Agilité impliquent que les projets de développement soient gérés de façon Agile non seulement en ce qui concerne les activités de développement, mais aussi pour les activités d’opérations qui sont maintenant intégrées à même les équipes. On tente donc de donner une autonomie complète à ces équipes. On recherche un sain équilibre entre le désir d’accélérer la livraison de valeur pour l’organisation, et d’offrir une stabilité et une qualité dans les solutions proposées, ce qui freine généralement le rythme de livraison.
 

L’Agilité, est-ce vraiment pour vous?

Avant de vous lancer dans une pratique Agile DevOps, demandez-vous si vous êtes suffisamment structurés. Le DevOps à la base nécessite beaucoup d’automatisation, soit l’automatisation de la chaîne d’assemblage logicielle. Il faut donc avoir une gouvernance au niveau de la gestion de son code, des environnements de production ou de non-production, savoir comment faire le branching model avec son code pour savoir ce qui est déployé dans quel environnement et avec quelle version. Une fois que toutes ces pratiques sont établies, alors il est possible d‘entreprendre l’automatisation des pratiques Agile DevOps à même les équipes de développement.

 

Ajoutez le QA à votre Agilité

Lorsqu’on travaille en Agile, on travaille nécessairement avec une série d’itérations dans les équipes Scrum. Or, l’assurance qualité doit faire partie intégrante des sprints, et non d’un sprint hardening (sprint de QA) qui n’a lieu qu’à la fin du projet.

Pour ce faire, il est essentiel que la personne effectuant des tests QA soit complètement intégrée dans l’équipe de développement du projet, et que les tests effectués fassent partie du definition of done (DOD) pour la livraison des user story à la fin du sprint. Il s’agit donc d’intégrer les tests automatisés au processus d’intégration continue (CI ou Continuous Integration), pas uniquement au code de la solution. Outre la programmation des tests automatisés, il est nécessaire de les insérer dans le guide de programmation afin de savoir comment ils seront appelés et comment ils seront intégrés dans le TCM (Test Case Manager) de façon automatisée. Ajoutons à cela la sécurité et on parlera donc ici d’une itération complète d’Agilité.

L’automatisation des tests de QA fait également partie des meilleures pratiques, bien que pour chaque projet, une catégorisation des types de tests devra être effectuée. Il sera logique que les tests de régression soient ceux appelés à être automatisés au tout début. On augmente ainsi toute l’intelligence organisationnelle en bâtissant une librairie de tests centralisée pour tester le code des applications et pouvant être réutilisée sur d’autres projets.

Cette nouvelle tendance est communément appelée « la mentalité de shift left ». Au lieu de livrer du code à une équipe de QA à la fin du développement pour débuter les tests, on le fera en simultané aux activités de développement. On parle alors de l’intégration du rôle dans les itérations de développement. Donc, si quelque chose brise, on le répare immédiatement. Plus on approche de la production, plus le produit est stable.

 

Security as Code (SaC)

La cybersécurité constitue maintenant la priorité de plusieurs entreprises, non pas uniquement dans le milieu bancaire. Pour aller encore plus loin, lorsque l’on parle de DevSecOps, on intègre toute la stratégie de sécurité et les différents protocoles de conformité liés au projet. On intégrera alors des tests de pénétration pour protéger les données sensibles et se protéger des failles au niveau de l’application, du réseau, de l’infrastructure et ainsi minimiser les risques liés aux vols d’identité et d’information.

La majorité des entreprises ne sont pas encore arrivées à ce niveau d’Agilité intégré avec le DevOps et la sécurité. Nous sommes au début de cette nouvelle tendance et ces équipes sont malheureusement encore très isolées, avec des méthodes relativement traditionnelles, et ne sachant pas comment s’insérer dans les itérations de développement. Malheureusement, il est souvent très difficile d’aller très rapidement en production à la suite d’un sprint, car les activités de QA et de validation de sécurité représentent des goulots d’étranglement à la livraison rapide des projets.

 

Le DevSecOps et ses avantages

Si le DevSecOps vous convient, alors vous bénéficierez d’une multitude d’avantages :

· Une meilleure qualité de la solution livrée
· Des tests unitaires de meilleure qualité
· Une meilleure qualité d’intégration
· La capacité à découvrir plus tôt les problèmes qui surviennent lors d’un projet, et éviter les surprises de fin       de parcours
· Une sécurité quant à la date de livraison
· La suppression d’emplois traditionnellement plus « plates » pour les transformer en emplois plus créatifs
· L’augmentation de l’intelligence organisationnelle et la diminution des étapes manuelles


 
 

La transformation vers l’Agilité, c’est un défi humain!

Prenez le temps de savoir où vous vous situez en matière d’Agilité dans votre entreprise. Ce n’est pas un défi technologique, c’est un défi humain. On change littéralement les façons de travailler. Attendez-vous à ce que le changement soit long, pénible et périlleux. Assurez-vous de ne pas entreprendre cette transformation uniquement pour suivre la tendance et être au goût du jour. Faites-le pour les bonnes raisons : pour amener de la stabilité et de la sécurité en accélérant la livraison de valeur pour l’organisation et ainsi en faire bénéficier les clients. Le courage managérial est de mise. Le changement nécessitera la création de nouveaux rôles au sein de l’organisation, de la formation et des investissements monétaires, et entraînera une perte de vélocité temporaire. Comprenez l’ampleur de la chose avant de vous lancer et démystifiez le changement à l’interne. Mettez des indicateurs en place pour mesurer et suivre la progression. Il pourrait s’agir d‘indices de maturité tels que l’augmentation de la qualité, la diminution des incidents, l’amélioration des disponibilités des systèmes. C’est un moyen de défense contre ceux qui s’opposent au changement. En fait, il s’agit de légitimer en tout temps la poursuite de la transformation.

 

Par Van Kim Nguyen, Conseiller Senior DevSecOps