Depuis quelques mois, nous avons établi un protocole de production détaillé sur les nouveautés les plus importantes. Explications :

1. Développement en méthode SCRUM. C’est la dernière née des méthodes Agile. Adieu les cahiers des charges hyper développés et rapidement obsolètes : ici, on se lance tout de suite dans le développement, sur des cycles courts de 2 semaines (les sprints), avec l’objectif de produire un livrable, c’est à dire un bout de fonctionnalité que l’on peut montrer (à l’équipe, aux co-producteurs), critiquer, valider… et qui donnera de nouvelles idées sur la suite du développement.
   Une petite fonctionnalité pourra être développée en 15 jours, les plus importantes pourront s’étaler sur 10 sprints ou plus.
2. les alpha tests. Lorsque le ou les développeurs ont terminé le développement, c’est Guillaume (ou Cécile, ou Jean-Luc) qui va vérifier que la nouveauté fonctionne, et qu’elle n’entraine pas d’effets de bords sur le reste de l’application. Ça s’est vu : un nouveau contrat qui modifie l’édition des mails, par exemple.
3. le bêta test. On passe à cette phase lorsque l’on est certain que la nouveauté n’est pas dangereuse pour les utilisateurs, et en particulier qu’aucune donnée ne risque d’être effacée.
   Mais il peut rester des petits bugs, que 30 utilisateurs vont pouvoir plus rapidement découvrir qu’un seul alpha testeur. D’autant que chacun a sa propre pratique de Bob, de la souris, du clavier…
   Autre vertu du bêta test, les retours d’utilisateurs sur les trucs qui manquent, ou qui pourraient proposés différemment. En fonction de ces retours, cette phase peut s’étaler sur 1 semaine, ou sur 2 mois
4. La release. Tout est ok : on livre à tout le monde. La découverte de bugs mineurs n’est pas exclus, mais les développeurs prévoient d’être très réactifs sur cette phase.