DESENVOLVIMENTO GIL: UMA ABORDAGEM SOBRE O SCRUM Klaus Fischer Gomes Santana1 Rafael Arajo de Freitas2

RESUMO A metodologia Scrum assume-se como extremamente gil e flexvel. Defini-se como um processo de desenvolvimento iterativo e incremental que pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa, proporcionando um excelente entendimento entre as equipes de desenvolvimento. Com todo esse entrosamento e participao ativa dos clientes, o rendimento do projeto aumenta e os requisitos e a solicitao de alterao passa a ser atendido mais rapidamente. As metodologias de desenvolvimento gil vem se destacando a cada dia, porm essas ainda so pouco difundidas no meio acadmico. O objetivo deste artigo, alm de difundir esse assunto e servir de apoio para futuras pesquisas, demonstrar de maneira simples e objetiva, o funcionamento, as caractersticas, o vocabulrio e a aplicao da metodologia Scrum em um ambiente de trabalho. Palavras-chave: Engenharia de Desenvolvimento gil, SCRUM. Software, Mtodos de Desenvolvimento,

1 INTRODUO

Um desafio constante da rea de Engenharia de Software melhorar o processo de desenvolvimento de software. Mesmo com a constante evoluo de mtodos, tcnicas e ferramentas, a entrega de softwares em prazos e custos estabelecidos nem sempre efetiva. Uma das causas desse problema o excesso de formalidade nos modelos de processo propostos nos ltimos 30 anos. Existe hoje a necessidade de criar software de forma mais rpida, mas com qualidade. Esse produto pode ser obtido utilizando mtodos geis e padres organizacionais e de processos. O desenvolvimento gil uma filosofia. uma maneira de pensar sobre produo de software. A deciso cannica desta maneira de pensar o Manifesto gil (Becket al., 2001), um conjunto de 4 valores (figura 1) e 12 princpios (figura 2).
1 2

Graduando em Anlise e Desenvolvimento de Sistemas. E-mail: klausfgsantana@gmail.com Graduando em Anlise e Desenvolvimento de Sistemas. E-mail: jedi.rafael@gmail.com

Figura 1: Manifesto para o gil Fonte: http://manifestoagil.com.br/index.html

Figura 2: Princpios do manifesto gil Fonte: http://manifestoagil.com.br/principios.html

Nos ltimos anos, mtodos geis como o XP (Beck, 1999), Scrum (Schwaber, 2002) e Crystal (Cockburn, 2002), entre outros, passaram a ser utilizados por grandes empresas como Google, Yahoo, Symantec, Microsoft, entre outras, universidades, institutos de pesquisa e agncias governamentais. Neste Artigo abordaremos a Metodologia de Desenvolvimento gil Scrum, veremos como se d sua implantao no processo de desenvolvimento de software.

2 ENTENDENDO O SCRUM
Estamos crescendo to rpido que parece que sempre precisamos de mais umas regrinhas aqui, mais um pouco de papel ali... precisamos ter muito cuidado, pois cada novo nvel gerencial, cada nova regra ou formulrio atrapalha. Eles acabam com a mgica, cortam a eletricidade da inspirao. Com restries em excesso, voc pra de pensar no que pode fazer e comea a pensar no que no d para fazer (Cirque Du Soleil A reinveno do Espetculo; Ed. Campus; Elsevier).

As razes do Scrum esto num artigo que sumariza as 10 melhores prticas em empresas japonesas, escrito por Takeuchi e Nonaka, cujo ttulo O jogo do desenvolvimento de novos produtos, publicada na Harvard Bussinesss Review em janeiro de 1986. Este artigo introduziu o termo Scrum para referir-se s reunies de equipes que praticam a autodireo e a adaptabilidade. A palavra Scrum no uma sigla e nem tem traduo para o Portugus. O termo Scrum o nome usado para a reunio de jogadores, no jogo de Rugby, quando eles se organizam em crculo para planejar a prxima jogada. uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma viso de longo prazo, que ganhar o jogo. Desenvolvimento de produtos complexos ocorre em situaes de muitas mudanas. Quanto mais prximo do limite do caos a equipe conseguir trabalhar, porm mantendo a ordem, mais competitivo e til ser o produto resultante. O Scrum a metodologia que permite esta forma de trabalhar. O processo de desenvolvimento de sistemas complicado e complexo. Logo, grande flexibilidade e controle so necessrios. A evoluo favorece aqueles que se expes e aceitam as mudanas e esto preparados para se adaptarem a essas. Nesse caso necessria uma abordagem gerencial de projetos que permita s equipes operarem de forma flexvel e adaptvel num ambiente complexo, usando processos imprecisos. Scrum um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para criao de produtos, alm de tratar-se de metodologia gil e seguir as filosofias iterativa e incremental. Ele se concentra no que realmente importante: gerenciar o projeto e criar um produto que acrescente valor para o negcio.

A maioria dos mtodos e tcnicas de gerenciamento de projetos so bastante prescritivas, isso fora as pessoas a seguirem uma sequncia predefinida de passos, com pouca flexibilidade para mudanas. Tradicionalmente, os projetos de construo de software seguem um ciclo envolvendo captura de requisitos, anlise, projeto tcnico (design), programao, teste e implantao com cada estgio sendo completado antes que o prximo seja iniciado. Contudo, so caractersticas importantes do Scrum: a adaptabilidade e o empirismo. Sua abordagem oposta a do modelo em cascata, inicia-se a anlise assim que alguns requisitos estiverem disponveis, assim que alguma anlise tiver sido feita comeam os trabalhos de projeto tcnico (design), e assim por diante. Em outras palavras, o projeto trabalha num pedao pequeno de cada vez. Esta abordagem pode ser chamada de iterativa, e cada iterao consiste na captura de requisitos, um pouco de anlise, um pouco de design, mais alguma programao e testes, culminando num ciclo iterativo com vrias entregas conforme podemos ver na figura 3.

Figura 3: Ciclo de iteraes de sprint de um projeto.

3 O PRODUCT BACKLOG

O projeto no Scrum comea com uma viso, que pode ser vaga no princpio, talvez expressa em termos de marketing ou uma viso tcnica, e que depois ficar mais clara medida que o projeto evoluir.

A partir da viso definida uma lista de itens priorizados, composta por requisitos e funcionalidade que precisam ser construdos para que a viso seja concretizada. Estamos falando do Product Backlog). O Product Backlog o corao do Scrum. basicamente uma lista de requisitos, histrias, coisas que o cliente deseja, descritas usando uma linguagem que seja clara para o cliente.

Figura 4:Eexemplo de planilha com o Backlog Product.

O Scrum baseia-se no desenvolvimento iterativo, que uma tcnica que procura antecipar o lucro do projeto de uma forma controlada. O produto pode ser entregue aos clientes de forma incremental, antecipando o momento de entrega para o cliente. Desta forma, o projeto comear a gerar valor e lucro muito mais cedo. O Scrum busca este objetivo produzindo uma verso que pode ser potencialmente distribuda para o mercado em intervalos regulares de 30 dias. Pesquisas indicam que 80% do valor do produto vem de 20% das suas freatures. Com isso em mente, poderamos construir, de forma interativa, um produto que tenha estes 20% das freatures logo no incio do projeto. 4 PAPIS NO SCRUM O Scrum trabalha basicamente com trs papis: o Product Owner, o Scrum Master e a Equipe Scrum.

O Product Owner responsvel por representar os interesses das pessoas que apostaram no projeto e no produto resultante. O Product Owner consegue a verba, define os requisitos gerais, define os objetivos e o plano de releases. A lista de requisitos o Product Backlog. O Product Owner provavelmente ser um gerente de projeto, ou um patrocinador do projeto, um membro da equipe de marketing ou um cliente interno (KNIBERG, 2007). O Scrum Master ocupa uma posio similar ocupada pelo Product Owner. responsvel por forar os valores e as prticas do Scrum, remover obstculos, ensinar o processo a todas as pessoas, implementar o Scrum e garantir que todas as pessoas sigam as regras e as prticas do Scrum. O Scrum Master um lder e no um gerente suas responsabilidades podem se resumir em: Remover as barreiras entre a equipe de desenvolvimento e o Product Owner, de modo que o Product Owner possa orientar o desenvolvimento; Ensinar ao Product Owner, como maximizar o ROI (Return on investment) e atingir os seus objetivos atravs do Scrum; Melhorar a vida da Equipe Scrum, facilitando a criatividade atravs do empowerment; Manter a informao sobre o progresso da Equipe Scrum sempre atualizado e disponvel para todos os interessados. A Equipe Scrum o grupo de pessoas responsvel por desenvolver ou construir as funcionalidades do produto. As equipes so autogerenciadas, autoorganizadas e multifuncionais. Geralmente, a equipe composta por 5 a 10 membros (o recomendado so sete pessoas) e deve ser multifuncional, composta por indivduos com diferentes especializaes. A equipe pode ser composta por desenvolvedores em tempo integral e participantes externos (marketing, vendas, clientes etc.).

5 FASES DO SCRUM

O Scrum composto por trs fases: pr-game, game e ps-game. A primeira e ltima fases consistem em processos definidos, onde todos os processos, mais as entradas e as sadas, so bem definidos. Os conhecimentos sobre como realizar estas fases so explcitos e podem compreender uma ou mais iteraes. No Pr-game temos duas partes: planejamento e arquitetura. No planejamento definido um novo release, com base nas informaes conhecidas at o momento, tabuladas num Backlog, junto com uma estimativa de prazo e custo. No caso de um novo produto, esta fase consiste na conceitualizao e anlise. No caso da evoluo de um produto j existente, esta fase consiste numa anlise limitada. Na arquitetura os itens do Backlog so projetados com vistas implementao. Esta fase inclui definies e modificaes na arquitetura e design de alto nvel (KNIBERG,2007). Na fase intermediria do game o processo emprico. A maioria dos processos nesta fase so indefinidos e tratados como uma caixa preta que requerem apenas controles externos. Por exemplo, o controle de riscos ocorre em cada Sprint para evitar o caos e maximizar a flexibilidade. Na fase do game o produto construdo em mltiplas iteraes chamadas no Scrum de Sprint. O produto pode ser modificado a qualquer momento durante o planejamento do Sprint, bem como durante o Sprint. Essas mudanas ocorrem por conta da complexidade, aes da decorrncia, prazo, qualidade, presso de custo etc. Esta fase composta dos seguintes macroprocessos: Reunies com as equipes para rever o planejamento dos releases; Reviso dos padres com os quais o sistema precisa ser compatvel e fazer os ajustes necessrios; Realizao dos Sprints at que o produto esteja pronto para distribuio. Quando a gerncia decide que as variveis de tempo, concorrncia de mercado, requisitos, custos e qualidade esto adequadas para distribuir o produto, ela declara que o release est fechado e a fase de ps-game comea. Nesta fase o produto preparado para distribuio, incluindo integrao, testes adicionais, documentao de usurio, preparao de material para treinamento e de marketing, dentre outras coisas. 6 PRTICAS DO SCRUM

6.1 Plano de Jogo

No Scrum o plano de jogo funciona da seguinte maneira: registram-se todos os requisitos num Product Backlog, que uma lista inicial de requisitos. Cabe lembrar que essa lista pode ser ajustada durante o projeto pelo Product Owner, a fim de modificar a sequncia em que os itens sero trabalhados, bem como para adicionar ou retirar itens. Os requisitos no necessitam ser precisos nem estarem descritos de forma completa e detalhada, estes requisitos sero obtidos com os futuros usurios do produto e com pessoas do negcio. Os principais itens, ou seja, os de maior importncia, vo para o topo da lista. Mesmo com muitos itens j definidos, pode acontecer de apenas alguns deles estarem associados a um Sprint. No desenvolvimento gil voc nunca dever planejar nada alm da iterao seguinte, isto pode ser uma perda de tempo, mesmo porque o contedo de cada Sprint sempre definido nas reunies de planejamento que precedem cada Sprint.

6.2 Sprint Um Sprint um conjunto de atividades de desenvolvimento conduzidas num perodo de tempo predefinido, chamado de Time Box (caixa de tempo), que normalmente varia de uma a quatro semanas. Este intervalo baseado na complexidade do produto, na avaliao de riscos e no grau de volatilidade dos requisitos. Durante um Sprint a equipe desenvolve as seguintes atividades: Desenvolvimento (anlise, projeto tcnico design, programao, testes e documentao); Empacotamento (criao de programas executveis); Reviso (reviso do que foi feito, correo de problemas); Ajustes (consolidar as informaes obtidas na reviso e realizar as mudanas necessrias). Ao final do perodo do Sprint, normalmente em 30 (trinta) dias, produzido uma verso do produto que pode potencialmente ser distribuda para o mercado. Esta verso deve prover algum valor para o negcio.

A vantagem desse curto perodo que ele permite ao Product Owner, o cliente, repriorizar os itens do Product Backlog com base no resultado do Sprint anterior. A importncia disto que o projeto sempre estar produzindo algo que possa ser utilizado no negcio. Todo Sprint comea com uma reunio de planejamento, trabalhando de forma colaborativa o Product Owner e a Equipe Scrum para decidirem os itens da prxima iterao. Os objetivos bsicos desta reunio so: a) O Product Owner deve selecionar os itens de maior prioridade; b) O Product Owner relembra Equipe Scrum quais os objetivos do projeto; c) dito ao Product Owner o que a Equipe Scrum pensa que conseguir realizar, considerando o que est sendo pedido. A reunio de planejamento no deve durar mais que 8 (oito) horas, sendo dividida em duas partes de 4 (quatro) horas. Na primeira o Product Owner apresenta e descreve os itens de maior prioridade. A equipe faz questionamentos e esclarece dvidas quanto ao contedo, propsito, significado e intenes. Quando a equipe achar que tem informaes suficientes, seleciona os itens que acredita que poder desenvolver durante a iterao. Nas prximas 4 (quatro) horas planejado o Sprint, j que a equipe que vai gerenciar seu prprio trabalho. feita tambm pelo Dono do Produto e pelo Mestre Scrum uma estimativa de tempo, que inicialmente so apenas

adivinhaes, ganhando preciso no decorrer do processo. Terminada a reunio a equipe de projeto cria o Backlog do Sprint, um quadro que vai ser atualizado diariamente, bastante parecido com o quadro do Product Backlog. Lembrando que o objetivo definir o que vai ser trabalhado e no como o trabalho vai ser feito.

6.3 Reunies do Scrum

No Scrum a Equipe Scrum realiza uma reunio de 15 minutos todos os dias pela manh. O propsito da reunio sincronizar o trabalho dirio de todos os membros da equipe, sempre sem se desviar do foco principal. Essa reunio curta, com todos os participantes em p, podendo caso necessrio, ser ampliada para 30 minutos.

Outra prtica interessante a cobrana de R$ 1,00 de cada participante que chegar atrasado. Pode at parecer engraado, mais ajuda criar foco e evitar que as reunies tenham que se prolongar devido ao atraso de alguns participantes. Existe tambm a reunio de reviso do Sprint, que ocorre no final de cada Sprint. uma reunio de quatro horas onde a equipe apresenta o trabalho desenvolvido para o Product Owner. Aps a reunio de reviso do Sprint, o Scrum Master faz uma reunio de retrospectiva com a Equipe. Em trs horas de durao ela visa encorajar a Equipe a revisar seu processo de trabalho, tendo em vista o framework e as prticas do Scrum, para ter um melhor desempenho na prxima iterao.

6.4 Escalabilidade Se houver necessidade pode ser montado mais de uma Equipe Scrum e realizar um trabalho em paralelo. Esta tcnica chama-se escalar o projeto. Projetos escalados necessitam de controles adicionais para acompanhar e sincronizar os trabalhos. Quanto s reunies dirias cada equipe realiza a sua, que sero seguidas de reunies de Scrum, com um representante de cada equipe. Antes de escalar um projeto deve ser preparada a infra-estrutura adequada para o projeto, utilizando o primeiro Sprint para tal implementao. Requisitos no funcionais para a construo da infra-estrutura de escalonamento devem ganhar maior prioridade no Product Backlog, j que estes itens precisam estar prontos para que o projeto possa ser escalonado.

7. CONCLUSO

O Scrum um mtodo bastante simples e objetivo, composto por poucas prticas, artefatos e regras e por isso fcil de aprender. No um processo prescritivo, sendo indicado para trabalhos complexos onde muito difcil prever acontecimentos futuros. Ainda oferece framework e conjunto de prticas que mantm a clareza do processo. O que permite que a equipe e outros interessados possam acompanhar o andamento do projeto e tomar as decises que forem necessrias para direcionar o projeto.

Aps estudarmos o desenvolvimento gil, e principalmente o Scrum, podemos ver o quanto benfico para o processo de construo de software tais tcnicas. O fato de apontarmos uma ou outra bastante complicado, sendo que dependendo dos objetivos da equipe de desenvolvimento, as vezes comum o trabalho em conjunto de mais de uma metodologia de desenvolvimento gil.

8. REFERNCIAS

MARTINS, Jos Carlos Cordeiro. Tcnicas para gerenciamento de projetos de software. Rio de Janeiro: Brasport, 2007, 432p.

SHORE, Jim; WARDEN, Shane. A Arte do Desenvolvimento gil. Alta Books, 2008, 408 p.

KNIBERG, Henrik. Scrum e XP direto das trincheiras. INFOQ. 2007, 141p.

SCHWABER, Ken. Guia do Scrum. ScrumAlliance. 2009, 22p.

Manifesto para o desenvolvimento gil de software. Disponvel em: <http://manifestoagil.com.br/index.html>. Acesso em 02 nov.

Doze princpios por trs do manifesto gil. Disponvel em: <http://manifestoagil.com.br/principios.html>. Acesso em 02 nov.