É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto, esses problemas nunca devem passar despercebidos e o Burndown é um grande auxílio nesse aspecto, sinalizando que algo pode não estar indo como previsto. Ele serve como uma alerta, para que o time analise o quadro atual e o que será necessário fazer para entregar o combinado, ou até para adicionar novas atividades, entregando mais do que o combinado.

No entanto, infelizmente, muitas vezes esse gráfico tão simples e útil, é mal empregado e acaba trazendo prejuízos ao invés de benefícios para o time. Vamos dar uma olhada nos 3 principais vícios na utilização do gráfico de Burndown.

Controlar o Time

Não é vigiando o Burndown para avaliar o trabalho do time que as coisas vão mudar. Na verdade, esse tipo de atitude atrapalha muito o funcionamento da agilidade. Na agilidade todos trabalham com comprometimento absoluto. As pessoas são empoderadas para resolverem problemas e atuarem da melhor forma possível.  O controle indevido acaba se tornando um estopim para o início de uma crise na equipe. Acaba gerando contrariedade entre PO e time, com acusações mútuas que podem desencadear crises muito mais sérias. O gráfico de Burndown não deve ser utilizado com uma ferramenta para exercer o Comando e Controle.

Comparar Times

O Burndown também não é ferramenta para comparar times. Aliás, na Cultura Ágil, a preocupação deve ser muito maior em motivar do que comparar desempenho. O objetivo não é dar “pressão” no time, mas trabalhar junto com o time, buscando pontos de melhoria, para cada vez mais aumentar a eficácia e eficiência. O próprio sistema de pontuação de histórias, velocidade, e planning poker, utilizados na maioria dos times Scrum, não permite comparações entre equipes. É um sistema de pontuação sem uma referência única, onde cada time estabelece suas referências e seus valores de acordo com as suas percepções e capacidades, dentro de seus respectivos cenários. A utilização do Burndown para comparação de times além de inapropriada e sem nexo, é improdutiva.

Medir Performance

A performance do time de forma ampla é avaliada pelo cumprimento do combinado. Isso de uma forma geral acaba sendo feito conjuntamente durante a Retrospectiva, em função do resultado da Revisão. Acontece que, em alguns casos, membros do time, ou mesmo participantes externos, acham que podem utilizar o Burndown para avaliar o desempenho do time durante a Sprint. Ficar medindo performance através de indicadores como o Burndown, além de não ser adequado, cria um clima de desconfiança prejudicial, e acaba levando ao primeiro vício que citamos, o de tentar controlar o time, utilizando o modelo de Comando e Controle.

É importante que todos os envolvidos com o Scrum entendam que o Burndown é um mecanismos de transparência, de awareness, e não uma ferramenta de medição de desempenho para uso numa estrutura de Comando e Controle. O propósito do Burndown é dar visibilidade à evolução dos trabalhos, para permitir que o time faça a devida análise do mesmo, considerando o cenário e o momento que se encontram. Existem outras métricas bem interessantes que podem ajudar o time. Entretanto o Burndown deve, e precisa, ser usado de forma útil e frequente para ajudar o time a dar o seu melhor.

Como vocês estão usando o Burndown no seu time? O Burndown tem ajudado? Conta para a gente.

The post Burndown Chart – As 3 Principais Confusões appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O movimento, se assim podemos chamar, #noestimates tem como fundamento básico a afirmação que “estimativas não geram valor”. Baseado nisso, prega que devamos evitar a todo modo estimar, reduzindo tal atividade ou mesmo a extinguindo. Advoga que devemos bolar métodos alternativos à estimação. Será? Esse caminho serve para a gente?

Vamos começar falando um pouco sobre estimativas. Estimativas são por natureza incertas, i.e., apresentam o valor aproximado de algo que ainda não conhecemos, não dominamos ou não temos como medir. Estimativas são comumente usadas para previsão. E porque precisamos prever algo? Simples: para podermos planejar.

A ideia com o planejamento de uma forma geral é permitir que nos preparemos para o futuro, especialmente no que diz respeito a tomarmos decisões que promovam a eficácia e eficiência do nosso projeto. Nesse artigo Planejando a Sprint: Velocidade e Estimativa, p.ex., falamos do planejamento da Sprint.

Entretanto, adicionalmente, devemos também entender que o processo de estimar envolve a procura de conhecimento sobre o que se deseja estimar. Em projetos de desenvolvimento, seja de software ou de qualquer outro produto ou serviço, isso representa discutir o assunto com o cliente/usuário. Buscar e investigar produtos ou serviços semelhantes ou de concorrentes. Muitas vezes até promover discussões com especialistas. E essa busca por conhecimento traz como efeito colateral um melhor entendimento do que se deseja estimar. Quanto mais sabemos mais acertamos, como discutimos nesse post Histórias bem Descritas, Estimativas mais Precisas.

Assim, chegamos ao primeiro aspecto importante, abordado de certa forma pelo #noestimates. Só devemos estimar se isso for necessário para alguma coisa que nos traga valor. Seja para prever custos, prazos, planejar capacidade, definir escopo de projeto, entender dependências entre requisitos e/ou melhorar o entendimento sobre algo que deveremos fazer.

Por outro lado, sabemos que estimativas são intrinsecamente imprecisas, especialmente se elaboradas pelas pessoas erradas, no momento errado. A literatura relacionada a projetos de software deixa isso bem claro, como apresentado por Robert Glass, aqui sintetizado:

1.  A maioria das estimativas de software é feita no início do ciclo de vida, quando tem-se pouco entendimento do problema.
2. A maioria das estimativas é feita pela gerência ou pelo marketing, não por quem irá efetivamente construir o software.
3. Raramente estimativas são refeitas.

Considerando tais observações, podemos também deduzir para que estimativas não devem ser usadas.

1. Determinar algo com precisão.
2. Estabelecer desafios.
3. Basear cobranças.
4. Premiar desempenho.
5. Curar falta de comprometimento.
6. Estabelecer confiança.

Sabemos que estimativas são muitas vezes utilizadas de forma errada e isso precisa sim ser combatido. Porém estimativas são parte indispensável de um processo de planejamento que, como vimos acima, serve pelo menos para organizarmos esforços para o atingimento de algum objetivo.

Como fazer então? Falamos para o cliente que é impossível planejar, porque não podemos ou devemos estimar nada? Planejamos com detalhes tudo que vamos fazer?

Bem, inicialmente devemos entender que o movimento ágil percebeu esse problema nos processos tradicionais de desenvolvimento e estabeleceu algumas diretivas que ajudam a reduzir os efeitos colaterais negativos de estimativas. Destaco a mais relacionada, ao meu ver, a estimativas: “Responder a mudanças mais que seguir um plano”.  Isso significa, por exemplo, que ao planejarmos algo entendemos que nosso conhecimento sobre o planejado irá mudar e que precisaremos rever nosso planejamento. Tudo a ver com o que discutimos acima.

De uma forma geral, o movimento #noestimates, ou as recomendações do mesmo, segue o mesmo caminho de muitos outros que tem surgido na agilidade: traz diversos insights interessantes, mas não pode ser aplicado de forma absoluta ou em qualquer caso.

Muitos projetos e organizações com  as quais temos contato já, de certa forma, ao utilizar o Scrum, trabalham com #noestimates. Em sua maioria, os times estimam histórias usando pontos de história. Entretanto, a maioria não estima tarefas, limitando-se a estabelecer um timebox para estas. É comum os times  quebrarem suas histórias em tarefas procurando limitar o tamanho de suas tarefas para que possam ser realizadas em um dia, no máximo em dois.

Concluindo, #noestimates é muito válido, mas não significa que deva ou possa ser aplicado indiscriminadamente. Se agrega valor, estimar é preciso. O mais importante é lembrar que estimar por estimar só atrapalha o time.

Como tem sido sua experiência em projetos Scrum? Sua equipe estima ou não? Vocês vêem valor em estimar?

The post Estimar ou #NoEstimates? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O SEMAT (Software Engineering Method and Theory) foi fundado em 2009 para ajudar a resolver diversos problemas que a indústria vem enfrentando. Seu primeiro passo foi fornecer uma fundação (chamada de Kernel) que irá suportar todo o pensamento de software daqui em diante, independentemente das práticas e ferramentas utilizadas. Com esse kernel, é possível entender se o processo, seja ele ágil, cascata ou qualquer outro, está atendendo as áreas consideradas pelo grupo como essenciais: Os chamados Alphas. Esses Alphas são divididos em temas e se relacionam entre si das mais variadas formas, como podemos ver na figura a seguir.

Mais informações sobre o modelo, os estados e os Alphas podem ser obtidas no guia de referência, mas farei uma breve descrição de cada um deles a seguir:

Cliente:

Área que se preocupa em saber se o time entende os stakeholders e a oportunidade que está sendo endereçada

• Oportunidade: As circunstâncias que fazem apropriado a criação ou alteração do sistema em questão.
• Stakeholders: As pessoas, grupos ou organizações que afetam ou são afetadas pelo sistema.

Solução:

Área que se preocupa  em saber se o time estabeleceu um entendimento conjunto dos requisitos e implementou um sistema capaz de atender os mesmos.

• Requisitos: As restrições que o sistema deve atender para endereçar a oportunidade e satisfazer os stakeholders
• Sistema de Software: O sistema como um todo, composto de software, hardware e dados

Endeavor (Traduzido livremente para esforço):

Área que se preocupa com o time, sua maneira de trabalhar e com o trabalho a ser feito.

• Trabalho: As atividades envolvendo esforço (mental ou físico) com objetivo de alcançar o objetivo
• Time: O grupo de pessoas engajado no desenvolvimento, suporte e gerência do projeto
• Maneira de Trabalhar: O conjunto de práticas selecionado que guiará o time e ajudará no trabalho

Cada um desses alphas possuem um estado a ser determinado pela equipe, utilizando a técnica denominada de Progress Poker. Esse método foi criado para ser rápido de ser executado e prover valiosa informação sobre o projeto de uma forma geral. O objetivo é que a equipe avalie cada Alpha, os estados que o mesmo possuem e entre em um consenso da situação atual naquele quesito.

É importante avaliar os itens que não foram atendidos porque são eles os pontos a serem atacados para a melhoria do processo.

Para verificar na prática essa técnica, utilizamos em um dos nossos projetos e obtivemos o seguinte resultado:

Como podemos ver, estamos bem posicionados em relação a Cliente (Oportunidade e Stakeholders) e Solução (Requisitos e Sistema de Software) mas pecando um pouco na área de Esforço (Time, Trabalho e Maneira de Trabalhar).

Sabemos que a causa dessa situação se deu pela entrada de diversos membros novos na equipe que ainda não haviam internalizado as práticas e atividades que a empresa executa. Esse foi o foco de maior trabalho para que o cenário identificado fosse revertido.

Em relação as outras duas áreas, é satisfatório perceber que bons resultados estão sendo obtidos e as práticas adotadas continuam sendo mantidas.

Faça você também a avaliação do seu projeto e deixe um comentário com a sua impressão!

The post SEMAT – Como Anda a Engenharia de Software do Seu Projeto? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

no post de hoje eu abordo alguns detalhes sobre o momento em que estamos planejando a Sprint, mais precisamente na etapa do processo Scrum conhecida como Reunião de Planejamento.

Nesse post aqui eu já falei sobre o planejamento da Sprint e procurei responder à pergunta "Quantas histórias minha equipe é capaz de desenvolver?". Nele, eu falo sobre a utilização da velocidade da equipe como medida para auxiliar nessa seleção.

No post de hoje quero mostrar que essa medida está em constante mudança e, por isso, é importante estarmos sempre atentos e atualizando a velocidade da equipe a cada Sprint.

Podemos notar isso analisando a quantidade de pontos que são entregues no final de Sprints sucessivas. Essa quantidade está sempre mudando e, portanto, a velocidade também. Os motivos dessa mudança podem ser vários:

• Ausência de algum membro da equipe
• Feriados durante a Sprint
• Subestimação/Superestimação de histórias
• Histórias urgentes e imprevistas que entram na Sprint
• Outros

No projeto em que faço parte utilizamos o Planning Poker para estimar os pontos das histórias (mais informações sobre como fazer isso aqui, aqui e aqui), mas também temos guardados quanto tempo (em horas) cada história levou para ficar pronta. Com isso podemos pegar, por exemplo, as histórias que pontuamos com 3 pontos, ver o total de horas consumidas, dividir pela quantidade de histórias e aí teremos uma relação de quanto tempo, em média, a equipe leva para finalizar uma história de 3 pontos.

Na tabela a seguir podemos observar que recentemente houve uma mudança na quantidade de horas que levamos para finalizar histórias de 3, 5 e 8 pontos. As duas últimas tiveram uma mudança sutil, mas a história de 3 pontos passou a ser finalizada em 75% do tempo anterior. Não devemos entender que essa diminuição do tempo significa necessariamente que a equipe passou a ser mais eficiente, mas devemos encarar como uma mudança natural, já que os pontos são baseados em estimativas.

Ainda analisando a tabela, podemos fugir um pouco do tema velocidade e entrar na discussão pontos vs horas, que já foi abordado nesse post aqui.

Olhando os dados da tabela percebemos claramente que pontos e horas não formam uma função linear. Ou seja, não é porque para finalizar a história de 1 ponto leva 2h que a história de 2 pontos deveria levar 4h, e a de 5 pontos levar 10h. Não é bem por aí, afinal estamos lidando com incerteza e nossos pontos de estimativa são fuzzy (mais informações sobre fuzzy você encontra aqui).

E você leitor, anda medindo frequentemente a velocidade da sua equipe? Faz de outro jeito? Sinta-se convidado a compartilhar conosco um pouco da sua experiência.

Até o próximo post!

The post Planejando a Sprint: Velocidade e estimativa appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O gráfico de burnup oferece informações do progresso do projeto como um todo e não apenas de um sprint como no caso do gráfico de burndown. Ele mostra claramente em que ponto a equipe está (Entregas) e onde ela deve chegar (Demandas).

Conforme podemos visualizar na figura abaixo, o gráfico de burnup é construído sobre dois eixos: no eixo horizontal tempos o fator tempo e no eixo vertical temos o fator que representa o montante de trabalho. Este montante de trabalho pode ser representado em pontos, medidas de esforço, horas, etc, de acordo com o que é utilizado no dia a dia de trabalho pela equipe.

Neste gráfico temos 2 linhas:

• Azul: representa o montante de trabalho entregue ao cliente. Ou seja, representa o total de histórias (ou item do backlog) entregues ao longo do projeto.
• Vermelha: representa o montante de trabalho que está sendo pedido pelo cliente.  Ou seja, representa o total de histórias (ou item de backlog) criadas para o projeto.

A distância entre estas duas linhas representa, a cada dia (ou outra unidade de tempo utilizada), o montante de trabalho que falta ser entregue para que se atinja o objetivo do projeto naquele momento.

Com este breve resumo sobre o gráfico de burnup, apresentamos 4 análises interessantes que podem ser feitas através dele.

1. Escopo X Entregas

A análise mais imediata que podemos fazer sobre este gráfico é a comparação do quanto o escopo do projeto evoluiu com o quanto de trabalho foi entregue ao longo do tempo.

Se o escopo do projeto começa a crescer muito mais do que a quantidade de trabalho entregue, então podemos ter um problema! Pois o projeto está crescendo em demandas, mas a velocidade de entregas da equipe não está acompanhando o ritmo de crescimento destas demandas.

Pontos de atenção:

• Talvez seja o momento de estudar um possível aumento na equipe, a fim de aumentar a velocidade das entregas
• Ou um estudo sobre o que pode estar impactando a velocidade das entregas.
• Ou ainda um estudo sobre a razão pela qual as demandas estão crescendo tão rapidamente.

Além disso, a comparação do montante de trabalho entregue com o montante de trabalho a fazer ao longo do tempo nos permite medir a distância entre o que se quer com o que se está atendendo através do projeto.

2. Regularidade das entregas frente ao objetivo do projeto

Outra análise interessante é sobre a regularidade das entregas do projeto frente ao objetivo.

Para esta análise traçamos uma linha desde a origem do gráfico até o ponto que representa o total de demandas no ultimo dia representado no gráfico, conforme a linha verde apresentada na figura abaixo.

Se a linha azul está sempre próxima da linha verde, mais equilibrado está o andamento do projeto.

Além disso, com essa linha é possível avaliar se estamos adiantados ou atrasados com as entregas. Caso a linha azul esteja acima da linha verde, estamos adiantados. Caso a linha azul esteja abaixo da linha verde estamos atrasados. É claro que essa ideia de atrasado ou adiantado depende das características do projeto, até porque dificilmente as entregas diárias seguirão rigorosamente uma regularidade.

3. Classificação dos montantes de trabalho em categorias

Outra análise interessante que pode ser feita com o gráfico de burnup é a separação dos montantes (demandados e entregues) em categorias. Por exemplo, em um projeto de software podemos ter as categorias Bug, Histórias técnicas e Novas Features.

Assim teríamos uma linha do montante demandado e uma linha do montante entregue para cada categoria. Estas informações poderiam ser visualizadas em um único gráfico de forma que para a classificação do exemplo teríamos 6 linhas no nosso gráfico de burnup.

Ou poderíamos também separar em três gráficos, um para cada categoria com uma linha do montante demandado e uma linha do montante entregue em cada um. Esta análise permite estudar não somente o quanto está sendo entregue como um todo, mas também, a natureza do que está sendo entregue.

Podemos analisar em que períodos entregaram-se mais correções de bugs ou em que período liberamos mais novas features, por exemplo. Ou talvez estudar quando estão surgindo mais demandas de correções de bugs…É após muitas entregas de novas features?  É antes?

Enfim, com a separação dos montantes de trabalho representados no gráfico em categorias podemos fazer uma correlação entre as entregas e demandas das diferentes categorias e buscar estratégias a fim de otimizar as entregas a fim de que se alcance o objetivo do projeto.

4. Análise da qualidade das entregas

Uma análise que fiz recentemente em um projeto que participo, e que pode até ser vista como uma análise decorrente da separação dos montantes de trabalho em categorias, é um estudo sobre o crescimento das demandas de correções de bugs frente às demais demandas do projeto. Ou seja, uma análise que nos ajuda a medir a qualidade do trabalho que está sendo entregue.

Se a quantidade de bugs encontrados começa a crescer muito mais do que as outras demandas ou se a quantidade de bugs começa a crescer mais do que a quantidade de trabalho entregue, pode ser sinal de problema, provavelmente relacionados à qualidade do que está sendo entregue através do projeto. Além disso, esta situação mostra que o trabalho que a equipe está entregando está ao mesmo tempo gerando mais trabalho (correção de bugs) pra própria equipe. Assim a distância entre as linhas azul e vermelha do gráfico de burnup será cada vez maior, quando na verdade o que se deseja é que estas linhas se aproximem e ao final do projeto se cruzem.

A partir destas 4 análises podemos extrair importantes informações sobre a evolução do projeto em questão, não só avaliando o total de trabalho entregue, mas também a natureza do está sendo entregue. Outras análises também podem ser feitas de acordo com as características do projeto. Portanto o gráfico de burnup fornece uma ferramenta poderosa e ao mesmo tempo flexível para que se possa avaliar o andamento de um projeto como um todo ao longo do tempo, permitindo que sejam tomadas ações a fim de que se atinja o objetivo do mesmo.

E você? Utiliza o gráfico de burnup? Como faz suas análises? Compartilhe com a gente através dos comentários! Até o próximo post!

The post 4 Dicas de Análise do Gráfico de Burnup appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.