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. to meet customer needs. . We describe the most important methods and their advantages and disadvantages. specifically tailored to the area of software development.

LISTA DE ABREVIATURAS .

LISTA DE FIGURAS .

SUMÁRIO .

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

com o intuito de satisfazer ou exceder as necessidades e as expectativas dos stakeholders1 Como este trabalho está voltado para a área de software. conforme requisitos específicos. KERZNER (2005). da concepção à obtenção do produto. A Gerência de Projetos é definida. sendo definida como a primeira camada deste processo e não é visto como uma etapa clássica do desenvolvimento. que define projeto como um empreendimento com objetivos bem definidos. consumindo recursos e operando sob pressões de prazo.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. desde que ela acompanha todas as etapas do desenvolvimento. A ABNT (NBR 10006) define que projeto é um processo único. custo e qualidade. podemos citar. é 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)]. segundo o Project Management Body of Knowledge (PMBOK. por exemplo. ferramentas e técnicas em atividades do projeto. . consistindo de um grupo de atividades coordenadas e controladas com datas para início e término. incluindo limitações de tempo. habilidades. ou seja. empreendido para alcance de um objetivo. Ainda no tocante à definição de projeto. 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. 2004) é a aplicação de conhecimentos. custos e recursos. Pressman também diz que para que um projeto de software seja bem sucedido.

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

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

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

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

É a área que descreve os processos relacionados ao término do projeto dentro do prazo estimado.3.1 Gerenciamento de Integração Segundo Vieira. especificação ou outra formalidade imposta”.3. 2003).1.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.2 Gerenciamento de Requisitos A definição para requisitos.3. o trabalho necessário para que seja concluído com sucesso.1. 1. 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.1. tão e somente. padrão. O Gerenciamento de Escopo faz a descrição dos processos envolvidos na verificação de que o projeto inclui. 2003).3. 1.3 Gerenciamento de Escopo De acordo com Vieira. 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.1. .1. escopo é todo trabalho envolvido na criação dos resultados do projeto (VIEIRA.

1. além de estuda bem a tecnologia a ser utilizada.7 Gerenciamento de Recursos Humanos Como é uma das principais fontes da produtividade no desenvolvimento de sistemas. o importante é não determinar custos antes da definição do requisito e do escopo.5 Gerenciamento de Custos Descreve os processos envolvidos no planejamento.1.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. visando o término do projeto dentro do orçamento aprovado. no orçamento e controle de custos. ao desempenho do sistema.3. 1. De acordo com VIEIRA (2003).1. no que está implícita a satisfação dos clientes e usuários finais.3. .3. na estimativa. especialmente para que os prazos sejam cumpridos. Vieira (2003) diz que a qualidade está ligada ao atendimento das necessidades do usuário final e. 1. o gerenciamento e o planejamento das pessoas envolvidas no projeto são de fundamental importância. em alguns casos.

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

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

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

através de pesquisas. o objetivo de atender os requisitos propostos e a qualidade esperada pelos envolvidos no projeto. levantando seus pontos comuns e divergentes. Demonstrar. 1.Nossa proposta é analisar os métodos ágeis na sua função de alcançar a melhoria no desenvolvimento de software. apresentaremos o objetivo geral e os específicos que serão desenvolvidos no decorrer deste trabalho. atingindo. assim.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. OBJETIVOS A seguir. são baseados nos seguintes itens: • • Citar as metodologias ágeis mais relevantes no mercado. que aqui serão tratados.3. • Fazer uma breve comparação entre os métodos ágeis e os tradicionais. a aceitação da metodologia ágil no mercado. .3.2 Objetivos Específicos Os objetivos específicos. 1. 1.3.

marcada pela pesquisa bibliográfica e também a eletrônica. em sua grande parte. 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. . Buscou-se também subsídios nos relatórios do Ministério da Ciência e Tecnologia.1. 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. sobre desenvolvimento de software. METODOLOGIA DE PESQUISA A metodologia de pesquisa utilizada neste trabalho foi.4. Também foram coletadas informações com professores do IFF – Campos dos Goytacazes.

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

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

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

. Uma metodologia de software comumente identifica as principais atividades (análise. a análise estruturada é um método para se realizar a fase de análise de um projeto. gerentes. projeto. Método: abordagem técnica passo a passo para se realizar uma ou mais das principais tarefas indicadas numa metodologia global. enquanto o projeto orientado a objetos é um método orientado para se executar a fase do projeto (YOURDON. metodologia incorpora todo o processo de desenvolvimento de software e método é aplicado em uma ou mais fases desse desenvolvimento. assim como a sua união. 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.7. testes) a serem executadas e indica quais pessoas (usuários. 1995). CONSIDERAÇÕES SOBRE METODOLOGIA E MÉTODO Existem diversas definições ou interpretações para metodologia e método. 1995). 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. 1. Dessa forma. No entendimento de YOURDON (1995). procurar para que haja conscientização da equipe. codificação.que ser Ágil é identificar e focar em objetivos bem definidos. técnicos) devem estar envolvidas em cada atividade e que papéis deverão desempenhar. As metodologias frequentemente descrevem os critérios de entrada (essas condições devem ser satisfeitas antes de iniciar a fase de projeto).

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

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

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

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

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

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

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.info/wp-content/uploads/2009/10 .Encerramento: Como sugere o próprio nome. motivado pelos itens mais prioritários. Figura 1 – Ciclo do SCRUM.. Ele ocorre. Fonte: http://mundoti.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. . é a última etapa de um projeto utilizando o SCRUM.

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

Essa comunicação poderá ser feita de várias maneiras.br/imagens/javamagazine/Figura_01CicloVidaXP.projeto.com.devmedia.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. . Fonte: http://www. Figura 2 – Ciclo de Vida do XP. Ele foi criado em 1997 por Jeff De Lucca. ainda que a mais utilizada seja a escrita em forma de documentação.JPG 1.9.

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

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

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

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

Sign up to vote on this title
UsefulNot useful