Hoje quero falar sobre o terceiro e último módulo daquela palestra, sobre o nosso “Museu de Grandes Novidades”. O primeiro módulo falava de pessoas e times e foi registrado aqui nos artigos “O Clube da Esquina Globalizada” e “O Cubículo Global“. O segundo tratou de tecnologias e arquitetura corporativa, tema que mereceu duas entradas: “(Pensando Alto sobre) Arquitetura Corporativa” e “Arquitetura do Negócio“. O prato quente é servido no final e o tal “Museu” foi a figura selecionada para puxar assunto sobre processos (metodologias) e projetos. Sim, eu esperava reações ruins entre as boas e indiferentes: “No size fits all!” Aliás, quem abre o tema com o slide abaixo não pode esperar coisa muito diferente, né?

O “outras relíquias” do título indica a existência de um slide anterior. Verdadeira jóia: a certidão de nascimento do modelo ‘Cascata’. Mas, peraí: queria eu requentar debate tão chato e batido? Não era a intenção. E tento aplacar ânimos dizendo se tratar de um ‘Museu’, não de uma lixeira. Guardamos em um museu coisas que merecem ser vistas, lembradas e estudadas. Mostramos em um museu peças que têm valor. Preciso reforçar a questão que repeti várias vezes na palestra e que rotulei como ‘retórica’ (só pra tentar provar o contrário): nossas teorias (sobre engenharia de software) resistem ao confronto com as pessoas e tecnologias de hoje? Quantas ou quais sobreviveriam de fato? Minha cara e meu caro, se eu tivesse a resposta não estaria aqui, gastando o seu e o meu tempo.

Também não se trata da elucubração isolada de um mineiro de Varginha que desfila lorotas nas horas vagas. O SEMAT (Software Engineering Method and Theory), que tem entre seus signatários algumas das pessoas que mais contribuíram com a área em todos os tempos, afirma com todas as letras em sua “chamada para a ação” que aquilo que conhecemos (conhecemos?) sobre engenharia de software encontra-se num perigoso e escuro mato sem cachorro porque:

• Está repleta de modas e tendências, coisa que não combina com *engenharia*;
• Está carente de uma base teórica forte e amplamente aceita;
• Está abarrotada de métodos e variações com diferenças pouco compreendidas e artificialmente aumentadas;
• Está pobre-pobre-pobre-de-marré-marré-marré em termos de avaliações e validações. Cada um fala que seu “método” funciona e pronto; e
• Há uma divisão entre práticas da indústria e pesquisas da academia.

Não consigo pensar em nenhuma outra área do conhecimento humano que tenha passado por algo semelhante. Repare bem: um grupo de pessoas que escreveu os livros e nos ensinou engenharia de software nos últimos 40 anos concordou com um diagnóstico nada favorável do nosso estágio atual. Repare também que entre os signatários existem representantes de todas as “escolas” relevantes, da extrema-direita até a extrema-esquerda. Hã.. ok. Alguns caras da extrema-esquerda que inicialmente concordaram com o diagnóstico tiraram o time de campo quando viram que o papo centro-direitista não os agradaria nem um pouco. Não importa. E também não creio que o SEMAT, pelo andar da carruagem, gere algum resultado. Mas o estrago está ou deveria estar feito. Ou alguém não concorda com o diagnóstico apresentado?

.:.

Definitivamente, minha intenção não é promover o bilionésimo papo besta sobre “cascateiros X agilistas”. Acontece que, tanto no evento aberto quanto em um fechado, teve gente que se sentiu pessoalmente atacada pelo conteúdo e, desconfio, pelo tom utilizado.

Uma pessoa que participou da edição fechada desta palestra no último dia 9/11 manifestou enorme descontentamento com o evento. Detalhe: ela registrou sua insatisfação na forma de um comentário no último artigo publicado. Outros detalhes: utilizando nome falso, insinuando uma insatisfação geral e, indevidamente, registrando um link para o site da empresa contratante. Empresa que solicitou a remoção do comentário ou, no mínimo, do link que a identificava. Nunca cogitei a censura ao comentário (blog que é blog não modera nem censura). Mas, claro, retirei a referência para a empresa. Pela atenção, pelo time e pela rapidez na resposta, a empresa não merecia ver seu nome associado a comportamento tão feio e desonesto.

Já fui atacado de quase tudo quanto é jeito pelas ideias que defendo e pelo que critico. Na grande maioria das vezes o ataque ou resposta, mesmo os mais agressivos, não é covarde. Não é anônimo. É o mínimo que se espera, certo?

.:.

Já escrevi por aqui que esta palestra é uma coletânea de temas que, por vários motivos, repousavam em minha gaveta. Pra ser sincero, não acreditava na viabilidade dos temas (em termos econômicos e políticos, hehe). Estouro champanhe quando erro assim. Além da apresentação para quase 100 profissionais de uma mesma empresa, ontem tive a chance de levar o mesmo papo para um território que parecia ser, no mínimo, inusitado. Ganhei um belíssimo presente da Profa. Renate Landshoff: a oportunidade de apresentar “O Futuro não é mais…”  para duas turmas do curso de graduação em Biblioteconomia da FESPSP (Fundação Escola de Sociologia e Política de São Paulo). Além da bela e antenada turma, contei com a enriquecedora presença de Sérgio Storch. Não vou tentar explicar agora o exótico mashup que se desenha. Mas algumas pistas você encontrará neste artigo da Profa. Renate (e respectivos comentários).

“Beans“, a foto utilizada neste artigo, é de autoria de Naomi Ibuki e foi obtida no Flickr.

.:.

Nossa história se inicia com um grande apagão. Lá nos idos de 1950 e início da década de 1960, quando agências do governo dos EUA e algumas pouquíssimas empresas começaram a apostar no potencial do “cérebro eletrônico”, aconteceu a Crise do Software 1.0: milhões foram gastos naquelas engenhocas mastodônticas antes que sentissem falta de um componente essencial: gente. Particularmente daquele tipo que depois receberia a genérica alcunha “programador¹”. Qualquer projetinho de meia tigela demandava dezenas e até centenas de profissionais. Acontece que poucos projetos daquela época eram pouco ambiciosos. Só o SAGE (Semi Automatic Ground Environment), da Força Aérea, contou com 700 programadores e 1400 profissionais de suporte. Época legal, em que cada linha de código chegava a custar assombrosos US$ 50.

A grana, melhor dizendo, o potencial de faturamento chamou a atenção de muita gente. Começaram a brotar as “software houses” independentes. O desenvolvimento de sistemas deixava de ser uma exclusividade dos produtores de ferro (IBM, Burroughs, RCA etc). Mas como faltava gente. Os dois anúncios que você vê ao lado se preocupavam só com isso: atrair talentos. O simpático Dr. Bauer, da Informatics Inc., cravou a sua “segunda lei” no clássico reclame²: “o talento vai para onde está a ação“.

Mas os anúncios não eram suficientes. E as empresas lançaram mão das estratégias mais agressivas para encontrar “talentos”. Montavam escritórios e quiosques em grandes cidades só para achar pessoas que poderiam ser “convertidas” em programadores. Os recrutadores eram orientados a dedicar especial atenção para: professores de matemática e, olha que jóia, professores de música!

A estratégia funcionou. Em paralelo, universidades e escolas nasceram ou criaram cursos para formar gente que deveria atender toda aquela demanda pós-moderna.

Até que, num belo dia, o mundo ficou chato (no sentido de ter uma superfície plana). E dos lugares mais improváveis surgiam programadores que prometiam executar o mesmo trampo de seus similares ocidentais por 1/10 do preço ou menos. Quem já teve o prazer de ler “O Mundo é Plano“, de Thomas L. Friedman (Objetiva, 2005), aprendeu que a Globalização 3.0 não afetou apenas os desenvolvedores de sistemas. Ninguém está isento do achatamento do mundo. E todo mundo pode aproveitá-lo. Acontece que a pancada no mercado do software, além de ter sido a primeira, foi também a mais sentida. “The New Face of the Silicon Age”, artigo publicado na Wired em fevereiro de 2004, mostra bem o tamanho do estrago.

Os Pecados do Lado de Baixo do Equador

O alegre povo de Pindorama, com um certo atraso, sacou: “tem bagulho bom aí!” (e João de Santo Cristo ficou rico a acabou com todos desenvolvedores da Índia). Bem, não foi bem assim. Poderia ter sido, não fôssemos tão viciados no auto-engano. A edição da EXAME aí ao lado, de 25/jun/2003, cravava na capa: “Descobrimos um segredo: o Brasil produz tanto software quanto a Índia.” Pouco tempo depois, em 17/mar/2004, a mesma revista jogou uma ducha d’água fria: “A Índia dá aula ao Brasil” (negrito e vermelho da versão original). Segredinho sem vergonha esse, hem?

Jogamos tantas fichas em apostas bobinhas (CMMI, MPS.br e cartórios afin$) que agora assistimos bondes a nos ultrapassar. EXAME, em 30/jun/2010: “Rivais Além do Futebol – No setor de tecnologia, os empreendedores da Argentina estão melhor que os brasileiros na corrida da globalização.”

Vou poupá-los do chororô sobre uma estratégia para o software tupiniquim. Quem se interessar pelos meus R$ 0,02 sobre o tema pode ler uma pequena série que publiquei em dezembro de 2007 no abandonado Graffiti. O ponto aqui é outro.

É a Educação, Estúpido!

O que Índia, China, Coréia do Sul e outros emergentes da indústria digital têm em comum é a preocupação com educação. O tema sempre aparece na pauta de nossos políticos. Mas aparece assim, como um tópico em um slide que apresenta suas “prioridades”. Até hoje não vi ninguém ir além do óbvio (mais escolas, professores melhor preparados e mais bem pagos etc etc). Como sou um dos menos indicados a tratar o tema com a profundidade e seriedade que ele merece, me limitarei a propor dois ou três novos “slides”, com questões mais específicas:

• No último dia 12/ago a FGV assustou um tanto de gente com um número: “Até 2014, haverá um déficit de 800 mil vagas no setor“. Como não tem muito tempo que esse número era 200 mil, minha desconfiança é alta. Tanto que na palestra perguntei: “Será que estão confundindo a gente com atendentes de telemarketing de novo?” Não importa (muito). O fato é que há sim um “apagão”. E como suprir tamanha demanda de forma rápida? Com cursos técnicos! Em 2 anos é possível formar um batalhão de bons desenvolvedores. Repito o que disse o mineiro Adail Retamal em um seminário há 3 anos: “Programação se aprende em curso técnico, não na faculdade“.
• Não tenho números oficiais, mas há tempos sabemos que cerca de metade da patota que inicia um curso (técnico ou superior) não o conclui. Alguém já se ocupou em descobrir as razões de tanta desilusão? Será que a distância entre nosso instigante cotidiano digital e os ângulos retos e empoeirados de nossas escolas não é uma boa explicação?
• Se eu tivesse grana montaria uma escola com uma grade antenada. Uma base comum, formada por mínimas certezas e teorias fortes, seria obrigatória para todos. Depois, um cardápio multidisciplinar estaria à disposição de designers, engenheiros, líderes, analistas etc. Não me preocuparia em ter o crivo do MEC, PMI, IIBA nem nada do tipo. Uma escola de pensamento independente. Acho que seria uma revolução.
• A formação de mão de obra qualificada é responsabilidade exclusiva de governos? É estranho o pensamento de alguns de nossos capitalistas de TI. Aqueles que têm real consciência da criticidade das pessoas para seu negócio devem se mexer. Quem quer talento hoje deve se preocupar em formá-lo. Duas dicas: i) Faça com que 4 ou 8 horas da jornada semanal seja utilizada exclusivamente em atividades de aprendizado; ii) Incorpore a segunda lei do Dr. Bauer: “O talento vai para onde a ação está“. Ação, pra quem não entendeu, é projeto que dá tesão.

Observações:

1. É preciso dizer que naquela época a tarefa de programação era dividida entre diversas funções, do pensador de algoritmos ao perfurador de cartões.
2. Sorte nossa que o anúncio, lá no rodapé (p.s.), mata a curiosidade. A “primeira lei” do Dr. Bauer é a seguinte: “se o programa tem um bug, o computador o encontrará”. Grande Dr. Bauer. Mal sabia que sua primeira lei viraria mantra-desculpa de tester preguiçoso…
3. A parte pré-histórica aqui narrada foi surrupiada do grande livro “From Airline Reservations to Sonic the Hedgehog – A History of the Software Industry”, de Martin Campbell-Kelly (The MIT Press, 2003).
4. O cartoon, “Fitting into the system“, foi surrupiado de HikingArtist.com. Os dois anúncios que ilustram este artigo foram publicados no livro citado acima. E as capas da EXAME e da Wired são propriedade de suas editoras.
5. O “Clube da Esquina” é do Milton e de todos os Mineiros; “O Pecado ao Sul do Equador” é do Chico; e o “Bom Bagulho”, do Renato Russo.

O mundo mudou. E não me lembro qual foi a última vez que utilizei um título tão “fraquinho”. Como o antecipei nas duas partes anteriores, seguirei com ele.

O mundo muda todo dia. Em negócios e TI a impressão que temos e deixamos é de uma dinâmica quase caótica. Uma volatilidade que, segundo experts, gera uma população repleta de pessoas inseguras, ansiosas e desconfiadas. Não raro, exageramos os possíveis impactos de determinado acontecimento. Outras tantas vezes subestimamos tendências. Como a imensa maioria das pessoas é desprovida de dons proféticos e bolas de cristal, é natural que seja assim. Como é normal que indivíduos apresentem reações muito diferentes quando defrontados com uma mesma mudança. Mas o papo aqui é ou deveria ser sobre projetos e seus gerentes.

Projeto é mudança. Talvez esta seja a verdade absoluta mais ignorada ou desprezada. Quando uma organização dispara um projeto ela está implementando uma mudança. Aqueles que foram selecionados para o trabalho devem estar preparados para lidar com todos os reflexos gerados por ela. Esses reflexos, com maior ou menor intensidade, fazem com que os projetos sejam naturalmente instáveis. Ainda bem que eles têm data para acabar, não é mesmo?

Porque é natural do ser humano o gosto ou necessidade de estabilidade. Mesmo aqueles viciados em adrenalina, como os praticantes de esportes radicais, valorizam muito os períodos de calmaria. O fato é que estabilidade perene apenas é possível em processos – em ações que repetimos ad infinitum. Projetos são únicos em seus objetivos e restrições. Eles sempre são inéditos de alguma maneira. Por isso é estranha uma certa obsessão por projetos estáveis. Surrupiando um dito de Michael Hammer¹, “projeto instável” é um oxímoro em vias de se tornar um pleonasmo. Por isso é equivocada a crença em planos. Ou, melhor dizendo, a crença na certeza dos planos. Mas, antes de “atacar” os planos (se é que vou fazê-lo), vamos falar sobre a crença. De onde ela vem? O que a alimenta?

Durante muito tempo jogamos praticamente todas as nossas fichas em padrões e metodologias que, de uma forma ou de outra, prometem estabilidade e previsibilidade. Apesar das promessas raramente cumpridas, particularmente em projetos de TI, essas propostas se espalharam como notícia ruim. As falhas, quando reconhecidas, raramente eram atribuídas aos padrões e metodologias adotados. Quase sempre a culpa é de quem os implementou. Mercados foram criados em torno dessas propostas. E elas se solidificaram. No mau sentido.

Temos hoje um imenso “sistema legado” de processos de gerenciamento e desenvolvimento. Usei o termo “sistema legado” exatamente porque ele nos remete aos nossos legados mais famosos – igualmente caros e não muito “simpáticos” a mudanças. O “sistema” que aqui trato é composto por treinamentos, certificações, ferramentas, corpos de conhecimento e, principalmente, cultura. Ou, para voltar ao termo utilizado anteriormente, crença.

Em determinado momento da história alguns componentes do “sistema” se iludiram com sua pretensa estabilidade. Algumas palavrinhas que guiam os tempos modernos, como inovação e criatividade, são simplesmente ignoradas pelo “sistema”. O próprio sentido de mudança e o entendimento de que não se trata de algo indesejável, mas necessário e inevitável, não encontra respaldo real em algumas das peças mais relevantes do “sistema legado” de processos de gerenciamento e desenvolvimento.

Seria então o caso de jogar todo o “sistema” no lixo? Claro que não. Sugestões assim são ingênuas (mas pouco inocentes). Ingênuas por não perceberem que o “legado” criado, assim como seus pares, é complexo e caro, mas não deixa de ter seu valor. Acredito que, de todos os seus componentes, o primeiro a ser questionado deveria ser a crença ou cultura. Questão de coerência: como um gerente de projetos – um profissional especializado na implementação de mudanças – pode resistir tanto em mudar?

Ao questionar a crença, ao adotar um perfil mais cético, o profissional tomará os outros componentes do sistema com outros olhos. Ele tenderá a ser mais cuidadoso e desconfiado. Mas será também mais curioso.

Não se iluda. Mudar cultura ou questionar a crença não é nada fácil. Também não é algo que possa ser implementado como um projeto. Mas é fácil apontar a trilha. Aliás, é até meio besta: 1) Aceitar que mudanças são inevitáveis; 2) Questionar certezas absolutas; e 3) Não ter medo do novo e muito menos de aprendê-lo.

O Argumento Derradeiro

Há poucos dias, Scott Berkun, autor de “A Arte do Gerenciamento de Projetos” (Bookman, 2008), retomou um tema que vou traduzir da seguinte maneira: Gerenciamento de projetos é chato? Berkun responde que “o gerenciamento de projetos é tão chato quanto a coisa que está sendo gerenciada”. Por favor, me desculpe a chatice, mas releia a frase negritada.

Em um artigo anterior Berkun já havia comentado sua impressão de que o Gerenciamento de Projetos não é muito respeitado. E, em outras palavras, não é uma função ou profissão sexy, atraente. Você não vê nenhuma criança ou adolescente dizendo: “Quando eu crescer quero ser gerente de projetos”. Mas Berkun argumenta que diretores de cinema, técnicos de futebol, produtores de discos e várias outras profissões são variações de gerentes de projetos. A diferença é que eles usam outros termos. Nomes que tornam explícita a coisa que gerenciam. E fazem daquela função algo mais atraente, com certeza.

Me lembro quando chegou a hora de definir minha profissão. Meu velho, como de costume, deu um conselho rápido e nada rasteiro: “Escolhe qualquer coisa, menos contabilidade”. Ele era contador. Dos bons, diga-se de passagem. Trabalhava 30 horas por semana e fazia de tudo para tornar sua rotina menos chata. Mas ele sabia que estava aprisionado em uma função que é, por natureza, 90% do tempo enfadonha.

Gerenciamento de projetos pode ser tudo, menos chato. Mas, por incrível que pareça, conseguimos torná-la uma profissão dura e carrancuda. Quadrada mesmo. E me parece claro que os ângulos retos de todos os componentes do nosso “sistema legado” são os maiores responsáveis por isso.

.:.

Nome aos Bois e Pingos nos ‘is’

Ao bom entendedor que por aqui navega ficou claro que dentre os componentes do “sistema legado” tratado acima figuram: PMBoK, CMMI, Prince2, MPS.br, ITIL, afins e derivados. Manada devidamente nomeada, resta agora esclarecer alguns pontos:

• PMBoK e BABoK não tratam de nenhum tipo específico de projeto. Então, pode parecer equivocada uma crítica que considere apenas projetos de TI. Não na minha opinião. Ainda avalio se vale a pena um artigo sobre “O Problema com os BoK’s”. Vale a pena ou a espada?
• Não estarei aqui para ver a aposentadoria do “sistema legado”. Ele resistirá e sobreviverá por um bom tempo. A torcida, de certa forma otimista, é para que ele encontre e beba de um tipo de fonte da juventude. O tipo de ‘service pack’ que o BABoK receberá, por exemplo², é uma de várias possibilidades de rejuvenescimento. Os únicos pré-requisitos são humildade e olhos e ouvidos abertos.
• Por ser longevo, o “sistema legado” não pode ser ignorado por nenhum profissional razoavelmente sério. Há muito conhecimento ali.
  Mas é um pecado iniciar a profissão pelo lado quadrado da força. Quem quer iniciar uma carreira em gerenciamento de projetos deveria, antes de qualquer coisa, estudar alguns documentos que ainda são meio “apócrifos”. Eu iniciaria por “A Arte do Gerenciamento de Projetos” (Scott Berkun. Bookman, 2008) e “Agile Project Management – Second Edition” (Jim Highsmith. Addison-Wesley, 2010). Necessariamente nesta ordem. Eu não tive essa sorte. Mas também não virei contador³.

.:.

Observações

1. Michael Hammer utilizou aquela frase para falar sobre mudanças corporativas. A original é: “Mudança corporativa é um oxímoro em vias de se tornar um pleonasmo“.
2. Em dezembro fiquei sabendo que o IIBA está preparando uma “Extensão Ágil” para o BABoK. Quem viu a “Leitura Crítica” que fiz já sabia que era uma correção mais que necessária. Apesar da tentativa da versão 2.0 em atender os mundos “Plan-Driven” e “Change-Driven”. Mais do que qualquer coisa, devemos elogiar a humildade e iniciativa do IIBA.
3. Por favor, prezados contadores, não me levem a mal. Além do meu velho, tenho vários outros parentes que assumiram e gostam desta honrosa profissão. Só não dá para discutir o fato dela ser  90% do tempo chatinha. Sabem o que meu velho fazia quando queria um pouco de diversão? Pegava a contabilidade de uma empresa pra lá de enrolada com fisco e afins. Ou então contratava o filho para desenvolver o sistema de contabilidade daquela empresa encrencada. Pois é, eu não estaria aqui se não fosse a contabilidade.
4. O desenho utilizado neste artigo, flikr0675, é do flikr.

O reuso de ativos de software é uma daquelas várias promessas da área de TI que parecem gerar mais decepções do que resultados concretos. Antes da onda SOA, as propostas que colocaram a reusabilidade como uma de suas maiores vantagens foram a Orientação a Objetos (OO) e o Desenvolvimento Baseado em Componentes (CBD – Component-Based Development). Ambas as propostas tinham o reuso como uma conseqüência natural. Ou seja, não se preocuparam em fazer do reuso uma prática sistemática, planejada. Autores como Grady Booch transferiam para os programadores a responsabilidade de reutilizar ativos de software: “durante a implementação, procure agressivamente por partes que possam ser reutilizadas” . Hoje é dito que “oportunidades para o reuso são como os bugs, quanto antes elas forem encontradas melhor” .

O reuso não planejado, chamado por Steve McConnell de “reuso oportunista”, careceria de “alguma sorte” para a sua realização . Sendo casual, ele dependeria muito da equipe do projeto e do conhecimento que esse time tem sobre os ativos existentes e projetos anteriores da organização. Hoje pode-se afirmar que os benefícios gerados pelo reuso de ativos de software não podem ser plenamente realizados se dependerem exclusivamente da casualidade – o encontro de coincidências entre dois ou mais projetos – e do conhecimento de uma equipe de projeto.

O reuso sistemático ou planejado de ativos de software significa :

• Compreensão de como o reuso contribui para a realização dos objetivos do negócio como um todo;
• Definição de estratégias técnicas e gerenciais para que se alcance o máximo valor com o reuso;
• Integração do reuso em todo o processo de software e também no programa de melhoria do processo;
• Garantia de que toda a equipe possui as competências e motivação necessárias;
• Estabelecimento do adequado suporte organizacional, técnico e orçamentário; e
• Uso de métricas apropriadas para controle da performance do reuso.

Ao contrário do que se imaginava, o reuso depende muito pouco de tecnologia. Pesquisa realizada com 71 organizações de desenvolvimento mediu o impacto de uma série de fatores na adoção do reuso e concluiu que, das 6 dimensões medidas, a tecnologia é a menos relevante. No reuso sistemático, os fatores mais críticos para o sucesso seriam :

• Planejamento e Melhoria Contínua do Processo;
• Existência de um Processo Formalizado;
• Apoio da Alta Gerência;
• Similaridade entre Projetos; e
• Arquitetura Comum.

Posteriormente esta série de artigos tratará de cada uma das dimensões apresentadas na lista acima. Neste ponto o importante é a constatação de que “a introdução do reuso sistemático é muito mais do que uma mudança tecnológica: ele deve ser compreendido e gerenciado como um grande conjunto de mudanças no processo de software” . As três primeiras dimensões apresentadas acima, do tipo organizacional, aparecem apenas quando o processo de reuso é sistemático e formalizado perante toda a organização.

É importante lembrar que, como foi colocado no primeiro artigo da série, dois dos principais modelos para melhoria dos processos de software, o CMMI e o MPS.br, não contemplam o reuso. Apesar de indicarem que se trata de um nítido sinal de maturidade do processo de uma organização . Algumas propostas sugerem a adaptação dos grupos de reuso da ISO/IEC 15504-5 para as áreas de processo do CMMI . Há ainda a possibilidade do MPS.br incorporar processos de reuso em versão a ser liberada no primeiro semestre de 2007. Organizações interessadas em adotar o reuso sistemático poderiam optar por incorporá-lo ao seu programa de Melhoria de Processos de Software (MPS) ou tratá-lo como uma iniciativa independente.

No entanto, na implementação de uma SOA, o reuso está no núcleo dos trabalhos. O reuso sistemático não é mais uma opção, mas uma condição crítica para o sucesso de uma iniciativa dessa natureza. Pode-se dizer então que a introdução de uma SOA forçará a adoção de práticas sistemáticas de reutilização de ativos de software. Organizações poderão aproveitar a oportunidade e tornar o reuso um componente fixo de seu programa MPS.

Alto Custo

Edward Yourdon sugeriu uma regra que dizia que um “ativo reutilizável exigirá o dobro do esforço requerido por um ativo comum” . Fred Brooks estima que deve ser “o triplo” do número sugerido por Yourdon . Steve McConnell reconhece que o reuso planejado não é uma prática de curto prazo. “Um programa de reuso pode demorar 2 anos para começar a gerar componentes realmente reutilizáveis”. Mas cita que os ganhos de produtividade podem fazer com que a organização passe a realizar 35 pontos de função (PF) / pessoa / mês, contra uma média nacional que seria de 5 PF / pessoa / mês *.

Os autores de “Practical Software Reuse” colocam o tema de outra forma: “todos os custos com software são sempre considerados um overhead“. “Por isso”, eles continuam, “as avaliações do retorno sobre os investimentos (ROI) em iniciativas de melhorias (seja reuso ou um programa MPS) raramente estão disponíveis e raramente são críveis”. No entanto, “independente da forma como o contabilizemos, reuso é um investimento. E todo investimento envolve incertezas, riscos e ‘chutes'” .

Por tudo isso parece que, sem o envolvimento e o apoio da alta gerência, torna-se quase impossível a implantação de práticas sistemáticas de reuso. E, com certeza, está aqui uma das grandes razões para o fato do reuso nunca ter entregue um mínimo das promessas realizadas nas últimas décadas.

===

Referências:

1. Object Solutions
   Grady Booch
   Addison-Wesley (1996).
2. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
3. Rapid Development
   Steve McConnell
   Microsoft Press (1996).
4. Strategies for Software Reuse:
   A Principal Component Analysis of Reuse Practices
   (PDF – Requer registro e pagamento)
   Marcus A. Rothenberger et al
   IEEE Transactions on Software Engineering, Vol. 29, No 9, (Set/2003).
5. CMMI Performance Results
   Exemplo de um caso específico (Boeing).
   Carnegie Mellon / Software Engineering Institute (SEI).
6. Adaptação dos Processos do Grupo de Reuso do ISO/IEC 15504-5 para as Áreas de Processo do CMMI (PDF)
   Leandro de Paula Silva
   Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras (2006).
7. Decline and Fall of the American Programmer
   Edward Yourdon
   Yourdon Press (1992).
8. The Mythical Man-Month – Anniversary Edition
   Fred Brooks
   Addison-Wesley (1995).
   

===

* Ah, como eu gostaria de conhecer, nem que fosse um pouquinho só, os números tupiniquins…

A crescente aceitação da proposta de Arquiteturas Orientadas a Serviços (SOA) fez com que voltasse para agendas e debates um velho tabu da área de TI: o Reuso de Ativos de Software. Uma pesquisa recente, tratando especificamente de SOA, mostra que a maioria das empresas espera reutilizar apenas 30% dos serviços criados. Apesar de 84% delas dizerem que a possibilidade de reutilização de ativos é uma das maiores promessas de uma SOA; uma das maiores justificativas para sua adoção. Vamos aproveitar o debate para tratar o tema de uma maneira mais aprofundada. Este post inaugura uma série sobre o assunto. Gestão de Ativos; Reuso Sistemático; Adequação de processos; RAS (Reusable Asset Specification); GBA (Gestor da Biblioteca de Ativos); dentre outros, serão tratados de maneira específica nos próximos artigos*.

O assunto é tão antigo e batido, com sucessivas ressurreições e decepções, que fará com que muitos profissionais da área simplesmente ignorem a discussão e a nova fase de oportunidades aberta pelo conceito SOA. Data de 1968 a primeira tentativa para tornar o reuso sistemático uma prática , uma disciplina obrigatória em Engenharia de Software. Muito tempo depois, de maneira menos impositiva, foi a vez da Orientação a Objetos e da Componentização proporem e facilitarem o reuso de ativos de software. A princípio, os resultados sempre foram desprezíveis. Quando havia algum resultado.

A reutilização de experiências e conhecimentos externos – normalmente apresentados como aplicações, frameworks, componentes, design patterns ou até mesmo código fonte – é prática corriqueira na maioria das organizações que desenvolvem sistemas atualmente. O grande problema, o tabu em torno do reuso de software, é o não aproveitamento dos ativos criados internamente. Qualquer tipo de ativo.

O reuso do capital intelectual – do conhecimento e da capacidade de aprendizado e inovação – é um desafio para todas as áreas de praticamente todo tipo de empresa. Não se trata de uma carência específica da área de TI, apesar de sua natural orientação a projetos e sua intimidade com tecnologias indicarem que seria teoricamente mais simples a adoção de métodos e ferramentas para uma excelente gestão de conhecimentos. Trata-se de uma área que tem muito a evoluir. Erros e falhas recorrentes indicam que o conhecimento não está fluindo de forma adequada. “Os que não conseguem lembrar-se do passado estão condenados a repeti-lo“, dizia George Santayana.

No entanto, de todos os ativos que formam o grande inventário da área de TI, aquele que parece mais esquecido ou, colocando de outra forma, relegado a um segundo plano, são os ativos de software. Seus co-irmãos palpáveis, notadamente o hardware e todas as instalações físicas, herdaram métodos e ferramental de controle de todos os outros ativos tangíveis de uma organização. Eles aparecem no controle patrimonial (nos sistemas de Ativo Fixo e Contabilidade) da empresa. Cadeiras, servidores e caminhões merecem uma “etiqueta” de patrimônio. Você usa, e reusa, aquilo que você sabe que possui. Quando conhece sua localização, utilidade, modos de uso, restrições, idade etc.

Autores como Robert Kaplan e David Norton, criadores do Balanced Scorecard, classificam os ativos de software como intangíveis . Talvez sejam exatamente a percebida intangibilidade e a infinita maleabilidade do software que façam com que ele seja um ativo muito mal tratado e pouco controlado. Outro motivo, sugerido por Paul Strassmann , seria a falsa idéia de que o ciclo de vida do software obedece aquele ditado pelo hardware (com uma total depreciação em um prazo de 4 anos). É sabido que algumas empresas, particularmente no ramo financeiro, possuem código com mais de duas décadas de vida.

“Sem o legado, cada geração começaria na idade da pedra.”
– Paul Strassmann

Visando à valorização dos ativos de software, Strassmann sugere que as organizações :

• Adotem ferramentas que forcem a construção de software a partir de um repositório de peças padrão reutilizáveis;
• Façam da acumulação e preservação dos ativos de software úteis um de seus principais objetivos;
• Ofereçam incentivos para que o staff de sistemas inclua a acumulação de ativos de software como um de seus objetivos-chave; e
• Aumentem a longevidade dos ativos de informação ao invés de aceitar a suposição de que eles não valerão nada após o período de breakeven.

Viabilidade

A era industrial se consolidou através do reuso de peças padrão. A economia de escala é indissociável do reuso. As linhas de montagem ganharam a forma que conhecemos hoje após a adoção de conceitos de reuso. O mercado de TI lançou suas “fábricas de software” mas parece ter se concentrado exclusivamente na parte (des)humana da metáfora.

Apesar do reuso sistemático ser considerado um claro indicador de maturidade , não há em propostas como o CMMI ou MPS.br uma área ou processo específico para incentivá-lo e controlá-lo. No RUP, amplamente divulgado e relativamente aceito, o reuso de ativos é citado como “facilitado” pelo processo . No entanto, não há uma única disciplina que tente fazer do reuso uma prática sistemática, intencional.

“Os ativos intelectuais, ao contrário dos ativos físicos, aumentam de valor com o uso.”
– James Brian Quinn

O mesmo se aplica para ativos de software (que são um tipo de ativo intelectual): quanto maior seu uso (e reuso), maior seu valor. Por isso causa estranheza, particularmente naqueles “não-letrados” na área, nossa incapacidade ou resistência em fazer do reuso uma prática central, obrigatória. Assim como parece estranha e extremamente pessimista a meta aferida na pesquisa citada no início deste artigo: a reutilização de 30% dos serviços em uma SOA. Casos documentados , anteriores à onda SOA, reportam ganhos de até 72% em organizações que adotaram o reuso de ativos de software como uma prática sistemática. Se sua viabilidade é provada em empresas que não têm no desenvolvimento de software uma atividade fim, o que dizer então daquelas que vivem de produzir e comercializar software?

===

* Como em alguns casos anteriores, este artigo é parte de um estudo/trabalho em desenvolvimento. Ao término da série será publicada uma compilação, em formato PDF, com as devidas revisões e considerando eventuais críticas e/ou sugestões recebidas. Sinta-se à vontade para participar.

===

Referências:

1. Outside the Box (blog de Todd Biske): Use or Reuse?
2. Software Reuse: Principles, Patterns, Prospects
   Mária Smolárová e Pavol Návrat
   Slovak University of Technology
3. Mapas Estratégicos
   Robert S. Kaplan e David P. Norton
   Editora Campus / Elsevier (2004).
4. The Squandered Computer
   Paul A. Strassmann
   The Information Economics Press (1997).
5. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
6. Hoje (11/Dez/2006) fiz uma consulta ao grupo de discussão CMM-Br. Tudo indica que o MPS.br receberá um processo específico para tratar de Reuso a partir de Abril/2007.
   Agradeço os colegas Rafael Prikladnicki e Marcio Pecegueiro do Amaral pelas informações.
7. The Rational Unified Process – An Introduction (Second Edition)
   Philippe Kruchten
   Addison-Wesley (2000).