CENTRO EDUCACIONAL DA FUNDAÇÃO SALVADOR ARENA FACULDADE DE TECNOLOGIA TERMOMECANICA

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

Download "CENTRO EDUCACIONAL DA FUNDAÇÃO SALVADOR ARENA FACULDADE DE TECNOLOGIA TERMOMECANICA"

Transcrição

1 CENTRO EDUCACIONAL DA FUNDAÇÃO SALVADOR ARENA FACULDADE DE TECNOLOGIA TERMOMECANICA GUSTAVO SOUZA LOPES MARCELO LUIZ ESPERATI PAGOTI RAFAEL ORTEGA CAMPANA GERENCIAMENTO DE PROJETOS ÁGIL SCRUM SÃO BERNARDO DO CAMPO 2009

2 GUSTAVO SOUZA LOPES MARCELO LUIZ ESPERATI PAGOTI RAFAEL ORTEGA CAMPANA GERENCIAMENTO DE PROJETOS ÁGIL SCRUM Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia Termomecanica como exigência para obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas Orientador: Denis Novais Prates. SÃO BERNARDO DO CAMPO 2009

3

4 APRESENTAÇÃO DOS AUTORES Gustavo Souza Lopes Analista de Suporte na OiC (Optical Imaging Comercial), empresa brasileira que fornece sistemas para grandes montadoras de automóveis como Ford, Volkswagen, Fiat, Toyota, entre outras, sendo a principal fornecedora de catálogos de peças online e off-line alem de sistemas sob encomenda. Experiência profissional com analise de processos e sistemas gerencia em TI com foco nas boas práticas do ITIL, suporte de primeiro e segundo nível a sistemas em geral com analise de plataforma e infra-estrutura. Técnico em mecatrônica formado pela Escola Técnica Estadual Lauro Gomes no ano de Marcelo Luiz Esperati Pagoti Gerente de Projetos na HP (Hewlett Packard) empresa multinacional líder e reconhecida nos setores de computação pessoal, impressão, tratamento de imagem, softwares e prestação de serviços ligados a TI. Experiência profissional ligada gerenciamento de projetos de infra-estrutura de TI, bem como automação de processos em um escritório de projetos PMO. Experiências passadas com outsourcing de Recursos Humanos, trabalhando com as mais diversas áreas de RH, desde o gerenciamento sistemas de folha de pagamento, até recrutamento e seleção. Técnico em informática formado pela Escola Técnica Estadual Professor Camargo Aranha no ano de Rafael Ortega Campana Analista Desenvolvedor de Sistemas na Acessa Brasil Informática. Atua no ramo de desenvolvimento de soluções para empresas como Dunas (Rally dos Sertões/ SuperCross), Anefac (Associação Nacional dos profissionais de contabilidade). Experiência com desenvolvimento de software web e qualidade de software com utilização de metodologias ágeis (Scrum e XP). Técnico de informática da Escola Técnica Estadual Jorge Street.

5 AGRADECIMENTOS Gostaríamos de agradecer todas as pessoas que dedicam seu tempo e esforço em prol da Fundação Salvador Arena e em especial da Faculdade de Tecnologia Termomecanica. A essas pessoas agradecemos por continuarem respeitando o ideal do fundador Engenheiro Salvador Arena, dando a muitas famílias a oportunidade de estudo e educação. Agradecemos aos três coordenadores Adão Alves Rodrigues, Elisamara Oliveira e Luciano Gaspar, pela dedicação e empenho em coordenar o Curso de Tecnologia em Análise de Desenvolvimento de Sistemas, assim como todos os professores que passaram suas noites e manhãs de sábado compartilhando o que se pode ter de mais valioso na vida, seus conhecimentos e experiências. Aos nossos colegas de sala, Samuel de Almeida Martinucci, João Guilherme Almeida César, Kleber Silva, Renato Bento, Devair Negrão e Bruno Botelho, temos uma enorme gratidão, pois essa obra é um trabalho direto e indireto de todos eles.

6 DEDICATÓRIA Este trabalho a dedicado aos nossos familiares, especialmente as nossas namoradas que tiveram paciência e compreensão durante a elaboração de nosso trabalho.

7 SUMÁRIO 1. INTRODUÇÃO Escopo do Trabalho Engenharia de Software Histórico da Engenharia de software Conceito Básico Definição Resumo Modelos Prescritivos de Processo Cascata (Waterfall) Prototipação Métodos ágeis Origem dos Métodos Ágeis O que é Agilidade? Políticas e práticas do desenvolvimento ágil Características comuns dos Métodos Ágeis Desenvolvimento Iterativo Desenvolvimento Incremental Principais Métodos Ágeis DSDM Crystal... 49

8 ASD FDD Extreme Programming - XP Metodologia de Gerenciamento Ágil - Scrum Características principais Elementos de apoio Papéis e Responsabilidades Fases do Scrum Combinação de scrum com outras técnicas Scrum e XP - Extreme Programming Desenvolvimento orientado a testes (TDD) Programação em par Design Incremental Integração Contínua Comparação do Scrum com o desenvolvimento Lean Objetivos Comparação Scrum com modelo Waterfall (Cascata) Métodos ágeis combinados com o PMBOK O que é um Projeto? Gerenciamento de Projeto Grupos de Processos... 73

9 Áreas de Conhecimento Pesquisas Métodos Ágeis X PMBOK Estudo de caso Globo.com Considerações finais ANEXO 1 - ESTUDO DE CASO Scrum em nosso Trabalho de Conclusão de Curso Conclusões sobre o Estudo De Caso

10 LISTA DE FIGURAS Figura 1 - Diagrama Engenharia de Software (Fonte: Jalote, 1991) Figura 2 - Modelo Cascata (Baseado de Pressman, 2004) Figura 3 - Product backlog (Fonte: AVELLAREDUARTE.COM.BR, 2009) Figura 4 ScrumBoard - KNIBERG, Henrik. Scrum e XP Direto das Trincheiras. InfoQ, Figura 5 - Ciclo de Deming (Fonte: Portal da administração, 2009) Figura 6 - Ciclo do Sprint (Fonte: Corporate Sprint, 2009) Figura 7 - Fases do Scrum (Adaptado de Improve IT, 2008) Figura 8 - Retrospectiva Scrum (Fonte: 62 Figura 9 - Desenvolvimento Ágil com Modelo Cascata (DUNCANPIRCE.ORG, 2009) Figura 10 - Formato do Processo (Adaptado de PMBOK, 2004) Figura 11- Desenvolvimento iterativo e grupos de processos PMBOK. (Adaptado de Koch, 2004) Figura 12 - Product Backlog Figura 13 - Sprint 1 - Fundamentação Teórica Figura 14 - Sprint 2 - Primeiro bloco de escrita Figura 15 - Sprint 3 - Primeira versão Escrita Figura 16 - Sprint 4 - Segundo bloco de Escrita Figura 17 - Sprint 5 - Terceiro bloco de escrita Figura 18 - Sprint 6 - Primeira versão oficial

11 Figura 19 - Sprint Final - Apresentação

12 LISTA DE QUADROS Quadro 1 - Manifesto ágil (Fonte: AGILEMANIFESTO.ORG, 2009) Quadro 2 - Fases Semelhantes entre Scrum e XP Quadro 3 - Mapeamento entre os processos de gerenciamento de projetos e os grupos de processos de gerenciamento de projetos e as áreas de conhecimento (PMBOK, 2004) Quadro 4 - Comparativo: PMBOK X Ágil (INNOVIT.com, 2009) Quadro 6 - Calendário atividades TCC (Cefsa.org, 2009)... Error! Bookmark not defined.

13 DICIONÁRIO DE TERMOS Ad Hoc Expressão latina que quer dizer como e quando necessário, para o caso em vista. Normalmente usado como razão ou justificativa para não fazer algo ou para apoiar uma opinião, Em redes computacionais consiste em uma conexão direta, computador computador, sem a intermediação de elementos computacionais. Agile Nome próprio que refere-se a Ágil Backlog Listas de itens que devem ser priorizados no desenvolvimento de um software Big Brother Brasil Reality Show Programa para o qual a aplicação do estudo de caso foi desenvolvida. Bugs Em TI, erros de aplicação (tradução Insetos) Chickens No contesto do Scrum, são os envolvidos em um projeto, que não fazem parte da equipe de desenvolvimento. Command-control Método de gerenciamento que utiliza ferramentas de workflow para gerencia de atividades. Communities Comunidades. Crystal Metodologia Ágil de desenvolvimento de softwares. Daily Scrum Reunião diária para alinhamentos de atividades Design Desenho, projeto gráfico, ou interface de um produto qualquer. Designer Profissional responsável pelo design (desenho gráfico) do produto. Development Desenvolvimento. Extreme Programming - Programação Extrema. Feedback Retorno ou resposta com análise crítica. Framework Conjunto de bibliotecas ou conceitos que visão resolver problemas rotineiros. Gold Plating No conceito de gerenciamento de projetos, Gold Plating refere-se a realizações de um projeto que não estavam inseridas em seu escopo. Guide - Guia

14 Lean Magro. Level Nível. Lean Manufacturing Conceito da Toyota para manufatura de seus produtos. Meeting - Reunião Maintenance Manutenção. Off-line Desconectado da rede. Online Conectado a uma rede. Outsourcing - Terceirização. Pair Programming Programação em pares Pigs No conceito Scrum, pigs são os envolvidos no projeto, que fazem parte da Equipe de desenvolvimento. Post-its Cartões geralmente usados na criação da estórias. Practices - Práticas Product backlog Backlog do Produto Product Owner Dono do produto Reflection Workshops Reunião típica de Scrum, com a retrospectiva do que foi feito. Releases Pequenas entregas, pedaços de um escopo reduzido. Rugby Esporte semelhante ao futebol americano, do rugby que surgiu o termo Scrum. Scrum Metodologia de Gerenciamento Ágil de Projetos. ScrumMaster Mestre Scrum (similar ao gerente de projetos) ScrumBoard Quadro Scrum Sponsor Quem financia um projeto. Sprint Equivalente a uma Iteração Stakeholders Envolvidos em um projeto. Survey Pesquisa.

15 Tester Profissional dedicado a realização de testes. Waterfall Método de engenharia de software - Cascata Web Rede de computadores, nome que remete a internet. Whiteboard Quadro Branco.

16 DICIONÁRIO DE ABREVIAÇÕES Anefac Associação Nacional dos profissionais de contabilidade ASD Adaptative Software Development - (Desenvolvimento Adaptável de Software) BDUF - Big Design Up Front CSM Certified ScrumMaster DBA Data Base Administrator DSDM Dynamic Systems Development Method - Método Dinâmico de Desenvolvimento de Sistemas EAP Estrutura Analítica do Projeto FDD Feature Driven Development (Desenvolvimento Orientado Funcionalidades) HP Hewlett Packard ITIL Information Technology Infrastructure Library LSD Lean Software Development OiC Optical Imaging Comercial PMBOK Project Management Body of Knowledge PMI Project Management Institute PMO Project Management Office PMP Project Management Professional PO Product Owner RAD Rapid Application Development RH Recursos Humanos TCC Trabalho de Conclusão de Curso. TDD Test Driven Development TI Tecnologia da Informação

17 UML Unified Modeling Language WBS Work Breakdown Structure XP Extreme Programming (Programação Extrema)

18 RESUMO Esta monografia consiste em discorrer sobre a metodologia ágil de gerenciamento de projeto Scrum, assim como apresentar a Metodologia Ágil como um todo, suas praticas provindas da Engenharia de Software e métodos tradicionais. O trabalho tem como principal objetivo apresentar o Scrum e suas práticas de gerenciamento direcionadas ao cliente, entregas rápidas e constantes, foco nas principais necessidades do projeto buscando um maior aproveitamento da equipe e reduzir a distancia com os stakeholders. Este trabalho busca aplicar as técnicas de Engenharia de Software desenvolvidas pela Metodologia Ágil para o gerenciamento do próprio trabalho acadêmico. Dessa forma, a equipe poderá analisar a produtividade alcançada e a diminuição dos problemas previamente detectados nos trabalhos executados durante o curso.

19 ABSTRACT This monograph consists in expatiate about the Scrum methodology, a Project Management Agile Methodology, presenting an Agile overview, in the practices inherited from the Software Engineering s traditional methods. The monograph s main goal is to introduce the Scrum methodology and its management practices based on the iteration with clients, quick and constant releases focus on project needs looking for better results and cutting as much as possible the distance with the stakeholders. In this work, we are looking for use the Software Engineering methods developed by Agile for manage the whole monograph. In This way, the groups can analyses the productivity achieved in order to cease problems detected previously in other academic works during the college course.

20

21 21 1. INTRODUÇÃO A maioria dos centros urbanos passou a ser muito dependentes dos computadores e seus sistemas. Os novos produtos são muito maiores e a crescente expansão desses sistemas, em todos os setores da sociedade exigem que o desenvolvimento de sistemas seja cada vez mais complexo. Com esta crescente necessidade, principalmente na década de 90, quando começou uma verdadeira revolução tecnológica principalmente quando se fala sobre softwares, surgiram novas tendências, que se concentram em fatores humanos e que tentam ter uma visão mais abrangente do negócio, com um foco maior em qualidade e satisfação do cliente sem a burocracia existente até então. Esses processos menos burocráticos, no início foram chamados de leves até que alguns dos mais renomados engenheiros de software, que estavam insatisfeitos com os resultados obtidos se reuniram e criaram valores para esse tipo de metodologia, que ficou conhecido como manifesto ágil (AgileManifesto.org, 2009).As metodologias que derivam deste manifesto e seguem os valores são chamas de Métodos Ágeis. A evolução e o aumento do uso das tecnologias, criam a necessidade de que os sistemas sejam mais confiáveis e tornam certa dependência destes tipos de sistemas. Quem vivencia o ambiente de desenvolvimento presencia, que cada vez mais a necessidade por softwares cresce e com isto, o prazo diminui.para se conseguir atingir tal objetivo o processo de desenvolvimento tem de se tornar cada vez mais eficaz, com processos definidos para cada necessidade, seja o com requisitos definidos ou não. As metodologias ágeis não atendem a todas as necessidades e nem solucionam todos os problemas encontrados em um ambiente de desenvolvimento, porém, reúne diversas técnicas e práticas para tornar o

22 22 desenvolvimento de projetos muito mais eficaz, sendo que a maioria delas é direcionada e aplicada a desenvolvimento de software e tem como base a Engenharia de Software tradicional, mas com foco em entregas rápidas e maior liberdade na parte organizacional do projeto. O Scrum difere da maioria dos métodos, pois atua principalmente na área gerencial do projeto, e oferece um modelo auto-organizacional por parte da equipe além de permitir a utilização em conjunto com outras práticas mais focadas em desenvolvimento Escopo do Trabalho O objetivo principal do projeto é pesquisar a viabilidade do uso da Metodologia Ágil de Gerenciamento de Projetos Scrum, demonstrar alguns dos seus processos, papeis documentos e boas práticas, utilizando como conclusão pratica um estudo de caso de um sistema desenvolvido pela Globo.com. Para apresentarmos o Scrum e a historia, idéias e tendências das Metodologias Ágeis, precisamos entender a sua criação, para isso temos um breve histórico da Engenharia de Software e seus métodos mais tradicionais. O principal roteiro do trabalho é fazer uma passagem sobre os métodos antecessores dos Métodos Ágeis, que são algumas práticas da Engenharia de Software. Logo em seguida, apresentar as principais idéias da Metodologia Ágil, mostrando um pouco de seu histórico e práticas, podendo assim iniciar a apresentação sobre o Scrum e sua combinação com partes de outras metodologias, voltadas ao desenvolvimento de sistemas. Finalizando, apresentaremos o estudo de caso do sistema da Globo.com para concluir o trabalho e em anexo segue um estudo de caso de nossa experiência com o Scrum, utilizando-o para o gerenciamento do próprio trabalho de conclusão de curso.

23 23 Para iniciar nossa monografia pesquisamos a história da Engenharia de Software, já que são os seus princípios que levaram a criação dos Métodos Ágeis.

24 24 2. ENGENHARIA DE SOFTWARE 2.1. Histórico da Engenharia de software Na iniciação da evolução dos sistemas computadorizados durante os anos 40, a maior parte dos esforços e custos, era concentrada no desenvolvimento e melhoria do hardware ocasionado pelas limitações e dificuldades encontradas na época. Conforme a tecnologia de hardware foi sendo melhorada, as preocupações se voltaram, no começo dos anos 50, para o desenvolvimento dos sistemas operacionais, onde surgiram então as primeiras realizações destes sistemas, assim como as primeiras linguagens de programação de alto nível, como COBOL e Fortran, e seus respectivos compiladores. A tendência da época foi de poupar gradativamente o usuário de computador de conhecer profundamente as questões relacionadas ao funcionamento interno da máquina, permitindo que este pudesse concentrar suas idéias na resolução dos problemas computacionais ao invés de preocupar-se com os problemas relacionados ao funcionamento do hardware. Com esta evolução, nos anos 60 surgiram os sistemas operacionais com características de multiprogramação, sendo que a utilidade e eficiência dos mesmos obtiveram um crescimento considerável e contribuíram para a diminuição nos preços de hardware. Com o crescimento da necessidade de sistemas maiores e mais complexos, e a falta de experiência em se lidar com projetos computacionais, na década de 60 ocorreu a crise do software, com isto, estudos para melhorar a eficácia no desenvolvimento, foi criado o termo Engenharia de Software Segundo Fairley, o desenvolvimento de software vem na contramão do hardware quando o preço é levado em consideração, isto ocorre porque o desenvolvimento ainda demanda muito trabalho e raciocínio, porém pouca coisa pode ser utilizada para se automatizar o desenvolvimento, diferentemente do

25 25 hardware, onde a produção pode ser feita através de maquinas. (Fairley, 1985) Conceito Básico A engenharia de software é na verdade o desenvolvimento de sistemas computacionais com certas regras, métricas, procedimentos e documentação. A Engenharia de Software visa melhorar todo processo com o intuito de se atingir o objetivo em um menor tempo, acarretando um menor custo do projeto Definição Para descrever a desenvolvimento ágil, temos que conhecer os conceitos chave e as práticas mais comuns da Engenharia de Software. Apesar de ser distinta a Engenharia de Software Ágil foi idealizado á partir dos métodos mais convencionais da Engenharia de Software padrão, porém as diferenças são notórias e claras, segundo Roger Pressman a Engenharia de Software Ágil é um conjunto de filosofias e diretrizes de desenvolvimento, sendo que a filosofia encoraja a satisfação do cliente e a entrega incremental do software logo de inicio, com equipes de projeto pequenas, altamente motivadas, usando métodos informais e simplistas da Engenharia de Software. As diretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e ao projeto e a comunicação ativa e contínua entre desenvolvedores e clientes Resumo A prática de Engenharia de Software engloba conceitos, princípios, métodos e ferramentas que engenheiros de software aplicam durante o processo de software. Cada projeto de Engenharia de Software é diferente, no entanto, um conjunto de princípios e tarefas genéricas aplica-se a cada atividade de arcabouço de processo (atividades guarda-chuva) independentemente do projeto ou do

26 26 produto. Um conjunto de princípios técnicos básicos e de gestão é necessário se a boa prática de Engenharia de Software tiver que ser conduzida. Esses princípios técnicos básicos incluem a necessidade de entender áreas de incerteza de requisitos e de protótipos, além da necessidade de definir explicitamente a Arquitetura do Software e planejar a integração dos componentes. Os princípios básicos de gestão incluem a necessidade de definir prioridades em um cronograma realístico que as reflita, a necessidade de gerir riscos ativamente, e a necessidade de definir medidas de controle de projeto adequadas quanto à qualidade e suas modificações. Os princípios de comunicação com o cliente focalizam a necessidade de reduzir o ruído e aumentar a afinidade de idéias e pensamentos funcionais entre equipe desenvolvedora e cliente. Todos os princípios de planejamento enfocam em diretrizes para construir o melhor caminho para a obtenção de um sistema ou produto completo. O plano pode ser projetado somente para um único incremento de software, ou pode ser definido para o projeto todo. Independentemente disso, o planejamento deve incluir o que será feito, quem irá fazê-lo e quando o trabalho será completado. A modelagem engloba tanto a análise quanto ao projeto, descrevendo representações de software que se tornam progressivamente mais detalhadas. A intenção dos modelos é consolidar o entendimento do trabalho a ser feito e fornecer diretrizes técnicas para aqueles que implementarão o software. A construção incorpora um ciclo de codificação e testes no qual o códigofonte de um componente é gerado e testado para descobrir erros. A integração combina componentes individuais e envolve uma série de testes que enfocam

27 27 umas funções globais e tópicos locais de interface. Princípios de codificação definem ações genéricas que devem ocorrer antes que o código seja escrito, enquanto ele estiver sendo criado e depois que estiver sido completado. Embora existam muitos princípios de testes, somente um é dominante Teste é o processo de execução de um programa com o objetivo de encontrar um erro. Durante o desenvolvimento de software evolutivo, a implantação ocorre a cada incremento de software que é apresentado ao cliente. Princípios-chave para a entrega consideram a gestão das expectativas do cliente e lhe fornecem as informações de suporte apropriadas para o software. O suporte exige preparação antecipada. O feedback permite ao cliente sugerir modificações que tenham valor de negócio e forneçam ao desenvolvedor entrada para o ciclo iterativo seguinte da Engenharia de Software. (Pressman, 1995) Figura 1 - Diagrama Engenharia de Software (Fonte: Jalote, 1991) Para iniciar o trabalho de pesquisa, iremos citar os Modelos Prescritivos de Processo, também conhecidos como métodos tradicionais da Engenharia de Software, esses modelos com o passar dos anos foram sendo utilizados e melhorados de acordo com a necessidade que cada equipe de desenvolvimento tinha, no capitulo 2.5 veremos mais detalhes.

28 Modelos Prescritivos de Processo. Os modelos prescritivos de processo foram originalmente propostos para colocar ordem no caos do desenvolvimento de software. A história tem indicado que esses modelos convencionais têm colaborado para que a estrutura útil para o trabalho de Engenharia de Software, trazendo um roteiro muitas vezes efetivo para as equipes de desenvolvimento de software. No entanto, o trabalho de Engenharia de Software e o produto que ele produz permanecem no limite do caos (Pressman, 2004). Segundo Pressman, modelos prescritivos são conhecidos também como modelos de processos convencionais, definindo um conjunto de atividades ações e tarefas, marcos e produtos de trabalho para garantir a alta qualidade necessária para executar os processos de Engenharia de Software. Em nosso trabalho, achamos por melhor explicar apenas dois Modelos Prescritivos de Processo, o Cascata, que iremos posteriormente combinar com os processos do Scrum, e como mostrado em nosso Estudo de Caso, Danilo Bardusco da Globo.com utilizava o modelo Cascata antes de aderir ao Scrum, com essa pequena explicação do modelo Cascata podemos evidenciar as diferenças mais gritantes entre os métodos ágeis e o Modelo Cascata. A outra escolha foi o Modelo de Prototipação, que tem por semelhança a entrega reduzida de um escopo maior previamente requerido, através de protótipos, com esse exemplo podemos posteriormente apresentar as principais diferenças entre um protótipo e um incremento. Porém existem outros Modelos Prescritivos de Processo como RAD (Rapid Application Development), o Modelo Espiral, entre outros Cascata (Waterfall)

29 29 O Modelo Cascata é o mais tradicional dos Modelos Prescritivos de Processo, tanto é que também é chamado de Modelo clássico. Ele foi concebido de proposto por Royce Winston em 1970 e até meados da década de 1980 ainda era o único modelo com aceitação. Comparado com outros modelos de desenvolvimento de software o Modelo Cascata é o mais rígido, porém o menos administrativo (Royce, 1970). O Modelo Cascata sugere uma abordagem sistemática e seqüencial para desenvolvimento de softwares. Esse fluxo linear começa com o cliente que especifica e requisita suas idéias de concepção de um sistema. Assim que essa fase progride esse fluxo passa por fases de planejamento, modelagem, construção e implantação, assim chegando a fase de manutenção progressiva do software acabado (Pressman, 2004). Figura 2 - Modelo Cascata (Baseado de Pressman, 2004) Por ser o modelo mais antigo da Engenharia de Software o Modelo Cascata tem sido alvo de inúmeras criticas e quanto a sua eficácia. Entre os problemas

30 30 relacionados à adoção do Modelo Cascata como Processos únicos de modelagem e desenvolvimento de software podem encontrar: 1 Projetos de software raramente seguem o fluxo seqüencial que o modelo Cascata prega. Apesar de o modelo linear acomodar a iteração, ele o faz indiretamente. Como resultado as modificações podem gerar confusão à medida que o projeto prossegue. 2 Em geral, é difícil estabelecer todos os requisitos de um projeto no primeiro momento. O Modelo Cascata exige essa definição previa, dificultando o andamento do projeto, logo em seu inicio e inibindo possíveis alterações durante o projeto. 3 O cliente precisa ter paciência. Uma versão executável do programa não vai ficar disponível até o período final do intervalo de tempo que o projeto dura. Um erro grosseiro pode ser desastroso se não for detectado até que o programa executável seja revisto. Atualmente o trabalho de se desenvolver um software requer que os profissionais envolvidos trabalhem em um ritmo acelerado. O Modelo em Cascata é inadequado para esse tipo de trabalho. No entanto, pode servir como modelo de processo útil em situações nas quais os requisitos são fixos e o trabalho e o trabalho deve prosseguir até o fim de modo linear (Pressman, 2004) Prototipação Durante o projeto, em um modelo tradicional de desenvolvimento de software, muitas vezes, o cliente fica muito tempo sem ter um contato com o software, para minimizar o impacto desta distância, uma alternativa é a Prototipação do projeto (Sharp, 2002).

31 31 Protótipo é a primeira versão do projeto, que o cliente tem contato, onde grande parte lógica do sistema ainda não está desenvolvida, normalmente o protótipo é utilizado para o cliente ficar ciente do layout/ design e a interface com o usuário, levantando alguns quesitos de validações, mas, sem as regras de negócio O objetivo principal da Prototipação é demonstrar aos stakeholders, com o intuito de validar o sistema e verificar os requisitos, quando estes são muito vagos ou insuficientes. Um protótipo pode ser usado como meio de comunicação entre os diversos membros da equipe de desenvolvimento ou mesmo como meio de nós mesmos testarmos a nossas idéias (Sommerville, 1985). Um dos principais problemas encontrado na Prototipação são as falsas expectativas geradas por parte de quem experimenta o protótipo, por isto os objetivos dos protótipos devem estar claros a todos que usarão o sistema. Sem os objetivos bem definidos há uma grande chance de essa experiência acabar por fracassar e não agregar nenhum ou pouco valor ao projeto (Pressman, 2004). Abaixo vamos citar alguns tipos de protótipos mais utilizados: 1 - Protótipo de baixa fidelidade São aqueles tem poucas características do produto final, são marcados por um baixo custo, tem um curto tempo de criação, mas teoricamente contemplam requisitos de interface e definem alguns quesitos e opção do design. 2 - Protótipos de Alta fidelidade

32 32 Os protótipos de alta fidelidade são aqueles que mais se assemelham com o produto final (Sharp, 2002). São utilizados normalmente com a finalidade de venda ou testes da versão final, e sempre contemplam as tecnologias e materiais das versões finais, porém, não é a versão final e os envolvidos devem estar cientes, para não gerar aquela falsa expectativa citada na introdução. Possuem um custo maior, porém grande parte dos recursos empregados no desenvolvimento é utilizada no projeto final, assim, esses recursos e tempo acabam por ser reutilizados. (Sharp, 2002). Após termos abordado os tópicos necessários da engenharia de software para a continuidade de nossa linha de raciocínio, vamos apresentar um conjunto de métodos provindos da engenharia de software, os métodos ágeis.

33 33 3. MÉTODOS ÁGEIS 3.1. Origem dos Métodos Ágeis No inicio de 2001, um grupo de profissionais, em sua grande maioria veterana no desenvolvimento de projetos de software, assinaram um Manifesto para o desenvolvimento Ágil de Software. Kent Beck e outros 16 notáveis desenvolvedores declaram nas seguintes palavras seu manifesto: Manifesto para Desenvolvimento Ágil de Software Estamos descobrindo melhores maneiras de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Com este trabalho, começamos a valorizar: Indivíduos e suas interações em vez de processos e ferramentas. Produto em funcionamento acima de documentação abrangente. Colaboração com o cliente acima de negociação de contratos. Responder a mudanças acima de seguir um plano. Portanto, enquanto os valores da direita existirem, nós valorizamos ainda mais os da esquerda. Assinado por Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas. Quadro 1 - Manifesto ágil (Fonte: AGILEMANIFESTO.ORG, 2009) Os próprios assinantes do Manifesto para o desenvolvimento Ágil de

34 34 Software intitulam seu movimento como um ataque a velha guarda e seus princípios retrógrados de gestão e Engenharia de Software, sugerindo a eles (os retrógrados) suas mudanças revolucionárias. Segundo Kent Beck, doze princípios para o desenvolvimento ágil de software foram criados com base no manifesto, os quais ele descreveu em seqüência. Inspirados pelos valores idealizados sobre o que deveria ser o Agile, doze princípios fundamentais foram criados para dar identidade ao processo ágil de desenvolvimento. Nossa maior prioridade é satisfazer os clientes através de entregas de software funcional, rápidas e continuas (Beck, 1999). Um processo ágil é aquele que entrega o mais cedo possível um produto funcional para o cliente testar e enxergar o que foi requisitado, um sistema rudimentar logo nas primeiras semanas do inicio do projeto e assim, a cada período de tempo, este sistema é atualizado e mostrado ao cliente com novas funcionalidades até o mesmo estar definitivamente atendendo ao negócio. Aceitar requisitos mutáveis, mesmo em fases avançadas do desenvolvimento. Processos ágeis trazem mudanças como beneficio competitivo para o cliente. (Beck, 1999). Os participantes no processo ágil não podem ter medo de mudanças. As mudanças nos requisitos significam que o time está aprendendo mais sobre o que satisfaz o mercado, trabalhando duro para que a estrutura do software se

35 35 mantenha flexível, assim, quando uma mudança é feita, o impacto no sistema é mínimo. Entregar freqüentemente software funcionando, a partir de duas semanas a dois meses, dando preferência a uma escala de tempo reduzida. (Beck, 1999). Este princípio refere-se a entregar software ao invés de documentação ou planos ao cliente, no intuito de mostrar o serviço feito o mais rápido possível e satisfazer as necessidades do cliente. Agentes do negócio e desenvolvedores devem trabalhar em conjunto diariamente no decorrer do projeto. (Beck, 1999). Para que o Agile possa funcionar, uma interação freqüente e significante entre clientes, desenvolvedores e stakeholders, é primordial, sempre discutindo as diretivas e guiando um projeto como um todo. Construir projetos ao redor de indivíduos motivados. Dê a eles um ambiente adequado e o suporte necessário, e confie neles para que o trabalho seja feito. (Beck, 1999). As pessoas são consideradas o fator mais importante para o sucesso de um projeto ágil. Fatores como processos, ambiente, gerencia, ferramentas, são considerados em segundo plano e estão sujeitos a mudanças caso um efeito adverso no time seja observado. O mais eficiente e efetivo método de unificar informação para a equipe de desenvolvimento é conversação

36 36 cara-a-cara. (Beck, 1999). Conversação é outro fator chave para um projeto ágil. Qualquer documentação, especificação de escopo, designs ou planos podem ser substituídos facilmente por uma conversa com o cliente. Tais documentações são necessárias porem não imediatamente ou sempre, somente caso seja necessário, portanto, a conversação é o padrão para coleta de requisitos e qualquer fator que precise que o cliente especifique. Software funcionando é a medida de progresso primária. (Beck, 1999). No processo ágil, o progresso do projeto é medido pelo numero de funcionalidades funcionando no software. Não existe uma medida por volume de documentação ou em que fase o projeto está. O quanto do software está funcionando mensura do andamento do projeto. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante (Beck, 1999). O ritmo de um projeto ágil é determinado pelos próprios times. Todos devem estar em um ritmo constante para que o projeto não afete as pessoas envolvidas. Evitar o cansaço, stress e trabalhar sempre visando o bem estar dos integrantes. Atenção continua com excelência técnica e bom design eleva a agilidade. (Beck, 1999)

37 37 Um software limpo e robusto auxilia tanto na qualidade quanto na velocidade do projeto com códigos com fácil manutenabilidade e de fácil adaptação às mudanças. No entanto, o time deve estar comprometido a produzir sempre um código com o máximo de qualidade, atendendo este principio. Simplicidade a arte de maximizar a quantidade de trabalho não feito é essencial. (Beck, 1999) Times ágeis estão sempre prontos para corrigir todos os erros encontrados hoje, não deixar os problemas para serem resolvidos no outro dia, além de seguir sempre o caminho mais simples e consistente possível para atingir os objetivos do projeto. As melhores arquiteturas, requerimentos e designs vêm de times auto-organizáveis. (Beck, 1999) Os times ágeis são auto-organizáveis e as responsabilidades são comunicadas sempre ao time como um todo e são decididas e executadas por todos. Os membros trabalham juntos em todos os aspectos do projeto, não existem responsabilidades totalmente individuais. Em intervalos regulares, o time reflete em como se tornar mais eficiente, para então ajustar o seu comportamento de acordo com a reflexão. Como ponto chave é a mudança, o time também deve estar sempre disposto a se ajustar para promover a melhoria continua e aumentar as relações internas. (Beck, 1999) Embora as idéias acima que guiam o desenvolvimento ágil tenham estado inseridas no âmbito da Engenharia de Software foi só durante a década de 1990

38 38 que essas idéias foram cristalizadas em um movimento. Em essência, os Métodos Ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e reais da Engenharia de Software convencional. O desenvolvimento ágil pode fornecer importantes benefícios, mas ele não é aplicável a todos os projetos, aos produtos, as pessoas e as situações. Ele também não é contrario à sólida prática de Engenharia de Software e pode ser aplicado como uma filosofia prevalecente a todo o trabalho do projeto de um software. Na economia moderna, é freqüentemente difícil ou impossível prever como um sistema baseado em computador (por exemplo, uma aplicação com base Web) evoluirá com o passar do tempo. Condições de mercado mudam rapidamente, necessidades dos usuários finais evoluem e novas ameaças de competição emergem sem alerta algum. Em muitas situações, não podemos mais definir completamente os requisitos antes do inicio do projeto. Os engenheiros de software devem ser ágeis o suficiente para responder a um ambiente de negócios mutante. Isso significa que uns reconhecimentos dessas causas realísticas modernas nos abrigam a descartar princípios, conceitos, métodos e ferramentas valiosos de Engenharia de Software? Certamente não! Como todas as disciplinas de engenharia, a Engenharia de Software continua a evoluir. Ela pode ser adaptada facilmente para encarar os desafios colocados pela demanda por agilidade. Em um livro sobre o desenvolvimento ágil de softwares, Alistair Cockburn (2001) argumenta que os modelos prescritivos de processo de software dos métodos convencionais da Engenharia de Software têm uma deficiência importante: Eles esquecem as fragilidades das pessoas e constroem software de computador. Engenheiros não são robôs. Eles exibem grande variedade de estilos de trabalho e diferenças significativas em nível de habilidade, criatividade, regularidade, consistência e espontaneidade. Alguns se comunicam bem de forma escrita, outros não. Alistair Cockburn argumenta que os modelos de processo

39 39 podem tratar fraquezas comuns das pessoas com disciplina ou tolerância. E que a maioria dos modelos prescritivos de processo escolhe a disciplina, ele afirma: Como a consistência em ação é uma fraqueza humana, metodologias de alta disciplina são frágeis. (Cockburn, 2001) Se os modelos de processo têm de funcionar, eles precisam fornecer um mecanismo realístico para encorajar a disciplina necessária, ou precisam ser caracterizados de um modo que mostre tolerância com as pessoas que fazem o trabalho de engenharia de software. Invariavelmente, práticas tolerantes são mais fáceis de serem adotadas e sustentadas pelo pessoal de software, mas Alistair Cockburn admite que elas possam ser menos produtivas, como a maioria das coisas na vida a negociação sobre a utilização ou não de um desenvolvimento chamado de ágil deve ser discutida previamente. (Cockburn, 2001) 3.2. O que é Agilidade? O que seria exatamente a agilidade no contexto de Engenharia de Software? Jacobson fez uma explanação com as seguintes palavras: Agilidade tornou-se atualmente uma palavra mágica quando se descreve um processo moderno de software. Tudo é ágil. Uma Equipe ágil é uma equipe esperta, capaz de responder adequadamente as modificações. Modificação é aquilo para o qual o desenvolvimento de software está principalmente focado. Modificações no software que está sendo requisitadas e construídas, modificações dos membros integrantes de uma equipe, novas tecnologias, qualquer espécie de modificação causam impacto no projeto e por conseqüência no produto. O apoio as modificações deveria ser incorporado em tudo que fazemos em software, algo que se adota porque está no coração e na alma do

40 40 software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as especialidades dessas pessoas e sua capacidade de colaborar estão no âmago do sucesso do projeto (Jacobson, 2002). Nessa visão o acolhimento de modificações é o principal guia da agilidade. Os engenheiros de software devem reagir rapidamente se tiverem de acomodar as rápidas modificações que Jacobson escreve. O conceito de agilidade abre espaço para Modelos Empíricos de Processo, que são modelos evolutivos dos Prescritivos, os modelos Empíricos são mais adaptáveis a projetos onde o escopo ainda é imprevisível e os processos precisem ser mais circulares e dinâmicos. Mas agilidade é mais que uma efetiva resposta a modificações, ela também engloba a filosofia apresentada no manifesto e nos princípios ágeis visto no início do capitulo. Enfatizando a entrega rápida de um software funcional, a comunicação efetiva e dinâmica entre membros da equipe e clientes Políticas e práticas do desenvolvimento ágil. Dentre todos os processos ágeis de desenvolvimento existem práticas e políticas comuns regidas de acordo com o Manifesto Ágil e seus princípios. De acordo com Martin Fowler os processos de Engenharia de Software Ágil são caracterizados por atenderem a três suposições chaves: 1 É difícil prever antecipadamente quais os requisitos de software vão persistir e quais serão modificados. É igualmente difícil prever como as prioridades do cliente serão modificadas à medida que o projeto prossegue.

41 41 2 Para muitos tipos de software, o projeto e a construção são intercalados, isto é as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados à medida que são criados. É difícil prever o quanto de projeto é necessário antes que a construção seja usada para comprovar o projeto. 3 Análise, projeto, construção e testes não são totalmente previsíveis do ponto de vista de planejamento quanto se espera no inicio de um projeto, dúvidas, incertezas e falta de clareza fazem parte dessas fases (Fowler, 2002). De acordo com essas três suposições Pressman afirma que um processo ágil deve ser adaptável. Porém a adaptação contínua sem progresso agrega muito pouco ao projeto, assim um processo ágil deve comportar as suas adaptações de forma incremental, uma equipe ágil requer feedback rápido e constante pra que essas adaptações sejam realizadas para melhorar o projeto de acordo com as expectativas do cliente (Pressman, 2004). Uma maneira encontrada de se obter feedbacks constantes e prover as adaptações necessárias de um projeto é a entrega incremental de uma funcionalidade, requisição pedida pelo cliente, ao invés de se entregar um protótipo que atende a poucos requisitos, a entrega de um incremento atende todos os requisitos de maneira rápida e adaptável, pois ainda não se trata do produto final e plenamente avaliável pelo cliente, que passa a ter domínio do que está sendo entregue (Pressman, 2004). Dentre as políticas comuns dos métodos ágeis já temos a sua capacidade de adaptação a mudanças e a quebra do escopo em incrementos funcionais que ajudam na avaliação previa dos clientes. Um dos integrantes do Manifesto ágil, Alistair Cockburn enfatiza os fatores

42 42 pessoais para um desenvolvimento ágil bem-sucedido. Segundo Cockburn: O Desenvolvimento Ágil enfoca os talentos e habilidades dos indivíduos moldando o processo e as pessoas envolvidas (Cockburn, 2001). Segundo o mesmo, Cockburn relata que os membros de uma equipe devem todos carregar as seguintes características para participar de uma equipe ágil: Competência: Característica relacionada ao talento para a realização do trabalho. O profissional deve ter habilidades especificas, relacionadas aos conhecimentos das matérias incluídas dentro de um projeto. Foco comum: Embora as equipes ágeis realizem atividades diferentes simultaneamente, todos devem estar focados em uma única meta entregar um incremento de software em funcionamento ao cliente dentro do prazo prometido. Colaboração: Engenharia de software diz respeito a avaliar, analisar e usar informações que são comunicadas à equipe de software. Essas informações sempre agregam valor à equipe e transmitem um ambiente colaborativo, onde todos sabem seus reais objetivos. Tomada de decisão: Boas equipes, ágeis ou não devem ter liberdade suficiente para controlar seu próprio destino. Isso implica que seja dada autonomia para a equipe. Resolução de Problemas: Equipes ágeis sempre lidam com ambigüidades nas modificações, em alguns casos a resolução de um problema que aparenta ser pequeno, pode ser um erro grosseiro no futuro, a equipe tem que estar preparada para resolver e solucionar qualquer tipo de problema, armazenando as lições aprendidas, pois essas podem se tornar facilitadoras de futuras resoluções.

43 43 Respeito e confiança mútua: Uma equipe consolidada exibe confiança e respeito necessário para torná-la forte o suficiente, sendo capaz de solucionar os problemas do projeto com resoluções em equipe. Auto-organização: auto-organização implica em três coisas: 1- A equipe ágil organiza-se para o trabalho ser feito local 2- A equipe organiza o processo para melhor acomodar seu ambiente 3- A equipe organiza o cronograma de trabalho para conseguir entregar o incremento de software da melhor maneira possível. A auto-organização tem benefícios técnicos, porém ela serve para aperfeiçoar a colaboração e aumentar a motivação da equipe. Em essência a equipe atua como sua própria gerência. Ken Schwaber outro integrante do Manifesto ágil e criador do Scrum trata a auto-organização com as seguintes palavras: A equipe seleciona quanto trabalho acredita que pode realizar dentro da iteração e a equipe se compromete com o trabalho. Nada desmotiva tanto uma equipe quanto a aceitação da responsabilidade de cumprir os compromissos que ela própria estabeleceu (Schwaber, 2002).

44 Características comuns dos Métodos Ágeis Os métodos de desenvolvimento ágil, por seguir o manifesto, têm muitas características em comum, iremos citar as principais características, que são encontradas na maioria dos métodos, são conceitos, que podem receber diversos nomes, mais que tem a base muito próxima Iniciação do projeto A iniciação do projeto traz as informações iniciais do projeto, que pode ser definida por alguém com responsabilidades necessárias para isto, dependendo da metodologia Plano do projeto (arquitetura e requisitos são opcionais) Planejamento de tudo que ocorre após o plano do projeto, esta fase pode ser usada pra criar os requisitos, caso necessário e definir a forma que o projeto será conduzido Releases constantes e curtos É quando o cliente recebe parte do software funcionando ou com potencial para funcionar e que podem ser apresentadas para relatar a evolução do projeto e mostrar o objetivo alcançado. Normalmente os releases duram de uma à seis semanas, mas quase sempre três ou quatro semanas. O mais importante e objetivo é o modulo funcionando com um tempo de entrega fixa. (Balagan, 2009).

45 Desenvolvimento Iterativo Uma iteração é uma parte do projeto entregável, onde o cliente pode utilizar aquela funcionalidade. A ordem de desenvolvimento das funcionalidades e que serão implementadas na iteração é definida de acordo com a necessidade e prioridade do cliente. Outro conceito a ser explorado é o potencialmente entregável, este conceito tem com idéia de que o software necessita de outras funcionalidades para poder ser usada comercialmente ou para ter alguma utilidade, mas é importante fechar o pacote, a fim de mostrar o que está sendo desenvolvido, para o cliente ter a noção do que está sendo feito e fazer uma avaliação se está tudo no caminho correto. Normalmente são definidos ciclos de iteração com cerca de duas à seis semanas, onde são definidas funcionalidades que atendam algumas necessidades especificas que o cliente necessita. Outra característica das principais metodologias ágeis é a capacidade de adaptar o software às atuais necessidades do cliente, dificilmente um projeto tem um escopo com requisitos muito bem definidos, então esta adaptabilidade tem grande importância nas metodologias ágeis. (Larman, 2004) Desenvolvimento Incremental O conceito de desenvolvimento incremental vem do fato que o cliente não sabe qual suas reais necessidades e começa a conhecer o software e saber o que é necessário automatizar durante o processo de desenvolvimento, ou quando o sistema começa a utilizar o sistema. Durante o desenvolvimento, com a interação com o cliente, novas

46 46 funcionalidade podem ser adicionas retiradas ou modificadas, de acordo com as reais necessidades do usuário do sistema. Outro quesito que é importante ressaltar é a colaboração do cliente com a equipe de desenvolvimento é fator determinante para o sucesso no desenvolvimento de uma aplicação implementada com metodologia ágil, pois, o contato com o cliente traz o feedback necessário para sanar dúvidas, e levantar questões, tanto por parte do cliente, como da equipe de desenvolvimento Estimativas Uma das características das metodologias ágeis é que as estimativas são tratadas como deveriam ser, apenas estimativas. Estimativa é na verdade, focado no desenvolvimento, algo que se pode ter uma idéia de custos e prazos de acordo com experiências passadas. Porém, isto não pode ser estipulado como algo concreto, pois no mesmo nível hierárquico, há pessoas que produzem mais do que outras e esta produtividade influencia diretamente nas estimativas primárias. Nas estimativas ágeis, tudo é levado em consideração, até problemas que podem ocorrer durante o processo de desenvolvimento, por isso, em alguns momentos das reuniões, é gasto tempo para definir as estimativas, sendo discutido entre todos e estabelecendo um ponto em comum. Dentre as formas de se estimar o projeto, vamos citar os mais usuais que seria o Planning Poker, onde as cartas são definidas de acordo com alguma sequência exponencial, já que quanto maior a estimativa, mais sucessível a erros, por isto um maior espaçamento entre os números, Mike Cohn recomenda a utilização da seqüência de Fibonacci. (Cohn, 2006).

47 47 O Planning Poker consiste em um jogo de cartas, em que a estória, que iremos explanar no decorrer do projeto, é divida em tarefas, e estas tarefas, todos os membros do time, selecionam uma carta de acordo com uma base, que pode ser a tarefa mais simples do projeto, que é escolhida por comum acordo. Assim que todos escolheram, todos viram as cartas selecionadas e é discutido o porquê da escolha daquela estimativa. As cartas são escolhidas ao mesmo tempo, com o intuito de que desenvolvedores menos experientes sintam maior firmeza na escolha. Outro método de se estimar o projeto, mesmo que bem menos utilizado nos métodos ágeis, mas que pode ser utilizado é a estimativa por ponto de função. Este tipo de estimativa é pouco utilizado para métodos ágeis, pois necessita de um escopo com requisitos amadurecidos. (Boehm, 200). Estas estimativas são utilizadas para construir gráficos que auxiliam na visualização geral do projeto e de como anda o projeto, pode também corrigir falhas e trazem experiência para uma próxima estimativa. (Cohn, 2006). 3.5 Contratos com métodos ágeis Um dos maiores problemas do desenvolvimento de software e do projeto são prazo e custo, que estão diretamente ligados ao contrato do desenvolvimento. Nas metodologias tradicionais, normalmente é utilizado contrato com escopo fechado e com requisitos definidos, o problema é que isto não é muito indicado para projetos desenvolvidos com metodologias ágeis. Este tipo de contrato é indicado para o Modelo Cascata. Com um produto não muito definido fica muito difícil fazer o projeto com um preço fixo ou mesmo impossível em alguns casos. Como as metodologias ágeis

48 48 pregam que o desenvolvimento seja interativo, sempre há mudanças, que podem acarretar em mais tempo ou até mesmo, menos tempo. O cliente muitas vezes acha que acaba saindo ganhando, já que o produto deverá ser entregue no tempo determinado e com um custo que ele já sabe qual é, porém, o que deve ser avaliado é que a empresa que desenvolve o software acaba tendo que compensa alguns pontos e para evitar diminuição nos lucros ou até mesmo prejuízos, o que acaba pendendo é a qualidade, que fica muito abaixo comparado a outra em que fosse empregado mais recursos. Neste tipo de projeto, mesmo que seja atendido tudo no prazo correto,o que dificilmente ocorre, sempre existe uma sobra de recursos, o que é chamado de gordura no projeto. Segundo José Papo, o cenário ideal para os projetos com metodologia ágil é um contrato com escopo variável, que atende perfeitamente as necessidades desse tipo de desenvolvimento. Onde, dentro vários modos de utilizar este tipo de contrato o mais utilizado é aquele que em cada iteração ou entrega é realizado o pagamento ou algum outro tipo de ressarcimento. Outro tipo que se encaixa bem é com o conceito ágil é o de aquisição progressiva, que seria, na verdade, cada módulo do projeto ou iteração um projeto separado no conceito do contrato, porém com uma qualidade bem superior e cria uma relação de confiança entre fornecedor e cliente. (Papo, 2008) Principais Métodos Ágeis Segundo Scott Ambler, todas as técnicas do Agile possuem pontos semelhantes, pois todos os seus autores fizeram parte do Manifesto Ágil, possuindo então princípios em comum.

49 DSDM Dynamic Systems Development Method - (Método Dinâmico de Desenvolvimento de Sistemas) - Foco no estudo de viabilidade e estudo do negócio, metodologia proprietária do consórcio DSDM, do Reino Unido. Funciona com três ciclos em paralelo e entrelaçado: Ciclo do modelo funcional, onde é feita a análise e o desenvolvimento de protótipos, Ciclo de design e build, estudo da engenharia do produto e Ciclo de implementação. Funciona com iterações fixas de duas a seis semanas, releases freqüentes, requisitos adaptativos. Usa um framework para desenvolvimento rápido de aplicações (RAD). (Ambler, 2004) Crystal Um conjunto de metodologias, uma para cada tipo de projeto, de acordo com as necessidades e adequações a cada um. O método de desenvolvimento é determinado por quatro parâmetros: localização geográfica, criticidade, segurança e tamanho da equipe, geralmente de até seis desenvolvedores. Os artefatos, papéis e ciclo de desenvolvimento do projeto são parametrizados por recomendação e ao final de cada iteração, são feitos Reflection Workshops, reuniões para promover a melhoria continua. Utiliza-se da técnica Whiteboard (quadro branco) para listar as funcionalidades, dividas por executadas ou não. Se uma funcionalidade não for pequena o suficiente para caber no quadro do projeto, o projeto não pode ser considerado para ser ágil. (Ambler, 2004) ASD Adaptative Software Development - (Desenvolvimento Adaptável de Software) Modelagem criada por Jim Highsmith, recomendado para sistemas complexos, projetos de grande porte, para resultados imprevisíveis. Foco nas funcionalidades, as quais são divididas. Possui três ciclos básicos: Colaboração,

50 50 Especulação e Aprendizado. Sua abordagem é errar cedo, corrija cedo, não potencialize os mal-entendidos e qualidade dimensionada pelos recursos disponíveis. Também se utiliza do RAD (Rapid Application Development) (Highsmith, 2000) FDD Feature Driven Development (Desenvolvimento Orientado Funcionalidades) Possui cinco processos: 1 - Modelo geral (arquitetura do domínio do negócio); 2 - Lista de funcionalidades, levantando requisitos para todo o projeto; 3 - Planejamentos por Funcionalidades, definindo escopo a cada iteração, quais as funcionalidades a serem desenvolvidas, formando times para cada funcionalidade 4- Projeto por funcionalidades; 5- Construção por funcionalidades. Releases frequentes, papéis bem definidos Extreme Programming - XP Extreme Programming (Programação Extrema) Metodologia para desenvolvimento de software desenvolvido por Kent Beck, com base em um projeto executado na Chrysler utilizando dos primeiros princípios da mesma. Seus principais valores são a comunicação, simplicidade, feedback e coragem para assumir riscos e mudanças continuas. Possui doze praticas: Pair Programming (programação em pares), refatoramento, design simples, desenvolvimento orientado a testes, ritmo sustentável, integração continua, padronização de código,

51 51 testes com o cliente, time funcionando como um todo, jogo do planejamento, releases constantes, metáforas de projeto e propriedade coletiva (Kniberg, 2007) Metodologia de Gerenciamento Ágil - Scrum O termo Scrum se origina de uma jogada do Rugby (Esporte praticado entre dois times, originado do futebol), o intuito da jogada é colocar a bola em jogo. Nesta jogada o time trabalha em equipe, e se auto-organizam com um objetivo a ser cumprido. A metodologia Scrum é realmente isto, um framework de conceitos, práticas a serem utilizadas, onde o time se auto-organiza, com comprometimento total com a equipe a fim de se atingir um objetivo, que no caso, que pode ser um Sprint finalizado ou até tarefas que necessitam ser concluídas. Diferentemente dos modelos tradicionais, onde o processo de desenvolvimento definido é rígido, com obrigatoriedade de ser seguido em seu todo, o Scrum tem outro conceito, com foco na satisfação do cliente e flexibilidade. Onde as necessidades do negócio é que ditam como e em que momento as funcionalidades serão implementadas. Este conceito agrega maior valor de negócio com um menor tempo de produção, entregas em prazos menores, com um módulo do projeto. O foco principal do Scrum é o gerenciamento e não como as tarefas são realizadas, com o conceito de auto-organização é possível utilizar o Scrum em conjunto com outras metodologias com foco em desenvolvimento, como o XP (extreme Programming). Diversos relatos e pesquisas, como o 3f Annual Survey sobre metodologias ágeis mostram bons resultados na utilização híbrida dessas duas metodologias.

52 52 Scrum, que é fundamentado na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Três pilares sustentam qualquer implementação de controle de processos empíricos Características principais As equipes no Scrum são encorajadas a serem sempre dinâmicas. Criação de times encorajados pela co-alocação de todos os membros, trocando sempre os membros das equipes internas para obter uma comunicação máxima e relacionamentos entre membros, além de comunicação entre todos os times Elementos de apoio Os elementos de apoio servem de base para a implantação de uma metodologia ágil no desenvolvimento de uma aplicação, todos envolvidos com o produto acabam tendo contato com estes elementos de apoio. São gerados backlogs, tarefas, estórias e gráficos de acompanhamento do projeto para auxiliar no decorrer do projeto e ter uma real noção de como está o andamento. Backlog do Produto: Lista de todos os cartões de funcionalidades que o produto deve possuir e que ainda não foram implementadas (Bassi, 2008). Geralmente contém as funcionalidades requeridas pelo Product Owner (Dono do produto). Esse documento descreve o que deve ser construído no decorrer do projeto. É um documento aberto a modificações e atualizações durante o projeto, pode ser comparado a um documento de levantamento de requisitos ou definição de escopo das metodologias comuns. A sua principal diferença é que esse documento visa ajudar nas estimativas de tempo e principalmente na prioridade das funcionalidades a serem desenvolvidas. Exemplo:

53 53 Figura 3 - Product backlog (Fonte: AVELLAREDUARTE.COM.BR, 2009) Nessa planilha de exemplo tendo em conta um Projeto Web genérico, podemos verificar como um backlog de produto. Nesse caso a descrição de cada atividade está comentada coluna descrição, a prioridade é relacionada de A até E, sendo o A o valor mais alto, ou seja, de maior prioridade e no campo Pontos a

54 54 quantidade de esforço necessário para a finalização da atividade. Backlog Selecionado: É parte do product backlog que foi selecionado pelo cliente, para ser implementado no sprint que será iniciado. É definido normalmente por prioridade de uso pelo cliente, ou seja, é a parte que necessita ficar pronto mais rapidamente (um sprint é equivalente a uma iteração posteriormente iremos detalhar essa fase do projeto). Backlog do Sprint: É uma lista de funcionalidades derivada do backlog selecionado onde os pontos levantados pelos clientes são divididos em tarefas menores Propriedade do Time, qualquer estimativa e mudanças no mesmo, são feitas pela equipe e as tarefas são classificadas de acordo com o seu status. Contém informações sobre o Sprint, como tarefas, tempo e como fazer cada uma das atividades. Criado logo após e baseado em partes do backlog do produto e backlog selecionado, esta documentação é criada a cada Sprint e serve para ajudar no desenvolvimento de melhorias para os próximos Sprints em reuniões típicas do Scrum como a de retrospectiva. (Schwaber, 2002) Backlog de impedimentos: É a lista de dificuldades que poderão ser enfrentadas durante o processo. Gráficos de acompanhamento: Gráficos que medem a quantidade de trabalho restante (burndown charts) são preferidos no Scrum. É recomendado fazê-lo para várias esferas do projeto, tanto para os releases, quanto para os Sprints.

55 55 Figura 4 ScrumBoard - KNIBERG, Henrik. Scrum e XP Direto das Trincheiras. InfoQ, 2007 Esta figura tem grande parte dos elementos de apoio do Scrum, chamada de ScrumBoard. A esquerda são elencadas todas as requisições, chamadas de estórias. Separadas de acordo com o incremento que será entregue no final do Sprint, de acordo com sua prioridade, acima da ScrumBoard estão as estórias priorizadas. Uma vez que as estórias à esquerda na coluna Não Iniciado são escolhidas por algum membro do time, esse passa a estória para a coluna Iniciado, uma vez que ele for finalizado é passado a coluna Pronto. O Gráfico de Burndown detalha o andamento do Sprint. A linha na vertical é a quantidade de pontos a serem realizadas no Sprint e a linha horizontal é o tempo gasto no Sprint, essa linha demonstra a variação do projeto.

56 Papéis e Responsabilidades O Scrum possui uma série de papéis definidos para organizar as equipes. Dois grupos distintos podem ser definidos, os pigs (porcos) e os chickens (galinhas), títulos curiosamente dados a partir de uma citação sobre uma piada. A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed, but you'd only be involved. (Schwaber, 2004) A piada citada basicamente, interpretada na visão do Scrum, ironiza que os porcos são aqueles estão envolvidos na construção de um produto e qualquer outra pessoa é uma galinha, interessados no projeto porem não está envolvidos diretamente do desenvolvimento de algo, porque se algo falhar, eles não são os porcos, ou seja, eles não fazem algo realmente no projeto, porem são suas idéias e influencias que idealizam o projeto, porém não podem ser interferências no mesmo (Schwaber, 2004). papeis são: Os Pigs são aqueles que realmente estão na equipe de projeto, cujos Dono do Produto (Product Owner): O Product Owner é quem tem a visão geral do projeto e faz a vez do cliente no projeto, é ele quem levanta o product backlog e verifica as necessidades iniciais do produto.

57 57 Qualquer dúvida da equipe de desenvolvimento quanto ao produto, deve ser encaminhada para o Product Owner e este dever solucionar o impasse com o cliente e trazer a solução do caso. Quando existem vários interessados ou envolvidos com o produto, o Dono do produto deve ser representado por uma só pessoa, que entenda todas as necessidades e seja capaz de priorizá-las. (Bassi, 2008) Equipe: Com analogia ao Rugby, seria o time propriamente dito, autogerenciável, e que vai executar e organizar tarefas a fim de se alcançar o objetivo. No time todos membros devem ter dedicação total ao time, mesmo tarefas que estejam fora de suas competências, mas que o membro tem capacidade de executar, deve executar, de acordo com as prioridades. O Scrum parte da idéia de que os profissionais da equipe são plenamente capazes de organizar as tarefas e prioridades, e manusear da melhor forma os componentes de apoio. ScrumMaster: O Scrum Máster tem como função fundamental, assegurar que os processos de desenvolvimento seguem os conceitos e idéias do Scrum, que os elementos de apoio estão sendo utilizados de forma correta, e que as idéias implantadas na fase inicial estão sendo seguidas. Pode ser atribuída ao ScrumMaster um status de líder de técnico, onde, com maior experiência no desenvolvimento, pode auxiliar em tarefas e retirar impedimentos, que possam ocorrer durante o processo. O ScrumMaster além de ser um gerente da Equipe, também acaba sendo um líder técnico. É natural que um ScrumMaster tenha que ajudar a Equipe com determinadas soluções técnicas para determinados problemas, pode ser que o ScrumMaster acabe executando uma tarefa típica da Equipe de desenvolvimento.

58 58 (Schwaber, 2004) Segundo Mike Cohn um bom ScrumMaster deve ter seis atributos imprescindíveis são eles: 1 Responsabilidade O ScrumMaster deve ser uma pessoa responsável, pois será ser um líder ser responsável por um projeto. 2 Humildade O Scrum Master deve ser uma pessoa com humildade para poder ouvir as criticas e problemas da equipe, pois no Scrum ele faz parte do grupo e tanto o time quanto o ScrumMaster são fundamentais para o alcançar o objetivo. 3 Colaborativo O ScrumMaster deve colaborar em todos os sentidos para manter um ambiente favorável e motivador, estimulando sempre a comunicação entre o time 4 Comprometido o ScrumMaster não, necessariamente deve estar alocado somente em um projeto Scrum ou mesmo apenas nesta função, porém, é necessário ele estar sempre disposto a fazer o melhor pela equipe. 5 Influência Por parte do ScrumMaster há a necessidade dele ter influente no projeto e fora dele, em todos os sentidos em que o time e o projeto estejam envolvidos, seja na empresa ou com os Product Owners. 6 Entendido O ScrumMaster deve ter o conhecimento necessário para ajudar a equipe em todos os pontos da equipe, seja tecnicamente, gerencialmente ou durante a entrega do projeto.

59 Fases do Scrum O Scrum é um processo adaptativo onde suas iterações baseiam-se no Ciclo de Deming, conhecido também como PDCA ou de Shewhart. O Ciclo de Deming é um ciclo de desenvolvimento que tem foco na melhoria contínua. No Ciclo de Deming temos as seguintes fases: Planejamento, Execução, Verificação e Ação. (Deming, 1986). Figura 5 - Ciclo de Deming (Fonte: Portal da administração, 2009) De acordo com Bassi, as três fases do Scrum, Planejamento, Sprint e Avaliação do projeto correspondem aos três primeiros estados do ciclo de Deming. Comparando as fases do Scrum com o Ciclo de Deming a etapa de Ação acontece no Scrum com mudanças no próximo planejamento baseadas nas conclusões da última avaliação. (Bassi, 2008)

60 60 O primeiro planejamento deve durar o tempo necessário para a equipe conhecer o projeto como um todo e ter uma idéia geral de como funcionará os processos e ter uma idéias das características principais do sistema. Essas informações são passadas através de reuniões que são realizadas nos primeiros dias do planejamento do projeto. Segundo Bassi, na reunião de estimativas, a equipe se reúne para estimar a quantidade de trabalho dos itens com maior prioridade do backlog do produto com a presença do ScrumMaster e do Product Owner para esclarecer dúvidas referentes às regras de negócio. Depois, na primeira reunião de planejamento do sprint (Figura de Ciclo de Vida Scrum), todos se reúnem para definir a meta do Sprint e criar o backlog selecionado de acordo com as prioridades de negócio estabelecidas pelo dono do produto. Em seguida, na reunião de planejamento do sprint a equipe se reúne para quebrar os itens do backlog selecionado em tarefas de implementação de menor granularidade. (Bassi, 2008). Figura 6 - Ciclo do Sprint (Fonte: Corporate Sprint, 2009)

61 61 A fase do Sprint é quando o time implementa o software, em que o time com todos os esforços possíveis e dedicação total ao projeto para entregar o que foi descrito do Sprint Backlog, Esta fase dura o tempo necessário, de acordo com a estimativa do Sprint. Figura 7 - Fases do Scrum (Adaptado de Improve IT, 2008) Ao Final do Sprint, a equipe se reúne com todos envolvidos no projeto a fim de apresentar tudo o que foi realizado durante a fase de sprint, as estórias devem ser classificadas como metas e são exibidas como Meta Atingida ou Meta não Atingida, portanto não há opção entre essas duas, pois, ou a funcionalidade está entregue ou não está pronta e não pode ser entregue. Ao final da entrega do Sprint é realizada uma reunião denominada Sprint Retrospeactive (restrospeactiva do Sprint) é uma reunião onde o time, e todos envolvidos com o projeto diretamente na parte de construção, fazem um reflexão dos pontos passados, relatando o que houve de bom, ruim e o que pode ser melhorado. Pode ser usado uma lousa, com fixação de post-its para uma melhor

62 62 visualização das idéias. (Pereira, 2009). Figura 8 - Retrospectiva Scrum (Fonte:

63 63 4. COMBINAÇÃO DE SCRUM COM OUTRAS TÉCNICAS. O Scrum como metodologia de gerenciamento ágil, como já citado, é um sistema genérico, não apenas focado em projeto de software, por isto, muitas vezes é importante aliar o Scrum com outros métodos ágeis com foco em desenvolvimento de software. Existem diversas metodologias ágeis como Waterfall (cascata) e Lean Software Development, O Extreme Programming (XP) ou mais conservadoras que podem ser utilizadas em um ambiente de desenvolvimento de software, abaixo, serão citadas algumas que vem sendo mais utilizadas hoje em dia. Como o Scrum é um conjunto de técnicas para gerenciamento de projetos, podemos combinar essas técnicas com as melhores práticas das metodologias mais aceitas e difundidas no mercado como o PMBOK (Project Management Body of Knowledge). Formando assim práticas mais robustas, nos próximos capítulos iremos mostrar combinações do Scrum com demais métodos ágeis e uma breve combinação com o PMBOK Scrum e XP - Extreme Programming Atualmente Scrum com XP é são as metodologias, utilizadas em conjunto com melhor aceitação no mercado, segundo o 3rd Annual Survey, publicado em 2008, 23% dos projetos que utilizam Metodologias Ágeis, utilizam Scrum / XP híbrido, ou seja, aliados.

64 64 Figura 9-3rd Annual Survey: The State of Agile Development, 2008 A utilização de Scrum com XP se encaixa de uma maneira certa, onde o Scrum tem o foco nas práticas de gerenciamento, enquanto o XP tem como ênfase a parte de desenvolvimento de software. O Scrum é focado nas práticas de gerenciamento e organização, enquanto o XP dá mais atenção às tarefas de programação mesmo. Aí está o porquê de elas trabalharem bem juntas elas abrangem áreas diferentes e uma complementa a outra. (Kniberg, 2007) O XP foi planejado com doze práticas primárias, que são práticas que tem como foco a programação e gerenciamento do código, a fim de reunir algumas práticas, que podem ser adotadas imediatamente para melhorar o jeito com que o programa é desenvolvido. Posteriormente os conceitos de XP foram revisados e inseridos mais onze práticas corolárias, que são como um complemento das praticas iniciais com

65 65 algumas melhorias. Porém, para implementar as práticas corolárias no projeto, é necessário dominar muito bem as primárias caso contrário pode ser arriscado aplicá-las. Citaremos algumas práticas primárias XP, com foco em desenvolvimento que são bem utilizadas em conjunto com o SCRUM para completar o projeto quando se há foco em desenvolvimento de software Desenvolvimento orientado a testes (TDD) Segundo Roland Jeffries, TDD É um teste automatizado, onde se tem como finalidade fazer o projeto passar nos testes, assim é possível enxugar o código e corrigir erros no processo de desenvolvimento. Teste é uma tarefa muito importante no desenvolvimento de software, porém para executar os procedimentos corretamente acaba-se consumindo muitos recursos do projeto. Normalmente os testes que são automatizados são os testes de regressão, ou seja, aqueles testes que já foram feitos e precisam ser realizados novamente, para verificar se as modificações não afetaram outros pontos do sistema. (Jeffries, 2007) Programação em par Programação em par, basicamente é dois desenvolvedores focados no desenvolvimento de um ponto do projeto, onde ambos ficam centrados em um computador, onde um analisa o código e auxilia (navegador) enquanto o outro faz a programação propriamente dita. Mesmo não sendo plenamente realizada a tarefa de programação em pares, se faz importante saber utilizar a esta técnica com o intuito de aumentar a eficiência no desenvolvimento. São algumas características da programação em par:

66 66 Aumenta o foco da equipe, onde um auxilia o outro e verifica se realmente são necessárias no Sprint atual. Programação em par, não é uma prática que deve ser utilizada diariamente, já que se torna muito cansativa. Os pares devem ser trocados com freqüência, para nivelar o conhecimento da equipe. Nem todos se adaptam bem à programação em par, muitas vezes o programador muito bom, não tem um bom desempenho trabalhando em pares, é necessário gerenciar a equipe a fim de tirar o melhor da equipe. (Kniberg, 2007). O código acaba sempre por ser revisado, e as melhores práticas são utilizadas e eventuais erros acabam sendo detectados com maior facilidade. O navegador pode ter um computador para si próprio, não para desenvolver, mas para outras tarefas, como navegar pela programação e fazer anotações Design Incremental Consiste em iniciar o projeto com um design inicial, muito básico e melhorálo durante o desenvolvimento do projeto, assim é possível incremental, onde o design acaba se encaixando perfeitamente ao projeto naturalmente Integração Contínua A integração contínua consiste em atualização da configuração no usuário, direta, deixando o ambiente de implantação compatível com o software e evita que o sistema funcione no ambiente de desenvolvimento e no cliente ocorra alguma

67 67 incompatibilidade. Essa é a solução definitiva para um velho problema Ei, mas isso funciona na minha máquina. Nosso servidor de construção contínua age como o juiz ou ponto de referência a partir do qual se determina a qualidade de todas as nossas bases de código (Kniberg, 2007) Esta função pode ser executada por programas gerenciadores de versão, onde, toda vez que o sistema é carregado no servidor, ele atualiza os sistemas clientes Build de 10 minutos Assegurar que o build do projeto seja realizado por completo, incluindo testes automatizados não passe de cerca de 10 minutos, pois, caso o projeto seja executado em um tempo muito superior a este, a equipe passa a não executar o build na freqüência necessária e deixa de receber um feedback importante do sistema Refatoração O conceito de Refatoração é na verdade o aperfeiçoamento de um código já desenvolvido anteriormente. Com ele é possível detectar partes do sistema com problemas de desempenho e/ou em uma alteração ou manutenção do código, o reparo é feito com muito mais facilidade, pois, quando outra pessoa, ou mesmo quem desenvolveu tem maior facilidade em entender o código melhor organizado. 4.2 Semelhanças entre Scrum e XP

68 68 Por se tratar ambas as metodologias ágeis, e poderem trabalhar independentemente, Scrum e XP têm muitos pontos em comum, o interessante, quando se há a necessidade de utilizar os dois métodos, é utilizar o melhor de cada um, com o Scrum, focado no gerenciamento e o XP, com algumas práticas de desenvolvimento. Quadro 2 - Fases Semelhantes entre Scrum e XP O Scrum inclusive aconselha o uso de XP quando o foco do projeto é desenvolvimento de software Comparação do Scrum com o desenvolvimento Lean Assim como o Scrum, LSD (Lean Software Development) é uma metodologia de gerenciamento, a origem do Lean voltado para software vem de Lean Manufacturing utilizado na Toyota e que agora passou a ter seus conceitos utilizados para desenvolvimento para outros tipos de projetos Lean manufacturing seria uma produção enxuta, surgiu no Japão, na fábrica da Toyota. Esta metodologia veio logo após o fim da guerra e visava o maior

69 69 resultado em menor tempo com poucos recursos (que eram escassos no pós guerra) e o objetivo do Lean, na indústria e também em outros setores que vem sendo empregados, como no gerenciamento de desenvolvimento de software é eliminação continua de desperdícios. A expansão dos Métodos Ágeis vem cada vez mais importando tecnologia de produção rápida industrial para o mundo da tecnologia e um dos sistemas de produção que vem sendo empregado no desenvolvimento de projetos é o conceito de Lean. LSD tem como meta, deixar o projeto mais magro o possível, enxugando eventuais pontos de desperdício de tempo e recursos com o maior esforçam o possível do time (envolvidos no projeto). Princípios da metodologia LSD: Satisfação do cliente é a maior prioridade. Sempre prover o maior valor ao dinheiro. O sucesso depende da participação do cliente. Todo projeto LSD é um esforço do time. Tudo é alterável. Domínio não aponta soluções. Completo não constrói. 80% do projeto hoje em vez de 100% do projeto amanhã. Minimalismo é essencial. É preciso determinar a tecnologia. Produto crescente são recursos crescentes. Nunca empurre o LSD além dos seus limites Objetivos O objetivo principal do LSD é ser minimalista, ou seja, enxugar a aplicação

70 70 o máximo possível para ter um retorno no menor tempo possível, como umas das características 80% hoje é melhor do que 100% amanhã, esta característica descreve bem o objetivo do Lean. Segundo Bob Charette, o idealizador do LSD, descreve que o objetivo mensurável do LSD é Construir softwares com um terço de esforço humano, um terço de horas de desenvolvimento e um terço de investimento, comparado com o CMM level 3 (Charette, 1989) Comparação Scrum com modelo Waterfall (Cascata) Escolhemos esta comparação entre o modelo cascata já explicado anteriormente, pois em nosso estudo de caso um dos métodos citados é o modelo escolhido. Figura 10 - Desenvolvimento Ágil com Modelo Cascata (DUNCANPIRCE.ORG, 2009)

71 71 Em cada módulo é definida uma prioridade e o trabalho é centrado na prioridade, com releases curtos, o processo passa a ser mais ágil com a documentação mais flexível. Em comparação, o Scrum como metodologia já desenvolvida para ser ágil, acaba levando vantagem no fato de poder ocorrer fases simultâneas, diferente da Waterfall, onde parte da equipe fica sem tarefas em determinadas fases do processo de desenvolvimento Métodos ágeis combinados com o PMBOK O PMBOK Project Management Body of Knowledge. É um dos principais frameworks pra gerenciamento de projetos, o único framework que chega próximo aos seus conceitos é o Prince, mas como é menos utilizado iremos passar os principais conceitos do PMBOK, para posteriormente combinar seus processos com os Métodos Ágeis. Abaixo temos a própria definição do PMBOK em sua terceira edição: O principal objetivo do Guia PMBOK é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. Identificar significa fornecer uma visão geral, e não uma descrição completa. Amplamente reconhecido significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. Boa prática significa que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma

72 72 boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico. (PMBOK, 2004) O que é um Projeto? De acordo com o PMBOK (PMBOK, 2004) um projeto é um esforço, temporário e único para criação de um produto, serviço ou determinado resultado que queira ser alcançado. Um projeto é temporário, pois se presume que tenha começo, um meio um fim definidos. É necessário tem que ter um objetivo, esse objetivo é a meta que deve ser alcançada para que o projeto chegue ao fim. Apesar de serem temporários os projetos podem levar, dias, meses até mesmo anos, porém basta se tiver uma data para o fim que se configura um projeto. Ao contrário do produto gerado, que pode ser eterno. Produto, resultado ou serviço significa que as entregas são únicas, com datas únicas, pessoas únicas, recursos únicos. Nenhum projeto é igual ao outro, qualquer fator por menor que seja já o torna único Gerenciamento de Projeto. O próprio PMBOK define as atividades de gerenciamento de projeto da seguinte forma: a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. (PMBOK, 2004)

73 73 Dentro os envolvidos no projeto o papel mais sugestivo é o do Gerente de Projetos. Ele é responsável pelo andamento do projeto e gerenciar todas as atividades atendidas nesse projeto. Ele é o responsável por fazer com que o projeto termine dentro do prazo acordado, com o objetivo alcançado, com a qualidade suficiente e que seja gasto o que foi planejado anteriormente. Os demais envolvidos no projeto são chamados de Stakeholders, até mesmo o gerente de projeto pode ser chamado de Stakeholders, já que essa palavra se refere a todos os interessados e envolvidos no projeto de alguma forma. O Sponsor é o patrocinador do projeto, ele é quem defende o projeto e financia suas atividades. Também existem outros envolvidos, mas que não são inseridos no contexto de papeis do PMBOK como, clientes, usuários e executivos, ou qualquer outra denominação relacionada Grupos de Processos O PMBOK possui 44 processos onde todos os todos recebem Entradas que são utilizadas por Ferramentas e/ou Técnicas gerando assim as Saídas, conforme ilustrado na Figura 10. Segundo o PMBOK processo é: Um conjunto de ações e atividades inter-relacionadas e realizadas para se obter um conjunto pré-especificado de produtos, resultados ou serviços. (PMBOK, 2004) Figura 11 - Formato do Processo (Adaptado de PMBOK, 2004) Áreas de Conhecimento

74 74 O PMBOK possui 9 áreas de conhecimento, que organizam os 44 processos, essas áreas são: Gerenciamento de Integração Gerenciamento de Tempo Gerenciamento do Escopo Gerenciamento de Riscos Gerenciamento da Qualidade Gerenciamento de Recursos Humanos Gerenciamento das Comunicações Gerenciamento de Custos Gerenciamento de Aquisições

75 Processos nos grupos e áreas de conhecimento. 75

76 76 Quadro 3 - Mapeamento entre os processos de gerenciamento de projetos e os grupos de processos de gerenciamento de projetos e as áreas de conhecimento (PMBOK, 2004) Ao olhar para este quadro, é perceptível o forte foco do PMBOK Guide em planejamento, já que a maioria, 21 dos processos são do grupo de planejamento. É quase a metade dos 44 processos Pesquisas Métodos Ágeis X PMBOK Certificada PMP (Project Management Professional) e CSM (Certified ScrumMaster), Michele Sligler é uma das pessoas que vem relacionando práticas ágeis com os estudos do PMBOK. Em seus quatro artigos chamados de Relating PMBOK Practices to Agile Practices (Sliger, 2006). Ela levanta práticas de como pode se trabalhar com o PMBOK e Métodos ágeis. De acordo com Sligler apesar de as duas práticas terem filosofias distintas elas podem ser combinadas. O gerenciamento do escopo é a área mais importante do PMBOK, pois a partir dessa definição o projeto começa a ser concebido. Nos Métodos Ágeis também é importante, porém a idéia é ser mais suscetível a adaptações e mudanças. Enquanto o PMBOK blinda o escopo contra mudanças. Sliger cita que é a forma de criar uma EAP (Estrutura Analítica do projeto ou WBS (Work Breakdown Structure). Ao invés de conter todo o trabalho para o projeto como normalmente é feito no PMBOK, no modelo ágil a EAP pode ser feita no início de cada release. Koch traz em uma de suas apresentações (The Agile Manifesto and the PMBOK), um mapeamento dos grupos de processos do PMBOK relacionado com o desenvolvimento iterativo, conforme na Figura abaixo:

77 77 Figura 12- Desenvolvimento iterativo e grupos de processos PMBOK. (Adaptado de Koch, 2004) Nesta apresentação Koch passa por cada um dos processos do PMBOK, abordando os impactos relacionados ao desenvolvimento interativo. Koch conclui dizendo que Nada nas Metodologias Ágeis é incompatível com os processos do PMBOK e que pode ser vantajoso reforçar as Metodologias Ágeis com processos do PMBOK, porém apenas onde realmente necessário e sem comprometer a agilidade (Koch, 2004). No quadro 5 podemos diferenciar as abordagens realizadas em cada área do processo do PMBOK com o ideal de gerenciamento Ágil de acordo com a Innovit empresa focada no mercado de Tecnologia da Informação e comunicação, que presta serviços de consultoria, educação e outsourcing em Gestão de Projetos, Engenharia de Software, Qualidade de Software e Melhoria de Processos. Onde controle de Gold Plating Ato de impedir a realizar de trabalho extra que não faça parte do escopo do projeto

78 Quadro 4 - Comparativo: PMBOK X Ágil (INNOVIT.com, 2009) 78

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

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

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

Daniel Wildt -dwildt@gmail.com

Daniel Wildt -dwildt@gmail.com Metodologias Ágeis e Software Livre Daniel Wildt -dwildt@gmail.com Bacharel em Informática (PUCRS) Professor Universitário (FACENSA) Mais de 10 anos de experiência em Desenvolvimento de Software, hoje

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

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 5 http://www.ic.uff.br/~bianca/engsoft2/ Aula 5-05/05/2006 1 Dúvidas da aula passada RUP (Rational Unified Process) é uma ferramenta ou um processo? Resposta: os dois. O

Leia mais

Análise de Sistemas Unidade III A Engenharia de Software Desenvolvimento Ágil

Análise de Sistemas Unidade III A Engenharia de Software Desenvolvimento Ágil Análise de Sistemas Unidade III A Engenharia de Software Desenvolvimento Ágil franciscogerson10@gmail.com Conteúdo Programático Introdução O que é um processo ágil A política de desenvolvimento ágil Fatores

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

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

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

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP extreme Programming extreme Programming (XP) Metodologia ágil para equipes pequenas a médias desenvolvendo software com requesitos vagos ou que mudam freqüentemente. [Beck 2000] Em XP, codificação é principal

Leia mais

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO Análise da Metodologia Ágil SCRUM no desenvolvimento de software para o agronegócio Limeira

Leia mais

2012. Quinta Conferência de Qualidade de Software ASR Consultoria

2012. Quinta Conferência de Qualidade de Software ASR Consultoria 1 Visão CMMI do Ágil 2 Visão CMMI do Ágil 3 Visão Ágil do CMMI 4 Visão Ágil do CMMI 5 Visão Ágil do CMMI 6 Manifesto para Desenvolvimento Ágil de Software Estamos descobrindo maneiras melhores de desenvolver

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

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

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

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

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

METODOLOGIA ÁGIL. Lílian Simão Oliveira

METODOLOGIA ÁGIL. Lílian Simão Oliveira METODOLOGIA ÁGIL Lílian Simão Oliveira Fonte: Pressman, 2004 Aulas Prof. Auxiliadora Freire e Sabrina Schürhaus Alexandre Amorin Por quê???? Principais Causas Uso das Funcionalidades Processos empírico

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

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Metodologias para Desenvolvimento de Software XP e SCRUM Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Agenda Desenvolvimento Ágil de Software

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

Prof. Me. Marcos Echevarria

Prof. Me. Marcos Echevarria Prof. Me. Marcos Echevarria Nas décadas de 80 e 90 a visão geral sobre a melhor maneira de desenvolver software era seguir um cuidadoso planejamento para garantir uma boa qualidade; Esse cenário era aplicável

Leia mais

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

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

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

Especialização em Engenharia de Software e Banco de Dados

Especialização em Engenharia de Software e Banco de Dados Especialização em Engenharia de Software e Banco de Dados Disciplina: Engenharia de Software Tópico: Metodologias Ágeis Prof. Rodolfo Miranda de Barros rodolfo@uel.br O que é agilidade? Agilidade: Rapidez,

Leia mais

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS Jeandro Maiko Perceval 1 Carlos Mario Dal Col Zeve2 Anderson Ricardo Yanzer Cabral ² RESUMO Este artigo apresenta conceitos sobre

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

um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO

um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO Um pouco de história... Década de 50: a gestão de projetos é reconhecida como disciplina,

Leia mais

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com.

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com. ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS (CASE STUDY: SCRUM AND PMBOK - STATES IN PROJECT MANAGEMENT) Aline Maria Sabião Brake 1, Fabrício Moreira 2, Marcelo Divaldo Brake 3, João

Leia mais

development Teresa Maciel DEINFO/UFRPE

development Teresa Maciel DEINFO/UFRPE development Teresa Maciel DEINFO/UFRPE Prazos curtos Baixo custo Agregação ao negócio Fidelidade do cliente Competitividade Sobrevivência Cenário 2000 35% dos projetos apresentam sucesso 31% dos projetos

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

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

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

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

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

Leia mais

Gerenciamento de Projetos de Software

Gerenciamento de Projetos de Software Gerenciamento de Projetos de Software Framework Ágil, Scrum Prof. Júlio Cesar da Silva Msc. 2º Encontro Ementa & Atividades Aula 1: Fundamentos do Gerenciamento de Projetos (p. 4) 30/abr (VISTO) Aula 2:

Leia mais

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum C.E.S.A.R.EDU Unidade de Educação do Centro de Estudos e Sistemas Avançados do Recife Projeto de Dissertação de Mestrado FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum Eric de Oliveira

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

SCRUM e Requisitos Ágeis

SCRUM e Requisitos Ágeis SCRUM e Requisitos Ágeis Régis Simão /44 Agenda Métodos Ágeis SCRUM Modelo de Negócio Definição do Produto Planejamento e Execução de uma Release 2 /44 Agenda Métodos Ágeis SCRUM Modelo de Negócio Definição

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

Introdução Engenharia de Software

Introdução Engenharia de Software Introdução Engenharia de Software Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 EMENTA Parte 1 Conceitos de Engenharia de Software. Processo de desenvolvimento

Leia mais

Desenvolvimento Ágil de Software em Larga Escala

Desenvolvimento Ágil de Software em Larga Escala Desenvolvimento Ágil de Software em Larga Escala Jutta Eckstein Encontro Ágil 2009 1 Agilidade é Quente Gerenciamento Ágil de Projetos Testes Ágeis Arquitetura Ágeis Offshore Ágil Investimento Ágil PLM

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

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente.

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Desenvolvido por Jeff SUTHERLAND e Ken SCHWABER ; Bastante objetivo, com papéis bem definidos; Curva de Aprendizado é

Leia mais

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças. METODOLOGIAS ÁGEIS SURGIMENTO As metodologias ágeis surgiram em resposta ao problema dos atrasos no desenvolvimento de software e aos cancelamentos, devido ao fato dos sistemas demorarem muito tempo para

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

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

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks S C R U M Apresentação Tiago Domenici Griffo Arquiteto de Software na MCP, MCAD, MCSD, MCTS Web, Windows e TFS, ITIL Foundation Certified, MPS.BR P1 Experiência internacional e de offshoring Agradecimento

Leia mais

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SIG Aula N : 11 Tema: Como desenvolver e

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE Prof. Msc. Hélio Esperidião O QUE É UM ALGORITMO? É qualquer procedimento computacional bem definido que informa algum valor ou conjunto de valores como entrada

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

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK V EPCC Encontro Internacional de Produção Científica Cesumar 23 a 26 de outubro de 2007 METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK Cleber Lecheta Franchini 1 Resumo:

Leia mais

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education [Agile] Scrum + XP Agilidade extrema Wagner Roberto dos Santos Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com 1 Apresentação Arquiteto Java EE / Scrum Master Lead Editor da Queue Arquitetura

Leia mais

Métodos Ágeis para Desenvolvimento de Software Livre

Métodos Ágeis para Desenvolvimento de Software Livre Métodos Ágeis para Desenvolvimento de Software Livre Dionatan Moura Jamile Alves Porto Alegre, 09 de julho de 2015 Quem somos? Dionatan Moura Jamile Alves Ágil e Software Livre? Métodos Ágeis Manifesto

Leia mais

GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS 1

GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS 1 1 GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS 1 Peter Rizzon 2 Resumo: Com a crescente demanda no desenvolvimento de softwares baseados na plataforma web, as empresas

Leia mais

Métodos Ágeis e Gestão de Dados Moderna

Métodos Ágeis e Gestão de Dados Moderna Métodos Ágeis e Gestão de Dados Moderna Bergson Lopes contato@bergsonlopes.com.br www.bergsonlopes.com.br Dados do Palestrante Bergson Lopes Rego, PMP é especialista em Gestão de Dados, Gerenciamento de

Leia mais

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE BOAS PRÁTICAS DO PMI COM OS MÉTODOS ÁGEIS Por: Sheyla Christina Bueno Ortiz Orientador Prof. Nelsom Magalhães Rio de Janeiro

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

Leia mais

Wesley Torres Galindo

Wesley Torres Galindo Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar

Leia mais

Método Aldeia de Projetos

Método Aldeia de Projetos MAP Método Aldeia de Projetos Como surgiu o MAP? Em mais de 15 anos de atuação experimentamos distintas linhas de pensamento para inspirar nosso processo e diversas metodologias para organizar nossa forma

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Wesley Torres Galindo. wesleygalindo@gmail.com

Wesley Torres Galindo. wesleygalindo@gmail.com Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br Comparativo entre Processos Ágeis Daniel Ferreira dfs3@cin.ufpe.br O que discutiremos: Histórico Os Princípios Ágeis Comparação Do ponto de vista incremental Do ponto de vista funcional Vantagens e Desvantagens

Leia mais

Métodos Ágeis, Fomando Times de Alto Desempenho. Ari do Amaral Torres Filho @ariamaral ariamaralt@gmail.com

Métodos Ágeis, Fomando Times de Alto Desempenho. Ari do Amaral Torres Filho @ariamaral ariamaralt@gmail.com Métodos Ágeis, Fomando Times de Alto Desempenho Ari do Amaral Torres Filho @ariamaral ariamaralt@gmail.com Iniciando com uma Apresentação (Instrutor, Alunos e Palestra) Apresentação do Professor Sou Bacharel

Leia mais

Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis

Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis Eduardo dos Santos Gonçalves 1, Heitor Boeira dos Reis Filho 1 1 Universidade Luterana do Brasil (ULBRA) Av. Itacolomi, 3.600 Bairro São

Leia mais

Kanban na Fábrica de Software

Kanban na Fábrica de Software Kanban na Fábrica de Software Casimiro Beleze (UEM) casimirobeleze@hotmail.com Lafaiete H. R. Leme (UEM) lafaiete@din.uem.br Resumo: Este trabalho apresenta um enfoque diferenciado para o gerenciamento

Leia mais

www.plathanus.com.br

www.plathanus.com.br www.plathanus.com.br A Plathanus Somos uma empresa com sede na Pedra Branca Palhoça/SC, especializada em consultoria e assessoria na criação e desenvolvimento de estruturas e ambientes especializados com

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

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

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Desenvolvimento Ágil de Software com Programação extrema (XP) Ricardo Argenton Ramos

Desenvolvimento Ágil de Software com Programação extrema (XP) Ricardo Argenton Ramos Desenvolvimento Ágil de Software com Programação extrema (XP) Ricardo Argenton Ramos Novos ventos no mundo do Desenvolvimento de Software Sociedade demanda grande quantidade de sistemas/aplicações software

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Processo Um processo é uma série de etapas envolvendo actividades, restrições e

Leia mais

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Roberto Costa Araujo Orientador: Cristiano T. Galina Sistemas de Informação Universidade do Vale do Rio dos Sinos

Leia mais

Gerenciamento Ágil de Projetos de Desenvolvimento de Softwares na Secretaria de Estado da Casa Civil

Gerenciamento Ágil de Projetos de Desenvolvimento de Softwares na Secretaria de Estado da Casa Civil Gerenciamento Ágil de Projetos de Desenvolvimento de Softwares na Secretaria de Estado da Casa Civil Claryanne A. Guimarães 1, Daniel Dias S. Rosa 1 1 Departamento de Computação Universidade Federal de

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso

Leia mais

MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS

MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS MIRILIAN CARLA ARAUJO CORILLO 1, ANDREA PADOVAN JUBILEU 2. 1 Tecnóloga em Análise e Desenvolvimento de Sistemas

Leia mais