Aplicação das abordagens Scrum e XP

INSTITUTO DE ESTUDOS SUPERIORES DA AMAZÔNIA
CURSO DE SISTEMAS DE INFORMAÇÃO
LUIZ SANCHES
MAURINELLE FREITAS
Aplicação das abordagens Scrum e XP em um
processo de software
Orientação da Profª. MSc. Silvana Rossy de Brito
BELÉM
2009

LUIZ SANCHES
MAURINELLE FREITAS
Artigo apresentado ao Curso de
Sistemas de Informação para
obtenção do grau de Bacharel em
Sistemas de Informação.
Orientado por: Profa
. MSc. Silvana
Rossy de Brito
BELÉM
2009

LUIZ SANCHES
MAURINELLE FREITAS
Este Artigo foi julgado adequado para a obtenção do Grau de Bacharel em
Sistemas de Informação, e aprovado na sua forma final pelo Instituto de
Estudos Superiores da Amazônia.
___________________________________________
Orientadora: Profª. MSc. Silvana Rossy de Brito
Instituto de Estudos Superiores da Amazônia – IESAM
___________________________________________
Examinador: Prof. Dr. Daniel Onofre Cruz
___________________________________________
Examinador: Prof. Esp. Paulo Santana Rocha
BELÉM
2009

Aplicação das abordagens Scrum e XP em um processo de
software
Luiz Sanches, Maurinelle Freitas
Curso de Sistemas de Informação - Instituto de Estudos Superiores da Amazônia
(IESAM)
66055-260 – Belém – PA– Brasil
luizsanches@opmbx.org, maurineliofreitas@gmail.com
Abstract. Scrum and XP are considered agile. Aims to define a process of
iterative software development (in cycles) and incremental (with incremental
additions of features), providing an excellent liaison between development
teams. With the active participation of customers, the profitability of the
project increases and the requirements and change requests are to be
understood more quickly. The agile development methodologies have been
ranked, but are still not widespread in the middle of production. The aim of
this paper is to demonstrate the functioning of the characteristics and
application of methodologies SCRUM and XP on a desktop.
Resumo. SCRUM e XP são consideradas metodologias ágeis. Tem por
objetivo definir um processo de desenvolvimento de software iterativo (em
ciclos) e incremental (com acréscimos gradativos de funcionalidades),
proporcionando um excelente entrosamento entre equipes de desenvolvimento.
Com a participação ativa dos clientes, o rendimento do projeto aumenta e os
requisitos e solicitações de alterações passam a ser entendidos mais
rapidamente. As metodologias de desenvolvimento ágil vêm se destacando,
porém são ainda pouco difundidas no meio de produção. O objetivo deste
artigo é demonstrar o funcionamento das características e a aplicação das
metodologias SCRUM e XP em um ambiente de trabalho.
1. Introdução
A complexidade e o tamanho dos sistemas computacionais atualmente requisitados
pelos clientes inviabiliza o uso de abordagens de desenvolvimento informais. Apesar da
vasta literatura sobre metodologias de desenvolvimento de software, segundo o CHAOS
Report de 1994 [Bassi, 2008], ainda são comuns os problemas relacionados ao prazo de
entrega, aos excessivos custos e à dificuldade de garantir a qualidade do software
desenvolvido.
Mesmo os projetos que respeitam prazos e custos podem possuir qualidade
suspeita, uma vez que seu desenvolvimento pode ter ocorrido sob pressão, o que pode
resultar em um elevado número de erros. Algumas destas falhas podem ser relacionadas
com os modelos de processo de software adotados, como por exemplo, o modelo
clássico ou seqüencial, considerado um processo tradicional [Pressman, 2006].
De acordo com Pressman (2006), na prática, os gerentes responsáveis pelo
desenvolvimento de software concentram-se nas questões de “primeiro plano”, as quais
se destacam:
- As estimativas de prazo e de custo freqüentemente são imprecisas;

- A produtividade das pessoas da área de software não tem acompanhado a
demanda por seus serviços.
Como resultado, custos excessivos têm sido experimentados. Além disso, os
índices de erros para novos desenvolvimentos causam insatisfação ao cliente e falta de
confiança. Esses problemas são a manifestação mais visível de outras dificuldades
(Pressman, 2006):
- O tempo dedicado para coletar dados sobre o processo de desenvolvimento de
software é insuficiente ou não há dados históricos para aumentar a confiabilidade das
estimativas;
- A qualidade de software freqüentemente é suspeita, em função da constante
falta de testes adequados e completos;
- Difícil manutenibilidade do software existente.
Cada um dos problemas descritos pode ser tratado, desde que se utilize a
abordagem apropriada. A chave está em uma abordagem de engenharia de
desenvolvimento de software aliada a uma contínua melhoria de técnicas e ferramentas.
No contexto das metodologias, enquanto que as metodologias tradicionais
propõem processos orientados à documentação para o desenvolvimento de software, as
novas abordagens adotam medidas para favorecer a produtividade dos desenvolvedores.
Um processo voltado para documentação acaba por limitar os desenvolvedores, visto
que necessitam de documentação pronta para iniciar as atividades de desenvolvimento.
Os problemas se agravam nos projetos que possuem requisitos pouco estáveis, equipes
pequenas e prazos curtos.
Dentre os diversos métodos disponíveis hoje no mercado, estão em evidência os
métodos ágeis. O objetivo desses métodos é obter um desenvolvimento de software
mais adequado ao ambiente turbulento dos negócios, o qual exige mudanças rápidas e
freqüentes. Dessa forma, pregam um conjunto de regras e práticas de gerenciamento as
quais são focadas em pessoas. Dentre esses métodos iremos abordar Scrum e XP.
Este estudo visa, inicialmente, apresentar estes conceitos e práticas dos métodos
ágeis, apresentando as suas características principais. Esses conceitos são explorados em
um estudo de caso onde foi aplicado os métodos Scrum e XP em um ambiente
organizacional de desenvolvimento de software. Por fim, este trabalho analisa os
resultados alcançados após a implantação dos métodos na organização.
2. Framework Scrum
Conforme visto por Schwaber (2002), o Scrum tem como objetivo definir um processo
para projetos, incluindo métodos específicos para desenvolvimento de software
orientado a objetos, os quais são focados em pessoas, cujos requisitos surgem e mudam
rapidamente. O método baseia-se ainda, em princípios como: equipes pequenas de, no
máximo, 7 pessoas; requisitos que são pouco estáveis ou desconhecidos, com iterações
curtas e dividindo o desenvolvimento em intervalos de tempos de, no máximo 30 dias,
também chamadas de Sprints. Este método não requer ou fornece qualquer técnica ou
método específico para a fase de desenvolvimento de construção de software, apenas
estabelece conjuntos de regras e práticas gerenciais que devem ser adotadas para o
sucesso de um projeto.
Segundo Schwaber (2002), os papéis do Scrum são:
- Product Owner: Proprietário do produto.

- Scrum Team: A equipe de desenvolvimento de um Sprint.
- Scrum Master: Elemento da equipe responsável pela gestão do projeto e
liderança da equipe, são normalmente engenheiros de software ou da área de sistemas.
Apesar de ser gestor, não tem propriamente autoridade sobre os demais membros da
equipe.
Ainda de acordo com Schwaber (2002), as práticas gerenciais do Scrum são:
- Product Backlog: Produção do trabalho executado.
- Sprint Backlog: Trabalho a ser desenvolvido num Sprint de modo a criar um
produto a apresentar ao cliente. Deve ser desenvolvido de forma incremental.
- Sprint Planning Meeting: Reunião de planejamento do Sprint, servindo para
traçar os objetivos do próximo ciclo de desenvolvimento.
- Dayling Scrum: Reunião diária onde são avaliados os progressos do projeto e
as barreiras encontradas durante o desenvolvimento.
- Sprint Review Meeting: Reunião de Revisão, ocorre no último dia do Sprint
para demonstrar as funcionalidades desenvolvidas para o Product Owner.
- Sprint Retrospective: Reunião entre Scrum Master e a equipe para manter a
transparência interna da equipe.
3. Extreme Programming
Teles (2006) define Extreme Programming, ou XP, com um processo de
desenvolvimento de software voltado para:
Projetos cujos requisitos são vagos e mudam com frequência;
Desenvolvimento de sistemas orientados a objetos;
Equipes pequenas, preferencialmente até 12 pessoas;
Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser
implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo
do tempo.
O método XP está organizado em torno de um conjunto de valores e práticas que
devem atuar de forma harmônica e coesa para assegurar que o cliente sempre receba um
alto retorno do investimento em software. Dentre os valores, destacamse: feedback,
comunicação, simplicidade e coragem. Já as práticas direcionam os seguintes aspectos
[Teles, 2006]:
- Cliente Presente: Para que a troca de feedback possa ocorrer e o cliente possa
obter o máximo de valor do projeto, é essencial que ele participe ativamente do
processo de desenvolvimento.
- Jogo do Planejamento: Todo projeto em XP é dividio em releases que são
módulos do sistema que geram um valor bem definido para o cliente, e iterações que são
períodos de tempo de poucas semanas o qual a equipe implementa um conjunto de
funcionalidades acordado com o cliente. No jogo do planejamento acontece uma
reunião onde o cliente avalia as funcionalidades que devem ser implementadas e
prioriza aquelas que farão parte do próximo release ou da próxima iteração.

No XP, as funcionalidades são descritas em pequenos cartões e são chamadas de
estórias. Durante o jogo do planejamento as estórias são estimadas, para que o cliente
possa conhecer o custo da implementação de cada uma delas. A estimativa é feita
utilizando-se uma unidade especial que recebe o nome de ponto.
- Stand Up Meeting: Trata-se de uma reunião, em pé, rápida que a equipe de
desenvolvimento avalia o trabalho que foi executado no dia anterior e prioriza aquilo
que será implementado no dia que se inicia.
- Programação em Par: No XP, os desenvolvedores implementam as
funcionalidades em pares diante de um computador. Esta prática permite que o código
seja revisado permanentemente, enquanto é construído.
- Desenvolvimento Guiado pelos Testes: Mais um mecanismo de validação
para assegurar que o software está correto. Os desenvolvedores escrevem testes para
cada funcionalidade antes de codificá-los. Fazendo isso, eles aprofundam o
entendimento das necessidades do cliente (o que aprimora a análise), se preocupam com
as interfaces externas dos métodos e classes antes de codificá-los (o que melhora o
design), sabem até onde codificar cada funcionalidade (o que ajuda a manter o sistema
simples) e passam a contar com uma massa de testes que pode ser usada a qualquer
momento para validar todo o sistema.
- Refactoring: É o ato de alterar um código sem afetar a funcionalidade que ele
implementa. É utilizado para tornar o software mais simples de ser manipulado e se
utiliza fortemente dos testes descritos anteriormente para garantir que as modificações
não interrompam o seu funcionamento.
- Código Coletivo: No XP o sistema não é segmentado em partes, de modo que
cada desenvolvedor fique responsável por uma delas. Os desenvolvedores têm acesso a
todas as partes do código e podem alterar aquilo que julgarem importante sem a
necessidade de pedir autorização de outra pessoa.
- Código Padronizado: Para que todos os desenvolvedores possam manipular
qualquer parte do software de forma mais rápida, a equipe estabelece padrões de
codificação, que servem também para tornar o sistema mais homogêneo e permitir que
qualquer manutenção futura seja efetuada mais rapidamente.
- Design Simples: Para que o cliente possa obter feedback logo, a equipe precisa
ser ágil no desenvolvimento, o que a leva a optar pela simplicidade do designer. Os
desenvolvedores se baseiam na premissa de que serão capazes de incorporar qualquer
necessidade futura quando e se ela surgir. Para isso, eles contam com o refactoring, os
testes e as demais práticas do XP.
- Metáfora: Para facilitar a criação de um design simples, a equipe de
desenvolvimento utiliza metáforas, já que têm o poder de transmitir idéias complexas de
forma simples, através de uma linguagem comum que é estabelecida entre a equipe de
desenvolvimento e o cliente.
- Ritmo Sustentável: Para garantir que a equipe tenha sempre o máximo de
rendimento e produza software com melhor qualidade possível. O XP recomenda que os
desenvolvedores trabalhem apenas oito horas por dia e evitem fazer horas-extras, visto
que é essencial estar descansado a cada manhã, de modo a utilizar a mente na sua
plenitude ao longo do dia.
- Integração Contínua: Quando uma nova funcionalidade é incorporada ao
sistema, ela pode afetar outras que já estavam implementadas. Para assegurar que todo o

sistema esteja funcionando de forma harmoniosa, a equipe pratica a integração
contínua que leva os pares a integrarem seus códigos com o restante do sistema
diversas vezes ao dia. Cada vez que um par faz isso, ele executa todos os testes para
assegurar que a integração tenha ocorrido de forma satisfatória.
- Releases Curtos: Uma equipe XP produz um conjunto reduzido de
funcionalidades e coloca em produção rapidamente de modo que o cliente já possa
utilizar o software no dia-a-dia e se beneficiar dele. Durante todo o projeto, a equipe
colocará o sistema em produção diversas vezes, cada vez incorporando mais
funcionalidades e gerando mais valor.
Segundo Beck (2004), XP assusta ou irrita algumas pessoas que a encontram
pela primeira vez. No entanto, nenhuma das idéias da XP é nova. A maioria delas é tão
velha quanto a programação. De uma certa forma, a XP é conservadora – todas as suas
técnicas foram comprovadas por décadas (para a estratégia de implementação) ou
séculos (para a estratégia de gerenciamento).
Conforme descrito por Beck (2004), a inovação da XP é:
- colocar todas essas práticas juntas, sob um só teto;
- garantir que elas sejam praticadas a fundo;
- garantir que as práticas apóiem umas às outras ao máximo.
Segue uma dica de [Beck, 2004]: “Adote uma prática da XP a cada vez, sempre
abordando o problema que mais preocupa o seu time. Uma vez que ele não é mais o seu
problema mais importante, passe para o próximo”.
4. Aplicando Scrum e XP em um Processo de Desenvolvimento de Software
Na figura 1, apresentamos a sinergia entre o Scrum e XP. Neste projeto, foi adotada a
abordagem ágil para gerência e desenvolvimento, buscando contribuir para o
planejamento do projeto e para o acompanhamento através de práticas sugeridas pelo
XP. Os conceitos chave adotados no projeto são descritos na figura 1.
Figura 1. Sinergia entre Scrum e XP, adaptado de [Kniberg, 2009].
Para efeito de estudo de caso e aprendizagem da equipe, foi selecionado um
projeto de desenvolvimento para aplicar as técnicas e métodos do Scrum e XP. O
projeto selecionado foi o Sistema de Informações Integradas de Gerenciamento (SIIG),
especificamente no desenvolvimento do módulo de administração de frotas.

4.1. Estudo de Caso: SIIG
Iniciado em 2007, a Diretoria de Tecnologia (DITEC) da Secretaria de Educação do
Estado do Pará (SEDUC) dirige o projeto conhecido como Sistema de Informações
Integradas de Gerenciamento (SIIG), a qual tem o objetivo de implantar módulos
administrativos nos departamentos da SEDUC, como o Controle de Processos (CPR),
Controle Financeiro (CRF), Administração de Frotas (AFR), Controle de Obras (SCO),
dentre outros, ainda em especificação.
Para efeito de experimentar a nova abordagem ao mesmo tempo que se inicia a
equipe com os princípios e práticas do desenvolvimento ágil, a estratégia foi adotar a
nova prática no planejamento e no desenvolvimento de apenas um módulo, no caso, a
Administração de Frotas. Apesar de aplicado a apenas um módulo, o sistema possui
algumas restrições, principalmente de tecnologia, que foram previamente definidas.
Portanto, as tecnologias atualmente envolvidas no sistema são:
- Sistemas operacionais Debian Linux [Murdock, 2009] para Servidores e
Ubuntu Linux [Canonical, 2009] para Desktops;
- Servidores Web Apache [Foundation, 2009a];
- Linguagens: HTML [Consortium, 2009], CSS [Bos, 2009], PHP [Lerdof,
2009], Jquery [Team, 2009];
- Banco de Dados PostgreSQL [Group, 2009];
- Ferramentas de desenvolvimento Eclipse PDT [Foundation, 2009b], Netbeans
[SUN, 2009];
- Repositório de código-fonte/controle de versão Subversion [CollabNet, 2009];
- Bugtracking Mantis [Mantis, 2009].
- A organização dos grupos de trabalho foi disposta conforme o modelo de
fábrica de software:
- Sala dos Analistas de Negócios;
- Sala dos Analistas Desenvolvedores;
- Sala dos Analistas de Banco de Dados;
- Sala de Suporte de Redes.
Cada sala foi definida com os seus respectivos coordenadores. No projeto, o
trabalho foi realizado da seguinte forma:
Os analistas realizavam o levantamento de requisitos com o cliente. Geravam a
documentação do módulo baseada no método Práxis com uma duração de meses. Em
seguida a documentação era repassada ao setor de desenvolvimento. O coordenador
destacava as pessoas para análise da documentação e possíveis não conformidades. Se a
documentação fosse aprovada era feita a divisão de trabalho entre os desenvolvedores.
Os DBA's então eram acionados para criação da estrutura física dos esquemas, tabelas,
índices, povoamento de tabelas no Banco de Dados. Finalmente, o Setor de Suporte de
Redes estava à disposição para solucionar problemas relacionados à infra-estrutura
lógica e física de redes, como exemplo do repositório de código-fonte Subversion,
bugtracking, servidor de testes, homologação, etc.
Existem vários problemas encontrados com este modelo, conforme descrito a
seguir.

a) A análise não era realizada em conjunto com um DBA, fazendo com que a
estrutura lógica do banco de dados não estivesse em conformidade com os padrões
definidos, devido a falta de conhecimento dos analistas na área;
b) A documentação era extensa e com itens desnecessários, como por exemplo:
diagramas de robustez. Além de demorar em meses para ser entregue aos
desenvolvedores. Na maioria das vezes, os casos de uso não estavam de acordo com os
protótipos de telas projetados pelos analistas de negócios. Enquanto a documentação
não era revisada o desenvolvimento do módulo não iniciava;
c) A demora para uma requisição de manutenção na base de dados ao setor dos
DBA's atrasava o desenvolvimento do sistema;
d) Por fim, quando o módulo era apresentado ao cliente, a constatação de que o
tinha sido desenvolvido não atendia as necessidades do usuário. Isso causava uma série
de discussões entre as equipes para apontar onde ocorreram as principais falhas;
Algumas das mudanças não tiveram boa aceitação da equipe. Entretanto, uma
avaliação final demonstrou que essas mudanças trouxeram vários benefícios
organizacionais:
A partir de Janeiro de 2009 a DITEC resolveu adotar o modelo de células, como
há tempos atrás havia sido implantado. Renomeou os setores de Negócios e
Desenvolvimento para Gerência de Projetos Acadêmicos (GPA) e Gerência de Projetos
Institucionais (GPI). A Gerência de Banco de Dados foi desmembrada e os DBA's
foram realocados nas novas Gerências de Projetos, assim como aconteceu com os
analistas e desenvolvedores.
A sala que previamente foi alocada para a Gerência de Banco de Dados foi
utilizada para alocar os profissionais que cuidam de informações de Recursos Humanos
baseadas no Banco de Dados Oracle, que fica hospedado na empresa de Processamento
de Dados do Pará (PRODEPA). Para complementar a mudança, foi criado um novo
cargo para a função de Arquiteto de Software, assumido por um Analista de Negócios.
Houve um período de adaptação dos funcionários para a nova estrutura de
projeto. Com o andamento do projeto, surgiram naturalmente novas formas de trabalhar,
já que cada Gerência tinha a sua disposição analistas, desenvolvedores e DBA's. Como
resultado, na GPI foi iniciado o módulo de Controle de Obras (SCO) e desenvolvido
com princípios ágeis, com a presença de analistas, desenvolvedores e DBA's nas
entrevistas de levantamento de requisitos.
As reuniões diárias eram realizadas para planejamento da base de dados,
distribuição de tarefas, acompanhamento do andamento do projeto. O cliente estava
presente as terças e quintas à tarde para avaliar o que tinha sido desenvolvido e
esclarecer possíveis dúvidas. A equipe utilizou, frequentemente, o recurso de
programação em pares, para resolver problemas aparentemente de maior complexidade.
Os analistas de testes além de detectar os erros, passaram a corrigi-los, o que
demonstrou na prática o conceito de “código coletivo” para a equipe.
A nova abordagem foi impulsionada pelas atividades de capacitação. A partir de
dois Workshops sobre gerenciamento e desenvolvimento ágil de software, realizados no
final de maio de 2009, alguns gerentes assumiram, com ânimo, as novas práticas. A
GPA passou, a partir de junho de 2009, a implementar Scrum um pequeno projeto, logo
depois passando para o módulo AOF do SIIG.

Através da conscientização da equipe sobre as dificuldades do modelo
tradicional de desenvolvimento de software, foi adotada a abordagem ágil na GPI,
utilizando as práticas e princípios das abordagens de Scrum e XP combinadas.
Finalmente, no dia 6 de julho foram criados os quadros de tarefas para os módulos de
obras e frotas.
No caso do módulo de obras só restavam duas estórias para serem concluídas
para a primeira versão. Já o módulo de frotas, que havia sofrido um retardo substancial
no cronograma, tinha problemas estruturais na base de dados e muitas operações para
serem criadas. Assim, para esse módulo, foram contratados novos desenvolvedores para
a equipe. A seguir apresenta-se, especificamente para esse módulo, a estratégia de
combinação de Scrum e XP.
4.2. Scrum e XP no desenvolvimento do módulo Administração de Frotas
Como o Scrum baseia-se em princípios como equipes pequenas e requisitos pouco
estáveis, com iterações curtas, o projeto foi desenvolvido em 25 dias, dividido em ciclos
(Sprints) um de 2 semanas (Sprint 1) e outro de 3 semanas (Sprint 2).
Os seguintes papéis foram definidos na equipe:
- Product Owner, selecionado um membro da equipe para realizar a função de
representante do cliente para validação das funcionalidades concluídas;
- Scrum Team, para o qual foram selecionados quatro membros da equipe de
desenvolvimento.
- Scrum Master, selecionado um membro da equipe para realizar a função de
intermediador da equipe com o cliente, realizar as reuniões diárias, acompanhar e
documentar os Sprints e remover os impedimentos da equipe.
- Coach [Teles, 2006], selecionado um membro da equipe para realizar a função
de treinador da equipe com o auxílio de materiais disponíveis na comunidade brasileira
de desenvolvimento ágil Aguiar (2008), Pimentel (2007), Coop (2008), Kniberg (2008).
Após a definição dos papéis, foi definido o Product Backlog. Foi utilizada a técnica
de Planning Poker [Yoshima, 2007] para estimativa do tempo de desenvolvimento, que
resultou no quadro 1.
Quadro 1. Estimativas Iniciais (Módulo de Administração de Frotas)
ID Estória Estimativa (Dias) Sprint
1 Refatoração da Base de Dados 5 1
2 Cadastro de Propriedades 2 1
3 Cadastro de Multas 3 1
4 Cadastro de Modelos 3 1
5 Cadastro de Marcas 2 1
6 Cadastro de Grupo de Táxi 3 1
7 Cadastro de Categorias de Veículo 3 1
8 Cadastro de Veículos 4 1
9 Refatoração da Solicitação de Veículos 3 1
10 Refatoração do Atendimento 5 1
11 Refatoração do Diário de Bordo 8 1

12 Criação de Relatórios com Ireport / Jasper 6 2
13 Homologação das estórias do Sprint 1 10 2
As reuniões (Sprint Planning Meeting) eram realizadas nas segundas no início
de cada Sprint para reavaliar o que seria desenvolvido durante as semanas seguintes.
As reuniões diárias (Dayling Scrum) foram realizadas em frente ao quadro de
tarefas (Scrum Board) (Figura 2) para acompanhamento do desenvolvimento das
tarefas. A equipe relatou que foi um dos eventos mais importantes para detecção de
problemas e impedimentos. A figura 3 apresenta a equipe presente para a reunião diária.
Figura 2. Scrum Board do Sprint 2
Figura 3. Reunião Diária da equipe conforme sugerido pela abordagem Scrum
Na reunião de revisão (Sprint Review Meeting), as estórias concluídas eram
apresentadas ao Product Owner para aprovação ou não.
Finalmente, foi na retrospectiva (Sprint Retrospective) que o trabalho do Coach
foi reconhecido como fundamental para ao projeto. De modo geral, a função do Coach
força a equipe a falar dos pontos fracos e fortes que ocorreram durante a Sprint. Entre os
pontos fortes a programação em pares recebeu destaque: a programação em pares foi
reconhecida como um fator fundamental para o nivelamento de conhecimento entre a
equipe e resolução rápida de problemas, já que uma pessoa que está fora do problema e

é inserida na atividade de programação analisa e detecta mais rapidamente o erro de
programação. De um modo geral, a comunicação entre a equipe melhorou bastante,
tanto que todos sabiam o que os membros do projeto estavam realizando no dia.
Os pontos fracos apontados na retrospectiva foram que três desenvolvedores
eram novos na equipe e tiveram que se adaptar aos padrões de desenvolvimento da
equipe. Outro ponto a ser observado com cautela é que, em alguns momentos, alguns
membros da equipe realizavam tarefas fora do escopo do Sprint em outros módulos do
sistema. Isso foi resultado da equipe da GPI ser reduzida.
6. Conclusões
Todos os profissionais resistem às mudanças em sua forma de trabalho. Assim também
são os profissionais da área de software, que muitas vezes se opõem às mudanças
introduzidas com novas metodologias.
Os princípios do desenvolvimento ágil são simples de compreender. Entretanto,
a sua implantação nas organizações não é trivial. Não só o Scrum como todas as
abordagens ágeis dependem muito das posturas profissionais, das crenças individuais e
das atitudes diante dos desafios na empresa. Na experiência relatada aqui não foi
diferente e as pessoas fizeram grande diferença, o que remete diretamente a
preocupação com os investimentos em capacitação e treinamento da equipe.
É importante considerar, ainda, que cada profissional possui o seu ritmo de
trabalho e crenças próprias que podem conflitar com os princípios das abordagens ágeis.
Assim, algumas pessoas simplesmente não se adaptam rapidamente à ruptura drástica
em sua forma de trabalhar. Por conta disso, o processo de seleção e capacitação de
profissionais deve ser contemplado com entrevistas que visem identificar esse perfil
necessário para participar de equipes ágeis. Não basta apenas o conhecimento técnico
para participar de uma equipe ágil, é preciso se adaptar ao tipo de ambiente criado para
atender os princípios de desenvolvimento ágil.
Com o projeto foi possível perceber o quanto é importante o apoio da alta
gerência. As equipes de desenvolvimento devem ter autonomia necessária para conduzir
“processos” de forma muito diferente dos tradicionais e isso necessariamente deve
passar pela aprovação da alta gerência. Também é essencial que as pessoas que deverão
assumir os papéis de Scrum Masters sejam líderes muito bem capacitados e que
conheçam profundamente os princípios e as práticas, não só para que tenham
capacidade de argumentação mas também para que não façam adaptações que violem os
princípios básicos das metodologias ágeis.
A grande dificuldade está no fato de interferir diretamente na cultura da empresa
e das pessoas. Para o projeto relatado aqui, utilizouse diversos materiais da comunidade
de desenvolvimento ágil brasileira para apoiar no que se refere a conscientização da
equipe, mas a conclusão é que esses recursos são insuficientes para envolver o time
com os princípios do desenvolvimento ágil. O ser humano tem medo do que é diferente,
do desconhecido. É preciso investimento progressivo para que o processo continue
evoluindo, buscando aumento da qualidade e produtividade.
Pelos resultados alcançados, observouse que a equipe assumiu uma postura
mais autogerenciável do que no início do projeto, o que se considera um ponto forte da
nova abordagem. Entretanto, ainda falta conhecimento das práticas ágeis para que a
implantação do Scrum e XP na empresa ofereçam resultados mais expressivos. Nessa

direção, o caminho adotado foi investir em workshops, minicursos e palestras
esclarecedoras, buscando consolidar os princípios na organização.
Sobre as práticas do XP, observouse que a equipe deve dominar com mais
profundidade a ferramenta PHPUnit (Bergmann, 2009) para aplicar o Desenvolvimento
Guiado à Testes, phpDoc (Eichorn, 2009) para gerar a documentação do códigofonte e
pesquisar ferramentas para realizar integração contínua, já que os analistas de teste só
fazem a homologação depois que o Sprint é concluído.
Referências
AgilCoop. Cooperativa de Desenvolvimento Ágil de Software. Disponível:
http://ccsl.ime.usp.br/agilcoop/. Acesso: julho/2008.
Aguiar, F. Scrum Overview. Disponível: http://fabiogr.com/2008/03/scrum-
overview.html. Acesso: maio/2008.
Bassi, D. Experiências com desenvolvimento ágil, Dissetação de Mestrado,
Universidade de São Paulo, 2008.
Beck, K. Programação extrema explicada: acolha as mudanças, Porto Alegre, Bookman,
2004.
Bergmann, S. PHPUnit. Disponível: http://www.phpunit.de/. Acesso: julho/2009.
Bos. B. Cascading Style Sheets. Disponível: http://www.w3.org/Style/CSS/. Acesso:
julho/2009.
Canonical. Ubuntu Linux. Disponível: http://www.ubuntu.com/. Acesso: julho/2009.
CollabNet. Subversion Open Source Version Control System. Disponível:
http://subversion.tigris.org/. Acesso: julho/2009.
Consortium, W. W. W. HTML 4.01 Specification. Disponível:
http://www.w3.org/TR/html401/. Acesso: julho/2009.
Eichorn, J. phpDocumentor. Disponível: http://www.phpdoc.org/. Acesso: julho/2009.
Foundation, T. A. S. Apache HTTP Server. Disponível: http://www.apache.org/. Acesso:
julho/2009a.
Foundation, T. E. Eclipse for PHP Developers. Disponível: http://www.eclipse.org/.
Acesso: julho/2009b.
Group, P. G. D. PostgreSQL Open Source Database. Disponível:
http://www.postgresql.org/. Acesso: julho/2009.
Kniberg, H. Scrum e XP direto das trincheiras: como fazemos Scrum, Disponível:
http://infoq.com/br/minibooks/scrum-xp-from-the-trenches. Acesso: novembro/2008.
Kniberg, H. Scrum and XP fit together. Disponível: http://blog.crisp.se/henrik
kniberg/2007/10/13/1192249140000.html. Acesso: julho/2009
Lerdof, R. PHP: Hypertext Preprocessor. Disponível: http://www.php.net/. Acesso:
julho/2009.
Mantis, Mantis Bugtraking System. Disponível: http://www.mantisbt.org/. Acesso:
julho/2009.
Murdock, I. Debian GNU/Linux. Disponível: http://www.debian.org/. Acesso:
julho/2009.

Pimentel, M. Revista Visão Ágil. Disponível: http://www.visaoagil.com/. Acesso:
julho/2007.
Pressman, R. S. “Engenharia de Software”. 6a. edição, Rio de Janeiro, McGraw-Hill.
2006.
Schwaber, K., Beedle, M. Agile Software Development with SCRUM. Prentice Hall,
2002.
SUN. NetBeans IDE. Disponível: http://www.netbeans.org/. Acesso: julho/2009.
Team, J. JavaScript Library. Disponível: http://jquery.com/. Acesso: julho/2009.
Teles, V. Extreme Programming: aprenda como encantar seus usuários desenvolvendo
software com agilidade e alta qualidade, São Paulo, Novatec Editora, 2006.
Yoshima, R. Gerenciamento de projetos com scrum, São Paulo, Aspercom, 2007.

Aplicação das abordagens Scrum e XP

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Aplicação das abordagens Scrum e XP

Similar to Aplicação das abordagens Scrum e XP (20)

More from s4nx

More from s4nx (20)

Aplicação das abordagens Scrum e XP