Olá! O post de hoje é diferente dos que estou acostumado a escrever. Ele não tem regras bem definidas e a minha intenção é que ele seja uma espécie de bate-papo com vocês. Espero que gostem!

Há duas semanas atrás tivemos na GPE uma palestra do Phil Calçado, da SoundCloud. Phil trabalha na Alemanha e aproveitou a sua passagem no Brasil para fazer a divulgação do SoundCloud por aqui, ao mesmo tempo que tenta "recrutar" talentos para irem trabalhar lá com ele (caso você tenha interesse, olha a oportunidade aí). 

Phil gentilmente palestrou sobre "Erros que eu cometi desenvolvendo software". Na verdade seria injusto com o Phil chamar de palestra, pois o mesmo fez questão de frisar que sua intenção era ter conosco uma conversa bem informal, compartilhando suas experiências.

Uma das situações vivenciadas durante o seu dia-a-dia de desenvolvimento foi mais ou menos assim:

Imagine a tela de um portal, composta por uma série de widgets. O cliente desejava uma funcionalidade que permitisse a liberdade da disposição desses widgets pela tela, no melhor estilo clicar e arrastar owidget para onde quisesse. Quando questionado o porquê dessa funcionalidade a resposta era: "Todo mundo quer liberdade!".

 

O plano original era uma série de 15 widgets e 4 páginas, com uma estimativa de 3 meses para realizar o desenvolvimento e um custo monetário de X.

Ao invés de executar esse plano a equipe de desenvolvimento decidiu adotar o "minimal value product", ou seja: "Vamos construir algo menor, mas que tenha valor, e aí vemos o que acontece!".  Esse novo plano consistia numa série de 5 widgets e 2 páginas, reduzindo a estimativa para 2 semanas de desenvolvimento e um novo custo, cerca de 6 vezes menor que X.

O resultado foi: Nenhum usuário moveu um widget sequer do seu lugar original!!! Após um certo tempo cerca de 30% de usuários fizeram uma requisição: incluir 2 novos widgets.

Ou seja, a tomada de decisão optando pelo produto menor foi crucial para que a execução do desenvolvimento num tempo inferior e a um custo reduzido.

Levando esse caso para o nosso contexto Scrum podemos traçar um paralelo com o papel do PO e SM. Durante a reunião de planejamento o SM precisa estar atento para intervir nos momentos em que se faz necessário. Tomemos como exemplo uma história proposta pelo PO que a equipe discorde. O ideal, nessas situações, é que a equipe possa expor a sua visão sobre a história e o SM deve saber conciliar a opinião da equipe com o requisitado pelo PO para que se chegue numa decisão única que agrade a todos e que seja a melhor. Essa decisão pode ser a mudança na descrição da história, a divisão em mais de uma história etc.

Ainda falando sobre decisões da equipe e do SM, recentemente no projeto em que trabalho tivemos a inclusão de uma nova história no meio da Sprint. Como lidar com essa nova história, que não havia sido planejada no início da Sprint? A história foi estimada pela equipe e possuía um custo relativamente alto para o ponto da Sprint em que estávamos e, segundo o PO, essa história seria prioritária.

Estávamos no meio de uma Sprint, então é claro que possuíamos histórias em desenvolvimento. O que fazer então com essas histórias? E as demais? O papel do SM nesse caso é reunir-se com a equipe para adotar uma estratégia de ataque. E foi o que aconteceu! Com o uso do Quadro de Tarefas do Scrumhalf fica visível as histórias em andamento, as que não foram iniciadas e onde a equipe estava trabalhando. Eis os fatos: 

  • A equipe avaliou que a havia condições de se implementar a nova história, mas para isso seria preciso dedicação exclusiva a ela;
  • As histórias em andamento não poderiam ficar da maneira que estavam. Teriam que ser finalizadas;
  • Ainda existiam histórias que não haviam sido iniciadas.

E eis a solução:

  • Parte da equipe fica responsável por implementar a nova história (agora, prioritária);
  • Outra parte da equipe fica incumbida de finalizar as histórias em andamento. Após isso, passam também a trabalhar na nova história;
  • As histórias que não foram iniciadas ficam para a próxima Sprint (menor prioridade).

Com essa estratégia foi possível a finalização da nova história e também das histórias que estavam em andamento. O custo para a Sprint foi o adiamento das histórias de prioridades mais baixas para a próxima Sprint.

Bem, chega de bate-papo por hoje! Um abraço e até o próximo post (formal ou informal?!?)!