Archive for the ‘Engenharia de software’ Category

Um exemplo prático de Fluent Interface

Monday, March 3rd, 2008

Há alguns meses escreví um post sobre Fluent Interfaces, mostrando um trabalho que fizemos aqui na empresa para tornar nossa API interna mais fácil de se utilizar. Depois disso, algumas pessoas me pediram códigos e exemplos de uso da WebMediaAPI, mas o código é da empresa e não posso compartilhá-lo.

Fiquei então com a idéia de criar uma demonstração de uso de Fluent Interfaces na cabeça, mas eu queria usar um domínio fácil para que as pessoas pudessem entender melhor. A WebMediaAPI pode ser até legal, mas o fato é que ninguém conhece o modelo de mídias da Globo.com e fica difícil de explicar ou discutir o que está sendo feito.

Há duas semanas, conversando com o Evandro sobre uma apresentação que faremos mês que vem no evento de tecnologia da Globo.com, ele deu uma idéia super simples e bem legal. Todas as pessoas já trabalharam com e-mail, seja enviando mensagens para outras pessoas ou então escrevendo código para enviar e-mails em diversas linguagens. Esse é um domínio extramanete fácil para todo mundo, e também, é pequeno o suficiente para ser implementado rapidamente em um dia.

Então, nasceu a Fluent Mail API. A Fluent Mail API é uma API simples que utiliza a JavaMail API da Sun para enviar e-mails. Meu objetivo não é criar mais uma ferramenta para envio de e-mails, é apenas demonstrar o uso de Fluent Interfaces como wrapper de um framework maior, simplificando seu uso. A idéia é fazer com que enviar um e-mail seja tão fácil quanto isso:

new EmailMessage()
    .from("demo@guilhermechapiewski.com")
    .to("destination@address.com")
    .withSubject("Fluent Mail API")
    .withBody("Demo message")
    .send();

Você pode ver os códigos-fonte e uma descrição mais detalhada no site do “projeto”. Se alguém quiser discutir, opinar, tirar dúvidas ou qualquer outra coisa, é só comentar.

[JBoss World 2008] Max Ross: Hibernate Shards

Friday, February 15th, 2008

JBoss World 2008 - Max Ross - Hibernate ShardsMax Ross, do Google, fez uma apresentação sobre o Hibernate Shards.

Desenvolvido em 6 meses como um “pet project” (projeto pessoal) usando 20% do tempo de 3 engenheiros, o Hibernate Shards foi lançado internamente no Google em dezembro de 2006 e depois doado para a JBoss em maio de 2007.

“Shard” é um termo que o pessoal do Google usa para falar de divisão/particionamento. O Hibernate Shards é um framework de persistência baseado no Hibernate, usado para dividir os dados entre vários bancos de dados diferentes, criando um particionamento horizontal das informações.

Resumidamente, o particionamento horizontal é usado quando você têm aplicações com bancos de dados monstruosamente grandes e você precisa distribuí-los em vários bancos de dados. Então, você tem várias instâncias de banco de dados diferentes, todas com o mesmo schema, e com os dados divididos entre elas. Quem gerencia onde está cada banco de dados e em qual “shard” (partição/bucket/o que você quiser) estão os dados é o Hibernate Shards, de forma transparente para a aplicação. O Shards pode usar qualquer banco de dados suportado pelo Hibernate (ele tira vantagem dos dialects).

Os criadores do projeto queriam que fosse fácil e natural para os usuários de Hibernate usá-lo, por isso ele usa vários conceitos familiares como, por exemplo, a ShardedSessionFactory, que implementa a interface SessionFactory. Eles tem uma ShardedSession, e por aí vai.

Apesar do Shards ser totalmente compatível com Hibernate do ponto de vista da aplicação (porque usa as mesmas interfaces), ele não suporta JPA, a implementação de Query ainda não funciona 100% e vários outros probleminhas e “gaps” em relação ao Hibernate…

Confesso que fiquei um pouco decepcionado, porque pelo que eu tinha conversado com o pessoal por aí, parecia que ele seria uma forma de ter um schema distribuído em vários bancos de dados diferentes, e isso ia resolver um problema gigante que tenho. Mas descobrí que isso que eu preciso é particionamento vertical. Perguntei para o Max se daria para fazer alguma adaptação e ele falou que até seria possível escrever um ShardStrategy que quebrasse um galho, mas eu teria muitos problemas maiores pra resolver.

Ao menos serviu para conhecer esses conceitos de banco de dados, que de certa forma eu conhecia mas não da maneira formal.

[JBoss World 2008] Mladen Turk: JBoss Web Server

Friday, February 15th, 2008

Mladen Turk acabou de fazer sua apresentação sobre o JBoss Web Server, que é um web server/container baseado no Tomcat, projetado para aplicações de médio e grande porte. Ele suporta Java (JSPs, Servlets, etc), PHP, e CGI. Basicamente ele concorre com o Tomcat, com a vantagem de que é excelente para prover conteúdo estático, lidar com milhares de requisições simultâneas e tem um container web bem razoável, suficiente para a maioria das aplicações.

É óbvio que o criador dele só poderia falar que ele é ótimo, então a opinião dele é suspeita. Mas o fato é que na Globo.com temos usado JBoss Web em várias aplicações e de fato ele é muito bom. Ele realmente aguenta o tranco de milhares de acessos e definitivamente é muito mais estável que o Tomcat, e muito mais leve que o JBoss. IMHO, ele é o mais completo da atualidade e é a minha primeira escolha para os tipos de projetos que tenho trabalhado (web applications que não usam EJBs, JMS e as parafernalhas mais complexas do Java EE).

As principais vantagens do JBoss Web sobre o Tomcat são:

  • Ótimo para conteúdo estático. Como ele usa a mesma engine do Apache, benchmarks mostram que ele consegue praticamente os mesmos resultados de performance.
  • Melhor integração com o sistema operacional, usando JBoss Native.
  • Networking é melhor devido a extensões na JRE.
  • Usa features modernas de sistema operacional para zero-copy.
  • Melhor solução de clustering.
  • Usa menos CPU e memória.
  • Tem uma implementação de mod_rewrite em Java.

O objetivo do JBoss Web não é substituir o Apache, nem o Tomcat, nem o JBoss. Se você tiver aplicações tradicionais onde um Apache é suficiente (conteúdo estático + PHP, por exemplo), use-o. Se você for usar JSP/Servlets para um site pequeno-médio, talvez a melhor opção seja mesmo o Tomcat. Se você precisar processar EJBs, certamente vai precisar de um full JEE application server. Além disso, o JBoss Web não têm a variedade de módulos que o Apache tem, e também não tem um foco grande em segurança. Mesmo assim, é mais uma excelente carta na manga.

[JBoss World 2008] Isaac Christoffersen e Dan Santillo: Virtualization technologies

Thursday, February 14th, 2008

Há algum tempo eu queria escrever sobre virtualização. Essa palestra do Isaac Christoffersen e do Dan Santillo, da Booz Allen Hamilton, foi o impulso que faltava.

Como esse é um assunto que muita gente não conhece, vou colar aqui a definição da wikipedia sobre virtualização:

“[Virtualization is] a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources. This includes making a single physical resource (such as a server, an operating system, an application, or storage device) appear to function as multiple logical resources; or it can include making multiple physical resources (such as storage devices or servers) appear as a single logical resource.”

Agora, falando em português curto e grosso e transportando para o nosso contexto (aplicações web): virtualização seria basicamente fazer com que as aplicações que rodam em clusters de várias máquinas passem a rodar em clusters de menos máquinas, onde em cada uma delas teria várias instâncias de sistemas operacionais. Ou seja, rodar vários sistemas operacionais em uma mesma máquina em paralelo. Com isso você mantêm o número de instâncias da aplicação, porém usando menos máquinas. Para isso pode-se usar VMWare ou Xen, por exemplo.

Muitas empresas hoje gastam milhões de dólares com hardware, como uma solução de contorno para software de qualidade ruim. E quando se gasta milhões comprando, naturalmente se gasta vários outros milhões mantendo essa infraestrutura, e não dá para crescer. Muitas vezes o hardware é super-dimensionado, e fica “90% idle” na maior parte do tempo.

As aplicações cliente-servidor de antigamente muitas vezes precisavam apenas de 1 servidor de banco de dados para funcionar (só para centralizar os dados, na verdade). Nos dias de hoje, com N-camadas e arquiteturas baseadas em SOA, as aplicações podem ser resultado da composição de dezenas de serviços, e cada um desses serviços pode estar instalado em dezenas de máquinas. Resumindo: hoje em dia temos aplicações que rodam em centenas, talvez milhares de máquinas.

E onde que a virtualização se encaixa nisso tudo? Vamos lá, vamos imaginar um cenário. Imagine uma aplicação que roda em um cluster de 20 máquinas, e que nos horários de pico a utilização de CPU chega a no máximo 5% ou 10%. Ou seja, você tem 90% de máquina sobrando o tempo inteiro! Com virtualização, uma estratégia poderia ser fazer com que esse mesmo cluster funcionasse em 5 máquinas, e cada máquina teria 4 instâncias de sistema operacional. Ou seja, cada sistema operacional ficaria com 25% da máquina original, que como vimos, é mais do que o dobro e o suficiente para ela funcionar. Resumindo: mesmo resultado e 1/4 dos recursos necessários.

Temos várias vantagens com essa abordagem:

  • Corte de custos.
  • Maior aproveitamento dos recursos existentes.
  • Liberação de recursos para outras aplicações que podem estar precisando mais.
  • Melhorar os planos de recuperação de desastre e backup, mantendo instâncias de aplicação prontas para funcionar em qualquer lugar.
  • Maior maleabilidade de recursos: se houver um pico em uma ou outra aplicação, os recursos podem ser gerenciados (até via script) para atender a demanda momentânea.
  • Redução do espaço físico necessário para os datacenters, bem como redução de consumo de energia e redução de custos para resfriamento.
  • Etc.

Sou apenas um curioso e não um especialista nesse assunto, mas com certeza essa é uma área que vai crescer muito nos próximos anos.

No nosso laboratório na Globo.com, já fazemos experiências com virtualização há algum tempo e temos inclusive deploys virtualizados de algumas aplicações para teste. Agora precisamos colocar para funcionar!

[JBoss World 2008] James Ward: Porting from web 1.0 to RIA

Thursday, February 14th, 2008

James Ward, evangelista da Adobe, fez uma apresentação muito legal sobre como criar Rich Internet Applitacions com Flex, usando back-ends robustos em Java com JBoss.

Essa apresentação teve muito a ver com o artigo que ele publicou no InfoQ sobre como portar aplicações HTML tradicionais para Flex, escrito em conjunto com Shashank Tiwari (mais detalhes no blog do James).

No início ele mostrou um demo sensacional de uma aplicação de seguros que eles migraram de “web 1.0″ para Flex. Realmente o poder das interfaces ricas é impressionante. Outro demo interessante foi do eBay Desktop, que tem uma boa combinação de HTML e Flash (usando o Adobe AIR), resultando em uma interface muito bonita e funcional.

Ultimamente na Globo.com temos trabalhado muito com Flash, por causa do player do Globo Vídeos. Antes disso eu nunca tinha trabalhado com Flash e talvez por isso nunca tenha tido a oportunidade de sentir tão de perto seu potencial. Flash/Flex/AS3/AIR/etc abrem um novo mundo de possibilidades, dando o poder de criar interfaces com usabilidade e interatividade excelentes, e ainda com um forte apelo visual.

Ele apresentou o conceito de “SOARIA” (aliás, quando ele falou isso eu comecei a rir sozinho, parecia que ele estava falando “sorria”). O que ele chama de SOARIA significa SOA + RIA, ou seja, aplicações ricas (RIA) que interagem com o back-end através de serviços (SOA). IMHO, acho essa abordagem muito legal, porque evita aquela dependência cíclica que sempre acaba se formando entre o Flash e a aplicação.

No final, vimos um benchmark interessante, comparando vários modelos de carregamento de dados em aplicações RIA usando Flex, Laszlo e Javascript/Ajax, integradas com serviços SOAP, pure-XML, HTML e JSON. O benchmark analisa como cada um desses modelos impacta em performance, consumo de banda e consumo de memória na máquina cliente. Fiquei surpreso com os resultados… Por exemplo, a aplicação mostra que o Dojo tem uma performance surpreendentemente ruim quando comparado a aplicações Flex, que têm uma performance normalmente superior a todas as outras (atenção, se você for rodar os testes não se esqueça de desabilitar o Firebug antes!).

A Adobe realmente acertou com o Action Script 3, Flex, AIR e todos esses novos produtos que têm sido lançados. Tenho que tirar o chapéu.

[JBoss World 2008] O Hibernate Validator me incomoda…

Thursday, February 14th, 2008

JBoss World 2008 - BOFAcabei de participar de um BOF com Emmanuel Bernard, Gavin King, Pete Muir, Max Andersen e mais uma dezena de pessoas.

O assunto era desenvolvimento de aplicações usando Hibernate, Seam e outras coisas mais da Red Hat. Dentre as várias coisas que foram discutidas, falamos sobre o Hibernate Validator.

O Hibernate Validator me incomoda, e é um pouco complicado de explicar o motivo, mas eu vou tentar. Na verdade não é o Validator em sí, mas as suas annotations. Vejamos um exemplo de código traduzido da página Validator. A sintaxe é muito simples e mesmo que você não saiba exatamente como funciona provavelmente conseguirá entender:

public class Endereco {
 
    @NotNull private String rua;
    private String cep;
    private String estado;
 
    @Length(max = 20)
    @NotNull
    private String pais;
 
    @Range(min = -2, max = 50, message = "Andar invalido")
    public int andar;
 
        ...
}

Na minha concepção, quando usamos o Hibernate Validator dessa forma, passamos a ter regras de negócio/validação do objeto fora do seu controle, e essas regras não estão fortemente encapsuladas. A verificação de que um endereço deve ter no máximo 20 caracteres, por exemplo, deveria estar encapsulada dentro de um método que cria/atualiza o endereço, e não numa annotation.

Existe uma discussão muito grande sobre isso. De um lado, os “puristas” acreditam que colocar annotations num objeto de domínio significa acoplar esses objetos à infraestrutura e implementações específicas. Do outro lado, os “práticos” acham que isso não tem o menor problema, que na prática o efeito colateral disso é nulo.

Eu sinceramente fico meio dividido. O que eu sei é que isso de alguma forma me incomoda. Estou acostumado a pensar de um modo “Domain-Driven Design”, e para mim o mais natural e certo seria que essa regra estivesse dentro de algum método.

Se você pensar que sua aplicação pode usar todas essas coisas juntas com esses quilos de annotations (Seam, Hibernate, Validator, Guice, etc, etc), no final você vai ter objetos de domínio altamente acoplados à toda a infraestrutura da aplicação. Pior ainda quando essas annotations tem regras de negócio. Os objetos vão acabar se tornando meros “fantoches” controlados por annotations… Isso definitivamente não parece ser bom.

[JBoss World 2008] Emmanuel Bernard: Hibernate

Thursday, February 14th, 2008

JBoss World 2008 - Emmanuel Bernard - HibernateA apresentação do Emmanuel Bernard sobre Hibernate foi muito boa. Inicialmente o Gavin King também iria participar, mas ele acabou não chegando a tempo. Fiquei com medo achando que eles fossem falar sobre coisas muito básicas que todo mundo já conhece, mas ao invés disso o Emmanuel se preocupou justamente em falar sobre coisas que as pessoas não estão muito acostumadas a ver por aí, como estratégias de replicação e ResultTransformers, por exemplo.

Roadmap do Hibernate 3.x

O Emmanuel deu uma visão muito ampla do que eles planejam para o futuro. O roadmap do Hibernate para as próximas versões (3.x), que serão lançadas durante os próximos meses, incluem dentre outras coisas o seguinte:

Second-level Cache

  • Re-design das estratégias de replicação em cluster usando JBoss Cache (aliás, muito necessário, porque isso definitivamente não funciona bem, já tive experiências não muito boas de aplicações que simplemente se afogam com isso).
  • Re-design da clusterização de um modo geral.

JDBC Work API

Quando o Hibernate se torna um impecilho para o desenvolvimento porque não te dá a flexibilidade que você precisa, use um “proxy” para JDBC provido pelo Hibernate.

Stateless API

Usada para operações em batch, esta API permitirá a inserção de milhões de objetos sem erros de “out of memory”, facilitará o desenvolvimento de tarefas para rodar em intervalos de tempo determinados (tipo cron jobs) e coisas do tipo.

Hibernate 4.0

Já o Hibernate 4.0, que não tem data marcada para sair e parece que não vai ser tão cedo, tem uma lista de features muito mais extensa e “agressiva”. Basicamente essa nova versão do Hibernate será focada nos seguintes objetivos:

Facilidade de desenvolvimento

Configuração mais simples

  • Cada vez menos baseada em texto/String e xml e mais baseada em convenções e annotations.
  • Mutável em runtime, ou seja, alterar determinadas configurações não irá requerer que o contexto seja reiniciado.

Mais flexibilidade de mapeamento

  • Mais opções para mapeamento de componentes polimórficos.
  • Mais opções para mapeamento de coleções.

Otimizações

  • Melhorias no startup, que hoje é muito lento, especialmente quando se tem centenas ou milhares de entities.
  • Novas estratégias de fetching e melhorias no fetch automático.

Queries

Funcionalidades de alto nível

Versionamento automático e transparente de dados “out of the box”.

Entity Manager

Uma das idéias é que não seja mais necessário registrar as entities em um arquivo de configuração, só a annotation @Entity será necessária.

Hibernate Tools

  • Criação de Ant tasks para que toda a DDL (tabelas, constraints, sequences, etc) necessária para a aplicação funcionar seja gerada automaticamente.
  • Leitura das informações para geração de DDL diretamente das entities, suportando tanto os mapeamentos feitos com Hibernate como com JPA.
  • Integração com JBoss Developer Studio.

Ampliação da plataforma

Outros projetos mais novos como Hibernate Search, Hibernate Validator e Hibernate Shards ganharão mais foco.

E a JPA?

Tudo isso automaticamente nos remete ao assunto Java Persistence API. A JPA foi lançada com um conjunto de featues muito pequeno que simplesmente não atende qualquer caso que não seja feijão-com-arroz. O que normalmente acaba acontecendo é que você sempre tem que recorrer a features específicas do Hibernate para resolver casos mais complexos. Isso simplesmente elimina o papel da JPA, que seria manter a aplicação desacoplada de um “vendor” específico. Então, o Emmanuel também falou um pouco do que podemos esperar para a JPA para resolver esses problemas:

  • Objetivo principal: padronização de um mecanismo de mapeamento objeto-relacional “lightweight”.
  • Focada em Domain Model.
  • Uso massivo de annotations: o objetivo é fazer tudo funcionar por annotations sem a necessidade de nenhum arquivo de configuração.
  • Incorporação das annotations avançadas específicas do Hibernate.
  • Fará parte do Java EE 6 padrão.
  • Terá uma Criteria API.

A falácia da otimização prematura

Tuesday, January 8th, 2008

“A otimização prematura é a raiz de todo o mal”. Quantas vezes você já ouviu essa frase? Eu mesmo já disse isso aqui nesse mesmo blog e já falei essa frase para várias outras pessoas. O problema, como já apontavam os sábios budistas, é que as pessoas acabam levando as coisas ao extremo… Para alguns desenvolvedores, como a otimização é a raiz de todo o mal ela deve ser evitada a qualquer custo e ao longo dos anos o sentido da frase acabou virando simplesmente “nunca otimize seu código”.

O criador dessa frase famosa foi Tony Hoare e Donald Knuth foi o responsável por torná-la popular. O que as pessoas não param para pensar é que quando essa frase foi dita, em 1975, o contexto era completamente diferente. O que Hoare e Knuth estavam realmente falando é que os engenheiros de software da época deveriam se preocupar com outras coisas mais importantes (como um bom design de algorítmos e boas implementações desses algorítmos) antes de se preocupar com micro-otimizações como a quantidade de ciclos de CPU que um determinado comando consome. A história toda é bem interessante e recomendo a leitura completa.

Hoje em dia os tipos de software que desenvolvemos são completamente diferentes. A capacidade computacional das máquinas é diferente, as arquiteturas dos sistemas, a quantidade de usuários… Temos bancos inteiros totalmente computadorizados com milhões de transações simultâneas acontecendo e essas trasações não podem falhar ou alguém perde dinheiro em algum lugar. Temos sistemas na internet que suportam milhões de usuários trocando mensagens o tempo todo. Enfim, precisamos considerar aspectos bem diferentes.

Eoin Woods, membro da IASA, publicou um artigo sobre o que ele acredita que sejam os 10 maiores erros de arquitetura cometidos em projetos. O item número 7 é “Assumir requisitos de performance e escalabilidade”. Ele acredita que você deve começar a considerar aspectos de performance e escalabilidade desde cedo porque isso ajudará a aumentar a sua confiança de que não há nenhum bicho de sete cabeças que na última hora vai arruinar qualquer possibilidade da sua aplicação ir para produção. Os requisitos de performance de uma aplicação devem ser conhecidos, estudados e levados em consideração desde o início do desenvolvimento.

Robert Annet do Coding The Architecture cita um outro exemplo do que pode acontecer quando você assume certas informações erradas no desenvolvimento. Ele também conclui que todos os desenvolvedores devem sempre estar cientes da arquitetura de um sistema e como isso afeta o que está sendo desenvolvido. Faz muita diferença, por exempo, se uma aplicação rodará em cluster ou não.

Resumindo, eu discordo de quem diga que um software não deve ser otimizado antes mesmo de ser desenvolvido. Há casos e casos. Veja a minha situação: quando eu desenvolvo sistemas na Globo.com, como é que eu posso ignorar o fato de que o sistema será acessado por milhões de usuários? No nosso último projeto, por exemplo, uma das premissas era que o player de vídeos fosse ultra-compacto (menor quantidade de bytes possível) já que ele seria baixado por qualquer usuário que fosse ver o vídeo e não poderia afetar o carregamento da página. Se não fosse isso poderíamos acabar tendo um daqueles arquivos Flash de 2 MB que quando você acessa a página tem que esperar 2 minutos para carregar – a experiência do usuário fica um lixo.

Porém também acho que temos que tomar cuidado para não exagerar na dose. Otimizações são boas quando elas são realmente necessárias.

Já cansei de ver desenvolvedores sacrificarem o design de uma aplicação por causa de performance ou otimizações que eram completamente desnecessárias. Quando você tem requisitos de performance claros como os que eu citei acima é óbvio que você tem que levá-los em consideração. Mas a grande maioria das aplicações certamente não atende milhões de usuários nem se você somar 10 anos de acesso! Então o que acaba acontecendo é que ao invés de se preocupar com desenvolver software de qualidade, bem testado, modular e com design decente muita gente acaba desenvolvendo software desnecessariamente otimizado e difícil de entender e modificar. A não ser que você tenha requisitos não-funcionais bem claros e definidos a prioridade sempre deve ser por um bom design, código legível, extensível e esse tipo de coisa.

Otimizar cedo ou não, sempre vai ser um assunto controverso. Normalmente esse tipo de coisa envolve julgar uma série de fatores técnicos e de negócio. Concluindo, é essencial que a equipe de desenvolvimento tenha bom senso ao tomar essas decisões. Nunca otimizar ou sempre otimizar são abordagens completamente equivocadas. Como dizem os budistas, “prefira sempre o caminho do meio”.

Cronogramas não funcionam

Tuesday, December 4th, 2007

Gantt ChartUma vez participei de um projeto que tinha um cronograma gigantesco tentando prever alguns meses de trabalho. Como de costume esses mega-projetos estão descritos em um também gigantesco Gantt Chart (se você não sabe do que eu estou falando veja a imagem ao lado).

O software que estávamos desenvolvendo era super específico e estavamos lidando com uma série de variáveis desconhecidas. Por exemplo, uma das partes do projeto era fazer integração com um sistema em C utilizando um protocolo não muito bem documentado baseado em HTTP. Para esta tarefa o gerente de projeto estimou “5 dias”. Quando eu perguntei como ele fez para estimar 5 dias sem nem mesmo saber exatamente como funciona o protocolo HTTP, a resposta foi a tradicional: “ah, eu chutei o valor pra cima porque não tinha muita certeza”. Como assim chutou pra cima? De onde ele tirou que isso é “para cima”? (só de curiosidade, no fim das contas a integração levou 3 semanas…)

Assumir que coisas deste tipo levarão tempos pré-determinados não funciona. O que esse gerente fez é tão tosco quanto um exemplo que tem no livro do Ken Schwaber: “para cada 4 classes, 3.5 designers completarão uma tarefa em 16 horas”. Acredite, esse é o tipo de “técnica” que os gerentes de projeto CMM Level 5 Certified utilizam para definir esses cronogramas malucos.

Além disso para poder fazer esse tipo de cálculo considera-se que as pessoas conseguem fazer uma determinada quantidade de trabalho por dia. Aí eu pergunto: isso leva em conta um dia de trabalho de um profissional bem treinado, bem qualificado, bem supervisionado, totalmente consciente, sem problemas pessoais, começando de manhã após um copo de café expresso? Ou seria um dia de trabalho de uma pessoa qualquer?

É por isso tudo que esses projetos sempre atrasam!

O que é preciso enxergar é que o processo de desenvolvimento de software não é uma linha de produção, não é executado por robôs e por isso não se pode determinar exatamente o que acontecerá durante um longo período de tempo. Além disso o processo envolve muita criação e não se pode garantir que os produtos finais sempre serão os mesmos ainda que aplicado o mesmo método de trabalho. Veja, produzir um carro, por exemplo, envolve uma série de atividades encadeadas e repetidas. Se você produzir 8.000 carros todos passarão pelo mesmo processo de fabricação e no fim do processo você terá 8.000 carros idênticos fabricados na mesma quantidade de tempo. Mas se você entregar o mesmo projeto de software para 8.000 programadores diferentes é totalmente possível que no final você tenha o mesmo problema resolvido de 8.000 formas diferentes e em prazos totalmente diferentes dependendo do nível de conhecimento, linguagem/tecnologias adotadas e etc.

No projeto que estou trabalhando atualmente fazemos diferente. Não definimos um prazo de entrega para o projeto inteiro mas sim a data de entrega dos Sprints (as iterações do Scrum). Fazendo análise e desenvolvimento de forma incremental os riscos são bem menores e é muito difícil alguém não levantar uma bandeira amarela antecipadamente caso uma estimativa esteja totalmente fora da realidade como a que eu citei. Mesmo não tendo muita flexibilidade nas datas de entrega acho que as pessoas se sentem mais confortáveis assim porque sempre estamos entregando alguma coisa e não atrasamos. O máximo que já aconteceu foi cortar a última história do Sprint (que voltou para o backlog e acabou nem entrando no Sprint seguinte), mas mesmo assim eu sinto que as pessoas ficam mais satisfeitas.

Sempre que esse papo vem á tona alguém pergunta: e como eu controlo o projeto? Quer ver um exemplo: sabendo que a nossa equipe faz Sprints de 15 dias nossos clientes decidiram que nós deviamos desenvolver determinadas funcionalidades chave para que agora no fim do segundo Sprint possamos fazer um release em produção de um software novo. Além disso eles participam ativamente das reuniões de planejamento dos Sprints e decidem quais tarefas serão feitas por nós. Quer mais controle que isso?!?

Por isso tudo que eu acredito que os cronogramas não são eficientes. Em alguns casos já é difícil planejar um Sprint de 15 dias, imagina projetos de meses ou anos? Fico me perguntando se esse projeto desse Gantt Chart (aquela imagem do início – achei no Google Images) foi entregue na data certinha que está especificada alí… Eu duvido!

[QCon 2007] Slides das apresentações

Wednesday, November 14th, 2007

Os slides de grande parte das apresentações da QCon 2007 foram liberados no endereço http://qcon.infoq.com/sanfrancisco/schedule/. Segundo a organização do evento em breve todos os slides estarão disponíveis lá!

Veja também o wiki e as fotos do evento, que continuarão sendo atualizados ao longo desta semana.