Débito Técnico

No sábado ministrei um Workshop Scrum e surgiram alguns assuntos que achei legal “documentar” aqui.

Se eu pudesse pegar um único valor ágil do XP e pudesse dar “uma injeção” desse valor nas pessoas eu escolheria a CORAGEM. Logicamente a coragem não é tudo que as pessoas e as empresas necessitam, porém, vejo que a falta de coragem gera uma paralisia. A paralisia é um dos sintomas do medo.

“Courage is effective action in the face of fear.”
Kent Beck

Creio que a definição do Kent Beck acima não necessita de tradução (acho que não sou muito bom em traduções, já que muita gente reclama delas nas minhas publicações). É interessante notar que coragem é uma ação e não um sentimento. É uma ação em resposta ao medo.

Algumas pessoas me perguntam porque sou tão crítico com relação aos “gerentes”. Bem, tenho contato com muitos profissionais de tecnologia nos treinamentos da Aspercom. Meu conhecimento dos problemas do mercado vem desses profissionais. Atualmente vejo que muitas práticas erradas adotadas pelas empresas, citadas nas minhas publicações, são defendidas por “gerentes covardes”.

As práticas ágeis estão começando a despontar aqui no Brasil. Scrum é uma metodologia que cresce a cada dia. Minha visão do mercado é que temos 3 “camadas de decisão” sobre a adoção de práticas ágeis. Só esse assunto já geraria um artigo, mas, só para iniciar o assunto “gestão covarde”, essas camadas são:

1. O Empre$ário
2. Os “Gerentes”
3. As equipes

Por mais incrível que possa aparecer, o empresariado (os caras que estão pagando a cara conta do desenvolvimento de software “Tradicional”), aceita Agilidade. É isso mesmo! Se você conversar com qualquer empresário você terá o seguinte padrão de diálogo:

Você: - O quanto você está gastando com projetos de software atualmente?
Empresário: - Muito!
Você: - E você está satisfeito com os resultados?
Empresário: - Não… os projetos atrasam, a aderência das soluções ao negócio geralmente são precárias e trocamos farpas com o fornecedor diariamente…
Você: - Você já ouviu falar em desenvolvimento iterativo?
Empresário: - Não…
Você: - O desenvolvimento iterativo é uma maneira de você diminuir o risco dos projetos, avaliando o trabalho do fornecedor durante todo o projeto e não somente no final. É uma forma de contratação que permitirá você proteger o investimento. Se o fornecedor não te atender da maneira esperada você não perde dinheiro…
Empresário: Puxa, me fala mais desse tal projeto iterativo…

Não há dúvidas que os benefícios para quem está pagando a conta são inúmeros para quem adota o desenvolvimento ágil. Sobre as equipes, elas também adorariam (com poucas excessões) adotar uma postura ágil. As equipes estão sobrecarregadas de burocracia, e muitos profissionais estão cansados da ineficiência de tantas práticas ruins. E o melhor de tudo: os profissionais estão estudando. Vejo cada vez mais nos meus treinamentos, nos fóruns de discussão e também nas pessoas que buscam informações no site da Aspercom que a procura por abordagens ágeis e as boas práticas de desenvolvimento de software estão em alta.

O problema está no nível gerencial. Os gerentes que compram, os que estão do lado do empresário, se sentem de mãos atadas, levados pelas más práticas do mercado. Os gerentes do lado do fornecedor, principalmente as “fábricas de software” tomam uma postura covarde pois não estão dispostos a correr riscos para atender melhor seus clientes. Para eles, as práticas ruins são boas, pois não arriscam seus salários que pingam a cada mês e eles não precisam aprender mais nada. Pegando esses gerentes do lado fornecedor, vemos algumas espécies de covardias do gerenciamento:

Gestor Covarde

Gestor Covarde foi um termo que encontrei para demonstrar um gerente que tem uma aversão patológica ao risco. Devemos buscar e mitigar riscos e não temê-los. O gerente covarde natural geralmente inicia o trabalho pelas tarefas menos arriscadas para mostrar que o projeto andou. Uma frase comum ao gerente covarde é:

- Este software é crítico. Vamos começar a comê-lo pelas beiradas. Vamos fazer todos os cadastrais e relatórios primeiro, depois fazemos o “core business”.

O gestor covarde teme as funcionalidades críticas de um software e tende a desenvolvê-las no final. As boas práticas de programação nos dizem o contrário: começe a desenvolver o software por aquilo que é mais complexo ou por aquilo que é mais crítico para os usuários. Como já havia comentado no post “Por que Gantt Charts não servem para projetos de Software?”, é comum que o gerente covarde mostre resultados maquiados. Nunca confie num relatório de status se problemas de negócio não estão sendo resolvidos através de software funcionando.

Uma coisa que poucas pessoas compreendem é que dificilmente existe dependência entre requisitos. Você pode começar a fazer o software por onde você quiser. É preferível que você inicie o desenvolvimento pelas funcionalidades mais importantes do seu cliente para demonstrar valor iterativamente. Se é um sofware de vendas nós iniciamos o desenvolvimento pelo Pedido de Vendas. Se é um software de prontuário eletrônico começamos o desenvolvimento pela Prescrição. Se é um software para automação de uma oficina, começamos pela abertura de atendimento. Inicie por aquilo que é mais significativo e o projeto será entregue antes do prazo. É aí que entra a coragem. Bem, algumas equipes podem ser covardes também.

Geralmente quando apresento isso os covardes retrucam:

- Como é que você vai demonstrar o pedido de vendas primeiro se você não tem o cadastro de produtos, o cadastro de clientes, o cadastro de usuários e blá, blá, blá?

Minha resposta: - Já ouviu falar do comando SQL INSERT?

O fato dessas entidades (produtos, cliente, usuário) serem parcialmente necessárias para a emissão do pedido, as telas de cadastro dessas entidades não são necessárias. Repito: Dificilmente existe dependências entre requisitos de software. Ao menos com relação a maneira que o software é construído. Você pode começar a construir o software por qualquer parte.

Existem outras características do gestor covarde. Geralmente ele cobra prazos mas desconhece os problemas. É acostumado a dar uns gritos e socos na mesa de vez em quando. É comum ele se esconder atrás de um Gantt Chart. Tem um post interessante que abri no GUJ:

http://www.guj.com.br/posts/list/68516.java

Gerente-Proxy

Uma definição formal do que é um proxy pode ser encontrada aqui.

http://pt.wikipedia.org/wiki/Proxy

Já teve alguma experiência em projetos onde “tudo deve passar pelo gerente”? Qualquer dúvida a tirar com o cliente deve primeiro passar pelo gerente? Esse é o gerente-proxy. Esse gerente é aquele que tem medo do que a equipe possa falar para o cliente. E também teme as verdades que o cliente possa falar para a equipe. A desculpa mais esfarrapada é: -”Não vamos perguntar a mesma coisa duas vezes para o cliente”. Geralmente nos meus projetos eu pergunto mais de 10 vezes a mesma coisa para os clientes e até agora não tive reclamações deles. Se o cliente não está disposto a participar é muito questionável a necessidade do projeto.

O Gerente-Proxy geralmente teme estar por fora das coisas que acontecem no projeto. Mas antes disso, ele tem medo de “sair do escopo”. Escopo em software é muito mal compreendido. É comum confundir escopo com requisitos detalhados em projetos de software. É comum achar que para se ter estimativas os requisitos devem estar documentados. Poucos entendem a natureza empírica de um projeto de software.

A colaboração entre os reais usuários e a equipe é primordial para o sucesso do projeto. Isso é defendido em todas as metodologias de desenvolvimento de projetos de sofware. Essa comunicação deve ser constante e não deve ter barreiras entre os desenvolvedores e os especialistas do negócio. É comum que ao final de um projeto que teve essa comunicação os desenvolvedores tenham um conhecimento do negócio muito próximo aos especialistas.

Tenho muitas outras espécies de gestores covardes. Mas fica para outros posts…

Este conteúdo que postei só pra iniciar o blog faz críticas duras a maneira como projetos de software são construídos ou gerenciados. Muitas empresas utilizam essas má praticas e já esperava que a opinião de muitos leitores iriam divergir. Vou tentar explicar um pouco mais meu ponto de vista.

De qualquer forma, desculpem a sinceridade, desculpem se isso pode ofender alguém, desculpem falar “na lata”, mas SÓ AGILIDADE FUNCIONA.

Desde 2005, quando iniciei a área de treinamento da ASPERCOM ouço constantemente uma afirmativa. Seja em palestras, seja em fóruns de discussão, seja em treinamentos, seja em consultoria ou projetos que participo, sempre ouço participantes dizendo “Tudo o que você falou que é errado é o que praticamos na nossa empresa.”

É triste mas é verdade. Existe um gap muito grande entre a teoria e a prática na nossa área de desenvolvimento de software. Por exemplo, neste ano de 2008 já tive contato com aproximadamente 200 profissionais em treinamentos. Numa pesquisa rápida, TODOS disseram praticar o processo de desenvolvimento em cascata (waterfall), mesmo que este modelo seja comprovadamente ineficiente e seja refutado por TODOS os autores que escrevem sobre desenvolvimento de software. Até mesmo o autor que cunhou o termo “Waterfall” já reconhecia que era um modelo que não deveria ser utilizado, que é um anti-pattern. Teve um aluno de uma turma de UML que ainda foi mais enfático “- É lógico que todo mundo aqui faz software em cascata!”.

Antes de continuar, para tentar explicar porque só agilidade funciona, vamos ver uma “ilusão” que o mercado tem chamado de “Modelo Tradicional” (ou agora também temos o “Modelo Controlado”, mais um devaneio inconsequente escrito por um “especialista” sem noção).

Modelo Tradicional x Modelo Ágil

A pergunta que me levou a escrever é: O que é o Modelo Tradicional? Durante aproximadamente uns 2 meses perguntei em praticamente todos os fóruns de discussão que participo (veja links do Blog) o que seria o modelo tradicional. Essa pergunta foi provocativa, mas ao mesmo tempo elucidadora para muitos. O fato é que NINGUÉM soube responder o que é o Modelo Tradicional. Ninguém soube explicar, ou citar, que autor escreveu ou defendeu algo chamado “Método Tradicional de Desenvolvimento de Software”. Nenhum modelo de processo é Tradicional. O Modelo Tradicional não existe.

Alguns citaram que o modelo tradicional é o Waterfall. Bem, como expliquei aqui, o Waterfall não é defendido em nenhuma literatura. Ok… ele pode ser tomado como tradicional pois é o modelo mais utilizado, porém, o modelo waterfall não tem sustentação teórica. Nenhum autor sério defende waterfall. Como pode pois a nossa indústria estar usando um modelo que desde o nascimento foi taxado como anti-pattern? Se o Waterfall é o modelo tradicional, seguimos uma tradição bem burra.

Outros citaram que o modelo tradicional é o RUP. Mais uma discordância aqui. O RUP é um “agile process framework”. Jacobson, Larman, Booch, Ambler são Rupeiros de plantão como eu e praticam agilidade. O problema com o RUP é que poucos compreendem o RUP. Já ví muitos “especialistas” em RUP falando muita besteira no mercado. Aqui no Brasil conheço 5 a 10 pessoas que realmente conhecem o RUP. O mercado tem um poder enorme de deturpar coisas que ele não compreende (quantas vezes você não ouviu sarcasticamente que XP “é aquela metodologia que são dois programadores por micro”?). O RUP verdadeiro, o que consta na literatura, é ágil. Se o RUP verdadeiro fosse o adotado nas empresas todas seriam ágeis e este artigo não precisaria existir.

Outros citaram o SWEBOK como sendo o Modelo Tradicional. Bem, o SWEBOK é um body-of-knowlegde jogado as moscas. Ninguém tá procurando hoje SWEBOK. SWEBOK surgiu recentemente, assim, não poderia ser tomado como Tradicional. O RUP é um body-of-knowledge mais maduro e mais experimentado que o SWEBOK.

Se você nunca parou para pensar pergunte a sí próprio: Quem falou que desenvolvimento de software é sequencial como Caso de Uso - UML - Codificação e Teste? Quem disse que Gantt Chart é bom para desenvolvimento de software? Que pesquisa revelou que especialização e divisão do trabalho é uma boa idéia para software? Por que eu tenho que levantar todos os requisitos antes? E a principal: Se waterfall funciona por que meus clientes estão insatisfeitos?

Essas práticas não tem o mínimo fundamento teórico, nenhuma literatura prega que desenvolvimento de software é assim. Sim, você que é universitário pode questionar seu “mestre”, pois muitos não tem a mínima noção ou experiência no que estão ensinando. Essas práticas erradas são “idéias” que gerentes burros adotaram simplesmente fazendo um comparativo com linhas de produção da indústria. Eles se encheram de práticas sequenciais e colocaram uma placa na frente da empresa: “Fábrica de Software”. Eles simplesmente viraram as costas para os avanços da tecnologia e desenvolvem software como se estivessem furando cartões em 1960.

Com isso colocado, não vejo o mínimo sentido as pessoas afirmarem que são “tradicionalistas” no desenvolvimento de software e por isso não são ágeis. Não faz sentido pessoas dizerem “Eu desenvolvo software no modelo tradicional e estou estudando modelos ágeis”. Se você parar para pensar, essa pessoa começou agora a estudar desenvolvimento de software. Não confunda tradicionalismo com burrice.

Agilidade não é falta de controle

Como o já citado “devaneio inconsequente“, o mito mais comum é que modelos ágeis são descontrolados e que não dão informações para o gerenciamento. Quando falamos sobre controle temos que ter em mente o que realmente queremos com o projeto.

Como podemos planejar e ter precisão nas nossas estimativas?

Como devemos capturar os reais desejos do cliente?

Como incorporar as constantes mudanças no projeto?

Como fazer com que as mudanças não impactem aquilo que funciona?

Qual arquitetura é a certa para meu projeto?

Como garantir a manutenção futura do sistema?

Como saber o real andamento do projeto de uma maneira livre de riscos?

Como ter certeza que estamos satisfazendo a real necessidade do cliente?

Como fazer a equipe não se dispersar?

Como manter a documentação atualizada?

Como manter prazo e planejamento num projeto em constante mutação?

Como me antecipar aos riscos?

Quais são as ferramentas certas?

Como evitar correrias, horas extras e a explosão de custo no final do projeto?

E a melhor de todas: Como fazer o projeto ser entregue muito antes do prazo?

Creio que estas e muitas outras perguntas são dúvidas muito frequentes para qualquer equipe que desenvolve software. O mais interessante é que a resposta está na frente deles e se chama AGILIDADE.

Os modelos ágeis são os modelos MAIS CONTROLADOS QUE EXISTEM. Se eu disser para você é possível fazer com que a equipe trabalhe motivada, focada em objetivos e que a assertividade das estimativas são muito próximas de 100% você acreditaria? Se eu disser para você que o simples fato de planejar baseado em objetivos e promover uma reunião diária de 15 minutos pode fazer com que a comunicação enriqueça e que o cliente sempre fique satisfeito mesmo com algumas falhas você acreditaria? As práticas do Scrum (que são baseadas no RUP) promovem esse tipo de controle.

Outros pontos. Se eu falar para você que com seu código coberto de testes automatizados você poderá incorporar mudanças com uma segurança total você acreditaria? Se eu falar pra você que esses mesmos testes automatizados podem servir como documentação dos requisitos e do design de maneira executável, e que através de um relatório de cobertura e muitas outras ferramentas deterministas é possível saber se a “documentação” está atualizada de fato, você acreditaria? Essas são práticas do XP e da TDD.

Se eu falar para você que aproximar o cliente da equipe de desenvolvedores, promover a colaboração e colocar “dois programadores para trabalhar numa mesma máquina” trocando pares é um excelente mecanismo para ganhar produtividade removendo atividades inúteis você acreditaria?

A melhor resposta para o controle são práticas ágeis. Até o momento nenhum outro modelo provou ser eficaz. Nem Gantt, nem PMBOK, nem CMMI, nem MPS.BR são modelos completos que garantem respostas para as perguntas acima. Muito menos um mito, um dogma, um devaneio inconsequente que se criou nas mãos de pessoas que não sabem desenvolver software e chamaram isso de “tradicionalismo”.

Práticas ágeis não competem com “alguma outra coisa” que funciona.

Conclusão: (pela milésima vez)
O modelo tradicional não existe.
Só Agilidade funciona.

Clique na imagem para aumentar…

Durante um único dia de trabalho de uma equipe ágil temos alguns instantes que fazemos a reunião em pé do XP ou o encontro diário do Scrum. Esta mini-reunião é um ponto de sincronização do status do projeto (é uma inspeção no ciclo da iteração). O Scrum sugere que essa reunião tome o tempo máximo de 15 minutos. Dentro de um dia de trabalho de uma equipe ágil, fora desses poucos minutos preocupados com o gerenciamento a equipe trabalha no sentido de fazer incrementos de software funcionar de maneira “atômica”, isto é, um pequeno requisito é capturado e rapidamente transformado em software funcionando. Isso é o ciclo ágil de um dia. Assunto que tratarei na próxima edição da MundoJava.

Uma caracterísca marcante do ciclo ágil de um dia é que ele é não precisa ser gerenciado no nível macro, isto é, ele não pode ser tomado como base para o andamento do projeto como um todo. Somente com software funcionando e usuários felizes é que você pode dizer que o projeto andou. Este ciclo ocorre de maneira muito rápida e quem gerencia é o próprio desenvolvedor. Essa responsabilidade é uma cultura auto-organizável que faz parte do cerne do gerenciamento ágil. Gerentes de Projeto e Coordenadores não devem interferir no trabalho que é responsabilidade técnica dos desenvolvedores.

Os pontos que defendo aqui são práticas ágeis essencialmente constantes na metodologia XP e no TDD. Infelizmente essas práticas não são adotadas na maioria das equipes que tive contato. Um padrão muito comum nas equipes são práticas fantasiadas de Unified Process (ou RUP) que seguem um formato “Casos de Uso - UML - Codificação - Teste”, seguindo basicamente um processo em cascata numa escala menor. Este modelo dá a entender que requisitos estão em Casos de Uso (geralmente em documentos Word), o projeto ou arquitetura está no modelo UML (uma abstração intermediária), o código simplemente é algo que o computador compreende e, ao final, testes baseados no Caso de Uso são aplicados.

Primeiramente, gostaria de deixar claro que esta pode ser uma maneira de você implementar uma funcionalidade específica de um usuário com certo sucesso, porém, esse tipo de desenvolvimento não deve ser sequêncial e nem mesmo ser um padrão para todas as funcionalidades e nem para todos os projetos. Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados. Porém, existem outras maneiras de você alcançar este mesmo objetivo! O próprio RUP não prega este tipo de prática.

Este anti-pattern causa uma cegueira técnica. O fato de sempre ter Casos de Uso, UML, Código e Testes em cascata leva a equipe a acreditar que todos os requisitos estão em casos de uso, temos que modelar tudo e codificar é uma atividade pouco criativa, assim como os testes. Porém, se verificarmos que estatisticamente somente um terço dos requisitos estão em casos de uso [Cockburn], que modelamos somente o que precisa ser modelado [Yoshima] e que todo o processo de desenvolvimento de software é uma atividade criativa (inclusive os testes [Fowler]), vemos que este padrão é muito questionável e muito dispendioso.

Você pode utilizar Casos de Uso para capturar requisitos e utilizar UML para analisar um problema. A culpa não é dessas ferramentas! O maior problema desse padrão é não conversar mais com os usuários depois que o Caso de Uso está escrito, roubando sorrateiramente a comunicação entre a equipe técnica e o cliente durante o desenvolvimento. Refinamentos surgem o tempo todo! A equipe precisa durante o desenvolvimento ligar para o cliente e tirar dúvidas! É comum que durante a codificação novos requisitos não capturados emergam. Requisitos capturados, modelados, codificados e testados podem não ser o que o usuário queria de fato, pois artefatos como Casos de Uso e modelos UML são propensos a muitas imperfeições (são abstrações e não são naturalmente executáveis).

Vejo que o padrão “Caso de Uso - UML - Codificação - Teste” é uma má influência do processo Waterfall, que declaradamente é uma péssima prática para desenvolvimento de software. Esse pensamento seqüencial é ainda mais danoso quando tentamos encaixar este padrão dentro da divisão e especialização de trabalho do Taylorismo, comum em fábricas de software. Nesse cenário, um analista de negócios escreve Casos de Uso, um analista de sistemas desenha o modelo, um programador codifica e um testador testa. Essa equipe muitas vezes utiliza artefatos para se comunicar (e logicamente, cada passo geralmente é controlado por um Gantt Chart). Antes de prosseguir, veja a citação de Kent Beck a respeito do Taylorismo:

“Especialização e rigorosamente dividir e conquistar serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido.” Kent Beck

A base da divisão do trabalho é que é possível quebrar um determinado processo em partes menores gerenciáveis, e se cada parte for otimizada, o processo como um todo é otimizado. A especialização diz que determinado recurso efetuando uma tarefa várias vezes torna-se ótimo para esta tarefa. A questão é que para desenvolvimento de software, nem sempre a soma “Casos de Uso + UML + Código + Testes” geram algo do agrado do usuário se ele não estiver envolvido em todo o ciclo. Isso nos mostra que esses passos não são mensuráveis. Além disso, um analista de negócio não se tornará um analista de negócio melhor se ele escrever muitos Casos de Uso, assim como acontece com um Analista de Sistemas ou Programador.

Desenvolvimento de software não é um processo mecânico. Todas as metodologias atuais pregam um trabalho coletivo, em constante comunicação, entrosamento e principalmente uma visão holística sobre o projeto (o todo, e não as partes). Se apegar a rígidos papéis e responsabilidades é péssimo sob qualquer aspecto para uma equipe que desenvolve software.

Neste fim de semana estava lendo a Revista Exame. A capa tem uma chamada enorme com o logo do Google (edição 915). A jovem jornalista Larissa Santana, diretamente de Montain View, relatou como é o dia a dia de uma empresa que conforme a revista é uma empresa do século 21.

“Como pessoas, empresas têm personalidade, que pode ser forte e marcante ou fraca e apagada. Uma companhia pode ter alma de líder. Ou espírito de seguidor. Pode gerar o amálgama que que junta pessoas em torno de um objetivo maior. Ou pode ser um agrupamento de gente em busca do salário nosso de cada mês.” Editorial de Cláudia Vassalo

O texto está excelente, e para quem já conhece práticas ágeis, dá pra ver que a cultura Google é encharcada de conceitos ágeis.

“Lá eles são livres.”

É interessante notar que muitas das empresas que conhecemos hoje estão tendo sucesso por possuirem uma cultura empresarial forte. Gigantes como o Google, Microsoft, IBM e outras tentam continuamente se reinventar. No caso do Google, no artigo, é interessante como na entrevista com Eric Schmidt transpareceu que talvez a cultura empresarial é mais importante que crescer desorganizadamente ou só visar o lucro a qualquer preço.

“Manter a cultura do Google enquanto a empresa cresce é uma das nossas maiores prioridades. Seguimos a filosofia de agrupar os funcionários em pequenos grupos, e vamos continuar a organizar a empresa dessa maneira. É um modelo que tem sido crítico para nosso sucesso” Eric Schmidt

Na mesma edição da revista há uma matéria chamada “Choque de Pragmatismo”, sobre o plano de recuperação da Light. É interessante também ler o texto sob uma perspectiva ágil. Foco em objetivos e a busca por atalhos mais simples para obter sucesso foram marcantes para a solução dos problemas.

Cultura empresarial não é algo que nasce do dia para noite e nem mesmo através de imposição. Poucas das empresas que tive contato aqui no Brasil demonstraram uma cultura social marcante e empolgante (infelizmente). Criar uma cultura empresarial inicia por parte dos líderes que demonstram valores claros, e nesse sentido, todas essas empresas que possuem cultura bem formada seguem o primeiro valor ágil que é valorizar as pessoas.

Por outro lado, as pessoas, as equipes devem demonstrar iniciativa e auxiliar a formação de uma boa cultura empresarial. A comunicação participativa pode ser uma parte importante de uma boa cultura empresarial. É importante ressaltar que todas as empresas possuem uma cultura. A questão é: Ela é boa ou é ruim? Como é a cultura empresarial da sua empresa? O que pode ser feito para melhorá-la?

Feedback do Workshop Scrum ministrado na Sumus.

Este curso particularmente foi interessante pois toda a gerência (e até os donos da empresa) participaram. Eles procuram adotar uma estratégia “Enterprise Scrum”.

Não é só a imagem abaixo e a substituição do Gantt que foram empolgantes. A equipe demonstrou real entusiasmo com o planejamento e as práticas do Scrum!

Abraços a todos da equipe Summus.

———- Forwarded message ———-
From: Fernando
Date: 03/04/2008 12:19
To: Rodrigo Yoshima

Ae Rodrigo blz?

O pessoal curtiu muito o curso, todo mundo falou bem, e o impacto do curso ta na foto anexa no email, lembra aquele quadro do gantt chart? virou isso aí que voce tá vendo!

Abraços,
Fernando