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.

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

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

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

LISTA DE ABREVIATURAS .

LISTA DE FIGURAS .

SUMÁRIO .

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

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

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

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

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

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

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

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

cuja temática envolve gerenciamento de projetos de software.1. em especial. além dos processos de gerenciamento de contratos (VIEIRA. 1. Depois de darmos algumas definições relacionadas ao Gerenciamento de Projetos e. coleta.3. armazenamento e destinação final das informações do projeto. avançamos neste trabalho. Descrevendo de maneira sucinta suas vantagens e desvantagens e quando é mais viável utilizá-los. 2003). de forma oportuna e adequada (VIEIRA.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.1.3.8 Gerenciamento de Comunicações O gerenciamento de comunicações descreve os processos relacionados à geração. serviços ou resultados. mas sem deixar de falar sobre os métodos tradicionais. 2003). . No Capítulo 3 faremos uma abordagem sobre os métodos tradicionais e ágeis. ao de software. lidando com os métodos ágeis.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful