Sharepoint pour le backlog

Avec l'utilisation des listes

Un backlog de produit peut se concrétiser sous différentes formes. Dans les différents projets auxquels j'ai participé, j'ai utilisé :

  • des fiches bristol épinglées sur un tableau
  • une feuille de calcul d'un tableur OpenOffice ou Excel
  • une feuille de calcul partagée avec GoogleDocs, ce qui est déjà beaucoup mieux qu'un simple tableur
  • un outil dédié, IceScrum bien sûr, ce qui est encore mieux

Mon client actuel utilise SharePoint pour les sites d'équipe, c'est à dire que SharePoint sert de référentiel pour tous les documents produits pendant le développement. Comme toute l'équipe n'est pas dans le même bâtiment, la solution de fiches pour le backlog de produit n'est pas suffisante. Et pas question d'utiliser GoogleDocs ou IceScrum pour le moment.

J'ai donc commencé par élaborer le backlog de produit avec Excel, le fichier produit étant mis dans un dossier du site d'équipe. Puis j'ai découvert la gestion des listes avec SharePoint. On peut créer facilement ses propres listes en définissant les attributs (colonnes) souhaités. Et un backlog n'est rien d'autre qu'une liste de éléments (une liste de user stories). L'avantage par rapport à une feuille de calcul Excel est que la liste est visible sur le portail sans qu'il soit nécessaire d'ouvrir un fichier. Cela facilite grandement le travail collaboratif. De plus SharePoint offre des facilités pour gérer les listes : on peut trier très facilement sur n'importe quelle colonne et surtout créer des vues qui ne montrent que l'information souhaitée.

Pour le backlog de produit, j'ai défini les colonnes suivantes pour chaque élément :

C'est déjà pas mal et on peut facilement adapter la liste en modifiant les valeurs possibles pour chaque champ, en définissant ce qui est obligatoire et ce qui est optionnel ou en ajoutant une nouvelle colonne.

J'ai créé des vues pour montrer la liste des éléments dans chaque état : ce qui est fini, ce qui est en cours, ce qui reste à estimer... On peut demander à SharePoint d'afficher le total des éléments présents dans chaque vue, ce qui facilite les mesures faites à la fin de chaque sprint.

Finalement, SharePoint pour le backlog de produit c'est pas si mal[1]. J'utilise aussi ces listes personnalisables pour la liste des problèmes et pour la gestion des risques. Pour le backlog de sprint nous préférons la solution des notes collantes affichées au mur, c'est plus adapté à une gestion au quotidien.

Notes

[1] mais ce n'est pas l'idéal, notamment pour la gestion des priorités, pour la production des burndown charts... et ce n'est pas du tout Web2.0 comme IceScrum

Commentaires

1. Le vendredi 25 janvier 2008, 19:24 par Oaz

De plus, si on utilise Sharepoint, c'est que l'on a une forte probabilité d'être en "environnement Microsoft" et, alors, l'utilisation de Team Foundation Server (qui propose automatiquement un portail Sharepoint pour chaque projet) offre des possibilités d'un autre niveau pour la gestion des backlogs de release et de sprint.
Par exemple, la gestion des fiches de tache est intégrée à l'environnement de développement (Visual Studio). Les développeurs peuvent donc les mettre à jour au fil de l'eau. Ces fiches, ainsi que le burndown chart de sprint correspondant (un rapport SQL server) sont accessibles sur le portail Sharepoint.

2. Le dimanche 03 février 2008, 19:27 par claude aubry

C'est de base ou cela nécessite d'avoir un plugin VSTS ? Je sais qu'il y en au moins 2 pour Scrum, celui de Conchango qui existe depuis 2 ans et eScrum qui date de juin.