MÉTODOS TRADICIONAIS VERSUS ÁGEIS: UM ESTUDO COMPARATIVO ATRAVÉS DO TRAININGCAD.

Transcrição

1 UNIVERSIDADE DE PERNAMBUCO FACULDADE DE CIÊNCIA E TECNOLOGIA DE CARUARU BACHARELADO EM SISTEMAS DE INFORMAÇÃO MÉTODOS TRADICIONAIS VERSUS ÁGEIS: UM ESTUDO COMPARATIVO ATRAVÉS DO TRAININGCAD. Gert Uchôa Müller Neto Humberto Rocha de Almeida Neto (Orientador) CARUARU (PE) DEZEMBRO DE 2009.

2 B.SC. GERT UCHÔA MÜLLER NETO M.Sc. Humberto Rocha de Almeida Neto (Orientador) MÉTODOS TRADICIONAIS VERSUS ÁGEIS: UM ESTUDO COMPARATIVO ATRAVÉS DO TRAININGCAD. Monografia apresentada como requisito parcial para obtenção do diploma de Bacharel em Sistemas de Informação pela Faculdade de Ciência e Tecnologia de Caruaru da Universidade de Pernambuco. CARUARU (PE) DEZEMBRO DE 2009.

3 MÜLLER NETO, Gert Uchôa. Métodos Tradicionais versus Ágeis: um estudo comparativo através do TrainingCad. / Gert Uchôa Müller Neto Caruaru: f.; 30 cm. Orientação: Humberto Rocha de Almeida Neto. Trabalho de Graduação em Sistemas de Informação (Bacharelado) - Faculdade de Ciência e Tecnologia de Caruaru da Universidade de Pernambuco, Inclui bibliografia. 1. Metodologia de Gerenciamento e Desenvolvimento de Software. I. Título.

4 A Deus, aos meus pais, à minha família e a Isabela Salvador.

5 AGRADECIMENTOS G ostaria de agradecer primeiramente a Deus, que me deu forças e capacidade para conclusão não só do trabalho de graduação, mas de todo o curso; e, em segundo lugar, aos meus pais, que sempre me apoiaram e me aconselharam em tudo: escolhas, dificuldades e medos. Tudo que vier a ser, devo a estas duas pessoas maravilhosas e batalhadoras. Quero aproveitar e agradecer aos meus amigos durante toda minha caminhada de construção do conhecimento, desde a época de garoto no colégio até os amigos de faculdade. Mas há alguns agradecimentos em especial. Agradeço a Flávio Ferreira, que foi quem me ajudou a descobrir meu grande dom dentro da área de informática, e aos gêmeos Diego Renato e Thiago Rodrigo, por serem sempre meus amigos fiéis, ajudando-me nas horas que mais precisei durante todo este curso. Meus sinceros agradecimentos aos professores do curso de Sistemas de Informação da UPE, por perseverarem e proporcionarem a continuidade da oportunidade que me foi dada. Em especial ao meu professor Humberto Rocha por ter me orientado e apoiado de forma brilhante não só durante o desenvolvimento deste trabalho, mas também em alguns momentos durante o curso, e por aceitar sem hesitar a responsabilidade de ser meu orientador, sempre acreditando que eu pudesse realizar um bom trabalho. Também gostaria de agradecer aos funcionários desta universidade. Obrigado a todos!

6 RESUMO Este trabalho visa apresentar o conceito de Métodos Ágeis, bem como suas características e aplicações, em contraponto aos Métodos Tradicionais. Suas formas de trabalho, seus valores e práticas serão apresentados de modo a identificar e justificar suas principais diferenças, estabelecendo uma relação de comparação entre elas. Também serão detalhados alguns destes métodos, especificando pontos-chave em sua metodologia e comparando suas características. Tentou-se alcançar esse objetivo através de uma pesquisa exploratória do Método Tradicional aplicado ao projeto TrainingCad da UPE Consultoria Jr. Definiu-se o Método Ágil Scrum alinhado às práticas de da metodologia de desenvolvimento denominada Extreme Programming, ou apenas XP, para aplicação de uma proposta em um estudo comparativo. Nesse estudo comparativo foram aplicadas técnicas especificadas pelo Scrum e XP para tentar aperfeiçoar o gerenciamento e desenvolvimento do projeto de software TrainingCad. Como resultado preliminar do estudo, apresentou-se uma proposta de desenvolvimento desse projeto utilizando Scrum alinhado ao XP, visando um desempenho satisfatório, um auxílio na monitoração das tarefas do projeto e melhorando a organização das atividades. Palavras-chave: Métodos Ágeis, Scrum, Métodos Tradicionais, Rational Unified Process, TrainingCad. i

7 ABSTRACT This paper presents the concept of Agile Methods as well as their characteristics and applications as opposed to Traditional Methods. Their forms of work, its values and practices will be presented in order to identify and explain the differences among them, establishing a relation of comparison between them. Will also detailed some of these methods by specifying key points in its methodology and comparing their characteristics. We tried to achieve this goal through an exploratory survey of Traditional Methods applied to the design of UPE Consultancy Jr s TrainingCad. was defined Scrum Agile Method aligned to the practices of the development methodology called Extreme Programming, or XP only, for application of a proposal in a comparative study. In this comparative study were applied techniques defined by Scrum and XP to try to improve the management and development of software project TrainingCad. As a result of the study, presented a proposal to develop this project using Scrum aligned to XP in order to perform satisfactorily, an aid in monitoring of project tasks and improving the organization of activities. Keywords: Agile Methods, Scrum, Traditional Methods, Rational Unified Process, TrainingCad. ii

8 SUMÁRIO Resumo Abstract Lista de Figuras Lista de Tabelas Lista de Símbolos e Siglas i ii v vi vii 1 Introdução Caracterização do Problema Motivação Objetivos Objetivo Geral Objetivos Específicos Metodologia da Pesquisa Classificação quanto à natureza Classificação quanto à abordagem do problema Classificação quanto aos objetivos Classificação quanto aos procedimentos técnicos Estrutura do Documento 12 2 Revisão da Literatura Gerenciamento e Desenvolvimento de Projetos de Software Métodos Tradicionais O Guia PMBOK O RUP Métodos Ágeis APM Scrum Extreme Programming 24 3 Estudo de Caso: TrainingCad Contextualização TrainingCad Gerenciamento e Desenvolvimento do Projeto 34 iii

9 3.4 Proposta de Aplicação do Scrum Proposta 43 4 Análise Comparativa Conclusões 47 5 Considerações Finais Contribuições Dificuldades Encontradas Trabalhos Futuros 49 Referências 51 iv

10 LISTA DE FIGURAS Figura 1 Ciclo PDCA (Plan-Do-Check-Act) 16 Figura 2 Mapeamento entre os grupos de processos e o ciclo PDCA 17 Figura 3 Ciclo de Vida do RUP 19 Figura 4 Processo de Desenvolvimento Ágil 21 Figura 5 Ciclo de Desenvolvimento do Scrum 24 Figura 6 Práticas do XP 30 Figura 7 Tela Principal do TrainingCad 34 Figura 8 Gráfico de Gantt do TrainingCad 35 Figura 9 Diagrama de Casos de Uso do TrainingCad 37 Figura 10 Diagrama de Sequência do Requisito Funcional Efetuar Login do TrainingCad 39 Figura 11 Diagrama de Classes do Requisito Funcional Efetuar Login do TrainingCad 40 Figura 12 Tela de Cadastro de Alunos do TrainingCad 41 Figura 13 Tela de Consultas do TrainingCad 42 Figura 14 Fases do Ciclo de Desenvolvimento anterior à Proposta 45 Figura 15 Ciclo de Desenvolvimento após aplicação da Proposta 45 Figura 16 Comparação de Custos de Mudanças entre Métodos Ágeis e Tradicionais 47 v

11 LISTA DE TABELAS Tabela 1 Cronograma de Marcos Sumarizado do TrainingCad 32 Tabela 2 Requisitos Funcionais do TrainingCad 36 Tabela 3 Requisitos Não-Funcionais do TrainingCad 36 Tabela 4 Cronograma detalhado do TrainingCad 38 Tabela 5 Gerenciamento de Riscos do TrainingCad 38 Tabela 6 Tabela de Estratégia de Teste de Stress do TrainingCad 42 Tabela 7 Tabela Comparativa entre as Metodologias usadas e propostas no TrainingCad 46 vi

12 LISTA DE SÍMBOLOS E SIGLAS APM - Agile Project Management BPMS - Business Process Management Systems GRP - Gerência de Riscos de Projeto PDCA - Plan, Do, Check and Act PMBOK - Project Management Body of Knowledge PMI - Project Management Institute RSC - Rational Software Corporation RUP - Rational Unified Process XP - Extreme Programming vii

13 CAPÍTULO 1 Introdução Cada vez mais os sistemas de computação têm conquistado espaço em no cotidiano da sociedade moderna. Apesar deste rápido avanço, ainda se faz necessário prazos mais curtos na produção de software para melhor atender às necessidades dos clientes. Contudo, a construção de um software robusto, confiável e de boa qualidade dentro dos prazos e custos estimados ainda é uma árdua tarefa. O gerenciamento de um projeto de software é uma tarefa complicada e envolve condições adversas, além de fatores externos que podem ser imprevisíveis. Podem-se citar algumas entre essas condições como mudanças de tecnologias e as constantes renovações dos requisitos do produto por parte do cliente (SCHWABER, 2004). Pesquisas nessa área realizadas por Carlos Bernardo Souza (2008) através da Pontifícia Universidade Católica do Rio Grande do Sul, por volta de 2005, tomando por base mais de 8300 projetos, atestam que apenas 16,2% dos projetos foram entregues dentro do prazo estipulado respeitando os requisitos e os custos. Levando em consideração os projetos que extrapolaram os limites temporais e financeiros, apenas 61% das funcionalidades requisitadas pelos clientes foram entregues. Até mesmo os que seguiram à risca os prazos, custos e funcionalidades são postos a suspeita de que não são de boa qualidade, pois os seus integrantes foram submetidos a uma grande pressão, o que pode levar a um aumento significativo dos erros no decorrer do projeto. Muitas dessas falhas estão relacionadas ao grande uso dos processos de gerenciamento de software tradicionalistas, podendo-se citar o RUP (Rational Unified Process 1 ), os quais possuem um nível mais rígido de formalidades, abusando de uma documentação muito extensa, dificultando que os requisitos dos softwares sejam elásticos e mutáveis. 1 Tradução: Processo Unificado Rational. 8

14 Contudo, o mercado atual é muito dinâmico e exige dos requisitos de um projeto de software o mesmo dinamismo. Logo, os modelos ou práticas de gestão e desenvolvimento de projetos orientados a documentação (tradicionalistas), como exemplo pode-se citar o guia PMBOK (Project Management Body of Knowledge 2 ) (2004), limitam a flexibilidade de adaptação desses mesmos requisitos. Então, algumas organizações acabam por não usar processo algum, tentando fugir da lentidão e do alto custo, e prejudicam a qualidade de seu produto final. As metodologias ágeis surgem então como contraposto às metodologias tradicionais. Mas, em sua grande maioria, não aparecem com algo novo, mas mudam os enfoques e os valores do gerenciamento de projetos. O enfoque agora é direcionado a pessoas, e não mais em processos. Começa, também, a existir a preocupação em reduzir os custos com o tempo e documentação extensiva. A implementação passa a ocupar mais tempo, proporcionalmente, no projeto (COCKBURN, 2001). Em 2001, foi criado o Agile Manifesto (2009), onde um grupo de especialistas em desenvolvimento ágil de software se reuniu e estabeleceu princípios comuns a estes métodos. Inserida neste contexto, uma empresa júnior do Campus Caruaru Faculdade de Ciência e Tecnologia de Caruaru da Universidade de Pernambuco, propôs o desenvolvimento de um software de gestão de inscrições para seus próprios cursos, o TrainingCad. Este software foi desenvolvido utilizando o RUP como método de desenvolvimento e as práticas do PMBOK (2004) como método de gerenciamento, e foram levantados muitos questionamentos sobre seu tempo de desenvolvimento e sobre seu custo durante suas reuniões. 1.1 Caracterização do Problema Como garantir o sucesso do projeto TrainingCad, desprendendo seu método de gerenciamento e desenvolvimento do tradicionalismo rígido usando as novas metodologias ágeis, suas práticas e valores? 2 Tradução: Corpo de Conhecimentos de Gerenciamento de Projetos. 9

15 1.2 Motivação O sucesso da produção de software depende cada vez mais da qualidade final do seu produto, além do cumprimento fiel dos prazos e custos estipulados. É necessário, então, aplicar uma metodologia para gerenciar e desenvolver o projeto, com o intuito de acompanhar as etapas de seu desenvolvimento e gerenciar qualquer impedimento que venha a ocorrer. As metodologias de gerenciamento e desenvolvimento de projetos tradicionais não são apenas baseadas em boas práticas para desenvolvimento de software, mas também, boas práticas para gerenciar os negócios. Entretanto, a maioria das empresas envolvidas neste tipo de negócio não possui recursos financeiros para implantação de processos de gerência tradicionais. Pode-se adicionar isso à informação de que os requisitos tendem a ser cada vez mais mutáveis, também. A justificativa para escolha do tema deste trabalho vêm da visibilidade crescente que as Metodologias Ágeis de desenvolvimento de software têm recebido em todo o mundo, e também aqui no Brasil. As características presentes neste trabalho também levam à tentativa de resolução de questionamentos, dos quais se pode citar: Quando devo usar que tipos de metodologia? Como obter resultados mais rápidos? Inspirado nisso, este trabalho tem por motivação responder algumas dessas questões que foram levantadas sobre o processo de criação do TrainingCad, propondo a aplicação de uma ou mais metodologias ágeis. 1.3 Objetivos Nesta seção serão apresentados os objetivos geral e específicos que este estudo comparativo tentou alcançar Objetivo Geral Propor uma metodologia de gerenciamento e desenvolvimento de projeto para o TrainingCad baseado nas premissas das Metodologias Ágeis após análise do processo que fora realizado utilizando o RUP como metodologia primordial. 10

16 1.3.2 Objetivos Específicos - Contextualizar o projeto TrainingCad e sua metodologia; - Analisar a metodologia utilizada no projeto de software em estudo; - Adaptar as disciplinas da metodologia usada no projeto; - Propor um novo método baseado no Scrum e no XP a ser seguido no gerenciamento e desenvolvimento do TrainingCad; - Estimar os efeitos da possível adoção do método proposto. 1.4 Metodologia da Pesquisa O método de construção do trabalho científico que se segue, está organizado da forma nos itens dispostos a seguir: Classificação quanto à natureza Quanto à sua natureza, este trabalho se classifica como uma pesquisa aplicada, já que pretende gerar conhecimentos dirigidos à solução de uma problemática (CERVO, 2007) Classificação quanto à abordagem do problema Do ponto de vista de abordagem do problema, pode ser vista como uma pesquisa qualitativa, pois não há uma forma de mensuração exata das opiniões descritas na dissertação (CERVO, 2007) Classificação quanto aos objetivos Quanto aos objetivos, este trabalho se encaixa como uma pesquisa exploratória, pois se trata de um estudo comparativo através do TrainingCad e explora o método de gerenciamento do projeto de software (CERVO, 2007). 11

17 1.4.4 Classificação quanto aos procedimentos técnicos Quanto aos procedimentos, esta pesquisa se encaixa em três aspectos: bibliográfica, experimental e estudo de caso. Bibliográfica porque se apóia em muitos aspectos descritos em livros e materiais publicados. Experimental, pois se determina um objeto de estudo e se identifica as variáveis que possivelmente o influenciariam. E, por fim, um estudo de caso comparativo, pois usa da analogia entre dois valores de uma característica do objeto, envolvendo-se profundamente em seu estudo, afim de seu detalhado conhecimento (CERVO, 2007). 1.5 Estrutura do Documento Este trabalho está dividido em cinco seções, incluindo o presente prefácio. Os demais capítulos visam à demonstração, o desenvolvimento do trabalho e o método de realização do estudo. A pesquisa está dividida da seguinte forma: Capítulo 1 - Introdução - Nesta seção serão introduzidas a problemática, a justificativa do trabalho, seus objetivos e metodologia usada na realização da pesquisa, além dos aspectos do contexto atual sobre os assuntos-chave do trabalho. Capítulo 2 - Revisão da Literatura - Este capítulo irá tratar sobre o embasamento teórico do trabalho. É nele que serão vistos conceitos sobre os assuntos-chave na área de métodos de gerência e desenvolvimento de projetos de software. Capítulo 3 - Estudo de Caso: TrainingCad - Esta parte se responsabilizará por apresentar, contextualizar, analisar o aplicativo TrainingCad. Também será nele que será proposto um novo método de gerência de projetos baseado no Scrum e no XP. Capitulo 4 - Análise Comparativa - Neste momento serão abordados os resultados esperados e comparados aos resultados obtidos anteriormente para uma análise comparativa entre as duas metodologias em questão. Capítulo 5 - Considerações Finais - Nesta seção serão tratadas as considerações finais do projeto. Bem como trabalhos relacionados, as dificuldades encontradas e opiniões para trabalhos futuros. 12

18 CAPÍTULO 2 Revisão da Literatura A pesquisa realizada neste trabalho tem por objetivo intrínseco auxiliar de alguma forma às atividades do ramo de gerenciamento e desenvolvimento de projetos. A disciplina de Gerência de Projetos é aquela responsável pelo controle dos riscos de insucesso do projeto durante o desenvolvimento do mesmo. Consiste na aplicação de conhecimentos e métodos de elaboração de tarefas que se relacionam para atingir os objetivos definidos (TAVARES, 2008). Há duas vertentes principais de metodologias de gestão de projetos de software: tradicionais e ágeis. Elas possuem os mesmos objetivos e metas, porém funcionam de maneiras distintas, além de enfatizarem valores diferentes. Explanarei o assunto um pouco aprofundado mais a seguir. 2.1 Gerenciamento e Desenvolvimento de Projetos de Software O mercado está cada vez mais dinâmico, o mundo por sua vez também está. As relações empresariais e os negócios estão cada vez mais competitivos. Quem possui maior acesso à informação possui vantagens sobre os concorrentes. Desde o advento da Internet na última década, a velocidade dos acontecimentos no mundo têm se tornado muito rápida. A informação cruza o globo instantaneamente. Uma notícia sobre uma empresa do outro lado do planeta pode afetar a bolsa de valores no mundo inteiro em questões de segundos, conforme a dissipação da informação pela Internet (VIEIRA, 2003). Defronte este cenário, a importância da gestão de projetos nas organizações tem se tornado cada vez maior. O TrainingCad se insere nesse quadro. O mesmo utiliza uma metodologia de gerenciamento e desenvolvimento de projeto tradicionalista, e para facilitar a compreensão de seu processo de desenvolvimento e de sua aplicação, serão introduzidos mais adiante, conceitos dos métodos tradicionais (Seção 2.2) e suas especificidades. Também serão colocados conceitos relacionados aos métodos ágeis (Seção 2.3) e, dentro deles, os conceitos 13

19 do Scrum e do XP. Serão abordadas as principais diferenças entre os métodos citados, bem como as vantagens da utilização de metodologias ágeis no contexto atual. Os conceitos da metodologia de gerenciamento tomada no desenvolvimento do TrainingCad se apoiaram nos conceitos do RUP, e os princípios ágeis da proposta, nas práticas existentes de gestão de projetos usando Scrum (SCHWABER, 2004), XP e APM (Agile Project Management). 2.2 Métodos Tradicionais Estas metodologias surgiram em um cenário de construção de software muito diferente do atual. A sequência de tarefas para desenvolvimento do software era realizada em terminais burros e mainframes, onde o custo para correção de erros ou qualquer outra alteração era muito elevado, pois o acesso aos computadores era muito limitado e não havia ferramentas de apoio à construção de software (PRESSMAN, 2002). Então a maneira de minimizar os problemas durante o desenvolvimento de um software foi planejar e documentar muito bem este antes do início de seu desenvolvimento. Esse foi um dos fatores primordiais para a existência de um processo de gerenciamento de software baseado em documentação detalhada, planejamento extenso e etapas bem delimitadas (PRESSMAN, 2002). Hoje, a gerência de projetos tradicionalista ainda é o método mais usado no desenvolvimento de software. Uma das grandes vantagens do método tradicional está na comparação e repetição com dados obtidos do passado, devido à padronização proporcionada pelo processo e guiado pela sensibilidade que indica que variações durante a execução do processo podem ser identificadas e solucionadas através do refinamento e mensuração do mesmo. A partir da obtenção de dados de fatos já ocorridos e da repetição, obtém-se a melhoria da capacidade do processo através da padronização, medição e controle do projeto. Este método também recebe o nome de pesado, pois possui um grande tamanho e traz consigo uma grande dificuldade de implementação. Na fase de planejamento é dissipado muito tempo com a documentação, pois esta é a base do projeto e tem por missão minimizar, o quanto puder, que novos requisitos e/ou funcionalidades surjam durante o período de construção propriamente dito do software. Nessa fase encontra-se a delimitação do escopo do projeto, um fator crucial para seu sucesso, pois a 14

20 qualidade é influenciada diretamente por este mesmo fator (SLIGER, 2006 apud TAVARES, 2008). É imprescindível ao analista ou engenheiro e ao gerente do projeto ter uma grande disponibilidade à comunicação. Saber ouvir e respeitar as pessoas que vivem no ambiente de trabalho, além de saber selecionar e adicionar as necessidades do usuário justificadas economicamente são qualidades essenciais a esta figura do processo. Quanto mais impedimentos ocorrerem durante a execução do projeto, maior será o re-trabalho e o tempo de finalização do mesmo. Isso implica em mudanças estruturais complicadas e que têm impacto muito grande sobre o custo, o prazo e a qualidade do produto final (SOUZA, 2008). O planejamento é detalhadamente descrito, extenso por sua vez, e enfatiza a criação e o cumprimento de cronogramas de atividades e procedimentos que auxiliem na construção do produto e na coordenação do processo. Este tipo de documento ainda é utilizado na mensuração do progresso durante a fase de execução do projeto, podendo sofrer constantes mudanças conforme a evolução do processo (VIEIRA, 2003). Este tipo de metodologia permite a opção entre vários tipos de ciclos de desenvolvimento. Pode-se citar os ciclos cascata 3, espiral 4 ou iterativo 5 como exemplos. Sua arquitetura é focada na reutilização, reduzindo a quantidade de retrabalho, com isso incentivando o crescimento da produtividade. Também pode ser utilizado em vários projetos, desde que os requisitos do mesmo não sejam muito voláteis, já que este método demonstra dificuldades claras em relação às mudanças colocadas pelo ambiente ou proprietário. Este fato pode ocasionar um desgaste no relacionamento entre o cliente e a equipe de desenvolvimento, resultando no atraso da entrega do projeto. É por este motivo que muitos estudiosos na área de Engenharia de Software se dedicam, atualmente, ao desenvolvimento de novos métodos de gerenciamento e desenvolvimento de projetos de software, entre eles os novos métodos ágeis, que possuem valores e visões diferentes das metodologias tradicionalistas. Dentre as metodologias de gerência de projetos tradicionais, pode-se exemplificar o Guia PMBOK (2004). 3 O modelo de ciclo de vida em cascata consiste basicamente num modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado. 4 No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividades são repetidas até uma decisão ser tomada e o documento de especificação de requisitos ser aceito. 5 Desenvolvimento iterativo é uma estratégia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido. 15

21 2.2.1 O Guia PMBOK Um dos principais responsáveis pela difusão do gerenciamento de projetos e da profissionalização dos gerentes é o PMI (Project Management Institute 6 ). Foi elaborado, então em 1996, o principal documento do PMI, o Guia PMBOK (2004). Este documento é referencial em muitas áreas para gerenciamento de projetos e foi desenvolvido para controlar apenas um projeto por vez. De acordo com o PMBOK (2004), o ciclo vital de uma metodologia tradicionalista é composto pelas fases de iniciação, planejamento, execução, controle e fechamento, e são responsabilidades do gerente do projeto. Estes processos é que irão conceituar atividades, as quais serão executadas para gerar os produtos que serão entregues ao cliente no final de cada etapa e as pessoas que irão realizar as atividades. Há uma coerção bem rígida entre os processos temporais do projeto, e cada um tem suas peculiaridades e interdependências. Ou seja, a fase a seguir começa apenas após o término da anterior, caracterizando a definição formal, que diz que esse método é sequencial e linear. As fases/atividades citadas foram relacionadas pelo Guia PMBOK (2004) de acordo com um ciclo chamado Plan-Do-Check-Act (PDCA) (Figura 1), onde a fase de planejamento se refere ao Plan, execução ao Do, controle ao Check e as fases de iniciação e fechamento, o início e término ou renovação do ciclo, se referem à ação (Act) (Figura 2). Figura 1 Ciclo PDCA (Plan-Do-Check-Act) Fonte: PMBOK (2004). 6 Tradução: Instituto de Gerenciamento de Projetos. 16

22 2.2.2 O RUP Figura 2 Mapeamento entre os grupos de processos e o ciclo PDCA Fonte: Sacramento (2009). O Rational Unified Process, mais comumente denominado de RUP, é um processo de Engenharia de Software desenvolvido inicialmente pela RSC (Rational Software Corporation). Desse modo, é uma metodologia de desenvolvimento e gerenciamento de software proprietária, onde são definidas regras e papéis, vislumbrando o aumento da produtividade. Uma das principais características do RUP é o alto teor de customização. Porém, é algo complexo, sendo apenas recomendado para grandes equipes e grandes projetos (KRUCHTEN, 1999). Do ponto de vista gerencial, o RUP fornece uma solução de como atribuir papéis, tarefas e responsabilidades de uma forma disciplinada em um ambiente de desenvolvimento de software, seja ele uma organização, seja ele uma grande equipe de desenvolvimento. Por si só, o RUP é um produto de apoio à Gerência de Projetos, onde todo método é agregado a variadas ferramentas de construção, desenvolvimento e gerenciamento. O RUP possui cinco figuras cruciais: papéis, atividades, artefatos, fluxos de trabalho (workflows) e disciplinas. Um papel conceitua e controla o comportamento e as responsabilidades de cada um dos indivíduos ou um conjunto deles na equipe. Uma atividade é uma parte do trabalho que um membro da equipe executa após estar ciente de qual papel deve exercer inserido no contexto do projeto. O artefato é o produto do projeto, produzido durante o desenvolvimento do projeto. É um espaço de informação criado, modificado ou utilizado em um dado processo. O fluxo de trabalho, por sua vez, é a determinação da 17

23 sequência do desenvolvimento das atividades, após a atribuição de papéis, para que se possa ser produzido um artefato. Por fim, a disciplina nada mais é que um conjunto de atividades inter-relacionadas que fazem parte do mesmo contexto. Ou seja, as disciplinas proporcionam uma melhor compreensão do projeto sob a visão tradicional, tornando o entendimento de cada atividade mais fácil (KRUCHTEN, 2001 apud PINHEIRO, 2005). O RUP faz uso de nove disciplinas, dentre as quais existe a divisão em processo e suporte. As disciplinas agrupadas em processo são: modelagem de negócios, requisitos, análise e projeto, implementação, teste e distribuição. Já as disciplinas agrupadas em suporte, e mais importantes para o estudo de caso em questão, são: configuração e gerenciamento de mudanças, projeto e ambiente (PINHEIRO, 2005). O RUP como processo de gerenciamento de projetos de software possui tanto características técnicas quanto gerenciais. Como o objetivo do trabalho é compará-lo ao Scrum, visa-se salientar e/ou explicitar seus aspectos gerenciais. Dentre eles, se destaca a disciplina de Gerência de Projetos e seus papéis, atividades e artefatos. Gerência de Projetos de Software, no RUP, é o fato de equilibrar objetivos competitivos, gerenciar riscos e superar as dificuldades para entregar um produto que atenda às necessidades dos clientes e dos usuários (RATIONAL, 2009). Logo, a proposta da disciplina de Gerência de Projetos no RUP é desenvolver uma força estrutural para gerir projetos de software, regras práticas para planejar, alocar recursos humanos, executar e monitorar projetos e uma estrutura que forneça suporte à gerência de riscos. No entanto, esta disciplina não tem objetivo de cobrir todos os aspectos do gerenciamento real de um projeto. Ela foca principalmente os aspectos do processo de desenvolvimento iterativo. Gerência de riscos, planejamento de um projeto iterativo através do ciclo de vida e monitoramento do progresso desse planejamento através das métricas podem ser alguns exemplos desses aspectos (KRUCHTEN, 2001 apud PINHEIRO, 2005). 18

24 Figura 3 Ciclo de Vida do RUP Fonte: Rational (2009). O RUP demonstra-se como uma metodologia de desenvolvimento de software que valoriza a atividade de gerenciamento. Apesar de, em algumas vezes, se tornar muito burocrático e repetitivo, o processo unificado tem por objetivo garantir o sucesso do projeto com o cumprimento de várias atividades e artefatos relacionados com a gerência de projetos. Tais atividades e artefatos são construídos por vários papéis que foram definidos com o mesmo desejo: dar suporte para realização da gerência de projetos (PINHEIRO, 2005). 2.3 Métodos Ágeis Os métodos ágeis de gerenciamento de projetos apareceram com contraposto às chamadas metodologias pesadas metodologias tradicionalistas como uma alternativa para se adaptar ao contexto do mercado atual, que exige resultados cada vez mais rápidos para atender às necessidades dos clientes, sob condições de constantes mudanças e incertezas. Pesquisas realizadas na Pontifícia Universidade Católica do Rio Grande do Sul em 2005 demonstram que somente 16,2% dos quase 8380 projetos usados por base da pesquisa, foram entregues dentro dos prazos, custos e com todas as funcionalidades especificadas (SOUZA, 2008). Muitos destes empecilhos estão relacionados ao processo de gerenciamento em cascata metodologias tradicionais de gerenciamento de projetos de software que possuem um nível de burocratização um tanto quanto grande, dificultando mudanças de requisitos no 19

25 projeto por possuir uma documentação extensa, causando um grande aumento no custo do projeto. O termo metodologias ágeis ficou mais popular em 2001, quando especialistas em vários processos de gerenciamento e desenvolvimento de software se uniram para desenvolver e estabelecer princípios comuns entre estes métodos, resultando na criação do Agile Manifesto (2009). Mesmo possuindo o enfoque voltado para pessoas e não mais para algoritmos, se preocupando mais com o desenvolvimento do software do que com sua documentação, usando desenvolvimento iterativo e incremental e aumentando a comunicação as metodologias ágeis se diferenciam por práticas e ênfases. Esses fatores em comum, de certo modo, aumentam as possibilidades de atender os requisitos dos clientes, já que estes muitas vezes passam por mudanças durante o projeto. O cliente possui o domínio do negócio, por isso agora passa a ser considerado participante e membro da equipe e tem poder de decisão sobre alterações que aparecerem durante o desenvolvimento do projeto (BOEHM, 2002). A essência do método ágil de gestão de projetos está em responder de forma mais rápida e menos dispendiosa às mudanças de requisito ocasionadas pelos clientes ou ambientes, no aumento da confiança na equipe de desenvolvimento e na entrega cíclica de versões ao cliente (COCKBURN, 2001). Os métodos ágeis são adaptativos e não preditivos, como é o caso das metodologias tradicionais. Eles se adaptam aos novos fatores que surgem durante o desenvolvimento do projeto ao invés de verificar antecipadamente todos os impedimentos que podem acontecer durante a construção do produto. O problema em si não está nas mudanças, pois estas estão sempre sujeitas a ocorrer em quaisquer dos âmbitos. O problema está na maneira que cada uma das metodologias trata essas mudanças. Como recebem, avaliam e respondem às mesmas (COCKBURN, 2001). O ciclo de vida básico de um método ágil pode ser observado na Figura 4. A partir dela, verifica-se que o processo utiliza a construção de uma versão cumprindo todas as fases de desenvolvimento para cada produto e, depois da entrega, passa pela fase de refatoração objetivando melhorias no produto, sem mudar o comportamento do processo. Este ciclo se repete para cada incremento de produto gerado, até o fim do processo de obtenção do produto final. 20

26 Figura 4 Processo de Desenvolvimento Ágil Fonte: Souza (2008) APM APM (Agile Project Management 7 ) é um conjunto de valores, princípios e práticas que auxiliam a equipe do projeto a entregar produtos ou serviços de valor em um ambiente complexo, instável e desafiador. É desejável, no APM, que sejam construídos produtos de modo ágil e adaptáveis e que sejam criadas equipes de desenvolvimento com as mesmas características (HIGHSMITH, 2004). Segundo Cockburn (2001), o APM tem como principais objetivos:» Favorecer a exploração e a cultura adaptativa;» Permitir a exploração e a autodisciplina;» Promover a confiabilidade e a consistência possíveis, dado o grau de incertezas e complexidade inerente do projeto;» Ser flexível e facilmente adaptável;» Permitir visibilidade ao longo do processo;» Incorporar o aprendizado;» Englobar as práticas específicas de cada fase;» Prover pontos de verificação. Este processo ágil tem suas iterações compostas por cinco fases, são elas (COCKBURN, 2001):» Visão: Nesta fase é gerada uma visão geral do produto e do negócio, também são definidos o escopo do projeto, os participantes e a definição de como a equipe trabalhará em conjunto; 7 Tradução: Gerenciamento Ágil de Projetos. 21

27 » Especulação: Há identificação dos requisitos iniciais do produto, são elaboradas estimativas e estratégias de resolução dos riscos, estimativas de custos e ocorre o desenvolvimento de um plano de projeto visando o lucro do cliente;» Exploração: Essa fase engloba a entrega dos produtos planejados sob a forma de incrementos de funcionalidades divididas entre os ciclos do projeto;» Adaptação: Nessa fase os resultados são revisados, é feita uma análise da situação atual do projeto, ocorre a avaliação da equipe e ações adaptativas podem ser incluídas na próxima iteração;» Encerramento: Ocorre a finalização das atividades do projeto e são registradas as lições aprendidas para que possam ser utilizadas em outros projetos Scrum Teoricamente, a melhor maneira de acelerar o processo de desenvolvimento é construir apenas o que o cliente valoriza e nada mais. O uso em exagero de formalização planejamento extensivamente detalhado das tarefas e documentação em excesso pode impedir o andamento do projeto, mas o contrário, ou seja, sem a utilização de algum modo de gerenciamento, pode gerar um cenário em que os objetivos do projeto não irão ser alcançados. O uso do Scrum Metodologia Ágil para Gestão de Projetos permite desenvolver projetos bem mais adaptados à nova realidade das organizações de forma rápida. O foco do Scrum é descobrir uma forma que os membros da equipe trabalhem para produzir um software flexível em um ambiente de constantes mudanças (SCHWABER, 2004). A maioria dos projetos em que se é escolhido inserir o Scrum é complexa e imprevisível. Ele provavelmente não vai solucionar todos os problemas do projeto, mas ajudará a percebê-los. Essa metodologia ágil serve como guia de boas práticas para o alcance do sucesso. Uma das características positivas do Scrum é a adaptabilidade, ou seja, a aplicação das mesmas de formas variadas. Decisões de como usá-lo e criação de estratégias para chegar a uma produtividade maior e realizar entrega de artefatos mais rapidamente ficam por responsabilidade de quem está aplicando o processo (SCHWABER, 2004). 22

28 Segundo Ken Schwaber (2004), criador da metodologia, o Scrum, os papéis dos membros do projeto são bem definidos e estão dispostos como a seguir:» Product Owner: É o proprietário do produto, como o próprio nome diz. É quem se responsabiliza pelo financiamento do projeto. Define e prioriza requisitos e funcionalidades e aceita ou rejeita o resultado de cada iteração;» Scrum Team: É uma equipe formada por entre cinco e dez pessoas. Seleciona itens priorizados pelo cliente para serem executados durante a iteração, com liberdade dentro da mesma para cumprir seus objetivos e ao fim de cada uma delas gera uma versão do produto.» Scrum Master: Responsável pela garantia das práticas do Scrum. Verifica se o time está produtivo, mitiga e remove impedimentos que atrapalham o progresso do projeto e participa de todas as reuniões. O ciclo de vida do Scrum se inicia com a fase de planejamento (View), onde requisitos e possíveis restrições são definidos pelo cliente em um documento chamado Product Backlog. Os requisitos (itens) são priorizados, os recursos para o desenvolvimento de cada um deles são estimados e o Product Backlog é dividido em releases. Cada release contém um conjunto de requisitos priorizados, denominado Sprint Backlog, e estes irão ser desenvolvidos em iterações denominadas Sprints. É aconselhável que cada Sprint dure de duas a quatro semanas gerando um produto ao final. Logo, é essencial que durante a construção do produto, os Sprints possuam o mesmo tempo de duração (Time-Box). Nessa fase Sprint Planning Meeting também são escolhidos os membros da equipe de desenvolvimento, as ferramentas que serão utilizadas e possíveis impedimentos. Durante a execução de cada uma das Sprints, o time realiza reuniões diárias de aproximadamente quinze minutos para acompanhar o andamento do projeto (Daily Scrum Meeting). As variáveis técnicas do ambiente que foram especificadas anteriormente são controladas nessa fase de desenvolvimento. Ao contrário das metodologias tradicionalistas, o Scrum considera essas variáveis durante todo o processo, não apenas na inicialização do projeto, aumentando com isso a flexibilidade em relação à adequação de mudanças. Ao final de cada Sprint, é realizada uma reunião de revisão denominada Sprint Review Meeting, onde o time mostra o resultado ao cliente e ao Scrum Master. Por fim, o Scrum Master realiza uma reunião com sua equipe (Sprint Retrospective Meeting) analisando a execução do progresso do projeto e a versão do produto 23

29 gerada. Essa reunião tem por objetivos melhorar o processo, a equipe e o produto para o próximo Sprint. A Figura 5 ilustra de forma simples o ciclo de desenvolvimento do Scrum. Figura 5 Ciclo de Desenvolvimento do Scrum Fonte: Improve It (2009) Extreme Programming Para Kent Beck (2000), criador da Extreme Programming, XP é uma metodologia ágil para pequenas e médias equipes desenvolvendo software com requisitos vagos e em constante mudança. Extreme Programming usa times integrados de programadores, clientes, e gerentes para desenvolver software de alta qualidade em velocidade alta. Reúne também um conjunto de práticas de desenvolvimento de software já testadas, que quando estimuladas as sinergias entre elas, gerarão vastas melhorias em produtividade global e satisfação do cliente (JEFRIES, 2009). Extreme Programming é uma disciplina de desenvolvimento de software baseada nos valores simplicidade, comunicação, realimentação e coragem. Trabalha reunindo o time inteiro na presença de práticas simples e através do feedback permite à equipe observar onde a mesma se encontra e afinar as práticas para situações únicas. As raízes do XP estão na comunidade Smalltalk 8 com a colaboração íntima de Kent Beck e Ward Cunningham este, por sua vez, programador americano criador dos 8 Linguagem de programação orientada a objetos fracamente tipada. 24

30 conceitos de wiki, no final da década de No início dos anos 90 os dois refinaram suas práticas em numerosos projetos, estendendo o desenvolvimento de software adaptável e orientado a pessoas. O passo mais importante, da prática informal para uma metodologia aconteceu na primavera de Kent foi convidado para revisar o andamento de um projeto de folha de pagamento para a montadora de veículos. Este estava sendo desenvolvido em Smalltalk por uma empresa contratada e estava em dificuldades. Devido à baixa qualidade da base de código, Kent sugeriu que fosse jogado todo fora, iniciando a partir daí o projeto Chrysler C3 que serviu como uma base de aplicação e treinamento para o XP (FOWLER, 2000) Valores de Extreme Programming O XP é uma disciplina de desenvolvimento de software baseada nos seguintes valores: comunicação, simplicidade, feedback e coragem. Ele também prega 12 práticas que projetos de XP devem seguir. Muitas destas práticas são antigas, experimentadas e testadas. Ainda que esquecidas por muitos, são incluídas na maioria dos processos planejados. Com base nestas técnicas, XP tece uma sinergia entre elas onde cada uma é reforçada pela outra. (FOWLER, 2000). A seguir descrevem-se detalhadamente os valores da metodologia XP: Comunicação Uma equipe de XP prospera ao entender e compartilhar o problema e o software. O método mais eficiente e efetivo de alcançar compartilhamento é tendo uma comunicação face a face. Qualquer obstáculo que obstrua a comunicação eficiente precisa ser removida. O valor de comunicação representa a convicção da metodologia XP de que a chave para um projeto próspero é a comunicação entre os membros do projeto (e consequentemente precisa ser apoiado através de práticas). Não é declarado por que comunicação é tão importante, mas é seguro assumir que a comunicação é vista como um valor fundamental para a coordenação e colaboração em um projeto (RIEHLE, 2000). O XP procura manter a fluência da comunicação através da utilização de diversas práticas que não podem ser feitas sem comunicação. Estas práticas fazem sentido em curto prazo, como testes de unidades, programação em pares e estimativas de tarefas. Como consequência destas práticas é que programadores, gerentes e clientes precisam se comunicar. É importante lembrar, que em se tratando do valor comunicação em XP, sempre significa comunicação verbal (BECK, 2000). 25

31 Simplicidade A simplicidade visa a facilitação contínua do design do software, não adicionando partes desnecessárias ao código, mantendo-o claro, com nomes significativos e algoritmos sempre quebrados em partes menores, para que não possua código nem funcionalidade duplicados. A flexibilidade adicionada logo no começo do design pode ser desnecessária e tornar o software complexo, o melhor estado do software no momento da mudança é o simples (BECK, 2000). O valor da Simplicidade representa a convicção do XP de que não se deve investir no futuro, mas só nas necessidades imediatas do projeto. Estando subentendida neste valor, há a suposição que o futuro não pode ser predito confiantemente e preocupar-se com isso hoje não é economicamente inteligente (RIEHLE, 2000). Complementando, o valor Simplicidade prega que se mantenha o sistema tão simples quanto possível. Isso significa não gastar tempo e esforço para implementar características que podem não ser necessárias depois. Projetos de XP constroem o mais simples possível, confiantes de que pode ser mudado depois a pequeno custo adicionado. Simplicidade e comunicação possuem uma relação de apoio mútuo. Quanto mais contínua é a comunicação, mas evidente fica o que deve e o que não deve ser feito. A simplicidade deve ser aplicada em todas as atividades do processo, procurando sempre o mais simples que possivelmente funcione (HAYES, 2001) Feedback O valor feedback significa que é importante ter um sistema rodando a qualquer hora. Isso dá para o desenvolvedor a informação fidedigna sobre seu funcionamento (aqui o feedback não está direcionado aos seres humanos mas, sim a respeito do estado de desenvolvimento). Efetivamente, o sistema e seu código servem como o oráculo incorruptível para informar sobre o progresso e estado do desenvolvimento. O feedback também é um meio para orientação e tomada de decisão, para onde ir (RIEHLE, 2000). O posicionamento concreto do estado corrente do projeto é absolutamente essencial, fazendo que todo o problema seja evidenciado o mais cedo possível para que possa ser corrigido o quanto antes, da mesma forma fazendo com que as oportunidades sejam descobertas o mais precocemente possível para que possam ser mais bem aproveitadas. O feedback funciona em conjunto com comunicação e simplicidade. Quanto mais feedback 26

32 existir, mais fácil será a comunicação. Se os indivíduos envolvidos no projeto estiverem se comunicando claramente, aprenderão sobre o sistema e saberão o que testar Coragem Equipes prósperas de desenvolvimento de software precisam constantemente trabalhar na extremidade do caos, eles precisam agir rapidamente sem perder o controle. Isto às vezes significa cometer algumas falhas, mas sem perder a coragem para se tomar as decisões certas mesmo quando se pressionado para fazer outra tarefa (HAYES, 2001). Na verdade é preciso que a equipe não tenha medo de: parar quando se está cansada; deixar as decisões do negócio para o cliente; apontar um problema no projeto; pedir ajuda ao parceiro e aos clientes quando necessário; simplificar o código que já está funcionando; dizer ao cliente que não será possível implementar um requisito no prazo estimado; fazer alterações no processo de desenvolvimento, ou muitas vezes jogar o código fora e recomeçar. Para tudo isto é preciso muita coragem (LONGMAN, 1998). Os valores de comunicação, simplicidade, feedback e coragem servem como suporte para as doze práticas do XP, que serão apresentadas no tópico seguinte Práticas de Extreme Programming As doze práticas promovidas pelo XP se forem examinadas individualmente apresentarão falhas, mas uma das forças do XP é que as práticas se combinam de um modo mútuo apoiando-se. Juntas as práticas conduzem a um complexo comportamento emergente. Cada prática tem sua função para manter o custo de mudança baixo (HAYES, 2001). De acordo com BECK (2000) as doze práticas do XP são mapeadas em três categorias, a primeira englobando as práticas de programação, a segunda as práticas orientadas para a equipe e a terceira contempla os processos através dos quais a equipe de programação relaciona-se com o cliente. As práticas estão dividas nas categorias da seguinte forma: a) Programming Simple design (projeto simples), testing (testes), refactoring (reconstrução), coding standards (código padrão); b) Team - Collective ownership (código coletivo), continuous integration (integração continua), metaphor (metáfora), coding standards (código padrão), 40-hour week 27

33 (40 horas por semana), pair programming (programação em par), small releases (versões pequenas); c) Process - On-site customer (cliente no local), testing (testes), small releases (versões pequenas), planning game (planejamento do jogo) Simple Design Manter o custo de manutenção baixo significa manter o design tão simples quanto possível. Também significa não implementar funcionalidades (features) que podem ou não serem utilizadas mais tarde. Em um projeto XP se constrói as funcionalidades tão simples quanto possível, acreditando que elas poderão ser alteradas mais tarde com um pequeno custo adicional (HAYES, 2001) Testing Todo o requerimento é refletido em um teste de aceitação. Os testes de aceitação são produzidos pelos próprios clientes. Os programadores escrevem os casos de teste antes de escreverem o código, usam o teste para focar o que tem que ser alcançado e também para especificar a interface. Todos os testes são automatizados e executados regularmente (HAYES, 2001) Refactoring É o processo de melhorar o design do código sem afetar seu comportamento externo. O refactoring é feito de forma que o código seja mantido tão simples quanto possível, pronto para qualquer mudança futura (HAYES, 2001) Coding Standards Codificar é uma atividade de equipe. Com o passar do tempo pessoas diferentes trabalharão em diferentes pedaços do código, e disparidades de estilo de codificação e convenções fazem o código mais difícil de trabalhar. Para a equipe ser efetiva precisa-se de um código padrão, do qual ao ser visto parece ser escrito pela mesma pessoa (HAYES, 2001) Collective Ownership Qualquer pessoa da equipe pode alterar qualquer código, contanto que apoiado por um parceiro, obedecendo aos padrões e assegurado por todo o trabalho de testes quando 28

34 eles terminarem. O benefício disto é que remove os gargalos e os problemas de distorção de arquitetura que podem surgir (HAYES, 2001) Continuous Integration A equipe XP trabalha em etapas curtas e integra o código periodicamente. Isto significa que os problemas de integração são descobertos logo ao serem criados, desta forma é razoavelmente fácil retificá-los. Integração contínua evita desenvolvimentos incompatíveis e ajuda assegurar que toda a equipe esteja trabalhando na mais recente versão do sistema todo o tempo (HAYES, 2001) Metaphor A metáfora de sistema dá para a equipe um vocabulário consistente para discutir os problemas e suas soluções. Significa falar sobre o sistema em termos de objetos de negócio (HAYES, 2001) Hour Week Desenvolvimento de software é um exercício criativo, e ninguém pode ser criativo se está exausto. Restringindo o número de horas por uma semana de trabalho mantém as pessoas descansadas, reduz a sobrecarga e melhora a qualidade do produto acabado (HAYES, 2001) Pair Programming Toda a produção de desenvolvimento é feita por duas pessoas que compartilham uma máquina. Isto é muito mais eficiente que ter duas pessoas programando separadamente. Os pares frequentemente giram. Desta forma, o conhecimento e a experiência circulam pela equipe e também o código é revisado continuamente (HAYES, 2001) Small Releases Os releases devem ser tão pequenos quanto possível, agregando bastante valor ao negócio. Equipes de XP podem executar lançamentos em ciclos de algumas semanas, porque estão trabalhando em passos pequenos, têm testes para efetuar uma regressão, e estão integrando continuamente. Alguns projetos de XP executam lançamentos diariamente (NERUR, 2005). 29

35 On-Site Customer Nenhuma exigência escrita está completa e sem ambiguidade. Os programadores sempre precisam ter acesso a um cliente para esclarecer os requisitos, não importando a quantidade de esforço dedicada na especificação original. Uma equipe de XP mantém isto simples saltando muito o esforço destinado para a especificação, e tendo um cliente todo o tempo disponível para os programadores. Programadores de XP não adivinham os detalhes de uma feature. Pelo contrário, eles perguntam para o cliente (HAYES, 2001) Planning Game Classifica as negociações regulares em cima das funcionalidades que acontecem em um projeto de software e as transforma em um jogo. O Jogo de Planejamento é realizado em repetição para determinar que funcionalidade irá ao próximo lançamento. Programadores tomam decisões técnicas (estimativas) e os clientes tomam decisões empresariais, selecionando as funcionalidades com a maioria de benefícios (HAYES, 2001). Figura 6 Práticas do XP Fonte: Beck (2000). 30

36 CAPÍTULO 3 Estudo de Caso: TrainingCad No capítulo anterior foram explanados vários conceitos sobre as metodologias de gerência de projetos tradicionais e ágeis, assim como, conceitos do Scrum, XP e a importância de sua utilização para o sucesso do produto final. O conteúdo descrito no Capítulo 2 visa facilitar o entendimento do funcionamento do processo de gerência e desenvolvimento do projeto TrainingCad, a razão da utilização desse método e todas as etapas que compuseram o processo. Nesse capítulo também será apresentado o contexto do estudo comparativo, os detalhes do projeto e de seu desenvolvimento, além de uma proposta de mudança de metodologia de gerência do projeto de RUP para Scrum alinhado às praticas do XP. 3.1 Contextualização A UPE Consultoria Jr. é uma empresa júnior criada pelos cursos de Sistemas de Informação e Administração com Ênfase em Marketing de Moda do campus Governador Miguel Arraes de Alencar da Universidade de Pernambuco. Este campus se situa no agreste pernambucano, mais especificamente na cidade de Caruaru. O cenário acadêmico onde se encontra essa empresa júnior destaca as atividades de ensino e aprendizado de tecnologias e conceitos inerentes ao processo de desenvolvimento e gestão de software. Por esse motivo, a presidência da empresa, juntamente ao seu restante, tomou a decisão de criar o Núcleo de Treinamento. O Núcleo de Treinamento da UPE Consultoria Jr. é a fatia da empresa responsável pela qualificação tanto dos seus próprios funcionários quanto dos alunos/clientes inscritos em aulas, palestras, mini-cursos ou workshops. A responsabilidade da criação, organização e desenvolvimento inclui-se coordenação também foi atribuída ao Núcleo de Treinamento. 31

37 Inicialmente, o Núcleo de Treinamento contava com oito pessoas. Durante a organização de um evento, a coordenadora do núcleo, Cláudia César, percebeu a necessidade de introdução de métodos de gerenciamento de inscrições dos clientes nos cursos promovidos pelo próprio núcleo. Então, propôs a criação de software que não apenas gerenciasse, mas também tornasse os processos do desenvolvimento dos cursos mais rápidos. Após a apresentação da proposta à Universidade e à presidência da empresa, houve a aprovação. Foram, então, atribuídos os papéis e as tarefas do projeto a alguns dos integrantes do Núcleo de Treinamento:» Gerente de Projeto;» Engenheiro de Software;» Desenvolvedores (dois integrantes). O processo de desenvolvimento escolhido foi o RUP, por ser a metodologia que já estava em uso na empresa. O conhecimento sobre a metodologia foi o ponto crucial para sua escolha, já que na disciplina de Engenharia de Software do curso de Sistemas de Informação todos os envolvidos eram alunos desse curso a explanação sobre o processo é intensa. A coordenadora do Núcleo de Treinamento, baseada num dos próximos cursos a ser desenvolvido e baseada também nos prazos dos contratos de estágio dos alunos, definiu uma data base para entrega do produto final do projeto: 12 de junho de Após isso, foi definido um cronograma pelo gerente do projeto, incluindo as tarefas a ser realizadas e os documentos a ser confeccionados, sumarizando os marcos intermediários. Esse cronograma pode ser visualizado na Tabela 1. Tabela 1 Cronograma de Marcos Sumarizado do TrainingCad Cronograma de Marcos Sumarizado Apresentação do projeto à universidade 22 de março de 2009 Planejamento do projeto 14 de abril de 2009 Modelagem do negócio e levantamento de requisitos 20 de abril de 2009 Análise e projeto 24 de abril de 2009 Implementação 18 de maio de 2009 Testes 05 de junho de 2009 Fonte: Trainingcad,

38 3.2 TrainingCad O TrainingCad é um sistema desktop proprietário do Núcleo de Treinamentos da UPE Consultoria Jr. e tem por objetivo automatizar e padronizar os processos de inscrição de alunos/clientes em cursos da empresa. Ele foi desenvolvido de modo que pudesse atender às necessidades dessa empresa quanto aos processos utilizados, usando a experiência dos responsáveis pelo projeto na solução dos impedimentos. Segundo o termo de abertura do projeto, o projeto TrainingCad: visa desenvolver um sistema desktop de gerenciamento de inscrições (cadastro e consulta) de alunos em eventos realizados pela UPE Consultoria Jr. O sistema deve realizar operações tais como cadastro de qualquer evento realizado, a princípio, pelo Núcleo de Treinamento. O sistema deve realizar o cadastro de dados pessoais bem como a matrícula de cursos de interesse do cliente. O que permite a criação de um banco de dados e extração de informações relevantes, tais como o perfil do cliente. (TRAININGCAD - Termo de Abertura do Projeto, 2009, p.01). O projeto durou pouco menos de três meses de 23 de março a 12 de junho de 2009 e teve seu desenvolvimento guiado pelo método tradicional de desenvolvimento de software chamado RUP. Possuiu três papéis bem definidos:» Gerente de Projeto: Coordenou o projeto envolvido no processo, principalmente no que diz respeito à fatia inerentemente gerencial.» Engenheiro de Software: Arquitetou e coordenou o projeto sob o enfoque técnico e estrutural.» Equipe de desenvolvimento: produziram os artefatos de software propriamente ditos através do seguimento das premissas propostas pela gerente do projeto e obedecendo aos parâmetros de arquitetura de software anteriormente definidos. O método de desenvolvimento escolhido foi o RUP, pelo fato da empresa já possuir projetos que usavam o mesmo processo. Ou seja, a principal motivação para uso do RUP foi a prévia experiência da equipe adquirida no desenvolvimento de outros projetos passados. A Figura 7 exibe a tela de início do TrainingCad. Esta tela foi construída baseada em requisitos definidos pelos futuros usuários do aplicativo: os membros do Núcleo de Treinamento. 33

39 Figura 7 Tela Principal do TrainingCad Fonte: Trainingcad (2009). A principal restrição durante o andamento do projeto foi o prazo. O software deveria ser entregue impreterivelmente até o dia 12 de junho de Este projeto apresentou também uma intensa caracterização e hierarquia de papéis. Além disso, seu processo de gerenciamento teve foco inicial em estimar o tempo, gerenciar recursos de software, de hardware e humanos minimizar os riscos e monitorar os requisitos e cronograma. Um dos maiores problemas identificados no Núcleo de Treinamento da UPE Consultoria Jr. foi a falta de controle sobre o perfil dos seus clientes. Não eram arquivados, ou analisados, ou ainda estudados, os tipos de alunos/clientes que frequentavam os cursos. Por esse motivo, a criação deste sistema foi solicitada, o que só reforça sua importância dentro deste contexto aqui apresentado. 3.3 Gerenciamento e Desenvolvimento do Projeto A metodologia de gerenciamento e desenvolvimento escolhida para desenvolver o projeto TrainingCad foi o RUP. Essa metodologia foi escolhida por ser o método utilizado com constância na empresa. Desse modo, as disciplinas de gerenciamento dessa metodologia ditam que alguns documentos e tarefas teriam de ser realizados em relação à extensa formalização, se comparadas aos métodos ágeis. 34

40 Logo, foram definidos marcos durante a execução do projeto para a elaboração dos documentos necessários. O marcos definidos foram os seguintes:» Apresentação da Proposta à UPE Consultoria Jr.;» Elaboração do Plano de Projeto;» Elaboração do Documento de Requisitos;» Elaboração dos Documentos de Análise e Planejamento;» Entrega do 1º release;» Entrega do 2º release;» Elaboração do Documento de Testes;» Entrega do release final. Pode-se visualizar a disposição cronológica do gerenciamento desses marcos através do gráfico de Gantt 9 do projeto TrainingCad gerado pelo aplicativo dotproject (Figura 8). Figura 8 Gráfico de Gantt do TrainingCad Fonte: Trainingcad (2009). Após a apresentação à universidade, iniciou-se a fase de planejamento do TrainingCad. No planejamento houve a predefinição do modo de gerenciamento de variáveis do projeto. Comportamento em relação à mudança na lista de requisitos, decisões a serem tomadas de acordo com a tabela de estimativa de riscos, entre outros. Nessa fase, também foi modelado o negócio e elicitados os requisitos. Na Tabela 2 e 3 pode-se observar todos os 9 Um gráfico usado na gerência de projetos para planejar e acompanhar o progresso do projeto. O tempo é indicado por colunas atravessadas no gráfico, com tarefas individuais representadas por flechas terminando em pontos. O tamanho e posições das flechas mostram a data de início e a duração das tarefas. Você também pode usar linhas sólidas ao invés de flechas terminando em pontos. 35

41 requisitos funcionais e não-funcionais definidos a partir da confecção do documento de requisitos do projeto TrainingCad. Tabela 2 Requisitos Funcionais do TrainingCad Identificação Descrição Prioridade RF-01 Efetuar Login Essencial RF-02 Efetuar Logout Essencial RF-03 Incluir Aluno Essencial RF-04 Atualizar Aluno Essencial RF-05 Excluir Aluno Essencial RF-06 Consultar Aluno Essencial RF-07 Incluir Curso Essencial RF-08 Atualizar Curso Essencial RF-09 Excluir Curso Essencial RF-10 Consultar Curso Essencial RF-11 Realizar Inscrição Essencial RF-12 Alterar Inscrição Essencial RF-13 Cancelar Inscrição Essencial RF-14 Consultar Inscrição Essencial RF-15 Criar Conta de Usuário Essencial RF-16 Alterar Senha de Usuário Essencial RF-17 Excluir Conta de Usuário Essencial RF-18 Gerar Relatórios Desejável Fonte: Trainingcad (2009). Tabela 3 Requisitos Não-Funcionais do TrainingCad Identificação Descrição RNF/PROC-01 O sistema deve ser implementado na linguagem Java, com foco para computadores desktops. RNF/PROC-02 Toda atualização nas informações tratadas devem ser realizadas no servidor. Deverá ser feita uma documentação que contenha o diagrama de classes, já RNF/PROC-03 que a linguagem utilizada será orientada a objetos, e informações sobre o código-fonte do projeto. RNF/EXT-01 Não deverá existir custo adicional para a implantação e desenvolvimento do sistema. RNF/CONF-01 Implementação de mecanismos de segurança e integridade dos dados manipulados durante a execução do sistema. RNF/CONF-02 O espaço disponível em disco para informações deve ser capaz de armazenar todos os dados/atualizações que forem adicionados no sistema. RNF/SEG-01 Restrição de acesso e funcionalidades com definição de senhas. RNF/USA-01 Robustez para atender ao acesso simultâneo de usuários às bases de dados. RNF/USA-02 Alto tratamento de exceções para conseguir recuperação de eventuais erros do sistema. RNF/USA-03 Uso de interface amigável para permitir a utilização do sistema em toda a sua potencialidade. Fonte: Trainingcad (2009). Na apresentação da proposta, foram definidos os objetivos, a demanda e o escopo do projeto. No plano de projeto foram traçados os métodos e formas de gerenciamento de 36

42 cada uma das disciplinas do RUP envolvidas no desenvolvimento do TrainingCad. A partir daí, iniciaram-se os trabalhos da fase de modelagem de negócio e levantamento de requisitos. Nessa fase foram elicitadas as funcionalidades que o sistema TrainingCad deveria possuir, além da construção do diagrama de Casos de Uso 10 (Figura 9). Figura 9 Diagrama de Casos de Uso do TrainingCad Fonte: Trainingcad (2009). Após isso, foram planejados os aspectos funcionais do projeto. Foi definida a relação entre as tarefas e as estimativas de tempo do projeto, foram definidos os recursos disponíveis e necessários a sua evolução. Nesse momento também foram definidos o gerenciamento de requisitos e cronograma (Tabela 4), como também o gerenciamento de riscos (Tabela 5). 10 Um tipo de diagrama que descreve a sequência de eventos de um ator que usa um sistema para completar um processo e o detalhamento de cada um deles. 37

43 Tabela 4 Cronograma detalhado do TrainingCad Tarefa Dependência Resp. Atividade Início Fim T1 - Gerente T2 - Gerente T3 - Gerente e Engenheiro T4 T3 Engenheiro Apresentação da Proposta à UPE Consultoria Jr. Elaboração do Plano de Projeto Elicitação de Requisitos e modelagem Elaboração do Documento de Requisitos 14/04/ /04/ /04/ /04/ /04/ /04/ /04/ /04/2009 T5 - Gerente e Engenheiro Análise e Planejamento 24/04/ /05/2009 T6 - Desenvolvedores e Engenheiro 1º release 08/05/ /05/2009 T7 T6 Engenheiro Entrega do 1º release 21/05/ /05/2009 T8 T7 Desenvolvedores e Engenheiro 2º release 22/05/ /06/2009 T9 T8 Engenheiro Entrega do 2º release 04/06/ /06/2009 T10 - Engenheiro Elaboração do Plano de Testes 05/06/ /06/2009 T11 T10 Desenvolvedores Execução do Plano de Testes 09/06/ /06/2009 T12 T11 Desenvolvedores e Elaboração do Engenheiro Documento de Testes 11/06/ /06/2009 Fonte: Trainingcad (2009). Tabela 5 Gerenciamento de Riscos do TrainingCad Risco Probab. Dano Estimado Aceitab. Mitigação Falta de horário para as reuniões semanais, em vista que os componentes possuem horários divergentes. Troca de funções dos componentes durante o projeto, acarretando atraso no cronograma. Cronograma do projeto estourar. Mudanças nos requisitos durante a implementação, em função da pouca clareza das especificações dos requisitos. O sistema depois de entregue ao cliente gerar valores incompletos ou incorretos. O sistema, depois de entregue, não ter o desempenho ideal para a realidade da empresa. Fonte: Trainingcad (2009). Moderado Moderado Moderado Tolerável Baixo Muito Baixo Muito Baixo/Baixo Aceitável Moderado Alto Moderado/Alto Não aceitável Baixo Alto Moderado Tolerável Muito Baixo Baixo Moderado Baixo Aceitável Muito Alto Moderado/Alto Não aceitável Mitigar: Acompanhar e cobrar, através de , que todos compareçam às reuniões quando essas forem marcadas. Mitigar: Ajustar novo cronograma e acompanhar de forma maior o cronograma do novo programador. Evitar: Controlar de forma rigorosa o cronograma. Mitigar: Realizar, sempre quando houver mudança nos requisitos. a validação dos mesmos junto ao cliente. Mitigar: Reunir equipe e reparar bugs. Evitar: Controlar, rigorosamente, durante todo o projeto os requisitos não funcionais de desempenho. Depois de cumprida mais esta tarefa, foi realizada a análise de cada um dos casos de uso, aplicando as regras de engenharia de software. Foram feitos a descrição sumária, definidos os atores envolvidos, especificadas as classes de análise e criados os diagramas de 38

44 Sequência 11 (Figura 10) e de Classes 12 (Figura 11) para cada um dos requisitos funcionais do projeto. Figura 10 Diagrama de Sequência do Requisito Funcional Efetuar Login do TrainingCad Fonte: Trainingcad (2009). 11 é um diagrama que representa a sequência de processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. 12 é uma metodologia usada para descrever os tipos de objetos no sistema e os vários tipos de relacionamento estático existente entre eles, bem como atributos e operações de uma classe e as restrições. 39

45 Figura 11 Diagrama de Classes do Requisito Funcional Efetuar Login do TrainingCad Fonte: Trainingcad (2009). Após a fase de planejamento do projeto, se deu a fase de desenvolvimento propriamente dito. Essa fase se deu em três iterações: primeiro release, segundo release e release final. Durante esta fase, a equipe de desenvolvimento juntamente ao engenheiro de software, construiu o produto resultante do projeto TrainingCad. Todos os arquivos e códigos do sistema eram depositados no repositório do próprio projeto, que se encontrava no aplicativo dotproject, adotado pela empresa. Todas as diretrizes de engenharia e arquitetura do software definidas nos documentos de requisitos e análise foram seguidas pela equipe de desenvolvimento. O primeiro release gerou uma versão beta do projeto. Essa versão continha apenas o esqueleto da aplicação e algumas das telas da versão definitiva. A Figura 12 apresenta a tela referente à funcionalidade de cadastro de alunos. 40

46 Figura 12 Tela de Cadastro de Alunos do TrainingCad Fonte: Trainingcad (2009). No segundo release foram entregues todas as funcionalidades finalizadas, aguardando apenas os testes, seguidos das possíveis correções e melhorias. Após a aplicação exaustiva dos planos de teste através do uso de ferramentas adequadas para o trabalho, pôde ser então entregue o release final. Apenas como maneira ilustrativa, na Figura 13 é apresentada a tela de consultas do TrainingCad em sua versão final, oferecendo as funcionalidades de consulta, listagem e geração de relatórios de alunos, cursos e inscrições. Inserido no contexto dessa fase, se deu início ao planejamento de testes. Foi elaborado pelo engenheiro de software um plano de testes, o qual foi executado após a entrega dos primeiro e segundo releases marcos anteriormente determinados para se obter um retorno sobre o estado do software e quais modificações ou reparos deveriam ser realizados. Finalizados os procedimentos de testes e corrigidos os erros encontrados, o próximo passo foi a elaboração do documento de testes, onde se encontravam os planos de testes, os procedimentos realizados e os resultados obtidos. A seguir pode-se ver brevemente uma das tabelas de estratégia de testes (Tabela 6). 41

47 Figura 13 Tela de Consultas do TrainingCad Fonte: Trainingcad (2009). Tabela 6 Tabela de Estratégia de Teste de Stress do TrainingCad Teste de Stress Objetivo do teste Analisar o comportamento do sistema sob condições adversas. Técnica Rodar o sistema em uma máquina com configuração inferior a 256 MB de RAM e velocidade de CPU igual ou inferior a 900 MHz. Critério de Finalização Os dados de saída são expelidos conforme o esperado para as entradas válidas e no tempo estimado nos requisitos não-funcionais. Se o tempo de resposta for 100 vezes superior ao tempo máximo estimado para um único cadastro, então o teste falhou e o sistema está ineficiente. Considerações Especiais Não há. Fonte: Trainingcad (2009). 42

48 3.4 Proposta de Aplicação do Scrum O grande objetivo deste trabalho é comparar as características assumidas pelo projeto com as características esperadas do desenvolvimento do mesmo projeto tomando por metodologia de gerenciamento o Scrum aliado às práticas de desenvolvimento do XP. Para isto, é necessário então que se apresente uma proposta para desenvolvimento baseada no método escolhido, permitindo assim uma melhor estimativa dos resultados. Na próxima seção esta proposta é apresentada com base em todo referencial teórico pesquisado em termos de métodos tradicionais e ágeis aliados à experiência no TrainingCad. Na Revisão da Literatura (Capítulo 2) foram vistas as características das metodologias em questão. Levando-se em conta o perfil dos integrantes, do projeto e de seu proprietário, será demonstrada a forma com que o Scrum, junto ao XP, será aplicado ao gerenciamento e desenvolvimento do projeto TrainingCad Proposta Esta proposta se baseia nas premissas básicas de métodos ágeis mais fortemente atreladas ao Scrum. Neste caso, a partir desta proposta torna-se possível prever algumas mudanças, por meio da análise comparativa realizada, para uma possível reimplementação do mesmo projeto ou de outros que possuam características similares. Como promotor das novas tarefas de gerenciamento do projeto TrainingCad, o Scrum, auxiliado pelo XP, irá guiar o gerente de projeto no caso Scrum Master na coordenação destas mesmas tarefas. A fase de visão (View) deverá iniciar-se e o Product Backlog deverá ser criado juntamente ao proprietário do produto, bem como suas divisões e a quantidade de releases. A equipe do projeto, então, deverá definir o Time-Box de cada um dos Sprints para respeitar o calendário de marcos sumarizado definido pela gerente do Núcleo de Treinamento. Seriam implementados o Planning Game, as User-Stories e o Burndown Chart 13 especificando a definição dos requisitos extremamente essenciais ao sistema (simple design). Após isso, se iniciará a codificação do projeto em si, em duplas (pair programming) para que pequenos releases sejam entregues de acordo com os Sprints definidos anteriormente. Essa 13 Representação gráfica do trabalho a fazer em função do tempo. O trabalho pendente (ou atraso) é representado freqüentemente no eixo vertical, enquanto o tempo é representado longo da horizontal. 43

49 codificação seria padronizada para que no revezamento o código escrito seja compreendido por todos os membros da equipe do projeto. Enquanto isso, as User-Stories seriam usadas como insumo para desenvolvimento dos casos de testes e seus scripts para serem realizados ao final de cada release (Testing). Também seriam realizadas reuniões diárias para verificação e remoção dos impedimentos que surgiram ao longo do dia anterior pelo gerente do projeto (Daily Scrum Meeting). E, por fim, ao final de cada um dos Sprints, seria realizada uma reunião para demonstrar ao cliente o release respectivo (Sprint Review Meeting) e analisar a execução do progresso do projeto (Sprint Retrospective Meeting) até o fim do número de iterações definido no início do projeto, respeitando os prazos. Dessa forma, a quantidade de integrantes dedicados à documentação diminuiria. Essa força de trabalho estaria agora direcionada a outras atividades como o Refactoring e o contato constante com o cliente (client on-site). O tempo de desenvolvimento do projeto também poderia diminuir, já que a fase de planejamento diminuiria consideravelmente. O ciclo de desenvolvimento não se daria mais em duas iterações releases mas em quatro, pois o Scrum adota duas semanas como tempo mínimo para uma iteração, e de acordo com o perfil do projeto em questão, embasado no Capítulo 2, dois meses seriam suficientemente aceitáveis. A documentação do software teria uma redução extrema, caindo de oito artefatos para apenas quatro: Product Backlog, Planning Game, User-Stories e Burndown Chart. Com isso a hierarquia de papéis mudaria também. Agora o engenheiro de software passaria a integrar o time de desenvolvimento junto a um dos desenvolvedores. O antigo gerente do projeto passaria à condição de Scrum Master. Por fim, o custo de desenvolvimento do projeto diminuiria bastante, além de ser concluído em menor tempo, justamente por ser a metodologia exatamente aplicável ao tamanho, tempo e custo do projeto. De forma ilustrativa, encontram-se nas Figuras 14 e 15 o ciclo de desenvolvimento anterior à proposta e o ciclo resultante da proposta de aplicação do Scrum alinhado ao XP. 44

50 Figura 14 Fases do Ciclo de Desenvolvimento anterior à Proposta Fonte: Autor, adaptado de Pressman (2002). Figura 15 Ciclo de Desenvolvimento após aplicação da Proposta Fonte: Autor, adaptado de Improve It (2009). 45