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 .

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

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

LISTA DE ABREVIATURAS .

LISTA DE FIGURAS .

SUMÁRIO .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful