Question

Je souhaite éventuellement utiliser Scrum avec mon équipe de développement (oui, je sais que ce sera un peu pénible d'y passer).Cependant, nous n'avons pas Team System et nous ne pouvons probablement pas nous permettre de l'obtenir immédiatement.

Quels sont les outils possibles pour qu'une équipe soit opérationnelle sur Scrum dans un environnement .NET/Visual Studio sans Team System ?

Était-ce utile?

La solution

En réalité, tout ce dont vous avez besoin est un logiciel de suivi des bogues pour suivre les problèmes brûlants du sprint en cours.Il peut même s'agir d'une feuille de calcul (n'utilisez pas de feuille de calcul).SCRUM est une méthodologie, http://en.wikipedia.org/wiki/Scrum_(development) et ne nécessite pas vraiment un système d'équipe, mais plutôt un bon chef de projet et une équipe engagée.

Autres conseils

prends un tableau blanc

démarrer avec SCRUM ne devrait nécessiter aucun outil - au minimum, vous aurez une réunion de planification au début de chaque sprint, une réunion debout quotidienne et une réunion de récapitulation à la fin de chaque sprint.

Lors de la réunion quotidienne, rassemblez-vous autour du tableau blanc et utilisez-le pour suivre l'état des tâches de chacun et votre progression pour le sprint.

Vous devrez également suivre votre retard pour la planification – cela peut être fait sur papier, sur un tableau blanc ou dans Excel.

J'étais impliqué dans une équipe Scrum dans ma dernière entreprise, et cela n'a vraiment rien à voir avec l'environnement de développement.Il s'agit d'un processus de développement de logiciels, et il existe souvent peu de technologie pour utiliser le processus lui-même (même si un bon tableur aidera à suivre les progrès).

Donc...Je dirais que vos inquiétudes concernant les outils sont peut-être déplacées, à moins que je ne comprenne mal la question.

  • Contrôle des sources : Subversion
  • Application d'intégration continue : Hudson (il existe beaucoup de plugins .NET), plus facile à utiliser que CruiseControlDotNet
  • Outil de construction :MSBuild – vous souhaiterez personnaliser le processus de génération, et apprendre MSBuild est le meilleur moyen de le faire
  • Cadre de tests unitaires :l'incomparable NUnité
  • Analyse de code statique : NDépend, FxCop, d'autres ?

Remarque connexe : SVNStats - un projet Java qui crée des rapports plutôt sympas sur ce qui s'est passé dans un référentiel au fil du temps, vous donne de jolies métriques de désabonnement au code

MSBuild est donc le ciment avec lequel vous lancerez ces outils à différentes étapes de développement, ou vous pouvez ajouter des hooks dans les événements qui se produisent avec le référentiel de code source.Il s'agit d'une liste approximative d'outils/applications qui vous donnent un aperçu des fonctionnalités fournies par Team System.

Ce qui est bien avec cette liste : à l’exception de NDepend, tous sont gratuits pour un usage commercial et privé.

@Jason et @Mike_Stone ont raison.Scrum n'implique aucun outil autre qu'un morceau de papier et un stylo au strict minimum.Scrum se concentre beaucoup moins sur les outils utilisés par les équipes que sur la manière dont l'équipe communique et travaille ensemble et avec ses parties prenantes pour prioriser et s'adapter au changement.

XP, d'un autre côté, est beaucoup plus orienté vers les outils et les développeurs, préconisant des choses telles que l'intégration continue, le développement piloté par les tests, la programmation en binôme, etc.

Les méthodologies agiles sont très indépendantes des outils et sont très pragmatiques en ce sens.Utilisez ce qui vous convient le mieux.Vous n'avez pas besoin de l'outil a ou de la bibliothèque b pour être agile.

Utilisez Excel pour créer un joli burndown chart !

Pour le suivi des éléments de travail, créez une application Web rapide pour les enregistrer, puis exportez les données vers Excel et gérez-les.

Je suis d'accord.Team System n’est qu’un ensemble d’outils intégrés dans un IDE.Visual Studio utilise MSBUILD par défaut, NUnit et tout autre plugin sélectionné.La seule vraie valeur réside dans les plugins de méthodologie comme celui de Conchango, qui permettent de hiérarchiser et d'attribuer les éléments de travail, ainsi que les rapports générés par la suite.

Les mêlées quotidiennes, le tableau blanc, Excel et la discipline sont un très bon début.

Tout à fait d'accord sur les commentaires concernant Excel.Il vaut mieux commencer de cette façon.Scrum peut être un peu un choc culturel si vous venez d'une méthodologie en cascade.S'assurer que votre équipe comprend d'abord la philosophie est bien plus important que les outils que vous choisissez pour la rendre plus efficace.

Scrum semble fonctionner mieux lorsque vous disposez d'éléments tangibles (un pense-bête, un morceau de papier) représentant un atout que vous construisez.C'est simple, direct et tout le monde peut s'y retrouver.Parfois, votre intention, ou les éléments de travail eux-mêmes, sont perdus ou mal interprétés lorsque toutes vos tâches sont abstraites en les stockant quelque part dans une base de données, en particulier si l'équipe est nouvelle dans Scrum.

En ce moment, mon équipe utilise Scrum avec Team System.C'est génial car nous obtenons gratuitement des rapports de gestion et d'équipe.Cependant, et c'est la chose importante, je pense que nous avons fait les choses plus rapidement et avec une meilleure qualité lorsque nous avons tout fait avec un tableau en liège à l'ancienne, Excel et ce modèle (j'adore ce truc, je le recommande à tous ceux qui font Scrum) :

http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html

Vous pouvez utiliser XPlanner pour gérer les ressources, gérer et surveiller les estimations.Vous pouvez consulter la durée estimée dans le passé pour les planifications futures.

Aussi avec .NET Reportez-vous:http://www.scrumforteamsystem.com/en/default.aspx

Comme d'autres l'ont mentionné, SCRUM peut être réalisé sans aucun outil spécifique, mais je vais lancer la pile Atlassian.Je les ai déjà utilisés et je les ai beaucoup aimés :

http://www.atlassian.com

  • JIRA pour le suivi des problèmes/le backlog
  • Plugin GreenHopper vers JIRA pour des googies Agile complets
  • Fisheye/Crucible pour l'examen par les pairs en ligne
  • Confluence pour la collaboration et le partage des connaissances
  • Bamboo pour une intégration continue

Dans le passé, j'ai réalisé des projets Scrum dans TFS avec Visual Studio 2005-2008 et j'en étais très satisfait.Je travaille actuellement sur un projet Scrum dans un environnement Linux utilisant Eclipse ce qui a nécessité un passage vers un autre système.Nous avons choisi Concert d'équipe rationnelle (RTC) et je trouve que cela répond bien à nos besoins.

J'ai trouvé que RTC était comparable à TFS, tant en termes de fonctionnalités que de concepts (ex.RTC utilise la même terminologie d'élément de travail), la transition a donc été assez simple.Il existe un plugin pour l'intégration de Visual Studio IDE ainsi qu'une interface Web qui fournit des graphiques d'avancement et d'autres mesures de progression pour les équipes de projet.Il est gratuit pour un maximum de 10 développeurs, il convient donc vraiment aux petites équipes.Je ne suis pas sûr du modèle de tarification une fois que vous devez payer, mais je suppose qu'il est comparable à TFS s'il est conforme aux autres offres IBM Rational.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top