Método Ágil em Gerenciamento de Projetos de Software

Fundação Getulio Vargas MBA em Gerenciamento de Projetos Método Ágil em Gerenciamento de Projetos de Software Ana Cristina Monteiro Almeida Arnaldo Lyrio Barreto (Orientador) Rio de Janeiro Outubro de 2014. 1

ANA CRISTINA MONTEIRO ALMEIDA Método Ágil em Gerenciamento de Projetos de Software Trabalho de Conclusão de Curso apresentado à Fundação Getulio Vargas, com um dos requisitos de conclusão de curso de MBA de Gerenciamento de Projetos.. Orientador: Prof. Arnaldo Lyrio Barreto Rio de Janeiro Outubro de 2014. 2

RESUMO Este trabalho visa apresentar conceitos e práticas do método ágil SCRUM com suas características e aplicações, realizando uma comparação entre metodologia ágil em relação à metodologia tradicional. É objeto desta pesquisa a aplicação do SCRUM junto ao gerenciamento de projetos de software apresentando diferenças entre eles e o que uma complementa na outra, concluindo com estudo de caso, com respostas de gerentes de projetos de uma empresa sobre a temática. Palavras-chave: Método Ágil, SCRUM, Metodologia Tradicional, Projetos, Software. 3

ABSTRACT This paper intends to present concepts and practices of SCRUM agile method with their characteristics and applications, performing a comparison between agile methodology versus a traditional one. Object of this research is this implementation of SCRUM in the software project management showing their differences and what they add up to each other, concluding with a case study with answers project managers of a company on the thematic. Keywords: Agile Methods, SCRUM, Traditional Methods, Project, Software. 4

SUMÁRIO RESUMO...i ABSTRACT...ii LISTA DE FIGURAS...v 1. INTRODUÇÃO... 7 2. COMPARATIVO DA METODOLOGIA ÁGIL EM RELAÇÃO AO MÉTODO TRADICIONAL... 7 2.1 Método Tradicional... 7 2.2 Metodologia Ágil... 9 3. RELAÇÃO ENTRE SCRUM E O GERENCIAMENTO DE PROJETO (PMBOK)... 10 4. SCRUM... 12 4.1 Papeis e responsabilidades... 13 4.2 Artefatos... 14 5. ESTUDO DE CASO... 17 5.1 Escolha da Empresa... 17 5.2 Condução do Estudo de Caso... 17 5.3 Respostas Obtidas - Gerente 1... 18 5.3 Respostas Obtidas - Gerente 2... 20 5.4 Respostas Obtidas - Gerente 3... 22 6 ANÁLISE DE DADOS... 24 CONCLUSÃO... 27 REFERÊNCIAS BIBLIOGRÁFICAS... 28 5

LISTA DE FIGURAS Figura 1 Modelo em Cascata...8 Figura 2 Ciclo de Vida Metodologia Ágil...10 Figura 3 Grupo de Processos do PMBOK...11 Figura 4 Sprint Burndown Chart...13 Figura 5 Sprint...15 Figura 6 Daily Scrum 16 6

1. INTRODUÇÃO Empresas de desenvolvimento de software geralmente enfrentam grandes desafios na produção de seus sistemas. Segundo Caetano (2010), um dos problemas encontrados entre os projetos de metodologias tradicionais são falhas na comunicação entre os envolvidos no projeto, gerando erros e atrasos nas etapas de desenvolvimento, falta de colaboração do cliente como integrante da equipe e documentação exaustiva que nem sempre diz o que realmente deve ser feito (Koscianski; Soares, 2007). Neste trabalho o objetivo é mostrar as práticas ágeis de desenvolvimento de software e gerenciamento de projetos e de como uma metodologia ágil pode simplificar os processos de gerenciamento de projeto, tornando um produto de software com mais qualidade. O trabalho está organizado nos seguintes capítulos: Comparativo da metodologia ágil em relação ao método tradicional, Relação entre SCRUM e o Gerenciamento de Projeto (PMBOK), O SCRUM e Estudo de Caso sobre o método ágil SCRUM, finalizando com a análise dos dados coletados de entrevistas e uma conclusão. 2. COMPARATIVO DA METODOLOGIA ÁGIL EM RELAÇÃO AO MÉTODO TRADICIONAL Muitas organizações desenvolvem software usando processos que não são muito bem definidos. Segundo Pressman (2002), geralmente isso acontece porque os processos tradicionais de software (cascata, prototipação e espiral) não são adequados às realidades das organizações ou os recursos não são suficientes para adotar o uso de processos. Para Sommerville (2003), organizações criam seu próprio processo ou adaptam algum processo à sua realidade. Dentre os vários processos, existem as metodologias tradicionais, que são orientadas a documentação, e as metodologias ágeis, que procuram desenvolver software com o mínimo de documentação. 2.1 Método Tradicional Pressman (2002), afirma que o Modelo Clássico ou Sequencial foi o primeiro processo publicado de desenvolvimento de software. É um modelo em que existe uma sequência a ser seguida de uma etapa a outra. Cada etapa tem associada ao seu término uma documentação padrão que deve ser aprovada para que se inicie a etapa imediatamente posterior. De uma forma geral, fazem parte do modelo Clássico as etapas de definição de requisitos, projeto do software, implementação e teste unitário, integração e teste do sistema, operação e manutenção. Para Pressman (2002), o Modelo em Cascata, também chamado de Ciclo de Vida Clássico, é um processo recomendado quando os requisitos de um problema são razoavelmente bem compreendidos, 7

ou seja, quando o trabalho flui da comunicação até a implantação de um modo linear. O Modelo em Cascata conforme ilustrado na figura 1, sugere uma abordagem sistemática e sequencial para o desenvolvimento de softwares. O foco principal das metodologias tradicionais é a previsibilidade dos requisitos do sistema, que traz a grande vantagem de tornar os projetos completamente planejados, facilitando a gerência do mesmo, mantendo sempre uma linha, caracterizando o processo como bastante rigoroso, Oliveira (2004). Figura 1 Modelo em Cascata Fonte: Pressman (2010). 8

2.2 Metodologia Ágil O termo Metodologias Ágeis tornou-se popular em 2001, quando dezessete especialistas em processos de desenvolvimento de software representando os Métodos SCRUM Schwaber e Beedle (2002), Extreme Programming (XP) Beck (2001) e outros, estabeleceram princípios comuns compartilhados por todos esses métodos. Foi então criada a Aliança Ágil e o estabelecimento do Manifesto Ágil [Agile Manifesto (2004)]. Os conceitos-chave do Manifesto Ágil são: Indivíduos e interações ao invés de processos e ferramentas. Software executável ao invés de documentação. Colaboração do cliente ao invés de negociação de contratos. Respostas rápidas a mudanças ao invés de seguir planos. Segundo Beck (2001), o Manifesto Ágil não rejeita a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária quando comparado com os indivíduos e interações, com o software estar executável, com a colaboração do cliente e as respostas rápidas a mudanças e alterações. Uma característica das metodologias ágeis é que elas são adaptativas ao invés de serem preditivas. Como afirmam Schwaber e Beedle (2002), elas se adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invés de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento. As metodologias ágeis não são uma forma de contrariar as metodologias tradicionais. Os princípios e valores propostos pelo Manifesto Ágil propõem uma nova maneira de pensar desenvolvimento e gerenciamento de software, tendo em mente um conjunto de valores compatíveis, baseados na confiança e respeito pelos companheiros de equipe e promovendo modelos organizacionais simplificados e centrados em pessoas e em colaboração. 9

Figura 2 Ciclo de Vida Metodologia Ágil Fonte: Adaptada Carçalto (2008). 3. RELAÇÃO ENTRE SCRUM E O GERENCIAMENTO DE PROJETO (PMBOK) De acordo com o PROJECT MANAGEMENT INSTITUTE (PMI, 2008), o PMBOK ou Guia de Conhecimentos em Gerenciamento de Projetos é um conjunto de boas práticas dividido em áreas de conhecimentos e grupos de processos. Porém não se usa todos os processos e sim aquilo que é realmente necessário num projeto. O principal objetivo do PMBOK é visualizar a gerência de projetos como um conjunto de processos encadeados e integrados. Por processos entende-se uma série de ações que provocam resultados. O PMBOK descreve 42 processos estruturados em cinco grupos, conforme mostrado na figura 3. 10

Figura 3 Grupo de Processos do PMBOK Fonte: Adaptado do PMBOK quarta edição (PMI,2008). O SCRUM se adapta mais a projetos cujo escopo é parcialmente desconhecido ou incerto. No PMBOK, não conhecer o escopo (pelo menos parte dele) inviabiliza o planejamento e a execução do projeto. O SCRUM trabalha com priorizações e ciclos curtos de entregas. O PMBOK trabalha com riscos, pode priorizar entregas e fazer ciclos de entregas. Segundo Tavares (2008), no SCRUM o projeto é dividido em Sprints enquanto que no PMBOK é dividido em várias fases, seguindo a sequência uma após a outra. No PMBOK, o envolvimento do cliente é menor, já no SCRUM a interação com o cliente é direta, pois o mesmo participa de todas as reuniões de Sprints tornando mais flexível que o PMBOK. O PMBOK aborda todas as áreas vitais de um bom planejamento e orienta os gerentes de projeto a conseguirem atingir os objetivos dos projetos que conduzem dentro do prazo, orçamento e qualidade exigidos. O PMBOK, através de práticas tradicionais e inovadoras, é aplicável na maior parte do projeto, na maior parte do tempo. Fornece um guia genérico para todas as áreas do projeto, seja uma produção de software ou uma obra de construção civil, e provê um vocabulário único para a gerência de projetos, padronizando seus termos. Para Schwaber e Sutherland (2013), o SCRUM é uma metodologia ágil que usa uma técnica simplificada. No entanto ser simples pode ser confundido com falta de controle e desorganização. 11

Entretanto, as decisões de quando e como usar o SCRUM, e quais táticas e estratégias seguir para obter produtividade e realizar entregas, fica por conta de quem o estiver aplicando. O conhecimento das suas práticas permite uma aplicação de forma variada, e este é um dos aspectos positivos do SCRUM a adaptabilidade. Vale ressaltar que as práticas do SCRUM podem ser aplicadas em qualquer contexto, no qual pessoas precisem trabalhar juntas para atingir um objetivo comum, segundo Chapiewski (2009). A abordagem ágil (SCRUM), assim como a abordagem tradicional (PMBOK), possui características positivas e negativas, sendo que a principal diferença entre as duas está no conjunto de pressupostos de cada uma. É possível afirmar que uma pode complementar a outra. O que deve ser levado em consideração para o uso das duas abordagens são as características do projeto a ser desenvolvido. A meta é portanto buscar aplicar a metodologia correta para alcançar o objetivo do trabalho. 4. SCRUM O SCRUM é um framework na qual pode empregar diversos processos e técnicas aplicáveis em ambientes voláteis e que se destaca entre os demais métodos ágeis pela ênfase dada ao gerenciamento de projetos. O papel do SCRUM é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que possa melhorá-las (Schwaber, 2009). O SCRUM emprega uma abordagem iterativa e incremental para otimizar a previsibilidade, controlar riscos, desenvolvimento de qualquer tipo de produto ou gerenciamento de qualquer tipo de trabalho. Dentre as metodologia ágeis, o SCRUM é uma das mais difundidas por ter maior foco em gerenciamento. Consiste em um conjunto formado por Time Scrum e seus papéis associados; Eventos com Duração Fixa (Time-Boxes); Artefatos e Regras (Schwaber, 2009). Baseia-se em princípios como equipes pequenas de, no máximo, 9 pessoas, iterações curtas e requisitos que são pouco estáveis ou desconhecidos. Como Funciona? Segundo Pereira (2009), o ciclo do SCRUM tem o seu progresso baseado em uma série de iterações bem definidas, chamada Sprint, cada uma com duração de duas a quatro semanas, chamada de Timebox. Antes de cada Sprint, realiza-se uma Reunião de Planejamento - Sprint Planning Meeting em que o time de desenvolvedores tem contato com o cliente - Product Owner para priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. A próxima fase é a Execução da Sprint Mountain (2009). Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando Reuniões Diárias Rápidas - Daily Meeting, não mais que 15 minutos de duração, e observando o seu progresso 12

usando um gráfico chamado Sprint Burndown (figura 3). Ao final de cada Sprint, é feita uma revisão no produto entregue para verificar se tudo realmente foi implementado (Pereira, 2009). Figura 4 Sprint Burndown Chart Fonte - Java Code Geeks (2012). Ao final de cada Sprint, deve-se realizar uma Reunião de Revisão - Sprint Review, em que o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunião de Retrospectiva - Sprint Retrospective, uma reunião de lições aprendidas, com o objetivo de melhorar o processo/time e/ou produto para a próxima Sprint, como afirma Figueiredo (2009). Ainda segundo este autor, o SCRUM torna-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos, sejam eles novos ou apenas requisitos modificados. No entanto, para aplicá-io, é preciso entender antes os seus papeis, responsabilidades, conceitos e artefatos das fases de seu ciclo. 4.1 Papeis e responsabilidades Na metodologia ágil é implementada uma estrutura iterativa e incremental através de três papeis principais: o Product Owner, o SCRUM Team e o SCRUM Master, como descrito abaixo Isotton Neto (2008): 13

SCRUM Master É o responsável por garantir que o processo seja entendido e seguido, devendo também remover obstáculos que atrapalham a produtividade da equipe, organizando e facilitando as reuniões. Product Owner É o dono do produto. Ele fornece conhecimento do negócio em forma de requisitos para a equipe assim como sua ordem na aplicação. Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos, documentando-os conforme a necessidade, e determinando a ordem da execução. O Product Owner também define o cronograma para liberação das releases e faz a validação final para saber se as implementações tem as características e qualidade necessárias para a liberação. SCRUM Team São auto-gerenciáveis, multidisciplinares e trabalham em iterações. São responsáveis pelo desenvolvimento do produto, devem também ter autonomia para tomar decisões sobre como executar o seu trabalho. O tamanho típico da equipe varia entre 6 e 10 pessoas e mais do que isso pode, dificultar a comunicação entre a equipe e dificultar a produtividade. 4.2 Artefatos Os artefatos do SCRUM representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o SCRUM são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos (Schwaber e Sutherland, 2013). Product Backlog É a lista principal de funcionalidades para o desenvolvimento de um produto. O product backlog pode mudar no decorrer das sprints tornando-se maior, melhor especificado e mudando as prioridades das entregas. 14

Sprint O processo de desenvolvimento é dividido em ciclos regulares ao longo do tempo. Sprint é cada um destes ciclos. Uma Sprint pode ser de 2 ou 3 semanas. As sprints devem ter sempre a mesma duração. Figura 5 - Sprint Fonte: Blog scrumhalf (2012). Sprint Backlog Sprint Backlog representa tudo o que deverá ser feito durante a próxima Sprint do projeto. Ele surge a partir do que foi levantado e listado pelo Product Owner, no Product Backlog. A maioria dos itens que estão no Product Backlog serão implementados um dia, mas para serem considerados para fazer parte do Sprint Backlog eles devem estar detalhados, estimados e priorizados. Planejamento de uma Sprint É preciso definir quais histórias do Product Backlog serão implementadas na Sprint que está para ser iniciada. Para isso, as histórias no Product Backlog devem estar em uma ordem de prioridade definida pelo Product Owner e estimadas pela equipe de desenvolvimento. Para Pereira (2009), o Product Backlog priorizado e estimado, a equipe de desenvolvimento realiza uma reunião de planejamento para selecionar as histórias que serão incluídas na Sprint de modo a 15

acomodá-las dentro do tempo da Sprint e respeitando a priorização definida pelo PO (Product Owner). Este conjunto de histórias incluídas na Sprint é chamado de Sprint Backlog. Uma vez definido o Sprint Backlog, a Sprint pode então ser iniciada. Neste momento, a equipe de desenvolvimento parte para um segundo planejamento, no qual cada história é subdividida em tarefas menores, a fim de se ter um maior controle sobre o desenvolvimento de cada história individualmente. Execução Durante a execução da Sprint, a equipe executa as tarefas para a realização das histórias seguindo a ordem de prioridade definida pelo PO. A cada dia da Sprint, a equipe de desenvolvimento faz uma breve reunião, chamada de Daily Scrum. O objetivo é falar o que foi feito no dia anterior, quais são seus impedimentos e o que será feito no dia atual. Caso haja impedimentos, o Scrum Master busca resolvê-lo o mais rápido possível para que a equipe possa dar prosseguimento aos trabalhos da Sprint. O Scrum Master também participa desta reunião diária se for possível. Figura 6 Daily Scrum. Fonte: The Scrum Guide - Ken Schwaber and Jeff Sutherland (2011). 16

Fechamento Ao final da Sprint é realizada a reunião de Review. Nesta reunião, a equipe apresenta as histórias implementadas na Sprint, mostrando o seu resultado para o Product Owner. O Product Owner então analisa a resolução de cada história junto à equipe de desenvolvimento e decide se aprova ou não cada uma delas. As histórias reprovadas retornam para o Product Backlog e ficam disponíveis para serem incluídas em uma nova Sprint. Nesta reunião, aproveitando que Product Owner e a equipe estão juntos, também podem ser discutidas histórias do Product Backlog que não tenham sido bem compreendidas pela equipe de desenvolvimento. Após a reunião de Review, a equipe de desenvolvimento junto ao Scrum Master faz a reunião de Retrospectiva. Nessa reunião, o Product Owner não participa. A equipe compartilha a sua opinião e reflete sobre o que funcionou e o que não funcionou ao longo da Sprint. É feita uma discussão sobre os pontos positivos e negativos da Sprint, com o objetivo de reforçar o que foi bom e levantar soluções para o que foi ruim. Assim, a cada Sprint, a equipe vai aprendendo e melhorando o seu processo de desenvolvimento. 5. ESTUDO DE CASO 5.1 Escolha da Empresa A empresa escolhida para estudo de caso é uma empresa brasileira de energia atuante nos seguintes setores: exploração e produção, refino, comercialização e transporte de óleo e gás natural, petroquímica, distribuição de derivados, energia elétrica, biocombustíveis e outras fontes renováveis de energia. É reconhecida mundialmente pela excelência tecnológica. A empresa desenvolve internamente os softwares que atendem aos diversos setores da empresa. A área de Tecnologia da Informação é uma das maiores do estado do Rio de Janeiro. A empresa escolhida utiliza metodologias ágeis, dentre elas, o SCRUM, para gerenciar seus projetos de software. 5.2 Condução do Estudo de Caso O estudo de caso foi conduzido por meio de entrevista, no qual foram entrevistados três Scrum Master e/ou Gerente de Projetos. Seguem abaixo as questões aplicadas para o resultado do estudo de caso. 1- Há quanto tempo à empresa adota a metodologia SCRUM em seus projetos? Existia outra metodologia para gerenciar projetos antes do SCRUM? 2 - Porque a empresa escolheu a metodologia SCRUM para o gerenciamento de projetos? 3 - Quais práticas do SCRUM a empresa adotou? Teve alguma prática adotada que não deu certo? 4 - Qual é o tamanho das Sprints para cada projeto? 17

5 - Existem interação e comunicação dos envolvidos (equipe, projeto e cliente) nas fases do projeto? Como? 6 - Como o gestor monitora e controla as atividades da Sprint? 7 - Como é realizado o planejamento de uma Sprint? 8 - Como é realizada a entrega do produto para os clientes? 9 - Qual é o processo quando o cliente solicita alterações ou novas mudanças no software que está em desenvolvimento? 10 - Quais tipos de testes são utilizados? E como são evidenciados? 5.3 Respostas Obtidas - Gerente 1 Nesta seção serão apresentadas as respostas obtidas na entrevista com o Gerente de Projetos 1, na qual as respostas serão descritas na ordem do questionário. Resposta 1: A empresa utiliza o SCRUM para gerenciar seus projetos há 4 anos, desde de 2010. As outras metodologias utilizadas para gerenciar seus projetos eram o RUP e Análise Essencial. Resposta 2: A empresa passou a utilizar o SCRUM após muitos projetos serem entregues com atrasos. Sendo que boa parte do que foi desenvolvido não estava atendendo o que o cliente tinha pedido. Causando retrabalho e insatisfação do cliente. Uma área da empresa adotou essa metodologia, e as outras áreas não vinham essa nova metodologia com bons olhos pois falavam que não teria nenhuma documentação de requisitos. Isso causou uma certa resistência nas outras áreas. A área na qual adotou o SCRUM começou a mostrar bons resultados. Os projetos passaram a cumprir prazos, o cliente estava satisfeito com o que estava sendo entregue. Houve maior qualidade no produto entregue ao cliente e a equipe se sentia mais motivada, pois a mesma passou a ter maior integração com todos os envolvidos do projeto, inclusive com o cliente. Com isso outras áreas passaram a adotar o SCRUM, e a troca de metodologia foi acontecendo gradativamente. Resposta 3: A empresa adotou praticamente todas as práticas: reuniões de planning, estimativa, retrospectiva e review, product backlog, quadro de tarefas Scrum, daily meeting. 18

A metodologia foi adaptada e associada a algumas práticas do RUP. Os requisitos levantados eram colocados no Documento de Visão e de Regras de Negócio. O product backlog é a lista de todas as funcionalidades e é priorizado pelo cliente e estimado pela equipe utilizando o planning poker. O Planning Poker acontece com toda a equipe, juntamente com o Scrum Master e o Cliente e desta forma, a equipe estima cada história do product backlog. As reuniões de planning são apresentadas as histórias associadas a uma Sprint em questão. Na reunião de retrospectiva é discutido as lições aprendidas de cada integrante da equipe, identificar os pontos fortes e fracos, o que é preciso iniciar, parar ou continuar para a próxima Sprint. Na reunião de review é uma prática considerada fundamental onde é apresentado ao cliente o que foi construído durante a Sprint. O Daily meeting é uma reunião em pé com duração de até 15 minutos, e que acontece diariamente entre a equipe de desenvolvimento, afim de obter de cada membro o status de suas tarefas, ou seja, o que cada um está fazendo, e o que irá fazer até a próxima reunião e se há algum impedimento e se houver o Scrum Master tem que resolvê-lo. Resposta 4: O tamanho das sprints variam em 2 e 3 semanas, dependendo do escopo e da necessidade do cliente. Resposta 5: Sim. Nas reuniões diárias há o encontro entre a equipe de desenvolvimento e o Scrum Master/Gerente de Projetos. E nas reuniões de review, a equipe interage com o Product Owner e o cliente. Fora isso a comunicação entre o cliente e a equipe de desenvolvimento é feita pelo analista de requisitos e o Scrum Master/Gerente de Projetos. Resposta 6: O gestor monitora através da ferramenta JIRA (é uma ferramenta para gerenciar projetos que conecta a equipe do projeto e o trabalho que está sendo realizado). E gráficos como a Sprint Burndown Chart que visam obter a quantidade de tarefas que estão sendo realizadas diariamente, assim como quantidade de tarefas novas inseridas na Sprint, tempo restante para realizar a release e finalizar a Sprint. Resposta 7: Normalmente, as histórias já foram identificadas e estão no product backlog. Na reunião de planning, o cliente junto com o Product Owner define o que será priorizado do backlog para a próxima Sprint e explicadas a equipe do projeto. Resposta 8: 19

A entrega do produto para o cliente é feita por partes, ou seja, é entregue um conjunto de funcionalidades, que foi priorizado e acordado para serem desenvolvidos na Sprint. A entrega é realizada na reunião de review. O objetivo dessa reunião é obter um feedback do cliente. Sendo que nesse momento o cliente aceita, rejeita ou solicita algumas mudanças. Resposta 9: Quando a alteração solicitada está relacionada a uma Sprint que está em desenvolvimento, é realizada uma análise com relação ao impacto que pode ser causado em termo de custo e prazo. Se o impacto for baixo, a alteração pode ser incluída na Sprint. Senão ela é discutida e inserida na próxima Sprint. Resposta 10: Os testes realizados são: unitários, exploratório e funcional automático. Os bugs são evidenciados no JIRA, dentro de cada história testada. Para automatização de testes é utilizado, o Selenium, uma ferramenta que permite gravação/execução de testes de telas. 5.3 Respostas Obtidas - Gerente 2 Nesta seção serão apresentadas as respostas obtidas na entrevista, que ocupa a função de Gerente de Projetos e SCRUM, na qual as respostas serão descritas na ordem do questionário. Resposta 1: Há pelo menos 4 anos a Empresa utiliza o SCRUM como metodologia ágil. A metodologia utilizada anterior ao Scrum era a metodologia tradicional baseada no PMBOK. Resposta 2: Na metodologia tradicional o cliente só via o produto de software no final do desenvolvimento, gerando quase sempre insatisfação na entrega do produto. Sem falar no re-trabalho, gasto de tempo e dinheiro. Com o SCRUM, o cliente participa mais ativamente do desenvolvimento e a equipe do projeto vai entendendo melhor a necessidade do cliente fazendo ajustes já durante as pequenas entregas (Sprints). Assim, o cliente fica satisfeito vendo o produto crescer com as funcionalidades que ele acha mais importante. Resposta 3: Backlog, Product Backlog, Sprint Backlog, Burdown Chart e Reuniões (Daily, Planning, Review e Retrospective). Até o momento, os longos dos anos de uso da metodologia tradicional ainda confundem os gestores e clientes, principalmente, no início do projeto. Pois estes, querem o planejamento de todo o projeto, da mesma forma que a metodologia tradicional faz. 20

Resposta 4: Para projetos pequenos e não complexos, sprints de 2 semanas. Para projetos grandes, Sprints de 3 ou Quatro semanas. Resposta 5: Sim, a equipe fica alocada num mesmo local, as reuniões diárias de 15 minutos são realizadas para comunicar o que cada um concluiu no dia anterior, os impedimentos, os sucessos, as dúvidas e o que irá fazer no dia corrente. O canal é aberto com o cliente e em caso de dúvida de algum requisito, este é sanado imediatamente ligando ou passando um e-mail para o cliente ou para o PO (Product Owner) O cliente também participa nas reuniões de Planejamento e de Entrega de cada Sprint. Resposta 6: O gestor utiliza um software chamado Jira, onde todo Backlog,Sprints, atividades e bugs são cadastrados e a equipe os movimenta diariamente. Além de utilizar um quadro físico para as reuniões diárias. Resposta 7: Tendo a velocidade da equipe definida e o backlog priorizado e pontuado, a equipe do projeto seleciona para a Sprint um somatório de histórias que caiba no quantitativo de pontos que a equipe suporta para cada Sprint. Resposta 8: Quando uma funcionalidade está completa e se o cliente acha que já tem o mínimo para começar a utilizá-lo. E conforme novas funcionalidade vão sendo finalizadas o produto vai sendo incrementado para uso do cliente até que todo produto seja entregue. Resposta 9: São criadas novas histórias no Backlog, o cliente faz a priorização dessas alterações ou novas mudanças e a equipe executa. Entretanto, a equipe informa ao cliente que o número de pontos do Backlog cresceu e que algumas funcionalidades menos importantes podem ficar de fora do produto final, necessitando assim de mais recursos, financeiros ou humanos, para concluir todo escopo. Resposta 10: Testes unitários, automáticos e funcionais são feitos pela equipe de acordo com os critérios de aceitação dos requisitos. E nas reuniões de entrega testes funcionais são feitos com o cliente e ou PO. 21

5.4 Respostas Obtidas - Gerente 3 Nesta seção serão apresentadas as respostas obtidas na entrevista, que ocupa a função de Gerente de Projetos, na qual as respostas serão descritas na ordem do questionário. Resposta 1: Há pelo menos 2 anos a equipe utiliza o SCRUM como metodologia ágil. Não utilizávamos outra metodologia. Resposta 2: Não tinha uma metodologia definida. E com isso o projeto estava sempre atrasado, aumentando o escopo e custo extrapolado. Depois de tantos problemas, resolvemos utilizar o SCRUM. Uma metodologia com uma proposta diferenciada e que estava aumentando a produtividade das equipes e a satifação dos clientes em outras empresas. Resposta 3: Backlog, Product Backlog, Sprint Backlog, Burdown Chart e Reuniões (Daily, Planning, Review e Retrospective). Depois de uma mudança cultural, todas as práticas adotadas foram aceitas. Resposta 4: De acordo com cada projeto, as sprints duram de 2 a 3 semanas. Resposta 5: Sim, existe interação entre a equipe, mas o contato com o cliente acontece às vezes nas reuniões de review e planning que nem sempre está presente. Em caso de dúvida, o contato é feito com o PO (Product Owner). Resposta 6: O gestor controla as histórias pelo Backlog onde as Sprints, atividades e bugs são cadastrados. Além de utilizar um quadro de tarefas. Resposta 7: Com o backlog priorizado e pontuado, de acordo com a velocidade da equipe de desenvolvimento é selecionada para a Sprint a quantidade de histórias. Resposta 8: A entrega do produto é dividida em releases. A cada release concluída o cliente homologa as funcionalidades entregues, assim o software vai sendo incrementado até que todo o produto seja finalizado. 22

Resposta 9: Depois que a Sprint inicia não pode ser incluída mais história. É verificado qual o impacto que pode ser causado no planejamento e é inserida na próxima Sprint. Mas deve ser informado ao cliente que histórias menos importante sairá do backlog, pois sua pontuação está fechado e isso não pode ser alterado. Resposta 10: São feitos testes unitários e funcionais, os resultados e bugs são evidenciados numa planilha excel. Foi possível identificar que a empresa adota parcialmente as práticas do SCRUM, ou seja, ela adota as práticas que são necessárias para gerenciar seus projetos. Relatou-se também que as reuniões de Daily Meeting, Planning, Retrospective e Review, além de alguns artefatos como Scrum Board e Burndown Chart são muito bem aplicadas e atendem às expectativas para controlar e monitorar os projetos. 23

6 ANÁLISE DE DADOS Neste capítulo são analisados os dados referentes ao estudo de caso feito no capítulo anterior e as respostas obtidas devidamente classificadas. P/R Tempo de util. Scrum Utilizava outra metodol ogia. Qual? Quais prática s são utiliza das Quais prátic as que não deram certo Tam. das Sprints para cada projeto Forma s de comun icação Formas de controle das atividade s Processo de solicitação de mudança Tipo de Testes Ger. 1 4 anos Sim. 1, 2, 3, N/A Entre 2 e 1 e 2 JIRA, Analisa Unitári RUP e 4, 5, 6 3 Sprint qual é o o, Análise e 7 semanas Burndow impacto no explora Essencia n Chart custo e tório e l prazo do funcio projeto. nal automá tico Ger. 2 4 anos Sim. 1, 2, 3, N/A 2 1, 2, 3 JIRA e o São criadas Unitári Metodol 4, 5, 6 semanas e 4 quadro novas o, ogia e 7 para de histórias no automá tradicion projetos tarefas backlog e o tico e al pequeno cliente funcio baseada s e 4 prioriza as nal no semanas alterações PMBOK para ou novas projetos mudanças. grandes Ger. 3 2 anos Não 1, 2, 3, N/A 2 a 3 2 e 4 Backlog Quando a Unitári 4, 5, 6 semanas e o Sprint o e e 7 quadro inicia não funcio de pode incluir nal tarefas mais histórias. È incluído na próxima Sprint. 24

* P/R - perguntas e respostas Tabela de Práticas do SCRUM Identificador Práticas 1 Reuniões de Planning 2 Estimativa 3 Retrospectiva 4 Review 5 Product Backlog 6 Quadro de Tarefas SCRUM 7 Daily Meeting Tabela de Formas de comunicação do SCRUM Identificador Formas de comunicação 1 Reunião diária 2 Reunião de review 3 E-mail 4 Reunião de planejamento 5 Reunião de retrospectiva 25

Através da análise de dados, conclui-se que o SCRUM teve uma boa aceitação na empresa. O tempo de utilização do SCRUM na empresa é de 2 a 4 anos, onde em um curto tempo, a aceitação foi bem sucedida. As práticas do SCRUM foram empregadas com sucesso, o tamanho da Sprint para cada projeto varia entre 2 a 3 semanas dependendo do tamanho do projeto. Utiliza reuniões e emails como formas de comunicação entre os envolvidos. O controle das atividades são feitos pelo JIRA, quadro de tarefas e backlog. Para o processo de solicitação de mudança em desenvolvimento são avaliados impactos no custo e prazo do projeto e podem ser criadas novas histórias e priorizadas para a próxima Sprint. Os tipos de testes utilizados são unitários, exploratórios e funcionais. 26

CONCLUSÃO Este trabalho procurou mostrar como utilizar as metodologias ágeis juntamente com as metodologias do PMBOK em gerenciamento de projetos. Foi possível mostrar como é consistente a compatibilidade entre as práticas do PMBOK e as práticas ágeis e a elevar melhoria da qualidade do processo empregado. De acordo com os estudos de casos realizados, a utilização do SCRUM melhorou a produtividade da equipe, aumentou a participação do cliente nas reuniões e, consequentemente um projeto bem sucedido. A implantação do método ágil SCRUM é um trabalho que na maioria das empresas, implica em mudanças culturais e técnicas. Apesar de algumas dificuldades encontradas, verificou-se uma grande melhoria final dos softwares desenvolvidos, bem como a satisfação do time e do cliente final. Com base nos pontos avaliados, conclui-se que o SCRUM é uma metodologia válida para o gerenciamento de projetos de software. O SCRUM promoveu uma mudança de cultura na empresa e criou um ambiente de cooperação, trazendo mais economia de tempo, aumento na produtividade da equipe e satisfação para o cliente. 27

REFERÊNCIAS BIBLIOGRÁFICAS BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em: http://www.agilemanifesto.org. Acesso: 15 jan. 2014. CAETANO, R. Metodologias de desenvolvimento: qual a mais apropriada?. Disponível em: http://computerworld.uol.com.br/gestão/2009/08/05/metodologias-de-desenvolvimento-qual-a-maisadequada/. Acesso: 10 jan. 2014. CHAPIEWSKI, G. Como estamos indo com a adoção de SCRUM na Globo.com Disponível em: http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de-scrum-na-globocom/. Acesso: 25 jan. 2014. CARÇALTO, C. Desenvolvimento iterativo e incremental. Trabalho de Conclusão de Curso, Faculdade de Tecnologia de TAQUARITINGA, São Paulo, Brasil. 2009. Disponível em: http://www.ebah.com.br/content/abaaaasdkag/monografia. Acesso: 25 jan. 2014. FIGUEIREDO A. M. As armadilhas do SCRUM. Disponível em: http://pt.scribd.com/doc/20007366/armadilhas-do-scrum. Acesso em: 07 mar. 2014. ISOTTON NETO, E. Scrumming: ferramenta educacional para ensino de práticas do SCRUM. Dissertação (Mestrado em Informática). Faculdade de Informática. Porto Alegre: Pontifícia Universidade Católica do Rio Grande do Sul, 2008. KOSCIANSKI, A. SOARES. Qualidade de Software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2ed. São Paulo: Novatec Editora, 2007. MARKUS SPRUNCK. Product-Burndown-Charts and Sprint-Burndown-Charts in SCRUM Projects, 15 may, 2012. Disponível em: http:// http://www.javacodegeeks.com/2012/06/product-burndowncharts-and-sprint.html. Acesso: 10 fev. 2014. PEREIRA, P. Entendendo SCRUM para Gerenciar Projetos de Forma Ágil. Disponível em: http://www.cesar.edu.br/docs/paulocaju.pdf. Acesso: 10 mar. 2014. PRESSMAN, R.S. Engenharia de Software. Rio de Janeiro. McGraw-Hill. 2002. PROJECT MANAGEMENT INSTITUTE, Inc. Guia PMBOK. Pennsylvania. PMI Book Service Center. 2008 SCHWABER, K. & BEEDLE, M. Agile Software Development with Scrum,Prentice Hall, 2002. SCHWABER, Ken. e SUTHERLAND, Jeff. GUIA do SCRUM. 2013. Disponível em: https://www.scrum.org/portals/0/documents/scrum%20guides/2013/scrum-guide-portuguese- BR.pdf. Acesso: 05 dez. 2013. 28

SCHWABER, Ken. GUIA do SCRUM. 2009. ScrumAlliance - transforming the word of work. Acesso em: 09 mar. 2014. SCHWABER, Ken. e SUTHERLAND, Jeff. The Definitive Guide to SCRUM: The Rules of the Game. Scrum.org, 2011. Disponível em: http://www.scrum.org/scrumguides Acesso: 10 fev. 2014. SOMMERVILLE, Ian. Engenharia de Software. São Paulo. 6. ed. Pearson Education Companion, 2003. UDO, N.; KOPPENSTEINER. S. Will Agile Change the Way we Manage Software Projects? Agile from a PMBOK Guide Perspective. Projectway, 2003. TAVARES, A. Gerência de Projetos com PMBOK e SCRUM - Um Estudo de Caso. Trabalho de Conclusão de Curso, Faculdade Cenecista Nossa Senhora dos Anjos, Gravataí, Brasil. 2008. 29