Você provavelmente conhece muitas analistas e desenvolvedores “ocupados”. Pessoas muito “ocupadas” almoçam em quinze minutos, não tem tempo de conversar cinco minutos no café, ler um bom blog na Internet ou fazer qualquer outra atividade de TI que não seja escrever, desenhar, codificar e testar casos de uso. O senso de urgência é tão grande que estas pessoas também não tempo de estudar ou pensar sobre estratégias para serem mais eficazes e eficientes no seu trabalho. Nos casos mais graves, eles também não tem tempo de dormir oito horas por dia ou dar atenção à sua família. Afinal, existem defeitos para consertar, sistemas para implantar ou ligações do trabalho para atender.

O Equilíbro P/CP

Este tipo de analista, consciente ou inconscientemente, somente enxerga a produção (P), em detrimento da sua capacidade produtiva (CP). A relação P/CP determina, como na fábula da galinha dos ovos de ouro, a relação entre a produção (P) e a capacidade necessária para a produção (CP). Queremos ovos de ouro, mas se não alimentarmos a galinha ou, ainda pior, matarmos a galinha, não teremos mais ovos.

É verdade que muitos analistas trabalham desta forma pois são guiados por gerências ou empresas que focam apenas na produção sem fornecer a infra-estrutura e meios para que o analista se recicle e seja um aprendiz constante (CP). Independente da razão, entretanto, o destino deste analista é um dos seguintes: a obsolescência ou um crônico problema de saúde. Analistas obsoletos ou doentes não produzem mais ovos atrativos e entram numa espiral descendente de produção inadequada e baixa capacidade produtiva. São galinhas velhas que param de botar ovos e se tornam canja para a sopa da rotatividade corporativa. No fim, estes analistas são substituídos por outros profissionais de mercado, que possuem um maior P e um maior CP. Eles formam a maior parte da massa de analistas demitidos e que tem grande dificuldade em se reposicionar no mercado.

Idealmente, as empresas deveriam fornecer espaço para que os seus profissionais trabalhem o CP. Programas de treinamento formais e espaços livres na agenda semanal para atividades de aprendizado constante de seus funcionários são exemplos de ações nesta linhas. Cito dois bons exemplos de empresas assim no Brasil:

• Uma multi-nacional no Rio de Janeiro que impede que gerentes aloquem mais do que 6 horas diárias ou 30 horas semanais de cada analista ou desenvolvedor.
• Uma empresa de pesquisa aplicada em Belo Horizonte que fornece às tardes de Sexta-Feira para os funcionários estudarem.

Profissionais que não trabalhem em empresas que priviligiem o CP, entretanto, não podem se lamentar. Ao invés, eles devem buscar o aprendizado constante e obviamente lutar para que as suas empresas implementem estes programas. Cursos de especialização, assinatura de revistas ou participação em comunidades técnicas são exemplos pessoais de aumentar o seu CP.

Não devemos, também, mirar no outro extremo e ficar apenas na “teoria”. Resultados contam e são muito importantes. Você provavelmente também deve conhecer algum analista “desocupado”. Ele passa o dia no MSN, no Orkut, Facebook, LinkedIn, Twitter e responde quase todos os emails em listas de discussão. Este profissional também não conclui projetos, pois ele está sempre mudando de empresas ao sabor dos modismos tecnológicos que ele ouviu falar ontem. Muitas vezes ele também é conhecido pela aplicação da técnica chamada “Resumèe-Driven-Design”, que é aplicar apenas o seu último framework “predileto” em todos os seus projetos. Sem o P, a equação P/CP se torna desiquilibrada. A sabedoria se encontra no equilíbrio ou como dizem os Budistas, no “Caminho do Meio”.

Por fim, lamento apenas que os “analistas ocupados” não poderão ler este post. Eles estarão muito atarefados na produção de ovos nas granjas de TI de todo o Brasil.

Pensamento do dia: “Os analfabetos do século XXI não serão aqueles que não sabem ler e escrever; mas os que não sabem aprender, desaprender e reaprender continuamente”, Alvin Toffler.

Da nossa experiência no meio acadêmico, percebemos alguns padrões e problemas comuns com alunos que estejam terminando trabalhos de fim de curso, em nível de graduação ou pós-graduação. Infelizmente o ensino metodológico formal nas nossas faculdade é muito deficitário, quando não é nulo, mesmo em instituições de renome nacional inquestionável.

Para exemplificar, recebo com frequência solicitações de monografia da seguinte forma: “Gostaria de fazer um trabalho sobre o framework Hibernate”, ou “Gostaria de fazer um trabalho sobre SOA”.

Qual o problema? O problema é que isto é apenas um “Desejo” e não se substancia em um mecanismo científico. Um trabalho científico deve estar ancorado em três pilares:

1. Um problema.
2. Uma hipótese para resolver este problema.
3. Uma metodologia que busque a comprovação desta hipótese.

Não é necessário curar o câncer ou a malária em um trabalho de monografia, mas os três elementos acima devem sempre estar presentes. Considere o desejo “Eu quero fazer um trabalho sobre o JSF”. O desejo está na ótica do aluno, o que é errado.

O trabalho deve sempre estar na ótica de um problema. Por exemplo, se fizermos uma análise de causa raiz, podemos identificar problemas no domínio onde o JSF está inserido, que é o desenvolvimento Web. Exemplos de problema poderiam incluir:

• Aplicações Web Java são custosas e improdutivas; ou
• Aplicações Web Java são pouco reusáveis.

A partir de um problema, devemos colocar uma hipótese. Para o problema acima, poderíamos ter uma hipótese da seguinte forma:

• O uso do JSF para desenvolver uma aplicação Web Java promove redução de custo, maior produtividade e maior reusabilidade.

Com a hipótese em mãos, devemos propor um método para tentar comprovar a mesma. Exemplos de métodos, que iremos explorar formalmente em outro blog, poderiam incluir:

• Analisar casos reais no mercado que usam o JSF e casos que não utilizem e realizar uma comparação de resultados de custo e esforço; ou
• Montar uma aplicação exemplo com JSF e a mesma aplicação sem JSF e realizar uma comparação de resultados

Finalmente, é importante lembrar que em um trabalho científico não tem por obrigação ter sucesso na hipótese. Isso é o desejado, óbvio, mas um resultado negativo pode ser bom (você mostrou uma forma de não atingir o resultado). Em outros casos, o trabalho pode ser inconclusivo. Cientificamente, isso é aceito também.

Na próxima vez que começar a escrever uma monografia, então, esqueça a tecnologia pela tecnologia e foque no problema.

Lembre-se de fazer a você mesmo três perguntas:

• Qual o problema que quero resolver?
• Qual a hipótese que tenho para atacar e resolver este problema?
• Como vou provar esta hipótese?

Fizemos uma apresentação ontem no ciclo de palestras do IGTI sobre conceitos de gerência de riscos, escopo e estimativas. Compartilho as idéias apresentadas lá no arquivo em anexo.

Para os mais interessados, recomendo aprofundar o assunto no excelente site do Steve McConnell, autor de dois clássicos de engenharia de Software (Rapid Development e Software Estimation: Demystifying the Black Art).

Um amigo do trabalho me passou um post anunciado na InfoQ anunciando que SOA está morto e a derradeira paulada é a recessão econômica. A figura com apelo gráfico é mostrada abaixo:

A premissa da autora é que SOA está morto porque a maior parte destes projetos falharam nas tentativas de gerar maior valor para os negócios, reduzir custos e promover agilidade por se concentrar em pilhas de fornecedores e discussões tecnicistas tais como ESB, WS-*. vs REST, entre outras. Esta premissa, entretanto, não prova que SOA é ruim. O uso errado de uma técnica ou metodologia não prova que esta técnica não funciona. A premissa prova apenas que o uso errado de uma técnica nao gera os resultados esperados pela aplicação correta desta técnica!

Usando os mesmos argumentos da autora, poderia afirmar também que os diversos projetos RUP onde os “gerentes e técnicos” fazem apenas “análise na elaboração” ou “implementação na construção”, adiando riscos e que portanto falharam poderiam provar também que o “RUP está morto”. Falacioso e errado. Se o RUP for usado adequadamente o que implica reduzir e mitigar riscos técnicos no projeto precocemente, o projeto será entregue e terá sucesso. Em um contexto mundial, poderia usar os mesmos argumentos da autora e dizer que as diversas iniciativas de paz entre Palestinos e Israelenses não funcionaram. Então a “Paz está morta!” também? Acredito que não, sinceramente.

Qual o problema com “projetos SOA” então? O problema é que SOA continua sendo muito mal entendido e aplicado de forma inadequada por pessoas de TI que não percebem os requisitos BPM e de governança necessários à uma implementação SOA bem sucedida. Isso não justifica entretanto, matar o termo SOA e criar um novo termo “Serviços”, conforme preconizado pela própria autora. Já temos termos demais em TI. Vida longa à SOA!

Para os interessados no debate que cercou este post, segue um resumo coletado pela InfoQ. Para os interessados em casos de sucesso SOA, recomendo a página a seguir, que possui dezenas de estudos de caso de sucesso SOA publicados.

Pensamentos do dia:

“Eu Não falhei. Eu inventei e provei mais um método que não permite criar a luz elétrica!”, Thomas Edson, após ser questionado na Décima-Milésima tentativa mal-sucedida em criar uma lâmpada.

“SOA is 1 percent about services and 99 percent about governance”, Danny Sabah.

Muitos usuários de CVS e Subversion pensam possuir apenas uma ferramenta para controlar versões de código. Estas ferramentas, assim como outras ferramentas de SCM (Gerência de Configuração) como o IBM Rational ClearCase, IBM Rational Team Concert ou o Visual Team System, permitem muito mais que o controle de versões de código. Estas ferramentas suportam Gerência de Configuração. Um rápido resumo das potencialidades desta estranha e pouco praticada disciplina é fornecido abaixo:

Dez Mandamentos da Gerência de Configuração

1. Identificar e armazenar itens de configuração (códigos, textos, documentos, binários, executáveis ou qualquer outro tipo de elemento) em um repositório seguro. Esta potencialidade endereça o problema comum em empresas chamado: Arquivos misteriosiamente perdidos devido a pessoas que confiam apenas em seus discos rígidos e pen-drives para backup.. Um repositório em SCM pode ser um disco local, disco virtual ou banco de dados seguro onde os itens de configuração são guardados e possuem rotinas de backup regulares.
2. Controlar e auditar mudanças nos itens de configuração. Esta potencialidade endereça o popular problema: Quem mexeu no código? Quando? Por quê?
3. Organizar itens de configuração em componentes. Esta potencialidade endereça o problema: Como proteger, baixar (checkout) ou entregar (checkin) todo um pacote relacionado de código (ex: camada visual) atomicamente.
4. Criar e manter linhas de base nos marcos de projetos e em liberações de manutenções. Esta potencialidade endereça o problema: Como consertar um defeito na versão 1.0 e evoluir o sistema para a versão 2.0 simultaneamente?
5. Organizar e integrar versões e atividades. Esta potencialidade endereça o problema: Como saber que atividades de manutenção alteraram quais códigos no meu sistema?
6. Manter espaços de trabalho estáveis e consistentes. Esta potencialidade trata o problema: Como evitar que alguém suba uma “versão” errada do código na véspera da entrega?
7. Suportar mudanças concorrentes nos itens de configuração. Esta potencialidade trata o problema: Como evitar que pessoas editem um código enquanto vários outros desenvolvedores joguem Paciência ou Tetris por que o código está “travado” para edição?
8. Integrar cedo e com frequência. Esta potencialidade trata o problema “Doom’s Day”: Como evitar dezenas ou centenas de defeitos que surgem misteriosamente quando um time resolve integrar o seu código na semana anterior à entrega do projeto.
9. Garantir a reprodutibilidade de builds de software. Esta potencialidade evita o problema: Como evitar que alguém instale uma nova versão do compilador ou de um framework não autorizado e torne o ambiente ou executável instável .

Os times que não buscam estas melhores práticas sofrem dos problemas nefastos colocados nas práticas (mandamentos) acima.

Aprendendo Gerência de Configuração

Uma fonte rica para o aprendizado de SCM é o portal CM Crossroads. Destaco aqui os blogs, arquivos e a revista sobre SCM deste portal.

Uma outra boa fonte também é o site SCM Patterns. Como o nome diz, boas práticas sobre SCM são a tônica deste site.

Finalmente, recomendo também o portal Planeta SCM, que agrega dezenas de feeds de gerentes de configuração e pessoas do meio com dicas práticas, conselhos e experiências com ferramentas.

Pensamento do dia: “O homem prudente edificou a sua casa sobre a rocha; e caiu a chuva, transbordaram os rios, sopraram os ventos e deram com ímpeto contra aquela casa, que não caiu, porque fora edificada sobre a rocha”, Mateus.

Fizemos hoje uma palestra dentro do circuito de palestras do IGTI (Instituto de Gestão em Tecnologia da Informação) sobre BPM. Discutimos aspectos gerais deste paradigma e apresentamos brevemente algumas soluções BPMS de mercado como o JBOSS jBPM, IBM WebSphere e MetaStorm ProVision.

Disponibilizo a apresentação em anexo para os iniciados e interessados em BPM.

Recursos adicionais como links, associações e blogs a respeito podem ser encontrados aqui.

Pensamento do dia: “Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?” -T.S. Eliot

Agora em Janeiro será lançado a segunda edição do livro SOA for Dummies, da autora Judith Hurwitz.

Não se deixe enganar pelo título. Apesar de ser um livro de introdução ao tema, o livro merece estar na biblioteca de qualquer empresa que trabalhe seriamente com SOA. O livro traz como principal novidade frente à primeira edição estudos de casos com diversas empresas e a coleta de lições aprendidas no período de 2007 a 2008.

Conforme descrito pela autora, as principais lições aprendidas em implementaçòes de projeto SOA foram:

• Projetos e empresas de sucesso começaram com serviços de negócio e processos de negócio antes de pensar em qualquer aspecto de implementação. Em outras palavras, SOA deve ser dirigida por BPM e não através de mecanismos tecnicistas como Web Services, ESB e adaptadores.
• Houve um grande aprendizado das empresas com projetos pilotos. O foco agora é em como melhorar as receitas de negócio através do reuso de serviços.
• As empresas desenharam uma estratégia de longo prazo através de uma implementação iterativa e incremental de serviços.
• Algumas poucas empresas aprenderam como criar serviços de ativos legados (Arqueologia de Software) e como reforçar o reuso destes serviços em novas aplicações (Reuso de Software).
• Companhias praticantes de SOA aprenderam, com um custo muito maior que o imaginado, como criar serviços de negócio com múltiplos usos em diversos processos de negócio.

Outras novidades do livro incluem Gerência de Serviços, Qualidade de Serviço, Componentização e também interação com BPM. Mais informações sobre este lançamento podem ser encontradas aqui.