O que é Scrum, tudo o que precisa de saber sobre esta metodologia

Muitos dos nossos leitores continuam a perguntar: “O que é a Metodologia Scrum”? Nesta publicação, apresentamos um longo artigo resumindo o que é o Scrum. Este artigo é baseado no Guia Scrum.

O Scrum é definido como uma estrutura na qual as pessoas podem abordar problemas adaptativos complexos, para além de serem produtivos e criativos na entrega de produtos finais de maior valor. O Scrum também incorpora vários elementos, incluindo ser leve e fácil de entender. No entanto, nota-se que é um desafio dominá-lo.

Um olhar mais profundo na metodologia Scrum

Como já foi dito, o Scrum é uma estrutura de processos, e tem sido usado desde o início dos anos 90. O Scrum é usado para a gestão do desenvolvimento de produtos complexos, e vários processos e técnicas garantem que isto acontece. Quando pretende melhorar as suas práticas de gestão e desenvolvimento, o Scrum pode ajudar a esclarecer a relativa eficácia da sua gestão de produtos.

A estrutura é composta por equipas Scrum que realizam uma série de funções, têm diferentes artefactos e eventos e seguem uma série de regras. Cada parte da estrutura tem um objetivo que trabalha para o sucesso do Scrum.

Este artigo explica tudo o que precisa de saber sobre o Scrum, incluindo as regras e relacionamentos envolvidos. Adicionalmente, há táticas discutidas que revelam as diferentes maneiras em que a Estrutura Scrum pode ser usada.

Entender Scrum: Teoria do Scrum

Para entender Scrum, é importante olhar para ele a partir dos seus fundamentos básicos. O Scrum foi fundado na teoria empírica de controlo de processos, também conhecida como empirismo. A sua afirmação é que o conhecimento é composto por tomada de decisão, bem como a experiência de fatores conhecidos.

Assim, o Scrum analisa como otimizar a previsibilidade, bem como controlar o risco usando uma abordagem Iterativa e Incremental. Para que isso ocorra, existem três pilares necessários para a sua implementação. Estes são Transparência, Inspeção e Adaptação.

Transparência

Há partes deste processo que precisam de ser visíveis para aqueles que são responsáveis pelo resultado. Isto requer definições padronizadas de todos os aspetos para garantir que há um entendimento comum de todas as observações. Considere estes exemplos: -

• Todos os participantes que se referem ao processo precisam de usar uma linguagem comum
• Aqueles que realizam o trabalho, bem como aqueles que aceitam o resultado, precisam de ter uma definição padrão de “Done”.

Inspeção

Aqueles que usam o Scrum precisam de inspecionar periodicamente os artefactos do Scrum e progredir quando se dirigem a um Sprint Goal. Isto garante que detetam variações indesejáveis no tempo. As Inspeções devem ser realizadas de vez em quando para não interromper o trabalho que está a ser feito. Inspetores qualificados asseguram que qualquer inspeção é bem-feita e altamente benéfica.

Adaptação

Após uma inspeção, pode ser revelado que um ou mais aspetos dentro do processo se desviaram dos limites aceitáveis. Isto significa que o produto final não será aceitável, e um ajuste deve ser feito no processo ou no material que está a ser usado. Quanto mais cedo isto acontecer, melhor, para reduzir a possibilidade de ainda haver um maior desvio.

Equipa Scrum

A Equipa Scrum básica é composta por três membros, e estes são o Product Owner, a Equipa de Desenvolvimento e o Scrum Master. Espera-se que estas equipas sejam auto-organizadas e interfuncionais. Quando são auto-organizadas, podem escolher a melhor abordagem para realizar o trabalho e não contar com a orientação de pessoas que estão fora da equipa.

Como equipas multifuncionais, têm todas as competências para realizar o trabalho, sem depender de outras pessoas fora da equipa. O objetivo da equipa é otimizar a flexibilidade, criatividade e produtividade.

As Equipas Scrum oferecem produtos de forma iterativa e incremental, aproveitando ao máximo as oportunidades de feedback. Entregas incrementais do produto “Done” garantem que uma versão possivelmente útil do produto de trabalho está sempre disponível. Se está interessado em ter uma ótima equipa, dê uma olhadela nestes dois artigos: “Como Criar uma Grande Equipa Ágil” e “How To Have An Awesome Team KickOff Meeting”.

Product Owner

Quando se trata de maximizar o valor do produto e o trabalho da equipa de desenvolvimento, é o Product Owner, que é responsável. Isto varia com base nas equipas Scrum e nos indivíduos de cada equipa. O Product Owner, tem a responsabilidade exclusiva de gerir o Product Backlog. Esta gestão inclui:

• Expressar claramente os artigos do Product Backlog
• Selecionar User Stories no Product Backlog para alcançar as missões e objetivos
• Otimizar o valor do trabalho que a Equipa de Desenvolvimento executa
• Certificar-se que o Product Backlog está visível, transparente e claro para todos.

Isto revela o que a Equipa Scrum estará a trabalhar em seguida e vai assegurar que a Equipa de Desenvolvimento compreenda completamente os artigos no Product Backlog para o nível requerido. Mesmo que o Product Owner, possa delegar este trabalho à sua equipa de desenvolvimento, estes são responsáveis pelos resultados.

O Product Owner é um indivíduo e não um comité. Se houver um comité em funcionamento, este pode representar os seus desejos no Product Backlog. Aqueles que quiserem fazer ajustes precisam de se dirigir ao Product Owner.

Para garantir que o Product Owner é bem-sucedido, todos na organização precisam de respeitar as suas decisões, que são visíveis no conteúdo e na ordem do Product Backlog. Não há ninguém capaz de dizer à Equipa de Desenvolvimento para trabalhar usando requisitos alternativos, e a Equipa de Desenvolvimento também está limitada em ação às instruções de outra pessoa.

A Equipa de Desenvolvimento

Esta é uma equipa formada por profissionais que trabalham para apresentar um potencial liberável Incremento do produto “Done” no final de cada Sprint. Apenas os membros dessa equipa podem criar o Incremento.

A organização garante que a Equipa de Desenvolvimento tem o poder de organizar e gerir o seu trabalho. A sinergia que ocorre, como resultado, vai otimizar a eficiência e a eficácia da Equipa de Desenvolvimento. Estas equipas têm as seguintes características:

• São auto-organizadas. Não recebem instruções ou conselhos de ninguém em como transformar o Product Backlog em Incrementos de funcionalidade potencialmente releasable.
• São multifuncionais e possuem todas as competências necessárias para criar um Incremento de produto.
• O Scrum não reconhece nenhum título para a Equipa de Desenvolvimento. Todos são developers, não importa o trabalho que estão a realizar. Isto aplica-se sem exceção.
• Dentro da Equipa de Desenvolvimento, o Scrum reconhece que não há subequipas. Isto acontece mesmo quando há vários domínios que precisam de ser tratados, como análise ou teste de negócios. Isto aplica-se sem exceção.
• Cada membro da Equipa de Desenvolvimento pode ter uma competência especial ou área de foco, mas quando se trata de ser responsável, é considerada a equipa como um todo.

A Equipa de Desenvolvimento é composta por várias pessoas, normalmente 7+-2 é o número ótimo. Isto garante que todos permaneçam ágeis, ainda são o número suficiente para concluir todo o trabalho que precisa de ser feito num Sprint.

Se a equipa tiver menos de três membros, a interação pode ser reduzida, o que significa que os resultados irão ter menores ganhos de produtividade. Adicionalmente, as pequenas Equipas de Desenvolvimento podem ter restrições nas suas competências durante a Sprint, o que significa que podem não conseguir apresentar um Incremento potencialmente releasable.

Grandes equipas, como aquelas com mais de nove membros, precisam de muito mais coordenação. Acabam por gerar muita complexidade para que um processo empírico seja gerido. Ao contar a Equipa de Desenvolvimento, o Product Owner e o Scrum Master não são contados, a não ser que também estejam a executar o trabalho do Sprint Backlog.

O Scrum Master

O Scrum Master tem a responsabilidade de garantir que o Scrum foi entendido e aprovado. Estes trabalham com a Equipa Scrum para que possam aderir à teoria, práticas e regras Scrum. O Scrum Master é essencialmente o líder-ajudante da Equipa Scrum. Se está na situação em que é o Scrum Master para duas equipas, dê uma olhadela em: "Your most burning questions about leading 2 teams as Scrum Master".

O Scrum Master ajuda as pessoas que não estão na Equipa Scrum a entender quais das suas interações com a Equipa Scrum são úteis e quais não são.

Entender o Serviço de Scrum Master

Existem três grupos que o Serviço de Scrum Master e estes incluem:

O Serviço de Scrum Master para o Product Owner

Isto é feito de várias maneiras, incluindo:

• Encontrar técnicas para uma gestão eficaz do Product Backlog
• Ajudar a Equipa Scrum a entender a necessidade de stories claras e precisas para o Product Backlog
• Compreender o planeamento de produtos dentro de um ambiente empírico
• Certificar-se de que o Product Owner está ciente da melhor maneira de organizar o Product Backlogpara maximizar valor
• Compreender e praticar agilidade
• Facilitar os eventos Scrum conforme solicitado ou necessário

O Serviço de Scrum Master para a Equipa de Desenvolvimento

Aqui, o Scrum Master vai ajudar a Equipa de Desenvolvimento das seguintes maneiras:

• Treinar a Equipa de Desenvolvimento em auto-organização e funcionalidade cruzada
• Ajudar a Equipa de Desenvolvimento a criar produtos de alto valor
• Eliminar Impedimentos do progresso da Equipa de Desenvolvimento
• Facilitar Eventos Scrum conforme solicitado ou necessário
• Treinar a Equipa de Desenvolvimento em ambientes organizacionais onde o Scrum não foi totalmente adotado ou entendido

O Serviço de Scrum Master para a Organização

O Scrum Master pode servir a organização de várias maneiras, tais como:

• Liderar e treinar a organização na adoção do Scrum
• Planear a implementação do Scrum na organização
• Ajudar os funcionários e partes interessadas a compreender o desenvolvimento do Scrum e o desenvolvimento empírico de produtos
• Causar mudança que leva ao aumento da produtividade da Equipa Scrum
• Trabalhar com outros Scrum Masters para elevar a eficácia da ativação do Scrum dentro da organização

Valores Scrum

Existem vários valores que a Equipa Scrum precisa de incorporar e viver. São coragem, compromisso, abertura, respeito e foco. Estes valores estão na raiz para dar vida aos pilares Scrum e construir confiança com todos os envolvidos.

Os membros da Equipa Scrum aprendem e exploram os valores enquanto trabalham com eventos, papéis e artefactos Scrum. Para o Scrum ter sucesso, os membros da equipa precisam de ser proficientes em viver estes cinco valores.

É assim que fazem isto:

• Têm a coragem de fazer o que é certo e trabalhar nos problemas difíceis
• Comprometem-se a alcançar os objetivos da equipa
• As partes interessadas e a equipa concordam em ser abertas sobre o trabalho e os desafios da realização do trabalho
• Respeitam-se e confiam que são independentes e capazes
• Concentram-se no trabalho Sprint e nos objetivos da equipa

Eventos Scrum: Eventos de Inspeção e Adaptação

Existem eventos formalmente prescritos que são usados no Scrum. Estes, muitas vezes, regulam e minimizam a necessidade de reuniões que não são projetadas no Scrum. Todos estes eventos são em timebox, o que significa que todos têm uma duração máxima.

No momento em que um evento, como o Sprint, começa, tem uma duração fixa que não pode ser alterada. Uma vez que o objetivo do evento tenha sido cumprido, quaisquer outros eventos restantes podem ser encerrados. Isto garante que há pouco tempo perdido durante o processo.

Todos os eventos estão a proporcionar uma oportunidade de inspecionar ou adaptar algo e foram projetados para permitir transparência crítica. Existem quatro eventos formais que o Scrum também prescreve. São:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Entender o Sprint

O núcleo do Scrum é um Sprint. Isto pode ser definido como uma caixa de tempo de um mês ou menos quando um Incremento de produto “Done”, utilizável e potencialmente liberável é criado. Normalmente têm durações consistentes ao longo de um esforço de desenvolvimento. Sprints devem ter durações constantes ao longo de todo o esforço de desenvolvimento. Um novo Sprint só começará quando o Sprint anterior for concluído.

Os Sprints contêm e consistem em Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospetive  e Trabalho de Desenvolvimento.

Enquanto o Sprint estiver em andamento, não deve haver alterações que possam afetar o Sprint Goal, as metas de qualidade não diminuem e o alcance pode ser esclarecido e renegociado entre o Product Owner,e a Equipa de Desenvolvimento, conforme houver mais aprendizagem.

É seguro considerar cada Sprint como um projeto longo do mês que tem de alcançar algo. Por essa razão, o Sprint é claramente definido como o que deve ser construído, design, um plano flexível para orientar a construção, o trabalho e o produto final. Se o horizonte de um Sprint for maior que um mês, então a definição do que está a ser construído pode aumentar, o risco pode aumentar e a complexidade geral.

Os sprints são importantes, pois garantem que o trabalho é previsível e possa ser inspecionado e adaptado ao aproximar-se do Sprint Goal. Limitam o risco, particularmente quando se trata de custo.

É possível cancelar um Sprint antes que a caixa de tempo Sprint chegue ao fim. No entanto, a única pessoa que tem autoridade para fazê-lo é o Product Owner. Esta decisão pode ser influenciada por outras pessoas, incluindo as Partes Interessadas, a Equipa de Desenvolvimento ou o Scrum Master. Um cancelamento pode entrar em vigor com o Sprint Goal a tornar-se obsoleto.

A obsolescência pode ser causada pelo acaso na direção, mercado ou condições tecnológicas. Se o Sprint não fizer mais sentido, deverá ser cancelado. No entanto, vai descobrir que o cancelamento raramente acontece, pois os Sprints têm uma duração curta.

Há etapas que precisam de ser executadas quando o Sprint for cancelado. As stories concluídos e “Feitas” do Product Backlog são revistas primeiro. Caso algum trabalho do Sprint seja acabado, será aceite pelo Product Owner. As stories que estão incompletas no Product Backlog são estimadas e retornadas ao Product Backlog. Como este tipo de trabalho pode depreciar rapidamente, precisa de ser estimado com frequência.

Cancelamentos são desencorajados à medida que consomem recursos. Isto porque todos os envolvidos no Sprint precisam de reagrupar e estar noutro processo de Sprint Planning para iniciar outro diferente. Causam algum trauma à Equipa Scrum e isto é evitado.

Sprint Planning

Qualquer trabalho que deve ser executado no Sprint é planeado no Sprint Planning. O plano reúne todo a Equipa Scrum e é criado pelo trabalho colaborativo. O Sprint Planning é limitado ao tempo máximo de oito horas durante um mês Sprint; aqui pode encontrar uma sugestão sobre como executar um Sprint Planning efetivo.

Quando o Sprint é mais curto, o evento também tende a ser mais curto. Cabe ao Scrum Master garantir que o evento ocorre e os participantes entendem o seu motivo. O Scrum Master irá ensinar a equipa a permanecer dentro da caixa de tempo.

Sprint Planning, responde à pergunta sobre o que pode ser entregue no Incremento do próximo Sprint e como o trabalho necessário para entregar o Incremento será alcançado.

O que pode ser entregue a partir do próximo Sprint?

Durante o período do Sprint, a Equipa de Desenvolvimento irá trabalhar para prever a funcionalidade que será desenvolvida durante o Sprint. O Product Owner, irá discutir o objetivo que o Sprint está a procurar alcançar. Adicionalmente, as stories do Product Backlog ajudarão a atingir o Sprint Goal. A Equipa inteira Scrum trabalhará em conjunto para entender o trabalho Sprint.

Esta reunião tem uma contribuição principal, que é o Product Backlog, o Incremento do produto mais recente, a capacidade projetada da Equipa de Desenvolvimento durante o Sprint e o desempenho anterior da Equipa de Desenvolvimento. A Equipa de Desenvolvimento selecionará quantos artigos para o Sprint virão do Product Backlog.

É a equipa de desenvolvimento que irá fornecer informações sobre o que podem realizar em relação às expetativas Sprint.

Seguindo uma previsão das stories do Product Backlog, a Equipa de Desenvolvimento irá desenvolver o Sprint, enquanto a Equipa Scrum elaborará o Sprint Goal. O Sprint Goal é o objetivo que será atingido no Sprint quando o Sprint Product Backlog tiver sido implementad.

Oferece orientação para a equipa de desenvolvimento sobre porque o Incremento está a ser construído. Se estiver interessado no assunto há algum tempo, Chris escreveu uma publicação no blog: “Quatro Razões Pelas Quais As Histórias De Utilizadores Ágil Não Estão A Ser Feitas”, dê uma olhadela.

Como o trabalho será alcançado?

Depois de o Sprint Goal ser definido e os artigos do Product Backlog que forem selecionados para o Sprint, a Equipa de Desenvolvimento irá decidir como a funcionalidade será incorporada num incremento de produto “Done” durante o Sprint. Os artigos do Product Backlog que são escolhidos para este Sprint, juntamente com o plano para entregá-los, são conhecidos como Sprint Backlog.

A Equipa de Desenvolvimento irá criar um sistema para converter o Product Backlog num Incremento do produto em funcionamento. O trabalho pode variar em relação ao esforço necessário e ao tamanho do trabalho. Durante o Sprint Planning, a Equipa de Desenvolvimento irá prever o que acredita que pode ser alcançado no próximo Sprint.

No final da reunião, o trabalho que foi planeado para os primeiros dias Sprint, que deve ser feito pela Equipa de Desenvolvimento, é decomposto em unidades diárias (ou menos). De seguida, ocorre a auto-organização para realizar o trabalho do Sprint Backlog, tanto durante o Sprint Planning como conforme exigido pela duração do Sprint.

O Product Owner tem a tarefa de ajudar a esclarecer os artigos selecionados do Product Backlog e, de seguida, fazer trocas quando necessário. Se a Equipa de Desenvolvimento decidir que o trabalho é muito ou pouco, poderá ser renegociado com base nos artigos doProduct Backlog.

Isto é feito com o Produto Terminado.

A Equipa de Desenvolvimento também tem a liberdade de convidar outras pessoas a participar por questões de domínio ou assessoria técnica. No final do Sprint Planning a Equipa de Desenvolvimento deve ter a capacidade de explicar ao Product Owner e ao Scrum Master como o trabalho será feito com uma equipa auto-organizada para atingir o Sprint Goal.

Sprint Goal

Este é um objetivo que foi definido para o Sprint, que é facilmente satisfeito uma vez que o Sprint Backlog tenha sido implementado. Oferece algumas orientações para a Equipa de Desenvolvimento sobre o motivo pelo qual o Incremento está a ser construído. É durante o Sprint Planning que o Sprint Goal é criado.

Garante que a Equipa de Desenvolvimento tem um nível de flexibilidade em relação à funcionalidade implementada no Sprint. O Sprint Goal é fornecido através dos artigos do Product Backlog e garante que a Equipa de Desenvolvimento possa trabalhar em conjunto, em vez de trabalhar em iniciativas separadas.

A Equipa de Desenvolvimento trabalha com o  Sprint Goal o tempo todo, afetando a funcionalidade e o uso da tecnologia. Quando há uma mudança nas expetativas, a Equipa de Desenvolvimento e o Product Owner vão facilitar a colaboração para a negociação do que pode ser alcançado durante o Sprint.

Daily Scrum

Todos os dias, a Equipa de Desenvolvimento reserva 15 minutos para sincronizar as suas atividades e desenvolver um plano para as próximas 24 horas. Isto é conhecido como Daily Standup. Envolve uma inspeção do trabalho que foi feito desde a última Daily e, de seguida, vê o trabalho que precisa de ser feito antes do próximo.

É essencial que o horário e o local da Daily Standup permaneçam os mesmos todos os dias, pois reduz qualquer complexidade. Na reunião, a Equipa de Desenvolvimento irá explorar:

• O que foi feito no dia anterior que os ajudou a atingir o Sprint Goal
• O que foi feito hoje para ajudá-los a atingir o Sprint Goal
• Quais impedimentos podem estar a impedir a sua capacidade de atingir o Sprint Goal

Isto significa que a Daily Standup é como um rastreador para a inspeção do progresso do Sprint Goal. Garante que o trabalho está em andamento e baseado no Sprint Backlog, facilitando muito o cumprimento da meta. A Equipa de Desenvolvimento é desafiada durante a Daily Scrum a trabalhar em conjunto como uma equipa auto-organizada através de discussões detalhadas onde podem ter que adaptar ou reproduzir o restante trabalho Sprint.

É o Scrum Master que assegura que esta reunião acontece todos os dias, embora seja conduzida pela Equipa de Desenvolvimento. O Scrum Master garante que a equipa mantém o tempo de 15 minutos e aplica as regras de participação.

Os benefícios da Daily são numerosos, incluindo melhorar a comunicação, reduzir a necessidade de outras reuniões, identificar impedimentos ao desenvolvimento, tomada de decisão rápida e elevar o conhecimento geral da Equipa de Desenvolvimento. Há algum tempo atrás, escrevi outro blog sobre “Como ter uma fantástica e efectiva Daily Standup”, fique à vontade para vê-lo.

Sprint Review

A Sprint Review é realizada após a conclusão do Sprint. Destina-se a inspecionar o Incremento e a adaptar o Product Backlog, se necessário. Quando a Sprint Review está a ocorrer, a Equipa Scrum e as partes interessadas avaliam o que foi feito durante o Sprint.

O resultado da discussão pode levar a alterações no Product Backlog, bem como a uma revisão do que pode ser otimizado para agregar valor. A Sprint Review é para partilhar informações e não é uma reunião de estado. É apenas para obter algum feedback, bem como garantir que há colaboração. Terá lugar durante um período de quatro horas se o Sprint durar um mês. Se for menor, a reunião será também mais curta.

Inclui os seguintes elementos:

• Participação da Equipa Scrum e das partes interessadas convidados pelo Product Owner
• O Product Owner explica os artigos do Product Backlog que estão "Done" e não "Done".
• A Equipa de Desenvolvimento explica o que funcionou durante o Sprint e o que não funcionou, e como os problemas foram resolvidos
• A Equipa de Desenvolvimento revela o que foi “Done” e fornece respostas sobre o Incremento
• O Product Owner discute o estado do Product Backlog e projeta possíveis datas de conclusão
• Todo o grupo colabora nas próximas etapas para que a Sprint Review forneça informações valiosas para o próximo Sprint Planning
• Rever o mercado ou o possível uso do produto, quaisquer alterações e a melhor coisa a fazer de seguida
• Rever o cronograma, o orçamento, os recursos e o mercado para o lançamento do produto

Após a Sprint Review, o Product Backlog é revista com frequência e os artigos prováveis do Product Backlog para o próximo Sprint são definidos. Pode ser ajustado globalmente para satisfazer novas oportunidades.

Sprint Retrospective

Esta é uma oportunidade para a Equipa Scrum realizar uma inspeção do que foi feito e desenvolver um plano para melhorias com o próximo Sprint. Acontece quando a Sprint Review é concluída antes que o Sprint Planning comece novamente.

É uma reunião com caixa de tempo que ocorre durante três horas, para Sprints de um mês. Sprints mais curtos levam a reuniões mais curtas. O Scrum Master vai garantir que ocorre e os participantes estão esclarecidos do seu objetivo.

O Scrum Master participará como um membro da equipa de pares para fornecer informações sobre a responsabilidade do processo Scrum. O objetivo desta reunião é:

• Inspecionar o último Sprint
• Identificar e ordenar os principais artigos que funcionaraam e o que precisa de ser melhorado
• Desenvolver um plano para implementar melhorias para a Equipa Scrum e o modo como funciona

O Scrum Master usará este caminho para encorajar a Equipa Scrum a melhorar dentro da estrutura de processos, processo de desenvolvimento e práticas. Isto vai garantir que o próximo Sprint seja mais eficaz e agradável. Planos são colocados em prática para elevar a qualidade do produto, adotando uma Definition Of Done, conforme apropriado.

Quando a Agile Retrospective estiver completa, a Equipa Scrum terá identificado o que pode ser melhorado para o próximo Sprint. Estes são adaptados e depois inspecionados pela própria Equipa Scrum. A Agile Retrospective é uma oportunidade formal para se concentrar na inspeção e adaptação.

O meu amigo Marc Loeffler escreveu um artigo: “Are you aware of the 5 most asked questions about Agile Retrospectives”. E, claro, se estiver a procurar novas ideias para a sua Agile Retrospective, dê uma olhadela em: “Agile Retrospectives Ideas”.

Artifactos Scrum

Estes representam o trabalho ou o valor para fornecer transparência, bem como oportunidades de inspeção e adaptação. São definidos como sendo especificamente projetados para maximizar a transparência das principais informações, de modo a que todos os envolvidos tenham o mesmo entendimento do artefacto.

Product Backlog

Isto é referido como uma lista ordenada de todas as coisas que são necessárias para o produto. Tem todos os requisitos para quaisquer alterações que precisam de ser feitas num produto; o Product Owner é o responsável.

É um trabalho em andamento e nunca tem uma versão final. Estabelece os requisitos e continua a evoluir à medida que o produto evolui. Muda com base no que torna o produto mais apropriado, útil e competitivo e existirá enquanto houver um produto.

Tem uma lista de todos os recursos, requisitos, funções, aprimoramentos e correções que compõem as alterações a serem feitas num produto lançado no futuro. Os artigos dentro do Product Backlog têm descrição, pedido, estimativa e valor.

Quanto mais o produto é usado e obtém valor, mais feedback pode ser esperado do mercado. Isto vai resultar no crescimento do Product Backlog conforme os requisitos evoluem. Também pode mudar com base nos requisitos de negócios, condições do mercado e tecnologia.

Onde existem várias equipas Scrum, pode ser necessário trabalhar em conjunto num produto. Nesse caso, apenas um Product Backlog será usada para descrever o produto. Para refinar o Product Backlog, podem ser alterados os detalhes, as estimativas e a ordem dos artigos.

Isto é feito com o Product Owner e a Equipa de Desenvolvimento a trabalhar em colaboração. Enquanto está a ser refinado, os artigos deixados também são revistos. É a Equipa Scrum que decidirá como o refinamento será feito para não levar mais de 10% da capacidade da Equipa de Desenvolvimento. O Product Owner tem o poder de atualizar os artigos do Product Backlog a qualquer momento.

Há artigos do Product Backlog ordenados pelo mais alto e pelo mais baixo, com os pedidos mais altos sendo os mais limpos e detalhados. São os mais altos que podem ser razoavelmente “Done” pela Equipa de Desenvolvimento, e são considerados “Prontos” para a seleção no Sprint Planning.

A Equipa de Desenvolvimento é responsável por todas as estimativas, pois são as pessoas que vão realizar o trabalho.

Monitorar o Progresso em Direção a um Objetivo

É possível calcular a quantidade de trabalho necessária para atingir uma meta a qualquer momento. Durante a Sprint Review, o Product Owner vai acompanhar quanto trabalho ainda precisa de ser feito. É feita uma comparação do trabalho que sobrou das Sprint Review anteriores e o progresso necessário para concluir o Sprint atual no tempo definido. Esta informação é então partilhada com todas as partes interessadas envolvidas.

Para prever o progresso, os fluxos cumulativos, burn downs e burn-ups são usados. Onde há um ambiente complexo, o resultado final pode ser desconhecido, assim apenas o que aconteceu no passado será encaminhado para a tomada de decisão prospetiva.

Sprint Backlog

Os artigos do Product Backlog que foram selecionados para o Sprint são conhecidos como Sprint Backlog. Também incluem o plano para entregar o Incremento do Produto e realizar o Sprint Goal. Fundamentalmente, o Sprint Backlog é uma previsão da Equipa de Desenvolvimento que analisa a funcionalidade de cada Incremento, assim como o trabalho necessário para entregar a funcionalidade num Incremento Done.

O Sprint Backlog garante que todo o trabalho da Equipa de Desenvolvimento está visível e possa ser identificado para atingir o Sprint Goal. O Sprint Backlog é essencialmente um plano que tem os detalhes necessários para que as mudanças em andamento sejam compreendidas na Daily Scrum.

A Equipa de Desenvolvimento pode modificar o Sprint Backlog por todo o Sprint e depois emergir durante o Sprint enquanto a Equipa de Desenvolvimento trabalha com o plano. Isto porque se aprende mais sobre o trabalho necessário para atingir o Sprint Goal.

Se houver necessidade de novo trabalho, será adicionado ao Sprint Backlog pela Equipa de Desenvolvimento. Conforme está a ser concluído, o trabalho remanescente estimado é atualizado. Ao longo do caminho, todos os elementos do plano que não são necessários são removidos.

É apenas a Equipa de Desenvolvimento que pode alterar o Sprint Backlog no curso de um Sprint. O Sprint Backlog é como um modelo visível para a Equipa de Desenvolvimento e pertence exclusivamente à Equipa de Desenvolvimento.

Monitorar o Sprint Progress

Durante o Sprint, o Sprint Backlog pode ser resumida a qualquer momento. Cabe à Equipa de Desenvolvimento acompanhar o trabalho total deixado para cada Daily Scrum para projetar a possibilidade de atingir o Sprint Goal. A monitorização possibilita que a Equipa de Desenvolvimento gira o progresso.

Incremento

O trabalho total deixado no Sprint Backlog pode ser resumido no momento. O Incremento é a soma destes, bem como o valor de quaisquer outros Incrementos Sprints anteriores. O incremento final no final do Sprint deve ser “Done”, o que significa que está numa condição utilizável e satisfaz a definição que foi definida pela Equipa Scrum. A condição utilizável é necessária, independentemente de o Product Owner optar por liberá-la.

Transparência de Artefacto

Para o Scrum ser o que é, a transparência é essencial. Esta é a base para decisões que são feitas para otimizar o valor, bem como controlar o risco. A extensão da conclusão da transparência determina se as decisões são ou não sólidas. Se os artefactos não são completamente transparentes, as decisões são falhas e o valor deles cairá. Para além disso, o risco aumentará.

O Scrum Master precisa de trabalhar com todas as partes envolvidas, incluindo o Product Owner e a Equipa de Desenvolvimento, para garantir que os artefactos são completamente transparentes. No caso de haver transparência incompleta, existem práticas para lidar com o problema.

O Scrum Master precisa de ajudar todos a aplicar as práticas mais apropriadas, onde a transparência não está completa. A transparência incompleta pode ser detetada pelo Scrum Master quando os artefactos são inspecionados, os padrões são detetados e todas as informações são cuidadosamente observadas.

A partir disto, diferenças podem ser detetadas entre os resultados reais e os esperados. O Scrum Master precisa de trabalhar com a Equipa Scrum e com a organização para elevar a transparência dos artefactos. Isto é feito aprendendo, convencendo e mudando e requer um caminho para acertar.

Definition of Done

O termo "Done" apareceu várias vezes ao longo deste texto. Quando um artigo da lista de pendentes de produtos ou um incremento for considerado "Done", é essencial que todos os envolvidos compreendam o significado.

Relaciona-se diretamente com o trabalho estar completo e garante que há transparência. Para a Equipa Scrum, “Done” significa que o trabalho realizado está completo no Incremento do produto. Algum tempo atrás, escrevi um exemplo de uma "Definition Of Done Checklist".

É esta definição que vai oferecer orientação à Equipa de Desenvolvimento no número de artigos do Product Backlog que devem ser selecionados durante o processo de Sprint Planning. A razão pela qual cada Sprint existe é entregar Incrementos de funcionalidades potencialmente liberáveis que se encaixam na Definition Of Done da Equipa Scrum.

Com cada Sprint, uma Equipa de Desenvolvimento deve fornecer um incremento da funcionalidade do produto. É utilizável e o Product Owner pode decidir aprová-lo imediatamente. No caso em que a Definition Of Done para um Incremento é uma parte das convenções, padrões ou diretrizes da organização de desenvolvimento, então todas as Equipas Scrum precisam de o seguir.

No caso de a Definition Of Done não ser uma convenção da organização de desenvolvimento, então a Equipa de Desenvolvimento da Equipa Scrum está encarregada de chegar a uma Definition Of Done que esteja alinhada com o produto. Onde há várias equipas Scrum a trabalhar no lançamento do produto, as equipas de desenvolvimento precisam de definir mutuamente o “Done”.

Cada Incremento é aditivo para todos os Incrementos anteriores e é testado minuciosamente. Isto garante que todos trabalhem juntos.

À medida que as Equipas Scrum amadurecem, as suas Definition Of Done também se expandem para incluir critérios mais clarificados, aqui apresento algumas sugestões de como pode começar com esta abordagem. Todos os sistemas e produtos precisam de uma Definition Of Done, que é o padrão aplicado ao trabalho realizado.

Gostou deste artigo?

Quer construir uma empresa ágil? Podemos ajudá-lo com esta tarefa de diferentes maneiras. Pode começar por ver as nossas páginas: Formação Agile e Consultoria Agile.

Um dos nossos serviços mais populares é a Agile Executive Workshop, um workshop de 2,5 dias para ajudar os líderes a identificar quais são os passos exatos que precisam tomar para construir uma empresa ágil.

Se precisar de um Scrum Master externo, veja o nosso programa de Consultoria Scrum Master, um programa de 6 meses para transformar suas equipas.

Se quiser uma Transformação Ágil completa, então nosso Programa de Agilidade Empresarial é a abordagem certa para você, um pacote completo para transformar sua empresa em uma empresa de Produto Digital Ágil, Flexível e Rápido.