Dans nos différents articles, nous avons abordé la méthode Agile sous l’angle du rôle du Product Owner ou encore de la comparaison entre Agile et cascade. L’Agilité est, comme son nom l’indique, un concept souple avec des principes généraux mais pas un cadre rigide. Chaque organisation en crée donc sa propre définition. Quelle est celle d’Uzinakod? Entrons dans le vif du sujet avec cet article qui vous dit tout sur la méthode Agile à la sauce Uzinakod.
Commençons par une question: quel est le point commun entre l’Agilité et l’athlétisme? Les sprints!
Les sprints (ou itérations) sont des cycles au cours desquels l’équipe Uzinakod travaille en partenariat avec le client sur la livraison de fonctionnalités. C’est le mouvement de chacune de ces itérations qui permet au projet d’avancer comme chaque relayeur en athlétisme. Sans être des Usain Bolt, les membres de l’équipe Uzinakod et le client travaillent ensemble pour franchir la ligne d’arrivée. L’heure est venue de présenter l’équipe Agile, façon Uzinakod.
L’équipe Agile, façon Uzinakod
Notre équipe Agile a comme point de départ la méthode Scrum, avec l’ajout d’autres rôles. Selon le projet, un membre de l’équipe peut officiellement ou officieusement assumer plusieurs rôles. À l’inverse, une responsabilité peut être distribuée entre les membres de l’équipe.
Les rôles Scrum classiques
Product Owner, le chef d’orchestre
Le Product Owner ou «PO» vient de la compagnie cliente. Son rôle est une version adaptée du rôle de Product Owner de la méthode Scrum.
- Avoir une vue globale de l’application
- Maintenir le cap sur les objectifs globaux de sa compagnie pour l’application
- Identifier les priorités
Voir cet excellent article pour plus de détails sur le rôle du Product Owner.
Scrum Master, le facilitateur
- Élimine les obstacles qui pourraient entraver l’avancement de l’équipe sur le travail en cours
- Gardien de la portée et des objectifs du sprint
- Communique sur l’avancement du sprint par rapport aux objectifs.
- Veille à l’application des principes Agile
L’équipe de livraison
L’équipe de livraison se divise en 3 spécialités:
1. Analyse d’affaires
- Fait le pont entre le client et l’équipe de développement
- Identifie les besoins, veille à comprendre le contexte des utilisateurs finaux, définit le contexte et les objectifs fonctionnalités
- Suppléant du Product Owner: donne des précisions sur des besoins exprimés par les utilisateurs pour aider à la priorisation
Voir notre article sur l’analyste d’affaires.
2. Développement
- Encadrés par un chef d’équipe (Team Lead) au niveau technique et pour le développement des compétences
- Définit et met en œuvre la solution technique qui correspond à une fonctionnalité
- Effectue les démonstrations des fonctionnalités livrées en fin de sprint
3. Assurance qualité
Responsabilité distribuée avec parfois un analyste en assurance qualité dédié au projet.
- Définition des scénarios de tests en fonction des réalités du client
- Définition de scénarios plus élaborés, cas limite au fil du développement
- Identification des anomalies
Voir aussi notre article sur l’analyste en assurance qualité.
Les rôles d’encadrement
Gestionnaire de projet
- Gardien de la portée et du budget
- Suit l’avancement du projet dans sa globalité par rapport aux objectifs définis pour le projet ou la phase du projet
- Analyse l’impact des changements de priorité et modifications de portée majeures sur l’échéancier et/ou le budget
- Identifie les risques
Gestionnaire de compte
- Gardien de la relation du client avec Uzinakod
- Point de contact permanent du client en parallèle des projets
- Suit les aspects de facturation, maintenance et besoins d’évolution de l’application
L’emploi du temps Agile, façon Uzinakod
Pour que l’équipe avance et surtout dans la bonne direction, des points de vérification récurrents ont lieu pour s’assurer de l’alignement de tous vers les mêmes objectifs: ce sont les réunions Agile aussi appelées «cérémonies Agile» qui s’étalent sur la durée du sprint. Pour faire le meilleur usage possible du temps de notre Product Owner, certaines de ces réunions impliquent uniquement l’équipe de livraison.
Les daily stand ups
Fréquence: Quotidienne, de préférence en début de journée
But: Communiquer l’avancement de chaque membre de l’équipe
Acteurs: Product Owner | Scrum Master | Équipe de livraison
Déroulement: Chaque membre de l’équipe identifie ce qu’il a fait la veille, ce qu’il fera aujourd’hui et identifie les éventuels défis rencontrés.
Comme les blagues, les réunions les plus courtes sont les meilleures! 😉 Le daily doit durer 15 minutes maximum. Dans le daily, les discussions sur les défis sont juste un début de conversation… la suite viendra dans une autre réunion!
Les priorisations
Fréquence: 1 ou 2 fois par sprint selon le contexte du projet
But: Guider la planification des prochains sprints et mieux suivre l’avancement des fonctionnalités en identifiant les priorités
Acteurs: Product Owner | Gestionnaire de projet | Analyste d’affaires | Scrum Master
Déroulement: Selon la phase du projet, les discussions seront à plus ou moins haut niveau de détail:
- Définir ensemble les objectifs de l’application à moyen terme (quelles activités veut-on pouvoir réaliser dans 3 mois?)
- Prioriser des fonctionnalités plus précises amenées par les utilisateurs finaux dans les réunions d’analyse ou par l’équipe de livraison
Les groomings
Fréquence: 1 ou 2 fois par sprint selon le volume de fonctionnalités à évaluer.
But: Définir l’effort relatif de fonctionnalités (user story) selon les priorités définies
Acteurs: Gestionnaire de projet | Équipe de livraison | Scrum Master
Déroulement: L’équipe revoit des user stories (portée, contexte, résultats attendus) et évalue chacune en termes de complexité et de niveau d’incertitude dans une unité appelée «story points».
Le nombre de story points livrés par l’équipe en un sprint permet de déterminer sa cadence d’avancement, appelée vélocité. La vélocité sert de guide à la planification des futurs sprints en termes de quantité.
Les pré-démos
Fréquence: 1 fois par sprint, avant la démonstration
But: Identifier les éléments qui seront prêts à être présentés durant la démonstration de fin de sprint et de définir le scénario qui sera présenté
Acteurs: Équipe de livraison | Scrum Master | Gestionnaire de projet
Déroulement: L’équipe passe en revue les stories qui ont été terminées et peaufine le scénario de la démonstration
Certains ajustements peuvent être identifiés à cette étape et effectués ou priorisés avec le PO selon leur portée et leur impact.
Les planifications de sprint
Fréquence: Une fois par sprint, en début de sprint.
But: Définir le contenu du sprint qui commence qui est l’engagement de l’équipe de livraison.
Acteurs: Gestionnaire de projet | Équipe de livraison | Scrum Master
Déroulement: Les user stories et bugs sont ajoutés au sprint selon les priorités définies, la vélocité de l’équipe et les disponibilités de l’équipe
Un objectif du sprint sera déterminé en équipe et communiqué au Product Owner.
Dans certains cas, l’assignation des différentes fonctionnalités aux membres de l’équipe sera définie.
Les bilans de fin de sprint/démonstrations
Fréquence: Une fois par sprint, à la fin du sprint.
But: Présenter au PO les éléments qui ont été livrés durant le sprint.
Acteurs: Product Owner | Gestionnaire de projet | Équipe de livraison | Scrum Master |Autres membres de l’équipe chez le client le cas échéant
Déroulement: Le bilan de fin de sprint et la démonstration peuvent être la même réunion ou deux réunions distinctes. Le bilan du sprint permet de revoir les résultats du sprint (ce qui a été livré, ce qui ne l’a pas été et pourquoi) et d’identifier si l’objectif défini a été atteint.
Au cours de la démonstration, comme son nom l’indique, un membre de l’équipe ou plusieurs membres font la démonstration des fonctionnalités terminées dans l’application.
Les commentaires du PO ou de son équipe sont recueillis et sont ajoutés au backlog pour priorisation.
Les rétrospectives
Fréquence: Une fois par sprint, après la démonstration
But: Favoriser l’amélioration continue du fonctionnement de l’équipe
Acteurs: Équipe de livraison | Scrum Master | Gestionnaire de projet
Déroulement: Chaque membre de l’équipe identifie ce qui a bien été et ce qui a moins bien été dans le sprint avec des post-it ou verbalement. L’équipe décide ensuite d’un plan d’action pour ce qui a moins bien été.
Conclusion
L’Agilité est une pratique adaptative et évolutive. Notre définition est donc non seulement appelée à changer au fil du temps mais aussi à s’adapter à la taille du projet et à la réalité de nos clients. Si cet article présente les grandes lignes de notre approche, cela ne signifie donc pas que tout ce qui y figure sera appliqué à la lettre. Notre but est d’avoir une approche pragmatique qui tend vers la qualité des applications et la satisfaction des clients.
