SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

Transcrição

1 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 e controle de todo projeto de software, as metodologias ágeis chegam para incentivar a mudança nos requisitos com o objetivo de entregar ao cliente o produto que ele precisa e trazer a satisfação do mesmo através da entrega incremental do software logo de início. Ao considerar a importância de melhorias no desenvolvimento de software e o crescente uso das práticas ágeis, em especial a Scrum, este trabalho teve como objetivo verificar e analisar como as práticas ágeis estão sendo tratadas por equipes de desenvolvimento que utilizam o método ágil Scrum. Para a construção do artigo utilizou-se a pesquisa bibliográfica como metodologia e as conclusões obtidas foram de grande importância pois nos mostrou o objetivo de alcançar a satisfação do cliente, onde ele se interage diretamente com os desenvolvedores através do método Scrum. Palavra-chave: Metodologias ágeis. Scrum. Testes de software. 1. INTRODUÇÃO Com um cenário competitivo, clientes mais exigentes, empresas mais flexíveis e demandas por prazo de entrega mais rápidos, foi necessário adaptar as metodologias tradicionais de gerenciamento de projetos para atender a essas novas exigências. Em virtude desse cenário, em 2001 foi formado a Aliança Ágil, quando dezessete especialistas em processos de desenvolvimento de software estabeleceram princípios comuns de métodos de criação de softwares e publicaram o Manifesto Ágil que sugere (BECK et al., 2001): 1 Graduando em Sistemas de Informação pela Faculdade Infórium de Tecnologia. eleandrogeracao@gmail.com 2 Graduando em Sistemas de Informação pela Faculdade Infórium de Tecnologia. nielsenalves23@gmail.com 3 Especialista em Gestão da Informação pelo IEC PUC Minas. Graduado em Analista de Business Intelligence há 12 anos. Professor da Pós-Graduação das Faculdades PUC Minas, Estácio de Sá e Infórium de Tecnologia. Professor da graduação das Faculdades Infórium de Tecnologia e Batista. rodrigo.moravia@gmail.com 4 Professora da Faculdade Infórium de Tecnologia, e Mestre em Psicologia pela PUC Minas. mariarenatafurtado@gmail.com

2 2 a) Indivíduos e interações melhor que processos e ferramentas. b) Software funcionando melhor que documentação excessiva. c) Colaboração do cliente melhor que negociação de contratos. d) Resposta a modificação melhor que seguir um plano. As metodologias ágeis também dividem o desenvolvimento do software em iterações, eliminando pontos fracos, como análise de riscos. Ao final de cada iteração, uma versão (release) funcional do produto, embora restrita em funcionalidades, é liberada ao cliente. As metodologias ágeis destacam aspectos humanos no desenvolvimento do projeto, promovendo interação na equipe de desenvolvimento e o relacionamento de cooperação com o cliente. A comunicação face-a-face é preferida à documentação compreensiva (VASCO; VITHOFT; ESTANTE, 2004, P.2). Processos de desenvolvimento ágil de software são construídos com os fundamentos do desenvolvimento iterativo. Os processos ágeis usam o feedback, mais que o planejamento, como seus mecanismos de controle primário. O feedback é produzido por testes regulares e das versões do software desenvolvido (SCHWABER, 2009). Os métodos ágeis têm-se destacado nesse contexto de mudanças, oferecendo respostas rápidas a esse novo ambiente de desenvolvimento, onde os requisitos são mutáveis, não estão totalmente claros ou não são totalmente esclarecidos, mas exige-se a entrega do produto com valor tangível. De acordo com (BECK et al., 2001) o Manifesto Ágil, estabeleceu doze princípios de agilidade:

3 3 Prioridade é satisfazer o cliente desde o início com entregas contínuas de software valioso. Alterações de requisitos são bem-vindas. Representam maior competitividade ao cliente. Entrega de softwares de modo frequente, de algumas semanas a alguns meses. Pessoal do negócio e desenvolvedores devem trabalhar juntos diariamente durante o projeto. Construção com indivíduos motivados. Conversa face-a-face, métodos mais eficientes de levar informação para dentro de uma equipe. Software funcionando é a melhor medida de progresso. Desenvolvimento sustentável. Capacidade de manter um nível constante. Atenção contínua, a excelência técnica e ao bom projeto facilitam a agilidade. Simplicidade é essencial. A arte de maximizar a quantidade de trabalho não efetuado. As melhores arquiteturas e projetos surgem de equipes auto-organizadas. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva e se ajustar. Portanto, utilizando as pesquisas bibliográficas notamos que ocorreram grandes melhorias nos softwares e também o crescente uso das práticas ágeis, em especial a Scrum. Com isso esse trabalho tem como objetivo verificar e analisar como as práticas ágeis estão sendo tratadas por equipes de desenvolvimento que utilizam o método ágil Scrum. 2. SCRUM O método Scrum é fundamentado na teoria de controle de processos empíricos, e emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. É incremental, porque envolve a construção de um pedaço de sistema a cada etapa, ou seja, permite a construção de conjuntos de funcionalidades até entregar o produto final. Também é iterativo porque aceita a probabilidade do desenvolvimento estar incorreto da primeira vez, permitindo o feedback do cliente a cada entrega parcial e o aperfeiçoamento em uma próxima etapa (VASCO;

4 4 VITHOFT; ESTANTE, 2004). O Scrum foi implementado por Jeff Sutherland e vem sendo usado para o desenvolvimento de produtos complexos desde o início da década de 90, com foco no gerenciamento da equipe, preocupada na organização dos processos, no modo como as atividades devem ser executadas, deixando a cargo dos participantes do projeto escolher a melhor maneira de concluir com sucesso essas etapas (SCRUM, 2008). Segundo Schwaber (2009), Scrum não é um processo, ou uma técnica para o desenvolvimento de produtos. Ao invés disso, é um framework dentro do qual você pode empregar diversos processos e técnicas. O papel do Scrum é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um framework dentro do qual os produtos complexos podem ser desenvolvidos. O desenvolvimento de softwares através do Scrum envolve muitas variáveis técnicas e do ambiente, como recursos, requisitos e tecnologia, que podem mudar durante o processo, tornando esse processo imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças. O resultado desse processo deve ser um software que seja realmente útil para o cliente. Segundo Cohn (2011, p. 202), uma pesquisa realizada em mais de sete mil projetos aponta que o tamanho ideal para uma equipe para obter maior produtividade é de cinco a sete pessoas. Logo, este também é um dos princípios do Scrum, que recomenda equipes pequenas com sete pessoas, podendo variar em mais ou menos duas pessoas. As pequenas equipes maximizam a comunicação e minimizam a supervisão. O Scrum compõe um ciclo de vida baseado em três fases: planejamento, desenvolvimento e pós-planejamento (KOSCIANSKI; SOARES, 2007), ilustrada na figura a seguir:

5 5 Figura 1 Ciclo de vida do Scrum. Fonte: MOUNTAIN GOAT SOFTWARE, Na fase de planejamento, o Product Owner (representante de todos os interessados do projeto e responsável pela gestão do Product Backlog) e o cliente definem e descrevem os requisitos em um documento, ordenados por prioridade, o chamado Product Backlog (Backlog do produto, local onde serão alocadas as funcionalidades a serem implementadas nos projetos). Em seguida, realiza-se o planejamento, o qual inclui a definição da equipe, as ferramentas para o uso, a identificação de possíveis riscos do projeto e lista de tarefas, com os requisitos prioritários, Sprint Backlog (subgrupo do Backlog do produto que foi selecionado para um Sprint). Como resultado, tem-se a proposta de uma arquitetura de desenvolvimento. Na fase de desenvolvimento, é onde as muitas variáveis técnicas e do ambiente identificadas previamente são observadas e controladas. Ao invés de considerar essas variáveis apenas no início do projeto, como no caso das metodologias tradicionais, no Scrum o controle é feito continuamente, o que aumenta a flexibilidade para acompanhar as mudanças. Essa fase é dividida em ciclos, denominados sprints, incluindo a reunião diária, Daily Meeting, e semanal, Sprint Review. O software é implementado e novas funcionalidades são acrescentadas a cada iteração/ciclo. Os riscos identificados são observados e controlados durante todo o desenvolvimento do sistema. Ao final desta fase, a equipe entrega um incremento funcional do projeto.

6 6 A última fase, o pós-planejamento, constitui a integração do software, bem como os testes finais, homologação e documentação do usuário. Em seguida, é feita uma análise do progresso do projeto e demonstração do produto para o cliente. O Scrum é formado por Times Scrum e seus papéis associados, Eventos com Duração Fixa (Time-Boxes), Artefatos e Regras(SCHWABER, 2009) Times Scrum Times Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada Time Scrum possui três papéis (SCHWABER, 2009): O ScrumMaster, que é responsável por garantir que o processo seja entendido e seguido. Ele é o líder da equipe que lidera a reunião e avalia as respostas e é aquele que cobra as práticas e as regras dos valores do Scrum. O ScrumMaster ajuda o Time Scrum a entender e usar autogerenciamento e interdisciplinaridade. Resolve problemas que possa estar prejudicando o andamento das tarefas, exige dos colaboradores, delega responsabilidades, marca reuniões e tem contato direto com os patrocinadores. Responsável por atualizar manualmente o Product Backlog com respeito a quaisquer mudanças que foram feitas. Quando o Sprint está perto do fim, o ScrumMaster lembra todo mundo sobre a apresentação que ocorrerá em breve. O Product Owner, representante de todos os interessados do projeto e responsável pela gestão do Product Backlog, por maximizar o valor do trabalho que o Time Scrum faz. Essa pessoa mantém o Backlog do Produto e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar. Normalmente o Product Owner reúne toda a equipe em uma sala, fornece algumas distrações e lhes diz que o objetivo da reunião é fazer uma estimativa de tempo para as 20 estórias mais importantes no Product Backlog (ou algo do tipo).

7 7 Ele passa por cada estória uma vez e então deixa a equipe trabalhar. O Product Owner permanece na sala para responder perguntas e esclarecer o escopo de cada item conforme necessário. Ele é o especialista no domínio que dá o norte a equipe. O Time, que executa o trabalho propriamente dito. O Time consiste em desenvolvedores com todas as habilidades necessárias para transformar os requisitos do Product Owner em um pedaço potencialmente entregável do produto ao final da Sprint. Membros do Time frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, projeto de interface de usuário ou projeto de banco de dados. No entanto, os conhecimentos que os membros do Time devem compartilhar, isto é, a habilidade de pegar um requisito e transformá-lo em um produto utilizável, tende a ser mais importantes do que aqueles que eles não dividem. Times também são auto-organizáveis. Ninguém, nem mesmo o ScrumMaster, diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis. O Time descobre por si só. Cada membro do Time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia geral do Time como um todo. O tamanho ótimo para um Time é de sete pessoas mais ou menos duas pessoas. Quando há menos do que cinco membros em um Time, há menor interação e, como resultado, há menor ganho de produtividade. Mais do que isso, o time poderá encontrar limitações de conhecimento durante partes da Sprint e não ser capaz de entregar uma parte pronta do produto Time-Boxes: eventos com duração fixa Seguem abaixo os conceitos dos time-boxes (COHN, 2011, cap. 14 e 18, SCHWABER, 2009): Sprint: a equipe trabalha por um período fixo de tempo chamado Sprint. É uma iteração do Scrum, onde será projetado, produzido e testado algum código funcional, que entregue valor para o usuário. O coração do Scrum é a Sprint, que é uma

8 8 iteração de um mês ou menos de duração consistente, com o esforço de desenvolvimento. O prazo de um Sprint nunca deve ser estendido. Isso faz com que se tenham entregas mais cedo, o feedback do usuário seja obtido rápido e que a equipe avalie mais cedo o seu progresso e sua produtividade. A equipe deve, no período de um Sprint, se adaptar às circunstâncias, tecnologias e limitações da organização para se organizar de uma forma a conseguir alcançar os objetivos. Essa organização não é mais de responsabilidade do gerente, mas do time. Sprints são eventos com duração fixa. Durante o Sprint, o ScrumMaster garante que não será feita nenhuma mudança que possa afetar a meta do Sprint. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante o Sprint. Os Sprints ocorrem um após o outro, sem intervalos entre eles. Durante o ciclo, Sprint, a equipe executa breves reuniões diárias para discutir o que foi feito, o que não foi realizado e quais as dificuldades e limitações encontradas. No final de cada Sprint, a equipe oferece um incremento do produto potencialmente entregável. Planejamento do Sprint: consiste em uma reunião envolvendo cliente, usuários, gerentes, dono do produto e a equipe scrum para discutir e determinar o objetivo e as funcionalidades do próximo Sprint, podendo ser feita presencialmente, por telefone ou virtualmente. O propósito principal é de estabelecer um plano e metas que o Time Scrum e o resto da organização possam entender e se comunicar. Reunião diária de Scrum (daily scrum): parte do pressuposto que o desenvolvimento de software é um processo complexo que requer muita comunicação. A reunião daily scrum deve ser breve e diária, com timebox de quinze minutos, com todos em pé. Normalmente cada membro responde três perguntas: O que você fez desde a última reunião? O que você vai fazer até a próxima reunião? Existe algum impedimento para você realizar seu trabalho? O objetivo é saber o que já está concluído, identificar os impedimentos para que o ScrumMaster possa atuar e engajar o time com suas próximas atividades.

9 9 Revisão de Sprint (Sprint review): é uma reunião informativa de quatro horas onde a equipe Scrum apresenta para a gerência, clientes, usuários e o dono do produto, o próprio produto ou seu incremento que foi construído durante o último Sprint. Esta reunião provê uma forma de corrigir a direção do projeto a tempo, uma vez que força um feedback imediato dos clientes, usuários e dono do produto. Essa é uma reunião informal, com a apresentação da funcionalidade, que tem a intenção de promover a colaboração sobre o que fazer em seguida. O Time discute sobre o que correu bem durante o Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos. O Time então demonstra o trabalho que está pronto e responde a questionamentos. Retrospectiva de Sprint (Sprint retrospective): reunião realizada pela equipe Scrum ao final de um Sprint com foco na melhoria do processo. Ela serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas, para melhorar. Nessa reunião, com duração fixa em três horas, o ScrumMaster encoraja o Time a revisar, dentro do modelo de trabalho e das práticas do processo do Scrum, seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para o próximo Sprint Artefatos Principais Os artefatos são os seguintes (COHN, 2011, cap. 11, SCHWABER, 2009): Backlog do produto (Product Backlog): É o local onde serão alocadas as funcionalidades a serem implementadas nos projetos. Consiste em uma lista priorizada de funcionalidades técnicas e de negócio desejadas que ainda não fazem parte do produto, mantida pelo dono do produto. Pode conter histórias de usuário, épicos, melhorias, mudanças, correções de defeitos ou qualquer outra coisa que precisa ser feita no produto para releases futuras. Diferente de um documento de requisitos tradicional o Backlog do produto é altamente dinâmico, pois itens são adicionados, removidos e repriorizados a cada Sprint à medida que o produto é mais bem conhecido. O Product Owner é o

10 10 responsável pelo Backlog do Produto, por seu conteúdo, por sua disponibilidade e por sua priorização. O Backlog do Produto representa tudo que é necessário para desenvolver e lançar um produto de sucesso. É uma lista de todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para versões futuras. Os itens do Backlog do Produto são geralmente representados como Estórias de Usuário. O Backlog do Produto é ordenado por prioridade. Backlog do Sprint (Sprint Backlog): é um subgrupo do Backlog do produto que foi selecionado para um Sprint. Ela consiste nas tarefas que o time executa para transformar itens do Backlog do Produto em um incremento pronto. O Backlog da Sprint é todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Backlog da Sprint devem ser decompostos. A decomposição deve ser suficiente para que mudanças no progresso possam ser entendidas na reunião diária. Burndown de versão para entrega: gráfico que mede o Backlog do Produto restante ao longo do tempo de um plano de entrega. Burndown de Sprint: gráfico que mede os itens do Backlog da Sprint restantes ao longo do tempo de uma Sprint. É o principal artefato para acompanhamento do andamento da iteração. Ele é gerado a partir da lista de tarefas do Sprint atualizadas diariamente pela equipe com as tarefas já concluídas e as tarefas ainda pendentes. É baseado no número de horas restantes para a conclusão de cada tarefa. Gráfico de Burndown: é uma ferramenta para auxiliar o gerenciamento de um Sprint, na qual todo o esforço em horas necessário para concluir as atividades do Sprint é plotado em um gráfico, mantendo rastreado o registro da soma das horas restantes a cada dia. Através da visualização é possível verificar se o projeto foi sub ou super estimado. Segue abaixo a figura de um gráfico de Burndown:

11 11 Figura 2 - Exemplo de gráfico de burndown Fonte: MOUNTAIN GOAT SOFTWARE, 2012 Quando um incremento está pronto, pode-se dizer que está incluído toda a análise, projeto, refatoramento, programação, documentação e testes para o incremento e todos os itens do Backlog do Produto no incremento. Os testes incluem testes de unidade, de sistema, de usuário e de regressão, bem como testes não-funcionais como de performance, de estabilidade, de segurança e de integração (SCHWABER, 2009). Para terminar um projeto é necessário que cada incremento seja adicionado aos outros e exaustivamente testado, garantindo que todos os incrementos funcionem juntos. 3. CONCLUSÃO Percebemos que as metodologias ágeis surgiram em resposta às deficiências no desenvolvimento tradicional, oferecendo uma estrutura para desenvolvimento de software altamente colaborativo. Elas são projetadas especificamente para facilitar a comunicação, a colaboração e a coordenação dentro de um ambiente dinâmico, com foco em atividades que contribuem diretamente para o objetivo final do projeto. Dessa forma, diante de um mercado muito competitivo, que exige produtos de

12 12 qualidade, se tornou fundamental o uso de uma metodologia ágil quecorrespondesse a essas expectativas no mundo tecnológico. Então o Scrum que é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível, tem correspondido a essas exigências. Portanto, com o uso do Scrum ocorre à rápida e contínua inspeção do software em produção a cada Sprint. As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade, até chegar à entrega final do software. REFERÊNCIAS BECK et al.; AGILE MANIFESTO Disponível em: < Acesso em: 15 de fev COHN, Mike. Desenvolvimento de Software com Scrum: aplicando métodos ágeis com sucesso. Porto Alegre: Bookman, KOSCIANSKI, A.; SOARES, M. S.; Qualidade de Software: Aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2ª Edição. São Paulo: Novatec, KNIBERG, Henrik. Scrum e XP direto das trincheiras: como fazemos Scrum. C4Media Inc, Disponível em < Acesso em: 03 de mar MOUNTAIN GOAT SOFTWARE; Introduction to Scrum: An Agile Process; Disponível em: < Acesso em: 23 de fev SCHWABER, Ken. Guia do Scrum: Transforming The Word of Work. Tradução: Heitor Roriz Filho, Disponível em: < Acesso em: 19 de mar SCRUM. Visão geral do Scrum. [S.l.], Disponível em: < Acesso em: 21 de mar VASCO, Carlos G.; VITHOFT, Marcelo H.; ESTANTE, Paulo R. C. Comparação entre metodologias RUP e XP. Curitiba, Disponível em: <

13 ariasof tware/artigos/resumosapresentacoes/rupvsxp_draft.pdf>. Acesso em: 10 de mar