Você está na página 1de 40

POLICAMP FACULDADE POLITÉCNICA DE CAMPINAS

GERÊNCIA DE PROJETOS UTILIZANDO METODOLOGIA SCRUM BASEADA NO MODELO ÁGIL PARA DESENVOLVIMENTO DE SOFTWARE

MONOGRAFIA DE CONCLUSÃO DO CURSO DE PÓS-GRADUAÇÃO EM GERÊNCIA DE BANCOS DE DADOS

Campinas, 07 de março de 2009.

EVERSON JOSÉ DE FREITAS PEREIRA LEANDRO LUIZ COSTA BORDIGNON

ORIENTADORA: DELIA PERLA PATRICIA VELÁSQUEZ PINHO

GERENCIAMENTO DE PROJETOS COM UTILIZAÇÃO DE SCRUM

Trabalho de conclusão de curso apresentado como parte das atividades para obtenção do título de pós-graduado, do curso de Gerência de Banco de Dados da Faculdade Politécnica de Campinas - Policamp.

Metodologia: SCRUM

Gerência de Projetos baseada na metodologia de Desenvolvimento de Software SCRUM

Everson José de Freitas Pereira

Leandro Luiz Costa Bordignon

Profª orientadora: Delia Perla Patricia Velásquez Pinho

Campinas, 2009

ERRATA

Folha Linha Onde se lê Leia-se
Folha
Linha
Onde se lê
Leia-se

Autoria: Everson José de Freitas Pereira Leandro Luiz Costa Bordignon

Título: Gerência de Projetos utilizando metodologia SCRUM baseada no modelo ágil para desenvolvimento de software.

Trabalho de conclusão de curso apresentado como parte das atividades para obtenção do título de pós-graduado, do curso de Gerência de Banco de Dados da Faculdade Politécnica de Campinas - Policamp.

Os componentes da banca de avaliação, abaixo listados, consideram este trabalho aprovado.

Nome

Titulação

Assinatura

Instituição

1

2

3

Data da aprovação:

de

de

“Dedico este trabalho primeiramente a Deus, criador de todas as coisas, a minha família que esteve presente em todos os momentos de minha vida sejam eles bons ou ruins, aos meus amigos que me apoiaram e me ajudaram a levantar após todos os tombos que tivemos pelos caminhos e minha namorada por todo amor, carinho e compreensão”

“Dedico esta monografia à meu querido pai Sr. Luiz Antonio Bordignon, à minha querida mãe Sra. Mary Ap. Costa Bordignon, pela força, pelo grande incentivo, dedicação, amor e confiança nas minhas decisões, à minha querida esposa Elizandra Del Santo Bordignon que me ensinou que não há derrota que derrote quem nasceu para vencer, à minha família pelo incentivo e paciência e a todos os amigos que nunca deixaram de acreditar no meu sucesso.”

AGRADECIMENTOS

Agradeço a todos os que me ajudaram na elaboração deste trabalho: Sabrina Kerly Pandolfo, meus professores e colegas de sala.

Gostaria de expressar meus sinceros agradecimentos à todos aqueles que de alguma forma me deram forças para que a conclusão desta Monografia fosse possível: À Deus, meus pais, esposa, amigos e colegas, professores e minha orientadora.

“Bem antes de sentir sede lembre-se de cavar um poço.”

Proverbio Chines

Não é preciso ter olhos abertos para ver o sol,

nem é preciso ter ouvidos afiados para ouvir o trovão .

Para ser vitorioso você precisa ver o que não está visível”

Sun Tzu

RESUMO

O presente trabalho procura mostrar os preceitos, fundamentos e características essenciais da metodologia de gerência de projetos SCRUM. Para isso dissertaremos sobre os modelos tradicionais a gerência de projetos, os métodos ágeis e por fim descreveremos um case de sucesso.

O SCRUM é um processo iterativo e incremental, ele possui a fase de planejamento e a de encerramento e entre essas fases existe uma fase que representa um Time Box chamada de Sprint. Com a correta utilização dessa metodologia empresas conseguem se organizar e produzirem resultados melhores, dentro do prazo previsto reduzindo assim custos e melhorando metas.

Palavras-chave: Gerência de Projetos, SCRUM, Processos Ágeis.

ABSTRACT

The use of Agile practices in processes is a trend and a challenge. Many professionals are not favorable to this new challenge the tendency is to implement more agile processes with the traditional model.

The history of the software industry is showing that it is feasible and positive. The secret is in the process learn to adapt, because there is no perfect solution.

This is precisely the objective of this work, the present study the application of Agile Methodologies to manage software projects, particularly the SCRUM.

Keywords: Project Management, SCRUM, Agile Processes.

LISTA DE ILUSTRAÇÕES

Figura 1.1 Metodologia SCRUM

24

Figura 1.2 Ciclo do Sprint

25

Figura 1.3 Exemplo de Gráfico de BurnDown para Sprint

29

LISTA DE ABREVIATURAS E SIGLAS

CMM

Capability Maturity Model

SEI

Software Engineering Institute

XP

Extreme Programming

FDD

Feature Driven Development

MSF

Microsoft Solutions Framework

DSDM

Dynamic Systems Development Method

ROI

Return On Investment

SUMÁRIO

Errata

 

3

Agradecimentos

6

Resumo

 

7

Abstract

8

Lista de ilustrações

9

Lista

de

abreviaturas e siglas

10

Sumário

11

Introdução

13

1

Definição do tema

15

1.1 Introdução

15

1.2 Objetivo

15

1.3 Escopo do trabalho

15

2 Conceitos Basicos

2.1 Modelos Tradicionais

16

16

3 Objetivos

18

4 Justificativa

19

5 Metodos Ágeis

20

5.1 Origem

21

5.2 Manifésto Ágil

21

5.3 Principios

22

5.4 SCRUM

23

5.4.1

Fases do SCRUM

25

5.4.1.1

Pre-game

25

5.4.1.2

Game

26

5.4.1.3

Post-game

26

5.4.2.1

Product Owner

26

5.4.2.2 SCRUM

Team

 

27

5.4.2.3 SCRUM

master

27

5.4.3

Artefatos do SCRUM

27

5.4.3.1 Product Backlog

 

28

5.4.3.2 Sprint Backlog

28

5.4.3.3 Burndown Chart

29

5.4.4

Controle, execução e planejamento do sprint

30

5.4.4.1 Sprint Planning Meeting

31

5.4.4.2 Daily SCRUM

Meeting

31

Sprint

5.4.4.3 Review

Meeting

32

Sprint

5.4.4.4 Retrospective

32

5.5 Estudo do case Globo.com

33

5.4.1

Introdução

33

5.4.1

Inicio da implementação

33

5.4.1

O atual resultado

35

5.4.1

Conclusão sobre o projeto

37

Considerações finais

39

Referências bibliográficas

40

13

INTRODUÇÃO

Indústrias no mundo todo vêm buscando um diferencial em um mercado cada vez mais competitivo, partiram então para a adoção de programas de qualidade total e melhoria contínua.

Estes programas baseiam-se na afirmação de que a qualidade do produto é intimamente influenciada pela qualidade do processo empregado na produção.

Baseados

nestes

princípios surgiram modelos e normas específicos para

software, dos quais o mais conhecido internacionalmente é o modelo CMM (Capability Maturity Model), desenvolvido pelo SEI (Software Engineering Institute) (SEI-USA, 2008).

Seguindo o mesmo caminho de busca da excelência surgiram outros modelos e propostas para as mais variadas áreas de atuação, como o gerenciamento de projetos, que hoje está amplamente difundido nas organizações do mundo todo.

As Metodologias Ágeis (AGILE MANIFESTO, 2001), que são mais voltadas para o desenvolvimento de software, tem ganhado visibilidade e aprovação em várias equipes de desenvolvimento de software.

Dentre estas metodologias o SCRUM (CONTROL CHAOS, 2008) é uma das mais difundidas por ter maior foco em gerenciamento.

Os Métodos Ágeis têm como visão “um desenvolvimento de software interativo, evolutivo e incremental”, sendo mais dinâmicos e flexíveis, possuindo também mais proximidade e comunicação com o cliente. Eles trazem não só a mudança no ciclo

14

de vida do desenvolvimento, mas defende princípios a serem seguidos pela equipe, uma mudança de cultura (AGILE MANIFESTO, 2001). Este modelo Ágil está sendo considerado uma moderna substituição para o modelo tradicional.

15

1 DEFINIÇÃO DO TEMA

1.1 Introdução

Este trabalho visa estudar processos e ferramentas utilizados no gerenciamento do desenvolvimento de sistemas nas empresas. E a partir deste estudo propor soluções para o auxilio de equipes de desenvolvimento de software que optam por metodologias ágeis. Esta contribuição sugere o armazenamento e administração dos conhecimentos adquiridos e aprendidos ao longo do ciclo de vida de desenvolvimento do software, mantendo uma maior proximidade e comunicação com o cliente.

1.2 Objetivo

Estudo para apresentar processos e ferramentas para auxiliar na análise e desenvolvimento de software utilizando métodos ágeis de desenvolvimento especificamente o SCRUM.

1.3 Escopo do trabalho

O objetivo não é pesquisar e nem apresentar metodologias tradicionais para desenvolvimento de software, nem o de determinar qual o melhor modelo para desenvolvimento.

16

2 CONCEITOS BÁSICOS

2.1 Modelos Tradicionais

Em modelos tradicionais de desenvolvimento de software, muitos analistas buscam identificar todos os possíveis problemas e mudanças que o sistema possa vir a sofrer. Na maioria das vezes esse esforço torna-se totalmente desnecessário e apenas acarreta maior custo e tempo para realização do projeto. Esse tempo gasto pode ter sido desperdiçado para um projeto que nem chegou a seu fim, devido aos atrasos e mudanças constantes que o projeto sofreu no decorrer do seu ciclo. Isso ocorre por acreditar-se que um sistema deva ser totalmente planejado antes de iniciar o seu desenvolvimento, pois na fase de desenvolvimento, alterações de requisitos acarretariam um custo elevado, além da dificuldade em alterar os códigos já existentes.

Os modelos tradicionais de desenvolvimento muitas vezes são incompatíveis com a realidade de empresas ou com a real necessidade do projeto, devido à necessidade de um número maior de colaboradores, pois este modelo foca muito em análise e documentação. Os projetos tornam-se excessivamente demorados, e em muitos casos, ao serem redefinidos os requisitos, a documentação deve ser totalmente reformulada para atender as novas especificações, aumentando assim o tempo do desenvolvimento do projeto, o não cumprimento de prazos além de resultar em um custo maior. E quando finalizados, podem já não serem capazes de suprir as necessidades do cliente, pois essas possivelmente já foram alteradas.

17

Metodologias ágeis buscam unir o que há de funcionalidade entre o que era o desenvolvimento de software no início, onde não havia documentação e ciclos para análise, porém o desenvolvimento tornava-se um caos, e as burocráticas metodologias tradicionais.

Modelos baseados em métodos ágeis são principalmente úteis em casos onde há constantes mudanças nos requisitos por parte do cliente, pois pregam que o sistema deve ir se adaptando conforme exigências que são demandadas ao longo do ciclo de desenvolvimento. Em muitos casos o cliente não sabe o que pode esperar do sistema. Objetivo esse que pode ser atingido através de diferentes protótipos e versões de um mesmo sistema, com isso o cliente passa a entender melhor o que pode esperar do produto que está sendo desenvolvido.

18

3 OBJETIVOS

Como objetivo principal este trabalho visa apresentar o método de gerenciamento de projeto conhecido como SCRUM a ser implementado na análise, no desenvolvimento do software e na comunicação com o cliente e aplicar a metodologia proposta em uma empresa.

19

4 JUSTIFICATIVA

Em projetos orientados por Metodologias Ágeis, a informação obtida ao final do projeto é pouca, restringindo-se quase que somente ao produto final em si. O que leva a poder dizer que, em projetos de desenvolvimento de software, a maior parte da informação e do conhecimento armazenado está nos códigos e em seus comentários deixados pelos desenvolvedores.

Acredita-se que é necessário estudar maneiras para armazenar e melhor gerenciar conhecimentos e lições aprendidas no uso de métodos ágeis de desenvolvimento de software.

20

5 MÉTODOS ÁGEIS

Metodologias Ágeis para desenvolvimento possibilitam à equipe de desenvolvimento focar somente no software, e não no projeto e documentação. Geralmente, as metodologias ágeis contam com uma abordagem iterativa para especificação, desenvolvimento e entrega de módulos do sistema, ou seja, o projeto é dividido em partes, e foram criados principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento (SOMMERVILLE, 2007). Complementando, o autor ainda cita que “destinam-se a entregar um software de trabalho rapidamente aos clientes, que podem então propor novos requisitos e alterações a serem incluídos nas iterações posteriores do sistema”.

Para Martin Fowler (Fowler, 2003) afirma que para os métodos ágeis as mudanças são bem-vindas, pois tentam ser processos que se adaptam e se fortalecem com as mudanças. O autor ainda cita que a diferença mais evidente dessas metodologias para as tradicionais são que metodologias ágeis são menos centradas em documentação, normalmente enfatizando uma quantidade menor de documentos para uma dada tarefa.

As Metodologias Ágeis de desenvolvimento de software se propõe a construir softwares com maior produtividade e qualidade. Com isso as Metodologias Ágeis encaram os projetos sobre um novo paradigma e defendem a adoção de uma série de princípios e práticas.

Entre os paradigmas está à forma de encarar a mudança, esta é encarada como algo inevitável no projeto de software. Enquanto que as metodologias tradicionais

21

abordam o escopo como fixo devendo ser controlado o máximo possível para não haver mudanças; as Metodologias Ágeis abordam o escopo como manipulável e oferecem flexibilidade para sua mudança. Um dos princípios do Manifesto Ágil (AGILE MANIFESTO, 2001) diz que “Mudança de requisitos são bem vindas, mesmo em estágios tardios do desenvolvimento”.

“Processos Ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente.

Dentre as várias Metodologias Ágeis destacam-se: SCRUM, eXtreme Programming ou XP (XP-ORG, XP-COM, 2008), Lean Development (POPPENDIECK, 2008), Feature Driven Development ou FDD (FDD, 2008), MSF for Agile (MSDN, 2008), Crystal (ALISTAIR, 2008) e DSDM (DSDM-ORG, 2008).

Cada uma das metodologias tem suas peculiaridades e formas de encarar o desenvolvimento de software. A FDD, por exemplo, tem um foco muito maior em modelagem e análise e projeto orientado a objeto que outras metodologias.

5.1 Origem

O surgimento dessas metodologias deu-se pelo fato de seus idealizadores, com grande experiência em desenvolvimento de software, terem presenciado um grande número de projetos que não tiveram um retorno esperado ou que em muitas vezes acabaram sendo cancelado, por esse motivo tentaram então definir maneiras para acabar com o “caos” que alguns projetos de software acabam se tornando. Para isso eles identificaram as principais causas de fracasso de projetos e buscaram maneiras e práticas, muitas já conhecidas, para elaborar uma nova maneira para gerenciar projetos de software.

5.2 Manifesto Ágil

Em 2001, um grupo de pesquisadores auto denominados de Aliança Ágil (Agile Alliance), entre eles Martin Fowler, Alistair Cockburn, Jim Highsmith, Kent Beck, Mike Beedle entre outros, motivados pela suas experiências em desenvolvimento de

22

software, iniciaram então uma discussão sobre como desenvolver software de uma forma mais rápida e eficaz, orientado principalmente à simplicidade (Zanatta, 2004). Esta discussão resultou no chamado Manifesto Ágil, que em síntese aponta:

Desejamos descobrir melhores caminhos para desenvolver software fazendo e ajudando outros a fazerem. Valorizamos os indivíduos e interações através de processos e ferramentas; O desenvolvimento de software deve possuir uma documentação compreensiva; A colaboração do cliente e respostas às mudanças através de um plano

específico” (AGILE, 2008).

5.3 Princípios

De acordo com o Manifesto Ágil, seus princípios são:

A prioridade é satisfazer o cliente, entregando o software antecipadamente. Para isso o sistema deve ser entregue em módulos, onde a prioridade será estabelecida junto com o mesmo.

Mudanças de requisitos são bem vindas mesmo em projetos em atraso. As metodologias ágeis pregam que o software é do cliente, ou seja, ele tem o direito de solicitar modificações quando necessário, podendo assim, atender suas reais necessidades.

A entrega do software deve ser freqüente, semanalmente, quinzenalmente ou mensalmente, preferencialmente no menor prazo possível. Para isso as metodologias ágeis trabalham com desenvolvimento incremental, ou seja, o sistema é implementado a cada nova funcionalidade definida.

Especialistas de negócio e desenvolvedores devem trabalhar juntos ao longo de todo o projeto. Para isso, o cliente deve ser parte da equipe de desenvolvimento, estando disponível para esclarecer dúvidas e também acompanhar o projeto para verificar se suas necessidades estão sendo atendidas.

Os projetos devem ser desenvolvidos por pessoas motivadas e aos mesmos devem ser dados todo o apoio e confiança para realização do trabalho. Para isso, o

23

ambiente deve ser totalmente propício e agradável para a equipe sentir-se à vontade na realização de suas atividades.

O mais eficiente e eficaz método para transmitir informação dentro de uma equipe de desenvolvimento é conversas “cara-a-cara”. Isso pode ser auxiliado com reuniões diárias dentro do projeto.

A principal medida de progresso é o software funcionando.

Contínua atenção a excelência técnica aumentam a agilidade e o bom design.

Simplicidade a arte de maximizar o valor do trabalho. Para isso, a equipe deve desenvolver o mínimo necessário para atender a necessidade do cliente.

As melhores arquiteturas, requisitos e desenhos surgem de equipes auto organizadas.

Em intervalos regulares, o time reflete como se tornar mais eficiente, ajustando seu comportamento para atingir seus objetivos. Reuniões regulares devem ser feitas para avaliar se o trabalho esta sendo desenvolvido da melhor maneira possível.

5.4 SCRUM

SCRUM é um processo iterativo e incremental para desenvolvimento de qualquer tipo de produto ou gerenciamento de qualquer tipo de trabalho (CONTROL CHAOS, 2008).

O SCRUM possui um processo bem definido com uma fase de planejamento (Planning) e de encerramento (Closure) (SCHWABER, 1995), conforme ilustrado na Figura 1.1. Entre estas fases, há uma fase chamada de Sprint, este representa um Time Box dentro do qual um conjunto de atividades deve ser executado, com duração de 2 a 4 semanas, que ocorre várias vezes durante o desenvolvimento do projeto. São as iterações que caracterizam as Metodologias Ágeis.

24

24 Fonte: SCRUM Development Process (SCHWABER, 1995). Figura 1.1 – Metodologia SCRUM. O SCRUM mantém uma

Fonte: SCRUM Development Process (SCHWABER, 1995).

Figura 1.1 Metodologia SCRUM.

O SCRUM mantém uma lista de funcionalidades que deverão ser implementadas, essa lista é chamada de Product BackLog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily SCRUM. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar possíveis impedimentos, definir e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo.

25

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 Backlog seja todo atendido (CONTROL CHAOS, 2008). Ver ciclo na Figura 1.2.

atendido (CONTROL CHAOS, 2008). Ver ciclo na Figura 1.2. Fonte: SCRUM in five minutes (SOFTHOUSE, 2005).

Fonte: SCRUM in five minutes (SOFTHOUSE, 2005).

Figura 1.2 Ciclo do Sprint.

5.4.1 Fases do SCRUM

O SCRUM possui 3 grupos de fases. O Pre-game, Game e o Postgame, tendo ainda atividades para cada uma destas fases.

5.4.1.1 Pre-game

Pré-planejamento (pre-game): os requisitos definidos pelo Product Owner são descritos em um documento chamado backlog, posteriormente eles são priorizados e são feitas estimativas de esforço (tempo e custos descritos no Burndown Chart) para o desenvolvimento de cada requisito. O planejamento inclui também, entre outras atividades, a definição da equipe de desenvolvimento (Scrum Team), as

26

ferramentas a serem usadas, os possíveis riscos do projeto e as necessidades de treinamento. Finalmente é proposta uma arquitetura de desenvolvimento. Eventuais alterações nos requisitos descritos no backlog são identificadas, assim como seus possíveis riscos.

5.4.1.2 Game

Desenvolvimento (game): as muitas variáveis técnicas e do ambiente identificadas previamente são observadas e controladas durante o desenvolvimento. Ao invés de considerar essas variáveis apenas no início do projeto, co mo no caso das metodologias tradicionais, no SCRUM o controle é feito continuamente, o que aumenta a flexibilidade para acompanhar as mudanças. Nesta fase o software é desenvolvido em ciclos (sprints) em que novas funcionalidades são adicionadas. Cada um desses ciclos é desenvolvido de forma tradicional, ou seja, primeiramente faz-se a análise, em seguida o projeto, implementação e testes.

5.4.1.3 Post-game

Pós-planejamento (post-game): após a fase de desenvolvimento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase são feitas as etapas de integração, testes finais e documentação.

5.4.2 Papéis no SCRUM

O SCRUM define basicamente apenas 3 papéis, o Product Owner, SCRUM Master e SCRUM Team.

5.4.2.1 Product Owner

Traduzido literalmente significa Dono do Produto, pode ser ainda chamado como Stakeholder. É o cliente do projeto, tipicamente um usuário chave que representa os interesses de todos os envolvidos com o software. É quem define os

27

requisitos que compõem o Product Backlog. Deve estar acessível à equipe, tem a responsabilidade de fazer a validação do produto ao final de cada Sprint.

5.4.2.2 SCRUM Team

É a Equipe responsável pelo desenvolvimento do produto de acordo com as

prioridades definidas pelo Product Owner.

Não há uma definição de papéis formal como programador, testador, arquiteto ou analista, o que não impede que haja estas funções. Todos trabalham juntos para completar as funcionalidades que todos conjuntamente se comprometeram para o Sprint.

A equipe deve ser idealmente pequena, de 5 a 9 pessoas, porém pode ser maior. Umas das principais abordagens para se trabalhar com equipes maiores é através do SCRUM of SCRUMs.

5.4.2.3 SCRUM master

É o papel do gerente do projeto, mas pode ser exercido por qualquer membro

da equipe. Responsável por garantir o trabalho da equipe através da remoção de obstáculos identificados e da proteção da equipe contra interferências externas.

Deve disseminar e aplicar os valores e práticas do SCRUM na equipe.

5.4.3 Artefatos do SCRUM

Os principais artefatos definidos pelo SCRUM são o Product Backlog, que é a lista de funcionalidades definidas pelo Product Owner. O Sprint Backlog que é uma lista dos itens do Product Backlog que foram priorizados para serem atendidos no Sprint. E o Burndown Chart que consiste de um gráfico para acompanhamento diário do Sprint quanto à velocidade do time pelo consumo diário de horas. Esses artefatos são melhor descritos a seguir.

28

5.4.3.1 Product Backlog

É uma lista de funcionalidades desejadas para o produto. É definida pelo

Product Owner. Ela não precisa ser completa desde o início do projeto, podendo ser complementada com novas funcionalidades durante o andamento do projeto, à medida que o conhecimento do produto vai aumentando.

Normalmente contêm no início do projeto os itens necessários para começar o primeiro Sprint. É uma lista dinâmica, já que pode sofrer alterações durante todo o andamento do projeto, como o cancelamento de itens, a mudança de prioridade, ou da própria descrição da funcionalidade.

O SCRUM não define como esta lista é formada, podendo ser usadas várias

técnicas de captura de requisitos. Uma das técnicas utilizadas é tratar cada item da lista como uma história, ou User Stories como no XP (MOUNTAIN, 2008).

O Product Owner deve priorizar os itens desta lista, e a equipe deve estimar

cada item para definirem o trabalho, ou funcionalidades que serão contempladas no Sprint.

5.4.3.2 Sprint Backlog

O Sprint Backlog é uma lista de tarefas que o SCRUM Team se compromete a

fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção

da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá- los.

Durante um Sprint, o SCRUM Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do

29

trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.

É interessante ter pelo menos três Sprints priorizados e estimados para que o time não fique ocioso na transição entre um Sprint e outro.

5.4.3.3 Burndown Chart

O gráfico de Burndown é 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. A soma de horas das tarefas determina a quantidade de horas necessárias para finalizar o Sprint, e conforme tarefas vão sendo concluídas ao longo dos dias do Sprint, o gráfico vai descendo até atingir o número de horas zero. No eixo Y encontra-se o número de horas total estimado para o Sprint e no eixo X os dias do Sprint, de acordo com o seu tamanho. Ver Figura 1.3.

do Sprint , de acordo com o seu tamanho. Ver Figura 1.3. Figura 1.3 – Exemplo

Figura 1.3 Exemplo de gráfico de BurnDown para Sprint.

Através deste gráfico é possível visualizar a velocidade da equipe no Sprint e verificar se no ritmo de “consumo de horas” atual a equipe irá conseguir terminar

30

todas as tarefas dentro do Sprint. O gráfico pode oscilar tanto para cima quanto para baixo. Oscilações para cima podem indicar alguma tarefa que foi mal estimada, cujo número de horas está consumindo mais que o planejado inicialmente ou tarefas novas que entraram ao longo do Sprint. Oscilações para baixo com queda muito brusca, geralmente indica uma ou mais tarefas que foram mal estimadas e que consumiram um número menor de horas do que foi planejado.

5.4.4 Controle, execução e planejamento do sprint

Durante o Sprint cada funcionalidade do software é trabalhada de forma a ser completada dentro do mesmo Sprint. Em se tratando de software, a funcionalidade é planejada, projetada, codificada e testada gerando software funcionando. Uma vez estabelecida à data final não deve ser alterada para que as métricas de velocidade do time sejam consistentes.

5.4.4.1 Sprint Planning Meeting

O Sprint Planning Meeting é uma reunião na qual estão presentes o Product

Owner, o SCRUM Master e todo o SCRUM Team, bem como qualquer pessoa

interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product

Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

Coletivamente, o SCRUM Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O

31

sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe SCRUM se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer.

5.4.4.2 Daily SCRUM Meeting

Reunião que ocorre diariamente preferencialmente no mesmo local, no mesmo horário e fora do ambiente de trabalho. Com todos em pé, deve ser rápida e objetiva, e durar não mais que 15 minutos. É objetivo desta reunião disseminar conhecimentos, identificar impedimentos e priorizar o trabalho do dia, por isso o ideal é fazê-la pela parte da manhã. É função do SCRUM Master tratar os impedimentos identificados o mais rápido possível.

Todos do time devem participar da reunião, e outras pessoas também podem participar, porém apenas como ouvintes.

Não é objetivo dessa reunião resolver problemas. Caso algum problema seja levantado, este deve ser tratado fora da reunião apenas com as pessoas diretamente envolvidas no problema ou com aqueles que podem auxiliar na solução.

Durante a reunião três perguntas devem ser respondidas por cada um dos membros do time:

O que foi feito desde ontem?

O que você planeja fazer hoje?

Há algum impedimento no seu caminho?

Através das respostas destas questões o time consegue ter uma boa noção do andamento do projeto quanto ao que já foi feito e o que ainda falta fazer. Por ém a

32

Daily SCRUM não deve ser tratada como um relatório de status para o SCRUM Master, mas como compromissos assumidos perante a equipe.

5.4.4.3 Sprint Review Meeting

Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião,

o

SCRUM Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem

o

formato de um demo das novas funcionalidades.

Os participantes do Sprint Review tipicamente incluem o Product Owner, o SCRUM Team, o SCRUM Master, gerência, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint.

5.4.4.4 Sprint Retrospective

Após a finalização do Sprint e antes da próxima reunião de planejamento de Sprint a equipe se reúne com o Product Owner, SCRUM Master e outros interessados para uma retrospectiva sobre o Sprint finalizado.

O principal objetivo é identificar pontos de melhorias e ajustes necessários principalmente nas práticas do SCRUM.

Há várias maneiras de se conduzir uma reunião de retrospectiva, mas é importante que ela seja objetiva e curta, com duração aproximada de 30 minutos.

33

5.5 Estudo do case Globo.com

5.5.1 Introdução

No início como na maioria das empresas brasileiras sem um gestor de projetos era tudo bem parecido com as histórias tradicionais, empresas que gastam uma enorme quantidade de dinheiro com uma consultoria para desenhar um processo de desenvolvimento de software. Poucos projetos eram entregues nas datas acordadas e muitos deles falhavam ou não satisfaziam as necessidades dos clientes. Contratar uma grande consultoria de software parecia ser uma boa tentativa de arrumar as coisas, mas o resultado do trabalho foi um documento que descrevia um processo com algumas centenas de páginas que devia ser seguido à risca, isso sem contar as dúzias de documentos padrão para todos os tipos de requisição e comunicação que se possa imaginar. Dezenas de páginas descreviam quem deveria falar com quem e quem entrega qual documento em qual momento. O processo foi feito para lidar com todas as complexidades, burocracias e exigências que nós mesmos criamos dentro da empresa.

5.5.2 Inicio da implementação

As metodologias ágeis na Globo.com vieram de baixo para cima. Tudo começou com um movimento tímido entre alguns desenvolvedores de aplicar práticas de desenvolvimento ágil do XP (eXtreme Programming) nos projetos. A porta de entrada foi à oportunidade de melhorar a qualidade dos nossos sistemas, pois tínhamos uma incidência muito grande de bugs em produção e poucas aplicações eram testadas adequadamente.

Com todas as dificuldades que tínhamos para nos organizar nesse caos, conseguimos acordar que faríamos entregas constantemente de duas em duas semanas, e que dentro desse período não haveria nenhuma mudança no planejamento, que seria feito no início de cada período. Antes de iniciar cada ciclo de desenvolvimento, os clientes tinham a oportunidade de escolher quais seriam as prioridades da equipe de desenvolvimento nas duas semanas seguintes. Sem

34

perceber eles haviam aceitado a idéia de desenvolvimento iterativo e jogo do planejamento, e nós teríamos alguma organização e paz para fazer o trabalho.

Em meados de Julho de 2007 a empresa decidiu bancar um curso de SCRUM com o Boris Gloger para alguns membros da nossa equipe e o resultado foi ótimo! Na semana seguinte mesmo já começou a mudança. Todos voltaram com um novo gás e dispostos a mudar a empresa. Lembro-me nessa época de alguém ter falado a seguinte frase: “Agora eu acredito em desenvolvimento de software”.

Desse momento em diante passamos a aplicar SCRUM no nosso time de desenvolvimento. O problema é que estávamos no meio de um projeto feito da forma “tradicional” (leia-se waterfall) e toda a fase de análise e especificação já tinha sido concluída. Tudo indicava que seria melhor esperar uma oportunidade melhor para começarmos a adoção, só que nós sabíamos que tinha que ser “naquela hora ou nunca” e então começamos a desenvolver nosso principal projeto usando práticas do SCRUM.

Quase ninguém na equipe havia trabalhado com desenvolvimento ágil, então achamos que seria mais fácil não falar de SCRUM, XP ou qualquer nome diferente. Simplesmente começamos a praticar e durante o desenvolvimento o time foi introduzido às práticas e à forma de trabalhar. As regras são muito simples e por isso foi muita fácil de adotá-las. Ao longo dos cinco Sprints o time foi amadurecendo, entendendo como trabalhar e também foram nascendo algumas adaptações necessárias ao funcionamento do projeto dentro da estrutura da empresa. Por exemplo, tivemos que resolver como seriam criadas as histórias e como isso seria integrado com o nosso sistema de tracking, como integrar com a equipe de QA, como colocar os projetos em produção e diversas outras questões.

Hoje, o Globo Vídeos 4.2, que é o tal projeto, está em produção. Para os padrões da empresa na época, ele foi um projeto surpreendente do ponto de vista de qualidade. Na versão anterior do Globo Vídeos (4.0) foi necessária uma janela de mais de 24 horas para colocá-lo no ar e ela aconteceu aos trancos e barrancos. Além disso, a semana seguinte foi infernal, com muitos bugs para serem corrigidos e várias mudanças arriscadas durante o dia para corrigi-los. Já a versão 4.2 foi

35

colocada em produção em pouco mais de uma hora e na primeira semana nem ouvíamos falar do Globo Vídeos. Nem parecia que um dos sites de maior audiência da empresa havia sido quase totalmente substituído por um totalmente novo e com grandes mudanças arquiteturais!

Ao mesmo tempo em que acontecia o Globo Vídeos, o site de inscrições para o Big Brother Brasil 8 foi desenvolvido de cabo a rabo usando SCRUM, da forma estrita, como está nos livros. O projeto simplesmente não teria sido feito considerando-se a complexidade e o tempo disponíveis. No final, ele foi um sucesso e além de ter sido entregue no prazo houve uma percepção de muita qualidade por todos - mais uma prova viva de que o SCRUM era uma possível resposta para os nossos problemas.

Esses dois projetos serviram de aprendizado e base para a estruturação de todos os projetos seguintes na empresa. O sucesso deles foi o grande responsável para ganharmos carta branca e começarmos a implementação de SCRUM em massa na Globo.com.

5.5.3 O atual resultado

Após um ano de metodologias ágeis a empresa já está bem mais madura nas práticas e já temos mais de 10 times usando SCRUM.

No fim do ano passado, após um treinamento para pessoas de todas as áreas da empresa, começamos todos a usar SCRUM da forma estrita (obviamente houve uma curva de aprendizado até todos estarem mais seguros e praticando melhor). Hoje, alguns meses depois, já é possível perceber diferenças entre alguns times, que acabaram se adaptando de forma diferente por terem problemas e questões diferentes.

Sobre a duração dos Sprints, estamos trabalhando com duas semanas porque achamos que quatro semanas é muito tempo e poderíamos acabar nos tornando lentos na resposta às mudanças. Além do mais já vínhamos usando iterações de duas semanas desde que começamos a adotar desenvolvimento iterativo e continuar com este tamanho de ciclo seria mais fácil para nós.

36

Em virtude disso, como temos a metade do tempo de desenvolvimento recomendado pelo SCRUM, decidimos que só precisamos da metade do tempo de planejamento. A recomendação é que o Sprint Planning tenha 8 horas para um Sprint de 4 semanas, e como nosso Sprint é de 2 semanas decidimos fazer um planning de 4 horas. As outras reuniões (Sprint Review, Retrospective, Daily SCRUM, etc) permaneceram com a mesma duração, lembrando que essa duração não é obrigatória, mas sim um limite para não ficarmos discutindo as coisas indefinidamente.

Nossos Sprint Plannings têm melhorado constantemente. No início sempre estourávamos o tempo da reunião discutindo um monte de coisas que não eram necessárias, mas agora já estamos mais focados e a reunião tem funcionado bem melhor. As estimativas com Planning Poker também evoluíram um bocado e em várias ocasiões todos os desenvolvedores colocam o mesmo número sem combinar, o que indica que estamos evoluindo na sensação de esforço necessário para desenvolver as coisas.

A equipe, que antes era só de desenvolvedores, agora tem também um designer, um arquiteto de informação, um especialista em programação client-side (JavaScript/CSS/HTML), uma pessoa da equipe de testes e homologação e uma pessoa focada em negócios e ROI (Return On Investment) (que é o Product Owner). Todas essas pessoas sentam próximas umas das outras, e isso efetivamente aumentou muito a produtividade delas e o ritmo do projeto. Aos poucos todo o conhecimento específico está sendo difundido entre os membros da equipe. Infelizmente nem todas as equipes estão completas dessa forma por diferentes motivos (espaço físico, distância entre os prédios da empresa, etc.), mas estamos trabalhando duro para resolver isso. Inclusive temos uma reunião chamada de SCRUM of SCRUMs, onde todos os SCRUM Masters se reúnem para se ajudarem a resolver esses tipos de problemas, que muitas vezes são comuns a várias equipes.

Já que o SCRUM não fala nada sobre práticas de desenvolvimento de software, acabamos adotando muitas práticas do XP. Isso fica por conta de cada equipe e cada uma faz o que julga mais adequado para entregar o melhor software possível, mas muitas equipes usam desenvolvimento guiado por testes, integração contínua,

37

programação em par, metáforas e várias outras práticas de eXtreme Programming com muito sucesso. De fato a integração entre SCRUM e XP funciona muito bem.

Temos na empresa uma equipe que é especializada no ambiente de produção e por isso colocar os sistemas no ar fica fora do nosso Sprint. Quando nosso Sprint termina, entregamos um pacote fechado, testado, homologado e pronto para ser colocado em funcionamento, e então agendamos uma data e hora para que a subida seja feita acompanhada por um ou mais desenvolvedores do time. Todas as alterações de arquitetura e ambiente de deployment, quando necessárias, são feitas dentro do Sprint, somente as mudanças que envolvem risco de indisponibilidade nos sistemas que são feitas numa data que agendamos após o termino do Sprint, geralmente no meio da madrugada (as famosas “janelas”). Alguns times, por terem menos criticidade no seu ambiente de deployment, consideram que um Sprint está concluído quando o software está no ar, e o seu último dia do Sprint sempre é uma subida para produção. Como já havia falado anteriormente, cada time se adaptou para funcionar da melhor forma possível de acordo com suas peculiaridades.

E por último, nossas retrospectivas têm sido uma base forte para adaptações no processo e na forma de trabalhar. Para mim foi um aprendizado enorme quando o Boris Gloger veio na Globo.com e acompanhou uma retrospectiva inteira do nosso time - ele deu excelentes toques importantíssimos. A última retrospectiva em especial, que aconteceu após uma grande entrega de um projeto interno, mostrou nitidamente a evolução do time e como estamos efetivamente conseguindo aos poucos achar e resolver todos os problemas. Estamos evoluindo devagar, mas constantemente e já temos várias equipes com um bom nível de maturidade e evolução na empresa.

5.5.4 Conclusão sobre o projeto

Não só o SCRUM como todas as metodologias ágeis dependem muito das pessoas. Na Globo.com não foi diferente e as pessoas certas fizeram toda a diferença. Também existe o outro lado da moeda: algumas pessoas simplesmente não se adaptam a essa forma de trabalhar. Desde o início da adoção nós já perdemos muitos desenvolvedores e acredito que ainda perderemos muito mais.

38

Por conta disso, nossos processos seletivos se tornaram mais exigentes e demorados, porque agora não só precisamos de pessoas que sejam ótimas tecnicamente, mas também que tenham um perfil adequado para trabalhar no tipo de ambiente que criamos dentro da empresa.

Além disso, é essencial que haja apoio da gerência e “carta branca” para que as equipes de desenvolvimento tenham a autonomia necessária para levar o projeto da forma correta. Como estes “processos” são muito diferentes dos tradicionais, algumas empresas acabam fazendo modificações antes do tempo por puro medo ou falta de conhecimento, que acabam atrapalhando ou até mesmo arruinando a adoção de uma metodologia ágil. Ainda em relação aos times de desenvolvimento, é essencial que os líderes de equipe (ou SCRUM Masters no caso do SCRUM) sejam muito bem capacitados e que conheçam profundamente as práticas/regras/princípios, não só para que tenham capacidade de argumentação com a empresa, mas também para que não façam adaptações que violem os princípios básicos das metodologias ágeis.

Por fim, acho que ainda estamos muito longe do ideal e vejo muitas oportunidades de melhoria na nossa forma de trabalhar, mas o mais importante é que agora acreditamos que estamos no caminho certo.

39

CONSIDERAÇÕES FINAIS

Através da correta utilização da metodologia SCRUM é possível organizar todos os processos de uma empresa, seja ela de desenvolvimento de software ou qualquer outro ramo, permitindo assim uma economia considerável em custos, além disso, cumprir sempre os prazos de entregas determinados, com isso a empresa consegue atingir facilmente suas metas dentro do tempo especificado e dos gastos previstos no inicio do projeto.

40

REFERÊNCIAS BIBLIOGRÁFICAS

BECKER, Fernando, FARINA, Sérgio, SCHEID, Urbano. Apresentação de trabalhos escolares. Orientação para datilografia e digitação. Porto Alegre:

Multilivro, 2000.

CHEMIN, Beatriz Francisca. Guia Prático da UNIVATES para trabalhos acadêmicos. Lajeado: UNIVATES, 2005.

FARINA, Sérgio. Referências bibliográficas e eletrônicas. São Leopoldo:

UNISINOS, 1997.

ROCHA, José Antonio Meira da. Modelo de Trabalho de Conclusão de Curso

(TCC). Modelo de documento digital do programa OpenOffice 2.0 disponível em

2006-06-12a.sxw>. Acesso em: 12 jun. 2006.

THUMS, Jorge. Acesso à realidade: técnicas de pesquisa e construção do conhecimento. Porto Alegre: Sulina/Ulbra, 2000.