• 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.

Um técnico de futebol precisa, assim como um Scrum Master, blindar o time de problemas e ações que possam atrapalhar o desenvolvimento ou causar falta de entrosamento no time.

A infelicidade de se isolar do problema do time após o zagueiro Jean fazer um gol contra:

“Eu não faço gol contra, eu não chuto a gol”

Causam insegurança e desmotivação aos jogadores do elenco, pois o time percebe que seu líder não se sente envolvido com o problema do time. Como se o líder que possuem está ali para dizer o que está certo e errado.

Um time para ir bem, precisa estar seguro e entre os integrantes precisa existir sempre uma avaliação e análise em conjunto dos erros que aconteceram. O próprio time sabe quem deveria estar em tal posicionamento, e, se não estava tem uma explicação.

Colocações inapropriadas como essas, motivam para que no próximo erro, o próprio time ficará procurando um culpado. Sempre teremos algo em que melhorar, cabe ao Técnico neste caso, procurar junto ao time, a melhor forma de evitar os erros cometidos.

Se falta um atacante, um bom batedor de falta…assim como em uma empresa, o técnico deve promover o treinamento específico do fundamento em carência ou contratar um jogador que possa suprir essa necessidade.

Times motivados lutam até o final. No futebol temos diversos exemplos de superação do time muitas vezes nos minutos finais de uma partida. Uma conversa franca no vestiário durante o intervalo, um bate-papo do técnico ao pé do ouvido com um jogador específico, podem ser muito valiosos.

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.

Simples, prático e viável.

Para cada Caso de Aceite de uma história, basta colocar o link correspondente para a validação e testes.

Com esta novidade, o tempo de Review foi surpreendentemente dinâmico, pois permitia que o próprio PO pudesse fazer uma pré-validação antes do Review.

A idéia rendeu elogios do PO Gustavo(Stag) e tornou-se uma das tarefas do time no momento de pré-review(último dia do Sprint).

A proposta foi:

1. montar pequenos grupos de mais ou menos 5 integrantes mesclando as 2 Equipes
2. os POs (Alexandre Moreno, Gustavo[Stag]) e o PD Newton dividiram o Globoesporte.com lembrando as sessões e aplicativos já existentes
3. cada grupo deveria gerar funcionalidades e/ou melhorias a serem desenvolvidas em tempo definido
4. ao término do tempo, cada representante do grupo leu as anotações de seu respectivo grupo ressaltando comentários quando se fez necessário
5. ao final das leituras dos grupos, estudou-se o melhor ponto de partida em conjunto com todo o grupo em um debate

No final da dinâmica, cada um teve a liberdade de comentar sobre a experiência em que participou. O retrospecto foi muito positivo, a liberdade dada aos desenvolvedore e o ambiente espaçoso com direito a coffee-break deixou todos mais à vontade e sem o sentimento de pressa para terminar.

Uma experiência feita pelo time de Esportes#1 foi fazer o Review e a Retrospective no Pub Beertaste, ambiente aconchegante onde o time teve um espaço reservado podendo ser servido de petiscos e bebidas.

Durante a reunião, observou-se o time mais descontraído e à vontade onde nem se fez perceber a hora passar.

O time na maioria aprovou a experiência e tal medida pode ser utilizada nos dias difíceis de agendar um horário em uma das salas de reunião.

A situação inicial:
- 1 equipe responsável pelo desenvolvimento das editorias do Portal Globoesporte.com
- 1 equipe responsável pelo desenvolvimento dos aplicativos e produtos voltados para o Esporte (CartolaFC, Futpédia etc.)

O objetivo:
- Mesclar os integrantes de ambas as equipes de forma que se tornassem 2 equipes homogêneas em experiências profissionais.

Como foi feito:
- Scrum Masters de ambas as equipes (Rafael Penna e Andréia Bustamante) sugeriram quais integrantes de seus times que poderiam trabalhar em equipes distintas de forma que as 2 novas equipes formadas pudessem ser o mais similar possível.
- Apresentado aos 2 times e colocado em liberdade a troca de equipe caso alguém não estivesse confortável na nova equipe.
- Para haver uma mudança ainda maior, separaram-se os SM e PO (Luiz Gustavo e Alexandre Moreno) das antigas formações.

Após sincronizar os Sprints, as distintas equipes seguiram com suas novas formações e desafios.

De início, no Planning foram vistos enormes diferenças de estimativas de complexidade, claro porém algumas somarizando o entendimento da nova forma de desenvolvimento a ter conhecimento.

Uma prática sugerida pela SM e que surtiu um bom andamento da equipe, foi do desenvolvimento em pair program. Ao final do Sprint houve um entendimento mais homogêneo dos processos antes desconhecidos. Tal sucesso surtiu efeito no Planning do Sprint seguinte onde a complexidade informada e a quantidade de tarefas levantadas foram melhor estimadas.

A experiência serviu também para alinhar os conhecimentos da metodologia SCRUM e as boas práticas aplicadas em cada time. Boas práticas essas que servirão de conteúdo para os próximos POSTS.