Visão geral

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

Neste artigo, irei definir esses termos, discutir como eles se relacionam e como diferem entre si. Muitos dos chavões mencionados são baseados em conceitos de Manufatura Enxuta que foi originalmente baseado no Sistema Toyota de Fabricação (TPS) então vamos falar sobre isso primeiro.

Metodologia Enxuta

Origens da Manufatura Enxuta e Enxuta

O termo “Lean” tem sua origem na fabricação, onde foi cunhado para descrever um modelo de fabricação baseado no Sistema Toyota de Produção (TPS) originalmente desenvolvido por Sakichi Toyoda, Kiichiro Toyoda e Taiichi Ohno, que foram originalmente inspirados por Henry Ford. A TPS estava focada na filosofia de “eliminação completa de todos os resíduos” e revolucionou a fabricação nas décadas de 1950 a 1970. TPS tornou-se conhecido como 'Manufatura Enxuta' em 1990 quando “A máquina que mudou o mundo” foi publicado.

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

• Jovem: traduzido como “desperdício”. Havia sete tipos de muda identificados na Toyota e um oitavo foi adicionado posteriormente. Esses são:
  • Defeitos: esforço envolvido na localização e correção de defeitos
  • Superprodução: produção à frente da demanda
  • Esperando: aguardando a próxima etapa de produção, interrupções, etc.
  • Talento não utilizado: subutilização de capacidades, treinamento inadequado, etc.
  • Transporte: peças móveis ou produtos que não são necessários para o processamento
  • Os inventários: inventário concluído e trabalho em andamento
  • Movimento: movendo ou andando mais do que o necessário para o processamento

  • Excesso de processamento: de ferramentas pobres ou design de produto

    

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

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

• Jidoka: Traduzido livremente como 'automação com um 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 pára imediatamente, evitando que produtos defeituosos sejam produzidos.
• Na hora certa: Fazendo apenas “o que é necessário, quando é necessário e na quantidade necessária”.

À medida que o TPS evoluía, esses pilares e valores fundamentais construídos sobre os conceitos de Jidoka e JIT e ficou arraigado:

• Melhoria continua:
  • Desafio: formando uma visão de longo prazo e enfrentando 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 em nossa melhor velocidade
• Respeito pelas Pessoas:
  • Respeito: respeitar os outros e fazer todos os esforços para compreender uns aos outros, assumindo a responsabilidade e fazendo o nosso melhor para construir confiança mútua
  • Trabalho em equipe: estimulando o crescimento pessoal e profissional, compartilhando oportunidades de desenvolvimento e maximizando o desempenho individual e da equipe
• Andon: um indicador visual de status ou problema
• Heijunka: significa nivelamento ou nivelamento da 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 outros melhores.
• Kanban: uma placa usada como uma ferramenta visual para controlar a produção
• Poka-yoke: Também conhecido como prova de erro ou prova de erro
• Sistema de tração: O material é puxado para uma estação de trabalho assim que é necessário
• Seiri: é o princípio que reflete o desperdício. Seiri determina que o que é desnecessário deve ser removido. Isso abrange todos os sete resíduos originais de TPS
• Estandardização: organiza todos os trabalhos em torno do movimento humano e cria uma sequência de produção eficiente sem muda. Isso ajuda a levar à qualidade, a um ritmo constante e permite a melhoria contínua.

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

Gestão Enxuta

O Sistema Toyota de Produtos e a Manufatura Enxuta evoluíram ao longo do tempo e foram aplicados em várias áreas, incluindo a gestão.

Gestão Enxuta aplicou os valores essenciais de 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 e eliminar o desperdício continuamente:

1. Identifique o valor: Especifique um valor do ponto de vista do cliente final por família de produtos.
2. Fluxo de valor do mapa: Identifique todas as etapas do fluxo de valor de 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 seqüência precisa para que o produto flua suavemente em direção ao cliente.
4. Estabelecer atração: Conforme o fluxo é introduzido, deixe que os clientes extraiam valor da próxima atividade upstream.
5. Procurar perfeição: Conforme o valor é especificado, os fluxos de valor são identificados, as etapas perdidas são removidas e o fluxo e o pull são introduzidos, inicie o processo novamente e continue até que um estado de perfeição seja alcançado no qual o valor perfeito seja criado sem desperdício.

Esses princípios e outros aspectos do gerenciamento Lean foram formalizados quando Womack & Jones publicou “Lean Thinking” em 1996.

Desenvolvimento Lean de Software

Desde então, o Lean tem sido aplicado ao gerenciamento, 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, à medida que os projetos executados com as metodologias tradicionais em cascata estavam demorando cada vez mais. Isso geralmente resultava em um grande intervalo entre a identificação de uma necessidade comercial e o fornecimento de uma solução de software. Às vezes, esse atraso foi medido em vários anos ou mesmo em décadas em certos setores com requisitos específicos, como o setor aeroespacial.

Durante esses prazos de vários anos, requisitos, sistemas ou até mesmo empresas inteiras mudaram. Freqüentemente, os projetos seriam cancelados no meio ou eles completariam seu escopo, apenas para descobrir que o que eles entregaram não atendia mais às necessidades de negócios identificadas no início do projeto.

o Metodologia em cascata recompensou as partes interessadas por pensar em tudo enquanto eram forçadas a escrever um contrato, embora provavelmente não tivessem certeza do que precisavam. A metodologia em cascata 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 não entregou o que era necessário.

Essa frustração geral levou a vários líderes de pensamento tentando melhorar o Waterfall. Os primeiros exemplos incluem Desenvolvimento rápido de aplicativos (RAD) que se concentrou na redução do desperdício, abreviando os requisitos e as fases de design por meio do desenvolvimento rápido de um protótipo e da colaboração com as empresas para desenvolver ainda mais o requisito. Houve também uma mudança em direção ao desenvolvimento iterativo, em que um pequeno projeto foi concluído e os recursos foram adicionados em iterações contínuas. Embora essas metodologias ajudassem, elas não resolveram o problemas centrais associados a Cachoeira .

Nos anos 1990 e no início dos anos 2000, vários autores publicaram livros sobre a aplicação dos princípios Lean ao desenvolvimento de software. Dr. Robert Charette publicou “Desenvolvimento Lean de Software” em 1993 e “12 Princípios de Desenvolvimento Lean de Software” em 2003.

Tom e Mary Poppendieck publicaram “Lean Software Development: An Agile Toolkit” em 2003. Este livro detalhou sete princípios do Desenvolvimento Enxuto, que se correlacionam diretamente com as sete formas de desperdício na Manufatura Enxuta. 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 o Lean e o Agile é que o Agile é de baixo para cima, enquanto o Lean é de cima para baixo.

Metas

Desenvolvimento de software enxuto da Charette	O Manifesto Ágil	Lean de Poppendieck
1/3 Esforço humano 1/3 horas de desenvolvimento 1/3 vez 1/3 Investimento 1/3 Esforço para se adaptar	Indivíduos e interações Software de trabalho Colaboração do cliente Respondendo à mudança

Princípios

Desenvolvimento de software enxuto da Charette	O Manifesto Ágil	Lean de Poppendieck
Satisfação do cliente Custo-benefício Participação do cliente Esforço de equipe Tudo é mutável Domínio, não soluções pontuais Completo, não construa 80% de solução hoje Minimalismo é essencial As necessidades determinam a tecnologia O crescimento do produto é o crescimento de recursos Cuidado com os limites	Satisfação do cliente Bem-vindo a mudanças de requisitos Ciclos frequentes de entrega Colaboração das partes interessadas Cultura de confiança, apoio e motivação Comunicação cara a cara Software funcional é a métrica Desenvolvimento sustentável Excelência técnica Simplicidade Equipes auto-organizadas Reflexão da equipe	Eliminar desperdício Amplifique a aprendizagem Entregue o mais rápido possível Decida o mais tarde possível Capacite a equipe Construa integridade no produto Veja todo o processo

Framework Agile

Origens do Agile e o Manifesto Agile

Na mesma época 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 do 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 de requisitos e necessidades do cliente, cortar desperdícios e entregar benefícios mais rapidamente usando uma abordagem incremental e iterativa.

O Manifesto Ágil é o seguinte:

“Estamos descobrindo melhores maneiras de desenvolver software fazendo isso e ajudando outros a fazerem. Por meio deste trabalho, chegamos a valorizar:

• Indivíduos e interações sobre processos e ferramentas
• Software de trabalho sobre documentação abrangente
• Colaboração do cliente sobre negociação de contrato
• Respondendo à mudança sobre seguir um plano

Ou seja, embora haja valor nos itens à direita, valorizamos mais os itens à 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 a mudanças de requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
3. Entregue software funcional com freqüência, de algumas semanas a alguns meses, com preferência para a escala de tempo mais curta.
4. Empresários e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto.
5. Construa 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 face a face.
7. O software funcional é 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 realizado - é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizadas.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, em seguida, sintoniza e ajusta seu comportamento de acordo. ”

Os valores e princípios acima são aplicações dos 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 é uma estrutura que aplica os princípios do Agile que foram inventados separadamente por várias pessoas, várias das quais assinaram o Manifesto Agile:

• Hirotaka Takeuchi e Ikujiro Nonaka inicialmente introduziram o termo 'scrum' em um contexto de manufatura 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 viria a ser o Scrum em sua empresa, Métodos de Desenvolvimento Avançado na década de 1990.

Schwaber e Sutherland colaboraram ao longo da 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 do Scrum:

• Scrum Alliance : criado em 2001. Configure o Scrum certificado série de acreditação.
• Scrum.org : criado em 2009 depois que Schwaber deixou a Scrum Alliance. Configure o paralelo Scrum Profissional série de acreditação.

Com o 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):

• Seguro : Framework Agile escalado
• Menos : Scrum em larga escala
• [email protegido] e: Scrum em escala criado por Jeff Sutherland

Valores Scrum

De acordo com a Scrum Alliance:

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

Scrum é uma estrutura prescritiva, incremental e iterativa para o desenvolvimento de software que aplica os princípios Agile. 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 de curta duração chamadas sprints, que geralmente duram de 1 a 3 semanas. Isso contrasta fortemente com o planejamento detalhado de Waterfall. O trabalho planejado para o sprint atual é escolhido a partir do 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, bem 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 acompanhamento do progresso são feitos usando artefatos visuais como o scrum board e os gráficos sprint burndown.

O trabalho em um sprint é retirado de uma lista de pendências priorizada. Seguir esses métodos permite mudanças nos 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 Scrum

Scrum tem três funções:

• Scrum Master : o Scrum Master é um líder servidor da equipe Scrum. Eles são o treinador da equipe que ajuda a facilitar a colaboração, remove impedimentos, reforça e protege o processo Scrum e protege a equipe. Isso normalmente significa que eles organizam e facilitam os rituais de sprint, garantem que o product owner tenha uma lista de pendências devidamente priorizada e preparada, garantem que a equipe não seja pressionada a se comprometer excessivamente com um sprint, garantem 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
• Proprietário do produto : o proprietário do produto é 'o único pescoço que se pode torcer' responsável pela entrega do produto. O product owner define a visão do que deseja construir e transmite essa visão para a equipe e a organização. O product owner é o 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 da carteira de produtos. Eles aceitam ou rejeitam o trabalho concluído em um sprint na demonstração do sprint.
• Membro da Equipe : A equipe Scrum é auto-organizada e multifuncional, normalmente composta de cinco a sete membros. Todos no projeto trabalham juntos e ajudam uns aos outros, 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 é dona do plano (Genchi Genbutsu).

Fluxo de Scrum, Atividades e Cerimônias

Conforme discutido acima, 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 então planeja seu trabalho de acordo com os objetivos.

Isso geralmente é feito com as seguintes atividades:

• Capacidade de Sprint: a equipe determina a capacidade para o sprint, levando em consideração o número de dias, número de membros da equipe, feriados, etc.
• Objetivos do Sprint: o product owner 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 preparado.
• Seleção de Trabalho: histórias ou tarefas são puxadas do topo da lista de pendências para o sprint até que a capacidade estimada seja atingida. Conforme as histórias são inseridas, o product owner vai explicar a história e responder às perguntas da equipe, atualizando a história conforme necessário, até que o product owner e a equipe Scrum tenham um bom entendimento comum da história. Depois que essa atividade for concluída, a equipe tem um escopo inicial de sprint proposto.
• Divisão de tarefas: 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 Sprint: uma vez que todas as histórias são divididas e as estimativas são atualizadas, o escopo do sprint inicial proposto é revisado. As 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 a sprint é medida em pontos da história.

Execução Sprint

Durante o sprint, os membros da equipe puxam itens de trabalho (histórias de usuário, tarefas, etc.) do topo da lista de tarefas pendentes para trabalhar. Vários membros da equipe trabalharão nos vários itens de trabalho ou em suas subtarefas. Eles irão atualizar o status de um item quando apropriado, movendo-o de uma coluna para a próxima (normalmente A fazer> Em andamento> Teste> Concluído ou alguma variação) no Scrum Board até que seja feito.

O progresso é rastreado usando um gráfico burndown que mostra a quantidade de trabalho concluído e o 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 burndown é atualizado quando as histórias são concluídas.

Diariamente, o Scrum Master se concentra em:

• Facilita a reunião diária para planejar o dia e revisar o progresso (veja abaixo)
• Garante que a equipe tenha um plano para o dia
• Remove roadblocks
• 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 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 do scrum e o product owner 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 às 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?
• Existe algum impedimento que o impeça de concluir seu trabalho?

Isso permite que todos vejam no que todos estão trabalhando, que progresso está sendo feito ou não e identifique impedimentos e / ou ajuda necessária.

Conclusão do Sprint

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

Sprint Demo

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 de trabalho para o proprietário do produto e o resto 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 na lista de pendências do produto em sua ordem de prioridade para ser concluída posteriormente ou não será concluída. Freqüentemente, as partes de uma história que o product owner não aceita são divididas em histórias separadas e a história original é encerrada.

O número total de pontos da 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 lançamentos serão concluídos.

Retrospectiva de 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 concluir e discute o que deu certo e o que não deu certo para que possam melhorar o processo de forma contínua e incremental e qualidade ao longo do tempo (Kaizen, Hansei). Há uma infinidade de formatos ou exercícios retrospectivos 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, mudanças no DoD ou estatuto da equipe, etc.

Gestão do Backlog do Produto

Criação do Backlog do Produto

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

Backlog Grooming

Depois que o backlog inicial do produto é criado e priorizado, o processo de preparação do backlog contínuo assume o controle. A meta é sempre ter, no mínimo, o suficiente dos principais itens da lista de pendências 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 pedidos pendentes com o gerente de produto e a equipe facilitada pelo Scrum Master.

Antes da reunião, uma lista de histórias é enviada à equipe para que eles possam 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 tenha um entendimento comum da história. Nesse ponto, a história é estimada em pontos de história usando uma técnica chamada planning poker.

Estimativa de Story Point

Os pontos da história são uma unidade de esforço que usa dimensionamento relativo, onde as histórias são comparadas com peças de trabalho anteriores, conhecidas e bem compreendidas. Você está sempre fazendo a pergunta “esta história é maior, menor ou aproximadamente do mesmo tamanho” como alguma outra peça de trabalho.

A escala 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 mais grande como uma história de três pontos). Às vezes, outras escalas como tamanhos de camisetas (XS, S, M, L, XL) ou mesmo peixes (peixinho, peixinho dourado, truta, atum, baleia, etc.) são usados. Qualquer escala que permita comparar o tamanho de algo em relação a outro funcionará.

Os pontos da 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 Concluído. A estimativa leva em consideração a quantidade de trabalho, complexidade e risco. Depois 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 da história estabelecendo primeiro uma linha de base para estimativa, escolhendo uma história de tamanho '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 do storypoint é 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 / avaliador possui um conjunto de cartas.
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 avaliador escolhe em particular um cartão para representar sua estimativa.
4. Quando todos os estimadores fizeram suas estimativas, eles revelam suas cartas ao mesmo tempo.
   • Se todas as estimativas coincidirem, os estimadores selecionam outro item da carteira 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 da história são:

• Rápido: as estimativas são relativas aos itens da carteira de produtos já concluídos.
• Exato o suficiente: preciso o suficiente para fornecer uma visão geral do escopo, planejar o trabalho futuro, priorizar e gerenciar as expectativas.
• Abraça a incerteza: Os pontos da história especificam um intervalo de tempo desconhecido. A seleção de uma sequência específica de pontos da história semelhante a Fibonacci permite capturar a incerteza.
• Time esportivo: Envolve todos (desenvolvedores, designers, QA, gerentes de produto). Usa múltiplas 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 a quantidade de trabalho que uma equipe realiza em um sprint em comparação com a quantidade de tempo gasto no trabalho. À medida que a equipe melhora, eles completam histórias do mesmo tamanho mais rapidamente, resultando em uma velocidade maior de pontos de história ao longo do tempo.

Estimativa e rastreamento de liberação

A estimativa de ponto da história também é usada em um contexto de planejamento de liberação usando a seguinte técnica:

1. Liste todas as histórias a serem dimensionadas
2. Coloque-os em ordem do menor para o maior
   • Veja a primeira e a segunda história de usuário.
   • Decida qual é maior e coloque o maior abaixo
   • Em seguida, 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 da menor para a maior)
3. Dimensione as histórias

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

Os artefatos e termos do Scrum

• Backlog do produto: Uma lista de pendências de todos os itens de trabalho para um determinado produto, que pode incluir recursos (histórias), tarefas técnicas, picos e defeitos
• Liberar Burn-up: Um gráfico usado para mostrar o progresso em um nível de versão e prever quando uma versão será finalizada usando Sprint Velocity. Os pontos da história concluídos são mostrados no eixo Y e as sprints são mostradas no eixo X.
• Sprint Backlog: Uma lista de pendências 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 em estilo de tabela que acompanha o andamento 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 scrum board é preenchido durante a reunião de planejamento do sprint e é reiniciado no final de um sprint.
• Sprint Burndown: Um gráfico que mostra a quantidade de trabalho concluído e restante medido em pontos da história ao longo da sprint. Os pontos de história restantes são mostrados no eixo Y e o tempo restante é mostrado no eixo X.
• Velocidade de sprint: O número de pontos de história que uma equipe Scrum completa em uma sprint.
• Backlog de impedimentos: Uma lista de impedimentos que precisam ser resolvidos 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 dar 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 de 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 ele deseja 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 inserida pelo Scrum Master ou membro da equipe que pode estar direta ou indiretamente relacionada às histórias de usuário. Geralmente são de natureza técnica e incluem critérios de aceitação.
• Espinho: Um pico é um tipo especial de tarefa que é usado quando você precisa pesquisar, prototipar e / ou arquitetar algum tempo 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 de usuário ou tarefa. Eles geralmente são inseridos pela equipe durante uma reunião de planejamento do sprint.
• Estimativas do Story Point: Uma escala de estimativa de tamanho relativo que se baseia na escala de Fibonacci (1, 2, 3, 5, 8, 13, 21 ...)
• Critérios de aceitação: A lista de itens testáveis ​​e específicos da história, incluídos em cada história que deve ser concluída antes que o product owner aceite uma história como concluída.
• Definição de Feito (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 Agile, bem como conceitos Lean como Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Sistema Pull e Iterações. A aplicação desses princípios permite que as equipes de projeto recebam feedback contínuo, adaptem-se rapidamente às mudanças de requisitos e incertezas, reduzam o desperdício, aumentem a visibilidade e a transparência e se esforcem para melhorar continuamente. Sempre focando nos itens mais importantes no backlog do produto e trabalhando apenas em iterações curtas que sempre produzem software funcional, o Scrum é mais focado no cliente e permite que os clientes vejam o que gostam (e não gostam) e façam as alterações conforme necessário. O custo indireto em termos de processo e gerenciamento é menor, levando a resultados mais rápidos e baratos.

Scrum é uma ótima metodologia para projetos com requisitos que não são claramente conhecidos e / ou não devem ser alterados. Isso se aplica à maioria dos projetos. Scrum também é ótimo para equipes experientes e motivadas, pois permite que as equipes organizem o trabalho e fornece visibilidade, transparência e responsabilidade tanto pelo progresso quanto pelos problemas. Tudo isso resultará em equipes melhorando e se tornando mais produtivas com o tempo.

Scrum tem algumas desvantagens e não é a melhor metodologia em algumas situações:

• Transparência: Scrum aumenta a transparência e responsabilidade, o que é tanto uma vantagem quanto uma desvantagem, pois os problemas e o desempenho ruim dentro e fora da equipe são expostos. Isso pode ser desconfortável e pode levar à resistência se não for tratado adequadamente dentro da estrutura do Scrum de melhoria contínua.
• Experiência e Compromisso da Equipe: Equipes Scrum ou Scrum Masters inexperientes e / ou descomprometidos podem causar sérios problemas por meio da aplicação incorreta da metodologia Scrum. Não há funções definidas na equipe Scrum, pois todos fazem tudo, portanto, requer membros da equipe comprometidos com experiência técnica para seguir o processo Scrum e melhorar ao longo do tempo. Também pode ser muito prejudicial se outras partes da organização forem resistentes ao Scrum.
• Oportunista: Há um risco de aumento do escopo, especialmente se não houver uma data de término definida, pois as partes interessadas podem adicionar ao escopo. Ser capaz de mudar o escopo e as prioridades é uma das principais vantagens do Scrum, mas também pode ser uma desvantagem se a disciplina não for usada.
• Trabalho mal definido: Histórias de usuários ou tarefas mal definidas e compreendidas podem levar a retrabalho, estimativas imprecisas e aumento de escopo. Embora o Scrum esteja focado em trabalhar o software em vez da documentação, o proprietário do produto precisa ser claro sobre o que deseja e ser capaz de comunicar isso claramente nas conversas e nas histórias de usuário.
• Dimensionamento: Adotar o framework Scrum em equipes grandes é um desafio, pois o Scrum se destina a equipes menores.

Kanban

O que é Kanban?

Kanban é um processo mais leve que aplica muitos dos valores Lean e Agile, bem como um subconjunto dos valores e princípios do Scrum, mas também há algumas diferenças fundamentais. Kanban se concentra na visualização, fluxo e limitação do trabalho em andamento.

Kanban é a palavra japonesa para “signboard” ou “billboard”. Os trabalhadores de linha da Toyota usaram um kanban (ou seja, uma placa real) para sinalizar a capacidade extra em várias etapas do processo de fabricação. No software, isso é feito com um quadro Kanban, que é muito semelhante ao quadro Scrum. Há uma lista de pendências priorizada de itens de tarefas pendentes e colunas verticais para cada status que um item de trabalho pode ter. Como Scrum, os itens de trabalho são movidos de um status para outro; entretanto, no Kanban, a quantidade de trabalho em andamento é estritamente limitada a um número máximo de itens em cada status com base na capacidade da equipe. O novo trabalho não pode ser puxado até que o trabalho existente seja movido para a próxima etapa do processo. No Scrum, o trabalho em andamento é indiretamente limitado pelo controle da quantidade de trabalho planejada para um sprint.

No Kanban, não há iterações fixas ou sprints, apenas um fluxo constante onde os itens de trabalho são puxados de um estágio para o próximo. Isso significa que o quadro Kanban nunca é redefinido. Isso também significa que muitos dos rituais do Scrum não são usados. As equipes Kanban geralmente têm reuniões diárias, mas não são prescritas. Não há reuniões de planejamento de sprint planejadas regularmente, demos de sprint ou retrospectivas de sprint, então o processo é mais leve. Algumas das atividades nesses rituais podem ou não ser realizadas em um nível informal. A melhoria contínua é realizada rastreando e analisando o fluxo de itens de um estado para outro e fazendo melhorias incrementais constantes com base em quais problemas são descobertos.

Kanban também não prescreve as funções que Scrum faz. A única função necessária é a função de membro da equipe, no entanto, muitas vezes há um gestor de projeto que gerencia a equipe e o backlog. Freqüentemente, um único quadro Kanban pode servir a múltiplas funções baseadas em funções e / ou equipes que trabalham apenas em itens em um determinado status. Por exemplo, uma equipe de desenvolvimento pode puxar itens de A Fazer para Em Andamento e movê-los para Teste, e a equipe de teste pode testar itens em Teste e movê-los para Concluído.

Muitas das atividades de gerenciamento de backlog para priorização e preparação de itens de trabalho ainda precisam ser feitas para garantir que um determinado item de trabalho seja bem compreendido e pronto para ser trabalhado; no entanto, estimar os itens de trabalho é prescrito como opcional.

Kanban vs. Scrum

A tabela a seguir compara Scrum e Agile:

Kanban	Scrum
Entrega Contínua	Sprints com cronometragem
Menos processo e sobrecarga	Prescreveu rituais e funções de Sprint
Concentra-se em completar itens individuais rapidamente	Concentra-se em concluir um lote de trabalho rapidamente
Tempo de ciclo de medidas	Mede a velocidade do sprint
Concentra-se no fluxo eficiente	Foca na previsibilidade
Limita WIP para itens individuais	Limita o WIP em um nível de Sprint
Os itens de trabalho individuais são puxados	O trabalho é puxado em lotes no Sprint Planning
Sem funções prescritas	Tem funções prescritas (Scrum Master, Product Owner, Team Member)
O Quadro Kanban pode ser organizado em torno de uma única equipe multifuncional ou várias equipes especializadas	Scrum Board é organizado em torno de uma única equipe multifuncional
As alterações podem ser feitas a qualquer momento -> mais flexível	As alterações são permitidas apenas no Backlog do produto. Mudanças dentro de um sprint não são permitidas
Requer menos treinamento	Requer mais treinamento
Bom para equipes onde apenas melhorias incrementais são necessárias	Bom para equipes onde mudanças fundamentais são necessárias

Resumo: O Fim da Parte 1

Nesta parte, revisamos algumas das metodologias mais populares usadas para Desenvolvimento de Software. Agora você deve ter um bom entendimento de Lean, Agile, Scrum e Kanban e suas raízes históricas na Manufatura Enxuta e TPS. Na próxima parte da série, continuaremos revisando e comparando outras metodologias de desenvolvimento de software, como Cascata , JTBD e Seguro (e outras estruturas de escalonamento), bem como metodologias híbridas, para que você tenha todas elas convenientemente explicadas em um só lugar.

Compreender o básico

O que é Agile?

Agile é uma estrutura abrangente que se aplica a qualquer processo que aplique o conjunto de valores e princípios Agile. Alguns dos exemplos são: Extreme Programming, Scrum e Kanban.

O que é Scrum?

Scrum é um conjunto de princípios e práticas simples, mas incrivelmente poderoso, que ajuda as equipes a entregar produtos em ciclos curtos. Scrum é uma estrutura que aplica os princípios do Agile que foram inventados separadamente por várias pessoas, várias das quais assinaram o Manifesto Agile.

O que é Kanban?

Kanban é um processo mais leve que aplica muitos dos valores Lean e Agile, bem como um subconjunto dos valores e princípios do Scrum, mas também há algumas diferenças fundamentais. Kanban se concentra na visualização, fluxo e limitação do trabalho em andamento.