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
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
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
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 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 Instituto de Estudos Superiores da Amazônia – IESAM ___________________________________________ Examinador: Prof. Esp. Paulo Santana Rocha Instituto de Estudos Superiores da Amazônia – IESAM
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
[email protected],
[email protected]
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 ID
Estória
de Administração de Frotas) 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 http://ccsl.ime.usp.br/agilcoop/. Acesso: julho/2008. Aguiar, F. Scrum Overview. Disponível: overview.html. Acesso: maio/2008.
de
Software.
Disponível:
http://fabiogr.com/2008/03/scrum-
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 http://subversion.tigris.org/. Acesso: julho/2009.
Control
System.
Consortium, W. W. W. HTML 4.01 Specification. http://www.w3.org/TR/html401/. Acesso: julho/2009.
Disponível: Disponível:
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 http://www.postgresql.org/. Acesso: julho/2009.
Database.
Disponível:
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.
