Antes, porém, a viagem. É minha segunda ida a Bauru, mais especificamente para a UNESP. A primeira foi em novembro do ano passado. Um passeio maluco que resultou em quase 24 horas dentro de ônibus, de Vga para Bauru via Campinas. A experiência foi legal mas excessivamente cansativa. Desta vez eu encararia um vôo de ATR, CGH – Bauru/Arealva sem escalas. Diz o povo, mineiro não perde o trem (ônibus ou avião). Daí que o mineiro aqui só descobriu em cima de hora que perderia o vôo se não fosse para Sampa na madrugada de domingo. Imprevisto que resultou em horas e horas perambulando feito um zumbi em dois terminais, Tietê e Congonhas. Zumbi? Pois é: desde a última quinta convivo com a 2ª gripe do ano: gripe “Carlinhos Bala”. Não sei se ela pega só corinthianos, mas é devastadora! E não deixa dormir. Azar dos corinthianos que compartilharam ônibus e aviões comigo…

Quando comecei a palestra, na noite de segunda, completava 37 horas sem dormir. Alertei a turma para um risco inédito: o palestrante poderia dormir! Azar deles, não aconteceu. E até que rolou sem grandes acidentes a primeira de duas palestras. Rolou até sorteio de uma caixa de quindins, o que ajuda a “prender” uma platéia. Invertendo a ordem natural de meus eventos, começamos com Engenharia de Requisitos. A mesma turma veria, no dia seguinte, uma palestra sobre Modelagem de Negócios. E um improviso que fecharia com chave de ouro a minha participação naquele evento que é totalmente organizado e tocado pela estudantada, a exemplo da Semana Acadêmica da UFLA.

Antes da surpresa, porém, vou falar sobre a viagem de volta. Ainda zumbi (tipo aqueles coadjuvantes dos filmes do Corman sobre o tema), me enganei sobre o horário do vôo. Quando cheguei no distante aeroporto de Arealva, certo de mais de uma hora de espera, fui recepcionado por três assustados funcionários: “o senhor vai embarcar?”. Como assim? Meu vôo é o próximo. Quase gelei quando falaram que não tinha próximo… Deve ter gelado mais aquele prestativo atendente que invadiu a pista correndo e pedindo para o piloto esperar: “Tem mais um!”. Foi surreal, mas atrasaram a decolagem e abriram a porta do avião para o zumbi aqui poder embarcar. Agora só falta dizer que eu sou culpado pelo caos aéreo. Bom, para terminar a saga, corri feito louco de Congonhas para o Tietê (Portuguesa) e consegui pegar o último buzão. Lá pelas 2h30 da matina, no meio d’uma neblina igualmente “Corman” e d’um frio daqueles, desembarquei em Vga. Eu e outros 3 zumbis.

Vou repetir o que escrevi depois da primeira ida para Bauru: queria descobrir uma forma de ‘importar’ aquele espírito empreendedor aqui para minha terrinha. Como na semana anterior estive com a estudantada de Lavras, as diferenças ficaram ainda mais nítidas. Não é demérito da turma de Lavras, não é isso. Mas é muito visível a diferença. Todos os participantes do evento de Bauru, do 3º e 4º anos, já trabalham. Na área! E muitos ainda têm fôlego para buscar projetos “por fora”, inclusive iniciativas de software livre. São mais dinâmicos e, de certa forma, mais “famintos” por novos conhecimentos e experiências. Precisa dizer que tal espírito se reflete na universidade e até na cidade? O interior de SP não é mais desenvolvido que o interior das Geraes por acaso, sorte ou força política. Triste (para os mineiros), mas este é outro assunto. Voltemos ao nosso.

Aquele improviso que rolou no evento de ontem é fruto de uma longa história. História de quase 1 ano. Um dos pontos principais de meu trabalho para a Formação de Analistas de Negócios é uma sugestão para a Estruturação de Requisitos. Dois participantes das primeiras edições do FAN, Jean Streleski de Bauru e Reinaldo Castro de São Carlos, gostaram da idéia e começaram a desenvolvê-la. Ontem fomos apresentados, platéia e eu, ao R/Open, uma versão “alpha” de uma aplicação que pega, remixa e estende minhas sugestões. Jean e Hailton, o desenvolvedor que transformou nossos requisitos na bonita ferramenta que aparece aí do lado, fizeram a apresentação. O R/Open (ou RequisiteOpen, nomes ‘temporários’?), foi todo desenvolvido com a dupla dinâmica PHP+MySQL. Usa Ajax e foi arquitetato, de nascença, para atender um nobre requisito: ter seu código aberto. Ou seja, a solução tem uma arquitetura robusta, que soube lidar muito bem com eventuais limitações do PHP. Nas palavras do Hailton, “é bem OO (Orientada a Objetos)”.

A ferramenta respeita integralmente aquele meu rabisco. Ou seja, parte dos Objetivos e Processos de Negócio. E organiza o escopo como um conjunto de casos de uso. E, antenadíssima, sugere a adoção de um processo de desenvolvimento que seja iterativo e incremental. Para tal Jean se baseou no OpenUP para traçar o método de desenvolvimento. Me arrisco a dizer que nenhuma outra ferramenta para desenvolvimento e gerenciamento de requisitos tem um enfoque tão rico, natural e prático. Não sei se a platéia notou, mas fiquei boquiaberto com aquilo que eles chamaram de “versão alpha”.

Claro, ainda há muito por fazer. Jean e outros voluntários de Bauru devem aproveitar as férias de julho para fechar uma versão “beta”, a primeira que deve ser disponibilizada para o público. Espero apoiá-los nesta etapa, inclusive na documentação da aplicação. Mas vou elaborar também uma sugestão de ‘roadmap’, uma coletânea de provocações: a primeira forçará um reencontro com a turma de São Carlos: será que conseguimos acoplar uma ferramenta CASE desenvolvida lá ao R/Open? Outra: vale a pena aproximar o R/Open do Eclipse? Caramba, são tantas possibilidades que só espero não ‘bagunçar o meio de campo’. Estamos todos cientes de que, tão logo seja publicada como software livre, a ferramenta ganhará vida própria. Que seja longa e resulte em produtividade e qualidade para todos os seus usuários.

Momento TKS!: Jean, Léo, Rafael, Hailton e toda aquela cambada que organizou e participou dos eventos merecem os parabéns. A UNESP e todos os seus professores (BSI e BCC) merecem os parabéns por abrir espaço e motivar uma turma tão especial.

Para encerrar, repetirei uma provocação que fiz para todos que vivem atolados em intermináveis congestionamentos: prestem atenção na riqueza que brota longe das capitais. Valorizem quem está gerando talento de verdade. Mas, por favor, valorizar não é plantar “fábricas de software caça-níqueis” em locais onde o salário é mais baixo, ok? Pensem grande. Da mesma forma como a estudantada da UNESP pensa. Inté!

Quais são os pontos de vista relevantes? Depende do projeto. Trata-se de um empreendimento que exige interfaces complexas com usuários? A equipe deveria contar com um especialista em usabilidade. O projeto requer um sofisticado desenho de bases de dados? A presença de um especialista em bases transacionais, analíticas e em gerenciamento de conteúdo não estruturado é recomendada. O projeto requer um preciso dimensionamento de servidores e da rede? Convoque o especialista em infraestrutura. Claro, o AN é presença obrigatória. É sua responsabilidade *ensinar* o problema para a equipe e auxiliar no desenho da solução. Essa reunião de especialistas é o que chamo de “Parlamento“.

Parlamento, s.m. (do inglês parliament)
assembléia ou câmara legislativa;
ato de falar.

Cabe aqui um lembrete: tomando o RUP ou o OpenUP como referência, ainda nos encontramos na fase conhecida como Incepção. Não iniciamos ainda a etapa de elaboração que, segundo aquelas propostas, resulta no “Lifecycle Architecture Milestone” (veja figura abaixo ). O parlamento foi convocado para desenhar uma ou mais soluções para o problema colocado, e apoiar o AN na elaboração de uma proposta (ou documento de visão, ou project charter, ou…).

Ao aprender e debater cada caso de uso, começando sempre por aqueles mais críticos para o negócio, os participantes do parlamento “rabiscam” as primeiras idéias de solução. São essas idéias que, em determinado momento, são agrupadas. Como vimos no artigo anterior, podemos ter até três alternativas de solução – três agrupamentos de idéias.

Cada idéia deve ser avaliada por todos os participantes. Antes dos chutes (ou estimativas), espera-se uma classificação bem simples: a implementação daquela idéia é Simples, de Média Complexidade ou Complexa? Ainda estamos preocupados em descobrir qual é a melhor solução para aquele problema. Lembrando: “melhor” não significa a mais sofisticada ou a mais econômica. A melhor solução será aquela que estiver mais alinhada com os objetivos e restrições do negócio.

Neste momento eu gosto muito de utilizar uma ferramenta que, aparentemente, é meio bobinha. Estou falando da Matriz SMBP (confesso, acabo de inventar um nome para o brinquedinho). Veja o rabisco abaixo:

Todo caso de uso e requisito aprendido e desenvolvido pelo AN mereceu uma classificação simples: Fundamental, Importante ou Opcional. Vamos assumir que esta classificação equivale a 3, 2 e 1 ponto, respectivamente. Somamos a pontuação de todos os requisitos registrados em um caso de uso e dividimos pelo número de requisitos. Ou seja, calculamos a pontuação média de cada caso de uso.

Todas as idéias de solução propostas pelo parlamento também foram classificadas, como Simples, de Média Complexidade e Complexas. Assumiremos aqui os valores 1, 2 e 3 pontos, respectivamente. Como a complexidade foi avaliada por vários especialistas, também calculamos a pontuação média. Pronto, agora temos as coordenadas que permitirão o posicionamento de cada idéia na matriz SMBP.

Todas as idéias que aparecerem no quadrante de “Sonho” devem ser consideradas. Todas são de fácil implementação e satisfazem requisitos que foram considerados fundamentais para o negócio. Podemos dizer que um projeto que só tem itens neste quadrante também é um projeto “dos Sonhos”. Pena que eles são raros. Existem também aquelas idéias cuja implementação é mais difícil. Como elas também representam alto valor para o negócio, as chamamos de “Mal Necessário”. Muito necessárias. Não podemos ignorá-las.

Já os dois quadrantes da parte inferior da matriz representam itens que devem ser muito questionados. As “bobeirinhas” um pouco menos, já que sua implementação é relativamente simples. Mas das idéias “Pesadelo” devemos fugir. Além de representar pouco ou nenhum valor para o negócio, são todas de implementação difícil. Como justificá-las?

Como eu disse, a ferramenta parece uma besteirinha. Mas é muito útil na tomada rápida de decisões. Permite que toda a equipe se concentre em itens que realmente fazem a diferença em um projeto. Didática, a própria matriz pode ser utilizada para justificar o escopo do projeto para um cliente. Permite também que se decida a meta de cada iteração ou o escopo de versões posteriores do produto em questão.

O parlamento, uma reunião que deve durar algo entre 1 e 4 horas, fornece bases para que o AN desenvolva a melhor proposta ou estudo possível. Respeita as inevitáveis restrições de custos e tempo – “é pra ontem!” – ao mesmo tempo em que elimina riscos e armadilhas. Não todos, é claro, mas é óbvio que a proposta ou estudo gerado é mais forte, melhor fundamentado.

É cara? Se comparada às propostas “bumba-meu-boi” e “balança-mágica” que algumas empresas elaboram, sim. Mas é um custo facilmente recuperado em um projeto que já começa em trilhos certos, sem desvios ou surpresas. E, claro, se estivermos falando de propostas comerciais, o método aqui sugerido aumenta consideravelmente as chances de vitória.

.:.

Notas:

1. Sim, *Especialistas*. Não coringas-especialistas-generalistas que chutam com as duas. Isso não tem nada a ver com Taylor e afins. O papo é cansativo, mas insistirei: é papo de Drucker, que diz que “conhecimento, por definição, é especializado“. Todo trabalhador do conhecimento (knowledge worker) busca (ou deveria buscar) a especialização. Como sou especialista em chatice, explorarei mais o tema em futuros artigos. A citação de Drucker eu tirei de “O Advento da Nova Organização”, artigo publicado na Harvard Business Review em 1988 (edição jan-fev).
2. Figura (indevidamente?) surrupiada do OpenUP (que não deveria ter Copyright).
3. Adoro nossa criatividade quando o assunto é a geração de propostas. O método “bumba-meu-boi” parece ser o default: um cara de vendas (ou pré-vendas) vai lá no cliente, se esforça para entender suas “dores”, volta correndo pra casa e se desdobra para traduzir aquilo tudo em cifras. Sim, porque a primeira coisa que seu chefe quer saber é o valor do projeto. “Bumba meu boi bumbá – é melhor alocar e cobrar por mês!!”, hehe.
   A “balança mágica”, como o nome confessa, é bem mais sofisticada. Ouvi dizer que uma grande empresa a utiliza. Na verdade, uma versão adaptada d’uma balança que um dia foi usada para pesar outro tipo de coisa ilícita. É de altíssima precisão. Joga lá a RFP e vê quanto deu: 127,34 gramas? Então o preço é R$ 400k, arredondado, e o projeto demorará 6 meses!! hehehe… Imprime até etiquetinha!

Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios que compõem o DEVAGAR:

D)emonstrar Valor de maneira Iterativa
Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura “ágil”, é o mesmo que dizer “entregamos software rodando” em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

E)ntender (e Melhorar) o Negócio
É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo ‘business-centric’ incentiva a busca por melhorias.

V)alorizar os Ativos de Software
Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

1. Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar… muito.
2. Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

A)daptar o Processo
Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia… por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

G)erenciar Requisitos (e Mudanças)
Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas “balancear prioridades dos stakeholders” não é o termo adequado. Parece até “forçada de barra” para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

A)tacar os Riscos
Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 , “se você não atacar os riscos, eles o atacarão”. O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

R)espeitar os Usuários
É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

Por tudo isso eu gostei do DEVAGAR. “DEVAGAR & SEMPRE”, como naquela fábula da tartaruga. Taí, já arrumei até mascote para o ‘business-centric’…

.:.

Notas:

1. Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são ‘intrusivos’. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
   O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
2. Object Solutions – Managing the Object-Oriented Project
   Grady Booch. Addison-Wesley (1996).

.:.

Para entender: quando lançado, eram apresentados como princípios (ou grupos de melhores práticas) do RUP :

1. Desenvolver software de maneira iterativa
2. Gerenciar Requisitos
3. Utilizar arquiteturas baseadas em componentes
4. Modelar o software
5. Verificar continuamente a qualidade dos artefatos gerados
6. Controlar mudanças

Com o tempo os princípios foram mudando. Em determinado momento, o “espírito do RUP” consistia em :

1. Atacar os grandes riscos o quanto antes, continuamente
2. Entregar valor para o cliente
3. Direcionar seus esforços para gerar software executável
4. Assimilar mudanças o quanto antes no projeto
5. Definir uma arquitetura o quanto antes
6. Construir o sistema com componentes
7. Trabalhar como uma equipe
8. Fazer da qualidade um modo de vida

A pressão do “Agile Manifesto” e por um processo menos “pesado” continuou, o que nos trouxe para o mais novo conjunto de princípios que, segundo Per Kroll e Bruce MacIsaac , norteiam tanto o RUP quanto o OpenUP. São eles:

• A)daptar o Processo;
• B)alancear Prioridades dos stakeholders;
• C)olaboração entre os times;
• D)emonstrar valor de maneira iterativa;
• E)levar o nível de abstração; e
• F)ocalizar continuamente a qualidade.

Este último conjunto seria, segundo seus criadores, “Business-Centric”, enquanto os dois anteriores, particularmente o primeiro, seria nitidamente “Architecture-Centric”. No grupo de discussão, respondendo ao Marcio Tierno e Rodrigo Yoshima, eu falei que não concordava com o rótulo “Business-Centric”. É um rótulo adotado pelos próprios criadores da lista de princípios. Se fosse um rótulo colocado por gente de fora, um consenso, tudo bem. Mas ao batizar suas idéias e sugestões de práticas de “business-centric”, os autores, imho, pesaram a mão. Eu disse que a lista parece mais “Agile-Manifesto-Centric”, enquanto o Tierno sugeriu “User-Centric”. Mas a crítica não basta.

Desde então ando pensando em quais seriam os princípios de um processo “Business-Centric” de verdade. Meus 7 cents:

• D)emonstrar valor de maneira iterativa
• E)ntender (e Melhorar) o negócio
• V)alorizar ativos de software
• A)daptar o processo
• G)erenciar requisitos (e mudanças)
• A)tacar os riscos
• R)espeitar os usuários

Ops… D.E.V.A.G.A.R…. não deve pegar muito bem. Talvez com sobrenome: “Devagar e Sempre!” hehe..

Mas, apesar do nome, gostei da idéia. No próximo post falo um pouco mais sobre cada princípio.

Bibliografia:

1. The Rational Unified Process – An Introduction
   Phillipe Kruchten. Addison-Wesley (2000 – 2ª Edição).
2. The Rational Unified Process Made Easy
   Phillipe Kruchten e Per Kroll. Addison-Wesley (2003).
3. Agility and Discipline Made Easy – Practices from OpenUP and RUP
   Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).