Objectifs

• Priorités changeantes
• Trop de sujets en parallèle
• Demandes en direct aux développeurs
• Suivi de l'avancement des projets difficiles

Méthodologie

• Process changeants
• Process pas respectés
• Objectifs des réunions pas clairs
• Pas de réunion "process/organisation"

Tickets

• Tickets mal spécifiés
• Technique absente de la phase de conception
• Outil Wrike mal adapté

Code

• Déploiements incertains
• Communication des mise en prod avec le reste d'ecov
• Documentation des features

Définir des rôles

• Objectif :
  • Clarifier la responsabilité de chacun
  • Identifier facilement les problématiques d'organisation
  • Permettre une évolution organique des process
• Définition : 
  • Un rôle est définit par ses redevabilités
  • Un rôle à toute autorité sur la manière dont il réalise ses redevabilités
  • Les rôles sont crées/modifiés/supprimés par toute l'équipe

Définir des workflow

• Objectif : 
  • Clarifier les actions qui doivent être prises et l'intervention de chaque rôle, de la conception au déploiement.
• Définition : 
  • Un workflow :
    • Détaille les colonnes du kanban
    • Le rôle assigné au ticket et qui doit faire une action
    • Les exigences requises pour qu'un ticket change de colonne
    • Et les différentes transitions possibles
  • Plusieurs workflow seront proposés : 
    • Conception / Craquage
    • Bug
    • Intersprint
    • Developpement & Review
    • Q/A
    • Déploiement

Définir des process réunions

• Objectif : 
  • Clarifier le but de chaque réunion
• Définition : 
  • L'objectif attendu de chaque réunion est définit
  • Le process de chaque réunion est définit
  • Un·e facilitateur·ice fait respecter le process

Responsable Équipe

• Assigner les rôles
• Assurer tous les rôles non assignés
• Assurer le lien avec le reste de l'entreprise
• Suivre les aspect administratifs de l'équipe

Facilitateur·ice

• Préparer l'espace de réunion, l'ouvre et le ferme
• Veiller au respect des process de réunion
• Veiller au respect du temps définit de réunion

• Fluidifier les échanges, veiller à la répartition des prises de parole dans les espaces de libre échange

Responsable Produit

• Définir le planning prévisionnel des projets de développement
• Centraliser les demandes de features du reste de l'entreprise
• Créer les tickets de 'features'
• Définir les spécifications produit sur les tickets 'features'
• Prioriser les tickets 'features'
• Définir le workflow "conception"
• Documenter le workflow "conception"
• Communiquer les mises en lignes de nouvelles 'features' avec le reste de l'entreprise
• Documenter les features

Responsable Projet

[par projet]

• Centraliser l'information sur le projet
• Interlocuteur privilégie du·de la responsable produit
• Partager l'état d'avancement du projet au reste de l'équipe
• Alimenter le backlog du projet au début des sprints
• Alerter le·a responsable produit en cas de retard

Responsable Conception/Craquage

[par projet]

• Découper les tickets 'feature' en tickets 'tech'
• Définir les spécification techniques des tickets 'tech'
• Définir l'estimation des tickets tech
• Définir le workflow "craquage"
• Documenter le workflow "craquage"

Responsable Support

[par projet]

• Centraliser les remontées de bug du reste de l'entreprise
• Créer les tickets 'bug'
• Prioriser les tickets 'bug'
• Définir le workflow 'bug'
• Documenter le workflow 'bug'
• Communiquer la résolution des bugs au reste de l'entreprise

Développeur

[par projet]

• Développer le code des tickets 'tech'
• Conserver la cohérence des développements avec le reste de l'équipe

Développeur Support / Hotseat

[par projet]

• Définir les spécifications techniques des tickets 'bug'
• Corriger les bugs

Responsable Qualité

[par projet]

• Assurer la lisibilité et la maintenabilité du code
• Définir le workflow "developpement & review"
• Documenter le workflow "developpement & review"
• Créer, spécifier et prioriser les tickets 'intersprint'
• Définir le workflow "intersprint"
• Documenter le workflow "intersprint"

Responsable Q/A

[par projet]

• Assurer que le code envoyé en production fonctionne conformément aux spécifications produit
• Définir le workflow 'Q/A'
• Documenter le workflow 'Q/A'

Responsable Déploiement

[par projet]

• Permettre que le projet puisse être déployé n'importe quand pendant les horaires de travail, y compris quand le porteur du rôle est absent
• Définir le workflow 'déploiement'
• Documenter le workflow 'déploiement'

Liste des projets

• Covoitici front
• Covoitici + lane back
• Netmanager
• Elancité/PMV
• ... ?

Workflow 'conception'

Pipelines

• 'Nouveau' : Tickets 'feature' entrants + creation
• 'idée' : Tickets 'feature' à faire un jour
• 'actionnable' : Tickets 'feature' a faire dans l'année
• 'ct (court terme)' : Tickets 'feature' à faire le plus tôt possible
• 'qualifiés / spécifiés' : Tickets 'feature' spécifiés fonctionnellement
• 'sprint / validés' : Tickets 'feature' priorisés pour le prochain sprint

Workflow 'craquage'

Pipelines

• 'Nouveau' : Creation tickets 'tech' à partir du pipeline 'sprint / validés' du workflow 'conception'
• 'Spécifiés' : Tickets 'tech' spécifiés techniquement
• 'Validés' : Tickets 'tech' estimés

Workflow 'bug'

Pipelines

• 'Nouveau' : Tickets 'bug' entrants + creation
• 'Spécifiés' : Tickets 'bug' spécifiés techniquement
  • transition vers 'valides' ou 'sprint en cours'
• 'Valides' : Tickets 'bug' priorisés pour le sprint suivant

Workflow 'developpement & review' (sprint en cours)

Pipelines

• 'Nouveau' : Tickets 'bug' ou 'tech'
• 'en cours' : Tickets 'bug' ou 'tech' en cours de développement
• 'review' : Tickets 'bug' ou 'tech' développé, avec une/des MR liées
• 'test fonctionnels / QA' : Tickets 'bug' ou 'tech' reviewé ok, déployés sur staging, à tester fonctionnellement
• 'validés' : Tickets 'bug' ou 'tech' validés fonctionnellement, à deployer
• 'closed' : Tickets déployés en prod

Workflow 'deploy'

Pipelines

• 'Nouveau' : Tickets validés fonctionnellement
• 'merged' : Tickets mergé dans la branche 'develop' (ou 'master'?)
• 'deployed' : Tickets 'déployés'

Workflows

• Différents Workflows ne signifie pas différents board
• Potentiellement, tout les workflows peuvent travailler sur le même board

Stand-up

• 1x /jour - 30 min
• objectif : 
  • informer de l'avancement des développements
  • demander de l'aide
  • planifier une réunion supplémentaire
• process : 
  • tour de table des rôles développeur pour informer le changement d'état de leurs tickets, ou d'un blocage et demande d'aide
  • tour de triage
    • chacun est libre de soulever un point problématique qui affecte son rôle et l'empêche de remplir ses redevabilités
    • (ex: le rôle "craquage" demande à faire une réunion poker pour estimer X tickets)

Review

• A chaque fin de sprint - 1h
• objectif : 
  • identifier les réalisations du sprint qui vient de terminer
• process : 
  • Revue de tous les tickets du sprint précédent, pour identifier la vélocité du sprint, les erreurs d'estimations, les blocages, les tickets non-réalisés

Retro

• A chaque fin de sprint - 1h
• objectif : 
  • identifier les problématiques de process
  • définir les actions (prochain petit pas) à mener pour résoudre ces problématiques
  • c'est le moment où on peut créer/modifier/supprimer des rôles
• process : 
  • tour de table sur les points de blocages, frustrations qui sont arrivés au cours du sprint
  • Pour chaque "tension", on définit une action à mener.

Planification

• A chaque fin de sprint - 2h
• objectif : 
  • Définir le contenu du sprint suivant
• process : 
  • On définit la vélocité prévisionnelle du prochain sprint
  • Pour chaque ticket 'spécifié' du workflow 'conception'
    • on découpe les tâches en tickets 'tech' sous la direction du rôle "craquage"
    • on fait une estimation sous la direction du rôle "craquage"
  • En prenant la liste des tickets 'tech' et 'bug' du pipeline 'validés', on remplit le prochain sprint