1up4Developers

Atualmente, desenvolver software não é uma atividade barata. O custo com os profissionais envolvidos, equipamentos, licenças de software (não é o caso se a equipe utiliza software livre), entre outros recursos, para um software que demore em média três meses para ser desenvolvido com uma equipe de 5 pessoas sairá pelo mesmo valor de um carro popular de luxo, por exemplo. Já que o investimento é alto, é importante que o software seja confiável, durável, adaptável e principalmente que sua utilização/adoção, além de atender a um problema/necessidade, obtenha o retorno sobre o investimento.

Para uma empresa que desenvolve software por encomenda, o retorno sobre o investimento (equipe, equipamentos, etc) é o lucro obtido com a venda do software através de uma conta muito simples: investimento – custo = lucro. Desta forma, qualquer CEO sabe que quanto menor for o “custo”, maior será o “lucro”. É aqui que mora o perigo!

Uma das falsas ilusões das metodologias baseadas no waterfall é o controle sobre o processo. Ou seja, com um processo bem engessado definido, o “motor” da empresa giraria de modo uniforme, sendo controlável e mensurável. Uma vez que esse mecanismo esteja funcionando, pode-se conter gastos contratando-se mão-de-obra mais barata para fazer a parte repetitiva e “não-criativa” do processo, que já foi previamente “projetada” pelos analistas e arquitetos. Desta forma, concentra-se a maioria do esforço no projeto ou desenho do software, que é mais caro, para recuperar o “gasto” na fase de construção, que é mais barata.

Modelo Waterfal: etapas bem definidas

Este método funciona muito bem… na engenharia civil, onde os problemas são bem definidos (a necessidade de atravessar um rio, por exemplo), a solução deve ser projetada (uma ponte) e executada por especialistas em construção (pedreiros). O esforço pode ser mensurado e cobrado do cliente. Dificilmente ocorrerão mudanças no projeto (ao invés de ponte, decidem mudar para um teleférico, por exemplo) e o tempo de construção pode ser diminuído aumentando-se a mão-de-obra porém permanecendo o mesmo custo no final do processo.

Infelizmente com software não é bem assim. O desenvolvimento de software é (ou deve ser) um processo criativo e iterativo, mais parecido com jardinagem. O problema/necessidade dificilmente é bem definido (dificuldade de controlar as vendas pela internet, por exemplo) e os requisitos geralmente mudam o tempo todo. Os clientes normalmente não sabem exatamente quais são suas necessidades e precisam “aprender” enquanto o software vai sendo desenvolvido, atendendo às necessidades aos poucos.

Clientes não sabem exatamente o que querem no início do projeto

Voltando ao assunto do post, para o cliente o que mais importa é que o software atenda suas necessidades (mesmo que ele ainda não saiba exatamente quais são). O retorno sobre o investimento começa a ficar evidente quando o cliente utiliza o software e obtém proveito dele, por exemplo, tendo um maior controle e organização de suas vendas pela internet. Neste caso o software é um meio pelo qual o cliente consegue resolver seus problemas ou atender suas necessidades. Isto o software não faz por sí só.

Para uma empresa que desenvolve software, o retorno sobre o investimento é obtido durante o desenvolvimento do software, guiado por práticas e ferramentas que fornecem velocidade e confiabilidade ao software, deixando-o adequado às necessidades do cliente, estável e fácil de ser mantido. Para obter estas características, a equipe deve estar muito alinhada e ter a experiência e habilidade técnica necessária para evitar trabalho desnecessário e focar na resolução do problema, colaborando com o cliente para fornecer constantemente software funcionando e que agrega valor ao negócio. Ou seja, devem seguir o manifesto ágil!

Atualmente, as empresas de desenvolvimento de software mais bem sucedidas utilizam metodologias ágeis, ou seja, pessoas ao invés de processos. O investimento em um bom profissional é recompensado pela sua experiência que pode economizar muito tempo e dinheiro ao longo de um projeto. Bons profissionais, motivados, utlizando metodologias ágeis são mais produtivos, ou seja, valem o investimento.

Na semana passada uma desconfortável discussão me pôs a pensar sobre os obstáculos culturais na aceitação de princípios ágeis no desenvolvimento de sistemas. A discussão ocorreu quando um amigo meu comentou comigo a respeito de uma metodologia que ele pretende aplicar em um projeto no qual está envolvido. Fiz questão que ouvi-lo com atenção, pois ele, além de ser uma pessoa da minha consideração, possui um background de sistemas muito diferente do meu. O que permite tentar entender outros lados de problemas em comum.

Logo nos primeiros instantes da conversa, percebi que a metodologia que ele estava a me explicar era nada menos que algo derivado de waterfall, onde, basicamente, um “sistema” é definido, por sábios analistas, em um conjunto de diagramas diversos, para depois passar por “estágios” de aprovações e assinaturas mil, e então finalmente cair nas mãos sujas de pizza dos programadores. Documentos. Documentos e mais documentos. Tudo para garantir que não houvesse mal-entendidos, nenhum “re-trabalho”, nenhuma oportunidade de “o cliente” pedir mais do que podia ou mudar de idéia depois de todos os acordos — simplesmente, a metodologia era sinônimo de controle total e absoluto sobre todas as “fases” de um projeto.

Eu não podia ouvir tudo aquilo e ficar calado. A primeira pergunta que eu fiz foi: quais problemas essa idéia vai combater? Ou, pra ser mais sincero com o eventual leitor, perguntei que problemas, observados na prática, seriam resolvidos com a metodologia. Sim, na prática, pois durante a conversa ele havia dado exemplos bastante hipotéticos e superficiais de problemas. Recebi como resposta um olhar de espanto, como se eu tivesse perguntado se a Lua era feita de queijo Minas. Deveria ser óbvio para mim quais eram os problemas! Na raiz de todos os males está a informalidade total no andamento dos projetos! Cliente conversando direto com programador! Sistema que foge às especificações! Cronogramas que não são cumpridos! Programador dando uma de arquiteto! E outras na mesma linha.

Diante de tantas certezas, vi que a conversa já não ia dar em nada, mas continuei o debate. Respondi que, no projeto em que eu estou trabalhando, uma situação de caos total foi revertida sem que a equipe tivesse que conversar em UML, sem que colocássemos travas no diálogo com o cliente… mas com muito, muito “re-trabalho”. Disse ainda que, do meu ponto de vista, os problemas eram de fundo humano: equipe mal qualificada e expectativas amadoras dos assim chamados responsáveis. E ainda afirmei que não acreditava em especificação perfeita, primeiro porque especificações e diagramas são feitos por seres humanos (ainda que na qualidade de iluminados analistas), e segundo porque software se trata de algo mutável pela própria natureza. (Ou então seria chamado “hardware”.) Não falei em termos tão professorais assim, ou ao menos, procurei ser humilde nas colocações.

Continuei dizendo que, por causa desse fundamento humano, a solução dos problemas, se é que existe, passaria por: apoiar o talento das pessoas, não ser reativo nas negociações, recrutar direito, apostar em um gerenciamento mais adaptativo (em nenhum momento usei a palavra “ágil”) de projetos. Certamente, soluções bem menos simples do que dar ordens de se produzir e seguir diagramas ao pé da letra. (Como se houvesse leitura “ao pé da letra”…)

Pensei que possuía alguma credibilidade, mas acho que a essa altura da conversa o meu amigo já não me via como desenvolvedor experiente, e sim como um encarregado que tinha ido trocar a água do bebedouro perto do qual estávamos e resolveu dar palpite sobre esse troço de sistemas. Tive que ouvir que eu estava “totalmente errado”, que esse papo de dar valor às pessoas era “a causa de nada funcionar”, que as empresas precisavam reter conhecimento através de documentação (no que ele está certo), e que “muitas empresas grandes” estavam trabalhando com essa metodologia. (Não citou as empresas e eu não questionei pra não ficar chato.)

O papo acabou logo depois, mas se alguém ainda está lendo e achou que brigamos, não foi o que aconteceu. Continuamos amigos igual antes. Mas dificilmente volto a ter uma conversa com ele sobre esses assuntos. Existe uma diferença cultural muito grande entre nós dois no que diz respeito a software, e é esse o assunto do post!

Em toda a minha carreira eu apostei na minha capacidade de resolver coisas, no meu domínio sobre as questões relevantes aos trampos com os quais me envolvi, na confiança que eu podia estabelecer com as pessoas em volta e, reciprocamente, na confiança que essas pessoas podiam ter em mim. Eu não sei trabalhar de outro jeito e nem quero mudar, pois várias vezes tive o prazer de ver as coisas funcionando/mudando justamente pelas minhas atitudes. Uma metodologia na base do diagrama, na base do analista/deus e programador/vassalo não é só inútil pra mim como simplesmente não me oferece condições de trabalho.

Por outro lado, não me lembro de ter visto esse meu amigo falar com orgulho a respeito de algum projeto do qual tenha participado. Percebo que sua carreira foi marcada por muito trabalho, muito esforço com equipes ruins, muita pedrada de cliente folgado. Chefes ignorantes. Tarefas monótonas. Isso tudo, sem a contrapartida de gostar do que faz, nem de conseguir se motivar observando os próprios sucessos, pode facilmente, na minha opinião, produzir um semeador de waterfall, como meu amigo parece ter se tornado. Para um perpetuador de waterfall, um sistema é uma coisa plana, composta de tarefas registradas em alguma linguagem esquemática pobre, que será transcrita para o computador por pessoas-robôs cujo maior erro é, eventualmente, pensar.

Uma coisa plana sem espaço para a confiança, nem para a imaginação — origens de todos os males, pelo bate-papo ao pé do bebedouro.

(Parte da motivação para este post veio de “What are the right conditions for agile adoption?“, de David Anderson.)

Não sei nem como começar a descrever o evento, foi muito bom !!! Logo no primeiro dia, na fila para pegar o pequeno cracha de identificação, já trombei logo com quem !?! Dr. Nic ! E ao seu lado, estava um cara muito simpático também, que de primeira não reconheci, o Chad Fowler e sem barba ! E pra quem não acredita, bom, tirei foto com o figura como prova ! (está aqui no album do flickr)

Palestrantes RailsSummit

Todas as palestras foram muito interessantes, no segundo dia, o tema testes foi muito abordado e acabou ficando repetitivo, porém o pessoal aproveitou para atualizar seus e blogs e tals. Na minha humilde opinião, as apresentações de abertura e final do evento foram as melhores ! Na abertura, destaque para o video que o pessoal do Rails Envy mandou !

Sem se preocupar em parecer repetitivo, mas a principal mensagem das palestras foram, “faça!”. Tudo se resume a ação!, ajude projetos open, crie novos projetos, participe com diferentes papéis, leia, escreva blogs, livros, screencasts, wikis … etc. Teve muita mensagem motivacional, e eu confesso que gostei !

É complicado tentar repassar a enxurrada de informação que veio do evento, e por serem parecidas, eu acabo misturando as informações. Resumão: Metodologias Agéis, teve bastante coisa sobre e com perspectivas diferentes, cool!

Parte do Chad Fowler, foi muito legal, com sacadas interessantes do “meio corporativo”, e apresentou questões filosoficas sobre a evolução de frameworks. Logo em seguida, teve uma conferência com o DHH (David Heinemeir Hansson), falou sobre o futuro de Rails, falou sobre thread-safe do Rails 2.2.

Palestra do Brando foi muito legal, e deu uns toques importantes de como conseguir aquele seu emprego rails tão desejado, sem contar o chefe dele, Carl, grande figura.

Depois teve o Chris Wanstrath (criador do github.com), é impressionante o tanto que ele batalhou pra chegar aonde o github é hoje, foi meio chato porque ele ficou lendo, mesmo assim, teve informações legais.

No final, o BOF (Birds of a Feather) foi um show a parte! Várias figuras, falando desde projetos em desenvolvimento até a técnicas de impor novas idéias … várias figuras, várias risadas.

O segundo dia de evento, começou muito interessante, com a apresentação muito boa – dei muita risada em várias partes – Ninh Bui e Hongli Lai os emos caras do Phusion ! Foi muita piada nerd, várias animações flash, citações de mega man à dragon ball, com direito a Star Wars no final …

Phusion Darth Vader !

Depois assisti a palestra do Jay Fields. Foi muito legal, ele apresentou o lado bom e ruim de vários frameworks de testes como selenium, rspec e talz. Destaque para o momento flame, quando o David Chelimsky mantenedor do rspec, começa a questionar alguns pontos levantados por Jay. Não se preocupem, que tudo acabou em breja …

Assisti a palestra do Vinicius Teles, cara, sensacional ! A palestra foi sobre empreendedorismo, com participação especial do Carl (da SurgeWorks), ficou muito legal a “union” das apresentações, e esta com certeza merece um post separado-extra.

Chegando ao final do dia, começou a bater o cansaço … assisti a palestra do Fabio Kung sobre JRuby. Ele entrou em detalhes na plataforma Java e como é executado o código ruby nela. Foi muito legal, porque eu finalmente entendi a diferença entre “servers” e talz. Eu não lembro muito ao certo, se eu tiver acesso a apresentação, coloco o link aqui.

Pra finalizar teve o fechamento com o Obie Fernandez, ele mostrou de maneira apaixonada e apaixonante, como está funcionando sua nova empresa, a HashRocket. Mostrou o manifesto agil, primeiro em papel e depois na vida real com os fatos da sua empresa. Mostrou que testes funcionam, programação em par também funciona! e etc. Foi muito show, acho muito legal a forma que ele conduz a apresentação.

1up4dev and ... Obie !

O evento fechou com chave de ouro, rolando várias brejas, e isso eu te garanto, é muito louco brindar com o Dr. Nic e Obie na mesma roda !

Além de tudo isso, é muito interessante como o espirito de “integração” é muito alto, por exemplo, o Diego Carrion do MouseOver Studio ficou com nosso grupo, os dois dias, trocamos experiências, foi show também. Até agora, a única apresentação que peguei foi a do Dr. Nic, que ele disponibilizou o link via twitter.

Me desculpem pelo tamanho do post … e como ele está muito grande, nem vou ler em busca de erros, vou arrumando conforme necessário, ou seja, fica pro próximo sprint !