CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM GERENCIAMENTO DE PROJETOS

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS

CAMPOS DOS GOYTACAZES/RJ 2011

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS

Monografia apresentada a FIJ – Faculdades Integradas Jacarepaguá, como requisito para conclusão do Curso de Pós-Graduação lato sensu em Gerenciamento de Projetos.

Orientador: Jorge Washington S. dos Santos

CAMPOS DOS GOYTACAZES/RJ 2011

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS

Monografia apresentada a FIJ – Faculdades Integradas Jacarepaguá, como requisito para conclusão do Curso de Pós-Graduação lato sensu em Gerenciamento de Projetos.

Aprovada em xx de xxxxxxxx de 2011. Banca Avaliadora:

....................................................................................................................................... Prof. Jorge Washington S. dos Santos

....................................................................................................................................... Prof.

....................................................................................................................................... Prof.

CAMPOS DOS GOYTACAZES/RJ 2011

AGRADECIMENTOS

Primeiramente agradeço a Deus, Doutor e Mestre por essência e excelência. Aos parentes e amigos que estiveram sempre presentes a apoiar-me em minhas dificuldades, bem como fornecer o devido auxílio, seja ele moral ou material. Enfim, a todos que colaboraram de alguma forma para que este trabalho fosse concluído com êxito.

As dificuldades crescem à medida que nos aproximamos do nosso objetivo. Johann Wolfgang Von Goethe .

RESUMO Este trabalho destina-se a fazer uma abordagem sistemática dos métodos de gerenciamento de projetos. visando atender as necessidades dos clientes. . Descreveremos os métodos mais importantes e suas respectivas vantagens e desvantagens. voltados especificamente para a área de desenvolvimento de software.

ABSTRACT This work is intended to make a systematic approach to project management methods. specifically tailored to the area of software development. We describe the most important methods and their advantages and disadvantages. to meet customer needs. .

LISTA DE ABREVIATURAS .

LISTA DE FIGURAS .

SUMÁRIO .

faz-se necessário que nos detenhamos na utilização de recursos que nos levarão à realização efetiva daquilo para o qual fomos designados ou contratados. em sua essência. que em certas áreas é tão rápida que se não estivermos atentos nos distanciaremos dela. segundo define o PMBOK (2004). recursos e controle. dependendo deles -. . Dessa forma. criando expectativas maiores no que se refere à agilidade e qualidade. Assim sendo. A competitividade nos mercados internacionais é fator preponderante dessa nova realidade. com isso. envolvendo planejamento. Diante disso. é um empreendimento temporário com o objetivo de criar um produto ou serviço único. onde aqueles que ficaram estagnados no tempo perderam seus lugares para outros que procuraram acompanhar tamanha evolução. diferente dos outros. Aquele. Em toda organização são desenvolvidos algum tipo de trabalho e esses são executados por pessoas – em maior ou menor número. significa que ele depois de concluído é. tornamo-nos parte de um sistema onde gerenciamos ou somos gerenciados. forçosamente.1. dessa forma tornando o mercado mais competitivo e. eles são divididos em projetos e tarefas. Estamos diante de pessoas mais exigentes e criteriosas com relação a produtos e serviços. INTRODUÇÃO A era de Globalização trouxe consigo mudanças que têm afetado sobremaneira os diversos processos de Gerenciamento de Projetos. Para que possamos atender as expectativas inseridas no contexto da demanda atual. a temporalidade aqui. temos que nos atualizar e nos adaptar aos novos rumos prescritos pela Era Moderna.

habilidades. que define projeto como um empreendimento com objetivos bem definidos. podemos citar. 2004) é a aplicação de conhecimentos. custos e recursos. da concepção à obtenção do produto. com o intuito de satisfazer ou exceder as necessidades e as expectativas dos stakeholders1 Como este trabalho está voltado para a área de software. Pressman também diz que para que um projeto de software seja bem sucedido. A Gerência de Projetos é definida. desde que ela acompanha todas as etapas do desenvolvimento. é necessário 1 Stakeholders são pessoas ou organizações que são afetadas pelo sistema e que tem influência direta ou indireta nos requisitos do sistema [PMBOK (2004)]. podemos acrescentar a definição de Gerência de Projetos dada por Pressman (1995) que diz que ela é uma tarefa de vital importância no processo de desenvolvimento de um produto. por exemplo. ou seja. A ABNT (NBR 10006) define que projeto é um processo único. custo e qualidade. . consumindo recursos e operando sob pressões de prazo. empreendido para alcance de um objetivo. KERZNER (2005). ferramentas e técnicas em atividades do projeto. incluindo limitações de tempo. Ainda no tocante à definição de projeto. consistindo de um grupo de atividades coordenadas e controladas com datas para início e término. conforme requisitos específicos.A alocação de recursos e o tempo de execução de um projeto são fatores determinantes para avaliar sua complexidade e nos levar a agir para que efetivamente levemos a cabo sua conclusão. sendo definida como a primeira camada deste processo e não é visto como uma etapa clássica do desenvolvimento. segundo o Project Management Body of Knowledge (PMBOK.

1. em sua maioria. fala sobre o Relatório Chaos Report (2004). em seu livro intitulado ‘Maturidade em Gerenciamento de Projetos’. mas antes por falta de conhecimento em gestão de projetos e que esse não é aplicado somente à figura do gestor. O Relatório Chaos realizado pelo Standish Group (1995) identificou que as empresas americanas gastaram $ 81 milhões em projetos de software que foram . os recursos e custos aplicados e a sistemática que deverá ser seguida. No ano de 1993. o Software Engineering Institute (SEI). verificou que o problema de maior relevância que preocupa as organizações de software é aquele relacionado com o aspecto gerencial. por falta de recursos ou acesso à tecnologia. GERENCIAMENTO DE PROJETO DE SOFTWARE Para que possamos nos deter com maior profundidade no tema deste trabalho. ao analisar os projetos de TI que falharam.que alguns parâmetros sejam corretamente analisados. afirma que isto não aconteceu. mas também de todos os integrantes da equipe. Darci Prado (PRADO. os recursos necessários. onde eram demonstradas que as principais causas do fracasso – falhas na execução e atraso na entrega – de um projeto de software estariam ligadas ao desempenho do gerenciamento do projeto. as tarefas a serem realizadas. os indicadores a serem acompanhados. Começaremos falando sobre pesquisas realizadas na década de 90. 2008). torna-se necessário falarmos um pouco sobre o gerenciamento de projetos de software. a saber: o escopo. os riscos envolvidos.1.

Também deve-se levar em conta alguns . 53% dos que foram concluídos excederam mais de 50% em sua estimativa de custo. considerando-se que a boa formação de uma equipe depende disto.Gerente de Projeto. Isso não se aplica somente aos projetos de software. . mas a toda atividade. mas com os mesmos objetivos. Programadores e Engenheiros de Testes). No que se refere às pequenas e médias empresas. .1.cancelados em 1995. 1. referentes às grandes organizações.Clientes. Denomina-se equipe o conjunto de pessoas que trabalham num projeto em diferentes tarefas. o números melhoraram em 28% e 16% respectivamente. Somente 9%. Projetistas.1 Partes envolvidas no Projeto de Software No projeto de Software há o envolvimento de várias pessoas que exercem diversos papéis. Os papéis de cada um devem ser bem definidos. .Desenvolvedor (Analistas.Gerente de Qualidade.Usuários. a saber: . 31% foram cancelados antes da sua conclusão. foram entregues no tempo e orçamentos previstos. . Destes. Esse relatório assinala o gerenciamento como principal responsável pelo sucesso ou falha de um projeto de software.

Segundo Pressman (PRESSMAN. 2005). . mas o consenso do grupo é quem determina a tomada de decisões. . 1. entre outros. o . tipo de projeto.1.Controlada Centralizada: há um líder e a comunicação entre ele e a equipe é vertical. do processo de software do projeto.Controlada Descentralizada: aqui há um líder. da elaboração de cronograma.elementos como relacionamento interpessoal. Pela própria natureza dos projetos. .2 O Processo do Gerenciamento do Projeto de Software A composição do processo de gerenciamento de software envolve três etapas principais: . da realização de estimativas. podemos classificá-las em vários tipos: . das estimativas feitas e do cronograma desenvolvido. da identificação e solução para os riscos agregados ao projeto. criatividade.Planejamento: é um plano bem organizado que define. não há um líder permanente. no início do projeto.Acompanhamento: No início do projeto existe pouca informação que possibilite evitar o comprometimento da precisão do escopo.Democrática Descentralizada: nesta. Ele tem como função abordar as definições do escopo do software. como esse será elaborado. ainda que a comunicação seja horizontal. no tocante à estrutura das equipes.

1. fazer alterações no processo do projeto e no cronograma. de riscos e de aquisições.conhecimento aumenta na medida em que estes avançam e. estão sempre sujeitos à modificações.1. do escopo. . da qualidade. identificar os problemas e suas causas. por fim. Como os projetos são dinâmicos e. de custos. de forma a se tornar um aprendizado para futuros projetos. monitorar riscos e tomar ações corretivas. dos recursos humanos. Abaixo faremos uma breve descrição de cada uma das referidas áreas. . das comunicações. Tudo isso deve ser feito com o envolvimento de toda a equipe. fazer refinamento no escopo e.Encerramento: Após o término do projeto. Aqui podemos fazer comparações entre o estimado e o realizado. torna-se fundamental acompanhar o seu progresso. passa-se para a análise do que deu certo e o que não funcionou conforme as especificações do projeto. existem nove áreas de conhecimento em gerenciamento de projetos. podemos ajustar e fazer um refinamento dos elementos supracitados. de tempo.3 Áreas de Conhecimento em Gerenciamento de Projetos Conforme cita o PMBOK (2004). assim sendo. a saber: gerenciamento de integração. dessa forma.

2 Gerenciamento de Requisitos A definição para requisitos.4 Gerenciamento de Tempo Envolve o controle das atividades para o cumprimento do cronograma e a confirmação dos marcos do projeto dentro das estimativas de prazo (VIEIRA. escopo é todo trabalho envolvido na criação dos resultados do projeto (VIEIRA. É a área que descreve os processos relacionados ao término do projeto dentro do prazo estimado.3. 1. 1. padrão.3.1.3.1 Gerenciamento de Integração Segundo Vieira.1. segundo SAYÃO E BREITMAN (2005) é: “uma capacidade de software que deve ser disponibilizada por um sistema ou componente de um sistema de modo a satisfazer um contrato. 2003).3. o Gerenciamento de Integração é a área responsável pela identificação e gerenciamento dos pontos de interação entre os elementos do projeto e o estabelecimento e manutenção da boa comunicação entre esses pontos. especificação ou outra formalidade imposta”. tão e somente. o trabalho necessário para que seja concluído com sucesso.1. 1. .3 Gerenciamento de Escopo De acordo com Vieira. O Gerenciamento de Escopo faz a descrição dos processos envolvidos na verificação de que o projeto inclui.1.1. 2003).

1. no que está implícita a satisfação dos clientes e usuários finais.1. no orçamento e controle de custos. ao desempenho do sistema.3.1.6 Gerenciamento de Qualidade Este tem por base a descrição dos processos envolvidos na garantia de que o projeto irá satisfazer as metas definidas a serem alcançadas por ele. na estimativa. 1. 1.3. De acordo com VIEIRA (2003). em alguns casos. além de estuda bem a tecnologia a ser utilizada. o gerenciamento e o planejamento das pessoas envolvidas no projeto são de fundamental importância. visando o término do projeto dentro do orçamento aprovado.1.7 Gerenciamento de Recursos Humanos Como é uma das principais fontes da produtividade no desenvolvimento de sistemas. especialmente para que os prazos sejam cumpridos.3.5 Gerenciamento de Custos Descreve os processos envolvidos no planejamento. o importante é não determinar custos antes da definição do requisito e do escopo. Vieira (2003) diz que a qualidade está ligada ao atendimento das necessidades do usuário final e. .

além dos processos de gerenciamento de contratos (VIEIRA.1. Depois de darmos algumas definições relacionadas ao Gerenciamento de Projetos e.3. Descrevendo de maneira sucinta suas vantagens e desvantagens e quando é mais viável utilizá-los.9 Gerenciamento de Aquisições Aqui são descritos os processos de compra ou aquisição de produtos. cuja temática envolve gerenciamento de projetos de software. No Capítulo 3 faremos uma abordagem sobre os métodos tradicionais e ágeis. 1. lidando com os métodos ágeis. coleta. O Capítulo 4 será destinado a uma pequena comparação entre os dois métodos.1. 2003). mas sem deixar de falar sobre os métodos tradicionais. em especial. . 2003). ao de software.1.3. serviços ou resultados. avançamos neste trabalho. armazenamento e destinação final das informações do projeto.8 Gerenciamento de Comunicações O gerenciamento de comunicações descreve os processos relacionados à geração. de forma oportuna e adequada (VIEIRA.

que têm sua fundamental atenção voltada para a qualidade dos processos e da produtividade. O desenvolvimento de software requer muita habilidade. no andamento do sistema.1. consequentemente. comumente marcada pelos verbos: codificar e consertar. uma longa fase de testes que confronta diretamente com o cronograma estabelecido. Quando o sistema é pequeno. Entretanto. tornam-se cada vez mais arraigados e. torna-se mais difícil implantar-lhe novos recursos e os defeitos que se subseguem. uma atividade normalmente muito confusa. se o projeto é de maior vulto. visto que na prática é. Segundo FOWLER (2000). não interferem. assim como para a redução de riscos. O sistema acima citado carrega consigo. . com as múltiplas decisões a serem tomadas em curto prazo.2. Elas fazem isso desenvolvendo um processo detalhado com uma forte ênfase em planejamento e inspiradas em outras disciplinas de engenharia. visto que as atividades de testes não deixam margem para uma previsão exata de tempo para a execução delas. JUSTIFICATIVA A acirrada competição no mercado de software tem como exigência principal a melhoria nos processos de desenvolvimento. difíceis de serem suprimidos. como característica. motivo pelo qual Fowler se refere a elas como “Metodologias de Engenharia”. as indefinições do plano inicial do projeto. Melhoria essa. metodologias impõem um processo disciplinado no desenvolvimento de software com a finalidade de torná-lo mais eficiente e previsível. em grande parte. sobremaneira.

para ter uma resposta plausível. surge um novo grupo que reage a elas. os métodos ágeis vêm se popularizando no Brasil nos últimos anos. Conforme FOWLER (2000). E continua. A princípio eram chamadas de metodologias “leves”. mas hoje o termo mais aplicado é metodologia ágil. pois existem casos em que é mais aconselhável adotar a metodologia tradicional. a cada dia surgem novos adeptos daqueles. De acordo com HIGHSMITH (2004). Ainda que os métodos ágeis ainda sejam vistos com desconfiança pelo gerenciamento tradicional. Não se trata aqui de colocar os métodos ágeis como a única alternativa para o desenvolvimento de software. dizendo que os métodos ágeis são menos centrados em documentação e de várias formas são mais voltados ao código-fonte do programa. de forma a prover o suficiente deles. o resultado disso é que os métodos ágeis têm algumas mudanças de ênfase significativas em relação aos métodos burocráticos ou tradicionais. .Sendo as metodologias supracitadas consideradas como burocráticas. Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto em um turbulento ambiente de negócios. ainda que acrescente que a estrutura em demasia gera a rigidez. Ele ainda enfatiza que a ausência de estrutura ou estabilidade pode levar ao caos. Pela utilização de uma abordagem simplificada. Agilidade é a habilidade de balancear flexibilidade com estabilidade. Essas metodologias tentam criar um meio termo entre a escassez e o excesso de processos.

1 Objetivo Geral O Objetivo principal deste trabalho é fazer uma análise das metodologias ágeis no gerenciamento de projetos de software em contraste com as metodologias tradicionais.3.3. através de pesquisas. levantando seus pontos comuns e divergentes. o objetivo de atender os requisitos propostos e a qualidade esperada pelos envolvidos no projeto. são baseados nos seguintes itens: • • Citar as metodologias ágeis mais relevantes no mercado.2 Objetivos Específicos Os objetivos específicos. OBJETIVOS A seguir. .3.Nossa proposta é analisar os métodos ágeis na sua função de alcançar a melhoria no desenvolvimento de software. 1. apresentaremos o objetivo geral e os específicos que serão desenvolvidos no decorrer deste trabalho. a aceitação da metodologia ágil no mercado. 1. 1. assim. • Fazer uma breve comparação entre os métodos ágeis e os tradicionais. Demonstrar. atingindo. que aqui serão tratados.

1. marcada pela pesquisa bibliográfica e também a eletrônica. . METODOLOGIA DE PESQUISA A metodologia de pesquisa utilizada neste trabalho foi. Também foram coletadas informações com professores do IFF – Campos dos Goytacazes. bem como a utilização de aulas da disciplina de Gerenciamento de Projetos do curso de Análise e Desenvolvimento de sistemas da referida Instituição. sobre desenvolvimento de software. em sua grande parte. Essas duas modalidades de pesquisa foram a base dos estudos necessários para que fosse possível adquirir conhecimentos que levasse a concretização do referido trabalho. Buscou-se também subsídios nos relatórios do Ministério da Ciência e Tecnologia.4.

fornecendo o suficiente de processo para a obtenção de um retorno aceitável. • Métodos ágeis são orientados a pessoas ao invés de serem orientados a processos. independentemente de quem os estiverem utilizando. INTRODUÇÃO Neste capítulo abordaremos a metodologia ágil nos seus diversos aspectos. o qual prega que a “prioridade é satisfazer o cliente através de entregas antecipadas e contínuas de software de valor”. entretanto. Para os métodos ágeis. Ele acrescenta que a maior diferença mais clara entre essa modalidade e a tradicional é que as metodologias ágeis são menos centradas em documentação.1. Métodos ágeis afirmam que nenhum processo jamais será equivalente à habilidade da equipe de desenvolvimento. ainda que menos documentação seja apenas um sintoma de duas diferenças mais profundas: • Metodologias ágeis uma são adaptativas parte do ao invés de de predeterminantes.5. a partir de um enfoque do Manifesto Ágil. De acordo com FOWLER (2000). CAPÍTULO I 1. Isso funciona bem até as coisas mudarem. até mesmo ao ponto de se auto-modificarem. Eles tentam ser processos que se adaptam e se fortalecem com as mudanças. . metodologias ágeis buscam criar um equilíbrio entre nenhum processo e muito processo. mudanças são bem-vindas. Então a natureza de tais métodos é a de resistir à mudança. O objetivo dos métodos de engenharia é de definir um processo que irá funcionar bem. Metodologias de engenharia tendem a tentar planejar grande processo desenvolvimento detalhadamente por um longo período de tempo.

1. Nossa abordagem não fará menção às controvérsias em torno do assunto. mas somente expor. Software em funcionamento mais que documentação abrangente. Nele são valorizados: • • • • Indivíduos e interações mais que processos e ferramentas. nos Estados Unidos da América. de maneira sucinta e clara. cujo intuito era determinar qual a visão de uma equipe de desenvolvimento de software. o papel do processo é dar suporte à equipe de desenvolvimento e seu trabalho. a metodologia ágil com suas características de usabilidade das principais metodologias utilizadas. desenvolvimento e entrega de software. HISTÓRICO Entre os dias 13 e 13 de fevereiro 2001. um grupo de dezessete especialistas (gestores e desenvolvedores) em desenvolvimento de software se reuniu em Utah. Nesse encontro foi assinado um documento chamado de “Manifesto para desenvolvimento ágil de software”.6. Colaboração com o cliente mais que negociação de contratos. . O Manifesto Ágil e formado por princípios e valores que devem servir de base para as equipes.Portanto. em geral. as metodologias ágeis dispõem de uma abordagem iterativa para especificação. Para SOMMERVILLE (2003). para discutir que práticas poderiam ser usadas para melhorar o desempenho de seus projetos. Responder a mudanças mais que seguir um plano.

3. a equipe deve refletir sobre como tornar-se mais efetiva. contudo. ajustar-se de acordo com seu comportamento. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. 2. 10. 11. requisitos e designs emergem de equipes auto-organizáveis. 8. que ser ágil é radicalizar ou defender que exista apenas uma solução para os projetos de desenvolvimento de software. Não significa. Em intervalos regulares. mesmo tardiamente no desenvolvimento. As melhores arquiteturas. 7. mas se dá preferência àqueles que estão colocados à esquerda. 9. Construa projetos em torno de indivíduos motivados. desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. . mas antes.Não são descartados os valores à direita. Contínua atenção a excelência técnica e bom design aumenta a agilidade. 5. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores. Simplicidade . O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. 6. Os princípios que norteiam o Manifesto são 12. Entregar frequentemente software funcionando. com preferência à menor escala de tempo. 4. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. 12.a arte de maximizar a quantidade de trabalho não realizado-é essencial. Mudanças nos requisitos são bem-vindas. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. e então. de poucas semanas a poucos meses. a saber: 1.

enquanto o projeto orientado a objetos é um método orientado para se executar a fase do projeto (YOURDON. 1995). . codificação. Método: abordagem técnica passo a passo para se realizar uma ou mais das principais tarefas indicadas numa metodologia global. testes) a serem executadas e indica quais pessoas (usuários. procurar para que haja conscientização da equipe. projeto. técnicos) devem estar envolvidas em cada atividade e que papéis deverão desempenhar. Dessa forma. metodologia incorpora todo o processo de desenvolvimento de software e método é aplicado em uma ou mais fases desse desenvolvimento. gerentes. Uma metodologia de software comumente identifica as principais atividades (análise. As metodologias frequentemente descrevem os critérios de entrada (essas condições devem ser satisfeitas antes de iniciar a fase de projeto). CONSIDERAÇÕES SOBRE METODOLOGIA E MÉTODO Existem diversas definições ou interpretações para metodologia e método. assim como a sua união.7.que ser Ágil é identificar e focar em objetivos bem definidos. a análise estruturada é um método para se realizar a fase de análise de um projeto. No entendimento de YOURDON (1995). 1995). 1. os critérios de saída e os pontos de conferência para decisões de prosseguir/não prosseguir (os usuários devem decidir ao final da análise se desejam continuar a financiar o projeto) (YOURDON. Yourdon dá a seguinte definição para metodologia e método: “Plano de batalha” ou livro de receitas passo a passo para se chegar a um resultado desejado.

o qual se refere como metodologia do gerenciamento de projetos. definindo-o assim: Os métodos de engenharia de software proporcionam os detalhes de “como fazer” para construir o software. os seguintes processos: . arquitetura de programa e algoritmo de processamento.Engenharia concorrente. É uma mistura de processos que nos dizem “o que deve ser feito”. teste e manutenção. 1995).Já PRESSMAN entende que método incorpora todo o processo de desenvolvimento de software.Gerência da Qualidade total. . KERNER (2001) diz que não é possível atingir a maturidade da gerência de projetos sem um processo repetitivo que possa ser usado em todos os projetos. mas não “como deve ser feito”.controle de Mudança de Escopo. Ele acrescenta que boas metodologias integram outros processos na gerência de projetos e. em nível estratégico. integraram numa única metodologia de gerência de projetos.8. uma metodologia fornece um plano. para planejar e controlar os processos de software. Os métodos da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada à linguagem especial e introduzem um conjunto de critérios para a qualidade do software (PRESSMAN. .Gerência de Projetos. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto. METODOLOGIAS DE GERENCIAMENTO DE PROJETOS De acordo com REHMAN (2007). codificação. . durante a década de 90. . várias organizações dos mais diversos ramos de atuação. projeto da estrutura de dados. análise de requisitos de software e de sistemas. 1.

Gerência de Risco. • Formato de relatórios padronizado. • Com base em um bom trabalho ético. a saber: • Um recomendado nível de detalhe. KERNER (2001) também enumera as características de uma boa metodologia. conforme necessário. • Utilização de modelos. programação e controle dos custos padronizado. • Prontamente aceito e utilizado em toda organização. • Baseado em orientações e não em políticas e procedimentos. • Técnicas de planejamento. tanto os internos quanto para os clientes. • Flexibilidade para uma rápida introdução de melhorias. • Flexibilidade para a aplicação em todos os projetos. • Fácil para que o cliente possa entender e seguir. baseada processos integrados.. . • Uso de fases do ciclo de vida padronizado.

1 SCRUM O SCRUM foi concebido por Takeuchi e Nonaka. METODOLOGIAS ÁGEIS De acordo com FOWLER (2003). como um estilo em gerenciamento de projetos em indústrias de automóvel e materiais de consumo. Ele aumenta significativamente a produtividade e reduz o tempo e reduz o tempo para obter . assim como outras metodologias de desenvolvimento. Abaixo faremos a descrição de algumas dessas metodologias para um maior entendimento de seus processos.9. Ainda que todas compartilhem algumas características. ainda que também possa ser utilizado em qualquer contexto. várias são as metodologias que estão dentro da categoria de ágeis. 1. SCRUM é um processo ágil e leve que utiliza práticas iterativas e incrementais para gerenciar e controlar o desenvolvimento de software. no artigo “The New Project Development Game”. A função primária do SCRUM é ser usado para o gerenciamento de projetos de desenvolvimento de software. existem algumas diferenças significativas entre elas. Takeuchi e Nonaka perceberam que projetos que se utilizavam de equipes pequenas e multidisciplinares produziam os melhores resultados.9. Ele tem sido usado com êxito para esse fim.1. onde um grupo de pessoas precise trabalhar junto para alcançar um objetivo comum.

resultados.1 Papéis do SCRUM Como qualquer metodologia. interessado no projeto.Team Members: pode ser considerado como um grupo de pessoas. As características do Team são: . antes que um papel. como indicado abaixo: . além de atender aos padrões CMMI e PMBOK.1.9. O Team Members é o grupo de pessoas ligadas diretamente ao trabalho a ser feito. Aceitar ou rejeitar os resultados do trabalho. 1. tendo em vista que facilita a adaptação a processos empíricos de desenvolvimento de sistemas. . de forma que se obtenha uma visão única dos requisitos do sistema. Suas responsabilidades são: • • Definir as funcionalidades do produto.Product Owner: Pode se tratar do financiador ou de alguém importante. Concentrar as informações vindas dos usuários. Poder alterar as prioridades fora do Sprint. stakeholders ou do mercado. O SCRUM foi adotado como ferramenta padrão de gerenciamento de projetos nas metodologias MSF for Agile e Open Up. o SCRUM é baseado em papéis e responsabilidades. • • • Priorizar o Product Backlog. que garantirá que o projeto seja entregue com todas as funcionalidades necessárias.

a fim de garantir que o cliente é quem realmente está direcionando as funcionalidades desenvolvidas.• • • Multifuncional. Formado por até 7 pessoas. Demonstra o resultado do Sprint para o Product Owner e outros Stakeholders. • • Remover impedimentos. Promover práticas de engenharia para que cada parte de funcionalidade seja potencialmente implantável. • Faz o que é necessário dentro das diretrizes do projeto. o SCRUM Master deve atender os seguintes requisitos: • Melhorar a vida e a produtividade do time de desenvolvimento promovendo o conhecimento e a criatividade. Gerencia os interesses do Product Owner através do Time. • • Garantir que o processo está sendo respeitado.SCRUM Master: Sua função está relacionada ao papel de líder. • • Proteger o time das interferências externas. para alcançar o objetivo do Sprint. Define o objetivo do Sprint e especifica o resultado do trabalho. . Estimular uma cooperação muito próxima entre todas as pessoas do time. Remover barreiras entre o desenvolvimento e o cliente. • • Auto-organizável. . Para ser eficiente.

. onde o Product Owner tem a oportunidade de atualizar a priorização dos itens do Product Backlog e definir juntamente com a equipe. Sprints: são iterações realizadas.2 Etapas de um Projeto com SCRUM Num projeto SCRUM existem. que é responsável por validar e/ou solicitar ajustes para que o jogo se torne adequado aos anseios do cliente. tais como: . .Daily SCRUM Meeting: É um encontro diário realizado pela equipe. . .Sprint Restrospective: tem como objetivo identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment e busca corrigir os erros encontrados.9. Este encontro é uma maneira eficiente de manter os membros cientes dos objetivos e evitar que o projeto se desvie do seu objetivo. um Product Increment a ser entregue ao cliente ao final do Sprint. .1.Sprint Review: é o momento em que a equipe exibe o Product Increment construído ao Project Owner. uma após outra.Criação do Product Increment: A finalização das estórias definidas para um determinado Sprint marca a realização do Product Increment. Dentro de cada Sprint são realizadas algumas atividades. Product Baccklog inicial e outras premissas ligadas ao projeto. onde os membros discutem aquilo em que trabalharam. as seguintes etapas (TEAM SYSTEM. 2004): • • Preparação: onde é definido o business-case. no que irão trabalhar e possíveis impedimentos que estejam atrapalhando o o progresso do trabalho.1.SCRUM Planning Meeting: é o início de um Sprint. para entregar gradativamente as estórias que compõem o jogo. basicamente. game concept.

.Encerramento: Como sugere o próprio nome. Fonte: http://mundoti.info/wp-content/uploads/2009/10 . Ele ocorre. é a última etapa de um projeto utilizando o SCRUM. Figura 1 – Ciclo do SCRUM..Atualização do Product Backlog: O Product Owner é responsável por re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado. motivado pelos itens mais prioritários. após a finalização de todos os Sprints e é marcada pela entrega do produto final que foi a causa da criação do projeto.

2 Extreme Programming (XP) De acordo com BECK (2004). Esses valores devem ser observados para que se tenha um melhor resultado da metodologia em questão. durante toda fase de desenvolvimento. ela é uma metodologia ágil. A Equipe da Extreme. Existem alguns valores na Extreme Programming.9. que definem como será o procedimento da equipe durante o processo de desenvolvimento. para pequenas e médias equipes.Comunicação: A equipe de desenvolvimento deve. se reúne diariamente com o cliente e. Os outros o complementam e lhe dão suporte. digitar menos código.Feedback: segundo TELES (2004). esse é o primeiro e talvez o mais importante dos valores do XP. mas antes ir de encontro à funcionalidade desejada pelo cliente.Simplicidade: No XP. para que ocorra o Feedback. Não deve ser confundido com se fazer de qualquer maneira e. simplicidade significa que o código deve ser simples. É o Feedback que garante um sistema ágil e consistente. tampouco. onde o cliente define o que será feito em seguida. mas funcional. .1. com a ajuda de formulários simples. onde os requisitos para o desenvolvimento de software são vagos e estão em constante mudança. o idealizador da Extreme Programming. São Eles: . . é possível ajustar suas necessidades a uma situação próxima do ideal. no intuito de dar continuidade ao . trocar informações com o cliente.

com. . Figura 2 – Ciclo de Vida do XP.devmedia. Ele foi criado em 1997 por Jeff De Lucca. Essa comunicação poderá ser feita de várias maneiras.projeto. ainda que a mais utilizada seja a escrita em forma de documentação.br/imagens/javamagazine/Figura_01CicloVidaXP.9.JPG 1. Fonte: http://www.3 FDD FDD - Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é um método iterativo e incremental que tem um bom funcionamento com iterações curtas de até duas semanas.

deve-se primeiro escrever um pequeno pedaço de código para testar o resultado. é possível saber quantas funcionalidades já foram desenvolvidas e quantas ainda restam para se desenvolver. Antes de se escrever um código funcional. É Especificado mais o que deve ser feito. 1.4. Adicionamos uma nova funcionalidade do sistema. Fazemos o Teste passar (Green). Onde: • • • Escrevemos um Teste que inicialmente não passa (Red). dessa forma.1 Fases O FDD possui duas fases: • Concepção e Planejamento: nessa fase acontece a triagem de requisitos.4 TDD O Test Driven Design (TDD) é a combinação de duas técnicas de programação: Test-First Development (TFD) e Refactoring (Refatoração).3. . • Construção: Aqui temos um detalhamento por funcionalidade. Refactor. .9. 1.9.1 Ciclo de Desenvolvimento do TDD O ciclo de desenvolvimento do TDD pode ser elaborado conforme discriminado abaixo.Red. 1. em qualquer linguagem de programação.9.O FDD prega a visibilidade do estado do projeto e. Green.

com/2010/11/tdd3. Escrevemos o próximo Teste.files.png .• • Refatoramos o código da nova funcionalidade (Refactoring). Figura 3 – Ciclo de Desenvolvimento do TDD.wordpress. Fonte: http://alexandregama.

Editora INDG-Tecs. Gerenciamento de Projetos de Software. em PMTECH. PMBOK . PMI .REFERÊNCIAS BREITMAN. 2004. 2003. São Paulo: Makron. Sayão. Disponível <http://www. Mini-Cursos do 20º SBBD e 19º SBES. Acesso 20/09/2010. GERENCIA de PROJETOS. J. São Paulo: Makron. em http://www. Bookman.pmtech. Miriam. Gerência de Requisitos. 1995. edição.com. PRESSMAN.pdf. . EUA.com/files/Apostila_GERENCIA_DE_PROJETOS_DE_ SOFTWARE.pdf. Artigo publicado em julho de 2003.pdf>. Acesso em 24 de outubro de 2010. Acessado em 12/09/2010. Karin Koogam. 2005. R. Martin. Engenharia de Software. Darci. R. Agile Project Management.. Newtown Square. Addison Wesley.googlecode. HIGHSMITH. The New Methodology. Marconi Fábio. Gerenciamento de Projetos de Tecnologia da Informação.Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK®) Terceira edição 2004 Project Management Institute. Porto Alegre.ufes. FOWLER. UFES.br/artigos/CMM&PMBOK. 2006.pdf>. Gestão de Projetos: As Melhores Práticas. Outubro. 2008. em em VIEIRA. 2005. Disponível acesso em 14/092010.html>.br/~falbo/files/GerenciaProjetosSoftware. 3a.com.Project Management Institute (PMI) (2004) “A Guide to the Project Management Body of Knowledge”. S. Disponível em: <http://martinfowler. S.2. Disponível <http://www.br/artigos/Gerenciamento_Projetos_Software. PRADO. KERZNER. Four Campus Boulevard. Acesso em 10/09/2010. Disponível em http://gerpro2008.pmtech. PMTECH. Rio de Janeiro: Campus. Maturidade em Gerenciamento de Projetos.inf. PRESSMAN. H. v. PA 19073-3299 EUA. Engenharia de Software. Creating innovative products. Projetos de Software.com/articles/newMethodologyOriginal.

São Paulo. (2001). ed. E. 2003 Manifesto para Desenvolvimento Ágil de Software. 1995. (2007). Software Project Management Methodologies/Frameworks Dynamics “A Comparative Approach”.5. Declínio e Queda dos Analistas e dos Programadores. REHMAN. São Paulo: Addison Wesley. John Wiley & Sons. 7ª. . A. Engenharia de Software.org/iso/ptbr/>. Ian. H.SOMMERVILLE. em YOURDON. Project Management. Edição. In Proceedings of the IEEE International Conference on Information and Emerging Technologies (ICIET). KERZNER. 1 . 6. Disponível <http://agilemanifesto. Acesso em 10 de novembro de 2010. pp.