|
Os Gráficos Burn-down e Burn-up são ferramentas de gestão à vista aplicadas no monitoramento e controle do progresso de projetos ágeis, notadamente, a estrutura Ágil Scrum. Seu objetivo principal é representar o desempenho das entregas, planejadas e realizadas, e dos recursos associados facilitando a análise dos dados e a comunicação com as diversas partes interessadas. A palavra “Burn” do inglês significa “queimar”, logo, esses gráficos representam a “queima” dos itens do Product Backlog ou da Sprint Backlog, ou até mesmo da dívida técnica (bugs), ao longo do tempo. Com o gráfico Burn-down aprendemos sobre o trabalho que resta a ser executado, enquanto com o gráfico Burn-up podemos apresentar o trabalho concluído e a quantidade total de trabalho e por isso costumam ser aplicados em conjunto. Em ambos os gráficos o eixo vertical Y representa o quantitativo de entregas ou trabalho (demanda) e o eixo horizontal X reflete a dimensão tempo e, no mínimo, a área do gráfico apresentará o comparativo entre o planejamento previsto e o planejamento realizado. Apesar da semelhança construtiva (linhas ou barras) e de propósito a aplicação de cada um desses gráficos é realizada de forma distinta por possuírem um conjunto específico de atributos. A análise dos gráficos permite obter respostas rápidas e confiáveis que auxiliam a equipe de projeto na sua adaptação e proposição de ações para reduzir inconsistências e aumentar a produtividade. Considerando que os projetos Ágeis têm entre seus princípios a flexibilidade, a frequência de entregas e a autoavaliação (adaptação) a representação do planejamento previsto, seja para o Product Backlog, seja para o Sprint Backlog ou seja para as dívidas técnicas é uma linha reta do ponto inicial ao ponto final do projeto sugerindo uma cadência única para as entregas dos Incrementos utilizáveis de valor. No ágil Scrum a demanda é focada no trabalho do Time Scrum que pode ser representado pelo quantitativo de itens do Product Backlog ou quantitativo de itens da Sprint Backlog ou pelas horas de tarefa. Este trabalho é monitorado e controlado ao longo do tempo por Sprint ou por unidade de tempo da Sprint. Quando desejado são criados gráficos específicos para monitoramento e controle das dívidas técnicas (bugs). GRÁFICO BURN-DOWN O gráfico Burn-down é mais aplicado para se visualizar a quantidade de trabalho remanescente para se concluir uma Sprint podendo, também, indicar a velocidade na qual se caminha em direção à conclusão da Sprint para que a equipe avalie se o tempo remanescente é hábil. Como ponto de atenção devemos perceber que este gráfico não representa a trajetória do projeto pois não reflete mudanças que venham a ocorrer durante a Sprint, especialmente se uma quantidade igual de trabalho ter sido adicionada e concluída ao mesmo tempo, não haverá indicação de progresso. Por ter foco na velocidade e produtividade e permitir a análise de interações curtas o gráfico Burn-down é utilizado principalmente para as avaliações da equipe de projeto durante a “Daily Scrum”. O Product Owner pode utilizar o gráfico Burn-down após a conclusão da Sprint para alinhar expectativas futuras.  Ao visualizar as linhas do gráfico Burn-down podemos inferir rapidamente quanto à velocidade e produtividade da equipe de projeto. Quando a linha de realização se apresenta acima da linha de planejamento significa a entrega de poucos itens em relação ao previsto, ou seja, a equipe de projeto realiza entregas em baixa velocidade e produtividade no período. Quando ocorre o inverso teremos uma alta velocidade e produtividade. A análise do gráfico Burn-down nos permite obter informações sobre:
Existem diversos fatores que afetam as tendências do gráfico Burn-down, é preciso avaliar qual o padrão apresentado pela equipe de desenvolvimento durante a Sprint Retrospective para se adaptar para as futuras Sprints. GRÁFICO BURN-UP O gráfico Burn-up é mais aplicado para se visualizar a quantidade de trabalho concluído em comparação com o trabalho total do Product Backlog podendo, também, indicar a velocidade na qual se caminha em direção à sua conclusão permitindo avaliar o progresso, identificar gargalos e prever a provável data de conclusão do projeto. Por ser um gráfico com foco no detalhamento e permitir a análise da trajetória do projeto o gráfico Burn-up é direcionado principalmente ao Product Owner e a comunicação com as partes interessadas externas.  Em relação à velocidade e produtividade ao visualizar as linhas do gráfico Burn-up podemos inferir que quando a linha de realização se apresenta acima da linha de planejamento significa a entrega de muitos itens, ou seja, uma alta velocidade e produtividade no período. Quando ocorre o inverso teremos uma baixa velocidade e produtividade.
O gráfico Burn-up nos permite obter as seguintes informações:
Essas informações permitem entender a eficiência da equipe de projeto Sprint à Sprint e possibilita estimar melhor o tempo necessário para concluir o trabalho subsidiando a criação de novos planos e ajustes nos prazos, se necessário. DIFERENÇAS ENTRE OS GRÁFICOS BURN-DOWN E BURN-UP Imagine que seu Time Scrum tenha 50 itens restantes para concluir e então, ocorre uma mudança, que adiciona mais 10 itens ao Product Backlog. Suponha também que, durante sua Sprint atual, o Time Scrum conseguiu entregar 15 Incrementos. Em um gráfico de Burn-down, antes da Sprint, teremos os 50 itens restantes representados e, após a Sprint, o gráfico iria apresentar 45 itens restantes (50 + 10 - 15). A quantidade restante está correta, mas se alguém não estiver ciente da mudança de escopo poderia inferir que você teve uma Sprint improdutiva, pois entregou “apenas” 5 Incrementos em vez dos 15 que eles realmente fizeram. Com um gráfico Burn-up, seria fácil observar o aumento de 10 itens na linha que representa o trabalho total a ser concluído, assim como observar na linha do trabalho realizado que o Time Scrum entregou efetivamente 15 Incrementos.
0 Comments
Um breve resumo do Guia Scrum ARTEFATOS SCRUM Idealizado em 1990 pelos seus co-criadores Ken Schwaber e Jeff Sutherland em um ambiente de desenvolvimento de produtos de software, o ágil SCRUM é uma estrutura simples, leve e constituída dos seguintes elementos: responsabilidades, eventos, artefatos e as regras que os unem. Nos artigos anteriores apresentamos a definição e a teoria do ágil Scrum o qual já apresenta algumas das regras que unem os demais elementos, os papéis e responsabilidades do Time Scrum e os eventos SCRUM. ARTEFATOS SCRUM Os artefatos SCRUM são a essência dos pilares do ágil SCRUM: Transparência, Inspeção e Adaptação e devem ser confiáveis para suportar o processo de tomada de decisão, otimizando os trabalhos e assegurando a geração de valor pelo Time Scrum. Cada artefato está relacionado a um compromisso específico que fornece foco ao Time Scrum e que permite o monitoramento e controle do progresso do projeto.  Product Backlog – Meta do Produto O artefato Product Backlog é gerenciado pelo Product Owner e consiste em: · Uma lista detalhada, ordenada e emergente dos trabalhos necessários (itens) para criar ou melhorar um produto; · Uma única fonte de requisitos para o produto; e, · Uma descrição, ordem e tamanho para cada item. O artefato Product Backlog representa valor e, desta forma, os itens de maior valor estão no topo da lista que segue em direção aos itens de menor valor. No ágil Scrum os itens de maior valor são sempre a prioridade dos trabalhos dos Developers.  O Product Backlog é um artefato dinâmico que evolui, muda, cresce e diminui ao longo do tempo e muitas vezes não estará completo antes do início dos trabalhos, é preciso atualizá-lo e reordená-lo continuamente mantendo-o pronto para uso antes de uma Sprint Planning.
Há várias formas de se registrar o Product Backlog: lista de cartões, planilha Excel, “histórias de usuários”, softwares para gestão de Backlog, etc. mas é fundamental para o ágil Scrum que esteja sempre transparente para o Time Scrum e as partes interessadas no produto. A meta do produto é uma informação do Product Backlog que representa um estado futuro do produto e permite o planejamento dos trabalhos pelo Time Scrum. A meta do produto deve ser alcançada (ou abandonada) antes de se assumir uma nova meta. Sprint Backlog – Meta da Sprint O artefato Sprint Backlog é o resultado da reunião Sprint Planning e fornece uma visão geral do trabalho de desenvolvimento dos Developers e consiste de 3 (três) produtos do gerenciamento:
É muito comum se realizar o refinamento dos itens selecionados do Product Bcklog durante a Sprint Planning, e até mesmo ao longo da Sprint, para se desdobrarem em itens menores para que possam ser inspecionados e permitam o monitoramento e controle do progresso dos trabalhos. A meta da Sprint é um objetivo que será alcançado dentro da Sprint através da implementação do Product Backlog sendo representada por uma breve expressão do compromisso assumido pelos Developers, geralmente um problema de negócio a ser abordado, e deve ser mantida ao longo da Sprint. Essa meta da Sprint visa fornecer ao Time Scrum:
Incremento – Definição de Pronto O artefato Incremento é o resultado dos trabalhos do Time Scrum considerado concluído e utilizável para gerar valor ao produto. Durante uma Sprint um ou mais Incrementos poderão ser desenvolvidos para atender aos itens selecionados do Product Backlog. Quando o Time Scrum considera que concluiu um Incremento deve apresentá-lo às partes interessadas para ser inspecionado e liberado para uso se atender sua Definição de Pronto, não sendo necessário aguardar até a Sprint Review. Todos os Incrementos liberados nas Sprints devem ser incorporados harmoniosamente ao produto e liberar valor na direção da meta do produto. A Definição de Pronto é a descrição das características do Incremento que atendem a qualidade exigida para o produto e assegura que um ou mais itens do Product Backlog foram concluídos e poderão ser liberados para uso. O não atendimento a Descrição de Pronto descaracteriza o resultado do trabalho como um Incremento e este não poderá ser apresentado na Sprint Review. Links recomendados: Guia Scrum https://scrumguides.org/ Glossário do Scrum https://www.scrum.org/resources/scrum-glossary Scrum.org https://www.scrum.org/ Um breve resumo do Guia Scrum EVENTOS SCRUM Idealizado em 1990 pelos seus co-criadores Ken Schwaber e Jeff Sutherland em um ambiente de desenvolvimento de produtos de software, o ágil SCRUM é uma estrutura simples, leve e constituída dos seguintes elementos: responsabilidades, eventos, artefatos e as regras que os unem. Nos artigos anteriores apresentamos a definição e a teoria do ágil Scrum o qual já apresenta algumas das regras que unem os elementos SCRUM e os papéis e responsabilidades do Time Scrum. EVENTOS SCRUM Os eventos Scrum representam o cerimonial do Time Scrum para que desenvolvam um Incremento utilizável de valor tangível para os Clientes e usuários ao longo de uma Sprint, permitindo que seus esforços e trabalhos gerem aprendizado e adaptação aos desafios que irão surgir. Todos os eventos SCRUM possuem duração fixa e, preferencialmente, devem ser executados no mesmo horário e local para facilitar as comunicações ainda mais se considerarmos práticas de gestão à vista para monitoramento e controle do progresso, tais como: gráfico burndown e burnup, kanban, etc. A gestão à vista contribui, também, para a transparência do projeto ao torná-lo visível a todos.   “Para que o ágil Scrum alcance o sucesso desejado é aconselhável que antes de se iniciar o projeto o Time Scrum se certifique de ter entendido o seu escopo e as necessidades do Cliente quanto à qualidade, prazos e custos.” Sprint (corrida/arrancada)  O evento Sprint é o principal evento do ágil Scrum pois é ao longo de sua execução que ocorrem os demais eventos: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
A Sprint é um evento com duração de 1 (um) mês ou menos para criar cadência e consistência ao trabalho do Time Scrum em atingir a meta do produto. As Sprints são realizadas consecutivamente sem intervalos entre si, uma nova Sprint se inicia imediatamente ao final da Sprint anterior. Cada Sprint é um projeto de curta duração. A Spring deve assegurar previsibilidade e garantir inspeção e adaptação ao longo de sua execução. Não há uma regra clara para a definição de sua duração sendo necessário considerar diversos aspectos, tais como: estabilidade do escopo, maturidade Scrum da organização, complexidade do projeto, riscos, investimento, etc., sendo importante ressaltar que a meta da Spring deve permanecer válida durante a sua execução. A Sprint poderá ser cancelada pelo Product Owner caso a meta definida se torne obsoleta, seja por mudança de tecnologia, mudança no direcionamento estratégico da organização, mudança de mercado ou quaisquer outros fatores. É durante a Sprint que ideias se transformam em valor, pois os itens do Product Backlog que serão priorizados (escopo) e trabalhados pelo Time Scrum resultarão em Incrementos utilizáveis do produto (valor). Além do mais, cada Sprint é um ciclo de aprendizado em que, devido ao empirismo do ágil Scrum, as experiências e observações vividas subsidiarão as tomadas de decisões futuras. Durante a Sprint:
Sprint Planning A Sprint Planning é conduzida pelo Scrum Master e deve ter duração máxima de 8 (oito) horas para Sprints de 1 (um) mês e duração menor para Sprints mais curtas. A reunião de Sprint Planning é o evento inicial da Sprint na qual o Time Scrum deve definir de forma colaborativa com o Product Owner os itens do Product Backlog que serão priorizados na Sprint, a meta da Sprint e o planejamento dos trabalhos da Sprint, esses 3 (três) produtos de gerenciamento definem o Sprint Backlog. Se necessário, outros participantes poderão ser convidados para aconselhamentos. A pauta principal do Sprint Planning inclui os seguintes tópicos:
Para responder a estas questões o Product Owner propõe uma discussão com os Developers e demais participantes para entendimento do valor e utilidade do produto, possíveis refinamentos do Product Backlog e esclarecimentos das dúvidas até que seja possível definir, de comum acordo, o Sprint Backlog. Para o detalhamento do esforço e do trabalho da Sprint os Developers, a seu critério, poderão decompor os itens priorizados em itens menores de um dia e que serão inspecionados e adaptados ao longo da Sprint, não cabendo a mais ninguém interferir em como ocorrerá à transformação dos itens priorizados em Incremento utilizável de valor ao atenderem suas Descrições de Pronto. O Time Scrum deve definir as atribuições específicas, as técnicas e ferramentas que serão aplicadas e a forma de inspeção do progresso da Sprint.
Daily Scrum A Daily Scrum é conduzida pelos Developers diariamente e deve ter duração máxima de 15 (quinze) minutos com o intuito de inspecionar o progresso e adaptar os trabalhos, se necessário, em direção à meta da Sprint, , criando foco e aprimorando a comunicação e o autogerenciamento. Considerando o envolvimento do Product Owner e do Scrum Master nos trabalhos estes participam da reunião. É ideal que os impedimentos identificados sejam tratados e decisões sejam tomadas em relação ao próximo dia de trabalho. Reuniões menos formais podem ser realizadas visando à adaptabilidade dos trabalhos a problemas que surjam. Sprint Review A Sprint Review é o penúltimo evento da Sprint sendo conduzida pelo Time Scrum de forma colaborativa com as partes interessadas e deve ter duração de 4 (quatro) horas para uma Sprint com duração de 1 (um) mês. O intuito desta reunião é a inspeção do Incremento resultante dos trabalhos do Time Scrum para avaliar se o Sprint Backlog foi plenamente atendido e, caso contrário, poderá conduzir a uma necessidade de revisão do Incremento, aceitação de uma dívida técnica (bug) e/ou ajustes no Product Backlog em decorrência de mudanças no ambiente do projeto. A aceitação de dívidas técnicas (bugs) visando realizar valor com o Incremento resultante da Sprint será administrada como um item do Product Backlog e tratada em outra Sprint. Sprint Retrospective A Sprint Retrospective é o último evento da Sprint sendo conduzida pelo Time Scrum e deve ter duração de 3 (três) horas para uma Sprint com duração de 1 (um) mês. O intuito desta reunião é inspecionar e adaptar os trabalhos realizados pelo Time Scrum mediante:
Com base nas experiências adquiridas em relação aos indivíduos, interações, processos, ferramentas e Definições de Pronto, o Time Scrum promove as adaptações pertinentes para a próxima Sprint. Um breve resumo do Guia Scrum RESPONSABILIDADES - TIME SCRUM Idealizado em 1990 pelos seus co-criadores Ken Schwaber e Jeff Sutherland em um ambiente de desenvolvimento de produtos de software, o ágil SCRUM é uma estrutura simples, leve e constituída dos seguintes elementos: responsabilidades, eventos, artefatos e as regras que os unem. No artigo anterior apresentamos a definição e a teoria do ágil Scrum o qual já apresenta algumas das regras que unem os demais elementos. Um Time Scrum envolve 3 (três) papéis e responsabilidades principais em sua estrutura:
Objetivando uma boa comunicação e maior produtividade, o Time Scrum deve ser pequeno o suficiente para ser ágil e grande o suficiente para concluir um trabalho significativo dentro de uma Sprint, normalmente 10 ou menos pessoas. Se o Time Scrum se tornar muito grande deve ser avaliado a sua reorganização em diversos Times Scrum que mantenham uma atuação coesa e focados no mesmo produto, ou seja, compartilhando a mesma meta do produto, Product Backlog e Product Owner. O Time Scrum é multifuncional e autogerenciável, não havendo sub-times ou hierarquias. Seus membros devem possuir todas as habilidades necessárias para criar valor a cada Sprint e para decidirem internamente quem faz o quê, quando e como, sendo responsável por todas as atividades relacionadas ao produto desde a sua concepção, construção e testes, criando Incrementos valiosos e úteis a cada Sprint. O ágil Scrum requer um Scrum Master para promover um ambiente harmonioso no qual: 1. O Product Owner ordene o trabalho (priorização de itens) para um problema complexo em um Product Backlog; 2. O Time Scrum transforme uma seleção do trabalho em um incremento de valor durante uma Sprint; e, 3. O Time Scrum e seus stakeholders inspecionem os resultados e se adaptam para a próxima Sprint.  Product Owner O Product Owner é um tomador de decisões que representa os Clientes e demais partes interessadas, não podendo ser um comitê, e domina os requisitos do produto a ser entregue. Deve possuir poder para exercer sua responsabilidade principal: gerenciar eficazmente o Product Backlog (lista de prioridades) de forma a maximizar o valor resultante do trabalho dos Developers e, mesmo que delegue suas atividades, continuará responsável pelo sucesso do projeto. O sucesso do ágil Scrum depende do respeito às decisões do Product Owner, as quais devem estar visíveis através do conteúdo e ordenação do Product Backlog e por meio do Incremento inspecionável na revisão da Sprint. Somente o Product Owner pode adicionar, excluir ou modificar a ordenação dos itens do Product Backlog, o Time Scrum e as demais partes interessadas devem convencê-lo caso desejem alterar o produto ou parte do produto. Suas atividades principais são:
Developers São pessoas com habilidades amplas (técnica, funcional ou outras) e comprometidas com o desenvolvimento do produto (trabalho = Incremento de valor da Sprint) e podem variar ao longo do projeto para assegurar o domínio sobre o trabalho a ser realizado, mas devesse evitar alterações ao longo de uma Sprint. O propósito do trabalho dos Developers é atender ao objetivo da Sprint, geralmente um problema de negócio que é abordado. A funcionalidade (itens do Product Backlog) pode ser ajustada durante a Sprint para que o trabalho dos Developers possa ser considerado concluído gerando valor em um Incremento utilizável que atenda a Descrição de Pronto. Suas atividades principais são:
Scrum Master (“Mestre” Scrum) O Scrum Master é um líder que atua como facilitador no Time Scrum e na organização, mas não possuindo a autoridade de um gerente tradicional. Ele é responsável por estabelecer o ágil Scrum atuando como uma guardião que ajuda as pessoas a entenderem a sua teoria, prática e regras, assegurando a incorporação dos pilares e valores do Scrum, respeitando as particularidades da organização. Ele também é responsável pela eficácia do Time Scrum ao permitir que seus integrantes melhorem suas práticas dentro da estrutura Scrum. Em relação aos Developers suas atividades são:
Em relação ao Product Owner suas atividades são:
Em relação às demais partes interessadas no produto (organização) suas atividades são:
“Para que o ágil Scrum alcance o sucesso desejado é aconselhável que antes de se iniciar o projeto seja assegurado que o Time Scrum e o Cliente compreendam os eventos Scrum e estejam cientes de seus papéis e responsabilidades no projeto.” Para o ágil Scrum o importante é determinar quais pessoas atuam no projeto e em qual papel, ressaltando que os papéis de Product Owner e de Scrum Master não podem ser exercidos por uma mesma pessoa, sendo irrelevante a função ou cargo na organização que essas pessoas efetivamente exercem.
Além dos papéis e responsabilidades relacionados acima o ágil Scrum permite que, quando necessário, outros papéis possam ser considerados, tais como: consultores (definição do Product Backlog), analistas de negócio (definição do Sprint Backlog), além das partes interessadas (Cliente/Usuário) que auxiliam na inspeção dos Incrementos. Segundo Daves J. West, as organizações que desejam implementar o ágil Scrum rapidamente costumam instituir o papel de Líderes Ágeis responsáveis em cobrir áreas da organização e cujas funções são:
Um breve resumo do Guia SCRUM |
