Building Minds - o Blog da OnCast

Um processo ágil não depende somente de ferramentas, boas práticas de engenharia ou mesmo de planejamento. Muito mais do que isso, precisa de pessoas com uma mentalidade ágil, pois são as peças fundamentais desse processo. Já diz o nosso bom e velho manifesto ágil: “Indivíduos e interação entre eles mais que processos e ferramentas”.

Mas o que é preciso para ser uma pessoa ágil? É preciso se comunicar, dar feedbacks, assumir  responsabilidades, ter espírito de equipe e acima de tudo ter coragem. A coragem promove a melhoria contínua (que não acontece sem coragem para mudanças), melhora a comunicação entre os indivíduos, faz com que as pessoas assumam suas responsabilidades, discutam seus erros, critiquem suas práticas.

A coragem é um dos ingredientes de um planejamento ágil de sucesso. A equipe passa a confiar nas suas estimativas, expôr para o product owner os problemas, alertar sobre possíveis impedimentos, aumentando a confiabilidade da equipe perante a ele. Assim funciona com o PO também: sem coragem, não é capaz de priorizar de acordo com seu real conhecimento do projeto, aderindo facilmente a pressões externas - vindas do setor comercial, por exemplo - delegando toda a pressão para a equipe. Isso expõe o projeto a certos riscos, mudando o escopo várias vezes por qualquer motivo (ou pressão), perdendo o foco, priorizando escopo daquela famosa categoria dos 80% de funcionalidades que geram somente 20% do valor.

Vale o cuidado com a utilização errada da coragem para não querer se tornar um “herói”! Afinal os heróis trabalham sozinhos e não se preocupam com a equipe, podendo até prejudicar um objetivo comum por tentar fazer tudo sozinho, querendo mostrar seu valor. Uma equipe unida e corajosa vale muito mais que um exército de heróis!

Vitor Pelizza Comunicação

Com certeza um dos momentos mais interessantes do planejamento é a hora de estimar as estórias! As melhores estimativas surgem quando o escopo da estória é bem discutido entre os membros do time e cada um defende fortemente suas opiniões sobre como alcançar os objetivos.

Ferramentas como o Planning Poker são alternativas muito interessantes para prender a atenção do time e motivar todos a pensarem e participarem ativamente do processo de estimativa de cada estória em vez de aceitar passivamente o que os outros decidirem.

Em http://planningpoker.com/ é possível criar as estórias e adicionar os participantes!

Planning Poker Online!

O bom e mais ou menos velho baralho sempre terá seu valor, no entanto esse tipo de ferramente pode facilitar e simplificar ainda mais o processo, trazendo mais interatividade, estimulo e união para todo o time!

Rodrigo Branas Comunicação, Ferramentas

Não é raro observar em iterações onde o Sprint Planning 2 não foi feito, problemas como: estimativas parciais, daily meetings mais longas e menos objetivas, impedimentos descobertos tarde demais e falta de alinhamento do time em relação ao que deve ser feito em cada estória.

O Spring Planning 2 é o processo no qual toda a equipe junta percorre os itens do selected backlog, entende o que se espera de cada estória e pensa em questões como: Quais classes devem ser criadas? Quantas camadas do sistema serão impactadas? Impedimentos? Quais tabelas do banco de dados serão atualizadas? Que telas devem ser criadas? Quantos testes unitários devem ser feitos? Qual é o critério de aceite? …

Após esse processo, os cartões de atividades serão criados e o time todo estará mais alinhado com o que deverá ser feito para atingir o objetivo em cada estória.

Lembra aquela estimativa que foi feita no Sprint Planning 1? Após todo esse processo, ela ainda continua válida? Muitas vezes ela precisa ser alterada e isso é necessário para garantir que o time se comprometa com entregas que ele realmente tem a capacidade de fazer.

Durante as Daily Meetings, que devem ser de curta duração e se restringir a responder as perguntas objetivas: o que foi feito ontem? o que será feito amanha? existem impedimentos afetando o desenvolvimento da estória?

Não é incomum notar estórias decompostas de forma inadequada ou até atividades criadas “on the fly” (durante a própria Daily Meeting) e com isso dificultando as respostas básicas e objetivas para ter um processo ágil e transparente. Além disso, evita explicações acerca do escopo da atividade, já que todos sabem pois também fizeram parte do processo de definição de todas as atividades.

Falando em impedimentos, será que não é tarde demais para pensar neles? Imagine uma iteração de 3 semanas. O que acontece se na última semana, quando uma estória foi decomposta em atividades, “apareceu” um impedimento que já poderia estar sendo resolvido desde o início da iteração. Agora existe a possibilidade de não entregar mais a estória porque pode não existir mais tempo hábil para resolvê-lo. Quanto antes os impedimentos forem descobertos mais livre será o caminho para fechar a estória, com menos interrupções e mais motivação.

O que mesmo precisa ser feito nessa estória? Perguntas como essa sempre surgem no meio da iteração, afinal ninguem mais lembra da reunião com o Product Owner e detalhes importantes do escopo da estória acabam sendo esquecidos. Se as atividades tivessem sido criadas enquanto todo esse conhecimento ainda é recente na mente de cada integrante do time, questionamentos poderiam surgir e ajudar a entender melhor o objetivo de cada estória que deverá ser desenvolvida ao longo da iteração.

Rodrigo Branas Comunicação, Riscos

Eu vi uma discussão interessante sobre priorização x estimativas x risco em uma lista da OnCast hoje. Gostei bastante do aprendizado e resolvi transcrever algumas coisas aqui.

Podemos ter diversas formas de priorizar nosso backlog, em geral analisamos o custo de desenvolvimento, o valor gerado para o cliente e o risco inserido numa estória. Sendo assim, considerando apenas valor gerado e risco, temos o seguinte:

- Primeiro desenvolve-se o que gera maior valor e tem maior risco para o cliente;
- Depois desenvolve-se o que gera maior valor e tem menor risco para o cliente;
- Em terceiro desenvolve-se o que gera menor valor e tem menor risco para o cliente;
- E, aquilo que tem maior risco e menor valor procuramos não executar.

Se a estimativa para uma dada estória/tema é de 13sp, parece bastante razoável e adequada em termos de estimativa para um trabalho que leva aproximadamente uma semana de esforço. Agora, se apenas 3 é a estimativa e uma semana é o tempo de esforço, indica que o risco pode ter sido subestimado. Neste último caso, me parece que um pouco mais de aprendizado sobre o que precisa ser feito, vai melhorar as estimativas e auxiliar a identificar melhor o risco.

Em geral, não alteramos nossas estimativas iniciais durante a iteração. Usamos esta informação para melhorar as estimativas da próxima iteração e, ao longo de iterações subsequentes, a velocidade vai equalizar-se e as estimativas passam a se tornar “quase certeiras”.

Uma estória, idealmente, é feita pelo time todo ao mesmo tempo (cada membro pega uma tarefa da estória mais prioritária no momento), e neste contexto o tamanho de estória ideal para proporcionar um boa granularidade e uma boa visibilidade no seu burndown chart é de 3 a 5 story points. Estórias pequenas não deveriam ter mais story points do que isto e deveriam levar em média 2 dias para serem implementadas, lembrem-se - pelo time todo. Então esta dica mostra que uma estória com maior risco, digamos 13 story ponits, projeta um período de aproximadamente 1 semana para ser implementada, o que me leva a crer que as estimativas do time estavam bem assertivas, considerando os 13 story points estimados na discussão que observei.

Dado que estamos usando a escala Fibonacci, utilizamos os gaps que existem entre estimativas maiores para acomodar a incerteza do risco. Então, se não tenho muita idéia do que pode vir a ser o meu risco, utilizo estimativas maiores e os gaps da Fibonacci vão me ajudar a equalizar minhas estimativas, mesmo em estórias com risco - num futuro próximo.

Samuel Crescêncio Auto-gestão, Riscos

A queda da produtividade do time pode ter suas origens em fatores motivacionais. Percebê-los a tempo é fundamental para que medidas corretivas possam ser tomadas a tempo de restabelecer o foco do time, eliminar o desperdício e reduzir o risco de não conseguir entregar o que foi combinado com o cliente no final da iteração.

Vários fatores podem causar a desmotivação de uma parte ou até de todo o time durante uma iteração. Estórias sem um objetivo claro, atividades decompostas de forma inadequada, complexidade e impedimentos constantes são fatores que podem ser resolvidos pelo próprio time antes e durante o processo de desenvolvimento, evitando a queda de produtividade e de motivação.

Uma estória sem um objetivo claro, pode levar o time por caminhos incertos, causando retrabalho, ao invés de convergir toda a sua força produtiva para contribuir com o aumento do progresso da iteração. As reuniões de planejando têm seu papel fundamental na extração do máximo de informações acerca do escopo de cada estória, tornando o processo de desenvolvimento objetivo e reduzindo a possibilidade de estimativas equivocadas.

Mesmo em uma estória onde não existem duvidas em relação ao que deve ser feito, a forma como a decomposição das atividades é feita serve para guiar o time em meio ao escopo definido, antecipando possíveis impedimentos que podem ocorrer. Além de contribuir positivamente com o foco no que deve ser desenvolvido, é possível mensurar o progresso da estória de uma forma mais precisa, prevendo os atrasos e adiantando as medidas corretivas que podem ser executadas para mitigá-los e garantir a entrega no final da iteração.

Impedimentos podem impactar fortemente a produtividade do time durante uma iteração. Após decompor as estórias é possível, salvo nas primeiras iterações, identificar atividades criticas que possam impedir o desenvolvimento da estória. Antecipar esses impactos é fundamental. Paralelizar a resolução dos impedimentos das estórias seguintes com o desenvolvimento das estórias atuais abre caminho para o processo produtivo seguir livremente, com menos interrupções.

Manter um canal de comunicação sempre aberto, ajuda a diminuir o risco de deixar que problemas se agravem e comprometam a entrega do time no final da iteração. Quando todos se envolvem e passam a agir como uma equipe comprometida, as barreiras técnicas são superadas, os impedimentos são resolvidos mais facilmente e os bons resultados vêm naturalmente.

Rodrigo Branas Auto-gestão, Comunicação

Há pouco mais de uma semana Adriano e eu tivemos o privilégio de participar do Agile Weekend em Porto Alegre. Particularmente para mim foi uma honra participar de um evento tão inspirador na cidade em que nasci. O evento organizado por nossos irmãos galdérios foi pra lá de excelente, especialmente por ter sido organizado em um período tão curto e por uma equipe de apenas 4 pessoas. Meus sinceros parabéns aos seus organizadores.

Tivemos o prazer de conduzir duas das palestras mais concorridas do evento. A palestra sobre o Lobo - Continuous Tuning, ferramenta open-source desenvolvida pela OnCast para o monitoramento e testes automatizado de performance, foi muito interessante. Mesmo em um espaço de tempo curtíssimo - 45 minutos, pudemos apresentar alguns conceitos que dão fundamento ao uso de testes automatizados, com foco principal na automatização dos testes de performance. Finalizamos esta palestra com uma apresentação “In Action” do Lobo, demonstrando seu funcionamento e instigando o público presente a baixar a ferramenta e a colaborar no seu desenvolvimento.

Já a palestra de Scrum superou totalmente as expectativas, pois este era um tema que acreditava-se, não teria muito quorum no evento. Para a nossa agradável surpresa, esta foi uma das palestras mais concorridas do evento, ao ponto de os organizadores colocarem cadeiras adicionais no auditório. Algumas pessoas queriam inclusive ficar em pé atrás do auditório mais foram impedidas para que a qualidade do evento pudesse ser mantida.

Além desta nossa pequena contribuição para ajudar a construir as mentes do evento, pudemos construir muito as nossas próprias, aprendendo e trocando experiência com um público tão cativante. Conhecemos pessoas, geramos oportunidades e trocamos idéias com gente muito experiente, o que enriqueceu muito o evento em minha opinião.

Além do imensurável valor de ter reencontrado e conhecidos importantes players do cenário ágil nacional, gostaria de destacar o Jaime, um paraense muito envolvido que nos fez uma entrevista sobre como fazemos ágil na OnCast. Esta entrevista deverá ser publicada em breve em seu blog, mas enquanto isto, convido os nosos leitores a conhecer o excelente e completo relato do Jaime, que cobriu o evento como um reporter profissional, apesar de eu descobrir que ele é um excelente programador

É isso aí pessoal, semana que vem tem o Scrum Gathering em Sampa. O Adriano irá conduzir uma excelente palestra sobre Scrum em um ambiente não ágil e eu estarei lá para dar uma força. Esperamos encontrá-los por lá.

Samuel Crescêncio Outros