Est-ce que quelqu'un utilise Scrum & Sprint pour Infrastructure. Je suis aux prises avec le concept d'un Sprint qui ne finit jamais, c'est-à-dire un projet d'amélioration du réseau.Meilleure façon d'utiliser Scrum et Sprint pour améliorer l'infrastructure
Aussi des suggestions sur la façon dont le temps de l'article peut être construit à un retard de produit, de sorte que je puisse vérifier que les ressources ne sont pas sur-acceptées sur le sprint.
Je suggère que vous pourriez commencer par rafraîchir votre mémoire sur l'ensemble du concept de Scrum (http://en.wikipedia.org/wiki/Scrum pourrait être un bon point de départ).
Par exemple, je ne crois pas qu'il devrait y avoir un 'sprint final'. Si vous avez une tâche très longue et/ou récurrente, divisez-la en tâches plus spécifiques. L'amélioration du réseau est très générique - le décomposer à:
Estimez-les et placez-les dans votre carnet de commandes.
etc.
Ensuite, planifiez court (1-2) la semaine sprints ou itérations. Assignez un objectif spécifique à chacun d'entre eux. Ajoutez certaines de vos tâches du backlog à l'itération. Complète le.
Examinez les résultats, ajustez le processus, répétez.
Donc, mon actualisation du réseau est le backlog et je le divise en éléments pour le sprint. Évident maintenant :-) –
Un sprint qui ne finit jamais n'est pas un sprint ... c'est une carrière. JK. Assurez-vous d'avoir des sous-objectifs clairement définis si un objectif majeur n'est pas accessible et/ou change constamment. Estimez les heures de travail pour chaque tâche et divisez-la en sous-tâches si ces heures sont supérieures à une demi-journée environ (règle très vague). Suivre le temps (ne doit pas être précis - peut être connecté à la réunion debout ou à travers votre système de gestion de projet ou système de billetterie) et de comparer aux tâches. Vous trouverez quelques tâches qui sont similaires dans la fonction et le temps à remplir. Utilisez-les comme prototypes pour le prochain sprint et continuez de l'améliorer jusqu'à ce que vous obteniez de plus en plus sur la marque.
Une fois que vous avez une bonne idée de cela, revisitez votre backlog, attribuez un temps estimé et commencez à définir des objectifs solides (constitués de sous-tâches discrètes bien définies), des objectifs extensibles et des objectifs distants pour votre sprint. Les objectifs solides doivent être bien à la portée de votre équipe (pas plus de 60% de vos objectifs estimés que vous pouvez accomplir et généralement moins), les objectifs doivent être de ce point à ce que vous estimez pouvoir accomplir (à 100% d'efficacité) objectifs que vous devriez avoir sur votre radar au cas où vous avez un peu de chance fantastique ce sprint. Tous les jours, passez en revue et organisez votre burn-down au stand up, et ré-éveillez vos objectifs pour ce sprint. S'il y a des changements imprévisibles dans vos estimations, notez pourquoi, et si elles sont systématiques, revisitez vos tâches et votre temps estimé et réajustez pour que votre prochaine estimation soit meilleure. C'est beaucoup de travail au début et il faut beaucoup de discipline mais les gains après quelques mois sont énormes. Gardez juste ancré dans la stricte réalité. Bonne chance!
Avoir brisé le projet pour faire un peu de planification. Y a-t-il quelque chose de plus agile qui serait approprié? –
Scrum est une méthode de gestion de projet, elle n'est pas spécifiquement destinée au développement de logiciels; donc il peut être utilisé pour le projet d'amélioration du réseau.Vous avez dit que vous vous battez avec "sprint qui ne finit jamais", ce n'est pas Scrum. Sprint sont timeboxed, ils finissent à l'heure, période. Maintenant, si l'équipe a été sur-engagée pour le sprint, ou si certaines tâches ont été sous-estimées, et qu'il y a des éléments de backlog qui ne sont pas "terminés", ils sont supprimés du résultat du sprint et peuvent être poursuivis dans le sprint. prochain sprint.
Il y a plusieurs choses que vous pouvez faire pour prévenir overcommitement:
Si le projet d'amélioration du réseau ne se termine jamais, je suppose qu'il est parce que les nouveaux besoins sont identifiés. Ajoutez-les dans votre carnet de commandes, hiérarchisez-les, estimez-les, ils seront éventuellement programmés dans un sprint.
J'aime le lien. Je vais essayer cela dans l'équipe et voir où nous allons avec. –
Vous pourriez regarder dans Kanban. Vous avez toujours un backlog, mais au lieu de timeboxing, il impose des limites WIP tout au long d'un flux de processus. Je recommande toujours d'utiliser le plan de communication Scrum w/standups et rétrospectives régulières et démos si approprié. Les réunions de planification sont un peu différentes en ce sens que vous ne vous engagez réellement à aucun travail, mais vous pouvez toujours utiliser des histoires et des points d'histoire (les limites de WIP peuvent être sur des points d'histoire). Si vous vous réunissez toutes les deux semaines, je ferais en sorte que vous ayez 2,5 ou 3 semaines de travail en attente (bien qu'un avantage de Kanban soit que vous puissiez toujours ajouter la prochaine grande chose en haut de la file sans avoir à attendre la prochaine sprint). J'aime aussi le fait que vous pouvez avoir des couloirs représentant leurs différents clients car l'infrastructure travaille souvent sur les tickets de support des utilisateurs finaux et supporte plusieurs projets en plus de leur propre travail au jour le jour.
En cascade, vous construisez et relâchez tous en même temps. Dans Scrum, vous construisez et libérez périodiquement, en courts sprints. Avec Kanban, vous gardez juste l'eau qui coule.
Google Infra-gile pour en savoir plus.
Cette question est hors-sujet car elle ne fait pas partie des questions appropriées pour ce site, comme défini dans [Quels sujets puis-je poser à propos ici?] (// stackoverflow.com/help/on-topic) Please voir aussi: [Quels types de questions dois-je éviter de poser?] (// stackoverflow.com/help/dont-ask) Vous pouvez obtenir de l'aide sur [un autre site Stack Exchange] (// stackexchange.com/sites# name), par exemple [pm.se] ou [softwareengineering.se]. – Makyen