Olá Habr! Meu nome é Maxim Lutzau, no Promsvyazbank eu trabalho como proprietário de um produto. Por quase um ano, o desenvolvimento do novo banco na Internet My Business está em andamento com a estrutura Scrum e, nesse sentido, eu já consegui preencher os obstáculos. Neste post, gostaria de falar sobre os mais dolorosos deles, bem como sobre quais ferramentas acabaram nos ajudando. Para que você possa evitar tais problemas.
Alguns funcionários se opõem fundamentalmente à mudança
A estrutura Scrum foi adotada em nosso banco para acelerar o desenvolvimento e reduzir o TTM. Quando a implementação começou, alguns funcionários não estavam prontos para isso. Eles não entenderam por que isso era necessário e o que daria.
“Costumávamos trabalhar bem, por que precisamos disso?”, “Por que não fazemos de maneira diferente?”, “Quem veio me ensinar isso, como ele sabe que isso é melhor?” - Perguntas semelhantes choviam constantemente da parte deles. E mesmo quando esses funcionários receberam respostas, depois de um tempo tudo foi repetido novamente.
A solução mais razoável nesse caso é transferir pessoas para outros projetos. Isso deve ser feito necessariamente, pois uma pessoa que irradia um negativo pode influenciar todos. Em nossa história, é exatamente isso que nosso coletivo curou - a tensão geral desapareceu e todos estão sintonizados com a percepção de novas informações.
Uma reação negativa às mudanças não depende da idade. Os desenvolvedores de que falamos acima tinham pouco mais de 30 anos. Ao mesmo tempo, uma pessoa que já tem mais de 50 anos está trabalhando perfeitamente em nossa equipe - ele não teve nenhum problema com o Scrum.
É difícil interagir com pessoas que não vivem do Scrum.
Qualquer organização precisa colaborar com pessoas que simplesmente não trabalham no Scrum. No nosso caso, são equipes de outros projetos e departamentos. Eles geralmente têm estágios muito mais longos de implementação do projeto. Honestamente, apenas os desenvolvedores do RBS trabalham para nós no Scrum até agora.
Decidimos não fazer nada com esse problema - não entrar no trabalho de outras pessoas com nosso scrum. Pedimos apenas que façam o que precisamos. Quando eles retornam com uma solução, começamos a vincular suas tarefas. Não complique a interação se a cultura corporativa ainda não estiver madura por si só. Obviamente, após os treinamentos em scrum, há um desejo de mudar absolutamente tudo, mas é melhor parar no tempo.
Embora não apressemos outras unidades, em cooperação conosco, elas começam a trabalhar mais rapidamente. Convidamos guardas de segurança para nossas reuniões e demonstrações, e agora concordar com um lançamento totalmente concluído leva apenas um dia. Antes disso, demorava de uma semana a duas.
"Não chegaremos a tempo do sprint!"
Após a implementação do Scrum, passamos dos períodos de relatório mensal para os sprints de duas semanas. A princípio, devido à escala das tarefas, eles não queriam compactar os prazos. Mas ajustar o tamanho do sprint ao que precisa ser feito é um grande erro. Pelo contrário, você precisa ajustar os planos para a duração do sprint. Para fazer isso é bastante simples - basta decompor as tarefas. Quando eles diminuem de tamanho, são mais fáceis de organizar de acordo com o plano, para dar prioridade a eles. Lotes menores de código são mais rápidos para testar, verificar e negociar com os guardas de segurança. Em geral, eu recomendaria até reduzir a duração do sprint, se possível, de duas semanas para uma.
Quando alguém da equipe não tem tempo para fazer tudo o que foi planejado até o final do sprint, existe um desejo natural de adiar a demonstração - de chegar totalmente armado. Mas, neste caso, você ainda precisa seguir a programação. De qualquer forma, vale a pena falar sobre os resultados do trabalho: o que eles fizeram, o que e por que não fizeram, o que fizeram para chegar a tempo. Portanto, não fugimos dos problemas, mas ficamos cara a cara com eles e podemos encontrar soluções juntos.
Essa abordagem aumenta a motivação, após demonstrações malsucedidas planejadas, a responsabilidade pelo trabalho aumenta. Se antes os desenvolvedores preparavam o suporte para a demonstração em cinco minutos, agora o fazem no dia anterior à demonstração e depois polem os solavancos restantes para tornar tudo super.
"Por que precisamos de levantamentos diários?"
A princípio, os colegas estavam céticos em relação a se distrair do trabalho habitual em reuniões de espera todos os dias. Mesmo que sejam mantidos online e precisem de apenas 10 minutos.
Ao resolver esse problema, o incentivo simbólico de uma pessoa que encontra uma linguagem comum com a equipe ajuda. Certa vez, por uma questão de diversão, eu disse que marcaria no calendário aqueles que se levantaram e começou a colocar vantagens. O resultado foi inesperado e o efeito foi perceptível após um sprint. Não querendo ser bombardeados, os próprios desenvolvedores chegaram a ficar de pé. Chegou a se tornar uma piada comum: agora eles estão ameaçando colocar um sinal negativo para mim quando não posso participar de nenhuma reunião.
Muitas pessoas pensam que as reuniões do scrum levam muito tempo. Basta calcular aqui se é realmente assim. Temos 40 horas semanais em 40. Isso não é muito para organizar o trabalho e manter-se atualizado com tudo.
Se toda a equipe não quiser ir a reuniões de stand-up e as reuniões em si não forem muito ativas, isso é um sinal de que o trabalho está dando errado. Como se a reunião estivesse atrasada por mais de 15 a 20 minutos. Uma história sobre suas atividades e planos em uma pessoa não deve levar mais de um ou dois minutos.
Mais uma regra está relacionada ao gerenciamento de tempo. Se a discussão da tarefa demorar mais de 30 minutos, paramos. Isso significa que não tivemos tempo para desenvolver a tarefa, que ela está mal decomposta e ainda requer tempo. Vale a pena prestar atenção. Estabelecemos um limite de 30 minutos para nós mesmos - cada empresa precisa estabelecer sua própria barreira.
Lista de pendências incompreensível
O sucesso do Scrum depende principalmente de um planejamento claro. É necessário determinar quantas tarefas devem ser avaliadas e descritas e quais podem ser simplesmente adiadas por enquanto. Não tente cobrir tudo de uma vez. O desenvolvedor precisa entender o que ele fará nos próximos dois sprints. Por períodos mais longos, basta uma idéia aproximada - quanto mais tarde, menos detalhes.
Microgerenciamento inadequado
O que os desenvolvedores estão fazendo hoje? O que acontecerá amanhã? Acontece que os gerentes fazem essas perguntas regularmente. Conseguimos explicar à nossa administração que todos os pontos de interesse podem ser encontrados em nosso conselho de administração ou consultando diariamente. Não há relatórios especiais com tabelas e monitoramento de tarefas em Jira. Conseguimos compactar esse microgerenciamento para reuniões semanais com a gerência, onde relato as tarefas específicas executadas pela equipe.
Algo quase nunca escrito sobre
Finalmente - há um problema claro, cuja menção eu quase nunca encontrei. Não é necessário tentar combinar o scrum master e o proprietário do produto. O último está construindo uma unidade de negócios, trabalhando em um backlog e executando KPI. Ele está interessado no sucesso do produto e tenta se aprofundar em tudo - portanto, começa a marcar consultas, discutindo alguns detalhes. Em geral, ele se carrega com várias funções, por causa das quais simplesmente não resta tempo para o backlog.
Isso aconteceu comigo. Organizei reuniões, stand-ups, resolvi os problemas dos membros da equipe. Por esse motivo, o backlog não foi resolvido, ou seja, simplesmente não havia tempo para a atividade principal. Agora encontramos um gerente de desenvolvimento que tem autoridade sobre a equipe e também começamos a desempenhar as funções de um scrum master, pois ele tem mais experiência trabalhando nessa estrutura. Agora pude me afastar do Scrum e me concentrar totalmente nas tarefas do proprietário do produto, que, por sua vez, deveria pensar nos requisitos. Sem bons requisitos, não haverá bom produto. Como resultado, a carteira de pedidos começou a melhorar, os colegas entenderam como seguiremos em frente.
À primeira vista, Scrum parece muito simples, mas ainda tem muitas armadilhas. Trabalhamos nessa estrutura há quase um ano, mas só agora começamos a avaliar mais ou menos claramente nossas habilidades, começamos a aumentar a velocidade do desenvolvimento.