ALOHA!
Olá Pessoal! Só pra quebrar um poquinho vou fazer um post um pouco mais "técnico". O Willi falou nos últimos posts sobre algumas das experiências obtidas com o uso de metodologias Ágeis no projeto SIGADAER da Aeronáutica. Acredito que boa parte deste "sucesso" é devido ao uso intensivo de desenvolvimento orientado à Testes. Semprei levei o uso de testes automatizados a sério, e aqui no projeto não foi diferente. Conseguimos evoluir, refatorar e detectar impactos com muita facilidade depois da implementação de um TestSuite com qualidade e cobertura de código significativa.
Hoje contamos com aproximadamente 180 casos de teste, entre unitários e de Interface. Vou falar um pouquinho sobre como implementamos os testes de Interface, utilizando o Selenium (IDE, RC e Server), o bom e velho Junit e o padrão de PageObjects. Sempre escrevendo o Teste de aceite junto com um StakeHolder antes tudo.

Ambiente:
Pra esse pequeno exemplo vamos utilizar a IDE Eclipse, o Selenium-IDE para gravar as funcionalidades de cada PageObject, e as versões 0.91 do Selenium Remote Control e Selenium Server. Logo ali eu falo um pouquinho sobre esses dois últimos. O projeto do eclipse com fontes e libs está disponível aqui.
O Selenium-IDE é um plugin fantástico para o Firefox. Com ele você pode gravar os testes executando as funcionalidades do sistema e exportar os Casos de Teste para Java, Html, PHP, Ruby e mais uma série de linguagens que o Selenium Server e Remote Control dão suporte. Sem programar uma linha de código sequer.

Vamos começar pela configuração do Selenium Server. O selenium Server funciona como um mini container que manipula as requisições HTTP entre o browser (no caso o Firefox) utilizado nos testes, e as classes de Teste que solicitam as requisições para o browser. Aqui nós criamos este arquivo properties para externalizar alguns parâmetros de configuração:



Em seguida criamos um Singleton para o Selenium Server para aproveitar o browser entre os testes e configurar o server com os valores do properties.




Agora temos uma classe para Testes Selenium que estende um TestCase Junit. Nossoas classes de teste de Interface vão estender deste cara aí Os métodos que interessam são o startSeleniumServer(), que inicia o servidor selenium e a sobrescrita do setUp(), que abre o contexto a ser utilizado nos testes.





Very Nice! Nossa infra de testes está quase pronta. Como eu já citei lá em cima, nós sempre escrevemos um "Teste de Aceite" antes de tudo. Ao escolher uma estória a ser implementada, identificamos os cenários e escrevemos o que cada cenário deve cotemplar. Ali no javadoc mesmo, sem frescuras. Assim nós sabemos que se o nosso teste passar, a estória tá pronta, simples assim.
Então vamos começar com um teste bem simples. Imagine a estória "Efetuar Login" do portal da Sea. Vamos escrever um caso de teste que contemple o cenário de falha no login. Taí o cabra:





Beleza! Já sabemos o que o teste tem que "testar". E aí? Agora entra em cena o Selenium IDE. É só abrir o console da IDE, setar a linguagem de programação a ser utilizadada (Java no caso) e mandar o bixo gravar. A partir daí você pode executar o fluxo normalmente e o Selenium vai gravar o TestCase já na linguagem escolhida, aí é só copiar e colar.

Beleza de novo! Mas e os asserts? Moleza de novo! O plugin conta com um menu de contexto contendo algumas validações que podem ser feitas naquela página. Você pode fazer asserts com valores de campos de tabelas, links, alerts e confirms javascript, títulos, basicamente todo o conteúdo da tela está disponível para manipulação através da api Java do selenium. O que não estiver no menu de contexto pode ser facilmente descoberto com uma olhadinha rápida na api.




Mas é aí que a gente esbarra com um pequeno probleminha. Eu poderia simplesmente usar o selenium direto nos meus testcases, mas a mudança de um label de um botão poderia quebrar todos os testes. O Brunão me mandou este link de um post muito interessante falando um pouco sobre PageObjects. Usando este padrão, podemos implementar classes que representam as interfaces gráficas, encapsulando o uso do selenium, aumentando drasticamente a manutenabilidade e deixando os testcases extremamente "limpos" e legíveis. Por exemplo, vejamos o nosso TestCase de Login já implementado com PageObjects:




Claro que este é um exemplo extremamente simples. Mas dá pra sacar como as coisas ficam transparentes. Vejamos outro exemplo:




E por aí vai! O Selenium é realmente uma ferramenta muito interessante. Se você também leva a sério a idéia de ter um sistema bem testado, com a possibilidade de saber com muito mais precisão qual o impacto de mudanças e refactorings, vale a pena dar uma conferida. O exemplo disponível pra download tá prontinho pra rodar.
Abraço e até a próxima!

Em Maio aconteceu a edição 2008 do JavaOne, conferência internacional sobre a tecnologia Java, da qual tive o prazer de participar pela 3a vez.

Muita gente tem me perguntado se o evento foi bom, quais foram as novidades e os grandes anúncios. Deixa então eu passar a minha visão de JavaOne, para que todos entendam o porquê de eu ainda insistir neste contexto aparentemente estagnado.

O mais importante que todos saibam é que o JavaOne não constitui-se apenas de palestras concentradas em 4 dias. Esses 4 dias na verdade funcionam como um pivô para uma série de encontros, confraternizações e discussões satélites lideradas por iniciativas independentes. É esta é a parte legal que justifica, IMHO, a viagem à California (além da própria Califórnia, claro).

Já no sábado antes do JavaOne, ocorreu a reunião anual dos líderes do portal java.net, para discussão de seu passado, presente e futuro. Teria sido uma discussão interessante, não fosse sua recorrência carente de resultados ano após ano. Em resumo, todos estão chateados com a plataforma operacional do portal (CollabNet) e pensam em substitui-la por alguma outra coisa.

No domingo, eu, Fabi, Bruno, Maltron e Flip passamos o dia degustando vinho na região próxima à San Francisco. Parece programa de turista, mas já nesse dia várias discussões abertas sobre grupos de usuários e comunidade em geral já vinham à tona. Particularmente, sou da opinião de que "reuniões" nesses  moldes geram ações muito mais criativas que as tradicionais conference calls.

Segunda-feira foi dia de CommunityOne. Um mini-evento exclusivo para discussão de tecnologias Sun (OpenSparc, OpenSolaris, Glassfish, Netbeans e OpenJDK, PhoneME…). Como o evento já é realizado dentro do Moscone Center, palco principal do JavaOne, já dá pra se ter uma noção de sua dimensão.

Da terça até a sexta-feira, foi o JavaOne, cujo slogan neste ano foi "Java+You".

Em resumo, a mensagem que a Sun quis passar é a de que a Tecnologia Java não foi criada exclusivamente para grandes corporações como bancos, tribunais e sites de comércio eletrônico, mas também para você, cidadão comum, não necessariamente tecnólogo. No geral, apesar de todo o barulho que se faz em torno da plataforma JEE, é preciso lembrar a todos que a tecnologia Java pode estar presente nos objetos mais ordinários do nosso cotidiano. Nas palavras do anfitrião dos keynotes, "Java, it’s all about you". E eu concordo plenamente. Na verdade, até generalizaria ainda mais esta afirmação, pois acredito que a computação em geral "is all about us". 

Pra mim, só essa temática que deram ao evento já teria valido a pena. Como pesquisador associado à Universidade de Brasília, com trabalhos sobre ubiquitous computing, o discurso de uma grande multinacional de pulverização e democratização da computação para seu uso imperceptível e diário alimenta a motivação para pesquisas e desenvolvimento de tecnologias que colaboram para concretização dos cenários de smart-spaces. É isso que temos feito há cerca de 1 ano no UnBiquitous. Um dia ainda falo só disso aqui.

Outra linha recorrente do discurso do JavaOne foi a distinção constante entre Java Platform e Java Language. A linguagem Java, com seus frameworks tradicionalíssimos, tem sofrido constante cheque por tecnologias emergentes. A plataforma, por outro lado, tem servido de base para corporativização dessas mesmas tecnologias. Isso também é papo para outro blog. 

A palestra realizada por mim, Jeanfrançois Arcand e Ted Goddard gerou ótimas impressões. Muita gente veio conversar conosco ao final atrás de mais informações. O título da apresentação foi Writing Real-time Applications Using Google Web Toolkit and Comet. O PDF tá disponível aqui.

Por fim, a grande razão que me motiva a participar e colaborar em várias comunidades tecnológicas: PESSOAS. No fim das contas, pouco importa a tecnologia que você usa, o processo adotado ou a metodologia de trabalho em prática se não houver PESSOAS, e não pessoas, no jogo.

O JavaOne pode não ter trazido grandes anúncios. A tecnologia Java pode não apresentar os mesmos índices de crescimento de outrora. Entretanto, ainda sim vale *muito* a pena participar de encontros como esses se se busca o relacionamento humano. Eu sempre digo que aprendizado é uma tarefa contínua e indisciplinada. Não é preciso sentar 8hs por dia em uma biblioteca para aprender. Aprende-se a todo momento e a toda hora. Basta estar atento.Estar rodeado das cabeças que lideram a tecnologia falando disso a todo momento, ainda que de modo informal, traz-nos um desenvolvimento técnico e pessoal que nenhuma faculdade conseguiria reproduzir. Trata-se de uma imersão cultural na qual respira-se tecnologia. Mesmo durante os jantares e outras confraternizações, entre um gole e outro, há um intercâmbio de experiências e conhecimento fantástico. Relaciona-se com gente do mundo inteiro, aprofunda-se o contato com líderes da comunidade do seu país e, o como resultado, abre-se portas, muitas portas.

Quem quiser ter uma noção do que passamos por lá, publiquei dois álbuns com fotos do evento que chamei, respectivamente, de visão tradicional e visão pessoal do JavaOne.

Sugiro que quem tiver a oportunidade, aproveite-a. Seja no JavaOne, Javapolis, Jazoon, JustJava, FISL, RailsConf, PyConf….. Não importa. Em todo lugar, tem gente boa. Em todo lugar, prevalece o espírito colaborativo. Sempre há oportunidades esperando por nós. Basta estarmos aptos a aproveitá-las. Tudo depende de você. It’s all about us.

 

De forma objetiva e bem-humorada, a série de posts sobre nossas eXPeriências Ágeis na Aeronáutica foi concluída (mas não o projeto). Com o tempo, iremos publicar aqui novos casos de sucesso (e também insucessos) na adoção de tecnologias e metodologias de ponta. Além do projeto da Aeronáutica, que está sendo todo desenvolvido sobre os padrões da tecnologia Java, há também várias outras atividades em andamento na empresa, das quais falaremos em momento oportuno:

• Implantação e suporte de infra-estrutura RedHat
• Implantação e suporte de infra-estrutura JBoss
• Implantação e suporte de infra-estrutura de portais (Liferay e JBoss Portal)
• Desenvolvimento de solução em C e Java para gerenciamento de placas de fax
• Extensão e customização, em Python, da ferramenta livre Pykota para gerenciamento de impressões
• Desenvolvimento de solução de business inteligence para setor de telecoms
• Desenvolvimento de projetos de pesquisa e desenvolvimento em tecnologias móveis, embarcadas e ubíquas
• Desenvolvimento de projetos em RubyOnRails

 Além de discussões sobre projetos, este é um espaço sistematicamente utilizado para reflexões sobre gestão de TI, empreendedorismo e análise de tendências e mercado. Se ainda não o fez, assine nosso RSS e entenda o SEA’s way of life.

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