Os prazos são ágeis?

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

Work expands so as to fill the time available for its completion.

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

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

• Garantir que todos possam ver quanto trabalho será realizado até o prazo
• Verifique se os recursos mais importantes foram concluídos primeiro
• Assegure-se de 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 a um ritmo sustentável

Dessa forma, quando o dia inevitável chegar, você não terá uma pilha inútil de código, mas um produto testado e em funcionamento, com a esperança de que apenas a coisa menos importante esteja inacabada. E ninguém é surpreendido pelo produto acabado.

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.

We need the software by Comdex

ou

The games must be on store shelves by Black Friday

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

O objetivo que o Agile tem é que as coisas que não cumprem o prazo falham mais rápido (e isso é uma coisa boa), ou o escopo pode ser reexaminado mais cedo para que os recursos possam ser focados no correto ROI de maneira mais oportuna.

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

A transparência que o Agile procura é a de mostrar os problemas e progredir no início do ciclo. A falha clássica na entrega em cascata é aquela em que você passou meses atrás de portas fechadas e entregou o produto uma semana antes do prazo final e foi informado de que está fazendo tudo errado e que você perdeu meses (e agora o prazo final foi completamente errado) . A outra falha clássica da cachoeira é descobrir uma semana antes do prazo que você ainda tem meses para ir. Ágil procura tornar essas questões conhecidas no início do processo.

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

Ok, we missed having everything we want for the tax software to be deployed on April 15th, but we've got 75% and what we do have works and has been working since we started last November. We've known we are not going to be able to deploy the full feature set since mid December and refocused our efforts on the 80% of the customer base.

Alguns prazos devem ser cumpridos. Obrigações contratuais, convenções, requisitos regulamentares. Alguns são impostos por gerentes que querem colocar o desenvolvimento de software no mesmo gráfico que o de fabricação em sua planilha. Seja qual for a causa, a maioria das pessoas não consegue se afastar delas.

Se você está trabalhando em uma equipe funcional, 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 com o desenvolvimento é mais importante.

Mesmo que você esteja entregando histórias de usuários completas uma vez por semana ou duas vezes por mês, provavelmente ainda terá prazos finais. Quando um estiver chegando, certifique-se de que seus stakeholders saibam o que você acha que vai se encaixar no prazo e defina as expectativas.

Se você está constantemente construindo o melhor software possível com os requisitos que você tem atualmente em cada estágio, então um prazo final no final de qualquer sprint não deveria, teoricamente, ser um problema. Na prática, esse normalmente não é o caso, mas nem os prazos que surgem do nada. Os prazos mais importantes que já recebi foram-me comunicados muito antes, era a expectativa da qualidade e das características que constituíam a questão.

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

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

"Only the Sith deal in absolutes"

É 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 software de rastreamento eleitoral. Se o software não estiver pronto a tempo para a 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 demais. Eu sei que este software que você está nos pagando é completamente inútil, mas os prazos não são ágeis, então como você pode realmente se opor a nós por não encontrá-los? '

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

Se a data de entrega for mantida constante, algum outro aspecto se torna uma variável. Como todos sabemos, pode haver uma grande incerteza em projetos de software. Algo tem que ser feito variável em resposta a esta incerteza se você quiser sucesso em seu projeto, e geralmente essa é a data de entrega. Parece natural o suficiente, de qualquer maneira. Mas essa não é sua única opção. Se você está preso a um prazo difícil, a maneira de lidar com isso é tornar variáveis suas características entregues. 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 uma maior probabilidade de serem enviados. Então, é como de costume, apenas quando o prazo final gira em torno de você enviar o que estiver pronto para ser enviado. Neste modelo, o envio de mais recursos é o análogo ao envio em uma data anterior, e o envio de menos recursos é o análogo de envio em uma data posterior.

Se alguém quiser definir um prazo, tudo bem e o prazo pode ser corrigido, mas o que eles devem entender é que, se o prazo for fixo, o escopo deve permanecer flexível.

tl; dr

Em um mundo ideal, não teríamos prazos e apenas entregaríamos as coisas quando estivessem prontos. A realidade, porém, é que as pessoas que pagam por coisas geralmente querem saber quando são feitas. 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ê fixar um prazo e escopo (e orçamento), então as coisas se apressam e você acaba de volta no mundo antigo da cachoeira com um tempo de crise louco 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), que quanto mais pessoas você adicionar (cada com suas próprias fraquezas) quanto mais tempo demora.

Agora, normalmente (a menos que eles realmente entendam os métodos ágeis) a pessoa que paga pelo software não gosta de ser informada, 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 de priorização pode ser assim:

Dev Team (D): "Please can you prioritise the features you want delivered, with most important first?"

Customer (C): "Everything is priority 1 - I want them all done by the end of next month."

D: "That may be possible, but that may not be possible if requirements change or we discover issues we didn't expect while going through development."

C: "Well what if I give you more money?"

D: "sigh...even with more resource it's going to take them one month to really get going; so if you're not sure how to prioritise the features just tell us which ones you want done first."

C: "Ok I want the big button but make it really big, and then ...etc"

Agora você pode começar a trabalhar nos recursos em ordem de prioridade. Ajuda também olhar para a frente com sua equipe para os itens mais baixos na ordem de prioridade e fazer algumas estimativas antecipadas, sabendo que você pode alterá-las quando chegar ao desenvolvimento, quando tiver mais informações. Isso pode ser usado para redefinir ou criar seu roteiro se você ainda não tiver um. 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 coisas a serem entregues.

Uma das grandes vantagens do Agile é que ele reconhece que as coisas mudam à medida que você avança no desenvolvimento e ajusta-se conforme elas acontecem. Ao contrário das abordagens mais tradicionais, este princípio, em conjunto com as entregas de sprint regulares e 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 que ele não consiga o que deseja até uma certa data, mas eles entenderão por que e o que receberão será de boa qualidade. E 6 meses após os recursos serem entregues, o cliente não se importará ou lembrará que você entregou até uma determinada data, eles se lembrarão da qualidade do produto que ainda estão usando.

Os prazos são tradicionalmente baseados no ciclo de vida do negócio. O software tributário precisa estar em 15 de abril. Relatórios para o próximo ano fiscal podem precisar ser feitos até julho.

O manifesto Agile afirma:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

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. O ágil nos permite saber se a nossa velocidade não nos permitirá fazer um prazo sem que um recurso seja cortado. Também nos permite saber se precisamos contratar para fazer um prazo. E, em alguns casos, nos permite saber que um prazo é impossível, quando não há recursos para cortar.

A melhor coisa que uma equipe Agile pode fazer é deixar que sua velocidade e backlog priorizado atinjam os prazos. Isso dará datas de entrega estimadas. Se esses estiverem fora do prazo, é hora de uma conversa séria com o cliente e determinar se o prazo é viável.

Eu diria que a entrega de cada sprint é inegociável. Você avalia o trabalho, coloca tamanhos de cartão nele e carrega o suficiente para manter sua equipe ocupada até que o sprint termine (e o sprint deve ser pequeno - qualquer coisa 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 antecipado. O Agile adiciona / remove nada da antiga idéia de restrição "custo / tempo / escopo", ele simplesmente usa o escopo como o método preferencial de gerenciar o escorregão com base em que uma melhor priorização contra escopo é geralmente preferível a gastar mais dinheiro ou tempo.

Algumas pessoas parecem confundir ágil para "oeste selvagem". Ágil não significa nada vale. Ágil significa que paramos de mentir para nós mesmos sobre o quão bem uma pessoa razoável pode estimar. Basicamente, podemos estimar o desenvolvimento de software de 2 a 4 semanas no futuro. Além disso, são todos os graus variados de grinaldas e palpites. Pior ainda, o custo de fornecer estimativas para as coisas mais e mais para o futuro aproxima-se do custo de apenas fazer o trabalho. Por qualquer motivo, os gerentes de projeto historicamente não estão dispostos a admitir essas verdades absolutas aos clientes. Agile simplesmente ajusta esse pensamento afirmando que há um limite para o quão bem podemos prever o futuro na engenharia de software, e faz uma sutil mudança para a "estimativa baseada em evidência" para previsão de longo prazo. Dando entregas certas em pequenos pedaços, e entregas baseadas em evidências para coisas de longo prazo, nós temos algo próximo do melhor dos dois mundos - nós conseguimos ser verdadeiros sobre o que nós realmente somos capazes de estimar e podemos fornecer estimativas razoavelmente razoáveis de entrega futura a longo prazo com base no que temos fornecido até agora.

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

• Como executar o planejamento ágil de versões

Pense nos prazos como compromisso. O fato de o projeto ser ágil não significa que você não deva 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 de especificação estrita de requisitos de software que defina que você deve entregar o recurso A composto pelas sub-características B, C, D e E para uma determinada data, você se compromete a entregar o recurso A para uma determinada data, dado que 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 já entregou mercadorias apenas para pequenas empresas e acaba de assinar um contrato com uma grande corporação. Essa grande corporação usa o EDIFACT e parece que o software de contabilidade atual usado pela sua empresa não controla o EDIFACT. Você é solicitado a criar um plugin que faz isso, dado que, contratualmente, sua empresa deve estar pronta para o dia 15 de abril .

A agilidade significaria que as etapas intermediárias serão entregues progressivamente e baseadas em feedback regular. Basicamente, você mostrará seu progresso para os contadores, e eles dirão o que pensam sobre o assunto, quais são os possíveis problemas, etc. Isso também significa que, talvez originalmente, os contadores tiveram uma ótima ideia que, eles pensaram, poderia melhorar. substancialmente a experiência do usuário. Três semanas depois, parece que não só não melhora 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 no prazo.

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

• Geralmente, as empresas precisam de uma data de entrega específica. Por exemplo, você não pode entregar o serviço de streaming online dos 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 de baixa prioridade. Embora a regularidade dos sprints ajude, isso não impede totalmente esse risco.

  Eu não gosto de prazos para isso, especialmente porque os prazos finais acontecem muito facilmente, mas eu ainda entendo porque muitas empresas fazem isso. Nem sempre é fácil ver que o projeto está atrasado, olhando apenas para os sprints: um prazo perdido, neste contexto, pode ser um claro lembrete de que algo sai de controle e deve ser resolvido agora. / p>

eXtreme Programming fala sobre o planejamento de lançamentos:

The base philosophy of release planning is that a project may be quantified by four variables: scope, resources, time, and quality.

O que parece justo. Afirma também que

No one can control all 4 variables. When you change one you inadvertently cause another to change in response. Note that lowering quality to any less than excellent has unforeseen impact on the other 3 variables

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

Portanto, com qualidade irredutível e recursos fixos: um prazo sendo uma restrição de tempo, isso significa que você precisa adaptar o escopo. E usar a agilidade dá a você a média para cumprir o prazo com o escopo mais produtivo possível. No entanto, você geralmente pode garantir que alguma parte do escopo será feita a tempo. Esta é a parte que você pode estimar com confiança seu tempo para ser limitado abaixo do prazo. Normalmente, algo que é realmente próximo do que você fez várias vezes e tem pouco conhecimento.

O propósito dos métodos de desenvolvimento de software, quando entendido corretamente, é tornar-nos mais produtivos focalizando nossos pensamentos e fornecer uma linguagem comum para situações típicas. É sobre inspiração e habilitação, não sobre controle mental e culpa.

Seguir um método de desenvolvimento de software literalmente, sem compromissos, corresponde ao que é chamado radicalismo ou fundamentalismo em outros contextos. A forma pura desta aberração é raramente vista na prática, porque normalmente leva a uma falha rápida 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 os missionários e evangelistas visam principalmente aqueles que ainda precisam ser convencidos a usar o método; e mesmo se eles pregam moderação, a natureza humana garante que recebe menos atenção.

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

1) Cachoeira e 2) Errado.

Software e prazos não funcionam bem juntos e nunca funcionam. De muitas maneiras, os métodos Ágeis são uma reação ao problema maciço de prazos perdidos ou software que foi abandonado quando ficou claro que o prazo não poderia ser atendido (bem como questões orçamentárias também).

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 disso, então vamos sair 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 pode ainda ser escrito em pedra - digamos, o software é para uso acadêmico e deve ser utilizável até o início do prazo - mas o que você vai entregar não é. Você tem um produto mínimo viável que todo mundo tem certeza que pode ser entregue até então, e você tem uma carga de "gostaria de haves". Em vez de todos jogarem as mãos para cima quando a lista inteira não for entregue no "prazo", você se certifica de tirar o MVP da porta e quantos dos "gostariam de ter" como possível e, em seguida, avaliar o custo / benefício do restante nesse ponto.

Qualquer um que jogou jogos de computador por um longo período de tempo sabe exatamente como isso funciona! Se o primeiro lançamento for de acordo com os padrões beta, muitos jogadores estão felizes, tão baixas são as expectativas do que significam "prazos reais e firmes" na vida real.

Assim, os prazos não são ágeis, eles 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 é nem possível nem desejável, pois elimina a maior vantagem que o software tem sobre o hardware: ele é flexível.

O Agile tenta explorar essa suavidade permitindo que os objetivos se desenvolvam e mudem ao longo do projeto de uma forma que o design de uma 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 scrum sprint 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 o departamento de gerenciamento ou vendas tentar definir todos os três (custo, tempo e escopo), então não é ágil no sentido de scrum porque a equipe não pode prometer alcançar o objetivo (sem violar qualidade = definição de feito)

O gerenciamento profissional tenta definir o custo e o tempo e reduz o escopo, se necessário, se houver alguma data fixa a ser cumprida.

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

Nenhum prazo não é ágil.

O objetivo é construir o que você pode de uma forma iterativa, aprendendo e se adaptando à medida que avança.

Um prazo final é "você tem que entregar x por y", o que falha em ambas as contas em que você está prometendo uma entrega fixa em uma escala de tempo predeterminada (onde ágil diz que não temos certeza do que estamos tentando entregar, e o aprendizado de ágil nos ensina que, mesmo que saibamos que é muito difícil ter certeza sobre escalas de tempo - ou se é um problema resolvido e não deveríamos estar fazendo isso 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 abordar prazos em um contexto ágil" e há uma muito bom pensar sobre isso nas outras respostas.

Na minha opinião, uma resposta razoável para o último é que vamos entregar incrementos de valor cedo e frequentemente e vamos ver onde estamos no devido tempo - mas não há um tamanho único para todos.

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

"Ágil" é bom, pelo que é. "Agile" sorta significa "mente aberta associada a competência suficiente". São os grunhidos no fundo que têm que ser os mais ágeis.

Se, em nível gerencial, o chefe de cabelo pontudo era ágil o suficiente para entender que empurrar um prazo de uma semana para um produto melhor, ou criar um código mais limpo, mais livre de erros e mais alavancável, a empresa (ou a divisão) economiza duas semanas no futuro, esse é um prazo ágil.

Mas como o autointeresse esclarecido, não existe realmente.