1.

Metodologias geis
Um dos problemas relacionados s metodologias mais tradicionais de desenvolvimento de software est na identificao, registro e tratamento dos requisitos de negcio. No atual ambiente de desenvolvimento de software, os requisitos esto sujeitos a freqentes modificaes durante o ciclo de desenvolvimento do produto para atender as alteraes da demanda (RISING; JANOFF, 2000). Frente s dificuldades de adaptao dos mtodos tradicionais s necessidades de mudanas dos processos de desenvolvimento de software, surgiram, durante a dcada de 1990, os chamados mtodos geis. Estes mtodos foram influenciados pelos princpios da manufatura enxuta implementados pelas companhias Honda e Toyota e pelas estratgias de gesto do conhecimento de Takeuchi e Nonaka (2004) e Senge (1990). Trata-se de metodologias de desenvolvimento adaptativas e flexveis, e que so indicadas para cenrios onde a mudana de requisitos constante e os resultados precisam ser entregues ao cliente em curtos espaos de tempo. (CARVALHO; MELLO, 2009). Estas metodologias, portanto, visam os participantes e na interao entre eles com o projeto, na capacitao do software, na participao com o cliente e na adaptao rpida s mudanas. Isto atingido atravs de ciclos iterativos de desenvolvimento de sistemas com objetivos de curto prazo, tonando possvel a adaptao dos requisitos at o momento em que entram em fase de desenvolvimento.

2. Scrum
O Scrum uma metodologia gil para gesto e planejamento de projetos, um processo para construir software incrementalmente em ambientes complexos, onde os requisitos no so claros ou mudam com muita freqncia.

2.1

Conceitos bsicos

Segundo Sutherland (2000), o Scrum baseado em ciclos de 2 a 4 semanas, chamados de Sprints. A cada sprint o esforo para se entregar itens com o maior valor de negcio ao cliente, dando a ele algo real e de valor para o negcio.

2.2

Product Backlog

Product Backlog a lista de tudo que se deseja para o software, de uma maneira enxuta, sem detalhamento. O grande diferencial que essa lista no precisa estar completa logo no incio, no precisa ter 100% dos itens possveis e imaginveis.

2.3

O Time (Scrum team)

O Time responsvel por transformar itens do Product Backlog em itens do Sprint Backlog e transformar esses itens em software pronto para ser entregue.

As equipes de Scrum contm geralmente entre 5 e 9 pessoas, no mais do que 10, isso essencial para a boa prtica do Scrum. Os membros so multifuncionais, podendo conter desenvolvedores, designers, arquitetos da informao, etc. Outra caracterstica importante que os times so auto-gerenciveis, sendo eles responsveis por controlar as tarefas do desenvolvimento da Sprint.

2.4

Reunio Diria (Scrum Daily Meeting)

A reunio diria serve para a equipe se alinhar em relao ao desenvolvimento dos itens do Sprint Backlog. Esta reunio deve durar no mximo 15 minutos, seu contedo exposto pela equipe basicamente respondendo 3 perguntas:

O que eu fiz ontem? O que farei hoje? Quais impedimentos eu tive?

2.5

Reviso (Sprint Review)

Est uma reunio muito importante do ponto de vista do cliente, nela, tudo o

que foi desenvolvido durante a Sprint ser apresentada para os responsveis pelo projeto, o cliente em si, ou as pessoas que o represente. Cada histria (user stories) apresentada de acordo com a ordem de prioridade definida no Sprint Backlog, e o cliente d o aval final histria e indica se a Sprint atingiu a meta proposta.

2.6

Retrospectiva (Sprint Retrospective)

Ao trmino de cada Sprint, a equipe se rene para analisar a Sprint que encerrou, com o propsito de um constante aperfeioamento. Nessa reunio sero debatidos o que funcionou bem na Sprint, o que precisa ser melhorado e quais aes sero tomadas para colocar essas melhorias em prtica. Geralmente o Sprint Retrospective tem um timebox de 4hs de durao.

2.7

Product Owner

O Product Owner responsvel por criar o Product Backlog e prioriz-lo. Como ele quem sabe o que mais importante pro negcio, ele tambm far as alteraes dos itens, seja prioridade ou remoo e adio de novos. Este o cara que representa o cliente, que conhece o negcio e as regras do funcionamento dele.

2.8

Scrum Master

O Scrum Master o papel responsvel por fazer o ambiente Scrum funcionar, verificando se time esta respeitando e cumprindo os valores e prticas do Scrum. Ele tambm orienta o time no Daily Meeting corretamente e o responsvel por remover todos os impedimentos apontados.

Ele protege a equipe de interferncias externas, assegura que os Sprints no contenham itens alm do que pode ser realmente entregue. Em alguns lugares se tem a viso de que o Scrum Master um Gerente de Projetos, e no ! O Scrum Master um facilitador, algum que tem a misso de fazer o time funcionar e aplicar corretamente o Scrum.
3.

Ciclo

Segundo Varaschim (2009), o Scrum tem o progresso de desenvolvimento baseado em iteraes com durao entre duas e quatro semanas, chamadas de Sprints. A primeira etapa dentro do Sprint a reunio de planejamento (Sprint Planning), onde o time (Scrum Team), em conjunto com o cliente (Product Owner) define o que ser implementado na iterao, sendo responsabilidade do cliente realizar a priorizao do trabalho a ser feito. A prxima etapa a de execuo, onde o time detalha as tarefas necessrias para implementar o que foi solicitado pelo cliente e posteriormente inicia a execuo das mesmas. Durante o Sprint o time realiza reunies dirias (Daily Meeting) com no mais de 15 minutos para averiguar o acompanhamento do progresso do desenvolvimento, usando para isto o BurnDown Chart, que um grfico usado para o acompanhamento das tarefas a realizar, em andamento e j realizadas. Ao final do Sprint realizada uma reunio para a validao da entrega (Sprint Review), onde o cliente e quem mais tiver interesse no produto pode verificar se o objetivo do Sprint foi atingido. Logo aps, realizada apenas pelo time uma reunio (Sprint Retrospective) onde o Sprint avaliado sob a perspectiva de processo, time ou produto, quais foram os acertos e os erros com o objetivo de melhorar o processo de trabalho.

4. Vantagens e Desvantagens
A mudana da cultura da empresa. ( sim uma desvantagem, pois como j foi dito o scrum para ter sucesso deve ser seguido regra por regra) O grupo deve ser do mesmo nvel (e de nvel alto), pois so poucas pessoas trabalhando. O problema de entendimento entre o PO (Product Owner), cliente e o restante da equipe, tambm uma desvantagem que deve ser tratada para que o projeto no seja aceito no final Projeto no documentado. A falta de documentao de software gera custos na hora da manuteno e no suporte, pois na hora de alterar alguma funcionalidade, sem documentao, o analista ou programador poder ficar perdido ou alterar algo que no poderia ser alterado. Esse um dos principais problemas na metodologia. Falta planejamento do escopo. A metodologia no aborda nenhum tipo de planejamento do escopo apenas que se deve ter um Backlog. Contudo, esse backlog sofre mudanas e fica a cargo da equipe avaliar e controlar esse backlog. A equipe tender sempre para o cliente, pois ele busca a satisfao do mesmo,

porm, pode deixar escapar itens que no era para serem feitos, ou seja, o risco de ser feito itens fora do escopo aumenta e a empresa pode perder dinheiro com isso.

5. Referncias
RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small Teams, IEEE Software, Vol. 17, No. 4, July-August 2000. CARVALHO, B. V.; MELLO, C. H. P. Reviso, anlise e classificao da literatura sobre o mtodo de desenvolvimento de produtos gil Scrum. Anais do XII Simpsio de Administrao da Produo, Logstica e Operaes Internacionais - SIMPOI, So Paulo/SP, 2009. FRANCO, 2006 SUTHERLAND, J. Agile Development: lessons learned from the first scrum. Cutter Agile Project Management Advisory Service. Executive Update, Vol. 5, No. 20. 2004 VARASCHIN, J. Implantando o SCRUM em um Ambiente de Desenvolvimento de Produtos para Internet. PUC, Rio de Janeiro, 2009. SENGE, P. The Fifth Discipline: the Art and Practice of the Learning Organization. New York: Currency, 1990. TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p. 137- 146, 1986.

Questes
1- O Scrum permite definir uma data final para o projeto? Ele permite que se tenha uma viso de data final atravs do burndown graph, o prazo vai sendo modificado ao longo da execuo do projeto (diariamente) e cabe ao Scrum Master garantir o cumprimento do prazo de cada sprint. Uma estratgia para alcanar um prazo especfico o dimensionamento dos sprints (mais curtos, mais longos, com maior ou menor quantidade de entregas ou de sprints). 2- Se a equipe auto-gerencivel, qual a importncia do Scrum Master?

O Scrum Master faz o controle do escopo, da alocao da equipe, puxa o ritmo de trabalho e arbitra conflitos, se necessrio. Ele tambm a porta de comunicao com Product Owner e alta gerncia.