Os prazos são ágeis?

Para maior clareza, o prazo final é:

Um limite de tempo ou prazo é um campo de tempo estreito, ou momento específico, pelo qual um objetivo ou tarefa deve ser realizado.

^{Da wikipedia}

Toda a minha carreira de desenvolvimento de software que tenho feito "Agile", que em toda parte parece significar que pelo menos as seguintes práticas foram seguidas:

• Sprints semanais ou quinzenais
• Retrospectivas Planejamento de Sprint
• Um proprietário do produto
• Scrum
• Histórias de usuários

No entanto, todos os projetos em que já participei insistiram em estabelecer um prazo. Dado que o Agile tenta se concentrar no planejamento adaptativo, flexibilidade e mudança; os prazos são ágeis?

Minha opinião é que eles não são, pois vejo prazos levando a uma falta de flexibilidade e qualidade. Em vez disso, acho que fornece mais valor ao foco em Sprints e entregas antecipadas. Parece, no entanto, que em todos os círculos em que participei, esse não é o caso, e os prazos são vistos para acompanhar o desenvolvimento do Agile.

Os prazos são uma realidade. Na maioria das vezes você precisa ter algo em uma determinada data. É inevitável. Sem prazos, até projetos ágeis podem sucumbir à Lei de Parkinson :

O trabalho se expande para preencher o tempo disponível para sua conclusão.

Em outras palavras, se o seu projeto puder continuar para sempre, ele continuará.

Em relação aos prazos, o Agile tenta fazer algumas coisas:

• Garanta que todos sempre possam ver quanto trabalho será realizado dentro do prazo
• Certifique-se de que os recursos mais importantes sejam concluídos primeiro
• Garanta que os recursos concluídos sejam utilizáveis, no sentido de que eles não dependem de recursos que ainda não foram concluídos
• Garantir que o desenvolvimento continue em um ritmo sustentável

Dessa forma, quando chegar o dia inevitável, você não terá uma pilha inútil de código, mas um produto testado e que funcione, espero, apenas as coisas menos importantes inacabadas. E ninguém se surpreende com o produto final.

Então sim. "Ágil" e "prazos" podem ser perfeitamente compatíveis.

Os prazos são um fato da vida. Há coisas que têm uma data muito firme.

Precisamos do software da Comdex

ou

Os jogos devem estar nas prateleiras das lojas até a Black Friday

e similar. Não se pode adiar a Comdex ou a Black Friday - o resto do mundo não funciona dessa maneira.

O objetivo do Agile é que as coisas que não cumpram o prazo falhem mais rapidamente (e isso é uma coisa boa) ou que o escopo possa ser reexaminado mais cedo para que os recursos possam se concentrar no ROI correto em um maneira mais oportuna.

O prazo é uma data difícil, estabelecida com firmeza. O Agile é uma ferramenta que permite perceber no início do ciclo que o software levará o dobro do tempo para se desenvolver como originalmente esperado. É importante que os gerentes de projeto consigam solucionar esses problemas mais cedo ou mais tarde, para que mais recursos possam ser adicionados, o escopo alterado, o prazo ajustado (na situação em que é uma empresa e não o prazo sólido) ou o projeto cancelado.

A transparência que o Agile procura é mostrar os problemas e o progresso no início do ciclo. A falha clássica na entrega em cascata é aquela em que você passou meses a portas fechadas e entregou o produto uma semana antes do prazo final e foi informado que você estava fazendo tudo errado e que perdeu meses (e agora cumpriu completamente o prazo) . A outra falha clássica em cascata é descobrir uma semana antes do prazo que você ainda tem meses pela frente. O Agile procura tornar esses problemas conhecidos no início do processo.

A outra parte que o Agile procura fazer no contexto de um prazo final é que, mesmo que apenas parte dos recursos acordados estejam completos (por qualquer motivo), a versão atual do software é útil e implementável.

Ok, perdemos ter tudo o que queremos para o software tributário ser implantado em 15 de abril, mas temos 75% e o que temos funciona e funciona desde que começamos em novembro passado. Sabíamos que não poderíamos implantar o conjunto completo de recursos desde meados de dezembro e reorientamos nossos esforços nos 80% da base de clientes.

Alguns prazos devem ser cumpridos. Obrigações contratuais, convenções, requisitos regulatórios. Alguns são impostos por gerentes que desejam colocar o desenvolvimento de software no mesmo gráfico da fabricação em sua planilha. Qualquer que seja a causa, a maioria das pessoas não pode fugir delas.

Se você estiver trabalhando em uma equipe que funcione, a comunicação entre os desenvolvedores e a gerência / partes interessadas significa que as pessoas que precisam tomar uma decisão estão bem informadas para decidir se perder o prazo ou continuar o desenvolvimento é mais importante.

Mesmo se você estiver entregando histórias de usuário concluídas uma vez por semana ou duas vezes por mês, provavelmente ainda terá prazos. Quando estiver chegando, verifique se seus stakeholders sabem o que você acha que caberá dentro do prazo e estabeleça expectativas.

Se você está constantemente criando o melhor software possível com os requisitos que você possui atualmente em todas as etapas, o prazo final de qualquer sprint teoricamente não deve ser um problema. Na prática, esse normalmente não é o caso, mas também não há prazos que surgem do nada. Os prazos mais importantes que eu já recebi foram comunicados há muito tempo; era a expectativa da qualidade e dos recursos que eram o problema.

Os prazos arbitrários que não têm consequências se perdidos não são muito ágeis, mas há situações em que, por razões fora dos prazos de controle da equipe de desenvolvimento, devem ser definidos e mantidos. Felizmente, se os prazos forem razoáveis, existem várias maneiras de inverter a equação e lidar com os prazos de maneira ágil.

Os prazos nem sempre estão errados. Como todos aprendemos com Obi-Wan:

"Somente os Sith lidam em absolutos"

É justo dizer que, na maioria dos casos, os prazos são tolos, desnecessários e certamente não são ágeis, mas seria um tolo dizer que esse é sempre o caso. O caso architypal é um software necessário para um uso sensível ao tempo, como o software de rastreamento de eleições. Se o software não estiver pronto a tempo da eleição, não seria sensato nem prático adiar a eleição, e não parece ser muito orientado para o cliente apenas dizer 'Desculpe, parece que demoramos muito tempo. Sei que esse software pelo qual você está nos pagando é totalmente inútil, mas os prazos não são ágeis; então, como você pode realmente resistir a nós por não cumpri-los?

Não é muito ágil dizer aos seus clientes para empurrá-lo por querer algo que é sensível ao tempo, e no final do dia alguém terá que construir essas coisas. Então, como ainda podemos fazer os clientes felizes e ainda oferecer soluções aparentemente razoáveis ​​para coisas que são sensíveis ao tempo? Bem, se o desenvolvimento de software leva uma quantidade incerta de tempo e o prazo não é variável, outra coisa precisará ser variável para lidar com essa incerteza ...

Se a data de entrega for mantida constante, algum outro aspecto se tornará variável.Como todos sabemos, pode haver uma grande quantidade de incerteza em projetos de software. Algo precisa ser modificado em resposta a essa incerteza, se você deseja obter sucesso em seu projeto, e geralmente essa é a data de entrega. Parece bastante natural, de qualquer maneira. Mas essa não é sua única opção. Se você está comprometido com um prazo final, a maneira de lidar com isso é fazer com que os recursos entregues sejam variáveis. Priorize uma lista de recursos, comunique claramente que há incerteza na quantidade de recursos que podem ser entregues até essa data. Trabalhe com o cliente para priorizar esses recursos, para que os mais importantes tenham maior probabilidade de serem enviados. Então, é como de costume, apenas quando o prazo chegar ao seu redor, o que estiver pronto para ser enviado. Nesse modelo,

Se alguém deseja definir um prazo, então está bem e o prazo pode ser fixado, mas o que eles devem entender é que, se o prazo for fixado, o escopo deverá permanecer flexível.

tl; dr

Em um mundo ideal, não teríamos prazos e apenas entregar as coisas quando estiverem prontas. A realidade, porém, é que as pessoas que pagam pelas coisas geralmente querem saber quando elas terminam. As metodologias ágeis reconhecem isso, mas também reconhecem que nem tudo pode ser amarrado.

Isso garante que você possa manter a qualidade da entrega no nível certo para o produto. Se você estabelecer um prazo e escopo (e orçamento), as coisas serão apressadas e você voltará ao antigo mundo da cachoeira com um tempo de crise no final do projeto. Aumentar o orçamento geralmente não é a resposta, porque adicionar mais desenvolvedores e testadores não resolve um problema mais rapidamente. É uma visão bem conhecida (e eu concordo com isso por experiência própria), que quanto mais pessoas você adicionar (cada uma com suas próprias fraquezas), mais tempo levará.

Agora, normalmente (a menos que eles realmente entendam os métodos ágeis) que a pessoa que paga pelo software não gosta de ser avisada, podemos cumprir seu prazo, mas não podemos fazer tudo o que você deseja. Isso pode ser gerenciado priorizando os recursos que compõem o software. Sua discussão sobre priorização pode ser como:

Equipe de desenvolvimento (D): "Por favor, você pode priorizar os recursos que deseja entregar, sendo os mais importantes primeiro?"

Cliente (C): "Tudo é prioridade 1 - quero que todos sejam concluídos até o final do próximo mês".

D : "Isso pode ser possível, mas pode não ser possível se os requisitos forem alterados ou se descobrirmos problemas que não esperávamos durante o desenvolvimento".

C: "Bem, e se eu lhe der mais dinheiro?"

D: " suspiro ... mesmo com mais recursos, eles levarão um mês para realmente começar; então, se você não tiver certeza de como priorizar os recursos, diga-nos quais você deseja que seja feito primeiro".

C: "Ok, eu quero o botão grande, mas faça-o realmente grande, e então ... etc"

Agora você pode começar a trabalhar com os recursos em ordem de prioridade. Também ajuda olhar em frente com sua equipe para os itens mais baixos na ordem de prioridade e fazer algumas estimativas antecipadas, sabendo que você pode alterá-los quando chegar ao desenvolvimento quando tiver mais informações. Isso pode ser usado para redefinir ou criar seu roteiro, se você ainda não o tiver. Isso então forma a base do seu plano de liberação. O roteiro pode ser discutido com o cliente, reconhecendo que o escopo pode mudar, mas você tem uma ordem de itens a serem entregues.

Uma das grandes vantagens do Agile é que ele reconhece que as coisas mudam à medida que você passa pelo desenvolvimento e se ajusta conforme elas. Ao contrário das abordagens mais tradicionais, esse princípio, em conjunto com as entregas regulares do sprint e a comunicação contínua com o cliente, significa que você é naturalmente forçado a ser mais transparente sobre o progresso, o que é uma coisa boa.

Às vezes, o cliente não gosta de não conseguir o que deseja em uma determinada data, mas entenderá o porquê e o que conseguirá será de boa qualidade. E seis meses após a entrega dos recursos, o cliente não se importará ou se lembrará de que você entregou em uma determinada data, eles lembrarão da qualidade do produto que ainda estão usando.

Tradicionalmente, os prazos são baseados no ciclo de vida dos negócios. O software tributário precisa estar disponível até 15 de abril. Os relatórios para o próximo ano fiscal podem precisar ser feitos até julho.

O manifesto ágil declara:

Indivíduos e interações sobre processos e ferramentas

Software que trabalha sobre uma documentação completa

Colaboração do cliente sobre negociação de contrato

Respondendo à mudança Seguindo um plano

Os prazos são um contrato. Eles são um plano. Eles não respondem à velocidade da sua equipe. Eles não mudam se você perder seus três melhores desenvolvedores.

Os prazos não são ágeis, mas o Agile pode nos dar feedback sobre os prazos. Ágil, deixe-nos saber se nossa velocidade não nos permitirá estabelecer um prazo sem que um recurso seja cortado. Também nos informa se precisamos contratar para cumprir um prazo. E, em alguns casos, vamos saber que um prazo é impossível, quando não há recursos a serem cortados.

A melhor coisa que uma equipe Agile pode fazer é deixar a velocidade e a lista de pendências priorizadas direcionarem os prazos. Isso fornecerá datas de entrega estimadas. Se as pessoas ficarem fora do prazo, é hora de conversar seriamente com o cliente e determinar se o prazo é viável.

Eu diria que a entrega de cada sprint não é negociável. Você avalia o trabalho, coloca tamanhos de cartão e carrega o suficiente para manter sua equipe ocupada até o sprint terminar (e o sprint deve ser pequeno - de uma semana a um mês). Os "prazos de entrega" devem basear-se na tendência histórica do trabalho concluído em relação ao trabalho previsto. O Agile não adiciona / remove nada da antiga idéia de restrição "custo / tempo / escopo"; ele simplesmente usa o escopo como o método preferido de gerenciar derrapagens, com base em que uma melhor priorização em relação ao escopo é geralmente preferível a gastar mais dinheiro ou tempo.

Algumas pessoas parecem confundir ágil com "oeste selvagem". Agile não significa que vale tudo. Ágil significa que paramos de mentir para nós mesmos sobre quão bem uma pessoa razoável pode estimar. Basicamente, podemos estimar o desenvolvimento de software em duas a quatro semanas no futuro. Além disso, são todos os graus variados de ganhos e suposições. Pior ainda, o custo de fornecer estimativas para coisas cada vez mais distantes no futuro se aproxima do custo de apenas fazer o trabalho. Por qualquer motivo, os Gerentes de Projeto historicamente não estavam dispostos a admitir essas verdades absolutas para os clientes. O Agile simplesmente ajusta esse pensamento afirmando que há um limite de quão bem podemos prever o futuro na engenharia de software e faz uma mudança sutil para a "estimativa baseada em evidências" para previsões de longo prazo.são capazes de estimar, e podemos fornecer estimativas razoáveis ​​de entrega futura a longo prazo com base no que entregamos até agora.

TL; DR

Os prazos de entrega [a] gile? ... [D] Os prazos de entrega são vistos para acompanhar o desenvolvimento [a] gile.

Muitas respostas aqui provavelmente se concentrarão nos aspectos de engenharia da pergunta. Em vez disso, abordarei isso da perspectiva de gerenciamento de projetos.

Um prazo implica uma grande quantidade de planejamento inicial que não está alinhado com os princípios ágeis. Em vez disso, os modelos de desenvolvimento iterativo baseiam-se em caixas de tempo, cadência e ciclos de lançamento que incluem planejamento just-in-time, mas não o "grande planejamento inicial" que geralmente é associado aos prazos tradicionais de gerenciamento de projetos.

Ainda é possível fazer o planejamento de liberação com metodologias ágeis, mas os planos geralmente se baseiam em uma estimativa do número de iterações necessárias para atingir uma meta, em vez das metas de gerenciamento definidas pelo decreto. Isso não quer dizer que as datas de entrega não possam ser definidas ou que as metas não possam ser cumpridas, mas a maneira como elas são definidas e cumpridas é bem diferente das metodologias tradicionais de gerenciamento de projetos.

Pense em caixas de tempo, não em prazos

No entanto, todos os projetos em que já participei insistiram em estabelecer um prazo. Dado que o Agile tenta se concentrar no planejamento adaptativo, flexibilidade e mudança; os prazos são ágeis?

Esse é um mal-entendido comum dos princípios ágeis. Estruturas ágeis como Scrum e Kanban não se concentram em prazos, mas em prazos e uma cadência sustentável de entrega.

No Scrum, por exemplo, o Sprint não é um "prazo". É um período que é preenchido com a quantidade de trabalho que a equipe estima caber no período sem excedê-lo e, em seguida, é "concluído" ou "não concluído" quando o período expirar. Uma vez fora, a caixa de tempo se foi para sempre; qualquer trabalho que não seja realizado deve ser re-planejado e re-estimado dentro de um novo prazo igualmente efêmero, com base nas necessidades atuais (e não históricas) do projeto.

A importância do cronograma é que ele cria uma cadência previsível para as partes interessadas revisarem o progresso e um ritmo sustentável para a equipe na qual fornece incrementos de valor potencialmente entregáveis . O trabalho é incremental e segue a cadência; o conceito de um grande prazo inicial não está, portanto, de acordo com os princípios ágeis.

Planejamento de liberação com base em tempos

Talvez a única área em que as pessoas tenham mais dificuldade em mapear processos ágeis para estruturas tradicionais esteja no planejamento de liberação. O planejamento de liberação geralmente envolve entregas com escopo fixo ou data fixa. Em estruturas ágeis, o planejamento de liberação geralmente é feito por meio de um processo de estimativa em que o escopo é explicitamente definido como uma variável mutável, enquanto as datas de liberação são estimadas em iterações.

Por exemplo, um projeto pode estar comprometido em liberar a versão 1.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 o escopo, os recursos e as prioridades podem mudar no início de cada Sprint), mas as datas de destino para cada release são fixadas no plano do projeto. A equipe se esforça para oferecer um incremento potencialmente entregável a cada Sprint, e a Definição de Concluído inclui verificações de qualidade, como 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, à medida que o escopo de cada iteração se ajusta, muda ou se adapta às necessidades em evolução do projeto. . 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

• Como executar o planejamento de liberação ágil

Pense nos prazos como compromisso. O fato de o projeto ser ágil não significa que você não deve se comprometer a fornecer determinados recursos para uma determinada data.

O que a agilidade traz é o que acontece no meio. Em vez de ter um documento rigoroso de especificação de requisitos de software, que define que você deve entregar o recurso A composto pelos sub-recursos B, C, D e E por uma data determinada, compromete-se a fornecer o recurso A por uma data determinada, considerando que no No estágio inicial, nem você nem seu cliente sabem como será o recurso, ou teriam os sub-recursos B, C, D e E ou talvez B e C, ou uma dúzia de outros sub-recursos.

Imagine uma empresa que anteriormente entregava mercadorias apenas para pequenas empresas e acabou de assinar um contrato com uma grande corporação. Esta grande corporação usa EDIFACT e parece que o software de contabilidade atual usado por sua empresa não lida com EDIFACT. Você está convidado a criar um plugin que faz isso, dado que contratualmente, a sua empresa deve estar pronto para 15 de abril ^th .

A agilidade significaria que as etapas intermediárias serão entregues progressivamente e serão baseadas em feedback regular. Basicamente, você mostrará seu progresso aos contadores, e eles dirão o que pensam sobre isso, quais são os possíveis problemas etc. Isso também significa que, talvez originalmente, os contadores tivessem uma ótima idéia que, eles pensavam, poderia melhorar substancialmente a experiência do usuário. Três semanas depois, parecia que não apenas não o aprimora muito, mas também resultará em um mês de desenvolvimento adicional. Graças ao Agile, você pode redirecionar seus esforços desse recurso para outra coisa, garantindo a entrega pontual.

Você também deve entender o ponto de vista do cliente:

• Muitas vezes, as empresas precisam de uma data de entrega específica. Por exemplo, você não pode fornecer o serviço de streaming on-line de jogos olímpicos após o final dos jogos olímpicos. Em termos de negócios, isso é simplesmente um fracasso, com enormes consequências negativas.

• Sem ter um compromisso, é tentador para um desenvolvedor ou subcontratado ser perfeccionista ou tornar o projeto com baixa prioridade. Embora a regularidade dos sprints ajude, isso não impede totalmente esse risco.

  Não gosto de prazos para isso, principalmente porque os prazos ocorrem com muita facilidade, mas ainda entendo por que muitas empresas fazem isso. Nem sempre é fácil ver que o projeto está atrasado, observando apenas os sprints: um prazo não cumprido, nesse contexto, pode ser um lembrete claro de que algo sai de controle e deve ser tratado agora.

A programação do eXtreme afirma sobre o planejamento de lançamento:

A filosofia básica do planejamento de liberação é que um projeto possa ser quantificado por quatro variáveis: escopo, recursos, tempo e qualidade.

O que parece justo. Também afirma que

Ninguém pode controlar todas as 4 variáveis. Quando você muda um, inadvertidamente, faz com que outro mude em resposta. Observe que a redução da qualidade para menos do que excelente tem um impacto imprevisto nas outras 3 variáveis

E como já observado pelo br3w5 , o aumento de recursos é uma solução limitada. Você provavelmente pode adicionar algumas pessoas que já faziam parte da equipe se elas foram enviadas para outra coisa. Mas você não pode simplesmente aumentar o tamanho da equipe de forma rápida e indefinida, pelo menos não sem a reorganização da equipe, que leva muitas vezes.

Portanto, com qualidade irredutível e recursos fixos: um prazo é uma restrição de tempo, significa que você precisa adaptar o escopo. E o uso da agilidade fornece o meio para cumprir o prazo com o escopo mais produtivo possível. No entanto, você geralmente pode garantir que parte do escopo seja concluída a tempo. Esta é a parte em que você pode estimar com confiança seu tempo a ser limitado abaixo do prazo. Normalmente, algo realmente próximo ao que você fez várias vezes e pouco conhecido.

O objetivo dos métodos de desenvolvimento de software, quando entendidos corretamente, é tornar-nos mais produtivos, concentrando nossos pensamentos e fornecer uma linguagem comum para situações típicas. É sobre inspiração e capacitação, não sobre controle e culpa da mente.

Seguir um método de desenvolvimento de software literalmente sem compromissos corresponde ao que é chamado radicalismo ou fundamentalismo em outros contextos. A forma pura dessa aberração é raramente vista na prática, porque geralmente leva ao rápido fracasso no mercado. Mas é claro que quando os desenvolvedores competem na difícil tarefa de implementar um método específico, ultrapassar a marca é uma ocorrência natural.

O problema é exacerbado pelo fato de que missionários e evangelistas visam principalmente aqueles que ainda precisam convencer a usar o método; e mesmo se eles pregam moderação, a natureza humana garante que receba menos atenção.

Os prazos não são ágeis, são eles:

1) Cachoeira e 2) Errado.

Software e prazos não funcionam bem juntos e nunca funcionaram. De várias maneiras, os métodos Agile são uma reação ao enorme problema de prazos ou softwares perdidos que foram abandonados quando ficou claro que o prazo não podia ser cumprido (assim como também as questões orçamentárias).

O Agile tenta injetar realidade na situação dizendo "Você sabe que o prazo ou os recursos vão escorregar e / ou mudar, nós sabemos, então vamos seguir com o pé direito e nem fingir".

A chave é que o prazo se torne simplesmente uma data de lançamento para a primeira versão do software. Isso ainda pode estar escrito em pedra - digamos, o software é para uso acadêmico e DEVE ser utilizável no início do semestre - mas o que você entregará não é. Você tem um produto mínimo viável que todo mundo tem certeza de que pode ser entregue até então e tem uma carga de "gostaria de ter". Em vez de todos levantarem as mãos quando se verificar que a lista inteira não será entregue dentro do "prazo", certifique-se de colocar o MVP na porta e o maior número de "gostaria de ter" como possível e, em seguida, avalie o custo / benefício do restante nesse ponto.

Quem joga jogos de computador por um período de tempo sabe exatamente como isso funciona! Se o primeiro lançamento atingir os padrões beta, muitos jogadores ficam felizes, então são baixas as expectativas do que "prazos reais e firmes" significam na vida real.

Portanto, os prazos não são ágeis, são remanescentes dos dias em que as pessoas pensavam que o software poderia ser tratado como hardware e engenharia de aço. Aprendemos que isso não é possível nem desejável, pois descarta a maior vantagem do software sobre o hardware: é flexível.

O Agile tenta explorar essa suavidade, permitindo que as metas se desenvolvam e mudem ao longo do projeto de uma maneira que um design de ponte nunca poderia.

Responda "provavelmente não"

O Project_management_triangle afirma que custo, tempo e escopo (e também qualidade) dependem um do outro. ("escolha dois e obtenha o terceiro")

Um sprint de scrum escolhe tempo fixo (ou seja, 7 dias = duração do sprint) e custo (ou seja, orçamento para 7 membros da equipe) e estima o escopo (o número de histórias a serem feitas no sprint)

Se a gerência ou o departamento de vendas tentar definir os três (custo, tempo e escopo), não será ágil no sentido de scrum, porque a equipe não pode prometer atingir a meta (sem violar a qualidade = definição de conclusão)

A gerência profissional tenta definir custo e tempo e reduzir o escopo, se necessário, se houver uma data fixa a ser cumprida.

Isso não pode ser respondido de maneira simples e direta?

Não há prazos não ágeis.

O ponto principal é criar o que você puder de maneira iterativa, aprendendo e se adaptando à medida que avança.

Um prazo final é "você precisa entregar x por y", que falha em ambas as contagens, pois promete um produto fixo em uma escala de tempo pré-determinada (onde o ágil diz que não temos certeza do que estamos tentando entregar e o aprendizado do ágil nos ensina que, mesmo sabendo que é muito difícil ter certeza sobre as escalas de tempo - ou se é um problema resolvido e que não deveríamos fazê-lo de qualquer maneira).

Tendo estabelecido que a resposta para a pergunta é "Não, os prazos não são ágeis" - então podemos ter uma conversa interessante que aborda a questão de "como lidamos com os prazos em um contexto ágil" e há muitas coisas boas pensando nisso nas outras respostas.

Na minha opinião, uma resposta razoável para esse último é que entregaremos incrementos de valor cedo e freqüentemente e veremos onde estamos no devido tempo - mas não existe um tamanho único para todos.

O grau de agilidade exigido no trabalho de uma pessoa é inversamente proporcional à sua posição no organograma.

"Ágil" é bom, pelo que é. "Agile" significa "mente aberta e competência suficiente". São os grunhidos na parte inferior que devem ser os mais ágeis.

Se, nos níveis gerenciais, o chefe de cabelos pontudos era ágil o suficiente para entender que adiar um prazo por semana resultaria em um produto melhor ou em um código mais limpo, sem bugs e mais aproveitável, para que a empresa ( ou a divisão) economiza duas semanas no futuro, esse é um prazo ágil.

Mas, como o interesse próprio esclarecido, ele realmente não existe.