Pra finalizar essa série, a retrospectiva.

Resumindo nossas reflexões, a própria equipe (novamente os problemas emergiram naturalmente), admitiu que estava falhando nas reuniões diárias, e que isso estava gerando problemas de comunicação.

Observamos que precisamos separar um tempinho para os refactorings e a documentação no código ainda não está legal. Anotamos num outro quadro novamente. A parte considerada positiva tinha sido a especificação dos testes funcionais para aprovação das estórias. Vamos escrevê-los no verso dos cartões agora.

No planejamento, as estimativas foram bem mais precisas. Todo mundo estava bem mais consciente do que deveria ser feito para desenvolvermos cada estória. Coisas que achávamos ser pequenas foram se mostrando complexas. Pudemos encontrar diversos “efeitos colaterais” de algumas alterações. Considero que vamos mexer novamente numa parte complicada do sistema, mas dessa vez estamos melhor preparados.

Um ou dois cartões não deram conta do tamanho das estórias e acabaram sendo divididos. Foi melhor assim. Com a divisão, as estimativas ficaram mais precisas e realistas. A divisão de tarefas mais clara. Chegamos ao final da reunião exaustos com 41 pontos estimados e 2 cartões não estimados. Não haveria problema nos 9 pontos restantes não estimados nesses 2 cartões pois, se chegarmos neles, os estimaremos e dividiremos de acordo com o que der pra fazer no prazo restante. Essa atividade é feita na reunião semanal.

Outra adaptação foi que rompemos a seqüência de Fibonacci em alguns cartões. 13 pontos era demais e 8 de menos. Alguns ficaram com 10. Tínhamos segurança suficiente pra quebrar essa regrinha. Vamos ver no que vai dar.

E é isso. Há um clima de otimismo geral a equipe, mas não podemos nos contaminar por ele.

O desafio agora é nos mantermos realistas. Já se fala em fazer mais que o inicialmente pensado para o projeto, mas não podemos nos comprometer com isso. É perigoso. O projeto tem ido bem porque a expectativa está bem gerenciada. Um otimismo desse pode frustrar a todos. Temos que manter o pé no chão. “Esperar pelo melhor e se preparar para o pior”.

No mais, agradeço o feedback e participação de todos que acompanharam essa série até aqui. Tenho falado com o pessoal e tem bastante coisa legal vindo por aí. Se quiserem acessar os posts do blog antigo da SEA, acessem http://www.seatecnologia.com.br/blog

Assine nosso feed e acompanhe o que andamos fazendo por aqui!

Grande abraço,

Willi

 

(Se chegou atrasado e quiser rever a saga desde o começo, clique aqui)

Novamente nossa retrospectiva foi muito boa. Inicialmente demos uma repassada na iteração, avaliando por que tudo tinha ido tão bem dessa vez. Avaliamos se essa situação se manteria, ou se foi só uma “sorte”, proveniente das funcionalidades. Os fatores que influenciaram eu já falei, mas repito aqui: na primeira iteração, ninguém sabia de nada do código, não tínhamos um ambiente totalmente preparado e estávamos mexendo no coração do sistema.

Na segunda iteração, as barreiras iniciais estavam todas vencidas e estávamos prontos pra correr. A simplicidade das funcionalidades também colaborou. Claro que o erro da segunda iteração não gerou desconforto algum, mas novamente queremos melhorar nossos planos. Sempre buscaremos isso.

Resolvemos mexer na duração da iteração. Isso não é boa prática. Não recomendo, mas precisávamos diminuir o tempo dessas reuniões gerenciais relativas ao tempo das iterações. Não teremos mais feriados no ano e queríamos dar um dia de folga como recompensa se fosse tudo bem. Quinzenalmente o custo disso seria alto. Queríamos também acertar cada iteração com o mês. Algo próximo da realidade do pessoal.

Acabou que nossa iteração 3 terá 5 semanas. Nossa velocidade agora foi acordada em 10 pontos por semana. Logo, priorizaríamos e estimaríamos 50 pontos dessa vez. Temos bastante trabalho pela frente.

Essa mexida no tempo e tamanho de iteração altera nossas noções, e deve gerar algum resultado diferente nessa iteração. Quando a terminarmos eu conto pra vocês. Outra coisa que deve afetar é que o Rafael arrumou uma bicheira, ficou de cama, não participou das estimativas nem da primeira semana da iteração.

O resto dessa reunião fica pro próximo post dessa série. O último.

Ah, se ainda não assinarem o feed, asinem pra acompanhar nossos posts! Tem mais coisa legal planejada aí pra frente.

Episódio VI

O planejamento da Sprint 2 saiu rapidamente. O tamanho seria exatamente o mesmo da passada. Teríamos os mesmos feriados nos mesmos dias e os mesmos problemas de expedientes. Já tínhamos as estórias que não tinham sido feitas na primeira iteração. Definimos que nossa velocidade era de 11 pontos por iteração. Eram os 8 pontos do cartão fatídico da iteração passada, e estimamos em 3 pontos as tarefas não planejadas que tivemos que fazer por conta dele.

Reavaliamos as estimativas das estórias passadas, deu muito pouca diferença, acho que só uma pulou de 3 pra 5 pontos. O resto foi acordado naturalmente sem muitas discussões. Estávamos bastante cuidadosos pra não errarmos como da primeira vez. A pontuação de cada estória agora era uma medida relativa pra equipe. Isto é, se aquela estoriazona que a gente tinha feito valia 8 ou 11 pontos, quantos pontos tinham essas outras? Essa noção é MUITO importante.

Juntamos os 11 pontos e na segunda seguinte iniciaríamos o desenvolvimento.

Vou falar pra vocês… Essa segunda iteração foi boa demais da conta! Eu me distanciei um pouco por questões externas, mas quando visitei a equipe na quinta-feira, quarto dia da iteração, estavam já acabando todas as estórias planejadas. O clima era ótimo e todos pareciam motivados e felizes.

Até aproveitei uns dias pra ir nadar…

Tô zoando.
A verdade é que a equipe andou sozinha muito bem. Finalizaram aqueles 11 pontos na primeira semana e na segunda finalizaram mais 7. Fazer essas funcionalidades não planejadas, sem enrolações, contribuiu muito pra confiança do cliente na equipe. Os fatores que prejudicaram a primeira iteração agora tinham sido todos praticamente superados. E agora não estávamos mais mexendo na parte complicada do sistema. Foi bem mais fácil. Por isso corremos tanto.

Só voltei na finalização da iteração. Não teve apresentação “oficial”, pois estavam apresentando constantemente as funcionalidades. Estavam gerando builds semanalmente, os bugs eram poucos e estavam sob controle, os problemas de padronização de nomes e granularidade foram resolvidos. Tudo indo muito bem.

Tão bem que foi decidido que o projeto começaria a ser colocado em produção nas Organizações Militares em breve. Isso é politicamente importante para o projeto obter mais verba e tals.

Vejam o trabalho feito. Este é nosso quadro do final da Sprint 2.

Os post-its “feitos” vão pra fora do quadro. O quadro é pequeno. Na primeira coluna temos nosso Product backlog. Os post-its são as tarefas decompostas das estórias. Estas são descritas em cartões.
Esse é o quadro depois da retrospectiva. Depois de limpar o que já estava pronto. A hora de jogar os cartões no lixo é toda especial. Todos ficam muito contentes ao jogar um monte de papel no lixo.

E esse é o Ten. Souto felizão e a equipe. Todo mundo satisfeito com o resultado.
No meio nossa mesa móvel de reunião. Essa mesinha tem muita estória pra contar… (Dã!)

A retrospectiva dessa iteração fica pro próximo post. Tá acabando já pessoal!

Episódio V

Nós fazemos uma coisa diferente do Scrum. No que eles chamam de Sprint Planning 2, cada estória é decomposta em atividades menores – tarefas, e cada tarefa é estimada. Ou então decompõem em tarefas de duração fixa - um dia cada.

Ao invés disso, nós temos reuniões semanais em que fazemos isso para as estórias que serão trabalhadas na semana. Acho isso muito bom pois permite que o aprendizado de cada semana sirva de entrada para melhorarmos a decomposição de tarefas e estimativas para a semana seguinte, e não tudo feito num só momento.

Só que… na Sprint 1… Não fizemos isso! :s
Marcamos bobeira nessa. Ficou um cartão de 8 pontos a sprint toda na coluna do “fazendo” (Temos 4 colunas: a fazer, planejado pra semana, fazendo e feito). Isso foi desmotivador, pois a equipe não percebia os cartões passeando pelo quadro pra ficarem prontos. Fomos anotando no próprio cartão novas tarefas. Descobrimos muitas novas tarefas: faltava estrutura de teste, faltava um monte de coisa. E o danado do cartão ficou lá parado até o final. Este foi um ponto negativo, que foi apontado na retrospectiva. Deveríamos, a partir de então, aumentar a granularidade dos cartões e post-its. E foi o que fizemos.

Pelas 2 semanas foram feitas reuniões diárias. Eu e o Bruno participamos bastante dessas reuniões no começo, pro pessoal pegar o jeitão da coisa. É importante essa atenção no começo para diminuir a dependência da equipe por gerência e/ou coaching. A equipe deve aprender que as reuniões são pra ela mesma, e deve aprender a se gerenciar.

Fizemos um bocado de testes automatizados nessa primeira sprint e resolvemos só esse primeiro cartão de 8 pontos, dos 21 planejados. Isso doeu.

Mas essa dor se mostrou boa na medida em que aprendemos com ela. Faz parte. Serviu de motivação para a iteração seguinte, que foi muito melhor. Apesar disso, no geral, achamos o resultado da iteração muito bom. Era o cerne do sistema, começo de projeto, vários fatores contra e mesmo assim terminamos com um pedaço importante do sistema pronto.

Ao final da sprint, conseguimos em um dia inteiro fazer a apresentação, retrospectiva e planejar a segunda sprint.

Na apresentação, o Ten. Souto achou uns poucos bugs bem bobos. Ficou a lição de apresentar antes, e o tempo todo, para que na apresentação final não tenhamos mais trabalho para as funcionalidades escolhidas.

Na retrospectiva, o ponto positivo em destaque evidenciado por TODOS foi o teste automatizado. Unitário e funcional. Usamos JUnit e Selenium. Todos gostaram de fazer, ficaram empolgados com os resultados, viram que ajuda em muito, viram a importância disso pra robustez do código e concordaram em continuar fazendo isso mais e mais. Este é um ponto sempre defendido pelo Bruno, e é o ponto de partida para a mudança das organizações em direção à agilidade. A frase dele é “Enquanto eu for o responsável técnico pelos projetos, não faremos nenhuma linha de código sem teste automatizado escrito antes”… Ou algo assim. ;)

Outro ponto positivo destacado foi a cooperação de todos. Chamaram isso de entrosamento. Todo mundo trabalhou como equipe, buscando objetivos comuns, independente de empresa ou força armada. Realmente algo bonito de se ver. Espero que esse blog não atrapalhe isso e continuemos assim.

Entre os pontos negativos, algumas pessoas admitiram falta de disponibilidade para cuidar do projeto, ainda não estávamos gerando uma build por semana, estávamos tendo falhas de comunicação (ma tarefa quase foi feita duas vezes), o código não estava documentado a contento, estávamos tendo problemas na padronização de nomes e queríamos aumentar a granularidade das estórias, ou dos post-its, pra vermos que algo está ficando pronto, pois uma iteração inteira com um cartão só foi realmente desmotivador (Esse é um fator psicológico interessante. Dá prazer trocar os cartões de lugar e mais prazer ainda em jogá-los no lixo).

Eu particularmente adorei essa retrospectiva porque não tive que chamar atenção de nada nem de ninguém. Não tive que ser o “chato”. Todos os problemas emergiram da própria equipe. É realmente uma mudança muito grande. Também mostra o quão responsável e madura é a equipe.

Discutimos como faríamos pra aumentar a quantidade de testes (Hoje temos um gráfico com a quantidade crescente de testes. Ao final da 2a iteração – um mês - estavam em 110 testes automáticos realizados a cada geração de build. Lembrando que começamos do zero!).

Como tratar os pontos fracos apontados? Não sabíamos direito como endereçar os problemas. Sabíamos que tínhamos que ficar mais atentos às questões apontadas, então, num pedaço do quadro, escrevemos alguns MANTRAS, que todos deveriam ler no começo de cada dia. Foi uma coisa engraçada. Os mantras diziam: “Vou me comunicar mais”, “Vou documentar mais o código”, “Vou apresentar o tempo todo”, e coisas assim. Para os demais, definimos uma padronização de nomes e anotamos no quadro, e aumentaríamos a granularidade das estórias e atividades para a próxima iteração.

O planejamento da Sprint 2? Continuo no próximo post.

Episódio IV

Voltando ao nosso primeiro Sprint Planning, já tinha sentado junto ao Ten. Souto, nosso Product Owner e levantado algumas estórias. O suficiente para a primeira Sprint. Ele entra em acordo com o Cap. Sant’Ana, do exército, sobre as funcionalidades e nos passa. Também avalia e gerencia o projeto.

Acordamos a definição de pronto, que era programado, testado, código documentado, apresentado e aprovado; e partimos para estimar as estórias em ordem de prioridade. Para essas primeiras estimativas, como não tínhamos nenhuma base anterior, usamos “dias ideais”. O tamanho da iteração foi definido em aproximadamente 2 semanas. Por que aproximadamente? Por conta de particularidades do expediente e feriados. Seriam 10 dias úteis. Consideramos 3 pessoas full-time, porque nem todos eram dedicados exclusivamente ao projeto (Não é uma boa prática, mas a realidade é essa.). Dava 30 pontos. Jogamos uns 70% de produtividade, que é uma taxa alta, mas jogar abaixo disso parecia incômodo para o cliente. Deu 21 pontos para as primeiras 2 semanas.

Para estimar cada estória, cada um se imagina trabalhando o dia inteiro sem interrupções, sem problemas, sem dependências, decompõe cada estória, pensa em todas as atividades até o PRONTO e anota um número pertencente à seqüência de Fibonacci. Depois todos mostram sua estimativa e deixamos que entrem num acordo sobre qual será a estimativa definitiva para a estória.

Assim foi nosso primeiro poker planning do projeto. Chegamos a 5 estórias e 21 pontos. Cada estória ficou anotada num cartão desse da foto, colado com uma melequinha no nosso quadro. Esse cartão tem um tamanho muito bom, pois podemos anotar a estória, estimativa, alguns lembretes para as tarefas, tipo requisitos especiais, efeitos colaterais, tabelas impactadas, etc. Dá pra anotar o caso de teste atrás, e se ficar coisa demais pra ele, é sinal de que devemos decompor a estória em 2 ou mais. Usamos cartão + meleca pois os post-its têm uma cola muito vagabunda e vivem caindo e dobrando. O cartão é melhor. Mais rígido e a meleca é reutilizável. A meleca é comprada em papelaria. Não é chiclete nem meleca de nariz.

Quando o Bruno perguntou ao final da reunião se todo mundo achava que dava conta de fazer aquilo tudo em 2 semanas (o tal comprometimento), o Rafael falou “Agora que está tudo na mesa tá parecendo tanta coisa!”. De fato era muita coisa, mas tínhamos que começar de algum lugar. Começamos assim.

Já sabíamos de antemão que não conhecíamos o código, não tínhamos muita base para estimativas e não conhecíamos a produtividade da equipe. Já sabemos pela literatura e por nossa experiência que é comum errar as primeiras estimativas, mas que o importante é ir melhorando com o tempo. O cliente também sabia disso tudo e também sabia que essas primeiras funcionalidades eram muito trabalhosas e o impacto era enorme, pois mexeriam no cerne do sistema. Por conta disso, já nos preparamos psicologicamente de que provavelmente erraríamos as 3 primeiras estimativas nos planejamentos, mas que melhoraríamos com o tempo e lá pela terceira ou quarta iteração estaríamos mais afinados. Setar essa expectativa é importante para não gerar frustrações depois.



Como foi a Sprint? Continua no próximo episódio…

Episódio III

Nossas experiências com metodologias ágeis estão rendendo bons resultados.

Hoje temos 2 projetos cujas expectativas foram superadas logo na segunda iteração. Interessante isso ter acontecido em ambos projetos e em ambos na segunda iteração, porque mostra justamente que há uma fase de aprendizado inicialmente, que foi rapidamente ultrapassada. Isso motiva a equipe e reforça a idéia de que usar “baby steps” não significa que o progresso seja lento.

Processos ágeis permitem esse aprendizado. Ele vem justamente do rápido feedback das iterações, e permite a rápida incorporação do aprendizado nos projetos. (Não temos que esperar todo um novo projeto, ou todo um novo planejamento pra colocar em prática nossas lições).

A retrospectiva parece boba, normalmente é negligenciada, mas aposto que as equipes desses 2 projetos já têm opiniões a favor dessa prática. Deixa eu contar um pouquinho do nosso projeto na aeronáutica, que é constantemente citado em listas de discussão.

Antes mesmo do projeto começar e qualquer equipe ser alocada, já iniciamos um trabalho de conscientização das nossas práticas, explicamos como fazíamos software e por que fazíamos dessa maneira. Tínhamos que tranqüilizar o cliente para que ele visse que a forma de fazer software diferente não ia trazer riscos contratuais ou prejuízos para eles.

Felizmente na aeronáutica tivemos um grande caso de sucesso ano passado usando XP. A equipe que acompanhou o outro projeto também passou segurança para a equipe desse novo contrato. Estamos mudando uma cultura de pouco em pouco. Trabalho de formiguinha mesmo.

Pois bem, o contrato era para a manutenção de um sistema feito em parceria entre Exército e Aeronáutica. Existiam 2 branches do sistema. Uma para cada força. E seria feito um merge antes do começo. Para nossas práticas ágeis, tivemos apoio total das equipes que já desenvolviam o projeto em ambas as forças. Todos tinham curiosidade pra colocar esses conhecimentos em prática, estavam doidos pra fazer teste automatizado mas nunca tinham encontrado um ambiente favorável pra isso.

Essa falta de ambiente favorável é comum por aí. Nunca há tempo pra criar a estrutura de testes, nunca há tempo pra desenvolver as classes de teste e continuamos desenvolvendo como sabemos que dá merlin. No entanto, sempre encontramos tempo pra consertar as merlins.

Depois de várias tentativas de início em falso, porque o tal do merge nunca ficava pronto pra começarmos numa versão definitiva, tivemos o primeiro Sprint Planning.

A equipe: Willi, Bruno, Carol, Rafael da SEA, Ten. Souto e Ten. Tarcísio da Aeronáutica, Cap. Sant’Ana e Ten. Waleska do Exército e Tiago, como terceirizado do Exército.

Continua no próximo capítulo…

Episódio II