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:
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:
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:
- 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.
- 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.
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:
- 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. - Object Solutions - Managing the Object-Oriented Project
Grady Booch. Addison-Wesley (1996).
.:.
Marcadores: engenharia_de_processos, openup, princípios, rup
quinta-feira, 16 de agosto de 2007 |
Assine o finito
Lista completa no del.icio.us
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...)