• alterar tamanho de fonte
• mudar o posicionamento de um conteúdo alguns pixels
• alterar cores
• trocar uma imagem

Porém, essa facilidade implica, muitas vezes, no tempo final do desenvolvimento pois não são computadas devido ao dinamismo em que são feitas.

Por esse motivo, costumo levantar a bandeira de que é uma boa prática manter um histórico do Estimado x Realizado. Sei que estimativa, é uma estimativa, não é um tiro certeiro; mas o exercício de relembrar porque foi feita uma estimativa e porque ela foi melhor ou pior do que o esperado, ajuda nos próximos planejamentos.

A melhor forma de fazer este levantamento é pegar as tarefas geradas durante o Sprint para uma determinada história e “pesar” junto ao time o quanto ela interfere no valor antes estimado.

Com esse valor do Sprint Realizado, fica na lembrança dos integrantes, os principais motivos que prejudicaram as estimativas no passado. Mesmo não sendo uma solução exata, ajuda na percepção quando se faz essa retrospectiva em cima das estimativas x realizado.

Parabéns aos responsáveis pelo evento Agile Weekend 2009. O evento contou com palestras e discussões de alto nível. Abaixo relato algumas anotações das palestras que compareci.

“Os desafios da cultura Lean no desenvolvimento de software” (Daniel Wildt e Luiz Parzianello – GUMA/SUCESU-RS)

Iniciando a palestra lembrando da Filosofia da Toyota, chamou a atenção o relato do tempo médio de produção de um Celta da Chevrolet em cerca de 1’08”.

Algumas observações dos palestrantes:

• TDD são muito bem aceitos e recomendados pois contribuem para a diminuição de erros
• Desenvolver com foco == trabalhar em 1 projeto evitando multitarefas
• Os testes devem estar no início do projeto, de preferência sendo feitos em pair programming

Destaque para o slide dos disperdícios da produção:

1. Produção excessiva
2. Estoque
3. Processamento excessivo
4. Movimentação excessiva
5. Transporte
6. Esperas
7. Defeitos

Interessante o ponto focado no time trabalhando como time. Assim como no livro do técnico de vôlei Bernardinho – Transformando suor em ouro – onde também ressalta a importância de se ter um time com bons profissionais e  sem “estrelas”, sem “heróis”.

Uma analogia foi feita com o espetáculo Cirque du Soleil onde não se é dado destaque a um determinado ator e sua habilidade. Todos no Cirque du Soleil são capazes de executar a habilidade de outro integrante quando há a necessidade seja por lesão ou doença.

“Agilidade Alternativa com a Corrente Crítica” (Adail Retamal – Heptagon SP)

A palestra lembrou do Manifesto Ágil, da própria palavra AGILIDADE ser equiparada à habilidade para mudar e algumas boas práticas a serem lembradas:

• Desenvolver com o pensamento e desejo de aumentar a probabilidade de reutilização
• Planejar objetivos com entregas de sucesso
• Garantir que os recursos necessários estejam disponíveis
• Alinhar tarefas dependentes
• Lembrar que as pessoas se comportam conforme são medidas

Demonstrou alguns conceitos de sua tese inserindo artifícios nomeados de Pulmão do Projeto onde no cronograma é removido 50% da segurança do projeto com no mínimo de 1/3 do tempo total.

“Anti-Práticas e Anti-Valores Ágeis” (José Peleteiro – Globo.com)

Lembrou das designações de um Scrum Master e do Project Owner no modelo SCRUM, de como geralmente acabam se comportando:

• Scrum Master deve ser o facilitador e não apresentar-se como chefe do grupo
• Product Owner dever estar preocupado com o produto e priorizar o que deve ser feito e não o como deve ser feito

Falou sobre o Scrum realizado na Globo.com, do horário fixo para o Daily Meeting e de alguns times estarem trabalhando em sincronismo em prol de um mesmo produto de forma incremental e iterativa.

Aboliu a comparação de pessoas serem chamadas de recursos.

“Como o Scrum mudou a forma da Borland entregar software” (Bruno Lichot – Borland)

O palestrante Bruno comentou que a Borland não possui um padrão para o tempo de um Sprint; cada Time, tem seu período próprio de Sprint; e que cada Sprint tem o objetivo de entregar uma versão executável (incremental e iterativo).

Uma interessante abordagem foi sobre o desenvolvimento de juntar o profissional de Tester com o Programador trabalhando em pair programming, após o Tester fazer o teste de uma funcionalidade, o Programador desenvolve para que o teste funcione.

Apresentou também a ferramenta desenvolvida para controle do Sprint: Borland Management Suite.

“A Agilidade está no ar – um case na Força Aérea Brasileira” (Alexandre Gomes, Bruno Pedroso e Renato Willi – SEA Tecnologia / DF)

Esta foi a palestra de destaque no domingo. A palestra abordou a diferença de cultura na forma de gerenciar um projeto dentro de um ambiente militar, onde a cultura é de imposição sem saber o porquê tem que ser feito. Comentaram que após demonstrar que através dos métodos ágeis conseguiam fazer entregas de sucesso de funções, ganharam a confiança e a credibilidade dos gestores militares e puderam ter melhores negociações de horários, formas de trabalhar, fazer cursos  e participarem de eventos.

Reforçaram a importância do uso do TDD.

Criaram alguns mantras para lembrarem aos integrantes do time a importância de certas ações como: fazer o TDD, manter o código limpo etc.

Para manter a visualização das etapas que já foram entregues, eles mantém a WBS do Projeto sob um contact e colorem sobre ele as etapas que terminadas.

Os Sprints são semanais e buscando iterar o produto.

Seguem um padrão de código ao ser desenvolvido.

Além de contarem e exibirem graficamente a quantidade de tarefas entregues, também geram o mesmo conceito para as entregas de funcionalidades.

Algumas Lições Aprendidas relatadas pelo grupo:

• Horário flexível geralmente não é bem visto pelo cliente
• A Rotatividade de integrantes do time é muito prejudicial
• Quando o cliente viajava e ficava sem a comunicação com o time, os problemas aumentavam
• É importante respeitar a cultura do cliente para que ele passe a respeitar a cultura do time

“Scrum feito com soluções simples e de baixo custo” (Luiz Faias Jr. – Bluesoft SP)

» link dos slides da apresentação

Como a metodologia Scrum tendencia a utilização de post-it, foi feita uma experiência na Bluesoft pintando uma parede com tinta imantada e prendendo as fichas das histórias e tarefas com mini-ímas.

Desenvolveram uma ferramenta chamada Trac para divulgar online as histórias desenvolvidas e de andamento.

Utilizam as cartas do Planning poker para Valor de Negócio das histórias.

São feitas semanalmente, uma reunião com objetivo de novidade técnica.

Utilizam o GIT para branch de cada tarefa executada.

Todos os desenvolvedores utilizam MAC.

“Métodos Ágeis x Gestão do Negócio” (Gustavo Casarotto – Metadados RS)

Iniciando a palestra com a frase: “O seu sucesso não depende só de você, depende de todos”, mostrou a importância de um time sempre se manter unido em prol de um objetivo; e que os feedbacks devem ser feitos na primeira oportunidade de serem feitos.

Ressaltou que, o que garante a satisfação do cliente não é 1, e sim uma sequência de bons resultados.

Fez a seguinte analogia mostrando que o cliente também precisa colaborar para que o resultado esperado seja entregue: “Do que adianta ter o melhor cabeleireiro do mundo, se o cliente fica mexendo a cabeça?”

“Agilizando seu Projeto de Software” (Bruno Pedroso – SEA – DF)

» link dos slides da apresentação

Defendeu a tese de que não se deve ser purista na metodologia, a preocupação com o Scrum by the book. Que se o time não estiver seguro para estimar, que procure colocar um objetivo agrupando as histórias e tarefas necessárias para seu cumprimento. Simplificar sempre que puder para conseguir medir e estimar melhor.

Fez analogia ao mestre de Capoeira, que durante o ensino, mostra aos alunos como os movimentos devem ser feitos.

Comentou que por experiência comprovada, um coach externo não funciona, quando não se tem um coach interno e próximo ao time não se tem o devido foco e comprometimento necessário.

“A Evolução dos Princípios Ágeis nas Normas do PMI” (Paulo Keglevich – PMI – RS)

Nesta palestra foi dado muito foco aos primcípios PMI e que segundo o palestrante, não considera a “melhoria contínua” dentro de um processo de desenvolvimento.

Assim que receber os links dos palestrantes de suas respectivas palestras, disponibilizarei aqui.