Menu

Metodologia ágil: um guia para iniciantes no método ágil e Scrum

agile methodology beginner s guide agile method

Experimente Nosso Instrumento Para Eliminar Problemas

Um Guia Completo para a Metodologia Agile: (20+ Tutoriais Detalhados da Metodologia Agile Scrum)

Este é o guia para desenvolvedores e testadores de software entenderem e começarem a trabalhar no famoso Metodologia Agile SCRUM para desenvolvimento e teste de software . Aprenda as terminologias básicas, mas importantes, usadas no processo Agile Scrum, juntamente com um exemplo real do processo completo.

Listamos todos os tutoriais ágeis desta série para sua conveniência. Espero que eles sejam de grande ajuda para você.

Assuntos abordados: O que é Agile, O que é Scrum, Metodologia Ágil em Desenvolvimento e Teste de Software, Testes Ágeis, Processo Agile Scrum, Metodologia Scrum com Scrum Team e Scrum Master.

introdução ao desenvolvimento ágil

O que você aprenderá:

Lista de tutoriais de metodologia ágil

Tutorial # 1: Metodologias Agile Scrum (Este tutorial)
Tutorial # 2: Manifesto Ágil
Tutorial nº 3: Equipe Scrum e suas funções e responsabilidades
Tutorial nº 4: Artefatos Scrum
Tutorial # 5: Eventos Scrum
Tutorial # 6: Triagem de defeitos no Scrum
Tutorial nº 7: Equipes Scrum Autossuficientes
Tutorial # 8: Princípio Três Amigo
Tutorial # 9: SAFe - Estrutura ágil escalonada
Tutorial # 10: Agile Scrum Quiz

MAIS tutoriais de Agile Scrum recomendados:

Tutorial # 11: Principais técnicas de estimativa ágil
Tutorial # 12: Modelo Híbrido Ágil em Cachoeira
Tutorial # 13: Kanban vs Scrum vs Agile
Tutorial # 14: JIRA Agile Tutorial
Tutorial # 15: Reuniões Retrospectivas Ágil
Tutorial # 16: Papel dos analistas de negócios em SCRUM
Tutorial # 17: Papel do QA no Scrum

Ferramentas e perguntas da entrevista:

Tutorial # 18: Ferramentas de teste ágeis
Tutorial # 19: Melhores ferramentas ágeis de gerenciamento de projetos
Tutorial # 20: Principais perguntas da entrevista do Agile
Tutorial # 21: Principais perguntas da entrevista do Scrum

Vamos começar com o primeiro tutorial da série - Introdução ao Agile Scrum.

Introdução ao Desenvolvimento Ágil

Ágil no Desenvolvimento de Software:

Agile é uma das estruturas de desenvolvimento de software mais amplamente utilizadas e reconhecidas do mundo.

A maioria das organizações já o adotou de uma forma ou de outra, mas ainda há um longo caminho a percorrer na maturidade de seus programas de adoção. O único objetivo desta série de tutoriais é integrar profissionais de tecnologia e não-tecnologia no mundo ágil.

Vamos levá-lo pela jornada ágil passo a passo até que você entenda a filosofia por trás do uso do Agile, suas vantagens e como praticá-lo. Esta série tem como objetivo equipar e capacitar os leitores a aplicar o aprendizado Agile e Scrum em seus trabalhos.

Este tutorial específico é dedicado a explicar por que o Agile era necessário e como ele foi criado. O fundamental aqui é fazer você entender o conceito de Adoção Ágil nas Indústrias de Desenvolvimento de Software.

História do Agile

O Agile nasceu quando, em um belo dia, quando 17 pessoas com experiência em diferentes metodologias de desenvolvimento, se reuniram para pensar se havia uma possível solução alternativa para o desenvolvimento de software que pudesse levar a um tempo de desenvolvimento mais rápido e com menos documentação pesada.

Naquela época, o desenvolvimento de software costumava acontecer por tanto tempo que, quando os projetos estavam prontos para serem entregues, o negócio avançou e os requisitos mudaram. Assim, um projeto não foi capaz de atender às necessidades do negócio, mesmo que fosse capaz de cumprir seus objetivos definidos.

Assim, esses campeões de diferentes técnicas de engenharia de software se reuniram e o resultado final de sua reunião foi o que eles chamaram de 'manifesto ágil', que discutiremos em detalhes no próximo tutorial desta série.

Mas o ágil que nasceu naquele dia não é o que vemos hoje nas organizações. A metodologia com a qual esses especialistas concordaram foi descrita como 'leve' e rápida. Mas a principal vitória dessa reunião foi a ideia de que a entrega mais rápida de um produto e o feedback constante eram as chaves para obter sucesso no desenvolvimento de software.

As técnicas em cascata existentes eram muito complicadas e não tinham previsão de feedback até que o produto final estivesse pronto para ser entregue. Isso significava que não havia espaço para correção de curso e o cliente não tinha nenhuma visão sobre o progresso até que todo o produto estivesse pronto. E era isso que esses especialistas queriam evitar.

Eles queriam uma solução que tivesse espaço para feedback constante, a fim de evitar o custo de retrabalho em um estágio posterior.

Desafios Agile

As técnicas em cascata existentes naquela época eram muito complicadas e não tinham provisão para feedback até que o produto final estivesse pronto para ser entregue. Foi chamado de modelo de desenvolvimento em cascata porque as equipes primeiro concluíram uma etapa completamente e somente depois seguiram para a próxima etapa.

Isso significava que não havia espaço para correção de curso e o cliente não tinha nenhuma visão sobre o progresso até que todo o produto estivesse pronto. E era isso que esses especialistas queriam evitar. Eles queriam uma solução que tivesse espaço para feedback constante, a fim de evitar o custo de retrabalho em um estágio posterior.

E é por isso que agile significa também ser adaptável e melhoria contínua, tanto quanto é feedback constante e velocidade de entrega.

O que são as promessas do Agile?

Agile Promises

Agile não se trata apenas de aplicar as práticas definidas no desenvolvimento de software. Isso também traz uma mudança na mentalidade da equipe que os leva a construir um software melhor, trabalhando juntos e, eventualmente, conquistando um cliente feliz.

Os valores e princípios ágeis permitem que a equipe mude seu foco e mude seu processo de pensamento de construção de software melhor.

O que exatamente é Agile?

Agile não é um conjunto de regras. Agile não é um conjunto de diretrizes. Agile não é nem uma metodologia. Em vez disso, o Agile é um conjunto de princípios que encoraja a flexibilidade, adaptabilidade, comunicação e software funcional sobre planos e processos. É captado de forma muito sucinta no que é chamado de manifesto ágil.

O desenvolvimento ágil de software permite que a equipe trabalhe em conjunto com mais eficiência e eficácia no desenvolvimento de projetos complexos. Consiste em práticas que exercitam técnicas iterativas e incrementais, facilmente adotadas e com ótimos resultados.

Para aplicar o Agile em ação, temos vários métodos e metodologias baseados no Agile. Esses métodos e metodologias atendem a todas as necessidades de uma indústria de desenvolvimento de software, desde o design e arquitetura de software, desenvolvimento e teste até gerenciamento de projeto e entregas.

Além disso, os métodos e metodologias ágeis também abrem espaço para a melhoria de processos como parte integrante de cada entrega.

Agile é uma abordagem de desenvolvimento de software em que uma equipe autossuficiente e multifuncional trabalha para fazer entregas contínuas por meio de iterações e evolui ao longo do processo, reunindo feedback dos usuários finais.

Como praticar o Agile?

Existem várias metodologias ágeis que estão em prática em vários setores diversificados.

Metodologias ágeis

No entanto, as metodologias mais populares entre todos eles são:

  • Scrum
  • Kanban
  • Programação extrema

Todas essas metodologias se concentram no desenvolvimento de software enxuto e ajudam na construção de um software melhor de maneira eficaz e eficiente.

Isso é tudo com a introdução do Agile. A parte é estruturada para ajudá-lo a entender os valores e princípios fundamentais que devem ser adotados para que uma equipe trabalhe em um modo e mentalidade Agile.

Ágil Metodologia

Introdução aos modelos ágeis:

Metodologia ágil

como abrir um arquivo .apk

Como todos sabemos, Agile é uma metodologia de desenvolvimento de software.

Também aprendemos sobre os valores e princípios que foram mencionados no manifesto ágil pelos fundadores do agile. Em nossas discussões iniciais, também contornamos as diferenças entre os modelos ágeis e os tradicionais em cascata.

Neste tutorial, conheceremos as vantagens e desvantagens da metodologia ágil.

Vamos ver o que é scrum? e como é diferente de ágil. Então, vamos entender as várias metodologias ágeis que estão sendo usadas por diferentes organizações e como podemos implementar o Agile usando-as.

Você também poderá apreciar a diferença e também as vantagens / desvantagens dessas metodologias.

Vantagens da Metodologia Ágil

Dada a seguir estão as várias vantagens da Metodologia Ágil:

  • Os clientes obtêm continuamente uma visão geral do andamento do projeto ao final de cada iteração / sprint.
  • Cada sprint fornece ao cliente um software funcional que atende às suas expectativas conforme definição de feito por eles fornecida.
  • As equipes de desenvolvimento são bastante receptivas aos requisitos de mudança e podem acomodar as mudanças mesmo nos estágios avançados de desenvolvimento.
  • Há uma comunicação bidirecional constante que mantém os clientes envolvidos, de forma que todas as partes interessadas - comerciais e técnicas - tenham uma visibilidade clara do andamento do projeto.
  • O design do produto é eficiente e atende aos requisitos do negócio.

Desvantagens da Metodologia Ágil

Embora existam várias vantagens da metodologia ágil, existem certas desvantagens envolvidas nela também.

Eles estão:

# 1) Não é preferível uma documentação abrangente, o que pode levar as equipes ágeis a interpretar isso incorretamente, já que o Agile não exige documentação. Portanto, o rigor se perde na documentação. Isso deve ser evitado perguntando-se continuamente se essas informações são suficientes para prosseguir ou não.

#dois) Às vezes, no início dos projetos, os requisitos não são claros. As equipes podem prosseguir e descobrir que a visão dos clientes foi realinhada e, em tais situações, as equipes precisam incorporar muitas mudanças e é difícil avaliar o resultado final também.

Tipos de metodologias ágeis

Existem várias metodologias ágeis em prática em todo o mundo. Vamos aprender mais em detalhes sobre quatro dos mais populares.

Tipos de metodologias ágeis

# 1) Scrum

Scrum pode ser facilmente considerado o framework ágil mais popular. O termo ‘scrum’ é muito considerado sinônimo de ‘ágil’ pela maioria dos praticantes. Mas isso é um equívoco. Scrum é apenas um dos frameworks pelos quais você pode implementar o Agile.

A palavra scrum vem do rugby esportivo. Onde os jogadores se amontoam em uma posição interligada, empurrando contra os oponentes. Cada jogador tem um papel definido em sua posição, podendo atuar tanto ofensivo quanto defensivo conforme a demanda da situação.

Da mesma forma, o scrum em TI acredita em equipes de desenvolvimento autogerenciadas com poderes e três funções específicas e claramente definidas. Essas funções incluem - Product Owner (PO), Scrum Master (SM) e a equipe de desenvolvimento composta por programadores e testadores . Eles trabalham juntos em durações cronometradas iterativas chamadas sprints.

A primeira etapa é a criação do backlog do produto pelo PO. É uma lista de tarefas a serem feitas pela equipe scrum. Em seguida, a equipe scrum seleciona os itens de prioridade mais alta e tenta concluí-los dentro da caixa de tempo chamada sprint.

Uma maneira mais fácil de lembrar de tudo isso é memorizar a estrutura 3-3-5. Isso significa que um projeto scrum possui 3 funções, 3 artefatos e 5 eventos.

Esses são -

Funções: PO, Scrum master e equipe de desenvolvimento.

Artefatos: Backlog do produto, Sprint BacklogeIncremento do produto.

Eventos: Sprint, planejamento do Sprint, Daily Scrum, revisão do Sprint e retrospectiva do Sprint.

Estrutura 3-3-5

Saberemos mais detalhadamente sobre cada um deles em nossos tutoriais subsequentes.

# 2) Kanban

Kanban é um termo japonês que significa um cartão. Esses cartões contêm detalhes do trabalho a ser feito no software. O objetivo é a visualização. Cada membro da equipe está ciente do trabalho a ser feito por meio desses recursos visuais.

As equipes usam esses cartões Kanban para entrega contínua. Assim como o Scrum, o Kanban também ajuda as equipes a trabalhar de maneira eficaz e promove equipes autogerenciadas e colaborativas.

Mas também existem diferenças entre esses dois - como durante um sprint scrum, os itens que estão sendo trabalhados por uma equipe são fixos e não podemos adicionar itens ao sprint, enquanto no Kanban podemos adicionar itens se houver capacidade disponível. Isso é particularmente útil quando os requisitos mudam com frequência.

Da mesma forma, outra diferença é que, embora o scrum tenha funções definidas de PO, scrum master e equipes de desenvolvimento, não existem essas funções predefinidas no Kanban.

Outra diferença é que, embora o scrum sugira uma priorização de backlogs de produtos, Kanban não tem tal requisito e é totalmente opcional. Assim, Kanban requer menos organização e evita atividades que não agregam valor e é adequado para os processos que exigem capacidade de resposta às mudanças.

# 3) Lean

Lean é uma filosofia que foca na redução do desperdício. Como isso faz?

No lean, você divide um processo em atividades que agregam valor, atividades que não agregam valor e atividades essenciais que não agregam valor. Qualquer atividade que possa ser classificada como uma atividade sem valor agregado é um desperdício e devemos tentar remover esse desperdício no processo para torná-lo mais enxuto.

Um processo mais enxuto significa entrega mais rápida e menos esforço desperdiçado em tarefas que não ajudam a atingir os objetivos da equipe. Isso ajuda a otimizar cada etapa do ciclo de desenvolvimento de software. É por isso que os princípios enxutos foram adaptados da manufatura enxuta para o desenvolvimento de software.

O desenvolvimento de software enxuto pode ser usado em qualquer projeto de TI, aplicando os sete princípios enxutos que são mostrados abaixo:

sete princípios enxutos

Eles são bastante autoexplicativos, como seus nomes sugerem. Eliminar o desperdício é o primeiro e mais importante princípio enxuto e vimos como fazer isso, apenas classificamos as atividades como valor e sem valor agregado.

Uma atividade que não agrega valor pode ser qualquer parte do código que pode torná-lo menos robusto, aumentar o esforço envolvido e tomar muito tempo, embora não agregue valor comercial justificável. Também podem ser histórias de usuários vagas, testes insatisfatórios ou adição de recursos que não são necessários no quadro geral.

O segundo princípio, amplificando o aprendizado, é novamente fácil de entender, pois uma equipe precisa de várias habilidades para entregar produtos em um ambiente que muda rapidamente, com novas tecnologias surgindo rapidamente.

Tomar decisões tardias pode ser gratificante em circunstâncias em que reduz o retrabalho, como se houver alguma mudança esperada, então é melhor atrasá-la para que a equipe não tenha que refazer o trabalho conforme as necessidades do negócio mudam.

Mas sempre há uma compensação aqui, pois as equipes precisam equilibrar isso com o quarto princípio de entrega mais rápida. O atraso nas decisões não deve afetar a entrega geral e não deve reduzir o ritmo de trabalho. Um olho deve estar sempre na imagem completa.

Ter equipes capacitadas também é muito comum hoje em dia e isso é algo que até o Agile sugere. Equipes capacitadas são mais responsáveis ​​e podem tomar decisões mais rapidamente. O senso de propriedade em uma equipe capacitada leva a melhores resultados. Para capacitar uma equipe, eles devem ter permissão para se organizar e tomar decisões por conta própria.

Assim, vemos que lean e ágil têm muito em comum com uma diferença marcante - enquanto as equipes lean podem ajudar a refinar um produto, as equipes ágeis são as que realmente constroem o produto.

# 4) Programação Extrema (XP)

A programação extrema é outra técnica ágil mais popular. De acordo com o extremeprogramming.org, o primeiro projeto XP foi iniciado em 6 de março de 1996. Eles também mencionam que o XP impacta o desenvolvimento de projetos de software de 5 maneiras diferentes - comunicação, simplicidade, feedback, respeito e coragem. Esses são chamados de valores do XP.

Destes, tudo começa com a comunicação. As equipes XP colaboram com as equipes de negócios e outros programadores regularmente e começam a construir código desde o primeiro dia. O foco aqui está na comunicação face a face, tanto quanto possível, com a ajuda de outros recursos visuais.

Os programadores extremos também criam um código simples e começam a receber feedback sobre ele desde o primeiro dia. O foco está em não exagerar ou prever requisitos que não foram compartilhados. Isso mantém o design simples e produz apenas o produto mínimo que atenderá aos requisitos.

O feedback ajuda a equipe a melhorar e produzir uma melhor qualidade de trabalho. Isso os ajuda a construir respeito um pelo outro à medida que aprendem uns com os outros e aprendem a compartilhar suas opiniões.

Isso também lhes dá coragem, pois sabem que reuniram as melhores ideias de todos e produziram um bom produto com feedback de outras pessoas. Assim, eles também não têm medo de incluir mudanças ou receber mais feedback sobre seu trabalho.

Isso é particularmente útil em projetos onde os requisitos mudarão com frequência. O feedback constante ajudará as equipes a incluir essas mudanças com coragem.

Assim, vimos as diferentes metodologias ágeis como Scrum, XP, Kanban e Lean juntamente com suas respectivas vantagens e desvantagens.

Agora, podemos facilmente diferenciá-los e também apreciar as diferenças mais sutis entre eles. Também aprendemos os fundamentos de cada uma dessas metodologias e vimos como aplicá-los em nossos projetos quando necessário.

Na próxima parte, vamos entender tudo sobre Scrum.

Metodologia Scrum

SCRUM é um processo em metodologia ágil que é uma combinação do modelo Iterativo e do modelo incremental.

Uma das maiores desvantagens do tradicional Modelo em cascata era isso - até que a primeira fase seja concluída, o aplicativo não passa para a outra fase. E, por acaso, se houver algumas mudanças na fase posterior do ciclo, torna-se muito difícil implementar essas mudanças, pois envolveria revisitar as fases anteriores e refazer as mudanças.

Teste ágil scrum

Algumas das principais características do SCRUM incluem:

  • Equipe auto-organizada e focada.
  • Não há documentos de requisitos enormes, em vez disso, têm histórias muito precisas e diretas.
  • As equipes multifuncionais trabalham juntas como uma única unidade.
  • Feche a comunicação com o representante do usuário para entender os recursos.
  • Tem um cronograma definido de no máximo um mês.
  • Em vez de fazer a “coisa” inteira de uma vez, o Scrum faz um pouco de tudo em um determinado intervalo.
  • A capacidade e a disponibilidade dos recursos são consideradas antes de comprometer qualquer coisa.

Para entender bem essa metodologia, é importante entender as terminologias-chave do SCRUM.

Ler também => Como entregar recursos de software de alto valor em um curto período de tempo usando o processo Agile Scrum

Terminologias importantes de SCRUM

1) Time Scrum

A equipe scrum é composta por 7 pessoas com + ou - dois membros. Esses membros são uma mistura de competências e incluem desenvolvedores, testadores, pessoal de banco de dados, pessoal de suporte, etc. junto com o product owner e um scrum master.

Todos esses membros trabalham juntos em estreita colaboração por um intervalo recursivo e definido, para desenvolver e implementar os referidos recursos. A disposição das cadeiras da equipe SCRUM desempenha um papel muito importante em sua interação, eles nunca se sentam em cubículos ou cabines, mas em uma mesa enorme.

Time Scrum

2) Sprint

Sprint é um intervalo ou período de tempo predefinido no qual o trabalho deve ser concluído e torná-lo pronto para revisão ou para implantação em produção. Essa caixa de tempo geralmente fica entre 2 semanas a 1 mês.

ferramenta de teste automatizada para aplicativos da web

No nosso dia-a-dia, quando dizemos que seguimos o ciclo Sprint de 1 mês, significa simplesmente que trabalhamos durante um mês nas tarefas e as deixamos prontas para revisão no final desse mês.

3) Proprietário do produto

O proprietário do produto é o principal interessado ou o usuário principal do aplicativo a ser desenvolvido. O product owner é a pessoa que representa o lado do cliente. Ele / ela tem a autoridade final e deve estar sempre disponível para a equipe.

Ele / ela deve estar disponível quando alguém tiver dúvidas que precisem de esclarecimento. É importante para o product owner entender e não atribuir nenhum novo requisito no meio do sprint ou quando o sprint já começou.

4) Scrum Master

Scrum Master é o facilitador da equipe scrum. Ele / ela garante que a equipe scrum seja produtiva e progressiva. Havendo impedimentos, o scrum master acompanha e resolve para a equipe. SCRUM Master é o mediador entre o PO e a equipe.

Ele / ela mantém o PO informado sobre o andamento do Sprint. Se houver algum obstáculo ou preocupação para a equipe, converse com o PO e resolva o problema. Como no Daily Standup da equipe, um standup do SCRUM Master com o PO acontece todos os dias.

Leitura recomendada => Como ser um bom mentor, treinador e um verdadeiro defensor de equipe em um mundo de testes ágeis?

5) Analista de Negócios (BA)

Um analista de negócios desempenha um papel muito importante no SCRUM. Essa pessoa é responsável por finalizar e redigir o requisito nos documentos de requisitos (com base nos quais as histórias de usuário são criadas).

Se houver alguma ambiguidade nos critérios de Histórias de Usuário / Aceitação, ele / ela é abordado pela equipe técnica (SCRUM) e ele então leva ao PO ou então se possível resolve por conta própria. Em projetos de grande escala, pode haver mais de 1 BA, mas em projetos de pequena escala, o SCRUM Master pode estar atuando como o BA também.

É sempre uma boa prática ter um BA quando o projeto começa.

6) História do usuário

As histórias de usuário nada mais são do que os requisitos ou recursos que devem ser implementados.

No scrum, não temos esses enormes documentos de requisitos, em vez disso, os requisitos são definidos em um único parágrafo, normalmente tendo o formato como:

Como um
eu quero
Alcançar

Por exemplo :

Como um administrador, eu quero ter um bloqueio de senha no caso de o usuário digitar uma senha incorreta por 3 vezes consecutivas para restringir o acesso não autorizado.

Existem algumas características das histórias de usuários que devem ser respeitadas. As histórias de usuário devem ser curtas, realistas, podem ser estimadas, completas, negociáveis ​​e testáveis. Uma história de usuário nunca é alterada ou modificada no meio da Sprint.

É responsabilidade do SCRUM Master e do BA (se aplicável) certificar-se de que o PO redigiu as Estórias de Usuário corretamente com um conjunto adequado de Critérios de Aceitação ”. Se quaisquer mudanças que afetarão o lançamento do sprint forem feitas, essas histórias são retiradas do sprint ou feitas de acordo com as horas disponíveis.

Cada história de usuário possui um critério de aceitação que deve ser bem definido e compreendido pela equipe.

Os critérios de aceitação detalham a história do usuário que fornece os documentos de suporte. Isso ajuda a refinar ainda mais a história do usuário. Qualquer pessoa da equipe pode escrever os critérios de aceitação. A equipe de teste baseia seus casos / condições de teste nesses critérios de aceitação.

7) Epopéias

Epopéias são histórias de usuários equivocadas ou podemos dizer que são histórias de usuários que não estão definidas e são mantidas para sprints futuros.

Procure relacionar isso com a vida, imagine que você está saindo de férias. Como você vai na próxima semana, você tem tudo pronto, como reservas de hotel, passeios turísticos, cheques de viagem, etc. Mas e quanto ao seu plano de férias para o próximo ano? Você tem apenas uma vaga idéia de que pode ir ao local XYZ, mas não tem um plano detalhado.

Uma Epic é como o plano de férias do próximo ano, onde você sabe que pode querer ir, mas para onde, quando, com quem, todos esses detalhes você não tem ideia neste momento.

De forma semelhante, existem recursos que devem ser implementados no futuro, cujos detalhes ainda não são conhecidos. Geralmente, um recurso começa com uma epopéia e, em seguida, é dividido em histórias que podem ser implementadas.

8) Backlog do produto

O backlog do produto é um tipo de depósito ou fonte onde todas as histórias de usuário são mantidas. Isso é mantido pelo Dono do Produto. O product backlog pode ser imaginado como uma lista de desejos do product owner que o prioriza de acordo com as necessidades do negócio.

Durante a reunião de planejamento (consulte a próxima seção), uma história de usuário é retirada do backlog do produto, então a equipe faz o brainstorming, entende e refina e decide coletivamente quais histórias de usuário tomar, com a intervenção do proprietário do produto.

9) Sprint Backlog

Com base na prioridade, as histórias do usuário são retiradas do Backlog do produto como uma de cada vez. O time Scrum faz um brainstorm sobre ele determina a viabilidade e decide sobre as histórias para trabalhar em um sprint específico. A lista coletiva de todas as histórias de usuário com as quais a equipe scrum trabalha em um determinado sprint é conhecida como Sprint backlog.

Sprint Backlog

10) Pontos de história

Os pontos da história são uma indicação quantitativa da complexidade de uma história do usuário. Com base no ponto da história, a estimativa e os esforços para uma história são determinados.

Um ponto da história é relativo e não absoluto. Para garantir que nossas estimativas e esforços estejam corretos, é importante verificar se as histórias de usuários não são grandes. Quanto mais precisa e menor for a história do usuário, mais precisa será a estimativa.

Cada história de usuário é atribuída a um ponto da história com base na série Fibonacci (1, 2, 3, 5, 8, 13 e 21). Mais alto é o número, o complexo é a história.

Para ser mais preciso

  • Se você der 1/2/3 ponto de história, significa que a história é pequena e de baixa complexidade.
  • Se você der pontos como 5/8, é um complexo médio e
  • 13 e 21 são altamente complexos.

Aqui, a complexidade consiste em desenvolvimento e esforço de teste.

Para decidir um ponto da história, o brainstorming acontece dentro da equipe scrum e a equipe decide coletivamente um ponto da história.

Pode acontecer que a equipe de desenvolvimento dê um ponto de história de 3 para uma história particular, porque para eles podem ser 3 linhas de mudança de código, mas a equipe de teste dá 8 pontos de história porque eles sentem que essa mudança de código afetará módulos maiores, então o esforço de teste seria maior. Seja qual for o ponto da história que você está dando, você tem que justificá-lo.

Portanto, nesta situação, ocorre o brainstorming e a equipe concorda coletivamente com um ponto da história.

Sempre que você estiver decidindo sobre um ponto da história, tenha em mente os fatores abaixo:

  • A dependência da história com outro aplicativo / módulo.
  • O conjunto de habilidades do recurso.
  • A complexidade da história.
  • Aprendizagem histórica.
  • Critérios de aceitação da história do usuário.

Se você não está ciente de uma história em particular, não a dimensione.

Sempre que uma história é = ou> 8 pontos, ela é dividida em 2 ou mais histórias.

11) Gráfico de queima

O gráfico Burn down é um gráfico que mostra o esforço real estimado v / s das tarefas scrum.

É um mecanismo de rastreamento pelo qual, para um determinado sprint, as tarefas do dia a dia são rastreadas para verificar se as histórias estão progredindo em direção à conclusão dos pontos de história comprometidos ou não.

Exemplo : Para entender isso, verifique a figura abaixo:

Gráfico de queima 1

Eu assumi:

  • Sprint de 2 semanas (10 dias)
  • 2 recursos reais trabalhando no sprint.

'História' -> Esta coluna mostra as histórias de usuário obtidas para o sprint.

'Tarefa' -> Esta coluna mostra a lista de tarefas associadas à história do usuário.

'Esforço' -> Esta coluna mostra o esforço. Agora, essa medida é o esforço total para completar a tarefa. Não retrata o esforço despendido por nenhum indivíduo específico.

“Dia 1 - Dia 10” -> Esta (s) coluna (s) mostra as horas que faltam para completar a história. Vejam que a hora NÃO é a hora que já acabou, MAS as horas que faltam.

'Esforço estimado' -> É o total do esforço. Para o “Iniciar” é simplesmente a soma de toda a tarefa individual: SUM (C5: C15)

Um número total de esforço que deve ser concluído em 1 dia é 70/10 = 7. Portanto, no final do dia 1, o esforço deve ser reduzido para 70 - 7 = 63. De forma semelhante, é calculado para todos os dias até o dia 10, quando o esforço estimado deveria ser 0 (linha 16)

“Esforço real restante” -> Como o nome sugere, é o esforço que resta para completar a história. Também pode acontecer que os esforços reais aumentem ou diminuam do que o estimado.

Você pode usar as funções embutidas e o gráfico no Excel para criar este gráfico burndown.

As etapas do Burn Down Chart seriam:

  1. Insira todas as histórias (Coluna A5 - A15).
  2. Insira todas as tarefas (coluna B5 - B15).
  3. Insira os dias (dia 1 - dia 10).
  4. Insira os esforços iniciais (some as tarefas C5 - C15).
  5. Aplique a fórmula para calcular os “Esforços Estimados” para cada dia (Dia 1 ao Dia 10). Insira a fórmula em D15 (C16- $ C $ 16/10) e arraste-a por todos os dias.
  6. Para cada dia, insira os esforços reais. Insira a fórmula em D17 (SUM (D5: D15)) para somar os esforços reais restantes e arraste-o para todos os outros dias.
  7. Selecione-o e crie o gráfico da seguinte maneira:

Burn Down Chart 2

12) Velocidade

O número total de pontos da história que uma equipe scrum arquiva em uma sprint é chamado de Velocidade. A equipe Scrum é julgada ou referenciada por sua velocidade. Dito isso, deve-se ter em mente que o objetivo aqui NÃO é atingir o máximo de pontos de história, mas ter uma entrega de qualidade, respeitando o nível de conforto da equipe scrum.

Por exemplo : Para um sprint específico: o número total de histórias de usuário é 8, tendo pontos de história conforme mostrado abaixo.

Velocidade do Scrum

Então, aqui a velocidade será a soma dos pontos da história = 30

Definição de Feito:

Um Sprint é marcado como Concluído quando todas as histórias são concluídas, todas as tarefas de desenvolvimento, pesquisa e controle de qualidade são marcadas como 'Concluídas', todos os bugs são corrigidos e fechados, caso contrário os que podem ser feitos posteriormente (como não completamente relacionados ou menos importantes) são retirados e adicionados ao backlog, a revisão do código e o teste de unidade são concluídos, as horas estimadas atendem às horas reais investidas nas tarefas e, o mais importante, uma demonstração bem-sucedida foi fornecida ao PO e às partes interessadas.

Atividades realizadas na metodologia SCRUM

# 1) Reunião de planejamento

Uma reunião de planejamento é o ponto de partida do Sprint. É a reunião onde toda a equipe scrum se reúne, o SCRUM Master seleciona uma história de usuário com base na prioridade do backlog do produto e a equipe faz um brainstorm sobre ela.

Com base na discussão, a equipe scrum decide a complexidade da história e a dimensiona de acordo com a série de Fibonacci. A equipe identifica as tarefas junto com os esforços (em horas) que seriam realizados para concluir a implementação da história do usuário.

Muitas vezes, a reunião de planejamento é precedida por uma “reunião de pré-planejamento”. É como o dever de casa que a equipe scrum faz antes de se sentar para a reunião de planejamento formal. A equipe tenta anotar as dependências ou outros fatores que gostariam de discutir na reunião de planejamento.

# 2) Execução de Tarefas Sprint

Como o nome sugere, esse é o trabalho real realizado pela equipe scrum para realizar sua tarefa e levar a história do usuário ao estado “Concluído”.

# 3) Levantamento diário

Durante o ciclo de sprint, todos os dias a equipe scrum se reúne por, no máximo, 15 minutos (pode ser uma chamada em pé, recomendado para ter durante o início do dia) e declara 3 pontos:

  1. O que o membro da equipe fez ontem?
  2. O que o membro da equipe planejou fazer hoje?
  3. Quaisquer impedimentos (bloqueios de estradas)?

É o Scrum master quem facilita esta reunião. Caso algum membro da equipe esteja enfrentando algum tipo de dificuldade, o scrum master faz o acompanhamento para resolver o problema. No Stand ups, o quadro também é revisado e por si só mostra o andamento da equipe.

# 4) Reunião de revisão

No final de cada ciclo de sprint, a equipe SCRUM se reúne novamente e demonstra as histórias de usuário implementadas para o product owner. O product owner pode cruzar a verificação das histórias de acordo com seus critérios de aceitação. É novamente responsabilidade do Scrum master presidir esta reunião.

Ainda na ferramenta SCRUM, o Sprint é fechado e as tarefas marcadas como concluídas.

# 5) Reunião Retrospectiva

A reunião de retrospectiva acontece após a reunião de revisão.

A equipe SCRUM se reúne, discute e documenta os seguintes pontos:

  • O que correu bem durante o Sprint (melhores práticas)?
  • O que não deu certo na Sprint?
  • Lições aprendidas
  • Itens de ação.

A equipe Scrum deve continuar a seguir as melhores práticas, ignorar as “práticas não recomendadas” e implementar as lições aprendidas durante os sprints subsequentes. A reunião retrospectiva ajuda a implementar a melhoria contínua do processo SCRUM.

Como o processo é feito? Um exemplo!

Tendo lido sobre os jargões técnicos de SCRUM. deixe-me tentar demonstrar todo o processo com um exemplo.

Exemplo:

Passo 1 : Vamos ter uma equipe SCRUM de 9 pessoas composta por 1 product owner, 1 Scrum master, 2 testadores, 4 desenvolvedores e 1 DBA.

Passo 2 : O Sprint segue um ciclo de 4 semanas. Portanto, temos Sprint de 1 mês começando de 5 de junho a 4ºde julho.

Etapa 3 : O Product Owner tem a lista priorizada de histórias de usuário no backlog do produto.

Passo 4: A equipe decide se reunir no dia 4ºJunho para a reunião de “Pré-planejamento”.

  • O product owner pega uma história do product backlog, descreve e deixa para a equipe fazer um brainstorming sobre ela.
  • Toda a equipe discute e se comunica diretamente com o proprietário do produto para compreender claramente a história do usuário.
  • De forma semelhante, várias outras histórias de usuário são obtidas. Se possível, a equipe pode prosseguir e dimensionar as histórias também.

Depois de toda a discussão, os membros individuais da equipe voltam para suas estações de trabalho e

  • Identifique suas tarefas individuais para cada história.
  • Calcule o número exato de horas em que trabalharão. Vamos verificar como o membro encerra essas horas.

Número total de horas de trabalho = 9
Menos 1 hora para uma pausa, menos 1 hora para reuniões, menos 1 hora para e-mails, discussões, solução de problemas etc.
Portanto, as horas de trabalho reais = 6.
Número total de dias úteis durante o Sprint = 21 dias.
Número total de horas disponíveis = 21 * 6 = 126.
O membro está de licença por 2 dias = 12 horas (isso varia para cada membro, alguns podem tirar licença e outros não).
Número de horas reais = 126 - 12 = 114 horas.

Isso significa que o membro estará realmente disponível por 114 horas para este sprint. Assim, ele dividirá sua tarefa de sprint individual de forma que um total de 114 horas seja alcançado.

Etapa 5 : No 5ºde junho todo o time Scrum se reúne para a “Reunião de Planejamento”.

  • O veredicto final da história do usuário do backlog do produto é feito e a história é movida para o Sprint Backlog.
  • Para cada história, cada membro da equipe declara suas tarefas identificadas, se necessário eles podem discutir essas tarefas, dimensionar ou redimensionar (lembre-se da série Fibonacci !!).
  • O Scrum master ou a equipe insere suas tarefas individuais junto com suas horas para cada história em uma ferramenta.
  • Depois que todas as histórias forem concluídas, o Scrum master anota a velocidade inicial e inicia formalmente a Sprint.

Etapa # 6 : Uma vez que o Sprint foi iniciado, com base nas tarefas atribuídas, cada membro da equipe começa a trabalhar nessas tarefas.

Etapa # 7 : A equipe se reúne diariamente por 15 minutos e discute 3 coisas:

  • O que eles fizeram ontem?
  • O que eles planejam fazer hoje?
  • Quaisquer impedimentos (bloqueios de estradas)?

Etapa # 8 : O scrum master acompanha o progresso diariamente com a ajuda de “Burn down chart”.

Etapa # 9 : Havendo impedimentos, o Scrum master acompanha para resolvê-los.

Etapa # 10 : Em 4ºJulho, a equipe se reúne novamente para a reunião de revisão. Um membro demonstra a história do usuário implementada ao proprietário do produto.

Etapa # 11 : Em 5ºJulho, a Equipe se reúne novamente para a Retrospectiva, onde discutem

  • O que foi bem?
  • O que não correu bem?
  • Itens de ação.

Etapa # 12 : Em 6ºEm julho, a equipe se reúne novamente para uma reunião de pré-planejamento para o próximo sprint e o ciclo continua.

processo de metodologia ágil scrum

Ferramentas de atividade SCRUM

Existem várias ferramentas que podem ser amplamente utilizadas para rastrear atividades de scrum.

Alguns deles incluem:

No próximo tutorial, estaríamos lançando luz sobre o Manifesto Agile, que é uma noção que impulsiona equipes Agile eficazes.

Próximo tutorial

Sobre os autores: Esta série foi escrita pelos seguintes membros da equipe STH: Shruti Shrivastava - Um Scrum Master Profissional com 9 anos de experiência em domínios BFSI, E-commerce e B2B. Shruti é especialista em testes de automação e liderança de equipes scrum.

Anshul Kumar Srivastava - Profissional de gerenciamento de produtos orientado para resultados e praticante do Agile, com 7 anos de experiência nos setores de BFSI e telecomunicações.

Leitura recomendada

^