A abordagem ágil é uma desculpa conveniente para cowboys?

73

Acredito que uma abordagem ágil é melhor para projetos em que os requisitos são imprecisos e é necessária muita interação para ajudar a moldar as idéias do usuário final.

No entanto ... No meu trabalho profissional, continuo terminando em empresas em que uma abordagem "ágil" é usada como desculpa para explicar por que nenhum esforço foi colocado em um projeto inicial; quando os requisitos forem bem compreendidos.

Não posso deixar de pensar que, se a abordagem ágil não estivesse por perto, eu estaria sentado aqui com uma boa especificação de alto nível e sem ter que revisitar a mesma tela e funcionalidade a cada segundo dia, quando algo mais surgisse e por isso não tinha pensado nisso.

Os benefícios das metodologias ágeis são realmente suficientes para compensar a desculpa de serem idiotas que isso dá aos líderes técnicos dos cowboys?

Atualização: Ironicamente, agora sou um Scrum Master certificado. Um dos trabalhos apresentados no curso Scrum observou que o melhor processo de desenvolvimento era aquele em que um único especialista ou guru tomava as decisões de design, no entanto, isso tem pontos fracos óbvios. O Scrum transfere a responsabilidade de produzir software de qualidade para a "Equipe", o que significa que uma equipe abaixo do padrão pode produzir espaguete, o que eu acho que não é diferente de outros processos de desenvolvimento Agile e não Agile.

Jim G.
fonte
6
Votos negativos eh ... Acho que alguns convertidos ágeis ficam um pouco na defensiva, especialmente quando vêem ágil e cowboy na mesma frase. E eu nem sou ágil, são os cowboys que me irritam.
Sipwiz 12/10/10
2
Isso pode ter algo a ver com o motivo pelo qual muitos dos signatários originais do Manifesto Ágil estão expressando desgosto pelo termo "ágil", como é usado na maioria das empresas. Em vez disso, agora eles estão falando sobre coisas como "habilidade com software".
Darcy Casselman
11
Primeiro, deixe-me dizer que não sou fã de ágil. Segundo, direi que, na minha experiência, "capital A Agile" apenas atrasa todo mundo (incluindo cowboys). Eu nunca trabalhei em uma situação em que senti que o ágil estava habilitando o chamado "codificador de cowboy".
TM.
11
Não acho correto chamar o que você está descrevendo de "codificação de cowboy". Este não é um problema individual - é um problema de grupo. Isso é péssimo gerenciamento de produtos e equipes.
Matt b
3
Acho que pensar na frente é quase inútil. Iterar em direção a uma solução seguindo os primeiros instintos pode ser muito eficaz se você empregar práticas de programação sensatas. Minha experiência indica que aqueles que apresentam planos substanciais antecipadamente não podem reagir à realidade quando começam a programar.
traço-tom-bang

Respostas:

87

Estou feliz que tenha um nome

Acredito que se você estiver usando o desenvolvimento Agile como uma desculpa para a programação no estilo cowboy, não estará realmente seguindo o desenvolvimento Agile. Os cowboys sempre serão cowboys, não importa qual processo você dê a eles.

Dean Harding
fonte
17
Dilbert (sempre)
arrasa
20

O Agile não é mais culpado por práticas inadequadas de desenvolvimento do que o BDUF. O problema está na disciplina, ou na falta dela, na aplicação das práticas. O objetivo das práticas do BDUF é identificar a direção do projeto e determinar os riscos antecipadamente. O objetivo das práticas ágeis é manter o estado do desenvolvimento flexível o suficiente para mudar rapidamente de direção. Um projeto ágil pode preparar histórias de usuários altamente detalhadas para que a equipe esteja ciente das direções futuras e ainda selecione apenas 2 ou 3 por iteração para implementar completamente. O problema continua sendo o mesmo, seja qual for a metodologia usada: a administração está deixando os caubóis zangados.

[BDUF: Big Design na frente]

Supermercados
fonte
3
Nunca será possível frustrar os vaqueiros, independentemente da abordagem. No entanto, pelo menos com a cascata, eles teriam que, pelo menos, produzir um documento de requisitos, um documento de sepcificação etc.
Sipwiz 12/10/10
3
Novamente, isso é uma falha no gerenciamento do processo corretamente. O cliente deve educar os desenvolvedores sobre qual é o valor comercial na história do usuário, e os testes devem verificar se estão integrados à base de código. Registre as áreas em que os desenvolvedores precisam refazer suas etapas. Eles não são bem versados ​​no processo de negócios do cliente? Eles são incertos quanto ao ambiente de implantação? Se o projeto estiver incorrendo em custos adicionais de desenvolvimento devido ao "retrabalho de componentes", a gerência deve corrigir isso para reduzir a probabilidade de exceder o orçamento ou o cronograma.
Huperniketes
4
Se você começar a digitar o código, não estará agilizando, mesmo que o chame. O que é para me impedir de bater no código e chamá-lo de cascata se eu passasse 5 minutos pensando nos requisitos no início.
Craig
11
Huperniketes está certo, o problema não está na metodologia; o problema é que a equipe de gerenciamento deixa os vaqueiros dirigirem o departamento.
Jeff Siver
7
@sipwiz: Mesmo na cachoeira, os cowboys batiam direto no código. Eventualmente, eles documentariam o que quer que escrevessem como especificação de design.
TMN
13

O Agile, como qualquer coisa , pode ser usado para cobrir um mau comportamento ou para tentar resolver um problema que a equipe acha que não é responsável.

No entanto, a mágica de algumas metodologias ágeis como o Scrum é que elas proporcionam muita visibilidade dos problemas da organização. Incluindo problemas dentro da equipe!

Você terá a oportunidade de resolvê-los conforme eles surgirem.

Se o problema estiver para os cowboys, isso ficará muito visível após a primeira iteração. Se o problema estiver em outro lugar, você também o verá em breve.

user2567
fonte
12

Curiosamente, a partir dos projetos "ágeis" com os quais me envolvi, parece mais uma desculpa da gerência para pular a fase de coleta de requisitos do que um desejo de cowboy de simplesmente começar a codificar. Meus projetos têm sido extremamente frustrantes porque não temos usuários finais com quem interagir. Em vez disso, temos um diretor que conversa com vendas para descobrir o que eles acham que os clientes desejam, depois convoca uma reunião e a descreve aos gerentes, que começam a atribuir tarefas aos desenvolvedores. Em um projeto "bom", podemos nos referir a uma apresentação de PP, mas geralmente acabamos passando nossas reuniões diárias perguntando como um recurso deve funcionar, e o gerente escreve as perguntas e pergunta ao diretor. É uma enorme perda de tempo - mas é "ágil"!

TMN
fonte
Não chamamos nada, mas é basicamente assim que as coisas acontecem por aqui. Na verdade, temos alguns documentos importantes sobre design, mas eles estão desatualizados e ninguém os observa. Em vez disso, todos os novos recursos ou correções são ditados apenas pelo que o VP considera quente ou pelas vendas que os clientes desejam, se esgotam rapidamente nas reuniões e são descartados com prazos pesados.
CodexArcanum
+1: @TMN, @CodexArcanum: Eu também tive a mesma experiência. Não havia campeão do usuário. As vendas ditaram novos recursos para o gerenciamento de produtos, que os repassaram ao desenvolvimento.
Jim G.
7

Não direi que sou fã do Waterfall, já que também lido com o alcance cada vez mais frustrante do escopo, mas sempre vi o Agile como uma concessão ao problema, não como uma maneira eficaz de combatê-lo. Um bom design, com testes iterativos iniciais e muitos protótipos de papel, parece ser muito mais eficaz.

Morgan Herlocker
fonte
4
O problema é que um bom design é quase impossível para qualquer coisa que não seja um projeto trivial. Problemas com o design só se tornam aparentes à medida que o projeto avança. Os usuários não sabem o que querem, por mais especializados que sejam.
Craig
@Craig. Embora eu concorde com você que as especificações são quase impossíveis de definir, mesmo sistemas não triviais devem poder ser prototipados em papel e isso é muito mais barato do que escrever o sistema inteiro apenas para descobrir que ele precisa ser reescrito. Se não puder ser prototipado em papel (pelo menos para a funcionalidade básica), é difícil imaginar que o sistema específico funcione bem ou que seja razoável implementá-lo no final. Se você e o usuário não puderem se sentar e percorrer um cenário de teste no papel antes de começar a trabalhar, haverá sérios problemas.
Morgan Herlocker 12/10/10
2
@ Craig Eu discordo que um bom design é impossível. Conhecer todas as complexidades do sistema desde o início pode ser quase impossível, mas isso não significa que um projeto em relação ao que é conhecido não possa ser produzido. Quero dizer, mesmo uma única frase como "Este aplicativo será escrito como um aplicativo MVC usando a estrutura de entidades para o DAL" seria algo. Além disso, já vi concursos com mais de 180 páginas de requisitos e você não pode me dizer que não há detalhes suficientes para produzir um design muito bom.
sipwiz
sipwiz, minha experiência é que o número de páginas não se correlaciona com a utilidade de uma especificação. O que está escrito é mais importante, não quanto. Depende totalmente do sistema, se 180 páginas são boas ou não; se eu estiver construindo o Windows, acho que é um pouco mais leve.
Craig
3
Também acho que você precisa se lembrar, ágil não significa nenhuma especificação.
Craig
6

Estou vendo defesas do Agile Development dizendo que não é responsável por falhas causadas por cowboys. O sucesso com o Agile requer diligência e inteligência.

Essa parece uma posição razoável, desde que você aplique a mesma concessão a outras metodologias. Se você não pode culpar o Agile por falhas de projeto causadas por cowboys, não pode culpar metodologias não-Agile por falhas de projeto causadas por cowboys.

Podemos então argumentar se existe uma correlação (não causalidade!) Entre Agile e cowboys. Com apenas evidências anedóticas, acredito que exista. É percebido como uma boa maneira de conviver com as práticas de caubói sem ser detectado pela gerência?

Obviamente, se aceitarmos que os cowboys não podem ser distribuídos igualmente entre as metodologias, e aceitamos que os cowboys prejudicam o uso bem-sucedido de um processo, tornamos muito difícil testar se um processo é bem-sucedido. A alegação de que um processo é melhor (dentro de um contexto) torna-se quase impossível de falsificar. Essa é uma das questões que me deixa com vergonha da minha profissão - a falta de sustentação científica de muitas das reivindicações.

(A propósito, eu odeio chamar a (s) alternativa (s) para Agile "cascata", porque os processos em cascata parecem ser um palhaço que todo mundo ataca, mas poucas pessoas realmente usaram sem nenhuma iteração.)

Oddthinking
fonte
4
Falhas no desenvolvimento não são o resultado da presença de cowboys. Falhas no desenvolvimento são o resultado de o gerenciamento não estar presente.
Huperniketes
@ Superniketes, são notícias FANTÁSTICAS. Os programadores nunca são os culpados! Que profissão ideal nós escolhemos!
Oddthinking
@ Pensando bem, pare de se limitar ao pensamento binário. Os programadores certamente podem ser responsabilizados por não apresentarem o desempenho de sua profissão, mas os programadores nunca são os culpados pelas falhas do projeto. Essa é a responsabilidade dos gerentes de projeto.
Huperniketes
@ Superniketes, talvez você possa esclarecer mais, por favor? Você disse originalmente "falhas no desenvolvimento", mas depois passou para "falhas no projeto". Eu concordo que os gerentes de projeto podem ter que "carregar a lata" se um de seus desenvolvedores tiver um desempenho abaixo das expectativas, mas é difícil ver como os caubóis que falham em entregar nunca podem ser a causa de um projeto falhar.
Oddthinking 18/10/10
Pensando bem, não quis dizer distinção entre "falhas de desenvolvimento" e "falhas de projeto". Eles são usados ​​como sinônimos aqui. Certamente, um projeto pode não ter sido bem-sucedido porque o esforço de programação foi insignificante, mas o dever do gerente de projetos é identificar esses casos e remediá-los com alterações na equipe, quando necessário. O trabalho dele é garantir que o projeto seja bem-sucedido. Ele precisa ser demitido se não puder fazer isso. Portanto, ele precisa garantir que os membros da equipe, até os programadores de cowboys e programadores de rock star, cumpram suas obrigações com o projeto ou os demitam.
Huperniketes 18/10/10
5

Agile é bom, desde que esteja trabalhando para sua equipe.

Muitos estão vendendo como uma maneira de transformar um time ruim em um bom time, e simplesmente não funciona dessa maneira. Você não pode pegar pessoas más e aplicar um processo para torná-las úteis de repente.

Eu gosto de muitas das ideias por trás do ágil, mas o fracasso que vejo repetidas vezes é que os gerentes estão pressionando um conjunto estrito de "processos ágeis", que contraria todo o conceito de ágil, de que as equipes devem ser auto -organizando.

Quanto aos "cowboys", acho que, para todas as equipes ágeis em que participei, os processos servem para retardá-los mais do que deixá-los ir à loucura. Eu nunca experimentei uma situação em que o ágil servisse para ativar um "codificador de cowboy".

Para boas equipes, parece funcionar bem (mais uma vez, a maioria dos processos parece funcionar bem quando você tem uma boa equipe, engraçado como isso funciona, não é?).

Para outras equipes, na minha experiência, isso nunca ajuda as pessoas más a se saírem melhor, mas às vezes serve para atolar as pessoas produtivas.

No geral, acho que o importante é formar uma boa equipe, dizer a eles o que você precisa e sair do caminho. Não acho que a aplicação de uma série de palavras-chave provavelmente resolva o problema de ter um time ruim.

(Se você ainda não descobriu o que foi exposto acima, não sou fã de "Capitol-A Agile", no mínimo. Por outro lado, também não acho que isso incentive os cowboys.)

TM.
fonte
3

Ágil, quando feito corretamente, deve ter o efeito de controlar os leads técnicos "cowboy" e os programadores "heróis". Se você não observar esse efeito, isso pode ser um sinal de que algo importante está faltando na sua implementação ágil.

Quero acrescentar que "Agile" é realmente uma interface (estou usando uma metáfora orientada a objetos aqui) e você não pode instanciar. Se sua implementação concreta é XP , você deve seguir várias práticas técnicas com muita disciplina, o que deixa pouco espaço para a programação de cowboys. Outra possibilidade é que o trabalho em equipe de uma equipe Scrum bem organizada o mantenha sob controle.

azheglov
fonte
3

Os codificadores de cowboy também tendem a escrever códigos que não são muito testáveis ​​e tendem a não gostar de escrever testes. Acho que ter todo mundo fazendo TDD pode ajudar a reinar na atitude caubói e fazer com que os desenvolvedores pensem um pouco mais na arquitetura. Nenhuma metodologia é perfeita, é claro.

Matt H
fonte
11
Não se esqueça do paranóico "if (var! = Null)" cheques polvilhado todo o código ...
Jörgen Sigvardsson
3

Atualmente, estou trabalhando em uma loja onde esse é o caso, exceto que tem mais a ver com a cultura organizacional do que com cowboys individuais em particular.

A organização sempre operou com uma abordagem relativamente informal e ágil "ágil". Eu não diria que é verdadeiramente ágil, é mais "nome ágil", mas apenas uma metodologia inexistente na prática. Equipes diferentes operam de maneira diferente, mas como a cultura organizacional geral não possui nenhuma metodologia, a não ser um processo muito solto de "Agile in name only" - é relativamente cowboy e caótico em geral - especialmente em integração (e há muito disso )

A moral da história é - Sim, isso acontece. Se eu estivesse procurando emprego no momento, teria muito cuidado com isso. Se uma loja está afirmando ser ágil - eu faria algumas perguntas bastante difíceis na entrevista para garantir que mais do que apenas um nome impróprio de Agile esteja sendo seguido.

Bobby Tables
fonte
11
Isso parece muito com a minha situação também. E chega ao ponto de toda essa questão: se o "Agile" não estivesse presente, as organizações provavelmente seguiriam a cascata e, quaisquer que sejam suas deficiências, é muito superior a não ter processo.
sipwiz
2

Descobri que os usuários só podem nos dar feedback quando tiverem um aplicativo que possam usar, telas nas quais possam inserir dados. Somente então, eles realmente entendem o que estávamos tentando dizer nos documentos de requisitos (que os clientes assinam, mas todos têm sua própria versão do significado). Se não for um desenvolvimento ágil, será um projeto em cascata acima do orçamento, mas o aplicativo mudará assim que você o entregar. Sua primeira versão não é mais que um protótipo para os usuários discutirem quais deveriam ser os requisitos. Então, prefiro chamá-lo ágil do que acima do orçamento.

Veronica Buitron
fonte
Também já vi isso (clientes que veem uma versão anterior e se envolvem demais nos bugs / recursos que você sabe que ainda não estão prontos) e, às vezes, pode ter dificuldades para obter feedback útil. Mas acho que é uma questão de educar seus clientes.
Re: Harding
Prototipagem ....
sipwiz 13/10/10
2

Eu acho que é verdade, em alguns ambientes o Agile é usado como desculpa para nenhuma disciplina. O verdadeiro problema é que perdemos de vista por que temos alguma metodologia. Pessoalmente, acho que a metodologia é uma questão arquitetônica, no sentido de que a arquitetura do sistema deve abordar os atributos não funcionais de qualidade; a metodologia deve abordar alguns desses mesmos atributos (manutenção, produtividade no desenvolvimento, transferência de conhecimento, et al.)

Visualizar a metodologia como um controle para os atributos do processo implica algumas coisas: 1) sem métricas, não podemos comparar a eficácia de uma metodologia em relação à outra, 2) é necessário tomar uma decisão ativa sobre quais atributos são importantes (tempo de entrega versus código qualidade versus transferência de conhecimento).

Sem ter métricas e uma meta tangível, simplesmente escolhemos uma metodologia como nossa "pena mágica" que, se mantivermos firme, poderemos fornecer software.

Agora, os negativistas do Agile, XP, Scrum, etc. falam sobre a fragilidade dessa categoria específica de metodologias. O argumento é: por que usar uma metodologia que pode ser sabotada por um indivíduo que não possui disciplina para seguir todas as regras? A questão é válida; no entanto, esse é o sintoma, não a causa. Se um conjunto de métricas de processo precisas e significativas (essa é a parte mais difícil) for definido, testado e fornecer feedback oportuno, acredito que descobriremos que a metodologia específica tem pouco a ver com sucesso. (Anedoticamente falando, eu vi projetos bem-sucedidos usando uma infinidade de metodologias e duas vezes mais falhando usando as mesmas metodologias)

Então, quais são as métricas? Eles variam de projeto para projeto, equipe para equipe e de tempos em tempos. Útil para quando o cronograma de entrega é importante, que eu pessoalmente usei é a habilidade e qualidade de estimativa. A maioria dos desenvolvedores pode estimar com precisão as tarefas que duram uma semana ou menos. Portanto, uma abordagem é dividir o projeto em tarefas de uma semana de desenvolvedor e acompanhar quem fez a estimativa. À medida que o projeto avança, eles podem alterar suas estimativas. Depois que uma tarefa é concluída, se estiver desativada em mais de 10% (1/2 por dia), trataremos o mesmo como um bug - identificamos por que a estimativa estava desativada (ou seja, uma tabela do banco de dados não foi considerada), identifique o ação corretiva (ou seja, envolver o DBA na estimativa) e depois seguir em frente. Usando essas informações, podemos criar métricas como número de erros de estimativa por semana, número de erros por desenvolvedor,

E daí? É aí que entram as metodologias - se você tem um modelo preditivo que falha em atender às qualidades do processo, pode optar por adicionar ou remover algum aspecto da metodologia e ver como isso afeta seu modelo. É verdade que ninguém quer jogar com um processo de desenvolvimento por medo de falhar, mas já estamos falhando a uma taxa consistentemente alta e previsível. Ao fazer alterações individuais e medir o resultado, você pode achar que o Agile é a metodologia perfeita para sua equipe, mas você pode facilmente encontrar o RUP, a cascata ou apenas um conjunto de boas práticas como ideal.

Portanto, minha sugestão é deixar de se preocupar com o que chamamos de processo, realizar verificações relevantes para nossos objetivos de processo de desenvolvimento e experimentar diferentes técnicas para melhorar esse processo.

TEC
fonte
Bons pontos. Minhas frustrações decorrem dos resultados de uma abordagem ágil são muito mais fluidos e isso permite que um líder técnico incompetente se safe do que quiser e que, na minha experiência, acaba como nenhum processo == codificação de cowboys.
Sipwiz 27/10/10
1

Eu estaria sentado aqui com uma boa especificação de alto nível e sem ter que revisitar a mesma tela e funcionalidade a cada segundo dia, pois outra coisa surge ou não, e por isso não pensei nisso.

Isso parece coincidir com a experiência do meu colega no projeto "ágil" em que ele está (eu nunca participei de um): ele é convidado a escrever um pedaço de código para algumas especificações e, assim que terminar de testá-lo e está pronto para avançar em um novo requisito que exige que ele seja alterado e testado novamente. Ele acha isso frustrante.

Não estou me baseando no modo ágil, suspeito que a equipe não esteja agindo adequadamente - mas, como você diz, o termo "ágil" às vezes pode ser usado pelos cowboys para convencer a gerência pontuda de que o design incompleto é mais positivo do que negativo .

Tony Andrews
fonte
ágil sem testes automatizados está pedindo dores de cabeça
Steven A. Lowe
1

É engraçado como ninguém se considera codificador de cowboys. Estou apostando que muitos dos pôsteres são ou foram um;)

user5206
fonte
11
Eu suspeito que a maioria de nós começou como cowboys.
David Thornley
Você pode estar certo, e eu não tenho programado muito, mas quando eu estava em uma loja sem metodologia, tínhamos cowboys. Estou em uma empresa de consultoria ágil agora, e o que você faz é grande e visível, e é realmente difícil para mim imaginar um cowboy codificando desfrutando desse ambiente.
9118 Eric Wilson #
1

Os codificadores de cowboy são bons porque gostam de fazer as coisas rapidamente. Eles geralmente não estão tão preocupados com problemas gerais ou com a qualidade do código, e é por isso que o "codificador de cowboy" costuma ser um epíteto. Seus métodos atenuam os riscos de custo de oportunidade da entrega tardia do projeto.

Os programadores que não são cowboys gostam de trabalhar de maneira segura, disciplinada e ordenada. Eles gostam de construir certo e construir uma vez. Eles são conhecidos por coletar informações para sempre, considerando o que é se, produzindo grandes documentos que ninguém lê e entregando sistemas tarde ou muito tarde. Seus métodos tentam mitigar os riscos de um software de baixa qualidade.

O brilho das metodologias Agile é que elas aproveitam os pontos fortes de ambos os tipos de codificadores, forçando iterações de trabalho com prazos curtos que solicitam aos codificadores que produzam pequenos trabalhos de alta qualidade rapidamente. E cada iteração reduz os riscos de custo de oportunidade de entrega tardia e os riscos de software de baixa qualidade.

Jay Godse
fonte
0

A razão pela qual o ágil está enfatizando muito pouco o design / especificações iniciais não é apenas porque os requisitos podem mudar. A razão mais profunda é que, mesmo quando os requisitos são estáveis, as especificações tendem a ser:

  • incorreto - falha ao capturar os requisitos.

  • inconsistente - repleto de contradições, porque elas contêm informações suficientes para impossibilitar o escritor / leitor de capturá-las.

  • separado - eles não incorporam feedback valioso de um sistema em execução (embora degenerado).

Itay
fonte