Je sais que cette question est idiote mais je veux juste m'assurer.Est-ce qu'une itération dans Scrum équivaut à une balise sous SCM?
Est-ce que chaque itération (la fin de chaque sprint) dans Scrum équivaut à une balise sous-say- Subversion?
Merci pour votre aide et votre temps.
Non, un sprint/itération est une période de temps fixe, et il n'y a pas de correspondance 1: 1 de telles quantités de temps avec des balises (ou branches, & c) dans n'importe quel système de contrôle de version que vous préférez. L'utilisation de tags dans svn & friends est plus une question d'ingénierie de version (pour la plupart des ateliers de développement SW, au moins) que de processus de développement en soi.
Bien sûr, rien n'empêche votre équipe spécifique de décider que chaque libérables incrément obtenu à la fin d'un sprint doit être en quelque sorte marqué, mais si vous avez réservé des tags pour seulement cette fin, vous êtes crampe votre ingénierie de libération processus inutilement.
Non, mais cela ne veut pas dire qu'ils ne sont pas liés.
Une étiquette correspond à une construction de votre système de construction. Vous pourriez utiliser un numéro de version sur l'étiquette qui équivaut à une itération - disons que vous numérotez vos versions avec un numéro de version majeur, et que vous utilisez un numéro de version «mineur» qui correspond à l'itération dans laquelle vous vous trouvez. être à l'itération "1.2", et chaque balise dans SVN commencerait par un 1.2. Peut-être que le troisième numéro est un numéro de build. C'est à vous de choisir les détails, mais vous aurez probablement plusieurs générations par itération - 1.2.1, 1.2.2., 1.2.3, et ainsi de suite ...
Je pense qu'il est plus probable que pour chaque sprint, l'équipe de développement travaille dans une branche de subversion spécifique, qui est fusionnée avec le tronc à la fin du sprint et une nouvelle branche créée pour la prochaine. De cette façon, le tronc reste toujours "propre" avec le travail du sprint précédent, ce qui vous permet de couper rapidement une nouvelle version avec un correctif si une urgence survient.
Vous pouvez également effectuer des corrections de bogues dans le sens inverse, en particulier lorsque vous faites de la révision svn une partie du numéro de version. De cette façon, vous pouvez créer une branche de maintenance lorsque vous en avez besoin, et économiser des frais supplémentaires de branchement et de fusion à chaque fois au lieu de simplement quand il y a des problèmes –
Vous devez créer une étiquette si vous décidez de la relâcher.
À la fin d'une itération de mêlée, vous avez un produit potentiellement expédiable. Cela ne signifie pas que vous devriez libérer.
Scrum ne dit rien sur l'utilisation d'un système de contrôle de version par l'équipe - en fait, Scrum ne dit rien sur les pratiques techniques. Scrum dit simplement que l'équipe doit fournir un "incrément de produit livrable" à chaque sprint - c'est une version du produit qui est entièrement intégrée et répond à la définition de DONE.
Maintenant, du point de vue pratique, il est tout à fait logique que vous souhaitiez marquer dans le référentiel les jalons qui représentent le produit de chaque sprint. Oui, vous pouvez le faire avec des tags et c'est assez intuitif - c'est comme ça que nous l'avons fait dans notre équipe quand nous utilisions encore SVN - mais vous pourriez aussi le faire différemment, je suppose. Je pense que tout dépend de votre situation particulière et je laisserai à l'équipe le soin de comprendre celle-ci. Tant qu'ils peuvent produire de manière fiable la source pour le produit de chaque sprint de quelque manière qu'ils le réalisent, c'est bien.
Nous désignons un «tag» comme étant notre produit de sprint à utiliser lors de la réunion de révision de sprint, mais ce n'est jamais le seul tag que nous créons au cours du sprint. Nous créons un tag au fur et à mesure que nous avons du code qui peut être testé après intégration dans notre "trunk/master".
Je vote pour clore cette question hors-sujet parce qu'il ne s'agit pas de programmation. –
Je vote pour clore cette question hors-sujet car [la gestion de projet est désormais hors-sujet sur Stack Overflow] (// meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website -to-ask-about-project-management-issues/343841 # 343841). Posez ces questions sur [SoftwareEngineering.SE] (// softwareengineering.stackexchange.com/) et [ProjectManagement.SE] (// pm.stackexchange.com/) à la place. (Vous pouvez également signaler l'intervention du modérateur pour faire migrer cette question.) – robinCTS