Your SlideShare is downloading. ×

Agil - artigo cientifico

3,884

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,884
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
95
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. DESENVOLVIMENTO ÁGIL: UMA ABORDAGEM SOBRE O SCRUM Klaus Fischer Gomes Santana1 Rafael Araújo de Freitas2RESUMO A metodologia Scrum assume-se como extremamente ágil e flexível.Defini-se como um processo de desenvolvimento iterativo e incremental que podeser aplicado a qualquer produto ou no gerenciamento de qualquer atividadecomplexa, proporcionando um excelente entendimento entre as equipes dedesenvolvimento. Com todo esse entrosamento e participação ativa dos clientes, orendimento do projeto aumenta e os requisitos e a solicitação de alteração passa aser atendido mais rapidamente. As metodologias de desenvolvimento ágil vem sedestacando a cada dia, porém essas ainda são pouco difundidas no meioacadêmico. O objetivo deste artigo, além de difundir esse assunto e servir de apoiopara futuras pesquisas, é demonstrar de maneira simples e objetiva, ofuncionamento, as características, o vocabulário e a aplicação da metodologiaScrum 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 oprocesso de desenvolvimento de software. Mesmo com a constante evolução demétodos, técnicas e ferramentas, a entrega de softwares em prazos e custosestabelecidos nem sempre é efetiva. Uma das causas desse problema é o excessode formalidade nos modelos de processo propostos nos últimos 30 anos. Existe hoje a necessidade de criar software de forma mais rápida, mascom qualidade. Esse produto pode ser obtido utilizando métodos ágeis e padrõesorganizacionais e de processos. O desenvolvimento ágil é uma filosofia. É uma maneira de pensar sobreproduçã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.com2 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 serutilizados por grandes empresas como Google, Yahoo, Symantec, Microsoft, entreoutras, 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 melhorespráticas em empresas japonesas, escrito por Takeuchi e Nonaka, cujo título é “Ojogo do desenvolvimento de novos produtos”, publicada na Harvard BussinesssReview em janeiro de 1986. Este artigo introduziu o termo Scrum para referir-se àsreuniõ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 formade mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com umavisão de longo prazo, que é ganhar o jogo. Desenvolvimento de produtos complexos ocorre em situações de muitasmudanç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. OScrum é 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 aquelesque se expões e aceitam as mudanças e estão preparados para se adaptarem aessas. Nesse caso é necessária uma abordagem gerencial de projetos que permitaàs equipes operarem de forma flexível e adaptável num ambiente complexo, usandoprocessos imprecisos. Scrum é um processo bastante leve para gerenciar e controlar projetos dedesenvolvimento de software e para criação de produtos, além de tratar-se demetodologia ágil e seguir as filosofias iterativa e incremental. Ele se concentra noque é realmente importante: gerenciar o projeto e criar um produto que acrescentevalor para o negócio.
  • 4. A maioria dos métodos e técnicas de gerenciamento de projetos sãobastante prescritivas, isso força as pessoas a seguirem uma sequência predefinidade passos, com pouca flexibilidade para mudanças. Tradicionalmente, os projetos deconstruçã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 sendocompletado antes que o próximo seja iniciado. Contudo, são características importantes do Scrum: a adaptabilidade e oempirismo. Sua abordagem é oposta a do modelo em cascata, inicia-se a análiseassim que alguns requisitos estiverem disponíveis, assim que alguma análise tiversido 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 capturade requisitos, um pouco de análise, um pouco de design, mais alguma programaçãoe testes, culminando num ciclo iterativo com várias entregas conforme podemos verna 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 noprincípio, talvez expressa em termos de marketing ou uma visão técnica, e quedepois ficará mais clara à medida que o projeto evoluir.
  • 5. A partir da visão é definida uma lista de itens priorizados, composta porrequisitos e funcionalidade que precisam ser construídos para que a visão sejaconcretizada. Estamos falando do Product Backlog). O Product Backlog é o coração do Scrum. É basicamente uma lista derequisitos, histórias, coisas que o cliente deseja, descritas usando uma linguagemque 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 queprocura antecipar o lucro do projeto de uma forma controlada. O produto pode serentregue aos clientes de forma incremental, antecipando o momento de entregapara o cliente. Desta forma, o projeto começará a gerar valor e lucro muito mais cedo. OScrum busca este objetivo produzindo uma versão que pode ser potencialmentedistribuída para o mercado em intervalos regulares de 30 dias. Pesquisas indicamque 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% dasfreatures logo no início do projeto.4 PAPÉIS NO SCRUM O Scrum trabalha basicamente com três papéis: o Product Owner, oScrum Master e a Equipe Scrum.
  • 6. O Product Owner é responsável por representar os interesses daspessoas que apostaram no projeto e no produto resultante. O Product Ownerconsegue a verba, define os requisitos gerais, define os objetivos e o plano dereleases. A lista de requisitos é o Product Backlog. O Product Owner provavelmenteserá um gerente de projeto, ou um patrocinador do projeto, um membro da equipede marketing ou um cliente interno (KNIBERG, 2007). O Scrum Master ocupa uma posição similar à ocupada pelo ProductOwner. É responsável por forçar os valores e as práticas do Scrum, removerobstáculos, ensinar o processo a todas as pessoas, implementar o Scrum e garantirque 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 ouconstruir as funcionalidades do produto. As equipes são autogerenciadas, auto-organizadas e multifuncionais. Geralmente, a equipe é composta por 5 a 10membros (o recomendado são sete pessoas) e deve ser multifuncional, compostapor indivíduos com diferentes especializações. A equipe pode ser composta pordesenvolvedores 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. Aprimeira 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 comorealizar estas fases são explícitos e podem compreender uma ou mais iterações. No Pré-game temos duas partes: planejamento e arquitetura. Noplanejamento é definido um novo release, com base nas informações conhecidasaté 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. Nocaso da evolução de um produto já existente, esta fase consiste numa análiselimitada. 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 dealto nível (KNIBERG,2007). Na fase intermediária do game o processo é empírico. A maioria dosprocessos nesta fase são indefinidos e tratados como uma caixa preta que requeremapenas controles externos. Por exemplo, o controle de riscos ocorre em cada Sprintpara 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 podeser modificado a qualquer momento durante o planejamento do Sprint, bem comodurante o Sprint. Essas mudanças ocorrem por conta da complexidade, ações dadecorrência, prazo, qualidade, pressão de custo etc. Esta fase é composta dosseguintes 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 demercado, 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 oproduto é 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 SCRUM6.1 Plano de Jogo
  • 8. No Scrum o plano de jogo funciona da seguinte maneira: registram-setodos os requisitos num Product Backlog, que é uma lista inicial de requisitos. Cabelembrar que essa lista pode ser ajustada durante o projeto pelo Product Owner, a fimde modificar a sequência em que os itens serão trabalhados, bem como paraadicionar ou retirar itens. Os requisitos não necessitam ser precisos nem estarem descritos deforma completa e detalhada, estes requisitos serão obtidos com os futuros usuáriosdo produto e com pessoas do negócio. Os principais itens, ou seja, os de maiorimportância, vão para o topo da lista. Mesmo com muitos itens já definidos, pode acontecer de apenas algunsdeles 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, mesmoporque o conteúdo de cada Sprint é sempre definido nas reuniões de planejamentoque precedem cada Sprint.6.2 Sprint Um Sprint é um conjunto de atividades de desenvolvimento conduzidasnum período de tempo predefinido, chamado de Time Box (caixa de tempo), quenormalmente varia de uma a quatro semanas. Este intervalo é baseado nacomplexidade do produto, na avaliação de riscos e no grau de volatilidade dosrequisitos. 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 omercado. Esta versão deve prover algum valor para o negócio.
  • 9. A vantagem desse curto período é que ele permite ao Product Owner, ocliente, repriorizar os itens do Product Backlog com base no resultado do Sprintanterior. A importância disto é que o projeto sempre estará produzindo algo quepossa ser utilizado no negócio. Todo Sprint começa com uma reunião de planejamento, trabalhando deforma colaborativa o Product Owner e a Equipe Scrum para decidirem os itens dapró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, sendodividida em duas partes de 4 (quatro) horas. Na primeira o Product Owner apresentae descreve os itens de maior prioridade. A equipe faz questionamentos e esclarecedúvidas quanto ao conteúdo, propósito, significado e intenções. Quando a equipeachar 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 quevai gerenciar seu próprio trabalho. É feita também pelo Dono do Produto e peloMestre Scrum uma estimativa de tempo, que inicialmente são apenas“adivinhações”, ganhando precisão no decorrer do processo. Terminada a reunião aequipe de projeto cria o Backlog do Sprint, um quadro que vai ser atualizadodiariamente, bastante parecido com o quadro do Product Backlog. Lembrando que oobjetivo é 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 osdias pela manhã. O propósito da reunião é sincronizar o trabalho diário de todos osmembros 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 30minutos.
  • 10. Outra prática interessante é a cobrança de R$ 1,00 de cada participanteque chegar atrasado. Pode até parecer engraçado, mais ajuda criar foco e evitar queas 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 cadaSprint. É uma reunião de quatro horas onde a equipe apresenta o trabalhodesenvolvido para o Product Owner. Após a reunião de revisão do Sprint, o Scrum Master faz uma reunião deretrospectiva com a Equipe. Em três horas de duração ela visa encorajar a Equipe arevisar seu processo de trabalho, tendo em vista o framework e as práticas doScrum, para ter um melhor desempenho na próxima iteração.6.4 Escalabilidade Se houver necessidade pode ser montado mais de uma Equipe Scrum erealizar um trabalho em paralelo. Esta técnica chama-se escalar o projeto. Projetosescalados necessitam de controles adicionais para acompanhar e sincronizar ostrabalhos. Quanto às reuniões diárias cada equipe realiza a sua, que serão seguidasde reuniões de Scrum, com um representante de cada equipe. Antes de escalar um projeto deve ser preparada a infra-estruturaadequada para o projeto, utilizando o primeiro Sprint para tal implementação.Requisitos não funcionais para a construção da infra-estrutura de escalonamentodevem ganhar maior prioridade no Product Backlog, já que estes itens precisamestar prontos para que o projeto possa ser escalonado.7. CONCLUSÃO O Scrum é um método bastante simples e objetivo, é composto porpoucas práticas, artefatos e regras e por isso é fácil de aprender. Não é umprocesso prescritivo, sendo indicado para trabalhos complexos onde é muito difícilprever acontecimentos futuros. Ainda oferece framework e conjunto de práticas que mantém a clareza doprocesso. O que permite que a equipe e outros interessados possam acompanhar oandamento do projeto e tomar as decisões que forem necessárias para direcionar oprojeto.
  • 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 taistécnicas. O fato de apontarmos uma ou outra é bastante complicado, sendo quedependendo dos objetivos da equipe de desenvolvimento, as vezes é comum otrabalho em conjunto de mais de uma metodologia de desenvolvimento ágil.8. REFERÊNCIASMARTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos desoftware. 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.

×