Márcio SenaHoje em dia, ver uma equipe de tecnologia seguindo a estrutura Scrum não é novidade. Inclusive, você sabia que ele é o framework mais utilizado no mundo todo? E não deve ser surpresa que ele é majoritariamente utilizado no setor tech. Se você ainda não conhece, a ideia principal do Scrum é trabalhar em iterações curtas e ininterruptas. Isso proporciona flexibilidade e um ciclo de feedback constante com as principais partes interessadas. Mas você já se perguntou se é possível melhorar o Scrum? Já fizemos muitas experiências para ajustar o Scrum às nossas necessidades e fizemos algumas melhorias que podem ajudar outras pessoas também. Quer ver?
Check-in de cards, em vez de pessoas
Todos os livros do Scrum orientam sobre como realizar a reunião diária ou, em outras palavras, a Daily. A equipe se reúne ao mesmo tempo, no mesmo local, e fornece atualizações. Cada membro da equipe deve responder às perguntas:
- O que eu fiz ontem?
- Em que trabalharei hoje?
- Há algo que esteja me bloqueando?
Três perguntas simples e que trazem, geralmente, respostas simples. O problema dessa abordagem é que ela se concentra nos indivíduos e não na meta da equipe. Cada pessoa compartilha suas realizações, especialmente devs que explicam detalhes técnicos que nem todos entendem. E a cerimônia pode se transformar em uma rotina de atualizações que ninguém ouve.
Em vez disso, precisamos nos concentrar no progresso, ou seja, comprometer-se com algum trabalho no início do sprint. Esse se torna o foco central: como a equipe vai realizar essa tarefa. Agora, o que importa mais é a atualização de cada problema no sprint planejado, de forma que impacte o time como um todo. Portanto, o conselho aqui é começar a perguntar sobre o status de cada card, o que dá um senso de progressão. Todos os dias, a equipe ouvirá as atualizações de cada tarefa, entendendo como isso impacta o todo.
Rascunho de sprints
O backlog consiste nos cards prontos para serem trabalhados. Entretanto, em cada planejamento de sprint, a equipe precisa classificar a prioridade. Quais cards devem ser feitos em seguida e quais devem ser feitos depois? E o que fazer com os bugs? O roadmap evidencia como o trabalho está sendo realizado em um nível estratégico. Mas é importante uma visão geral do trabalho para alguns sprints futuros.
Portanto, existe uma solução simples: ter sprints preliminares. Por exemplo, crie um cronograma das tarefas que você deseja entregar nas próximas duas semanas. Em seguida, organize as outras tarefas que você deseja realizar após este período.
Agora, a equipe pode ver seu plano para os próximos sprints. Essa abordagem nos permite planejar o trabalho nas mudanças do produto juntamente com os bugs e a dívida técnica. O principal responsável cuida dos recursos, enquanto devs organizam as tarefas de manutenção. E os planos de curto prazo ficam visíveis para todos.
Dica final
Falando em planos de curto prazo, em vez de mirar em processos longos, estabeleça junto com a sua equipe objetivos que podem ser seguidos dentro de pouco tempo, sempre com um limite de duas semanas. Assim, o seu backlog não fica cheio de demandas que só poderão ser tocadas daqui muito tempo. E desse jeito você também mantém sob controle tarefas possíveis e menores que impactam o todo de forma bastante significativa, em vez de investir tempo em demandas enormes que quase nunca caminham.
Para mais dicas como essas, entre na nossa Comunidade por aqui e converse com outros e outras profissionais de tecnologia. Lá, você pode entender mais sobre frameworks como o Scrum e até mesmo discutir questões do dia a dia de devs, além, é claro, de receber nossas vagas de trabalho em primeira mão.
[Esse texto foi inspirado em um artigo do perfil Better Programming]
