[Scrum] Artefatos e a gestão visual
Olá pessoas! Tudo bem com vocês? Espero que sim… Continuando nossa série sobre Scrum, hoje falaremos sobre artefatos. Mas o que são artefatos?
Segundo o dicionário: Artefato — substantivo masculino. Do latim, arte factus (factus = “feito”) = “feito com arte”: 1 — produto de trabalho mecânico; objeto; dispositivo; artigo manufaturado. 2 — aparelho, engenho, mecanismo construído para um fim determinado. 3 — conclusão enganosa derivada de ensaio científico ou de medição, e causada por problemas na aparelhagem empregada ou por ineficácia do método eleito. 4 — forma individual de cultura material ou produto deliberado da mão de obra humana (ANTROPOLOGIA/ARQUITETURA). 5 — qualquer alteração na estrutura ou no estado das células, causada por manipulações de laboratório; artifício (CITOLOGIA).
Mas, e no Scrum, o que são artefatos? Bom, segundo o Scrum Guide™, os artefatos do Scrum representam trabalho ou valor que geram transparência e oportunidades para inspeção e adaptação. Os artefatos definidos pelo Scrum foram especificamente designados para maximizar a transparência das informações-chave para que assim, todos os envolvidos tenham o mesmo entendimento daquele artefato.
“Mas Eduardo, quais são estes tais artefatos do Scrum?” Vamos lá então… Segundo o Scrum Guide™, são definidos três artefatos básicos: Product Backlog, Sprint Backlog e o Product Increment, mas é comum utilizarmos mais alguns outros artefatos em conjunto, que mostrarei para vocês também, mais abaixo.
Product Backlog
O Product Backlog (PB) é uma lista ordenada com tudo o que é conhecido e necessário no produto. É a única fonte de requisitos para quaisquer mudanças que eventualmente sejam necessárias no produto. O Product Owner (o PO, lembram dele?) é responsável pelo PB, incluindo seu conteúdo, disponibilidade e ordenação.
O PB lista todos os recursos, funções, requisitos, aprimoramentos e correções que constituem as alterações a serem feitas no produto em versões futuras. Os itens do PB têm os atributos de uma descrição, ordem, estimativa e valor. Os itens do PB geralmente incluem descrições de teste que comprovarão sua integridade quando “Concluído”.
À medida que um produto é usado e ganha valor, e o mercado fornece feedback, o PB se torna uma lista maior e mais exaustiva. Os requisitos nunca param de mudar, portanto, um PB é um artefato vivo. Alterações nos requisitos de negócios, condições de mercado ou tecnologia podem causar alterações no PB.
O refinamento do PB é o ato de adicionar detalhes, estimativas e pedidos aos itens do PB. Esse é um processo contínuo no qual o PO e o Time de Desenvolvimento colaboram nos detalhes dos itens do PB. Durante o refinamento do PB, os itens são revisados e revisados. A equipe Scrum decide como e quando o refinamento é feito. O refinamento geralmente consome não mais que 10% da capacidade do Time de Desenvolvimento. No entanto, os itens do PB podem ser atualizados a qualquer momento pelo PO ou a critério do PO.
Os itens do PB com ordem mais alta geralmente são mais claros e detalhados que os com ordem mais baixa. Estimativas mais precisas são feitas com base na maior clareza e maior detalhe; quanto menor a ordem, menos detalhes. Os itens do PB que ocuparão o Time de Desenvolvimento para a próxima Sprint são refinados para que qualquer item possa ser razoavelmente “Concluído” dentro do prazo da Sprint. Os itens do PB que podem ser “Concluídos” pelo Time de Desenvolvimento em uma Sprint são considerados “Prontos” para seleção em uma Sprint Planning. Os itens do PB geralmente adquirem esse grau de transparência através das atividades de refinamento descritas acima.
O Time de Desenvolvimento é responsável por todas as estimativas. O PO pode influenciar o time, ajudando-o a entender e selecionar compensações, mas as pessoas que executarão o trabalho fazem a estimativa final.
Monitorando o progresso em direção aos objetivos do projeto
A qualquer momento, o trabalho total restante para atingir uma meta pode ser resumido. O PO rastreia esse trabalho total restante pelo menos a cada Sprint Review. O PO compara essa quantia com o trabalho restante nas Sprint Review anteriores para avaliar o progresso na conclusão do trabalho projetado no tempo desejado para a meta. Esta informação é tornada transparente para todas as partes interessadas.
Várias práticas projetivas sobre tendências foram usadas para prever o progresso, como burndowns, burn-ups ou cumulative flows. Estes provaram ser úteis. No entanto, estes não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. Somente o que já aconteceu pode ser usado para tomadas de decisão prospectivas.
Sprint Backlog
O Sprint Backlog (SB) é o conjunto de itens do PB selecionados para a Sprint, além de um plano para entregar o incremento do produto e atingir a meta da Sprint. O SB é uma previsão do Time de Desenvolvimento sobre quais funcionalidades estarão no próximo incremento e qual o trabalho necessário para entregar essas funcionalidades em um incremento “Concluído”.
O SB torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir a meta da Sprint. Para garantir a melhoria contínua, inclui pelo menos uma melhoria de processo de alta prioridade identificada na Sprint Retrospective anterior.
O SB é um plano com detalhes suficientes para que as mudanças em andamento possam ser entendidas na Daily Meeting. O time de desenvolvimento modifica o SB em todo a Sprint, e o SB surge durante a Sprint. Esse surgimento ocorre quando o Time de Desenvolvimento trabalha com o plano e aprende mais sobre o trabalho necessário para atingir a meta da Sprint.
Conforme novo trabalho é necessário, o Time de Desenvolvimento o adiciona ao SB. À medida que o trabalho é executado ou concluído, o trabalho restante estimado é atualizado. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente o time de desenvolvimento pode alterar seu SB durante uma Sprint. O SB é uma imagem altamente visível e em tempo real do trabalho que o Time de Desenvolvimento planeja realizar durante a Sprint, e pertence exclusivamente ao Time de Desenvolvimento.
Monitorando o progresso da Sprint
A qualquer momento da Sprint, o trabalho total restante no SB pode ser resumido. O Time de Desenvolvimento rastreia esse trabalho total restante, pelo menos para cada Daily Scrum, para projetar a probabilidade de atingir a meta da Sprint. Ao rastrear o trabalho restante em todo a Sprint, o Time de Desenvolvimento pode gerenciar seu progresso.
Product Increment
O incremento é a soma de todos os itens do PB concluídos durante uma Sprint e o valor dos incrementos de todas as Sprints anteriores. No final de uma Sprint, o novo incremento deve ser “Concluído”, o que significa que deve estar em condições de uso e atender à definição de “Concluído” da equipe Scrum. Um incremento é um corpo de trabalho inspecionável e realizado que apóia o empirismo no final do Sprint. O incremento é um passo em direção a uma visão ou objetivo. O incremento deve estar em condições utilizáveis, independentemente de o PO decidir liberá-lo ou não.
Kanban para a gestão visual do Sprint Backlog
Para deixar a gestão do SB mais visual e transparente para todos os integrantes da equipe Scrum, é comum se utilizar a técnica Kanban para isso. Maiores detalhes sobre o Kanban falarei em uma nova série mais para a frente, mas basicamente, consiste em dividir um espaço em branco (pode ser em uma parede, um quadro, uma folha A3, um software específico para isso) em algumas colunas, como por exemplo, na imagem abaixo:
Na coluna Sprint Backlog, se coloca em forma de post-its as atividades presentes na lista de itens da Sprint Backlog. Estes post-its deverão ir progredindo conforme os membros do Time de Desenvolvimento forem progredindo nas suas atividades até que estejam “Concluído”. Tornando assim, o andamento da Sprint mais transparente para todos os membros da equipe.
A transparência dos artefatos
O Scrum depende da transparência. As decisões para otimizar o valor e controlar o risco são tomadas com base no estado percebido dos artefatos. Na medida em que a transparência é completa, essas decisões têm uma base sólida. Na medida em que os artefatos sejam incompletamente transparentes, essas decisões podem ser falhas, o valor pode diminuir e o risco pode aumentar.
O Scrum Master (SM) deve trabalhar com o PO, o Time de Desenvolvimento e outras partes envolvidas para entender se os artefatos são completamente transparentes. Existem práticas para lidar com a transparência incompleta; o SM deve ajudar todos a aplicar as práticas mais apropriadas na ausência de total transparência. Um SM pode detectar transparência incompleta, inspecionando os artefatos, detectando padrões, ouvindo atentamente o que está sendo dito e detectando diferenças entre os resultados esperados e os reais.
O trabalho do SM é trabalhar com a equipe Scrum e a organização para aumentar a transparência dos artefatos. Esse trabalho geralmente envolve aprender, convencer e mudar. A transparência não ocorre da noite para o dia, mas é um caminho.
A definição de “Concluído”
Quando um item do PB ou um incremento é descrito como “Concluído”, todos devem entender o que significa “Concluído”. Embora isso possa variar significativamente de acordo com a equipe do Scrum, os membros devem ter um entendimento compartilhado do que significa o trabalho ser concluído, para garantir a transparência. Essa é a definição de “Concluído” para a equipe Scrum e é usada para avaliar quando o trabalho é concluído no incremento do produto.
A mesma definição orienta o Time de Desenvolvimento a saber quantos itens do PB ele pode selecionar durante uma Sprint Planning. O objetivo de cada Sprint é fornecer incrementos de funcionalidades potencialmente liberáveis que aderem à definição atual de “Concluído” da equipe Scrum.
Os times de desenvolvimento oferecem um incremento da funcionalidade do produto a cada Sprint. Esse incremento é utilizável; portanto, o PO pode optar por liberá-lo imediatamente. Se a definição de “Concluído” para um incremento fizer parte das convenções, padrões ou diretrizes da organização de desenvolvimento, todas as equipes de Scrum devem segui-la no mínimo.
Se “Concluído” para um incremento não for uma convenção da organização de desenvolvimento, o Time de Desenvolvimento da equipe Scrum deverá definir uma definição de “Concluído” apropriado para o produto. Se houver várias equipes Scrum trabalhando no lançamento do sistema ou do produto, os times de desenvolvimento de todas as equipes Scrum deverão definir mutuamente a definição de “Concluído”.
Cada incremento é aditivo a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.
À medida que as equipes Scrum amadurecem, espera-se que suas definições de “Concluído” se expandam para incluir critérios mais rigorosos para maior qualidade. Novas definições, conforme usadas, podem descobrir o trabalho a ser feito em incrementos anteriormente “Concluídos”. Qualquer produto ou sistema deve ter uma definição de “Concluído”, que é um padrão para qualquer trabalho realizado.
Bom, chegamos ao final de mais um texto. Sei que ficou um “pouco” grande, mas espero que tenham gostado. Forte abraço e até o próximo texto, aonde falaremos sobre as tão faladas e aguardadas cerimônias do Scrum.
Referência:
Schwaber, K., Sutherland, J. (2017) The Scrum Guide™ — The definitive guide to Scrum: The rules of the game. https://www.scrumguides.org/scrum-guide.html
