Certes les méthodes agiles imposent de pouvoir livrer de manière itérative, dans des délais constants (parfois très courts, ex. : sprint de 2 semaines) et avec un niveau de qualité élevé. On remarquera donc que diminuer ce « time-to-market » est intimement lié à la qualité et l’automatisation de livraison. Dans ce principe d’excellence technologique, lorsque l’on parle de qualité logicielle, cela commence par la qualité du code : écrivez du code « clean[1] » ! Nommez les variables, les méthodes, les classes, de manière parlantes. Ces noms doivent être signifiants par rapport à l’analyse métier qu’ils supportent. Evitez les commentaires inutiles. Un bon commentaire est un commentaire que l’on ne doit pas écrire car le code est suffisamment explicite sur ce qu’il fait. Définissez et alignez un formatage du code entre les développeurs. Utilisez des outils de contrôles et de formatages automatiques (ex. : Resharper, tslint, etc.) pour garantir et automatiser le code « clean ». Ensuite adoptez un design de qualité, un design « SOLID[2] ». Lorsque vous écrivez une classe, celle-ci ne doit avoir qu’une seule responsabilité. Une classe « couteau suisse » sera difficile à comprendre et à maintenir. Etendre une classe plutôt que modifier l’interface de celle-ci permettra de réduire les risques de régression sur le code initial. Ecrire des classes découplées les unes des autres grâce à l’inversion et l’injection des dépendances, favorisera une meilleure structuration du code. Ecrire des tests unitaires est un impératif pour garantir la qualité logicielle. Ces tests seront exécutés aussi souvent que possible, à la demande, à l’intégration et dans le meilleur des cas à chaque fois que le code change. Le code des tests unitaires est également utile à la compréhension du code testé. C’est pourquoi, l’écriture de tests unitaires doit également souscrire aux principes de qualité de code et de design cités précédemment. Différent patterns et librairies existent afin d’écrire et maintenir le code de tests unitaire ex. : AAA (Arrange-Act-Assert), xUnit, Jamine, Moq, TypeMoq, Autofixture, etc. Il est important de garder à l’esprit que le code que vous écrivez, n’est pas destiné à la machine, mais à vous et aux autres développeurs qui maintiendrons et ferons évoluer ce code. Et dans une approche agile, l’évolution du code est continue. L’automatisation de livraison, est l’art d’automatiser les étapes : d’intégration du code, de compilation, de testing, de déploiement et autres étapes de contrôle qualité, pour arriver à la livraison de la solution en 1 click. Plus les architectures se complexifie (ex : infra. Distribuée, cloud, micro-service), plus la valeur ajoutée de cette automatisation sera grande. Aujourd’hui plusieurs suites d’outils ALM[3] existent pour soutenir cette automatisation de livraison : Visual Studio Team Service, Jira, TeamForge, etc. L’agilité n’est pas qu’une question de processus et/ou de rigueur d’analyse, c’est aussi et surtout une question d’excellence technologique au travers des aspects évoqué précédemment. Il n’y a pas de SCRUM, XP, KANBAN ou autre processus agile, sans la maitrise de ces pratiques d’ingénierie logicielle. Et plus que tout, ces maitrises sont l’histoire de techniciens, de programmeurs, de personnes. [1] “Clean Code: A Handbook of Agile Software Craftsmanship” – Robert C. Martin [2] “Agile Principles, Patterns, and Practices in C#” – Robert C. Martin [3] Application lifecycle management