Olá pessoal,

Vou aproveitar a entresafra bloguística do pessoal pra deixar uma notinha.

No começo de outubro, publiquei no Blog da Visão Ágil um artigo sobre uma consultoria de Agile que demos no INEP para desenvolvimento do Encceja.

Foi uma experiência muito interessante pra gente, além de considerar um marco muito importante para as metodologias ágeis no Brasil, pois se trata de um projeto de nível nacional e no governo! (Além de outras coisas, como ter utilizado um servidor de aplicação feito em Software Livre).

Espanta um monte de crenças e preconceitos a respeito de Agile.

Leia o artigo na íntegra aqui.

Ah, e pra quem ainda não leu sobre nossa Saga na Aeronáutica,apresentada no Falando em Agile, o Case Sigadaer descrito em maiores detalhes aqui.

Grande abraço, [                  ]

Willi

Me lembrei da história de um cara que visitou uma enorme construção e perguntou a um operário o que ele estava fazendo. Ele respondeu que estava assentando tijolos. Perguntou pra outro e esse respondeu que estava levantando uma parede. Perguntou a mesma coisa a um terceiro, que estava fazendo a mesma coisa que os outros dois, e ele disse que estava construindo uma catedral.

É nesse sentido que coloquei no título o “Construindo um Brasil Melhor”.
Muita gente pode achar que o que fizemos foi só uma tradução de um livro, mas acredito que estamos fazendo mais que isso.
Estamos favorecendo a popularização das metodologias ágeis. Com isso, favorecemos a produção de mais software de qualidade, a compreensão dos prejuízos causados por contratos de escopo fechado, deixando melhores legados para nossos colegas, diminuindo os tantos sistemas inteiros que são jogados no lixo todo ano para serem refeitos por fortunas cada vez maiores, fazendo com que os recursos sejam melhor utilizados, ajudando o país a enriquecer de uma forma sustentável, para gerar mais impostos, para sobrar mais dinheiro pra educação, pro povo aprender a ter senso crítico, pra votar melhor, pra daqui a um bom tempo ocorrer uma limpeza real no nosso sistema e o Brasil ser um país melhor pra todos nossos tataranetos.

Viajei? Se deixar chego até a contribuição para a diminuição do aquecimento global! :)

Mas toda essa jornada começa com um simples passo, e esse passo foi dado por 30 pessoas que ao melhor estilo bazar construíram a catedral.

Não me lembro quando a idéia apareceu, mas apareceu depois de terminarmos de traduzir as tirinhas do Why’s Poignant Guide to Ruby. Mandei um e-mail pro Henrik Kniberg com a idéia de traduzir o livro pra português, depois de um tempo ele me respondeu topando, e em seguida mandou o livro em formato editável. Dividi o livro em 114 pequenos pedaços, e dia 16/07/08 lançamos um post  convocando nossos leitores e a galera da comunidade no Brasil, e explicando o procedimento. No mesmo dia, três pessoas já apareceram. Pra gente já foi uma vitória. Quem poderia imaginar que ao total iriam aparecer 30? São eles:
 

• Acyr José Tedeschi
• Adam Victor Brandizzi
• Alexandre Gomes
• Álvaro Maia
• Bruno Pedroso
• Cássio Marques
• Daniel Wildt
• Eduardo Bobsin Machado, que traduziu todas as imagens
• Emanoel Tadeu da Silva Freitas
• Fernanda Stringassi de Oliveira
• Francisco M. Soares Nt.
• Gustavo Grillo
• Ian Gallina, cuja mãe ajudou na revisão do português
• Israel Rodrigo Faria
• José Inácio Serafini
• Juliana Berossa Steffen
• Marcos Machado
• Marcos Vinícius Guimarães
• Mauricio Vieira
• Pablo Nunes Alves
• Rafael Benevides
• Rafael Recalde Caceres
• Renato Willi
• Rodrigo Palhano
• Rodrigo Russo
• Taiza Sousa
• Victor Hugo Germano
• Vinícius Assef

Em 21 dias, mais de 150 e-mails depois, a idéia virou realidade. Todo o livro já estava traduzido, dia 07/08. Cada pedaço levou em média 2,22 dias pra ser traduzido. No total, entre tradução e revisão, levamos apenas 1 mês e 1 semana. O Cássio Marques e Vinícius Assef juntos traduziram quase 50% dos pedaços.
Parabéns novamente a todos. Foi um trabalho excepcional. Comemorem!!!

Convencer, ensinar, vender… são todos processos internos (acontecem no espaço entre 2 orelhas). Teremos muito mais sucesso se agirmos no sentido de motivar as pessoas para que se convençam, motivar pra que aprendam ou para que comprem alguma coisa. Parece apenas um jogo de palavras, mas a idéia por trás é bastante forte! Apenas 2,5% da população é de pessoas inovadoras, que são naturalmente ávidos por mudança e não têm aversão ao risco. Quer dizer que de cada 100 chefes que você tentar convencer, só 2 irão te dar ouvidos.

Os demais irão agir provavelmente assim:

Se você riu é porque já passou por isso. Eu tive uma crise de riso! :)

Vejam que um dos padrões para introduzir novas idéias é plantar sementes.

Eis a semente!

[                       ]
Willi

 
Começamos com o Ten. Souto apresentando o que é projeto, depois as dificuldades culturais na Aeronáutica, que é Militar, tem hierarquia rígida, e é governo, tem que contratar por licitação (Lei 8666). Em seguida o Alê falou da dificuldade cultural também presente na SEA, que vem de uma cultura RUP (reparem no gráfico das baleias!) + MPS.Br + PMI.
Então, apresentei as argumentações que foram usadas pra Aeronáutica se sentir segura pra acreditar nas práticas que estávamos propondo. Acho que muita gente não entendeu o slide “Gerente + Coach”, você entendeu? ;)

Na seqüência, o Bruno apresentou as práticas que foram adotadas no projeto e a evolução de algumas delas ao longo do tempo, além de algumas curiosidades sobre o ambiente militar. Por fim, fizemos uma retrospectiva do projeto, com um balanço dos pontos negativos e positivos do projeto. Fizemos questão que o Souto contasse sem censura os podres do projeto pra que todos possamos aprender com isso, afinal, não é de aprendizado e melhoria contínua que falamos o tempo todo?

Nem me atrevo a falar das outras apresentações. Estão muito bem descritas nos blogs dos participantes e demais palestrantes. Vou deixar aqui as referências pr vocês curtirem. Vale à pena:

• Série do Victor Hugo Germano;
• Post do Daniel Wildt;

Esses 2 ajudaram na tradução do Scrum and XP from the Treches, que será disponibilizado dia 01/11 na estréa do site da InfoQ.

• O Relato caprichado sobre o evento do André Faria Gomes;
• E mais um  e outro do André Pantalião Ferreira  e mais esse aqui;
• Um case parecido com o nosso, mas em proporções GLOBAIS do Danilo Bardusco, uma das apresentações favoritas da galera;
• E o colega dele: Guilherme Chapiewski;
• E do ex colega deles: Antonio Carlos Silveira, hoje na Yahoo;
• E pra saber mais sobre padrões de Daniel Cukier, da Locaweb.

É isso! Talvez até tenha mais coisa por aí. Se ficar sabendo, deixe nos comentários!

[]s Willi

Depois do #RailsSummit, voltaremos nesta semana à São Paulo para participar do evento FalandoEmAgile, promovido pela Caelum, onde apresentaremos o caso de sucesso de uso de práticas ágeis na Força Aérea Brasileira. Segue resumo da apresentação:

É com grande satisfação que apresentamos o sucesso obtido na utilização de práticas ágeis na Força Aérea Brasileira. De todos impedimentos à implantação de métodos ágeis, as barreiras social e cultural são, sem dúvida, os maiores obstáculos a serem vencidos. Em nossa história, poucos pontos favoreceram a quebra do tradicional paradigma de desenvolvimento de software. De um lado, uma empresa nascida de uma parceria Rational, com anos de experiência na implantação de processo unificado. Do outro, um órgão militar, tradicionalmente conservador, burocrático, procedimentalizado, "RUPeiro" e regido pela Lei 8.666, que normatiza de maneira inflexível toda aquisição e contratos da Administração Pública.

Apresentaremos as dificuldades enfrentadas desde a licitação até hoje, o processo de convencimento, detalhes técnicos da utilização de Scrum e XP e o balanço final da empreitada, sempre com testemunhos de todas as partes envolvidas: o oficial militar responsável pelo projeto, o diretor técnico da empresa executora do projeto e seus gestores e técnicos responsáveis pela operacionalização da proposta.

Serão dois dias de evento (23 e 24/10) recheados de novidades e com a participação das grandes cabeças brasileiras no assunto. Vejam abaixo a programação completa. Nos vemos por lá!

Programação

Conseguimos! Chegamos em São Paulo sãos e salvos e ao Encontro Ágil 2008, que rolou no IME. Só conseguimos andar aqui graças a um GPS emprestado do Léo, amigo do Bruno, claro.

Logo na chegada, eu e o Bruno nos espantamos com a quantidade de gente que estava participando. Tinha uma fila que ia até a parte de fora do IME. Parece que foram umas 700 pessoas. Ficamos felizes em ver como o “movimento” está forte por aqui. E não é à toa. O pessoal tem feito um trabalho de divulgação aqui desde 2001, com a chegada do professor Fábio Kon de um mestrado feito nos EUA.

As melhores partes foram os debates sobre Agile x Capacitações (CMMI, MPS.Br), Agile x Certificações e o “Birds of Feather” que participei sobre Scrum, que acabou sendo sobre “Como vender Agile”. Descrevo-os em seguida. Para saber das palestras, visitem o site da AgilCoop, onde publicarão os slides, fotos e filmes, ou este post aqui. O Autor foi nas mesmas apresentações que a gente.

Nos debates, não houve debate na verdade. Não tinha ninguém a favor de certificações ou de modelos de maturidade. Parece que o povo não veio. Por que será?

Na verdade, os modelos de maturidade certificam que você faz direitinho o processo que se propõe, com a premissa de que um processo maduro gera um bom produto. Mas isso não é necessariamente verdadeiro sempre. Se você se propõe a fazer um processo inadequado e fizer ele direito, sairá certificado, mas seu produto pode não sair direito. Isso não garante a qualidade do produto.

Porém, uma reflexão interessante que surgiu foi : “Se isso é tão ruim, não vale nada, por que os gestores de tantas organizações continuam pedindo?”. As respostas não foram conclusivas. Na minha opinião, é uma mistura de proteção dos contratantes com jogos de interesses.

Proteção para os gestores poderem dizer, depois de dar problema no projeto, que trataram todos os riscos, tomaram todas as precauções, as empresas eram certificadas, capacitadas e etc. Há a crença de que esses certificados trazem confiança, pois são emitidos por entidades sérias, imparciais e por aí vai. (Vejam que o pensamento é de precaução - se preparando pro pior, não de colaboração!).
Jogo de interesse pois gente das próprias empresas que investiram nesses selos, “influenciam” os gestores para que as incluam como critérios de seleção, para que as empresas tenham vantagem. Os gestores não tiraram isso do nada.

No Birds of Feather, que foi a parte mais legal, estava presente o Juan Bernabó, da Teamware, quem eu vi fazendo a primeira palestra de Scrum em Brasília. Ele me reconheceu pelo agile tales! :) Também tinha um pessoal da Paggo, que acabamos visitando e conhecendo melhor depois (escreveremos sobre isso em breve - muito legal!), e de outras empresas e faculdades.
Discutimos venda de softwares usando agile. A grande falácia é que existe escopo de sistema fechado. O escopo do sistema muito raramente é fechado. As especificações vêm em alto nível e crescem "pra dentro". Logo, vender isso é pedir pra ter problemas na certa! O contrato mais honesto para as duas partes seria o de escopo aberto, mas já que é considerado arriscado demais, o ideal é encontrar outra medida para mensurar o escopo da venda, como pontos por função ou pontos por caso de uso. Preferimos pontos por caso de uso por usarmos modelos mais próximos de estórias, logo, mais visíveis para o cliente.

Outra falácia é que você pode convencer alguém de alguma coisa, e isso não existe (assim como venda, ensino, etc – longa história…). As pessoas que se convencem. Logo, paremos de dar soco em ponta de faca. No longo prazo a verdade aparece. “Deixa estar.”

Sobre certificação, a grande questão que ficou entre nós (pois isso não foi discutido no debate), foi de natureza ética. Alguns têm vendido certificações, aproveitando uma demanda do mercado, sem mesmo acreditar no valor delas. (Hate the game, not the players). Certificações não querem dizer que a pessoa é boa, mas que passou numa prova. Só.

Será que não deveríamos investir também na conscientização dessas pessoas sobre o real valor do que estão procurando?

Pra finalizar, 3 outras coisas legais: conhecer as pessoas da comunidade, a comida do evento e um mural para retrospectiva, onde todo mundo colocou o que foi legal e o que poderia melhorar.

 Jorge Diz, Ricardo Almeida e Bruno.

O Mural da Retrospectiva.

[]s Willi

Inspirados pela participação na tradução do “Why’s (Poignant) Guide to Ruby”…

Estamos recrutando voluntários pra tradução do “Scrum and Xp From the Trenches”, do Henrik Kniberg!

O livro já foi traduzido pra Espanhol, Chinês e Japonês. O blog do autor diz que estão em curso as traduções para Coreano, Alemão, Francês, Eslovaco e Português… Essa última, nossa própria promessa!

O processo é muito simples. Basta entrar na nossa lista de discussão, em sft_pt arroba googlegroups ponto com, e enviar um email com o subject “Quero traduzir SfT”, que em breve você receberá um pequeno pedaço do livro em formato word pra traduzir. Depois, basta traduzir o pedaço e devolvê-lo pra gente, no mesmo arquivo, seguindo a numeração. Pra cada pedaço devolvido, respondemos enviando mais um.

Ah, e é claro que todos os colaboradores serão citados na versão final da tradução.

Abraços,

Willi

No último domingo, 06 de julho, aconteceu o Grande Prêmio de Silverstone, na Inglaterra. Achei dois aspectos interessantes na corrida relacionados a projetos de software que gostaria de comentar aqui.

Pra quem não teve oportunidade de acompanhar, vou contar resumidamente os fatos interessantes. O clima estava bastante instável no final de semana. Chovia e parava seguidamente, e ninguém sabia qual o melhor jogo de pneus usar a cada pit-stop durante a corrida: o de chuva pra pista bastante molhada, o intermediário pra pista molhada (ou secando) ou o liso pra pista seca. Na primeira parada das Ferraris, não estava chovendo, a pista já estava secando e existia uma previsão de chuva que poderia se confirmar ou não. Os carros estavam desde o começo com pneus intermediários, que desgastados ficam próximos dos lisos, servindo bem em pistas secas. Numa corrida anterior, em Mônaco, a Ferrari se viu na mesma situação e confiou na previsão de chuva. Trocou os pneus para de chuva, não choveu, e acabaram perdendo a corrida. Provavelmente influenciados por essa decisão errada, tentaram se redimir e arriscaram apostar contra a previsão do tempo agora – mantiveram os pneus intermediários gastos acreditando que a pista ia secar. Só que choveu… E muito!

Os carros deram algumas voltas com um rendimento bem ruim, perderam bastante tempo, o Felipe Massa rodou 5 vezes na corrida e depois de algum tempo a Ferrari chamou os pilotos de volta pra mais um pit-stop não planejado pra trocar os pneus pra de chuva. Os locutores ficaram se perguntando: “Por que não chamou antes, já que iam fazer uma parada a mais de qualquer jeito? Perderam mais tempo ainda!”. Resultado: Quem não arriscou e apostou na previsão se deu bem e o Massa apesar de ter feito o maior número de voltas (inclusive em torno do próprio eixo), terminou em último. Quem quiser ler mais, pode ver aqui, aqui e aqui também.

A primeira lição tirada desse episódio é sobre tomada de decisão. Quem joga poker sabe que cada mão é um jogo novo. Você tem que manter a mente limpa e se concentrar em uma jogada de cada vez, “se esquecendo” do que se passou nas outras mãos. A Ferrari pecou justo nesse ponto. Olhou pra trás ao invés de olhar pra cima. Ficou comprometida com a recuperação do erro do passado ao invés de analisar a situação atual. Ela não deveria ter arriscado dessa vez. Tirou a lição errada de Mônaco e aplicou em Silverstone. As outras equipes olharam pro céu e viram nuvens realmente bastante negras, estavam na Inglaterra, que tem um dia sem chuva por ano e se lembraram dos dias passados, em que chovia o tempo todo. Claro que havia risco de não chover, mas bem menor.

Depois de cometido ao erro, ficaram comprometidos demais com o planejamento inicial de 3 paradas e demoraram pra tomar uma nova decisão e corrigi-lo: chamar os pilotos pra parar mais uma vez e trocar os pneus pra chuva. A nova parada custaria caro! Mais tempo perdido… Mas será que teria compensado o tempo perdido com as 5 rodadas do Massa? Será que se tivessem trocado pra chuva a corrida seria diferente? Será que se tivessem chamado os pilotos de volta logo depois o resultado não teria sido o mesmo?

A resposta é: nunca saberemos.

Decidir é um negócio difícil! Os americanos dizem “Se tomar uma decisão, pode errar. Se não tomar, já errou.” Hoje, com a velocidade com que as decisões complexas têm de ser tomadas, é muito caro e difícil ter as informações necessárias a tempo. O grau de incerteza é grande e talvez seja mais difícil ainda saber se uma decisão foi a bem tomada, pois também é difícil mensurar e comparar resultados. Assim como na corrida, você passa pela situação aquela vez e não tem como voltar e saber no que outra decisão teria resultado.

Tem um agravante quando o ambiente é instável, como na corrida ou em desenvolvimento de software: com a mudança do ambiente, o que seria aparentemente uma boa decisão pode tornar-se rapidamente ruim. Seria o caso se qualquer variável da corrida tivesse mudado, por exemplo, se a chuva tivesse sido muito breve. Nesse caso, todo mundo que colocou pneu de chuva seria prejudicado depois. E se tivesse dado uma bandeira amarela? bagunça tudo de novo… Gerenciar projetos de software é como se durante a corrida, mudasse o tempo todo o clima, o piloto, a equipe, a pista, o carro, várias bandeiras amarelas, acidentes e etc.

Normalmente nós passamos muito mais tempo convivendo com o efeito das decisões tomadas do que tomando as decisões. Decisões ruins podem se tornar fatais. Além disso, algumas informações só ficam visíveis depois de tomada a decisão. Então, por tudo isso que está escrito, é muito mais importante estar atento a esses efeitos e mudar rápido do que investir em uma decisão excelente.

O ambiente pode mudar e a decisão que foi caríssima e lenta fica mais cara ainda, pois terá que mudar tudo de novo. E como normalmente houve muito comprometimento com essa decisão, há mais demora ainda para que seja corrigida. Enquanto que, se tomar a melhor decisão possível para o momento e ela se mostrar ruim, você aprende e se adapta rapidamente à nova realidade, com baixo custo, e não sofre por completo (nem por muito tempo), seus males.

E o que tem Scrum, XP e agilidade a ver com isso tudo? Tudo!
Um dos valores do Manifesto Ágil é que se adaptar às mudanças é mais importante que seguir um plano… Por essa razão que temos reuniões diárias, semanais, mensais, trimestrais e etc. Cada uma pra inspecionar e nos adaptarmos ao caos do nosso dia-a-dia. Temos vários pit-stops pra inspecionar o tempo e trocar nossos pneus de acordo com o altíssimo ritmo das mudanças de nosso ambiente. Na Fórmula 1 o pit-stop sai caro pois é demorado… Em projetos também pode acabar ficando caro, e é por isso que controlamos o tempo das reuniões.

Também é por essas razões que não planejamos com detalhes todo o projeto antes de iniciá-lo. Ao planejar, tomam-se várias decisões que, à época da execução, podem todas terem “perdido a validade” devido às diversas mudanças de ambiente. Cria-se uma expectativa perigosa com a idéia de que o plano seja uma “previsão do futuro”, e qualquer mudança nele pode gerar frustração. Além disso, cria-se um “comprometimento”, ou “apego” à todo trabalho despendido nesse planejamento que pode retardar uma mudança necessária, como no caso das 3 paradas planejadas antecipadamente para a corrida.

Notaram alguma semelhança com seu dia-a-dia? Acho que é uma analogia bem legal e espero que ajude a clarear as idéias sobre essa forma de planejar, além de motivar algumas mudanças. Que tal um planejamento iterativo agora?

Até a próxima!

Willi

Eu tenho falado da filosofia ágil por todo lugar que passei ultimamente e, após uma ou outra olhada torta, a conclusão coletiva sempre tem sido simpática aos valores defendidos.

Em alguns lugares mais tradicionalistas, disseram que já ouviram esse discurso N vezes na história da computação e que, no fundo, todo mundo está atrás da qualidade e produtividade no desenvolvimento de software. Até acredito nisso, mas tenho uma tendência a acreditar mais no momento atual do que nas tentativas de outrora. Nós da SEA não vivemos todas as "grandes idéias" do passado, mas estamos participando do momento atual e temos observado grandes resultados na pele.

Como César Brod, colunista da tradicionalíssima lista Dicas-L, do colega Rubens Queiroz, bem disse, metodologias ágeis de desenvolvimento não se aplicam apenas para software. E ele exemplifica isso com o caso da Alaska Airlines que, utilizando-se de técnicas muito utilizadas em projetos Scrum, otimizaram seus procedimentos de atendimento. E, para engrossar o coro, compartillho experiência semelhante que temos tido na própria gestão da área técnica da SEA.

Bem que tentamos implantar vários procedimentos administrativos, burocráticos, taylorianos no passado. Por alguma razão, ainda desconhecida, falhamos todas as vezes. Pode ser porque não estudamos Administração de Empresas, ou não. De fato, isso sempre era visto como a causa óbvia de todos nossos problemas, até que arriscamos experimentar algo diferente.

Nos últimos tempos, sob a luz dos valores ágeis, não apenas solucionamos 80% dos conflitos tolos existentes na área, como também apresentamos índices de evolução e satisfação do grupo nunca antes observados. Ainda há muito o que melhorar, sem dúvida mas, mantidas suas devidas proporções, só tenho a acreditar que aquele pensamento "old-school" está  muito comprometido.

Hoje somos muito mais democráticos, decisões são tomadas muito mais rápidas e a máquina, definitivamente, anda. Reveja alguns posts que já fizemos aqui e entenda melhor o caso.

Mudanças na TEC

"Estamos adotando um novo modelo de gestão para a Diretoria de Tecnologia da SEA. Após várias tentativas com modelos tradicionalistas e, agora, motivados por algumas tendências de mercado, caminhamos rumo a uma estratégia que apelidamos de "Gestão Ágil". Afinal, acreditamos que a condução de toda a área aproxima-se mais ao ato de dirigir um veículo, recheado de eventos assíncronos, do que ao seu processo de construção, previsível e determinístico.(…)"

 Empreender faz sentido

"Se hoje eu entrar na sala de aula de qualquer universidade e perguntar quem quer ser empreededor, acredito que poucos demonstrarão interesse. Entretanto, em verdade em verdade eu vos digo: aquele que não souber empreender, queimará no purgatório da subserviência até que a asas da previdência os leve ao "conforto" da inatividade.(…)"

Depoimento pró-agilidade

"Gostaria de dar meu depoimento em relação à boa experiência que tivemos numa reunião num cliente, utilizando práticas ágeis no desenvolvimento dum projeto.(…)"

Por que mudar?

"Por muito tempo estivemos melhorando nosso processo de desenvolvimento de software, treinando mais as equipes, aperfeiçoando nossas atividades, nossa documentação e mesmo assim nossa taxa de sucesso nos projetos era a mesma de qualquer empresa, segundo o Standish Group.(…)"

SEA: um celeiro de idéias

"(…)A SEA, já há algum tempo, vem incentivando seus colaboradores e parceiros a desenvolverem habilidades empreendedorísticas essenciais às atividades de consultoria especializada por ela executada. Vários posts já foram publicados no blog público da SEA e constantes incentivos são dados para a elaboração de projetos de pesquisa e para a condução autônoma dos projetos em execução. Agora, a fim de galgar mais um degrau nessa escala de capacitação profissional, a empresa traz uma nova modalidade de incentivo à atividade empreendedora.(…)"

Pessoas auto-gerenciáveis

"(…)É um tipo habilidade que a gente valoriza bastante aqui na SEA. Em geral valorizamos habilidades sociais, tanto quanto as técnicas. Como mencionei outro dia num email cá entre nós:
Vc sabe programar muito bem? Bom pra vc.
Vc conhece as API’s de cór e salteado? Bom pra vc.
Vc tem iniciativa, criatividade, coragem e astúcia? Bom para o projeto.(…)"

Adoraríamos também ouvir seus comentários a respeito. Estamos de portas abertas para apresentação do modelo SEA de operacionalização e gestão.  Colaboração é a palavra-chave. Queremos um mundo melhor e acreditamos que só chegaremos lá se formos juntos.

Um abraço.

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