cionalidades de baixa prioridade ou que se tornaram desnecessárias ao longo
do tempo [20]. Abordagens não ágeis geralmente tendem a cair nesse pro-
blema devido ao grande espaço de tempo entre o levantamento dos requisitos
e entrega do produto.
11
1.5. Agregando Mais Valor com Scrum
Casa do Código
1.5
Agregando Mais Valor com Scrum
Figura 1.3: Scrum
Scrum é um dos métodos ágeis mais populares na atualidade e tem foco maior nos
aspectos gerenciais do desenvolvimento de software. Nele, cada iteração é chamada
de sprint. Geralmente cada sprint tem um período de mês que pode variar de poucos
dias a algumas semanas. As pessoas envolvidas no processo de desenvolvimento são
dividas no Scrum em três papéis principais: o Scrum Master, o Product Owner (dono
do produto) e a equipe.
O Product Owner é o maior interessado no software, é aquele que teve (ou que
representa quem teve) a necessidade do produto, e por isso tem a visão do produto.
Define o que deve ser feito, e prioriza as funcionalidades a serem desenvolvidas,
mantendo-as em um artefato chamado de product backlog, que nada mais é do que
uma lista de todas as funcionalidades que devem ser implementadas, ordenadas por
prioridade.
É também responsabilidade do Product Owner passar toda a informação de ne-
gócio que for necessária para que a equipe possa transformar suas ideias em software.
A Equipe é composta por um número que varia de cinco a nove pessoas e é cross-
funcional, isto é, há pessoas dos mais variados perfis, como testadores, desenvolve-12
Casa do Código
Capítulo 1. Introdução à Métodos Ágeis
dores, designers, analistas de negócio etc. integrando a equipe. O principal objetivo dela é implementar as funcionalidades que foram selecionadas para serem desenvolvidas na iteração e entregá-las em funcionamento ao final desse período. No capítulo 6 abordaremos mais a fundo as vantagens de se trabalhar com equipes pequenas.
O Scrum Master, também chamado de facilitador, é responsável por manter o
processo em funcionamento, assegurando que todas as regras estão sendo aplica-
das, e remover os impedimentos da equipe, isto é, resolver qualquer problema que
possa atrapalhar o progresso do desenvolvimento, garantindo assim que o objetivo
da iteração seja atingido.
É importante ressaltar que o Scrum Master não atua como um gerente ou chefe
da equipe porque ela é auto-organizável. O Scrum Master não determina o que
cada
membro da equipe deve ou não fazer: a equipe se compromete com a entrega das
funcionalidades e, então, se auto-organiza, definindo por quem e em qual momento
as tarefas serão realizadas.
Toda sprint começa com uma reunião de planejamento, que é dividida em duas
partes. A primeira delas tem um enfoque mais estratégico, na qual se decide o que
será feito, isto é, quais funcionalidades serão implementadas e define-se uma meta
para a Sprint. Para isso, o Product Owner apresenta os itens do product backlog, e a equipe obtém informações suficientes sobre cada um dos itens, dessa forma, é possí-
vel fornecer uma estimativa que expresse um tamanho ou um número de horas para
o trabalho e assim seja definido quantas e quais tarefas poderão ser desenvolvidas
no sprint (de acordo com a velocidade da equipe que é calculada através de dados de sprints passados).
Depois de definidas quais tarefas serão desenvolvidas no sprint, a equipe utiliza
a segunda parte da reunião, que tem um enfoque mais tático, para decidir como
serão feitas as tarefas. Então se analisa tarefa por tarefa com mais detalhes, mais informações de negócio são apresentadas e é possível tomar diversas decisões de
negócio e decisões técnicas.
Ao fim da reunião de planejamento a equipe começa a trabalhar nas tarefas, res-
peitando as prioridades: fazendo sempre primeiro as tarefas mais importantes, que
representam maior valor para o produto de acordo com o Product Owner. Todos
os dias é realizada uma reunião para que a equipe converse sobre o andamento do
sprint. Posteriormente apresentaremos em mais detalhes as reuniões.
Ao longo da Sprint a equipe mantém sempre em mente a sua meta e quando o
andamento das coisas foge do que foi previsto, ela pode negociar o escopo com o
Product Owner, de forma que não comprometa a meta [59].
13
1.6. Excelência Técnica com XP
Casa do Código
Timeboxes
O Scrum reforça a ideia de que todas as cerimônias do time preci-
sam ter um timebox (tempo definido) e que é muito importante que es-
ses tempos sejam respeitados para se manter um ritmo sustentável. Se
as Sprints, por exemplo, tem duração de duas semanas, é importante que
não sejam estendidas. Se a reunião diária dura 15 minutos, é importante
que a reunião não seja estendida. Os timeboxes das outras reuniões va-
riam de acordo o timebox da Sprint e e podem variar também de acordo
com cada contexto da equipe.
Os tempos sugeridos para um Sprint de 30 dias são [59]:
Reunião Planejamento: 8 horas.
Reunião de Revisão (Demonstração): 4 horas.
Reunião de Retrospectiva: 3 horas.