Aplicando práticas de eXtreme Programming(XP) em equipes SW

VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
[email protected]
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
VI Simpósio Internacional de
Melhoria de Processos de Software
•
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
237
632
34091
59421
Tabelas
45
42
Telas
90
95
Especialistas
3
4
Cronograma
Janeiro a Junho de 2004
Janeiro a Outrbro de 2004
Classes
Linhas de Código
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
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
VI Simpósio Internacional de
Melhoria de Processos de Software
São Paulo, SP – Brasil 24-26/11/2004
www.simpros.com.br
54