13 de abril de 2010

Scrum Solo? - Conclusão

Então demorei para colocar esse post, primeiro porque dia 17/04 haverá o #CaféComJava uma espécie de reunião para desenvolvedores que comecei a pensar e o pessoal topou, segundo pela falta de tempo mesmo, a corrida com um novo projeto, porém não vamos esquecer do projeto que fiz utilizando Scrum Solo que comecei no POST anterior: link

Bom vamos lá, o projeto saiu como o esperado, porém tive muitas surpresas, principalmente que como estava organizando, definindo prioridades acabava terminando em 1 semana ou menos, o que me animou mais ainda.

Este projeto agora está com outras pessoas e no momento minha parte está concluída, mas caso ele volte com novas features estarei pronto.

Primeiro porque como sobrava tempo junto com outros da equipe definimos uma arquitetura melhor de um modo que qualquer programador Java entendesse e conseguisse dar manutenção, facilitando a refatoração das partes desenvolvidas, estudei o sistemas e coisas comuns e padrões novos e mais eficazes foram implementados, o que garante que este sistema será produtivo, simples tanto para o programador como para o usuário.

Bom mas deixando Arquitetura e Refatoração de lado, vamos ao SCRUM:


Primeira Sprint após o post no blog:

Poucas coisas eu tinha no backlog, alguns problemas com umas querys e meu RSA deu pau (isso sim me preocupou, fiquei 2 dias sem computador por causa de instalação do RSA e programas da IBM).

Bom resolvido o problema do RAD em 5 dias ficou assim:

Ótimo, a empresa toda tirando um sarro por causa do Quadro e dos Post-its mas o primeiro Sprint Solo funcionando e faltando um prazo de 3 dias para acabar, levantei no mesmo dia o segundo Sprint após mostrar que o primeiro estava funcionando, documentado e o código além de limpo, estava comentado e totalmente POO.
No segundo Sprint era um módulo bem mais complicados com muitas regras de negócio e acabei colorindo mais, coisas em verde (faceis), amarelas (médio), rosa/laranja (difíceis ou problemas), meu quadro estava assim:
O Calendário foi que anotei os dias de Sprint, mas eu utilizava outro, pode ver que este está todo riscado, como eu mesmo acabei tendo que definir as Sprints e etc, peguei dois calendários para auxíliar, um quando eu ia para reunião (este) e outro que eu ia dia a dia marcando (final do artigo).
Outra observação é que como o quadro era pequeno, eu precisei mudar algumas posições.

Mas em poucos dias ele ficou assim:


E notei que quando terminei esse Sprint faltavam 3 dias para o fim do prazo, o histórico que tinha que documentar eu acabei pegando todos os Post-its e colando no caderno como se fosse um histórico, caso alguém viesse para me ajudar poderia mostrar tudo que já havia feito, métodos, problemas, soluções, etc, sei que temos que jogar fora os post-its, mas no meu caso eu estava sozinho e se alguem chegasse e perguntasse o que estava feito, teria a resposta em mãos =) Como meu quadro é pequeno, só me deixaram comprar um quadro pequeno, se fosse maior não deixariam eu utilizar na minha mesa e em lugar algum =(

Meu caderno:


Bom alguns desenvolvedores começaram a curtir, alguns falaram de usar post-its virtuais, alguns projetos que montam o Quadro no PC, mas o fato é que sem ser visual não é a mesma coisa, não dá impacto e essa ideia de ninguém saber o que você faz... não concordo, acho que todos os envolvidos tem que ver.

Bom o terceiro e quarto (último Sprint) foram os piores, pois eram módulos complexos e com muita coisa legada que refatorei, mas também ocorreu tudo no prazo.
O Dia final era 29/03, foi entregue dia 27/03.

Espero que minha experiência com Scrum Solo tenha ajudado aqueles que querem implementar Scrum mas por causa da Cultura e/ou pessoas não podem, mas experimentem aplicar o Solo, é simples, fácil e um quadro não custa 20,00 reais rs
  
Observação Final: Meu caro amigo Boaglio não usei o Gráfico de Burndown pois o quadro é minúsculo, mal cabem os Post-its, mas assim que tiver um quadro maior eu farei completo.

Eduardo Bregaida

4 comentários:

Celso Martins disse...

Muito interessante a sua experiencia, Bregaida. Eu estou pensando em usar o Scrum na reconstrução que estou trabalhando, mas quero participar do workshop primeiro para decidir depois.
Como está a cobertura de testes deste sistema? O desenvolvimento foi orientado a testes?

Abraços e parabéns pelo sucesso.

Eduardo Bregaida disse...

Então, estamos testando de um jeito bem trash criando classes na mão e não JUnit, mais por causa das conexões com CICS e MainFrame a maioria das coisas ficam lá, basicamente é exibir as informações e cadastrar, por isso a regra de negócio fica nos MainFrames da vida, mas ainda vou me dedicar a ver um jeito de conseguir usar JUnit e testar a parte Java, mesmo que eu não tenha que fazer as documentações para receber os resultados do Main Frame.

Celso Martins disse...

Tenho sido um pouco psicopata com relação aos testes nos últimos meses.
Não acredito na bala de prata, mas acho que o TDD chega bem próximo do mundo ideal.

Eduardo Bregaida disse...

Concordo, aplicar testes é essêncial para qualidade de Software.