Terminologias e definições ágeis

Teste de aceitação

Testes formais conduzidos para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir que o cliente determine se aceita ou não o sistema.

Metodologia Ágil de Desenvolvimento de Software


O desenvolvimento ágil de software dá grande ênfase à colaboração, capacidade de resposta às mudanças e redução do desperdício ao longo do ciclo de desenvolvimento. O desenvolvimento ágil de software se concentra em manter o código simples, testando com frequência e entregando bits funcionais do aplicativo assim que estiverem prontos.

Um princípio ágil importante é entregar software (potencialmente) liberável após cada iteração.


Backlog Grooming

A preparação do backlog é o processo de adicionar novas histórias de usuário ao backlog, priorizando novamente as histórias existentes conforme necessário, criando estimativas e desconstruindo histórias maiores em histórias ou tarefas menores. Em vez de limpar o backlog esporadicamente ao longo de uma iteração, a equipe pode realizar uma sessão de limpeza do backlog uma vez por iteração.

Quebrando a construção

Quando um desenvolvedor adiciona alterações ao repositório de código-fonte que resultam na falha de um processo de compilação subsequente, o desenvolvedor “quebrou a compilação”.


Deve ser um compromisso da equipe para evitar quebrar a compilação, pois isso tornará o desenvolvimento lento e pode ser um gargalo para outros desenvolvedores. Quando o build é interrompido, a equipe de desenvolvimento deve tomar medidas imediatas para consertar o build.

A compilação é interrompida se o processo de compilação não pode ser concluído com êxito por vários motivos, incluindo (mas não se limitando a) falha na compilação, compilação com avisos inaceitáveis ​​ou falha de qualquer número de testes automatizados.

Processo de construção / pipeline de construção

O processo de construção ou pipeline de construção, é o processo no qual uma história vai do início à produção, geralmente passando por diferentes estágios e verificações para garantir a qualidade.


O pipeline de construção define o fluxo de trabalho para entrega de software e o que acontece em cada estágio.

Burndown Chart

Um gráfico que exibe o total de horas de tarefas restantes por dia. Mostra a posição da equipe em relação à conclusão das tarefas que foram comprometidas com o sprint. O eixo X representa os dias no sprint, enquanto o eixo Y representa o esforço restante.

Frango


No scrum, frango é uma gíria usada para designar alguém que está interessado em um projeto, mas não tem responsabilidade por trabalhar em uma tarefa na iteração ativa. Eles podem observar as reuniões da equipe, mas não podem votar ou falar.

Integração contínua

Integração contínua (CI) é uma prática de Programação eXtreme (XP) onde os membros de uma equipe de entrega frequentemente integram seu trabalho (por exemplo, de hora em hora, ou pelo menos uma vez por dia).

Cada integração é verificada por uma construção automatizada, que também realiza testes, para detectar quaisquer erros de integração de forma rápida e automática. O principal objetivo da CI é evitar o que é comumente chamado de integração ou inferno de fusão.


Equipe multifuncional

Equipe composta por membros com todas as habilidades funcionais e especialidades (muitas vezes chamadas de multi-qualificadas) necessárias para concluir um projeto do início ao fim.

Cliente

O cliente normalmente é definido como o destinatário ou usuário do produto. Os clientes podem ser internos ou externos à organização. O cliente pode ser uma pessoa, um departamento ou um grande grupo.

Os clientes internos às vezes são chamados de 'Negócios'.

Levantamento Diário

Uma reunião diária da equipe geralmente acontecia no início da manhã para fornecer uma atualização de status aos membros da equipe. As reuniões geralmente têm um tempo limitado de 5 a 15 minutos e são realizadas em pé para lembrar as pessoas de que devem ser curtas e diretas.

Definição de Feito (DoD)

Os critérios para aceitar o trabalho como concluído. A especificação desses critérios é responsabilidade de toda a equipe, incluindo o negócio. Geralmente, existem três níveis de 'Pronto' (também conhecido como Pronto-Pronto-Pronto):

  • Feito: desenvolvido, é executado na caixa do desenvolvedor
  • Concluído: verificado pela execução de testes de unidade, revisão de código, etc.
  • Feito: validado como sendo de qualidade de entrega com testes funcionais, análises, etc.

Os critérios exatos para o que constitui “Concluído” variam para atender às necessidades específicas de diferentes organizações e iniciativas.

Épico

Uma história de usuário muito grande que eventualmente é dividida em histórias menores. As epopeias costumam ser usadas como espaços reservados para novas ideias e histórias relacionadas a serem desenvolvidas em sprints subsequentes.

Histórias épicas ajudam as equipes de desenvolvimento Agile a gerenciar e preparar com eficácia o backlog de seus produtos.

Estimativa

O processo de concordar com uma medida de tamanho para as histórias ou tarefas em uma carteira de produtos. Em projetos ágeis, a estimativa é feita pela equipe responsável pela entrega da obra, geralmente por meio de um jogo de planejamento ou planejamento de pôquer.

Programação extrema

Uma metodologia ágil de desenvolvimento de software que visa melhorar a qualidade do software e a capacidade de resposta às mudanças nos requisitos do cliente.

O XP defende “lançamentos” frequentes em ciclos de desenvolvimento curtos, com o objetivo de melhorar a produtividade e introduzir pontos de verificação nos quais novos requisitos do cliente podem ser adotados.

Outros elementos de programação extrema incluem: programação em pares, revisões de código extensas, testes de unidade, integração contínua, para citar alguns.

Característica

Uma função comercial coerente ou atributo de um produto ou sistema de software. Os recursos normalmente incluem muitos requisitos detalhados (da unidade). Normalmente, um único recurso é implementado por meio de muitas histórias.

Os recursos podem ser funcionais ou não funcionais; eles fornecem a base para a organização de histórias.

Sequência de Fibonacci

Uma sequência de números em que o próximo número é derivado pela adição dos dois anteriores (por exemplo, 1, 2, 3, 5, 8, 13, 21, 34 ...). A sequência é usada para dimensionar histórias em técnicas de estimativa Agile, como o planning poker.

Impedimento

Qualquer coisa que impeça um membro da equipe de realizar o trabalho com a maior eficiência possível é um impedimento. Cada membro da equipe tem a oportunidade de anunciar impedimentos durante a reunião diária em pé.

O trabalho do ScrumMaster é garantir que os impedimentos sejam removidos o mais rápido possível para que a equipe possa continuar a ser produtiva.

Iteração

Um período (de 1 semana a 2 meses de duração) durante o qual a equipe de desenvolvimento Agile produz um incremento de software concluído. Todo o sistema fases do ciclo de vida (requisitos, design, código e teste) devem ser concluídos durante a iteração e depois demonstrados para que a iteração seja aceita como concluída com êxito.

No início da iteração, o negócio ou o proprietário do produto identifica a próxima parte (prioridade mais alta) de trabalho a ser concluída pela equipe. A equipe de desenvolvimento então estima o nível de esforço e se compromete a concluir um segmento de trabalho durante a iteração.

Kanban

Kanban é uma ferramenta derivada da manufatura enxuta e está associada ao ramo de práticas ágeis vagamente conhecido como Desenvolvimento de Software Enxuto. Kanban restringe quanto trabalho em andamento pode ocorrer ao mesmo tempo.

A principal diferença entre Kanban e Scrum é que o Scrum limita o trabalho em andamento por meio de sprints e o Kanban limita o trabalho em andamento, limitando a quantidade de trabalho que pode ocorrer de uma vez (por exemplo, N tarefas ou N histórias).

Desenvolvimento Lean de Software

O desenvolvimento de software Lean ou apenas Lean tem como foco a redução do desperdício e a otimização do fluxo de valor da produção de software.

Produto mínimo viável (MVP)

O menor produto funcional que pode ser construído, testado e entregue em um determinado momento que agrega valor aos usuários.

Programação em par

Uma técnica ágil de desenvolvimento de software em que dois programadores trabalham juntos em uma estação de trabalho. Um digita o código enquanto o outro revisa cada linha de código à medida que é digitada. A pessoa que está digitando é chamada de driver. e a pessoa que está revisando o código é chamada de observador ou navegador. Os dois programadores trocam de função com frequência.

Porco

Alguém que é responsável por realizar uma tarefa em uma iteração ativa. É o oposto do frango. Os porcos estão ativamente envolvidos no projeto.

Planning Poker

O Planning Poker é uma técnica de estimativa baseada em consenso, usada principalmente para estimar o esforço ou o tamanho relativo das tarefas no desenvolvimento de software. A equipe usa a série Fibonacci ou o dimensionamento de camisetas para estimar histórias durante o jogo de planejamento de pôquer.

produtos

Em termos gerais, produto se refere a um conjunto de recursos integrados e empacotados em versões de software que oferecem valor a um cliente ou mercado.

Proprietário do produto

O Product Owner é uma das principais funções no Scrum. As responsabilidades do Dono do Produto incluem:

  • Estabelecer, nutrir e comunicar a visão do produto
  • Criar e liderar uma equipe de desenvolvedores para melhor fornecer valor ao cliente
  • Monitorar o projeto em relação aos seus objetivos de ROI e uma visão de investimento
  • Tomar decisões sobre quando criar um lançamento oficial

Backlog do produto

O backlog do produto é como uma lista de desejos de recursos que as empresas desejam oferecer a longo prazo. É uma coleção de histórias e tarefas nas quais a equipe trabalhará em algum momento no futuro.

O Product Owner mantém essa lista de pendências do produto de acordo com as prioridades e necessidades do negócio. Os itens da carteira de pedidos devem refletir o roteiro de negócios.

Reestruturação

Alterar o código de software existente para melhorar o design geral. A refatoração normalmente não altera o comportamento observável do software; melhora sua estrutura interna.

Plano de Liberação

O plano de lançamento é um cronograma para lançar o software em produção. Os planos de lançamento típicos incluem os principais recursos a serem entregues, junto com as datas de lançamento correspondentes.

Retrospectivo

Uma reunião limitada no tempo realizada no final do sprint em que a equipe examina seus processos para determinar o que foi bem-sucedido e o que poderia ser melhorado. A retrospectiva é a chave para a melhoria contínua.

Um resultado positivo para uma retrospectiva é identificar um ou dois itens de ação de alta prioridade nos quais a equipe deseja trabalhar na próxima iteração ou release.

Scrum

Scrum é uma estrutura para o desenvolvimento de produtos de software complexos de forma iterativa e incremental e é a estrutura Ágil mais amplamente reconhecida.

Scrum é composto de uma série de iterações curtas - chamadas de sprints - cada uma das quais termina com a entrega de um incremento de software funcional.

Time Scrum

A equipe scrum é um grupo multifuncional e auto-organizado responsável por entregar o software.

A equipe scrum inclui pessoas multi-qualificadas que entendem os requisitos do cliente e conduzem o projeto, codificação e teste do software. Habilidades adicionais (por exemplo, design de interface do usuário, usabilidade, etc.) também podem ser incluídas.

A equipe scrum é responsável por todos os compromissos e resultados de trabalho.

Scrum Master

O ScrumMaster é responsável por manter o processo Scrum e a saúde geral da equipe. O ScrumMaster garante que a equipe esteja totalmente funcional e produtiva, removendo quaisquer obstáculos que possam estar impedindo o progresso da equipe. O ScrumMaster também organiza as cerimônias Scrum.

Espinho

Uma história ou tarefa destinada a responder a uma pergunta ou reunir informações, em vez de implementar recursos do produto, histórias de usuário ou requisitos.

Às vezes, é gerada uma história de usuário que não pode ser estimada até que a equipe de desenvolvimento faça algum trabalho real para resolver uma questão técnica ou um problema de design. A solução é criar um “pico”, que é uma história cujo objetivo é fornecer a resposta ou solução.

arrancada

No desenvolvimento de produtos, um sprint é um período de tempo durante o qual um trabalho específico deve ser concluído e preparado para revisão. A duração típica de um sprint é geralmente de 2 semanas e normalmente não mais do que 4 semanas.

Sprint Backlog

Uma lista de recursos, histórias de usuário ou tarefas extraídas do backlog do produto para consideração para conclusão durante o próximo sprint. Os recursos do backlog do produto e as histórias do usuário são divididos em tarefas para formar o backlog do sprint durante a reunião de planejamento do sprint.

Preparação de histórias

Nas sessões de preparação de histórias, os detalhes das histórias de usuários são detalhados. Os critérios de aceitação são escritos e elaborados. As histórias também são estimadas nesta fase.

O objetivo desta sessão é garantir que todos os envolvidos no desenvolvimento e teste das histórias compartilhem um entendimento comum do contexto das histórias antes de iniciar o desenvolvimento das histórias.

As sessões de preparação de histórias geralmente são realizadas no meio do sprint seguinte, para que a equipe esteja ciente da carga de trabalho do próximo sprint.

Os participantes são a equipe scrum, o scrum master e o product owner.

Planejamento de Sprint

As sessões de planejamento de sprint são realizadas pouco antes do início de um novo sprint. Nesta sessão, a equipe identifica as tarefas que precisam ser feitas e decide quantos pontos da história eles podem se comprometer para o próximo sprint.

Antes das sessões de planejamento de sprint, as histórias devem ser elaboradas e estimadas durante as sessões de preparação de histórias, de forma que nenhum tempo seja perdido durante o planejamento de sprint.

Os participantes são scrum master e a equipe scrum.

História do usuário

Uma história de usuário (também conhecida como história) pode ser considerada um requisito, recurso que tem algum valor comercial.

As histórias descrevem o trabalho que deve ser concluído para entregar um recurso para um produto. As histórias são a unidade básica de comunicação, planejamento e negociação entre a Equipe Scrum, Proprietários de Negócios e o Dono do Produto.

As histórias consistem nos seguintes elementos:

  • Uma descrição, geralmente em termos de negócios
  • Um tamanho, para fins de estimativa aproximada, geralmente expresso em pontos da história (como 1, 2, 3, 5)
  • Um ou mais critérios de aceitação, dando uma breve descrição de como a história será validada

Tarefa

Tarefas são descrições do trabalho real que um indivíduo ou dupla faz para completar uma história. Eles são unidades de trabalho gerenciáveis, realizáveis ​​e rastreáveis. Normalmente, existem várias tarefas por história.

Dívida Técnica

Um termo cunhado por Ward Cunningham para descrever a obrigação que uma organização de software incorre quando escolhe uma abordagem de projeto ou construção que é conveniente no curto prazo, mas que aumenta a complexidade e é mais cara no longo prazo.

Tamanhos para camisetas

Um método de estimar o trabalho necessário para completar uma história em tamanhos de camiseta, ou seja, pequeno (S), médio (M), grande (L) ou extragrande (XL)

Timebox

Uma caixa de tempo é um período de tempo de duração fixa alocado para atingir algum objetivo. No desenvolvimento ágil, iterações e sprints são exemplos de timeboxes que limitam o trabalho em processo e o progresso incremental do estágio.

Velocidade

A velocidade mede quanto trabalho uma equipe pode concluir em uma iteração. A velocidade geralmente é medida em histórias ou pontos de história. A velocidade também pode medir tarefas em horas ou uma unidade equivalente.

A velocidade é usada para medir quanto tempo levará para uma equipe específica entregar resultados futuros, extrapolando com base em seu desempenho anterior.

Trabalho em progresso

Qualquer trabalho que não tenha sido concluído, mas que já tenha incorrido em um custo de capital para a organização. Qualquer software desenvolvido, mas não implantado na produção, pode ser considerado um trabalho em andamento.