METODOLOGIA ÁGIL FRAMEWORK SCRUM EM GERENCIAMENTO DE PROJETOS DE SOFTWARE.

Transcrição

1 METODOLOGIA ÁGIL FRAMEWORK SCRUM EM GERENCIAMENTO DE PROJETOS DE SOFTWARE. Jaqueline Martins¹ Discente do Curso de Pós-Graduação em MBA em Gerenciamento de Projetos do Centro Universitário de Lins Unilins, Lins-SP, Brasil Renato Marcelo Teixeira de Menezes² Docente do Curso de Pós-Graduação em MBA em Gerenciamento de Projetos do Centro Universitário de Lins Unilins, Lins-SP, Brasil Resumo O presente artigo discute o uso de metodologias ágeis em gerenciamento de projetos. Elas nasceram no berço do desenvolvimento de software e, atualmente, são usadas, em sua maioria, na área de Tecnologia da Informação. Com foco na satisfação do cliente, as metodologias ágeis são caracterizadas pela flexibilidade às mudanças e possuem uma forma alternativa de gerenciamento em relação às metodologias tradicionais. Por meio de uma pesquisa de revisão bibliográfica, o objetivo do artigo é mostrar os benefícios que essas metodologias oferecem à gestão de projetos de software, apresentar o framework 1 ágil Scrum 2, bem como detalhar o seu funcionamento e realizar uma análise comparativa entre os métodos ágeis e tradicionais. Palavras-chave: Metodologias Ágeis. Tecnologia da Informação. Flexibilidade. Scrum. Abstract This article discuss the use of agile methodologies in project management. They have emerged in the cradle of software development and have been currently used, for 1 Estrutura 2 Framework Ágil the most part, in the Information Technology field. Focusing on customer satisfaction, agile methodologies are characterized by flexibility to change and by having an alternative management form compared to the traditional methodologies. Through a bibliographic review research, the objective of the article is to show the benefits that these methodologies offer to the management of software projects, to present the agile Scrum framework, as well as to detail its operation and perform a comparative analysis between agile and Traditional. Keywords: Agile methodologies. Information Technology. Flexibility. Scrum. 1 Introdução Atualmente, muitas organizações estão trabalhando com projetos e estes necessitam ser gerenciados para se obter êxito. Segundo o PMBOK 3, Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. A natureza temporária dos projetos indica que eles têm um início e um término definidos. O término é alcançado quando os objetivos do projeto são atingidos ou quando o projeto é 3 Guia com conjunto de práticas para gestão de projetos, organizado pelo instituto PMI e considerado a base do conhecimento sobre gestão de projetos. 1

2 encerrado porque os seus objetivos não serão ou não podem ser alcançados, ou quando a necessidade do projeto deixar de existir. (PMBOK, 2013, p. 03). Diferentemente das operações, que são contínuas e repetitivas, os projetos são temporários. Resumidamente, tem início e fim, e dentro desse período existem as fases que necessitam ser gerenciadas. Gerenciamento de projetos é a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos. (PMBOK, 2013, p. 05). Para o desenvolvimento de um projeto é de suma importância a adoção de uma metodologia, que nada mais é que um conjunto de regras a ser seguido visando a sua conclusão com sucesso. Visto que os projetos são temporários em natureza, seu sucesso deve ser medido em termos da sua conclusão dentro das restrições de escopo, tempo, custo, qualidade, recursos e risco. (PMBOK, 2013, p.35). Embora exista todo um planejamento, monitoramento e controle, mudanças podem ocorrer e os Gerentes de Projetos, junto com a equipe, devem estar preparados para contornar esse tipo de imprevisto da melhor maneira possível, evitando que impactem de forma negativa, principalmente, no orçamento do projeto. E as metodologias ágeis são caracterizadas pela adaptação a essas possíveis mudanças. O Scrum é um framework de desenvolvimento ágil que busca melhorias no desenvolvimento de projetos, especialmente em projetos de software onde é utilizado em sua maioria buscando a satisfação do cliente. Mas, como funciona o Scrum? Por que utilizar metodologias ágeis em projetos de desenvolvimento de software? Quais são as vantagens em relação às metodologias tradicionais? É possível associar o framework às boas práticas citadas pelo PMBOK? Diante dos questionamentos acima, por meio de uma pesquisa de revisão bibliográfica, o objetivo do artigo é mostrar os benefícios que essas metodologias oferecem à gestão de projetos de software, apresentar o framework ágil Scrum, bem como detalhar o seu funcionamento e realizar uma análise comparativa entre os métodos ágeis e tradicionais. Os conceitos apresentados a seguir são fundamentais para o entendimento do contexto do artigo, pois possuem um elo, visto que softwares são considerados produtos, desenvolvidos em forma de projetos, e que a engenharia de software consiste na aplicação de processos que garantam qualidade ao software. Ainda, o conceito de metodologia tradicional é importante para entender porque surgiram as metodologias e frameworks de desenvolvimento ágil para serem aplicadas em gerenciamento de projetos. 1.1 Software e engenharia de software Segundo Pressman, software é o produto que profissionais de software desenvolvem e ao qual dão suporte ao longo prazo. Abrange programas executáveis em um computador de qualquer porte ou arquitetura, conteúdos (apresentados à medida que os programas são executados) e informações. A engenharia de software, por sua vez, abrange um processo, um conjunto de práticas e ferramentas que possibilitam aos profissionais desenvolverem software de alta qualidade. (PRESSMAN, 2011, p.29). 1.2 Metodologias tradicionais de desenvolvimento de software As metodologias tradicionais de desenvolvimento de software, ou metodologias clássicas, são caracterizadas pela documentação abrangente e pela ordem e disciplina no decorrer do desenvolvimento, garantindo um controle excessivo dos processos. Um tipo de metodologia tradicional ou clássica é o modelo cascata. Segundo Paige Baltzan, em seu livro Tecnologia Orientada para Gestão, a principal característica do modelo é a divisão do projeto em etapas que seguem uma sequência linear, onde a próxima se inicia somente após o termino da anterior. As metodologias tradicionais são consideradas rígidas e burocráticas. 2

3 1.3 História do manifesto ágil De acordo com o site agilemanifesto.org, o Manifesto Ágil surgiu nos EUA, em fevereiro de 2001, a partir de uma reunião realizada com dezessete pessoas, especialistas em processos de desenvolvimento de softwares, cada qual com suas peculiaridades (representantes de Extreme Programming 4, Scrum, DSDM 5, Adaptive Software Development 6, entre outros), que decidiram se reunirem em busca de melhorias no desempenho dos projetos. Buscavam reagirem contra métodos pesados - assim caracterizados por possuírem uma regulamentação rígida - usados no modelo cascata para desenvolvimento de software (modelo sequencial), visto como burocrático e lento comparado à forma com que os engenheiros de software desempenhavam o trabalho. Conforme consta no site agilemanifesto.org, a reunião foi simbólica e deu origem a Agile Alliance, ou seja, Aliança Ágil, composta pelo grupo de pensadores que estabeleceu o Manifesto Ágil para desenvolvimento de softwares, com base em quatro valores, descritos no site:» Indivíduos e interações entre eles mais que processos e ferramentas.» Software em funcionamento mais que documentação abrangente.» Colaboração com o cliente mais que negociação de contratos.» Responder às mudanças mais que seguir um plano. Embora cada envolvido tivesse suas particularidades, todos concordavam, com base em suas prévias experiências, que quando os projetos eram bem-sucedidos um conjunto composto por doze princípios parecia ter sido cumprido:» Foco no cliente;» Flexibilidade às mudanças;» Entrega em menor tempo;» Interação;» Indivíduos motivados;» Conversa face a face;» Software funcionando;» Desenvolvimento sustentável;» Excelência técnica e bom design;» Simplicidade;» Auto-organização;» Reflexão em intervalos regulares. Compreender os valores destes doze princípios, e aplicá-los em projetos, pode trazer inúmeras melhorias. 1.4 Scrum Em virtude do Manifesto Ágil, outras metodologias e frameworks alternativos foram ganhando espaço, entre eles: o Scrum. Scrum é um framework de desenvolvimento ágil que busca melhorias no desenvolvimento de projetos, especialmente em projetos de software onde é utilizado em sua maioria buscando a satisfação do cliente. Segundo o Guia do Scrum, desenvolvido por Ken Schwaber e Jeff Sutherland: Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. Três pilares apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação (SCHWABER; SUTHERLAND, 2013, p.04). É composto por um time, denominado Scrum Team 7, formado por três integrantes principais: Product Owner 8, Scrum Master 9 e Development Team 10. E por artefatos e eventos importantes, entre os principais: Product Backlog 11, 4 Metodologia ágil de desenvolvimento de software 5 Metodologia ágil de desenvolvimento de software 6 Técnica de desenvolvimento de software adaptativo 7 Equipe Scrum 8 Dono do produto 9 Líder Scrum 10 Equipe de desenvolvimento 11 Backlog (lista) do produto 3

4 Planning Sprint 12, Sprint 13, Daily Scrum 14, Sprint Review 15 e Sprint Retrospective 16, que serão detalhados na dinâmica do processo do framework adiante. 1.5 Metodologias tradicionais e metodologias ágeis As metodologias tradicionais, mesmo com o surgimento das metodologias ágeis, ainda estão presentes na gestão de projetos de desenvolvimento de software, porém já não são mais tão adequadas ao atual ambiente de negócios, onde os clientes querem retorno do benefício o mais rápido possível. De acordo com Paige Baltzan, em seu livro Tecnologia Orientada para Gestão, a metodologia cascata, também conhecida como tradicional, consiste em uma sequência de fases, onde o resultado de cada uma delas se torna o subsídio para a próxima. (BALTZAN, 2016, p. 280) São consideradas metodologias pesadas, marcantes por serem divididas em fases, onde cada fase concluída deve ser documentada, gerando um marco de conclusão. Esse modelo se inicia com a especificação de requisitos pelo cliente, planejamento, análise, design, desenvolvimento, teste, implementação e finaliza com a manutenção. Figura1 Modelo Cascata/Tradicional Fonte: Paige Baltzan - (2016) Baltzan destaca os problemas relacionados à metodologia cascata (tradicional). A metodologia em cascata é problemática na medida em que presume que os usuários podem especificar todos os requisitos de negócio com antecedência. Definir a infraestrutura adequada que seja flexível, escalável e confiável é um desafio. A solução final da infraestrutura de TI deve responder não só às necessidades atuais, mas também às futuras, em termos de tempo, custo, viabilidade e flexibilidade. A visão é inevitavelmente limitada à frente da cascata. (BALTZAN, 2016, p. 281) O método tradicional possui processos extremamente organizados e o escopo, uma vez definido, não é recomendado que se altere. Os processos são muito bem disciplinados. Uma das grandes vantagens da utilização desses métodos é a organização em demasia e etapas bem documentadas, uma vez que o projeto possua requisitos fixos. E a desvantagem é que não é flexível às mudanças e o cliente só usufrui do produto ao final da sequência do modelo cascata. Hoje em dia, o trabalho de software tem um ritmo acelerado e está sujeito a uma cadeia de mudanças intermináveis (em características, funções e conteúdo de informações). O modelo cascata é frequentemente inapropriado para tal trabalho. Entretanto, ele pode servir como um modelo de processo útil em situações nas quais os requisitos são fixos e o trabalho deve ser realizado até a sua finalização de forma linear. (PRESSMAN, 2011, p. 61). Os métodos tradicionais funcionam, mas é essencial que o projeto esteja completamente planejado, com todos os requisitos enfatizados e não variáveis por um cliente que não exija utilizar o software antes de estar completamente pronto. Os conceitos existentes relacionados ao desenvolvimento ágil de software foram motivados por uma reação adversa aos chamados métodos pesados de desenvolvimento de software, caracterizados por um formalismo muito grande nas 12 Planejamento do ciclo 13 Ciclo (período) 14 Scrum diário 15 Revisão do ciclo 16 Retrospectiva do ciclo 4

5 documentações e regulamentações, sendo, na sua maioria, micro gerenciados pelo tradicional e burocrático modelo em cascata. A partir desta reflexão, novos frameworks para processos de desenvolvimento de software começaram a surgir, sendo conhecidos inicialmente pela denominação métodos leves ou Lightweight Methods. (SBROCO, 2012, p.87) Segundo PMBOK, Os ciclos de vida adaptativos (também conhecidos como direcionados à mudança ou utilizadores de métodos ágeis) são projetados para reagir a altos níveis de mudança e envolvimento contínuo das partes interessadas. (PMBOK, 2013, p.46). As metodologias ágeis utilizam um processo iterativo e incremental e, por sua vez, são adaptativas às mudanças que podem ocorrer. Iterativo corresponde à repetição, reiteração, frequentativo. O incremental vem exatamente do fato que a cada entrega (final de fase) o produto ganha mais um pedaço e vai crescendo e sendo incrementado com mais valor, até que se torne um produto completo e o projeto seja encerrado. (CRUZ, 2013, p. 17). O próximo tópico detalhará o funcionamento do framework de desenvolvimento ágil Scrum, onde será possível perceber a iteratividade e incremento do processo, o que facilita as possíveis mudanças e agrega valor para o cliente. colaborar com a equipe, ativamente, para garantir o sucesso do projeto;» Scrum Master: Assemelha-se a um coach 17, um facilitador e um líder (e não à figura do gerente) que ajuda os indivíduos envolvidos a entender e praticar os valores e princípios do framework. Está diretamente ligado à produtividade da equipe, poupando-a das interferências externas e auxiliando-a na resolução de problemas.» Development Team: São as pessoas que, de fato, irão colocar a mão na massa e construir o projeto, os responsáveis pela concepção do produto desejado. Na visão da metodologia tradicional de desenvolvimento corresponde aos analistas, administradores de bancos de dados, programadores, etc. Essa equipe deve ser auto-organizada para definir a melhor forma de desenvolver o trabalho, com foco na meta estabelecida pelo Product Owner. Figura 2. Scrum Team 1.6 Detalhamento do framework Scrum Com base no livro escrito por Kenneth S. Rubin Essential Scrum. A Practical Guide to the Most Popular Agile Process, o framework é formado por integrantes que compõem o Scrum Team e que desempenham, basicamente, os seguintes papéis:» Product Owner: é o proprietário do produto/serviço, o ponto central, e tem poder de liderança sob o que será desenvolvido. É a pessoa responsável por decidir os recursos que serão utilizados e as funcionalidades, bem como a ordem que serão executadas, definindo uma priorização das tarefas e, ainda, deve Fonte: Kenneth S. Rubin (2012) 1.7 Dinâmica do Processo Tudo começa a partir da visão do produto, e o responsável por provê-la é o Product Owner através da especificação dos requisitos desejados. Em seguida, essa visão é desmembrada em funcionalidades, dando origem ao artefato 17 Profissional qualificado e que utiliza metodologias, técnicas e ferramentas do coaching para o benefício de uma empresa ou de um indivíduo, quer na sua área pessoal ou profissional. 5

6 Product Backlog - que nada mais é que uma lista de funcionalidades necessárias para o desenvolvimento do projeto. As funcionalidades desmembradas devem ser ordenadas por prioridade definida pelo Product Owner, juntamente com a equipe Scrum e as partes interessadas. Figura 3. Product Backlog aleatoriamente e seguem a ordem de prioridades definida pelo Product Owner, porém, conforme os incrementos de produto são entregues, poderá haver a necessidade de mudanças e é neste instante que é possível observar a flexibilidade do Scrum diante delas. As mudanças, com suas devidas prioridades, também deverão ser inseridas no Product Backlog. A repetição do processo ocorrerá até que o produto final esteja completamente desenvolvido, incluindo as mudanças que foram solicitadas no decorrer do desenvolvimento do projeto. Figura 4. Sprints Fonte: Kenneth S. Rubin (2012) Uma das principais características do Scrum é a divisão do processo de desenvolvimento do projeto em ciclos, períodos de tempo denominados Sprints, onde algumas funcionalidades do Product Backlog serão construídas e entregues. Os Sprints devem ser planejados de acordo com a complexidade e a capacidade da equipe em relação a execução da funcionalidade do respectivo período, porém devem obedecer a uma regra do Scrum chamada Time-boxed, que corresponde a evento de duração fixa, ou seja, o ideal é que os Sprints possuam a mesma duração, que variam entre duas a quatro semanas. Ao término de cada Sprint espera-se uma entrega/incremento do produto final, se tratando de um software, parte dele deverá ser entregue funcionando ao usuário. O trabalho realizado em cada Sprint deve criar algo de valor tangível para o cliente ou usuário. (RUBIN, 2012, p. 20). Antes de iniciar cada Sprint é realizado o Planning Sprint, uma reunião onde é definida a quantidade de funcionalidades para o ciclo. É importante lembrar que as funcionalidades não são implementadas 18 Reunião em pé. Fonte: Mindmaster (2014) No processo Scrum são realizadas, diariamente, reuniões com o intuito de saber o andamento do projeto como um todo, onde os membros da equipe podem visualizar, de modo geral, a progressão do trabalho do Sprint. Estas reuniões são chamadas de Daily Scrum, possuem curta duração, com tempo de mais ou menos quinze minutos, e em decorrência dessa característica também é chamada de Stand-up Meeting 18, em virtude de uma recomendação para que os participantes da reunião fiquem em pé, objetivando uma reunião rápida e objetiva. Os interrogados respondem a três perguntas básicas feitas pelo Scrum Master:» O que fez ontem?» O que fará hoje?» Existe algum impedimento para realizar a tarefa? 6

7 Um Scrum diário, no entanto, pode ser útil para comunicar o status do Sprint entre os membros da equipe de desenvolvimento. Principalmente, o Scrum diário é uma inspeção, sincronização e atividade de planejamento diário adaptativo que ajuda a equipe fazer seu trabalho melhor. (RUBIN, 2012, p. 24). Figura 5. Daily Scrum Outra ferramenta muito útil, que traz benefícios ao projeto em virtude da transparência que apresenta, é o Kanban Board. A ideia é apresentar o fluxo do trabalho e pode ser feito de diversas formas, com softwares específicos ou em uma simples lousa onde serão colados post-its 20, representando as funcionalidades que fazem parte do Product Backlog. Figura 7. Kanban Board Fonte: Mindmaster (2014) Existe uma ferramenta útil chamada Burndown Chart 19, muito utilizada em projetos gerenciados por métodos ágeis. Trata-se de um gráfico que relaciona o tempo com o esforço realizado, sendo possível perceber o adiantamento ou atraso em relação às estimativas, permitindo, dessa forma, medir o progresso do trabalho e saber como caminha o Sprint. O gráfico apresenta uma linha ideal, tomada com referência, e outra que representa o que foi realizado. O ideal é que todos os esforços sejam realizados ao final do tempo para se obter sucesso. Figura 6. Burndown Chart Fonte: Dbbest (2014) Fonte: Guia do Excel (2016) Ao final do Sprint existem, ainda, duas atividades que são extremamente fundamentais: Sprint Review e Sprint Retrospective. A primeira tem o objetivo de validar o que está sendo construído no projeto, o produto/serviço, e verificar se está sendo feito de acordo com o planejamento inicial. É neste momento que é apresentado o que foi realizado na funcionalidade do Sprint e, também, neste momento podem surgir mudanças e o Product Backlog ser alterado. É importante ressaltar que as mudanças também devem seguir um Grooming 21 ao serem inseridas no Product Backlog. A revisão do Sprint representa, portanto, uma oportunidade programada para inspecionar e adaptar o produto. (RUBIN, 2012, p.26). A segunda, por sua vez, tem o objetivo de verificar a necessidade de adaptações no processo, além dos pontos positivos e os negativos que precisam de melhorias. 19 Gráfico de Burndown 20 Bloco de notas composto por pequenas folhas de papel adesivo. 21 Atividade de criar e refinar os itens do product backlog, estimando o tamanho e esforço de cada item. 7

8 Depois que a retrospectiva de Sprint estiver concluída, todo o ciclo é repetido novamente - começando com a próxima sessão de planejamento de Sprint, realizada para determinar o conjunto de trabalho de maior valor atual para a equipe focar. (RUBIN, 2012, p.28). A figura a seguir representa a dinâmica do processo Scrum, envolvendo os artefatos e eventos até chegar a conclusão/incremento do produto ou funcionalidade. Figura 8. Processo Scrum Fonte: Desenvolvimento ágil (2013/2014) (Irena Balin), PMBOK e Gerenciamento de Projetos (Márcio d'ávila), Scrum: A Metodologia Ágil Explicada de forma Definitiva (Denisson Vieira) e os livros Tecnologia Orientada Para Gestão (Paige Baltzan), SCRUM e PMBOK unidos no Gerenciamento de Projetos (Fábio Cruz), Engenharia de software. Uma abordagem professional (Roger Pressman), Essential Scrum. A Practical Guide to the Most Popular Agile Process (Kenneth S. Rubin), Metodologias Ágeis. Engenharia de Software sob Medida (José Henrique Teixeira de Carvalho Sbrocco e Paulo Cesar de Macedo), Guia do Scrum. Um guia definitivo para o Scrum: As regras do jogo (Ken Schwaber e Jeff Sutherland), Practical Risk Assessment for Project Management (Stephen Grey) e o famoso PMBOK. Será desenvolvido por meio de uma pesquisa de revisão bibliográfica nos materiais citados, onde será possível analisar e comparar as metodologias, com foco no ambiente de desenvolvimento de projetos de software. Ao final do artigo serão apresentadas as conclusões com fundamento nas questões citadas no tópico da introdução. A pesquisa por metodologia de revisão bibliográfica é realizada através de publicações anteriores, visando a obtenção de um contexto para a análise e discussão do tema. 2 Materiais e Métodos O trabalho consiste em um levantamento teórico e bibliográfico e será elaborado a partir de materiais já publicados que discutam sobre metodologias de desenvolvimento de softwares, entre eles o conteúdo publicado nos sites desenvolvimentoagil.com.br e agilemanifesto.org, os artigos Desenvolvimento de Software: Processos Ágeis ou Tradicionais? Uma visão crítica e Metodologias Ágeis para o Desenvolvimento de Softwares: Aplicação e o Uso da Metodologia Scrum em Contraste ao Modelo Tradicional de Gerenciamento de Projetos, disponíveis nos sites enacomp.com.br e revistas.ung.br, respectivamente, e ainda, os trabalhos Agile Software Development 3 Resultados e discussão A partir das informações apresentadas, torna-se possível discutir qual a metodologia ideal para ser utilizada em projetos de desenvolvimento de software. Para isso, será exposto um breve exemplo com o uso de ambas metodologias, a tradicional e a ágil (aplicada com o uso do framework Scrum, para análise comparativa entre elas. 3.1 Por que utilizar o Scrum no desenvolvimento de projetos de software? Porque, dificilmente, tudo o que foi estimado no início do projeto ocorrerá 8

9 conforme planejado, embora o ideal não seja este. Mas alguns imprevistos podem trazer riscos para o projeto de acordo com o livro Practical Risk Assessment for Project Management :» Gastos que superam o orçamento, em decorrência de prioridades que não foram previstas inicialmente, mas que são importantes para o projeto;» Consumo de tempo que supera o cronograma, ao passo em que mais funcionalidades precisam ser implementadas ou alguma das existentes necessite ser alterada, o que consequentemente gera atraso na entrega do projeto;» Funcionalidades mal elaboradas que podem acontecer por diversos motivos, desde o distanciamento entre os Stakeholders 22 até problemas internos entre a equipe de desenvolvimento;» Qualidade reduzida dos produtos finais. Portanto, todos estes riscos podem gerar perda de contratos futuros. E controlar estes pontos, que são inerentes em quaisquer projetos, é fundamental para garantir que a entrega seja realizada dentro do prazo e orçamento previstos. Veremos que, com base na dinâmica do Scrum, citada no referencial teórico deste trabalho, as mudanças que surgirem no decorrer do desenvolvimento dos projetos podem ser solucionadas mais facilmente em decorrência dos artefatos e eventos que compõem o framework. Mas, como? Imaginemos um projeto de software, onde o usuário solicite um software básico para uma loja, que deverá conter uma tela de cadastro de clientes e de produtos e uma tela de vendas. O escopo é definido e a equipe começa a desenvolver. No método tradicional, a equipe iria desenvolver conforme solicitado e entregaria o produto final, o software completo, com todas as funcionalidades solicitadas implementadas, em perfeito funcionamento e totalmente documentado. Mas, vamos supor que o usuário, ao começar a usar o software, note que seria ideal uma tela para cadastro de fornecedores também, além das outras que já tinham sido implementadas. Estamos, então, diante de um imprevisto que irá impactar no custo e no tempo do projeto, pois a funcionalidade para cadastrar fornecedores não foi prevista no início do planejamento. Este tipo de imprevisto pode ocorrer, principalmente, por conta da falta de comunicação. Agora, imaginemos o projeto sendo desenvolvido utilizando o framework ágil Scrum. O escopo foi definido com as mesmas funcionalidades requisitadas. Tais funcionalidades irão compor o Product Backlog tela de cadastro de clientes, tela de cadastro de produtos e tela de vendas. Os Sprints serão definidos e cada um irá conter a sua respectiva funcionalidade, conforme planejado no Planning Sprint. Ao término de um Sprint, a funcionalidade implementada, depois de testada e funcionando corretamente, desde que não dependa de uma outra, já poderá ser entregue ao cliente, o que gerará ao mesmo uma certa satisfação em poder utilizar o software, mesmo que não esteja totalmente pronto. As reuniões diárias possibilitarão a descoberta da nova funcionalidade cadastro de fornecedores antes do término do sistema completo, o que torna possível incluí-la no Product Backlog, em ordem prioritária, inclusive. No Sprint Review poderemos validar se o produto foi desenvolvido conforme planejado e adaptá-lo caso necessário neste exemplo, adaptar a nova funcionalidade de cadastro de fornecedores, solicitada pelo cliente - pois essa revisão é feita para inspeção e adaptação. No Sprint Retrospective poderemos observar os pontos negativos e positivos do desenvolvimento do Sprint, o que permite que no próximo ciclo se aproveite o que foi bom e evite erros. 22 Parte interessada ou interveniente. 9

10 Com o uso do gráfico de Burndown Chart é possível ver o que foi realizado em relação ao tempo estimado, tornando visível o progresso do projeto. Com o Kanban Board, por exemplo, poderemos visualizar o que está aguardando, o que está em andamento e o que foi concluído. Resumindo, no Scrum, com a organização das funcionalidades por prioridades, as entregas parciais, reuniões diárias, entre outros eventos, é possível garantir maior sucesso ao projeto e evitar que mudanças ocorram em momentos que são prejudiciais ao projeto, pois quanto antes prever o que precisa ser incluso ou alterado, menos impacto negativo será causado. Este foi um simples exemplo de desenvolvimento de um software em que é possível observar os benefícios que os métodos ágeis trazem para o gerenciamento de projetos, principalmente, quando não existe um escopo bem definido e os requisitos são imprevisíveis. O Scrum é bem-vindo para aumentar a taxa de sucesso dos projetos, pois as estratégias, os processos de negócio e os requisitos podem mudar, mesmo depois do escopo definido, porque muitas vezes não há boa comunicação ou, ainda, o cliente não sabe exatamente o que deseja. Diferentemente dos métodos tradicionais que priorizavam a tripla restrição - escopo, prazo e custo - o Scrum prioriza, também, a qualidade do projeto e o valor agregado. 3.2 Análise comparativa entre métodos Diversos fatores influenciam na escolha da metodologia a ser utilizada no desenvolvimento de projetos, portanto não existe uma regra que defina qual é a melhor. Tanto os métodos tradicionais quanto os métodos ágeis possuem benefícios e a sua aplicabilidade varia de acordo com cada projeto e empresa, levando em consideração a natureza e cultura organizacional, respectivamente. O ideal é conhecer cada um deles e entender as suas principais diferenças. A partir daí deve-se analisar o projeto para ver qual metodologia melhor se enquadra. O quadro a seguir representa uma análise comparativa entre ambos, com ênfase nas principais diferenças que puderam ser observadas no decorrer deste trabalho e referenciados. Figura 9. Quadro com análise comparativa simplificada entre metodologias Fonte: Elaborado pela autora, Associação das metodologias ágeis com as boas práticas do PMBOK O PMBOK contém um conjunto de processos, ferramentas e técnicas, considerado um guia de boas práticas para gerenciamento de projetos. É composto por grupos de processos (iniciação; planejamento; execução; monitoramento e controle; e encerramento) que abrangem diversas áreas de conhecimento (integração; escopo; tempo; custos; qualidade; recursos humanos; comunicações; riscos; aquisições; e partes interessadas) Uma área de conhecimento representa um conjunto completo de conceitos, termos e atividades que compõem um campo profissional, campo de gerenciamento de projetos ou uma área de especialização. Essas dez áreas de conhecimento são usadas na maior parte dos projetos, na maioria das vezes. As equipes dos projetos utilizam essas e outras áreas de conhecimento, de modo apropriado, 10

11 para os seus projetos específicos. (PMBOK, 2013, p. 60). Figura 10. Áreas de Conhecimento. Em outras palavras, pode-se dizer que, ao rodar o Scrum, é possível sentir exatamente onde os processos do Guia PMBOK podem ser encaixados na sua rotina. (CRUZ, 2013, p. 45) 4 Conclusão Fonte: Mhavila (2015) O Guia PMBOK sugere tudo que pode ser realizado para gerenciar um projeto do início ao fim, mas não diz como isso pode ser feito - e em algumas vezes não é muito claro na definição dos momentos ideais para cada aplicação. (CRUZ, 2013, p. 43) Diante deste conceito, Fabio Cruz, em seu livro SCRUM e PMBOK unidos no gerenciamento de projetos, diz que é perceptível que o Guia contém inúmeros processos, com uma imensidão de detalhes praticamente completos quanto ao conteúdo gerencial, porém não define uma metodologia exata para a aplicabilidade das boas práticas. Surge, então, a possibilidade de associar as boas práticas do PMBOK ao framework ágil Scrum. O Scrum, diferentemente do Guia PMBOK, não é abrangente e extenso, mas contém um conjunto de regras sequenciais bem definidas para aplicar em gerenciamento de projetos. O modelo menos complexo e mais compacto que o PMBOK permite utilizar o Scrum como uma perspectiva que traz visibilidade ao projeto, o que torna mais fácil fazer o uso das boas práticas e entender como e quando utilizar os processos. Diante do levantamento teórico e bibliográfico realizado neste artigo, foi discutido o uso de metodologias ágeis para gerenciamento de projetos de software, não deixando de citar as metodologias tradicionais, para que fossem comparadas. O mercado de software é amplo, pois os sistemas de informações estão sendo automatizados, ou seja, os softwares estão, cada vez mais, realizando tarefas humanas de maneira eficiente. O objetivo deste trabalho era mostrar os benefícios que as metodologias ágeis oferecem à gestão de projetos de software, apresentar o framework ágil Scrum, bem como detalhar o seu funcionamento e realizar uma análise comparativa entre os métodos, Para atende-lo, foram apresentados, inicialmente, os conceitos básicos de software e engenharia de software, metodologias tradicionais, a história do manifesto ágil para que ficassem explícitos os objetivos e a origem das metodologias e frameworks ágeis. No cenário contemporâneo de tecnologia da informação os clientes exigem que os trabalhos solicitados sejam realizados com qualidade e em prazos cada vez mais curtos, e as empresas que se encarregarão do desenvolvimento do projeto devem estar preparadas para atender a esses requisitos, para a garantia de contratos futuros e, consequentemente, lucratividade. Portanto é fundamental adotar modelos de gerenciamento compatíveis com este contexto, que garantam a satisfação dos clientes. A garantia da qualidade de software é uma atividade que deve ser bem planejada e, nos métodos tradicionais (divididos em fases), deve cobrir todas as fases, desde análise até implantação do produto, por isso é muito difícil de ser obter essa garantia, visto que a falha em uma etapa pode prejudicar as demais. 11

12 Com o uso do Scrum, onde há a valorização de indivíduos e interações entre eles mais que processos e ferramentas, software em funcionamento mais que documentação abrangente, colaboração com o cliente mais que negociação de contratos e responder às mudanças mais que seguir um plano, o controle da qualidade se torna mais eficaz, pois a iteratividade do framework previne a ocorrência de riscos, detectando-os no começo e evitando que se proliferem para as demais etapas do processo e impactem negativamente. O detalhamento do framework ágil Scrum, com os principais conceitos, papéis, eventos e artefatos, tornou possível entender, na teoria, sobre a sua aplicabilidade, e com posterior exemplo de um projeto de desenvolvimento de um software simples, foi notório o benefício de seu uso em relação aos métodos tradicionais, pois o envolvimento dos participantes, a transparência, a inspeção contínua e a flexibilidade agregam valor ao projeto. Em virtude das exigências do mercado de software, onde as condições mudam com frequência, a aplicação do Scrum é indicada, visto que a metodologia ágil foca na satisfação do cliente, em entregas parciais (onde o software pode ser utilizado mesmo incompleto), são adaptativas às mudanças, as equipes são auto-organizadas e há mais comunicação entre os envolvidos. O artigo apresentou o framework, seus benefícios, simples análise comparativa entre os métodos, destacando as principais características de cada um, e a possível associação dos métodos ágeis às práticas do PMBOK. Com base nos questionamentos apresentados na introdução, é possível concluir que o uso de métodos ágeis é indicado para o gerenciamento de projetos imprevisíveis e complexos, como os de software, e o framework Scrum apresenta vantagens se comparado a métodos tracionais, neste cenário, em decorrência da flexibilidade em relação às mudanças, que adequa o produto às necessidades do cliente, e das entregas contínuas, que agregam valor, entre outras vantagens, uma vez que deixa de focar nos processos e ferramentas e direciona o foco aos indivíduos e interações entre eles e, ainda, pode ser associado ao PMBOK, visto que o guia não cita como fazer e sim as boas práticas que podemos aplicar na gestão de projetos. A respeito da escolha da metodologia ideal, o que deve ficar claro é que, nesse contexto de desenvolvimento de software, é perfeitamente cabível o uso do Scrum, porém o uso dos métodos tradicionais não é descartado. A escolha da metodologia varia de acordo com a natureza do projeto e cultura organizacional da empresa, portanto os métodos devem ser analisados para ver qual melhor se enquadra para atender às necessidades do cliente. É sugerido como pesquisas futuras a aplicação do uso do SCRUM em outras áreas, além da Tecnologia da Informação no desenvolvimento de softwares, visto que a sua aplicabilidade é indicada para projetos imprevisíveis. 5 Referências ARTIGO acadêmico: Desenvolvimento de Software: Processos Ágeis ou Tradicionais? Uma visão crítica. Disponível em: < completos/enacomp2010_4.pdf>. Acesso em: 03 nov ARTIGO acadêmico: Metodologias Ágeis para o Desenvolvimento de Softwares: Aplicação e o Uso da Metodologia Scrum em Contraste ao Modelo Tradicional de Gerenciamento de Projetos. Disponível em: < plicada/article/viewfile/1408/1194>. Acesso em: 03 nov BALIN, I. Agile Software Development. Disponível em: < Acesso em 06 nov BALTZAN, P. Tecnologia Orientada para Gestão, 6ed. McGraw Hill Brasil,

13 CRUZ, F. SCRUM e PMBOK unidos no Gerenciamento de Projetos. Brasport, D ÁVILA, M. PMBOK e Gerenciamento de Projetos. Disponível em: < mbok.html>. Acesso em 05 nov Desenvolvimento Ágil. Disponível em:< scrum/>. Acesso em 29 out SCHWABER K.; SUTHERLAND J. Guia do Scrum. Um guia definitivo para o Scrum: As regras do jogo, Disponível em: < e/v1/scrum-guide-portuguese-br.pdf>. Acesso em 20 nov VIEIRA, D. Scrum: A Metodologia Ágil Explicada de forma Definitiva. Mindmaster Educação Profissional. Disponível em: < Acesso em 05 nov GREY, S. Practical Risk Assessment for Project Management, Nova York: John Wiley and Sons, Manifesto Ágil. Disponível em: < Acesso em: 20 out PMBOK 5ª ED. Project Management Institute PRESSMAN, R. S. Engenharia de software. Uma abordagem profissional, 7ª ed. AMGH Editora Ltda., RIEPER, M. Quadro SCRUM Quadro de tarefas KANBAN Excel. Disponível em: < Acesso em 06 nov RUBIN, K., S. Essential Scrum. A Practical Guide to the Most Popular Agile Process. Addison-Wesley, 2012 SBROCCO, J., H., T., C.; MACEDO, P., C. Metodologias Ágeis. Engenharia de Software sob Medida, 1ª ed., Érica,