Le développement trunk-based : la pratique d'ingénierie qui fait fonctionner Scrum
Les équipes Scrum s'engagent à livrer un logiciel fonctionnel à la fin de chaque sprint. Cet engagement n'est crédible que si les pratiques d'ingénierie qui sous-tendent la capacité à intégrer et déployer à la demande sont réellement en place. Dans de nombreuses équipes Scrum, ce n'est pas le cas. Les équipes travaillent dans des branches de fonctionnalités à longue durée de vie, puis font face à un événement d'intégration douloureux en fin de sprint lorsque tout le travail est fusionné simultanément. Le coût d'intégration est élevé, les retours sont tardifs, et la promesse de livraison continue reste théorique plutôt qu'opérationnelle.
Ce que le développement trunk-based signifie en pratique
Intégrer sur main au moins une fois par jour : le plus long délai de divergence est d'une journée. Les conflits de fusion sont petits et fréquents plutôt que grands et occasionnels.
Utiliser des branches à courte durée de vie (maximum deux jours) : une branche qui ne peut pas être complétée et fusionnée en deux jours est généralement le signe que le travail doit être davantage décomposé.
Utiliser des drapeaux de fonctionnalité plutôt que des branches pour masquer le travail incomplet : le code est intégré et testé dans la base de code principale mais pas exposé aux utilisateurs finaux tant que l'équipe n'est pas prête.
Tests automatisés rapides : la condition préalable la plus importante. Un suite de tests qui prend quarante-cinq minutes à s'exécuter décourage l'intégration fréquente.
Si vos équipes Scrum ont du mal avec l'intégration ou l'écart entre la cérémonie et la livraison, la pratique de livraison de programmes et projets de XNM peut vous aider à évaluer vos pratiques d'ingénierie et à construire les fondations techniques qui rendent la livraison agile crédible.