Top Posts

Série Continuous Integration: Reiniciando Jenkins sem reiniciar

Continue lendo

Série Scrum Remoto: Time Evoluindo Sprint 3

Posted by camilolopes | Posted in Agile/Scrum/TDD, Series | Posted on 01-05-2014

0

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

Related Posts with Thumbnails

Write a comment