SlideShare uma empresa Scribd logo
DESENVOLVIMENTO ÁGIL: UMA ABORDAGEM SOBRE O SCRUM


                                                           Klaus Fischer Gomes Santana1
                                                                  Rafael Araújo de Freitas2




RESUMO

           A metodologia Scrum assume-se como extremamente ágil e flexível.
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 participação ativa dos clientes, o
rendimento do projeto aumenta e os requisitos e a solicitação de alteração passa a
ser atendido mais rapidamente. As metodologias de desenvolvimento ágil vem se
destacando a cada dia, porém essas ainda são pouco difundidas no meio
acadêmico. O objetivo deste artigo, além de difundir esse assunto e servir de apoio
para futuras pesquisas, é demonstrar de maneira simples e objetiva, o
funcionamento, as características, o vocabulário e a aplicação da metodologia
Scrum em um ambiente de trabalho.

Palavras-chave: Engenharia de              Software,    Métodos     de    Desenvolvimento,
Desenvolvimento Ágil, SCRUM.



1 INTRODUÇÃO


            Um desafio constante da área de Engenharia de Software é melhorar o
processo de desenvolvimento de software. Mesmo com a constante evolução de
métodos, técnicas 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 rápida, mas
com qualidade. Esse produto pode ser obtido utilizando métodos ágeis e padrões
organizacionais e de processos.
            O desenvolvimento ágil é uma filosofia. É uma maneira de pensar sobre
produção de software. A decisão canônica desta maneira de pensar é o “Manifesto
Ágil” (Becket al., 2001), um conjunto de 4 valores (figura 1) e 12 princípios (figura 2).
1
    Graduando em Análise e Desenvolvimento de Sistemas. E-mail: klausfgsantana@gmail.com
2
    Graduando em Análise 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: Princípios do manifesto ágil
          Fonte: http://manifestoagil.com.br/principios.html

          Nos últimos anos, métodos á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 agências governamentais.
          Neste Artigo abordaremos a Metodologia de Desenvolvimento Ágil Scrum,
veremos como se dá sua implantação no processo de desenvolvimento de software.
2 ENTENDENDO O SCRUM


                        Estamos crescendo tão rápido que parece que sempre precisamos de mais
                        umas regrinhas aqui, mais um pouco de papel ali... precisamos ter muito
                        cuidado, pois cada novo nível gerencial, cada nova regra ou formulário
                        atrapalha. Eles acabam com a mágica, cortam a eletricidade da inspiração.
                        Com restrições em excesso, você pára de pensar no que pode fazer e
                        começa a pensar no que não dá para fazer (Cirque Du Soleil – A reinvenção
                        do Espetáculo; Ed. Campus; Elsevier).


          As raízes do Scrum estão num artigo que sumariza as 10 melhores
práticas em empresas japonesas, escrito por Takeuchi e Nonaka, cujo título é “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
reuniões de equipes que praticam a autodireção e a adaptabilidade.
          A palavra Scrum não é uma sigla e nem tem tradução para o Português.
O termo Scrum é o nome usado para a reunião de jogadores, no jogo de Rugby,
quando eles se organizam em círculo para planejar a próxima jogada. É uma forma
de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma
visão de longo prazo, que é ganhar o jogo.
          Desenvolvimento de produtos complexos ocorre em situações de muitas
mudanças. Quanto mais próximo do limite do caos a equipe conseguir trabalhar,
porém 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 são necessários. A evolução favorece aqueles
que se expões e aceitam as mudanças e estão preparados para se adaptarem a
essas. Nesse caso é necessária uma abordagem gerencial de projetos que permita
às equipes operarem de forma flexível e adaptável num ambiente complexo, usando
processos imprecisos.
          Scrum é um processo bastante leve para gerenciar e controlar projetos de
desenvolvimento de software e para criação de produtos, além 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 negócio.
A maioria dos métodos e técnicas de gerenciamento de projetos são
bastante prescritivas, isso força as pessoas a seguirem uma sequência predefinida
de passos, com pouca flexibilidade para mudanças. Tradicionalmente, os projetos de
construção de software seguem um ciclo envolvendo captura de requisitos, análise,
projeto técnico (design), programação, teste e implantação com cada estágio sendo
completado antes que o próximo seja iniciado.
           Contudo, são características importantes do Scrum: a adaptabilidade e o
empirismo. Sua abordagem é oposta a do modelo em cascata, inicia-se a análise
assim que alguns requisitos estiverem disponíveis, assim que alguma análise tiver
sido feita começam os trabalhos de projeto técnico (design), e assim por diante.
           Em outras palavras, o projeto trabalha num pedaço pequeno de cada vez.
Esta abordagem pode ser chamada de iterativa, e cada iteração consiste na captura
de requisitos, um pouco de análise, um pouco de design, mais alguma programação
e testes, culminando num ciclo iterativo com várias entregas conforme podemos ver
na figura 3.




                     Figura 3: Ciclo de iterações de sprint de um projeto.


3 O PRODUCT BACKLOG


           O projeto no Scrum começa com uma visão, que pode ser vaga no
princípio, talvez expressa em termos de marketing ou uma visão técnica, e que
depois ficará mais clara à medida que o projeto evoluir.
A partir da visão é definida uma lista de itens priorizados, composta por
requisitos e funcionalidade que precisam ser construídos para que a visão seja
concretizada. Estamos falando do Product Backlog).
           O Product Backlog é o coração do Scrum. É basicamente uma lista de
requisitos, histórias, 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 técnica 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 começará a gerar valor e lucro muito mais cedo. O
Scrum busca este objetivo produzindo uma versão que pode ser potencialmente
distribuída 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,
poderíamos construir, de forma interativa, um produto que tenha estes 20% das
freatures logo no início do projeto.
4 PAPÉIS NO SCRUM


           O Scrum trabalha basicamente com três papéis: o Product Owner, o
Scrum Master e a Equipe Scrum.
O Product Owner é responsável 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 posição similar à ocupada pelo Product
Owner. É responsável por forçar os valores e as práticas do Scrum, remover
obstáculos, ensinar o processo a todas as pessoas, implementar o Scrum e garantir
que todas as pessoas sigam as regras e as práticas do Scrum. O Scrum Master é
um líder e não 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 através do Scrum;
           • Melhorar a vida da Equipe Scrum, facilitando a criatividade através do
                  empowerment;
           • Manter a informação sobre o progresso da Equipe Scrum sempre
                  atualizado e disponível para todos os interessados.
            A Equipe Scrum é o grupo de pessoas responsável por desenvolver ou
construir as funcionalidades do produto. As equipes são autogerenciadas, auto-
organizadas e multifuncionais. Geralmente, a equipe é composta por 5 a 10
membros (o recomendado são sete pessoas) e deve ser multifuncional, composta
por indivíduos com diferentes especializações. 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 três fases: pré-game, game e pós-game. A
primeira e última fases consistem em processos definidos, onde todos os processos,
mais as entradas e as saídas, são bem definidos. Os conhecimentos sobre como
realizar estas fases são explícitos e podem compreender uma ou mais iterações.
          No Pré-game temos duas partes: planejamento e arquitetura. No
planejamento é definido um novo release, com base nas informações 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 conceitualização e análise. No
caso da evolução de um produto já existente, esta fase consiste numa análise
limitada. Na arquitetura os itens do Backlog são projetados com vistas à
implementação. Esta fase inclui definições e modificações na arquitetura e design de
alto nível (KNIBERG,2007).
          Na fase intermediária do game o processo é empírico. A maioria dos
processos nesta fase são 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 é
construído em múltiplas iterações chamadas no Scrum de Sprint. O produto pode
ser modificado a qualquer momento durante o planejamento do Sprint, bem como
durante o Sprint. Essas mudanças ocorrem por conta da complexidade, ações da
decorrência, prazo, qualidade, pressão de custo etc. Esta fase é composta dos
seguintes macroprocessos:
   •   Reuniões com as equipes para rever o planejamento dos releases;
   •   Revisão dos padrões com os quais o sistema precisa ser compatível e fazer
       os ajustes necessários;
   •   Realização dos Sprints até que o produto esteja pronto para distribuição.
          Quando a gerência decide que as variáveis de tempo, concorrência de
mercado, requisitos, custos e qualidade estão adequadas para distribuir o produto,
ela declara que o release está fechado e a fase de pós-game começa. Nesta fase o
produto é preparado para distribuição, incluindo integração, testes adicionais,
documentação de usuário, preparação de material para treinamento e de marketing,
dentre outras coisas.
6 PRÁTICAS 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 sequência em que os itens serão trabalhados, bem como para
adicionar ou retirar itens.
              Os requisitos não necessitam ser precisos nem estarem descritos de
forma completa e detalhada, estes requisitos serão obtidos com os futuros usuários
do produto e com pessoas do negócio. Os principais itens, ou seja, os de maior
importância, vão 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 além da iteração seguinte, isto pode ser uma perda de tempo, mesmo
porque o conteúdo de cada Sprint é sempre definido nas reuniões de planejamento
que precedem cada Sprint.


6.2 Sprint


              Um Sprint é um conjunto de atividades de desenvolvimento conduzidas
num período 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 avaliação de riscos e no grau de volatilidade dos
requisitos.
              Durante um Sprint a equipe desenvolve as seguintes atividades:
          • Desenvolvimento (análise, projeto técnico – design, programação,
                testes e documentação);
          • Empacotamento (criação de programas executáveis);
          • Revisão (revisão do que foi feito, correção de problemas);
          • Ajustes (consolidar as informações obtidas na revisão e realizar as
                mudanças necessárias).
              Ao final do período do Sprint, normalmente em 30 (trinta) dias, é
produzido uma versão do produto que pode potencialmente ser distribuída para o
mercado. Esta versão deve prover algum valor para o negócio.
A vantagem desse curto período é que ele permite ao Product Owner, o
cliente, repriorizar os itens do Product Backlog com base no resultado do Sprint
anterior. A importância disto é que o projeto sempre estará produzindo algo que
possa ser utilizado no negócio.
            Todo Sprint começa com uma reunião de planejamento, trabalhando de
forma colaborativa o Product Owner e a Equipe Scrum para decidirem os itens da
próxima iteração. Os objetivos básicos desta reunião são:
           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 reunião de planejamento não 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
dúvidas quanto ao conteúdo, propósito, significado e intenções. Quando a equipe
achar que tem informações suficientes, seleciona os itens que acredita que poderá
desenvolver durante a iteração.
            Nas próximas 4 (quatro) horas é planejado o Sprint, já que é a equipe que
vai gerenciar seu próprio trabalho. É feita também pelo Dono do Produto e pelo
Mestre     Scrum   uma   estimativa   de   tempo,    que   inicialmente   são      apenas
“adivinhações”, ganhando precisão no decorrer do processo. Terminada a reunião 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 não como o trabalho vai ser feito.


6.3 Reuniões do Scrum


            No Scrum a Equipe Scrum realiza uma reunião de 15 minutos todos os
dias pela manhã. O propósito da reunião é sincronizar o trabalho diário de todos os
membros da equipe, sempre sem se desviar do foco principal. Essa reunião é curta,
com todos os participantes em pé, podendo caso necessário, ser ampliada para 30
minutos.
Outra prática interessante é a cobrança de R$ 1,00 de cada participante
que chegar atrasado. Pode até parecer engraçado, mais ajuda criar foco e evitar que
as reuniões tenham que se prolongar devido ao atraso de alguns participantes.
           Existe também a reunião de revisão do Sprint, que ocorre no final de cada
Sprint. É uma reunião de quatro horas onde a equipe apresenta o trabalho
desenvolvido para o Product Owner.
           Após a reunião de revisão do Sprint, o Scrum Master faz uma reunião de
retrospectiva com a Equipe. Em três horas de duração ela visa encorajar a Equipe a
revisar seu processo de trabalho, tendo em vista o framework e as práticas do
Scrum, para ter um melhor desempenho na próxima iteração.


6.4 Escalabilidade


           Se houver necessidade pode ser montado mais de uma Equipe Scrum e
realizar um trabalho em paralelo. Esta técnica chama-se escalar o projeto. Projetos
escalados necessitam de controles adicionais para acompanhar e sincronizar os
trabalhos. Quanto às reuniões diárias cada equipe realiza a sua, que serão seguidas
de reuniões 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 implementação.
Requisitos não funcionais para a construção 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. CONCLUSÃO


           O Scrum é um método bastante simples e objetivo, é composto por
poucas práticas, artefatos e regras e por isso é fácil de aprender. Não é um
processo prescritivo, sendo indicado para trabalhos complexos onde é muito difícil
prever acontecimentos futuros.
           Ainda oferece framework e conjunto de práticas que mantém a clareza do
processo. O que permite que a equipe e outros interessados possam acompanhar o
andamento do projeto e tomar as decisões que forem necessárias para direcionar o
projeto.
Após estudarmos o desenvolvimento ágil, e principalmente o Scrum,
podemos ver o quanto é benéfico para o processo de construção de software tais
técnicas. 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. REFERÊNCIAS


MARTINS, José Carlos Cordeiro. Técnicas 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. Disponível em:
<http://manifestoagil.com.br/index.html>. Acesso em 02 nov.


Doze princípios por trás do manifesto ágil. Disponível em:
<http://manifestoagil.com.br/principios.html>. Acesso em 02 nov.

Mais conteúdo relacionado

Mais procurados

Modelo de Projeto de Pesquisa
Modelo de Projeto de PesquisaModelo de Projeto de Pesquisa
Modelo de Projeto de Pesquisa
José Antonio Ferreira da Silva
 
Artigos Científicos: Análise e Elaboração
Artigos Científicos: Análise e ElaboraçãoArtigos Científicos: Análise e Elaboração
Artigos Científicos: Análise e Elaboração
Carlos Fernando Jung
 
Meios de Contraste em Tomografia Computadorizada
Meios de Contraste em Tomografia ComputadorizadaMeios de Contraste em Tomografia Computadorizada
Meios de Contraste em Tomografia Computadorizada
Alex Eduardo Ribeiro
 
Como Elaborar Um Projeto De Pesquisa
Como Elaborar Um Projeto De PesquisaComo Elaborar Um Projeto De Pesquisa
Como Elaborar Um Projeto De Pesquisa
mauricio aquino
 
Normas ABNT Apresentação de trabalhos acadêmicos
Normas ABNT Apresentação de trabalhos acadêmicosNormas ABNT Apresentação de trabalhos acadêmicos
Normas ABNT Apresentação de trabalhos acadêmicos
Patrícia Éderson Dias
 
Sugestões para elaboração de projeto de pesquisa qualitativa
Sugestões para elaboração de projeto de pesquisa qualitativaSugestões para elaboração de projeto de pesquisa qualitativa
Sugestões para elaboração de projeto de pesquisa qualitativa
Lucinea Lima Lacerda
 
Design gráfico II - Aula 01 - Logotipo
Design gráfico II - Aula 01 - LogotipoDesign gráfico II - Aula 01 - Logotipo
Design gráfico II - Aula 01 - Logotipo
audreicarvalho
 
Metodologia do artigo científico
Metodologia do artigo científicoMetodologia do artigo científico
Metodologia do artigo científico
Mirian Ribeiro Daniel Neitzke
 
Midia Impressa #02 - Elementos Gráficos
Midia Impressa #02 - Elementos GráficosMidia Impressa #02 - Elementos Gráficos
Midia Impressa #02 - Elementos Gráficos
Renato Melo
 
TCC SLIDE DE APRESENTAÇÃO
TCC SLIDE DE APRESENTAÇÃOTCC SLIDE DE APRESENTAÇÃO
TCC SLIDE DE APRESENTAÇÃO
professsorcarlinho
 
Aula Mobile Marketing Completa
Aula Mobile Marketing CompletaAula Mobile Marketing Completa
Aula Mobile Marketing Completa
Patrick Duarte Silveira
 
4 estrutura do trabalho acadêmico tcc
4 estrutura do trabalho acadêmico   tcc4 estrutura do trabalho acadêmico   tcc
4 estrutura do trabalho acadêmico tcc
diemili
 
Modos de organização, seqüência e apresentação que caracterizam os diferentes...
Modos de organização, seqüência e apresentação que caracterizam os diferentes...Modos de organização, seqüência e apresentação que caracterizam os diferentes...
Modos de organização, seqüência e apresentação que caracterizam os diferentes...
maria aparecida coelho lira
 
Aula 2 elaboração trabalhos científicos
Aula 2   elaboração trabalhos científicosAula 2   elaboração trabalhos científicos
Aula 2 elaboração trabalhos científicos
Rodrigo Abreu
 
Apresentacao Seminario
Apresentacao SeminarioApresentacao Seminario
Apresentacao Seminario
Reginaldo Avelino
 
Metolodogia daniela cartoni - slides - parte 12 - redação técnica
Metolodogia   daniela cartoni - slides - parte 12 - redação técnicaMetolodogia   daniela cartoni - slides - parte 12 - redação técnica
Metolodogia daniela cartoni - slides - parte 12 - redação técnica
Daniela Cartoni
 
Metodologia cientifica
Metodologia cientificaMetodologia cientifica
Metodologia cientifica
jaddy xavier
 
Produção editorial elementos básicos
Produção editorial elementos básicosProdução editorial elementos básicos
Produção editorial elementos básicos
Barreto
 
Módulo 1 - Design gráfico
Módulo 1 - Design gráficoMódulo 1 - Design gráfico
Leitura e interpretacao de textos (revisão para o enade)
Leitura e interpretacao de textos (revisão para o enade)Leitura e interpretacao de textos (revisão para o enade)
Leitura e interpretacao de textos (revisão para o enade)
Universidade Estadual de Campinas
 

Mais procurados (20)

Modelo de Projeto de Pesquisa
Modelo de Projeto de PesquisaModelo de Projeto de Pesquisa
Modelo de Projeto de Pesquisa
 
Artigos Científicos: Análise e Elaboração
Artigos Científicos: Análise e ElaboraçãoArtigos Científicos: Análise e Elaboração
Artigos Científicos: Análise e Elaboração
 
Meios de Contraste em Tomografia Computadorizada
Meios de Contraste em Tomografia ComputadorizadaMeios de Contraste em Tomografia Computadorizada
Meios de Contraste em Tomografia Computadorizada
 
Como Elaborar Um Projeto De Pesquisa
Como Elaborar Um Projeto De PesquisaComo Elaborar Um Projeto De Pesquisa
Como Elaborar Um Projeto De Pesquisa
 
Normas ABNT Apresentação de trabalhos acadêmicos
Normas ABNT Apresentação de trabalhos acadêmicosNormas ABNT Apresentação de trabalhos acadêmicos
Normas ABNT Apresentação de trabalhos acadêmicos
 
Sugestões para elaboração de projeto de pesquisa qualitativa
Sugestões para elaboração de projeto de pesquisa qualitativaSugestões para elaboração de projeto de pesquisa qualitativa
Sugestões para elaboração de projeto de pesquisa qualitativa
 
Design gráfico II - Aula 01 - Logotipo
Design gráfico II - Aula 01 - LogotipoDesign gráfico II - Aula 01 - Logotipo
Design gráfico II - Aula 01 - Logotipo
 
Metodologia do artigo científico
Metodologia do artigo científicoMetodologia do artigo científico
Metodologia do artigo científico
 
Midia Impressa #02 - Elementos Gráficos
Midia Impressa #02 - Elementos GráficosMidia Impressa #02 - Elementos Gráficos
Midia Impressa #02 - Elementos Gráficos
 
TCC SLIDE DE APRESENTAÇÃO
TCC SLIDE DE APRESENTAÇÃOTCC SLIDE DE APRESENTAÇÃO
TCC SLIDE DE APRESENTAÇÃO
 
Aula Mobile Marketing Completa
Aula Mobile Marketing CompletaAula Mobile Marketing Completa
Aula Mobile Marketing Completa
 
4 estrutura do trabalho acadêmico tcc
4 estrutura do trabalho acadêmico   tcc4 estrutura do trabalho acadêmico   tcc
4 estrutura do trabalho acadêmico tcc
 
Modos de organização, seqüência e apresentação que caracterizam os diferentes...
Modos de organização, seqüência e apresentação que caracterizam os diferentes...Modos de organização, seqüência e apresentação que caracterizam os diferentes...
Modos de organização, seqüência e apresentação que caracterizam os diferentes...
 
Aula 2 elaboração trabalhos científicos
Aula 2   elaboração trabalhos científicosAula 2   elaboração trabalhos científicos
Aula 2 elaboração trabalhos científicos
 
Apresentacao Seminario
Apresentacao SeminarioApresentacao Seminario
Apresentacao Seminario
 
Metolodogia daniela cartoni - slides - parte 12 - redação técnica
Metolodogia   daniela cartoni - slides - parte 12 - redação técnicaMetolodogia   daniela cartoni - slides - parte 12 - redação técnica
Metolodogia daniela cartoni - slides - parte 12 - redação técnica
 
Metodologia cientifica
Metodologia cientificaMetodologia cientifica
Metodologia cientifica
 
Produção editorial elementos básicos
Produção editorial elementos básicosProdução editorial elementos básicos
Produção editorial elementos básicos
 
Módulo 1 - Design gráfico
Módulo 1 - Design gráficoMódulo 1 - Design gráfico
Módulo 1 - Design gráfico
 
Leitura e interpretacao de textos (revisão para o enade)
Leitura e interpretacao de textos (revisão para o enade)Leitura e interpretacao de textos (revisão para o enade)
Leitura e interpretacao de textos (revisão para o enade)
 

Destaque

Modelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNTModelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNT
Rosineia Oliveira dos Santos
 
Modelo de resumo
Modelo de resumoModelo de resumo
Artigo científico tcc educação do campo (júnior)
Artigo científico   tcc educação do campo (júnior)Artigo científico   tcc educação do campo (júnior)
Artigo científico tcc educação do campo (júnior)
Junior Lima
 
Artigo Científico: Direitos Fundamentais x Acessibilidade
Artigo Científico: Direitos Fundamentais x AcessibilidadeArtigo Científico: Direitos Fundamentais x Acessibilidade
Artigo Científico: Direitos Fundamentais x Acessibilidade
Karine Souza
 
Artigo cientifico anhanguera
Artigo cientifico anhangueraArtigo cientifico anhanguera
Artigo cientifico anhanguera
mkbariotto
 
Artigo pronto! desinfecção de efluentes primário municipal de águas residua...
Artigo pronto!   desinfecção de efluentes primário municipal de águas residua...Artigo pronto!   desinfecção de efluentes primário municipal de águas residua...
Artigo pronto! desinfecção de efluentes primário municipal de águas residua...
José Demontier Vieira de Souza Filho
 
Ciencias da natureza e artigo
Ciencias da natureza e artigoCiencias da natureza e artigo
Ciencias da natureza e artigo
Rosineia Oliveira dos Santos
 
Projeto tcc-faculdade de pedagogia-2014
Projeto tcc-faculdade de pedagogia-2014Projeto tcc-faculdade de pedagogia-2014
Projeto tcc-faculdade de pedagogia-2014
Andre Silva
 
Tcc anhanguera a dificuldade no ensino de leitura na educação
Tcc anhanguera   a dificuldade no ensino de leitura na educaçãoTcc anhanguera   a dificuldade no ensino de leitura na educação
Tcc anhanguera a dificuldade no ensino de leitura na educação
mkbariotto
 
Modelo formatação artigo científico
Modelo formatação artigo científicoModelo formatação artigo científico
Modelo formatação artigo científico
Marcos Azevedo
 
Metodologia e processo da alfabetizacão das séries iniciais
Metodologia e processo da alfabetizacão das séries iniciaisMetodologia e processo da alfabetizacão das séries iniciais
Metodologia e processo da alfabetizacão das séries iniciais
cefaprodematupa
 
Paper TRABALHO DE GRADUAÇÃO
Paper TRABALHO DE GRADUAÇÃOPaper TRABALHO DE GRADUAÇÃO
Paper TRABALHO DE GRADUAÇÃO
Polliane Almeida
 

Destaque (12)

Modelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNTModelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNT
 
Modelo de resumo
Modelo de resumoModelo de resumo
Modelo de resumo
 
Artigo científico tcc educação do campo (júnior)
Artigo científico   tcc educação do campo (júnior)Artigo científico   tcc educação do campo (júnior)
Artigo científico tcc educação do campo (júnior)
 
Artigo Científico: Direitos Fundamentais x Acessibilidade
Artigo Científico: Direitos Fundamentais x AcessibilidadeArtigo Científico: Direitos Fundamentais x Acessibilidade
Artigo Científico: Direitos Fundamentais x Acessibilidade
 
Artigo cientifico anhanguera
Artigo cientifico anhangueraArtigo cientifico anhanguera
Artigo cientifico anhanguera
 
Artigo pronto! desinfecção de efluentes primário municipal de águas residua...
Artigo pronto!   desinfecção de efluentes primário municipal de águas residua...Artigo pronto!   desinfecção de efluentes primário municipal de águas residua...
Artigo pronto! desinfecção de efluentes primário municipal de águas residua...
 
Ciencias da natureza e artigo
Ciencias da natureza e artigoCiencias da natureza e artigo
Ciencias da natureza e artigo
 
Projeto tcc-faculdade de pedagogia-2014
Projeto tcc-faculdade de pedagogia-2014Projeto tcc-faculdade de pedagogia-2014
Projeto tcc-faculdade de pedagogia-2014
 
Tcc anhanguera a dificuldade no ensino de leitura na educação
Tcc anhanguera   a dificuldade no ensino de leitura na educaçãoTcc anhanguera   a dificuldade no ensino de leitura na educação
Tcc anhanguera a dificuldade no ensino de leitura na educação
 
Modelo formatação artigo científico
Modelo formatação artigo científicoModelo formatação artigo científico
Modelo formatação artigo científico
 
Metodologia e processo da alfabetizacão das séries iniciais
Metodologia e processo da alfabetizacão das séries iniciaisMetodologia e processo da alfabetizacão das séries iniciais
Metodologia e processo da alfabetizacão das séries iniciais
 
Paper TRABALHO DE GRADUAÇÃO
Paper TRABALHO DE GRADUAÇÃOPaper TRABALHO DE GRADUAÇÃO
Paper TRABALHO DE GRADUAÇÃO
 

Semelhante a Agil - artigo cientifico

Metodologia agil scrum x pmbok
Metodologia agil   scrum x pmbokMetodologia agil   scrum x pmbok
Metodologia agil scrum x pmbok
Marisa Wittmann
 
ANALISE E DESENVOLVIMENTO DE SISTEMAS
ANALISE E DESENVOLVIMENTO DE SISTEMASANALISE E DESENVOLVIMENTO DE SISTEMAS
ANALISE E DESENVOLVIMENTO DE SISTEMAS
Nilo Basílio
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horas
Wise Systems
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
Audasi Tecnologia e Inovação
 
Desenvolvimento ágil com scrum
Desenvolvimento ágil com scrumDesenvolvimento ágil com scrum
Desenvolvimento ágil com scrum
Carlos Lucas Brandão
 
2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx
2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx
2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx
GeorgeoNocera2
 
Gerenciamento e desenvolvimento ágil de software
Gerenciamento e desenvolvimento ágil de softwareGerenciamento e desenvolvimento ágil de software
Gerenciamento e desenvolvimento ágil de software
Impacta Eventos
 
Um guia definitivo para o Scrum em Português
Um guia definitivo para o Scrum em PortuguêsUm guia definitivo para o Scrum em Português
Um guia definitivo para o Scrum em Português
Marcelo Gaspar BLACK BELT, CISA, CGEIT
 
Apostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumApostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do Scrum
MindMasterBrasil
 
Metodologia agil scrum x pmbok
Metodologia agil   scrum x pmbokMetodologia agil   scrum x pmbok
Metodologia agil scrum x pmbok
Marisa Uzun Wittmann
 
Sobre o Scrum
Sobre o ScrumSobre o Scrum
Sobre o Scrum
Juliana Amorim
 
Trabalho scrum
Trabalho scrumTrabalho scrum
Trabalho scrum
Jarbas Pereira
 
Scrum
ScrumScrum
Scrum guide portuguese br
Scrum guide   portuguese brScrum guide   portuguese br
Scrum guide portuguese br
brunobc123
 
Aplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeisAplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeis
fayrusm
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
Paulo Ricardo Dalmagro Vinck
 
Guia do scrum
Guia do scrumGuia do scrum
Guia do scrum
Elisa Morelli
 
Guia do scrum
Guia do scrumGuia do scrum
Guia do scrum
leopaiva217101
 
Inciando com Scrum
Inciando com ScrumInciando com Scrum
Inciando com Scrum
Idéia Ágil
 
Minicurso Aplicando Scrum em projetos de software (2010)
Minicurso Aplicando Scrum em projetos de software (2010)Minicurso Aplicando Scrum em projetos de software (2010)
Minicurso Aplicando Scrum em projetos de software (2010)
Mariana de Azevedo Santos
 

Semelhante a Agil - artigo cientifico (20)

Metodologia agil scrum x pmbok
Metodologia agil   scrum x pmbokMetodologia agil   scrum x pmbok
Metodologia agil scrum x pmbok
 
ANALISE E DESENVOLVIMENTO DE SISTEMAS
ANALISE E DESENVOLVIMENTO DE SISTEMASANALISE E DESENVOLVIMENTO DE SISTEMAS
ANALISE E DESENVOLVIMENTO DE SISTEMAS
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horas
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Desenvolvimento ágil com scrum
Desenvolvimento ágil com scrumDesenvolvimento ágil com scrum
Desenvolvimento ágil com scrum
 
2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx
2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx
2024.1 - Módulo B - Frameworks de Gestão de Projetos - SCRUM.pptx
 
Gerenciamento e desenvolvimento ágil de software
Gerenciamento e desenvolvimento ágil de softwareGerenciamento e desenvolvimento ágil de software
Gerenciamento e desenvolvimento ágil de software
 
Um guia definitivo para o Scrum em Português
Um guia definitivo para o Scrum em PortuguêsUm guia definitivo para o Scrum em Português
Um guia definitivo para o Scrum em Português
 
Apostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumApostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do Scrum
 
Metodologia agil scrum x pmbok
Metodologia agil   scrum x pmbokMetodologia agil   scrum x pmbok
Metodologia agil scrum x pmbok
 
Sobre o Scrum
Sobre o ScrumSobre o Scrum
Sobre o Scrum
 
Trabalho scrum
Trabalho scrumTrabalho scrum
Trabalho scrum
 
Scrum
ScrumScrum
Scrum
 
Scrum guide portuguese br
Scrum guide   portuguese brScrum guide   portuguese br
Scrum guide portuguese br
 
Aplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeisAplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeis
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
 
Guia do scrum
Guia do scrumGuia do scrum
Guia do scrum
 
Guia do scrum
Guia do scrumGuia do scrum
Guia do scrum
 
Inciando com Scrum
Inciando com ScrumInciando com Scrum
Inciando com Scrum
 
Minicurso Aplicando Scrum em projetos de software (2010)
Minicurso Aplicando Scrum em projetos de software (2010)Minicurso Aplicando Scrum em projetos de software (2010)
Minicurso Aplicando Scrum em projetos de software (2010)
 

Último

Subindo uma aplicação WordPress em docker na AWS
Subindo uma aplicação WordPress em docker na AWSSubindo uma aplicação WordPress em docker na AWS
Subindo uma aplicação WordPress em docker na AWS
Ismael Ash
 
se38_layout_erro_xxxxxxxxxxxxxxxxxx.docx
se38_layout_erro_xxxxxxxxxxxxxxxxxx.docxse38_layout_erro_xxxxxxxxxxxxxxxxxx.docx
se38_layout_erro_xxxxxxxxxxxxxxxxxx.docx
ronaldos10
 
Aula combustiveis mais utilizados na indústria
Aula combustiveis mais utilizados na indústriaAula combustiveis mais utilizados na indústria
Aula combustiveis mais utilizados na indústria
zetec10
 
Ferramentas que irão te ajudar a entrar no mundo de DevOps/CLoud
Ferramentas que irão te ajudar a entrar no mundo de   DevOps/CLoudFerramentas que irão te ajudar a entrar no mundo de   DevOps/CLoud
Ferramentas que irão te ajudar a entrar no mundo de DevOps/CLoud
Ismael Ash
 
Apresentação sobre Deep Web e anonimização
Apresentação sobre Deep Web e anonimizaçãoApresentação sobre Deep Web e anonimização
Apresentação sobre Deep Web e anonimização
snerdct
 
INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...
INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...
INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...
Faga1939
 

Último (6)

Subindo uma aplicação WordPress em docker na AWS
Subindo uma aplicação WordPress em docker na AWSSubindo uma aplicação WordPress em docker na AWS
Subindo uma aplicação WordPress em docker na AWS
 
se38_layout_erro_xxxxxxxxxxxxxxxxxx.docx
se38_layout_erro_xxxxxxxxxxxxxxxxxx.docxse38_layout_erro_xxxxxxxxxxxxxxxxxx.docx
se38_layout_erro_xxxxxxxxxxxxxxxxxx.docx
 
Aula combustiveis mais utilizados na indústria
Aula combustiveis mais utilizados na indústriaAula combustiveis mais utilizados na indústria
Aula combustiveis mais utilizados na indústria
 
Ferramentas que irão te ajudar a entrar no mundo de DevOps/CLoud
Ferramentas que irão te ajudar a entrar no mundo de   DevOps/CLoudFerramentas que irão te ajudar a entrar no mundo de   DevOps/CLoud
Ferramentas que irão te ajudar a entrar no mundo de DevOps/CLoud
 
Apresentação sobre Deep Web e anonimização
Apresentação sobre Deep Web e anonimizaçãoApresentação sobre Deep Web e anonimização
Apresentação sobre Deep Web e anonimização
 
INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...
INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...
INTELIGÊNCIA ARTIFICIAL + COMPUTAÇÃO QUÂNTICA = MAIOR REVOLUÇÃO TECNOLÓGICA D...
 

Agil - artigo cientifico

  • 1. DESENVOLVIMENTO ÁGIL: UMA ABORDAGEM SOBRE O SCRUM Klaus Fischer Gomes Santana1 Rafael Araújo de Freitas2 RESUMO A metodologia Scrum assume-se como extremamente ágil e flexível. 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 participação ativa dos clientes, o rendimento do projeto aumenta e os requisitos e a solicitação de alteração passa a ser atendido mais rapidamente. As metodologias de desenvolvimento ágil vem se destacando a cada dia, porém essas ainda são pouco difundidas no meio acadêmico. O objetivo deste artigo, além de difundir esse assunto e servir de apoio para futuras pesquisas, é demonstrar de maneira simples e objetiva, o funcionamento, as características, o vocabulário e a aplicação da metodologia Scrum em um ambiente de trabalho. Palavras-chave: Engenharia de Software, Métodos de Desenvolvimento, Desenvolvimento Ágil, SCRUM. 1 INTRODUÇÃO Um desafio constante da área de Engenharia de Software é melhorar o processo de desenvolvimento de software. Mesmo com a constante evolução de métodos, técnicas 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 rápida, mas com qualidade. Esse produto pode ser obtido utilizando métodos ágeis e padrões organizacionais e de processos. O desenvolvimento ágil é uma filosofia. É uma maneira de pensar sobre produção de software. A decisão canônica desta maneira de pensar é o “Manifesto Ágil” (Becket al., 2001), um conjunto de 4 valores (figura 1) e 12 princípios (figura 2). 1 Graduando em Análise e Desenvolvimento de Sistemas. E-mail: klausfgsantana@gmail.com 2 Graduando em Análise e Desenvolvimento de Sistemas. E-mail: jedi.rafael@gmail.com
  • 2. Figura 1: Manifesto para o ágil Fonte: http://manifestoagil.com.br/index.html Figura 2: Princípios do manifesto ágil Fonte: http://manifestoagil.com.br/principios.html Nos últimos anos, métodos á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 agências governamentais. Neste Artigo abordaremos a Metodologia de Desenvolvimento Ágil Scrum, veremos como se dá sua implantação no processo de desenvolvimento de software.
  • 3. 2 ENTENDENDO O SCRUM Estamos crescendo tão rápido que parece que sempre precisamos de mais umas regrinhas aqui, mais um pouco de papel ali... precisamos ter muito cuidado, pois cada novo nível gerencial, cada nova regra ou formulário atrapalha. Eles acabam com a mágica, cortam a eletricidade da inspiração. Com restrições em excesso, você pára de pensar no que pode fazer e começa a pensar no que não dá para fazer (Cirque Du Soleil – A reinvenção do Espetáculo; Ed. Campus; Elsevier). As raízes do Scrum estão num artigo que sumariza as 10 melhores práticas em empresas japonesas, escrito por Takeuchi e Nonaka, cujo título é “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 reuniões de equipes que praticam a autodireção e a adaptabilidade. A palavra Scrum não é uma sigla e nem tem tradução para o Português. O termo Scrum é o nome usado para a reunião de jogadores, no jogo de Rugby, quando eles se organizam em círculo para planejar a próxima jogada. É uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma visão de longo prazo, que é ganhar o jogo. Desenvolvimento de produtos complexos ocorre em situações de muitas mudanças. Quanto mais próximo do limite do caos a equipe conseguir trabalhar, porém 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 são necessários. A evolução favorece aqueles que se expões e aceitam as mudanças e estão preparados para se adaptarem a essas. Nesse caso é necessária uma abordagem gerencial de projetos que permita às equipes operarem de forma flexível e adaptável num ambiente complexo, usando processos imprecisos. Scrum é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para criação de produtos, além 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 negócio.
  • 4. A maioria dos métodos e técnicas de gerenciamento de projetos são bastante prescritivas, isso força as pessoas a seguirem uma sequência predefinida de passos, com pouca flexibilidade para mudanças. Tradicionalmente, os projetos de construção de software seguem um ciclo envolvendo captura de requisitos, análise, projeto técnico (design), programação, teste e implantação com cada estágio sendo completado antes que o próximo seja iniciado. Contudo, são características importantes do Scrum: a adaptabilidade e o empirismo. Sua abordagem é oposta a do modelo em cascata, inicia-se a análise assim que alguns requisitos estiverem disponíveis, assim que alguma análise tiver sido feita começam os trabalhos de projeto técnico (design), e assim por diante. Em outras palavras, o projeto trabalha num pedaço pequeno de cada vez. Esta abordagem pode ser chamada de iterativa, e cada iteração consiste na captura de requisitos, um pouco de análise, um pouco de design, mais alguma programação e testes, culminando num ciclo iterativo com várias entregas conforme podemos ver na figura 3. Figura 3: Ciclo de iterações de sprint de um projeto. 3 O PRODUCT BACKLOG O projeto no Scrum começa com uma visão, que pode ser vaga no princípio, talvez expressa em termos de marketing ou uma visão técnica, e que depois ficará mais clara à medida que o projeto evoluir.
  • 5. A partir da visão é definida uma lista de itens priorizados, composta por requisitos e funcionalidade que precisam ser construídos para que a visão seja concretizada. Estamos falando do Product Backlog). O Product Backlog é o coração do Scrum. É basicamente uma lista de requisitos, histórias, 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 técnica 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 começará a gerar valor e lucro muito mais cedo. O Scrum busca este objetivo produzindo uma versão que pode ser potencialmente distribuída 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, poderíamos construir, de forma interativa, um produto que tenha estes 20% das freatures logo no início do projeto. 4 PAPÉIS NO SCRUM O Scrum trabalha basicamente com três papéis: o Product Owner, o Scrum Master e a Equipe Scrum.
  • 6. O Product Owner é responsável 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 posição similar à ocupada pelo Product Owner. É responsável por forçar os valores e as práticas do Scrum, remover obstáculos, ensinar o processo a todas as pessoas, implementar o Scrum e garantir que todas as pessoas sigam as regras e as práticas do Scrum. O Scrum Master é um líder e não 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 através do Scrum; • Melhorar a vida da Equipe Scrum, facilitando a criatividade através do empowerment; • Manter a informação sobre o progresso da Equipe Scrum sempre atualizado e disponível para todos os interessados. A Equipe Scrum é o grupo de pessoas responsável por desenvolver ou construir as funcionalidades do produto. As equipes são autogerenciadas, auto- organizadas e multifuncionais. Geralmente, a equipe é composta por 5 a 10 membros (o recomendado são sete pessoas) e deve ser multifuncional, composta por indivíduos com diferentes especializações. A equipe pode ser composta por desenvolvedores em tempo integral e participantes externos (marketing, vendas, clientes etc.). 5 FASES DO SCRUM
  • 7. O Scrum é composto por três fases: pré-game, game e pós-game. A primeira e última fases consistem em processos definidos, onde todos os processos, mais as entradas e as saídas, são bem definidos. Os conhecimentos sobre como realizar estas fases são explícitos e podem compreender uma ou mais iterações. No Pré-game temos duas partes: planejamento e arquitetura. No planejamento é definido um novo release, com base nas informações 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 conceitualização e análise. No caso da evolução de um produto já existente, esta fase consiste numa análise limitada. Na arquitetura os itens do Backlog são projetados com vistas à implementação. Esta fase inclui definições e modificações na arquitetura e design de alto nível (KNIBERG,2007). Na fase intermediária do game o processo é empírico. A maioria dos processos nesta fase são 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 é construído em múltiplas iterações chamadas no Scrum de Sprint. O produto pode ser modificado a qualquer momento durante o planejamento do Sprint, bem como durante o Sprint. Essas mudanças ocorrem por conta da complexidade, ações da decorrência, prazo, qualidade, pressão de custo etc. Esta fase é composta dos seguintes macroprocessos: • Reuniões com as equipes para rever o planejamento dos releases; • Revisão dos padrões com os quais o sistema precisa ser compatível e fazer os ajustes necessários; • Realização dos Sprints até que o produto esteja pronto para distribuição. Quando a gerência decide que as variáveis de tempo, concorrência de mercado, requisitos, custos e qualidade estão adequadas para distribuir o produto, ela declara que o release está fechado e a fase de pós-game começa. Nesta fase o produto é preparado para distribuição, incluindo integração, testes adicionais, documentação de usuário, preparação de material para treinamento e de marketing, dentre outras coisas. 6 PRÁTICAS DO SCRUM 6.1 Plano de Jogo
  • 8. 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 sequência em que os itens serão trabalhados, bem como para adicionar ou retirar itens. Os requisitos não necessitam ser precisos nem estarem descritos de forma completa e detalhada, estes requisitos serão obtidos com os futuros usuários do produto e com pessoas do negócio. Os principais itens, ou seja, os de maior importância, vão 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 além da iteração seguinte, isto pode ser uma perda de tempo, mesmo porque o conteúdo de cada Sprint é sempre definido nas reuniões de planejamento que precedem cada Sprint. 6.2 Sprint Um Sprint é um conjunto de atividades de desenvolvimento conduzidas num período 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 avaliação de riscos e no grau de volatilidade dos requisitos. Durante um Sprint a equipe desenvolve as seguintes atividades: • Desenvolvimento (análise, projeto técnico – design, programação, testes e documentação); • Empacotamento (criação de programas executáveis); • Revisão (revisão do que foi feito, correção de problemas); • Ajustes (consolidar as informações obtidas na revisão e realizar as mudanças necessárias). Ao final do período do Sprint, normalmente em 30 (trinta) dias, é produzido uma versão do produto que pode potencialmente ser distribuída para o mercado. Esta versão deve prover algum valor para o negócio.
  • 9. A vantagem desse curto período é que ele permite ao Product Owner, o cliente, repriorizar os itens do Product Backlog com base no resultado do Sprint anterior. A importância disto é que o projeto sempre estará produzindo algo que possa ser utilizado no negócio. Todo Sprint começa com uma reunião de planejamento, trabalhando de forma colaborativa o Product Owner e a Equipe Scrum para decidirem os itens da próxima iteração. Os objetivos básicos desta reunião são: 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 reunião de planejamento não 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 dúvidas quanto ao conteúdo, propósito, significado e intenções. Quando a equipe achar que tem informações suficientes, seleciona os itens que acredita que poderá desenvolver durante a iteração. Nas próximas 4 (quatro) horas é planejado o Sprint, já que é a equipe que vai gerenciar seu próprio trabalho. É feita também pelo Dono do Produto e pelo Mestre Scrum uma estimativa de tempo, que inicialmente são apenas “adivinhações”, ganhando precisão no decorrer do processo. Terminada a reunião 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 não como o trabalho vai ser feito. 6.3 Reuniões do Scrum No Scrum a Equipe Scrum realiza uma reunião de 15 minutos todos os dias pela manhã. O propósito da reunião é sincronizar o trabalho diário de todos os membros da equipe, sempre sem se desviar do foco principal. Essa reunião é curta, com todos os participantes em pé, podendo caso necessário, ser ampliada para 30 minutos.
  • 10. Outra prática interessante é a cobrança de R$ 1,00 de cada participante que chegar atrasado. Pode até parecer engraçado, mais ajuda criar foco e evitar que as reuniões tenham que se prolongar devido ao atraso de alguns participantes. Existe também a reunião de revisão do Sprint, que ocorre no final de cada Sprint. É uma reunião de quatro horas onde a equipe apresenta o trabalho desenvolvido para o Product Owner. Após a reunião de revisão do Sprint, o Scrum Master faz uma reunião de retrospectiva com a Equipe. Em três horas de duração ela visa encorajar a Equipe a revisar seu processo de trabalho, tendo em vista o framework e as práticas do Scrum, para ter um melhor desempenho na próxima iteração. 6.4 Escalabilidade Se houver necessidade pode ser montado mais de uma Equipe Scrum e realizar um trabalho em paralelo. Esta técnica chama-se escalar o projeto. Projetos escalados necessitam de controles adicionais para acompanhar e sincronizar os trabalhos. Quanto às reuniões diárias cada equipe realiza a sua, que serão seguidas de reuniões 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 implementação. Requisitos não funcionais para a construção 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. CONCLUSÃO O Scrum é um método bastante simples e objetivo, é composto por poucas práticas, artefatos e regras e por isso é fácil de aprender. Não é um processo prescritivo, sendo indicado para trabalhos complexos onde é muito difícil prever acontecimentos futuros. Ainda oferece framework e conjunto de práticas que mantém a clareza do processo. O que permite que a equipe e outros interessados possam acompanhar o andamento do projeto e tomar as decisões que forem necessárias para direcionar o projeto.
  • 11. Após estudarmos o desenvolvimento ágil, e principalmente o Scrum, podemos ver o quanto é benéfico para o processo de construção de software tais técnicas. 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. REFERÊNCIAS MARTINS, José Carlos Cordeiro. Técnicas 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. Disponível em: <http://manifestoagil.com.br/index.html>. Acesso em 02 nov. Doze princípios por trás do manifesto ágil. Disponível em: <http://manifestoagil.com.br/principios.html>. Acesso em 02 nov.