A necessidade de equipes ágeis é uma realidade nas empresas e quando falamos em mudar a cultura de uma empresa para aumentar o engajamento dos colaboradores, é praticamente certo, independente do ramo da sua empresa, que você tenha pelo menos um time desenvolvendo soluções internas, produtos ou serviços na área de software.
Equipes ágeis somente são possíveis quando começamos a entender que o tipo de gestão que estamos utilizando não é mais eficaz no mundo em que vivemos. Muitas equipes ágeis acabam utilizando vários métodos, metodologias e framework ágeis muito rapidamente, muitas vezes sem entendimento adequado.
É normal quando trabalhamos com gestão ágil e desenvolvimento ágil de software começarmos a experimentar várias práticas, métodos e frameworks, e nos depararmos com muitos termos específicos, assim não é difícil que isso cause alguma dúvida ou confusão até mesmo entre agilistas experientes.
O objetivo desse glossário e terminologia ágil é ser um local de consulta simples para esclarecer dúvidas sobre os termos mais comuns que encontramos no mundo Ágil.
Um movimento para encontrar melhores formas de desenvolver software. Scrum e Extreme Programming são dois exemplos importantes. Outros, como Kanban ou Lean Startup não se definem tradicionalmente como Ágil, mas são baseados em valores e princípios compatíveis.
Agilidade de negócios é a capacidade de uma organização de perceber mudanças interna ou externamente e responder de forma adequada para entregar valor aos clientes.
Antipadrões são soluções comuns para problemas comuns onde a solução é ineficaz e pode resultar em consequências indesejáveis.
Prática de desenvolvimento de software orientada primeiramente a testes, na qual os critérios de aceitação para novas funcionalidades são criados como testes automatizados. Os testes de falha são construídos para passar conforme o desenvolvimento prossegue e os critérios de aceitação são atendidos.
O princípio de gestão de que as equipes organizam seu trabalho de forma autônoma. A auto-organização acontece dentro de limites e contra objetivos determinados. As equipes escolhem a melhor forma de realizar seu trabalho, em vez de serem dirigidas por outras pessoas fora da equipe.
Um backlog é uma lista ordenada de itens que representam tudo o que pode ser necessário para entregar um resultado específico. Existem diferentes tipos de pendências, dependendo do tipo de item que contêm e da abordagem que está sendo usada.
Uma lista ordenada do trabalho a ser feito para criar, manter e sustentar um produto. É gerenciado pelo Product Owner.
A preparação do backlog é quando o product owner e a equipe refinam o backlog regularmente para garantir que o backlog contenha os itens apropriados, que eles sejam priorizados e que os itens no topo do backlog estejam prontos para entrega.
BDD é uma prática em que os membros da equipe discutem o comportamento esperado de um sistema para construir uma compreensão compartilhada da funcionalidade esperada.
Um gráfico que mostra a quantidade de trabalho que permanece no backlog para ser feita. O tempo é mostrado no eixo horizontal e o trabalho restante no eixo vertical. Conforme o tempo avança e os itens são retirados do backlog e concluídos, pode-se esperar que uma linha de base mostrando o trabalho restante caia.
A quantidade de trabalho pode ser avaliada de várias maneiras, como pontos da história do usuário ou horas de tarefa. O trabalho remanescente em Sprint Backlogs e Product Backlogs pode ser comunicado por meio de um gráfico burn-down.
Um gráfico que mostra a quantidade de trabalho que foi concluído. O tempo é mostrado no eixo horizontal e o trabalho concluído no eixo vertical. À medida que o tempo avança e os itens são retirados da lista de pendências e concluídos, pode esperar que uma linha de base mostrando o trabalho realizado cresça.
A quantidade de trabalho pode ser avaliada de várias maneiras, como pontos da história do usuário ou horas de tarefa. A quantidade de trabalho considerada dentro do escopo também pode ser plotada como uma linha; pode-se esperar que o burn-up se aproxime dessa linha quando o trabalho for concluído.
São critérios pelos quais um item de trabalho (história de usuário) pode ser julgado como tendo sido implementado e testado com sucesso. Uma história está “pronta” quando todos os critérios passam no teste; por outro lado, uma história não está “pronta” se algum critério falhar no teste. Os Critérios de Aceitação são recursos testáveis discretos relacionados às condições de satisfação que quando atendidas, agregam valor ao negócio.
Evento diário com limite de tempo de 15 minutos, ou menos, para que a Equipe de Desenvolvimento planeje o próximo dia de trabalho de desenvolvimento durante uma Sprint. As atualizações são refletidas no Sprint Backlog.
O desenvolvimento ágil é uma estrutura conceitual e abordagem para o desenvolvimento de software com base nos princípios do Manifesto Ágil. O termo é um “guarda-chuva” para uma série de metodologias específicas baseadas em técnicas de desenvolvimento iterativo, onde os requisitos e os produtos evoluem por meio da colaboração entre equipes multifuncionais e auto-organizadas. As metodologias ágeis mais populares incluem: Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development (DSDM), Lean Development e Feature Driven Development (FDD).
Em um contexto Ágil, o Desenvolvimento Incremental ocorre quando cada versão sucessiva de um produto pode ser usada e cada uma se baseia na versão anterior, adicionando funcionalidade visível ao usuário.
O desenvolvimento do cliente é uma estrutura de quatro etapas que fornece uma maneira de usar uma abordagem científica para validar suposições sobre seu produto e negócio.
Os projetos ágeis são iterativos na medida em que permitem intencionalmente “repetir” as atividades de desenvolvimento de software e, potencialmente, “revisitar” os mesmos produtos de trabalho (a refatoração é um bom exemplo).
A estimativa relativa consiste em estimar tarefas ou histórias de usuários por comparação ou agrupamento de itens de dificuldade equivalente.
Equipes ágeis compostas por membros com todas as habilidades funcionais e especialidades necessárias para concluir um projeto do início ao fim.
Épicos são histórias de usuário que representam itens grandes demais ou sem detalhes suficientes para serem desenvolvidos. Pode ser quebrado em histórias menores.
No desenvolvimento de software, uma “estimativa” é a avaliação do esforço necessário para realizar uma determinada tarefa de desenvolvimento; isso é geralmente expresso em termos de duração.
Extreme Programming (XP) é uma estrutura ágil de desenvolvimento de software que visa produzir software de alta qualidade e maior qualidade de vida para a equipe de desenvolvimento. XP é a mais específica das estruturas ágeis em relação às práticas de engenharia apropriadas para o desenvolvimento de software.
Um facilitador é uma pessoa que escolhe ou recebe a função explícita de conduzir uma reunião sem influenciar diretamente no resultado da mesma.
A definição de Scrum, escrita e fornecida por Ken Schwaber e Jeff Sutherland, co-criadores do Scrum. Esta definição consiste nas funções, eventos, artefatos do Scrum e as regras que os unem.
Integração contínua é a prática de mesclar alterações de código em um repositório compartilhado várias vezes ao dia para liberar uma versão do produto a qualquer momento. Isso requer um procedimento de integração reproduzível e automatizado.
Um software funcional que se soma aos incrementos criados anteriormente, onde a soma de todos os ncrementos – como um todo – forma um produto.
A implantação contínua visa reduzir o tempo decorrido entre a gravação de uma linha de código e a disponibilização desse código aos usuários em produção. Para alcançar a implantação contínua, a equipe conta com uma infraestrutura que automatiza e instrumenta as várias etapas que levam à implantação, de modo que, após cada integração que atenda com sucesso a esses critérios de lançamento, o aplicativo ativo seja atualizado com o novo código.
Um conceito ágil em que as equipes avaliam um projeto olhando para o produto, ouvindo o feedback uns dos outros e, por fim, melhorando o processo ou mudando o curso.
“Integração” refere-se a quaisquer esforços ainda necessários para uma equipe de projeto entregar um produto adequado para lançamento como um todo funcional.
A sigla INVEST significa um conjunto de critérios usados para avaliar a qualidade de uma história de usuário. Se a história não atender a um desses critérios, a equipe pode querer reformulá-la.
Uma iteração é uma caixa de tempo durante a qual o desenvolvimento ocorre. A duração pode variar de projeto para projeto e geralmente é fixa.
O Método Kanban é um meio de projetar, gerenciar e melhorar o fluxo para o trabalho do conhecimento e permite que as equipes ágeis comecem de onde estão para impulsionar a mudança evolutiva.
Lead Time é o tempo entre o pedido do cliente e a entrega. No desenvolvimento de software, também pode ser o tempo entre o momento do requisito solicitado até o seu cumprimento.
Um Manifesto para Desenvolvimento Ágil de Software é um documento histórico escrito em fevereiro de 2001 em um resort de esqui em Utah. A reunião foi realizada para discutir diferentes abordagens para o desenvolvimento de software leve, responsivo e adaptável. O Manifesto representa seu melhor pensamento combinado. É composto por duas partes: quatro declarações de valores e doze princípios. Aqui estão as quatro declarações de valor do Manifesto:
“Estamos descobrindo melhores maneiras de desenvolver software fazendo isso e ajudando outros a fazê-lo. Por meio desse trabalho, valorizamos:
Modelagem Ágil é uma metodologia baseada em prática para modelagem e documentação de sistemas baseados em software. Pretende ser uma coleção de valores, princípios e práticas para modelagem de software que podem ser aplicados em um projeto de desenvolvimento de software de uma maneira mais flexível do que os métodos tradicionais de modelagem.
Um Produto Mínimo Viável é a “versão de um novo produto que permite a uma equipe coletar o máximo de aprendizado validado sobre os clientes com o mínimo esforço”.
Mob Programming é uma abordagem de desenvolvimento de software em que toda a equipe trabalha na mesma coisa, ao mesmo tempo, no mesmo espaço e no mesmo computador.
A programação em par consiste em dois programadores que compartilham uma única estação de trabalho (uma tela, teclado e mouse entre o par).
As quatro etapas de um ciclo de melhoria contínua popularizado por W. Edward Deming.
Personas são biografias sintéticas de usuários fictícios do futuro produto.
Uma abordagem de estimativa usada por equipes ágeis. Cada membro da equipe “joga” uma carta com um valor numérico correspondente a uma estimativa de pontos para uma história de usuário.
As equipes ágeis geralmente preferem expressar estimativas em unidades diferentes das consagradas “horas-homem”. Possivelmente, a unidade mais difundida é “pontos da história”.
Papel no Scrum responsável por maximizar o valor de um produto, principalmente gerenciando e expressando incrementalmente as expectativas funcionais e de negócios de um produto para as equipes de desenvolvimento.
Um Quadro Kanban é uma ferramenta de fluxo de trabalho visual que consiste em várias colunas. Cada coluna representa um estágio diferente no processo de fluxo de trabalho.
Ramificação é a duplicação de objetos sob controle de revisão (como um arquivo de código-fonte ou uma árvore de diretório) de forma que os objetos recém-criados tenham inicialmente o mesmo conteúdo que o original, mas podem evoluir independentemente do original. A ramificação pode assumir duas formas, estática ou dinâmica.
Em ramos estáticos, as operações de cópia e label são usadas para duplicar um determinado ramo. A duplicata então pode evoluir de forma independente.
Com ramificações dinâmicas, geralmente implementadas em fluxos, apenas a operação de label é usada para sinalizar o ponto no tempo em que um fluxo divergiu de seu fluxo pai. Ambos os formulários de ramificação suportam alguma forma de mesclagem, para que as alterações de código feitas em uma ramificação possam ser reintegradas em outra ramificação, como é típico em processos de desenvolvimento paralelos.
A atividade em uma Sprint por meio da qual o Product Owner e as equipes de desenvolvimento adicionam granularidade ao Backlog do Produto.
Refatorar consiste em melhorar a estrutura interna do código-fonte de um programa existente, preservando seu comportamento externo.
Regra de simplicidade é um conjunto de critérios, em ordem de prioridade, proposto por Kent Beck para julgar se algum código-fonte é “simples o suficiente”.
Uma Retrospectiva Milestone é uma análise detalhada de uma equipe dos eventos significativos do projeto após um determinado período de tempo ou no final do projeto.
Equipes ágeis almejam um ritmo de trabalho que seja capaz de ser sustentado indefinidamente.
Uma estrutura para apoiar equipes no desenvolvimento de produtos complexos. Scrum consiste em equipes ágeis Scrum e suas funções, eventos, artefatos e regras associados, conforme definido no Scrum GuideTM.
Um quadro físico para o time Scrum visualizar as informações, frequentemente usado para gerenciar o Sprint Backlog. Scrum boards são uma implementação opcional dentro do Scrum para tornar as informações visíveis.
Papel dentro de um Time Scrum responsável por orientar, treinar, ensinar e auxiliar o time em uma compreensão e uso adequados do Scrum.
A sprint é um período de tempo onde um trabalho específico deve ser executado concluído e preparado para uma posterior revisão. Uma nova sprint se inicia imediatamente após a conclusão da sprint anterior, sendo assim, não é possível dar inicio a outra em paralelo. As sprints geralmente duram de uma a três semanas.
Uma visão geral do trabalho de desenvolvimento para realizar o objetivo de um Sprint, normalmente uma previsão de funcionalidade e o trabalho necessário para entregar essa funcionalidade. Gerenciado pela Equipe de Desenvolvimento.
Uma breve expressão do propósito de um Sprint, geralmente um problema de negócios que é abordado. A funcionalidade pode ser ajustada durante o Sprint para atingir o objetivo.
Evento com limite de tempo de 8 horas ou menos para iniciar uma Sprint. Ele serve para o Time Scrum inspecionar o trabalho do Backlog do Produto que é mais valioso para ser feito em seguida e projetar esse trabalho no Backlog do Sprint.
Evento com caixa de tempo de 3 horas ou menos para encerrar uma Sprint. Ele serve para equipes ágeis Scrum inspecionarem o Sprint anterior e planejarem melhorias a serem implementadas durante o próximo Sprint.
Evento com caixa de tempo de 4 horas, ou menos, para concluir o trabalho de desenvolvimento de um Sprint. Serve para o Time Scrum e as partes interessadas inspecionar o incremento do produto resultante da Sprint, avaliar o impacto do trabalho realizado no progresso geral e atualizar o backlog do produto a fim de maximizar o valor do próximo período.
Uma pessoa externa ao time com um interesse específico e conhecimento de um produto que é necessário para a descoberta incremental.
A forma mais básica de um quadro de tarefas é dividida em três colunas denominadas “Para Fazer”, “Fazendo” e “Feito”. Os cartões são colocados nas colunas para refletir o status atual dessa tarefa.
“Desenvolvimento orientado a testes” é um estilo de programação em que três atividades estão intimamente ligadas: codificação, teste (na forma de escrever testes de unidade) e design (na forma de refatoração).
O teste exploratório é, mais do que estritamente falando, uma “prática”, um estilo ou abordagem para testar o software que muitas vezes é contrastado com o “teste com script”.
Equipes ágeis, auto-organizadas e compostas por um Dono do Produto, Equipe de Desenvolvimento e Scrum Master.
Um timebox é um período de tempo previamente acordado durante o qual uma pessoa ou uma equipe trabalha constantemente para a conclusão de algum objetivo.
Um teste de aceitação é uma descrição formal do comportamento de um produto de software, geralmente expressa como um exemplo ou cenário de uso. Uma série de notações e abordagens diferentes foram propostas para tais exemplos ou cenários. Em muitos casos, o objetivo é que seja possível automatizar a execução de tais testes por uma ferramenta de software, podem ser feitos ad-hoc pela própria equipe de desenvolvimento.
Um teste de unidade é um pequeno fragmento de programa escrito e mantido pelos desenvolvedores da equipe do produto, que executa uma parte restrita do código-fonte do produto e verifica os resultados.
O teste de usabilidade é uma técnica empírica exploratória para responder a perguntas como “Como um usuário final responderia ao nosso software em condições realistas?”
Em consulta com o cliente ou Product Owner, a equipe divide o trabalho a ser feito em incrementos funcionais chamados de “histórias de usuário”.
Um conjunto de valores e qualidades fundamentais que sustentam o framework Scrum em equipes ágeis de desenvolvimento de software; compromisso, foco, abertura, respeito e coragem.
Uma indicação opcional, mas frequentemente usada, da quantidade média de Backlog do Produto realizado durante uma Sprint, rastreado pelo Time de Desenvolvimento para uso dentro do Time Scrum.
“Extreme Programming”, uma forma de implementação muito utilizada em equipes ágeis de desenvolvimento de software e se concentra na produção da situação de codificação mais simples para os requisitos do aplicativo e inclui práticas como programação em pares, design incremental e integração contínua.
Chamamos de formato cascata quando o projeto é concluído em etapas sequenciais distintas, passo a passo, até finalmente chegar na mão dos usuários ou clientes. Esse tipo de processo normalmente resulta em grandes atrasos de planejamento, é lento, e muitas vezes resulta em um produto que as pessoas não querem ou não estão dispostas a pagar.
Esses são apenas alguns dos termos mais comuns utilizados pelas equipes ágeis. Independente de você estar trabalhando em uma equipe ágil de desenvolvimento de software ou sendo parte da gestão de uma equipe ágil, vários desses termos vão surgir no seu dia a dia, pode acreditar.
Vou adicionar mais termos conforme for necessário, espero que você tenha gostado do conteúdo e das dicas.
Um grande abraço, e até a próxima.
