Um exemplo claro de como os valores ágeis estão sendo desprezados distorcidos é o aumento constante de “cursos” e treinamentos de metodologias ágeis. Não é raro eu receber semanalmente vários spams e-mails de escolas de treinamento que ministram cursos de Scrum, XP, preparação para certificação ScrumMaster, técnicas de TDD, DDD, BDD, etc. Infelizmente o que estes cursos não ensinam (como todos os outros) é o verdadeiro significado de “ser ágil”. Fazer um curso de 20 horas de Scrum não o torna um ScrumMaster (você pode até ter um certificado, mas se você realmente é “ágil”, sabe que um certificado é um mero pedaço de papel sem valor).

E assim chegamos à “agilidade cascateira”, onde todos na empresa estufam o peito para falar que seguem práticas ágeis, desenvolvimento orientados à testes, utilizam Scrume para gerenciar os projetos, etc. Na verdade estão apenas praticando um waterfall incremental, cometendo os mesmos erros clássicos da cascata, valorizando os processos ao invés das pessoas, focando em soluções equivocadas ao invés de resolver os problemas dos clientes e assim, difamando e denegrindo a reputação e o propósito do AgileManifesto.

Esse é o cenário ideal para os guardiões cascateiros. É por estes e outros motivos que vemos “flames” oportunistas como The Decline and Fall of Agile começarem a fazer sentido na comunidade. Como disse o Guilherme Chapiewski, as pessoas estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Utilizar uma metodologia ágil não é desenvolver software de forma anarquista, existe muito conceito e experiência adquirida para sustentar esta filosofia.

Neste blog você já viu várias maneiras de como ser um verdadeiro cascateiro e de como não ser ágil. Já que estamos falando nisso, vamos tentar resumir alguns pontos e características que tornam um desenvolvedor realmente ÁGIL!

Estude, mantenha-se atualizado!

A principal característica de um agilista é sua sede por conhecimento, sua busca incansável por novas técnicas, linguagens, ferramentas, etc. O seguidor ágil lê artigos, revistas, livros e o faz como diversão. Se você não leu pelo menos um livro técnico nos últimos 6 meses, isto é um mal sinal. Faça laboratórios, testes de novos frameworks, bibliotecas, etc. Pet-projects também são uma maneira pragmática de aprender novas formas e técnicas de desenvolvimento. Finalmente, conheça e pratique os princípios e valores do AgileManifesto, tendo-os como seu mantra, seu guia filosófico e seu mentor profissional.

Entenda realmente o problema do seu cliente

Isto parece ser óbvio, mas na maioria das vezes não é. Existem vários perfis de clientes, e é claro que você deve lidar de maneiras diferentes com cada um deles.

Alguns são visionários sonhadores e sempre têm necessidades mirabolantes, sem sentido. Outros são simplistas demais e muitas vezes “ocultam” detalhes importantes. Também existem os pseudo-técnicos, que acham que sabem fazer seu trabalho e já vêm sugerindo como você deve implementar aquela nova funcionalidade.

Reação comum quando há um problema

Como verdadeiro agilista, saber identificar o perfil de seu cliente é o início para um relacionamento de confiança e transparência. Só assim você será capaz de concentrar esforços para resolver seu problema e agregar valor ao produto.

Não tenha medo de mudanças

A única maneira de criar, corrigir ou melhorar algo é com coragem E com mudança. O essencial para mudar algo é saber identificar o que está errado. Por exemplo, você sofre diariamente para fazer o deploy da sua aplicação para homologação. Identificado o problema e uma possível solução, por exemplo, fazer o deploy em .war, você tem duas soluções: ou deixa como está e coloca a culpa na aplicação ou no processo de desenvolvimento (conformismo) ou com muita coragem investe algumas horas e resolve de vez o problema (agilismo).

Quando bater a insegurança, repita: coragem! coragem! coragem!

Coragem: o cão covarde!

Reflita e aprenda com os próprios erros

Existem várias maneiras de você evoluir seu conhecimento, e a maioria dos programadores utilizam somente uma: tomando na cabeça.

Prego só toma na cabeça!

Como um bom seguidor de práticas ágeis, reflita e aprenda com seus erros. Compartilhar seus problemas é a melhor maneira de escolher um solução adequada e ainda espalhar sua experiência entre a equipe para que outras pessoas não cometam o mesmo erro.

Errar é humano. Persistir no erro é burrice. Se você está com problemas, procure por pessoas que já tiveram um problema parecido e aprenda com ele. Não cometa os mesmo erros, e mais importante, não cometa os mesmo erros dos outros!

Resumo

Se tudo que você leu até agora não é novidade, parabéns! Caso contrário comece o quanto antes estudar e principalmente praticar estes conceitos no seu trabalho e na sua vida.

Seja responsável e comprometido com seu trabalho. Esforce-se para fazer o melhor. Faça valer o seu salário. E lembre-se: cuidado com os falsos agilistas!

Com certeza todos ficaram com um gostinho de quero mais, e com uma imensa vontade de agradecer ao Fábio Akita e todos aqueles que tornaram este evento possível. Mas uma coisa que não vi ser muito falada foi o happy hour que aconteceu ao final do último dia. Você consegue imaginar como seria poder tomar uma breja com o cara que escreveu um de seus livros preferidos?! Ou o cara que mantém aquele blog que te inspirou a aprender ruby/rails? Melhor ainda. Imagine poder passar um momento falando besteiras e dando muita risada com esses caras?! Bom, eu passei por isso!! E até agora a ficha parece não ter caído, não consigo acreditar que passei por isso.

Bom, para organizar os fatos a coisa aconteceu mais ou menos assim. Depois do fim da palestra do Obie Fernandez toda galera correu para tiras fotos, pegar autógrafos e coisas do tipo, foi agitação total como era esperado. Feito isso, o pessoal da organização começou a servir espumante e cerveja no saguão e é claro que corremos para lá. Foi muito legal, pois nesse momento conseguimos conhecer mais gente e ainda presenciar Dr Nic mandando ver numa Skol gelada! Nesse momento começou um movimento revolucionário lutando por uma causa que eu considerei mais que justa, procurar um lugar para comer e beber mais cerveja (e depois algumas caipirinhas, como pode ser confirmado pelo próprio Dr Nic no video abaixo!). Surgiu a idéia de comer um sushi, e é claro que só podia ser no bairro da Liberdade.

Rails Summit Happy Hourt, chegada from miguel aranha baldi horlle on Vimeo.

Nesse momento todos se mobilizaram, e o pessoal da LocaWeb ainda deu uma força na logistica, e todos foram para um restaurante na Liberdade. Muitos pegaram carona (como eu!), outros foram na Van da LocaWeb, mas o importante é que depois de algumas voltas estávamos todos lá. Simplesmente lotamos o lugar, um monte de nerds loucos para comer e tomar umas cervejas, todos loucos depois de um evento como esse. A galera se organizou em várias mesas, e fiquei em uma mesa com o Ricardo Yasuda (shadow) e o Márcio Trindade. Junto com a gente estava Dr Nic e um argentino maluco (qual que não é?! huahauhua). Em outras mesas estavam Obie Fernandez, Chad Fowler, Chris Wanstrath, David Chelimsky! A galera do Phusion Passenger também estava lá, assim como Vinicius Teles, Juan Bernabó e muitos outros (Incluindo Fábio Akita!). Bom, o resto foi um misto de muita bebida, risadas, e claro, muito papo nerd. E o mais legal de tudo é que sobrou um pouco de bateria na filmadora e eu consegui filmar alguma coisa (com a ajuda do nosso amigo argentino, que se alguem lembrar do nome por favor me avise).

O mais legal de tudo isso foi poder conhecer muita gente legal, ter contato com meus ídolos e ver que estes são pessoas muito acessiveis. Certamente esse dia não vai sair de minha lembrança, um abraço pra galera que esteve lá, devido ao nível alcoolico do momento não me lembro do nome de todos, huahuahuaha. E fica a chamada pra galera, quem esteve lá nessa noite por favor se manifeste e comente aí, gostaria de saber o nome da galera.

Rails Summit Happy Hour, hino nacional from miguel aranha baldi horlle on Vimeo.

Observações: Conforme eu for subindo mais videos no Vimeo eu vou atualizando este post, portanto fiquem ligados! Tentei deixar os videos em uma boa qualidade para quem for baixar. Ainda tenho que editar a maior parte da filmagem que foi feita pelo argentino maluco, que logo no inicio pegou a camera de mim e não soltou mais até acabar a bateria!

Espero que mais eventos como esse aconteçam, e que a galera compareça e participe como participou neste evento, abraço à todos!

Mas qual a diferença entre foco no problema ou solução? Vamos a um exemplo:

Quando a Nasa enviou os primeiros astronautas ao espaço, descobriu que as canetas não funcionavam com gravidade zero. Para resolver esse problema, os engenheiros contrataram uma empresa especializada para projetar a caneta espacial.
Dez anos e US$ 12 milhões depois, estava pronta a caneta que podia ser usada no espaço, em qualquer posição. Nem a temperatura poderia atrapalhar: a supercaneta funcionava bem fizesse frio ou calor.
Os russos, que tiveram o mesmo problema, optaram por uma solução mais simples: passaram a usar um lápis.

A história acima é bem famosa e mesmo sendo falsa, demonstra muito bem o que acontece quando o problema não está em foco. Neste caso, o problema é a impossibilidade de escrever em gravidade zero. Uma das soluções seria uma caneta que escreva nessas condições. Veja que aqui a solução já está em foco. Outra solução para o problema seria utilizar algo que escrevesse em gravidade zero: um pedaço de carvão ou um giz já serviriam. Assim, o problema seria resolvido.

Outro exemplo de falta de foco no problema é esta história da fábrica de pasta de dente, onde ocasionalmente algumas caixas da pasta de dente eram entregues vazias. Para eliminar este problema, a empresa gastou investiu milhões para garantir que durante a fabricação, nenhuma caixa ficasse sem o tubo de pasta de dente dentro. Mas o problema foi realmente resolvido depois que um operário deixou um ventilador soprando as caixas vazias para fora da esteira de produção. Simples não?

Na área de desenvolvimento de software não é tão raro acontecer algo parecido, onde o foco está inteiramente na solução. Sabe aquele sistema meio capenga, que funciona e dá dinheiro para empresa mas não é “web 2.0″ nem utiliza conceitos de “SOA”? De repente a diretoria decide que este sistema deve ser “migrado” para uma tecnologia da moda mais atual, que o permita “evoluir” mais facilmente.

Para atender esta necessidade, normalmente uma equipe nova é contratada, toneladas de documentos e diagramas são produzidos até que os programadores comecem a codificar. A esta altura, o prazo já está apertado e os “stakeholders” ainda não viram os resultados. Depois de muito tempo e dinheiro desperdiçados, um sistema feito às pressas, bonitinho mas meia-boca, é entregue com os mesmos defeitos do anterior. E o problema não foi resolvido…

Desenvolver software deve ser um investimento lucrativo, proporcionando algum ganho às partes envolvidas. Quando uma necessidade surgir, o primeiro passo é identificar o problema para então encontrar a melhor solução, ou seja, foco no problema. Neste exemplo da “migração”, o problema é que a manutenção do software atual é muito cara, porém “migrar” o sistema inteiro não vai resolver o problema, no máximo criará um novo.

Mas de quem é a culpa quando o foco está na solução? Eu respondo: a cascata! Apesar das metodologias ágeis estarem em alta e aos poucos serem adotadas pelas empresas, a maldição do waterfall ainda é está entre nós. Clientes continuam com a mania de pedir tudo no início do projeto. Ao exporem seus problemas, já estão pensando na solução. Fazem questão de engordar o escopo com coisas das quais não têm certeza da utilidade, mas querem que estejam lá pois podem precisar um dia. Os desenvolvedores também não estão isentos dessa culpa. Um legítimo analista cascateiro não se envolve com os problemas do cliente, apenas ouvem suas solicitações e transformam em casos de uso ou diagramas. É aí que uma simples necessidade se transforma numa bola de neve e a lenda da caneta da Nasa se repete…

Um verdadeiro desenvolvedor ágil deve se comprometer com o cliente, ouvir, entender e se envolver com suas necessidades para então sugerir uma solução simples, focada e que resolva o problema. Esta interação é muito importante e deve ser constante, pois o cliente passa a identificar o que realmente ele precisa, ou seja, o qual seu problema! Assim, começa a se concentrar em funcionalidades que realmente serão úteis e agregarão valor ao software e, consequentemente, ao negócio. Feedback é muito importante. O pessoal do Google sabe muito bem disso…

Este post é uma homenagem aos Arquitetos defensores do waterfall/cascata.

Recentemente tive o desprazer de conhecer um arquiteto, é isso mesmo, aquele com certificado e tudo, com direito a broche da Sun em seu terninho. Aliás, certificado é um tema polêmico que eu não tenho uma opinião muito certa e/ou formada… bom, vou deixar esta parte para um próximo post, quem sabe.

Voltando ao assunto, hoje no fretado, comecei a pensar nas semelhanças que um arquiteto de sistemas (certificado que decorou patterns inutéis da Sun) tem com um arquiteto de obras. Só para deixar claro, na tabela abaixo estou usando dois estados: FAIL e Ok. Fail quer dizer que vai dá merda não vai dar certo e não tem jeito, caso queira uma definição mais formal, o wikipédia ajuda, agora se você prefere imagens, o Fail Blog também serve.

Exemplo de FAIL

Parei a tabela por aqui pois já dá pra saber que o FAIL tende a infinito né.
Pergunta: o que ambos arquitetos estão fazendo!?!
Resposta educada: Estão fechando o escopo do projeto.

Arquiteto Cascateiro trabalhando ...

A resposta acima é uma frase chave pra você ter certeza que vive num projeto waterfall cascateiro. Fechar o escopo do projeto inteiro deve ser muito bom para o arquiteto de obras, já para um sistema, o efeito é contrário. Acredito muito na teoria que desenvolver software não é construir prédios. Livros de renome como Pragmatic Programmer citam isso.

Sei que este tema de construção civil já está batido. Comecei a escrever este post ao mesmo tempo que o Sr. Panachi publicou o anterior, e com a idéia de ficar menos repetitivo, já vou linkar as sugestões dos nossos incríveis leitores:

• O Diego Carrion (grande peruano! :D) cita este link, que fala que a engenharia civil também consegue ser ágil em alguns casos.
• O Witaro, fez um ótimo post “Desenvolvendo software como uma Rock Band” que quebra a barreira da analogia com a engenharia civil. Cara, continue escrevendo, porque a sua visão é muito legal!

Bom, agora que acabou o desabafo, vamos as possíveis soluções. O que fazer com o Arquiteto Cascateiro?

Acho que a primeira coisa seria conscientizá-lo de que ele não é o Oscar Niemeyer e que a primeira versão de seu software nunca será completa de uma vez. Você deve conversar sobre iterações com ele e mostrar que o software deve evoluir conforme o cliente também evolui nas descobertas das suas reais necessidades. Sei que o post já está cheio de links, mas este post do Phillip Calçado, Analista Pedreiro, resume bem o que quero dizer.

Arquiteto, este nome ou termo ou cargo ou seja-lá-o-que-for, é coisa de modelo waterfall/cascata. Numa equipe, não deve haver distinção desta maneira. Todos programam, modelam, configuram, trabalham no Banco de Dados quando necessário, ou seja, ninguém deve exercer um papel único. Papéis únicos, representam Guardiões que defendem somente seus interesses e não trabalham em pró da equipe/cliente/projeto.

O Arquiteto deve programar, colocar a mão na massa, assim como toda a equipe, pois UML, Caso de Uso, Diagrama de Sequência, etc. sempre compilam! Muito diferente na vida real, onde muitas vezes você é obrigado a implementar uma coisa diferente e torta para acompanhar estes documentos cascateiros. Caso você seja obrigado a gerar a documentação fútil acima, pense em algo que seja automatizado após você ter programado e testado, com certeza você será umas cinco vezes mais produtivo.

E por último e não menos importante, a equipe (inclusive o Arquiteto) tem que conhecer o negócio que implementa. Quando se inicia um novo projeto ou até mesmo decidem reestruturar um existente, o arquiteto cascateiro sempre prioriza novas tecnologias e frameworks, o que na maioria das vezes, não é necessário. Novos projetos ou refactoring em existentes, devem ter um único prioritário objetivo: KISS. Com esta prioridade em mente, novas tecnologias e frameworks serão escolhidos naturalmente, e não somente usar porque é a última moda no estilo SunTechDays.

E vocês leitores?! Sofrem ou já sofreram muito com Arquitetos Cascateiros!?!

O principal apelo de um processo cascateiro são suas fases e papéis bem definidos, onde cada membro da “equipe” é responsável por uma determinada tarefa que é executada em uma seqüência previamente definida. Dentre os papéis, pode-se facilmente identificar os especialistas daquela tarefa, que defendem sua necessidade execução com unhas e dentes. Para ilustrar, resolvi chamá-los de guardiões, seja da tecnologia ou da atividade em questão. Um guardião protege sua fase, tarefa e interesses, defendendo-os para que o “processo” não seja quebrado. Desta forma, <sarcasmo> a “equipe” atinge seu objetivo: o software! </sarcasmo> Seguem alguns exemplos desses guardiões cascateiros:

O guardião do banco de dados: “Não rodarás nenhum script na base alheia“
Começo por este por ser o mais comum dos guardiões. Ele trata o banco de dados como um filho, mesmo que seja um adolescente que não obedeça inteiramente à 3ª regra normal. São vistos como semi-deuses, capazes de transcrever o modelo de negócio da empresa em uma linguagem de alto nível, impossível de ser compreendida por simples programadores. Protejem as tabelas com a própria vida e qualquer alteração na base de dados é motivo para um duelo até a morte! Utilizam um padrão para nomenclatura de campos que somente é conhecido pelo clã dos DBAs. Geralmente são seguidores do Oráculo, o senhor de todos os bancos de dados.

O guardião do projeto: “Guia-te pelo teu Gantt e serás recompensado”
Este guardião está presente em todos os projetos, garantindo que a palavra do Gantt seja cumprida, protegendo o escopo do projeto com a própria vida (ou a vida de algum programador). Adicionalmente atua como roteador de atividades: recebe os requisitos pelo email, encaminha para um recurso disponível (programador) que estima o esforço e define uma data de entrega, devolvendo para o guardião que atualiza seu Project.

O guardião do framework: “Venerarás o Struts e nada te faltarás”
O framework é o objeto de adoração deste guardião, nenhum outro framework é tão bom quanto o que ele venera. Ele provê solução para todos seus problemas simplesmente escrevendo um bloco de XML aqui, outro ali, mudando aquela linha acolá e estendendo uma classe X implementando aquela interface Z. Qualquer evolução do framework em questão não passa de uma tentativa frustrada de “reinventar a roda”.

O guardião da arquitetura: “Não usarás a instância do teu objeto em vão”
Uma variação interessante de guardião, que neutraliza seu oponente através de técnicas de tortura e perturbação mental, inundando as sessões de brainstorm com uma enxurrada de DTO’s, VO’s, Facades, EJB’s entre outros patterns que fazem a cabeça dos programadores entrar em conflito, até que seus órgãos faleçam (ou simplesmente se demitam). Geralmente são cúmplices dos guardiões do projeto, conspirando para a dominação do Gannt.

O guardião do root: “Teu processo não executarás no meu bash”
A jóia mais preciosa da empresa: a senha do root. Seu guardião é o mais honrado dos seres, sendo uma espécie de Frodo, protegendo-a com a própria vida pois uma vez em mãos erradas pode ser usada para a destruição da humanidade (ou apenas para reiniciar aquela instância do Tomcat travado em produção). Aquele que desafia este guardião perde o direito de executar seus processos como administrador local e fica vagando pelo filesystem eternamente.

O guardião dos guardiões: “Tua TI é um mal necessário”
Também conhecido como diretor, presidente, CEO, dono, investidor, sócio, etc. É o guardião das decisões, aquele que protege sua riqueza acima de tudo, economizando nos salários, contratando funcionários despreparados e investindo rios de dinheiro em consultorias e licenças de software para garantir seus investimentos.

Enfim, são guardiões dos próprios interesses. A “equipe” é apenas uma palavra que usam em discursos mas nunca aplicaram o conceito na prática!

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.

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

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 !

Na maioria dos problemas que presenciei, a diretoria (quem toma decisões e libera a grana do projeto) contribuiu para que as coisas ficassem cada vez piores, seja tomando decisões visando curto prazo ou aplicando conceitos ilusórios como adoção de uma tecnologia ou metodologia da moda. Seguem algumas pérolas da “diretoria”:

• “Programadores são descartáveis”. Não consigo acreditar que pessoas numa hierarquia superior ainda tenham esta visão dos programadores, comparando desenvolvimento de software com construção civíl e programadores com pedreiros (em alguns [poucos] casos é verdade). Certa vez presenciei um dos mais famosos defensores de práticas ágeis, autor de vários livros e que subiu na carreira devido a seu destaque como programador (Delphi), dizer: “programadores têm em todo lugar, basta sacudir uma árvere e cai um monte deles no chão”. Depois dessa, passei a ignorar tudo que ele escreve ou fala. Talvez se ele tivesse lido pelo menos o resumo do Manifesto ágil saberia que blasfemou feio!
• “Meu maior gasto é gerado pelos programadores”. Fiquei sem reação quando ouvi esta pérola do dono da empresa. Ele ainda achava que os atrazos e erros do sistema vinham dos seus quatro programadores juniores que utilizavam uma tecnologia quem ninguém conhecia direito (mas está na moda), não utilizavam nenhum processo ou metodologia e ainda tinham que manter contato direto com os clientes.
• “Precisamos de documentação”. Esta todos nós já ouvimos e conhecemos o final. Um certo dia alguem chega na empresa e decide que tudo deverá ser documentado. Então gastam-se alguns meses levantando os requisitos do sistema, definindo os casos de uso e diagramas UML, reuniões, definição do banco de dados, etc. Lá pelo 10º mês descobrem que nenhuma linha de código foi escrita e o sistema só existe no papel. Nem preciso contar o final da história né?
• “Como assim não dá pra desenvolver este ERP em três meses?”. Nunca assisti um Tech-Ed nem outra palestra do tipo, por isso não sei exatamente o que vendem falam sobre pazos, mas com certeza é uma mentira das grandes! Não existe mágica nesse ramo, não existe ferramenta nem tecnologia milagrosa e nenhum processo vai acelerar o desenvolvimento do sistema. Ponto. Somente uma pessoa que não entende nada sobre desenvolvimento de software acreditaria nesse conto de vigário. Um general sabe comandar seus soldados pois certamente foi um soldado e esteve num campo de batalha. Será que todo chefe/diretor foi programador (de verdade) no início da carreira? Ter programado em Cobol há 20 anos atrás não conta!
• “Não podemos perder tempo com refactoring e testes unitários”. Bom, se deixar o código do sistema mais “manutenível” e garantir que o que já foi feito funcione corretamente do jeito que deve ser for uma “perda de tempo”, então estou no ramo errado. Fazer com que o sistema “rode” é muito importante pois sistema rodando é dinheiro entrando no caixa. Mas abrir mão da qualidade é uma péssima estratégia a curto prazo, pois todos nós sabemos que sistemas mudam constantemente e ter mecanismos para responder rapidamente a essas mudanças é mais importante do que “parir” um sistema remendado de uma hora pra outra e depois perceber que a menor das mudanças custa 10 vezes mais do que o normal.

Por enquanto só consigo me lembrar dessas, mas outras pérolas virão e renderão novos posts.

Fiquem a vontade para comentar. Até o próximo post!

A primeira dica do “dicas para o desenvolvedor”, foi:
- Gerador de código descartável.

Pois bem, hoje, vou mostrar um exemplo de “código descartável” que utilizei e deu certo !

Problema: No projeto que estou existem algumas queries em arquivos XML do hibernate, preciso convertê-las para Spring. Pra cada query do hibernate, precisei gerar dois arquivos de XML do Spring e mais uma classe Java que herda de SqlUpdate … blá blá blá. Bom, os detalhes não importam muito, o que importa é que vamos ler o XML do hibernate e gerar o que for necessário, tudo isso com Ruby!

Antes de qualquer coisa, já aviso que ainda não domino totalmente Ruby, e o script que fiz é do tipo código “descartável”, então não tive o menor cuidado em deixá-lo bonito, apenas funcional. Acho que a melhor maneira de aprender uma nova linguagem é escrevendo código com ela, não somente lendo sobre.

Exemplo super simplificado do XML do Hibernate:
script generator-bean em Ruby:

É isto ! O script é simples e direto, deixei a saida pro console mesmo e para jogar em arquivo é muito simples:

$ ruby generator-bean.rb > spring-exemplo.xml

O script que coloquei é uma versão bem reduzida, já que a idéia do post é mostrar que é possível transformar tarefas chatas e trabalhosas em scripts semi-automáticos ! Ah, lembrando que com ele consegui terminar a minha tarefa em 2 dias, sendo que a previsão era quase uma semana de trabalho !

Precisa de mais informações de como ler XML com Ruby !?

Segue as referências.
Tirei deste post, muito legal por sinal.
* API do REXML: http://www.ruby-doc.org/stdlib/libdoc/rexml/rdoc/index.html
* Sobre o Electric XML: http://www.xml.com/pub/r/1098
* Tutorial um pouco mais complexo sobre XML com Ruby: http://www.xml.com/pub/a/2005/11/09/rexml-processing-xml-in-ruby.html

OBS: Estou usando o gist.github.com para colocar o xml e script de exemplo, provavelmente não vai aparecer no leitor de feed.