O movimento antropofágico, cunhado por Oswald de Andrade nos anos 20, propunha a “Devoração cultural das técnicas importadas para reelaborá-las com autonomia, convertendo-as em produto de exportação”.

Processos de software, como o AUP, RUP ou o XP são elementos muito complexos, compostos por diversas técnicas, métodos, papéis e pontos de extensão. Não é de se estranhar que a tarefa de implantar processos de software em organizações seja muito complexa e falhe em grandes partes das tentativas. É consenso que um processo deve ser personalizado à sua realidade para que ele funcione. Ao tentarmos personalizar um processo completo, temos muito trabalho e muitos pontos de divergência cultural com a realidade da organização alvo.

Antropofagia de Software

Como engenheiros de software, também devemos praticar a antropofagia dos processos de software e esquartejá-los em “práticas de processo”. Uma prática de processo é uma melhor prática, provada em diversos cenários e projetos. Uma prática de processo tem algumas características importantes, tais como: ser atômica, facilmente implantável e composível com outras práticas.

Exemplos de práticas de processo incluem:

• Projetos iterativos
• Modelagem de casos de uso
• Modelagem arquitetural
• Casos de teste
• Revisão pelos pares
• Planning Poker/Wide Band Delphi)
• Daily Builds (Produtos diários)

As vantagens de adotarmos e implantarmos práticas de processo, ao invés de um processo completo, são várias. Podemos destacar:

• Redução do risco de transformações culturais em times.
• Retorno mais rápido do investimento.
• Adequação a realidade cultural de cada empresa
• Possibilidades de composição com outras práticas para a montagem do um processo personalizado

As escolas mais modernas de processos tem adotado o conceito de práticas de processo em sua essência. Exemplos são o RUP 7.5 e o Essential UP, de Ivar Jacobson. O SCRUM, que tanto sucesso faz atualmente, tem a sua maior força na sua pequena essência, composta de um pequeno conjunto de práticas gerenciais ágeis.

Pensamento do dia: “Menos é mais”, Ludwig Mies van der Rohe

O SOFTEX divulgou os resultados de desempenho de 2009 das empresas que adotaram o MPS BR.

A síntese do relatório é fornecida abaixo:

“De forma geral, a satisfação das empresas com o modelo MPS é notória, com mais de 98% das empresas se dizendo parcialmente ou totalmente satisfeitas. Além disso, as empresas relataram que o retorno do investimento foi obtido e, principalmente, para aquelas empresas que evoluíram ou internalizaram o modelo MPS em seus processos foi possível observar tendência a melhoria de custo, qualidade, prazo e produtividade, princípios básicos quando se desenvolve software seguindo os preceitos de engenharia.”

Os resultados detalhados do estudo são muito interessantes e destaco neste espaço dois índices: o aumento do faturamento das empresas e o retorno sobre o investimento obtido no esforço da implementação. Com cada vez mais evidências estatísticas, podemos começar a observar dados quantitativos que correlacionam investimento em engenharia de software com melhorias concretas e permanentes nas empresas.

O relatório completo, para os interessados, está disponível aqui.

Aplicações Java EE impõe fortes desafios aos times de testes, qualidade e arquitetura de aplicações. Além dos inúmeros aspectos funcionais a serem observados, devemos observar também elementos técnicos de qualidade interna e qualidade externa tais como desempenho, usabilidade, segurança ou manutenibilidade.

Sabemos que ferramentas isoladamente não resolvem problemas complexos, mas uma vez que você tenha um método simples e eficaz para endereçar um problema, podemos aumentar a eficiência do método com ferramentas eficientes. Neste contexto, destacamos aqui algumas ferramentas que podem apoiar o seu trabalho em testes técnicos na plataforma Java EE.

• Testes de acessibilidade - O portal DaSilva (http://www.dasilva.org.br) realiza testes de acessibilidade a partir dos padrões WCAG e eGOV. Além disso, o portal também disponibiliza uma ferramenta para download para testes em Intranets.
• Testes de desempenho - O Apache JMeter é uma ferramenta para testes de carga, estresse e maturidade de páginas Web, filas JMS, pool de conexões JDBC e outros objetos Java EE. Robusta e madura, possui diversos tipos de gráficos e análises estatísticas de confiança. Recomendo também uma extensão simples do JUNIT chamada JUNITPerf, para testes de caixa branca de desempenho ou vazão (thoughput).
• Testes de instrumentação de códigos e servidores - O Eclipse TPTP realiza testes de instrumentação de código (profiling), que permite análise em nível de caixa branca (métodos Java) o uso de CPU, consumo de memória, vazamentos de memória e mesmo contenções de threads. Muito robusto ele gera inclusive diagramas UML2 de sequência dinamicamente a partir da interação com o servidor de aplicação alvo.
• Testes de cobertura - Recomendo novamente o Eclipse TPTP, que permite analisar que linhas, métodos e classes foram cobertas durante um determinado tipo de teste. A ferramenta indica linhas virgens e também permite montar histogramas das seções e métodos mais usados durante teste de aceite do usuário.
• Testes de automação Web - A plataforma Selenium realiza a automação de testes na Web através do conceito de gravação automatizada, extensão dos códigos gerados e reprodução. Os scripts gravados podem ser incluídos em suítes do JUNIT e ser também colocados em processos de integração contínua. O TPTP também possui uma ferramenta neste sentido, embora um pouco mais complexa para operação que o Selenium.
• Testes de interoperabilidade - Ferramentas como o jMOCK ou o EasyMock permitem que simulemos recursos como programas de terceiros para que possamos fazer testes fim a fim mesmo antes que estes programas estejam prontos. Estas ferramentas são baseadas no conceito de “dublês” e simulam literalmente o comportamento de um recurso a ser integrado. Este tipo de tecnologia também é util em grandes projetos quando times estejam construindo módulos que requeiram grande integração. e que ainda não estejam prontos.
• Testes de manutenibilidade - O Metrics é um plugin simples para Eclipse que faz análises diversas de código e extrai métricas universais de qualidade como por exemplo a complexidade ciclomática. Em resumo, ela responde a pergunta se o seu código é manutenível ou não. Uma outra ferramenta de livre acesso neste sentido é o SourceMonitor, que também traz gráficos diversos de análise como gráficos de histogramas e diagramas de Kiviat (gráficos polares) para análises executivas de qualidade.

Caso você conheça alguma outra ferramenta de teste técnico para Java EE, deixe aqui a sua opinião ou comentário.

Pensamento do dia: Amplius juvat virtus, quam multitudo (Mais vale a qualidade que a quantidade)

Tradicionalmente o desenho e implementação de aplicações modernas em linguagens como Java EE e .NET é tratado como um elemento puramente técnico. Um pequeno volume de horas é concedido ao time de desenvolvimento para resolver um problema complexo através de um conjunto de modelos técnicos, linguagens como UML e provas de conceito exploratórias. O foco na ótica gerencial é apenas em custos, o que explica porque pouco times no Brasil exploram o desenho como um software realmente merece. O resultado é publicamente conhecido, como nos relatórios das crônicas do caos na TI, que mostram o pífio desempenho dos projetos de TI por todo o mundo.

E se ao invés de pensarmos no desenho como um custo, pensássemos no mesmo como um investimento financeiro baseado nos conceitos de valor agregado e da prática da indústria chamada de software engineering economics.

O desenho baseado em valor agregado pode ser visto como uma atividade econômica, visto fazer um software não é uma atividade puramente técnica. Arquiteturas conceituais como o SOA mostram a importância de se pensar em software como um elemento de negócio.

Compilo aqui um conjunto de elementos necessários à implementação do desenho baseado em valor econômico em times de software.

1. Times devem ser auto-gerenciáveis. Times auto-gerenciáveis definem coletivamente os passos necessários para produzir os entregáveis técnicos de um projeto, ao invés de receber ordens de gerentes de mais alto nível que não entendem do método construtivo de software. Naturalmente, time auto-gerenciáveis são completamente responsáveis pelas consequências dos seus atos. O SCRUM é um excelente exemplo do uso desta técnica.
2. Todo elemento técnico deve ser pensado no valor agregado que ele produz para o projeto. O raciocínio da análise de valor agregado, difundida nos círculos gerenciais, deve se tornar uma obsessão diária. Por exemplo, a escolha sobre o uso de um estilo de RPC baseado em WS-* versus um estilo REST-* deve ser analisado de forma quantitativa e econômica. O valor agregado deve ser medido através do alinhamento dos benefícios técnicos aos condutores do projeto, ao custo de oportunidade do produto para uma organização e outros elementos organizacionais.
3. Orçamentos de projetos devem ser comunicados aos times técnicos. Times devem ser responsáveis pelo uso adequado do investimento do dinheiro de um projeto. Para criar esta responsabilidade, os orçamentos devem ser divulgados. Já tive a oportunidade de presenciar projetos onde técnicos passaram semanas experimentado tecnologias a seu bel prazer, sem nenhum compromisso com o dinheiro que estava sendo investido pelos patrocinadores.
4. Orçamentos devem ser monitorados diariamente. Por exemplo, um dia de um projeto de um time de cinco pessoas com formação plena no mercado Brasileiro é um investimento da ordem de 2 a 4 mil reais. Qual a contra-partida fornecida tecnicamente para justificar este investimento? Ao divulgar e monitorar o raciocínio de investimentos para desenvolvedores, eles se tornam mais comprometidos, conscientes e criativos no uso do dinheiro.
5. Praticar a mentalidade da abundância, do líder Stephen Covey. Ao comunicarmos investimentos para os times, temos que promover mecanismos de recompensas. Por exemplo, se tivermos um orçamento de 100.000 reais para um projeto e se o time atingir os critérios de qualidade para a entrega no projeto, a sobra de orçamento deve ser dividida pelo time, conforme a participação entre os seus membros.
6. Educar desenvolvedores em práticas de administração. Talvez a mais difícil missão, desenvolvedores devem não apenas conhecer Java, .NET, OO e padrões de desenho, mas também sobre o contexto e a importância do software para as organizações e empresas.

Pensamento dia dia:

“Não somos responsáveis apenas pelo que fazemos, mas também pelo que deixamos de fazer.”, Molière

A maioria de nós já ouviu falar da eficência da Toyota, que já assumiu o posto de primeira montadora de carros do mundo. Entretanto, é ainda mais interessante estudar os princípios que norteiam esta eficiência, chamados de manufatura enxuta. São sete os seus princípios, que focam na redução do desperdício:

• Superprodução: a maior fonte de desperdício.
• Tempo de espera: refere-se a materiais que aguardam em filas para serem processados.
• Transporte: nunca geram valor agregado no produto.
• Processamento: algumas operações de um processo poderiam nem existir.
• Estoque: sua redução ocorrerá através de sua causa raiz.
• Movimentação
• Defeitos, produzir produtos defeituosos significa desperdiçar materiais, mão-de-obra, movimentação de materiais defeituosos e outros.

Em 2004, dois computatas (Mary e Tom Poppendieck) adaptaram este processo para o contexto da engenharia de software, criando um conjunto de 22 “ferramentas” que promovem o aumento da eficiência de projetos em TI. Estes princípios foram batizados como “Desenvolvimento Enxuto de Software”.

Eliminação de Desperdícios

Comento aqui sobre o princípio da eliminação de desperdício através da remoção de atividades e produtos que não geram valor para o cliente. Alguns exemplos incluem:

• Requisitos folheados a ouro. A XP Conference de 2002 mostrou que quase metade das funcionalidades de um sistema não é usada. Funcionalidades não usadas implicam em desperdício. Uma forma de combater este mal é fazer perguntas e estudar a causa raiz das necessidades dos usuários.
• Requisitos ambíguos e voláteis. Requisitos voláteis provocam retrabalho. Retrabalho é desperdício. Devemos simplificar requisitos e criar sessões intensivas de coletas e acomodação de requisitos junto a todos os usuários chave.
• Burocracia. Reuniões gerenciais sem foco, sistemas de apontamento de horas que controlam até a ida de um funcionário ao banheiro e excesso de controle gerenciais são exemplos de burocracia.
• Comunicação interna ineficiente. Afastar os usuários dos analistas desenvolvedores, trocar a comunicação face a face por documentações frias e trancar desenvolvedores em baias (cubículos com paredes) são excelentes exemplos de como reduzir a comunicação em times e aumentar a ineficiência.
• Defeitos. Defeito é retrabalho. Devemos evitar defeitos realizado um processo contínuo de testes de unidade e refatorações desde o primeiro dia do projeto. Devemos procurar reduzir ao mínimo a densidade de defeitos no código de um sistema.
• Atrasos no processo de desenvolvimento de software. Testes que somente começam no meio do projeto, processos “mastodontes” e foco em documentos que não geram valor reduzem o valor de processos e aumentam o desperdício.

Alguns recursos complementares sobre o desenvolvimento enxuto de software são listados abaixo:

• Instituto para o desenvolvimento enxuto de software.
• Entrevista com Mary Poppendieck
• O livro que originou o tema na Engenharia de Software - Lean Software Development - An Agile Toolkit.

Estive em uma interessante e instigante apresentação de um arquiteto chamado Jan Bosch no último evento do SBQS. Comento aqui alguns dados interessantes sobre a organização de times da Amazon e do Google.

• 3 homens mês x 3 meses. Todo e qualquer projeto tem no máximo 3 pessoas em um tempo não maior que 3 meses.
• A regra das 2 pizzas. O tamanho máximo de um time deve ser limitado pela quantidade de comida presente em 2 pizzas grandes. Fiz rápidas contas e acredito que um o tamanho máximo não deve exceder 6 ou 7 pessoas para que ninguém fique com fome.

Aparentemente, a premissa é colocar como regra corporativa que o ciclo de vida de um produto deva ser guiado por projetos curtos com poucas pessoas e portanto com pouco overhead gerencial. Em times deste porte, podemos ter gerentes técnicos ou mesmo arquitetos que possam conduzir as atividades necessárias a geração de um produto.

Este conceito também traz implicações interessantes. Produtos devem ser gerados incrementalmente respeitando as enormes pressões de tempo de mercado e ao mesmo incentivando a criatividade dos técnicos envolvidos. A técnica clara para que isto opere é uma forte priorização de requisitos e um adiamento dos requisitos menos importantes para futuros ciclos e novas versões dos produtos.

Podemos ver também uma forte influência de culturas ágeis, com a geração de valor (produto operável na mesa dos usuários) como a regra número 01.

Em resumo, o que vemos nestas empresas talvez seja também uma forma humilde de reconhecer que a TI não deve operar como um fim em si mesma mas como uma forma de gerar maior valor de negócios. Projetos pequenos e rápidas liberações parece ser uma estratégia interessante, o que pode explicar uma parte do sucesso da Amazon e da Google.

Pensamento do dia: “Divide et impera”, ditado latino.

Todos sabem que o Spagetti é uma massa de origem italiana muito popular no Brasil. Nem todos sabem, entretanto, o que é um código spagetti. Um código desta natureza é normalmente formado por um longo conjunto de instruções, com um vários níveis de aninhamento e grande complexidade técnica. A sua manutenção é trabalhosa e muitas vezes injeta erros colaterais na aplicação sendo mantida. Diferentemente do seu primo culinário, portanto, o código spagetti não é bem visto no mundo de TI.

Cortando spaggettis com o uso da métrica de complexidade ciclomática
Cortar um spagetti com faca é um crime culinário para os italianos. Na TI, infelizmente, não nos resta outra opção. Devemos cortar o mal pela raiz, literalmente.

Para isso, podemos usar como métrica um algoritmo que mede o quão simples ou complexos são os métodos e funções que compõem uma aplicação. Chamado de complexidade ciclomática e formalizado por Thomas McCabe, este algoritmo basicamente mede o número de caminhos lineares independentes encontrados em um método ou função. Quanto maior o número de caminhos, mais complexo é o seu código. Valores maiores que 10 geram um alerta amarelo, pois isto indica que o código está muito complexo para um ser humano manter. Surpreendentemente, vemos códigos em empresas com valores maiores que 100, 200 ou 500 (!!!), que são verdadeiros lamaçais de spagetti.

Felizmente não precisamos conhecer os detalhes do algoritmo (baseado em teoria de grafos) para usá-lo. Ferramentas simples e gratuitas analisam todo o código fonte das nossas aplicações e produzem uma análise de complexidade média e de ofensores individuais. Compilo abaixo algumas ferramentas para suporte este processo.

• Source Monitor - Ferramenta simples que calcula a complexidade ciclomática e outras métricas para Delphi, VB, VB.NET, HTML, C#, C++, Ansi C e Java.
• Metrics - Excelente plugin para eclipse, compila diversas métricas de qualidade de código, incluindo a complexidade ciclomática.

Com os resultados em mãos, podemos refatorar os códigos para torná-los mais simples.

Pensamento do dia: “A evolução do conhecimento humano é em direção à simplicidade, e não à complexidade”, L. Ron Hubbard

A comunicação talvez seja o princípio mais importante das escolas ágeis mas é infelizmente muito mal compreendido por técnicos de TI. Exploro aqui duas rápidas questões sobre princípios de comunicação efetiva.

O princípio da comunicação quente
A paleta de cores abaixo mostra algumas formas de comunicação em projetos. Quanto mais quente (à direita), mais rico e efetivo é o mecanismo de comunicação.

Surpreendemente, analistas gostam de email e documentação (mesmo com o colega a dez metros de distância), que são formas frias de comunicação. Ao invés, comunicações quentes (conversas) devem ser usadas para estabelecer sinergia e transmitir idéias entre times. Este princípio, explorado anteriormente por Alistair Cockburn e revisitado por Scott Ambler, é descrito em mais detalhes aqui.

O princípio SUCESSO
Idéias que colam e sào lembradas por pessoas são simples, inesperadas, concretas, transmitem crença imediata, remetem a emoções e são baseadas em histórias. Cito como um exemplo um assunto aparentemente árido - a instrumentação de alarmes em sistemas telefônicos, que foi transmitido com sucesso através da metáfora arquitetural Clínica médica por um grupo de técnicos do nosso convívio.

O caso completo é descrito em mais detalhes aqui.

O livro Idéias que Colam, escrito por Chip Heath e Dan Heath, endereça estes princípios e fornece dezenas de exemplos de como comunicar efetivamente idéias para outras pessoas.É um livro brilhante e leitura indispensável a bons comunicadores.

Pensamento do dia: “True interactivity is not about clicking on icons or downloading files, it’s about encouraging communication.”, Edwin Schlossberg.

Acaba de ser disponibilizado o portal da revista Communications of ACM. É mais uma excelente fonte de recursos técnicos para engenheiros de software, estudantes, professores, acadêmicos e profissionais de TI de forma geral.

A ACM, para quem ainda não conhece, é a mais respeitada associação de classe da área de computação. Com 51 anos de existência, a ACM congrega materiais de qualidade excepcional, além de hospedar os melhores e mais influentes congressos e conferências técnicas da área de computação. Podemos dizer, metaforicamente, que a CACM possui um prestígio acadêmico similar aos das revistas Science e Nature é para a área das ciências naturais.

A revista Communications of ACM é uma revista de propósito geral que traz mensalmente assuntos brilhantes, novidades e tendências da área de computação. Este portal, acredito, irá popularizar fortemente a ACM fora da comunidade acadêmica e permitirá um maior acesso às excelentes informações lá disponíveis.

Recomendo, em particular, dois excelentes artigos (o primeiro da edição do mês de Abril e o segundo da edição de Março):

• A Direct Path to Dependable Software. Como criar softwares com maior valor agregrado e menores custos.
• An Interview With C.A.R. Hoare. Uma entrevista com um dos “gênios” vivos da história da computação, que realizou feitos notáveis como o desenvolvimento do algoritmo de ordenação mais eficiente da história (Quicksort), definição dos fundamentos das lnguagens estruturadas e criação dos conceitos de monitores para programas concorrentes. Tudo isso antes da maioria dos que leêm este blog nascerem.

Processos ágeis ganham cada vez mais momento na indústria Brasileira. A palavra “ágil”, entretanto, ainda sucita muitas dúvidas e é muito mal interpretada. Leigos e não-técnicos muitas vezes confundem o termo ágil como indisciplinado ou “conserta e remenda”. A verdade não poderia estar mais longe, entretanto. Agilidade tem a ver com disciplina e trabalho coordenado e pode suportar, enquanto paradigma, projetos dos mais diferentes portes e até mesmo a gestão da TI de ume empresa.

Maturidade de Processos Ágeis

Para colocar alguma luz sobre estas questões, Scott Ambler publicou um excelente post sobre a maturidade de processos ágeis, que podemos resumir na figura abaixo.

O nível 1 contempla um processo de ciclo de vida de desenvolvimento para alguma disciplina, como por exemplo gerência, modelagem, testes ou implementação. Exemplos incluem o SCRUM (para gerência ágil de projetos) ou Agile Modeling (modelagem ágil de projetos).

O nível 2 contempla um processo de ciclo de vida para todas as disciplinas de um projeto. Um excelente exemplo é o Open-UP ou um uso personalizado do RUP, que pode ser usado de forma ágil.

O nível 3 lida modelos de escalabilidade extremos como por exemplo projetos geograficamente distribuídos ou times de maior porte. Um exemplo muito interessante é o uso do CMMI com métodos ágeis. Pode parecer incoerente ou irreal, mas não é. Um relatório técnico do SEI mostra esta feliz união. O C.E.S.A.R tem diversos casos reais a respeito e inclusive está promovendo um evento técnico sobre CMMI e SCRUM, agendado para o próximo mês de maio em Recife.

Empresas Ágeis

Um outro artigo relacionado leva o modelo ágil a um patamar ainda maior, que lida com o gerenciamento de empresas através de modelos ágeis. Este termo, chamado Agile Enterprise, tem recebido também cada vez mais atenção por gestores e diretores.

Finalmente, recomendo dois livros chave sobre este tema para os mais interessados no assunto:
- The Enterprise and SCRUM, Ken Schwaber
- Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell

Pensamento do dia: Citius Altius Fortius. Expressão latina para o lema olímpico: Mais rápido, mais alto, mais forte!

Bons projetos ágeis e escaláveis.