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 [1] 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.

Gerenciar 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 [2], "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).



.:.

Marcadores: , , ,

quinta-feira, 16 de agosto de 2007 | | Compartilhe: Adicionar esta notícia no Linkk

neste post

 

Anonymous Djalma Gomes, PMP disse:

Concordo que na entrada da era de aquarius, a integração é o lema. Por isto termos como SOA e globalização surgem muito fortes e profissões como "Relações com Investidores" e "Gerente de Relacionamento" também aparecem com força total.

A abordagem ágil é algo similar que vem propor justamente uma maior interação entre TI e usuários ou entre cliente e fornecedor.

Muito louvável, mas esquecem-se dos conflitos resultantes desta tentativa de integração. E quando os conflitos surgem, a reação automática é "Tirar da reta" com pérolas como "Não foi isto que eu disse" ou então "vc entendeu tudo errado". Formalizações e aprovações formais visam justamente reduzir este conflito.

Diz-se tambem que em TI, a equipe de projeto só descobre o que o usuário queria depois de entregar o que ele pediu. E o usuário só percebe o que ele realmente precisa depois de receber aquilo que ele queria. Enfim, há situações que um pouco mais de braimstorm e planejamento inicial pode-se economizar muito dinheiro mal gasto no futuro (esta é toda a tônica da técnica de Value Improvement Practice em gerenciamento de projetos).

Obviamente que há situações que não conseguimos um braimstorm eficiente no inicio e precisamos de ir definindo gradualmente o escopo detalhado ao longo do projeto. Neste contexto, pode-se usar a técnica de sprint, desde que bem gerenciado os conflitos comportamentais de algo "mal definido". Deve-se também ficar de olho naqueles recursos e usuários que adoram discutir o sexo dos anjos, mas não chegam a lugar algum. A definição de um escopo inicial detalhado pode reduzir este tipo de risco.

Em projetos grandes ou que competem por recursos, a abordagem ágil também pode conter grandes perigos. Sem uma gestão centralizada, corre-se o risco de 2 projetos ou sub-projetos simultaneos atualizarem o mesmo artefato ou programa. Nestas situações de muitos projetos, é vital termos uma gestão de configuração muito forte e para tanto, a abordagem waterfall pode ser mais interessante, desde que possivel (pois há situações em que Waterfall se torna impraticavel)

E por fim, gostaria de chamar a atenção de que gestão agil não existe (na minha modesta opinião). O PMBoK deixa aberto para usar de mais ou menos formalidade dependendo do projeto. Como projeto lida com pessoas e culturas, não há 2 projetos identicos. Em um projeto, eu posso ter maior necessidade de formalização e em outro pode ser o oposto.

O que estamos na verdade discutindo é o ciclo do projeto (e não o ciclo do gerenciamento de projetos), que em TI chamamos de SDLC. Dentro do SDLC, temos sim 2 abordagens diferentes que são Waterfall e Iterativo. Portanto não é adequado (na minha opinião) falarmos de gerenciamento ágil. Afinal, cada gerente deve definir a regra do jogo que é mais adequado ao seu contexto. Mais ou menos formalismo.

A ideia de um gerenciamento agil com equipes auto-gerenciaveis se assemelha ao ideal defendido por Thomas Morus em seu livro Utopia (descrevendo uma perfeita sociedade socialista). Mas até termos empresas com altissma maturidade e pessoas sem motivações pessoais (apenas motivações do grupo), penso que a presença de um gerente formal é fundamental. E este gerente deve ter responsabilidade (ou seja, accountability) de gerente. Os motivos pessoais sempre existem na grande maioria das pessoas (já dizia Maslow) e portanto, tecnicas de resolução de conflitos é um MUST em qualquer projeto. Sem um responsável mior pelo projeto, como ficaria a gestão dos conflitos?

Ufa, este comentário foi longo. Está aberto a descontrução (rs...)

 

Qual é a sua opinião?

A T E N Ç Ã O

Esta é uma versão antiga do finito. Só é mantida aqui porque o Google ainda direciona algumas buscas para cá. E eu seria louco se simplesmente o desativasse, certo? Mas, por favor, não deixe de visitar o finito certo. Todo o conteúdo aqui disponível está lá também.
  • Catálogo de Serviços

  • Contato Imediato

    • My status

    Assine & Compartilhe

    Busca

    Technorati


  • Temas & Tags

  • Lista completa no del.icio.us
  • Últimos Posts

  • Créditos & Débitos