Quand une équipe fait appel à moi pour une mission de coaching Agile ou que je m’engage dans un séminaire interactif consacré à l’agilité, mes interlocuteurs sont toujours surpris et curieux de me voir aborder ces questions là …
Vous êtes le premier à nous en parler…
Je n’avais pas vu le Sprint Zéro sous cet angle…
Ça me rassure, j’y vois plus clair…
Attendez mais c’est donc compatible avec notre process de déploiement…
Sans pour autant fixer des règles ultra figées qui n’auraient guère de sens dans un contexte Agile, j’ai pourtant des messages forts à délivrer et quelques repères à proposer :
- Oui, dans un projet Agile, il y a un Sprint 0 au démarrage, un sprint vraiment différent des autres, même si sa durée selon les contextes est variable (de quelques jours à 3 semaines) en fonction de la maturité de l’Equipe sur certaines questions…
- Oui dans un projet Agile, il y a souvent un « End Game », un sprint un peu particulier en fin de version…
Et puisqu’un schéma vaut mieux qu’un long discours, voilà un exemple de cycle de vie (agile) :
SPRINT 0
Le Sprint Zéro n’est pas un vrai sprint (agile) au sens où il ne se termine pas forcément par la livraison d’un produit qui marche, et que sa durée est variable (de quelques jours à 3 ou 4 semaines). Ce sprint est pourtant essentiel pour mettre le projet sur de bons rails et permettre à l’équipe d’apprendre à travailler ensemble.
C’est un moment privilégié pour construire sa collaboration et prendre ses marques.
Quelles sont les activités typiques menées en Sprint 0 ?
- Partager une VISION claire du produit
- Analyser les risques
- Déterminer un plan de release (version)
- Produire un Backlog de produit estimé et priorisé
- Préparer l’environnement de développement (y compris quelques docs)
- Définir la posture ergonomique de l’interface et identifier les cibles (Personas)
- Selon les contextes, travailler l’architecture
- Dans tous les cas rôder l’équipe qui se DECOUVRE
END GAME
« End Game » mais pas vraiment une fin dans le sens où dans les faits ce sprint apparaît davantage comme une transition. Ce sprint, c’est le moment où l’équipe met la touche finale à la version et travaille de concert avec ceux qui vont déployer et exploiter au quotidien la future application.
Attention : CE N’EST PAS UNE PHASE DE TEST, même si certains types de test y trouveront une place privilégiée (tests d’acceptation, performance globale, alpha ou beta testing).
La durée du End Game est aussi variable (selon les activités menées au préalable), il peut être très court même courir sur deux sprints…
Quelles sont les activités typiques pouvant être menées en End Game ?
- Test final de la version dans un environnement similaire à la Prod
- Tests d’acceptation et tests utilisateurs sur l’ensemble de la version (même si des tests ont été réalisés au fur et à mesure)
- Tests d’install
- Possibles tests d’intégration de parties tierces non disponibles jusqu’alors
- Rework car qui dit test dit activité de dév 🙂
- Touche finale à la documentation
- Formation des utilisateurs
- Travail sur les bases de données
- …
Dans le « End Game » je n’y met que tes points 6 et 7. En effet le déploiement en production au fur et à meusure du dev ou dans le pire des cas à la fin de chaque sprint me parait indispensable : Fail Fast ! Même si c’est sur un environement iso prod non ouvert au publique, mais avec l’ensemble du monitoring, applicatifs et technique.
La notion de Done est à mon avis indissociable du « ça marche en production ». Ce qui exclu d’office les tests « en environement prod like » du end game, ça exclu aussi les test d’install et les taches de packaging.