D.E.V.A.G.A.R.

Como apresentei no post anterior, DEVAGAR é um acrônimo para um conjunto de princípios que deveriam nortear um processo de desenvolvimento ‘business-centric’. Confesso, não deixa de ser uma provocação. E um contra-ponto ao ABCDEF que, segundo seus autores, seria ‘business-centric’. Na minha opinião, mais que ‘business-centric’, aquele conjunto de princípios – que, aliás, é muito legal – é mais ‘agile-manifesto-centric’ ou, em outras palavras, ‘developer-centric’.

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).

.:.