A base do desenvolvimento ágil de software

Foto de Sohrab Salimi
Sohrab Salimi
2 Min. Tempo de Leitura
Este conteúdo foi traduzido com IA. Ver original

O desenvolvimento ágil de software é, com exceção do caso mencionado abaixo, iterativo. Uma iteração é um período curto de tempo, de um mês até apenas uma semana. Na minha experiência, a duração média de uma iteração em diferentes equipes varia de um mês (o padrão do Scrum) até uma semana, que é a minha recomendação para um ciclo XP. Acredito que a tendência atual seja de duas semanas.

Mas estou fugindo do assunto. O elemento mais importante no Agile, a Conditio sine qua non, a condição necessária, o pré-requisito, aquilo que você deve fazer de qualquer forma, é:

A equipe deve entregar software funcionando, testado e integrado ao final de cada iteração; em Scrum, diríamos que ele deve estar "done-done"

Não há como escapar disso. Você não pode entregar algo apenas a cada duas iterações. Também não pode entregar software quase pronto e depois corrigi-lo na próxima iteração. Nem tente fugir disso. Você precisa entregar software.

Uma exceção

Se você pensou que encontraria aqui uma forma de escapar disso, pensou errado. A única exceção para entregar software funcionando em cada iteração é entregar ainda mais frequentemente. Algumas equipes de ponta trabalham atualmente em uma espécie de modo Kanban, onde entregam funcionalidades essencialmente de forma contínua, geralmente a cada poucos dias.

Desculpa, não tem como escapar disso

Software real, funcionando, integrada, testada, done-done – e isso em cada iteração, ou simplesmente de forma permanente. No caminho até lá, você vai precisar aprender o que tudo isso significa, e certamente vai encontrar dificuldades. Mas você também vai perceber que "done" significa mais do que você pensava. Claro que inclui o manual de instruções. Claro que inclui treinamentos para usuários. Claro que inclui tudo aquilo que você achava que não era possível.

Ninguém é perfeito

A sua equipe não é perfeita e provavelmente não vai conseguir fazer tudo isso em cada iteração. O que você definitivamente deveria fazer, no entanto, se ainda tem espaço para melhorar, é algo chamado "Inspect & Adapt" no Scrum. Kent Beck disse uma vez assim: "Encontre o seu maior problema, resolva-o à maneira do XP e repita o processo."

Se você precisar de ajuda com isso, busque essa ajuda.

E agora comece a entregar esse software!

Este texto é do blog de Ron Jeffries e foi traduzido por nós para o alemão.

Mais sobre este tema

Você conhece seus stakeholders como Product Owner?

Quem são seus stakeholders? Como Product Owner, você deve sempre ter consciência de quem é importante no desenvolvimento do produto. Saiba mais no blog!

A Apple é realmente "Ágil"?

Como as grandes empresas como Apple, Google ou Spotify trabalham de forma ágil? Nós te contamos na nossa área de conhecimento da Agile Academy!

Produtos fracassados

Como os produtos falham e como você pode prever ou evitar isso? Respondemos essa e outras perguntas na área de conhecimento da Agile Academy!

Fale com nosso assistente Fale com nosso assistente