Comment nommez-vous les sprints dans vos projets?
Certains outils de gestion du logiciel Scrum vous offrent cette option pour nommer explicitement vos sprints.
Avez-vous une façon préférée de nommer vos sprints ou utilisez-vous simplement un schéma simple comme 1, 2, 3, ...?
Demandez à l'équipe .
S'ils pensent qu'il est amusant ou utile de nommer le sprint, choisissez-en un ensemble.
Puisque chaque sprint devrait avoir un objectif, il ne devrait pas être difficile de trouver un nom approprié.
Nommer le sprint pourrait réellement aider l'équipe à se concentrer sur l'objectif principal.
J'aimerais personnellement ce genre de chose.
Après un certain temps à y penser, je suis venu avec la convention suivante:
<year> CW <starting calendar week> - <ending calendar week>: <goal> (<version>)
La version est facultative.
Vous vous retrouvez donc avec quelque chose comme:
2013 CW 27-28: Improved reporting and dashboards (v1.5.1)
2013 CW 29-30: Redesigned gadgets (v1.5.2)
...
Cette syntaxe répond aux questions:
- Quand a-t-il été fait?
- Pourquoi cela at-il été fait?
- Sous quelle version est-il sorti?
Et aussi:
- Il est triable
- C'est prévisible
- Permet la flexibilité sans sacrifier les informations
Dans une entreprise où je travaillais, nous avions des sprints/sorties mensuels, et nous les avons nommés alphabétiquement d'après les mèmes Internet. Les versions sur lesquelles j'ai travaillé récemment étaient:
- clavier
- lol chat
- megashark
- numanuma
Cela a ajouté un peu de plaisir au processus, surtout quand vient le temps de nommer la prochaine itération.
Si le tout est dans un but précis ("ajouter des rapports", "apporter des sites européens"), alors il y a votre nom. Si c'est une collection de choses de l'arriéré, alors une date vague ("la version de juin") fonctionne pour nous. Cela nous permet de dire à un utilisateur "Je ne pense pas que cela conviendra à la version de juin, est-ce correct de le mettre dans la prochaine?" ou "si vous le souhaitez dans la version de juin, nous devrons régler [quoi que ce soit] d'ici le 5 juin". Ce ne sont que des étiquettes, mais elles servent à quelque chose.
Pour nous, nous aimons mettre des noms amusants, en interne de toute façon, à nos sorties numérotées et à nos projets plus grands pour briser un peu la monotonie. Nous recherchons toujours des noms plus drôles/plus créatifs pour nos projets et sorties plus importants, mais nous utilisons également évidemment un système de numérotation traditionnel (1.0, 1.1) ou basé sur la date pour garder une trace du point de vue du code, notre meilleur à ce jour étant les rappeurs de la vieille école. Personne ne dit que le développement de la mêlée ne peut pas être un peu drôle
Ex. Beastie Boys, Coolio, DJ Jazzy Jeff, Eazy-E, Flavour Flav, Etc.
Dans mon équipe, les sprints ont tendance à être nommés d'après la version de sortie de production que nous préparons. Dans le cas d'une version de production qui s'étend sur plusieurs sprints, nous ajoutons le numéro d'itération. Ainsi, par exemple,
- 5.0.2 Itération 1
- 5.0.2 Itération 2
- 4.16.1
etc.
Rendez-vous!
Notre processus utilise une branche de publication pour chaque sprint que nous faisons, de sorte que les noms des branches de sprint et de publication s'alignent. Nous utilisons la date de sortie prévue comme nom de la branche et du sprint.
Cela rend la compréhension de l'histoire un peu plus facile en même temps - par exemple si vous consultez un ancien e-mail concernant un bogue que vous pensiez avoir été corrigé, en fonction de la date de l'e-mail, vous pouvez facilement accéder au (x) nom (s) de branche le (s) plus proche (s) pour avoir une meilleure idée du changement. (Bien sûr, vous devriez également espérer que cela soit suivi dans votre traqueur de bogues /, mais nous savons tous que ce n'est pas toujours le cas.)
Il est également très agréable que toute notre équipe sache toujours exactement quel est le nom, donc nous sommes toujours sur la même longueur d'onde lorsque nous parlons d'un sprint ou d'une branche. (Il n'y a jamais de confusion de "Est-ce que le blaireau est sorti cette semaine ou la semaine dernière?".)
À mon avis, l'utilisation de chiffres pour le nom n'apporte pas vraiment de valeur. D'ailleurs, bien que cela puisse être amusant à faire, les noms abstraits non plus. L'utilisation de noms axés sur les objectifs peut être un ajout intéressant (par exemple, "2012-04-03: widgets clients mis à jour"), mais je ne reviendrais pas uniquement à l'utilisation de noms abstraits.
Pour chaque version, nous choisissons un nom de code de grande ville par ordre alphabétique (par exemple A tlanta, B oston, C hicago, D allas ...)
Et certains noms de collège dans cette ville deviennent nos noms de sprint (Morehouse, Spelman, ..., Harvard, Cambridge, etc.)
Je n'ai jamais vraiment pensé à les nommer. Nous avons généralement joint un ID de build à la fin afin que nous puissions suivre les problèmes, mais le nommage ne fait vraiment pas partie du processus. Avec des sorties toutes les deux semaines, vous graveriez 26 noms par an.
Je suppose que cela en ferait une partie amusante de la planification du sprint. Je devrais peut-être l'essayer pour notre prochain sprint.