O Project Management Blueprint Parte 1: Uma comparação abrangente de Agile, Scrum, Kanban e Lean

Visão geral

Muitas metodologias são usadas no desenvolvimento de software hoje. Você já deve ter ouvido chavões como Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming, etc.

Neste artigo, definirei esses termos, discutirei como eles estão relacionados entre si e como eles diferem um do outro. Muitos dos chavões mencionados acima são baseados em conceitos do Lean Manufacturing, que foi originalmente baseado no Toyota Manufacturing System (TPS), então falaremos sobre isso primeiro.

Metodologia Lean

Origens do Lean e Lean Manufacturing

O termo “Lean” tem suas origens na manufatura, onde foi cunhado para descrever um modelo de manufatura baseado no Toyota Production System (TPS) originalmente desenvolvido por Sakichi Toyoda, Kiichiro Toyoda e Taiichi Ohno, originalmente inspirados por Henry Ford. O TPS estava focado na filosofia de “eliminação completa de todos os resíduos” e revolucionou a fabricação nas décadas de 1950 a 1970. O TPS ficou conhecido como “Lean Manufacturing” em 1990, quando “The Machine That Changed the World” foi publicado.

O TPS identificou três grandes tipos de resíduos na Toyota:

• Muda: traduzido como “desperdício”. Havia sete tipos de muda identificados na Toyota e um oitavo foi adicionado posteriormente. Estes são:
  • Defeitos: esforço envolvido em encontrar e corrigir defeitos
  • Superprodução: produção acima da demanda
  • Aguardando: aguardando a próxima etapa de produção, interrupções, etc.
  • Talento não utilizado: subutilização de recursos, treinamento inadequado, etc.
  • Transporte: peças móveis ou produtos que não são necessários para o processamento
  • Estoques: estoque finalizado e trabalho em andamento
  • Movimento: mover-se ou andar mais do que o necessário para o processamento

  • Processamento em excesso: de ferramentas ou design de produto ruim

• Muri: traduzido como “sobrecarga”. Muri geralmente resulta de mura, mas pode resultar de muda. Muri se manifesta em avarias, absenteísmo, questões de segurança, etc.
• Mura: traduzido como “desigualdade”. O Mura pode ser encontrado na flutuação da demanda do cliente, nos tempos de processo por produto ou na variação dos tempos de ciclo para diferentes operadores. Quando a mura não é reduzida, aumenta-se a possibilidade de muri e, portanto, muda. Mura pode ser reduzido criando abertura na cadeia de suprimentos, alterando o design do produto e criando um trabalho padrão para todos os operadores.

A TPS trabalhou para eliminar o desperdício aplicando estes dois conceitos principais:

• Jidoka: traduzido livremente como “automação com toque humano” estipula que “a qualidade deve ser incorporada durante o processo de fabricação!” o que significa que quando ocorre um problema, o equipamento para imediatamente, impedindo a produção de produtos defeituosos.
• Just-in-Time: Fazer apenas “o que é necessário, quando é necessário e na quantidade necessária”.

À medida que o TPS evoluiu, esses pilares e valores centrais foram construídos sobre os conceitos de Jidoka e JIT e se consolidaram:

• Melhoria continua:
  • Desafio: formar uma visão de longo prazo e enfrentar desafios com coragem e criatividade para realizar sonhos
  • Kaizen: melhorando continuamente as operações de negócios, sempre buscando inovação e evolução, eliminando um muda de cada vez
  • Genchi Genbutsu: praticando genchi genbutsu, indo à fonte para encontrar os fatos para tomar decisões corretas, construir consenso e atingir metas na nossa melhor velocidade
• Respeito pelas pessoas:
  • Respeito: respeitar os outros e fazer todos os esforços para entender uns aos outros, assumindo responsabilidades e fazendo o nosso melhor para construir confiança mútua
  • Trabalho em equipe: estimular o crescimento pessoal e profissional, compartilhar oportunidades de desenvolvimento e maximizar o desempenho individual e da equipe
• Andon: um indicador visual de status ou problema
• Heijunka: significa nivelamento ou nivelamento de produção
• Hansei: significa autorreflexão. Para melhorar a eficiência, os trabalhadores devem desafiar as suposições por trás dos processos atuais para encontrar melhores.
• Kanban: uma placa usada como ferramenta visual para controlar a produção
• Poka-yoke: Também conhecido como à prova de erros ou à prova de erros
• Sistema de puxar: o material é puxado para uma estação de trabalho conforme necessário
• Seiri: é o princípio que espelha o desperdício. Seiri dita que o que é desnecessário deve ser removido. Isso engloba todos os sete desperdícios originais do TPS
• Padronização: organiza todos os trabalhos em torno do movimento humano e cria uma sequência de produção eficiente sem desperdício. Isso ajuda a levar à qualidade, a um ritmo constante e permite a melhoria contínua.

O diagrama abaixo mostra como os conceitos centrais e os valores centrais se relacionam entre si.

Gestão Lean

O Toyota Product System e o Lean Manufacturing evoluíram ao longo do tempo e foram aplicados em várias áreas, incluindo a gestão.

A Gestão Lean aplicou os valores centrais da melhoria contínua e respeito pelas pessoas e os destilou em um conjunto de cinco princípios Lean prescritivos que seriam repetidos várias vezes para melhorar continuamente e eliminar o desperdício:

1. Identificar Valor: Especifique um valor do ponto de vista do cliente final por família de produtos.
2. Mapear Fluxo de Valor: Identifique todas as etapas do fluxo de valor para cada família de produtos, eliminando sempre que possível aquelas etapas que não criam valor.
3. Criar Fluxo: Faça com que as etapas de criação de valor ocorram em uma sequência apertada para que o produto flua suavemente em direção ao cliente.
4. Estabeleça o Pull: À medida que o fluxo é introduzido, permita que os clientes extraiam valor da próxima atividade upstream.
5. Buscar a perfeição: à medida que o valor é especificado, os fluxos de valor são identificados, as etapas desperdiçadas são removidas e o fluxo e o pull são introduzidos, inicia o processo novamente e continua até que um estado de perfeição seja alcançado em que o valor perfeito seja criado sem desperdício.

Esses princípios e outros aspectos da gestão Lean foram formalizados quando Womack & Jones publicou “Lean Thinking” em 1996.

Desenvolvimento de software enxuto

Desde então, o Lean tem sido aplicado à gestão, desenvolvimento de software e outros campos.

Nas décadas de 1980 e 1990, a indústria de desenvolvimento de software estava se aproximando de uma crise, pois os projetos executados usando metodologias tradicionais em cascata estavam demorando cada vez mais. Isso geralmente resultava em um enorme atraso entre a identificação de uma necessidade de negócios e a entrega de uma solução de software. Às vezes, esse atraso foi medido em vários anos, ou mesmo em décadas, em certas indústrias com requisitos específicos, como a indústria aeroespacial.

Durante esses prazos de vários anos, requisitos, sistemas ou até mesmo negócios inteiros mudaram. Muitas vezes, os projetos eram cancelados no meio do caminho ou completavam seu escopo, apenas para descobrir que o que eles entregavam não atende mais às necessidades de negócios identificadas no início do projeto.

A metodologia Waterfall recompensava as partes interessadas por pensarem em tudo, pois eram forçadas a redigir um contrato, embora provavelmente não tivessem certeza do que precisavam. A metodologia Waterfall forçava a tomada de decisões durante a fase de requisitos ou design, e essas decisões eram muito difíceis de mudar sem alterar o contrato e adicionar custos ao projeto. Uma alta porcentagem de projetos de software falhou completamente, ou foi entregue com atraso e acima do orçamento, ou falhou em entregar o que era necessário.

Essa frustração geral levou vários líderes de pensamento a tentar melhorar o Waterfall. Os primeiros exemplos incluem o Rapid Application Development (RAD), que se concentrou na redução do desperdício, encurtando os requisitos e as fases de design por meio do desenvolvimento rápido de um protótipo e da colaboração com os negócios para desenvolver ainda mais o requisito. Houve também um movimento em direção ao desenvolvimento iterativo, onde um pequeno projeto foi concluído e os recursos foram adicionados em iterações contínuas. Embora essas metodologias tenham ajudado, elas não resolveram os principais problemas associados ao Waterfall.

Na década de 1990 e início de 2000, vários autores publicaram livros sobre a aplicação dos princípios Lean ao desenvolvimento de software. Dr. Robert Charette publicou “Lean Software Development” em 1993 e “12 Principles of Lean Software Development” em 2003.

Tom e Mary Poppendieck publicaram “Lean Software Development: An Agile Toolkit” em 2003. Este livro detalhou sete princípios do Lean Development, que se correlacionam diretamente com as sete formas de desperdício na Lean Manufacturing. As semelhanças e diferenças entre as duas diferentes publicações Lean e Agile (discutidas na próxima seção) são apresentadas no diagrama abaixo.

Diferenças entre Lean e Agile

De acordo com o Dr. Charette, uma das principais diferenças entre Lean e Agile é que Agile é de baixo para cima, enquanto Lean é de cima para baixo.

Estrutura Ágil

Origens do Agile e do Manifesto Ágil

Na mesma época em que Charette e os Poppendiecks publicaram seus livros, o Agile Framework foi criado para ajudar a resolver os mesmos problemas. Em fevereiro de 2001, um grupo de pioneiros do Agile se reuniu na infame reunião Snowbird em Snowbird, Utah, para tentar encontrar uma solução.

O resultado foi o Manifesto Ágil, que estabeleceu um conjunto de valores e princípios para uma metodologia que tenta se adaptar às mudanças nos requisitos e necessidades dos clientes, reduzir o desperdício e fornecer benefícios mais rapidamente usando uma abordagem incremental e iterativa.

O Manifesto Ágil diz o seguinte:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar:

• Indivíduos e interações sobre processos e ferramentas
• Software funcionando sobre documentação abrangente
• Colaboração do cliente sobre a negociação do contrato
• Responder à mudança ao invés de seguir um plano

Ou seja, enquanto há valor nos itens da direita, valorizamos mais os itens da esquerda.”

Alinhados com os valores do manifesto estão os 12 princípios por trás do Manifesto Ágil:

“Seguimos estes princípios:

1. Nossa maior prioridade é satisfazer o cliente por meio da entrega antecipada e contínua de software valioso.
2. Bem-vindo à mudança de requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
3. Entregue o software em funcionamento com frequência, de algumas semanas a alguns meses, com preferência à escala de tempo mais curta.
4. Pessoas de negócios e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.
5. Construir projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte de que precisam e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa cara a cara.
7. Software funcionando é a principal medida de progresso. Processos ágeis promovem o desenvolvimento sustentável.
8. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
11. As melhores arquiteturas, requisitos e designs surgem de equipes auto-organizadas.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, depois ajusta e ajusta seu comportamento de acordo.”

Os valores e princípios acima são aplicações de princípios Lean como Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka e redução de desperdício.

Princípios Ágeis Aplicados ao Desenvolvimento de Software

Agile é uma estrutura abrangente que se aplica a qualquer processo que aplique o conjunto de valores e princípios Agile.

Alguns exemplos são:

• Programação extrema
• Scrum
• Kanban

Scrum

Breve História da Escória

Scrum é um framework que aplica princípios ágeis que foram inventados separadamente por várias pessoas, várias das quais assinaram o Manifesto Ágil:

• Hirotaka Takeuchi e Ikujiro Nonaka introduziram inicialmente o termo “scrum” em um contexto de fabricação em seu white paper “The New Product Development Game”. publicado em 1986 na Harvard Business Review.
• Jeff Sutherland, John Scumniotales e Jeff McKenna implementaram o Scrum na Easel Corporation em 1993.
• Ken Schwaber usou o que se tornaria Scrum em sua empresa, Advanced Development Methods na década de 1990.

Schwaber e Sutherland colaboraram durante a década de 1990 para desenvolver e refinar a estrutura em um contexto de desenvolvimento de software, falando em várias conferências. Schwaber trabalhou com Mike Beedle para descrever o método no livro “Agile Software Development with Scrum” em 2001.

Schwaber passou a criar as duas principais autoridades de certificação Scrum:

• Scrum Alliance: criada em 2001. Estabelece a série de acreditação Certified Scrum .
• Scrum.org: criado em 2009 depois que Schwaber deixou a Scrum Alliance. Configure a série paralela de acreditação Professional Scrum .

Ao longo do tempo, vários frameworks/organismos de certificação foram criados para abordar o dimensionamento do framework Scrum para equipes e projetos maiores, pois o Scrum foi originalmente projetado para equipes pequenas (7 mais ou menos 2 membros):

• SAFe: Estrutura ágil em escala
• LeSS: Scrum em grande escala
• Scrum@scale: Scrum em escala criado por Jeff Sutherland

Valores do Scrum

De acordo com a Scrum Alliance:

Scrum é um conjunto simples, mas incrivelmente poderoso, de princípios e práticas que ajudam as equipes a entregar produtos em ciclos curtos, permitindo feedback rápido, melhoria contínua e rápida adaptação às mudanças.

Scrum é uma estrutura prescritiva, incremental e iterativa para o desenvolvimento de software que aplica os princípios ágeis. Os valores e princípios do Scrum são descritos nos gráficos abaixo e têm alinhamento significativo com os valores e princípios Lean e Agile.

Visão geral do Scrum

O trabalho é dividido em iterações curtas, chamadas sprints, que geralmente duram de 1 a 3 semanas. Isso contrasta fortemente com o planejamento aprofundado de Waterfall. O trabalho planejado para o sprint atual é escolhido no topo de um backlog priorizado de itens de trabalho chamado Product Backlog (Pull System, Heijunka) e é corrigido assim que o sprint começa. O objetivo é ter um software funcionando ao final de cada sprint, permitindo um feedback rápido.

No final do sprint, a equipe se reúne para revisar o trabalho concluído, como foi o sprint e planejar o próximo sprint. A duração do sprint, assim como os rituais e a cadência do sprint, são fixados para cada sprint.

Sprints são executados por equipes multifuncionais contendo todas as habilidades necessárias para completar o trabalho no sprint. O planejamento diário e o rastreamento do progresso são feitos usando artefatos visuais como o quadro de scrum e gráficos de burndown de sprint.

O trabalho em um sprint é extraído de um backlog priorizado. Seguir esses métodos permite alterar os requisitos ao longo do tempo e incentiva o feedback constante dos usuários finais.

O diagrama do mapa mental abaixo descreve alguns dos principais conceitos de Scum que serão discutidos nas próximas seções.

Funções do Scrum

Scrum tem três papéis:

• Scrum Master : o Scrum Master é um líder servidor da equipe Scrum. Eles são os coaches da equipe que ajudam a facilitar a colaboração, removem impedimentos, reforçam e protegem o processo Scrum e protegem a equipe. Isso normalmente significa que eles organizam e facilitam os rituais do sprint, garantem que o proprietário do produto tenha um backlog devidamente priorizado e preparado, garante que a equipe não seja pressionada a se comprometer demais com um sprint, garante que o escopo não seja adicionado a um sprint, garante que a Definição de Pronto seja cumprida. Eles não atribuem tarefas aos membros da equipe (Genchi Genbutsu) e não são responsáveis ​​pela entrega de um projeto
• Product Owner : o product owner é o único responsável pela entrega do produto. O proprietário do produto define a visão do que eles querem construir e transmite essa visão para a equipe e a organização. O proprietário do produto é dono dos requisitos do negócio e do mercado e prioriza todo o trabalho que precisa ser feito através da criação e gerenciamento do backlog do produto. Eles decidem quais recursos enviar e quando. Eles trabalham com a equipe e outras partes interessadas para garantir que todos entendam os itens do backlog do produto. Eles aceitam ou rejeitam o trabalho concluído em um sprint na demonstração do sprint.
• Membro da equipe : A equipe Scrum é uma equipe auto-organizada e multifuncional normalmente composta por cinco a sete membros. Todos no projeto trabalham juntos e ajudam uns aos outros e não necessariamente vinculados a funções distintas, como arquiteto, programador, designer ou testador. Todos completam o conjunto de trabalho juntos. A equipe Scrum planeja quanto trabalho pode completar cada sprint e possui o plano (Genchi Genbutsu).

Fluxo, Atividades e Cerimônias do Scrum

Conforme discutido acima, o Scrum tem um fluxo definido e um conjunto de rituais e atividades. O fluxo de um sprint é o seguinte.

Planejamento de Sprint:

Antes de um sprint começar, o Scrum Master facilita uma reunião com a equipe scrum e o proprietário do produto, chamada de reunião de planejamento do sprint, onde o proprietário do produto identifica os objetivos do próximo sprint e a equipe planeja seu trabalho de acordo com os objetivos.

Isso geralmente é feito com as seguintes atividades:

• Capacidade do Sprint: a equipe determina a capacidade do sprint, levando em consideração o número de dias, número de membros da equipe, feriados, etc.
• Objetivos do Sprint: o proprietário do produto identifica quais são os objetivos do sprint. É fundamental que o backlog do produto seja priorizado de acordo com os objetivos (ou seja, as histórias relevantes estão no topo) e preparada.
• Seleção de trabalho: histórias ou tarefas são puxadas do topo do backlog para o sprint até que a capacidade estimada seja atingida. À medida que as histórias são trazidas, o proprietário do produto explicará a história e responderá às perguntas da equipe, atualizando a história conforme necessário, até que o proprietário do produto e a equipe Scrum tenham um bom entendimento comum da história. Uma vez que esta atividade é concluída, a equipe tem um escopo de sprint inicial proposto.
• Desdobramento da Tarefa: a equipe Scrum discute cada história em detalhes com ênfase no planejamento de como eles irão completar a história e abordar todos os critérios de aceitação e o DoD. Eles produzirão uma lista de subtarefas necessárias para completar a história. Assim que a lista de subtarefas estiver completa, a estimativa da história é revisada e atualizada, se necessário.
• Compromisso do Sprint: uma vez que todas as histórias são divididas e as estimativas são atualizadas, o escopo inicial do sprint proposto é revisado. Histórias podem ser removidas do sprint e colocadas de volta no backlog e/ou histórias adicionais podem ser adicionadas. Feito isso, SOMENTE a equipe Scrum (e não o Scrum Master ou o proprietário do produto) se compromete a concluir o trabalho no sprint, e o sprint é iniciado.

A quantidade total de trabalho ou escopo comprometido para o sprint é medido em pontos de história.

Execução de Sprint

Durante o sprint, os membros da equipe extraem itens de trabalho (histórias de usuários, tarefas etc.) do topo da lista de tarefas do sprint para trabalhar. Vários membros da equipe trabalharão nos vários itens de trabalho ou em suas subtarefas. Eles atualizarão o status de um item quando apropriado, movendo-o de uma coluna para a próxima (normalmente To Do > In Progress > Testing > Done ou alguma variação disso) no Scrum Board até que seja feito.

O progresso é rastreado usando um gráfico de burndown que mostra a quantidade de trabalho concluído e restante medido em pontos de história. Os pontos de história restantes são mostrados no eixo Y e o tempo restante é mostrado no eixo X. O gráfico de burndown é atualizado quando as histórias são concluídas.

Diariamente, o Scrum Master se concentra em:

• Facilita a reunião em pé diária para planejar o dia e revisar o progresso (veja abaixo)
• Garante que a equipe tenha um plano para o dia
• Remove bloqueios
• Protege o escopo do sprint e a equipe de distrações
• Ajuda a equipe a manter seu gráfico de burndown e outras estatísticas do Scrum

Levantamento Diário

No início de cada dia no sprint, o Scrum Master facilita uma breve reunião de 15 minutos com a equipe scrum e o proprietário do produto para planejar o dia e revisar o progresso do sprint. Esta é uma reunião curta onde todos estão em frente ao Scrum Board e cada pessoa na reunião responde as seguintes perguntas em 2 minutos ou menos, referindo-se a itens específicos no sprint board:

• O que você fez ontem?
• O que você está planejando fazer hoje?
• Há algum impedimento que o impeça de concluir seu trabalho?

Isso permite que todos vejam no que todos estão trabalhando, que progressos estão sendo feitos ou não, e identifiquem os impedimentos e/ou a ajuda necessária.

Conclusão do Sprint

O Scrum Master facilita duas cerimônias para encerrar o sprint antes de planejar o próximo sprint.

Demonstração do sprint

No final do sprint, o Scrum Master facilita uma reunião de demonstração do sprint, onde cada história concluída é demonstrada no software em funcionamento para o proprietário do produto e o restante da equipe. O proprietário do produto aceitará a história se todos os critérios de aceitação forem atendidos ou rejeitará a história. Se uma história for rejeitada, as deficiências são identificadas e a história é colocada de volta no backlog do produto em sua ordem de prioridade para ser concluída posteriormente ou não ser concluída. Muitas vezes, as partes de uma história que o proprietário do produto não aceita são divididas em histórias separadas e a história original é fechada.

O número total de pontos de história concluídos por sprint (Velocidade) é calculado e o sprint é encerrado. A velocidade é usada para rastrear o nível de produção da equipe e é usada para estimar quando os recursos ou versões serão concluídos.

Retrospectiva da Sprint

Após a demonstração do sprint, mas antes da próxima reunião de planejamento do sprint, o Scrum Master facilita uma retrospectiva do sprint, onde a equipe reflete sobre o sprint que acabou de ser concluído e discute o que deu certo e o que não deu certo para que eles possam melhorar continuamente e de forma incremental o processo e qualidade ao longo do tempo (Kaizen, Hansei). Há uma infinidade de formatos retrospectivos ou exercícios que podem ser usados ​​para ajudar a equipe a gerar discussões.

Uma lista de itens de ação de melhoria é produzida e, às vezes, eles resultam em itens sendo adicionados ao backlog do produto, alterações no DoD ou na carta da equipe, etc.

Gerenciamento do Backlog do Produto

Criação do Backlog do Produto

Antes que um sprint possa ser planejado ou executado, o proprietário do produto precisa criar um backlog de trabalho do produto. A lista de pendências geralmente começa com itens de desenvolvimento de recursos chamados histórias escritas pelo proprietário do produto e, com o tempo, também é preenchida com tarefas de desenvolvimento ou controle de qualidade, picos e defeitos, etc. potencialmente criados por qualquer membro da equipe. Todos os itens do backlog são organizados em ordem de prioridade.

Preparação de pendências

Depois que o backlog inicial do produto é criado e priorizado, o processo de preparação do backlog contínuo assume o controle. O objetivo é sempre ter, no mínimo, o suficiente dos principais itens do backlog preparados e estimados para que estejam prontos para serem puxados para um sprint durante uma reunião de planejamento do sprint. Isso normalmente é feito por meio de reuniões regulares de preparação de pendências com o gerente de produto e a equipe facilitadas pelo Scrum Master.

Antes da reunião, uma lista de histórias é enviada à equipe para que ela possa revisar e se preparar para a reunião de preparação. Na reunião de preparação, cada item é discutido em termos de critérios de aceitação, complexidade, risco, tamanho, estratégia de implementação, etc. Os critérios de aceitação e outros detalhes da história são revisados ​​e revisados ​​até que a equipe, o proprietário do produto e o Scrum Master têm uma compreensão comum da história. Nesse ponto, a história é estimada em pontos de história usando uma técnica chamada de planning poker.

Estimativa de pontos de história

Os pontos da história são uma unidade de esforço que usa dimensionamento relativo onde as histórias são comparadas com trabalhos anteriores, conhecidos e bem compreendidos. Você está sempre fazendo a pergunta “essa história é maior, menor ou aproximadamente do mesmo tamanho” que algum outro trabalho.

A escala de Fibonacci (1, 2, 3, 5, 8, 13, 21…) é a escala mais comumente usada, onde cada incremento é aproximadamente duas vezes maior que o anterior (ou seja, uma história de cinco pontos é mais ou menos duas vezes maior). grande como uma história de três pontos). Às vezes, outras escalas, como tamanhos de camisetas (XS, S, M, L, XL) ou até mesmo peixes (peixinho, peixinho, truta, atum, baleia, etc.) são usadas. Qualquer escala que permita comparar o tamanho de algo em relação a outro funcionará.

Os pontos de história representam todo o esforço da equipe para implementar uma história, incluindo desenvolvimento, teste, design e outras tarefas diversas necessárias para a Definição de Pronto. A estimativa leva em consideração a quantidade de trabalho, complexidade e risco. Uma vez que o tamanho relativo da história é determinado, um tamanho na escala é atribuído como estimativa.

As equipes se preparam para o processo de estimativa de pontos de história, primeiro estabelecendo uma linha de base para estimativa, escolhendo uma história de tamanho “mais médio” que toda a equipe entende como uma história de referência. Algumas histórias de referência adicionais que são maiores e menores também são escolhidas.

A estimativa de pontos de história é feita durante as reuniões de preparação e, às vezes, durante o planejamento do sprint usando o Planning Poker:

1. Cada membro da equipe/estimador tem um conjunto de cartões.
2. Os itens do backlog são discutidos um de cada vez, conforme descrito acima.
3. Uma vez que o item foi totalmente discutido, cada estimador escolhe em particular um cartão para representar sua estimativa.
4. Quando todos os estimadores tiverem feito suas estimativas, eles revelam suas cartas ao mesmo tempo.
   • Se todas as estimativas corresponderem, os estimadores selecionam outro item da lista de pendências e repetem o mesmo processo.
   • Quando as estimativas diferem, os estimadores discutem a questão para chegar a um consenso.

As vantagens da estimativa de pontos de história são:

• Rápido: as estimativas são relativas aos itens do backlog do produto já concluídos.
• Preciso o suficiente: preciso o suficiente para fornecer uma visão geral do escopo, planejar trabalhos futuros, priorizar e gerenciar expectativas.
• Abraça a Incerteza: Os pontos de história especificam um intervalo de tempo desconhecido. A seleção de uma sequência específica de pontos de história semelhantes a Fibonacci permite capturar a incerteza.
• Team Sport: Envolve todos (desenvolvedores, designers, QA, gerentes de produto). Usa várias perspectivas para determinar o tamanho do trabalho, mas apenas os membros da equipe que fazem o trabalho podem estimar
• Mede a velocidade da equipe: mede quanto trabalho uma equipe faz em um sprint versus a quantidade de tempo gasto fazendo o trabalho. À medida que a equipe melhora, eles completam histórias do mesmo tamanho mais rapidamente, resultando em uma maior velocidade de pontos de história ao longo do tempo.

Estimativa e acompanhamento de lançamentos

A estimativa de pontos de história também é usada em um contexto de planejamento de lançamento usando a seguinte técnica:

1. Liste todas as histórias a serem dimensionadas
2. Coloque-os em ordem do menor para o maior
   • Pegue a primeira e a segunda história de usuário.
   • Decida qual é maior e coloque o maior abaixo
   • Então pegue o próximo e decida onde ele se encaixa em relação aos outros dois
   • Repita o processo até que todas as histórias estejam agora na lista (em uma sequência do menor para o maior)
3. Dimensione as histórias

As estimativas de história para todas as histórias em uma versão combinada com a velocidade da equipe permitirão que você estime quando uma versão será concluída e acompanhe seu progresso. Isso geralmente é mostrado em um gráfico de queima de lançamento.

Os Artefatos e Termos do Scrum

• Product Backlog: Uma lista de backlog de todos os itens de trabalho para um determinado produto que pode incluir recursos (histórias), tarefas técnicas, picos e defeitos
• Release Burn-up: Um gráfico gráfico usado para mostrar o progresso em um nível de lançamento e prever quando um lançamento será concluído usando o Sprint Velocity. Os pontos de história concluídos são mostrados no eixo Y e os sprints são mostrados no eixo X.
• Sprint Backlog: Uma lista de backlog de todos os itens de trabalho a serem concluídos em um determinado sprint. O conteúdo do sprint backlog é acordado durante a reunião de planejamento do sprint.
• Scrum Board: Um quadro de estilo de tabela que acompanha o progresso do trabalho comprometido para o sprint. Os status são mostrados na parte superior em colunas verticais e os itens de trabalho são movidos em cada status até que sejam concluídos. O quadro do scrum é preenchido durante a reunião de planejamento do sprint e é redefinido no final de um sprint.
• Sprint Burndown: Um gráfico gráfico que mostra a quantidade de trabalho concluído e restante medido em pontos de história ao longo da duração do sprint. Os pontos de história restantes são mostrados no eixo Y e o tempo restante é mostrado no eixo X.
• Velocidade do Sprint: O número de pontos de história que uma equipe Scrum completa em um sprint.
• Backlog de Impedimentos: Uma lista de impedimentos que precisam ser abordados pelo Scrum Master para que a equipe possa continuar trabalhando. Quando um membro da equipe é bloqueado, ele adiciona um item ao backlog de impedimentos para fornecer visibilidade à equipe e ao Scrum Master.
• Épico: Um épico é um grande corpo de trabalho que consiste em várias histórias de usuários relacionadas.
• História do usuário: uma história do usuário é uma descrição de um recurso de software da perspectiva do usuário final. A história do usuário descreve o tipo de usuário, o que eles querem e por quê. Uma história de usuário ajuda a criar uma descrição simplificada de um requisito e inclui critérios de aceitação. As histórias de usuário são criadas e mantidas pelo proprietário do produto.
• Tarefa: Uma tarefa é uma parte do trabalho que é inserida pelo Scrum Master ou membro da equipe que pode estar direta ou indiretamente relacionada às histórias do usuário. Eles geralmente são de natureza técnica e incluirão critérios de aceitação.
• Spike: Um pico é um tipo especial de tarefa que é usado quando você precisa pesquisar, prototipar e/ou arquitetar em algum momento antes de decidir como implementar ou estimar uma história de usuário.
• Subtarefa: Uma subtarefa é uma tarefa inserida como uma etapa de implementação para concluir uma história ou tarefa do usuário. Eles geralmente são inseridos pela equipe durante uma reunião de planejamento do sprint.
• Estimativas de pontos de história: uma escala de estimativa de tamanho relativo baseada na escala de Fibonacci (1, 2, 3, 5, 8, 13, 21…)
• Critérios de Aceitação: A lista de itens testáveis ​​específicos da história incluídos em cada história que devem ser concluídos antes que um proprietário do produto aceite uma história como concluída.
• Definição de Pronto (DoD): Uma lista de etapas ou critérios comuns que devem ser concluídos antes que qualquer história possa ser considerada concluída. A equipe concorda com isso e documenta para que não precise ser listado em todas as histórias.

Vantagens e Desvantagens do Scrum

A principal vantagem do Scrum é a aplicação de valores e princípios ágeis, bem como conceitos Lean, como Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System e Iterations. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.