TL; DR
Are deadlines [a]gile?...[D]eadlines are viewed to go hand in hand with [a]gile development.
Muitas respostas aqui provavelmente se concentrarão nos aspectos de engenharia da questão. Em vez disso, abordarei isso de uma perspectiva de gerenciamento de projetos.
Um prazo implica uma grande quantidade de planejamento inicial que não está de acordo com os princípios ágeis. Em vez disso, os modelos de desenvolvimento iterativo se baseiam em time-boxes, cadência e ciclos de lançamento que incluem o planejamento just-in-time, mas não o grande planejamento inicial geralmente associado ao projeto tradicional. prazos de gestão.
Ainda é possível fazer o planejamento de liberações com metodologias ágeis, mas os planos geralmente são baseados em uma estimativa do número de iterações necessárias para atingir uma meta, em vez de metas de gerenciamento definidas por decreto. Isso não quer dizer que as datas de envio não possam ser definidas, ou que as metas não possam ser cumpridas, mas a maneira como são definidas e atendidas é bem diferente das metodologias tradicionais de gerenciamento de projetos.
Pense nos prazos, não nos prazos
However, every project I have ever been on has insisted on setting a deadline. Given that Agile attempts to focus on adaptive planning, flexibility and change; are deadlines Agile?
Este é um mal-entendido comum dos princípios ágeis. Frameworks ágeis como Scrum e Kanban não são focados em prazos, mas sim em time-boxing e uma cadência sustentável de entrega.
No Scrum, por exemplo, o Sprint não é um "prazo final". É uma caixa de tempo que é preenchida com a quantidade de trabalho que a equipe estima caberá dentro da caixa de tempo sem transbordá-la, e é então "concluída" ou "não terminada" quando a caixa de tempo expirar. Uma vez fora, a caixa de tempo se foi para sempre; qualquer trabalho que não seja feito deve ser re-planejado e reestimado dentro de uma nova caixa de tempo, igualmente efêmera, baseada nas necessidades atuais (e não históricas) do projeto.
A importância da caixa de tempo é que ela cria uma cadência previsível para que as partes interessadas avaliem o progresso e um ritmo sustentável para a equipe na qual é possível fornecer incrementos de valor potencialmente despachados . O trabalho é incremental e segue a cadência; o conceito de um prazo inicial grande não está, portanto, de acordo com os princípios ágeis.
Liberar o planejamento com base nas caixas de tempo
Talvez a única área em que as pessoas tenham mais dificuldade em mapear processos ágeis para estruturas tradicionais seja no planejamento de versões. O planejamento de liberação geralmente envolve entregas de escopo fixo ou datas fixas. Em frameworks ágeis, o planejamento de release geralmente é feito através de um processo de estimativa onde escopo é explicitamente definido como uma variável mutável, enquanto datas de lançamento são estimadas em iterações.
Por exemplo, um projeto pode estar comprometido em liberar v1.0 de um projeto no final de 20 iterações; o escopo do que é lançado pode mudar ao longo da vida do projeto (como escopo, recursos e prioridades podem mudar no início de cada Sprint), mas as datas de destino para cada versão são fixadas no plano do projeto. A equipe se esforça para fornecer um incremento potencialmente utilizável a cada Sprint, e a Definição de Concluído inclui verificações de qualidade, como a integração contínua, para garantir que o projeto esteja em um estado liberável no final de cada Sprint.
Ocasionalmente, você verá projetos ágeis em que o escopo é fixo, mas como o escopo é a variável mutável em projetos ágeis, a data de lançamento pode mudar com o tempo conforme o escopo de cada iteração se ajusta, muda ou se adapta às necessidades em evolução do projeto. Eu certamente não recomendo a abordagem de escopo fixo para equipes ágeis, especialmente equipes inexperientes, mas há momentos em que é a abordagem correta.
Veja também