BT

Anarquia dos Programadores: um passo além do Agile?

por Roopesh Shenoy , traduzido por Fernando Ultremare em 07 Mar 2012 |

Fred George, no primeiro dia da conferência Agile Índia, compartilhou suas ideias sobre como ir além do Agile, atingindo um estado que chama de "Anarquia dos Programadores" (Programmer Anarchy). Através de exemplos de sua experiência na empresa britânica Forward Technology, George explicou como tal modelo pode levar a um ambiente extremamente produtivo na resolução de problemas complexos e ao aumento substancial de resultados.

George iniciou sua sessão com a introdução de conceitos do Framework Cynefin, através do qual estreitou o foco de sua apresentação sobre o domínio de problemas complexos. Seguiu com uma comparação entre a abordagem tradicional de desenvolvimento de software e a abordagem do Agile, no que diz respeito à eficácia para resolver problemas neste domínio de problemas.

George lembra que os métodos tradicionais determinam que o cliente defina o projeto e o repasse para que a empresa de desenvolvimento realize sua implementação. Já em projetos ágeis, existe uma parceria entre o cliente e a empresa (ou equipe) de desenvolvimento na condução do projeto.

No estado de Anarquia dos Programadores, por outro lado, essa característica do Agile é levada ao extremo. O cliente apenas apresenta o problema de negócio para a empresa ou equipe de desenvolvimento. Esta, em seguida, assume e dirige o projeto tornando-se totalmente responsável pela criação de valor para o negócio.

Ele cita um exemplo (parafraseando):

Tivemos que reescrever um sistema que foi previamente escrito em .NET e SQL e a equipe acabou utilizando várias tecnologias (Ruby, Clojure, Node.js, MySQL, MongoDB etc). O núcleo do sistema continha lógica de cálculo de contas de energia, com diversas condições e verificações complexas, e que estava distribuída por toda parte no sistema.

Como parte do nosso exercício de reescrita, reescrevemos o núcleo em Ruby com cerca de 600 linhas de código. Em seguida, reescrevemos a mesma parte em Clojure, com cerca de 300 linhas. Depois, o mesmo desenvolvedor reescreveu em Clojure com 200 linhas de código mais limpo do que a implementação anterior. Tudo isso com diversas novas funcionalidades que pretendíamos para o sistema original, e que nunca haviam sido implementadas.

Que gerente lhe permite reescrever o núcleo do sistema três vezes? Nenhum. É por isso que não temos gerentes!

Fred George explica que um ambiente tão radical como esse é possível porque os desenvolvedores entendem onde está o valor de negócio; as métricas de negócio são as únicas que são coletadas. Se a equipe comete erros, as métricas indicam esses erros e a equipe corrige os problemas. As entregas contínuas levam ao feedback contínuo e as ações corretivas podem ser tomadas quase que imediatamente. Os desenvolvedores são autoorganizados em quase todos os sentidos, inclusive nas tarefas de contratação e alocação de tarefas.

A mudança de Waterfall (Cascata) para Agile requer uma mudança radical de mentalidade e na confiança entre o cliente e a equipe de desenvolvimento. A mudança para a Anarquia dos Programadores requer ainda mais confiança, uma vez que o cliente perde essencialmente toda a sua impressão de controle sobre o projeto e passa a depender da equipe de desenvolvimento para agregar valor ao negócio. Além disso, a empresa aceita uma série de riscos: falhas são compreendidas como algo comum e uma oportunidade de se aprender rapidamente. Outra empresa que George indica conhecer com este tipo de trabalho orientado ao desenvolvedor e uma cultura de tolerância aos riscos, é o Facebook.

Os slides da apresentação de Fred George sobre a Anarquia dos Programadores está disponível online.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Muito bom by Paulo Moura

Infelizmente isso não é pra todo mundo.

Re: Muito bom by Diogo Capistrano

O que eu vejo aqui no Brasil sâo empresas se escondendo atrás do Agile, falando que fazem Agile, quando na verdade fazem a mesma coisa de antes só que usando outras ferramentas.

Re: Muito bom by Luciano Costa

Certamente não vai servir para todas empresas, assim como Agile ou CMMi não funcionam para todas.

O time em que trabalho hoje funciona da forma como descrita no artigo, mas vejo alguns requisitos/motivos para isso:

  • Equipe pequena - Somos 4 desenvolvedores. Não acho que funcionaria com 40.
  • Multidisciplinaridade - Papéis como 'programador', 'analista', 'testador', etc.. vão na direção oposta ao tratado no artigo.
  • Coragem - É preciso que alguém assuma a responsabilidade de mudar e dar autonomia ao time. No nosso caso, um dos sócios também atua como desenvolvedor. 50% dos méritos são dele!
  • Resultados - Talvez a coisa toda comece e termine por aqui. Se um pequeno experimento der certo, pq não dar continuidade a ele?


      Por iniciativa do time de desenvolvimento, atualmente postergamos a inclusão de novas funcionalidades. Nos dividimos para, durante o mês de março, reescrever algumas partes do sistema e iniciar uma versão mobile do mesmo. Mais uma vez tivemos o apoio de quem toma as decisões finais.

    Re: Muito bom by Pablo Leary

    Sem dúvida. Algumas equipes estão adotando o Agile mais o ScrumMaster continua com o papel de centralizador prepotente. O velho gerente.

    Re: Muito bom by Pablo Leary

    Poderia ser, estamos a caminho. Quando o elefante descobrir a força que tem , ninguém o segura . Quando os programadores tomarem frente o modo de organização vai mudar.

    Como um preso pode livrar o outro ? O gerente decide mais não programa. by Pablo Leary

    Podemos ter equipes anárquicas. É preciso ter coragem e agir em grupo . Os programadores são os que criam e os que devem decidir sobre projeto. Infelizmente temos a velha hierarquia : Diretor , gerente , programador.

    O diretor pressiona, o gerente bajula o diretor e programador é explorado. Caso um programador se rebele, ele é demitido e se contrata um programador obediente.

    Os programadores obedientes normalmente são : endividados, com família, ou outra situação que não pode haver risco. É nesse ponto que os gerentes sorridentes trabalham. São os velhos Capatazes, que bajulam os donos e exploram os subordinados.

    Apenas uma observação quanto a resolução de problemas by Charles Fortes

    Vivi essa situação em uma startup que tinha tudo pra se dar bem... (pena que não deu)

    O cenário teve estes resultados como ditos na notícia, mas teve um porém que não vi (pode ser que no estudo o tenha, não o li ainda). A resolução de problemas complexos é rápida e são impressionantemente boas, porém problemas menores muitas vezes geram discussões enormes e desnecessárias. Em principal por necessitarem de uma equipe muito TOP (tecnicamente), e que devido a esta característica, acaba tendo pessoas com ego frágil.

    Fábricas de softwares by Giulliano Morroni

    Há tempos que eu venho trabalhando desta forma, solicitando às pessoas que me passem seus problemas ou a sua necessidade. E senti que a maioria tende a dar o problema e citar ou impor a solução que ela quer. Os melhores projetos que desenvolvi foram baseados em problemas expostos, com a solução definida por mim.

    Isso só ocorre quando o programador está diretamente envolvido com o projeto, não através de um contrato empresa x empresa, mas através de uma expectativa de ver o resultado de seu trabalho.

    Como no Brasil temos ainda o modelo de fábricas de software usando cascata, esse modelo de processo acaba sendo usado pelas empresas startups.

    HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

    Receber menssagens dessa discussão

    HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

    Receber menssagens dessa discussão

    8 Dê sua opinião

    Conteúdo educacional

    Feedback geral
    Bugs
    Publicidade
    Editorial
    InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
    Política de privacidade
    BT