Estimativa e Planejamento Ágil de Projetos (parte 1)

Este mês, vou iniciar uma série de artigos falando sobre planejamento ágil de projetos. A base para a escrita destes posts são 3:

1. O livro "Agile and Estimating Planning" (por Mike Cohn)
2. O livro "Sotware Estimation" (por Steve McConnell)
3. Minhas experiências*

* Sem dúvida alguma que a maioria esmagadora da base para a escrita destes posts virá dos livros citados acima.

Neste primeiro post, iremos falar sobre os propósitos do planejamento, porque fazê-lo e entender o que faz um planejamento ser ágil..

Começando do começo

Muitos de nós acha que fazer planejamento e estimativa é algo difícil.  Bom, estes muitos estão certos.  Planejar um projeto no início e se comprometer com um plano é algo extremamente perigoso.  Podemos visualizar essa afirmação em uma figura chamada "Cone da Incerteza" (Steve McConnell).

O eixo X mostra a linha de tempo do projeto e o eixo Y mostra a margem de erro do plano  inicial do projeto.  A medida que a linha do tempo avança, menor é a margem de erro.

Mas afinal... por que planejar?

Fazer planejamento e estimativas não é apenas ou somente uma questão de determinar uma data apropriada para entregar um produto.  Planejamento (principalmente quando lidamos com uma abordagem ágil) é trabalhar para encontrar a solução para o principal enigma a ser quebrado: O que deveremos construir?  

De fato, fazer planejamento nos ajuda a:

• Reduzir riscos no projeto
• Reduzir a incerteza no projeto (lembra do cone?)
• Fornecer suporte para melhor tomada de decisões
• Estabelecer confiança
• Transmitir informações

Ironicamente, um plano ruim é aquele que dá uma data exata para entregar o produto contratado.  

Então o que faz um plano ser bom ou ruim?
Um bom plano é aquele em que os patrocinadores do projeto podem setir confiança suficiente para usá-lo na tomada de decisões.  Por exemplo, antes de começar o projeto poderíamos fazer um planejamento que resultasse num plano que nos dissesse que o projeto não poderia ficar pronto no primeiro semestre do ano caso o número de funcionalidades não fosse menor.  Isso é uma decisão estratégica que não precisa de data exata.  

Segundo Mike Cohn, planejamento ágil tira o foco da palavra Plano e enfatiza a palavra Planejamento.  Planos são documentos estáticos ou figuras.  Eles são projeções do que nós achamos que o projeto terá no futuro.  Planejamento é uma atividade.  Ele nos ajuda a aprender no decorrer do projeto e isso nos permite diminuir a incerteza e ganhar confiança ao estimar.  Em outras palavras, o projeto ágil não tem um Plano, ele tem um planejamento contínuo.  Um plano ágil é preparado para mudar porque as mudanças são boas, uma vez que elas nos ajudam a aprender sobre os usuários e sobre o projeto.

Mesmo assim, alguém pode indagar: "Eu faço planejamento contínuo, mas mesmo assim ele falha, por quê?" 

Responderemos isso no próximo post: "Por que meus planejamentos falham?"

Grupo Scrum Fortaleza - 3o. Encontro

Aconteceu no último dia 29/03/2010 o terceiro encontro do grupo Scrum Fortaleza. Tivemos a oportunidade de conhecer o Michel Goldenberg e o Heitor Roriz, assim como rever nosso amigo Fabiano Milani.

Na ocasião, tivemos uma palestra do Michel falando sobre "Estimativa e Planejamento Ágil" ou como ele prefere dizer: "Planificação e Estimação Ágil". Alguns destaques da sua palesta:

"Se sua equipe não acredita em Reunião Diária, pare de fazer e veja o que acontece. Mas lembre... marque o dia em que deixaram de fazer."

"Existem duas maneiras de calcular prazo e custo de projeto: i) Mentindo para o cliente e ii) colocando uma baita gordura no projeto"

Depois tivemos a oportunidade de ouvir e ver Fabiano Milani falando sobre as armadilhas de usarmos Scrum.

Ao final, tivemos o Michel, o Fabiano e a presença ilustre de Heitor Roriz numa mesa-redonda-em-pé-ao-lado-de-uma-mesa-retangualar (veja as fotos). Na oportunidade o grupo discutiu sobre: importância do PO nos projetos, nova cerfifcação CSD da Scrum Alliace ...

Enfim, esse encontro reuniu ainda mais a comunidade Ágil de Fortaleza e foi nosso maior encontro, pois no primeiro encontro tivemos 28 pessoas. No segundo, 40 pessoas. E agora, no terceiro, mais de 70 pessoas presentes.

Abraço a todos e aguardem pelos próximos...

A primeira vez de Martin Fowler... no Brasil

Em entrevista feita a Danilo Sato, o cientista-chefe da ThoughtWorks, Martin Fowler, estará no Brasil para ministrar um Keynote no Agile Brazil 2010.
Seguem abaixo alguns pontos da entrevista que me chamaram a atenção:

- Quando perguntado sobre suas espectativas sobre o evento, Martin Fowler foi emblemático quando disse que depois de tantos anos participando de conferências e encontros, seria difícil se sentir empolgado pelo Agile Brazil 2010. Ele está mais empolgado em visitar o Brasil do que com qualquer outra coisa, uma vez que é sua primeira vez na América do Sul.

- Outro ponto interessante foi sua afirmação em dizer que não sabia ainda o que iria falar em seu Keynote e que isso seria uma decisão para ser tomada na noite anterior. Nosso amigo Danilo foi feliz em dizer que o Mr. Fowler é um dos poucos palestrantes que consegue preparar um keynote de um evento internacional na noite anterior.

Aqui você pode conferir a entrevista inteira.

No mais, quem puder participar do evento não perca esta oportunidade!!! Abraços.

Agiles 2009, um GRANDE evento

Nos últimos dias 08 e 09 de Outubro tivemos a oportunidade de participar do Agiles 2009 em Florianópolis (que cidade linda). Realmente um evento ímpar para a nossa comunidade e sem dúvida está entre os melhores que já tivemos no país... ou o melhor.

O evento começou com o KeyNote sensacional de Brian Marick, um dos autores do Manifesto Ágil. Seu bom humor foi o tom de sua apresentação e seu principal foco foi sempre voltado para equipes multidisciplinares, auto-gerenciadas e, sobretudo, XP.

Várias apresentações chamaram a atenção:

A primeira delas foi a simpática Diana Larsen entitulada "TRUST – THE KEY TO AGILE TEAM COLLABORATION". Os pontos fortes foram:

• É fundamental que conheçamos as pessoas antes de trabalharmos com elas
• A credibilidade é fundamental para a confiaça entre as pessoas e isso é conseguido através do compartilhamento de informações e sentimentos
• A confiança não deve estar presente apenas no time, mas na relação que eles têm com pessoas externas

Uma segunda palestra que me chamou a atenção foi de Dave Nicolette, "Agiles Project Metrics" e uma frase resume o que foi o tom do seu discursso: "Measure just the necessary, nothing more". Outra frase de Dave que me chamou a atenção foi: "Working software is the primary measure of progress".

Joshua Kerievsky também nos deu uma aula de agilidade e arte quando comparou de maneira muito feliz os diversos estágios da arte com os diversos estágios da Agilidade. Foi ele que afirmou veementemente que muitos de nós estamos fazendo software de uma forma medieval.

Uma das palestras que mais me chamou a atenção foi a de David Hussman, um cara que tem sido mentor e coach de equipes ágeis nos EUA, Canadá, Europa, Índia, Egito, Rússia e Ucrânia. Foi recentemente agraciado com o prêmio Gordon Pask Award no último Agiles em Chicago. Fez questão de dizer que é apaixonado por música e não exitou em fazer a comparação de uma banda com uma equipe ágil.

Por fim, tivemos um belo painel com os "astros" do evento: Brian Marick, Diana Larsen, Roy Singham (ThoughWorks) e Joshua Kerievsky. Não podemos deixar de dizer que essa parte do evento teve como pano de fundo o bom humor de Brian Marick, sempre ressaltando a importância das pequenas empresas na economia mundial, o que era sempre elegantemente rebatido pelo sócio-fundador da ThoughWorks, Roy Singham. Segue foto abaixo.

Da esquerda para a direita: Brian Marick, David Hussman, Joshua Kerievsky, Roy Singham (ThoughWorks), Diana Larsen.

O ponto negativo foi saber que nós, cearenses, estamos a alguns anos atrás no tocante ao desenvolvimento ágil de sistema e, principalmente, no que se refere aos paradigmas que precisam ser quebrados por nossos profissionais.

Bom, esse foi um resumo muito rápido do que foi o evento em Floripa. Abraço.

Apresentação de SCRUM na Faculdade de Juazeiro do Norte

No último dia 19/06, eu e nosso amigo Cristiano Milfont participamos de um evento em Juazeiro do Norte onde foram feitas duas apresentações, uma de XP (Milfont) e outra de Scrum (Eu), ambas disponibilizadas no Slideshare.

Fiquei realmente surpreso com o interesse da turma e com o nível de conhecimento dos participantes, que demonstraram isso com perguntas e questionamentos bastante relevantes para os temas abordados.

Infelizmente o tempo era curto para falar tudo que gostaríamos, tanto que a segunda palestra (a qual falei sobre Scrum) terminou depois das 22:00h.

Seguem abaixo os links para acessar as duas palestras
http://www.slideshare.net/cmilfont/apresentando-extreme-programming
http://www.slideshare.net/paulofurtado/palestra-de-scrum-em-juazeiro

Esperamos novos convites para voltar a essa terra tão receptiva que é Juazeiro do Norte.

2o. Curso de Certificação Scrum Master em Fortaleza

Devido ao rápido preenchimento da turma de CSM agendada para fortaleza nos dias 25 e 26 de Junho, tivemos que abrir uma nova turma de CSM (Certified Scrum Master) nos dia 30 e 31 de Julho de 2009. O evento vai ter, novamente, total apoio do CGDT (Centro de Gestão e Desenvolvimento Tecnológico) e terá como instrutor Alexandre Magno, único Certfied Scrum Trainer do Brasil (pelo menos por enquanto, :) ).

As incrições poderão ser feitas através da Adaptworks ou através do telefone (0x11) 5585-7738.

Esperamos mais uma turma cheia em Fortaleza. Abraço.

Especificação: Documentação ou Comunicação?

Esse é um tema que já causou muita polêmica e AINDA causa, como vemos em posts como "Documentação Ágil" e "E a documentação?". Poderia citar vários outros.

Entretanto, vai aqui alguns mitos sobre documentação que ainda incomodam pessoas da nossa área:

1) A documentação serve para Especificar detalhadamente o funcionamento do sistema, pois dessa forma os Analistas de Negócio repassam algumas necessidades dos usuários para os desenvolvedores enquanto trabalham na especificação de novas funcionalidades.

Mera ilusão!!! A documentação, neste caso, está servindo como um mecanismo de comunicação entre os analistas e os desenvolvedores. Eu poderia aqui citar várias referências de profissionais que aboliram esse mecanismo de comunicação a muito tempo. Mas, em vez disso, faço as seguintes indagações:

a) Como desenvolvedor, você prefere conversar com o analista e entender as funcionalidades em 2 horas de "papo" ou prefere passar o dia lendo uma especificação de caso de uso extensa e tentar interpretar o que foi dito, ou melhor, escrito pelo Analista?

b) Como Analista (seja sincero!!), você acha que conseguiu entender perfeitamente o problema do usuário para chegar ao ponto de escrever um bolo de documentos e garantir que isso não vai mudar assim que o usuário ver o que foi implementado? Além disso, temos que ser sinceros, as pessoas que escrevem documentos de especificação não são nenhum Luís Fernando Veríssimo ou um Ariano Suassuna.

c) Como Stakeholder, você se sente a vontade para esperar que toda ou grande parte da análise seja escrita para entrar em desenvolvimento e só depois ter alguma funcionalidade do sistema pronta (ou não)?

Bom, proponho aqui (isso muitos já fizeram também) algumas ferramentas que podem substituir um documento extenso de análise: Boca, mão, pincel e quadro branco. Nesse caso, até uma foto do quadro ou um rascunho no papel podem servir para comunicação das idéias por trás de uma funcionalidade e, ao final do projeto, pode-se até criar uma documentação mais formal se for o caso

2) Deve-se ter uma documentação completa para garantir que, quando os atuais integrantes da equipe sejam substituídos, seus sucessores possam ter uma referência do que foi feito.

Ótimo!!! Mas não existe melhor documentação do que um código bem feito, e isso pode ser alcançado com algumas práticas como Programação em Par e Refatoração Contínua. No entanto, se mesmo assim houver a necessidade de uma documentação, deixe para fazer ao final do projeto, pois a probabilidade de mudanças nessa documentação será mínima.


Enfim, espero que os profissionais da área de TI possam focar muito no produto final em vez de se preocupar com atividades "burrocráticas" e desnecessárias. Não somos escritores de software, somo DESENVOLVEDORES de software.