METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM:
ESTUDO DE REVISÃO
Bruno Edgar Fuhr
1Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um
produto que tenha ao mesmo tempo qualidade e agilidade de execução. Hoje em dia, o cliente do software não aceita esperar um longo período para receber o seu produto, coisa que era comum no passado. Com isso, é clara a necessidade da adoção de uma metodologia de gerenciamento de projetos moderna e ágil, que possa responder às frequentes mudanças de requisitos, de forma rápida e funcional. Este artigo tem como objetivo apresentar a metodologia Scrum como uma alternativa a outras estratégias de gerenciamento de projetos existentes no mercado, mostrando suas características principais e o seu processo de funcionamento.
Palavras-chave: Gerenciamento de projetos. Metodologias ágeis. Scrum.
1 INTRODUÇÃO
Com o crescente aumento na demanda de sistemas informatizados em praticamente todas as áreas da nossa sociedade, é necessário, e quase que imprescindível, a constante atualização e melhoramento dos processos de desenvolvimento de software. Cada vez mais, o mercado consumidor exige sistemas de qualidade, sem deixar de buscar pelo melhor custo/benefício.
Neste contexto, um projeto de software, para ser bem sucedido e vantajoso perante seus concorrentes, deve conseguir aliar a qualidade do produto desenvolvido com a redução de custos e prazos de produção. Em busca destes objetivos, foram-se desenvolvendo ao longo dos anos, diversas metodologias para o gerenciamento de projetos, desde modelos mais conservadores, ou tradicionais, até métodos mais flexíveis e ágeis.
O presente artigo visa apresentar uma destas metodologias ágeis, denominada Scrum, como uma alternativa atualizada ao gerenciamento de projetos de software tradicional, demonstrando seu funcionamento e suas principais características.
2 GERENCIAMENTO DE PROJETOS
Pode-se definir projeto como um esforço temporário e único, executado de forma coordenada por uma conjunto de indivíduos, com a meta de, em um
determinado período de tempo, alcançar um objetivo pré-estabelecido.
Segundo Pressman (1995), para que um projeto de software seja bem sucedido, é necessário que alguns parâmetros sejam corretamente analisados, como por exemplo, o escopo do software, os riscos envolvidos, os recursos necessários, as tarefas a serem realizadas, os indicadores a serem acompanhados, os esforços e custos aplicados e a sistemática a ser seguida.
Para que se possa acompanhar o andamento e garantir o cumprimento dos objetivos, são aplicadas técnicas e utilizadas ferramentas para o planejamento, execução e controle do projeto. Esta atividade é definida como “Gerenciamento de Projetos”.
Na área de sistemas de informação, existem diferentes visões como o projeto deve ser gerenciado, sendo estas centradas em alguns modelos. Pode-se dividir estes modelos em dois grupos: tradicionais e ágeis.
2.1 Metodologias tradicionais de gerência de projetos
Assim que os primeiros sistemas começaram a ser desenvolvidos, começou-se a perceber uma série de problemas de qualidade e demandas maiores do que a capacidade produtiva.
2.1.1 Modelo Cascata
Neste cenário, surgiu o primeiro modelo de gerenciamento de software, chamado Cascata (ou Waterfall). Este modelo definiu um ciclo de vida básico do software e foi um grande salto qualitativo para o desenvolvimento de software. Este ciclo de vida divide o desenvolvimento do software em etapas claras, onde somente é possível passar para a próxima etapa do ciclo após a etapa anterior ter sido concluída.
Mesmo sendo um modelo antigo, o processo Cascata ainda é utilizado atualmente e, apesar de ter ajudado muito a organizar o desenvolvimento de sistemas, traz consigo uma série de problemas. Segundo Pressman (1995), as principais críticas a esse modelo são:
• Os projetos raramente seguem o fluxo sequencial;
• É muito difícil para o cliente declarar todas as suas necessidades corretamente e de forma clara logo no início do projeto;
• Decorre muito tempo entre o início do projeto e a disponibilização de uma primeira versão utilizável do sistema (durante esse período, os requisitos podem sofrer modificações ou mesmo deixar de fazer sentido);
• O risco de insucesso é alto, visto que, se um erro de grande impacto for cometido e não detectado, provavelmente só será descoberto muito tarde – o que pode ser desastroso para o projeto.
O ciclo Cascata presume que o projeto terá uma sequência correta, sem desvios ou problemas, ou seja, não considera riscos que podem impactar ou até inviabilizar o projeto.
2.1.2 Modelo Espiral
O modelo espiral foi originalmente proposto por Boehm em 1988 e traz uma alternativa interessante aos problemas do modelo Cascata, pois divide a tarefa de levantar requisitos em etapas que não ocorrem todas de uma vez, no início do desenvolvimento. À medida que o desenvolvimento ocorre, caminha-se, na espiral, para sua parte mais externa, passando pelas disciplinas de desenvolvimento várias vezes. O efeito dessa forma de trabalho são entregas parciais de software para o cliente, em vez de uma entrega única ao final do processo.
O modelo espiral foi a base para diversos modelos posteriores, do qual pode-se citar o modelo RUP (Rational Unified Process) criado pela IBM e que é o mais utilizado atualmente.
2.2 Metodologias ágeis de gerência de projetos
No início dos anos 2000, um grupo de representantes de diversas metodologias consideradas “leves” se reuniu para levantar pontos em comum entre suas metodologias. A partir dessa reunião foi criado o Manifesto Ágil e definidos os princípios para o desenvolvimento ágil de software. Dentre esses princípios, pode-se citar alguns, como:
• A maior prioridade é satisfazer o cliente através da entrega contínua e desde cedo de software com valor;
• Mudanças de requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis utilizam a mudança em favor da vantagem competitiva do cliente;
• Entregar frequentemente software em funcionamento, desde a cada duas semanas até a cada dois meses, com uma preferência por prazos mais curtos;
• Pessoas do negócio e desenvolvedores devem trabalhar em conjunto diariamente por todo o projeto;
• Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o suporte que precisam e confie neles para fazerem o trabalho;
• O método mais eficiente e eficaz de se transmitir informação para e entre uma equipe de desenvolvimento é a conversação face a face;
• Software em funcionamento é a medida primária de progresso.
O objetivo do Manifesto Ágil não é desconsiderar processos, ferramentas, documentação, negociação de contratos ou planejamento, mas mostrar o valor secundário que estes possuem diante dos indivíduos e interações, do bom funcionamento do software, da colaboração do cliente e das respostas velozes às modificações. Esses conceitos estão mais relacionados à forma que as pequenas e médias empresas trabalham, devido a estarem habituadas a mudanças.
Os métodos ágeis mais conhecidos são o Extreme Programming (conhecido também como XP) e o Scrum, que será detalhado a seguir.
3 METODOLOGIA SCRUM
Scrum é uma metodologia ágil de gestão de projetos, que teve sua origem em um artigo, intitulado “The New New Product Development”, publicado por Hirotaka Takeuchi e Ikujiro Nonaka na prestigiada Harvard Business Review em 1986. Neste artigo, os autores descrevem uma abordagem onde, pequenos e multifuncionais times trabalham com sucesso em direção a um objetivo comum, semelhante à formação scrum do jogo rúgbi (DA SILVA et al, 2008).
Segundo Bissi (2007), este método pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa , porém é bastante indicado para o desenvolvimento de softwares, onde os requisitos surgem e mudam com certa frequência, por sua flexibilidade e poder de adaptação.
Sua abordagem se opõem ao modelo Cascata pois inicia-se o desenvolvimento assim que alguma análise tenha sido feita, e não mais aguarda a finalização de toda a análise para então iniciar o desenvolvimento.
3.1 Características
Os princípios do Scrum são baseados em boas práticas de gestão e tem por objetivo definir um processo iterativo e incremental de desenvolvimento de software. Ao final de cada iteração, que no Scrum são chamadas de Sprints, visa produzir um conjunto de funcionalidades mais próximas do objetivo final. O Sprint representa um período de tempo (geralmente 15 ou 30 dias), dentro do qual um conjunto de atividades deve ser executado.
É uma metodologia voltada ao trabalho em equipe, que melhora a comunicação e a cooperação entre os envolvidos, permitindo que cada um desempenhe o seu melhor e se sinta bem com o que faz, resultando em um aumento na produtividade.
Não requer técnicas ou métodos específicos para a fase de desenvolvimento, estabelecendo apenas um conjunto de regras e práticas de gestão que devem ser adotadas para garantir o sucesso do projeto (FERREIRA, 2005).
3.2 Personagens
São três os personagens do processo Scrum:
qual não necessariamente tem por obrigação ser um funcionário do cliente, apesar de ser muito recomendado, visto que essa pessoa deverá ter um ótimo conhecimento das necessidades da empresa, de maneira a expressar pontualmente as prioridades dentro do projeto. É quem irá elencar as funcionalidades pretendidas, bem como um grau de importância para essas funcionalidades dentro do processo. É também atribuído a esse personagem o poder de aceitar ou rejeitar o resultado do trabalho efetuado em cada Sprint;
• Scrum Master – é o elemento da equipe responsável pela gestão do projeto e
de liderar as reuniões. São normalmente engenheiros de software ou de sistemas e que, apesar de serem gestores, não tem propriamente “autoridade” sobre os demais membros da equipe. O Scrum Master pode exercer outros papéis no processo, desde que não o impossibilitem de exercer suas funções de gerência;
• Scrum Team (Time) – é a equipe de desenvolvimento de um Sprint.
3.3 Artefatos
Artefato, em engenharia de software, é um modelo, documento ou código produzido por uma atividade.
Na metodologia Scrum, os principais artefatos são:
• Product Backlog – é uma lista de todas as funcionalidades desejadas em um
produto. Esta lista é definida pelo dono do produto (Product Owner), que prioriza os itens e os descreve para a equipe. O Product Backlog não precisa estar completo no início do projeto, podendo-se começar com itens mais báscios, ou óbvios;
• Sprint Backlog – é uma lista de tarefas que o Scrum Team se compromete a
desenvolver em um Sprint. Os itens desta lista são extraídos do Product Backlog, com base na priorização realizada pelo Product Owner e a percepção da equipe sobre o tempo necessário para realizá-los;
• Product Burndown Chart – é um gráfico que representa o trabalho restante no Product Backlog. Tem o objetivo de informar o andamento global do projeto;
• Sprint Burndown Chart – é um gráfico informativo do trabalho restante em um Sprint.
4 O PROCESSO SCRUM
responsável pela coleta de requisitos do produto a ser desenvolvido. Nesta prática, através de reuniões com o Product Owner, são apontados os itens com todas as necessidades e requisitos técnicos a serem desenvolvidos, e que irão constituir o
Product Backlog (ZANATTA et al, 2005).
Para iniciar o processo Scrum deve-se, inicialmente, definir as pessoas que irão trabalhar no projeto. Cada equipe deve ter de 6 a 9 integrantes (FERREIRA, 2005), e cada equipe irá focar em uma área específica do trabalho. Após a definição das equipes, define-se o Scrum Master. É a ele que compete o papel de gerente do projeto.
Todo o processo é controlado durante o Sprint que, ao final de seu período de desenvolvimento, resulta em um incremento no produto final, que é analisado pelo
Product Owner.
No início de cada Sprint, realiza-se uma reunião de planejamento (Sprint
Planning Meeting), onde o Product Owner prioriza os itens do Product Backlog e a
equipe seleciona atividades que julga ser capaz de implementar durante o Sprint que se inicia. As tarefas então são transferidas do Product Backlog para o Sprint
Backlog.
Quanto à priorização dos itens do Product Backlog, pode-se utilizar uma técnica chamada de “MoSCoW”, onde os itens são classificados em Must (Deve ter),
Should (Deveria ter), Could (Poderia ter) e Want (Interessante ter).
A cada dia de um Sprint, a equipe faz uma breve reunião, chamada de Scrum
Meeting, com o objetivo de monitorar o andamento dos trabalhos, identificar
possíveis impedimentos, definir e priorizar o trabalho a ser feito no dia. Cabe ao
Scrum Master tomar decisões imediatas e resolver todos os impedimentos
rapidamente, de modo a não estender o tempo da reunião.
No fim de cada Sprint, deve ser feita uma Sprint Review Meeting (reunião de revisão do Sprint) para revisão e demonstração das funcionalidades implementadas. Cada equipe deve demonstrar algo, uma vez que o objetivo é que sigam regras de auto-organização.
Ao final do Sprint deve sair um produto com valor agregado, ou seja, é feito um incremento no produto. Esse ciclo se repete várias vezes até que o Product
Figura 2 – Ciclo de desenvolvimento do Scrum.
5 CONCLUSÃO
O Scrum se mostra uma ótima metodologia para o gerenciamento dos processos de desenvolvimento de software, pois possui muitas características desejadas pelos gestores atuais, tais como acompanhamento em tempo real do trabalho realizado, diminuição dos riscos, maior integração e comprometimento dos envolvidos, rápida solução de problemas e respostas frequentes ao cliente (dono do produto).
É uma excelente opção para empresas e desenvolvedores que buscam implantar um padrão e qualificar seus processos, e mesmo para a substituição de uma metodologia já aplicada, mas que esteja dificultando o potencial produtivo da equipe.
REFERÊNCIAS
PRESSMAN, R. S. Engenharia de Software. Makron Books. São Paulo. Brasil. 1995.
SOMMERVILLE, I. Engenharia de Software. 6. ed. Addison Wesley. São Paulo. Brasil. 2003.
SCHWABER, Ken. Control Chaos. Disponível em: <http://www.controlchaos.com/>. Acesso em: dez de 2012.
FERREIRA, D., COSTA, F., ALONSO, F., ALVES, P., NUNES, T. SCRUM. Um Modelo Ágil para Gestão de Projetos de Software.
ZANATTA, Alexandre Lazaretti, VILAIN, Patrícia. Uma análise do método ágil Scrum conforme abordagem nas áreas de processo Gerenciamento e Desenvolvimento de Requisitos do CMMI. Anais do WER05 - Workshop em Engenharia de Requisitos. Porto. Portugal. p. 209-220. 2005.
DA SILVA, Alexandre Almeida et al. Breve descrição do método SCRUM de gerenciamento de projetos. Minas Gerais. Brasil. 2008. Disponível em: <http://pt.scribd.com/doc/44265501/scrum>. Acesso em dez. 2012.
