O que é anarquia de desenvolvedor?


24

Eu tenho lido sobre Anarquia de desenvolvedor (ou programador), que parece ser considerada uma metodologia de desenvolvimento pós-Agile. Encontrei alguns recursos nele ( 1 , 2 ), mas não parece haver muito por aí.

Fiquei me perguntando se alguém tinha bons recursos para descobrir mais sobre isso - como implementá-lo, prós e contras, comparação com outras metodologias etc.


11
Eu nunca ouvi falar disso antes, mas me parece um pouco contraditório. Eles dizem "... formalidade e regras restringem a criatividade e a produtividade", mas ao mesmo tempo realizam reuniões regulares (como parte da metodologia?). Não acredito que a descrição de tal metodologia comece definindo uma regra.
Giorgio

Lendo sobre isso pela primeira vez, parece-me que foi feito por pessoa ou pessoas que só tiveram experiência com o Agile meia-boca. Porque essa "Anarquia do desenvolvedor" é um exemplo de livro didático de "agile corretamente". Por exemplo. implementado de forma ágil.
Euphoric

O primeiro link que você cita parece já conter tudo o que você está procurando.
Michael Borgwardt

2
Que palavra de ordem adorável!
precisa saber é o seguinte

11
@ CesarGon: Buzzwords são mais fáceis de inventar do que metodologias realmente novas. ;-)
Giorgio

Respostas:


46

Posso apontar os pensamentos de Alistair Cockburn sobre esse aspecto dos projetos "verdadeiros" do Agile:

Um membro da família de metodologias Crystal é o Crystal Clear. O Crystal Clear pode ser descrito para um ouvinte de nível 3 nas seguintes palavras:

“Coloque 4-6 pessoas em uma sala com estações de trabalho e quadros brancos e acesso aos usuários. Faça com que eles entreguem software testado e em execução aos usuários a cada um ou dois meses e os deixem em paz. ”

De fato, descrevi o Crystal Clear nessas palavras para um patrocinador experiente do projeto. Ele seguiu essas instruções e relatou cinco meses depois: "Fizemos o que você disse e funcionou!"

Entrevistei o líder da equipe alguns meses depois e seu relatório foi tão curto quanto minhas instruções:

“Seguindo sua sugestão, nós quatro assumimos a sala de conferências, que possui conexões de rede. Nós a mantivemos por todos os quatro meses, desenhando nos quadros brancos por lá, fornecendo software à medida que avançávamos. Funcionou muito bem. ”

é disso que trata o ágil, e parece que essa é a abordagem adotada pela metodologia Anarchy - o ponto é que, se você já experimentou caras , pode dizer a eles para "se afastarem e fazê-lo funcionar" e eles farão exatamente isso . (isso não funciona com pessoas menos experientes, você não deixaria uma equipe de juniores fazer isso sem pelo menos alguma supervisão).

Todo o barulho sobre o ágil criado ao longo dos anos, como standups diários e painéis de scrum, sessões de preparação do backlog do produto, reuniões pré-reunião sobre as reuniões de planejamento da sessão de preparação do backlog do backlog do produto .. são todas as coisas de peso pesado do projeto que devem ser vistas como despesas gerais para a entrega bem-sucedida do produto.

Hoje em dia, porém, essas coisas são vistas como obrigatórias e a metodologia 'ágil' desce para um sistema que possui mais processos do que os métodos antigos!


14
"Hoje em dia, porém, essas coisas são vistas como obrigatórias e a metodologia 'ágil' desce para um sistema que possui mais processos do que os métodos antigos!": Você atinge um ponto importante (+1). Eu tenho trabalhado com a SCRUM em uma equipe de desenvolvedores experientes e, depois de dois anos, é que ... éramos mais ágeis antes, quando não tínhamos reuniões diárias (costumávamos nos reunir duas vezes por semana) e muitas outras atividades aconteceu "quando a equipe decide que são necessários" em vez de "quando a metodologia os prescreve".
Giorgio

9
+1. Por fim, acho que essas metodologias são indicativas de um ciclo contínuo: metodologias pesadas falham repetidamente, (algumas) pessoas percebem que os programadores são inteligentes o suficiente para lidar com as coisas, raspar o processo e geralmente as coisas funcionam - mas o processo leve é ​​tentado com equipes pobres ou inexperientes, falha ou perde as estimativas, o processo é adicionado para aumentar a "certeza" e a "previsibilidade", e o ciclo continua.
asthasr

Gahhh ... esse ciclo parece preciso e deprimente.
Graham


11
@syrion: Você pode estar certo. Li em algum lugar que as práticas ágeis funcionavam para programadores experientes. Então, programadores experientes que treinavam equipes inexperientes precisavam escrever regras para eles (porque o treinamento contínuo custa muito e é melhor ter algumas regras anotadas em um livro). Dessa maneira, novas metodologias como SCRUM e similares se desenvolveram: agora as pessoas podem vender livros ou certificações. Mas o verdadeiro espírito do ágil é aplicar seu próprio senso comum, em vez de regras escritas por outros. Regras são diretrizes, mas são consideradas por muitos como uma religião.
Giorgio
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.