Meilleures pratiques lors de l'utilisation de Sharepoint en tant qu'outil de communication Scrum

Question

Actuellement, nos équipes utilisent une combinaison d'un tableau d'affichage et d'une feuille de calcul Excel pour effectuer le suivi des tâches et dessiner un graphique Burndown. Les arriérés sont conservés sur des fiches dans des enveloppes.

Cela fonctionne bien lorsque les parties prenantes sont au même endroit. Cependant, nous aurons bientôt des équipes Scrum dans deux endroits géographiquement éloignés et je cherche des bonnes pratiques sur comment nous pouvons utiliser Sharepoint pour nous aider à communiquer autour des artefacts Scrum (backlog, burndown chart, vélocité, etc.). Comment avez-vous utilisé Sharepoint à cette fin, quelles sont les meilleures pratiques et les pièges potentiels?

Answer 1

avec un utilisateur Je pense qu'il serait assez facile de commencer à l'utiliser pour SCRUM.Je commencerai par ce qui suit:

Une collection de sites pour contenir 1 site scrum par projet

Un site scrum doit contenir:

• bibliothèque de documents pour les fichiers électroniques (ajouter des colonnes pour la catégorisation comme approprié)

• Liste des membres de l'équipe

• Forum de discussion

Le site peut être construit à partir d'un modèle de site Wiki si nécessaire. Une fois que vous obtenez le site de mêlée "se sentir bien", enregistrez-le comme un modèle de sorte qu'il est facile d'en créer un nouveau.

Cette solution peut ne pas être conçue pour SCRUM au nième degré, mais elle devrait être suffisante pour vous aider à démarrer. Cela semble beaucoup plus facile que d'apprendre à l'ensemble de l'équipe un nouvel outil quand il semble que vous subissez d'autres changements assez radicaux.

mon 0,02 $

jt

Answer 2

Vous devriez vraiment considérer quelque chose comme Trello, VersionOne, Rally, ou même Basecamp pour cela. Ils ont tous hébergé des solutions et offrent des versions communautaires gratuites que vous pouvez essayer pour commencer. Mon expérience avec SharePoint est qu'il faut beaucoup de ressources à maintenir. Si vous utilisiez Team System et que vous disposiez de beaucoup d'éléments prédéfinis pour vous, cela pourrait être différent - même si j'ai Team System et que vous choisissez toujours d'utiliser un wiki pour mes tâches de gestion de projet. Si vous avez déjà investi dans SharePoint en tant qu'intranet et tout le personnel de support, alors cela pourrait être une solution viable dans ce cas également.

SharePoint n'est pas l'outil que je pense d'abord pour le développement agile. YMMV.

Answer 3

AFAIK, Sharepoint est ASP.net avec des goodies gratuits. Il n'est pas conçu pour la gestion de projet agile. Vous devez donc lancer votre propre site.
IMHO au lieu d'essayer de plier le travail à l'outil que vous avez .. passer à un meilleur outil pour le travail serait une meilleure option. Vérifiez this thread pour voir s'il y a quelque chose de plus léger qui correspond à votre facture.

Personnellement, je suis un grand fan de ne pas numériser les activités de développement .. Donc, je voudrais utiliser une feuille de calcul pour le carnet de commandes et afficher ses tableaux et Big Visible. Utilisez un appareil photo numérique pour conserver les instantanés de discussion de diagramme/conception (photo de tableau blanc de Google pour les outils) ou pour les rapports. Je trouve que la plupart des outils de «gestion de projet» ne sont que des excuses pour générer des mises à jour de statut instantanées. Cela entrave le développement de logiciels (qui est l'objectif principal) et inhibe trop souvent les interactions sociales.

: Si vous avez SharePoint dans la maison déjà, (disclaimer absolument 0 expérience avec sharepoint .. sauf que je l'ai lu dans les 2 derniers jours peut donc être totalement hors piste)

Answer 4

Nous utilisons en fait Sharepoint pour notre développement Agile et nous avons trouvé cela fonctionne assez bien pour la gestion/projet de collaboration.
Nous avons fait deux choses que j'ai trouvées particulièrement utiles, le suivi des mesures et les tests automatisés. Nous utilisons la bibliothèque de documents et infopath pour ajouter toutes nos histoires pour le projet sur le site. Le formulaire Infopath doit contenir toutes les informations dont vous avez besoin pour une histoire: points, temps estimé, développeur, testeur, tâches d'histoire, cas de test. Pour les métriques, nous créons des composants Web pour: graver des graphiques, vitesse, points par itération, etc. Cela est particulièrement agréable pour les gestionnaires ou les clients de voir les progrès réalisés sur le projet et les aidera à prendre des décisions concernant caractéristiques vs temps de libération. Pour les tests, nous avons un langage SEND-RECV-ASSERT simple qui exécute les tests tous les soirs en extrayant le XML pour les tests automatisés. Nous avons un petit webpart vert/rouge sur la page principale qui vous indique l'état des tests.
Cela peut être fait simplement avec un peu d'analyse XML puisque le backend de la bibliothèque de documents est XML. (Nous utilisons actuellement un simple ActiveX et javascript)

Les métriques sont assez faciles à configurer (juste un peu d'analyse XML et de graphiques html). Les tests automatisés prennent un certain temps pour mettre en place un testeur, mais une fois qu'il est en place, et assez facile, vous pouvez même demander aux clients/gestionnaires d'écrire des tests d'acceptation! Agile! :)

Answer 5

Vous devez essayer d'éviter que l'outil ne vous empêche de travailler. Dans un monde idéal, l'équipe sera assise dans une seule pièce avec de grands tableaux blancs, mais souvent ce n'est pas le cas et les équipes sont distribuées, ou il y a une poussée pour une forme de sauvegarde pour le post-it.

Je suis un grand fan de SharePoint et vous l'avez déjà en interne, vous faites déjà de la collaboration et travaillez en équipe sur la plateforme. L'ajout d'un autre outil, avec des identifiants uniques, peut fonctionner mais l'équipe doit vraiment vouloir les utiliser.

J'ai essayé de faire sortir SharePoint de la boîte pour faire ce que je voulais, mais ça n'a pas fonctionné. J'ai essayé d'utiliser Version One (à plusieurs reprises au cours de nombreuses années, avec beaucoup d'équipes) mais je trouve que l'outil est trop, il y a trop d'otpions et il y a des choses qui doivent être faites. est loin du tableau blanc. J'ai donc décidé de développer ce dont j'avais besoin pour mes projets. J'avais besoin d'un outil simple, et en utilisant l'approche 37signals (créateurs de basecamp) j'avais besoin de quelque chose avec moins de fonctionnalités que la concurrence.

21Scrum est un outil de scrum simple construit sur SharePoint qui utilise la plate-forme, ajouter les choses dont vous avez besoin (tableau blanc, graphiques burndown) et vous laisser pour aller de l'avant avec le projet. Peut-être que c'est peut-être la meilleure option pour les personnes qui ont déjà et utilisent SharePoint - du moins c'est le but.

Answer 6

Nous avons configuré un espace de travail SharePoint avec des listes pour la planification Release/Sprint, Product Backlog et Sprint Backlog.

L'élément central est ce tableau de tâches pour SharePoint - nous pouvons faire glisser & des histoires et des tâches - même si nous ne sommes pas au même endroit. http://www.youtube.com/watch?v=XW89M0C3N7Q

Un rapport de burndown visualise automatiquement la progression.

Fonctionne bien!