O Agile pode ser realizado sem o envolvimento do cliente?


23

Eu não conseguia escrever um livro sobre Agile. Já trabalhei em várias lojas que chamam seu processo de Agile. Um dos principais pontos do desenvolvimento Agile é o envolvimento regular do cliente. Após um sprint, o trabalho pode ser demonstrado ao cliente para obter seu feedback. Enxague e repita.

O problema que me deparo é que muitos clientes não querem estar envolvidos. Eles preferem uma abordagem em cascata. Reúna os requisitos antecipadamente e volte quando terminar. Na minha experiência, cachoeira não funciona. Os clientes não sabem o que querem até vê-lo. O dilema da cascata é propagado ainda mais por uma grande comunidade de desenvolvedores que desejam ter todos os requisitos antecipadamente. Dessa forma, eles sabem o que estão construindo, podem arquitetar adequadamente e o cliente é o culpado porque "assinou" os requisitos.

Estou incorreto? O Agile pode funcionar sem o envolvimento do cliente? Se sim, como e como você supera os problemas que discuti?


12
Não deixe que o "ágil" se torne seu martelo, para que todo o resto pareça um prego que precise ser atingido por você.
Patrick Hughes

1
Na minha experiência, a preferência por abordagens em cascata geralmente se deve à falta de compreensão de como o software ou o design funcionam. A boa notícia é que isso significa que o Agile não é o grande problema, é a atitude / compreensão do cliente. A má notícia é a atitude do cliente.
21412 Ben Brocka

@BenBrocka: Isso não é muito surpreendente, considerando que é para isso que o Waterfall foi projetado especificamente. O autor queria escrever um artigo sobre como seria um processo de desenvolvimento criado por alguém que não entende o desenvolvimento de software e por que esse processo não pode funcionar. Então, ele inventou especificamente o Waterfall como exemplo, um processo projetado por alguém que não entende o desenvolvimento de software e que não pode funcionar. Obviamente, não é nenhuma surpresa que ele apela para as pessoas que não entendem de desenvolvimento de software nem é uma surpresa ...
Jörg W Mittag

@BenBrocka:… que não funciona. O que é surpreendente é por que alguém iria querer usar um processo projetado especificamente para não funcionar. Acho que ninguém se incomoda em ler o jornal.
Jörg W Mittag

1
@ JörgWMittag A adoção real do Waterfall (se eles percebem que é o waterfall ou não) é principalmente porque é um modelo padrão de decisões de negócios; chefe quer alguma coisa, subjacente faz isso, o cliente está feliz, certo? É claro que não faz o trabalho , mas é um modelo simples agradável para agradáveis simples mentes :)
Ben Brocka

Respostas:


17

Como pôde isso? A própria natureza da técnica determina algum tipo de loop de feedback entre o cliente e o desenvolvedor.

No entanto, partes de sua equipe podem atuar como clientes "proxy" (um processo semelhante a "comer sua própria comida de cachorro") para que você possa "fingir" ser ágil, embora isso não seja tão satisfatório quanto obter clientes reais comentários.

Goste ou não, o cliente estará envolvido no processo de design; é apenas uma questão de quanto eles querem que o retrabalho custe (quanto mais atrasado, mais caro é).

Como o cliente deseja o "Big Design Up Front", ajude-os a entender que levará mais tempo e esforço inicial para obter o design correto da primeira vez.


5
No entanto, partes da sua equipe podem atuar como clientes "proxy" - na minha experiência, os testadores tornaram "proxies" bastante eficazes do tipo que você menciona. Quando eu era testador, às vezes também fingia usar um terno de cliente, por assim dizer. Tal proxy têm limitações embora - por exemplo QA cara reclamando sobre quanto tempo é preciso para instalar o produto só poderia se sentir assim, porque eles fazem isso diariamente, enquanto cliente faz isso uma vez por ano ou dois
mosquito

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).Para quem é realmente mais caro? A maioria dos clientes não vê isso pagando seu tempo para obter a visão atual de uma solução. Às vezes, eles apenas têm um problema e não têm como saber qual deve ser a solução até que você lhes diga qual será. Nesse ponto, se o que você disse a eles não resolver o problema deles, então é SUA FALHA, não deles. Como é culpa deles que você tenha entendido mal os problemas reais em primeiro lugar? cont ...
maple_shaft

cont ... por que eles deveriam pagar por isso? Apenas para deixar a cara do cliente e não estragar completamente a chance de repetir negócios, você precisa se virar e fazer o retrabalho gratuitamente, porque eles exigiram o contrato de preço fixo em primeiro lugar. Essa é a atitude mais prevalecente e exatamente o que P.Brian.Mackey está enfrentando. Os clientes fortalecem essas negociações e, quando você é apenas uma das 100 startups que tentam pontuar o contrato, o cara com o contrato ágil e realista e justo terá que esperar na parte de trás da linha. É DURO lá fora agora.
Maple_shaft

@ maple_shaft: Claramente você foi queimado por isso. Mas, como em todas as coisas, tudo se resume a escolhas. O Agile existe porque a cascata tem seus problemas e as pessoas não são perfeitas. Se o cliente foi avisado dos riscos e deseja uma cascata de qualquer maneira, a escolha é deles. Também é a escolha da loja de software decidir se vale ou não a pena arriscar uma queda em um cliente que não entende os riscos ou nega a validade desses riscos.
Robert Harvey

@RobertHarvey Mesmo um cliente ruim em uma economia ruim ainda é um cliente e ainda mantém as luzes acesas por mais alguns meses. Os riscos para o cliente no caso que mencionei são mínimos e contidos se eles receberam a solução prometida no prazo. O risco para a loja de software, neste caso, é se esse cliente incomodativo vai nos sugar.
Maple_shaft

7

A resposta curta para sua pergunta é 'não'. Aqui estão comentários sobre algumas partes da sua pergunta. Para ser mais preciso, a maioria das respostas é baseada em minha experiência e observação pessoal.

Na minha experiência, cachoeira não funciona.

O Waterfall é uma metodologia sólida para fornecer sistemas de complexidade variável. É lamentável que não seja bem apresentado ou compreendido. Uma razão para isso é que ele não ganha dinheiro suficiente competindo com a metodologia do dia que continua aparecendo. Você pode se surpreender ao saber que muitos dos sistemas bancários, de seguros e de fabricação foram construídos apenas com a abordagem Waterfall e muitos deles ainda estão em produção hoje. É triste que a indústria de software se baseie mais no hype do que na ciência.

Os clientes não sabem o que querem até vê-lo.

Isso é um mito. Um grande também. Esse pode ser o caso no design / layout da página da Web, mas no processamento de dados comerciais, a maioria dos usuários deseja algo que funcione. Alguns desses usuários ainda usam telas AS / 400 e monitores 3270 CICS com RGB e podem realizar seus negócios com essas ferramentas. Além disso, esses mesmos usuários aceitam os sistemas SAP e ORACLE ERP sem ter nada a dizer no design da interface (e algumas vezes na funcionalidade). A maioria dos usuários corporativos adapta seus hábitos e fluxos de trabalho se o sistema estiver produzindo a função correta. O estresse aqui está na função, não parece. Os empresários entendem como fazem seu trabalho muito bem 90% das vezes.

O dilema da cascata é propagado ainda mais por uma grande comunidade de desenvolvedores que desejam ter todos os requisitos antecipadamente. Dessa forma, eles sabem o que estão construindo, podem arquitetar adequadamente e o cliente é o culpado porque "assinou" os requisitos.

Você não pode culpar os desenvolvedores por quererem saber o que estão construindo, porque esses desenvolvedores querem ir para casa preparar o jantar e pressionar suas camisas para outra broca depois de passarem três horas aprendendo a próxima tecnologia. que substituirá o conjunto de habilidades atual! O jogo da culpa não faz ninguém um vencedor. Pense em termos dos papéis e responsabilidades de cada parte e a imagem será muito clara.

Em conclusão, gerentes de projeto, programadores e web designers não substituem os analistas de negócios, que devem saber como coletar requisitos dos usuários finais, independentemente da metodologia.


3
+1 - Para "clientes desconhecidos" concorrentes. É uma questão de domínios diferentes, ter diferentes tipos de clientes. É por isso que os agilistas não conseguem entender as pessoas da cachoeira. Eles acreditam que você só pode dizer o que deseja quando vê. Não é verdade, mas é tudo o que vêem de seus clientes. Embora os proponentes em cascata não entendam por que você não consegue entender a grande maioria dos requisitos com antecedência, para que o design possa levar em consideração todos os problemas. Provavelmente porque as pessoas da cachoeira não lidam muito com os clientes à vontade.
Dunk

1
@ Dunk, obrigado pelo seu comentário. Eu gosto do seu texto "" querendo ou não "!
NoChance

2

Eles não querem gastar tempo e, se tiverem uma opção, preferem obter software de graça, mas você ainda vai cobrar, certo? Isso fica confuso se você estiver desenvolvendo software internamente para sua empresa. Eles acham que o departamento de TI foi comprado e pago (funcionários assalariados), para que possam tirar o máximo de trabalho possível de você.

Você pode ser potencialmente ágil. Obtenha todas as especificações e comece a codificar. Uma vez que o cliente interrompe o trabalho porque eles acabaram de pensar em algo e você precisa fazer alterações e retrabalhos, você se torna um pouco mais ágil. Você também pode fazer as aprovações dentro de sua equipe. Peça a uma equipe que coloque terno e gravata e finja ser o cliente.

Comprometer-se com muito tempo de antecedência pode assustá-los. Sugira fazer um sprint para testá-lo. Em seguida, dê a eles a chance de optar por não participar. Você sempre pode mudar para uma cachoeira pelo resto do projeto. Sugira também que pessoas diferentes de sua equipe possam fazer a revisão e aprovar se o tempo é uma restrição para a pessoa que está escrevendo o cheque.

Em algum momento, você precisa dizer a eles que não acha que a cachoeira vai funcionar. Pergunte a eles se eles ficaram satisfeitos com essa abordagem e, se sim, por que eles não têm o último responsável por esse projeto?


2

Nenhuma metodologia pode funcionar sem o envolvimento do cliente. Ter aprovação nos requisitos pode não fazer sentido, como testemunhei nos projetos em que participei. Seu problema vai além da capacidade de fazer o Agile; você precisa educar seu cliente e garantir que ele entenda o quanto é importante que eles participem.


2
Não é uma questão de quantidade e frequência de participação do cliente e não uma questão de tudo ou nada?
10242 JeffO

3
Um cliente que se recusa a participar com frequência é, a meu ver, um cliente que precisa de educação. Não é incomum os especialistas em negócios do cliente colocarem uma posição em que precisam interagir com a empresa de desenvolvimento de software e ainda realizar suas atividades diárias e isso precisa ser resolvido conversando com seus superiores.
Otávio Décio

2

Eu acho que um dos principais benefícios do Agile é a capacidade de obter requisitos mais detalhados para cada recurso em geral. Quando o cliente fornece todos os seus requisitos antecipadamente, cada recurso tende a ser uma ideia vaga, com um pouco de funcionalidade definida. O Agile força o cliente a revisitar cada recurso e se concentrar exatamente no que deseja e em como o recurso se encaixará no cenário geral. Para obter essa mesma quantidade de detalhes (detalhes suficientes para implementar os recursos) nas especificações, o waterfall realmente exige que você faça uma de duas coisas:

  1. Acho. Implemente até encontrar algo que é vago e faça um julgamento sobre como você acha que o recurso seria melhor implementado. Obviamente, isso não é o ideal, pois leva ao "Espere, não foi o que eu pedi!" cenário.

  2. Coloque muito mais ênfase no design antecipadamente. Essencialmente, quando o cliente apresentar as especificações incompletas para você no primeiro dia, planeje passar por todos os detalhes antes de implementar qualquer coisa. Peça ao cliente que esclareça tudo ad nauseum a ponto de conhecer todos os detalhes da implementação de todo o projeto. Embora não seja perfeito, é melhor que a opção 1. Você ainda pode encontrar detalhes que não havia previsto, e pode até enviar o cliente correndo para as montanhas, mas se eles realmente não querem se comunicar durante o desenvolvimento e você não são psíquicos, isso é uma necessidade. Isso é basicamente cascata e vem com todas as desvantagens associadas, incluindo a extrema dificuldade de executar corretamente.

  3. Pegue a especificação meio cozida, mas peça esclarecimentos à medida que avança. Trabalhe até atingir uma parte vaga da especificação e peça ao cliente que esclareça. Obviamente, não é isso que o cliente solicitou, mas se ele não quiser um aplicativo tão obscuro quanto a especificação e se recusar a definir a especificação antecipadamente, essa é a única opção restante. Ele não possui todos os benefícios do Agile (como aprovação regular do cliente para garantir que todos estejam na mesma página); no entanto, permite que você obtenha as informações necessárias para o desenvolvimento. Como a opção 1 provavelmente deixará você com um produto inferior, a opção 2 é um desperdício e frustrante para o cliente (você provavelmente precisará gastar pelo menos o dobro do tempo em design e coleta de especificações em geral, se o fizer totalmente antecipadamente), isso realmente não é uma opção tão ruim. A chave aqui é ser diligente na modificação de linhas de tempo e preço a cada alteração que surgir. Se você fizer isso corretamente, poderá descobrir que a maioria das práticas ágeis são compatíveis com esse arranjo, mesmo que o cliente não o conheça. IMHO, isso está realmente de acordo com o espírito do Agile, na medida em que você deve adaptar as metodologias ao seu arranjo específico.

Se o cliente realmente não consegue conviver com as consequências de qualquer uma dessas três opções ou do Agile completo, é difícil imaginar como esse cliente realmente valerá a pena.


Você deixou de fora a opção 4. Você aceita as especificações com a esmagadora maioria dos requisitos. Faça o design (provavelmente iterativo) com as análises dos clientes. Implemente e teste o código (provavelmente iterativo). Realize revisões periódicas do programa, informando o cliente sobre o progresso e as decisões. Eles dão feedback, você incorpora os comentários e segue em frente.
Húmido

As situações descritas acima ocorreriam apenas com equipes que não sabem fazer cascata. Sim, é difícil de executar corretamente. O Agile também é difícil de executar corretamente. Toda vez que alguém falha no ágil, algum agilista lança uma nova regra que não foi seguida e afirma que essa é a razão do fracasso. Nunca é culpa do ágil. Pelo menos os defensores da cachoeira admitem que são necessárias pessoas boas e com boas habilidades para fazer a cachoeira funcionar.
Húmido

Sua opção 4 é exatamente o que eu pretendia descrever em opção 3.
Morgan Herlocker

Como eu poderia melhorar minha resposta? Não sei dizer se você concorda ou discorda do que estou dizendo.
Morgan Herlocker

Você pode melhorá-lo, talvez usando a palavra meio cozida para iniciantes. Remover a parte sobre isso não é o que o cliente queria. Remova a parte escura das especificações, etc. Na cascata, a parte importante da captura dos requisitos é obter os significativos de arquitetura e os que o sistema absolutamente deve fazer para ser útil antecipadamente. Depois disso, as mudanças geralmente não são tão grandes assim. Acredite ou não, existem e sempre houve iterações, formais ou informais, no desenvolvimento em cascata. Muito antes de o ágil aparecer.
Dunk

1

Eu acho que é difícil, mas ainda é possível. Acho que a ideia de proxy de Robert funciona, mas é necessário que o proxy gaste o máximo de tempo possível com o cliente 'real' para que eles possam ver as coisas do seu ponto de vista. Dessa forma, o proxy pode verificar quais recursos são realmente importantes e ter uma idéia da experiência do usuário que o cliente espera / deseja.

Mas em algum momento você precisará mostrar o software para o cliente 'real' ...


0

É possível evitar clientes reais, de fato, às vezes, é necessário para a regulamentação. Normalmente, os clientes de software médico não estão envolvidos. Nesses casos, outras entidades podem substituir a função de cliente, por exemplo, a equipe de marketing pode ser considerada como cliente.


0

O Agile exige o loop apertado para substituir o grande projeto inicial que é Difícil - Bastante difícil, mas na verdade isso pode ser feito, o Agile não é o único caminho.

Você pode encontrar uma das modificações do Agile - existem muitas e uma provavelmente resolve esse problema específico, mas se não for o seu caso, se você acha que pode.

Todos esses processos foram compostos por pessoas inteligentes - e as pessoas inteligentes podem fazer qualquer processo funcionar. Você não acha que a cachoeira foi inventada porque nunca funcionou para ninguém, não é? Ele evoluiu porque algumas pessoas conseguiram fazê-lo funcionar, e outras observaram e disseram: "Eu tenho que refinar isso e alimentá-lo com a MINHA equipe que parece não produzir tão eficazmente" - nesse ponto, provavelmente funcionou melhor do que aquilo que eles estavam fazendo, mas se você não reconhece que nem todo programador pode resolver todos os problemas, ele pode realmente confundir você porque duas equipes que usam o mesmo processo podem ter resultados diferentes.

O problema é que muitos processos exigem talento para implementá-los - estamos falando de talentos tão raros quanto os profissionais de esportes em meio a todo mundo que já praticou um esporte - é provável que a maioria de nós nunca conheceu alguém capaz de fazer os processos ruins como o trabalho em cascata e é por isso que tantas pessoas pensam que não pode ter sucesso - nunca o viram funcionar.

É preciso muito menos talento para fazer o Agile funcionar, mas exige alguns investimentos muito específicos, como fazer com que o cliente observe constantemente o que você está fazendo, para que os erros não possam se propagar, e coisas como refatoração implacável, para que você não construa uma dívida técnica que a equipe não pode desvendar daqui a alguns meses.


0

Defina o cliente.

É outra empresa? Outro indivíduo?

É outra equipe da sua empresa?

É um campeão de produtos dentro da sua empresa?

É você?

Todas as opções acima são possíveis e razoáveis, dependendo das circunstâncias. Você não deseja ter uma única visão do túnel sobre o que é ser ágil; portanto, um NO definitivo seria incorreto. SIM, por outro lado, requer um pouco de reflexão lateral.

Pense na palavra Ágil por um momento. O grupo muito inteligente de pessoas que cunhou o termo não poderia ter escolhido uma metáfora melhor para o conceito que estava tentando descrever. Quando você diz Agilidade , o que vem à sua mente? Sendo frota de pé? Rápido para reagir, talvez? Rápido para se adaptar?

Agora pense em todas as práticas Agile comumente aceitas no mercado e pergunte a si mesmo o que elas realmente trazem aos métodos de desenvolvimento de software considerados Agile .

Sou o cliente de todas as intenções e propósitos para meus projetos solo. Às vezes, até uso um chapéu de verdade, quando realmente quero fazer uma mudança mental distinta no meu papel de cliente . Isso não me torna menos ágil do que quando estou no trabalho. Por tudo que eu me importo, meu gato pode ser o gerente. Ele garante que eu descanse de vez em quando e me lembre de evitar ficar obcecado por uma única tarefa. Você pode preferir usar sua sofisticada "Técnica Pomadoro", mas eu prefiro o temporizador "Rascal" !! O fato é que trabalho em um processo estritamente ágil sempre que escrevo código para mim. Eu não sou do tipo hacker e cowboy, que vive uma vida de picos de desenvolvimento sem fim e sem realizar nada. Gosto de criar meu software, agendar o desenvolvimento em torno de minhas vidas profissionais e pessoais e concluí-lo da maneira que eu esperaria que estivesse se estivesse trabalhando para um cliente real. Quando as coisas interrompem meu cronograma, ajusto e priorizo ​​o trabalho do meu projeto de acordo. Eu uso todas as práticas e técnicas padrão do Agile que posso aplicar sozinho e "entrego" código de trabalho para mim mesmo (ou para um amigo ou colega para testar) o mais rápido possível. Se tudo isso não é ágil, pergunto o que é.

Portanto, minha resposta é Sim , você pode ser um desenvolvedor de software ágil e aplicar uma metodologia ágil e não precisa necessariamente do cliente ou mesmo do gerente. Você pode trabalhar sozinho em um projeto e usar vários chapéus. No entanto, pode não ser necessariamente ideal eliminar esses outros papéis, pois é muito útil cooperar com os outros para alcançar uma meta. Eles atuam como uma caixa de ressonância para suas idéias e atendem a requisitos que, de outra forma, você pode achar difícil de gerar com sensatez por conta própria. A outra função muito importante que o cliente e o gerente cumprem é a de manter você focado em seus objetivos, sem adicionar recursos continuamente e refinar seu código além do estritamente necessário.

Ainda assim, se você trabalha de maneira disciplinada, adere estritamente à sua metodologia de escolha e aplica práticas ágeis, e se você se desviar ou mudar de idéia (ao usar o chapéu do cliente) e o design ou direção do produto Por outro lado, se você pode adaptar sua programação e ajustar suas prioridades exatamente como imaginaria que seu cliente esperaria, você estará sendo Agile.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.