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

Le développement agile est un terme utilisé pour décrire le développement de logiciels itératifs. Le développement logiciel itératif raccourcit le cycle de vie DevOps en effectuant des travaux par incréments courts, généralement appelés sprints. Les sprints sont généralement longs d’une à quatre semaines. Le développement agile est souvent contrasté avec le développement traditionnel ou en cascade, qui planifie des projets plus importants à l’avance et les termine en fonction du plan.

Fournir du code de qualité de production chaque sprint nécessite que l’équipe de développement Agile compte pour un rythme accéléré. Toutes les vérifications de codage, de test et de qualité doivent être effectuées à chaque sprint. À moins qu’une équipe ne soit correctement configurée, les résultats peuvent tomber en deçà 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 commencer.

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
• Réduction de la dette technique

Affinement diligent du backlog

Une équipe de développement Agile se base sur un backlog de tâches, souvent appelées récits utilisateur. Le backlog est hiérarchisé, avec les récits utilisateur les plus importants en haut. Le propriétaire du produit possède le backlog et ajoute, modifie et rérioritise les récits utilisateur en fonction des besoins du client.

L'un des plus grands freins à la productivité d'une équipe Agile est un backlog mal défini. Une équipe ne peut pas être censée fournir de manière cohérente des logiciels de haute qualité chaque sprint, sauf si elles ont des exigences clairement définies.

Le travail du propriétaire du produit est de s’assurer que chaque sprint, les ingénieurs ont clairement défini les récits utilisateur à utiliser. Les récits utilisateur en haut du backlog du projet doivent toujours être prêts à être entamés par l'équipe. Cette notion est appelée affinement du backlog. Maintenir un backlog prêt pour une équipe de développement Agile nécessite des efforts et une discipline. Heureusement, il vaut bien la peine d’investir.

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

1. L’affinement des récits utilisateur est souvent une activité à long terme. Les interfaces utilisateur élégantes, les belles conceptions d’écran et les solutions de plaisir client prennent du temps et de l’énergie pour créer. Les propriétaires de produits diligents affinent les histoires utilisateur deux à trois sprints à l’avance. Ils prennent en compte les itérations de conception et les avis des clients. Ils travaillent pour s’assurer que chaque récit utilisateur est quelque chose que l’équipe Agile est fière de livrer au client.

2. Un récit utilisateur n’est pas affiné, sauf si l’équipe l’indique. L’équipe doit passer en revue le récit utilisateur et convenir qu’il est prêt à être traité. Si une équipe ne voit pas l’histoire de l’utilisateur jusqu’à l’un des jours d’un sprint, des problèmes peuvent probablement se produire.

3. Les récits utilisateur plus loin dans le backlog peuvent rester ambigus. Ne perdez pas de temps à affiner les éléments de priorité inférieure. Concentrez-vous sur la partie supérieure du backlog.

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 en tant que première tâche que votre équipe s’attaque lorsque vous démarrez un nouveau projet.

Avec l’automatisation, l’équipe évite les processus de déploiement manuels lents, sujets aux erreurs et nécessitant beaucoup de temps. Étant donné que les équipes publient chaque sprint, il n’y a pas le temps d’effectuer ces tâches manuellement.

CI/CD influence également votre architecture logicielle. Il garantit que vous fournissez des logiciels pouvant être générés et déployables. Lorsque les équipes implémentent une fonctionnalité difficile à déployer, elles prennent connaissance 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. Envisagez de tester unitairement une partie du codage. Vérifiez les tests avec le code. Effectuez des tests unitaires dans chaque build. Les tests unitaires ayant échoué signifient qu’une build a échoué.

2. Générer l’automatisation. Le système de génération 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 branchement et de compilation. Configurez les stratégies de branche et de génération pour générer automatiquement, car l’équipe vérifie 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.

Réduire la dette technique

En matière de finances personnelles, il est plus facile d'éviter la dette 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 traiter en raison de raccourcis qui ont été pris précédemment. 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.

Gérer la dette technique nécessite du courage. Il existe de nombreuses pressions pour retarder le remaniement du code. Il est agréable de travailler sur les 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 longtemps qu’elle existe. Un propriétaire de produit intelligent travaille avec son équipe pour s’assurer qu'il y a du temps prévu pour rembourser la dette technique à chaque sprint. L’équilibrage de la réduction de la dette technique avec le développement de caractéristiques est une tâche difficile. Heureusement, il existe quelques techniques simples pour créer des équipes productives et axées sur les clients.

Toujours être agile

Être Agile signifie apprendre à partir de l’expérience et à 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 fournit quelque chose de nouveau à l’équipe pour apprendre.

Par exemple:

• Une équipe fournit de la valeur au client, obtient des commentaires, puis modifie son backlog en fonction de ces commentaires.
• Ils apprennent que leurs compilations automatisées manquent des tests clés. Ils incluent une tâche dans leur prochain sprint pour résoudre ce problème.
• Ils constatent que certaines fonctionnalités s’exécutent mal en production, de sorte qu’elles prévoient d’améliorer les performances.
• Quelqu’un de l’équipe apprend une nouvelle pratique. L’équipe décide de l’essayer pour quelques sprints.

Les équipes qui commencent simplement par le développement Agile doivent s’attendre à des opportunités d’apprentissage supplémentaires. Ils font partie intégrante du processus parce qu’ils mènent à la croissance et à l’amélioration.

Étapes suivantes

Il existe de nombreuses façons de s’installer sur un processus de développement Agile qui convient à 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 évoluent, il peut s’agir d’un défi de rester discipliné. En savoir plus sur la mise à l’échelle d’Agile vers de grandes équipes.