O modelo Kano de satisfação do cliente define diferentes classes de recursos do produto. Entre eles estão
Qualidades indispensáveis: se não forem implementadas, o cliente não aceitará o produto.
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.
fonte
Respostas:
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:
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.
fonte
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.
fonte
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.
Nada poderia estar mais longe da verdade.
Os processos ágeis geralmente enfatizam estes pontos:
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.
fonte
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.
fonte
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.
Claro que você deveria. Exceto ao estimar seu tempo. Porque esses requisitos obrigatórios não são a única consideração.
fonte
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)
fonte
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" . "
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.
fonte
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:
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.
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.
fonte
Estou atrasado para esta festa, mas gostaria de compartilhar outro ângulo sobre esse assunto:
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:
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
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.
fonte
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"
fonte
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".
fonte
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 .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.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.
fonte