Discussion :

[mikaelkrief]

Voici un article sur comment gérer un projet scrum avec TFS (Team Foundation Server) l'outil ALM de Microsoft.

http://mikael-krief.developpez.com/g...crum-avec-tfs/

Je suis interréssé par vos retours.

[Laurent 1973]

Je citerai une valeur de l'agile manifesto (http://agilemanifesto.org/iso/fr/) :

Ces expériences nous ont amenés à valoriser :
Les individus et leurs interactions plus que les processus et les outils ...

Sûrement que cette outil est très intéressant, mais avant d'utiliser un outil pour gérer un projet Scrum, il est important de bien comprendre la philosophie Scum/Agile.
Une fois que celle-ci est bien intégrer dans une organisation, pourquoi pas se pencher sur un outil de se genre pour simplifier certain taches administratives rébarbatives.

Mais vouloir se mettre à Scrum via l'utilisation d'un tel outil est, pour ma part, une erreur et une très mauvaise compréhension de ce que peux apporter l'agilité dans une équipe de développement.
L'Agilité incite tout personne impliqué dans un projet à se parler (en face à face de préférence), c'est pas pour se retrouver coincer derrière son écran.

[mikaelkrief]

bonjour,
je ne suis pas d'accord avec toi

Mais vouloir se mettre à Scrum via l'utilisation d'un tel outil

L'article n'a pas dit cela.

De plus , l'article montre que TFS:

- permet la collaboration pour toutre l'équipe (PO, SM, Equipe, stakeholder) du backlog , du burdown , de l'état d'avancement , et si je ne me trompe pas la collaboration fait aussi parti du manifeste agile, et pour cela un outil de type excel ou tfs est bien necessaire

Les utilisateurs ou leurs représentants et les
développeurs doivent travailler ensemble quotidiennement
tout au long du projet.

- permet de faire de l'integration continue (ce n'est pas expliqué dans l'article)

Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée.

[Laurent 1973]

et pour cela un outil de type excel ou tfs est bien necessaire

Pourquoi faut-il forcement un outil aussi "compliqué" que même un Excel?
Je dis pas qu'il n'est pas nécessaire d'utilisé des outils informatiques que l'on a à notre disposition, je pose juste la question sur le but d'un tel outil?

Communiquer peut-être, non?

Est-ce que commencer avec un tableau blanc ça ne marche pas?
Un mur de post-it pour voir d'un coup d’œil où en sont nos user-stories n'est pas suffisant?

Plein de solutions existent sans forcement avoir comme premier réflexe d'avoir un bel outil informatique.
Les outils qui marchent bien dans une équipe et dans un projet donné ne sont peut-être pas adaptés à une autre équipe ayant un autre contexte.
Faire simple pour commencer, et au fur et a mesure des remarques en rétrospective on peut adapter nos outils et nos pratiques à nos besoins.

Attention, je ne suis pas contre l'utilisation de tels outils, j'en utilise aussi.
Mais je voulais juste "titiller" sur l'objectif que l'on veux attendre avec eux: les outils doivent nous aider dans notre travail, pas guider (voir contraindre) notre façon de travailler.

[Reward]

Merci pour ce tuto bien détaillé mikaelkrief.

Laurent, il ne faut pas voir TFS comme une fin en soi, mais comme un support. Si tu lis le manuel SCRUM, aucun outil n'est recommandé. Cependant des points sont à respectés. 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. D'autres peuvent l'être, comme la possibilité de pouvoir voir à tout moment le backlog, ou le contenu d'un sprint, ou bien encore la capacité à faire du "forecast" basée sur la vélocité de l'équipe.

En cela, TFS est un des outils répondant au besoin.

Après, c'est une suite logique. Si tu utilises Visual Studio, tu utilises probablement TFS pour le contrôle de code source. Si en plus tu as un besoin en Scrum, TFS va permettre de fédérer et d'agréger beaucoup de données, ce qu'un tableau avec des post its ne pourrait pas faire.

Ce n'est pas la meilleure solution, mais c'est une solution qui marche bien, et qui ne doit pas pour autant supprimer tout support papier.

[Laurent 1973]

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.

[Babyneedle]

Bonjour à tous, j'utilise TFS et son module de gestion de projet depuis 5 ans.

Il y avait beaucoup de bugs au tout début. Par exemple, jusqu'à il y a quelques mois, il était impossible d'exclure les weekends du burndown chart.

Avec la dernière version, les choses se sont améliorées mais il reste encore quelques irritants:

- Certain termes ne sont pas les plus usuels en Scrum. Par exemple, on dit des 'effort points' plutôt que des 'story points'. Les 'Epics' s'appellent des 'features'.
- L'historique de la vélocité ne repose que sur les points d'efforts (story points). C'est une approche puriste mais dans la réalité, les administrateurs vont toujours finir par demander combien d'heures réelles ont été passées sur un projet X. Pour y arriver avec TFS, on doit nécessairement accepter d'extrapoler à partir du nombre de points d'efforts ESTIMÉS. En théorie, les points d'efforts devraient être stables. Dans la pratique, pour un projet qui dure plus d'un an, les points en début de projet ne veulent plus dire la même chose souvent. Mais bon. C'est pas la fin du monde.
- Les requêtes et la façon dont les résultats sont affichés sont un peu simplistes. Jira est supérieur à cet égard.

Mais en bref, si votre équipe évolue déjà dans un environnement Microsoft avec des licences avec MSDN, la gestion SCRUM de TFS est déjà incluse et ne nécessite que des investissement de temps minimes afin de faire le setup initial. C'est un excellent choix!

Par contre, il existe des plateformes payantes que j'estime (ce n'est que mon opinion) être plus matures. L'extension Greenhopper de Jira par exemple.

Bonne chance dans l'aventure Agile et Scrum!