Tarde tem algum significado nas metodologias ágeis?

Isso resultou de algumas respostas e comentários sobre outra pergunta ( esta ).

Trabalhei principalmente em projetos em cascata e, embora tenha trabalhado em projetos ad-hoc que adotaram comportamentos ágeis e leram bastante sobre o ágil, eu diria que nunca trabalhei em um projeto ágil "adequado" .

Minha pergunta é: o conceito de "atrasado" tem algum significado em ágil? Se sim, e daí?

Meu raciocínio é que, com o Agile, você não tem um plano inicial e não possui requisitos detalhados desde o início. Você pode ter uma meta de alto nível em mente e uma data nocturna anexada a ela, mas ambas podem mudar (potencialmente massivamente) e nenhuma delas é certa.

Portanto, se você não sabe exatamente o que vai entregar basicamente até entregá-lo e o usuário o aceitar, e se você não tiver um cronograma além do próximo sprint, como poderá se atrasar de alguma maneira realmente tem significado?

(Obviamente, eu entendo que um sprint pode ultrapassar, mas estou falando além disso.)

Só para esclarecer, eu (pessoalmente) estou feliz com a suposição de que os projetos em cascata no tempo (mesmo os relativamente grandes) são possíveis com base no fato de eu os ter visto e envolvido neles - eles não são fáceis nem comuns nem mesmo mas eles são possíveis.

Não se trata de bater ágil, é sobre eu entender. Eu sempre vi o benefício do ágil como nada a ver com prazos ou orçamentos (ou apenas indiretamente), tem a ver com o escopo - o ágil oferece mais perto do que é realmente importante do que o que a equipe do projeto pensa ser importante antes de eles ' já vi alguma coisa.

Não concordo que um projeto Agile não tenha um plano inicial.

Minha experiência é que os analistas de negócios passaram bastante tempo trabalhando em reuniões de design com clientes e desenvolvedores para elaborar uma lista detalhada de requisitos alcançáveis ​​que são apresentados como histórias de usuários. Eles são divididos em tarefas com estimativas adequadas anexadas por desenvolvedores experientes.

Depois que as tarefas mais importantes forem identificadas no início do sprint / iteração, a codificação poderá começar. Esse processo de seleção determina o significado da iteração no projeto geral ("Estamos construindo o processo de login"). Vários membros da equipe realizam as várias tarefas necessárias para que a história do usuário aconteça.

No final da iteração, todas as histórias de usuário para essa iteração devem estar completas ou você está atrasado . Da mesma forma, o desenvolvimento deve poder parar no final de cada iteração e o produto lançado. Pode não estar completo em termos de todas as histórias de usuário, mas as histórias de usuário que foram solicitadas na iteração estão completas e o produto pode funcionar dentro desses limites.

"atrasado" em uma metodologia ágil significa o mesmo que em uma metodologia em cascata: as estimativas estavam erradas, o escopo era grande demais para o tempo previsto, surgiram dificuldades inesperadas, o cliente não respondeu o suficiente, os programadores ficaram preguiçosos, as máquinas bateram, seu cachorro comeu meu bytecode, etc.

você aprende e se ajusta para a próxima iteração

a diferença é que isso pode acontecer a cada 2-4 semanas, para que as lições sejam aprendidas e o processo seja ajustado rapidamente

Sim, mas levará apenas 1 mês para saber que você não atingirá a data de vencimento do projeto final mítico de 9 meses em vez de 9.

Seu raciocínio baseia-se no pressuposto de que são possíveis planos iniciais e requisitos detalhados para grandes projetos. Não tenho certeza de que existem muitas evidências para apoiar isso. Talvez todas as histórias de horror sejam apenas anedóticas? Qualquer desenvolvedor adoraria trabalhar com especificações completas e nunca alteradas com as quais o cliente concorda e entende completamente.

Sempre que você se comprometer com algum tipo, corre o risco de chegar atrasado. Isso se aplica ao ágil também.

Mas sabemos que você não pode prever o futuro, e sabemos que o cliente mudará constantemente de idéia e concordamos que isso é uma coisa boa. Se aceitarmos isso, também devemos aceitar que todos os compromissos estão quase sempre errados, o que, por sua vez, facilita a resposta à questão do atraso: Estamos sempre errados (cedo ou tarde). É tudo uma questão de suposições, não importa quão bem polido. Atirar uma moeda.

Isso é algo que nós, como desenvolvedores, simplesmente devemos aceitar e, desse ponto de vista, tentamos encontrar outra maneira de trabalhar, uma maneira pela qual a questão do atraso se torna muito menos importante. Uma mudança de perspectiva. Eu acho que a maneira de fazer isso é focar no fornecimento de software operacional o mais rápido possível, com a opção de sair quando o cliente estiver satisfeito.

E é disso que se trata o ágil. Uma maneira inteligente de gerenciar essa noção desconfortável de que atraso é um fato e simplesmente precisamos lidar com isso da melhor maneira possível.

Por exemplo, você está atrasado quando falha em cumprir os compromissos que fez no início da iteração atual. Isso é esperado e você deve aprender com isso e adaptar seu processo para ter menos chances de falhar na próxima iteração. A melhor maneira de lidar com isso é manter as iterações o menor possível.

Para o planejamento de várias iterações, também conhecido como planejamento de liberação, você usa a velocidade calculada a partir das iterações concluídas e extrapola os dados para prever uma data de liberação futura. Eu recomendo James Shores' artigo ou a minha própria (mais curto) para mais detalhes sobre isso. Observe que nunca é um compromisso sólido e mais do que "temos 80% de certeza de que concluiremos os próximos recursos até essa data". Isso pode (mais ou menos) resultar em você chegar atrasado, mas o compromisso é apenas uma probabilidade, não um fato.

Agora compare isso com a promessa básica do ágil de que você deve sempre estar pronto para lançar o software em funcionamento, com o recurso completo ou não. Isso dá ao cliente a liberdade de interromper o desenvolvimento quando ele achar que o sistema é bom o suficiente, o que pode acontecer muito antes do previsto. Também incentiva a tomada do projeto em novas direções, com base no feedback real da última iteração.

Os pontos acima devem ser mais do que suficientes para qualquer cliente estar no controle total do desenvolvimento, e espero que isso responda à pergunta sobre atraso nos métodos ágeis.

Existem dois tipos de "atraso" no Agile SCRUM>

1. Transição - Histórias não "Concluídas" no final de um sprint, os desenvolvedores "comprometem-se" com a realização de um PBI; portanto, quando não é feito, pode ser considerado transportado.

2. Roteiro - Supondo que sua organização tenha um roteiro e supondo que ele tenha datas, se os principais resultados para essas datas forem perdidos, isso poderá ser considerado "atrasado".