Mode d'organisation proposé

Agilité et libre organisation d'équipe

Les projets proposés seront instruits par le CNES/ ArianeWorks selon un ésprit agile, plus adapté quand les besoins sont à construire dans le temps et que les spécifications sont difficiles à prévoir très tôt dans le projet.

Le schéma ci-dessous illustre le principe de fonctionnement que l'on souhaite proposer.

Une grande liberté d'organisation interne est laissée. L'idée est de toujours garder le lien avec le référent du projet (CNES ou Arianeworks)

Proposition de suivi des activités

Pour rentrer dans le détail du suivi des sprints, il est suggéré qu'une liste ou backlog de User stories soient construites par le "Product owner" ou "chef de projet" à partir de la liste/ backlog d'EPICs proposés.

Dès l'identification de la user-story, une définition du "Réalisé" est précisé. "J'ai bien un materiel fabriqué", "j'ai testé l'objet", "j'ai codé un algorythme validé"...

Chaque User-story sont découpées en sous-tâches qui devront être traitées par les équipes lors de sprints. Dès que la complétion de toutes les tâches liées à une user story est faite, on peut la considérer comme "réalisée". Lors de ces revues de sprint, CNES pourra être acivé si disponible. Dans tous les cas, le product owner définit la réalisation ou non de la tâche.

Une classification en complexité et en priorité est toujours bienvenue pour piloter les tâches.

Si à la fin d'un sprint (tous les 4 sprints en baseline si on cherche à cadencer programmatiquement), on obtient un MVP (produit minimum viable), dans ce cas là, une revue ou un évenement est fait pour montrer la réalisation qui servira de base à la suite du projet.