# data[].attributes.attachment_link.readable_text
We couldn't load some important parts of our website. They may have been blocked by your firewall, proxy or browser set-up. Try refreshing the page or get in touch through our help center.

You need a JavaScript-enabled browser to use WeTransfer

# data[].attributes.attachment_link.description
We couldn't load some important parts of our website. They may have been blocked by your firewall, proxy or browser set-up. Try refreshing the page or get in touch through our help center. You need a JavaScript-enabled browser to use WeTransfer

# data[].attributes.body
Comment intégrer les changements de cap de la direction ? À moindre échelle, comment intégrer des demandes clients/prospects émanant des commerciaux et des échanges que nous avons avec les clients ? Évaluer des changements sur la roadmap à 6 mois.
Tout est consigné dans le Backlog produit :
- Si  des exigences/fonctionnalités deviennent soudain plus importantes, la  Business Value consignée sur les Stories correspondantes va augmenter.
- Si ce sont de nouvelles demandes d'évolutions ou corrections de bugs, elles sont enregistrées dans le Product Backlog par le PO. Le PO les affine ( voir notion de INVEST), avant le Sprint Planning, en vue de pouvoir les sélectionner ou pas pour le prochain Sprint.
Q2 : Une roadmap peut être définie lorsqu'on a une bonne idée de la capacité de production de l'équipe de dev (vélocité) . Habituellement on mesure la vélocité sur 3 mois pour en avoir un bon aperçu. Connaissant ainsi le nb de ponts de complexité qu'est capable de délivrer l'équipe pendant la durée du sprint, il est possible d'estimer le nombre de sprints nécessaires pour produire la somme des complexités de l'ensemble des stories à développer sur 6 mois.

# data[].attributes.body
Comment avoir au niveau de la direction un moyen simple de suivi des échéances de livraison en production des évolutions / corrections attendues. Certains pouvant être macro, grosse fonctionnalité nécessitant plusieurs sprints, ou micro comme des demandes spécifiques pour des clients identifiés.

Le SprintBoard de l'équipe Scrum montre au cours du Sprint l'atat d'avancement de la production des stories. La Sprint Review est l'autre moyen d'inspecter l'avancement réel

# data[].attributes.body
- Multiteam / Multiproduit / Multi vélocité : quelle méthode de planification
Quelques pistes
1- Empirisme : qu'est ce que tu as essayé de mettre en place et qui a fonctionné, pas fonctionné ? Reprendre ce qui a marché.
2- Demander aux développeurs ce qu'ils proposent ( les bonnes réponses viennent souvent du terrain)
3-Une réunion d'allocation des ressources mensuelle entre les SM de tous les produits et toi Bastien ( ou toi seul), pour attribuer du temps-développeurs au projet contenant les stories de plus forte valeur ajoutée
4- Définir dès le démarrage une règle du style : tel développeur travaille 3j/ sem sur tel produit et 2 jours/sem  sur l'autre ou tel développeur travaille 1 mois sur tel produit et 1 mois sur l'autre
...

# data[].attributes.body
- Que faire si à la fin du sprint on n'a pas la release attendue
-Il devrait y avoir au minimum un incrément opérationnel prêt à être livré, ( l'incrément du dernier sprint) contenant peut être moins de fonctionnalités promises, mais pouvant être présenté au PO et livré au client avec son accord
-Les stories qui n'ont pas pu être développées dans le dernier sprint sont traitées prioritairement dans le sprint suivant.
-Normalement, le SM doit pouvoir alerter de cette dérive suffisamment tôt et renégocier avec le PO pour voir s'il est possible de repousser les stories de moindre business value dans le sprint suivant ou la release suivante

# data[].attributes.body
- La fameuse conversion vélocité / heure
En SCRUM il est fortement déconseillé de mesurer la productivité de chaque individu mais de mesurer la vélocité d'une équipe, sur le sprint complet

# data[].attributes.body
- Soupape / Pause après plusieurs sprints

A l'équipe de définir son process. -Oui, pourquoi pas un sprint pause avec développement de stories de moindre complexité par exemple. -Mais idéalement, le rythme de production doit être soutenable, au risque d'épuiser l'équipe. Le rythme soutenable est défini lors d'une retrospective à partir de la vélocité moyenne sur 3 mois.
- Des équipes intègrent parfois 2 jours de  respiration sur un sprint de 3 semaines, pour prendre du recul, travailler à son rythme, aire de la veille, innover, travailler sur ce qui plait. Voir l'article https://blog.goood.com/2020/01/21/prenez-le-temps-de-respirer-pendant-les-sprints/

# data[].attributes.body
- Difficultés à transformer les user story (commercial, marketing) en développements (technique, support)

A préciser :
-Soit la difficulté vient du PO qui n'arrive pas à préciser suffisamment les user stories, par manque de discussion/connaissance du client.
-Soit la difficulté vient d'un manque de compétence de l'equipe technique
- Soit la difficulté vient du temps insuffisant que les developpeurs prennent avec le PO lors de session d'affinage des user stories

# data[].attributes.body
- Place du CTO dans l'organisation Agile, crainte d'être trop dominant
Le CTO doit avoir une bonne vision produit. Doit être transparent sur les KPI et leur utilisation. Le CTO apporte son soutien à la Dev Team en allouant notamment les ressources nécessaires au projet et en participant de temps en temps à la sprint review pour encourager la Scrum Team. Il aide si besoin le SM à lever les obstacles identifiés par l'équipe. Il garde un oeil sur le Sprintboard de la dev team ( burndown chart, velocité) pour pouvoir reporter à la Direction,avec le SM, l'avancement du projet, notamment le reste à faire

# data[].attributes.body
- Quels sont les KPI en agilité ?

un petit article sur les bons, les mauvais et les moches :
https://www.berejeb.com/2020/08/metriques-en-agile-les-bonnes-les-mauvaises-et-les-moches/
Scrumchecklist : https://www.crisp.se/wp-content/uploads/2012/05/Scrum-checklist.pdf

# data[].attributes.body
- Quelles sont les possibilités de formation / auto-formation / certification à notre portée, notamment via le CPF
Autoformations :
-  Bcp de choses sur internet. Regarder les minutes agiles de Judicael Paquet.
Formations certifiantes :
1- Personnellement j'ai commencé par Scrumstudy (gratuit)https://www.scrumstudy.com/certification/scrum-fundamentals-certified
2- puis j'ai été formée par Agilbee. Pas sûre qu'ils prennent le CPF.
3-Je suis formatrice chez CEGOS qui accepte les CPF. Voir leurs formations certifiantes SCRUM par ex celle pour le scrummaster : https://www.cegos.fr/formations/systemes-dinformation-informatique/formation-certifiante-scrum-master

# data[].attributes.body
Rapide/Pas cher/Bonne Qualité.
Cette année rapide et cher. DevTeam besoin d'être rassurés sur le fait que, certes cela a coûté cher , mais on va avoir un retour sur investissement et des clients
Essoufflement

# data[].attributes.body
Constat : on veut sortir bcp de choses et cela ne sort pas qd on veut. Clean2 fait de l'ombre aux autres. Bilan gestion de projet : difficulté à produire des gros modules

# data[].attributes.body
Echecs = ressenti: temps de dev longs/ concurrents et demandes client
Le plus : meilleure comm. A améliorer encore : Etre mieux informé de ce qui sort. Redmine pas suffisant

# data[].attributes.body
4 valeurs - 12 principes :
+ :
- : Collaboration avec marché -> club utilisateur

# data[].attributes.body
- : adaptation au changement difficile
+ : individus et interaction, attention avec teletravail

# data[].attributes.body
Je suis agile

# data[].attributes.body
+ : on est déjà agiles
- : on le fait dans la douleur : plus cher, trop de stress, trop de colère -> apaiser, être plus sereins. Finalement objectif être sereins à la montagne, ça lui va bien

# data[].attributes.headline
Quelques actions glanées par Béatrice dans les discussions ou préconisées suite aux 2 sessions de formation

# data[].attributes.subject
Quelques actions glanées par Béatrice dans les discussions ou préconisées suite aux 2 sessions de formation

# data[].attributes.body
- Clarifier le levier d'ajustement de l'équipe technique :
--Soit le contenu pour produire à iso-ressources et dans un délai fixé,
--soit les ressources ( nb de développeurs et testeurs) pour livrer le produit promis au client dans les délais annoncé,
--soit le délai pour livrer le contenu promis avec les moyens limités à l'équipe de dev actuelle.

-Rassurer Nicolas sur les tests unitaires qui continuent d'être faits par les développeurs

-Déployer un plan d'action / Roadmap, la stratégie étant de livrer tout ou rien

-Travail sur les KPI, pour connaître l'état d'avancement de Clean2

- Renforcer le process SCRUM : un backlog correctement estimé et priorisé ( BV et Complexité), des évènements systématiquement tenus : sprint planning, sprint review, sprint retro, daily, la mise en place du suivi de la production ( vélocité) et reporting de l'avancement au CODIR.

# data[].attributes.body
Quelques outils permettant de rendre plus ludique le mode de travail agile (à distance)
Jira : le plus utilisé pour gérer backlog
Trello
Miro tableau blanc
Mantis
Klaxoon
Padlet
Jamboard (postit, tableau blanc)
Planning Poker en ligne :https://www.scrumpoker-online.org/en/
Redmine, Asana, Wrike, VersionOne