A cilada típica em ambientes corporativos:

E agora, quem poderá nos ajudar?

Infelizmente, e-mails e reuniões, mesmo em ambientes ágeis, são inevitáveis, e na maioria das situações, tóxicos. Reuniões de 2 horas de duração ou 50 emails diários são sinais claros de que as coisas não andam muito bem.

Atitudes ágeis tendem a evitar “enrolações” que desviem o foco da equipe ou desacelerem a produtividade. A seguir, algumas estratégias e dicas que podemos aplicar para quebrar um pouco essas práticas corporativas cascateiras, ajudar a manter o foco da equipe e produzir mais.

Reuniões

Simplesmente evite reuniões, com temor! Tente resolver os problemas com conversas cara-a-cara, na sua mesa mesmo. Se precisar discutir um assunto por mais de 5 minutos, convide as pessoas envolvidas para um cafézinho, de preferência em pé.

Se não puder evitar a reunião, defina com antecipação: 1) o(s) objetivo(s) e 2) a duração máxima. Limite qualquer reunião a no máximo 5 participantes e duração de 15 minutos. Acredite: é suficiente.

Se um problema for muito complexo para ser resolvido em uma reunião de 15 minutos, quebre o problema em problemas menores, e discuta um de cada vez. Os próximos problemas devem ser discutidos somente quando o problema anterior for resolvido.

Antes de começar qualquer discussão, faça com que todos presentes tomem ciência dos objetivos e da duração máxima. Assim que alcançarem os objetivos ou o tempo se esgotar, termine a discussão imediatamente! Não dê oportunidade para que alguém inicie uma nova discussão desnecessária.

Diga não! Em certas ocasiões, é a melhor resposta. Se você não é o responsável por determinado problema, desconhece ou não pode ajudar plenamente, simplesmente diga “não, obrigado”.

E-mails

Alguns problemas podem ser resolvidos com um simples e-mail, é verdade. A única regra que devemos seguir é a do “passa, repassa ou paga”. Não deixe os e-mails passarem das tréplicas. Se depois de 3 e-mails o problema ainda não foi resolvido, convide os envolvidos para tomar um cafezinho.

E-mail não é chat. O time deve conversar cara-a-cara, incluindo os clientes. Trocar mais do que 5 e-mails diários entre a equipe é um mau sinal. Se não puder falar pessoalmente, use o telefone ou skype ao invés de mandar um e-mail que pode ser facilmente ignorado pelo destinatário.

E-mail não é documentação. Não é preciso enviar um e-mail a cada decisão tomada pelo cliente ou pelo time. Se algo importante foi decidido, converse pessoalmente com os envolvidos.

Finalmente, use o e-mail com sabedoria, para trocar informações importantes e relevantes entre a equipe. E-mail não deve ser regra, e sim um suporte para comunicação entre a equipe. Lembre-se: quanto mais e-mails você enviar, maior a chance de ser ignorado.

Resumo

Reuniões e e-mails são tóxicos. Evite-os! Se não puder evitar, use-os com sabedoria.

Se identificou com alguma situação? Acha que essas dicas “choveram no molhado”? Concorda, discorda, quer complementar algo? Use os comentários.

Reflexão: quais dessas práticas você aplica no seu cotidiano profissional?

Nos últimos anos o mercado de TI cresceu exponencialmente. Surgiram desde pequenas empresas especializadas em construir websites até monstruosas fábricas de software com seus contratos milionários. Algumas com orçamento limitado outras com dinheiro jorrando pelos canos. Umas com problemas por falta de organização outras com problemas burocráticos. Bons profissionais vs. equipes de sobrinhos, habilidade técnica contra enxurradas de documentos… muito fracasso, pouco sucesso.

A meta é coletar as moedas até conseguirmos uma estrela

Surgiram muitas empresas especializadas em desenvolver software ou que têm um software como produto principal. Normalmente, essas empresas se preocupam apenas em satisfazer os investidores e se esquecem dos clientes. Focam em vender e deixam a qualidade de lado. Prezam pela imagem e ignoram os problemas.

É uma triste realidade que essas empresas tenham mais executivos do que programadores. Como diz o Luli Radfahrer, executivos são aqueles seres que se vestem com um pensamento fracassado, usam uma linguagem própria sendo uma mistura de termos que só eles entendem e 20% de palavras em inglês… não vivem os problemas reais da empresa. É como se estivessem em outro mundo: Mario World!

O mundo dos executivos: nuvens sorrindo

A maioria das empresas que têm problemas com desenvolvimento de software ainda estão vivendo na década de 90. Internet ainda é uma palavra assustadora. Programador é apenas um funcionário que sabe o que significam siglas de informática e sabem mexer no computador. Mudança ainda é encarada como algo arriscado, que deve ser planejado, estudado e aprovado pelo presidente, diretoria e gestores. A palavra da vez é processo e seu fiel companheiro é prazo. A burocracia é uma amiga que garante que as coisas não fujam de controle. Nesse cenário não há como fugir do waterfall.

O maior problema do waterfall são os papéis: cada um com sua “especialidade”. Alguém determina que um infeliz funcionário vai ser responsável por “levantar requisitos”. Faz um cursinho de UML e começa a escrever uma quantidade sem fim de Casos de Uso sem ter noção alguma do que seu trabalho afeta no processo. Então a “equipe” começa a ter muito “retrabalho”, uma vez que os clientes não estão satisfeitos com o que está sendo entregue. Logo percebem que devem fazer o “levantamento” mais detalhado e passam a engessar ainda mais o processo com reuniões, assinaturas, etc. Conclusão: tempo e dinheiro desperdiçados e nenhum resultado satisfatório.

Meu trabalho é digitar 4 8 15 16 23 42 a cada 108 segundos

Falta de foco? Profissionais não qualificados? Processo falho? Não apenas isso: não há comunicação, não há troca de experiências. O waterfall favorece o aparecimento da síndrome do funcionário público: “eu sou gerente: eu córdeno, não preciso saber programar”. As decisões geralmente são tomadas por uma única pessoa. Os projetos seguem o modelo de construção civil. Os profissionais se acomodam pois não veem perspectiva, não conhecem o processo completo, não são ouvidos e por isso não são valorizados.

O foco destas empresas está longe de ser tecnologia. Se concentram em suas buzzwords, processos e reuniões e se esquecem do produto, ou seja, o software. Focam mais na solução do que no problema. Fazendo uma analogia, essas empresas são como um barco furado, onde está entrando água mas há pessoas com baldes para retirá-la e mantê-lo flutuando. Se a agua subir muito, contratam mais pessoas para operar os baldes. Enquanto isso, os executivos ficam acenando como se nada tivesse acontecendo. Quando perguntam se há algum problema, nenhum fdp infeliz tem coragem para falar que o problema é o furo no barco!

As empresas que focam em tecnologia e nos profissionais, tipo o Google ou a 37signals, estão se dando bem e mostrando que agilidade não é apenas mais um processo… é algo real e que funciona!

Agilidade é sair fazendo as coisas de qualquer jeito

Diante do cenário caótico das empresas, um grupo de profissionais organizou um movimento a fim de unificar as práticas bem sucedidas e tornar o processo de desenvolvimento mais produtivo e pragmático: o manifesto ágil. Quem freqüenta esse blog sabe que nós somos fãs e seguidores das práticas ágeis, não porque somos fanáticos e acreditamos somente em uma verdade absoluta, mas por que já sofremos muito com projetos e empresas fracassadas, vivenciamos os problemas que compartilhamos neste blog, passamos noites em claro corrigindo código escrito por maus profissionais, acumulamos horas em reuniões suficiente para tirarmos brevê, tivemos que negociar com cliente, com o chefe, fazer entrevista, contratar, gerenciar, analisar, programar, testar… nós sofremos os problemas do waterfall na pele!

O termo agilidade é bem popular atualmente: “precisamos agilizar nosso processo de desenvolvimento”. Como divulgação do manifesto ágil é algo muito positivo, pois mais pessoas podem conhecer e utilizar as práticas ágeis. Mas, como toda fama tem seu lado negativo, não seria diferente neste caso. Muitos profissionais “gafanhoto” estão utilizando esse termo como alavancagem profissional. Já tem gerente falando que RUP é ágil, arquiteto defensor de modelagem UML ágil, diagrama ER ágil, modelo de dados ágil, caso de uso ágil, cronograma ágil, etc. Ou seja, estão distorcendo totalmente o propósito e a filosofia da agilidade.

Como disse o Chapiewski, os programadores estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Agile é muito mais do que desenvolver iterativamente, fazer stand-up meetings e planejamentos ágeis. Não dá para ignorar todas as práticas de engenharia de software que realmente fazem com que a produção e mudanças em softwares sejam ágeis, sem contar todos os princípios e práticas que fazem uma diferença enorme.

O mercado que não é bobo já percebeu esse movimento migratório e lançou seus cursos de “Gerenciamento de projetos ágeis com MSProject”, “Desenvolvendo aplicações web com agilidade”, “Aprenda a programar com JUnit e TDD”. Não demorou muito para que uma massa de desenvolvedores colocasse o termo ágil em seus currículos. Pretensiosos demais em achar que um cursinho qualquer pode ensinar todo conceito e técnicas ágeis catalogadas por profissionais com décadas de experiência em desenvolvimento de software.

“Estou aprendendo Ruby on Rails por que o mercado está pagando bem“. do dia para a noite surgiram milhares de especialistas ágeis. O cara que programava em .NET ou Java no modelo tradicional (digitador de código), faz um cursinho rápido e de repente começa a desenvolver aplicações numa tecnologia que exige uma enorme bagagem conceitual. Faz tudo errado, pois não sabe realmente o que está fazendo, o projeto fracassa e ainda deixa a tecnologia com má fama. Isso aconteceu com PHP, ASP e está acontecendo com Rails.

Programar é difícil, não é um trabalho para qualquer aventureiro. É preciso estudar muito, se dedicar e principalmente, gostar! Não basta apenas estudar para conseguir uma certificação pois não garante nada. Deve-se viver a programação, participar de fóruns, contribuir com projetos open-source, discutir idéias, ser auto-crítico, ler muito, praticar, apreciar as boas práticas e abolir o que não presta…

Agilidade é propor soluções simples para os problemas

Agilidade não é anarquia, não significa “sair fazendo as coisas de qualquer jeito”, dizer “não” para documentação, etc. É uma mudança de atitude, uma nova maneira de enfrentar os problemas e propor soluções simples e práticas, é ter foco, é saber fazer mais com menos, é automatizar tarefas, é estar comprometido… agilidade é atitude.

Contratamos uma consultoria para implantar Scrum

Scrum é a metodologia da moda. Assim que começou a se popularizar entre a comunidade de desenvolvedores, não demorou muito para o que vários sites e blogs se dedicassem exclusivamente na sua divulgação, apresentando benefícios, artigos, guias, exemplos, certificados para imprimir e pendurar em uma moldura na parede, etc. Logo surgiram as consultorias especializadas em adestramento treinamento e implantação de Scrum nas empresas. Um pouco de política aqui e influência ali até que a INFO Magazine publicasse uma matéria dizendo sua empresa deveria usar Scrum como solução para todos os problemas.

Mais uma vez, a falta de foco e maturidade das empresas distorcem tudo. Muitas empresas “compraram” o Scrum como a solução pronta. Bastar treinar os funcionários, comprar blocos de post-it e tudo passa a funcionar bem e gerar lucro. Pagam um curso de “gerenciamento de projetos com Scrum” para os gerentes. Depois apostam todos as fichas em um projeto “piloto”. Fazem tudo que manda o manual: reuniões diárias, planing-pocker, quadro com post-its, etc. E o projeto… fracassa!

Queimando dinheiro

Então quer dizer que Scrum não funciona? Foi dinheiro desperdiçado? Tanto esforço para nada? Neste caso, devo dizer que sim! Se esqueceram do processo anterior falho, funcionários pouco qualificados e dos líderes sem foco. Escolheram aqueles funcionários mais “experientes” para serem o Scrum Master. Sim, aqueles mesmos que só sabiam escrever casos de uso e diagramas UML. Se esqueceram dos valores, dos princípios, da atitude, do relacionamento com o cliente. O pensamento não mudou, o foco ainda era no processo. Depois de tanto esforço, só deram outro nome o waterfall. Não demorou muito e surgiram os papéis, artefatos, documentos… ou seja, a empresa continua cometendo os mesmos erros!

Não importa a tecnologia ou processo se não souber usá-lo corretamente! E definitivamente Scrum não pode ser encarado como mais um processo bonitinho, com seus papéis, artefatos, bla bla bla. Um processo de software que funciona é aquele onde a equipe está realmente comprometida e tem experiência acumulada para enfrentar e resolver problemas ao longo do desenvolvimento da aplicação. O processo, ou metodologia, será meramente um nome para as práticas que a equipe conhece e utiliza naturalmente.

Resumo

Não há ferramenta, metodologia ou processo que substitua a atitude e experiência de um verdadeiro desenvolvedor ágil. Estude, pratique, esteja comprometido, estude denovo, questione-se, estude novamente. Revise seu código, estude mais um pouco, e principalmente, tenha atitude! Agilidade não é metodologia, é atitude!

Atualmente as metodologias ágeis vêm aparecendo com cada vez mais freqüência nas empresas que desenvolvem software, introduzidas pelos próprios desenvolvedores (o que é mais comum) ou em alguns raros casos pela “cúpula” da empresa, na esperança de melhorar a produtividade e/ou o alto tempo de resposta do fracassado processo cascateiro. Porém, esta “fama” prematura dos métodos ágeis tem gerado mais resultados ruins do que bons. Sua aplicação na vida real, na maioria em muitos casos, ocorre de maneira equivocada, distorcida e desprezando-se os reais valores e princípios que apoiaram o surgimento desta filosofia.

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!

Desenvolver software é uma atividade muito gratificante pois sempre podemos (ou deveríamos) exercitar nossa criatividade para solucionar os problemas dos clientes. Isto, apesar de divertido pode ser perigoso e/ou catastrófico se estivermos com o foco errado. Num ambiente cascateiro, onde cada envolvido está comprometido apenas com o processo e não se preocupa verdadeiramente com os problemas dos clientes, não é difícil que isto ocorra. Quase sempre o foco acaba sendo direcionado para a solução ao invés do problema.

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! ) 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!?!

Se você freqüenta este blog já deve ter percebido que nós não gostamos da maldita cascata. Fases bem definidas, detalhamento de requisitos, documentos inúteis, diagramas UML, papéis… tudo muito lindo na teoria. Eu fico até emocionado quando leio a documentação do RUP. Mas infelizmente a maioria dos profissionais de TI precisam são obrigados a trabalhar nestes ambientes cascateiros, enfrentando chefes sem noção, colegas com síndrome do funcionário público, prazos sem sentido, entre outras pérolas da área.

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!

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

Eu preciso desenvolver uma idéia que vem me provocando ultimamente. Na verdade é menos uma idéia do que um reflexo da situação desoladora em que a maioria de nós está.

Em se tratando de 1up4dev, nem preciso dizer que a situação a que me refiro é a de quase inevitabilidade do waterfall, em que estamos tão engolidos pelo “sistema” que, aparentemente, só nos resta lamentar, se frustrar e eventualmente se acostumar com tudo. Não deduzo, porém, que esses são estágios de uma manifestação de bunda-molice. Do contrário, seria suficiente encerrar o assunto com algo do tipo “ou somos parte da solução ou do problema” (doutrina Bush, em pleno 2008). E ainda assim, sem que ao menos sejam esboçados tanto “o problema” como “a solução”, esse raciocínio binário não serviria para nada.

Antes de continuar com a minha idéia, gostaria de escrever rapidamente sobre o panorama que se desenha para o futuro. Especificamente, o nosso futuro. Nem sempre lembramos dele, mas é lá que vamos viver em breve. E sem querer parecer auto-ajudesco, digo que o futuro do desenvolvimento de software está nas nossas mãos — e não de forma indireta ou abstrata. É lógico: as mãos que hoje controlam o “sistema” vão se aposentar daqui uns anos, e as nossas vão substituí-las. Nessa seqüência, é possível imaginar que, em breve, estaremos perpetuando o waterfall. Pois nesse dia nós é que seremos o status quo, e o status quo, para ser digno do nome, não quer saber de mudar nada.

Software já é estratégico há algum tempo e ocupará cada vez mais espaço na vida das pessoas, das empresas e dos governos. Que qualidade de software será oferecida quando nossa geração estiver no comando? Imagine o alto custo financeiro e social de se manter na periferia de TI. Sub-desenvolvimento passa a ter um novo significado, não é? Temos que assumir a responsabilidade, até porque ela pode significar a existência dos nossos empregos. Ou você vai preferir usar um software made in India?

Nada contra a Índia, claro. Mas o alerta já tinha sido dado por David Anderson no comecinho do livro Agile Management for Software Engineering. Abaixo traduzo livremente um trecho cujo original você encontra na página xxvi do livro:

Se a atividade intelectual de software tiver que permanecer nos países desenvolvidos e se os engenheiros de software americanos, europeus e japoneses quiserem manter o alto padrão de vida ao qual se acostumaram, eles devem aumentar sua competitividade. Há um mercado global de desenvolvimento de software, o que encolheu a distância entre um cliente na América do Norte e um fornecedor na China ou na Índia.

Esse medo do sr Anderson tem que ser nosso também (exceto que nós não temos como rebaixar nosso “alto padrão de vida”). Sabemos que precisamos melhorar, e muito, a nossa competitividade, e não só individualmente. Agora, a grande questão é: como vamos fazer isso, se não temos suporte para viabilizar novas formas de trabalho sem dispararmos o sinal de pânico no chefe, no cliente?

Pretendo desenvolver a minha sugestão em alguns posts, seguindo alguns princípios:

1. “Mudança” é definida como o amplo abandono da mentalidade waterfall no mercado de TI.
2. Você acredita na mudança e é o maior interessado nela, pois ela representa o futuro que você quer.
3. O risco da mudança é percebido com mais intensidade quanto maior é o poder de quem a observa.
4. O benefício da mudança é percebido com menor intensidade quanto maior é o poder de quem a observa.
5. A mudança pode ocorrer de baixo para cima na cadeia de poder.

No próximo post, pretenderei detalhar melhor os efeitos desses cinco pontos. Dali em diante, dificilmente irei sugerir uma ação coordenada e planejada — nada menos ágil que isso! Prefiro apostar no desenrolar natural das coisas, desde que os princípios sejam válidos. No mínimo, vamos avançar o debate. Tomara que eu não escreva muita besteira, e espero ser corrigido a qualquer momento.

Falta pessoal qualificado em TI, diz Assespro

http://www.guj.com.br/posts/list/15/92783.java#497015

Esta discussão está boa, e no meio das chamas levei um “impacto” ao ler a frase abaixo.

louds wrote: [...] Não usem a incompetência alheia como desculpa. Se está ruim e você não está ativamente combatendo isso, você é parte do problema e não da solução. [...]

Esta é uma das frases que eu deveria lembrar toda vez que começo a lamentar sobre o ambiente atual de trabalho, eu tento, me gerencio, mas confesso que é difícil.

Com o diabinho no ombro, logo ouvi um suspiro … Waterfall é bom ! Não questione … volte a codificar … Só que ao olhar pro lado, vi o meu poster do Dijkstra e voltei a realidade. Foi quando me perguntei:

Por que é difícil combater o Waterfall ?!?

Sei que esta é uma pergunta sem resposta direta e que depende de muitos fatores do seu ambiente de trabalho, mas eu numa análise fria e cruel respondo: Porque a maioria não sabe o que é waterfall.

No último ano da faculdade (cursei Sistemas de Informação), e sem brincadeira, nas aulas de Engenharia fui obrigado a decorar todas as fases, papéis, artefatos e etc. do RUP, e pra fechar com chave de ouro, no segundo semestre veio o famoso Análise de Ponto de Função. Isso somente prova que já aprendemos errado, e sei que muita gente fica nisso. Se hoje tivesse a oportunidade de encontrar este mesmo professor, iria fazer a pergunta acima, e acrescentar com questionamentos como, engenharia de software não é eng. civil e neste processo todo quem está preocupado com o Retorno de Investimento do cliente !?!

Acredito que a chave para combater o Waterfall é conhecimento, temos que trazer questionamentos a quem está do lado e isso não é nada fácil, como você convence os mais de vinte desenvolvedores que estão ao seu redor que eles estão na Matrix !?! O que fazer com o pessoal que não quer sair da Matrix !?! O Waterfall é uma grande mãe que coloca muitas pessoas (Analistas, Desenvolvedores, Gerentes, Testers … etc.) numa casca irreal de proteção e que gera um ciclo vicioso que se auto sustenta.

Neste exato momento que sou obrigado a concordar com o grande malucão Raulzito:

É pena não ser burro ! Não sofria tanto.

As vezes me questiono sobre esta insistência em tentar mudar, nadar contra o Waterfall. Não seria melhor se “render” logo e entrar no jogo, sei lá, poder falar, “Caso de Uso não é comigo, só programação!” e ver que são 10 pras 18, desligar o computador e sair sem o minimo peso na consciência.

Por que numa equipe de dez desenvolvedores, só eu sinto falta de testes unitários !?! Fico indignado ao receber um caso de uso que não agrega nada ao cliente, somente foi “inventado” pra ser cobrado dele, e só eu que vejo isso !?! Sei lá, eu devo estar maluco mesmo com toda esta historia de desenvolvimento ágil, e se preocupar com ROI do cliente, apesar de achar uns malucos por ai que sofrem do mesmo “problema” que o meu.

Como no filme dos 300, tenho esperanças e sei que poucos enfrentarão muitos, e continuo minha batalha com o Waterfall.

Paz a Todos !

Obs: Sei que o RUP é mal usado, pois uma brecha dele é ser muito genérico, e isto cada vez se confirma mais, que o modelo atual “tradicional” está falido.