Estudo de Caso Sobre a Aplicação de Metodologia Ágil

Transcrição

1 Estudo de Caso Sobre a Aplicação de Metodologia Ágil Nery Signorini Neto Instituto de Pesquisas Tecnológicas do Estado de São Paulo Avenida Prof. Almeida Prado, 532. Prédio 56 São Paulo SP Brasil nery.signorini@mac.com Abstract. Case study of a software development process used in an organization compared to the processes and agile methods, such as the OpenUp. In the organizational context there is a dependency between the process of development with other processes and methodologies that other joints strengthen the management of the projects of software development. Resumo. Estudo de caso de um processo de desenvolvimento de software utilizado em determinada organização em comparação aos processos e métodos ágeis, como o OpenUp. No contexto organizacional há uma dependência entre o processo de desenvolvimento com outros processos e outras metodologias que juntas fortalecem o gerenciamento dos projetos de desenvolvimento de software. Introdução Este estudo de caso tem como objetivo a análise do processo de desenvolvimento de software utilizado na empresa XYZ Acme à luz das metodologias ágeis, neste caso especificamente, o OpenUp. O estudo conduzido analisará o processo existente denominado MDS, 17 projetos executados no período de Jan/2006 a Dez/2007 e um segundo processo, uma instância criada a partir do processo OpenUp denominado neste estudo como Open-MDS. Serão analisados todas as características individuais de cada processo, suas particularidades e complexidades dentro da organização estudada. Um segundo objetivo é identificar uma co-relação de possíveis dependências entre os demais processos e outras metodologias que interagem junto à qualquer processo de desenvolvimento de software. Contextualização da Empresa A empresa analisada é uma grande multinacional americana, presente em diversos países ao redor do mundo. No Brasil, ela atua no ramo de refrigerantes (beverages), produtos alimentícios (foods) e salgadinhos (snacks). A empresa é composta por diversas BU-Business Units independentes e com total autonomia para desenvolvimento de padrões próprios e de contratações para a área da Tecnologia da Informação (TI). Possui pouca interação com outras BU s na região LA (Latin America). O contexto analisado neste estudo de caso é baseado na primeira versão de uma metodologia de desenvolvimento de sistemas, denominada neste artigo como MDS, que foi criada por parceiro local e cuja implantação se deu durante o ano de 2005 e

2 primeiro trimestre de A metodologia desenvolvida deveria servir também para ser utilizada no gerenciamento de projetos em geral, para controle de mudanças, para o gerenciamento da qualidade dos artefatos de software e para o controle da versão dos programas criados e ou modificados. Problemas Existentes na Organização Abaixo estão relacionados os principais problemas e dificuldades encontrados na organização no período analisado para este artigo. Havia 4 diferentes fábricas de software contratadas, cada qual responsável por um sistema ou grupo de sistemas e interfaces menores. Cada fábrica mantinha seus próprios padrões de desenvolvimento de software independentes umas das outras. Não existia internamente qualquer padrão, seja para o desenvolvimento de software, para modelagem de dados, eliciação de requisitos funcionais e não funcionais, documentação dos artefatos ou decisões arquiteturais. Devido a fusões, existiam na empresa 3 ERPs 1 (Sistemas: FAS, TRUCK e MFGPRO) que funcionavam em paralelo e que suportavam grandes partes do negócio. (Na Figura 1 Mapa de interfaces e de sistemas na empresa XYZ Acme, os ERPs estão identificados na cor Verde). Os cadastros de produtos, denominados SKUs 2, eram descentralizados; os produtos eram incluídos em qualquer dos ERPs existentes. Os cadastros básicos do sistema, denominados Masterfiles, eram uma entidade separada dos demais sistemas. Sua consistência e integridade eram mantidas através da grande quantidade de interfaces de atualização e transformação (ETL 3 ) executadas diariamente. Inexistência de documentação atualizada dos sistemas contribuía para a falta de conhecimento das equipes responsáveis pela manutenção e suporte, gerando perda de agilidade e acuidade no tratamento de problemas. Manutenções simples acabavam se transformando em grandes projetos de atualizações. Devido a complexidade e do alto grau de acoplamento entre as aplicações, era comum a necessidade de atualizações em dados (updates manuais em tabelas) durante o processamento, especialmente no processamento de fechamento mensal. Segundo auditoria realizada internamente, a maturidade dos processos foi avaliada em - Nota Geral: 1,3. Os graus de avaliação variam do grau mais baixo 1 ao grau mais alto 5 conforme indicado pelo CMM/CMMI 4, definido a seguir: 1 Caótico, 2 Repetitivo, 3 Definido, 4 Controlado e 5 Otimizado). Mapa Visual dos Sistemas e Interfaces Existentes 1 ERP Enterprise Resource Planning São os sistemas de informação das empresas. 2 SKU - Stock Keeping Unit, Unidade de manutenção de estoque. 3 Extract Transform Load - Extração Transformação de Dados. 4 CMM/CMMI Capability Maturity Model Integration- São modelos de maturidade de processos.

3 Figura 1 Mapa de interfaces e de sistemas na empresa XYZ Acme Analisando a MDS Existente A empresa estudada possui uma Metodologia de Desenvolvimento de Sistema (MDS 5 ) própria, implementada durante o ano de 2005 e no começo de 2006 e foi desenvolvida junto a parceiros comerciais com o objetivo de organizar os processos internos utilizados para o desenvolvimento e gerenciamento de projetos de software. A metodologia desenvolvida não se restringia apenas aos processos inerentes ao desenvolvimento, manutenção e evolução de sistemas ou artefatos de software. A MDS criada possuía também uma série de artefatos adicionais importados de outras metodologias, como por exemplo: Gerenciamento de escopo, Project charter, Plano geral do projeto e WBS adotadas do PMI PMBoK [PMI]; Gerenciamento de mudanças, ITIL - CAB - Change Advisory Board e CMDB [ITIL]; Processo de qualidade, Data Quality Assurance, Software Quality Assurance, Sarbanes & Oxley [SOX] e outros Processos e Auditorias Internas 6. Neste caso, a MDS foi expandida muito além de suas habituais fronteiras do desenvolvimento de software, para poder atender outras demandas internas da área de Tecnologia da Informação, como por exemplo: auditorias, controles operacionais, versão de documentos e para o gerenciamento de projetos de desenvolvimento. A adoção pela MDS de controles adicionais oriundos de outras metodologias gerou um total de 81 artefatos reutilizados entre os diversos fluxos e fases existentes. Os artefatos estão divididos em 54 mandatórios e 27 facultativos. 5 MDS Nome comum para Metodologia de Desenvolvimento de Sistema, esse acrônimo foi adotado como sendo o nome oficial da metodologia da Companhia e neste artigo. 6 Auditorias Internas são os controles de governança obrigatórios.

4 A MDS é composta por 3 processos principais (Desenvolvimento Principal, Desenvolvimento Emergencial e Fluxo de Aquisição), 7 sub-processos menores (Anteprojeto, Análise, Projeto, Codificação, Homologação, Aguardando Implantação e Implantação). Visão dos fluxos e fases da MDS Tabela 1: Relação de fases, processos e sub-processos e total de artefatos Visão geral dos artefatos no Fluxo de Desenvolvimento Principal. Tabela 2: Divisão dos artefatos por Fases Descrição das fases de um projeto de desenvolvimento 7 artefatos: com seus principais 1) Fase de Anteprojeto: Fase inicial do projeto de desenvolvimento de software, onde todos os requisitos funcionais e não-funcionais são identificados e registrados pelos usuários chaves, gerentes e patrocinadores do projeto. 2) Fase de Análise: É criado o desenho da solução que será desenvolvida, algumas decisões arquiteturais começam a ser levantadas e compreendidas, são tomadas todas as decisões inerentes ao escopo e da arquitetura do sistema. 3) Fase de Projeto: É a fase onde se inicia o projeto de desenvolvimento propriamente dito, os recursos são alocados pelo parceiro comercial (fábrica de software) contratada e/ou alocados internamente entre as áreas usuárias. 7 Somente estão descritos neste artigo os artefatos que são mandatórios dentro da MDS.

5 4) Fase de Codificação: É a construção das linhas de códigos do novo software, o produto está sendo desenvolvido/codificado pela fábrica de software. 5) Fase de Homologação: Teste de todos os requisitos funcionais que foram registrados na fase de Anteprojeto. Todo os artefatos deverão ser validados e aprovados pelo usuário final. 6) Fase de Aguardando Implantação: Será solicitada a revisão de todos os artefatos gerados durante o projeto ante da implantação. Estes artefatos serão validados e aprovados pelos responsáveis pela qualidade e auditoria na área de TI e de Negócio. 7) Fase de Implantação: O novo sistema será implantado e disponibilizado ao cliente final. Durante o estudo de caso foi levado em consideração apenas o fluxo de desenvolvimento principal, identificado como Desenvolvimento de Software Principal que é o mais completo e o mais utilizado entre todos os fluxos existentes. Devido a grande quantidade de artefatos mandatórios, os demais fluxos acabaram sendo incorporados pelo fluxo aqui comentado e acabaram caindo em desuso dentro da organização. Análise e Coleta das Informações O procedimento de coleta para este estudo de caso foi baseado no processo de desenvolvimento utilizado e na análise de 17 projetos executados e estudados baseados no método de análise de Complexidade x Incertezas [Little]. As ações se resumem nas coletas e nas análises dos documentos existentes dos projetos incluindo: escopos, cronograma, realizações/entregas, fases, problemas encontrados, lições aprendidas, ações corretivas e a sensação de usuários, técnicos e gestores que participaram dos projetos. Processo de Análise: 1) Análise do contexto organizacional da empresa, levando em consideração a maturidade de outros processos e controles que interagem com o fluxo de desenvolvimento de software. 2) Análise em detalhes da metodologia de desenvolvimento de sistemas (MDS) utilizada pela empresa, incluindo os fluxos e fases de desenvolvimento e todos os artefatos propostos na metodologia. 3) Estudo dos artefatos mandatórios e obrigatórios determinando sua real importância ao processo de desenvolvimento. Os artefatos oriundos de outros processos e outras metodologias foram identificados e separados, permitindo assim a mesma base de informação para a análise comparativa entre a metodologia utilizada (primeiro estudo) e a nova metodologia proposta (segundo estudo). 4) Foram analisados 17 projetos de desenvolvimento de software durante o período de Jan/2006 a Dez/2007. A comparação entre as metodologias foi baseada nos métodos ágeis, especificamente o OpenUp.

6 Comparativo entre MDS e OpenUp Cada projeto tem aspectos e características únicas, e estes fatores determinam qual será o processo mais adequado a ser adotado, ou seja, um processo mais formal ou mais ágil. Entre esses fatores existentes, podemos considerar a localização, o tamanho das equipes, a complexidade da arquitetura utilizada, cronogramas/prazos, riscos, complexidades e incertezas que envolvem o projeto. Invariavelmente uma boa metodologia de desenvolvimento de sistemas adequada à realidade e a maturidade da organização, contribui fortemente para o sucesso dos projetos de desenvolvimento e manutenção dos artefatos de software. O OpenUp [ECLIPSE] é um processo de desenvolvimento de software, baseado nos princípios ágeis descritos no Manifesto Ágil [Agile], (veja Tabela 3 Relação entre Princípios OpenUp e Princípios Ágeis). Sua estrutura provê total sustentação para o desenvolvimento, teste e entrega de sistemas e também possui uma estrutura maleável que se adaptará as necessidades de cada organização ou de cada projeto, seja da inclusão de novos controles, artefatos ou interações, inclusive com outros processos existentes dentro da organização. Exemplo: Gerenciamento de Projetos, ITIL, SOX, Auditorias internas ou outros controles que sejam necessários ou impostos pela organização. Essa característica facilita sua utilização e adaptação. Princípios do OpenUp e seus Respectivos Princípios do Manifesto Ágil Tabela 3 Relação entre Princípios OpenUp e Princípios Ágeis [Lyons] A estrutura do OpenUp é formado por camadas, 1 - Micro-Increment; 2 - Iteration LifeCycle e 3 - Project LifeCycle [Cockburn]. Micro-Increment: É o nível das equipes de trabalho, aonde os recursos contribuem no desenvolvimento e na conclusão das atividades (tasks), por meio de realizações e entregas. É a realização das tarefas identificadas. Iteration LifeCycle: Tem atenção especial ao processo de iteração entre todas as tarefas, provendo uma visão normalmente semanal das atividades que deverão ser iniciadas. Tem o objetivo de manter as engrenagens funcionando, criando um fluxo contínuo de produtos criados, testados e aceitos pelos sponsors e stakeholders. Project LifeCycle: É composta pelas fases de desenvolvimento e planejamento do projeto, provê aos sponsors e stakeholders uma visão ampla do projeto, clareza, transparência, controles para riscos, gastos (budget/founding) e do escopo do projeto.

7 O OpenUp possui 2 tipos de dimensões: Method Content (que define o que será entregue, como por exemplo: tarefas, regras, artefatos, guias e etc) e Process Content (determina quando serão entregues os artefatos, ou seja, sua execução/realização no tempo). O processo é constituído de 4 fases, denominado OpenUp LifeCycle. Sendo elas: (1 - Inception Phase, 2 - Elaboration Phase, 3 - Construction Phase, 4 - Transition Phase). Abaixo, estão relacionados todas as fases, elementos e os objetivos a serem alcançados por cada fase. Fases e Iterações do processo de desenvolvimento de software Figura 2 OpenUp LifeCycle Process Abaixo, estão relacionados todas as fases e sub-fases das iteração do OpenUp, incluindo as atividades e objetivos a serem alcançados dentro da cada fase. Tabela 4 Descrição das fases e objetivos [Balduino] Open-MDS Instância criado a partir do OpenUp No estudo de caso realizado, a falta de processos que suportam o desenvolvimento de sistemas contribui para o aumento da complexidade e da probabilidade de insucesso dos projetos de desenvolvimento de software.

8 Com a implementação de novos controles e o consequente aumento da maturidade dos processos já existentes, a MDS pode ser gradualmente migrada para o modelo de processo proposto pelo OpenUp. A Open-MDS é uma instância derivada a partir da MDS com base nos princípios ágeis do OpenUp. O novo processo é mais rápido e maleável podendo ser completamente adaptada as regras da organização que a utiliza. Abaixo um comparativo das fases e artefatos entre os 2 processos. Comparativo das Fases e Artefatos do OpenUp e equivalentes na MDS Tabela 5 Comparativo entre OpenUp e seus Artefatos e Fases da MDS Análise de projetos sob a MDS Para o estudo de caso, os projetos foram classificados e pontuados conforme os critérios definidos no estudo sobre gerenciamento de complexidades e incertezas em projetos ágeis [Little]. Para a análise da Complexidade foram analisados os seguintes critérios: 1 - Team Size; 2 - Mission Criticality; 3 - Team location; 4 - Team capacity; 5 - Domain knowledge gaps; 6 - Dependencies. Para a análise das Incertezas, 4 critérios foram analisados: 1 - Market uncertainty; 2 - Technical uncertainty; 3 - Project duration; 4 - Dependencies scope flexibility.

9 Resultados Obtidos da Análise dos Projetos Figura 3 Projetos Gerenciados pela MDS Entendimento do resultado: 4 projetos (24%) foram classificados como sendo do tipo: Bulls pelo alto grau de complexidade e de incertezas que os envolviam. Os demais projetos 13 permaneceram nos quadrantes inferiores (76%), porém com alto grau de complexidade representando: Cows com 2 (15%) e Dogs com 11 (85%). Projeção do Estudo sob a Ótica do Processo Proposto Foi realizado um segundo estudo com as mesmas informações de entrada, mas com a alteração do processo de desenvolvimento de software da MDS para a Open-MDS. Este segundo estudo é apenas uma projeção dos possíveis resultados obtidos a partir da utilização de uma segunda metodologia mais Ágil, neste caso do OpenUp. Projeção dos resultados Figura 4 Projeção para Projetos Gerenciados pela Open-MDS Entendimento: Com base no novo processo de desenvolvimento, temos agora apenas 1 projeto classificado como Bulls que representa 6% do total de projetos. Para o quadrante imediatamente inferior, temos 2 projetos classificados como Cows, ou seja,

10 12% do total de projetos. Os demais projetos foram deslocados para o quadrante com menor complexidade e menor incertezas, com 14 projetos do tipo Dogs com 82%. Conclusão O estudo de caso aponta uma forte dependência entre o processo de desenvolvimento de sistemas analisado neste documento com outros processos corporativos, como por exemplo: procedimentos operacionais, auditorias internas, SOX e outros processos de governança instituídos e também com outras metodologias como: Gerenciamento de Projetos [PMI] e Gerenciamento de infraestrutura - ITIL [ITIL]. A falta de outros processos e controles bem definidos e maduros, gerou uma sobrecarga no número total de artefatos obrigatórios e das aprovações requeridas da MDS, tornando-a extensa, complexa e de difícil gerenciamento. Na análise da Figura 4 Projetos Gerenciados pela MDS, a complexidade da metodologia causou o deslocamento da maioria dos projetos analisados para os quadrantes com maior dificuldade de gerenciamento, ou seja, para os quadrantes Dogs/Cows e Bulls. Todos os projetos, por mais simples que fossem, se tornaram complexos, lentos e com maior probabilidade de insucesso. Já na Figura 5 Projeção para Projetos Gerenciados pela Open-MDS, onde há menor complexidade e maior agilidade, a maioria dos projetos ficaram no quadrante Dogs, mais facilmente controlados e com maior probabilidade de sucesso. Referências Bibliográficas [PMI] PMI Project Management Institute. Project Management Body of Knowledge. PMBok 3 rd. [ITIL] ITIL Information Technology Infrastructure Library [SOX] The Sarbanes-Oxley Act of 2002 (Pub.L , 116 Stat. 745, enacted July 30, 2002) [Little] Little, T. et al - Adaptive Agility - Managing Complexity and Uncertainty by Little, T., Greene, F., Phillips. T.,Pilger, R. and Poldervaart, R.. Agile Software Development Conference, June [ECLIPSE] Eclipse Process Framework project: [Agile] Manifesto for Agile Software Development: Agile Manifesto: [Lyons] Lyons, B.: The Open Unified Process: A Brilliant, Collaborative March into Open Source - Manifesto: [Cockburn] Agile Software Development, Cockburn, Alistair. Addison Wesley, [Balduino] Balduino, R. Paper - Introduction to OpenUP (Open Unified Process). Agosto, 2007.