Sie sind auf Seite 1von 16

Conhecendo o Scrum

O presente artigo conceitua o framework para projetos geis Scrum. Alm de apresentar os termos usados no Scrum, ele menciona de forma prtica como se aplicar o Scrum em projetos para desenvolvimento de software gil.
0

Gostei (4)

(0)
Artigo do tipo Exemplos Prticos Recursos especiais neste artigo: Contedo sobre boas prticas.

Porque esse artigo til O presente artigo conceitua o framework para projetos geis Scrum. Alm de apresentar os termos usados no Scrum, ele menciona de forma prtica como se aplicar o Scrum em projetos para desenvolvimento de software gil. O tema til porque ajuda as pessoas a entenderem os conceitos do Scrum e aborda um exemplo prtico para a empresa fictcia Software, Ltda com o desenvolvimento de histrias, Product Backlog, o jogo Planning Poker, Sprint, entre outros artefatos. Define-se Scrum como um processo gil ou ainda um framework para o gerenciamento de projetos geis. Por ser gil, apresenta princpios geis de como satisfazer as necessidades do cliente entregando o software o mais rpido possvel e com qualidade. O Scrum no descreve o que se deve fazer em cada situao, ele utilizado em trabalhos complexos nos quais impossvel predizer tudo que pode acontecer em um projeto de software. A primeira experincia com o Scrum ocorreu em uma fbrica de automveis, onde se verificou que os projetos utilizados em equipes pequenas e multidisciplinares produziam melhores resultados. Com base nessas essas equipes, associou-se a formao do Scrum a de um jogo de Rugby, ento Jeff Sutherland, John Scumniotales e Jeff McKenna documentaram e implementaram o Scrum.

A partir de 1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implantlo em projetos geis de software em todo o mundo. O Scrum pode ser usado para vrios desenvolvimentos, tais como: Software comercial e complexo; Software interno e terceirizado; Sistemas embarcados; Websites; Aplicaes para telefones celulares; Aplicaes para redes; Sistemas para controle de satlites; Sistemas para suporte vida. Alm disso, tambm pode ser utilizado para: Tornar a equipe multifuncional e autogerencivel; Controlar e gerenciar o trabalho; Implantar o conceito iterativo e incremental do desenvolvimento de software; Preservar as prticas da engenharia de software; Tornar a equipe produtiva; Valorizar os integrantes da equipe do projeto. Algumas caractersticas do Scrum so: Os clientes participam ativamente do projeto; Ocorrem entregas frequentes com todas as funcionalidades previstas desenvolvidas; Planos de mitigao de riscos frequentes; Discusso diria da equipe; Reunies frequentes com os envolvidos no projeto;

As horas de trabalho e reunies so definidas evitando o desgaste da equipe. O Scrum tem como valores: a transparncia, a integridade, a auto-organizao e a entrega de valores. Atualmente, so muitas as empresas que utilizam o Scrum, entre elas tm-se: Microsoft, Yahoo, Google, Philips, Nokia, Sabre, Siemens, BBC, Oce, Capital One, First American Real Estate, Nielsen Media, Xerox, HP, Borland, Globo, Abril, Uol, Locaweb, entre outras. O Scrum a estrutura de processos que possui grupos de prticas e papis pr-definidos. Nele, os principais papis so Product Owner, Scrum Master e Equipe.

Product Owner (PO)


O Product Owner, conhecido como o dono do produto, o responsvel por definir o projeto e levar equipe de trabalho a viso do produto. As principais caractersticas do Product Owner so: Definir o projeto; Alterar os requisitos do projeto; Definir prioridades; Definir as tarefas; Decidir a data de cada tarefa; Representar o cliente; a pessoa responsvel pelo retorno e investimento do produto; Aceitar ou rejeitar as entregas.

Scrum Master (SM)


O Scrum Master um integrante da equipe de desenvolvimento do software com algumas responsabilidades diferentes dos demais. As principais caractersticas do Scrum Master so: Ser o lder da equipe; Retirar impedimentos;

Proteger os integrantes da equipe; Auxiliar nas tarefas do grupo; Garantir as prticas do Scrum; Precisa ter total dedicao ao projeto; Ser o facilitador da equipe do projeto.

Equipe (EQ)
A equipe a responsvel pela execuo do projeto. A equipe gerenciada pelo Scrum Master e o seu principal objetivo atender as necessidades do Product Owner. As principais caractersticas da equipe so: Fazer estimativa; Definir as tarefas; Desenvolver o produto e/ou servio; Garantir um produto e/ou servio de qualidade; Formado na maioria das vezes por at sete pessoas; Apresentar o produto e/ou servio ao cliente; Os integrantes da equipe de um projeto de software precisam ter habilidades para desenvolver o sistema, testar, desenhar prottipos de tela, dentre outros. O tamanho da equipe de fundamental importncia, o Scrum no recomenda uma equipe grande, recomenda-se em torno de 2 a 7 pessoas. As equipes so menores para facilitar a comunicao durante o projeto. A formao da equipe multidisciplinar, sendo composta por analista de sistemas, engenheiro de software, analista de banco de dados, arquiteto de software, desenvolvedores, web designer, entre outros. Alm de ser multidisciplinar, a equipe tambm pode ser generalista, onde todos os membros realizam todos os papeis conforme a necessidade do projeto. As equipes do Scrum definem sua forma de trabalho e evolui essa forma atravs da execuo do projeto. Na equipe constitui-se o conceito de autogesto, onde ela ganha autonomia de deciso para o desenvolvimento do sistema.

Viso do produto

A viso do produto ou escopo do projeto a apresentao do projeto equipe de desenvolvimento. O principal objetivo da viso do produto apresentar os mdulos que sero construdos no sistema. A viso do produto pode ser realizada vrias vezes durante o projeto, atravs dela todos mantem informados, reduzindo ento os riscos de desentendimento da equipe diante dos objetivos definidos no projeto. Para executar a viso do produto, os membros da equipe precisam ser informados com antecedncia. No convite para a apresentao da viso do produto preciso ter o local da reunio, hora, data e a pauta da reunio. Na sala de reunies preciso disponibilizar para a equipe etiquetas coloridas colantes, papel e canetas. A Figura 1 apresenta um template de convite para reunio da viso do produto da empresa fictcia Software Ltda.

Figura 1. Convite para reunio Durante a reunio pode-se utilizar slides, filmes ou qualquer outro meio de transmisso de conhecimento. Os participantes precisam ter total liberdade para realizao de perguntas. O objetivo da reunio informar os mdulos, as principais entregas e fazer com que os integrantes tenham conhecimento do projeto. A Figura 2 exibe um exemplo de viso do produto.

Figura 2. Exemplo de viso do produto

Product Backlog
Aps a apresentao do produto preciso desenvolver uma relao de requisitos para o desenvolvimento do software. A relao dos requisitos denominada Product Backlog. A lista de requisitos pode ser organizada de vrias formas, sendo uma apenas com requisitos referentes ao negcio a ser desenvolvido ou uma lista com a relao dos requisitos envolvendo o negcio a ser desenvolvido mais os requisitos no funcionais do sistema (BOX 1). BOX 1. Requisitos no funcionais Requisitos no funcionais descrevem um aspecto (no funcional) que o sistema deve satisfazer. Podem estar relacionados s propriedades emergentes do software, como tempo de resposta, confiabilidade, segurana, desempenho, proteo, entre outras. No Scrum, todos os integrantes da equipe tm autoridade para acrescentar requisitos lista de requisitos do sistema, mas apenas o Product Owner pode priorizar estes requisitos. A priorizao dos requisitos do Product Backlog informa quando uma nova funcionalidade ser desenvolvida no projeto de software. Um exemplo de Product Backlog para a empresa Software Ltda segue conforme a Tabela 1, onde se tem o nvel de prioridade (alta, mdia, baixa), a categoria e a descrio do item.

abrir imagem em nova janela Tabela 1. Product Backlog para a empresa Software Ltda

Histria do Usurio (User Story)


A histria do usurio uma pequena descrio que informa com maiores detalhes um item do product backlog. A histria representa parte do produto a ser desenvolvido ou uma necessidade levantada que precisa ser implementada. Na maioria das vezes as histrias so levantadas em reunies e podem descrever desde alterao de um componente na tela at o desenvolvimento de uma nova funcionalidade no sistema. O importante na histria identificar se o que vai ser acrescentado no sistema foi compreendido pela equipe de desenvolvimento. Em algumas histrias a equipe pode dividir a atividade prevista para se ter o melhor controle do servio a ser realizado. Essa diviso deve ser sugerida ao Product Owner, uma vez que ele tem permisso para alter-la. A funo da equipe no Scrum no apenas desenvolver o software, como tambm auxiliar o Product Owner a melhor forma de concluir as histrias levantadas. Cada histria deve ser dividida em tarefas, sendo cada tarefa responsvel por representar passo a passo o que deve ser realizado por dia de trabalho. Para escrever uma histria, preciso reunir com os integrantes da equipe para detalhar e escrever todos os itens que devem ser realizados. Um exemplo de histria segue conforme as Figuras 3, 4 e 5 que apresentam trs histrias para o cadastro de funcionrio da empresa Software Ltda.

Figura 3. Histria com prioridade alta

Figura 4. Histria com prioridade mdia

Figura 5. Histria com prioridade baixa

Planning Poker
O planning poker a prtica para auxiliar na estimativa de uma histria ou de uma tarefa. O planning poker parecido com um jogo de baralho e tem suas regras bem definidas. Algumas regras apresentadas no jogo do Scrum so: Apresenta doze cartas numeradas: 0, , 1, 2, 3, 5, 8, 13, 20, 40 e 100; Apresenta duas cartas com smbolos: ? e uma carta com o desenho de uma xcara de caf. A Figura 6 apresenta as cartas utilizadas para o planning poker no Scrum.

Figura 6. Cartas do planning poker Para entender o uso das cartas no jogo do Scrum preciso compreender as cartas especiais, que so: 0: representa uma histria ou uma tarefa concluda ou quase concluda; 100: representa uma histria ou uma tarefa muito grande. As tarefas grandes devem ser divididas em sub tarefas; ?: representa uma histria ou uma tarefa indefinida, ou seja, ainda no se pode definir o prazo para tal histria ou tarefa; Desenho de uma xcara de caf: representa uma pausa para um caf, gua ou descanso. O desenho de uma xcara de caf acontece quando a reunio demorada e a equipe necessita de uma pausa por alguns minutos. O planning poker simples, o Product Owner expe as histrias ou as tarefas a serem desenvolvidas e cada integrante da equipe escolhe uma carta do jogo e apresenta na mesa.

A primeira histria ou tarefa a ser definida precisa ser a que demanda um tempo menor e menos esforo, j que ela ter o menor valor e ser referncia para as demais. Algumas equipes atribuem o menor valor como dois pontos. Aps definir a primeira histria preciso ler as outras e pontu-las conforme a numerao das cartas e o grau de dificuldade de cada histria ou tarefa. No planning poker, quando todos os integrantes da equipe colocarem as cartas na mesa, elas so viradas. Se houver cartas com numerao diferente, as diferenas so discutidas at que haja um consenso entre toda a equipe, caso contrrio a equipe pontua a histria ou tarefa a ser desenvolvida e passa para a prxima histria. Se durante o jogo as cartas apresentarem valores como ? ou 100, a equipe precisa devolver a histria ou a tarefa ao Product Owner para ser melhor esclarecida ou subdividida por ele. A Figura 7 apresenta as cartas expostas no planning poker da empresa Software Ltda onde os quatros integrantes do jogo apresentaram cartas com numerao diferentes.

Figura 7. Cartas com nmeros diferentes

A Figura 8 apresenta um exemplo de histria pontuada (oito pontos) atravs do planning poker para a empresa Software Ltda.

Figura 8. Histria pontuada atravs do planning poker Quando as histrias ou tarefas estiverem todas pontuadas, preciso planejar a primeira Sprint do projeto.

Sprint
A Sprint um ciclo de trabalho no Scrum que tende a durar em torno de uma semana e no mximo um ms. Antes de iniciar a Sprint, necessrio definir as histrias no Product Backlog conforme o seu grau de prioridade e pontuao estimada, para depois inclu-las na Sprint. O grupo de histrias inseridas na Sprint denomina-se Sprint Backlog. Definido o Sprint Backlog, inicia-se a Sprint, neste momento a equipe realiza um novo planejamento para dividir as histrias em pequenas tarefas de forma a obter melhor controle das tarefas individualmente. Durante a execuo da Sprint a equipe realiza as tarefas para a realizao das histrias, isso em ordem de prioridade. Essas tarefas so avaliadas diariamente atravs de reunio, onde a equipe informa o que foi realizado no dia anterior e se tiver impedimentos, informam tambm quais so os impedimentos em relao atividade. Ao trmino da Sprint a equipe realiza a reunio de reviso para apresentar as histrias implementadas durante a Sprint. Para melhor entendimento, a Figura 9 apresenta um quadro na Sprint. No quadro, o Product Owner insere as atividades previstas e controla-as de acordo com o desenvolvimento, isso conforme a situao da tarefa: Pendente, Iniciada e Concluda.

Figura 9. Quadro da Sprint Para melhor controle das tarefas o Product Owner poder utilizar o grfico Burndown. O grfico Burndown uma ferramenta para gerenciar projetos de software, ele permite visualizar o progresso das tarefas que esto sendo executadas. Outra ferramenta bem interessante para gerenciar o projeto seria o software Redmine. Alm de free, o Redmine permite o gerenciamento de todas as tarefas da equipe e permite o grfico Gantt (BOX 2). BOX 2. Grfico de Gantt O Grfico de Gantt ilustra o andamento de etapas de um projeto, no sendo restrito a projetos de software. Neste grfico, o eixo horizontal representa a linha do tempo desde o incio do projeto e sobre esse eixo so adicionadas barras coloridas indicando as fases ou tarefas de cada um. Cada barra posicionada sobre uma coordenada do eixo horizontal que indica o momento em que foi iniciada e estende-se at a posio no tempo em que foi finalizada. Atravs do grfico Gantt pode-se visualizar todo o progresso das tarefas no software Redmine. Um exemplo de grfico Gantt no Redmine segue na Figura 10. Na Figura 11 segue um exemplo de grfico Burndown.

Figura 10. Grfico Gantt

Figura 11. Grfico Burndown

Cerimnias na Sprint
As cerimnias so reunies que ocorrem em momentos distintos da Sprint. O conceito de Timebox aplicado na Sprint, onde Timebox representa o tempo para cada cerimnia. Na Sprint ocorrem as seguintes cerimnias: Reunio de planejamento da Sprint: a primeira reunio cujo objetivo planejar a Sprint. Ela dividida em duas partes. Na primeira parte definem-se as prioridades, os itens do Product Backlog e a meta da Sprint. Na segunda, determinam-se quais tarefas so necessrias para cumprir a meta do projeto. Toda a reunio de planejamento dura

em torno de oito horas e tem como participantes o Product Owner, a equipe e o Scrum Master; Reviso da Sprint: ocorre ao trmino da Sprint e seu objetivo apresentar o trabalho da equipe. Geralmente tem durao de quatro horas e tem como participantes o Product Owner, a equipe, o Scrum Master e outras pessoas convidadas; Retrospectiva da Sprint: ocorre aps a reviso da Sprint. Visa avaliar o que deu certo e o que deu errado durante a Sprint para fazer os ajustes necessrios na prxima Sprint. A retrospectiva da Sprint tende h durar trs horas e tem como participantes a equipe e o Scrum Master. Alm das cerimnias na Sprint, o Scrum apresenta a cerimnia de reunio diria, na qual devem estar presentes a equipe e o Scrum Master. Na reunio diria as pessoas se renem durante 15 (quinze) minutos de p e o principal objetivo atribuir trs questes aos participantes, que so: 1. O que fizeste ontem? 2. O que vais fazer hoje? 3. H algum impedimento? Para melhor entendimento sobre o Scrum a Figura 12 apresenta todo o processo desenvolvido com o framework para mtodos geis Scrum.

Figura 12. Todo o processo do Scrum

Concluso
O Scrum um excelente framework para projetos geis e que vem ganhando cada vez mais espao nas equipes de desenvolvimento de software, permitindo uma boa comunicao entre os membros da equipe e possuindo os seus papis, cerimnias e artefatos bem definidos. Atravs dos artefatos do Scrum como o Product Backlog, a Sprint Backlog e o grfico Burndown possvel desenvolver as tarefas criadas e gerar um produto ou servio que atenda os objetivos do projeto. Diante disso, o presente artigo buscou conceituar os termos inseridos no framework de Scrum e aplicar de forma prtica alguns conceitos em um estudo de caso para a empresa Software Ltda, de forma a fornecer ao leitor uma base para avanar nos estudos desse framework e aprofundar seus conhecimentos. Dessa forma, possvel analisar a viabilidade de utilizao do Scrum em um contexto especfico (considerando o projeto, recursos, equipe, etc) e, alm disso, estar apto a participar de projetos onde este framework seja utilizado. Links

A engrenagem do Scrum Apostila de apoio http://danielettinger.com/2011/04/06/a-engrenagem-do-scrum/ Blog do Scrum Apostila de apoio http://www.blogdoabu.blogspot.com Princpios geis: entrega e valor http://www.fabiocruz.com/outros/sprint-planning-sp1/ Scrum Experience http://rildosan.blospot.com

Celina Ferreira Ribeiro

Sou graduada no curso de Tecnologia em Sistemas para a Internet do Instituto Federal de Educao, Cincia e Tecnologia do Tocantins - Campus Palmas. Atuei durante quatro anos no Projeto SIGA-EPCT-EDU (Sistema Integrado de Gesto A [...]

Leia mais em: Conhecendo o Scrum http://www.devmedia.com.br/conhecendo-oscrum/29129#ixzz2jLRlRJFm

Das könnte Ihnen auch gefallen