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

61

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.

Frank Puffer
fonte
12
Transformando-os em requisitos? Não é brincadeira. Eu concordo com o modelo Kano. No entanto, tenho visto muitas vezes empresas confundindo qualidades e prazeres com marketing vazio e inútil que morre. Depois que o projeto é vendido. Transforme essas coisas em requisitos essenciais. Além disso, metodologias ágeis não são dogmas imóveis. Quem usa agaile é livre para adaptar a metodologia a objetivos mais elevados.
Laiv
8
"Mas nós (e o cliente) realmente sempre sabemos antecipadamente o que é preciso ser" - não, e é por isso que as metodologias ágeis podem oferecer um software excelente; eles permitem isso. Você não segue nada servilmente e pode alterar prioridades e revisar os requisitos à medida que avança.
jonrsharpe
17
"Eu experimentei algumas vezes que os requisitos que receberam alta prioridade no começo se tornaram muito menos importantes, se não inúteis, mais tarde." - e esse é exatamente o ponto do ágil - para reagir a isso. processo de aprendizado. Os processos em cascata não podem alterar as prioridades por definição.
Doc Brown
21
@ DanMills: O modelo Waterfall, como descrito originalmente, era literalmente um homem de palha. Era uma ilustração de como alguns projetos de desenvolvimento de software da época alegavam absurdamente (que pretendiam) fazer todo o planejamento antes de toda a implementação antes de todos os testes. O mesmo artigo mostrou que o desenvolvimento iterativo (incluindo o que agora chamamos de ágil) era onipresente, mas mal gerenciado porque era nominalmente contra a prática acordada e argumentou que deveria ser explicitamente adotado e explorado.
Phil Miller
4
Como desenvolver um excelente software? Contrate excelentes desenvolvedores. A metodologia de desenvolvimento é muito menos importante do que as pessoas que fazem o desenvolvimento.
Mark

Respostas:

78

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.

Martin Maat
fonte
4
É irônico que o ágil tenha evoluído para fora da indústria automobilística (a Toyota). Faça o que o original fez: a metodologia "The Toyota Way" da Toyota não define o "cliente" como a pessoa que compra o carro. Em vez disso, é o departamento de design / marketing do produto. O trabalho do departamento de produto ou marketing é seguir modelos de design de produtos como o Kano. O trabalho do Agile é implementar e realmente construir o produto. Se você se encontra misturando metodologias, seu chefe realmente não entende as funções do trabalho. Se você é uma startup e não tem escolha, faça-o separadamente.
slebetman
11
Uma boa pergunta seria. Como nós (desenvolvedores) podemos influenciar o cliente para fazê-lo entender que hoje em dia apenas a funcionalidade não é suficiente. Sempre tive dificuldade em influenciar algumas das decisões que provaram estar erradas ou que não têm sustento real.
Laiv
5
+1 Melhor descrição de ágil no mundo real que já vi há muito tempo.
Paul Smith
4
Eu gosto de lembrar às pessoas que a palavra "ágil" não foi escolhida por acidente. O objetivo é ser capaz de responder de maneira ágil a coisas que surgiram durante o desenvolvimento que eram inesperadas (como um obstáculo ou um cliente mudando de idéia). Se o seu cliente é estático e seu trabalho não traz surpresas, então o ágil é um modelo ruim para você ou você pode ser ágil para poder agitar um pouco as coisas.
Cort Ammon
3
@Kik ​​Eu fiz tanto em algumas das mesmas empresas e os resultados foram dramaticamente diferentes. Mesmo quando a abordagem Agile foi mal executada, ficou claro quem / qual era o problema e poderia ser resolvido. Waterfall não é e nunca foi uma boa ideia, na verdade, o cara que 'a inventou' o fez em um artigo explicando por que era uma ideia tão terrível, mas as pessoas não se incomodavam em ler a coisa toda, suponho.
21417 JimmyJames
74

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.

nvoigt
fonte
5
É verdade que as ferramentas são agnósticas e amorais. Se alguém souber de um processo comprovadamente mais eficaz do que o realizado, informe-me nos comentários abaixo.
Mindwin
21
E com o Agile, você poderá estender seu projeto Fiat e obter uma Ferrari, ou com um projeto Ferrari, ainda obter um Fiat (com valor diferente de zero), mesmo que o projeto falhe.
user253751
7
Sim, tudo isso é verdade, mas também não está respondendo à pergunta. O ponto é que as práticas ágeis permitem que as forças comerciais já existentes na operação entrem no processo de desenvolvimento de software. Isso pode facilmente levar a que um proprietário do produto seja o chute lateral do gerente de vendas ou o chute lateral de outra pessoa poderosa da empresa sem muita afinidade com o desenvolvimento do produto. Isso de novo normalmente resulta na mediocridade descrita pelo OP, ele não está inventando isso.
Martin Maat
13
@MartinMaat Eu concordo com você no fato de que uma PO ruim gera um resultado ruim, mas eu vi tantos documentos de requisitos ruins em cascata que não posso concordar que seja uma coisa ágil. Um trabalho ruim é um trabalho ruim ... em qualquer processo.
Nvoigt
28

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.

Michael Borgwardt
fonte
11
"Mas em um projeto não-ágil, esse ainda seria o caso". Não tenho certeza se concordo. Parte do objetivo de cumprir primeiro os requisitos "obrigatórios" é que ele oferece espaço para cortar coisas consideradas menos importantes ou empurrá-las para uma versão posterior se liberar os recursos que você possui por um determinado tempo for considerado mais importante . O Agile parece colocar ênfase adicional na reavaliação periódica de seus requisitos declarados, o que tende a levar a uma espécie de resposta implacável à realidade, mostrando que você não pode obter tudo o que queria tão rápido quanto queria.
Jpmc26
9

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.

Karl Bielefeldt
fonte
9

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.

candied_orange
fonte
O que eu quis dizer com "não segue servilmente" é que os clientes sabem o que querem em termos de necessidades de negócios, mas geralmente não conseguem criar requisitos detalhados que fazem sentido porque não sabem o suficiente sobre desenvolvimento de software. Eles geralmente fornecem uma lista subótima de requisitos e faz parte do trabalho do produtor de software discuti-lo com o cliente e sugerir melhorias e alternativas a ele.
Frank Puffer
@FrankPuffer muito verdadeiro, na verdade, é por causa dessa desconexão que é tão importante iterar com frequência. Você pode ter todas as reuniões que deseja, mas nada chega perto de permitir que o cliente use seu software. É quando você começa a aprender o que eles realmente significam.
Candied_orange
4

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)

Pieter B
fonte
3

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.

Pooh
fonte
1

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.

Paul Wasilewski
fonte
1

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.

Theo Lenndorff
fonte
1
   > 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"

k3b
fonte
1

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".

David
fonte
1
  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.

Gangnus
fonte