Organisation Tech @ecov

Problématiques cibles

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

Proposition

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

Rôles

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
  • ... ?

Workflows

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

Réunions

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

Conclusion

  • Ceci est une proposition
  • Tous les aspect de ce document peuvent être modifiés
  • La mise en place de ce système devrait être soumis au consentement de toute l'équipe
  • Ce document n'est pas exhaustif, les process & workflows devront êtres travaillés par les rôles dont c'est la redevabilité
  • Avec l'organisation par rôles, les workflow & process sont fait pour être évolutifs, et s'adapter aux besoins de l'équipe

deck

By Thomas Petrachi

deck

  • 24
Loading comments...

More from Thomas Petrachi