Aplicando práticas de extreme Programming(XP) em equipes SW-CMM nível 2 Carlos Henrique Rodrigues Cardoso DCOM Departamento de Computação Instituto Nacional de Telecomunicações (Inatel) Av. João de Camargo, 510 37.470-000 Santa Rita do Sapucaí MG Brazil caique@inatel.br Abstract. The agile process s use has been growing in the latest year and some researches are being developed according to how to use the formal process for software development associated with the agile process [Paulk 2001]. This paper shows the practical application of the extreme Programming(XP) in evaluated teams with the officially CMM level 2, and the advantages and difficulties to using them simultaneously. Resumo. A utilização de processos ágeis vem crescendo nos últimos anos e algumas pesquisas estão sendo desenvolvidas no sentido de utilizar processos formais para desenvolvimento de software associado a técnicas de processos ágeis [Paulk 2001]. Este artigo apresenta a análise da aplicação de práticas de extreme Programming (XP) em equipes avaliadas oficialmente SW-CMM nível 2 e quais as vantagens e dificuldades de se utilizá-las simultaneamente. 1. Introdução O uso de processo de desenvolvimento de software para ajustar os níveis de qualidade do produto final são reconhecidos e utilizados por muitas empresas ao redor do mundo. O SW-CMM (Capability Maturity Model for Software) define 368 práticas chaves[paulk et. Al, 1995] e o XP define 12 práticas [Back, 1999]. Estudos tem sido feitos no sentido de permitir mapear as práticas de SW-CMM nível 2 e 3 para as práticas de XP[Koch, 2003]. A aplicação das práticas XP em empresas certificadas SW-CMM são complexas e nem sempre tem atingido sucesso[reifer, 2003]. Em [Campelo, 2003] foi apresentado um diagnóstico e um guia prático para utilizar XP em conjunto com CMM em nível 2 e apresenta um lista de problemas encontrados em compatibilizá-los; além disso houve grande dificuldade em aplicá-los em projetos reais. Em [Bonato, 2002] é feita uma comparação entre XP e CMM tomando como base as Key Process Area (KPAs). A conclusão é que XP atende a boa parte das KPAs dos níveis 2 e 3, porém sem fazer uma leitura muito rigorosa das mesmas. A definição de um processo que atenda a todas as práticas do SW-CMM para um pequeno grupo de desenvolvedores (grupo com 3 a 4 pessoas) é difícil e pode torná-lo pesado demais para ser utilizado no dia-a-dia. Para atender as áreas de processo chave do SW-CMM (KPAs) foi criado pela equipe do ICC Inatel Competence Center um processo chamado Modelo para Pequenos Grupos (MPG). A necessidade de gerências específicas para atender ao SW-CMM fez com que pessoas assumissem mais de um papel ao mesmo tempo. Os papéis são executados pelos especialistas de cada projeto em 45
desenvolvimento. Para se adequar as práticas de extreme programming o MPG foi modificado no que se refere a desenvolvimento de projeto, mais especificamente gerencia de requisitos, acompanhamento e planejamento. A definição de como realizar gerência de configuração e garantia da qualidade do MPG foram remodeladas. Este artigo irá apresentar o resultado destas mudanças e da aplicação das práticas de extreme programming em um grupo avaliado oficialmente SW-CMM nível 2 em dois projetos. Apresenta-se no tópico seguinte as características do modelo para pequenos grupos. Apresenta-se no tópico 3 as práticas do extreme programming adotadas no Modelo para Pequenos Grupos (MPG) e dados de planejamento e acompanhamento de projetos utilizando o MPG. Apresenta-se no tópico 4 as conclusões da pesquisa e novos trabalhos e finalmente o tópico 5 as referências bibliográficas utilizadas no desenvolvimento da pesquisa. 2. O Modelo para Pequenos Grupos (MPG) O Modelo para Pequenos Grupos foi criado para atender as KPAs do nível 2(com exceção da KPA de subcontratação) do SW-CMM em grupos de desenvolvimento de software composto de 3 a 4 especialistas. Em fevereiro de 2003 o Inatel foi avaliado no SW-CMM nível 2 e recebeu 100 % de pontos fortes. O MPG foi baseado no Rational Unified Process (RUP) em particular em relação a gerência de requisitos, planejamento e acompanhamento e gerência de configuração. A área de garantia da qualidade foi adicionada para atender a KPA respectiva. A figura 1 mostra o gráfico do RUP adaptado para o MPG, apresentando as fases e disciplinas. Figura 1. Fases do Modelo para Pequenos Grupos A gerência de configuração e a garantia da qualidade foram introduzidas nas fases de gerência de projeto de modo a permitir que o grupo de desenvolvimento fosse responsável por todos as atividades. A gerência de projeto (requisitos; planejamento e acompanhamento) compõem todo o ciclo de desenvolvimento do projeto e são afetadas pela adoção de práticas XP. Apresenta-se na figura 2 as disciplinas para gerência de projetos associado as fases de concepção, elaboração, construção e transição. A fase de negociação de projetos possui um ciclo de atividades totalmente diferente dos restante do processo. A fase de mudança de produto em garantia também possui uma seqüência 46
de atividades específicas e algumas vezes são negociadas com o clientes e adaptadas as necessidades. Figura 2. Disciplinas da Gerência de Projetos Mostra-se na figura 3 as atividades internas das fases de concepção, elaboração, construção e transição. As atividades são semelhantes para facilitar a execução e a adoção das práticas de XP. A principal modificação ocorrida no MPG foi a simplificação do processo interno de cada fase. A intenção é permitir a fácil compreensão das atividades e adequá-las às práticas de XP. Três documentos são amplamente utilizados durante o projeto: PDS Plano de Desenvolvimento do Sistema. Neste documento são registradas as ações de planejamento e acompanhamento do projeto, além de gerência de 47
riscos, configuração e mudança, e garantida da qualidade. Este documento é atualizado semanalmente a cada nova release do projeto. DS Documento de Sistema. Este documento apresenta todos os dados do projeto, incluindo requisitos, diagrama de componentes, diagrama de dados, diagrama de classes, diagrama de seqüência, entre outros. PE Planilha de Estimativa. Esta planilha é responsável pelo cálculo das estimativas de tamanho, esforço, cronograma, custo e risco. Serve de base para a estratégia do projeto no que se refere a gerência de riscos e arquitetura a ser adotada. Figura 3. Atividades internas das fases de concepção, elaboração, construção e transição. 48
A verificação de final de fase é feita em uma revisão formal para registro das atividades da fase e acompanhamento macro das ações a serem adotadas na fase seguinte. Os papéis que executam as atividades são: GDS Gerência de Desenvolvimento de Sistema GGQ Grupo da Garantia da Qualidade GD Grupo de Desenvolvimento GCM Grupo de Configuração e Mudança LP Líder de Projeto A menos da GDS, todos os outros grupos são compostos por especialistas em desenvolvimento de software que a cada ciclo assumem diferentes papéis, no sentido atender as necessidades específicas de cada disciplina. A interação tem duração de uma semana, na maioria dos projetos, e inicia-se com o planejamento da interação. No mesmo momento do planejamento é feita a revisão e o acompanhamento a partir da primeira interação. Estas duas atividades duram algumas horas e não tem impacto no desenvolvimento da fase. As atividades de modelagem, documentação, desenvolvimento e testes são feitas em pequenos ciclos diários e os especialistas trabalham em ambientes que permitem a troca constante de informações. 3. Práticas XP adotadas no Modelo para Pequenos Grupos O uso de papéis, valores e práticas foram adicionadas ao MPG a fim de produzir um processo aderente ao SW-CMM, porém mais ágil e atendendo às necessidades de desenvolvimento de pequenos grupos com requisitos que mudam constantemente. A seguir são apresentadas cada uma das práticas e a caracterização da adoção em equipes avaliadas SW-CMM nível 2. O cliente/usuário esta sempre disponível: Infelizmente nem sempre é possível ter os clientes/usuários disponíveis. Porém, esta é uma das práticas mais importantes e o planejamento e acompanhamento do sistema são sempre disponibilizados na página da internet do projeto. Em todas as reuniões semanais de acompanhamento e planejamento a responsável pela garantida da qualidade e pela administração do projeto assume o papel de ombudsman. Metáforas: O uso de metáforas é utilizado principalmente na definição da arquitetura dos sistemas. Por exemplo: O sistema de coleta de dados na produção deve funcionar como medidores em aquedutos, com todas as possibilidades de ramificações. Planejando o Jogo: O planejamento semanal previa a definição de atividades a serem desenvolvidas e definição da melhor estratégia a ser utilizada para atender 49
ao desenvolvimento. Foi mantido um planejamento de nível mais alto para acompanhamento das fases e o planejamento semanal das atividades. Releases Pequenas:A cada semana uma realease foi disponibilizada na forma online para avaliação do cliente. Estas releases eram acompanhadas pelos clientes sem uma periodicidade definida. Testes de Aceitação: Foram desenvolvidos testes de aceitação e implementados testes automáticos antes da entrega de cada versão(release) ao cliente. Projeto Orientado a Testes: Para todos os componentes foram desenvolvidos testes unitários automáticos que eram executados a cada release e durante a integração dos componentes. Integração Contínua: No início a integração dos componentes eram semanais e passaram a ser dirárias no final do desenvolvimento. Projeto Simples: Desde a definição da arquitetura foi adotado a simplicidade do projeto. Uso de patterns foi adotado para facilitar a compreensão da arquitetura. Refactoring: Foi incentivado o refactoring sempre que a implementação do código necessitasse. A arquitetura foi avaliada durante o desenvolvimento do projeto e decisões de alteração eram tomadas quando necessário, porém avaliando-se o impacto das mudanças. Programação aos Pares: Um ambiente que propiciasse a troca constante de informações durante o desenvolvimento foi criado para os especialistas. A programação aos pares foi realizada em determinadas etapas da codificação. Revezamento de Duplas: O revezamento foi possível no terço final do projeto. Todos são proprietários do Código: A responsabilidade de todo o código foi compartilhada pelos especialistas. O código sempre esteve disponível e os especialistas foram incentivados a discutir sobre as soluções de codificação adotadas. Padrão de Codificação: Foram definidas normas de codificação para facilitar o compartilhamento do código e a revisão. A revisão do código foi feita por amostragem e sempre que necessário solicitado que fosse feito o refactoring do código. 40 horas semanais: Em nenhuma etapa do desenvolvimento foi necessário trabalho fora do horário. As práticas foram aplicadas em dois projetos: Projeto Horus: Sistema de missão crítica para gestão de chão de fábrica, responsável pela aquisição dos dados de produção e pelo controle do produção de empresas de manufatura. Inclui gestão de dados em tempo real. 50
Projeto Hathor: Sistema de gestão pública, desenvolvido para atender as necessidades de prefeituras. O primeiro módulo do Hathor desenvolvido foi o Financeiro que compreende as gerências de ISS e IPTU. Tabela 1. Comparativo dos Projetos Tópico Hathor Horus Classes 237 632 Linhas de Código 34091 59421 Tabelas 45 42 Telas 90 95 Especialistas 3 4 Cronograma Janeiro a Junho de 2004 Janeiro a Outrbro de 2004 A tabela 1 apresenta um comparativo entre tópicos dos projetos. Os projetos atenderam as estimativas e apesar das mudanças de requisitos dos projetos, não houve impacto significativo de tamanho, custo, cronograma e esforço. A tabela 2 apresenta o percentual de esforço em cada atividade durante o desenvolvimento de cada um dos projetos. Considerando as atividades diretas de projeto, ou seja, modelagem, implementação e teste os recursos no projeto Hathor foram de 69,2 % e no projeto Horus de 71,5 %. Apesar de seguir um processo definido baseado no nível 2 do SW-CMM aproximadamente 70 % do esforço foi dedicado as atividades diretas de projeto. Tabela 2. Esforço por atividade nos dois projetos Atividade Esforço Projeto Hathor (%) Esforço Projeto Horus (%) Acompanhamento 2,3 2,7 Atividades Gerais 4,6 8,0 Configuração 0,6 0,1 Documentação 8,3 4,6 Estudo 6,3 7,1 Instalação do Ambiente 3,3 2,2 Implementação 49,2 62,9 Modelagem 5,7 6,3 Planejamento 2,2 0,2 Qualidade 2,2 1,1 Requisitos 1,1 2,5 Teste 14,3 2,3 Total 100 100 51
4. Conclusões O desenvolvimento de software não é uma atividade trivial. A experimentação de novas técnicas e paradigmas permite que se possa melhorar sempre. O que ocorreu de mais importante durante o desenvolvimento deste trabalho foi a motivação e o envolvimento da equipe. Os especialistas se sentiram a vontade para desenvolver e isso foi fundamental para o sucesso do desenvolvimento. O padrão SW-CMM define boas práticas, o que se deve fazer. O extreme programming apresenta práticas que aproximam as pessoas da equipe e facilitam o relacionamento, e trata da forma como se pode fazer. Não se trata da solução de todos os problemas de desenvolvimento mas facilita muito o processo. Algumas empresas utilizam processos com a intenção de evoluir o projeto independente das pessoas, ou seja, em caso de necessidade a documentação daria subsidio para a mudança na equipe. Esta pesquisa permitiu constatar é que esse não é o melhor caminho. O entrosamento, relacionamento e troca de informações esta no centro do sucesso de desenvolvimento de projetos de software. Muito trabalho ainda precisa ser feito, em especial em relação ao gerenciamento automatizado do projeto, métricas que permitam uma forma mais apurada de estimativa e que permitam desde o início a definição de prazos e custos, tão necessários aos clientes. Para que o uso das práticas de XP fossem utilizadas foi necessário alterações no MPG para torna-lo mais ágil. A adoção não comprometeu as necessidades formais de gerenciamento de projeto para o atendimento ao nível 2 do SW-CMM. A Gerência de Configuração e Garantia da Qualidade foram remodeladas para atender a agilidade da nova versão do MPG. Semanalmente foram geradas baselines de artefatos utilizados no projeto e realizadas medições e análises para a tomada de decisão. Algumas definições que não são utilizadas em XP foram adotadas, como por exemplo documentação formal. O passo seguinte será passar a criar os documentos diretamente para serem apresentados online, isso irá agilizar a documentação e a publicação dos documentos. Um outro trabalho futuro será o desenvolvimento de uma ferramenta de gerenciamento de projetos que utilizem técnicas vindas de processos ágeis e de suporte a gestão do projeto sem ferir a agilidade conquistada pelo processo. Esta ferramenta integrará toda a gerência já em concordância com o CMMI níveis 2 e 3. A adoção de práticas ágeis podem ter inserido alguns pontos fracos no MPG em relação a uma avaliação formal mas sem comprometer a avaliação formal desta nova versão. Um trabalho no sentido de gerar mais formalismo ao MPG poderia torna-lo novamente 100% em concordância com o CMM nível 2. 5. Referências Back, Kent, Extreme Programming Explained: Embrace Change, Addison Wesley Professional, 1999. 52
Koch, Alan, (2003) SW-CMM Compliant XP, http://www.askprocess.com/articles/sw-cmm-xp.pdf. (último acesso em 15/08/2004). Paulk, Mark C. et. al., The Capability Maturity Model: Guidelines for Improving the Software Process, Addison Wesley, 1995. Paulk, Mark C. (2001) Extreme Programming from a SW-CMM perspective, IEEE Software, November/December 2001, p. 1-8. Reifer, Donald. J., (1995) XP and the SW-CMM, IEEE Software, May/June 2003, p. 14-15. Campelo, Renata E. C., XP-CMM2: Um guia para Utilização de Extreme Programming em um Ambiente Nível 2 do CMM, Dissertação de Mestrado Universidade Federal de Pernanbuco, Novembro 2003 Bonato, A., Extreme Programming e Qualidade de Software, http://www.xispe.com.br/evento2002/index2.html (último acesso em 31/08/2004), Extreme Programming Brasil, Dezembro 2002 53
54