5 - scrum

SERVIÇO PÚBLICO FEDERAL - MINISTÉRIO DA EDUCAÇÃO INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA TRIÂNGULO

MINEIRO GESTÃO COMERCIAL – SISTEMAS DE INFORMAÇÃO APLICADOS AO COMÉRCIO

PROF. ESP. DÊNIS HENRIQUE DE DEUS LIMA

Métodos ágeis - SCRUM

1 MÉTODOS ÁGEIS

Até o início da década de 1990, acreditava-se que a melhor maneira de obter

sucesso no desenvolvimento de software era com um planejamento completo e detalhado,

elaborado antes do início do projeto. Essa abordagem pesada, baseada em planos e em

documentação maciça, foi aplicada em pequenos e médios projetos, sendo constatado que o

tempo gasto para determinar como o sistema deveria ser desenvolvido era maior do que o

gasto na criação e teste do software. A insatisfação com essa abordagem levou alguns

especialistas a proporem métodos ágeis de desenvolvimento. (SOMMERVILLE, 2011)

Em 2001, Kent Beck e outros renomados autores, consultores e desenvolvedores

da área de software, assinaram o “Manifesto para o Desenvolvimento Ágil de Software”. O

mesmo tem como finalidade sanar as fraquezas reais e perceptíveis da engenharia de software

convencional. (BECK et al., 2001)

As condições de mercado e as ideias das pessoas estão em constante mutação. Em

muitas situações não é possível definir com clareza todos os requisitos antes do início do

projeto. A agilidade veio com a finalidade de fornecer uma resposta rápida e consistente ao

ambiente fluido de negócios.

Fluidez implica diretamente mudanças, e mudanças são relativamente caras,

principalmente se forem sem controle e mal coordenadas. Uma das grandes vantagens

reconhecidas pelo emprego de metodologias ágeis é a redução do custo de mudança ao longo

do processo de desenvolvimento de software. (PRESSMAN, 2011)

De acordo com Pressman (2011, p. 81),

a engenharia de software ágil combina filosofia com um conjunto de

princípios de desenvolvimento. A filosofia defende a satisfação do cliente e

a entrega de incremental prévio; equipes de projetos pequenas e altamente

motivadas; métodos informais; artefatos de engenharia de software mínimos

e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de

desenvolvimento priorizam a entrega mais que a análise e projeto (embora

essas atividades não sejam desencorajadas); também priorizam a

comunicação ativa e contínua entre desenvolvedores e clientes.

Perante os desafios impostos pela moderna realidade e o uso de metodologias

ágeis, em consonância com Pressman (2001), não podemos descartar os importantes




princípios pregados pela engenharia de software, pois os mesmos continuam em constante

processo de evolução e podendo ser empregados com facilidades em ambientes ágeis.

Ainda segundo o autor, o desenvolvimento ágil apresenta benefícios bem

notáveis. No entanto, não é designado a todos os produtos, projetos, situações e pessoas.

2.1 SCRUM

O Scrum é um framework voltado para desenvolvimento ágil de software criado

por Jeff Shuterland e sua equipe em meados da década de 1990. Este nome pertence a uma

atividade que é executada durante uma partida de rugby1 (PRESSMAN, 2011). O método ágil

utiliza uma abordagem iterativa e incremental, com a finalidade de construir um software

gradativamente, possibilitando melhorias, provisões de riscos e medidas de controle. (COHN,

2011)

Os fundamentos do Scrum foram criados condizentes com o manifesto ágil e são

utilizados para guiar o desenvolvimento dentro de um processo que tem como base as

seguintes atividades estruturais: requisitos, análise, projeto, evolução e entrega. Estas

atividades são desenvolvidas dentro de um padrão definido como Sprint, como pode ser visto

na Figura 1. O número de Sprints pode variar de acordo com o tamanho e a complexidade do

produto que venha a ser desenvolvido. (PRESSMAN, 2011)

Figura 1 Ciclo de vida do SCRUM

FONTE: http://blog.concretesolutions.com.br/

1 Um grupo de jogadores faz uma formação em torno da bola e seus companheiros de equipe

trabalham juntos para avançar com a bola sentido ao fundo do campo.




O Scrum provou ser eficaz através de um conjunto de padrões de processo de

software utilizados em projetos com prazos de entregas pequenos, de vários tamanhos e com

requisitos críticos com grande chance de alteração. Cada um desses padrões caracteriza um

conjunto de papéis, cerimônias e artefatos de desenvolvimento que será apresentada nos

próximos parágrafos. (COHN, 2011)

2.1.1 Papéis

O Product Owner, ou dono do produto, é um dos papéis mais desafiadores de um

projeto Scrum. Segundo Cohn (2011), o dono do produto fica exposto a necessidades internas

e externas coexistentes, como a participação em reuniões de planejamento ou a captura de

requisitos junto aos usuários finais. É parte integral da equipe, sendo responsável pela visão

do produto, pelos itens e também pela priorização do backlog no ponto de vista empresarial,

levando em consideração aspectos como valor, risco, prioridade e necessidade. O cliente deve

ser disponível, comunicativo e determinado, deve responder com autoridade e ter uma boa

visão no negócio.

O Scrum Master é o responsável por controlar e auxiliar toda equipe. Ele é

especialista em Scrum, e dentre as suas principais atividades estão à ajuda ao time na criação e

gerenciamento do backlog, treinar membros e remover impedimentos. (PHAM, A.; PHAM,

P., 2012)

A Equipe de Desenvolvimento (Team) é responsável pela construção do produto,

desde os levantamentos de requisitos até a codificação e testes. A Equipe de Desenvolvimento

é definida como auto-organizável e multifuncional.

O Time Scrum (Scrum Team) é constituído pelo Product Owner, pelo Scrum

Master e pela Equipe de Desenvolvimento (Team). Além dos papeis já apresentados, o Scrum

também é baseados em artefatos e cerimonias. (SCHWABER; SUTHERLAND, 2013)

2.1.2 Cerimônias

Os eventos definidos pelo Scrum tem a finalidade de criar uma rotina de trabalho

e minimizar a necessidade de reuniões não previstas pelo mesmo. Todas essas cerimônias são

time-boxed, ou seja, o evento possui uma duração máxima definida. Esses eventos são




planejados a fim de garantir uma transparência e uma inspeção detalhada. A não utilização

destes ocasiona perca de transparência e redução da possibilidade de inspecionar e adaptar.

(SCHWABER; SUTHERLAND, 2013)

2.1.2.1 Sprint

Visto como um dos itens mais importantes do Scrum, o Sprint possui uma duração

de uma a quatro semanas, visando gerar uma versão incremental utilizável do produto. Ao

termino de uma Sprint se inicia uma nova, isso acontece até a finalização do software.


Após a Sprint ser iniciada devemos nos atentar para alguns detalhes, como:

Não devem ser feitas alterações que possam colocar em risco os objetivos da mesma;

As metas de qualidade permanecem inalteradas; e,

O escopo pode ser renegociado entre o Produtc Owner e o Team.

Uma Sprint tem como principal finalidade a execução das features priorizadas

pelo Produtc Owner e revisadas pelo Team. Essas features são as funções do produto a ser

desenvolvido. O conjunto delas é definido como Sprint Backlog que está definido logo à

frente no item 2.1.3. (SCHWABER; SUTHERLAND, 2013) A Sprint é um plano descrito e

flexível que deverá ser seguido orientando o trabalho em prol do resultado do produto.

(PHAM, A.; PHAM, P., 2012)

2.1.2.2 Sprint Planning

A Sprint Planning é a reunião que realiza o planejamento da Sprint. Esse plano é

criado juntamente com todo o Team Scrum. É uma reunião com no máximo oito horas de

duração quando a Sprint tem um tempo estipulado de um mês. Este tempo pode ser reduzido

proporcionalmente à duração da Sprint. (SCHWABER; SUTHERLAND, 2013)

Essa reunião tem como prioridade definir o que pode ser entregue do incremento

até o final da Sprint e como o trabalho será realizado. O Product Backlog, descrito mais a

frente, é onde são armazenadas todas as features do produto. O Product Owner avalia quais

atividades são mais importantes e o Team fica responsável para avaliar se essas podem ou não




ser implementadas durante a Sprint que será iniciada. O Scrum Master possui um papel

importante em todas as reuniões, sendo ele o responsável pelo andamento e a garantia que a

mesma seja realizada na duração prevista e garantindo o foco no assunto proposto. (PHAM,

A.; PHAM, P., 2012)

2.1.2.3 Daily Scrum

A Daily Scrum, conhecida popularmente como reunião diária, possui uma duração

de quinze minutos, devendo ser repedida todos os dias de preferência no mesmo horário e

local. A mesma tem como finalidade inspecionar o que foi feito desde a última reunião e

definir o que pretende ser feito para a próxima. (SCHWABER; SUTHERLAND, 2013)

Durante essa reunião, o Team responde três perguntas, sendo elas:

O que foi feito desde a última reunião;

O que será feito para a próxima reunião; e,

Se houve algum obstáculo ou empecilho que atrapalhou ou que ainda está presente

dificultando a finalização do que foi proposto e qual é.

O Team utiliza essa reunião para verificar se o processo em direção ao objetivo da

Sprint está ocorrendo dentro do planejado, a fim de chegar ao final da mesma com todos os

itens priorizados pelo PO concluídos e entregues.

O Scrum Master ensina o Team a realizar a reunião dentro da duração proposta.

Porém, essa reunião é de responsabilidade do time, sendo assegurado que somente membros

dele, como o Product Owner, o Scrum Master e a equipe de desenvolvimento, devem

participar dessa reunião. (SCHWABER; SUTHERLAND, 2013)

2.1.2.4 Sprint Review

A Sprint Review é uma reunião realizada ao final de cada Sprint. Sua finalidade é

avaliar o incremento e ajustar o Backlog, se necessário. É uma reunião informal, com

finalidade de prover motivação, obter opiniões e promover a colaboração. Também se trata de

uma reunião com tempo definido, sendo ele de quatro horas para uma Sprint de um mês,




podendo ser reduzida proporcionalmente de acordo com o tamanho da Sprint. (SCHWABER;

SUTHERLAND, 2013)

Itens importantes referentes a esta cerimônia:

Participa todo o Team Scrum e mais os interessados no projeto, convidados pelo

Product Owner;

O Product Owner define os itens “prontos” e os “não prontos”;

O Team avalia o que foi bem, os problemas e como foram resolvidos ao longo da

Sprint; e,

Essa reunião funciona como entrada para a próxima Sprint Planning.

O resultado dessa reunião se resume previamente em um Sprint Backlog revisado

e inicialmente pré-definido para a próxima Sprint. (PHAM, A.; PHAM, P., 2012)

2.1.2.5 Sprint Retrospective

A Sprint Retrospective é a chance do time se avaliar, identificar itens a serem

melhorados e traçar metas para a próxima Sprint. Essa reunião deve ocorrer logo após a Sprint

Review e antes da Sprint Planning, com duração fixa de três horas para Sprints de um mês,

também podendo ser reduzida proporcionalmente ao número de semanas definido para a

Sprint. (SCHWABER; SUTHERLAND, 2013)

É uma reunião com foco nas pessoas, com finalidade de verificar processos,

ferramentas e os relacionamentos, relacionar os itens que se destacaram e apontar as

melhorias a fim de melhorar o trabalho de todo o time Scrum. (KNINBERG, 2007)

O Scrum Master encoraja o time a sempre buscar melhorias nos seus processos

internos, em busca de ações que tragam um maior efeito, visando o aumento da qualidade do

produto e melhorando a definição de “pronto”. (PHAM, A.; PHAM, P., 2012)

2.1.3 Artefatos

O Scrum também utiliza artefatos para auxiliar no processo. Esses artefatos são

projetados para aumentar a transparência e garantir que todos tenham o mesmo entendimento




dos itens. Esses artefatos são o Product Backlog, o Sprint Backlog e o gráfico BurnDown.


2.1.3.1 Product Backlog

O Product Backlog é uma lista única onde consta tudo que será necessário para o

produto e é onde estão armazenados todos os requisitos para uma eventual mudança feita no

artefato final. O Product Backlog nunca está completo, os primeiros itens a serem

desenvolvidos representam os requisitos já conhecidos e melhor entendidos. (KNINBERG,

2007)

O Backlog do produto contém tudo que deve ser feito para versões futuras do

mesmo, desde requisitos, novas funções, melhorias e até correções. Os itens do Backlog

possuem os seguintes atributos: descrição, ordem, estimativa e valor. Este artefato também

pode ser refinado, ou seja, podem ocorrer adição de detalhes, estimativas e alteração na ordem

dos itens. Essa análise deve ser expandida a todos os itens do Product Backlog.

A priorização desses itens é de responsabilidade do Product Owner, já o time fica

responsável por todas as estimativas. No entanto, o Product Owner deve auxiliar o time

ajudando no entendimento e em decisões que podem gerar conflitos, porém isso não muda a

responsabilidade do time quanto a real estimativa dos itens. (SCHWABER; SUTHERLAND,

2013)

2.1.3.2 Sprint Backlog

O Sprint Backlog são os itens que foram selecionados do Product Backlog para

serem entregues durante determinada Sprint. O Backlog da Sprint é uma previsão do time de

desenvolvimento, o mesmo acredita que todos os itens priorizados estarão prontos ao final da

mesma, estando presente por completo no incremento.

Sempre que um novo trabalho é necessário, o time adiciona este ao Sprint

Backlog, e se o trabalho é realizado ou completado, a estimativa restante é utilizada. Quando

algum item é considerado desnecessário, este é removido. Somente o time Scrum pode alterar

o Sprint Backlog durante a Sprint. O Backlog da Sprint pertence exclusivamente ao time, se

tratando de uma visão em tempo real do trabalho a ser feito. (SCHWABER; SUTHERLAND,

2013)




Caso o time encontre alguns problemas ou empecilhos que impeçam a entrega do

incremento, os itens restantes do Sprint Backlog devem ser negociados com o Product Owner

a fim de garantir que o ao final da Sprint os itens previstos considerados prontos sejam

entregues. (PHAM, A.; PHAM, P., 2012)

2.1.3.3 Gráfico BurnDown

O gráfico BurnDown é considerado muito importante no processo de

monitoramento do times ágeis. O eixo Y pode ser expresso em horas, dias ou semanas, sendo

o eixo X apresentado em horas de trabalho ou em pontos. A escolha das unidades de medida

devem-se adequar às necessidades das empresas, projetos ou aos objetivos a serem

alcançados. (HAZRATI, 2010)

As empresas utilizam este gráfico para auxiliar no gerenciamento da Sprint, sendo

possível visualizar em tempo real se o que foi proposto realmente vai ser entregue. Este

gráfico também serve como base para a reunião de retrospectiva, mostrando como o time

evoluiu ao longo da Sprint. (KNINBERG, 2007)

Como pode ser visto na Figura 2, temos a linha ideal (Ideal Line) que apresenta

como o gráfico teoricamente deveria seguir. Trabalhar em cima dessa linha é praticamente

impossível, sendo que estamos falando sobre pessoas e processos. O ideal é que se ande o

mais próximo a essa, representada pela linha 3 (Line 3).

Em casos como o apresentado pela linha 1 (Line 1), indica que o time está fora do

prazo e não conseguirá entregar tudo que foi proposto durante a Sprint. Com base nesses

dados deve-se avaliar o que aconteceu. Se possível, renegociar os itens do Sprint Backlog ou

até mesmo abortar a Sprint.

Outro caso comumente encontrado é representado pela linha 2 (Line 2), onde o

time nos primeiros dias encontram dificuldade em entender, integrar e entregar as tarefas.

Porém nos últimos dias o time consegue efetuar as entregas com mais frequência, assim

finalizando o incremento. (HAZRATI, 2010)




Figura 2 GráficoBurnDown

FONTE: http://www.infoq.com

O gráfico deve ser encarado como um avaliador do time ágil, sendo possível

extrair do mesmo uma gama de informações bem abrangentes, dentre elas, a velocidade do

time, se o planejamento foi seguido e se é efetivo e identificar se o objetivo da Sprint vai ser

alcançado. (FERNANDES, 2011)

5 - scrum

Documents