Bonjour, Habr! Je m'appelle Maxim Lutzau, à Promsvyazbank, je travaille en tant que propriétaire de produit. Depuis près d'un an, le développement du nouveau My Business Internet Banking se poursuit avec le framework Scrum, et à cet égard, j'ai déjà réussi à combler les bosses. Dans cet article, je voudrais parler des plus douloureux d'entre eux, ainsi que des outils qui nous ont finalement aidés. Pour éviter de tels problèmes.
Certains employés sont fondamentalement opposés au changement
Le cadre Scrum a été adopté dans notre banque afin d'accélérer le développement et de réduire le TTM. Lorsque la mise en œuvre a commencé, il s'est avéré que certains employés n'étaient pas prêts pour cela. Ils ne comprenaient pas pourquoi cela était nécessaire et ce que cela donnerait.
"Nous avions l'habitude de bien travailler, pourquoi en avons-nous besoin?", "Pourquoi ne le faisons-nous pas différemment?", "Qui est venu m'apprendre cela, comment sait-il que c'est mieux?" - Des questions similaires pleuvaient constamment de leur part. Et même lorsque ces employés ont reçu des réponses, après un certain temps, tout s'est répété.
La solution la plus raisonnable dans ce cas est de transférer des personnes vers d'autres projets. Cela doit être fait nécessairement, car une personne rayonnant un négatif peut influencer tout le monde. Dans notre histoire, c'est précisément ce que notre collectif a guéri - la tension générale a disparu et tout le monde est à l'écoute de la perception de nouvelles informations.
Une réaction négative aux changements ne dépend pas de l'âge. Les développeurs dont nous avons parlé ci-dessus avaient un peu plus de 30 ans. Dans le même temps, une personne qui a déjà plus de 50 ans travaille parfaitement dans notre équipe - il n'a eu aucun problème avec Scrum.
Il est difficile d'interagir avec des gens qui ne vivent pas avec Scrum.
Toute organisation doit collaborer avec des personnes qui ne travaillent tout simplement pas sur Scrum. Dans notre cas, ce sont des équipes d'autres projets et départements. Ils ont généralement des étapes beaucoup plus longues de mise en œuvre du projet. Honnêtement, seuls les développeurs RBS travaillent pour nous sur Scrum jusqu'à présent.
Nous avons décidé de ne rien faire avec ce problème - de ne pas entrer dans le travail des autres avec notre mêlée. Nous leur demandons simplement de faire ce dont nous avons besoin. Quand ils reviennent avec une solution, nous commençons à lier leurs tâches. Ne compliquez pas l'interaction si la culture d'entreprise n'est pas encore mûre par elle-même. Bien sûr, après les entraînements de mêlée, il y a un désir de tout changer, mais il vaut mieux s'arrêter à temps.
Bien que nous ne précipitions pas d'autres unités, en coopération avec nous, elles commencent à travailler plus rapidement. Nous invitons des agents de sécurité à nos réunions et démonstrations, et maintenant, nous mettre d'accord sur une version complète ne prend qu'un jour. Avant cela, cela prenait d'une semaine à deux.
"Nous ne serons pas à temps pour le sprint!"
Après avoir implémenté Scrum, nous sommes passés de périodes de rapports mensuels à des sprints de deux semaines. Au début, en raison de l'ampleur des tâches, ils ne voulaient pas comprimer les délais. Mais ajuster la taille du sprint à ce qui doit être fait est une grosse erreur. Au contraire, vous devez ajuster les plans pour la durée du sprint. Pour ce faire, c'est assez simple - il suffit de décomposer les tâches. Lorsqu'elles diminuent de taille, elles sont plus faciles à organiser selon le plan, pour leur donner la priorité. Des lots de code plus petits sont plus rapides à tester, vérifier, négocier avec les agents de sécurité. En général, je recommanderais même de réduire la durée du sprint, si possible, de deux semaines à une.
Quand quelqu'un de l'équipe n'a pas le temps de faire tout ce qui est prévu d'ici la fin du sprint, il y a un désir naturel de reporter la démo - pour y arriver complètement armé. Mais dans ce cas, vous devez toujours respecter le calendrier. Dans tous les cas, il vaut la peine de parler des résultats du travail: ce qu'ils ont fait, quoi et pourquoi ils ne l'ont pas fait, ce qu'ils ont fait pour être à l'heure. Donc, nous ne fuyons pas les problèmes, mais nous nous trouvons face à face avec eux et nous pouvons alors trouver des solutions ensemble.
Cette approche augmente la motivation, après des démonstrations planifiées infructueuses, la responsabilité du travail augmente. Si avant les développeurs préparaient le stand pour la démo en cinq minutes, maintenant ils le font la veille de la démo, puis ils polissent les bosses restantes pour que tout soit super.
"Pourquoi avons-nous besoin de stand-ups quotidiens?"
Au début, les collègues étaient sceptiques à l'idée d'être distraits de leur travail habituel chaque jour lors de réunions debout. Même s'ils sont tenus en ligne et ne nécessitent que 10 minutes.
Pour résoudre ce problème, l'encouragement symbolique d'une personne qui trouve un langage commun avec l'équipe aide. Une fois, pour le plaisir, j'ai dit que je marquerais sur le calendrier ceux qui viennent se tenir debout et j'ai commencé à mettre des avantages. Le résultat était inattendu, et l'effet était perceptible après un sprint. Ne voulant pas être bombardé, les développeurs eux-mêmes se sont levés. Cela est même devenu notre plaisanterie commune: maintenant, ils menacent de me mettre un inconvénient quand je ne peux assister à aucune réunion.
Beaucoup de gens pensent que les réunions Scrum prennent beaucoup de temps. Il suffit de calculer ici si c'est effectivement le cas. Nous avons deux heures par semaine sur 40. Ce n'est pas tant pour organiser le travail et rester au courant de tout.
Si toute l'équipe ne veut pas participer à des réunions debout et que les réunions elles-mêmes ne sont pas très actives, c'est le signe que le travail va mal. Comme si la réunion était retardée de plus de 15 à 20 minutes. Une histoire sur ses activités et ses projets chez une personne ne devrait pas prendre plus d'une ou deux minutes.
Une règle de plus est liée à la gestion du temps. Si la discussion de la tâche dure plus de 30 minutes, nous l'arrêtons. Cela signifie que nous n'avons pas eu le temps de développer la tâche, qu'elle est mal décomposée et nécessite encore du temps. Cela vaut la peine d'y prêter attention. Nous nous fixons une limite de 30 minutes - chaque entreprise doit établir sa propre barrière.
Arriéré incompréhensible
Le succès de Scrum dépend principalement d'une planification claire. Il est nécessaire de déterminer combien de tâches doivent être évaluées et décrites, et lesquelles peuvent être simplement reportées pour l'instant. N'essayez pas de tout couvrir à la fois. Le développeur doit comprendre ce qu'il fera dans les deux prochains sprints. Pour des périodes plus longues, une idée approximative suffit - plus tard, moins de détails.
Microgestion inappropriée
Que font les développeurs aujourd'hui? Que se passera-t-il demain? Il arrive que les gestionnaires posent régulièrement de telles questions. Nous avons pu expliquer à notre direction que tous les points d'intérêt se retrouvent sur notre scrum board ou en venant au stand-up quotidien. Pas de rapports spéciaux avec tableaux et suivi des tâches dans Jira. Nous avons réussi à intégrer cette microgestion à des réunions hebdomadaires avec la direction, où je rend compte des tâches spécifiques effectuées par l'équipe.
Quelque chose presque jamais écrit
Enfin - il y a un problème clair, dont je n'ai presque jamais mentionné la mention. Pas besoin d'essayer de combiner le Scrum Master et le Product Owner. Ce dernier construit une unité commerciale, travaille sur un carnet de commandes et exécute des KPI. Il s'intéresse au succès du produit et essaie de se plonger dans tout - par conséquent, il commence à prendre des rendez-vous, à discuter de certains détails. En général, il se charge avec un tas de fonctions, à cause desquelles il n'y a tout simplement pas de temps pour le backlog.
Cela m'est arrivé. J'ai organisé des réunions, des stand-ups, résolu les problèmes des membres de l'équipe. Pour cette raison, l'arriéré n'a pas été résolu, c'est-à-dire qu'il n'y avait tout simplement pas de temps pour l'activité principale. Nous avons maintenant trouvé un responsable du développement qui a autorité sur l'équipe et a également commencé à exercer les fonctions de Scrum Master, car il a plus d'expérience dans ce cadre. Maintenant, j'ai pu m'éloigner de Scrum et me concentrer pleinement sur les tâches du propriétaire du produit, qui, à son tour, devrait réfléchir aux exigences. Sans bonnes exigences, il n'y aura pas de bon produit. En conséquence, l'arriéré a commencé à s'améliorer, les collègues ont compris comment nous allons avancer.
À première vue, Scrum semble très simple, mais présente encore de nombreux pièges. Nous travaillons sur ce cadre depuis près d'un an, mais ce n'est que maintenant que nous avons commencé à évaluer plus ou moins clairement nos capacités, avons commencé à accélérer le développement.