Benefícios das metodologias ágeis no gerenciamento de projetos de Tecnologia da Informação (TI)

Tamanho: px
Começar a partir da página:

Download "Benefícios das metodologias ágeis no gerenciamento de projetos de Tecnologia da Informação (TI)"

Transcrição

1 1 Benefícios das metodologias ágeis no gerenciamento de projetos de Tecnologia da Informação (TI) Greick Roger de Carvalho Lima - greickroger@yahoo.com.br MBA Governança nas Tecnologias da Informação Instituto de Pós-Graduação e Graduação IPOG Goiânia, Goiás, 17 de abril de 2015 Resumo A Tecnologia de Informação (TI) tem sido considerada um dos componentes mais importantes na atualidade, oferecendo grandes oportunidades para as empresas que têm sucesso no aproveitamento dos benefícios oferecidos por este uso no desempenho empresarial. A problemática a ser refere-se à relação entre os benefícios oferecidos pelo uso de metodologias ágeis ao desempenho empresarial, e a sua aplicação no gerenciamento de projetos de TI. O artigo objetiva explorar os conceitos de metodologias ágeis, seu surgimento, aplicação, conceitos e principais métodos. Serão discutidas as metodologias Scrum, que abrange gerenciamento de projetos de software, e Extreme Programming, no âmbito de desenvolvimento. A partir dessa avaliação preliminar, busca-se identificar na literatura algumas evidências de aplicação dessas metodologias, de forma a entender como a teoria está sendo aplicada. Este estudo é considerado descritivo e exploratório, realizado mediante revisão bibliográfica. Os resultados destacam que metodologias ágeis têm sido bem aceitas pela indústria de software e por pesquisadores da Engenharia de Software, quando comparadas com as metodologias tradicionais, devido aos resultados satisfatórios. A conclusão deste estudo evidencia indícios da forma como o mercado utiliza e encara as metodologias ágeis nos dias atuais. Com isso, favorece a revisão constante dos conceitos da teoria, possibilitando maior ênfase aos que são largamente utilizados com resultados satisfatórios, de modo a filtrar e propor transformações aos que estão tornando-se arcaicos por falta de aplicação. Palavras-chave: Metodologias ágeis. Gerenciamento de projetos. Software. Scrum. 1. Introdução Um ambiente de crescentes mudanças exige das organizações inovações constantes e criativas. As disputas, cada vez mais acirradas por uma fatia do mercado, exigem decisões estratégicas rápidas e inovadoras, conduzindo as empresas a abandonarem modelos tradicionais de gestão. Um componente indispensável neste processo é o Sistema Integrado de Gestão, capaz de alimentar a empresa com informações necessárias para avaliar a situação financeira, como também permitir que estas informações possam ser comparadas e trabalhadas de maneira rápida, de modo a auxiliar a empresa nas suas tomadas de decisão.

2 2 Na atualidade, muitas empresas, de diversos segmentos, reconhecendo a importância da competência estratégica para o sucesso de seus negócios, vêm utilizando o gerenciamento de Projetos de Tecnologia da Informação (TI), caracterizado pela aplicação de conhecimentos, habilidades e técnicas para a execução de projetos de forma eficaz (RABECHINI JR.; CARVALHO, 2008). De fato, o gerenciamento de projetos de TI tem alcançado níveis consideráveis de importância nas empresas, sobretudo para aquelas que necessitam passar por processos de transformação, organizando-se para poder dar respostas eficazes e ágeis às solicitações ambientais e organizacionais. A aplicação desta prática é bastante utilizada no desenvolvimento de projetos, sejam eles de pequeno, médio ou grande porte, com forte referência no Project Management Institute, (PMI), que utiliza as melhores práticas de Gerenciamento de Projetos. Este vem se tornando um grande diferencial competitivo para as empresas que almejam obter sucesso nos serviços prestados em um mercado cada vez mais exigente (SILVA, 2008). Neste contexto, as empresas e a sociedade, de modo geral, encontram-se cada vez mais dependentes da indústria de desenvolvimento de software. Porém, devido aos diversos problemas que esta área possui, como alto custo de implementação, alta complexidade e falta de manutenção, não conseguem atender a demanda do mercado. Segundo Sommerville (2003:147), [...] a melhoria no processo de desenvolvimento de software aperfeiçoa a qualidade do produto final ; e como destacam Côrtes e Chiossi (2001:20), [...] a preocupação com a qualidade deixou de ser um diferencial competitivo e passou a ser um pré-requisito básico para participação no mercado. Existem duas linhas distintas de metodologia: tradicionais e ágeis. Enquanto as tradicionais primam por quantidade excessiva de documentação, as ágeis prezam por ter o software funcionando com o mínimo de documentação necessária (LUDVIG; REINERT, 2007). Portanto, adotar processos mais simplificados, como as metodologias ágeis tem despertado um grande interesse entre as comunidades de desenvolvimento de software. Coloca-se em discussão a seguinte pergunta: Quais as relações existentes entre os benefícios oferecidos pelo uso de metodologias ágeis ao desempenho empresarial e a sua aplicação no gerenciamento de projetos de TI? Em resposta a esta questão, considera-se a hipótese de que o uso de metodologias ágeis nos projetos ajuda a construir somente o que o cliente valoriza, criando produtos melhor adaptados à realidade do cliente. Neste contexto, o objetivo do artigo é estudar as metodologias ágeis em seus conceitos gerais e em especial os dois métodos mais largamente utilizados no presente momento: Scrum e Extreme Programing, ou XP. O primeiro é uma metodologia de gerenciamento, enquanto que o segundo é uma metodologia de desenvolvimento. Será feita uma identificação da forma como as metodologias ágeis estão sendo aplicadas em empresas, envolvendo um levantamento de quais pontos estão sendo utilizados conforme a teoria e quais são descartados, verificando assim a importância de especialização e o impacto dessa na rotina de profissionais e equipes. Com base nas proposições de Gil (2010), o presente estudo caracteriza-se como pesquisa bibliográfica, por incorporar uma revisão de literatura associada à experiência dos autores, no campo de investigação sobre o tema em estudo. O levantamento bibliográfico foi realizado

3 3 mediante consultas em material já existente, constituído de livros e artigos científicos, publicações periódicas, dissertações e teses de conteúdos similares. A justificativa para investigar um assunto dessa natureza está na oportunidade de aumentar os conhecimentos sobre a aplicação das metodologias ágeis no desenvolvimento de software, por se tratar de um assunto da atualidade e que vem despertando o interesse de vários pesquisadores sobre o tema. 2. Gerenciamento de projetos Projeto é um esforço empreendido para criar um produto, serviço ou resultado exclusivo, diferindo das operações de rotina, que são contínuas e repetitivas, pelas seguintes características principais: são temporários, possuindo um início e um fim claramente definidos; são planejados, executados e controlados; entregam produtos, serviços ou resultados exclusivos; são desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva; são realizados por pessoas; são executados com recursos limitados (SALLES JÚNIOR et al., 2006). Vargas (2006) definiu projeto como um empreendimento não repetitivo, caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade. Um aspecto crítico para o sucesso dos projetos é o da sua gestão, definida como a aplicação de conhecimentos, habilidades e técnicas para iniciar, planejar, executar, controlar e encerrar as atividades que visam atingir as necessidades ou expectativas das partes envolvidas com relação ao projeto (SILVA, 2008). Gerenciar projetos significa apropriar-se de um conjunto de atividades para a definição e a busca do alcance dos objetivos e resultados, por meio da otimização dos recursos disponíveis e do tempo (SILVA, 2008). Para o autor, o gerenciamento de projetos desenvolve-se nas etapas de definição e organização, planejamento e acompanhamento, contemplando cinco grupos de processos - iniciação, planejamento, execução, controle e encerramento que utilizam técnicas ou áreas de conhecimento para gerência de integração, escopo, tempo, custo, qualidade, recursos humanos, comunicações, aquisições e riscos. O termo Gerenciamento de Projetos às vezes é usado para descrever uma abordagem organizacional ou gerencial do gerenciamento de projetos e de algumas operações já em andamento, que podem ser redefinidas como projetos, o que também é chamado gerenciamento por projetos (PMBOK, 2012). O Project Management Body of Knowledge (PMBOK) não pode ser definido como uma metodologia, pois não distingue os diferentes tipos de projetos e sim como um guia de boas práticas de gerenciamento de projetos criado e mantido pela Project Management Institute (PMI). O guia formaliza os conceitos em gerenciamento de projetos, como a própria definição de projeto reconhecendo cinco grupos de processo e nove áreas de conhecimento. Os cinco grupos de processo reconhecidos pelo PMI são: Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento. Esses grupos possuem dependências claras e são

4 4 executadas na mesma sequência em todos os projetos. As dez áreas de conhecimento abordam o gerenciamento dos seguintes processos listados abaixo: Integração: Processos e atividades para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dentro dos grupos de processos de gerenciamento do projeto. Escopo: Processos que verificam apenas o trabalho necessário para que o projeto seja concluído com sucesso. Tempo: Processos relativos ao prazo de término do projeto. Custos: Processos que envolvem planejamento e controle de custos de modo que o projeto termine dentro do orçamento aprovado. Qualidade: Processos que asseguram que o projeto irá cumprir os objetivos para os quais foi empreendido. Recursos Humanos: Processos que organizam e gerenciam a equipe do projeto. Comunicações: Processos que disseminam as informações relacionadas ao projeto. Riscos: Processos de planejamento, identificação, análise, planejamento de respostas e controle de riscos de um projeto. Aquisições: Processos que compram ou adquirem bens, produtos, serviços ou resultados externos à equipe do projeto. Engloba também os processos de gerenciamento de contratos e controle de mudanças. Partes Interessadas: Processos que identificam todas as pessoas, grupos ou organizações que podem impactar ou serem impactados pelo projeto. Além disso, analisam suas expectativas e desenvolvem estratégias de engajamento nas decisões e execução do projeto. Projetos de desenvolvimento em grande parte possuem quatro fases comuns como análise, projeto, construção e teste. Mas no caso de projetos de migração de dados, por exemplo, é comum termos as fases de análise, extração e transformação, validação, carga e testes (PMBOK, 2013). 3. Metodologias de desenvolvimento de Software O desenvolvimento de software precisa ser reconhecido como um processo imprevisível e complicado. Reconhecer que um software nunca foi construído da mesma forma, com a mesma equipe, sob as mesmas circunstâncias antes é a grande mudança do pensamento tradicional de desenvolvimento de software (BALLE, 2011). Mas, o mais importante é reconhecê-lo como um processo empírico: que aceita a imprevisibilidade e tem mecanismos de ação corretiva.

5 5 Metodologias de desenvolvimento de Software (ou Processo de Software) é o conjunto de atividades, ordenadas ou não, com a finalidade de produzir um software de qualidade. O resultado do processo é um produto que reflete a forma como o processo foi realizado. O modelo de processo de software é uma representação abstrata de um processo de software. Cada modelo é representado sob determinada perspectiva e fornece somente informações parciais. Embora existam vários processos de desenvolvimento de software, Sommerville (2007) apresenta as atividades comuns a todos eles: Especificação do software: definição do que o sistema deve fazer; definição dos requisitos e das restrições do software; Desenvolvimento do software: projeto e implementação do software, o sistema é desenvolvido conforme sua especificação; Validação do software: o software é validado para garantir que as funcionalidades implementadas estejam de acordo com o que especificado; Evolução do software: evolução do software conforme a necessidade de cliente. O desafio mais comum do Desenvolvimento de Software é entregar um produto que atenda as reais necessidades do cliente, dentro do prazo e orçamento previsto. (LUDVIG; REINERT, 2007). Porém, muitas organizações desenvolvem software sem usar nenhum Processo de Desenvolvimento. Geralmente porque os Processos Tradicionais não são adequados às realidades das organizações. 3.1 Metodologias tradicionais Na década de 1970, a atividade de desenvolvimento de software era executada de forma desorganizada, desestruturada e sem planejamento, gerando um produto final de má qualidade, que não correspondia com as reais necessidades do cliente (PRESSMAN, 2007). A partir deste cenário surgiu a necessidade de tornar o desenvolvimento de software como um processo estruturado, planejado e padronizado (NETO, 2004). As metodologias consideradas tradicionais também são conhecidas como pesadas ou orientadas a documentação. Têm como característica marcante dividir o processo de desenvolvimento em etapas e/ou fases bem definidas. Segundo Soares (2004), essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros. Na época, o custo de fazer alterações era muito alto, uma vez que o acesso aos computadores era limitado e não existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Por isso, o software era todo planejado e documentado antes de ser implementado (LUDVIG; REINERT, 2007). Muitas metodologias pesadas são desenvolvidas em cima do Modelo em Cascata (SOMMERVILLE, 2003). É um modelo em que as fases definidas são seguidas de maneira

6 6 linear (LUDVIG; REINERT, 2007). Cada fase tem associado ao seu término uma documentação padrão que deve ser aprovada para que se inicie a etapa imediatamente posterior. Cada fase concluída gera um marco, que geralmente é algum documento, protótipo do software ou mesmo uma versão do sistema (NETO, 2004). De uma forma geral fazem deste modelo as etapas de análise de requisitos, projeto do software, geração de código e testes. Nos anos 80, surgiu outro processo para desenvolvimento de software, o processo em espiral, que apareceu como a solução para os problemas existentes no modelo em cascata, a exemplo do ciclo de Demming (ciclo PDCA) (MARQUES, 2012). Esse modelo surgia com apenas quatro fases (Planejamento, Avaliação, Análise de Risco e Engenharia), o processo inicia no planejamento, vai para a avaliação, análise de risco, engenharia e, seguindo a ideia do espiral, volta para o planejamento fazendo todo o ciclo novamente, idealizando assim um modelo iterativo e incremental, permitindo que os erros ocorridos em uma fase possam ser revistos. Conforme Sommerville (2003), a principal diferença entre o modelo em espiral e outros modelos de processo de software é o reconhecimento explícito do risco no modelo em espiral, pois riscos podem causar problemas no projeto, tal como ultrapassar o cronograma e os custos. Com o passar do tempo, a complexidade dos sistemas tem aumentado ainda mais, os sistemas possuem mais usuários e tornam-se cada vez mais importantes, podendo, em muitas vezes, gerenciar a vida ou a morte de pessoas, como é o caso de softwares que calculam quantidades de medicamentos a serem aplicados em pacientes ou que monitoram o estado de saúde dos pacientes, os sistemas também controlam a economia e as armas do mundo, é possível ver isso através do pânico que foi causado pela possibilidade do bug do milênio no final dos anos 90 (MARQUES, 2012:11). Unindo-se aos problemas até então encontrados e à importância atual dos sistemas informatizados, surgiram alguns teóricos discordando da ideia de tratar o desenvolvimento de software como uma fábrica de produção em série. Um exemplo citado por Marques (2012) é Cockburn que compara o desenvolvimento de software ao ato de escrever uma poesia épica em conjunto com diversas pessoas: seriam diversas pessoas, com diversos argumentos, tentando dar seu melhor sem talento, tempo ou recursos suficientes. 3.2 Metodologias ágeis As metodologias ágeis constituem parte da Engenharia de Software, a área de conhecimento voltada para a especificação, desenvolvimento e manutenção de sistemas de software (PRESSMAN, 2007). De acordo com este autor, a Engenharia de Software abarca três componentes básicos: métodos, que proporcionam os detalhes de como construir um software, tratando do planejamento, estimativas, análises de requisitos e arquitetura, entre outros; ferramentas, que sustentam cada um dos métodos; e procedimentos, que definem a sequência em que os métodos são aplicados, e fazem o elo entre os métodos e as ferramentas. A popularidade do termo Metodologias Ágeis data de 2001, a partir de uma reunião nos Estados Unidos da América (EUA), em que um grupo de dezessete especialistas em processos

7 7 de desenvolvimento de software colocou em discussão a proposta de como melhorar o desempenho de seus projetos (BALLE, 2011). Os resultados dessa discussão deram origem à criação da Aliança Ágil e o estabelecimento do Manifesto Ágil, contendo os conceitos e princípios comuns compartilhados por todos os métodos já utilizados pelos participantes da reunião, haja vista que eles suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso. Embora cada um dos envolvidos apresentasse as suas particularidades, havia um consenso entre eles de que, em suas experiências prévias, alguns princípios pareciam ter sido respeitados quando os projetos davam certo (BECK et al., 2001 apud BALLE, 2011). Desde então o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes conceitos que, segundo Libordi e Barbosa (2010), implicam em valorizar: Indivíduos e interação entre eles são mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano. Com o intuito de auxiliar as pessoas a compreenderem melhor o desenvolvimento de software ágil, foram definidos doze princípios aos quais, conforme Beck et al. (2001 apud LIBORDI; BARBOSA, 2010), as metodologias de desenvolvimento software ágeis estão adequadas. São eles: 1. Nossa maior prioridade é satisfazer o cliente, através de entregas rápidas e contínuas gerando valor ao software. 2. Recebendo bem as mudanças dos requisitos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente. 3. Trabalhando para entregar software, em intervalos de 2 semanas até 2 meses, com preferência para que tenha uma curta escala de tempo. 4. Empresários e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto. 5. Construa projetos com indivíduos motivados, dê-lhes o ambiente e o suporte que precisam, e confie neles para ter o trabalho realizado. 6. O método mais eficiente e efetivo de transmitir informação para a equipe de desenvolvimento está na conversa face a face. 7. Software funcionando é a principal medida para o progresso. 8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, os desenvolvedores, e os usuários devem ser capazes de manter um ritmo constante indefinidamente.

8 8 9. Atenção contínua para uma excelência técnica e um bom design aumentam a agilidade. 10. Simplicidade a arte de maximizar o valor do trabalho não feito é essencial. 11. As melhores arquiteturas, requisitos, e design surgem a partir de equipes autoorganizadas. 12. Em intervalos regulares, as equipes devem refletir sobre como se tornaram mais efetivas. Em seguida, devem se aprimorar e ajustar de acordo com seu comportamento. Para isso, cada metodologia conta seus ciclos específicos e pode se apoiar em artefatos que auxiliam na avaliação do trabalho realizado e programação do que deverá ser realizado, seguido ou melhorado para os ciclos seguintes. Em síntese, o Manifesto Ágil não abandona os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária, quando comparado com os indivíduos e interações, com o software funcionando, com a colaboração com o cliente e as respostas rápidas a mudanças e alterações (LIBORDI; BARBOSA, 2010). Na opinião de Balle (2011), da mesma forma que existe várias metodologias ágeis, também há conjuntos de práticas ágeis que são aceitas por quaisquer das metodologias, podendo ser adotadas pelos times ágeis ou não. Essas práticas muitas vezes são uma reunião de conceitos de diversas metodologias, organizados de forma neutra para que possam viver simultaneamente com qualquer uma, ou nenhuma. Agile Modeling é um processo baseado em práticas que descreve como ser um modelador efetivo. Essas práticas são muito baseadas em metodologias ágeis diversas, mas aplicadas à modelagem e vistas de forma mais ampla (AMBLER, 2002 apud BALLE, 2011). Agile Modeling ajuda a encontrar o meio-termo entre os extremos em que as formas de modelar podem cair, seja não existindo nenhum modelo, o que acaba significando retrabalho, como na modelagem excessiva, quando documentos e modelos demais são criados, o que atrasa o desenvolvimento. A proposta do Agile Modeling é modelar o suficiente para explorar e documentar o sistema de forma eficiente, mas não a ponto de diminuir a velocidade do projeto (BALLE, 2011:15). Conforme a autora supracitada, a Agile Modeling pode ser aplicada por times que utilizam metodologias ágeis, mesmo que se trate simplesmente de uma técnica e não uma metodologia, haja vista que seus princípios e técnicas são partilhados por várias metodologias ágeis, como XP, Scrum, entre outras. No entanto, a técnica pode ser também aplicada por projetos que não utilizam métodos ágeis e desejam melhorar e simplificar seus modelos. Em um contexto de mercado, as metodologias ágeis são consideradas como Freemium (ANDERSON, 2009). No caso, as metodologias foram desenvolvidas por empresas ou pessoas físicas, que não cobram nada pela sua utilização, em uma primeira análise, o que poderia caracterizar um Mercado Não-Monetário. Não há como negar que se pode simplesmente procurar informações na Web, onde milhares de sites e materiais de apoio são mantidos, inclusive por alguns dos participantes do Manifesto Ágil.

9 9 Pode-se, inclusive, simplesmente seguir as diretrizes do próprio Manifesto, aplicando os princípios ágeis em qualquer setor. Essa gratuidade das metodologias, que também não impõe uma ferramenta específica para a caracterização dos seus conceitos, vem atraindo diversas empresas, da mesma forma que uma conta gratuita (mas limitada) de um serviço na Web atrai muitos usuários (BALLE, 2011:17). É observável, neste contexto, toda uma economia girando em torno das metodologias ágeis, a exemplo das certificações oficiais, livros das mais diversas metodologias e práticas, cursos, workshops e palestras, em especial dos autores chave das metodologias em questão e, como se pode verificar com a análise de relatos de aplicação de metodologias ágeis. Também é comum que sejam contratados consultores para o auxílio da implantação da metodologia escolhida (ANDERSON, 2009). Dessa forma, a gratuidade das metodologias atrai mais consumidores, mas estes, sem uma orientação mais profunda e correta, acabarão muitas vezes aplicando a metodologia com uma interpretação errada. Assim, alguns desses consumidores procurarão orientação, seja em cursos, livros, consultorias, muitas vezes encabeçadas por autores consagrados, os mesmos que mantém materiais gratuitos que são a porta de entrada para o mundo de metodologias ágeis, o que caracteriza um mercado Freemium (LIBORDI; BARBOSA, 2010). O Manifesto Ágil diz que software funcional é mais valorizado que uma documentação extensa. Isso acaba por gerar confusão, sendo que um dos erros básicos dos que estão começando a trabalhar com metodologias ágeis é acreditar que não devem manter documentação nenhuma. Metodologias ágeis podem comportar documentação, porém, sob de forma que não deixe de lado as características que definem o trabalho ágil. Um documento é ágil se seguir uma série de critérios. Primeiramente, os documentos ágeis maximizam o investimento dos stakeholders, ou seja, o benefício que deles provêm é maior que o investimento em sua criação e manutenção. Por isso, descrevem somente informações que não mudam com facilidade, pois quanto maior a chance de uma informação mudar, menor o valor de um documento escrito sobre a mesma. Da mesma forma, um documento ágil deve capturar informações críticas e que não são facilmente deduzíveis (AMBLER, 2004 apud LIBORDI; BARBOSA, 2010). Um documento ágil contém somente as informações para atingir o seu objetivo, ou seja, é o mais simples possível. E, mais do que isso, precisa ter um objetivo simples e facilmente identificável. Precisa ter um público específico e facilitar o trabalho do mesmo, sendo suficientemente precisa e detalhada (e não mais que isso). E, por fim, documentos ágeis são indexados de forma eficiente e precisa, pensando em seu público-alvo. Tendo como objetivo principal do artigo a interpretação, análise e classificação de pontos comuns na aplicação de metodologias ágeis, é importante saber quais são os conceitos mais relevantes e aos quais deve nos prender para um entendimento pleno, maior abrangência e acuidade no que tange ao cenário atual da aplicação dos métodos e seus conceitos. Como o domínio de metodologias ágeis é muito amplo, são tratados os termos de mais relevância e abrangência, ou com foco específico em Scrum e Extreme Programming, por serem as metodologias mais amplamente utilizadas, muitas vezes conjuntamente.

10 10 4. SCRUM Scrum trabalha com a complexidade de desenvolvimento de softwares através do controle de inspeção, adaptação e visibilidade de requisitos de um processo empírico fazendo uso de uma série de regras e práticas, onde controle não significa controle para criar o que foi previsto e sim controlar o processo para orientar o trabalho em direção a um produto com o maior valor agregado possível (BARROS et al., 2009). Para atingir esses objetivos o Scrum emprega uma estrutura iterativa e incremental da seguinte maneira: no início de cada iteração, a equipe analisa o que deve ser feito e então seleciona aquilo que acreditam poder se tornar um incremento de valor ao produto ao final da iteração. A equipe então faz o seu melhor para realizar o desenvolvimento daquela iteração e ao final apresenta o incremento de funcionalidade construído para que os stakeholders possam verificar e requisitar alterações no momento apropriado (BARROS et al., 2009). Segundo a Scrum Alliance (DUNCAN et al., 2005), Scrum é um framework ágil para a realização de projetos complexos. Scrum originalmente foi formalizado para projetos de desenvolvimento de software, mas funciona bem para qualquer escopo, complexo e inovador de trabalho. Um dos motivos para a abrangência de campos é a simplicidade do framework Scrum. O Scrum destaca-se dos demais métodos ágeis pela maior ênfase dada ao gerenciamento do projeto. Reúne atividades de monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando à identificação e correção de quaisquer deficiências e/ou impedimentos no processo de desenvolvimento (SCHWABER, 2004). O método baseia-se ainda em princípios como: equipes pequenas de, no máximo, sete pessoas; requisitos que são pouco estáveis ou desconhecidos; e iterações curtas. Divide o desenvolvimento em intervalos de tempos de no máximo, trinta dias, também chamados de Sprints. O Scrum implementa um esqueleto iterativo e incremental através de três papéis principais (SCHWABER, 2004): Product Owner: representa os interesses de todos no projeto; Time: desenvolve as funcionalidades do produto; ScrumMaster: garante que todos sigam as regras e práticas do Scrum, além de ser o responsável por remover os impedimentos do projeto. Um projeto no Scrum se inicia com uma visão do produto que será desenvolvido (SCHWABER, 2004). A visão contém a lista das características do produto estabelecidas pelo cliente, além de algumas premissas e restrições. Em seguida, o Product Backlog é criado contendo a lista de todos os requisitos conhecidos. O Product Backlog é então priorizado e dividido em releases.

11 11 Figura 1 - Esqueleto Scrum Fonte: Scrum Alliance (DUNCAN et al., 2005 apud BALLE, 2011:18) Observa-se na Figura 1 que, no Scrum, um projeto se inicia com uma visão simples do produto que será desenvolvido. A visão pode ser vaga a principio e ir tornando-se clara aos poucos. O Product Owner (PO) então, transforma essa visão em uma lista de requisitos funcionais e não-funcionais que quando forem desenvolvidos reflitam essa visão. Essa lista, chamada de Product Backlog é priorizada pelo PO de forma que os itens que gerem maior valor ao produto tenham maior prioridade. Projetos Scrum progridem em uma série de Sprints, que são iterações não maiores do que um mês. No início de um Sprint, os membros da equipe se comprometem a entregar um número de características que foram listadas no Product Backlog. No final do Sprint, esses recursos estão feitos - estão codificados, analisados e integrados no produto em desenvolvimento ou sistema. No final do Sprint há uma revisão durante a qual a equipe demonstra a nova funcionalidade para o Product Owner e outras partes interessadas que fornecem feedback que possa influenciar o próximo Sprint (COHN, 2002). Schwaber (2004) explica que cada Sprint inicia-se com uma reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o Time decidem em conjunto o que deverá ser implementado (Selected Product Backlog). A reunião é dividida em duas partes. Na primeira parte (Sprint Planning 1) o Product Owner apresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados. O Time então define, colaborativamente, o que poderá entrar no desenvolvimento da próxima Sprint, considerando sua capacidade de produção. Na segunda parte (Sprint Planning 2), o time planeja seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas no Product Backlog. Nas primeiras Sprints, é realizada a maioria dos trabalhos de arquitetura e de infraestrutura. A lista de tarefas pode ser modificada pelo Time ao longo da Sprint, e as tarefas podem variar entre quatro e dezesseis horas para a sua conclusão (BARROS et al., 2009).

12 12 Figura 2 - Fluxo do Sprint Fonte: Libordi; Barbosa (2010, p. 18) No final da Sprint é realizada a reunião de revisão (Sprint Review Meeting) para que o Time apresente o resultado alcançado na iteração ao Product Owner. Nesse momento, as funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida, o ScrumMaster conduz a reunião de retrospectiva (Sprint Retrospective Meeting), a fim de melhorar o processo/time e/ou produto para a próxima Sprint (SCHWABER, 2004). Depois da Sprint Review Meeting e antes do próximo Sprint o Scrum Master se reúne com o Scrum Team numa última reunião: a Retrospective Meeting. O Scrum Master encoraja o Scrum Team a revisar as práticas do Scrum e refletir sobre o que precisa ser feito para melhorar no próximo Sprint. Juntas, a Sprint Planning Meeting, a Daily Scrum Meeting, a Sprint Review Meeting e a Sprint Retrospective Meeting implementam as práticas de inspeção e adaptação empíricas (SCHWABER, 2004). A finalidade do Scrum é permitir manter o foco na entrega do maior valor de negócio, no menor tempo possível. Isto permite a rápida e contínua inspeção do software em produção. As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. Todos podem ver o software real em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um Sprint. A equipe Scrum é auto-organizável, e não há nenhum líder geral da equipe que vai decidir qual pessoa vai fazer qual tarefa ou como um problema será resolvido. Essas são questões que são decididas pela equipe como um todo. A equipe é multifuncional e apoiada por dois indivíduos específicos: um Scrum Master e um Product Owner. O ScrumMaster pode ser visto como um treinador para a equipe, ajudando os membros da equipe a utilizar o framework Scrum. O Product Owner é o proprietário do produto e representa a empresa, clientes ou usuários, orientando a equipe de desenvolvimento na construção do produto correto (BALLE, 2011:31). O ambiente de trabalho de Scrum é extremamente importante. Ele deve ser aberto, para facilitar o diálogo da equipe e a auto-organização. O Time deve ter à mão sempre as melhores

13 13 ferramentas possíveis para a realização do trabalho e há mais sucesso se todo o Time ocupar o mesmo espaço físico, ou seja, se trabalhar na mesma sala (BALLE, 2011). As práticas de Scrum evoluíram ao longo da sua aplicação em milhares de projetos. É recomendado que essas práticas sejam aplicadas estritamente, até que seja entendida a forma como Scrum funciona com a experiência. Quando Scrum estiver funcionando bem, podem ser feitos ajustes (SCHWABER, 2004). 4.1 Papéis Scrum O Scrum implementa sua estrutura iterativa e incremental através de três papéis: o Product Owner, o Team, e o ScrumMaster. Toda responsabilidade no projeto é dividida entre esses três papéis (SCHWABER, 2004). O Scrum Master é responsável pelo processo Scrum, por ensiná-lo a todas as pessoas envolvidas no projeto, por implementá-lo, fazendo dele uma cultura na organização e ainda por garantir que toda a equipe siga as regras e as práticas do Scrum (SCHWABER, 2004). Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint. O Scrum Master atua como facilitador na Daily Scrum Meeting e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões (BARROS et al., 2009). O papel de Scrum Master pode ser exercido por qualquer pessoa da equipe, entretanto é tipicamente exercido por um gerente de projeto ou um líder técnico. O Scrum Team é a equipe de desenvolvimento. Um Scrum Team típico tem de 6 a 10 pessoas auto-organizáveis, autogerenciáveis e multifuncional (BALLI, 2011). Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos e são responsáveis por completar o conjunto de trabalho com o qual se comprometem a cada iteração. A equipe não pode ser alterada durante o Sprint. Quando é necessário uma equipe maior no Scrum é usando o conceito de Scrum of Scrums. Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrum, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações (LIBORDI; BARBOSA, 2010). O Product Owner é responsável por representar os interesses dos stakeholders no projeto. O Product Owner é a pessoa que define todos os itens de requisito do projeto numa lista chamada Product Backlog. Utilizando essa lista ele é responsável por garantir que as funcionalidades que agreguem maior valor ao produto sejam desenvolvidas primeiro. Isto é feito através da frequente priorização do Product Backlog para que os itens de maior valor agregado sejam entregues a cada iteração (SCHWABER, 2004).

14 Artefatos Dentre os artefatos do Scrum, o Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido e priorizado pelo Product Owner. O Product Backlog é totalmente dinâmico, ele é modificado toda vez que se identifica algo que o produto precisa para ser mais apropriado, competitivo ou proveitoso (SCHWABER, 2004). Por isso ele nunca está completo, ele sempre contém os requisitos mais conhecidos e melhores entendidos. O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint como um potencial incremento de produto entregável (LIBORDI; BARBOSA, 2010). Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades. A quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog é definida pelo Scrum Team que se compromete a implementá-los durante o Sprint. Os itens do Sprint Backlog são divididos em tarefas com detalhes suficientes para que possam ser executadas em até 16 horas (LIBORDI; BARBOSA, 2010). Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart (MARQUES, 2012). O monitoramento do progresso do projeto é realizado através de dois gráficos principais: Product Burndown Chart e Sprint Burndown Chart. Estes gráficos mostram ao longo do tempo a quantidade de trabalho que ainda resta ser feito, sendo um excelente mecanismo para visualizar a correlação entre a quantidade de trabalho que falta ser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este trabalho. 4.4 Cerimônias A Sprint Planning Meeting é uma reunião na qual estão presentes o PO, o Scrum Master e o Scrum Team. Durante esta reunião o PO descreve as funcionalidades de maior prioridade para a equipe (MARQUES, 2012). Essa reunião, que deve ser de 8 horas, é dividida em duas partes (SCHWABER, 2004): nas primeiras 4 horas o PO apresenta os itens de maior prioridade do Product Backlog para a equipe. O Scrum Team faz perguntas para entender melhor as funcionalidades e ser capaz de quebrar as funcionalidades em tarefas técnicas que irão dar origem ao Sprint Backlog e então definem colaborativamente o que poderá entrar no desenvolvimento do próximo Sprint, considerando o tamanho da equipe, a quantidade de horas disponíveis e a produtividade do Scrum Team. durante as próximas 4 horas o Scrum Team planeja seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas no Product Backlog

15 15 A cada dia do Sprint o Scrum Master realiza uma reunião de 15 minutos com o Scrum Team. Essa reunião, chamada Daily Scrum Meeting, tem como objetivo disseminar informações sobre o estado do projeto As Daily Scrum Meetings devem ser realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho (MARQUES, 2012). Embora qualquer pessoa possa participar da reunião, somente os membros do Scrum Team estão autorizados a falar Cada membro do Scrum Team deve então responder cada uma destas três perguntas: O que você fez ontem? O que você fará hoje? Há algum impedimento no seu caminho? Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. A Daily Scrum Meeting não é uma reunião de status na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual os membros da equipe assumem compromissos perante os demais. Os impedimentos identificados na Daily Scrum Meeting devem ser tratados pelo Scrum Master o mais rapidamente possível. O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. No final do Sprint a Sprint Review Meeting é realizada. Essa reunião é planejada para ser realizada em no máximo 4 horas. Nesta reunião o Scrum Team mostra o que foi desenvolvido durante o Sprint. Tipicamente, isso tem o formato de uma demonstração das novas funcionalidades. Durante a Sprint Review Meeting, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante a Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Sprint Backlog. A Sprint Retrospective Meeting é uma reunião de 3 horas [4] que ocorre ao final de um Sprint depois da Sprint Review Meeting e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar. 5. Extreme Programming De acordo com Don Wells em sua página de referência sobre XP (Extreme Programming) (WELLS, 2009), Extreme Programming é um dos vários processos ágeis populares; já foi provado ser muito bem sucedido em muitas empresas de todos os tamanhos e indústrias do mundo inteiro. Extreme Programming enfatiza o trabalho em equipe. Os gerentes, clientes e desenvolvedores são todos parceiros iguais em uma equipe colaborativa. Extreme Programming implementa um ambiente simples, mas eficaz, que permite as equipes tornam-se altamente produtivas. A equipe se auto-organiza em torno do problema para resolvê-lo o mais eficientemente possível.

16 16 Extreme Programming melhora um projeto de software em quatro formas essenciais: comunicação, simplicidade, feedback e respeito. Esses são os pilares sobre os quais a metodologia XP é sustentada (BECK, 1999 apud BALLE, 2011): Comunicação: A maioria dos problemas que ocorrem nos projetos invariavelmente tem sua causa associada ao fato de alguém não ter informado alguma coisa muito importante para umapessoa que precisava saber. Dessa forma, a comunicação é o valor de maior importância no XP; Simplicidade: A simplicidade não é fácil. Uma das coisas mais difíceis de se fazer é não olhar para as coisas que serão necessárias implementar no dia seguinte, na semana seguinte e no mês seguinte. Deve ser implementado apenas aquilo que é necessário e realmente importa ser construído. Isto significa dizer que as pessoas só devem se preocupar em solucionar hoje os problemas de hoje. A complexidade custa muito caro e tentar prever o futuro é muito difícil. É necessário aguardar o futuro para ver se está certo ou não. Feedback: A veracidade dos relatórios do estado atual das atividades é extremamente importante em XP. Feedback significa perguntar e aprender com as respostas. A única forma de saber a necessidade do cliente é perguntando a ele. O único modo de saber se um código faz o que ele se destina fazer é testando-o. Quanto mais cedo se obter o feedback, mais tempo se terá disponível para reagir. A metodologia XP fornece um feedback rápido e frequente por parte dos seus seguidores. Coragem: Depois de se falar nos três valores, comunicação, simplicidade e feedback, é hora de se esforçar como nunca antes. Se o trabalho não for desempenhado na sua velocidade mais rápida possível, alguém mais o irá fazer, e ele vai lucrar no lugar. A coragem significa tomar as decisões na hora em que elas precisam ser tomadas. Se uma funcionalidade não está funcionando, ela deve ser consertada. Se algum código não parece estar bem escrito, ele deve ser refatorado. Se não será possível entregar tudo o que se havia prometido dentro do prazo acordado, o cliente deve ser informado. A coragem é uma virtude difícil de se aplicar. Ninguém gosta de estar errado ou quebrar um acordo. O único modo de consertar um engano é admitir que houve um engano e consertá-lo. Programadores de um time que implementa Extreme Programming constantemente se comunicam com seus clientes e colegas programadores (BECK, 1999 apud BALLE, 2011). Eles mantêm seu design simples e limpo, entregam o sistema para os clientes o mais cedo possível e implementam mudanças. Cada pequeno sucesso aprofunda seu respeito para as contribuições únicas de cada membro da equipe. Com essa fundação, programadores Extreme são capazes de responder com coragem a novos requisitos e tecnologia (WELLS, 2009). Extreme Programming (XP) é apoiado em práticas que formam a metodologia. A maioria das práticas XP também pode ser adotada por desenvolvedores individualmente. Devido ao fato da metodologia XP ser muito bem detalhada e explicada, e não existir grandes dificuldades em seguir suas práticas, entretanto, é extremamente difícil e arriscado seguir todas as práticas rigorosamente e ao pé da letra de uma única vez (CARVALHO; RABCHINI JR 2007). Cada prática pode desempenhar vários papéis. Por exemplo, o teste influencia o projeto da solução e encoraja a execução de pequenos experimentos controlados.

17 17 Apenas escolher algumas práticas XP ao acaso, sem antes entender a relação existente entre elas, pode levar a resultados desastrosos. Por exemplo, um refinamento de código sem que tenha sido realizada uma rigorosa fase de testes anteriormente poderá resultar na introdução de defeitos tão sutis dentro do código que poderiam levar a extensas sessões de depuração para sua correção. 6. Critérios utilizados Os critérios adotados para servirem de base para a identificação das atividades propostas pelos Métodos Ágeis são as atividades sugeridas pelo Desenvolvimento Incremental. Sommerville (2003) afirma que os métodos ágeis são fundamentados no Desenvolvimento Incremental. E conforme puderam ser observado, as atividades sugeridas durante o seu processo de desenvolvimento são bastante semelhantes aos Princípios Ágeis. No Desenvolvimento Incremental (Figura 4) os clientes inicialmente identificam, em um esboço, os requisitos do sistema e selecionam quais são os mais e os menos importantes. Em seguida é definida uma série de iterações de entrega, onde em cada uma é fornecido um subconjunto de funcionalidades executáveis, dependendo das suas prioridades. Figura 4 Desenvolvimento Incremental Fonte: Adaptado de Sommerville (2003) Após a identificação dos incrementos, as funcionalidades a serem entregues na primeira iteração são detalhadas e desenvolvidas. Paralelamente a este desenvolvimento, outras funcionalidades podem ser analisadas para fazerem parte dos outros incrementos. Uma vez que cada incremento é concluído e entregue, os clientes podem colocá-lo em operação. O fato dos clientes poderem experimentar o sistema gradualmente facilita o esclarecimento das funcionalidades para os incrementos subsequentes e à medida que novos incrementos são concluídos, eles são integrados às iterações existentes, de modo que o sistema melhora a cada novo incremento entregue (SOMMERVILLE, 2003). 7. Metodologia

18 18 A metodologia em um projeto de pesquisa se refere ao [...] procedimento em que se explora a realidade, por meio de uma atividade que se volte para soluções de problemas práticos ou teóricos com base de esclarecimentos dos processos científicos (GIL, 2010:19). Segundo Vergara (2009), as principais finalidades de uma pesquisa são as seguintes: descrição, explicação e exploração. A autora comenta que a maioria dos estudos tem mais de um objetivo e às vezes todos os três. O presente estudo foi realizado por meio de um levantamento bibliográfico, com características de uma pesquisa descritiva e exploratória. Segundo Gil (2010), uma pesquisa descritiva analisa aspectos de grupos relevantes. Por sua vez, o estudo exploratório suscita novas possibilidades que mais tarde serão exploradas em pesquisas mais controladas. A pesquisa bibliográfica, de caráter exploratório-descritivo foi abordada com a finalidade de incorporar uma revisão de literatura para subsidiar teoricamente este artigo. Este tipo de pesquisa nada mais é do que saber quais os métodos utilizados em investigações similares e averiguar o melhor para ser aplicado através da busca de uma problematização de um projeto de pesquisa (VERGARA, 2009). Esta foi realizada a partir de referências publicadas, analisando e discutindo as contribuições culturais e cientificas. A consulta de fontes consiste na identificação das fontes documentais (documentos audiovisuais, documentos cartográficos e documentos textuais), na análise das fontes e no levantamento de informações (reconhecimento das ideias que dão conteúdo ao documento). Para tanto, utilizou-se de livros, artigos científicos, revistas especializadas e periódicos, dentre outras fontes de pesquisa, como a Internet. 8. Conclusão Buscou-se, ao longo deste estudo, fazer um levantamento bibliográfico dos benefícios das metodologias ágeis no gerenciamento de projetos. A partir do posicionamento dos autores pesquisados foi possível identificar que as práticas apontadas pelas metodologias ágeis apresentadas são eficientes para desenvolver sistemas, desde que usadas corretamente. As metodologias ágeis surgem de uma mesma motivação e apresentam as principais ideias em comum. O que identifica cada uma de forma unívoca é a forma de implementar as ideias através de práticas para o dia a dia. Cada conjunto de práticas deve ser examinado de maneira isolada, conforme feito neste trabalho, para verificar sua eficiência. De uma maneira geral, pelo levantamento bibliográfico apresentado neste artigo, pode-se entender que, para o desenvolvimento de software, as metodologias baseadas em processos adaptativos têm potencial de apresentar resultados melhores que os resultados apresentados pelas metodologias baseadas em processos preditivos. Para as pessoas que desenvolvem o sistema, as metodologias orientadas a pessoas apresentam melhores condições de trabalho e melhores resultados que as metodologias orientadas a processos. Os resultados destacam que metodologias ágeis têm sido bem aceitas pela indústria de software e por pesquisadores da Engenharia de Software, quando comparadas com as metodologias tradicionais, devido aos resultados satisfatórios. Dentre seus benefícios, constatou-se que os métodos utilizados para desenvolvimento de software podem ser considerados um diferencial que promete aumentar a satisfação do cliente agregando maior

19 19 valor ao produto final, produzindo software alta qualidade e acelerando os prazos de desenvolvimento de projetos. A conclusão deste estudo evidencia indícios da forma como o mercado utiliza e encara as metodologias ágeis nos dias atuais. Com isso, favorece a revisão constante dos conceitos da teoria, possibilitando maior ênfase aos que são largamente utilizados com resultados satisfatórios,de modo a filtrar e propor transformações aos que estão tornando-se arcaicos por falta de aplicação. Diante disso, considera-se que o objetivo a que se propôs este estudo foi alcançado, embora, caiba ressaltar que o assunto não se esgota no tempo. Ao contrário, a sensação que se tem no encerramento do artigo é de que a mesmo foi apenas um primeiro passo onde tantos outros poderão ser dados. Referências ANDERSON, C. Free: Grátis O futuro dos preços. 1. ed. Rio de Janeiro: Ed. Campus, BALLE, A. R. Análise de Metodologias Ágeis: Conceitos, Aplicações e Relatos sobre XP e Scrum f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Instituto de Informática, Universidade Federal do Rio Grande do Sul (UFRS), Porto Alegre, BARROS, P. V. A. et al. SCRUM: Uma metodologia ágil para projetos WEB com pequenas equipes. In: IX Jornada de Ensino, Pesquisa e Extensão (JEPEX 2009). IX Jornada de Ensino, Pesquisa e Extensão, Universidade Federal Rural de Pernambuco, Serra Talhada, COHN, Mike. Introduction to Scrum - An Agile Process. Mountain Goat, Lafayette, Disponível em: < Acesso em: 13 abr CÔRTES, M. L.; CHIOSSI, T.C. S.. Modelos de Qualidade de Software. Campinas: Unicamp, Instituto de Computação, DUNCAN, S. et al. Scrum Is An Inovattive Approach to Make Things Done. Scrum Alliance, Indianapolis, Disponível em: < scrum>. Acesso em: 11 abr GIL, A. C. Métodos e técnicas de pesquisa social. 5. ed. São Paulo: Atlas, HARVARD BUSSINESS SCHOOL. Implementando a inovação. Tradução de Carlos Cordeiro de Mello. Rio de Janeiro: Elsevier/Campus, 2007.

20 20 LIBORDI, P. L. O.; BARBOSA, V. Métodos Ágeis f. Artigo (Especialização em TI) - Faculdade de Tecnologia FT, Universidades Estadual de Campinas, LUDVIG, D.; REINERT, J. D. Estudo do uso de metodologias ágeis no desenvolvimento de uma aplicação de Governo Eletrônico fl. Trabalho de Conclusão de Curso (Bacharelado em Sistema de Informação) - Departamento de Informática e Estatística, Universidade Federal de Santa Catarina (UFSC), Florianópolis, MARQUES, A. N. Metodologias ágeis de desenvolvimento: processos e comparações Monografia (Graduação em Tecnologia da Informação) Faculdade de Tecnologia de São Paulo, São Paulo, NETO, O. N. S. Análise comparativa das metodologias de desenvolvimento de softwares tradicionais e ágeis. Trabalho de Conclusão de Curso. Universidade da Amazônia. Belém: PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) 4. ed. Newtown Square: Project Management Institute, PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) 5. ed. Newtown Square: Project Management Institute, PMI. Integração Nacional, Programa dos Capítulos do PMI. Disponível em:. Acesso em: 15 nov PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: Ed.Mc Graw Hill, RABECHINI, R.; CARVALHO, M. M. Construindo competências para gerenciamento de projetos. 2. ed. São Paulo: Atlas, SCHWABER, K. Agile Project Management With Scrum. Microsoft Press, disponível em: < < Acessado em 27 mar SALLES JÚNIOR., C. A. C.; SOLER, A. M.; VALLE, J. A. S.; RABECHINI JR., R. Gerenciamento de riscos em projetos. Rio de Janeiro: Editora FGV, SILVA, W. S. Gestão de risco nas organizações de base tecnológica f. Dissertação (Mestrado em Gestão, Pesquisa e Desenvolvimento em Tecnologia Farmacêutica) - associação entre a Universidade Católica de Goiás, Universidade Estadual de Goiás e o Centro Universitário de Anápolis. Goiânia, SOARES, M. S. Comparação entre metodologias ágeis e tradicionais para o desenvolvimento de software Disponível em: < infocomp/artigos/v3.2/art02.pdf>. Acessado em 29 mar

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana

Leia mais

Promoção especial para o III Congresso Cearense de Gerenciamento Certified ScrumMaster, Certified Scrum Product Owner e Management 3.

Promoção especial para o III Congresso Cearense de Gerenciamento Certified ScrumMaster, Certified Scrum Product Owner e Management 3. Promoção especial para o III Congresso Cearense de Gerenciamento Certified ScrumMaster, Certified Scrum Product Owner e Management 3.0 Sobre a GoToAgile! A GoToAgile é uma empresa Brasileira que tem seu

Leia mais

3 Qualidade de Software

3 Qualidade de Software 3 Qualidade de Software Este capítulo tem como objetivo esclarecer conceitos relacionados à qualidade de software; conceitos estes muito importantes para o entendimento do presente trabalho, cujo objetivo

Leia mais

Processos de gerenciamento de projetos em um projeto

Processos de gerenciamento de projetos em um projeto Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.

Leia mais

Gerenciamento da Integração (PMBoK 5ª ed.)

Gerenciamento da Integração (PMBoK 5ª ed.) Gerenciamento da Integração (PMBoK 5ª ed.) O PMBoK diz que: O gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar

Leia mais

Ouvir o cliente e reconhecer o problema: ingredientes essenciais à gestão de projetos

Ouvir o cliente e reconhecer o problema: ingredientes essenciais à gestão de projetos Ouvir o cliente e reconhecer o problema: ingredientes essenciais à gestão de projetos Antonio Mendes da Silva Filho * The most important thing in communication is to hear what isn't being said. Peter Drucker

Leia mais

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de

Leia mais

INTRODUÇÃO A PROJETOS

INTRODUÇÃO A PROJETOS INTRODUÇÃO A PROJETOS Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br GESTÃO DE PROJETOS Gestão Ágil de projetos Gestão de projetos com PMBOK GESTÃO ÁGIL DE PROJETOS GESTÃO ÁGIL

Leia mais

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com) SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features

Leia mais

Alexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes

Alexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes Instituto Federal do Rio Grande do Norte IFRN Graduação Tecnologia em Analise e Desenvolvimento de Sistema Disciplina: Processo de Desenvolvimento de Software Scrum Alexandre Lima Guilherme Melo Joeldson

Leia mais

Gerenciamento de Projetos Modulo II Clico de Vida e Organização

Gerenciamento de Projetos Modulo II Clico de Vida e Organização Gerenciamento de Projetos Modulo II Clico de Vida e Organização Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos

Leia mais

Gerenciamento de Projetos Modulo III Grupo de Processos

Gerenciamento de Projetos Modulo III Grupo de Processos Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução. Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer

Leia mais

3 Gerenciamento de Projetos

3 Gerenciamento de Projetos 34 3 Gerenciamento de Projetos Neste capítulo, será abordado o tema de gerenciamento de projetos, iniciando na seção 3.1 um estudo de bibliografia sobre a definição do tema e a origem deste estudo. Na

Leia mais

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Gerenciamento de integração de projeto

Gerenciamento de integração de projeto Objetivos do Conteúdo Gerenciamento de integração de projeto Sergio Scheer / DCC / UFPR TC045 Gerenciamento de Projetos Prover capacitação para: - Identificar os processos de Gerenciamento de Projetos;

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Introdução. Gerência de Projetos de Software. Sumário. Sistemas de Informação para Processos Produtivos

Introdução. Gerência de Projetos de Software. Sumário. Sistemas de Informação para Processos Produtivos Sumário Sistemas de Informação para Processos Produtivos 1. Gerência de 2. Agentes principais e seus papéis 3. Ciclo de vida do gerenciamento de projetos M. Sc. Luiz Alberto lasf.bel@gmail.com Módulo 6

Leia mais

Porque estudar Gestão de Projetos?

Porque estudar Gestão de Projetos? Versão 2000 - Última Revisão 07/08/2006 Porque estudar Gestão de Projetos? Segundo o Standish Group, entidade americana de consultoria empresarial, através de um estudo chamado "Chaos Report", para projetos

Leia mais

Desenvolve Minas. Modelo de Excelência da Gestão

Desenvolve Minas. Modelo de Excelência da Gestão Desenvolve Minas Modelo de Excelência da Gestão O que é o MEG? O Modelo de Excelência da Gestão (MEG) possibilita a avaliação do grau de maturidade da gestão, pontuando processos gerenciais e resultados

Leia mais

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP Planejamento - 7 Planejamento do Gerenciamento do Risco Identificação dos riscos 1 O que é risco? Evento que representa uma ameaça ou uma oportunidade em potencial Plano de gerenciamento do risco Especifica

Leia mais

Unidade I Conceitos BásicosB. Conceitos BásicosB

Unidade I Conceitos BásicosB. Conceitos BásicosB à Engenharia de Software Unidade I Conceitos BásicosB Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br 1961 a 1963 Surgimento de novos Hardwares 1963-1968 Crise do Software! Incapacidade de se utilizar

Leia mais

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT Disciplina: Modelagem a Programação Orientada a Objetos

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Gerência de Projetos Prof. Késsia Rita da Costa Marchi 3ª Série kessia@unipar.br

Gerência de Projetos Prof. Késsia Rita da Costa Marchi 3ª Série kessia@unipar.br Gerência de Projetos Prof. Késsia Rita da Costa Marchi 3ª Série kessia@unipar.br Motivações Gerenciamento de projetos, vem sendo desenvolvido como disciplina desde a década de 60; Nasceu na indústria bélica

Leia mais

29/05/2012. Gestão de Projetos. Luciano Gonçalves de Carvalho FATEC. Agenda. Gerenciamento de Integração do Projeto Exercícios Referências FATEC

29/05/2012. Gestão de Projetos. Luciano Gonçalves de Carvalho FATEC. Agenda. Gerenciamento de Integração do Projeto Exercícios Referências FATEC Gestão de Projetos 1 Agenda Gerenciamento de Integração do Projeto Exercícios Referências 2 1 GERENCIAMENTO DA INTEGRAÇÃO DO PROJETO 3 Gerenciamento da Integração do Projeto Fonte: EPRoj@JrM 4 2 Gerenciamento

Leia mais

Ideal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê?

Ideal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê? Significado de XP? Extreme Programming (Programação Extrema). Ideal para que tipo de empresa (equipe): pequena, média, grande? Pequenas e Médias. Em software onde os requisitos não são conhecidos é recomendado

Leia mais

Roteiro SENAC. Análise de Riscos. Planejamento do Gerenciamento de Riscos. Planejamento do Gerenciamento de Riscos

Roteiro SENAC. Análise de Riscos. Planejamento do Gerenciamento de Riscos. Planejamento do Gerenciamento de Riscos SENAC Pós-Graduação em Segurança da Informação: Análise de Riscos Parte 2 Leandro Loss, Dr. Eng. loss@gsigma.ufsc.br http://www.gsigma.ufsc.br/~loss Roteiro Introdução Conceitos básicos Riscos Tipos de

Leia mais

Capítulo 2 Objetivos e benefícios de um Sistema de Informação

Capítulo 2 Objetivos e benefícios de um Sistema de Informação Capítulo 2 Objetivos e benefícios de um Sistema de Informação 2.1 OBJETIVO, FOCO E CARACTERÍSTICAS DOS SISTEMAS DE INFORMAÇÃO. Os Sistemas de Informação, independentemente de seu nível ou classificação,

Leia mais

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados 1. Introdução O governo é um dos maiores detentores de recursos da informação. Consequentemente, tem sido o responsável por assegurar que tais recursos estejam agregando valor para os cidadãos, as empresas,

Leia mais

Concurso da Prefeitura São Paulo. Curso Gestão de Processos, Projetos e Tecnologia da Informação. Tema: Gestão de Projetos - Conceitos Básicos

Concurso da Prefeitura São Paulo. Curso Gestão de Processos, Projetos e Tecnologia da Informação. Tema: Gestão de Projetos - Conceitos Básicos Contatos: E-mail: profanadeinformatica@yahoo.com.br Blog: http://profanadeinformatica.blogspot.com.br/ Facebook: https://www.facebook.com/anapinf Concurso da Prefeitura São Paulo Curso Gestão de Processos,

Leia mais

Questionário de Avaliação de Maturidade Setorial: Modelo PRADO-MMGP

Questionário de Avaliação de Maturidade Setorial: Modelo PRADO-MMGP DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo PRADO-MMGP Versão 1.6.4 Setembro 2009 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 2ª Edição (a publicar) Autor: Darci

Leia mais

METODOLOGIAS ÁGEIS - SCRUM -

METODOLOGIAS ÁGEIS - SCRUM - METODOLOGIAS ÁGEIS - SCRUM - André Roberto Ortoncelli ar_ortoncelli@hotmail.com 2010 Organização da Apresentação Introdução as Metodologias Ágeis Scrum Conceitos Básicos Artefatos Papeis Cerimônias Estórias

Leia mais

Profa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br

Profa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br Modelos de Processo Pessoal e de Equipe na Melhoria da Qualidade em Produção de Software Profa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br Agenda Importância das Pessoas / Constatações Compromisso

Leia mais

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto

Leia mais

Administração de Pessoas

Administração de Pessoas Administração de Pessoas MÓDULO 5: ADMINISTRAÇÃO DE RECURSOS HUMANOS 5.1 Conceito de ARH Sem as pessoas e sem as organizações não haveria ARH (Administração de Recursos Humanos). A administração de pessoas

Leia mais

PMBoK Comentários das Provas TRE-PR 2009

PMBoK Comentários das Provas TRE-PR 2009 PMBoK Comentários das Provas TRE-PR 2009 Comentário geral: As provas apresentaram grau de dificuldade médio. Não houve uma preocupação da banca em aprofundar os conceitos ou dificultar a interpretação

Leia mais

Leslier Soares Corrêa Estácio de Sá / Facitec Abril/Maio 2015

Leslier Soares Corrêa Estácio de Sá / Facitec Abril/Maio 2015 Leslier Soares Corrêa Estácio de Sá / Facitec Abril/Maio 2015 Prover capacitação para: - Identificar os processos de Gerenciamento de Projetos; - Desenvolver o Plano de Gerenciamento; - Construir um sistema

Leia mais

BSC Balance Score Card

BSC Balance Score Card BSC (Balance Score Card) BSC Balance Score Card Prof. Gerson gerson.prando@fatec.sp.gov.br Uma das metodologias mais visadas na atualidade éobalanced ScoreCard, criada no início da década de 90 por Robert

Leia mais

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

7 perguntas para fazer a qualquer fornecedor de automação de força de vendas

7 perguntas para fazer a qualquer fornecedor de automação de força de vendas 7 perguntas para fazer a qualquer fornecedor de automação de força de vendas 1. O fornecedor é totalmente focado no desenvolvimento de soluções móveis? Por que devo perguntar isso? Buscando diversificar

Leia mais

Gerenciamento de Projetos Modulo VIII Riscos

Gerenciamento de Projetos Modulo VIII Riscos Gerenciamento de Projetos Modulo VIII Riscos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Empreenda! 9ª Edição Roteiro de Apoio ao Plano de Negócios. Preparamos este roteiro para ajudá-lo (a) a desenvolver o seu Plano de Negócios.

Empreenda! 9ª Edição Roteiro de Apoio ao Plano de Negócios. Preparamos este roteiro para ajudá-lo (a) a desenvolver o seu Plano de Negócios. Empreenda! 9ª Edição Roteiro de Apoio ao Plano de Negócios Caro (a) aluno (a), Preparamos este roteiro para ajudá-lo (a) a desenvolver o seu Plano de Negócios. O Plano de Negócios deverá ter no máximo

Leia mais

PMBOK 4ª Edição III. O padrão de gerenciamento de projetos de um projeto

PMBOK 4ª Edição III. O padrão de gerenciamento de projetos de um projeto PMBOK 4ª Edição III O padrão de gerenciamento de projetos de um projeto 1 PMBOK 4ª Edição III Processos de gerenciamento de projetos de um projeto 2 Processos de gerenciamento de projetos de um projeto

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 03

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 03 PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 03 RELATÓRIO TÉCNICO CONCLUSIVO

Leia mais

Processos de Gerenciamento de Projetos. Planejamento e Controle de Projetos 5 TADS FSR. Processos

Processos de Gerenciamento de Projetos. Planejamento e Controle de Projetos 5 TADS FSR. Processos Processos de Gerenciamento de Projetos Planejamento e Controle de Projetos 5 TADS FSR Prof. Esp. André Luís Belini 2 Processos O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas

Leia mais

Géssica Talita. Márcia Verônica. Prof.: Edmilson

Géssica Talita. Márcia Verônica. Prof.: Edmilson Géssica Talita Márcia Verônica Prof.: Edmilson DESENVOLVIMENTO ÁGIL Técnicas foram criadas com o foco de terminar os projetos de software rapidamente e de forma eficaz. Este tipo de técnica foi categorizada

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Introdução. Toda organização executa basicamente dois tipos de atividade: Projeto; e. Operação (execução).

Introdução. Toda organização executa basicamente dois tipos de atividade: Projeto; e. Operação (execução). Gestão de Projetos Introdução Toda organização executa basicamente dois tipos de atividade: Projeto; e Operação (execução). O projeto é uma atividade muito particular, cuja finalidade principal é dar origem

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

POLÍTICA DE GESTÃO DE RISCO - PGR

POLÍTICA DE GESTÃO DE RISCO - PGR POLÍTICA DE GESTÃO DE RISCO - PGR DATASUS Maio 2013 Arquivo: Política de Gestão de Riscos Modelo: DOC-PGR Pág.: 1/12 SUMÁRIO 1. APRESENTAÇÃO...3 1.1. Justificativa...3 1.2. Objetivo...3 1.3. Aplicabilidade...4

Leia mais

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE Questionamento a alta direção: 1. Quais os objetivos e metas da organização? 2. quais os principais Produtos e/ou serviços da organização? 3. Qual o escopo da certificação? 4. qual é a Visão e Missão?

Leia mais

CAPÍTULO 25 COERÊNCIA REGULATÓRIA

CAPÍTULO 25 COERÊNCIA REGULATÓRIA CAPÍTULO 25 COERÊNCIA REGULATÓRIA Artigo 25.1: Definições Para efeito deste Capítulo: medida regulatória coberta significa a medida regulatória determinada por cada Parte a ser objeto deste Capítulo nos

Leia mais

FACULDADE PITÁGORAS DISCIPLINA: GESTÃO DE PROJETOS. Prof. Msc. Carlos José Giudice dos Santos

FACULDADE PITÁGORAS DISCIPLINA: GESTÃO DE PROJETOS. Prof. Msc. Carlos José Giudice dos Santos FACULDADE PITÁGORAS DISCIPLINA: GESTÃO DE PROJETOS Prof. Msc. Carlos José Giudice dos Santos O QUE SÃO PROCESSOS? De acordo com o Guia PMBOK, (2013) processo é um conjunto de ações e/ou atividades inter-relacionadas

Leia mais

Um passo inicial para aplicação do gerenciamento de projetos em pequenas empresas

Um passo inicial para aplicação do gerenciamento de projetos em pequenas empresas Instituto de Educação Tecnológica Pós-graduação Gestão de Projetos Aperfeiçoamento/GPPP1301 T132 09 de outubro de 2013 Um passo inicial para aplicação do gerenciamento de s em pequenas empresas Heinrich

Leia mais

Síntese do Projeto Pedagógico do Curso de Sistemas de Informação PUC Minas/São Gabriel

Síntese do Projeto Pedagógico do Curso de Sistemas de Informação PUC Minas/São Gabriel PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS Instituto de Informática Síntese do Projeto Pedagógico do Curso de Sistemas de Informação PUC Minas/São Gabriel Belo Horizonte - MG Outubro/2007 Síntese

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

Gestão e estratégia de TI Conhecimento do negócio aliado à excelência em serviços de tecnologia

Gestão e estratégia de TI Conhecimento do negócio aliado à excelência em serviços de tecnologia Gestão e estratégia de TI Conhecimento do negócio aliado à excelência em serviços de tecnologia Desafios a serem superados Nos últimos anos, executivos de Tecnologia de Informação (TI) esforçaram-se em

Leia mais

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Abstract. Resumo. 1. Introdução Vinicius A. C. de Abreu 1 Departamento de Ciência da Computação - DCC Universidade

Leia mais

A NECESSIDADE DE UMA NOVA VISÃO DO PROJETO NOS CURSOS DE ENGENHARIA CIVIL, FRENTE À NOVA REALIDADE DO SETOR EM BUSCA DA QUALIDADE

A NECESSIDADE DE UMA NOVA VISÃO DO PROJETO NOS CURSOS DE ENGENHARIA CIVIL, FRENTE À NOVA REALIDADE DO SETOR EM BUSCA DA QUALIDADE A NECESSIDADE DE UMA NOVA VISÃO DO PROJETO NOS CURSOS DE ENGENHARIA CIVIL, FRENTE À NOVA REALIDADE DO SETOR EM BUSCA DA QUALIDADE ULRICH, Helen Departamento de Engenharia de Produção - Escola de Engenharia

Leia mais

Curso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP

Curso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP Conceitos RUP RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo de Engenharia de software criado pela Rational Software Corporation(a qual foi incorporada pela

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DO DESEMPENHO

ADMINISTRAÇÃO GERAL GESTÃO DO DESEMPENHO ADMINISTRAÇÃO GERAL GESTÃO DO DESEMPENHO Atualizado em 30/12/2015 GESTÃO DE DESEMPENHO A gestão do desempenho constitui um sistemático de ações que buscam definir o conjunto de resultados a serem alcançados

Leia mais

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software Projeto e Desenvolvimento de Sistemas Dr. Fábio Levy Siqueira levy.siqueira@gmail.com Aula 2: Garantia da Qualidade e Padrões Qualidade de software Quais são as atividades de Gestão

Leia mais

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish

Leia mais

PLANO DE NEGÓCIOS. Causas de Fracasso:

PLANO DE NEGÓCIOS. Causas de Fracasso: PLANO DE NEGÓCIOS Causas de Fracasso: Falta de experiência profissional Falta de competência gerencial Desconhecimento do mercado Falta de qualidade dos produtos/serviços Localização errada Dificuldades

Leia mais

As Organizações e a Teoria Organizacional

As Organizações e a Teoria Organizacional Página 1 de 6 As Organizações e a Teoria Organizacional Autora: Sara Fichman Raskin Este texto é totalmente baseado no primeiro capítulo do livro Organizational theory: text and cases, do autor Jones Gareth,

Leia mais

Erros no Gerenciamento de Projetos em Inteligência Competitiva

Erros no Gerenciamento de Projetos em Inteligência Competitiva Erros no Gerenciamento de Projetos em Inteligência Competitiva Daniela Ramos Teixeira Muito já se escreveu sobre gerenciamento de projetos. Mas será que gerenciar projetos de inteligência competitiva (IC)

Leia mais

O Processo Unificado

O Processo Unificado UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo Unificado 879SCC Projeto e Desenvolvimento de Sistemas

Leia mais

agility made possible

agility made possible RESUMO DA SOLUÇÃO Utilitário ConfigXpress no CA IdentityMinder a minha solução de gerenciamento de identidades pode se adaptar rapidamente aos requisitos e processos de negócio em constante mudança? agility

Leia mais

Gestão do Conhecimento A Chave para o Sucesso Empresarial. José Renato Sátiro Santiago Jr.

Gestão do Conhecimento A Chave para o Sucesso Empresarial. José Renato Sátiro Santiago Jr. A Chave para o Sucesso Empresarial José Renato Sátiro Santiago Jr. Capítulo 1 O Novo Cenário Corporativo O cenário organizacional, sem dúvida alguma, sofreu muitas alterações nos últimos anos. Estas mudanças

Leia mais

Aula 2 Introdução ao Scrum

Aula 2 Introdução ao Scrum Curso Preparatório para a certificação Scrum Fundamentals Certified (SFC ) da ScrumStudy www.scrumstudy.com Aula 2 Introdução ao Scrum www.sitecampus.com.br - Cadastre-se gratuitamente para acessar ao

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

AS CONTRIBUIÇÕES DAS VÍDEO AULAS NA FORMAÇÃO DO EDUCANDO.

AS CONTRIBUIÇÕES DAS VÍDEO AULAS NA FORMAÇÃO DO EDUCANDO. AS CONTRIBUIÇÕES DAS VÍDEO AULAS NA FORMAÇÃO DO EDUCANDO. Autor: José Marcos da Silva Instituição: UFF/CMIDS E-mail: mzosilva@yahoo.com.br RESUMO A presente pesquisa tem como proposta investigar a visão

Leia mais

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br SCRUM Otimizando projetos Adilson Taub Júnior tecproit.com.br Sobre mim Adilson Taub Júnior Gerente de Processos Certified ScrumMaster; ITIL Certified; Cobit Certified; 8+ anos experiência com TI Especialista

Leia mais

Processos de Software

Processos de Software Processos de Software Prof. Márcio Lopes Cornélio Slides originais elaborados por Ian Sommerville O autor permite o uso e a modificação dos slides para fins didáticos O processo de Um conjunto estruturado

Leia mais

Projetos Ágeis aplicados a TI. Júlio Cesar da Silva Msc.

Projetos Ágeis aplicados a TI. Júlio Cesar da Silva Msc. Projetos Ágeis aplicados a TI Júlio Cesar da Silva Msc. Apresentação Graduação em Matemática e TI MBA em Gestão em TI Mestre em Administração Certificado ITIL, Cobit e ScrumMaster Professor Graduação Professor

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

6 Conclusão do estudo e implicações empresariais

6 Conclusão do estudo e implicações empresariais 6 Conclusão do estudo e implicações empresariais Este estudo buscou entender o fenômeno da criação de aceleradoras corporativas por parte de empresas de grande porte, com base na análise dos dois casos

Leia mais

Resumo artigo Agile Modeling- Overview

Resumo artigo Agile Modeling- Overview Universidade Federal de Santa Catarina Centro Tecnológico Disciplina: Projetos I Aluno: Diogo Ludvig 0313812-7 Resumo artigo Agile Modeling- Overview Este trabalho se refere ao resumo do artigo Agile Modeling,

Leia mais

Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização

Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização Prof. Ricardo José Pfitscher Material elaborado com base em: José Luiz Mendes Gerson Volney Lagemann Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

Gerenciamento de custos do projeto

Gerenciamento de custos do projeto PMBOK Visão Geral O PMBOK (Project Management Body of Knowledge) é um guia do Conjunto de Conhecimentos em de Projetos, o qual inclui práticas comprovadas que são amplamente aplicadas na gestão de s, além

Leia mais

PLANEJAMENTO ESTRATÉGICO

PLANEJAMENTO ESTRATÉGICO PLANEJAMENTO ESTRATÉGICO Este material resulta da reunião de fragmentos do módulo I do Curso Gestão Estratégica com uso do Balanced Scorecard (BSC) realizado pelo CNJ. 1. Conceitos de Planejamento Estratégico

Leia mais

Unidade II MODELAGEM DE PROCESSOS

Unidade II MODELAGEM DE PROCESSOS Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que

Leia mais

Scrum. Gestão ágil de projetos

Scrum. Gestão ágil de projetos Scrum Gestão ágil de projetos Apresentação feita por : Igor Macaúbas e Marcos Pereira Modificada por: Francisco Alecrim (22/01/2012) Metas para o o Metas para treinamento seminário Explicar o que é Scrum

Leia mais

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM Peterson Vieira Salme 1, Claudete Werner 1 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil petersonsalme@gmail.com, claudete@unipar.br

Leia mais

QUANDO este projeto deve ser realizado e QUANTO este projeto deverá custar?

QUANDO este projeto deve ser realizado e QUANTO este projeto deverá custar? O PROJECT MODEL CANVAS (www.pmcanvas.com.br) é uma ferramenta que permite que um projeto seja entendido no contexto dos aspectos Fundamentals da teoria de gerenciamento de projetos. A metodologia facilita

Leia mais

17/5/2009. Esta área de conhecimento tem o objetivo de utilizar de forma mais efetiva as pessoas envolvidas no projeto (equipe e stakeholders)

17/5/2009. Esta área de conhecimento tem o objetivo de utilizar de forma mais efetiva as pessoas envolvidas no projeto (equipe e stakeholders) Gerenciamento de Recursos Humanos do Projeto FAE S. J. dos Pinhais Projeto e Desenvolvimento de Software Gerenciamento de Recursos Humanos Esta área de conhecimento tem o objetivo de utilizar de forma

Leia mais

Organização. Trabalho realizado por: André Palma nº 31093. Daniel Jesus nº 28571. Fábio Bota nº 25874. Stephane Fernandes nº 28591

Organização. Trabalho realizado por: André Palma nº 31093. Daniel Jesus nº 28571. Fábio Bota nº 25874. Stephane Fernandes nº 28591 Organização Trabalho realizado por: André Palma nº 31093 Daniel Jesus nº 28571 Fábio Bota nº 25874 Stephane Fernandes nº 28591 Índice Introdução...3 Conceitos.6 Princípios de uma organização. 7 Posição

Leia mais

CAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com

CAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com CAPABILITY MATURITY MODEL FOR SOFTWARE Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com 1. Introdução Após décadas de incontáveis promessas sobre como aumentar à produtividade e qualidade de software,

Leia mais

Texto para Coluna do NRE-POLI na Revista Construção e Mercado Pini Dezembro 2013

Texto para Coluna do NRE-POLI na Revista Construção e Mercado Pini Dezembro 2013 Texto para Coluna do NRE-POLI na Revista Construção e Mercado Pini Dezembro 2013 PROPOSTA DE ESTRUTURA PARA O GERENCIAMENTO DE PROJETOS DE REVITALIZAÇÃO URBANA Núcleo de Real Estate, Mestrado, Mariana

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

08/05/2009. Cursos Superiores de. Prof.: Fernando Hadad Zaidan. Disciplina: PIP - Projeto Integrador de Pesquisa. Objetivos gerais e específicos

08/05/2009. Cursos Superiores de. Prof.: Fernando Hadad Zaidan. Disciplina: PIP - Projeto Integrador de Pesquisa. Objetivos gerais e específicos Faculdade INED Cursos Superiores de Tecnologia Disciplina: PIP - Projeto Integrador de Pesquisa Objetivos gerais e específicos Objetivo resultado a alcançar; Geral dá resposta ao problema; Específicos

Leia mais

CÓDIGO CRÉDITOS PERÍODO PRÉ-REQUISITO TURMA ANO INTRODUÇÃO

CÓDIGO CRÉDITOS PERÍODO PRÉ-REQUISITO TURMA ANO INTRODUÇÃO PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS ESCOLA DE GESTÃO E NEGÓCIOS CURSO DE CIÊNCIAS CONTÁBEIS, ADMINISTRAÇÃO E ECONOMIA DISCIPLINA: ESTRUTURA E ANÁLISE DE CUSTO CÓDIGO CRÉDITOS PERÍODO PRÉ-REQUISITO

Leia mais