Modelagem ágil com Scrum

A correta identificação dos campos auxilia a não haver dúvidas no desenvolvimento. O quadro apresenta um exemplo de documentação de um Backlog do Produto .

QUADRO - Exemplo de Backlog do Produto.

BACKLOG DO PRODUTO
Produto	Sistema de acompanhamento de atividades
Dono	José Macedo	Atualizado em:	15/05/2012

Identificação	Descrição	Categoria	Tipo	Prioridade	Estimativa	Solicitante
7	Gerente deseja uma listagem de todos ativos e respectivo status.	Consulta	Funcionalidade	500	4	Gerente Adm.
5	Gerente deseja uma listagem com dados estatísticos dos clientes, incluindo valor e permanência	Relatórios	Funcionalidade	450	5	Gerente Adm.
3	Gerente deseja posição financeira consolidada de todas as movimentações	Relatórios	Funcionalidade	450	6	Gerente Fin.
13	Gerente deseja possibilidade de cancelar atividades em andamento.	Alteração	Funcionalidade	500	8	Gerente Adm.
8	Correção de saldo no relatório de despesas	Relatórios	Erro	150	4	Gerente Fin.
5	Gerente deseja uma tela com as atividades em andamento e algum tipo de status (vermelho, amarelo ou verde).	Consulta	Funcionalidade	100	3	Gerente Adm.

Fonte: elaborado pelos autores

Uma documentação um pouco mais completa do backlog do produto pode ser definida por diferentes campos. Uma sugestão dos atributos que podem ser utilizados para gerenciar projetos com Scrum inclui:

• Identificação : Pode ser um número incrementável ou alguma referência à atual fase de atividades. Deve ser uma identificação clara em que não haja dúvidas para os executores.
Backlog do Produto.

Fonte: RIBEIRO (2013). 
 
• Descrição : Um descritivo curto que exponha de forma clara a atividade. Deve conter poucas palavras.
• Importância (Prioridade) : Devemos evitar aqui o termo “prioridade”, amplamente usado, porém dúbio. Dê preferência a uma faixa de referência que seja de fácil compreensão para a equipe. Deve-se deixar sempre uma margem de segurança entre os números para possível incremento durante o processo e não haver dúvidas sobre qual é o mais prioritário.
• Estimativa inicial : Define a previsão para a realização da tarefa. Esta informação deve ser complementada com a quantidade de pessoas da equipe envolvida com a tarefa.
• Observações : Quaisquer outras informações que sejam relevantes à equipe, principalmente as que podem agilizar a atividade.

Dependendo da conveniência, podem-se adicionar outros campos, como:

• Componentes : Informação sobre outras equipes que podem ser envolvidas, identificação do Product Owner, componentes técnicos envolvidos etc.
• Solicitante : Product Owner ou stakeholder que solicitou o item para que se possa dar feedback .
• Outros : Qualquer outra informação pertinente ao planejamento.

Deve haver apenas um único Product Backlog e este deve expressar a real necessidade do Product Owner.

Saiba mais   

O Product Backlog representa uma visão do produto, mostrando a sua relação com o negócio e suas funcionalidades.  Esta agregação de valor ao negócio é o motivo básico de se buscar com o Product Owner todas as “estórias” ou informações adequadas ao desenvolvimento.

Artefatos Scrum: Backlog do Produto, Backlog da Sprint e Incremento

Backlog do Produto (Product Backlog)

De acordo com Schwaber e Sutherland (2016, p. 13),

Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. Lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor .

 

Atributos do Backlog do Produto.

Fonte: elaborado pelos autores.

Caro aluno, representar os requisitos do cliente é mais do que documentá-los, e o Scrum faz isso com muito critério. Assim, o Backlog do Produto é uma relação dos requisitos desejáveis pelo cliente.

Um Backlog do Produto nunca está completo. No início do desenvolvimento nele constam apenas os requisitos que foram inicialmente levantados e melhor entendidos. O Backlog do Produto vai evoluindo na medida em que o produto e o ambiente no qual ele será implantado evoluem. Assim, o Backlog do Produto é dinâmico e vai mudando constantemente para abranger o que o produto precisa para ser mais adequado, competitivo e útil ao cliente. A vida útil do Backlog do Produto acompanha a existência do produto – existe enquanto o produto também existir – sendo um artefato vivo, já que os requisitos, tecnologia e condições do mercado sempre mudam.

O Backlog do Produto passa sempre por um refinamento, que é um processo contínuo de adicionar detalhes, estimativas e ordem aos seus itens. Nesta ação, o Product Owner e o Time de Desenvolvimento colaboram para a definição dos detalhes destes itens.

Em sua disposição, os itens mais relevantes ou valiosos devem ficar na parte superior.

IMPORTANTE

Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento: quanto menor a ordem na lista, menos detalhes.

Os itens do Backlog do Produto que irão ocupar o desenvolvimento na próxima sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do timebox da sprint.

Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro da sprint são considerados como “Preparados” para seleção na reunião de  planejamento da sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparência através das atividades de refinamento.

O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalham fazem a estimativa final.

Fonte: SCHWABER; SUTHERLAND (2016, p. 14)

Reunião de revisão da sprint (Sprint review meeting)

A reunião de revisão da sprinté realizada no final da sprint com o propósito de inspecionar o incremento e fazer adaptações no Backlog do Produto, se necessário. É uma reunião time-boxed de quatro horas de duração para uma sprint de um mês. Para sprint s menores, este evento também deve ser proporcionalmente menor. Novamente o Scrum Master garante que a reunião ocorra, que os participantes entendam o seu objetivo e que ela seja mantida dentro dos limites do tempo.

IMPORTANTE

Na reunião de revisão da sprint:

1. Os participantes incluem o Time Scrum e os stakeholders -chave convidados pelo Product Owner;
2. O Product Owner esclarece quais itens do Backlog do Produto estão “prontos” e quais ainda não estão “prontos”;
3. O Time de Desenvolvimento discute o que foi bem durante a sprint, quais problemas ocorreram e como estes problemas foram resolvidos;
4. O Time de Desenvolvimento apresenta o trabalho que está “pronto” e responde as questões sobre o incremento;
5. O Product Owner informa como o Backlog do Produto está e projeta as prováveis datas de conclusão baseado no progresso até a data (se necessário);
6. O grupo todo colabora sobre o que fazer a seguir, e é assim que a reunião de revisão da sprint fornece valiosas entradas para a reunião de planejamento da próxima sprint;
7. É feita uma análise de como o mercado ou o uso potencial do produto pode ter mudado e o que é o mais importante a se fazer a seguir;
8. É feita uma análise da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada do produto.

Fonte: SCHWABER; SUTHERLAND (2016, p. 12)

O processo Scrum.

Por Ionova Margarita / shutterstock.com.

Reunião de retrospectiva da sprint ( Sprint retrospective meeting )

A reunião de retrospectiva da sprinté realizada depois da reunião de revisão da sprinte antes da reunião de planejamento da próxima sprint. Seu propósito é dar uma oportunidade ao Time Scrum de se autoinspecionar e criar um plano de melhorias para serem aplicadas na próxima sprint.  É uma reunião time-boxed de três horas de duração para uma sprint de um mês. Para sprint s menores, este evento também deve ser proporcionalmente menor. Novamente o Scrum Master garante que a reunião ocorra, que os participantes entendam o seu objetivo e que seja mantida dentro dos limites do tempo. O Scrum Master participa como membro auxiliar do Time.

Na reunião da retrospectiva da sprint:

• é feita uma análise da sprintcom foco no relacionamento entre as pessoas e da eficiência dos processos e ferramentas utilizadas;
• são identificados os itens que tiveram bom desempenho e as potenciais melhorias são listadas;
• é criado um plano com o objetivo de implementar melhorias no modo que o Time Scrum realiza seu trabalho;
• o Time Scrum planeja como a qualidade do produto pode ser melhorada, podendo até adaptar a definição de “pronto”, quando apropriado.

Reunião diária (Daily scrum meeting)

As reuniões diárias são conhecidas como daily scrum, têm duração (time-box) de no máximo 15 minutos e todos devem ficar em pé. Esta reunião é realizada para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas, com o objetivo de inspecionar o trabalho desde a última reunião diária, e prever o trabalho que deverá ser feito antes da próxima reunião diária.

Um alerta: as daily scrum meetings não podem ser confundidas com encontros sociais, momento de descontração ou simplesmente hora do cafezinho. 

 Reunião diária (Daily scrum meeting)

Por Sakaidasan / shutterstock.com

 Nas reuniões diárias devem-se buscar respostas para as perguntas:

• O que foi feito desde a última reunião?
• O que se pretende fazer até a próxima?
• Existe algum impedimento?
• Quanto tempo o time tem gasto com reuniões? É possível reduzi-lo?
• Qual tem sido o ganho real destas reuniões?
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da sprint ?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da sprint?

Reunião diária

Fonte: RIBEIRO (2013)

Uma avaliação honesta das reuniões pode torná-las mais produtivas.

As reuniões devem ter hora de início e término, preferencialmente no mesmo local e horário, e os participantes devem respeitar o tempo que lhes foi concedido. Isto demonstrará respeito aos participantes.

Toda reunião deve ser bem preparada e bem dirigida. O Scrum Master assegura que haja a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box .

IMPORTANTE

Regras de “etiqueta” de Times Scrum

Nunca use a palavra “você” porque a outra pessoa pode se sentir no centro do problema e agir na defensiva;

Nunca se remeta a uma história (“há três meses você disse que...”);

Seja pontual nas reuniões; se atrasar peça desculpas e pague uma “penalidade”;

Se todo mundo está falando ao mesmo tempo, use algum objeto para determinar quem fala. Aquele que está com o objeto fala, os outros escutam;

A opinião de todos é importante e precisa ser entendida e levada em consideração;

Nunca use palavras de baixo calão.

Fonte: TAUB JUNIOR (2009)

Reunião de planejamento da sprint (Sprint planning meeting)

A reunião de planejamento da sprint é uma reunião crítica, provavelmente a mais importante no Scrum e servirá para gerar confiança suficiente ao Product Ownerpara que apoie o time de desenvolvimento e deixe-o livre para atuar dentro do planejamento.

Esta reunião possui um time-box com no máximo oito horas para uma sprint de um mês de duração. Para sprints menores, este evento deve ser proporcionalmente menor. O envolvimento do Scrum Master se faz necessário para que também contribua com o produto final. O Scrum Master ajuda a garantir que a reunião ocorra, que os participantes entendam seu objetivo e ainda ensina o Time Scrum a se manter dentro dos limites do time-box .

De acordo com Schwaber e Sutherland (2016, p. 9), “o número de itens selecionados do Backlog do Produto para a sprint é o único trabalho do Time de Desenvolvimento. Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima sprint”. Os autores indicam que as entradas da reunião de planejamento da sprintincluem:

• o Backlog do Produto;
• o mais recente incremento do produto;
• a capacidade projetada do Time de Desenvolvimento durante a sprint;
• o desempenho passado do Time de Desenvolvimento.

Cada sprint é uma iteração que segue um ciclo (PDCA). Para desenvolver um determinado produto, é possível ter inúmeras sprints. Ao final de cada sprint bem-sucedida a equipe terá produzido um incremento potencialmente integrável, quer dizer, com qualidade, testado, completo e pronto, por isso a reunião de planejamento é tão importante. Nesta reunião a meta da sprint é definida. Há um provérbio popular que diz: “Se você não sabe em qual porto quer chegar, não importa a direção dos ventos”... Então definir uma meta é essencial ao sucesso da sprint.

A meta de uma sprint deve ser SMART :

SMART.

Fonte: elaborado pelos autores

A reunião de planejamento da sprint deve buscar responder as seguintes questões:

• Qual é o objetivo (ou meta) da sprint?
• O que pode ser entregue como resultado do incremento da próxima sprint?
• Como o trabalho necessário para entregar o incremento será realizado?

Reunião de planejamento da sprint.

Fonte: RIBEIRO (2013)

Vamos identificar os envolvidos e o fluxo de atividades na reunião de planejamento da sprint , com base nestas perguntas, de acordo com Schwaber e Sutherland (2016):

• O Time de Desenvolvimento identifica as funcionalidades que serão desenvolvidas durante a sprint. O Product Owner promove um debate sobre o objetivo que a sprintdeve alcançar e os itens de Backlog do Produto que, se completados na sprint, alicerçarão este objetivo ou meta. Todo o Time Scrum colabora para que ocorra o claro entendimento do trabalho da Sprint.
• Após o Time de Desenvolvimento identificar os itens de Backlog do Produto que irá entregar na sprint, o Time Scrum determina a meta da sprint. A meta da sprint orienta o Time de Desenvolvimento em relação aos motivos para a construção do incremento.
• Com o objetivo da sprint e os itens do Backlog do Produto da sprint definidos, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a sprint, acompanhados do plano de entrega destes itens, compõem o Backlog da Sprint ( Sprint Backlog) .
• O Time de Desenvolvimento se auto-organiza para realizar todo o trabalho do Backlog da Sprint. Se o Time de Desenvolvimento acredita que haja excesso ou escassez de trabalho, os itens do Backlog da Sprint podem ser renegociados com o Product Owner.
• No final do planejamento da sprint, o Time de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da sprint e criar o incremento previsto.

Sprint

Sprint é um time-box de duas a quatro semanas, ou seja, limitada a um mês, no qual a equipe ou time do projeto irá produzir uma parte do produto. Recomenda-se que uma sprint deve ser empreendida por um time multidisciplinar com no máximo nove componentes.

A sprint é a unidade básica de desenvolvimento do Scrum. Sprints têm durações coerentes em todo o esforço de desenvolvimento. Uma nova sprint se inicia imediatamente após a conclusão da sprint anterior.

O conceito de sprint envolve uma entrega constante de algo de valor ao cliente, diferente dos modelos tradicionais, em que se desenvolve um produto em um longo período de tempo e, apenas no final, o produto “pronto” é entregue ao cliente. No Scrum sempre é entregue uma “parte” do produto em pequenos intervalos de tempo. À medida que o “pronto” vai ocorrendo com frequência, os critérios de qualidade se tornam mais rigorosos.

Cada sprint deve ter uma meta específica que possa ser realizada naquele time-box específico. Tudo no Scrum deve ser delimitado pelo tempo, e a sprintsempre determinará o tempo visando um produto final comprometido com o negócio.

Os eventos Scrum são time-boxed .

Por Tashatuvango / shutterstock.com.

No contexto do Scrum, o empirismo está relacionado aos sprint s . Por exemplo: o prazo de duas a quatro semanas, na maioria dos casos atribuído para cada sprint, tem demonstrado ser suficiente para a maioria dos projetos. De fato, se o período de tempo aumenta muito, acaba-se por perder a agilidade...

Schwaber e Sutherland (2016, p. 8), elencam as seguintes características de uma Sprint:

• Durante uma sprint não são feitas mudanças que possam por em perigo o seu objetivo, as metas de qualidade não diminuem  e o escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento;
• Cada sprint pode ser considerada um projeto com horizonte não maior que um mês.
• Como os projetos, as sprint s são utilizadas para realizar algo. Cada sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto;
• Sprint s são limitadas a um mês corrido. Quando o horizonte da sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer.
• Sprint s permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprint s também limitam o risco ao custo de um mês corrido.

Curiosidade  

Uma sprint pode ser cancelada?

Uma sprint pode ser cancelada antes do time-boxed da sprint terminar. Somente o Product Owner tem a autoridade para cancelar a sprint, embora ele (ou ela) possa fazer isso sob influência dos stakeholders , do Time de Desenvolvimento ou do Scrum Master.

A sprint poderá ser cancelada se o objetivo da sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem.

Geralmente a sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da sprint, raramente cancelamentos fazem sentido.

Quando a sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado.

O cancelamentos de sprints consome recursos, já que todos tem que se reagrupar em outra reunião de planejamento da sprint para iniciar outra sprint. Cancelamentos de sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.

Fonte: SCHWABER; SUTHERLAND (2016, p. 5)

Eventos Scrum

No Scrum os eventos (ou cerimônias) criam uma rotina que evita a marcação de reuniões informais. Todos os eventos do Scrum são uma ocasião oportuna para se inspecionar e adaptar algum aspecto do produto e são time-boxed , ou seja, possuem uma duração máxima.

Os eventos foram criados para permitir que haja adaptação, dentro de transparência e inspeção criteriosa. A sprint funciona como um container para os eventos. 

 Eventos do Scrum

 

Fonte: quickscrumcrm.azurewebsites.net .

 

O Scrum define quatro eventos formais, contidos dentro dos limites da sprint, quais sejam:

• Reunião de planejamento da sprint ( Sprint Planning Meeting );
• Reunião diária ( Daily Scrum Meeting );
• Reunião de revisão da sprint ( Sprint Review Meeting );
• Reunião de retrospectiva da sprint ( Sprint Retrospective Meeting ).

Dentro das regras do Scrum está implícito que a não inclusão de qualquer um dos eventos pode resultar na redução da transparência e da perda de oportunidade para inspecionar e adaptar o produto em desenvolvimento.

De acordo com Schwaber e Sutherland (2016), uma vez que uma sprint se inicie, sua duração é fixada e não pode ser nem reduzida nem aumentada. Os outros eventos, no entanto, podem terminar sempre que o seu objetivo tenha sido alcançado, sem que haja perdas na qualidade do processo.