ScrumBut dans l'équipe d'analyse: avant le décollage

Bonjour, Habr! Je m'appelle Zhenya. Je suis analyste système chez NORBIT et Scrum-master débutant. Je regarde Scrum depuis longtemps pour étudier, essayer et évaluer ses capacités au sein de notre équipe d'analystes. Et maintenant, après un coup de pied léger d'une conversation inspirante avec le RP, j'ai réalisé: arrêtez de penser, il est temps de le faire.

Dans cet article, je parlerai de notre expérience de préparation à l'utilisation du Scrum limité au nom du Scrum master: ce que nous avons fait pour commencer. Au moment de la rédaction, le 15e sprint est terminé. Le vol est normal!


J'ai souvent entendu parler de l'utilisation du framework Scrum dans des équipes dont les membres ne sont pas développeurs. Des équipes de diverses expertises rejoignent activement Agile. Je pensais que Scrum a été créé à l'origine pour les équipes de développement à cycle complet, et il y a donc un certain nombre de difficultés ou de points intéressants auxquels vous devez faire attention si l'équipe diffère de celle de référence à laquelle les créateurs ont pensé. Je distingue les équipes dans le sens de l'expertise et du degré de participation au cycle de développement produit. La direction de l'expertise, à mon avis, ne limite pas l'utilisation de Scrum. Mais le degré de participation au développement de produits peut limiter. Certains d'entre eux peuvent effectuer le cycle complet de travail sur le produit, étant responsables du résultat final à la disposition du client - et à mon avis, dans de telles équipes, vous pouvez utiliser un Scrum à part entière. Et d'autres ne font qu'une partie du cycle complet, faisant partie de la chaîne de travail. Dans ce cas, il peut y avoir des questions et des difficultés avec une Scrum à part entière. Une telle situation de conception peut nécessiter un compromis.
Cet article se concentrera sur l'équipe responsable d'une partie du cycle de développement de produit et la préparation du lancement de ScrumBut.

Notre plan d'action pour le lancement était le suivant:

• d'étudier et d'évaluer la situation actuelle et les
• construire un modèle tel quel et être dans la terminologie ScrumBut,
• présenter et inspirer l'équipe

Comment j'ai appris ce qu'est ScrumBut

J'ai d'abord googlé et obtenu:

Un ScrumBut a une syntaxe particulière: (ScrumBut) (Reason) (Workaround). Exemples ScrumBut: "(Nous utilisons Scrum, mais) (avoir un Scrum quotidien tous les jours est trop lourd,) (donc nous n'en avons qu'un par semaine.)" "(Nous utilisons Scrum, mais) (Les rétrospectives sont une perte de temps ,) (donc nous ne les faisons pas.) "

C'est-à-dire ScrumBut est un Scrum limité. Cette variation du cadre vous permet de prendre tout ce dont vous avez besoin de Scrum et de ne pas prendre ce qui, à notre avis, n'est pas requis. Bien sûr, c'est un chemin glissant, car Pour comprendre ce qui est nécessaire et ce qui n'est pas requis, il était important d'avoir une idée du Scrum classique, il était important pour moi de comprendre pourquoi cela est inclus dans la version complète.

Utiles pour moi dans le matériel étaient:

• étude de la littérature: manifeste Agile du développement logiciel , «méthode de gestion de projet révolutionnaire SCRUM» (Joseph Sutherland), «coaching d'équipe agile» (Lissa Adkins);
• une série de consultations longues et intéressantes avec un scrum master actif certifié pratiquant les classiques.

Comment ai-je évalué la situation actuelle

Pour commencer, j'ai profité de ma vision et mis en avant plusieurs points à évaluer par les managers.

Recueilli les opinions des membres de l'équipe et les a enregistrées.

Nous avons obtenu deux listes: ce que nous avons à l'entrée et ce que nous voulons obtenir.

Ici, je ferai des listes consolidées et généralisées.

Ce qu'ils avaient à l'entrée

1. Un grand projet pour le développement d'un système d'interpraise.
2. Des équipes distinctes de développeurs, de support et d'analystes.
3. Une équipe d'analystes sympa (environ 14 personnes).
4. La capacité d'agir uniquement dans le cadre d'une équipe d'analystes.
5. Release release des versions du système.
6. Modèle de gestion du cycle de vie du logiciel Waterfall.
7. L'impossibilité d'une planification rigoureuse, car les tâches du client viennent à tout moment.
8. Charge de travail inégale des analystes.
9. Répartition fonctionnelle des zones d'examen des analystes.

Que voulons-nous obtenir

1. Être en mesure de répondre rapidement aux changements commerciaux.
2. Prendre en compte et prioriser les tâches au travail
3. Avoir des prévisions de croissance de produits réalisables.
4. Les sprints courts peuvent vous permettre de suivre, d'enregistrer et de terminer des tâches, et de prévoir plus précisément quand les tâches seront publiées.
5. Créez un carnet de tâches pour les analystes.
6. À tout moment, l'analyste sait quoi faire.
7. Échangez votre expérience dans la résolution de problèmes complexes.
8. Établir un travail d'équipe de manière à partager les connaissances était agréable, confortable et mutuellement bénéfique.
9. Organisez votre Scrum avec Black Jack, etc. :)
10. Essayez de nouvelles choses, améliorez l'esprit d'équipe. Cool les gars. Pourquoi pas?

Modélisation

Au stade de la modélisation, nous avons attribué des rôles d'équipe: nous avons identifié les chefs de produit, les membres de l'équipe et moi en tant que Scrum Master, la durée du sprint, le processus de remplissage et de priorisation du backlog.

Les attributs de tâche obligatoires, le flux de travail pour le suivi, l'outil de suivi, l'attribution d'une estimation en heures humaines pour chaque type de tâche et le nombre total d'heures par semaine pour chaque analyste ont été déterminés, en tenant compte de la réalisation du plan de l'équipe de sprint, du temps et de la régularité des rallyes et rétrospectives quotidiennes.

Le propriétaire du produit et la personne qui établit l'arriéré sont à la tête d'un groupe d'analystes. Il a été décidé de former des équipes de 2 à 7 personnes, répondant à l'exigence d'un montant de 7 ± 2. Il s'agissait de deux équipes, conditionnellement réparties en fonction de l'attribut fonctionnel des tâches à résoudre, qui était plus proche du modèle d'origine, mais plus éloigné de l'objectif visé - la fonctionnalité croisée.

Pour le suivi, nous avons décidé d'utiliser le TFS existant, dans lequel il est pratique de mettre des tâches sur les statuts de "Nouveau", "En cours", "Terminé" au tableau et il est possible de collecter de petites statistiques sur les résultats pour discussion lors d'une réunion rétrospective à la fin du sprint. La carte TFS imite une carte Scrum physique, mais nous en avions également une physique.

Présentation

La phase de planification s'est terminée par une démonstration à l'équipe de la présentation des résultats de la modélisation «Commencer ensemble ensemble», discussion et correction de ce qui n'a pas trouvé de réponse des gars.

Scrum et ScrumBut en particulier sont le travail d'équipe, la cohérence, la transparence et l'acceptation générale. Ce fut un moment important dont nous sommes partis avec inspiration.

Source

Conclusions des préparatifs de lancement

Lorsque vous travaillez sur un grand projet, il n'y a aucun moyen d'entrer dans la piscine avec votre tête, vous ne pouvez donc pas vous passer de planification. Il est important de comprendre comment il sera et quels résultats il apportera, mais nous avons rencontré le besoin de nous préparer au fait que le plan, à certains égards, restera le plan. Lors de la planification, nous avons peint à grands traits, et déjà au stade de la mise en œuvre, nous avons pu ajouter les détails que l'équipe et la situation de conception ont apportés.

Notre équipe n'est responsable que d'une partie du cycle de développement logiciel, il y avait donc des difficultés avec ce qu'il fallait appeler un produit et ce qu'il fallait recevoir en augmentation. Nous savions qu'il devait être holistique et complet. Nous avons convenu que, de la part de l'équipe d'analystes, nous préparons plusieurs types de documents pour l'interaction avec le client et créons des tâches pour que les développeurs les retiennent. Ainsi, les tâches relèvent des sprints pour les développeurs. À mon avis, une telle voie de compromis peut convenir à la fois aux projets dans lesquels des équipes individuelles d'analystes, de développeurs, de testeurs, de support et aux projets où le nombre de personnes nécessite une séparation en plusieurs équipes. Il y a aussi un inconvénient dans cette décision - les membres de notre équipe ne peuvent pas affecter le moment de la disponibilité des fonctionnalités du produit, nous ne pouvons affecter que les performances de leur partie du travail. Il y a des avantages - la continuité des tâches des analystes pour les développeurs. Cette décision nous a permis d'éviter les tentatives de devenir une équipe interfonctionnelle (analystes = développeurs = testeurs, etc.), ce qui dans notre cas à ce stade serait impossible, tout en maintenant le cycle de développement du produit avec une réfraction de compromis à la jonction de l'interaction d'équipe.

Au stade de la présentation, nos gars de NORBIT ont réagi avec beaucoup d' enthousiasme et d'intérêt. Mais je suppose que la réponse émotionnelle positive de l'équipe est le mérite de travailler sur les objectifs et leur lien avec des problèmes urgents et évidents.

Les étapes décrites ci-dessus (étude théorique, modélisation et présentation) ont fait l'affaire: nous avons commencé avec succès.

Mais le démarrage n'est que la première étape. Je vais vous parler de ce qui s'est passé après le lancement et des résultats obtenus dans mon prochain article.