Impulsion de sprint: créer un travail efficace au sein d'une grande équipe

L'impulsion de sprint est un outil supplémentaire que la commande Scrum peut utiliser pour organiser le processus à l'intérieur du sprint. Il permet de mettre en place un travail d'équipe et fait gagner du temps pour l'immersion de nouveaux spécialistes. Comment l'appliquer, explique Alyona Shester, chef de projet de fer. En bonus, à la fin de l'article, vous trouverez un modèle pour le premier montage.



Une fois, nous avons parlé un peu de cet outil. Depuis la rédaction de l'article précédent, il nous a sauvés plusieurs fois, nous avons donc décidé d'ouvrir le sujet plus en détail.

Sprint pulse et sprint: quelle est la différence

Les noms sont similaires, mais l'essence est différente:

• Sprint est une période de temps pendant laquelle l'équipe Scrum crée une partie du produit qui peut être montrée au client et qui lui sera utile. Sprint se compose de cinq événements: planification, Scrum quotidien, développement, démonstration de sprint et rétrospective.
• Le pouls de sprint est un outil qui aide à créer un travail efficace au sein de l'équipe pendant le sprint.

Les événements de sprint sont inchangés et l'impulsion de sprint est une partie qui peut être personnalisée pour un projet spécifique.

Termes

Un artefact est un objet créé dans le processus de travail sur un projet (par exemple, protocole, mise en page, backlog, etc.).
Incrément - croissance du produit (par exemple, l'apparition de nouvelles fonctionnalités ou leur mise à jour).
Le bloqueur est une situation qui interfère avec le travail et le bloque.
Les jalons sont des étapes importantes du projet.

Impulsion de sprint en action

L'objectif principal de notre projet, que nous avons pris comme exemple, était de créer une application mobile à partir de zéro. Le travail a été divisé en plusieurs étapes. La première étape de production a été la création d'une conception de service. Et comme premier artefact significatif - la création de dispositions d'écran (wireframes) pour les scripts d'application haute priorité. Ces scripts faisaient partie du produit MVP.

L'équipe de démarrage était composée de 6 personnes: un chef de produit côté client, un chef de projet, un chercheur en ux, un directeur artistique et deux designers. Chaque itération nécessaire pour fournir de nouvelles dispositions - c'est un indicateur que le projet avance au bon rythme. Une itération - une semaine. Scrum était parfait pour cette tâche. Après avoir convenu des jours de début et de fin du sprint, ainsi que des jours et de la composition des participants aux épreuves de sprint, nous avons commencé à travailler.

La tâche clé suivante consistait à développer un concept de conception. Après cela, le développement nous attendait, donc en parallèle de cette tâche, nous avons connecté un analyste, un architecte, des développeurs et un testeur pour préparer tout ce qui est nécessaire pour un démarrage à part entière: réfléchir et définir l'architecture de l'application, configurer CI (intégration continue) et, surtout, convenir d'une interaction à l'intérieur équipe unie.

À ce moment, nous avons réalisé que nous devions trouver une solution qui «se lierait» avec la conception et le développement, maintiendrait également le rythme de travail et obtiendrait systématiquement une augmentation.

Dans le processus d'analyse des travaux à venir, nous avons réalisé que nous avions besoin de quelque chose de plus que des événements Scrum pour démarrer efficacement. Nous avons été confrontés à un grand nombre d'activités: analyse et préparation des exigences commerciales principales, conception de scénarios, préparation de mises en page, préparation des exigences fonctionnelles, conception, développement et tests d'API. Pour cette raison (lors de la planification d'un sprint), il y avait une forte probabilité de passer à côté de quoi, à qui et quand vous pourriez avoir besoin pendant le travail, à l'intérieur du sprint lui-même.

De plus, en utilisant uniquement des outils Scrum standard, vous pouvez rencontrer le problème de la planification de sprint à sprint long. Chaque fois, nous devions négocier avec les sous-commandes quand et ce qui pouvait être vu et apprécié.

De plus, avec l'aide des outils Scrum, il ne sera pas possible de répartir efficacement le temps des spécialistes. Dans le cadre d'un grand projet, cela conduirait à des bloqueurs: un artefact pour démarrer le travail de l'étape suivante ne serait pas prêt. Par exemple: pour que les développeurs côté serveur puissent commencer à créer l'API, ils doivent comprendre quelles fonctionnalités les concepteurs ont l'intention de concevoir. Si vous n'attribuez pas de manière optimale le temps aux spécialistes, il y a un risque que le travail ne soit pas fait à temps.

Nous avons essayé de construire un «stream» à l'intérieur du sprint. La tâche principale est de rendre le processus de travail compréhensible pour chaque membre de la sous-commande et de minimiser les temps d'arrêt. Chacun doit comprendre son domaine de responsabilité et les moments et les besoins à fournir.

Parallèlement au développement, nous avons commencé à collecter une impulsion de sprint. Nous avons commencé par des réunions avec des experts de premier plan dans chaque domaine et avec le propriétaire du produit de la part du client. Nous avons fixé les principales étapes du travail et déterminé ce dont chaque sous-commande a besoin pour démarrer sa partie du processus. Par exemple, les exigences fonctionnelles de l'analyste sont à la base du travail des développeurs. S'il y a un retard, l'ensemble du projet «sortira» à temps.

De plus, nous avons discuté avec le client de points importants qui pourraient affecter le pouls de sprint. Un de ces points est le paramètre time-to-market (time to market) de 1 mois et l'augmentation (augmentation des fonctionnalités) toutes les 2 semaines.

Après avoir collecté les informations, nous avons trouvé et enregistré les dépendances: quoi et après ce qui se passe, et aussi - dans quelle période de temps doit être fait. Tout cela est devenu un workflow.


Les tout premiers croquis

Lors de la collecte d'une impulsion de sprint, il est important de minimiser les moments où il peut y avoir des temps d'arrêt. Par exemple, dans notre cas, il valait la peine de laisser plus de temps à l'analyste pour décrire les méthodes API. Étant donné que sur la base de ces informations, des exigences sont en cours de préparation pour l'équipe de développement front-end, il était nécessaire d'être prêt à augmenter la durée.


Les premières versions des options de connexion à l'intérieur du sprint étaient dans la version physique: croquis sur papier, autocollants - tout est entré en vigueur!

La dernière étape consiste à intégrer l'impulsion de sprint dans le sprint lui-même.


Réflexions sur la façon de diviser un instrument en sprints

Nous avons réussi à collecter la variante d'impulsion de sprint optimale pour nous-mêmes: il a pris en compte toutes les dépendances et points de contrôle pour fournir le résultat à une autre équipe.

Impulsion de sprint à partir d'autocollants et de feuilles de papier, nous avons reconstruit à Miro . Vous pouvez utiliser n'importe quel autre programme (et sur des supports physiques, si cela vous convient). L'essentiel est que tous les participants au sprint puissent consulter le diagramme à tout moment - synchroniser dans le temps, les tâches et les relations avec d'autres sous-commandes.


Impulsion de sprint pour notre projet

Comment construire une impulsion de sprint

Pour créer un pouls de sprint pour votre équipe, vous devez répondre à 6 questions. Cela vous aidera à recueillir des informations à partir desquelles vous pourrez identifier les dépendances et les bloqueurs. Ensuite, ils doivent être disposés pour le calendrier de chaque sprint.

1) Quoi et qui fait?
Au début, il est nécessaire de déterminer la direction du travail: ce que nous faisons, qui fait, quel est le but, ce que nous considérons comme le résultat, etc.

2) Quelle sera l'activité?
Nous trouvons toutes les activités qui affectent chacune des sous-commandes. Nous prescrivons leurs étapes du début à la fin du sprint.

3) Quels sont les jalons du sprint?
Définissez des jalons (jalons) dans le sprint de chaque sous-commande. Ils indiquent la fin du travail sur une tâche dans le sprint.

4) Quels sont les liens au sein de l'équipe?
Nous déterminons le temps de production de tous les artefacts «dépendants» nécessaires au travail des autres équipes (par exemple, des maquettes de concepteurs pour les développeurs). On retrouve toutes les interdépendances. Ensuite, nous les connectons et les plaçons sur la chronologie du sprint.

5) Où peut-il y avoir des temps d'arrêt?
Nous identifions les temps d'arrêt - moments qui peuvent affecter la vitesse et la réalisation des objectifs de sprint. Nous trouvons également des tâches qui peuvent être reprises par des sous-commandes lors de pannes forcées. Mais ce n'est pas facile pour les spécialistes de faire quelque chose - ces tâches devraient aider l'autre équipe à travailler plus efficacement à l'avenir.

Par exemple, nous avons le premier jour du sprint consacré à la planification et aux évaluations, donc pour nous, un tel événement était la «journée propre» de l'équipe de conception, dans laquelle ils pouvaient nettoyer les mises en page et mettre à jour la carte d'écran.

6) Quand les équipes doivent-elles se synchroniser?
Ici, vous devez comprendre à quels points de contrôle la commande sera synchronisée. Nous fixons tous ces points: quel résultat, dans quel volume et à quelle date devrait être prêt. Ceci est nécessaire pour toutes les sous-commandes.

Afin que les concepteurs puissent produire un résultat réalisable pour les développeurs, une fois la conception du script en filaire terminée, nous nous sommes réunis en équipe pour présenter les développements et recueillir des commentaires sur les limites techniques.

Il est important de comprendre que pendant un certain temps, le pouls du sprint «se brouillera» aux réalités du projet. Mais, malgré cela, le départ sera toujours plus rapide que sans lui.

Pour collecter une impulsion de sprint pour votre équipe, vous pouvez utiliser ce modèle. Les points principaux sont indiqués ici, mais quelque chose peut et doit être adapté à votre projet.



Vous pouvez regarder de plus près et télécharger ici

Quand l'impulsion de sprint est nécessaire, et quand non

Il y a des cas où l'impulsion de sprint est superflue, mais parfois elle sera simplement irremplaçable.
Cette plaque est un indice: si la quantité «oui» est supérieure à «non», alors vous devriez peut-être utiliser cet outil.


Sprint Pulse Mini-Test

Problèmes qu'une impulsion de sprint peut résoudre

Il existe plusieurs situations auxquelles l'outil nous aide à faire face. C'est précisément notre expérience et, bien sûr, ce n'est pas toute la liste. Chaque utilisateur d'impulsion de sprint peut avoir le sien.

Démarrage long du projet

Selon les règles de Scrum, l'équipe elle-même doit construire du travail à l'intérieur du sprint, en fonction de ses activités. Mais le premier problème est que les membres de l'équipe ont différents niveaux de communication et d'organisation. La seconde est que pour établir la communication et les processus, les équipes doivent tenir une série de réunions et y consacrer beaucoup de temps.

Solution: sprint pulse - un kit de démarrage qui accélérera le travail. Après l'avoir formé avant le début de la production (jusqu'au moment où les équipes se verront confier des tâches), vous pouvez démarrer rapidement et en douceur.

Bloqueurs en cours

Pendant le travail, les spécialistes se concentrent sur l'accomplissement de leurs tâches. Ils peuvent ne pas être conscients des risques et des relations avec d'autres professionnels. Sans un plan fixe à l'intérieur du sprint, il est difficile pour l'équipe de voir l'ensemble de l'image. En conséquence, des bloqueurs apparaissent: les spécialistes suivants de la chaîne ne peuvent pas commencer à travailler. Le résultat de cette «boule de neige» est l'échec à atteindre les objectifs du sprint, et dans les cas extrêmes - l'échec du projet.

Exemple: un exemple vivant teste une application mobile pour une banque. Si vous n'y mettez pas de temps pour les tests et la stabilisation, à la fin du sprint, il y aura une base de code, mais il ne restera plus de temps pour rechercher les défauts. Et sans cela, le code développé ne peut pas être appelé un «incrément complet». Il ne sera pas possible de donner un tel produit aux clients de la banque: outre le fait qu'il fonctionnera mal, cela peut entraîner des problèmes pour la banque. Par exemple, une fuite de données personnelles, un piratage de compte, un vol de fonds, etc. peuvent se produire.

Solution: tout au long du travail, l'équipe voit une seule impulsion de sprint. Chacun sait qui et quoi attend de lui un jour particulier du sprint, et construit son travail sur la base de ces dépendances. De plus, l'impulsion de sprint est une sorte de «contrat» entre les sous-commandes. Et si les artefacts n'ont pas été fournis à temps, le spécialiste a parfaitement le droit d'aggraver le problème, car toutes les dates clés sont fixées dans le pouls du sprint.

Immersion d'un nouveau spécialiste du projet

Habituellement, le spécialiste de l'intégration prend beaucoup de temps. Pour commencer à travailler à pleine capacité, il doit comprendre ce qui se passe et s'immerger dans les processus.

Exemple: un autre concepteur est connecté au projet. On lui parle du projet et des tâches: à l'échelle de l'équipe, ainsi que des tâches directement de sa sous-équipe. Ensuite, il doit parler avec d'autres concepteurs et développeurs. Il est important d'apprendre toutes les subtilités, par exemple, quand il peut attirer des développeurs pour évaluer la complexité technique de l'implémentation qu'il a conçue. Cela prend du temps et distrait l'équipe des tâches, ce qui réduit généralement son efficacité.

Solution: L'impulsion de sprint préparée pour le projet simplifie et accélère considérablement le processus d'immersion d'un spécialiste. Il montre déjà clairement les dépendances de l'équipe - à qui, à quel moment et ce qui doit être fourni. Avec son aide, vous pouvez intégrer rapidement et efficacement de nouveaux spécialistes dans un projet.

Conclusion

Il s'avère mettre en place un processus efficace si chaque employé comprend quoi, quand et pourquoi il le fait. Pour ce faire, l'équipe doit être synchronisée et le pouls de sprint s'adapte bien à cette tâche. Ce n'est qu'un outil supplémentaire pour les commandes Scrum, mais certainement utile. Il vous permet d'établir rapidement un processus de production et de désigner une zone de responsabilité pour chacun. L'impulsion de sprint aidera à se déplacer dans le calendrier de sprint, et les sprints terminés en temps opportun, à leur tour, garantissent le produit fini à temps.