Reward, je vois bien que TFS est un support, pas une fin en soi.
Scrum est une méthode agile qui implique d'être adopté et compris par l'équipe qui la pratique.
Ce que je pense qu'il faut éviter, c'est de penser qu'imposer un tel outil sur un projet va faire convertir automatiquement l'équipe à Scrum et l'état d'esprit qui en découle.
Certains ne pourront jamais être vérifiés par un outil, comme la tenue du daily standup meeting, et relèvent purement de l'organisation humaine.
Tu as mis le doigt dessus.
Je dirais même plus: Scrum, c'est essentiellement de l'organisation humaine.
Si une équipe n'a pas compris à quoi sert un rétro, si elle n'a pas une DoD (Definition of Done) commune et comprise par tous, si le PO n'a pas une vision de son produit, des contraintes de ses clients et de ces priorité, si les User Story n'ont pas des critères d'accéptances compris, si les équipiers ne se parlent pas, si les équipiers ne s'entraident pas .... là, on loupe complètement Scrum et l'Agilité (avec ou sans TFS)
Pour revenir au tutoriel qu'a évoqué
mikaelkrief, je le trouve également assez claire et cela montre rapidement les possibilités d'un tel outil.
Je le mettrais en œuvre plutôt sur un gros projet: de plusieurs mois (voir années) faisant intervenir plusieurs équipes Scrum (géré par un seul PO).
Pour des petits projets, une équipe sur quelque mois (moins de 10 itérations), je resterai sur une solution plus simple: post-it et mur graphique (avec éventuellement un Backlog log géré sous Excel, j'avoue
, pour les graphiques c'est pratique)
Après, pour des projets intermédiaires, on doit aussi pouvoir l'utiliser partiellement (par exemple, le product backlog dans TPS mais le sprint backlog sur un mur graphique dans la salle de l'équipe)
Je pense qu'il est important aussi que les équipes, qui utilisent TPS, soient bien formé à Scrum, voir même qu'elles aient une expérience de gestion Scrum plus épurée, afin de bien voir où est l'essentiel: le produit livré au client, pas TFS.
Le temps de prise en main d'un tel outil est à prendre en compte aussi.
Faudrait pas que le PO et le Scrum Master se retrouvent à passer plus de temps sur l'outil qu'à géré le produit, les exigences clients et coacher l'équipe.
Par contre, quand les équipes sont nombreuses, ce temps deviens de toute façon nécessaire, et là TFS peux faire gagner du temps.
0 |
0 |
Envoyé par mikaelkrief
