Os prazos são ágeis?

100

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.

stevebot
fonte
36
Não é como sprint um prazo?
JeffO 23/02
12
@JeffO a Sprint é um compromisso, que muda com base na velocidade da sua equipe. Os prazos são IMO, compromissos sem honestidade ou transparência para o cliente. Eles não levam em consideração a velocidade ou a multiplicidade de outros riscos envolvidos na criação de projetos de software.
Stevebot
8
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.
Calphool
8
Aqui está Ron Jeffries (um dos autores originais do Manifesto Ágil) assume prazos: xprogramming.com/articles/jatmakingthedate
Jules
4
Alguns dos meus prazos se mostraram bastante ágeis.
psr

Respostas:

147

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.

Eric King
fonte
10
@ stevebot Essa é exatamente a situação que leva à lei de Parkinson. Eu nunca conheci um cliente que não consiga pensar em mais recursos para adicionar. Sem prazos, a lista de recursos e, portanto, o projeto, é infinita.
Eric King
12
@ stevebot Acho que nos entendemos, mas temos diferentes significados para a palavra "prazo". Para mim, um "prazo" é uma data específica. Para você, um "prazo" é um conjunto específico de recursos prometidos em uma data específica. Acredito que minha definição é o uso mais comum e minha resposta é baseada nessa definição. A julgar pelas outras respostas que você recebeu, outras pessoas concordam comigo. Aceite o que quiser, não ficarei ofendido. :-) Mas minha resposta ainda permanece.
Eric King
5
"Sempre haverá expectativas e é sempre possível que a velocidade de suas equipes faça com que você perca os recursos mais básicos". Se você está implementando o ágil corretamente, essa afirmação é um absurdo. Seu backlog DEVE ser priorizado de acordo com o valor máximo do cliente. Se não for, POR QUALQUER MOTIVO , então você não está praticando ágil. Você está praticando outra coisa.
Calphool
7
"Temos que enviar algo até 28 de julho". O prazo desta sentença é 28 de julho. Você pode fazer com que "algo" seja um conjunto pré-determinado de requisitos ou pode estar pronto. A parte "algo" não é o prazo final. A data é o prazo final.
Eric King
5
@stevebot "(A resposta) induz o leitor a acreditar que Agile + Prazos = perfeitamente bem." Esse é o ponto, no entanto. Agile está perfeitamente bem com prazos. Ou sem. Faça sua escolha. Dizer o contrário é basicamente dizer "Bem, como temos um prazo, não podemos fazer esse projeto com agilidade!" o que é bobagem. Já trabalhei em muitos projetos que tiveram prazos e foram "ágeis". Os prazos são ágeis? Bem, eles não são nem ágeis.
Eric King
24

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.


fonte
2
Eu concordo com você, embora eu revire a importância de suas duas afirmações. # 1 O Agile é focado principalmente em garantir que a versão atual do software seja útil e implementável. # 2 Secundariamente, ele nos ajuda a perceber quando o escopo é completamente irracional anteriormente, para que os proprietários do produto possam priorizar e manter a meta nº 1.
Calphool
2
@ user40980 Isso é horrível. Sim, há coisas que têm uma data firme. no entanto, você não pode produzir uma quantidade infinita de trabalho em um período finito de tempo. Os prazos não podem ser ágeis, exceto quando são produzidos somente após a estimativa. Essa é uma ressalva extremamente importante. É por isso que você planeja um sprint - para determinar exatamente qual trabalho pode ser concluído. Um prazo fixo e rígido, no qual tudo deve estar completo, apesar do esforço, NUNCA será Ágil.
EKW
18

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.

Encaitar
fonte
13

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,

Cães
fonte
11

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.

br3w5
fonte
7
"Então, se alguém quer estabelecer um prazo, então está bem e o prazo pode ser fixado, mas o que eles precisam entender é que, se o prazo for fixado, o escopo deve permanecer flexível". Absolutamente.
Eric King
Esta é provavelmente a resposta mais ágil aqui. O fato de não ter muitos votos é prova de quão ágil é incompreendido.
PostCodeism
10

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.

stevebot
fonte
1
Às vezes, você deve enviar até uma data determinada e não negociável (um prazo). Nesse caso, a melhor coisa que uma equipe do Agile pode fazer é deixar o prazo aumentar sua lista de pendências, fornecendo os recursos estimados no prazo. Se esse conjunto de recursos estimado não atender aos requisitos do cliente, é hora de conversar seriamente com o cliente e determinar se o projeto é viável.
Eric King
@ EricKing, sim, você está certo, o Agile pode trabalhar com prazos, acho que tenho lido suas declarações como "prazos são ágeis" em vez de "Agile trabalha com prazos".
24515 stevebot
Obrigado por seu comentário. Eu acho que nós dois estamos conversando um com o outro há um tempo, e talvez seja preciso apenas uma certa frase para fazer as coisas clicarem. Eu não quis dizer "negócios são ágeis", mas posso ver como isso aconteceria. Me desculpe por isso.
Eric King
6

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.

Calphool
fonte
BTW, Cal, eu praticamente concordo com tudo o que você está dizendo aqui. e eu não acho que isso contradiga o que escrevi.
Robert Bristow-johnson
5

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

CodeGnome
fonte
... mais ou menos ... mas, com o tempo, é melhor que a equipe se concentre em fazer com que a montagem do trabalho caiba bem nessas "caixas de tempo". Se você simplesmente aceitar que suas caixas de horário e trabalho concluídos não são relacionados, está fazendo a codificação de cowboys e isso é completamente imprevisível. Eu diria que talvez ele comece como "caixas de tempo" e, com o tempo, se torne um prazo um tanto inegociável, pois a equipe fica melhor em prever quanto trabalho eles podem lidar em um sprint. Trata-se de um autotreinamento da equipe para se tornar excelente na estimativa de curto prazo, porque é daí que a previsibilidade vem.
Calphool
4

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.

Arseni Mourzenko
fonte
Obrigado, mas por que a regularidade dos sprints não impede totalmente esse risco? Além disso, gosto do seu exemplo dos Jogos Olímpicos, mas acho que um requisito é esse escopo e custo, e não vinculados. Se eu colocasse um desenvolvedor nesse projeto e fosse obrigado a fornecer todos os recursos, o prazo realmente não ajudaria e provavelmente nos levaria a entregar um produto de qualidade muito baixa.
23415 stevebot
A regularidade dos sprints não impede o risco, porque é relativamente fácil para um gerente enganar as partes interessadas a pensar que o projeto está indo bem. Coisas como "Não implementamos isso porque você enfatizou essas duas coisas durante a nossa última reunião". Ou "Dois de nossos desenvolvedores estão de férias, então fizemos apenas metade do trabalho durante este sprint". são difíceis de discutir para as partes interessadas e, em todos os detalhes do sprint, elas podem perder a visão geral do projeto.
Arseni Mourzenko
então você tem um problema de transparência e colocar um prazo no topo não ajuda. Essas desculpas também serão facilmente lançadas no prazo e isso é quase sempre o que vejo acontecer na vida real.
23615 stevebot
1

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.

Juh_
fonte
0

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.


fonte
-1

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.

Nagora
fonte
3
Eu não tenho idéia de por que as pessoas votaram contra você. Venho desenvolvendo aplicativos ágeis / xp há mais de 10 anos em uma empresa da Fortune 100 - introduzi-o aqui por uma questão de fato e não vejo absolutamente nada de errado com o que você disse. Eu votei você de volta para zero, porque quem quer que te tenha menos votado tem que ser uma novidade ágil, ainda apegada à antiga realidade deles, pois Deus sabe qual o motivo. As pessoas são muito simplistas. Eles acham que "software e prazos não funcionam bem juntos" é um absoluto. Você pretende atingir CADA prazo de sprint. Você simplesmente não mente sobre sua capacidade de atingir datas estimadas a longo prazo. É simples assim.
Calphool
7
@ Calphool Eu tenho problemas em dizer que os prazos são em cascata (eles existem, não importa qual metodologia seja usada - eles até existem para codificadores de cowboys) e estão errados (eles existem devido a restrições externas de tempo - nada mais errado do que "nós temos que ter isso"). código executado nesse hardware com desempenho mínimo "). É uma restrição de tempo sobre o que é uma solução aceitável. A apresentação de impostos até 15 de abril é um prazo. Ter o software no distribuidor até 1º de novembro para que ele possa estar nas prateleiras até 27 de novembro é um prazo. Nenhum destes está errado.
4
@ MichaelT: Se você ainda não o fez, sugiro que você leia o livro de Tom & Mary Poppendiecks "Líder em desenvolvimento de software enxuto: resultados não são o ponto". Ele está simplesmente transmitindo um meme bastante popular em círculos magros / ágeis. Se você e sua equipe estão focando nos prazos mais do que na melhoria contínua, não está realmente vivendo com agilidade. Você pode estar fazendo scrum, mas não vivendo ágil. Existem prazos de longo prazo? Obviamente. Eles são o que as equipes ágeis devem focar? Absolutamente não. Os prazos são incidentais ao pensamento ágil.
Calphool
4
@MichaelT O OP se refere aos prazos do projeto e é a isso que estou respondendo - prazos de longo prazo estabelecidos por um gerente de projetos no início de um projeto, em vez de um sprint. Certamente, existem prazos de uma espécie em ágil, mas eles têm uma natureza muito diferente do que as pessoas normalmente querem dizer com prazos de projeto, mas talvez seja apenas a semântica que seja o problema aqui.
Nagora
3
@ Ellesedil: diga-me o seu recurso mais importante, ou o seu conjunto mínimo de recursos comercializáveis, deixe-me de algumas semanas a alguns meses para criar um histórico com base no conjunto de recursos desejado (varia dependendo de quanto você está solicitando - leva mais tempo para prever quanto tempo levará para chegar à lua vs. Pittsburgh). Então eu direi a você e, como minha estimativa foi construída com base em entregas reais de software útil , poderemos nos basear na estimativa, ao contrário do conto de fadas que você está me forçando a lhe dar desde o início.
Calphool
-1

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.

k3b
fonte
-1

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.

Murph
fonte
-2

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.

Robert Bristow-Johnson
fonte
5
Um prazo que pode ser movido não é um prazo. Isso é chamado de data do calendário. Prazos são coisas como Black Friday - ou está na loja ou não. Ainda assim, Agile significa que tenho o melhor que posso ter até esse prazo.
MSalters 24/02
então, se ele não cumprir esse prazo, mas estiver na loja na semana seguinte, o fabricante sempre morre? perder esse prazo implica custos. mas e se esse custo for mais do que compensado com um produto melhor, que impressiona mais os clientes com a primeira impressão ( "você nunca tem uma segunda chance de causar uma primeira impressão" ) e tem outros benefícios que excedem esse custo? se a gerência é inteligente o suficiente para tomar uma decisão tática para adiar a liberação (está cumprindo o prazo, não diminuindo) para o benefício de clientes e fabricantes, não é "ágil"?
22815 Robert Bristow-Johnson
Você já teve prazos de Black Friday com o Walmart? A sensação que tive foi que, se você estragou tudo este ano, não terá uma segunda chance no próximo ano. Isso é literalmente "sem segunda chance".
MSalters 24/02
3
ouça o código na área de instrumentos de áudio e música. certamente o produto precisa sair pela porta para ganhar dinheiro com ele. mas os prazos literalmente fizeram com que algumas porcarias mal desenvolvidas saíssem pela porta que os clientes, a empresa e os futuros desenvolvedores foram forçados a conviver por anos depois.
22815 Robert Bristow-Johnson
5
O que acontece com as vendas da Black Friday é que é uma tentativa de marketing criar uma falsa escassez de tempo e produto para fazer com que as pessoas se comportem irracionalmente e comprem coisas que de outra forma não o fariam. Este exemplo de comportamento irracional induzido não parece ser tão diferente de algumas abordagens ao gerenciamento de projetos de software. Ao argumentar que criar faltas escassez de tempo com software não é uma boa idéia, não estou dizendo que escassez real de tempo seja impossível porque elas obviamente estão em alguns contextos (e são cruciais nisso).
shuttle87