Segundo, ele � um documento bastante enxuto!

Voc�s ver�o que, oficialmente e

obrigatoriamente, ele � composto por tr�s papeis (Product Owner, Scrum Master e
Development Team); por quatro eventos (Sprint Planning, Daily Meeting, Sprint
Review e Sprint Retrospective); por tr�s artefatos (Product Backlog, Sprint Backlog
e
Product Increment); e por um fluxo (chamado Sprint).

O empirismo afirma que o conhecimento vem da experi�ncia e da tomada de

decis�es com base naquilo que � verdadeiro e conhecido. Para tal, ele emprega
uma abordagem iterativa e incremental para aperfei�oar e otimizar a previsibilidade
e controle de riscos, fundamentando-se � para tal � em tr�s pilares fundamentais:
Transpar�ncia, Inspe��o e Adapta��o (� o famoso T I A).

Em suma, a equipe deve ter entre 3 e 9 integrantes (exclu�dos PO e SM, exceto se

eles tamb�m codificarem), de modo que n�o seja pequena demais que haja
restri��es de habilidades nem grande demais que seja complicado de gerenciar.

O ScrumTeam � composto por: Product Owner (PO), Scrum Master (SM) Development
Team (DT).

O trabalho a
ser realizado na Sprint � planejado na Reuni�o de Planejamento da Sprint
(proporcional de 8 horas). Essa reuni�o consiste em duas partes e elas devem
responder adequadamente as perguntas:
1. O que ser� entregue como resultado do incremento da pr�xima Sprint?
2. Como o trabalho necess�rio para entregar o incremento ser� realizado?

Detalhe: algumas vezes as hist�rias de usu�rio s�o muito grandes para serem
desenvolvidas em uma sprint � s�o chamadas de �picos. Elas precisar�o ser
quebradas em partes menores. Mais que isso, em alguns projetos � necess�rio um
n�vel ainda maior que um �pico � chamado de Saga � para features geralmente
mais complexas.

Qual a diferen�a entre Product e Sprint Backlog? O primeiro � uma lista de todos os
requisitos/funcionalidades de usu�rio levantados at� o momento e mantidas pelo
Product Owner, que pode alter�-las a qualquer momento. O segundo � um
subconjunto do primeiro transformado em uma lista de tarefas t�cnicas e mantidas
pela Equipe de Desenvolvimento, que pode alter�-las a qualquer momento.

O Product Owner pode estar presente durante a segunda parte da reuni�o para
clarificar itens do Backlog do Produto. A Reuni�o Di�ria (M�ximo de 15 minutos) �
um evento que busca criar um plano para as pr�ximas 24 horas e inspecionar o
trabalho desde a �ltima Reuni�o Di�ria. Deve ocorrer sempre no mesmo hor�rio e
local (Em p�? N�o � obrigat�rio!), e cada integrante deve responder tr�s perguntas:
1. O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da
Sprint?
2. O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da
Sprint?
3. Eu vejo algum obst�culo que impe�a a mim ou o Time de Desenvolvimento no
atendimento da meta da Sprint?

No final da sprint, ocorre a Revis�o da Sprint (Proporcional a 4 horas). Embora

seja
utilizada para demonstrar as novas funcionalidades durante a sprint, seu principal
motivo � o de inspecionar o que a equipe de desenvolvimento produziu e colher
opini�es e impress�es dos presentes para, caso seja necess�rio, adaptar o plano
para a sprint seguinte. O foco � aprimorar o produto!

A Retrospectiva da Sprint (Proporcional a 3 horas) � uma chance para o Scrum Team

inspecionar a si pr�prio e criar um plano de melhorias para a pr�xima sprint. Ela
inspeciona como foi a �ltima sprint em rela��o �s pessoas, �s rela��es, aos
processos e �s ferramentas. Pode identificar e ordenar os itens que se tornaram
potenciais de melhorias e cria um plano para implementar melhorias no trabalho.

O Product Backlog � uma lista ordenada

(por valor, risco, prioridade, entre outros) de requisitos ou funcionalidades que o
produto deve conter4 criada pelo Time Scrum.

Apesar de o Scrum Team (PO, SM, DT) ser o respons�vel pela cria��o do Product
Backlog, o respons�vel pelo
artefato e o �nico que pode priorizar suas funcionalidades � o Product Owner.

O Sprint Backlog � o conjunto de itens selecionados para serem implementados

durante a sprint mais o plano para transform�-los em um incremento. Assim, ao
final de cada Reuni�o de Planejamento, um novo Sprint Backlog � criado.
Normalmente, o plano � composto por tarefas t�cnicas necess�rias para transformar
o item em um incremento do produto.

Vamos diferenciar Product Backlog e Sprint Backlog! O primeiro � uma lista

ordenada dos requisitos ou funcionalidades que o software dever� possuir.
segundo � uma lista de tarefas a serem executadas durante uma sprint para atingir
a sua meta. Trata-se do desmembramento de cada item selecionado do Product
Backlog em pequenas tarefas.

Product Increment
Ao final de cada sprint, a equipe de desenvolvimento entrega um incremento do
produto, resultado do que foi produzido durante a sprint. Esse � um dos conceitos
principais do framework e vai ao encontro da sua natureza emp�rica, j� que permite
ao Product Owner perceber o valor do investimento e tamb�m vislumbrar outras
possibilidades.

Definition of Done (DoD) ou Defini��o de Pronto

O DoD � um acordo formal que define
claramente quais s�o os passos m�nimos para a conclus�o de um item ou
funcionalidade potencialmente entreg�vel.

Definition of Ready (DoR) � um checklist de crit�rios acordados para que a equipe

de desenvolvimento possa aceitar um requisito.

Definition of Done (DoD) � um checklist

crit�rios acordados para que o Product Owner possa aceitar uma funcionalidade.
Ambos tratam de crit�rios de aceite, mas o primeiro trata do aceite dos requisitos
pela equipe de desenvolvimento e o segundo trata do aceite das funcionalidades
pelo dono do produto. Ficou bem tranquilo de entender agora, eu suponho.

Por fim, � salutar enfatizar que o ciclo de vida do nosso framework � baseado em
tr�s fases principais:
1) Pr�-Planejamento (Pre-game Phase):
Define o sistema sendo desenvolvido. Cria-se o Product Backlog, que cont�m todos
os requisitos atuais e informa��es sobre o planejamento do projeto. Cria-se tamb�m
uma arquitetura de alto n�vel.
2) Desenvolvimento (Game Phase):
O sistema � desenvolvido em sprints, por meio de uma abordagem iterativa. A cada
sprint, novas funcionalidades s�o adicionadas de modo tradicional, i.e., an�lise,
projeto, implementa��o, etc.
3) P�s-Planejamento (Post-game Phase):
Ap�s a fase de desenvolvimento s�o feitas reuni�es para analisar o progresso do
projeto e demonstrar o software atual para os clientes. Aqui s�o feitas as etapas
de
integra��o, testes finais e documenta��o.

O Product
Backlog nunca est� completo, pois os requisitos est�o sempre mudando.

XP
Valores Fundamentais: Feedback, Coragem, Respeito, Comunica��o e
Simplicidade; Princ�pios B�sicos: Feedback R�pido, Abra�ar Mudan�as, Presumir
Simplicidade, Mudan�as Incrementais e Trabalho de Qualidade.

XP
(Extreme Programming) � uma metodologia �gil voltada para equipes pequenas
e m�dias que desenvolvam software baseado em requisitos vagos e se
caracteriza por possibilitar modifica��es r�pidas.

Constituem pr�ticas
recomendadas pelo XP a coloca��o r�pida de uma vers�o simples em produ��o,
a libera��o das novas vers�es em curtos intervalos de tempo, a programa��o
em duplas, a refatora��o (refactor) dos c�digos produzidos, a ado��o de
padr�es para a codifica��o; a integra��o e o teste cont�nuos de c�digos; a
limita��o em 40 horas da carga de trabalho semanal.

O BDD busca melhorar a comunica��o e a intera��o entre os stakeholders (clientes,

programadores, analistas de qualidade, analistas de neg�cio, etc), deixando claro
como o software deve se comportar por meio de cen�rios escritos em linguagem
natural6. Isso minimiza ru�dos de comunica��o, previne falhas e reduz riscos � este
� o grande foco dessa metodologia.

BDD associa os benef�cios de uma documenta��o formal, escrita e mantida pelo

�neg�cio�, com testes de unidade que �demonstram� que essa documenta��o �
efetivamente v�lida.

O Test-Driven Development (TDD7) � um m�todo �gil de desenvolvimento de

software que se baseia na repeti��o de um ciclo de desenvolvimento curto, focado
em testes unit�rios, em que os casos de teste que verificam uma nova funcionalidade
s�o escritos antes mesmo da pr�pria funcionalidade. Escreve-se o teste, encontre
uma falha e refatore-o, ciclicamente � conhecido como Red, Green e Refactor.

O Test Driven Development (TDD) n�o � uma abordagem para realizar testes, � uma
abordagem para desenvolver softwares. Entenderam? Se alguma quest�o disser que
tratase
de uma t�cnica para realiza��o de testes de software, est� errado! � um processo
para
desenvolvimento de software! Ok?