O Scrum nas Empresas

Certamente você já se deparou com situações na produção de algo que o levaram a ter que responder algumas questões, como:

• Quanto tempo vai levar?
• Quanto vai custar?
• Vai realmente valer a pena?
• É o que é realmente preciso? 

Artefatos Scrum nas empresas.

 

Por jera_art / shutterstock.com.

 São questões relevantes que os consultores tentam responder com segurança para os interessados. Com a tamanha falta de sucesso em implantações e muitos traumas já vividos, pode ser difícil convencer um cliente sobre os reais benefícios ao negócio que o desenvolvimento de um software pode trazer.

Existem muitos desafios enfrentados pelas equipes que aplicam o Scrum. Um deles é: “ é este o framework certo a usar?”

É muito difícil responder perguntas como estas, no entanto, existe algo que podemos afirmar com convicção: o framework Scrum vai expor seus problemas . Você pode decidir não usá-lo no desenvolvimento por diversos motivos, mas com os problemas mais críticos identificados, pode-se considerar que ele já cumpriu sua função.

O Scrum não é uma solução mágica para problemas complexos. Não é a “bala de prata”. Longe de ser uma visão pessimista, é uma visão realista, principalmente porque não é possível controlar totalmente fatores externos e internos com a adoção de um método ágil, simplesmente.

Scrum World Market Share.

Fonte: VERSIONONE.com (2016)

Conta certa estória que, em uma cidade, a principal fonte de renda estava ligada à produção de leite. Então o prefeito, querendo fazer algo que chamasse a atenção de todos para esta atividade, decidiu construir uma fonte de leite. Conversou com todos os produtores e, após ter o seu apoio completo e irrestrito, empreendeu-se a obra. Ao terminá-la, convocou a todos os produtores e solicitou que cada um trouxesse alguns litros de leite para a fonte. Na inauguração, com toda a imprensa local e nacional atenta, acionou a fonte e saiu... água. Por quê? Cada produtor achou que se apenas ele colocasse água, misturado com tanto leite, ninguém notaria. Só que todos pensaram desta forma. Então, ao invés de leite, saiu água.

Cada membro de uma equipe Scrum é importante. Todos têm seus deveres a serem cumpridos e, se apenas um decidir não cumpri-lo, isso pode acarretar um grande prejuízo para todo o time. Daí a necessidade de todos darem o devido valor à sua atividade e prazo, não importando o tamanho de sua tarefa.

De acordo com a Version One (2016), responsável pela publicação do State of Agile Report 2016 , o Scrum representa 58% do mercado ágil, conforme indica o gráfico da figura 38. E muitas empresas brasileiras também estão migrando para métodos de gestão ágil, seguindo a tendência mundial.

Saiba mais     

Para quais empresas o Scrum serve?

É claro, como para qualquer método que se implante para a gestão de uma empresa, ele precisa ser adequado para não gerar conflitos e não acabar prejudicando os negócios.O Scrum pode ser implementado em qualquer empresa, mas alguns pontos devem ser observados.

• A empresa deve ter em mente que deverá “quebrar” os seus projetos e produtos em etapas de 1 a 4 semanas;
• A empresa deve ter equipes de trabalho pequenas, de no máximo 7 componentes e de preferência multifuncionais;
• Com a implementação do Scrum, as equipes e a hierarquia se tornam mais horizontais: isso não deve ser um problema;
• A base do Scrum é o empoderamento da equipe para se auto-organizar e gerenciar a entrega de tarefas: este ponto deve ser de concordância do empreendedor ou da liderança da empresa;
• A empresa deve ter ciência que alguns mecanismos de controle podem ser substituídos para se tornar mais ágil.

Fonte: capitalsocial.cnt.br

Ferramentas de Apoio às Práticas Ágeis

Schwaber e Sutherland (2016, p. 14) afirmam que práticas como burndown , burnup e outras práticas de estimativa têm sido usadas para prever o progresso do desenvolvimento Scrum e que elas têm se mostrado úteis. Mas os autores alertam que não substituem a importância do empirismo, pois em projetos complexos, não se pode prever o que acontecerá. Somente o que já ocorreu pode ser usado para uma tomada de decisão a respeito do que virá.

Além das práticas de estimativas, o Time Scrum também pode utilizar outras ferramentas de controle. A seguir, algumas destas ferramentas e métodos de apoio às práticas ágeis são apresentadas. 

Cartões: Os cartões são mecanismos para registrar os requisitos do projeto em andamento. Uma forma manter os membros do time atualizados sobre o andamento do projeto é a criação de um painel para gestão a vista. A figura ilustra um quadro para o estilo “gestão à vista” utilizando cartões para mostrar o work in progress ou trabalho em progresso. 

Work in progress

.

Fonte: elaborado pelos autores. 

 

Kanban: O conceito Kanban foi desenvolvido a partir do conceito simples de aplicação da gestão visual no controle de produção e estoques. Kanban  significa “cartão visual” em japonês e tem como função primordial viabilizar a produção de algo. A figura ilustra um quadro para controle por meio do Kanban.

 

Estrutura Kanban

 

Fonte: diferencialti.com.br .

 

Artigo apresenta o estudo obtido com a experiência da aplicação do método Kanban como melhoria da gestão de projetos de software em uma equipe de manutenção de sistemas, utilizando uma abordagem ágil baseada no Scrum. Clique no link para conhecer o estudo completo:

www.lbd.dcc.ufmg.br 

Gráfico burndown: o burndown chart é uma forma visual e rápida de enxergar o status atual do projeto. Possui uma estrutura simples, em que o eixo X representa os dias da sprinte o eixo Y representa o trabalho restante. A figura ilustra um gráfico burndown .  

Gráfico burndown

 

Fonte: myscrumhalf . 

 

Gráfico burnup : um burnup chart apresenta informações sobre o andamento do projeto como um todo e não apenas da sprint, como mostra o burndown . É uma ferramenta que permite que o time saiba em que ponto está em relação às entregas e onde precisa chegar em relação às demandas. O eixo horizontal do gráfico mostra o fator tempo e o eixo vertical apresenta o montante de trabalho. Assim, as demandas de trabalho podem ser representadas por horas, pontos ou outro tipo de medida de esforço, de acordo com o que é praticado pelo time.

Backlog da Sprint (Sprint Backlog)

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

o Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da sprint. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a sprint.

  O Backlog da Sprint

 

Por Sakaidasan / shutterstock.com.

O Backlog da Sprint fornece um plano com um nível de detalhamento que seja suficiente para que, durante as reuniões diárias, as mudanças no progresso do produto possam ser compreendidas pelo Time Scrum. O Time de Desenvolvimento é responsável pelas alterações no Backlog da Sprint ao longo de toda a sprint, e é desta forma que o Backlog da Sprint vai sendo construído durante a Sprint, refletindo o amadurecimento do Time em relação ao trabalho sendo realizado. Assim, o Backlog da Sprint é uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, dando visibilidade ao trabalho do Time.

Sempre que um novo trabalho se torna necessário, este é adicionado ao Backlog da Sprint pelo Time de Desenvolvimento e, na medida em que o trabalho é realizado, a estimativa do trabalho restante é atualizada ou é removido, quando finalizado.

Artefatos e Time Scrum

Fonte: www.bloomy.com

Incremento

De acordo com Schwaber e Sutherland (2016, p. 15), o incremento

é a soma de todos os itens do Backlog do Produto completados durante a sprinte o valor dos incrementos de todas as sprint s anteriores. Ao final da sprintum novo incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e atender a definição de “Pronto” do Time Scrum. Este deve estar na condição utilizável independente do Product Owner decidir por liberá-lo realmente ou não.

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)