AkitaOnRails

Off-Topic: O Manifesto Ágil, ou Como se Tornar o Google

2008 October 07, 03:39 h

Não sou um dos melhores estudiosos de metodologias Ágeis que existe, nem de longe. Por isso vou me dar ao luxo de seguir uma visão talvez “ingênua” sobre o que eu pessoalmente enxergo sobre o assunto. E eu sei, eu sei, a palavra “Google” no título é mais para chamar a atenção. No final eu explico ;-)

Antes de mais nada, quero separar duas coisas: metodologia e filosofia. A parte mais relevante sempre é a filosofia. Se uma empresa/profissional não absorveu a filosofia Ágil dificilmente será verdadeiramente Ágil por mais que se implemente uma metodologia, ou seja, uma série de procedimentos. Você pode até ler receitas de pratos franceses, mas até entender como um cozinheiro de verdade pensa, até adquirir a cultura francesa, dificilmente terá pratos franceses decentes, apenas cópias mecânicas de baixa qualidade.

O importante não é o “como” e sim o “porquê”. O Manifesto Ágil diz isso já no seu primeiro valor. Vamos relembrar os quatro valores Ágeis:

Estamos descobrindo melhores maneiras de desenvolver software fazendo isso e ajudando outros a fazê-lo. A partir desse trabalho temos os seguintes valores:

  • Indivíduos e interações mais que processos e ferramentas
  • Software que funciona mais que documentação completa
  • Colaboração do cliente mais que negociação de contratos
  • Responder à mudança mais que seguir um plano

Quer dizer, mesmo que exista valor nos ítens da direita, nós valorizamos mais os ítens da esquerda.

O primeiro valor já diz tudo: indivíduos mais que processos.

Neste artigo quero mostrar porque a grande maioria das empresas não é efetivamente Ágil, mesmo quando implementam “metodologias” Ágeis.

Princípios por trás do Manifesto Ágil

Para recapitular, será útil citar os 12 Princípios por trás do Manifesto de Valores. Muita gente já leu todos esses ítens. Mas “ler” e “entender” são duas coisas completamente diferentes. Para efeitos da minha explicação, vou colocar algumas palavras-chave em negrito para me referir a elas mais tarde.

Nós seguimos estes princípios:

O Quinto Elemento

“Construímos projetos através de indivíduos motivados. Dê-lhes o ambiente e suporte que precisam, e confie neles para ter o trabalho executado.”

Eu realmente não sei como os fundadores do Manifesto chegaram a estes princípios, mas baseado apenas neste ponto imagino que eles sejam realmente muito experientes. Este elemento, para mim, é o mais denso de todos os Princípios.

Corolários ao Quinto Elemento são o 11o e 12o Elementos. Vou explicar porque.

Escalando Agilidade

Recentemente eu citei um capítulo do livro Scaling Lean and Agile Development: Successful Large, Multisite and Offshore Products with Large-Scale Scrum. Acredito que muita gente não teve paciência para ler, por isso vou resumir a parte que me interessa.

Esse PDF discute as diferenças entre Feature Teams e Component Teams. De forma simplificada, uma equipe Ágil é necessariamente uma Feature Team, ou seja, uma equipe que é o mais independente possível e assume um produto ou uma feature completa de um produto, do começo ao fim, dos requerimentos até o contato com o cliente.

Um Componente Team é o estilo tradicional e departamental. Cada equipe é responsável apenas por um trecho de vários produtos. Equipe de interfaces, equipe de infra-estrutura, equipe de arquitetura, equipe de componentes visuais, equipe de banco de dados, equipe de qualidade e assim por diante.

Uma Feature Team é uma equipe cross-funcional, normalmente formada por generalistas. Uma Component Team é uma equipe limitada, formada normalmente por especialistas. Uma Equipe Scrum é, por definição, uma Feature Team, capaz de realizar todo o trabalho de um ítem de um Product Backlog.

Como eu disse antes, esqueça o “como” por enquanto.

Lei de Conway

Melvin Conway, em abril de 1968 escreveu uma pesquisa onde um trecho dela entraria para os anais da história da computação:

“Qualquer organização que faz design de sistemas (definição ampla) produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da empresa”

Como está explicado em seu site, o famoso Frederick Brooks citou essa pesquisa e sua idéia no clássico (que todo profissional da área de tecnologia deveria ler) The Mythical Man Month, chamando essa idéia de Lei de Conway. Brooks reconheceu que a lei tinha corolários importantes em teorias de gestão. Aqui vai uma afirmação sua:

“Como o design que acontece primeiro quase nunca é o melhor possível, o conceito de sistema que permanece pode precisar de mudanças. Portanto, flexibilidade da organização é importante para design efetivo.”

Como eu já disse em Matando a Média até hoje ainda aplicamos metodologias e processos Gaussianos. Ainda não consegui escrever um material mais completo que explique isso, portanto assista ao vídeo que gravei e leia os materiais de referência que indico nele. Por enquanto apenas entenda que a grande maioria do que conhecemos como verdades incontestáveis da Teoria das Organizações não se aplica mais.

Essas Teorias antiquadas, que delineiam cadeias de comando rígidas, diversos departamentos “feudais”, cultura baseada em cargo e poder político, foram feitos essencialmente para dar grande grau de controle a chefes de seção em linhas de fábricas do século XIX, onde o máximo que se esperava de um trabalhador era que ele apertasse parafusos e não executasse muitos trabalhos que exigissem o cérebro.

Como diz a Lei de Conway: as equipes tendem a criar estruturas que espelham a estrutura da organização. O corolário disso é: tenha uma empresa que incentiva o trabalho medíocre e suas equipes serão medíocres. Como eu falava sobre o Quinto Elemento: “… dê-lhes o ambiente e o suporte que precisam …”

O PDF de Larman menciona Brad Silverberg, VP sênior do Windows e Office que enfatizou:

“O software tende a refletir a estrutura da organização que a construiu. Se você tiver uma organização grande e lenta, você tende a construir software grande e lento.”

Uma afirmação irônica, mas verdadeira.

Generalistas vs Especialistas

Empresas tradicionais que se iludem achando que conseguirão controle total de suas equipes apenas conseguem criar funcionários pouco produtivos, sem atitude, sem perseverança, comodistas, limitados e que nunca aprenderão nada de novo.

Isso porque o estilo de Controle Total, prefere a divisão de trabalho, como em linha de chão de fábricas, onde cada equipe faz uma parte do todo. Nesse estilo de gestão reina o incentivo aos Especialistas.

Especialistas são aqueles funcionários que normalmente começaram determinado pedaço do sistema e apenas eles sabem como aquele pedaço funciona. Eles não se sentem muito confortáveis em dividir esse conhecimento e se sentem menos confortáveis ainda em aceitar mudanças externas. Ele costuma ser tratado como herói porque quando há urgência, não há tempo para outra pessoa aprender sobre aquele pedaço e apenas ele consegue resolver o problema.

Se você tem heróis desse tipo em sua empresa, esses devem ser os primeiros a ser despedidos.

Não é à toa que equipes Scrum são, por definição, Feature Teams. Caso contrário o primeiro efeito que vem à tona é o seguinte:

Reconhecem isso? Cada Component Team faz seu Sprint, sua iteração. Somente quando a iteração de uma equipe acaba, a da outra pode começar. Isso justamente porque nenhuma das equipes comanda a Feature completa e depende de pedaços das anteriores.

Isso tem um nome: bem vindos de volta ao Waterfall! Não importa que costumem chamar isso de mini-waterfall, cascata é cascata, não importa o tamanho delas.

Outros grandes efeitos colaterais de Component Teams: como ninguém é efetivamente o dono do produto, nenhuma das equipes se sente responsável pelo todo, apenas por sua parte. Naturalmente emergem os comportamentos de “a minha parte eu fiz, a culpa é da outra equipe.”

Além disso, Component Teams, por sua própria natureza de lidar apenas com um tipo de problema, força seus integrantes a se tornarem especialistas. E fazendo assim, força esse profissional a limitar seus conhecimentos, não dando absolutamente nenhuma motivação para aprender coisas novas.

Lembram do Quinto Elemento? “Construímos projetos através de indivíduos motivados …” Onde estão os indivíduos motivados numa organização que força todos à mediocridade? Claro, não quer dizer que todos devem saber tudo de tudo, sempre haverá uma ou mais disciplinas onde cada profissional se adeque mais, mas todos devem ser incentivados a saber um pouco de todo o resto. Por isso mesmo Feature Teams são importantes: você tem vários especialistas onde cada um sabe um pouco das coisas diferentes que seu colega do lado sabe fazer. E com isso Pair Programming ganha novo significado.

Além disso Test Driven Development começa a fazer muito mais sentido se a equipe é realmente responsável por um produto/feature que agrega valor de verdade ao cliente final. Uma vez que não há dependência entre equipes fica muito mais claro como realizar os testes completos. Mas há outra questão sobre testes que vou explicar mais abaixo.

Auto-Organização

Este é o ponto crucial nas novas teorias organizacionais. Don Tapscott e Anthony D. Williams chamariam isso de Wikinomics ou a economia da colaboração.

As organizações tradicionais tem horror ao caos e por isso perseguem controle absoluto de maneira patológica, o suficiente para ser prejudicial.

E eles deveriam mesmo ter horror ao caos. Mas o que elas precisam entender é que existe o fenômeno de ordem que emerge a partir do caos.

Estamos acostumados a pensar em eventos isolados, em resultados baseados na soma de eventos independentes. Coloque uma colher de açúcar e o chá fica doce. Coloque duas colheres de açúcar e o chá fica duas vezes mais doce.

Porém, sistemas dinâmicos não podem ser definidas dessa forma. Certos sistemas são muito sensitivos a condições iniciais, dando resultados não lineares. Em particular, fenômenos naturais como relacionamentos sociais, cadeias alimentares, eventos econômicos, são todos sistemas não lineares.

Isso retorna à minha palestra sobre Distribuições Power Law, ou Distribuições de Pareto. Recapitulando, um mundo platônico e linear pode ser modelado segundo Gauss. Esse tipo de distribuição é extremamente confortável para os analistas pois possui média definida e desvio padrão constante, estável. Power Laws, por sua vez, são caracterizados pela ausência de média e desvio padrão que tende ao infinito!

O ponto mais óbvio é que “Bell Curves” (curvas em forma de sino) como a Normal/Gauss, exigem eventos independentes, isolados, como jogar dados ou tirar cara ou coroa em uma moeda não viciada. Não é difícil ver, por exemplo, que comportamento de seres humanos pode ser tudo, menos independentes: por definição, humanos se relacionam entre si, logo formamos sistemas altamente dependentes.

Mas algo importante em redes dinâmicas, ao contrário do que se imaginava, não formam redes com conexões aleatórias – cuja distribuição seria Normal – mas sim exibem distribuição de Pareto. Albert-László Barabási explica em mais detalhes a formação de Redes Scale-Free

Como eu dizia, se alguém pensa em nós (pessoas, animais, neurônios, vírus) e conexões (amizade, transmissão, sinapse), é mais natural primeiramente imaginar que os nós se conectem de forma aleatória e caótica. Porém, os estudos de Barabási e as observações detalhadas dos fenômenos naturais levou à conclusão que elas tendem a formar redes scale-free, cuja distribuição de nós segue Pareto, ou seja, poucos nós concentram a grande maioria das conexões e muitos nós dividem as poucas conexões restantes, formando algo assim:

Para nós de tecnologia, isso se pareceria com a representação da Internet, onde os nós são websites e as conexões são, literalmente, os links entre elas. Mas é isso mesmo: a Internet segue uma distribuição de Pareto.

Para os que tem tendências socialistas, esqueçam Marx, ele estava obviamente errado ao se inspirar na curva de Gauss e tentar rebaixar toda a sociedade à média. O pensamento de “tirar dos ricos para dar aos pobres” é totalmente anti-natural. O natural é exatamente o oposto: poucas pessoas vão sempre deter a grande maioria da riqueza do mundo, enquanto a maioria das pessoas terá menos riquezas. A única forma de os pobres enriquecerem é fazer o sistema inteiro enriquecer, incluindo os próprios ricos. A natureza sempre privilegia a meritocracia, nunca a mediocridade.

Assumindo que todos estudem mais um pouco sobre Barabási, Poincaré, Mandelbrot, Zipf, Pareto, Bak e assuntos como redes scale-free, power laws, self-organized criticality, phase transition, chaos, fractals, vamos concluir algo rapidamente: a ordem costuma sim emergir do caos, redes se formam como Barabási descreveu, através de mecanismos como preferential attachment e no final teremos redes scale-free, auto-organizadas.

80/20

A famosa regra 80/20 de Pareto não veio a partir do nada. Num estudo na Itália muitos anos atrás, Wilfredo Pareto constatou que 80% do território italiano esta nas mãos de não mais do que 20% da população. Daí o “80/20”.

Essa divisão é justamente o que mostra uma distribuição de Pareto, conforme figura abaixo:

Como Chris Anderson explica em seu livro The Long Tail, pensa na famosa Wikipedia. Na época da publicação de seu livro em 2006 a Wikipedia já tinha 860 mil artigos, contra 80 mil da Enciclopédia Britannica.

A idéia de Jimmy Wales foi ousada e bastante controversa apesar da boa intenção de fornecer uma rica e extensa enciclopédia gratuita a todas as pessoas do mundo, incluindo crianças pobres em países sub-desenvolvidos que de outra forma talvez nunca tivessem acesso à informação.

Wales começou com o projeto Nupedia em 2000, com apenas alguns poucos verbetes e uma idéia que na realidade se popularizou antes disso, com Linus Torvalds e seu Linux: criar uma plataforma totalmente aberta (livre, liberdade) onde qualquer pessoa que quisesse poderia contribuir, revisar, refinar.

Olhando hoje, em 2008, todos diriam que Jimbo (como é conhecido) é um gênio. Mas no ano 2000, ele foi considerado um louco. Quando vemos as coisas em retrospectiva sempre é muito mais simples de criar uma narrativa que encaixa-se perfeitamente nos eventos que já aconteceram. Como Nassim Nicholas Taleb diria: depois que um Cisne Negro acontece, é fácil explicá-lo, mas antes que ele aconteça é impossível prevê-lo.

Seguindo o exemplo de Torvalds, Jimbo criou um ambiente adequado para colaboradores. Ele foi capaz de motivar as pessoas e, principalmente, confiar nelas, pois ao contrário do sistema editorial tradicional, não haveria editores ou filtros: tudo o que qualquer um digitasse estaria imediatamente disponível. Sua esperança é que erros grosseiros seriam rapidamente corrigidos pelos próprios colaboradores, assim como Eric S. Raymond descreve no clássico The Cathedral and the Bazaar:

“Dada uma quantidade suficiente de olhos, todos os bugs são superficiais”

Eric chamou essa afirmação de “Lei de Linus”, que também pode ser explicada como “dada uma quantidade suficiente de beta-testers e co-desenvolvedores, quase todo problema será encontrado rapidamente e a correção será óbvia para alguém.”

A Wikipedia se valeu dessa mesma Lei: num sistema dinâmico, aberto, onde os colaboradores começam a participar lentamente, evoluindo para uma rede scale-free auto-organizada, erros vão acontecer, mas a maioria deles será rapidamente corrigida. O benefício de se conseguir informações de milhares de pessoas espalhadas pelo mundo é ordens de grandeza superior aos pequenos defeitos que aparecem de vez em quando.

Num modelo de controle tradicional, costuma se pensar como na Britannica: poucos verbetes mas todos muito corretos. Qual vale mais: 80 mil verbetes com taxa de erro perto de zero, ou quase 1 milhão de verbetes com uma pequena taxa de erros? Alguns críticos retrógrados continuam achando que 1 pequeno erro na Wikipedia invalida 1 milhão de grandes acertos.

Software como Arte

Pete McBreen já escreveu em 2001 sobre Software Craftsmanship e eu sou um defensor dessa definição.

Muita gente pensa em Software, programação como Engenharia. Sinto informá-los de que não é. Software é música. Desenvolvimento de Software é muito próximo de se compor uma música.

Software é pintura. Desenvolver Software é como pintar um quadro. Sem querer diminuir a área da engenharia, que já nos trouxe maravilhas incríveis pelo mundo todo como a Muralha da China, as pirâmides do Egito, mas no caso específico de software é muito mais simples pensar nela como Engenharia do que como Arte.

Novamente, o mesmo motivo: tentativa de controle, afinal engenharia é previsível, é controlável, é mensurável. Arte é criativa, rebelde, imprevisível, caótica. Acho muito interessante que muitos dos grandes nomes do passado como Pitágoras, Da Vinci, foram grandes generalistas, artistas mas com muitos trabalhos nos campos da ciência e matemática. É exatamente isso que um desenvolvedor de software precisa ser: um artista da Renascença.

Como eu disse antes, um membro de uma Feature Team tem algumas especialidades, mas tem a mente absolutamente aberta a tentar novas coisas, a aprender novos ofícios, a explorar e criar.

Arte não pode ser implementada apenas lendo procedimentos. E é exatamente isso que muitos dos que se entitulam “desenvolvedores” ou “programadores” fazem: aprendem uma (ou poucas) maneira de fazer as coisas e continuam fazendo conforme lhe foi ensinado. Artistas aprendem a partir de mentores, treinam incansavelmente num longo processo de tentativa e erro, inspiram-se nos trabalhos de outros mestres, entendendo suas técnicas e tentando mesclá-las às suas próprias.

Apesar de não ser uma verdade absoluta, eu tendo a achar que desenvolvedores de software que participam ativamente de projetos Open Source, como um Linux, são programadores muito mais completos do que programadores que saíram da faculdade e passaram a integrar “Component Teams” dentro de organizações tradicionais. Especialmente se ficaram anos demais na mesma organização.

Um programador especialista, membro de um Component Team, numa organização gaussiana tradicional, é exatamente como um pintor de parede: sabe apenas passar o rolo de cal de cima para baixo, simetricamente, sem um pingo de criatividade e sem absolutamente nenhum talento ao aprendizado e à auto-evolução.

80% do perfil profissional de um funcionário é reflexo direto da organização onde trabalha – os outros 20% são culpa do próprio funcionário que não aceita sair da zona de conforto. Ambos tem 100% da culpa por apenas 29% dos projetos de software serem considerados sucessos. Ambos tem 100% da culpa pelo custo de USD 55 bilhões gastos em projetos de software cancelados. (fonte: Standish Chaos Reports)

Mundo Open Source

Acredito que não seja necessário explicar muito mais sobre projetos open source. Não há milagres: não significa que simplesmente porque um projeto é de código-aberto que ele automaticamente terá tanto sucesso quanto o Linux. Muito pelo contrário: centenas de projetos nunca chegam a ver a luz do dia.

Novamente, estamos falando de Pareto, talvez apenas 20% dos projetos open source realmente tenham grande sucesso. Porém, os outros 80% são identificados como fracasso muito mais rapidamente, alguns se mesclam em projetos maiores, alguns simplesmente páram. A decisão de parada é muito mais rápida e efetiva do que em projetos tradicionais corporativos que já investiram recursos (tempo e dinheiro, além da reputação de alguns dos envolvidos).

Com tudo que expliquei acima, fica fácil entender que projetos Open Source começam com condições iniciais simples: uma idéia, uma pequena implementação, poucas pessoas. Também começa a fazer sentido entender como elas evoluem do caos para redes scale-free através de auto-organização.

Não é difícil entender que esses projetos não tem como ser implementados através de consenso prévio muito rígido, só poderia evoluir para Feature Teams onde os colaboradores normalmente tem habilidades diferentes e complementares.

Também não é difícil entender que, como na Wikipedia, os verbetes mais importantes e/ou mais conhecidos são preenchidos primeiros, depois os mais obscuros são preenchidos com o tempo. No melhor estilo Pareto, 20% das prioridades acontecem primeiro. Num ambiente onde os recursos costumam ser escassos (não existe presença física, os colaboradores são voluntários, motivas as pessoas é ainda mais importante), realmente as prioridades – que dão mais valor ao grupo como um todo – são implementadas primeiro.

Em se entendendo Software como Arte, também fica simples entender que desenvolvedores que participam de vários projetos open source estão automaticamente expostos a muitas diferentes expressões de arte e, como tal, a diferentes maneiras de se implementar software. Um bom desenvolvedor começará a incorporar essas diferenças em seu próprio estilo, automaticamente melhorando muito a qualidade do seu trabalho.

Um desenvolvedor, sozinho, ou numa equipe conhecida, tem muito pouco motivo para criar testes do seu próprio código. Mas quando se vê numa situação onde está colaborando numa comunidade onde qualquer desconhecido poderá ver seu código e, portanto, aferir sua reputação, a motivação para criar código de boa qualidade, decentemente coberta com testes, fica mais óbvio. Daí porque eu disse antes que Test-Driven Development começa a fazer não só mais sentido como se torna uma real necessidade.

O idealizador do projeto, o desenvolvedor ou grupo de programadores que iniciou o projeto, necessariamente serão obrigados a gerenciá-lo. E num ambiente aberto, onde as pessoas não tem cargos, não tem salários, não tem chefes nem clientes diretos, vai por baixo qualquer tentativa de se usar técnicas gaussianas de gerenciamento tradicional de projetos. Agora estamos falando de projetos de verdade, sem a zona de conforto do cubículo. O mantenedor do projeto se verá numa posição onde será obrigado a tomar decisões. Entenderá rapidamente que é impossível obter unanimidade em todos impasses e por isso vestirá o chapéu de ditador benevolente, ou seja, um ditador que se for rígido e autoritário demais irá afastar todos os seus colaboradores (que não tem obrigação nenhuma de seguí-lo) e que se for flexível demais se arriscará a demonstrar insegurança, indecisão, morosidade e por fim poderá motivar um coup um tipo de “golpe de estado”, onde seu projeto será clonado e outro mantenedor mais carismático e efetivo poderá tomar seu lugar. Ou pior: seu projeto pode simplesmente parar e deixar de existir.

Não existe ambiente mais hostil mas ao mesmo tempo mais recompensador para um verdadeiro gerente de projetos do que projetos open source. Tire de um Gerente o seu cargo e seu poder e só então poderá avaliar se ele realmente sabe o que significa “gerenciar”.

Princípios Ágeis, Redux

Tudo isso dito, acho que podemos recapitular o 6o, 11o e 12o princípios novamente:

  • Construímos projetos através de indivíduos motivados. Dê-lhes o ambiente e suporte que precisam, e confie neles para ter o trabalho executado.
  • As melhores arquiteturas, requerimentos, e designs emergem de equipes auto-organizadas.
  • Em intervalos regulares, as equipes refletem sobre como se tornar mais efetivos, então ajustam seu comportamento de acordo.

Os outros princípios são consequência:

Dado um ambiente adequado, com profissionais efetivamente elevados acima da média, motivados podemos realmente confiar em suas capacidades de auto-organização, onde a própria estrutura orgânica e não hierarquizada naturalmente levará seus membros a reajustarem sua rotina de acordo com os problemas enfrentados, levando-os a gerar código de qualidade, onde apenas o essencial está realmente sendo produzido, com alta qualidade, atenção à refatoração, testes, integração contínua, o que leva também naturalmente às melhores arquiteturas, e o sistema como um todo se retro-alimenta num ciclo contínuo de feedback positivo, criando um ambiente sustentável, sempre produtivo, com profissionais pesquisando e implementando inovações tecnológicas que de tempos em tempos dão saltos de qualidade e produtividade para a empresa como um todo.

Como resultado, o cliente estará recebendo produtos que lhe agregam real valor, mudanças de requerimentos podem efetivamente ser aceitos sem maiores problemas, uma vez que a organização é flexível e cada membro se sente responsável pelo todo. Além disso nesse tipo de ciclo virtuoso, os profissionais estão em constante aprendizado, aumentando suas habilidades em ritmo crescente indeterminado, gerando uma empresa inovadora, acima da média, que não se baseia no passado para tentar, futilmente, prever o futuro: eles não precisam mais pois os profissionais finalmente estão preparados para seja lá qual for o futuro que chegar. Em vez de tentar prever o futuro, as pessoas estarão capacitadas para qualquer futuro, e isso é fundamental: mudanças constantes não os assusta mais, pelo contrário, eles querem mudanças.

Como chegar Lá?

Não foi à toa que eu falei sobre:

Os dois artigos primeiros focam na figura do profissional: uma tentativa de acordar os funcionários-batedores-de-cartão de que o mundo não é estático, o futuro não é estável e o mundo gaussiano é uma ilusão.

Os dois últimos artigos falam especificamente de uma ferramenta: Git. É uma dica para criar o ambiente que suporte o que o desenvolvedor precisa, como está no Quinto Princípio. Mas ferramenta, assim como metodologia, não serve para nada se tanto empresa quanto funcionário não incorporarem os Valores e Princípios Ágeis.

Daí este artigo.

Como eu disse no começo, não me considero nenhum grande estudioso dessa filosofia, mas por alguma razão me identifico com suas bases e observo claramente sua aplicação na prática em projetos Open Source. Também está claro que no mundo de Pareto esse modelo não só sobreviveu como deu frutos impressionantes, como a Wikipedia, como o fato de mais de 60% dos servidores web do mundo serem Apache e assim por diante.

Você é uma empresa onde software faz parte do seu core business? Aplique o modelo “Open Source”, ou o modelo “Bazaar”, segundo Eric Raymond. Não necessariamente abra seu código para o público em geral na internet, claro.

Crie um repositório simples, que todos os funcionários tenham acesso irrestrito, onde a barreira de adoção seja baixa. Incentive-os a participar de projetos fora de seus departamentos tradicionais. No começo, código mal feito, de baixa qualidade, sem testes, e toda qualidade de defeitos será revelada. Mas o objetivo não é apontar o dedo e sim parar o ciclo vicioso que gera esse tipo de software.

“Programador ruim fará código ruim, não importa que linguagem, ferramenta você dê a ele.” Portanto, o objetivo é criar Programadores excelentes, não mudar de ferramenta. De forma impressionante, um programador bom fará código bom até mesmo em ASP ou Perl (novamente, sem querer denegrir o Perl, mas apenas falando pela reputação – criada principalmente pelos programadores ruins).

Assim como numa escultura, é hora de aparar as pontas, refazer alguns pedaços, remoldar o que não parece certo e levar essa peça a se tornar realmente uma obra de arte, de forma colaborativa. É a melhor maneira de se evitar desperdícios, uma vez que pessoas com um pouco mais de tempo sobrando numa equipe, podem ajudar seus colegas que estão mais atarefados na outra.

No começo haverá desordem e sinais de caos. Haverá duplicação de trabalho. Acontecerá dessincronia, problemas de comunicação (afinal, ninguém estava habituado a realmente se comunicar). As deficiências de habilidade e conhecimento ficarão óbvias. Todos os problemas existentes virão à tona e isso será feio, desconfortável.

Porém, se houver apenas um pouco de insistência e confiança nas pessoas, verá que o grupo como um todo sairá do caos. Os verdadeiros líderes vão emergir como hubs na rede scale-free. O fenômeno de preferential attachment começará a delinear a ordem. Com tempo suficiente, as pessoas se auto-organizarão de forma orgânica.

A partir daí sim, realmente poderemos começar a falar em crescimento sustentável com ritmo constante ou crescente de produtividade.

Um dia de Inovação

No Google existe aquela velha história de que todos os seus funcionários tem direito a um dia por semana para fazer o que bem entender.

Dito apenas dessa forma a primeira coisa que me vem à cabeça é um monte de garotos passeando de bicicleta, jogando videogame, tomando uma caipirinha à beira da piscina do campus.

Porém, assumindo que você leu todo meu artigo, imagine o Orkut Büyükkökten num desses dias. Ele tem o ambiente correto, tem a cultura correta, tem a motivação correta, tem o conhecimento correto. Ele resolve iniciar um certo projeto pessoal para experimentar com conceitos de redes sociais.

Ele tem um local onde colocar seu código. Também entende que deve se desapegar dele. Entende naturalmente como funciona a colaboração no estilo “open source”. Por causa disso sabe como se comunicar.

Ele divulga seu projeto internamento. Os membros de sua equipe ou de outras, também todos sintonizados na cultura correta de pró-atividade, inovação, aceitação de mudanças e colaboração, imediatamente entendem o valor da idéia. Mais do que isso: sabem de onde baixar o código e como começar a colaborar.

Eu não sei realmente como funciona o Google, nunca trabalhei lá e provavelmente ela deve ter tantos problemas quanto qualquer empresa normal. Mesmo assim eu fantasio que muitos produtos deles começaram dessa forma: num ambiente permissivo, voltado à inovação. Não basta apenas apenas contratar phds. do MIT ou de Stanford se não houver ambiente e cultura adequadas para realmente fazê-los produzir de verdade. Como Larry e Sergey tiveram um começo nesse mundo permissivo de open source eu fico imaginando se eles não criaram uma organização que segue exatamente esse modelo, mesmo que tenha sido de forma instintiva.

Muitas empresas querem ser o próximo Google. Porém, quero lembrá-los que é preciso muito mais do que sofás confortáveis, mesas de pebolim, salas de videogame e restaurantes de comida japonesa dentro da empresa para se tornar um Google. Isso é fácil: basta comprar.

O difícil é cultivar uma cultura. Muitas empresas reclamam que profissionais de boa qualidade pedem demissão e procuram outras empresas. Óbvio: pessoas realmente inteligentes não aceitam uma cultura gaussiana por muito tempo. Nós não gostamos da mesmice, não gostamos de pensamento retrógrado e falta de atitude. Verdadeiros artistas precisam de ambientes de inspiração para serem criativos.

O cubículo da maioria das empresas é um péssimo lugar para se criar.

Bibliografia

Finalmente, uma vez entendida a filosofia, podemos voltar à metodologia. Agora faz sentido aplicar as ferramentas que metodologias como XP ou Scrum advogam: Pair Programming, Planning Game, Test Driven Development, Continuous Integration, Refactoring, Small Releases, Collective Code Ownership, Simple Design, Sustainable Pace, etc.

Leiam com outros olhos minhas recomendações de leitura:

Dica: A maioria desses livros tem traduções em português.

Sei que alguns desses livros não tem a ver diretamente com este assunto (como os de Carl Sagan), mas acredite: faz muita diferença para a maneira como formamos nossas idéias.

tags: off-topic principles agile career management chaos

Comments

comentários deste blog disponibilizados por Disqus