Qu’est-ce que le développement Agile ?

Le développement Agile est un terme qui est utilisé pour décrire le développement logiciel itératif. Le développement logiciel itératif raccourcit le cycle de vie DevOps en terminant le travail par petits incréments, généralement appelés sprints. Les sprints durent généralement une à quatre semaines. Le développement Agile est souvent contrasté avec le développement traditionnel ou en cascade, qui planifie des projets plus importants en amont et les réalise conformément au plan.

La livraison de code de qualité de production à chaque sprint nécessite que l’équipe de développement Agile prenne en compte un rythme accéléré. L’ensemble du codage, des tests et de la vérification de la qualité doivent être effectués à chaque sprint. À moins qu’une équipe ne soit correctement configurée, les résultats peuvent ne pas être à la hauteur des attentes. Bien que ces déceptions offrent de grandes opportunités d’apprentissage, il est utile d’apprendre quelques leçons clés avant de bien démarrer.

Cet article présente quelques facteurs clés de réussite pour les équipes de développement Agile :

• Affinement diligent du backlog
• Intégration précoce et fréquente
• Minimiser la dette technique

Affinement diligent du backlog

Une équipe de développement Agile travaille à partir d’un arriéré d'exigences, souvent appelées histoires d'utilisateurs. L'arriéré hiérarchisé, avec les histoires d'utilisateurs les plus importantes en haut. Le propriétaire du produit, qui est le backlog, ajoute, modifie et hiérarchise de nouveau les récits utilisateur en fonction des besoins du client.

Un backlog mal défini constitue l’un des principaux freins à la productivité d’une équipe Agile. On ne peut pas s'attendre à ce qu'une équipe fournisse systématiquement des logiciels de haute qualité à chaque sprint à moins d'avoir des exigences clairement définies.

Le travail du propriétaire du produit est de s’assurer qu'à chaque sprint, les ingénieurs disposent d'histoires d'utilisateurs clairement définies avec lesquelles travailler. Les histoires d'utilisateurs en haut de l'arriéré doivent toujours être prêtes pour que l’équipe puisse démarrer. Cette notion s'appelle affinement d'arriéré. Garder un arriéré prêt pour une équipe de développement Agile nécessite des efforts et de la discipline. Heureusement, l'investissement en vaut la peine.

Lorsque vous affinez un arriéré, n’oubliez pas les considérations clés suivantes.

1. L’affinement des histoires d'utilisateurs est souvent une activité à à long délai de livraison. Des interfaces utilisateur élégantes, de belles conceptions d’écran et des solutions qui enchantent le client prennent toutes du temps et de l’énergie à créer. Les propriétaires de produits diligents affinent les histoires d'utilisateurs deux à trois sprints à l’avance. Ils tiennent compte des itérations de conception et des avis des clients. Ils travaillent pour s’assurer que chaque histoire d'utilisateur est quelque chose que l’équipe Agile est fière de livrer au client.

2. Une histoire d'utilisateur n’est affinée que si l’équipe l’indique. L’équipe doit passer en revue l’histoire d’utilisateur et convenir qu’elle est prête à travailler dessus. Si une équipe ne voit pas l’histoire d'utilisateur avant le premier jour d'un sprint, des problèmes peuvent probablement en résulter.

3. Les histoires d'utilisateurs plus en aval dans l'arriéré peuvent rester ambiguës. Ne perdez pas de temps à affiner les éléments de priorité inférieure. Concentrez-vous sur la partie supérieure de l'arriéré.

Intégrer tôt et souvent

L’intégration continue et la livraison continue (CI/CD) configurent votre équipe pour le rythme rapide du développement Agile. Dès que possible, automatisez les pipelines de génération, de test et de déploiement. Configurez cette automatisation comme l'une des premières tâches auxquelles votre équipe s’attaque lorsque vous démarrez un nouveau projet.

Avec l’automatisation, l’équipe évite les processus de déploiement manuel lents, sujets aux erreurs et chronophages. Puisque les équipes publient chaque sprint, elles n'ont pas le temps d’effectuer ces tâches manuellement.

CI/CD influence également votre architecture logicielle. Il garantit que vous fournissez des logiciels modulables et déployables. Lorsque les équipes implémentent une fonctionnalité difficile à déployer, elles se rendent compte immédiatement si la génération et les déploiements échouent. CI/CD force une équipe à résoudre les problèmes de déploiement au fur et à mesure qu’elles se produisent. Le produit est alors toujours prêt à être expédié.

Il existe des activités CI/CD clés qui sont extrêmement importantes pour le développement Agile efficace.

1. Test unitaire. Les tests unitaires constituent la première défense contre l’erreur humaine. Considérez les tests unitaires comme une partie du codage. Enregistrez les tests avec le code. Faites des tests unitaires une partie de chaque build. Les tests unitaires échoués signifient une build échouée.

2. Automatisation de build. Le système de build doit extraire automatiquement le code et les tests directement à partir du contrôle de code source lors de l’exécution des builds.

3. Stratégies de branche et de build. Configurez les stratégies de branche et de build pour générer automatiquement, car l’équipe enregistre le code dans une branche spécifique.

4. Déployer dans un environnement. Configurez un pipeline de mise en production qui déploie automatiquement des projets générés dans un environnement qui imite la production.

Minimiser la dette technique

Avec les finances personnelles, il est plus facile de ne pas s’endetter que de s’en sortir. La même règle s’applique à la dette technique. La dette technique comprend tout ce que l’équipe doit résoudre en raison des raccourcis pris plus tôt. Par exemple, si vous avez un calendrier serré, vous pouvez sacrifier la qualité pour respecter une échéance. La dette technique est le prix que vous payez plus tard, quand vous devez refactoriser le code pour compenser ce manque de qualité. Les exemples incluent des correctifs pour résoudre les problèmes de conception, les bogues, les problèmes de performances, les problèmes opérationnels, les problèmes d’accessibilité et d’autres problèmes.

Maîtriser la dette technique nécessite du courage. Il y a de nombreuses pressions pour retarder la révision du code. Cela fait du bien de travailler sur des fonctionnalités et d’ignorer la dette. Malheureusement, quelqu’un doit rembourser la dette technique tôt ou tard. Tout comme la dette financière, la dette technique devient plus difficile à rembourser plus elle existe longtemps. Un propriétaire de produit intelligent travaille avec son équipe pour s’assurer qu’il a le temps de rembourser sa dette technique à chaque sprint. L’équilibrage de la réduction de la dette technique avec le développement de fonctionnalités est une tâche difficile. Heureusement, il existe quelques techniques simples pour créer des équipes productives et axées sur les clients.

Soyez toujours Agile

Être Agile signifie apprendre de l’expérience et s'améliorer continuellement. Le développement Agile fournit plus de cycles d’apprentissage que la planification traditionnelle des projets en raison des boucles de processus plus étroites. Chaque sprint offre à l’équipe quelque chose de nouveau à apprendre.

Par exemple :

• Une équipe apporte de la valeur au client, obtient des commentaires, puis modifie son arriéré en fonction de ces commentaires.
• Elles apprennent qu'il manque des tests clés dans leurs builds automatisées. Elles incluent du travail dans leur prochain sprint pour résoudre ce problème.
• Elles constatent que certaines fonctionnalités s’exécutent mal en production en envisagent donc d’améliorer les performances.
• Quelqu'un de l'équipe entend parler d'une nouvelle pratique. L'équipe décide de l'essayer pendant quelques sprints.

Les équipes qui débutent dans le développement Agile doivent s'attendre à plus d'opportunités d'apprentissage. Elles constituent une partie inestimable du processus parce qu’elles mènent à la croissance et à l’amélioration.

Étapes suivantes

Il existe de nombreuses façons de choisir un processus de développement Agile adapté à une équipe. Azure DevOps fournit différents modèles de processus. Les équipes qui recherchent différentes structures de base pour leur planification peuvent utiliser ces modèles comme points de départ. Pour plus d’informations sur la sélection d’un modèle de processus qui correspond le mieux à la culture et aux objectifs d’une équipe, consultez Choisir un flux de processus ou un modèle de processus à utiliser dans Azure Boards.

À mesure que les organisations se développent, il peut être difficile de rester discipliné. En savoir plus sur l'adaptation Agile aux grandes équipes.