Congresso de TI – 3ª edição eu vou

Camilo-Lopes

 

olá Pessoal,

Mais uma vez fui convidado pelo Rafael um dos organizadores do Congresso de TI   para participar da Terceira edição. Realmente fico muito feliz pelo convite em poder compartilhar  algumas horas do meu dia  falando de um assunto que possa ajudar outros colegas. E dessa vez  vou falar sobre Scrum. Não será sobre o que é Scrum, isso tá lotado na internet.  E sim falar um pouco da experiência que venho tendo desde 2013 com Scrum Remoto. Iai rola ou não rola ter o time remoto e rodar Scrum? Quais as diferenças de Scrum presencial? O que muda? É isso que vou falar o que vivi e vivo hoje no meu dia a dia entregando produtos rodando Scrum remoto com clientes em São Paulo Capital e desenvolvedores que estão de sua casa no interior do estado.

Corra e faça sua inscrição para garantir sua vaga. Lembrando que o evento é gratuito e online.

abraços, see ya!!!

 

Série Scrum Remoto: Time Evoluindo Sprint 3

Olá Pessoal, 

Mais um post da série Scrum Remoto e hoje estamos na Sprint 3. O objetivo é mostrar para vocês como foi a nossa Sprint, o que aprendemos e o mais legal é o fato de que ser remoto não impactou no objetivo. Então, para quem fala que times distribuídos com Scrum não funcionam, é importante ver o que tem de errado, mas não buscando colocar problemas no framework, ferramentas etc. Há outro fator envolvido, chamado de pessoas. 

Let’s go…

 

Scrum Remote Team Sprint 3 

Esse Sprint não foi um dos melhores para o time, porém melhor que os outros dois, uma vez que o time está aprendendo e pegando o jeito de trabalhar Agile, então estou considerando até um bom resultado. Conforme já falei em outros posts da série, a equipe nunca trabalhou com Agile, estavam acostumados sempre no lado “o meu está pronto” ou “eu sou desenvolvedor e não tenho que realizar teste se não for em minha máquina, quem faz isso é um tester”. E do lado técnico, o pessoal também estava aprendendo algumas práticas, como TDD, CI etc. Aqui todos metem mão na massa desde code até infraestrutura, o projeto é de todos e temos vários chapéus para ir usando até o final do Sprint.  Há desenvolvedores que no Sprint 1 nem sabiam para que servia o Jenkins, e hoje no Sprint 3 já mexem com a ferramenta, apresentam plugins que podem facilitar o processo de CI, etc. Vamos agora ao resultado: 

Iai, como foi o Sprint 3? 

Não pior que o Sprint 2, mas longe ainda de um Sprint ideal. A seguir o burndown nos fala isso. Vamos analisar 

<img sprint3handson> 

sprint3handson

O team prometeu uma entrega de 16 pontos. Se olharmos o Sprint 2, é uma capacidade maior do que havia entregado. 

 

sprint2handson

Tudo começou bem na primeira semana do Sprint, na verdade mandaram muito bem, quase mataram o Sprint rápido demais. Eu já havia suspeitado que tinha algo de estranho ai, mas preferi não comentar e ver o que ia acontecer. Quando chegou no dia 01/09, por algum motivo alguma estória voltou e faltavam poucos dias para terminar o Sprint, a equipe trabalhou duro e conseguiu fazer entrega no mesmo dia e nos próximos, mas observe que eles começaram a entregar somente faltando poucos dias do término do Sprint e no último dia de desenvolvimento, trabalharam duro para entregar. 

Velocity Chart

sprinthandsonvelocity

Foi bom?

Se comparar com a Sprint 2 e Sprint 1 foi um avanço muito bom da equipe. Percebo que agora eles estão pegando o jeito da coisa, e claro que há pontos para melhorar, mas eu sei que não é a mesma equipe que tinha no Sprint 1. É uma equipe melhorada. Tivemos um risco alto de acontecer alguma coisa ali no final e não entregar nada, ou pior, demoramos demais para entregar 5 dias depois do Sprint, ou seja, se temos 9 dias de desenvolvimento só entregamos quando já passamos da metade do tempo, não é muito bom isso. Exceto se está seguro que a estória não pode voltar e aconteceu isso: ela voltou, mas o time soube como contornar o problema e resolveu rapidamente entregando. 

Resultado

Saímos da Sprint 3 muito feliz com o resultado, pois tínhamos  no passado só tempestades, mas parece que está passando, porém o céu ainda não está ensolarado para o pessoal poder ir para praia. Aqui na ITS gosto muito que o team aprenda com eles mesmos, apesar de que algumas situações eu consigo ver que vai acontecer algo, mas prefiro que aconteça. Isso pode ser ruim para o negócio da empresa, mas para o aprendizado do team considero superimportante, pois vai impactar no negócio e no projeto. Às vezes há perdas financeiras por uma questão de contrato, mas não me importo muito com isso, até porque quando a ITS nasceu não foi por dinheiro, e sim por paixão pelo que fazemos. Não posso limitar nossos profissionais por uma questão financeira. Claro que vamos fazer um bom uso disso e sempre analisar para que não aconteça o pior de um drop do projeto. O pior é que um drop do projeto não é a grana envolvida e sim a oportunidade de aprendizado que deixamos de ter. Acredite ou não é a nossa cultura. Qualidade técnica é mais importante que seguir um contrato comercial. E mais interessante aqui é que quem faz parte do nosso comercial concorda com isso. Não temos aquela briga entre um grupo de nerd com business.

Vou ficando por aqui, e espero que tenha gostado desse post. 

 

Abracos, see ya!!

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

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

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!!

Scrum Remoto: Praticando Planning Poker

Olá Pessoal,

O post de hoje é bem mais uma dica. Mas a pergunta é: como fazer estimativa se meu time está remoto? Ou melhor, como se beneficiar do planning poker?

Lets go..

Starting…

Aqui na ITS temos projetos presenciais e remotos, mas a maioria é remoto, ou seja, o time trabalha de casa. Depois farei um post sobre como é o nosso trabalho remoto. Voltando ao problema, como fazer as estimativas com planning poker se o time está remoto? Pesquisando sobre alguma ferramenta que pudesse nos auxiliar, encontrei http://www.planningpoker.com/ realmente sensacional. Além de ser free, é muito simples de usar. Aqui na ITS estamos usando a ferramenta e está sendo uma boa experiência.

Como funciona?

  1. Você faz o cadastro, que é simples e rápido;
  2. Você escreve a estória;
  3. E dá um start;

As cartas aparecem e você escolhe a sua estimativa. Quando todos estimarem, o resultado aparece e o time discute. Se for aceito, a estimativa é associada com User Story.

Simples, não?

Era isso que queria compartilhar com vocês, mais uma experiência com gerenciamento de projeto Scrum Remoto.

Abraços, See ya!!