O que é o desenvolvimento Agile?

O desenvolvimento agile é um termo usado para descrever o desenvolvimento de software iterativo. O desenvolvimento de software iterativo reduz o ciclo de vida do DevOps concluindo o trabalho em incrementos curtos, geralmente chamados de sprints. Sprints normalmente duram de uma a quatro semanas. O desenvolvimento agile geralmente é contrastado com o desenvolvimento tradicional ou em cascata, que planeja projetos maiores antecipadamente e os conclui de acordo com o plano.

Fornecer código de qualidade de produção a cada sprint requer que a equipe de desenvolvimento agile seja responsável por um ritmo acelerado. Toda a codificação, teste e verificação de qualidade devem ser feitas a cada sprint. A menos que uma equipe esteja configurada corretamente, os resultados podem ficar aquém das expectativas. Embora essas decepções ofereçam grandes oportunidades de aprendizado, é útil aprender algumas lições importantes antes de começar.

Este artigo apresenta alguns dos principais fatores de sucesso para as equipes de desenvolvimento agile:

• Refinamento de pendências diligente
• Integrar cedo e frequentemente
• Minimizando a dívida técnica

Refinamento de pendências diligente

Uma equipe de desenvolvimento do Agile trabalha com um backlog de requisitos, que geralmente são chamados de histórias de usuário. A lista de pendências é priorizada, com as histórias de usuário mais importantes na parte superior. O dono do produto possui a lista de pendências e adiciona, altera e reprioriza histórias de usuário com base nas necessidades do cliente.

Um dos maiores arrastes na produtividade de uma equipe agile é um backlog mal definido. Não se pode esperar que uma equipe forneça consistentemente software de alta qualidade a cada sprint, a menos que tenha requisitos claramente definidos.

O trabalho do proprietário do produto é garantir que cada sprint, os engenheiros tenham claramente definido histórias de usuário com as quais trabalhar. As histórias de usuário na parte superior da lista de pendências devem estar sempre prontas para a equipe começar. Essa noção é chamada de refinamento do backlog. Manter uma lista de pendências pronta para uma equipe de desenvolvimento agile requer esforço e disciplina. Felizmente, vale a pena o investimento.

Ao refinar um backlog, lembre-se das considerações principais a seguir.

1. Refinar histórias de usuário geralmente é uma atividade de longa duração. Interfaces de usuário elegantes, designs de tela bonitos e soluções que encantam o cliente levam tempo e energia para serem criadas. Os proprietários de produtos diligentes refinam histórias de usuários de dois a três sprints com antecedência. Eles são responsáveis por iterações de design e revisões de clientes. Eles trabalham para garantir que cada história de usuário seja algo que a equipe agile se orgulha de entregar ao cliente.

2. Uma história de usuário não é considerada refinada até que a equipe afirme que é. A equipe precisa examinar a história do usuário e concordar que está pronta para trabalhar. Se uma equipe não vir a user story até o primeiro dia de um sprint, problemas poderão surgir.

3. As histórias de usuário mais abaixo no backlog podem permanecer ambíguas. Não perca tempo refinando itens de prioridade mais baixa. Concentre-se na parte superior da lista de pendências.

Integrar cedo e de forma frequente

A CI/CD (integração contínua e entrega contínua) configurou sua equipe para o ritmo rápido do desenvolvimento agile. Assim que possível, automatize os pipelines de build, teste e implantação. Configure essa automação como uma das primeiras tarefas que sua equipe enfrenta quando você inicia um novo projeto.

Com a automação, a equipe evita processos de implantação manuais lentos, propensos a erros e com uso intensivo de tempo. Como as equipes liberam cada sprint, não há tempo para realizar essas tarefas manualmente.

CI/CD também influencia sua arquitetura de software. Ele garante que você forneça software compilável e implantável. Quando as equipes implementam uma funcionalidade difícil de implantar, elas ficam imediatamente cientes se a compilação e as implantações falharem. A CI/CD força uma equipe a corrigir problemas de implantação conforme eles ocorrem. O produto está sempre pronto para ser enviado.

Há algumas atividades importantes de CI/CD que são extremamente importantes para o desenvolvimento agile eficaz.

1. Teste de unidade. Os testes de unidade são a primeira defesa contra o erro humano. Considere os testes de unidade como parte da codificação. Integre os testes ao código. Torne o teste de unidade uma parte de cada build. Testes de unidade com falha significam uma compilação com falha.

2. Compilar automação. O sistema de build deve efetuar pull automático de código e testes diretamente do controle do código-fonte quando os builds forem executados.

3. Ramificar e criar políticas. Configure as políticas de branch e build para serem compiladas automaticamente à medida que a equipe verifica o código em um branch específico.

4. Implantar em um ambiente. Configure um pipeline de lançamento que implanta automaticamente projetos criados em um ambiente que imita a produção.

Minimizar a dívida técnica

Com as finanças pessoais, é mais fácil manter-se longe das dívidas do que livrar-se delas. A mesma regra se aplica à dívida técnica. A dívida técnica inclui tudo o que a equipe deve resolver devido a decisões rápidas que foram tomadas anteriormente. Por exemplo, se você estiver em um agendamento apertado, poderá sacrificar a qualidade para cumprir um prazo. Dívida técnica é o preço que você paga mais tarde, quando você tem que refatorar o código para compensar essa falta de qualidade. Exemplos incluem correções para resolver problemas de design, bugs, problemas de desempenho, problemas operacionais, problemas de acessibilidade e outros problemas.

Gerenciar a dívida técnica requer coragem. Há muitas pressões para atrasar o retrabalho do código. É bom trabalhar em funcionalidades e ignorar a dívida técnica. Infelizmente, alguém deve pagar a dívida técnica mais cedo ou mais tarde. Assim como a dívida financeira, a dívida técnica torna-se mais difícil de pagar quanto mais tempo ela existe. Um dono de produto inteligente trabalha com sua equipe para garantir que há tempo para quitar a dívida técnica em cada sprint. Equilibrar a redução da dívida técnica com o desenvolvimento de recursos é uma tarefa difícil. Felizmente, há algumas técnicas simples para criar equipes produtivas e focadas no cliente.

Sempre ser Agile

Ser Agile significa aprender com a experiência e melhorar continuamente. O desenvolvimento agile fornece mais ciclos de aprendizagem do que o planejamento de projeto tradicional devido aos loops de processo mais rígidos. Cada sprint fornece algo novo para a equipe aprender.

Por exemplo:

• Uma equipe fornece valor ao cliente, obtém comentários e modifica sua lista de pendências com base nesses comentários.
• Eles aprendem que suas compilações automatizadas estão faltando testes principais. Eles incluem trabalho em seu próximo sprint para resolver esse problema.
• Eles acham que determinados recursos têm um desempenho ruim na produção, portanto, fazem planos para melhorar o desempenho.
• Alguém da equipe fica sabendo de uma nova prática. A equipe decide experimentar por alguns sprints.

As equipes que estão apenas começando com o desenvolvimento agile devem esperar mais oportunidades de aprendizado. Eles são uma parte inestimável do processo porque levam ao crescimento e à melhoria.

Próximas etapas

Há muitas maneiras de estabelecer um processo de desenvolvimento Agile que é adequado para uma equipe. O Azure DevOps fornece vários modelos de processo. As equipes que estão procurando estruturas de linha de base diferentes para seu planejamento podem usar esses modelos como pontos de partida. Para obter informações sobre como selecionar um modelo de processo que melhor se adapte à cultura e às metas de uma equipe, consulte Escolher um fluxo de processo ou modelo de processo para trabalhar no Azure Boards.

À medida que as organizações crescem, pode ser um desafio permanecer disciplinado. Saiba mais sobre como dimensionar o Agile para grandes equipes.