2004 - aplicando pr ticas de extreme programming (xp) em equipes sw-cmm n¡vel 2

45

VI Simpósio Internacional deMelhoria de Processos de Software

São Paulo, SP – Brasil 24-26/11/2004www.simpros.com.br

Aplicando práticas de eXtreme Programming(XP) emequipes 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 – [email protected]

Abstract. The agile process’s use has been growing in the latest year and someresearches are being developed according to how to use the formal process forsoftware development associated with the agile process [Paulk 2001]. Thispaper shows the practical application of the eXtreme Programming(XP) inevaluated teams with the officially CMM level 2, and the advantages anddifficulties to using them simultaneously.

Resumo. A utilização de processos ágeis vem crescendo nos últimos anos ealgumas pesquisas estão sendo desenvolvidas no sentido de utilizar processosformais para desenvolvimento de software associado a técnicas de processoságeis [Paulk 2001]. Este artigo apresenta a análise da aplicação de práticasde eXtreme Programming (XP) em equipes avaliadas oficialmente SW-CMMní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 qualidadedo 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áticaschaves[Paulk et. Al, 1995] e o XP define 12 práticas [Back, 1999]. Estudos tem sidofeitos no sentido de permitir mapear as práticas de SW-CMM nível 2 e 3 para as práticasde XP[Koch, 2003]. A aplicação das práticas XP em empresas certificadas SW-CMMsã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 comCMM 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 ProcessArea (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 umpequeno grupo de desenvolvedores (grupo com 3 a 4 pessoas) é difícil e pode torná-lopesado demais para ser utilizado no dia-a-dia. Para atender as áreas de processo chavedo SW-CMM (KPAs) foi criado pela equipe do ICC – Inatel Competence Center umprocesso chamado Modelo para Pequenos Grupos (MPG). A necessidade de gerênciasespecíficas para atender ao SW-CMM fez com que pessoas assumissem mais de umpapel ao mesmo tempo. Os papéis são executados pelos especialistas de cada projeto em

46



desenvolvimento. Para se adequar as práticas de extreme programming o MPG foimodificado no que se refere a desenvolvimento de projeto, mais especificamentegerencia de requisitos, acompanhamento e planejamento. A definição de como realizargerê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áticasde extreme programming em um grupo avaliado oficialmente SW-CMM nível 2 emdois projetos.

Apresenta-se no tópico seguinte as características do modelo para pequenosgrupos. Apresenta-se no tópico 3 as práticas do extreme programming adotadas noModelo para Pequenos Grupos (MPG) e dados de planejamento e acompanhamento deprojetos utilizando o MPG. Apresenta-se no tópico 4 as conclusões da pesquisa e novostrabalhos e finalmente o tópico 5 as referências bibliográficas utilizadas nodesenvolvimento da pesquisa.

2. O Modelo para Pequenos Grupos (MPG)

O Modelo para Pequenos Grupos foi criado para atender as KPAs do nível 2(comexceção da KPA de subcontratação) do SW-CMM em grupos de desenvolvimento desoftware composto de 3 a 4 especialistas. Em fevereiro de 2003 o Inatel foi avaliado noSW-CMM nível 2 e recebeu 100 % de pontos fortes. O MPG foi baseado no RationalUnified Process (RUP) em particular em relação a gerência de requisitos, planejamentoe acompanhamento e gerência de configuração. A área de garantia da qualidade foiadicionada para atender a KPA respectiva. A figura 1 mostra o gráfico do RUP adaptadopara 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 nasfases de gerência de projeto de modo a permitir que o grupo de desenvolvimento fosseresponsável por todos as atividades. A gerência de projeto (requisitos; planejamento eacompanhamento) compõem todo o ciclo de desenvolvimento do projeto e são afetadaspela adoção de práticas XP. Apresenta-se na figura 2 as disciplinas para gerência deprojetos associado as fases de concepção, elaboração, construção e transição. A fase denegociação de projetos possui um ciclo de atividades totalmente diferente dos restantedo processo. A fase de mudança de produto em garantia também possui uma seqüência

47



de atividades específicas e algumas vezes são negociadas com o clientes e adaptadas asnecessidades.

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 aadoção das práticas de XP. A principal modificação ocorrida no MPG foi asimplificação do processo interno de cada fase. A intenção é permitir a fácilcompreensã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 registradasas ações de planejamento e acompanhamento do projeto, além de gerência de

48



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 doprojeto, 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 dasestimativas de tamanho, esforço, cronograma, custo e risco. Serve de base para aestratégia do projeto no que se refere a gerência de riscos e arquitetura a seradotada.

Figura 3. Atividades internas das fases de concepção, elaboração, construção etransição.

49



A verificação de final de fase é feita em uma revisão formal para registro dasatividades da fase e acompanhamento macro das ações a serem adotadas na faseseguinte.

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 emdesenvolvimento de software que a cada ciclo assumem diferentes papéis, no sentidoatender as necessidades específicas de cada disciplina. A interação tem duração de umasemana, na maioria dos projetos, e inicia-se com o planejamento da interação. Nomesmo momento do planejamento é feita a revisão e o acompanhamento a partir daprimeira interação. Estas duas atividades duram algumas horas e não tem impacto nodesenvolvimento da fase. As atividades de modelagem, documentação,desenvolvimento e testes são feitas em pequenos ciclos diários e os especialistastrabalham 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 umprocesso aderente ao SW-CMM, porém mais ágil e atendendo às necessidades dedesenvolvimento 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 emequipes avaliadas SW-CMM nível 2.

• O cliente/usuário esta sempre disponível: Infelizmente nem sempre é possível teros clientes/usuários disponíveis. Porém, esta é uma das práticas maisimportantes e o planejamento e acompanhamento do sistema são sempredisponibilizados na página da internet do projeto. Em todas as reuniões semanaisde acompanhamento e planejamento a responsável pela garantida da qualidade epela administração do projeto assume o papel de ombudsman.

• Metáforas: O uso de metáforas é utilizado principalmente na definição daarquitetura dos sistemas. Por exemplo: “O sistema de coleta de dados naprodução deve funcionar como medidores em aquedutos, com todas aspossibilidades de ramificações.

• Planejando o Jogo: O planejamento semanal previa a definição de atividades aserem desenvolvidas e definição da melhor estratégia a ser utilizada para atender

50



ao desenvolvimento. Foi mantido um planejamento de nível mais alto paraacompanhamento das fases e o planejamento semanal das atividades.

• Releases Pequenas:A cada semana uma realease foi disponibilizada na formaonline para avaliação do cliente. Estas releases eram acompanhadas pelosclientes sem uma periodicidade definida.

• Testes de Aceitação: Foram desenvolvidos testes de aceitação e implementadostestes automáticos antes da entrega de cada versão(release) ao cliente.

• Projeto Orientado a Testes: Para todos os componentes foram desenvolvidostestes unitários automáticos que eram executados a cada release e durante aintegração dos componentes.

• Integração Contínua: No início a integração dos componentes eram semanais epassaram a ser dirárias no final do desenvolvimento.

• Projeto Simples: Desde a definição da arquitetura foi adotado a simplicidade doprojeto. Uso de patterns foi adotado para facilitar a compreensão da arquitetura.

• Refactoring: Foi incentivado o refactoring sempre que a implementação docódigo necessitasse. A arquitetura foi avaliada durante o desenvolvimento doprojeto e decisões de alteração eram tomadas quando necessário, porémavaliando-se o impacto das mudanças.

• Programação aos Pares: Um ambiente que propiciasse a troca constante deinformações durante o desenvolvimento foi criado para os especialistas. Aprogramaçã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 foicompartilhada pelos especialistas. O código sempre esteve disponível e osespecialistas foram incentivados a discutir sobre as soluções de codificaçãoadotadas.

• Padrão de Codificação: Foram definidas normas de codificação para facilitar ocompartilhamento do código e a revisão. A revisão do código foi feita poramostragem e sempre que necessário solicitado que fosse feito o refactoring docódigo.

• 40 horas semanais: Em nenhuma etapa do desenvolvimento foi necessáriotrabalho 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çãode empresas de manufatura. Inclui gestão de dados em tempo real.

51



• Projeto Hathor: Sistema de gestão pública, desenvolvido para atender asnecessidades de prefeituras. O primeiro módulo do Hathor desenvolvido foi oFinanceiro 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 dosprojetos, não houve impacto significativo de tamanho, custo, cronograma e esforço. Atabela 2 apresenta o percentual de esforço em cada atividade durante o desenvolvimentode 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 noprojeto Horus de 71,5 %. Apesar de seguir um processo definido baseado no nível 2 doSW-CMM aproximadamente 70 % do esforço foi dedicado as atividades diretas deprojeto.

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

52



4. Conclusões

O desenvolvimento de software não é uma atividade trivial. A experimentação de novastécnicas e paradigmas permite que se possa melhorar sempre. O que ocorreu de maisimportante durante o desenvolvimento deste trabalho foi a motivação e o envolvimentoda equipe. Os especialistas se sentiram a vontade para desenvolver e isso foifundamental para o sucesso do desenvolvimento. O padrão SW-CMM define boaspráticas, o que se deve fazer. O extreme programming apresenta práticas queaproximam as pessoas da equipe e facilitam o relacionamento, e trata da forma como sepode fazer. Não se trata da solução de todos os problemas de desenvolvimento masfacilita muito o processo.

Algumas empresas utilizam processos com a intenção de evoluir o projetoindependente das pessoas, ou seja, em caso de necessidade a documentação dariasubsidio para a mudança na equipe. Esta pesquisa permitiu constatar é que esse não é omelhor caminho. O entrosamento, relacionamento e troca de informações esta no centrodo sucesso de desenvolvimento de projetos de software. Muito trabalho ainda precisaser feito, em especial em relação ao gerenciamento automatizado do projeto, métricasque permitam uma forma mais apurada de estimativa e que permitam desde o início adefiniçã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 noMPG para torna-lo mais ágil. A adoção não comprometeu as necessidades formais degerenciamento de projeto para o atendimento ao nível 2 do SW-CMM.

A Gerência de Configuração e Garantia da Qualidade foram remodeladas paraatender a agilidade da nova versão do MPG. Semanalmente foram geradas baselines deartefatos utilizados no projeto e realizadas medições e análises para a tomada dedecisão.

Algumas definições que não são utilizadas em XP foram adotadas, como porexemplo documentação formal. O passo seguinte será passar a criar os documentosdiretamente para serem apresentados online, isso irá agilizar a documentação e apublicação dos documentos. Um outro trabalho futuro será o desenvolvimento de umaferramenta de gerenciamento de projetos que utilizem técnicas vindas de processos ágeise de suporte a gestão do projeto sem ferir a agilidade conquistada pelo processo. Estaferramenta 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 emrelação a uma avaliação formal mas sem comprometer a avaliação formal desta novaversão. Um trabalho no sentido de gerar mais formalismo ao MPG poderia torna-lonovamente 100% em concordância com o CMM nível 2.

5. Referências

Back, Kent, Extreme Programming Explained: Embrace Change, Addison WesleyProfessional, 1999.

53



Koch, Alan, (2003) “SW-CMM – Compliant XP”,http://www.askprocess.com/Articles/SW-CMM-XP.pdf. (último acesso em15/08/2004).

Paulk, Mark C. et. al., The Capability Maturity Model: Guidelines for Improving theSoftware Process, Addison Wesley, 1995.

Paulk, Mark C. (2001) “Extreme Programming from a SW-CMM perspective”, IEEESoftware, 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 ExtremeProgramming 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

54



2004 - aplicando pr ticas de extreme programming (xp) em equipes sw-cmm n¡vel 2

Documents