É a abordagem ágil muito de uma desculpa conveniente para cowboys

72

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

No entanto ... Em meu trabalho profissional, continuo indo parar em empresas onde uma abordagem "ágil" é usada como desculpa para que nenhum esforço seja colocado em uma frente design; quando os requisitos são bem compreendidos.

Eu 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 não tendo que revisitar a mesma tela e funcionalidade a cada segundo dia quando alguma outra coisa mais ou menos e assim não tinha pensado nisso.

Are the benefits of agile methodologies really enough to outweigh the excuse for being lame it gives to cowboy technical leads?

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

    
por Jim G. 24.02.2012 / 01:16
fonte

16 respostas

86

Eu acredito que se você estiver usando o desenvolvimento Agile como uma desculpa para programação estilo cowboy, então você não está realmente seguindo o desenvolvimento Agile. Cowboys sempre serão cowboys, não importa o processo que você lhes der.

    
por 12.10.2010 / 07:19
fonte
20

O Agile não é mais responsável por práticas de desenvolvimento ruins do que o BDUF. O problema está na disciplina, ou 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 de antemão. O objetivo das práticas ágeis é manter o estado do desenvolvimento flexível o suficiente para mudar rapidamente de direção. Um projeto ágil poderia preparar histórias de usuário altamente detalhadas para que a equipe esteja ciente das direções futuras e ainda selecione apenas 2 ou 3 por iteração para implementar totalmente. O problema permanece o mesmo, seja qual for a metodologia usada: a administração está deixando os caubóis correrem mal.

[BDUF: Big Design Up Front]

    
por 25.04.2011 / 19:40
fonte
13

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 em algumas metodologias Agile , como o Scrum , é que elas fornecerão muita visibilidade sobre problemas dentro da organização. Incluindo problemas dentro da equipe!

Você terá a oportunidade de resolvê-los assim que surgirem.

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

    
por 12.10.2010 / 17:25
fonte
12
Estranhamente, a partir dos projetos "ágeis" com os quais estive envolvido, parece mais uma desculpa para o gerenciamento pular a fase de coleta de requisitos do que o desejo de um caubói de simplesmente começar a codificar. Meus projetos foram extremamente frustrantes porque não temos nenhum usuário final para interagir. Em vez disso, temos um diretor que fala sobre vendas para descobrir o que eles acham que os clientes querem, depois convoca uma reunião e a descreve para os gerentes, que então começam a atribuir tarefas aos desenvolvedores. Em um projeto "bom" podemos ter uma apresentação de PP para se referir, mas geralmente acabamos gastando nossas reuniões diárias de scrum perguntando como alguns recursos devem funcionar, e o gerente anota as perguntas e pergunta ao diretor. É uma enorme perda de tempo - mas é "ágil"!

    
por 12.10.2010 / 14:44
fonte
7
Não vou dizer que sou fã de Waterfall, já que eu também luto com o sempre frustrante escopo, mas eu sempre vi o Agile como uma concessão ao problema, não uma maneira eficaz de combatê-lo. Um bom design, com testes iterativos e muitos protótipos de papel, parece ser muito mais eficaz.

    
por 12.10.2010 / 06:54
fonte
6

Estou vendo as defesas do Desenvolvimento Ágil dizendo que não é responsável por falhas causadas por caubóis. Sucesso com 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 caubóis, você não pode culpar metodologias não ágeis por falhas de projeto causadas por caubóis.

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

É claro que, se aceitarmos que os caubóis podem não estar uniformemente distribuídos entre as metodologias, e aceitarmos que os vaqueiros 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 próximo de ser infalsificável. Esta é uma das questões que me fazem envergonhar a minha profissão - a falta de base científica para muitas das alegações.

(A propósito, eu odeio chamar a (s) alternativa (s) a "cascata" Agile, porque processos em cascata parecem ser um palhaço que todos atacam, mas muito poucas pessoas realmente usam sem qualquer iteração.)

    
por 12.10.2010 / 18:11
fonte
5

O Agile está bem desde que esteja funcionando para sua equipe.

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

Eu gosto de muitas das ideias por trás da agile, mas a falha que vejo uma e outra vez é que os gerentes estão forçando um conjunto rigoroso de "processos ágeis", que se contrapõe a todo o conceito de agile, que as equipes deve ser auto-organizado.

No que diz respeito a "cowboys", acho que para todos os times ágeis em que estive, os processos servem para atrasá-los mais do que deixá-los enlouquecer. Eu nunca experimentei uma situação em que a agile servia para ativar um "codificador cowboy".

Para boas equipes, parece funcionar bem (então, novamente, 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 fazer melhor, mas às vezes serve para atolar as pessoas produtivas.

No geral, acho que o importante é construir uma boa equipe, dizer a eles o que você precisa e depois sair do caminho. Eu não acho que a aplicação de qualquer série de chavões provavelmente resolverá o problema de ter um time ruim.

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

    
por 12.10.2010 / 18:31
fonte
3

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

Eu quero adicionar que "Agile" é realmente uma interface (eu estou usando uma metáfora orientada a objetos aqui) e você não pode instanciá-lo. Se a sua implementação concreta é XP , então você tem que seguir um monte de práticas técnicas com muita disciplina, o que deixa pouco espaço para a programação do cowboy. Outra possibilidade é que o trabalho em equipe de uma equipe Scrum auto-organizada irá mantê-lo sob controle.

    
por 12.10.2010 / 16:29
fonte
3

Codificadores Cowboy também tendem a escrever código que não é muito testável, e eles tendem a não gostar de escrever testes. Eu acho que ter todo mundo fazendo TDD pode ajudar a reinar na atitude cowboy e fazer os desenvolvedores pensarem sobre arquitetura um pouco mais. Nenhuma metodologia é perfeita, claro.

    
por 12.10.2010 / 18:29
fonte
3

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

A organização sempre operou uma abordagem relativamente solta, "informal, ágil". Eu não diria que é realmente ágil, é mais "ágil no nome", mas simplesmente uma metodologia inexistente na prática. Equipes diferentes operam de maneira diferente, mas como a cultura organizacional geral não tem metodologia alguma além de um processo muito ágil "Agile in name only" - é relativamente caótico e caótico no geral - especialmente na 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á alegando ser Agile - eu faria algumas perguntas bastante difíceis na entrevista para garantir que mais do que apenas um equívoco do Agile esteja sendo seguido.

    
por 13.10.2010 / 00:35
fonte
2

Descobri que os usuários só podem nos fornecer feedback quando tiverem um aplicativo que possam usar, telas nas quais possam inserir dados. Só 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 ultrapassando o orçamento, mas o aplicativo será alterado assim que você o disponibilizar. Sua primeira versão não é mais do que um protótipo para os usuários discutirem quais deveriam ter sido os requisitos. Então, eu prefiro chamá-lo de ágil do que de orçamento.

    
por 13.10.2010 / 10:03
fonte
2

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

Visualizar a metodologia como um controle para os atributos do processo implica um par de coisas: 1) sem métricas não podemos comparar a eficácia de uma metodologia sobre outra, 2) uma decisão ativa precisa ser feita sobre quais atributos são importantes tempo vs qualidade de código vs transferência de conhecimento).

Sem ter métricas e objetivos tangíveis, simplesmente escolhemos uma metodologia como nossa "pena mágica", que, se nos mantivermos firmes, poderemos fornecer software.

Agora, os simuladores do Agile, XP, Scrum, etc. falam sobre a fragilidade dessa categoria particular de metodologias. O argumento é: por que usar uma metodologia que pode ser sabotada por um indivíduo que não tem disciplina para seguir todas as regras? A questão é válida; entretanto, esse é o sintoma, não a causa. Se um conjunto de métricas de processo preciso e significativo (que é a parte difícil) for definido, testado e respondido em tempo real, acho que descobriremos que a metodologia específica tem pouco a ver com o sucesso. (Curiosamente, vi projetos bem-sucedidos usando uma miríade de metodologias e o dobro de falhas usando as mesmas metodologias)

Então, quais são as métricas? Eles variam de projeto para projeto, de equipe para equipe e de vez em quando. Útil para quando o cronograma de entrega é importante, um que eu pessoalmente usei é habilidade de estimativa e qualidade. A maioria dos desenvolvedores pode estimar com precisão tarefas com duração de uma semana ou menos. Portanto, uma abordagem é dividir o projeto em tarefas de uma semana de desenvolvimento e acompanhar quem fez a estimativa. Conforme o projeto avança, eles podem alterar suas estimativas. Depois que uma tarefa é concluída, se ela estiver desativada em mais de 10% (1/2 por dia), tratamos isso da mesma forma que um bug - identificamos porque a estimativa estava desativada (isto é, uma tabela de banco de dados não foi considerada). ação corretiva (ou seja, envolver o DBA na estimativa) e, em seguida, seguir em frente. Usando essas informações, podemos criar métricas como # erros de estimativa por semana, # de erros por desenvolvedor, # de erros por KLOC, # de erros por desenvolvedor-KLOC, etc. Publicar esses números no wiki da equipe fornece uma pressão social séria e a partir da perspectiva gerencial, depois de algumas semanas, você pode gerar um modelo preditivo de semanas subseqüentes de desenvolvimento.

Então o que? É aí que entram as metodologias - se você tem um modelo preditivo que não atende às qualidades do processo, pode optar por adicionar ou remover algum aspecto da metodologia e ver como isso afeta seu modelo. É claro 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 descobrir que o Agile é a metodologia perfeita para sua equipe, mas você pode facilmente encontrar o RUP, o cascata ou apenas uma miscelânea de práticas recomendadas como ideal.

Portanto, minha sugestão é que deixemos de nos preocupar com o que chamamos de processo, implementemos verificações que sejam relevantes para as metas do processo de desenvolvimento e experimentemos diferentes técnicas para melhorar esse processo.

    
por 27.10.2010 / 23:04
fonte
1

I'd be sitting here with a nice high level specification and not having to revisit the same screen and functionality every second day as something else crops up or so and so hadn't thought of that.

Isso parece concordar com a experiência do meu colega com o projeto "ágil" em que ele está (eu nunca estive em um): ele é solicitado a escrever um pedaço de código para algumas especificações, então assim que ele terminar testá-lo e está pronto para avançar em um novo requisito que requer que ele o altere e faça um novo teste. Ele acha isso frustrante.

Eu não estou atacando ágil, eu suspeito que o time não está agilizando corretamente - mas como você diz, o termo "ágil" às vezes pode ser usado por caubóis para convencer o diretor que o design meio cozido é positivo do que um negativo.

    
por 12.10.2010 / 12:18
fonte
1

É engraçado como ninguém pensa em si mesmo como codificadores de cowboys. Estou apostando que muitos dos cartazes são ou foram um;)

    
por 13.10.2010 / 00:02
fonte
1

Codificadores Cowboy são bons porque gostam de fazer as coisas rapidamente. Eles geralmente não estão tão preocupados com questões de grande porte ou qualidade de código, e é por isso que "codificador cowboy" é muitas vezes um epíteto. Seus métodos mitigam os riscos de custo de oportunidade da entrega tardia do projeto.

Codificadores não-vaqueiros gostam de fazer seu trabalho de maneira segura, disciplinada e organizada. Eles gostam de construir direito e construí-lo uma vez. Eles são conhecidos por sempre coletar informações, considerando o que são, produzindo documentos grandes que ninguém lê, e entregando sistemas tarde ou muito tarde. Seus métodos tentam atenuar os riscos de softwares de baixa qualidade.

O brilho das metodologias Ágeis é que elas aproveitam as forças de ambos os tipos de codificadores, forçando iterações de tempo limitadas que pedem aos codificadores para produzir rapidamente pequenos trabalhos de alta qualidade. E cada iteração atenua os riscos de custo de oportunidade de entrega atrasada e os riscos de software de baixa qualidade.

    
por 19.03.2011 / 18:28
fonte
0

O motivo, enquanto ágil, é colocar muito pouca ênfase no 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.

  • inconsistentes - cheias de contradições porque contêm informações suficientes para impossibilitar que o escritor / leitor as capture.

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

por 12.10.2010 / 17:44
fonte