Já faz um tempo que deixei de aplicar o Scrum solo no ambiente de trabalho, pois felizmente na empresa que atualmente presto serviço usa Scrum , mas antes de mudar para cá tive uma segunda experiência que decidi compartilhar.
Aposto que muitos de vocês voltaram aqui depois da minha primeira gloriosa tentativa de Scrum Solo e querem saber o que deu errado.
Bom, não foi um fracasso completo, mas foi muito diferente do que eu esperava.
Ao contrário da tentativa passada, essa era uma alteração na aplicação mais complexa e era possível dividi-la em duas versões que o usuário poderia usar, daí eu resolvi dividir em dois Sprints de duas semanas.
Nesse primeiro quadro tudo bem, parece bem, sobre controle, as histórias divididas em pequenas tarefas nos post-its, distribuídas de acordo com sua situação: pendente, em andamento e feito.
Aqui estamos teoricamente no final no primeiro Sprint, mas observe o quadro atentamente, de cara notamos duas coisas :
- existe um item em andamento ainda!
- o gráfico de convergência mostra uma coisa terrível: a coisa não anda há vários dias!!
Com essa situação eu fui obrigado a adiar o início do segundo Sprint para terminar o item pendente, o que deixou a coisa bem desproporcional e atrapalhou a conclusão da alteração.
No final das contas, vejam como ficou estranho, o segundo Sprint ficou muito menor que o primeiro e notem ainda que o gráfico de convergência mostra que apesar do projeto ter sido entregue, ele sofreu um atraso.
O que aconteceu?
Usamos uma metodologia ágil e o projeto atrasou?
Quem é o vilão da história?
Obviamente que ninguém menos que eu mesmo! O grande erro foi não dividir as tarefas adequadamente, o que fez com que uma tarefa no meio do caminho fosse tão grande que atrapalhou os dois Sprints.
Bom, o erro é somente completo se você não aprende nada com ele, portanto as lições aprendidas foram:
- pense muito bem em cada detalhe de história e divida bastante as tarefas para não ter surpresas no futuro
- não deixe acumular as pendências como eu fiz, o certo é terminar o Sprint conforme planejado, dividindo aquela tarefa pendente em outras menores e decidir o que vai entrar nessa iteração e o que fica para a próxima
agosto 1st, 2008 at 9:59 am
Olá Boaglio !
Fiz uma entrevista em Ago/2007 ai na Sumus, lembro até que citei que acompanhava o seu blog … coisa de louco não !?!
Agora sabendo que estão usando Scrum, confesso, que estou arrependido … mas sucesso!
agosto 4th, 2008 at 11:12 pm
É, Boaglio, acho que o seu maior erro foi não dar por encerrado o primeiro sprint na data estipulada. Scrum é time-boxed, logo o sprint deveria ter sido encerrado mesmo com a tarefa em andamento. Ela entraria no planejamento da segunda iteração…
Mas bem legal a sua experiência. Parabéns por compartilhar!
agosto 5th, 2008 at 2:30 pm
Aê Boaglio… não sabia que vc está na Sumus. A Aspercom que treinou o pessoal aí… abraços!
agosto 21st, 2008 at 9:52 am
Acho que você deveria ter encerrado o Sprint na data prevista e as tarefas “Pendentes” e “Em Andamento” deveriam ser replanejadas no Sprint seguinte.
Pergunta: Você conhece alguma ferramenta (de preferencia em php) que automatize o quadro de “to do”, “doing” e “done” ?
Abraços!
agosto 24th, 2008 at 11:48 pm
Adolfo/Augusto, realmente eu precisava quebrar a coisa em pedaços menores, vivendo e aprendendo!
Augusto, não conheço nenhum software que faça isso, mas não duvido que até exista um plugin do eclipse que faça isso, entretanto aconselho você a investir alguns reais e comprar um pequeno mural, além de não precisar fazer ALT-TAB toda hora, será muito mais fácil e acessível para você alterar e mudar os post-its de lugar. É incrível como algo tão simples é ao mesmo tempo tão eficaz.