Top Posts

Série Git:Importando Projeto do GitHub para Eclipse via Egit

Continue lendo

Série Scrum Remoto: Primeira Sprint – falhou e agora?

Posted by camilolopes | Posted in Agile/Scrum/TDD, Series | Posted on 28-04-2014

0

Olá Pessoal,

Mais um post da série Scrum Remoto e chegamos ao final do primeiro Sprint que falhou. Mas por que? Alguns podem pensar porque o time estava remoto. Será?

Lets go…

Começamos falhando

Fico feliz que a gente não começou diferente de alguns projetos Scrum que falham no primeiro Sprint. E umas das razões que já vi em projeto presencial com Scrum foram:

  • Estimativas;
  • Não saber a velocidade do Sprint;
  • Time aprendendo Scrum;
  • Blockers longos;
  • Comunicação;
  • Não saber o timebox do Sprint.

Quando falham em um projeto com Scrum remoto, muitos vão dizer o seguinte: “falhou porque o time não estava presente fisicamente”. Será? Ou estamos buscando uma desculpa para não enxergar os erros?

E porque falhamos aqui na ITSLabs?     

Falhamos por todos os problemas que há no Scrum Presencial, exceto um. O de comunicação. Por incrível que pareça, por estarem remotos o time se comunicava com maior frequência via chat, call, fazendo share da tela e pedindo ajuda do outro. Tudo isso em tempo muito curto comparado com o que já vi em times presenciais. O problema real, foram  os demais pontos e isso eu já esperava, na verdade eu ficaria muito surpreso se a estória e o Sprint fosse entregue com qualidade. Um dos pontos foi não saber qual o tamanho do Sprint ideal. Começamos com 2 semanas e não deu muito certo, pois parte do time ficou ocioso e houve desperdício de tempo no final do Sprint 0. Tentamos de 1 semana, e a Sprint falhou porque o time teve bastante blocker e tinha que parar a task em development para resolver e depois retornar para task e alguns blockers duraram quase 6hrs do dia. Ruim, heim? Fora quando tinham que ser dois devs trabalhando no mesmo blocker para tentar resolver rápido, ai era pior eram dois membros parados em função de um problema.

O final

Isso já sabemos, né? Todos com aquele feeling ruim por não terem entregue o Sprint como acordado e pensando em como resolver os problemas. De qualquer forma foi uma Sprint rica de aprendizado. O time se comportou muito bem em se adaptar e responder aos problemas mais criticos e ajudar o outro colega que ficou blocker. O espírito de team e foco no projeto e não na “minha entrega” era algo forte e isso me deixou muito feliz ao término do Sprint.

Veja como ficou o gráfico do Sprint 1:

scrumremotoburndownsprint1

 

E como foi a sua primeira Sprint ? Comente sua experiência… :)

Abraços, see ya!!

Série Scrum Remoto: Terminado a Sprint 0

Posted by camilolopes | Posted in Agile/Scrum/TDD, Series | Posted on 25-04-2014

0

Olá pessoal,

Vamos ver hoje como foi a Sprint 0. Será um post rápido.

Lets go…

Como foi o Sprint 0

Conforme já falei em outros posts da série, foi nessa Sprint que definimos o Sprint 0 como uma Sprint de setup e discussão sobre quais tecnologias eram ideais adotar para o projeto. Como por exemplo: vamos de Sprint MVC ou Vraptor? Fora outras discussões de infraestrutura, arquitetura inicial, etc. Claro que não definimos tudo aqui e pronto, mas o básico que precisamos para iniciar o Sprint 1, visando o baixo risco de ter que trocar amanha a versão ou framework escolhido por algum motivo específico, então vários pontos são analisados e discutidos com a equipe. Outro ponto interessante é que muitos membros do time criam POCs para mostrar o quanto a tecnologia X que ele defende pode ajudar. A única coisa requerida é que você apresente argumentos que convença o time da escolha da tecnologia, se conseguir ela é adotada e não precisa entrar em processo nenhum (que vai para “aquele cara” que em algumas empresas é considerado “o deus” que vai ter que dar o ok). Removi isso, não existe isso aqui. Odeio qualquer coisa que seja engessada. É o time técnico que define. Claro, nada impede de consultar especialistas, etc, mas no final é o team que decide as tecnologias que eles vão trabalhar nos próximos N Sprints que estão por chegar. O case aqui é de um projeto que participei em julho/2013.

A seguir o Burndown do Sprint:

scrumremotoburndownsprint0

Podemos ver que foi um Sprint bem apertado, mas a equipe conseguiu entregar bem na trave. Então concluímos ela acreditando que tudo que foi entregue já nos permite começar a Sprint 1 e meter a mão na massa na primeira estória. Vamos ver o que acontece no Sprint 1.

A retro do Sprint 0

Fizemos a retro usando a realtimeboard. Encontrei essa ferramenta por acaso e achei muito bacana para time remoto. Uma das funcionalidades que acho show é não precisar compartilhar a tela e a atualização é em tempo real para os convidados. Possui um chat e na versão free permite criar tres projetos privados. Olha o que rolou:

 scrumremotesprint0retro

Vou ficando por aqui. Espero que tenham gostado do post.

Abraços, see ya!!