BENEFITS OF AGILE METHODOLOGIES IN MANAGING PROJECTS INFORMATION TECHNOLOGY (IT)

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

Download "BENEFITS OF AGILE METHODOLOGIES IN MANAGING PROJECTS INFORMATION TECHNOLOGY (IT)"

Transcrição

1 1 DOI: / CONTECSI/RF-3782 BENEFITS OF AGILE METHODOLOGIES IN MANAGING PROJECTS INFORMATION TECHNOLOGY (IT) Greick Roger de C. Lima - Instituto de Pós-graduação e Graduação Goiás Brasil greickroger@yahoo.com.br Lucas Moreira Pires - Universidade Federal de Goiás Goiás Brasil lucasm.eng@gmail.com Júlio César Pessoa - Universidade Federal de Goiás Goiás Brasil juliopessoa@live.com Terezinha de Jesus Rodrigues de Sousa Universidade Federal de Goiás Goiás Brasil terezinharodrigues@outlook.com Adriano César Santana Universidade Federal de Goiás Goiás Brasil adrianosantana@gmail.com The Information Technology (IT) has been considered one of the most important components today, offering great opportunities for companies that succeed in harnessing the benefits offered by this use in business performance. The issue to be addressed concerns the relationship between the benefits offered by the use of agile methodologies to business performance, and its application in managing IT projects. The article aims to explore the concepts of agile methodologies, its appearance, application, key concepts and methods. Scrum methodologies are discussed, covering management of software projects, and Extreme Programming in the development context. Based on this preliminary assessment, we seek to identify in the literature some evidence of application of these methodologies in order to understand how the theory is being applied. This study is considered descriptive and exploratory, conducted through literature review. The results highlight that agile methodologies have been well accepted by the software industry and by researchers at the Software Engineering, when compared to traditional methods, due to satisfactory results. The conclusion of this study shows evidence of the way the market sees and uses agile methodologies today. With that favors the constant review of the concepts of the theory, allowing greater emphasis to those that are widely used with satisfactory results, in order to filter and propose changes to it are becoming archaic for lack of application. Keywords: Agile, Project management, Software Development, Scrum. BENEFÍCIOS DAS METODOLOGIAS ÁGEIS NO GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO (TI) 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 abordada 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. 0858

2 2 Palavras-chave:Metodologias ágeis, Gerenciamento de projetos, Desenvolvimento de Software, Scrum. 0859

3 3 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. 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, considerase a hipótese de que o uso de metodologias ágeis nos projetos, ajudam a construir somente o que o cliente valoriza, criando produtos melhores e 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 0860

4 4 empresas, envolvendo um levantamento de quais pontos estão sendo utilizados conforme a teoria e quais são descartadas, 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 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. 0861

5 5 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 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. 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. 0862

6 6 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 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. 0863

7 7 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 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). 0864

8 8 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; 9. Atenção contínua para uma excelência técnica e um bom design aumenta 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. 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 0865

9 9 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. 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, sejam 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 0866

10 10 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úblicoalvo. 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. 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 funcionam 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. 0867

11 11 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; Scrum Master: 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. Figura 1 - Esqueleto Scrum Fonte: Scrum Aliance (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 tornandose 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 0868

12 12 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). 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 ferramentas possíveis para a realização do trabalho e há mais sucesso 0869

13 13 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 Scrum Master. 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ária uma equipe maior no Scrum, é usado 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). 4.2 Artefatos 0870

14 14 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.3 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. 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 0871

15 15 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 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. 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 uma pessoa 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 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 0872

16 16 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 aplicar. Ninguém gosta de estar errado ou quebrar um acordo. O único modo de consertar um engano é admitir que houvesse 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. 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. 0873

17 17 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 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 0874

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software DCC / ICEx / UFMG Desenvolvimento Ágil de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Agenda Métodos ágeis Histórico e Motivação Manifesto ágil Desenvolvimento dirigido a planos e ágil

Leia mais

INTRODUÇÃO A ENGENHARIA DE SOFTWARE

INTRODUÇÃO A ENGENHARIA DE SOFTWARE Universidade Estadual Vale do Acaraú INTRODUÇÃO A ENGENHARIA DE SOFTWARE : Prof. Raquel Silveira Métodos ágeis focam em simplicidade, software funcional no início das iterações, flexibilidade e intensa

Leia mais

Scrum. Projeto de. Desenvolvimento. Software. Prof.: Ari Oliveira

Scrum. Projeto de. Desenvolvimento. Software. Prof.: Ari Oliveira Projeto de Desenvolvimento Software Prof.: Ari Oliveira As Metodologias Ágeis de Desenvolvimento de Software são indicadas como sendo uma opção às abordagens tradicionais para desenvolver softwares; Comparadas

Leia mais

SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos

SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos Jonas Analista de Negócios e Gerente de Projetos Fone:5184298411 Jonas.dc.cardoso@gmail.com 1 PROJETO Esforço temporário* para criar um produto,

Leia mais

Scrum. Daniel Krauze

Scrum. Daniel Krauze Scrum Daniel Krauze daniel.krauze@gmail.com http://danielkrauze.wordpress.com/ Quem eu sou... Porque Scrum?? Fundamentos do Scrum Valores e Princípios Pilares do Scrum Time Scrum Eventos do Scrum Daily

Leia mais

METODOLOGIAS ÁGEIS FEATURE DRIVEN DEVELOPMENT E AUP

METODOLOGIAS ÁGEIS FEATURE DRIVEN DEVELOPMENT E AUP Tecnologia em Análise e Desenvolvimento de Sistemas METODOLOGIAS ÁGEIS FEATURE DRIVEN DEVELOPMENT E AUP Definição, aplicações, vantagens e desvantagens Marcelo Buratti de Freitas Vitor Matheus Buratti

Leia mais

SCRUM aplicado na Gerência de Projetos

SCRUM aplicado na Gerência de Projetos SCRUM aplicado na Gerência de Projetos Processo Conjunto de atividades ordenadas, restrições e recursos que produzem um resultado de algum tipo. (Pfleeger) Em software: Processo de desenvolvimento Define

Leia mais

22/03/2018. Professor Ariel da Silva Dias RUP e Modelos Ágeis

22/03/2018. Professor Ariel da Silva Dias RUP e Modelos Ágeis Professor Ariel da Silva Dias RUP e Modelos Ágeis Modelo de processo de software proprietário. Desenvolvido pela empresa Rational Software Corporation. Em 2003 a empresa foi adquirida pela IBM. Então O

Leia mais

Metodologia Ágil com Scrum. Como uma ideia pode se tornar um software com a ajuda de boas práticas

Metodologia Ágil com Scrum. Como uma ideia pode se tornar um software com a ajuda de boas práticas Metodologia Ágil com Scrum Como uma ideia pode se tornar um software com a ajuda de boas práticas Quem sou eu Sou o Cristiano de Moraes, 38 anos, formado em Engenharia de Software, pós-graduado em Java

Leia mais

Scrum Foundations. Fundamentos de Scrum

Scrum Foundations. Fundamentos de Scrum Scrum Foundations Fundamentos de Scrum Sobre o curso Curso base para as funções de Scrum Developer e Scrum Master Histórico, Estrutura e Funções Scrum Product Owner Scrum Developer Scrum Master Artefatos

Leia mais

Desenvolvimento Ágil de Software. Prof. Edjandir Corrêa Costa

Desenvolvimento Ágil de Software. Prof. Edjandir Corrêa Costa Desenvolvimento Ágil de Software Prof. Edjandir Corrêa Costa edjandir.costa@ifsc.edu.br Métodos Ágeis História Na início da década de 90 havia uma visão de que a melhor maneira para se criar software era

Leia mais

Papel do PO Métodos Ágeis. Fonte: Adaptworks

Papel do PO Métodos Ágeis. Fonte: Adaptworks Papel do PO Métodos Ágeis Fonte: Adaptworks Scrum - Visão Geral Manifesto Ágil Indivíduos e interação entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente;

Leia mais

SCRUM Prof. Jair Galvão

SCRUM Prof. Jair Galvão 1 SCRUM Prof. Jair Galvão 2 Definição do Scrum Scrum é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos; Surgiu em 1990; Scrum não é um processo, é um

Leia mais

Modelos de Gestão de Projetos

Modelos de Gestão de Projetos Modelos de Gestão de Projetos Gestão de Projetos Tradicionais Criados para situações de baixo risco e incertezas, já existe conhecimento sobre o que será desenvolvido, o escopo envolvido e o objetivo proposto

Leia mais

ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE CURSO TÉCNICO DE INFORMÁTICA Módulo A ENGENHARIA DE SOFTWARE Processos de Software O PROCESSO É LENTO... Todo software deve ser construído de forma organizada, através de processos. Um processo pode ser

Leia mais

Manifesto Ágil Princípios

Manifesto Ágil Princípios Manifesto Ágil Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o cliente

Leia mais

O PAPEL DO ANALISTA DE NEGÓCIOS NA AGILIDADE. Ainda precisamos de Analistas de Negócios?

O PAPEL DO ANALISTA DE NEGÓCIOS NA AGILIDADE. Ainda precisamos de Analistas de Negócios? O PAPEL DO ANALISTA DE NEGÓCIOS NA AGILIDADE Ainda precisamos de Analistas de Negócios? Camila Capellão Entusiasta em agilidade, participo ativamente da comunidade ágil Tenho mais de 13 anos de experiência

Leia mais

Métodos Ágeis e o SCRUM. Bruno Henrique Oliveira

Métodos Ágeis e o SCRUM. Bruno Henrique Oliveira Métodos Ágeis e o SCRUM Bruno Henrique Oliveira Apresentação Formado em BCC Consultoria Gestão de projetos e implantação de escritório de projetos ITIL e ECM Candidato a título de mestre em Engenharia

Leia mais

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE 1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE Nickerson Fonseca Ferreira nickerson.ferreira@ifrn.edu.br Introdução 2 Antes de qualquer

Leia mais

Scrum e Extreme Programming

Scrum e Extreme Programming Scrum e Extreme Programming CODEX Sumário Objetivo 3 Scrum 4 Papéis de Atuação 4 Eventos do Scrum 5 Artefatos do Scrum 5 Porque Scrum? 5 Extreme Programming 6 Práticas do Extreme Programming 6 Porque XP?

Leia mais

SCRUM Na Prática o que importa são os Valores. Danilo Bardusco Gerente Geral de Desenvolvimento

SCRUM Na Prática o que importa são os Valores. Danilo Bardusco Gerente Geral de Desenvolvimento SCRUM Na Prática o que importa são os Valores. Danilo Bardusco Gerente Geral de Desenvolvimento Abstract Nessa palestra você vai descobrir por que os Princípios e Valores do SCRUM

Leia mais

O que ele não é? Um método ou técnica definitiva para desenvolvimento de um produto.

O que ele não é? Um método ou técnica definitiva para desenvolvimento de um produto. Scrum Lucas Roque 1. Visão Geral O que é Scrum? Um framework desenvolvido para que pessoas possam solucionar problemas complexos e adaptativos, ao mesmo tempo que produzem produtos de alto valor. Características?

Leia mais

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC) SIMULADO DO EXAME Sample Test V092018

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC) SIMULADO DO EXAME Sample Test V092018 SIMULADO DO EXAME Sample Test V092018 1. O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. 2. Scrum é um(a) que está sendo utilizado para gerenciar o trabalho em

Leia mais

PDS. Aula 1.10 SCRUM. Prof. Dr. Bruno Moreno

PDS. Aula 1.10 SCRUM. Prof. Dr. Bruno Moreno PDS Aula 1.10 SCRUM Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br Visão Geral 2 Artefatos Estórias; Product Backlog; Sprint Backlog; Gráfico Burndown; 3 Artefatos Estórias; Product Backlog; Sprint Backlog;

Leia mais

ENGENHARIA DE SOFTWARE. SCRUM Carlos Mar, Msc. Maio/2014

ENGENHARIA DE SOFTWARE. SCRUM Carlos Mar, Msc. Maio/2014 ENGENHARIA DE SOFTWARE SCRUM Carlos Mar, Msc. Maio/2014 SCRUM Is a simple yet incredibly powerful set of principles and practices that help teams deliver products in short cycles, enabling fast feedback,

Leia mais

SCRUM Agilidade na Gestão de Projetos

SCRUM Agilidade na Gestão de Projetos SCRUM Agilidade na Gestão de Projetos Prof. Flávio Barros flavioifma@gmail.com 2 www.flaviobarros.com.br 3 MOTIVAÇÃO POR QUE OS PROJETOS FALHAM 4 POR QUE OS PROJETOS FALHAM 5 http://metaconsulting.blogspot.com.br/2016/03/blog-post.html

Leia mais

Aula 03 Gestão de projetos em arquitetura

Aula 03 Gestão de projetos em arquitetura Aula 03 Gestão de projetos em arquitetura AUT 0593 1 Semestre 2019 Projeto: iniciativa planejada para atingir objetivo específico Temporário: início e fim definidos Resultado único: diferente dos anteriores

Leia mais

Processos Ágeis de Desenvolvimento de Software. Yuri Pereira

Processos Ágeis de Desenvolvimento de Software. Yuri Pereira Processos Ágeis de Desenvolvimento de Software Yuri Pereira ycssp@cin.ufpe.br Contexto Processos ágeis surgiram como alternativa aos processos tradicionais...... que apresentam restrições principalmente

Leia mais

Engenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata

Engenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata Processo de Desenvolvimento Também chamado de ciclo de vida do software Reflete os passos necessários para se construir um produto de software Existem vários modelos de ciclo de vida Cascata (1956) Iterativo

Leia mais

Projetos Visão Geral Esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Projetos Visão Geral Esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Projetos Visão Geral Esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Expressões usadas para definir projetos: Empreendimento único, não repetitivo; Sequência clara

Leia mais

Engenharia Software. Ení Berbert Camilo Contaiffer

Engenharia Software. Ení Berbert Camilo Contaiffer Engenharia Software Ení Berbert Camilo Contaiffer Características do Software Software não é um elemento físico, é um elemento lógico; Software é desenvolvido ou projetado por engenharia, não manufaturado

Leia mais

Gestão de Projetos. Requisito é a tradução das necessidades e expectativas dos clientes e das demais partes interessadas (stakeholders).

Gestão de Projetos. Requisito é a tradução das necessidades e expectativas dos clientes e das demais partes interessadas (stakeholders). Gestão de Projetos Tomar decisões e realizar ações de planejamento, execução e controle do ciclo de vida do projeto. Combinação de pessoas, técnicas e sistemas necessários à administração dos recursos

Leia mais

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC) SIMULADO DO EXAME Sample Test V092018

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC) SIMULADO DO EXAME Sample Test V092018 SIMULADO DO EXAME Sample Test V092018 1. Se a reunião diária do Scrum tem uma duração de 15 minutos, então... A. A Revisão da Sprint tem duração de 4 horas. B. A Revisão da Sprint tem duração de 1 hora.

Leia mais

ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE ENGENHARIA DE SOFTWARE Curso: Sistemas de Informação Profª: Janaide Nogueira ENGENHARIA DESOFTWARE APRESENTAÇÃO Formação Técnica: Informática(IFCE-Campus Tianguá-CE) Secretária Escolar(FDR) Graduação:

Leia mais

Engenharia da Computação. Tópicos Avançados em Engenharia de Software. Aula 2

Engenharia da Computação. Tópicos Avançados em Engenharia de Software. Aula 2 Engenharia da Computação Tópicos Avançados em Engenharia de Software Aula 2 (01/03) mario.godoy@univasf.edu.br http://www.univasf.edu.br/~mario.godoy/ Universidade Federal do Vale do São Francisco - UNIVASF

Leia mais

Engenharia de Software. Herbert Rausch Fernandes

Engenharia de Software. Herbert Rausch Fernandes Engenharia de Software Herbert Rausch Fernandes Scrum Não é uma metodologia que fará você desenvolver produtos melhores; Não te dá as respostas e não é uma bala de prata; Scrum é simplesmente um framework;

Leia mais

Processos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Prof. Cristiane Aparecida Lana slide 1 Bibliografia utilizada: Mais opções visite meu site, clique aqui para acessá-lo. slide 2 2011 Pearson 2011 Pearson Prentice Prentice

Leia mais

Prof. Luiz A. Nascimento. As práticas denominadas ágeis vêm sendo cada vez mais utilizadas na gerência de projetos de software.

Prof. Luiz A. Nascimento. As práticas denominadas ágeis vêm sendo cada vez mais utilizadas na gerência de projetos de software. Prof. Luiz A. Nascimento As práticas denominadas ágeis vêm sendo cada vez mais utilizadas na gerência de projetos de software. Porque metodologias ágeis? A história dos fracassos no desenvolvimento de

Leia mais

Metodologias Ágeis de Desenvolvimento. Fernando Trinta

Metodologias Ágeis de Desenvolvimento. Fernando Trinta Metodologias Ágeis de Desenvolvimento Fernando Trinta Contextualização A Engenharia de software vêm recorrentemente enfrentando o cenário onde... as aplicações são cada vez mais complexas... o tempo de

Leia mais

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) A Rational é bem conhecida pelo seu investimento em orientação em objetos. A empresa foi à criadora da Unified Modeling Language (UML), assim como de várias ferramentas que

Leia mais

2 Processos Ágeis Scrum

2 Processos Ágeis Scrum 2 Processos Ágeis Processos ágeis, também conhecidos como métodos ágeis, referem-se a um grupo de processos de desenvolvimento de software baseados em desenvolvimento iterativo, onde os requisitos e as

Leia mais

Engenharia de Software DESENVOLVIMENTO ÁGIL

Engenharia de Software DESENVOLVIMENTO ÁGIL Engenharia de Software DESENVOLVIMENTO ÁGIL Em 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e consultores da área de software assinaram o Manifesto para Desenvolvimento Ágil de

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Processos de Software Professor: Charles Leite O processo de software Um conjunto estruturado de atividades, procedimentos, artefatos e ferramentas necessários para o desenvolvimento

Leia mais

Adoção de metodologia ágil baseada em Scrum - Case da Procergs

Adoção de metodologia ágil baseada em Scrum - Case da Procergs Adoção de metodologia ágil baseada em Scrum - Case da Procergs Outubro / 2014 Fundamentos do Scrum Pilares do Scrum Procergs Procergs - Setor de Fábrica SD1 Quem sou... Porque mudar a forma de trabalho?

Leia mais

GPS Gestão de projeto de software Aula 7a - Scrum. Professor Emiliano S. Monteiro

GPS Gestão de projeto de software Aula 7a - Scrum. Professor Emiliano S. Monteiro GPS Gestão de projeto de software Aula 7a - Scrum Professor Emiliano S. Monteiro http://www.desenvolvimentoagil.com.br/scrum/ Esquema Scrum Definição É um framework para gerenciar o desenvolvimento de

Leia mais

INSTITUTO FEDERAL DE SÃO PAULO CAMPUS PRESIDENTE EPITÁCIO MODELO DOS PROCESSOS DE SOFTWARE

INSTITUTO FEDERAL DE SÃO PAULO CAMPUS PRESIDENTE EPITÁCIO MODELO DOS PROCESSOS DE SOFTWARE INSTITUTO FEDERAL DE SÃO PAULO CAMPUS PRESIDENTE EPITÁCIO CURSO ANÁLISE E DESENVOLVIMENTO DE SISTEMA MODELO DOS PROCESSOS DE SOFTWARE ALUNO SAMUEL BRAGA LOPES SUMÁRIO - AGENDA INTRODUÇÃO MODELO CASCATA

Leia mais

Processos de Gerenciamento de Projetos. Parte 02. Gerenciamento de Projetos Espaciais CSE-301. Docente: Petrônio Noronha de Souza

Processos de Gerenciamento de Projetos. Parte 02. Gerenciamento de Projetos Espaciais CSE-301. Docente: Petrônio Noronha de Souza Processos de Gerenciamento de Projetos Parte 02 CSE-301 / 2009 / Parte 02 Gerenciamento de Projetos Espaciais CSE-301 Docente: Petrônio Noronha de Souza Curso: Engenharia e Tecnologia Espaciais Concentração:

Leia mais

Escolhendo um Modelo de Ciclo de Vida

Escolhendo um Modelo de Ciclo de Vida Escolhendo um Modelo de Ciclo de Vida Ciclos de Vida 1 Ciclo de Vida de um Produto Qualquer desenvolvimento de produto inicia com uma idéia e termina com o produto pretendido. O ciclo de vida de um produto

Leia mais

PDS. Aula 1.9 SCRUM. Prof. Dr. Bruno Moreno

PDS. Aula 1.9 SCRUM. Prof. Dr. Bruno Moreno PDS Aula 1.9 SCRUM Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br 2 Introdução O nome SCRUM é derivado do Rugby É um método de reinício de jogada; Os jogadores se empurram para pegar a bola; Envolve o

Leia mais

Processos Ágeis de Desenvolvimento de Software

Processos Ágeis de Desenvolvimento de Software Processos Ágeis de Desenvolvimento de Software -Focono XP - Rodrigo Rebouças de Almeida rodrigor@rodrigor.com Processo Conjunto de atividades ordenadas, restrições e recursos que produzem um resultado

Leia mais

Engenharia de Software. Prof. Me. Clodoaldo Brasilino

Engenharia de Software. Prof. Me. Clodoaldo Brasilino Engenharia de Software Prof. Me. Clodoaldo Brasilino clodoaldo.neto@ifpi.edu.br Acompanhamento da Disciplina 1. Introdução à Engenharia de Software 2. Processos de Software e Projetos 3. Metodologia Ágil

Leia mais

Implementação de um sistema para gerenciamento de projetos baseado no Framework Scrum: um estudo de caso

Implementação de um sistema para gerenciamento de projetos baseado no Framework Scrum: um estudo de caso ISSN 23162872 T.I.S. São Carlos, v. 1, n. 1, p. 8290, jul. 2012 Tecnologias, Infraestrutura e Software Implementação de um sistema para gerenciamento de projetos baseado no Framework Scrum: um estudo de

Leia mais

Ainda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existem alguns aspectos que os diferenciam:

Ainda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existem alguns aspectos que os diferenciam: Prof. Edson dos Santos Cordeiro 1 Tópico: Objetivo: Introdução a Ciclo de Vida do Software Conhecer os principais conceitos relacionados a ciclo de vida do software. Bibliog. Base: McCONNEL, Steve. Rapid

Leia mais

PDS. Aula 1.4 Modelos de Processo. Prof. Dr. Bruno Moreno

PDS. Aula 1.4 Modelos de Processo. Prof. Dr. Bruno Moreno PDS Aula 1.4 Modelos de Processo Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br 2 Introdução Há alguns anos, o desenvolvimento de softwares era muito obsoleto; Existiam diversos problemas relacionados

Leia mais

Visão Geral do Processo de Desenvolvimento de Software Introdução aos Sistemas de Informação

Visão Geral do Processo de Desenvolvimento de Software Introdução aos Sistemas de Informação - Centro de Ciências Exatas, Naturais e de Saúde Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução aos Sistemas de Informação COM06852 - Introdução aos SI Prof.

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos MBA em EXCELÊNCIA EM GESTÃO DE PROJETOS E PROCESSOS ORGANIZACIONAIS Gerenciamento de s Planejamento e Gestão de s Prof. Msc. Maria C Lage Prof. Gerenciamento de Integração Agenda Gerenciamento da Integração

Leia mais

METODOLOGIA ÁGEIS FDD FEATURE DRIVEN DEVELOPMENT. Prof. Fabiano Papaiz IFRN

METODOLOGIA ÁGEIS FDD FEATURE DRIVEN DEVELOPMENT. Prof. Fabiano Papaiz IFRN METODOLOGIA ÁGEIS FDD FEATURE DRIVEN DEVELOPMENT Prof. Fabiano Papaiz IFRN Feature Driven Development = Desenvolvimento Guiado por Funcionalidades FDD é uma metodologia ágil para gerenciamento e desenvolvimento

Leia mais

INF014 Análise e Projeto de Sistemas Processos Unificado -RUP

INF014 Análise e Projeto de Sistemas Processos Unificado -RUP INF014 Análise e Projeto de Sistemas Processos Unificado -RUP Maurício Pitangueira antoniomauricio@ifba.edu.br Instituto Federal de Educação, Ciência e Tecnologia da Bahia Departamento de Tecnologia Eletro-Eletrônica

Leia mais

15/03/2018. Professor Ariel da Silva Dias Modelos de Processo de Software

15/03/2018. Professor Ariel da Silva Dias Modelos de Processo de Software Professor Ariel da Silva Dias Modelos de Processo de Software Conjunto de atividades que leva à produção de um produto de Software [Sommerville,2011]; Podemos contar com ferramentas de apoio com o objetivo

Leia mais

FUNDAMENTOS DA ANÁLISE E PROJETO DE SISTEMAS. Projeto de Programas PPR0001

FUNDAMENTOS DA ANÁLISE E PROJETO DE SISTEMAS. Projeto de Programas PPR0001 FUNDAMENTOS DA ANÁLISE E PROJETO DE SISTEMAS Projeto de Programas PPR0001 2 Introdução Antes de desenvolver ou construir qualquer produto ou sistema em engenharia é necessário um... o PROJETO O que é um

Leia mais

Análise e Projeto. Prof. Erinaldo Sanches Nascimento

Análise e Projeto. Prof. Erinaldo Sanches Nascimento Análise e Projeto Prof. Erinaldo Sanches Nascimento Objetivos Apresentar o ciclo de vida de desenvolvimento de sistemas. Descrever as metodologias de desenvolvimento de sistemas. 2 Introdução Programação

Leia mais

PROJETO EM SISTEMAS DE INFORMAÇÃO. Unidade I - Metodologia de desenvolvimento a ser adotada. Luiz Leão

PROJETO EM SISTEMAS DE INFORMAÇÃO. Unidade I - Metodologia de desenvolvimento a ser adotada. Luiz Leão Unidade I - Metodologia de desenvolvimento a ser adotada Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático Exposição das metodologias possíveis, conforme o tipo de projeto; Fundamentação

Leia mais

MANIFESTO ÁGIL, SCRUM E EXTREME PROGRAMMING COMO CONSTRUIR SOFTWARE COM QUALIDADE E QUE AGREGAM VALOR AO CLIENTE?

MANIFESTO ÁGIL, SCRUM E EXTREME PROGRAMMING COMO CONSTRUIR SOFTWARE COM QUALIDADE E QUE AGREGAM VALOR AO CLIENTE? MANIFESTO ÁGIL, SCRUM E EXTREME PROGRAMMING COMO CONSTRUIR SOFTWARE COM QUALIDADE E QUE AGREGAM VALOR AO CLIENTE? CAIO ROSÁRIO DIAS FORMADO EM TÉCNICO DE INFORMÁTICA IFBA; QUINTO SEMESTRE DO CURSO DE ANALISE

Leia mais

PROJETO INTEGRADO AULA 4 INTEGRAÇÃO E ESCOPO

PROJETO INTEGRADO AULA 4 INTEGRAÇÃO E ESCOPO PROJETO INTEGRADO AULA 4 INTEGRAÇÃO E ESCOPO PROF.: KAIO DUTRA Gerenciamento da Integração do Projeto O gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar,

Leia mais

BENEFÍCIOS DA AGILIDADE

BENEFÍCIOS DA AGILIDADE BENEFÍCIOS DA AGILIDADE COMO O ÁGIL PODE MELHORAR OS SEUS PROJETOS AGILEIT COACH INSTITUTE TABELA DE CONTEÚDOS 01 Há muitos projetos falhando! 03 ANTECIPAR Valor de Negócios 05 Como ANTECIPAR O ROI é POSSÍVEL?

Leia mais

Scrum. Adriano J. Holanda 18/10/2016. [Fundamentos de Sistemas de Informação II]

Scrum. Adriano J. Holanda 18/10/2016. [Fundamentos de Sistemas de Informação II] Scrum [Fundamentos de Sistemas de Informação II] Adriano J. Holanda 18/10/2016 Referências Reusable Scrum Presentation. Mountain Goat Software. Scrum (desenvolvimento de software). Wikipedia. Scrum: a

Leia mais

Processos de software

Processos de software Processos de software 1 Processos de software Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software. 2 Objetivos Introduzir modelos de processos de

Leia mais

Gerência de Projetos. Elias Ferreira

Gerência de Projetos. Elias Ferreira Gerência de Projetos Elias Ferreira Administrando um Depto de TI Podemos identificar quatro grandes áreas: Aplicativos: desenvolvimento, atualização e implantação de aplicativos ou softwares Serviços:

Leia mais

4/14/11. Processos de Engenharia de Requisitos. Engenharia de requisitos. Elicitação e análise. A espiral de requisitos

4/14/11. Processos de Engenharia de Requisitos. Engenharia de requisitos. Elicitação e análise. A espiral de requisitos Processos de engenharia de requisitos Processos de Engenharia de Requisitos Os requisitos e as formas de obtê-los e documentálos variam drasticamente de um projeto para o outro Contudo, existe uma série

Leia mais

Metodologia SCRUM. Figura 1 - Estrutura de processo do Scrum. [2]

Metodologia SCRUM. Figura 1 - Estrutura de processo do Scrum. [2] Guia SCRUM Sumário Metodologia SCRUM... 3 1. Time Scrum... 4 1.1. Proprietário do Produto... 4 1.2. Time de Desenvolvimento... 4 1.3. Líder Scrum... 5 2. Eventos Scrum... 6 2.1. Sprint... 6 2.2. Reunião

Leia mais

19/03/2018. Engenharia de Software. Prof. Luís Fernando GARCIA.

19/03/2018. Engenharia de Software. Prof. Luís Fernando GARCIA. Engenharia de Software 2 Prof. Luís Fernando GARCIA luis@garcia.pro.br www.garcia.pro.br 1 Parte 3 Processos de Desenvolvimento Ágeis Bibliografia Leituras ALTAMENTE recomendadas! 2 5 6 3 Descontraindo...

Leia mais

PRODUCT BACKLOG. Aula de Luiz Eduardo Guarino de Vasconcelos

PRODUCT BACKLOG. Aula de Luiz Eduardo Guarino de Vasconcelos PRODUCT BACKLOG Aula de Luiz Eduardo Guarino de Vasconcelos Product Backlog Introdução O PO é a única pessoa responsável por gerir o Product Backlog e assegurar o valor do trabalho feito pelo Team. Este

Leia mais

RUP/PSDS. Introdução e Comparação

RUP/PSDS. Introdução e Comparação RUP/PSDS Introdução e Comparação Agenda RUP Introdução Mlehores Práticas Estrutura Tempo Conteúdo Contraponto PSDS Introdução Objetivos Promover planejamento, medição e controle dos projetos Reduzir riscos

Leia mais

Introdução a Gerencia de Projetos

Introdução a Gerencia de Projetos MBA EM GERENCIA DE PROJETOS Introdução a Gerencia de Projetos Rogério Santos Gonçalves 1 Agenda 1. Introdução ao Curso de Gerencia de Projetos 2. Conceitos Básicos sobre Gerenciamento de Projetos. 1. O

Leia mais

PDS. Aula 1.7 Métodos Ágeis. Prof. Dr. Bruno Moreno

PDS. Aula 1.7 Métodos Ágeis. Prof. Dr. Bruno Moreno PDS Aula 1.7 Métodos Ágeis Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br O que é ser ágil? 2 Definição Ágil: Refere-se a capacidade de criar e responder a mudanças com o objetivo de ter sucesso em um

Leia mais

INSTITUTO FEDERAL DO MARANHÃO - CAMPUS CAXIAS BACHARELADO E CIÊNCIA DA COMPUTAÇÃO TÓPICOS EM ENGENHARIA DE SISTEMAS DOCENTE: FLÁVIO BARROS

INSTITUTO FEDERAL DO MARANHÃO - CAMPUS CAXIAS BACHARELADO E CIÊNCIA DA COMPUTAÇÃO TÓPICOS EM ENGENHARIA DE SISTEMAS DOCENTE: FLÁVIO BARROS INSTITUTO FEDERAL DO MARANHÃO - CAMPUS CAXIAS BACHARELADO E CIÊNCIA DA COMPUTAÇÃO - 2015.1 TÓPICOS EM ENGENHARIA DE SISTEMAS DOCENTE: FLÁVIO BARROS Desenvolvimento de Ágil de Sistemas SCRUM 1 Desenvolvimento

Leia mais

MODELOS DE PROCESSO TÉCNICAS INTELIGENTES QUE APOIAM A CONSTRUÇÃO DE UM SOFTWARE

MODELOS DE PROCESSO TÉCNICAS INTELIGENTES QUE APOIAM A CONSTRUÇÃO DE UM SOFTWARE MODELOS DE PROCESSO TÉCNICAS INTELIGENTES QUE APOIAM A CONSTRUÇÃO DE UM SOFTWARE Ana Paula Carrion 1, Claudete Werner 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil anapaulacarrion@hotmail.com,

Leia mais

Processos de Software

Processos de Software DCC / ICEx / UFMG Processos de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Processos Procedimentos e métodos definindo relação entre tarefas PROCESSO Pessoas com habilidades, treinadas

Leia mais

XP EXTREME PROGRAMMING. AGO106 - Gestão

XP EXTREME PROGRAMMING. AGO106 - Gestão XP EXTREME PROGRAMMING AGO106 - Gestão de Processos de Desenvolvimento de Software DESENVOLVIMENTO TRADICIONAL Sequencial: Análise, Design, Implementação, Teste, Implantação e Manutenção Características:

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda Rodrigo Reis Cleidson de Souza! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados!

Leia mais

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS. Nome:

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS. Nome: Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS Nome: 1. A figura abaixo representa, simplificadamente, as fases do Modelo de Ciclo de Vida Cascata.

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 Para Sommerville a arquitetura de sistemas descreve o sistema em termos de um conjunto de unidades

Leia mais

1. A função DevOps, que se concentra principalmente em Produtos & Serviços:

1. A função DevOps, que se concentra principalmente em Produtos & Serviços: Questões de múltipla escolha 1. A função DevOps, que se concentra principalmente em Produtos & Serviços: a) Desenvolvimento Ágil b) Melhoria Contínua c) Automatizar tudo d) Centralizar o Desenvolvimento

Leia mais

Extreme Programming. Projeto de. Desenvolvimento. Software. Prof.: Ari Oliveira

Extreme Programming. Projeto de. Desenvolvimento. Software. Prof.: Ari Oliveira Projeto de Desenvolvimento Software Extreme Programming Prof.: Ari Oliveira O Extreme Programming (XP) é uma metodologia de desenvolvimento de software que auxilia na produção de sistemas de maior qualidade,

Leia mais

Engenharia de Software

Engenharia de Software PLANO DE AVALIAÇÕES Engenharia de Software 1ª AP: 08 de setembro 2ª AP: 13 de outubro 3ª AP: 10 de novembro NAF: 17 de novembro Referência bibliográfica: SOMMERVILLE, I. Engenharia de Software. 8ª ed.

Leia mais

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS 1. Com relação à engenharia de software, julgue os itens seguintes. Engenharia de software não está relacionada

Leia mais

PDS. Aula 1.5 Modelos de Processo. Prof. Dr. Bruno Moreno

PDS. Aula 1.5 Modelos de Processo. Prof. Dr. Bruno Moreno PDS Aula 1.5 Modelos de Processo Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br Tipos de Modelos Modelo em Cascata; Prototipação; RAD; Modelo Incremental; Desenvolvimento Evolucionário; Desenvolvimento

Leia mais

Processos de Software

Processos de Software Riscos Processos de Software Gidevaldo Novais (gidevaldo.vic@ftc.br) Muitos problemas no desenvolvimento de software provêm de riscos Seriam problemas potenciais que poderão ocorrer em um futuro próximo

Leia mais

Processo de Desenvolvimento. Edjandir Corrêa Costa

Processo de Desenvolvimento. Edjandir Corrêa Costa Processo de Desenvolvimento Edjandir Corrêa Costa edjandir.costa@ifsc.edu.br Processo de Desenvolvimento Definição: É um roteiro que determina quais são as tarefas necessárias e em que ordem elas devem

Leia mais

Engenharia de Software. Processos. Desenvolvimento de Software Tradicionais 2014/2. Prof. Luís Fernando Garcia

Engenharia de Software. Processos. Desenvolvimento de Software Tradicionais 2014/2. Prof. Luís Fernando Garcia Engenharia de Software Processos Desenvolvimento de Software Tradicionais 2014/2 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR Processos Um conjunto estruturado de atividades necessárias para o desenvolvimento

Leia mais

Aula 3 - Modelos de Processo - cascata, iterativo e incremental e ágil

Aula 3 - Modelos de Processo - cascata, iterativo e incremental e ágil Aula 3 - Modelos de Processo - cascata, iterativo e incremental e ágil Análise de Sistemas Prof. Filipe Arantes Fernandes filipe.arantes@ifsudestemg.edu.br 2 Vale a pena ver de novo Modelo de Processo:

Leia mais

INTRODUÇÃO À GESTÃO DE PROJETO. Profª Andrea Padovan Jubileu

INTRODUÇÃO À GESTÃO DE PROJETO. Profª Andrea Padovan Jubileu INTRODUÇÃO À GESTÃO DE PROJETO Profª Andrea Padovan Jubileu O que é um projeto? Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo Temporário Cada projeto

Leia mais

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS Prof. Fabiano Papaiz IFRN O RUP recomenda as seguintes práticas que devem ser utilizadas no desenvolvimento de um software: 1. Desenvolver de forma iterativa

Leia mais

Gestão de Projetos Projeto: esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Gestão de Projetos Projeto: esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Gestão de Projetos Projeto: esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Singularidade, Temporariedade, Incerteza, Elaboração Progressiva, Recursos limitados, Interdisciplinaridade,

Leia mais

Gerenciamento da Integração de Projetos. Parte 03. Gerenciamento de Projetos Espaciais CSE-301. Docente: Petrônio Noronha de Souza

Gerenciamento da Integração de Projetos. Parte 03. Gerenciamento de Projetos Espaciais CSE-301. Docente: Petrônio Noronha de Souza Gerenciamento da Integração de Projetos Parte 03 Gerenciamento de Projetos Espaciais CSE-301 Docente: Petrônio Noronha de Souza Curso: Engenharia e Tecnologia Espaciais Concentração: Engenharia e Gerenciamento

Leia mais

Uma breve visão sobre a metodologia scrum dos discentes de sistema de informação da faculdade projeção de Sobradinho/DF

Uma breve visão sobre a metodologia scrum dos discentes de sistema de informação da faculdade projeção de Sobradinho/DF Uma breve visão sobre a metodologia scrum dos discentes de sistema de informação da faculdade projeção de Sobradinho/DF Douglas Martins Neves Leonardo Paiva Campos de Melo Rogério Oliveira da Silva Resumo:

Leia mais

Cultura Ágil e SCRUM. Bruno Oliveira.

Cultura Ágil e SCRUM. Bruno Oliveira. Cultura Ágil e SCRUM Bruno Oliveira bruno@arquivei.com.br Mas o que são MÉTODOS ÁGEIS? Motivação Requirements Design Implementation Verification Maintenance Abordagem Funciona...as vezes!!!! Contratos

Leia mais

QUESTIONÁRIO PARA PROVA DE GESTÃO DE PROJETOS

QUESTIONÁRIO PARA PROVA DE GESTÃO DE PROJETOS QUESTIONÁRIO PARA PROVA DE GESTÃO DE PROJETOS 1. Quais são os níveis de escritórios no Projeto? As responsabilidades de um PMO, podem variar desde fornecer funções de suporte ao gerenciamento de projetos

Leia mais