Desmistificando o Scrum

Gostaria de tratar aqui de um tema bem conhecido para quem trabalha diariamente com projetos, mas muito discutido em sua real eficiência por algumas empresas.

Sim, falaremos de Scrum.

Mas o que é Scrum? É de comer? De onde ele veio? Que benefícios nos traz?

Pode parecer um pouco estranho, mas compartilhando um pouco de minha vivência, quando entrei para a faculdade ouvia a todo instante nos corredores alguém falando de Scrum.

Era um tema comum nas rodas de conversas, momento perfeito para desenvolver nosso Networking.

Lembro que mais de uma vez fiquei me questionando.

- Que diabos é isso?

Mas como todo calouro com receio, deixei para descobrir na prática mais a frente.

Para que possamos entender em poucas frases o que é Scrum, vou tentar explicar por outro ponto de vista menos formal onde é importante ressaltar o que NÃO é Scrum.

Scrum não é: mesmo que para muitos Scrum seja um processo metódico com objetivo de garantir a entrega de um produto ou serviço ao cliente dentro do prazo e orçamento através de uma série de etapas sequenciais, lamento informar, mas Scrum não é isso.

Scrum é um framework, uma metodologia com foco em gestão e planejamento de projetos de software.

Por mais que seja uma metodologia, o Scrum não é uma bíblia que deva ser seguida à risca. Sua proposta é de customização, adaptação as reais necessidades do projeto personalizando o interior de sua estrutura, adicionando artefatos e recursos de maneira que se tenha um processo funcional.

Um pouco da linguagem utilizada em Scrum.

• Product Backlog

Todas as funcionalidades esperadas pelo cliente, ou seja, os requisitos pré -definidos são armazenados em uma lista chamada de "Product Backlog". Esse é ponto central do Scrum, é baseado nele que o projeto começa.

Para melhor estruturar o Product Backlog nós utilizamos as chamadas "User Stories"que focam nos objetivos do usuário e como o sistema alcançará esses objetivos.

É importante destacar que as “User Stories” não fazem parte do framework Scrum e, assim, seu uso é opcional, porém, elas facilitam e muito o entendimento das necessidades do projeto.

• User Stories

Uma "User Story" contém a descrição detalhada dos requisitos de cada solicitação a ser implementada.

Parte da magia de uma "User Story" está no envolvimento do cliente com o projeto, a compreensão de todos envolvidos de maneira que facilite a memorização do que é esperado ao final de cada Sprint.

Uma "User Story" pode ser escrita em fichas ou cartões, seu objetivo é simplificar o entendimento de um requisito imposto pelo cliente.

O importante de fato é que uma “Story” deve ser curta, simples e clara, possível de ser escritas em um simples e pequeno cartão (conhecidos como “User Index Cards”). Se não há espaço para escrevê-la em um cartão é porquê devemos refiná-la mais, e as dividir em outras User Stories.

Para criar uma "USer Story" devemos levar em consideração 3 fatores fundamentais:

QUEM é o proprietário dela? Normalmente escrita em 1ª pessoa, o proprietário é o usuário daquela funcionalidade, ou seja, o ATOR..

EU QUERO? qual a ação eu procuro executar? Define -se o objetivo dentro do sistema. ou seja, seria a AÇÃO.

POR QUÊ? o que deve aconter após a realização da ação? Define -se o resultado esperado, a FUNCIONALIDADE.

Abaixo segue um modelo de uma “User Story”.

• Sprint

No Scrum os projetos passam por divisões as quais chamamos de "Sprints". Uma Sprint representa uma "Time Box" que contem as atividades que devem ser executadas.

Todas “Spints” devem ter a mesma duração, esse ciclo pode ser de 2, 3, ou 4 semanas. Cada “Sprint” trabalha sobre um conjunto de requisitos pré -estabelecidos .

ATENÇÃO PARA AS ETAPAS ABAIXO :

1.   PLANEJAMENTO: para dar início a uma “Sprint”, é preciso selecionar quais as “User Stories” serão implementadas nessa etapa. É relaizada então uma “Sprint Planning Meeting”, ou seja, uma reunião de planejaento onde o PO é responsável por organizar essas “User Stories” conforme suas prioridades, definindo –se assim o que chamamos em Scrum de “Sprint Backlog”.

Após a definição da “Sprint Backlog”, é realizada pela equipe de desenvolvimento do projeto a subdivisão de cada “Story” de maneira que facilite o controle de cada história individualmente.

As tarefas até então alocadas na “Sprint”, passam do “Product Backlog” para a “Sprint Backlog”.

2.   EXECUÇÃO: nessa etapa é realizada a execução da “Sprint Backlog” conforme ordenada pelo PO.

Com o objetivo de realizar um apontamento e compartilhamento de conhecimento adiquirido, identificar os impedimentos e priorizar o trabalho diário, são realizadas diarimente reuniões de curta duração chamadas de "Daily Scrum".

3.   APÓS A EXECUÇÃO: ao final da execução da “Sprint” é preciso saber se foi alcançado o objetivo. Para isso, uma reunião é agendada onde o projeto é avaliado conforme os objetivos propostos para essa “Sprint”, essa avaliação chama-se “Sprint Review Meeting”.

Por último, são apontados pontos que podem ser melhorados e o que realmente funcionou bem, essa etapa dentro de Scrum chamamos de “Sprint Retrospective”.

Finalizada a “Sprint”, a vida segue. É preciso seguir o ciclo.

CONSIDERAÇÕES FINAIS:

Espero poder ter esclarecido algumas dúvidas básicas para todas as pessoas com dificuldade do entendimento de alguns conceitos de Scrum.

Minha maior preocupação enquanto escrevia esse artigo era com que conseguisse passar uma forma mais simples de entendimento sem que “atropelasse” alguns conceitos importantes sobre Scrum.

Obrigado a todos que dedicaram parte de seu tempo para ler esse artigo.

Evandro Rocha da Cunha