Академический Документы
Профессиональный Документы
Культура Документы
O manifesto gil
Diante desse cenrio, um grupo de profissionais veteranos no desenvolvimento de software se
reuniu e, em 2001, criou o Manifesto para o Desenvolvimento gil de Software (frequentemente
chamado apenas de Manifesto gil), que compilava um conjunto de princpios que, de acordo
com a experincia de todos, sempre pareciam ter sido respeitados quando um projeto de
software alcanava o sucesso.
O Scrum
Dentre os profissionais que criaram o manifesto gil, estavam Ken Schwaber e Jeff Sutherland
que desenvolveram o Scrum. So eles tambm quem escrevem e fornecem o Guia do Scrum.
O Scrum trabalha com ciclos curtos de desenvolvimento e entrega de software. Dessa maneira, o
feedback sobre o resultado obtido rapidamente, o que garante a qualidade do produto e a
satisfao do cliente, que passa a fazer parte do processo e a perceber os resultados rapidamente.
Inspeo
Os artefatos e o progresso em direo ao objetivo devem ser inspecionados frequentemente por
todos os usurios do Scrum, de maneira a detectar desvios indesejveis.
Adaptao
As coisas mudam. O Scrum aceita essa verdade e prega a adaptao a mudanas no lugar de
tentar evit-las. Trabalhando com ciclos curtos, as mudanas so melhor aceitas e menos
dolorosas, uma vez que no existem planos extensos que devero ser mudados para adequar-se a
elas.
Papis
Um time Scrum apresenta 3 papis distintos, que sero melhor explicados a seguir: Scrum
Master, Product Owner e Time de Desenvolvimento.
Aqui uma curiosidade: O nome Scrum refere-se a uma jogada do Rugby, na qual os jogadores
dos dois times entram em uma formao para disputar a bola. Caso um dos jogadores caia, o
time inteiro prejudicado, pois a formao perde a sustentao. Esse o conceito principal por
trs do Scrum, a interdependncia entre todos os componentes do time.
Scrum Master
O Scrum Master ou SM o Mestre do time Scrum. No entanto, ele no um gerente ou coisa
que o valha, uma vez que o time Scrum autogerencivel.
Product Owner
O Product Owner ou PO representa o cliente dentro do time Scrum. sabido que um alto grau
de envolvimento do cliente representa mais assertividade nos resultados. No entanto,
normalmente o cliente no pode estar disponvel para o Time de Desenvolvimento toda vez que
seja necessrio tirar uma dvida ou validar um requisito, por exemplo. Por isso esse papel no
Scrum cabe ao Product Owner.
Caso o Product Owner no possua alguma informao necessria, papel dele realizar esse
levantamento junto ao cliente.
Time de Desenvolvimento
O Time de Desenvolvimento composto por todos os responsveis pelo desenvolvimento dos
requisitos (programadores, testers, DBA's, etc.). Dentro do time, independente de seu cargo na
organizao, todos so conhecidos como Desenvolvedor.
O Time de Desenvolvimento auto gerencivel, ou seja, ningum pode dizer ao time o que
fazer, exceto o prprio time.
De acordo com o Guia do Scrum, o Time de Desenvolvimento idealmente deve ter entre 3 e 9
membros.
Artefatos
O Scrum possui alguns artefatos definidos que tm como principal objetivo possibilitar a
sustentao dos trs pilares do Scrum durante o trabalho, fornecendo transparncia e
oportunidades para inspeo e adaptao durante todo o processo.
Product Backlog
uma lista priorizada de todos os requisitos necessrios no produto.
O Product Backlog a origem nica de todos os requisitos para qualquer mudana a ser feita no
produto, e mantido pelo Product Owner.
J os itens menos imediatos tm um nvel de detalhe menor, uma vez que no sero
desenvolvidos imediatamente.
A medida que um item vai subindo no backlog, seu nvel de detalhe aumenta.
O Product Backlog nunca est pronto. Uma vez que o Scrum aceita as mudanas, a cada ciclo de
desenvolvimento, novos requisitos so descobertos, e esses devem ser includos no backlog de
acordo com sua prioridade.
Da mesma maneira, durante o ciclo de vida de um produto pode-se perceber que determinados
itens do backlog deixaram de fazer sentido, no sendo mais necessrios. Esses itens devem ser
removidos do Product Backlog to logo se perceba essa necessidade.
Sprint Backlog
uma lista priorizada de tudo que ser desenvolvido na Sprint atual.
Definio de Pronto
Todos os itens que sero implementados devem possuir uma definio de pronto clara e que faa
sentido para todos os envolvidos.
Somente itens com definio de pronto clara so considerados aptos para terem sua estimativa
realizada e seu desenvolvimento iniciado, uma vez que sem essa informao impossvel para o
Time de Desenvolvimento estimar e realizar o trabalho.
Eventos
O Guia do Scrum descreve alguns eventos, usados para criar uma rotina e diminuir a ocorrncia
de reunies no planejadas.
Todos os eventos do Scrum so oportunidades para inspecionar e adaptar algo. A ocorrncia dos
eventos aumenta a transparncia do processo para todos os envolvidos.
Sprint
Com um time-box que varia entre duas e quatro semanas, a sprint o corao do Scrum.
durante a sprint que o trabalho efetivamente realizado pelo Time de Desenvolvimento e, ao seu
final, espera-se obter um incremento potencialmente utilizvel do produto.
A sprint serve como container para todos os outros eventos (como apresentado na Figura 1).
Toda sprint possui uma meta. A meta definida pelo Product Owner e deve refletir um objetivo
do negcio. Durante a sprint, o Time de Desenvolvimento se guia pela meta, para saber qual
tarefa mais importante de ser concluda. A meta a grande responsvel por manter todos os
membros do time em sintonia, uma vez que guia o trabalho de todos durante a sprint.
Sprints no podem durar mais do que quatro semanas. Isso porque em quatro semanas as coisas
podem mudar e a meta da sprint deixar de fazer sentido.
Scrum aceita muito bem mudanas, no entanto, durante uma sprint certas coisas no podem ser
alteradas:
Caso o aprendizado durante a sprint force alguma alterao no escopo combinado previamente,
isso deve ser negociado entre o Product Owner e o Time de Desenvolvimento.
O Product Owner deve estar disponvel durante a sprint o maior tempo possvel. Um Product
Owner ausente costuma ser um grande problema, uma vez que algumas dvidas relacionadas a
regras de negcio s podem ser esclarecidas por ele.
Reunio de Planejamento da Sprint
Com um time-box que varia entre quatro e oito horas, a reunio de planejamento o evento
onde so definidos e discutidos os itens que faro parte da sprint.
A reunio de planejamento dividida em duas partes, cada uma com metade do time-box da
reunio, dedicada a responder uma das questes.
Com base em seu desempenho passado, o Time de Desenvolvimento projeta sua capacidade
durante a sprint e avalia quais os itens do backlog podem ser completados durante a sprint. Essa
avaliao preliminar nesse momento, e cabe somente ao Time de Desenvolvimento.
Aps a definio dos itens que sero completados na sprint define-se a meta da sprint. A meta
definida pelo Product Owner, no entanto o time colabora para sua elaborao.
Os itens que sero realizados na sprint, junto com seu plano de entrega, compem o Sprint
Backlog.
Feito isso, o Time de Desenvolvimento estima todos os itens do backlog da sprint. Nesse
momento, o Product Owner pode estar presente, para esclarecer alguma dvida que possa surgir
ou mesmo realizar algum ajuste no escopo da sprint, caso o Time de Desenvolvimento julgue
esse ajuste necessrio.
Reunio diria
Com um time-box de quinze minutos, a reunio diria deve ser realizada sempre no mesmo
local e horrio, contando com a presena de todos os membros do Time de Desenvolvimento.
Alguns sustentam que essa reunio seja feita com os participantes em p, de maneira a evitar
que o time-box seja desrespeitado.
Nessa reunio, cada membro do Time de Desenvolvimento deve responder trs questes:
A reunio diria uma reunio chave para inspeo e adaptao, uma vez que, a cada 24 horas,
todos os membros do Time de Desenvolvimento tem oportunidade de se reunir, inspecionar o
andamento do trabalho e adapt-lo a alguma necessidade que tenha surgido.
O Scrum Master deve ficar atento aos impedimentos levantados durante a reunio diria, uma
vez que ser sua responsabilidade remov-los para que o trabalho do time possa ser executado.
Reviso da Sprint
Com um time-box entre duas e quatro horas, a reunio de reviso da sprint realizada ao final
da sprint e tem o propsito de inspecionar o incremento e atualizar o Product Backlog, se
necessrio.
Nessa reunio, o Time de Desenvolvimento e as partes interessadas discutem sobre o que foi
feito na sprint e tambm sobre os prximos itens a serem entregues.
O Time de Desenvolvimento levanta o que foi bem durante a sprint, alm dos problemas
ocorridos e como foram resolvidos. Alm disso, o Time de Desenvolvimento apresenta o que
est pronto e tambm responde questes sobre o incremento.
Retrospectiva da Sprint
Com um time-box entre uma e trs horas, a reunio de retrospectiva da sprint serve para o Time
de Desenvolvimento promover sua melhoria contnua.
Nessa reunio o Scrum Master, como facilitador, deve incentivar o Time de Desenvolvimento a
levantar os seguintes pontos:
Ao final dessa reunio, o time possui uma lista de melhorias a serem realizadas para a prxima
sprint, alm de uma lista do que deu certo e deve ser repetido.
Encerro aqui esse artigo introdutrio sobre Scrum. Espero que ele tenha sido claro o bastante.
Abraos e at prxima.