Anda di halaman 1dari 19

Metodologias geis: Evoluo necessria

POR
TIAGO SOUZA
19 DE SETEMBRO DE 2009PUBLICADO EM: GESTO DE PROJETOS, NEGCIOS

Com a evoluo dos softwares, cada vez mais preciso


inovar durante o desenvolvimento, desde novas tecnologias,
funcionalidades at novas metodologias e para suprir essa
necessidade do mercado softwares house vem buscando
metodologias geis com o foco em reduo de risco e
aumento da produtividade.
As metodologias geis so baseadas no processo iterativo,
mas usam como comunicao o mecanismo de controle
primrio, que vem de testes e uso das verses do software
desenvolvido, e para atender ao mercado de maneira rpida
e eficiente a evoluo vista a todo o momento, seja em
uma reunio, seja ao final de cada semana de trabalho.
Hoje podemos encontrar diversas metodologias para desenvolvimento de softwaregil como SCRUM,
Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method
(DSDM), entre outras, abaixo um pouco mais sobre essas metodologias.

SCRUM uma metodologia de gesto e baseia-se em atividades de monitoramento


e feedback, com reunies rpidas e dirias com suas equipes de poucos integrantes, visando a
identificao e correo de qualquer problema no processo de desenvolvimento.

Extreme Programmimg uma metodologia voltada para equipes pequenas e mdias, que
desenvolvem software baseado em requisitos no totalmente definidos e que se modificam
rapidamente.

Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) uma das


seis metodologias geis originais, cujos representantes redigiram o Manifesto gil para
Desenvolvimento de Software (http://agilemanifesto.org/), em 2001.

Dynamic Systems Development Method (DSDM) uma metodologia de desenvolvimento


de software inicialmente baseada na metodologia Rapid Application Development, sendo iterativa
e incremental, com uma abordagem que enfatiza a continuidade do envolvimento dos utilizadores.

Grande parte dessas metodologias tem como foco principal o desenvolvimento de software em perodos
curtos que so chamados iteraes. Essas iteraes duram em mdia de duas a quatro semanas e so
tratadas como miniaturas do projeto. Ao final de cada perodo de iterao possvel ter um software j
com partes funcionais, possvel de ser usado. Alm disso, elas possuem todas as etapas necessrias
para o desenvolvimento do software.
Mas preciso ressaltar que mudar a metodologia de desenvolvimento de software de uma empresa no
acontece da noite para o dia, preciso mudar o jeito de agir e pensar de todos os integrantes da equipe
de desenvolvimento e outras pessoas envolvidas com essa equipe, ou seja, uma mudana cultural deve
acontecer de forma gradual. O primeiro passo para essa mudana adaptar os processos da
metodologia gil que ser utilizada, pois as prticas propostas por essa metodologia nem sempre so
necessrias para a sua empresa, ou mesmo no so totalmente acoplveis a sua equipe e viso cultural
da empresa.

Metodologias de Desenvolvimento gil Parte 1:


Introduo
POR
FERNANDO FONTE
22 DE MAIO DE 2012PUBLICADO EM: EXTREME PROGRAMMING (XP), GESTO DE
PROJETOS, SCRUM

Estamos comeando hoje uma srie de artigos sobre Metodologias


de Desenvolvimento gil. Estes artigos so baseados no Trabalho de Concluso de Curso apresentado
como exigncia para a obteno do grau de Bacharel em Cincia da Computao da Faculdade
Anhanguera de Campinas Unidade 3, denominado Metodologias de Desenvolvimento gil
Aplicadas No Desenvolvimento DeSoftwares Em Empresas De Pequeno Porte, escrito por Felipe
Morandin, Fernando Fonte e Tiago Souza.
Espero que voc aproveite a leitura.
1 INTRODUO:
1.1 Apresentao:
O desenvolvimento de software algo relativamente recente e desde o seu surgimento procura sempre
facilitar a execuo de tarefas que so feitas com frequncia. Os primeiros programas eram criados para
realizar funes simples como fazer clculos ou criar pequenos textos; com o tempo e com o
desenvolvimento das tecnologias utilizadas nos computadores, os programas comearam a ser maiores,
mais complexos e mais funcionais.
Com essa evoluo dos softwares, as software houses[1] comearam a buscar novas metodologias,
como por exemplo as metodologias geis, para o desenvolvimento de programas visando, entre outras
coisas, a reduo de risco nos projetos e uma maior produtividade.
Segundo alguns dados (Grey, 1995) o desenvolvimento de software uma atividade cada vez mais
passvel de erros de projeto e de execuo e, entre seus principais riscos, pode-se citar os gastos que
sempre superam o oramento, o consumo de tempo que supera o cronograma, os requisitos mal
elaborados (o que faz com que o problema do usurio dificilmente seja solucionado) e a baixa qualidade
nos sistemas desenvolvidos (Fowler, 2003).
Todos esses riscos podem gerar diversos problemas dentro da empresa, pois no caso dos prazos
terminarem, os funcionrios sofrero mais uma presso para terminar o programa e com isso a qualidade
do cdigo, consequentemente cair, fazendo com que o cliente ou no receba seu produto no prazo, ou o
receba com m qualidade. Tudo isso far com que ele no volte a confiar nessa empresa para prover
novas solues.
Todos esses fatores incentivaram uma busca constante por uma melhora, por uma soluo para esses
problemas (Braga). Essa busca teve como marco inicial a criao da chamada Engenharia de Software, e
desde sua criao, o processo de desenvolvimento de software vem recebendo inmeras propostas para
melhorar os seus passos. Essas propostas podem ser dividas em trs grandes processos. So eles:

Processo em cascata: todo o processo feito em etapas rgidas que s podem ser
comeadas quando a anterior j estiver finalizada. Alm de ter as etapas bem definidas, esse
processo caracterizado por ter os papis dentro da equipe bem definidos. Nesse tipo de
processo cada pessoa realiza a sua atividade preocupando-se somente com uma parte do
processo, com a sua tarefa entregue. Nesse tipo de processo comum tambm que as pessoas
envolvidas com o processo no saibam exatamente tudo o que feito, tudo o que usado dentro
do projeto e, em alguns casos, qual ser o resultado final.

Processo iterativo: este processo visa construo de uma pequena parcela do projeto,
assim reduz o tempo em que os problemas so encontrados, facilitando a correo e evitando o
atraso do projeto.

Processo gil: esse processo baseado no processo iterativo, mas usam como
comunicao o mecanismo de controle primrio, que vem de testes e uso das verses do software
desenvolvido.

Esses processos buscam o aperfeioamento e o adequamento do projeto dentro das necessidades


apresentadas pelo mercado. sempre o mercado o responsvel pelas mudanas de processos, pois,
esse sempre est em movimento, sempre est sofrendo alteraes e, com isso, sempre pede uma
alterao no esperada ou novas funcionalidades para que o projeto continue atendendo as expectativas
do cliente. Para atender ao mercado de maneira rpida e eficiente, importante adequar o
desenvolvimento de software a essas mudanas.
No processo de desenvolvimento de software convencional, o resultado de requisies para adicionar
uma nova funcionalidade ao sistema, ou mesmo para efetuar uma correo, s disponibilizada quando
uma nova verso do software liberada. Na metodologia gil, a evoluo vista a todo o momento, seja
em uma reunio, seja ao final de cada semana de trabalho.
Hoje podemos encontrar diversas metodologias para desenvolvimento de software gil como
SCRUM[2] (Wells, 2006), Extreme Programming (XP[3]) (Jeffries, 2008), FDD[4] (Web Site a, 2008),
DSDM[5] (Alexandrou, 2008) entre outras. Grande parte dessas metodologias tem como foco principal o
desenvolvimento de software em perodos curtos que so chamados iteraes. Essas iteraes duram
em mdia de duas a quatro semanas e so tratadas como miniaturas do projeto. Ao final de cada perodo
de iterao possvel ter um software j com partes funcionais, possvel de ser usado. Alm disso, elas
possuem todas as etapas necessrias para o desenvolvimento do software.
A metodologia de desenvolvimento gil reala a comunicao frente a frente entre os integrantes da
equipe. Para tornar essa comunicao um item positivo para o projeto, os integrantes essenciais para
concluso do mesmo (clientes, gerentes, analistas de negcios, etc.) so reunidos em uma nica sala
para discutir as necessidades do software e esclarecer as dvidas que ainda restam para seu
desenvolvimento.
Os mtodos de desenvolvimento gil visam, principalmente, os aspectos humanos dentro de um projeto
e, justamente por isso, que eles demonstram sucesso.
O objetivo deste trabalho apresentar a utilizao e aplicao da metodologia SCRUM em empresas de
pequeno porte que utilizam metodologias de desenvolvimento em cascata ou iterativos, visando a
agilidade no desenvolvimento de software, e assim fazendo com que o processo comum de
desenvolvimento (que visa o levantamento total dos requisitos, compreenso e domnio do problema
antes do inicio do desenvolvimento), seja substitudo pelo processo de desenvolvimento gil que visa o
levantamento parcial e planejamento constantes.
Essa metodologia vem para, como foi dito anteriormente, trazer agilidade para o processo e para a
produo de resultados satisfazendo o cliente em uma menor frao de tempo. O uso dessa metodologia

tem sido amplamente divulgado por todo o mundo e vem causando grandes modificaes nas formas de
pensar e agir de gerentes, clientes e todas pessoas que esto diretamente ligadas com o projeto.
No captulo 2 deste trabalho so apresentadas as principais caractersticas das metodologias Extreme
Programming (XP) e SCRUM. No captulo 3 discutido como as empresas de pequeno porte esto
utilizando estas metodologias. Nele ainda, so apresentadas as dificuldades de implantao e ganhos e,
por fim, no captulo 4 so demonstrados os resultados alm de apresentar concluses e possveis
sugestes.

[1]

Software houses so empresas que se dedicam a produzir esses produtos

[2]
SCRUM uma metodologia de questo baseia-se em atividades de monitoramento e
feedback, com reunies rpidas e dirias com suas equipes de poucos integrantes, visando a
identificao e correo de qualquer problema no processo de desenvolvimento.
[3]
Extreme Programmimg uma metodologia voltada para equipes pequenas e mdias, que
desenvolvem software baseado em requisitos no totalmente definidos e que se modificam rapidamente.
[4]
Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) uma das seis
metodologias geis originais, cujos representantes redigiram o Manifesto gil para Desenvolvimento de
Software, em 2001.
[5]
Dynamic Systems Development Method (DSDM) uma metodologia de desenvolvimento de
software inicialmente baseada na metodologia Rapid Application Development, sendo iterativa e
incremental, com uma abordagem que enfatiza a continuidade do envolvimento dos utilizadores.

Metodologias de Desenvolvimento gil Parte 2:


Tcnicas
POR
FERNANDO FONTE
29 DE MAIO DE 2012PUBLICADO EM: EXTREME PROGRAMMING (XP), GESTO DE
PROJETOS, SCRUM,TECNOLOGIA

Esta a segunda parte da srie de artigos sobre Metodologias de


Desenvolvimento gil. Estes artigos so baseados no Trabalho de Concluso de Curso apresentado
como exigncia para a obteno do grau de Bacharel em Cincia da Computao da Faculdade
Anhanguera de Campinas Unidade 3, denominado Metodologias de Desenvolvimento gil
Aplicadas No Desenvolvimento DeSoftwares Em Empresas De Pequeno Porte, escrito por Felipe
Morandin, Fernando Fonte e Tiago Souza.
Espero que voc aproveite a leitura.
2 TCNICAS DE DESENVOLVIMENTO GIL
2.1 Apresentao
O desenvolvimento de software utilizando metodologias de desenvolvimento gil criou novos pontos de
vista para o desenvolvimento de software. Alguns desses pontos vieram para quebrar paradigmas
gerados por metodologias em cascata[1].
O marco inicial para a quebra desses paradigmas surgiu oficialmente no dia 13 de fevereiro de 2001, no
qual 17 pessoas em busca de um mesmo ideal uniram-se e assinaram o que batizaram de Manifesto gil,
cujo objetivo principal criar uma forma de desenvolvimento mais eficaz.
Esse manifesto possui uma caracterstica marcante para o desenvolvimento de software. Ele muda a
viso de que um desenvolvimento com qualidade precise de processos e ferramentas bem definidos,
documentao extremamente abrangente e cercada de negociaes para o fechamento de contrato, alm
de um plano totalmente fechado. Todas essas caractersticas so substitudas por um software funcional
criado por indivduos envolvidos diretamente com o projeto e interagindo diretamente com o cliente, ou
seja, criando uma relao com o cliente e assim sendo possvel prever mudanas necessrias durante o
desenvolvimento.
Embora as caractersticas de maior valor no desenvolvimento de software sejam as apresentadas como
os pontos a serem substitudos, a metodologia gil prioriza as novas caractersticas apresentadas, por
afirmar que elas possuem maior importncia para o desenvolvimento de software. Para o desenvolvedor,
a agilidade gira em torno da expanso com o parecer do cliente e da equipe de desenvolvimento.

[1]
Metodologias em cascata so as que aplicam o modelo Waterfall que consiste, basicamente,
em ter cada etapa bem definida e uma etapa s comea quando a anterior foi finalizada

Metodologias de Desenvolvimento gil Parte 3:


Extreme Programmimg (XP)
POR
FERNANDO FONTE
05 DE JUNHO DE 2012PUBLICADO EM: EXTREME PROGRAMMING (XP), GESTO DE
PROJETOS, SCRUM

Esta a terceira parte da srie de artigos sobre Metodologias de


Desenvolvimento gil. Estes artigos so baseados no Trabalho de Concluso de Curso apresentado
como exigncia para a obteno do grau de Bacharel em Cincia da Computao da Faculdade
Anhanguera de Campinas Unidade 3, denominado Metodologias de Desenvolvimento gil
Aplicadas No Desenvolvimento DeSoftwares Em Empresas De Pequeno Porte, escrito por Felipe
Morandin, Fernando Fonte e Tiago Souza.
Espero que voc aproveite a leitura.
2.2 Extreme Programmimg
2.2.1 Caractersticas do conceito
Extreme Programmimg, mais conhecido como XP, uma das metodologias de
desenvolvimento geis mais populares. Foi criada por Kent Back e Want Cunningham entre a dcada de
80 e 90, tendo como principal ponto de referncia a experincia no desenvolvimento em Smalltalk , cujas
suas principais prticas so: refatorao, programao em par, mudanas rpidas e no previstas,
feedback constante do cliente, desenvolvimento iterativo e testes automatizados, analisando o Smalltalk
sobre esse ponto de vista o XP pode ser o modo de agir do Smalltalk para outros ambientes, sem muitas
novidades (Beck, 1999).
2.2.2 Metodologias
O Extreme Programmimg por sua vez define um conjunto de doze prticas de desenvolvimento, sobre os
quatros valores adotados pelo XP como sendo os pontos mais relevantes no desenvolvimento.
2.2.2.1 Valores
Os quatros valores adotados pelo XP so feedback, comunicao, simplicidade e coragem, descritos nas
seguintes sees (Beck, 1999).
2.2.2.2 Feedback
A compreenso dos requisitos por parte dos desenvolvedores uma das atividades mais complexas em
todo o desenvolvimento, isso por sua vez to difcil quanto o cliente transmitir suas necessidades e
desejos do software, assim para amenizar essa dificuldade, fundamental que haja uma forte interao
entre o cliente e os desenvolvedores ao longo do desenvolvimento.

Por sua vez a compreenso das necessidades vem de um aprendizado contnuo, nela o desenvolvedor
apreende sobre os problemas do negcio e as limitaes tcnicas (Weinberg, 1971, p.102).
Com a diminuio da defasagem do sistema, o desempenho do mesmo s tende aumentar, isso obtido
atravs da ampliao do aprendizado do software obtido pelos desenvolvedores e o entendimento das
possibilidades tecnolgicas e suas limitaes (Senge, 2002, p.119).
2.2.2.3 Comunicao
Os projetos de software sempre envolvem duas partes e por isso para o desenvolvimento a comunicao
essencial, atravs dessa comunicao que o usurio informa o que ele necessita, e, que o
desenvolvedor apresenta as consideraes que afetam a soluo e a velocidade de implementao da
mesma.
Ambas as partes podem ser compostas por vrias pessoas e com isso a frequncia da comunicao
entre elas tende a ser cada vez mais dinmica o que faz com que haja desentendimentos ou
incompreenso de algum aspecto do projeto.
A transmisso das idias dentro da equipe que est desenvolvendo o projeto precisa ser eficaz, e isso
pode ser resolvido de forma simples. Um dos melhores mecanismos colocar todos da mesma equipe
em um nico local, onde todos podero compartilhar suas idias atravs do dilogo e consequentemente
os vrios elementos que compem a comunicao, tais como expresses faciais, gestos, postura,
palavras verbalizadas e tom de voz estaro ao alcance de todos. (Teles, 2004, p.48)
A velocidade com que a comunicao se estabelece entre as partes envolvidas no projeto de extrema
importncia para o andamento e o custo do projeto (Cockburn, 2002, p.81).
2.2.2.4 Simplicidade
Segundo estudos grande parte dos recursos gastos no desenvolvimento de software, so esforos
desnecessrios, pois so funcionalidades que nem sequer sero utilizadas. A ocorrncia de fenmenos
durante o desenvolvimento ajudam a esclarecer esse esforo desnecessrio, so eles:
Com o escopo fechado do projeto, quando as alteraes surgem os desenvolvedores evitam implant-las
assim que mencionadas.
Desenvolvem-se solues genricas para facilitar as alteraes solicitadas.
Produo de funcionalidades adicionais na tentativa de antecipar as solicitaes de alteraes.
Os casos acima so influenciados devido s preocupaes que so justificveis, pois fixar o escopo no
inicio do projeto arriscado, j que as verdadeiras necessidades so notadas quando o software
implantado, por isso a adoo de um modelo de desenvolvimento iterativo com iteraes curtas, assim
como o XP proporciona (Poppendieck & Poppendieck, 2003).
Para que uma equipe de desenvolvimento seja capaz de suprir essas necessidades necessrio
desenvolver funcionalidades com um pequeno escopo, isso leva ao desenvolvimento somente dos itens
essenciais com a maior qualidade possvel e de forma que novas funcionalidades sejam inseridas com
facilidade (Boehm & Turner, 2003, p.41).

2.2.2.5 Coragem
Alguns temores costumam assombrar os desenvolvedores e os clientes envolvidos no projeto, esses
temores por sua vez exercem influncia significativa no desenvolvimento.

Clientes temem:

No obter o que pediram;

Pedir a coisa errada;

Pagar demais por muito pouco;

Jamais ver um plano relevante;

No saber o que est acontecendo e

Fixarem-se em suas primeiras decises e no serem capazes de reagir a mudanas nos


negcios.

Desenvolvedores, por sua vez, temem:

Ser solicitados a fazer mais do que sabem fazer;

Ser ordenados a fazer coisas que no faam sentido;

Ficar defasados tecnicamente;

Receber responsabilidades, sem autoridade;

No receber definies claras sobre o que precisa ser feito;

Sacrificar a qualidade em funo de prazo;

Ter que resolver problemas complicados sem ajuda e

No ter tempo suficiente para fazer um bom trabalho.

As equipes XP reconhecem esses temores e buscam formas de lidar com eles utilizando mecanismos de
segurana para garantir a qualidade do projeto, minimizando o risco desses temores (Beck e Fowler,
2001).
O cliente teme no obter o que foi solicitado, ou mesmo solicitar algo de que no precisa, para proteg-lo
o XP constitudo de iteraes curtas, e mesmo que o cliente solicite algo que no precisa ou a equipe
de desenvolvimento implemente algo de maneira errada, isso logo descoberto devido ao curto tempo
entre as iteraes no desenvolvimento (Poppendieck & Poppendieck, 2003).
Outra preocupao dos desenvolvedores no ter tempo suficiente para desenvolver as funcionalidades
necessrias com qualidade, o XP trata dessa preocupao dividindo a responsabilidade pelas decises
tcnicas e de negcio, o cliente escolhe as funcionalidades a serem implementadas e em que ordem e os
desenvolvedores estimam os prazos necessrios para o desenvolvimento (Beck e Fowler, 2001).
2.2.3 Prticas
As prticas citadas abaixo devem ser aplicadas em conjunto, pois aplicadas de modo isolado podem no
produzir a agilidade esperada, isso se deve ao fato das prticas apoiarem umas as outras.
2.2.3.1 Jogo de planejamento (The Planning Game)
Atravs desse planejamento possvel determinar o escopo das prximas verses, baseando-se na
combinao das prioridades do negcio e estimativas tcnicas. O planejamento assegura que toda a
equipe siga trabalhando no mais importante a cada momento do projeto.

O planejamento de projetos com metodologia XP procurar dividir o projeto utilizando dois conceitos:
releases[1] e iteraes. Dentro desses dois conceitos so encontradas subdivises; o release tem
durao de poucos meses e se divide em iteraes que tem a durao de aproximadamente duas
semanas. Dentro dessas iteraes as tarefas so dividas de forma que ocupem alguns dias (Beck &
Fowler, 2001, p.139).
O release representa um conjunto de funcionalidades fechadas que so liberadas para o uso do usurio
aps o trmino do tempo determinado no planejamento, neste momento o cliente, junto com a equipe de
desenvolvimento, realiza testes e avalia as novas prioridades para o prximo release, com isso os ajustes
e erros encontrados so detectados antes do prximo desenvolvimento (Jeffries & Anderson, 2001, p.55).
Como foi dito anteriormente a responsabilidade pela definio das prioridades feita pelo cliente e a
estimativa feita pela equipe responsvel pelo desenvolvimento, o que faz com que o cliente tenha uma
viso sobre o custo e tempo que o prximo release levar para ser concludo e qual o seu custo estimado
(Jeffries & Anderson, 2001, p.14).
2.2.3.2 Pequenas Verses (Small releases)
O XP procura maximizar o retorno dos projetos assegurando que o maior valor de negcio possvel seja
entregue ao final de cada release e que cada release tenha uma durao curta. Isso feito atravs do
processo contnuo de priorizao que seleciona sempre as funcionalidades de maior valor para serem
implementadas primeiro. Alm disso, procura antecipar o retorno entregando software rapidamente.
Essa metodologia trabalha com a prtica de releases curtos que consistem em colocar o sistema em
produo com freqncia, em prazos curtos, normalmente de dois ou trs meses. Isso costuma ser bemvindo, porque clientes querem entregas rpidas (Poppendieck & Poppendieck, 2003, p.70-71).
Colocando releases em produo rapidamente, o cliente tem a oportunidade de receber feedback
concreto sobre o real potencial de retorno do projeto. Portanto, tem a chance de decidir cedo, quando
ainda no gastou muito, se continua ou no com o projeto e particularmente se continua ou no
investindo na mesma equipe de desenvolvimento. Portanto, a adoo de releases curtos funciona como
uma estratgia de gesto de risco do projeto (Teles, 2004).
2.2.3.3 Metfora (Metaphor)
Uma equipe de desenvolvimento formada por diversos programadores convive, entre outros, com o
desafio de manter a integridade conceitual do sistema mesmo havendo diversos projetistas criando
estruturas novas na arquitetura ao longo do tempo. Isso pode ser resolvido caso exista um mecanismo
capaz de alinhar as idias dos diversos projetistas assegurando que todos compartilhem uma viso nica
de como adicionar e manter as funcionalidades do sistema. O XP utiliza o conceito de metfora para
atingir este objetivo (Cockburn, 2002, p.227).
Segundo Cockburn (2002, p.227) a programao vista como uma atividade atravs da qual os
programadores formam ou atingem uma certa idia, uma teoria, sobre os problemas que tm nas mos,
ou seja, o programador capaz de explicar o que cada parte do programa capaz de fazer e responder
de imediato sobre qualquer modificao do sistema. Essas teorias representam a viso de como as
decises influenciam na estrutura do software.
2.2.3.4 Projeto Simples (Simple design)
Existem pelo menos quatro coisas que os usurios de um software esperam dele:

Que faa a coisa certa;

Que funcione;

Que seja fcil de utilizar;

Que possa evoluir com o tempo.

As prticas do XP se complementam formando um conjunto que busca atingir estes objetivos. Para
assegurar que o sistema esteja fazendo a coisa certa e esteja funcionando, o desenvolvimento
executado em iteraes curtas nas quais se implementa um pequeno conjunto de funcionalidades e por
sua vez o feedback gerado ao final de cada iterao permite que os usurios avaliem se o sistema
realmente est fazendo a coisa certa e se est funcionando.
Adotar iteraes curtas, portanto, um mecanismo importante para atingir parte destes objetivos,
entretanto, impe um desafio. Como fazer a anlise, design, implementao, teste e depurao de um
conjunto de funcionalidades em uma ou duas semanas? Isso s possvel se os desenvolvedores
mantiverem o design da aplicao suficientemente simples (Beck, 2000).
2.2.3.5 Testes (Testing)
Sistemas computacionais e projetos de software costumam vivenciar diversas dificuldades ao longo do
tempo. Um dos problemas mais caros e recorrentes a incidncia de defeitos.
Quando um defeito identificado, faz-se necessrio depurar o software. Por isso, essencial que as
equipes de desenvolvimento sejam capazes de reduzir a incidncia de bug[2]s e o custo associado
depurao e eliminao dos mesmos. Isso vlido durante o projeto, porm ainda mais relevante
durante a manuteno do sistema.
Os desenvolvedores se concentram em dois aspectos durante a programao. O cdigo deve se manter
limpo e precisa funcionar. O XP se concentra sobretudo em dois tipos de testes: o teste de unidade e o
teste de aceitao. O primeiro tenta assegurar que cada componente do sistema funcione corretamente.
O segundo procura testar a interao entre os componentes, as quais do origem s funcionalidades
(Beck, 2000).
2.2.3.6 Refatorao (Refactoring)
Sistemas mudam ao longo do tempo, especialmente quando so desenvolvidos de forma interativa.
Tradicionalmente os reparos tendem a prejudicar a estrutura e, alm disso, sem melhoria contnua
qualquer sistema de software ficar com vrios problemas. As estruturas internas iro se calcificar e se
tornar frgeis (BROOKS, 1995, p.243).
Por esta razo, projetos XP investem diariamente no aprimoramento do design e na identificao de
pontos da arquitetura que estejam se degradando, a medida que eles so encontrados, so corrigidos
atravs de uma tcnica conhecida como refatorao.
A refatorao o processo de fazer mudanas em um cdigo existente e funcional sem alterar seu
comportamento externo. Em outras palavras, alterar como ele faz, mas no o que ele faz. O objetivo
aprimorar a estrutura interna (Astels, 2003, p.15).
Tal processo conduzido permanentemente por todos os desenvolvedores como uma forma disciplinada
de limpar o cdigo minimizando a chance de introduzir bugs (Fowler, 2000, p.xvi)
Portanto, o objetivo elaborar programas que sejam fceis de ler, tenham toda a lgica em um e apenas
um lugar, no permitam que mudanas ameacem o comportamento existente e permitam que lgicas
condicionais sejam expressas da maneira mais simples possvel (Fowler, 2000, p.60).
2.2.3.7 Programao em par (Pair Programming)
Segundo Williams e Kessler (2003, p.3) programao em par um estilo de programao no qual dois
programadores trabalham lado a lado em um computador, continuamente colaborando no mesmo design,
algoritmo, cdigo e teste. Durante um projeto XP as equipes utilizam essa tcnica.
Esta tcnica implementada para reduzir os riscos de eventuais falhas. Quando um programador
desenvolve em par, ele conta com a presena de outro desenvolvedor que faz uma inspeo imediata de
todo o cdigo que produzido.

10

A programao em par torna-se um processo dirio de teste, no qual a equipe de desenvolvimento


consegue utilizar inspees com freqncia sem incorrer nos problemas que tornam os testes
tradicionalmente desagradveis.
A programao em par tambm til no processo de aprendizado dos desenvolvedores, j que os
desenvolvedores compartilham seus conhecimentos (Williams & Kessler, 2003, p.29).
Finalmente, a programao em par tambm ajuda a elevar a motivao dos desenvolvedores, tornando o
trabalho mais divertido e facilitando a comunicao. Naturalmente, quanto mais agradvel e divertido for
o trabalho de programao, mais produtivo o mesmo tender a ser (Williams & Kessler, 2003, p.239).
2.2.3.8 Propriedade Coletiva (Collective owneship)
Equipe XP pratica o conceito de cdigo coletivo, ou seja, todo o cdigo desenvolvido pertence equipe,
isto , qualquer um da equipe pode melhorar o que for necessrio (Jeffries & Anderson, 2001, p.122).
Isto significa que os desenvolvedores tm a oportunidade de trabalhar com pessoas diferentes e em
partes diferentes do cdigo. Como as alteraes no cdigo podem causar erros, a prtica de cdigo
coletivo s pode ser adotada com segurana se a equipe investir em testes automatizados (Beck, 2000,
p.99-100)
A adoo do cdigo coletivo tambm permite que a equipe avance mais rapidamente. O cdigo
permanece mais limpo porque os programadores no so forados a contornar uma deficincia em um
objeto criando um outro (Jefries & Anderson, 2001, p.122).
A propriedade coletiva do cdigo bastante utilizada juntamente com a programao em par, pois
possvel identificar cdigos complexos dentro de pouco tempo (em algumas horas) e com isso os
programadores so obrigados a colocar no sistema cdigos simples e eficazes.
2.2.3.9 Interao continua (Continuous integration)
Equipes XP normalmente so compostas por diversos programadores, trabalhando em pares de acordo
com a prtica de cdigo coletivo. Isso cria dois problemas prticos. O primeiro que diversos indivduos
esto trabalhando na mesma funcionalidade e ocorre uma necessidade de sincronizao. O segundo
que os pares precisam ser capazes de evoluir rapidamente sem interferir no trabalho uns dos outros
(Poppendieck & Poppendieck, 2003, p.34).
Esta questo resolvida no XP utilizando-se uma prtica conhecida como integrao contnua. Os pares
trabalham de forma isolada, porm integram, diversas vezes ao dia, o que produzem com a verso mais
recente do cdigo em produo. Isto , os pares se sincronizam com freqncia medida que terminam
pequenas atividades de codificao (Beck, 2000).
O processo de integrao serial, ou seja, somente um par pode integrar o seu cdigo de cada vez,
assim assegura-se que eventuais erros de integrao estaro sempre relacionados a um nico par:
aquele que est integrando no momento. Somente aps assegurar que a integrao est perfeita, todos
os testes executam com sucesso e o sistema encontra-se em um estado consistente poder outro par
fazer a integrao (Beck, 2000).
2.2.3.10 Semana de 40 horas (40-hour week)
O XP defende um ritmo de trabalho que possa ser mantido, sem prejudicar o bem estar da equipe.
Trabalho alm do horrio normal pode ser necessrio, mas fazer horas extras por perodos maiores que
uma semana sinal de que algo est errado com o projeto.
2.2.3.11 Cliente junto ao desenvolvedor (On-site customer)
No desenvolvimento de software medir o tempo necessrio que ser gasto at o fim do desenvolvimento
uma tarefa completamente complexa, pois o tempo est atrelado a diversos problemas que podem
ocorrer durante o desenvolvimento.

11

Para facilitar o cumprimento do prazo que foi estabelecido para o desenvolvimento preciso que o cliente
como os desenvolvedores cumpram seus papis, infelizmente a falta de feedback[3] entre o cliente e os
desenvolvedores gera falhas nos projetos. O XP se preocupa com esta questo e, por isso, tenta trazer o
cliente para prximo da equipe durante o desenvolvimento, em outras palavras, colocar o cliente no
mesmo ambiente que a equipe de desenvolvimento (Cockburn, 2002, p.179).
Com o cliente presente durante o desenvolvimento, o ciclo continuo de feedback viabilizado e permite
que mudanas sejam feitas ao longo do desenvolvimento e de forma rpida. importante lembrar que
para que o feedback tenha efeito deve haver proximidade fsica (Jeffries & Anderson, 2001, p.18).
A proximidade entre o cliente e os desenvolvedores tambm produz outros pontos positivos, um deles o
aumento de confiana entre a equipe e o cliente, no qual o cliente capaz de perceber os esforos
aplicados pela equipe de desenvolvimento (Teles, 2004).
2.2.3.12 Padronizao de cdigo (Coding Standards)
Para um bom desenvolvimento preciso que a equipe adote um padro a ser seguido. Este padro ajuda
toda a equipe simplificando o desenvolvimento e a comunicao e, atravs da programao em par e da
propriedade coletiva, pode-se assegurar que este padro ser seguido.
Como o cdigo passa por vrias revises durante as etapas de testes fcil detectar a falta de padro e
corrigir antes que a verso do software evolua para o prximo release (Demarco, 2001, p.109).

[1]

Release o nome dado ao lanamento de uma nova verso.

[2]

Bug o nome dado para os defeitos que so achados no sistema.

[3]
Feedback o termo usado para caracterizar as interaes do cliente com a equipe no sentido
de troca de informaes sobre a qualidade e desempenho.

12

Metodologias de Desenvolvimento gil Parte 4:


Scrum
POR
FERNANDO FONTE
20 DE JUNHO DE 2012PUBLICADO EM: EXTREME PROGRAMMING (XP), GESTO DE
PROJETOS, SCRUM

Esta a quarta parte da srie de artigos sobre Metodologias de


Desenvolvimento gil. Estes artigos so baseados noTrabalho de Concluso de Curso apresentado como
exigncia para a obteno do grau de Bacharel em Cincia da Computao da Faculdade Anhanguera de
Campinas Unidade 3, denominado Metodologias de Desenvolvimento gil Aplicadas No
Desenvolvimento De Softwares Em Empresas De Pequeno Porte, escrito por Felipe Morandin, Fernando
Fonte e Tiago Souza.
Espero que voc aproveite a leitura.
2.3 Scrum
2.3.1 Introduo ao conceito
O Scrum foi criado, a princpio, para ser um modelo de gerenciamento de projetos para empresas
automobilsticas (Takeuchi, 1986). Esse modelo deu to certo que anos mais tarde foi documentado e
passou a ser usado tambm no desenvolvimento de software (Beedle, 2001).
Essa metodologia de desenvolvimento gil herdou algumas formas e padres de metodologias como a
Lean[1], o Desenvolvimento Iterativo[2] e as idias de Hirotaka Takeuchi e Ikujiro Nonaka, criadores do
scrum para indstrias automobilsticas.
Como principais caractersticas do Scrum podemos citar os times pequenos, o cliente como parte atuante
do desenvolvimento, as entregas sempre em intervalos de tempo curtos, os planejamentos freqentes e
as discusses dirias para poder levantar o que foi feito, o que ainda vai ser feito e se existe alguma coisa
impedindo essas tarefas de serem executadas (Cohn, 2009).
Atualmente o Scrum muito utilizado em desenvolvimento de software, mas graas a algumas de suas
caractersticas possvel us-lo em quase todo o tipo de projeto que se queira desenvolver.
2.3.2 Caractersticas e Artefatos
Nesse tpico sero apresentadas as principais caractersticas e os artefatos que so gerados dentro de
um processo de desenvolvimento utilizando Scrum. Algumas reunies sero citadas nesse tpico e
explicadas de forma mais detalhada no tpico seguinte.
O Scrum caracterstico por ser uma metodologia que prega entregas em tempo curto sem abrir mo
da qualidade (Cohn, 2009). Diferentemente do XP, no aplica metodologias e sim artefatos que so
usados durante todo o perodo de desenvolvimento por todos os envolvidos no processo. Dentro do

13

Scrum, alm dos artefatos, existem tambm alguns papis razoavelmente bem definidos. Todos esses
artefatos, papis e reunies do Scrum sero apresentados nesse captulo.
Para que um time desenvolva um produto e aplique o Scrum durante o seu desenvolvimento,
primeiramente preciso definir quem ser o Product Owner e o Scrum Master, definir por quantas
pessoas ser composta a equipe e definir a durao de cada Sprint.
Sprint o nome dado para o perodo de tempo em que o time executa suas atividades. Normalmente
cada sprint dura de duas a trs semanas comeando no dia que foi realizada a Planning Meeting indo at
o dia anterior prxima Planning.
Product Owner o cliente, o dono do produto que ser construdo, ele o responsvel por dizer o que
tem que ser feito, assim como a ordem em que isso deve ser feito. tambm o responsvel por
responder a maioria das dvidas que o time tiver.
Definido quem ser o Product Owner, tambm chamado PO, ser a hora de escolher um Scrum Master,
ele ser o responsvel por conduzir todas as reunies relativas ao processo. Fica a cargo dele conduzir
as reunies de planejamento, as reunies de status dirio e as retrospectivas. O Scrum Master tambm
o responsvel por tentar solucionar tudo o que esteja bloqueando o time de alguma forma. Muitas vezes,
caso o Scrum Master no possa efetivamente desbloquear o time, ele entrar em contato com quem
possa.
Como a prpria metodologia prega, os documentos so diferentes e menores do que os utilizados na
metodologia RUP[3], por exemplo. No lugar de vrios requisitos completos e complexos, no Scrum
criado um nico documento com todas as User Stories[4] do sistema chamado Product Backlog.
O Product Backlog o corao do Scrum (Kniberg, 2007). nele que o processo comea a se
desenvolver. Ele contm todas as User Stories, tambm chamadas US, itens do Backlog ou
simplesmente estria, que o cliente deseja descritas de um jeito que todos do projeto tenham uma idia
do que ela se trata s de ler o ttulo.
Esse backlog normalmente escrito pelo PO, porm qualquer outra pessoa pode incluir uma nova
estria. Qualquer outra estria que seja includa no backolg por uma outra pessoa que no seja o PO no
pode ter a importncia definida pois isso feito pelo PO.
Cada US composta por um ID nico, um nome curto e descritivo, a estimativainicial da equipe em
pontos de complexidade, o critrio de aceitao da histria e alguma nota ou observao. Todos estes
itens sero explicados a seguir.
O ID um nmero de identificao nico para cada US. Esse nmero incrementado a cada US
adicionada no Product Backlog e ele utilizado, principalmente, para evitar que se perca o controle sobre
as estrias caso alguma delas tenha o nome alterado.
O nome composto de duas a dez palavras, normalmente, e tem como funo ser uma maneira rpida e
fcil de identificao de uma histria. O nome deve ser suficientemente claro para que quando um
desenvolvedor, ou at mesmo o PO, for consultar o Backlog ele consiga ter uma idia do que se trata e
tambm que, atravs do nome, fique clara a distino entre cada estria.
A Importncia definida pelo PO. Ele deve avaliar o quanto essa estria importante para o projeto, o
quanto ela gerar de valor comercial para o projeto. Normalmente a quantidade de pontos definidas pelo
PO equivalem a prioridade da tarefa, mas isso nem sempre verdade pois o PO pode ter uma estria que
muito importante para o projeto mas no uma prioridade. Essa importncia normalmente
quantificada atravs de nmeros que representam o quanto importante, quanto maior o nmero mais
importante essa estria para o PO.
Os responsveis pelas Estimativas so os desenvolvedores e eles fazem isso durante a Planning
Meeting I. As Estimativas so medidas usando pontos de complexidade que indicam o quo complexo
desenvolver a estria. So escolhidos levando-se em conta os critrios de aceitao e a quantidade de
pessoas no time numa proporo de homens/dia Esse pontos podem ser calculados da seguinte forma:
os desenvolvedores so questionados sobre quantos dias eles levariam para terminar aquela estria e

14

quantas pessoas eles precisariam. Esse valor multiplicado e ento se tem a complexidade; como
exemplo, podemos citar uma estria que levaria trs dias para ficar pronta com uma equipe de quatro
pessoas, sendo assim, ela deveria ter doze pontos de complexidade. Esta no a nica forma de se
pensar nos pontos de complexidade, outra forma bastante comum definir a menor histria que existe no
sprint, a mais simples de ser feita e, a partir dela, ir estimando as outras atravs de comparaes. Todas
essas formas de se pensar e definir os pontos de complexidade ocorrem na Planning Meeting I e esta
ser explicada mais a frente junto com todas as outras reunies do Scrum.
Ainda dentro de uma estria possvel encontrar o Acceptance Criteria ou Critrio de Aceitao que,
nada mais , que os pontos que os desenvolvedores devem cumprir antes de considerar aquela histria
como finalizada. O que deve ser feito, o que ser testado e quais os resultados esperados so coisas que
podem estar no Acceptance Criteria.
Para finalizar uma estria ainda temos, de forma no obrigatria, as Notas que podem conter
esclarecimentos, outras fontes de informao ou qualquer outro tipo de informao que o PO ou at
mesmo o time ache relevante, a Nota sempre colocada de forma breve dentro da estria.
O Product Backlog normalmente uma planilha mantida pelo PO e que fica compartilhada para que todo
o time possa acessar sempre que tiver alguma dvida sobre o que deve ser feito. Manter essa planilha
compartilhada til tambm pois, normalmente, o time faz uma releitura, ao final do sprint, dos pontos de
complexidade que foram estimados e se eles foram corretos ou no.
Segue um exemplo de Product Backlog:

ID

Nome

Imp. Est.

Acceptance Criteria

Notas

Depsito

30

- Realizar o Depsito
Corretamente- Atualizar Saldo
Cliente

- Para realizar o
depsito o usurio
precisa estar logado
no sistema.

Verificar
histrico
transaes

10

- Exibir todo o histrico de


transaes- Exibir maiores
informaes de cada entrada no
histrico
Tabela 1 Product BackLog

Algumas vezes podemos extrair um outro documento de dentro do Product Backlog chamado de
Definition of Done. Esse documento contm alguns critrios de aceitao que so gerais para qualquer
estria. Quando esse documento existe, alm dos critrios de aceitao de cada estria o desenvolvedor
deve observar os itens do Definition of Done antes de falar que a estria est realmente finalizada.
Depois que o Product Backlog montado chega a hora de definir o Sprint Backlog. Esse artefato
definido entre a Planning Meeting I e a Planning Meeting II e tem a funo de manter separado,
normalmente numa outra planilha, as estrias que sero feitas no Sprint que ir comear.
As estrias que sero feitas so definidas usando a Velocity do time. Essa Velocity , basicamente,
quanto o time consegue entregar de pontos de complexidade por Sprint e para ach-la o time vai fazendo
comparaes com os Sprints que j acabaram e vai chegando num valor mdio. Muitas vezes, durante
uma Planning o time pode pegar um pouco mais ou um pouco menos pontos de complexidade do que a
velocidade mdia e, caso o time termine os pontos que pegou e ainda tiver tempo no Sprint ele pode
comear a trabalhar no prximo item de backlog.
Quando um time est comeando normal que as estimativas de velocity no sejam precisas porm
uma tendncia natural do time achar esse valor mdio com o tempo.

15

Uma coisa importante a ser dita que, pelo menos na teoria, s existe um backlog por produto e um PO
por backlog, no deve existir um backlog que seja mantido por mais de um PO e nem mais de um backlog
por projeto.
Podemos considerar como artefatos do Scrum os boards com as tarefas e com os grficos. Depois da
Planning Meeting 2 o time j tem o Sprint Backlog com as estrias divididas em tarefas. Essas tarefas so
colocadas num quadro branco ou em uma parede, esse o primeiro dos boards de um Sprint. Ele
dividido em trs colunas, a primeira contm as estrias e as tarefas de cada estria, na segunda so
colocadas as tarefas que esto sendo feitas naquele dia e na terceira as tarefas que j foram finalizadas.
Algumas equipes fazem uma quarta coluna para colocar os blocks[5].
Esse quadro pode ser montado de diversas formas ficando a cargo da equipe decidir que material ser
usado. Alguns boards so montados usando post-its, os de cor amarela para tarefas, os de cor vermelha
para bugs e blocks. Outras vezes so usados papis de diferentes cores (definido pela equipe) mas
sempre estrias tcnicas, estrias no tcnicas, bug e blocks so apresentados de cores diferentes como
se pode ver na figura 1.

Figura 1 Quadro com as tarefas do sprint

Um outro tipo de board so os grficos ou burndowns. Neles so desenhadas linhas para a quantidade de
tarefas total, quantas faltam e quantas j foram concludas. Em alguns casos esse grfico feito de forma
mais simples s traando uma linha correspondente das tarefas que esto faltando.
Existe um outro board muito parecido com o de tarefas mas, ao invs de mostrar as informaes
referentes as tarefas ele mostra as informaes referentes a complexidade. Nele, da mesma forma que
no de tarefas, temos uma linha que indica a quantidade total de pontos de complexidade que sero
entregues no sprint, uma outra linha indicando quantas j foram terminadas e uma outra indicando
quantas faltam. Assim como no grfico de tarefas , uma outra maneira de se desenhar usando somente
uma linha que corresponde a quantidade de pontos de complexidade que ainda no foram concludos.
Alguns projetos utilizam um terceiro grfico que atualizado somente no final do sprint. Esse grfico
mostra, sprint por sprint, quantos pontos de complexidade o time se comprometeu a entregar e quantos
pontos o time realmente entregou. Esse grfico muito utilizado para poder ter uma idia da
assertividade do time e demonstrador na figura 2.

16

Figura 2 Burndown

Como o Scrum uma metodologia em que se faz pouca documentao, alguns times utilizam uma pgina
onde todos tem acesso para ver e editar com algumas informaes que so relevantes para o projeto
como dicas de como corrigir alguns problemas, preparao de ambiente para o desenvolvimento, contato
do time caso alguma pessoa de outro time precise, informaes sobre backlogs e sprints ou qualquer
outra informao que o time ache pertinente de ser divulgada.
2.3.3 Reunies do Scrum
2.3.3.1 Planning Meeting I e II
As reunies de planejamento so as mais importantes dentro do Scrum pois um nico sprint mal
planejado pode estragar todo o trabalho dentro do projeto. Normalmente dividida em duas partes, as
reunies de planejamento tem um prazo de duas horas cada uma e so feitas, quase sempre, no mesmo
dia e uma logo aps a outra.
Antes de comear as reunies, principalmente a Planning Meeting I, preciso que o backlog j esteja
pronto e priorizado pelo PO pois ele fundamental para a Planning Meeting I.
No comeo dessa reunio normalmente o time apresenta ao PO a disponibilidade de cada membro da
equipe, o PO define a data de entrega do Sprint e o time, juntamente com o PO define o horrio e local
das Stand ups.
Definidos esses itens chega a hora de realmente planejar. O PO apresenta para o time o backlog
priorizado e comea a explicar para o time o que so as estrias e qual o critrio de aceitao de cada
uma. Durante a explicao se o time tiver alguma dvida ele pergunta para o PO que ir tirar essa dvida.
Depois que o time todo entendeu do que se trata uma estria e no tem mais dvidas chega a hora de
estimar. Para isso, normalmente, utilizado o mtodo de Planning Poker em que cada integrante do time
tem um baralho e cada carta deste baralho representa um ponto de complexidade. Cada integrante do
time, ento, mostra, ao mesmo tempo, uma carta com a complexidade que ele acha necessria para
finalizar aquela estria. Havendo diferenas entre os pontos de complexidade apresentados o time
conversa entre si ou at mesmo faz mais perguntas para o PO para tentar acabar com a diferena de
pontos. Depois dessa rodada de perguntas e discusso o time mostra novamente as cartas e, se pela
segunda vez, o time no entrar em um acordo o processo se repete. Para no passar do tempo que
destinado para essa reunio esse processo de planning poker realizado at trs vezes.
Ainda dentro da Planning Meeting I, depois do time ter terminado de estimar as estrias chega a hora de
montar o Sprint Backlog que uma verso reduzida do Product Backlog contendo s as estrias que
sero feitas dentro do Sprint.

17

Finalizada a Planning Meeting I chega a hora do time pegar as estrias que sero desenvolvidas no sprint
e definir quais as tarefas que so necessrias para finalizar a estria, essa a Planning Meeting II.
Na Planning Meeting II o PO no precisa, necessariamente, participar pois essa reunio , na teoria, s
para o time poder quebrar a estrias em tarefas. Em algumas situaes o PO pode ser chamado na
Planning Meeting II caso tenha surgido alguma dvida do time sobre uma estrias especfica que s
apareceu na hora de quebrar as tarefas. Sero essas as tarefas que iro para o board.
Acabada as duas reunies de planejamento o time j pode comear a trabalhar nas tarefas. Em alguns
casos, no mesmo dia da Planning Meeting ao invs de comear a trabalhar o time monta todos os boards.
ideal ainda que, no meio do sprint seja feita uma reunio de 1 hora para estimar alguns outros itens do
backlog fazendo com o time sempre tenha um backlog maior do que o necessrio j estimado o que faz
com que a Planning Meeting I seja mais rpida ou que seja mais detalhada do que o normal.
2.3.3.2 Stand up Meeting
Essa uma reunio que acontece diariamente durante o Sprint num horrio e local definido pelo time e
pelo PO durante a reunio de planejamento. Todo o time participa dessa reunio que, assim como as
outras conduzida pelo Scrum Master.
Durante essa pequena reunio, que tem durao de quinze minutos, o time apresenta o que foi feito
desde a stand up do dia anterior, o que ser feito e se existe alguma coisa bloqueando o time para
terminar a tarefa.
As atualizaes de board so feitas ou durante a stand up ou logo aps a sua finalizao. Durante a stand
up cada integrante do time fala o que fez, o que pretende fazer e se tem algo o bloqueando, ao mesmo
tempo ele vai atualizando o quadro de tarefas movendo para a coluna de tarefas finalizadas o que ele j
fez, para a coluna das que esto sendo feitas o que ele vai fazer e, se tiver um block, ele escreve um
outro papel e coloca na coluna de blocks. Esse block sempre o Scrum Master que deve resolver ou
procurar quem possa resolver.
Logo aps a stand up o time atualiza os grficos e volta a trabalhar nas prximas tarefas at que no dia
seguinte tem outra stand up e o processo se repete.
2.3.3.3 Sprint Review
Essa reunio tambm conhecida como Demo Meeting, tem durao estimada de uma hora e ocorre ou
no ltimo dia do sprint ou no dia seguinte ao final do sprint. Nela todos participam porm s o time e o
Scrum Master falam. O Scrum Master responsvel por conduzir a reunio e o time apresenta o que foi
feito durante o sprint.
Cada integrante do time demonstra o que fez durante o Sprint e, caso uma estria no tenha sido
finalizada, ele explica o que aconteceu. Aps cada demonstrao de estria o PO diz se, de acordo com
os critrios de aceitao, a estria realmente foi finalizada. O PO acompanha o desenvolvimento e o
rendimento do time atravs das Stand up mas durante a Demo que ele realmente v o trabalho
finalizado.
2.3.3.4 Sprint Retrospecitve
A Restrospective uma reunio que quase sempre logo em seguida da Review e pode at ser
confundida como uma nica reunio. Nela o time discute o que foi bom e o que foi ruim ou no to bom
no sprint. A retrospective, assim como a review, tem durao de uma hora.
O PO vai anotando o que foi discutido e todos no time podem propor melhorias. Depois que a reunio
acaba o time analisa o que foi levantado e se prope a melhorar algumas coisas para o prximo sprint.

18

Alguns times realizam, no mesmo dia e em seqncia, a Review, a Retrospective e logo em seguida as
reunies de planejamento. Quando isso acontece o time usa quase o dia inteiro s nas reunies e
montando os boards.

[1]
Lean uma metodologia tambm conhecida como Sistema Toyota de Produo e foi criada
logo aps a Segunda Guerra Mundial procurando aumentar a produtividade da fbrica que estava muito
baixa.
[2]
Desenvolvimento Iterativo uma estratgia de planejamento de retrabalho em que os tempos
utilizados para a reviso e a melhoria do sistema j so pr-definidos.
[3]
RUP uma metodologia de desenvolvimento que tem todos os documentos muito bem
definidos e muito detalhados. Nessa metodologia todo os requisitos so definidos antes do
desenvolvimento j prevendo, assim, todas as possibilidades de erro e todos os possveis fluxos do
sistema.
[4]

User Stories o equivalente ao requisito, so elas que dizem o que o sistema deve ou no ter.

[5]
Block algo que est acontecendo dentro de um sprint que impede que uma determinada
tarefa seja completada.

19