A abordagem ágil é uma desculpa conveniente para cowboys?

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.

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.

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]

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.

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

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.

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

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

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

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.

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.

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.

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.

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 .

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

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.

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