Como desenvolver um excelente software com métodos ágeis?

O modelo Kano de satisfação do cliente define diferentes classes de recursos do produto. Entre eles estão

1. Qualidades indispensáveis: se não forem implementadas, o cliente não aceitará o produto.

2. Qualidades atraentes (deliers): recursos que o cliente nem sempre espera em primeiro lugar, mas causa excitação e prazer ao ser descoberto.

Qualidades atraentes obviamente têm muito valor comercial. Eles fazem as pessoas comprarem uma Ferrari por 500.000 quando um Fiat usado por menos de 5.000 atenderia a todos os requisitos obrigatórios.

No entanto, todos os processos ágeis que conheço favorecem fortemente os requisitos obrigatórios. Estes sempre têm a maior prioridade. Nem parece haver um lugar para qualidades atraentes no ágil.

Eu acredito que processos ágeis são muito úteis no desenvolvimento de software. Mas como eles podem ser aplicados para criar deliciosos produtos de software de alta qualidade e não apenas o mínimo que mal atende aos requisitos essenciais?

Adendo: Como as duas primeiras respostas apontaram, faz sentido dar aos requisitos essenciais a maior prioridade. Mas nós (e o cliente) realmente sempre sabemos antecipadamente quais são os requisitos essenciais. Fiz a experiência algumas vezes de que os requisitos que receberam alta prioridade no começo se mostraram muito menos importantes, se não inúteis, posteriormente. Portanto, acredito que não se deva concentrar-se servilmente nos requisitos essenciais.

A resposta formal é que você entendeu mal o ágil, o ágil não determina os requisitos, as partes interessadas o fazem. O núcleo do ágil não é esculpir seus requisitos em pedra, mas sim fazê-los emergir à medida que avança, em contato próximo com seu cliente, beneficiando-se de insights progressivos.

Mas isso é tudo teoria. O que você testemunhou é de fato uma característica comum de muitas linhas de produção de software que adotaram uma maneira ágil de trabalhar.

O problema é que, ouvindo o cliente e respondendo rapidamente às suas necessidades, muitas vezes acaba acabando por não pensar no produto ou fazer qualquer design. O que costumava ser um processo pró-ativo alimentado pela visão e experiência pode e muitas vezes se deteriora, transformando-se em um processo passivo e totalmente reativo, alimentado pelos desejos do cliente. Isso levará a fazer apenas as necessidades básicas que "farão o trabalho".

O automóvel nunca teria sido inventado se os fabricantes da época fossem "ágeis" porque todos os clientes estavam pedindo um cavalo mais rápido.

Isso não torna o ágil ruim. É um pouco como o comunismo. Uma ótima idéia que quase nunca funciona bem porque as pessoas são apenas pessoas, fazendo coisas para as pessoas. E o método / ideologia / religião os leva à idéia de que eles estão indo bem, desde que sigam os movimentos e / ou sigam as regras.

[editar]

Slebetman:

É irônico que o ágil tenha evoluído para fora da indústria automobilística (a Toyota).

Lembra da regra de ouro da automação? "Primeiro organize, depois automatize". Se você automatizar um processo interrompido, o melhor que poderá acontecer é acelerar tudo o que der errado. As pessoas da Toyota não eram idiotas.

A razão típica para a adoção de qualquer nova metodologia é que as coisas não estão indo bem. A gerência reconhece, mas eles podem não entender os problemas principais. Então eles contratam esse guru que faz um discurso resiliente sobre Agile e Scrum. E todo mundo adora. Por suas próprias razões.

Os desenvolvedores podem pensar: "Ei, isso pode funcionar. Estaríamos mais envolvidos com problemas de negócios e poderíamos fornecer informações para preencher essa lista de pendências. Essa poderia ser uma oportunidade para fazer com que vendas e atendimento ao cliente entendam o que fazemos, por que é necessário, e nós os tiraríamos de nossos cabelos enquanto estivermos queimando transparentemente o que combinamos ". Não há mais "pare o que você está fazendo, isso precisa ser feito agora" por um cara que você não quer adiar aparecendo em sua mesa.

Vendas, atendimento ao cliente ou o proprietário, por outro lado, podem vê-lo como uma maneira de obter (voltar) o controle sobre essa caixa preta de um departamento que, presumivelmente, está fazendo as coisas necessárias. Eles não vêem o que está acontecendo lá, mas têm certeza de que o núcleo do problema está enterrado em algum lugar. Então, eles introduzem o Scrum, instalam um proprietário do produto de sua escolha e, de repente, eles têm todo o controle, todas as seqüências de caracteres estão em suas mãos. Agora o que? ... Ehrr ...

O problema real é geralmente que a loja não foi bem organizada em primeiro lugar e isso não mudou. As pessoas receberam responsabilidades de responsabilidade que não podem lidar, ou talvez possam, mas o Sr. Boss está constantemente interferindo e arruinando o que fizeram, ou (na maioria das vezes na minha experiência), responsabilidades cruciais não foram reconhecidas ou atribuídas a ninguém.

Às vezes, com o tempo, uma organização informal surge entre as linhas formais. Isso pode compensar parcialmente a falta de uma estrutura formal. Algumas pessoas acabam fazendo o que são boas, tenham ou não um cartão de visita para provar isso. A introdução franca do Agile / Scrum pode arruinar isso instantaneamente. Porque agora as pessoas devem seguir as regras. Eles acham que o que costumavam fazer não é apreciado, recebem pequenos papéis amarelos com pequenas histórias, a mensagem será: "o que você estava fazendo, ninguém se importava". Escusado será dizer que isso não será particularmente motivador para esses indivíduos. Na melhor das hipóteses, começarão a aguardar pedidos e não tomarão mais nenhuma iniciativa.

Então, as coisas pioram e a conclusão será que o Agile é péssimo.

O Agile não é um saco, é ótimo para projetos de manutenção e pode até ser bom para novos desenvolvimentos se aplicado com cuidado, mas se as pessoas erradas não o entenderem ou o adotarem pelos motivos errados, pode ser muito destrutivo.

Nem parece haver um lugar para qualidades atraentes no ágil.

Você está comparando maçãs e laranjas. Na cachoeira tradicional, se seus requisitos dizem que você precisa dos itens essenciais, você recebe um Fiat. Se os requisitos dizem que precisa ser de primeira, você recebe uma Ferrari.

O mesmo acontece no Agile. Se seus requisitos param em itens obrigatórios, você recebe um Fiat. Se você tem histórias de excelência, recebe uma Ferrari. Tudo o que o ágil realmente impõe é que você faça o que precisa primeiro . Não construa um spoiler super legal por dois anos e depois perca o prazo para o motor.

Tão longa história curta: você obtém o que precisa. Se você planeja um carro esportivo, recebe um carro esportivo. O Agile não muda nada disso. Se o seu processo ágil atender aos requisitos de um Fiat, não culpe o Agile, culpe os caras que precisam apenas de um Fiat.

No entanto, todos os processos ágeis que conheço favorecem fortemente os requisitos obrigatórios. Estes sempre têm a maior prioridade.

Como deveriam - olhe novamente para o seu modelo Kano: se os requisitos essenciais não forem atendidos, o cliente não aceitará o produto. E então seus prazeres não importam.

Nem parece haver um lugar para qualidades atraentes no ágil.

Nada poderia estar mais longe da verdade.

Os processos ágeis geralmente enfatizam estes pontos:

• Entrega frequente de um produto que você pode obter feedback.
• Divida os recursos em partes pequenas que podem ser concluídas em pouco tempo.
• Implemente essas partes em ordem de prioridade.

Nada impede que você dê aos recursos "deliciosos" uma alta prioridade. Depende completamente das pessoas encarregadas de determinar as prioridades.

Agora é verdade que muitas dessas pessoas preferem não correr riscos e, portanto, podem não dar grandes prioridades aos "deliers". Mas em um projeto não-ágil, esse ainda seria o caso.

O Agile não diz nada sobre o que deve ser feito primeiro, apenas esse código deve ser escrito de forma incremental e mantido em um estado liberável o mais rápido possível, em vez de planejado ficar inutilizável por meses até o próximo estado liberável.

Eu trabalhei tanto no processo Agile quanto no BDUF (Big Design Up Front) e, embora você possa definitivamente obter recursos atraentes e inovadores de ambos os processos, no BDUF, sem surpresa, você deve planejar com antecedência. Isso significa que as inovações geralmente precisam ser propostas ou pelo menos patrocinadas por pessoas com influência no processo de design.

Isso ocorre porque você tem seis meses (ou o que for) até o próximo lançamento, e os gerentes de projeto estão estressados ​​com o que está entrando nesse lançamento, porque se o recurso deles não entrar, serão outros seis meses até o próximo . Portanto, há uma lista repleta de recursos em um cronograma repleto de bloqueios, e se o ranking baixo for pego trabalhando por dois ou três dias em algo bacana, eles acham que o cliente vai gostar e não está no mercado. lista, eles arriscam toda a programação e haverá um inferno para pagar.

Em um processo ágil, nos esforçamos para manter o software em um estado liberável, e os gerentes de projeto ficam menos estressados ​​porque, se seu recurso falha, eles podem obtê-lo em duas semanas. Portanto, se um desenvolvedor voltar de uma conferência com uma idéia interessante e passar alguns dias em alguma coisa, ele não estará colocando em risco um cronograma de seis meses por escrito.

Basicamente, você colhe o que planta. Se você incentivar a inovação e oferecer às equipes autonomia suficiente para obter, você a obterá. Se você constantemente exige arestas de corte para cumprir os prazos, o software será compatível, independentemente da sua metodologia.

Um excelente software vem de duas coisas:

• Dar ao cliente o que eles exigem

• Ser profissional

Existem todos os tipos de princípios a serem seguidos ao desenvolver software. SECA, legível, SÓLIDO, etc. que nada têm a ver com os requisitos do cliente. O cliente pediu um carro esportivo. Se o cliente entendesse o que é necessário para tornar um carro esportivo incrível, ele não precisaria de você. Depende de você descobrir o que mais é importante.

Parte do nosso trabalho é manter padrões que o cliente nunca experimenta, a menos que as coisas dêem muito errado.

Se você estiver fazendo o certo, o ágil só tenderá ao decreto quando é isso que o cliente realmente deseja. Não quando é para isso que eles pensam que precisam se contentar.

A cachoeira é diferente porque uma vez que um mal-entendido sobre um requisito de carro esportivo de alto nível se instala, ele tende a permanecer. O Agile pode lidar com novas informações e se adaptar, se elas realmente precisarem ser de uma bicicleta de bala.

A cachoeira ainda está em uso em muitas lojas até hoje. Essas lojas são bem-sucedidas porque seus requisitos mudam menos de 2% em um ano.

Seu trabalho não é apenas dar ao cliente o que ele deseja. É também para cuidar de coisas pelas quais você sabe que não receberá nenhum crédito. Coisas que o cliente nunca mencionará, a menos que você deixe as coisas terrivelmente erradas. É melhor que essas coisas sejam bem escolhidas, ou você precisará de muita merda por perder tempo com elas.

Qualquer idiota pode construir uma ponte com um orçamento ilimitado. Um profissional constrói uma ponte que quase nunca cai.

Portanto, acredito que não se deva concentrar-se servilmente nos requisitos essenciais.

Claro que você deveria. Exceto ao estimar seu tempo. Porque esses requisitos obrigatórios não são a única consideração.

Está bem,

No Agile, o programador pode criar o software, mas no final é o proprietário do produto que cria o produto. (usando os desenvolvedores de software.)

Então, sobre "qualidades atraentes", isso depende do proprietário do produto.

Se o proprietário do produto exigir "design sexy", isso poderá ser um requisito. O desenvolvedor não precisa se preocupar com essas opções.

Além disso, o software é tão diferente dos produtos físicos reais que acho que grande parte do modelo Kano não se aplica. Por exemplo, por que eu facebook? Única razão: porque meus amigos fazem. Como colocar isso no próximo sprint ........ E também, uma das qualidades mais atraentes do software, é que ele realmente faz o que deveria fazer. (E é aí que o ágil ajuda muito: P)

Minha experiência concorda com os comentários acima - não há nada inerente ao Agile que impeça o desenvolvimento de software excelente - no entanto, existem vários aspectos de como o Agile é frequentemente praticado (mal-), o que leva ao software que é apenas "suficientemente bom" . "

• O Agile enfatiza a obtenção de algo que funcione o mais rápido possível; no entanto, isso significa fazer suposições simplificadas e cortar custos, principalmente na infraestrutura não visível ao usuário. Não há nada inerentemente errado nisso, se o custo de corrigir as suposições simplificadoras for baixo; no entanto, com muita freqüência, essa "dívida técnica" não é removida antes que um produto entre em produção;
• O Agile prega que, no final de um sprint, você sempre deve ter algo o mais próximo possível de entregar, para que as partes interessadas e os gerentes de projeto possam decidir que "o que eles têm" é bom o suficiente para impulsionar Produção. Novamente, nada inerentemente errado com isso, sevocê cancelou todas as suas "dívidas técnicas" (ou ficou em paz com o quanto tem e onde está.) No entanto, na minha experiência, muita dívida técnica entra em produção com a promessa de um gerente de que "nós vamos limpá-lo assim que a pressão de enviar for reduzida ", que rapidamente se transforma em" está em produção, temos que ter muito cuidado com o que mudamos agora ", que acaba se transformando em" Você nunca me disse que tivemos essa exposição! Temos que fazer um trabalho melhor da próxima vez! " A lição de Ben Frankin sobre "A amargura da má qualidade permanece muito tempo depois que a doçura do preço baixo é esquecida" parece nunca ser aprendida;
• No entanto, mesmo com os gerentes de confiança e desenvolvedores bem disciplinados, há o problema comum que simplesmente muito pouco adequada análise, design e revisão do projeto ocorre antes do início do sprint em que se espera que a implementação seja iniciada e concluída. O fracasso em considerar cuidadosamente as alternativasAs metáforas e os designs da interface do usuário são grandes - geralmente é muito caro revisar isso significativamente depois que um projeto é iniciado; o fracasso das equipes juniores em estudar cuidadosamente os produtos de seus concorrentes ou priorizar a definição e implementação de tecnologias de infraestrutura como I18N, estruturas de notificação, log, segurança e estratégias de versão de API (por exemplo) significa que eles terão bugs mais altos, menor produtividade e acumularão mais dívidas técnicas do que se tivessem acabado de gastar os primeiros 2 a 5 sprints antecipadamente, fazendo o treinamento, a análise, o design e a criação de protótipos necessários. Em resumo, as equipes Agile devem resistir à licença para invadir;
• Tive um gerente de segundo nível (de mais de 100 desenvolvedores) que desencorajou seus desenvolvedores a dedicar tempo para anotar seus projetos planejados, mesmo no nível mais básico. Seu raciocínio - "quero que as pessoas conversem" - foi irônico porque estavam em cinco fusos horários diferentes e em três países. Escusado será dizer que houve muita discussão sobre qual equipe teria que trabalhar muitas noites e fins de semana no final do projeto, depois que descobriram que todo mundo achava que o outro cara era responsável por implementar alguma funcionalidade (ou reimplementação porque os projetos do fornecedor e do consumidor simplesmente não se encaixavam.)

Tudo se resume a se o gerente de projeto e as partes interessadas desejam entregar um produto de alta qualidade. Se eles se comprometerem a fazê-lo, o Agile o habilitará. OTOH, como o Agile coloca o cronograma de tomada de decisão apenas nas mãos do interessado e do gerente de projeto, o Agile dificulta que uma equipe de desenvolvimento entregue um excelente projeto sem esse suporte. Resumindo: a responsabilidade pela qualidade do produto está quase exclusivamente aos pés do (s) gerente (s) de projeto.

TL; DR

De fato, o desenvolvimento ágil ajuda você a aumentar a qualidade do software, manter o cliente satisfeito e entregar um produto altamente valioso.

O desenvolvimento ágil foi introduzido por algumas pessoas inteligentes para resolver os problemas que muitos projetos de software enfrentam nos processos tradicionais.

Os principais valores do desenvolvimento ágil, conforme definido pelo manifesto ágil (1) , são:

• 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 após seguir um plano

Portanto, o desenvolvimento ágil não impede a criação de software de alta qualidade. O desenvolvimento ágil ajuda você a fornecer software de alta qualidade.

Mas nós (e o cliente) realmente sempre sabemos antecipadamente quais são os requisitos essenciais.

Esse é o ponto. Ao focar nas pessoas, o cliente, o software de trabalho e as alterações de requisitos, o desenvolvimento ágil, ajudam você a descobrir o que os clientes desejam antes da entrega do produto final.

Essa é uma razão pela qual estruturas ágeis como o Scrum têm ciclos de iteração curtos, cujos resultados são produtos funcionais. Você já pode validar seu trabalho em um estágio inicial de acordo com as expectativas do cliente e ajustar as metas / requisitos sob demanda. Um desenvolvimento ágil ajuda a garantir a qualidade essencial de um produto.

Antigamente - ainda é verdade hoje - muitos projetos de software desenvolvidos em abordagens tradicionais falharam, não foram bem-sucedidos ou causaram desagrado aos clientes porque a qualidade imprescindível não foi alcançada.

Além disso, o desenvolvimento ágil também ajuda você a alcançar Qualidade Atrativa . A reflexão do produto após cada iteração esclarece novos requisitos que não foram atendidos pelo cliente no início do projeto (qualidades atraentes). Isso mantém o cliente satisfeito.

Gostaria também de mencionar a qualidade reversa - atributos que leva à insatisfação - do modelo Kano.

Em todo projeto, existem requisitos que parecem boas idéias no início do projeto. Depois de um tempo, eles mudam para o oposto e causam decepções.

Em um processo tradicional de desenvolvimento de software, você reconhecerá esses requisitos no produto final após uma longa execução do projeto. Tarde demais para evitar decepções dos clientes e alterá-los, é necessário um projeto de acompanhamento.

O desenvolvimento ágil ajuda a identificar os requisitos que não são satisfatórios ou que não funcionam ou a alterá-los durante o projeto.

Como eu disse, o desenvolvimento ágil ajuda você a aumentar a qualidade do software, manter o cliente satisfeito e entregar um produto altamente valioso.

Estou atrasado para esta festa, mas gostaria de compartilhar outro ângulo sobre esse assunto:

Mas como eles podem ser aplicados para criar deliciosos produtos de software de alta qualidade e não apenas o mínimo que mal atende aos requisitos essenciais?

Há um aspecto temporal no desenvolvimento de software ágil que resulta da abordagem iterativa e considerando o feedback do cliente , que são dois elementos importantes da metodologia ágil. Exemplo: os recursos que são identificados como qualidade atraente na iteração t podem se tornar uma qualidade obrigatória na próxima iteração t + 1.

A aplicação de métodos ágeis pode alterar dinamicamente a categoria de qualidade de um recurso. Se você comparar os recursos planejados da iteração t com os recursos finalizados de alguma iteração posterior t + n, experimentará exatamente o que mencionou:

Fiz a experiência algumas vezes de que os requisitos que receberam alta prioridade no começo se mostraram muito menos importantes, se não inúteis, posteriormente.

Com esse aspecto temporal em mente, é plausível que os métodos ágeis possam produzir deliciosos produtos de software de alta qualidade enquanto se concentram no mínimo . A abordagem iterativa combinada com o feedback do cliente altera as regras do jogo ao longo do tempo.

Conclusão

Como desenvolver um excelente software com métodos ágeis?

Aplique uma abordagem iterativa e ouça os comentários dos clientes . Abandone um desses elementos e você obterá uma forma menos bem-sucedida de desenvolvimento ágil de software.

   > How to develop excellent software with agile methods?

• Ao produzir um software individual específico do cliente :
  • encontre um cliente onde o custo não importa, porque o recurso "delicioso" custa dinheiro extra e o cliente precisa decidir se deseja pagar por isso.
• Ao produzir produtos de software :
  • Os recursos "deliciosos" são bons para atrair novos clientes e o custo para implementar um recurso "delicioso" não é tão importante se o produto for vendido mais de 1000 vezes.
• Em um ambiente em que "o suficiente (o mais barato) é o melhor"), você não receberá o dinheiro para implementar os recursos "agradáveis"

Em uma equipe Scrum, o Dono do produto é responsável por escolher quais recursos implementar. Portanto, cabe a ele (e até seu orçamento) definir um software "bom o suficiente" ou "excelente"

Você levanta alguns bons pontos. Mas não acredito que esses problemas sejam restritos a processos / metodologias ágeis.

Existem opiniões divergentes sobre o que é essencial e o que não é essencial. Para usar seu exemplo, alguém que compra um automóvel pode considerar a captação de atenção como um recurso essencial e, portanto, considerar um Fiat como não atendendo a esse requisito essencial.
Mais realisticamente, um produto de software pode precisar de uma certa funcionalidade para atender às necessidades de seus usuários finais reais ... mas também pode precisar de alguns outros recursos para ser vendido. Porque a pessoa que autoriza a compra frequentemente não é um usuário final.
Portanto, um recurso "não essencial" para o (s) usuário (s) final (es) pode ser essencial para vender o produto ... e, portanto, também essencial para a empresa que o criou.

Tudo isso se resume ao fato de que é crucial ter uma boa equipe de desenvolvimento de produtos para definir requisitos e prioridades adequadamente. Mas isso não é verdade apenas para lojas ágeis.

Também é importante ter proprietários / partes interessadas do produto que estejam autorizados a tomar decisões. Se as decisões do proprietário do produto estão sendo constantemente anuladas por outra pessoa, eu seria o primeiro a concordar que isso é um problema, mas, novamente, não é um problema com o ágil.

Há outras coisas que você deseja no (s) proprietário (s) do produto ... uma descrição que ouvi é "CRACK" (colaborativa, representativa, autorizada, comprometida e com conhecimento). Um proprietário de produto que não esteja em nenhuma dessas áreas pode significar problemas para um projeto. Mas ouvi pela primeira vez esse acrônimo em um ambiente em cascata; portanto, claramente a dor de maus clientes / proprietários de produtos não se restringe a lojas ágeis.

O que o agile pode (ajudar) fazer é trazer à tona alguns desses problemas.

Por exemplo, a literatura sobre XP é IIRC bastante explícita sobre ter o "cliente" conhecedor, acessível à equipe e autorizado a tomar decisões. O termo "proprietário do produto" implica algum nível de conhecimento, comprometimento e autoridade.

Se você se encontrar em uma situação em que a maior parte da funcionalidade fornecida consiste em delights em vez de recursos obrigatórios, é muito mais fácil levantar esse problema (e muito mais fácil determinar a causa) quando você entrega software em funcionamento ou quase em funcionamento a cada 2-3 semanas do que quando as entregas são separadas por meses ou anos.

Se você estiver trabalhando em pequenas iterações - e revisando o backlog frequentemente (incluindo revisar a priorização) -, isso oferece à equipe a oportunidade de aprender com os erros anteriores. "Parece que é realmente importante agora, mas lembre-se da navegação dinâmica que tínhamos certeza de que precisávamos que não acabamos usando?" Como outros já apontaram, essas discussões são muito menos prováveis ​​se tudo tiver sido planejado antecipadamente.

Por outro lado, a metodologia de projeto inicial assume (por padrão) que o entendimento do produto e dos recursos é estático. Essa não foi minha experiência: ter algo tangível para trabalhar quase sempre muda a compreensão do problema pelas pessoas de negócios. Daí a ênfase no feedback rápido. (O entendimento dos desenvolvedores também muda, mas isso não afeta as prioridades.)

Adiar parte do planejamento também permite que você responda às mudanças nas necessidades dos negócios. "Você conhece o site que está construindo? Realmente precisamos que esse seja um aplicativo móvel, capaz de operar desconectado". Isso não é algo que foi perguntado especificamente ... mas você não gostaria que seu processo fosse capaz de responder a mudanças no cenário dos negócios (pelo menos em teoria)?

O Agile não diz "não crie recursos não essenciais". Ele diz "permite que a empresa decida quais recursos (não) criar".
... e (igualmente importante) "permitem que os técnicos digam quanto tempo um recurso que você deseja para criar".

1. Must-be qualitiesgeralmente são difíceis de determinar. As pessoas os têm no subconsciente. As iterações ágeis e a participação do cliente ajudam a encontrar a maioria dos itens obrigatórios. Esse é o poder do ágil e é tolice negligenciá-lo .
2. One-dimensional qualitiesisso significa que as promessas que devem ser cumpridas são suportadas pela cachoeira OK, até que não estejam mudando. Ser ágil apenas ajuda, mas não com tanta força.
3. Attractive qualitiessão bons recursos. Eles podem se tornar obrigatórios na próxima geração. Mas na geração atual eles não estão de acordo - ou seriam qualidades unidimensionais. Esses métodos ágeis que supõem a participação representativa do cliente suportam muito bem essas qualidades. Pois podemos mudar o escopo levemente durante o trabalho. Podemos negociar melhorias em um lugar para compensar em outro. Na cachoeira é praticamente impossível. Sem um grande atraso organizacional, poderíamos adicionar recursos gratuitamente. É possível, se algum tempo extra for previamente colocado no orçamento.

Portanto, processos ágeis podem suportar o modelo Kano, alguns deles o fazem muito e definitivamente muito melhor do que os melhores projetos em cascata.

Para isso, você deve definir processos ágeis com um participante representante do cliente responsável.