Pequeno glossário ágil
Deploy não é nome de planeta, sprint não é marca de refrigerante e product backlog é algo que você deveria ter
Para quem não conhece metodologias ágeis ou está começando a estudar agora, ouvir uma conversa entre um time ágil pode ser o mais próximo de uma viagem para fora da órbita terrestre que essa pessoa irá chegar.
O desenvolvedor diz que vai “deployar”. O designer, durante uma daily meeting, pede para que os sprints sejam maiores. Outro integrante do time comenta que o product backlog precisa ser atualizado, pois houve mudança nas prioridades.
Enquanto isso, você:
E, jurando para si mesmo que o entendimento dessa conversa só seria possível em outro planeta, já começa a formular perguntas sobre como é a vida em Marte. Afinal, essas pessoas só podem ter nascido há pelo menos duzentas luas de distância da Terra.
Sinto te desapontar, mas não vai ser dessa vez que você vai postar uma selfie com um extraterrestre no Instagram. Afinal, essas palavras não só fazem sentido, como se relacionam com práticas extremamente importantes para o desenvolvimento ágil.
A boa notícia é que causos como esse nos motivaram a resumir as principais práticas ágeis e trazer pra cá explicações sobre cada uma delas. Então, se você já sabe o que é agile e tem alguma dúvida sobre alguma das práticas que definem as metodologias, pode respirar aliviado, pegar um café quentinho e se debruçar sobre o glossário ágil, feito especialmente para clarear suas ideias e te trazer de volta para a órbita terrestre.
Porém, se você quer ser ágil, mas ainda não domina bem o conceito, sugerimos começar pelo começo (uma receita velha e funcional) para entender melhor os quatro valores e os 12 princípios do Manifesto Ágil.
Feitas as devidas recomendações, vamos ao que interessa. Afivele o cinto e aproveite a viagem!
Glossário do desenvolvimento ágil
1. Product Owner (P.O.)
Também conhecido como P.O. (pi-ow), é o papel de maior responsabilidade para o desenvolvimento ágil. É a pessoa que representa o cliente e define os itens que compõem o Product Backlog (2) — ou só Backlog, para os íntimos.
Definir metas, priorizar e aprovar a qualidade do produto em desenvolvimento, procurando garantir o maior retorno ao investimento, também fazem parte das atividades do P.O.
Para o desenvolvimento ágil, quanto mais próximo o cliente estiver do time, melhor. Essa proximidade garante que o projeto percorra o melhor caminho possível.
2. Product Backlog
É uma lista de todas as funcionalidades desejadas para um produto. Quem define esse conteúdo é o P.O.(1), durante o Sprint Planning Meeting(6) .
Inicialmente, essa lista começa com as necessidades mais óbvias, mas normalmente muda com o tempo, à medida que o time aprende mais sobre o produto e seus usuários.
Manter uma lista priorizada é importante para sustentar o fluxo de produção, dar mais visibilidade às trocas que são feitas e aos efeitos dessas mudanças. Fazem parte do Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.
3. Sprint/Iteração
Em metodologias ágeis, como o Scrum(12), o processo de desenvolvimento é dividido em ciclos de trabalho regulares com duração pré-definida. Sprint é cada um desses ciclos e ocorre em intervalos de uma a quatro semanas, sem alteração.
A cada Sprint um conjunto de requisitos deve ser implementado. A essas implementações contínuas é dado o nome de Incrementos, que, na prática, são pequenos pedaços de produto em funcionamento.
4. Desenvolvimento iterativo e incremental
Já fizemos um post só sobre isso. Se você estiver com tempo, vale a pena dar uma olhada. Mas, resumidamente, é um processo de desenvolvimento que defende que o ciclo de vida de um software (requisitos — desenvolvimento — testes — implantação) deve ser reduzido ao menor tamanho possível e repetido várias vezes com entregas pequenas de software. Essa repetição cíclica e contínua é chamada de iteração. E os pequenos pedaços entregues a cada ciclo são os incrementos.
5. Daily Meeting ou Stand Up Meeting
É uma reunião diária que dura cerca de 15 minutos, com o objetivo de deixar o canal de comunicação entre o time sempre ativo e entender como vai a evolução do projeto.
Para isso, cada pessoa deve, além de ouvir o que os outros têm a dizer, responder algumas questões fundamentais sobre seu trabalho. O que você fez ontem? O que você fará hoje? Há algum impedimento no seu caminho?
A ideia é que o Daily aconteça sempre no mesmo lugar e no mesmo horário, idealmente pela manhã, para ajudar a estabelecer as prioridades do dia.
Vale dizer que essa não é uma reunião para resolver problemas. Questões levantadas durante o Daily devem ser levadas para fora da reunião e tratadas por um grupo menor de pessoas, que tenham ligação direta com a solução do problema.
6. Sprint Planning Meeting
Com o Backlog(2) pronto, é feita uma reunião para escolher as histórias (itens da lista) com prioridade mais alta para o desenvolvimento. Essas histórias são quebradas em pequenas tarefas, que serão executadas durante o Sprint (3).
A função do P.O. no Sprint Planning Meeting é ajudar a definir e priorizar as histórias. Mas também é legal quando o P.O. participa da reunião para auxiliar nas quebras de tarefas, pois, nesse momento, podem surgir algumas dúvidas que só ele consegue responder com segurança.
7. Sprint Retrospective
Ocorre ao final de cada Sprint(3) e serve para identificar o que funcionou bem durante o ciclo, o que pode ser melhorado e que ações serão tomadas para melhorar.
8. Sprint Review Meeting
Reunião para mostrar o que foi feito durante o Sprint(3). Geralmente, essa apresentação tem o formato de um demo das novas funcionalidades.
Algumas Sprint Review Meeting reúnem usuários e time de desenvolvimento na mesma sala. A ideia é criar um ambiente propício para críticas produtivas, que ajudem a melhorar o produto em construção.
Durante o Sprint Review, o projeto é avaliado em relação ao objetivo geral do Sprint, determinado durante o Sprint Planning Meeting(6).
9. Release planning
É um plano de ação criado no início do projeto, baseado nas expectativas do cliente e no histórico de desenvolvimento do produto.
Como não é possível que o time conheça tudo no início, o Release Plan não precisa ser detalhado. Mas é interessante que aborde a quantidade e a duração dos Sprints(3), o número de pessoas ou times que participarão do projeto, a quantidade de entregas (releases), o valor a ser entregue em cada release e a data de liberação de cada um deles.
10. Deploy
Deploy ou Deployment significa instalar aplicações em um servidor e disponbilizá-las para o usuário. Da próxima vez que você ouvir alguém dizendo que vai “deployar”, já sabe que ele não está dizendo que vai voltar para Marte.
11. Extreme Programming (XP)
É uma metodologia de desenvolvimento ágil de software para pequenos e médios times, que ajuda a criar sistemas com mais qualidade, em menos tempo e de forma mais econômica.
Assim como o Manifesto Ágil, essa metodologia tem seus próprios valores e princípios.
12. Scrum
É uma das mais populares metodologia do desenvolvimento ágil para gestão e planejamento de projetos de software. Segue os valores e princípios do Manifesto Ágil.
13. Scrum Master
É a pessoa responsável por garantir que o time respeite e siga os valores e as práticas da metodologia Scrum(12). É uma função geralmente exercida por um gerente de projeto ou por um líder técnico, mas pode ser qualquer integrante da equipe com afinidade para gerenciamento e liderança.
Outra preocupação do Scrum Master é cuidar para que o time não se comprometa com tarefas que não é capaz de realizar durante um Sprint(3).
O Scrum Master também atua como facilitador do Daily Meeting(5), sendo a pessoa responsável por tirar do caminho os obstáculos levantados durante essas reuniões.
14. Test Driven Development (TDD)
É o desenvolvimento orientado por testes. O que, na prática, significa escrever um caso de teste antes de programar a real implementação.
O ciclo de desenvolvimento com o TDD acontece em três passos:
- Criar um teste e observá-lo falhar;
- Escrever um código suficientemente simples para o teste passar;
- Refatorar para remover duplicidade.
Ah, e se você não sabe, refatoração é o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.
15. Behaviour Driven Development (BDD)
O Desenvolvimento Guiado por Comportamento (BDD) é uma técnica de desenvolvimento ágil que encoraja a colaboração entre desenvolvedores, pessoas de qualidade, não técnicas e de negócios em um projeto de software.
16. Continuous Delivery (Entrega contínua)
Ao aplicar práticas e técnicas de Continuous Delivery, os times de desenvolvimento entregam novas versões de software de maneira contínua, reduzindo o tempo do ciclo de vida da implantação de funcionalidades e trazendo mais agilidade para os negócios.
Dicas de leitura
E aí, sua cabeça já voltou a habitar a Terra ou ainda está flutuando pelo espaço?
Se você ainda está assim:
E quer entender melhor algumas dessas práticas (ou todas elas), separamos alguns conteúdos úteis e interessantes:
- Um guia open source brasileiro sobre Desenvolvimento Ágil, cheio de explicações e passo a passo;
- Uma abordagem mais profunda sobre o que são as siglas DDD, TDD e BDD e como usá-las na prática;
- O nosso artigo sobre as razões para desenvolver iterativamente;
- Este texto mastigadinho sobre os quatro valores ágeis e;
- A série “ser ágil é uma questão de princípios”, que aborda os 12 princípios ágeis com profundidade e exemplos.
