Nos rôles ne sont pas purement le développement de produits. Nous fournissons également un «support de première ligne» aux clients externes internes, et l'une de ces tâches, de par leur nature même, annulera toujours les priorités de développement de produits. Comment utiliser les sprints de SCRUM pour nous aider à gérer les problèmes de développement et de support des produits?Utilisez SCRUM lorsque les membres de l'équipe jonglent avec différents rôles?
Vous pouvez jeter un oeil à Kanban ou Scrum-ban. Je ne suis pas un fan mais cela peut fonctionner mieux pour votre scénario où les distractions et les interruptions peuvent être inévitables. Fossé le sprint tout en conservant un backlog prioritaire. Plutôt que de suivre et de mesurer la vitesse du ressort, mesurez la latence dans chaque phase.
http://leansoftwareengineering.com/ksse/scrum-ban/
Je vous recommande de prendre un pas en arrière bien. Si vous voulez être une équipe agile efficace, vous avez besoin de la direction de buy-off ... pourquoi l'équipe de développement fait-elle le support de premier niveau? Avez-vous un scrummaster fort qui est capable d'isoler l'équipe des clients internes gênants? Je ne sais pas quel est votre volume de soutien, mais je jouerais avec la rotation des membres de votre équipe dans une situation où ils prennent tout le soutien/client interne pendant une semaine à la fois, permettant aux autres membres de se concentrer. Dans tous les cas, choisissez un brouilleur ... tournez les membres de l'équipe dans cette position jusqu'à ce que vous trouviez la bonne personne pour le travail.
Une raison à cela peut être que l'entreprise ou IT dept. est trop petit pour avoir des équipes de soutien dédiées et séparées du développement. – Andy
@Andy ... aucun doute. C'est juste une question qui mérite d'être posée. (IT ou Customer Support) et Engineering n'ont pas beaucoup de chevauchement de compétences donc c'est bizarre de voir les deux (ou trois) groupés. Je pense que lorsque vous le faites, c'est souvent une décision de gestion que vous devez remettre en question ... en prenant la parole ou en votant avec vos pieds et en trouvant une meilleure entreprise pour laquelle travailler. – Trey
Bonjour je suppose que c'est facile à dire et un peu compliqué au début.
Incite chaque membre de votre équipe à se familiariser avec les rôles qui existent dans votre équipe, par exemple dans mon entreprise nous utilisons environ 1 mois pour l'itération puis nous faisons une rotation.
Aussi, je pense que vous devriez mélanger SCRUM et d'autres techniques de développement de logiciels.
Sultan
"Aussi je pense que vous devriez mélanger SCRUM et d'autres techniques de développement de logiciels". Vous ne savez * rien * sur leur lieu de travail, alors comment pouvez-vous offrir ce conseil? J'ai personnellement eu des expériences extrêmement horribles avec des équipes essayant de confisquer SCRUM dans un modèle de cascade existant. @Fairy Bower: Soyez très conscient que le refus de prendre en compte les besoins de la situation spécifique * va coûter de l'argent, brûler les gens, et finalement faire échouer votre entreprise. –
Fairy Bower: Ce qui ne veut pas dire que les techniques de mixage sont une mauvaise solution non plus.C'est juste que nous vous connaissons à peine, sans parler de votre équipe de développement, alors comment pourrions-nous savoir quelle est la bonne solution pour votre problème? –
Avant d'aborder la question des sprints, je pense qu'il est important de savoir si votre équipe s'est organisée autour des rôles Scrum.
Le Product Owner et ScrumMaster doivent être deux personnes différentes. Ces rôles ont-ils été définis dans votre unité? Si non, je recommanderais de considérer qui devrait remplir ces emplacements.
Quoi qu'il en soit, je pense qu'il vaut mieux commencer petit, choisir quelques projets et piloter le processus. Apprends de tes erreurs. Voyez ce qui fonctionne et ce qui ne fonctionne pas.
Puisque vous savez que d'autres travaux peuvent avoir préséance sur les activités planifiées. Essayez de terminer les sprints par intervalles de 4 semaines pendant quelques mois. Itérer, réfléchir et ajuster au fur et à mesure.
Enfin, faites participer vos clients, invitez-les à vos commentaires de sprint. Vous obtiendrez de super commentaires et votre produit s'améliorera plus rapidement.
Promesse moins. Lorsque vous planifiez des sprints, spécifiez une vélocité minimale probable. Vous pouvez toujours retirer des articles du carnet de commandes si votre disponibilité augmente.
Si votre ressource disponible est très variable d'un sprint à l'autre, envisagez de passer à Kanban, comme d'autres l'ont suggéré.
Mon équipe est également dans cette situation. Nous avons beaucoup de travail de développement continu, mais aussi un peu de soutien. Et, nous soutenons les services de production, donc s'il y a un problème, nous pourrions avoir besoin de tout laisser tomber et de le réparer.
Nous avons opté, jusqu'ici, pour continuer à utiliser la mêlée comme auparavant, mais en réservant un certain temps chaque sprint pour les billets en cours et d'autres travaux non connus à l'avance. Chaque jour, il y a une personne dédiée pour traiter les tickets entrants, les notifications Nagios, etc. En cas de besoin, cette personne peut toujours consulter ou remettre des choses à un autre ingénieur - mais nous essayons d'éviter cela. Cela réduit la perturbation dans le flux d'autres ingénieurs.
Planification du temps réservé peut sembler très difficile: la charge de support a tendance à varier. Cependant, notre expérience est que la plupart du temps, notre temps réservé est dans la bonne gamme. Il y a évidemment des exceptions, où nous perdons plusieurs jours de travail supplémentaires, mais dans le pire des cas, nous laissons tomber des objets du sprint. Je ne me souviens pas de la dernière fois que cela s'est passé.
En résumé: la charge de support est la plupart du temps prévisible. Réservez du temps dans le sprint pour cela, et ça devrait marcher. Mais, le conseil le plus important que je peux donner est: essayez quelque chose, même si vous n'êtes pas sûr que c'est la bonne chose, et regardez en arrière dans votre rétrospective. Vous savez seulement avec certitude une fois que vous avez essayé et réfléchi.
Je suis d'accord avec Trey. Vous pourriez envisager Kanban ou Scrumban. Mais que faites-vous lorsque vous êtes une véritable équipe de développement et que vous ne pouvez pas suivre Kanban pour une raison organisationnelle étrange? J'étais un Scrum Master d'une équipe qui était dans une situation similaire à celle de vous. Maintenant, permettez-moi d'être clair, quand vous dites "1ère ligne", est-ce que les utilisateurs contactent directement le propriétaire de votre produit ou votre équipe? Si oui, je pense juste qu'il doit y avoir une autre équipe Scrum qui pourrait gérer cela.
Nous avions une équipe Scrum de soutien aux opérations qui faisait habituellement cela. Notez que cette équipe peut également effectuer des activités de lancement et de déploiement. Demandez également à un membre différent de l'équipe Scrum de développement de se joindre à l'équipe Scrum de soutien aux opérations à chaque Sprint pour les activités de soutien. Un point important est qu'une fois qu'un Sprint a démarré pour une équipe Scrum de développement, il n'est pas recommandé de commencer à ajouter des arriérés de problèmes de production pendant le sprint en cours. Cela peut enlever la valeur du Sprint actuel et démoraliser les membres de l'équipe. Il est de la responsabilité des OP de maintenir la liste de Sprint Backlog stable, et elle peut avoir à combattre la bataille contre l'entreprise pour faire cela parfois. Le SM devrait certainement faire ce qu'il faut pour protéger l'équipe contre les influences extérieures et aider l'OP à s'assurer que le Sprint Backlog est stable.
Maintenant, le revers de la médaille est que la Direction peut avoir besoin d'annuler un Sprint si le But du Sprint devient obsolète. Cela peut se produire si l'entreprise change de direction ou si les conditions du marché ou de la technologie changent ou s'il y a trop de problèmes de production. En général, un Sprint devrait être annulé s'il n'a plus de sens dans les circonstances. Cependant, en raison de la courte durée des Sprints, il est rarement logique de le faire.
Donc, pour résumer:
Références: Guide Scrum - Ken Schwaber et Jeff Sutherland (les créateurs de Scrum)
Vous ne pouvez pas faire les deux. Utilisez Scrum ou soutenez vos clients.
Je suggère d'utiliser Scrum si vous pouvez créer une équipe d'au moins cinq développeurs qui ne seront pas interrompus pendant le sprint. Généralement, même si un support est requis, les clients peuvent attendre la fin du Sprint. D'autre part, vous pourriez avoir un développeur de rechange dont le travail consiste à répondre au soutien des clients. L'équipe sera alors en mesure de remplir son travail en développant des produits de plus grande valeur afin que vos exigences de support client diminuent. À mon avis, votre organisation bénéficiera de votre expérience Scrum.
J'ai une équipe qui prend en charge deux outils - y compris le développement, la correction de bugs, la maintenance, les travaux. Donc, notre situation n'est pas trop différente. Peut-être que notre solution pourrait également fonctionner pour vous ...
Nous avons récemment commencé à utiliser Scrum avec une itération de deux semaines. La façon dont nous le faisons, nous avons un accord de niveau de service qui est accepté par tous nos clients; Les demandes qui ne sont pas couvertes par le SLA ne sont prises en compte que lors de la planification du sprint, tandis que celles qui le sont peuvent être traitées immédiatement.
Nous avons ensuite un historique utilisateur de "Support général" dans chaque sprint qui nous demande simplement de suivre le SLA. Dans ce cadre, nous avons mis en place une tâche pour les "demandes inconnues" évaluées en un ou deux heures; lorsque de nouvelles tâches légitimes arrivent, nous soustrayons l'évaluation de la nouvelle tâche des inconnues, ce qui n'entraîne aucun gain net de travail. Si vous estimez de façon appropriée le montant du travail de soutien, cela n'entraîne aucune perte nette de temps de développement. Et bien sûr, si vous sous-estimez, ce qui arrivera probablement la première ou la deuxième fois, c'est quelque chose que vous pouvez apprendre du prochain sprint. Avec le support déjà pris en compte dans le plan, vous pouvez mieux évaluer ce que vous pouvez réaliser en termes de développement dans un sprint. Les demandes d'assistance entrantes peuvent encore rendre votre équipe aléatoire, mais si vous pouvez vous concentrer sur une tâche à la fois, cet effet n'est pas très sérieux.
(Nous avons également commencé à utiliser Rational Team Concert pour tout suivre, mais nous ne l'avons pas utilisé assez longtemps pour que je puisse dire à quel point c'est utile dans cette situation).
Je vote pour clore cette question hors-sujet car elle concerne le processus de développement, pas la programmation. – EJoshuaS