2.5 Jogando o jogo

 

Scrum, como um framework para o desenvolvimento Ágil, foi projetado para otimizar e controlar a criação de produtos valiosos em circunstâncias empresariais, organizacionais, de negócio e de mercado turbulentas.

 

O tabuleiro de jogo do Scrum mostra os elementos essenciais e princípios do Scrum, tudo o que é necessário para jogar o jogo.

O Scrum requer muita disciplina de seus jogadores, enquanto deixa muito espaço para criatividade pessoal e táticas específicas do contexto. As regras do jogo são baseadas no respeito pelos jogadores através de uma distribuição sutil e equilibrada de responsabilidade. Respeitar as regras do jogo, sem pegar atalhos nas regras e papéis, nem causar um curto-circuito nos fundamentos empíricos do jogo, proporciona os melhores prazeres e os maiores benefícios para os jogadores, assim como resultados.

O tabuleiro de jogo Scrum mostra os jogadores, os artefatos, os eventos e os principais princípios do jogo do Scrum. As regras do Scrum unem esses elementos.

 

2.5.1 Jogadores e responsabilidades

 

Métodos Ágeis são movidos por um senso de oportunismo de negócio. A técnica de gerenciamento de time-boxing (limitar o tempo) de todo o trabalho permite que os jogadores respondam rapidamente às novas oportunidades e se adaptem a quaisquer mudanças e evoluções.

Scrum organiza seus jogadores em torno três responsabilidades afins, cada uma complementando as outras, tornando a colaboração a chave para o sucesso:

❖ Product Owner;

❖ Development Team;

❖ Scrum Master.

O Product Owner é um papel de um só jogador, injetando a perspectiva de negócio do produto dentro do processo de entrega. Um Product Owner representa todos os stakeholders, internos e externos, para o Development Team, um papel composto por várias pessoas. Embora um Product Owner possa ter tarefas estratégicas de gerenciamento de produto além do Scrum Team, é importante que o Product Owner se envolva ativamente com os outros jogadores da equipe regularmente e repetidamente.

O Product Owner garante ao Development Team que existe um Product Backlog. O Product Owner gerencia o Product Backlog baseado na visão do produto como uma perspectiva de longo prazo do caminho a seguir. Uma visão do produto captura o porquê o produto existe.

O Product Backlog representa todo o trabalho atualmente imaginado para o produto que está sendo criado e mantido. Este trabalho pode incluir expectativas funcionais e não funcionais, aprimoramentos, correções, reparos, ideias, atualizações e outros requisitos. Se alguém quiser saber qual trabalho é identificado e planejado para o produto, basta consultar o Product Backlog.

O Product Owner expressa as expectativas de negócios e as ideias capturadas no Product Backlog para a equipe e ordena os itens no Product Backlog a fim de otimizar o valor entregue. O Product Owner gerencia o orçamento para otimizar o equilíbrio de valor, esforço e tempo para os stakeholders que ele representada.

O Development Team se auto organiza para executar todas as atividades de desenvolvimento de ponta a ponta necessárias para transformar itens do Product Backlog, expressos e ordenados pelo Product Owner, em versões de produto lançáveis. ‘Desenvolvimento’ aplica-se a todo o trabalho realizado pelo Development Team dentro de uma Sprint. Dependendo do contexto, pode incluir a criação de casos de teste, atividades de teste, programação, documentação, integração, atividades de release, etc. Abrange todo o trabalho necessário para garantir que o Incremento do produto esteja em um estado utilizável até no máximo ao final de uma Sprint, e que tecnicamente pode ser liberado para os usuários e consumidores do produto ou serviço. Esse estado do Incremento é chamado de “Pronto”. As qualidades e critérios que precisam ser atendidos para alcançar esse estado, também direcionando o trabalho de desenvolvimento a ser realizado pelo Development Team, são capturados em uma “Definição de Pronto”.

O Development Team tem um conjunto de ‘Padrões de Desenvolvimento’ para descrever como a implementação está sendo realizada. Isso é necessário para garantir o nível de qualidade necessário para lançar regularmente. E fornece a transparência certa para o modo como o jogo está sendo jogado.

O Development Team define a indicação de custo ou esforço nos itens do Product Backlog. O Development Team seleciona a quantidade de trabalho que supõe que pode realizar em uma Sprint no início da mesma. As indicações de esforço emergentes no Product Backlog podem ser comparadas com alguma experiência comprovada anteriormente para fazer uma projeção do Product Backlog para uma Sprint.

O Scrum Master é um papel de uma única pessoa para facilitar a interação do Product Owner e o Development Team, dentro da organização, durante o jogo. Um Scrum Master ensina, treina e orienta o time e a organização, em entender, respeitar e saber como jogar o jogo do Scrum. O Scrum Master certifica-se de que as regras do jogo são bem compreendidas e que quaisquer elementos que atrapalhem ou bloqueiem a equipe em seu progresso sejam removidos. Tais elementos são chamados Impedimentos no Scrum.

O Scrum Master induz o desejo contínuo de se tornarem jogadores melhores. O Scrum Master implementa o Scrum ajudando os outros a usar melhor o Scrum.

 

2.5.2 Tempo

 

As iterações com time-boxe no jogo do Scrum são chamadas de Sprints. Sprints permitem que o Development Team se concentre em alcançar o próximo nível de jogo, o Objetivo da Sprint, com o mínimo de interrupções externas.

Todo o trabalho no Scrum é organizado em Sprints. O Scrum não tem Sprints estereotipadas já que o objetivo de cada Sprint é entregar um pedaço valioso de produto funcionando, um Incremento (de produto). A duração de uma Sprint nunca é superior a quatro semanas e normalmente dura de uma a quatro semanas.

Como um evento contêiner, a Sprint encapsula os outros eventos do Scrum. Cada evento tem um time-box (duração máxima) e é uma oportunidade para mudar de rumo ou se adaptar às condições de mudança:

❖ Sprint Planning;

❖ Daily Scrum;

❖ Sprint Review;

❖ Sprint Retrospective.

Cada Sprint começa com a Sprint Planning, na qual o Development Team obtém trabalho para a Sprint a partir do Product Backlog atual. A equipe seleciona a quantidade de trabalho que considera viável para a Sprint em relação às expectativas do que é necessário para torná-la lançável. O trabalho selecionado é uma projeção que representa as informações que a equipe tem no momento da seleção. O Development Team pode analisar a quantidade de trabalho que eles realizaram, em média, em Sprints anteriores e compará-la com sua capacidade para a próximo Sprint, para aumentar ligeiramente a precisão da projeção. As opiniões do Product Owner são respeitadas e detalhes adicionais são discutidos com o Product Owner.

O trabalho selecionado, projeção, é desenhado, analisado e elaborado em um plano de trabalho implementável para a Sprint (time-box), o Sprint Backlog. Após o término do time-box da Sprint Planning, ou possivelmente antes, o Development Team começa a trabalhar nesse plano que foi criado de forma colaborativa. A Sprint Planning nunca leva mais de oito horas.

Para gerenciar e acompanhar seu trabalho de desenvolvimento, o Development Team organiza um curto evento diário de 15 minutos, chamado de Daily Scrum. É um evento de planejamento no tempo oportuno. O plano de trabalho do time é otimizado para atingir o objetivo da Sprint com base no progresso real dentro da Sprint. A adaptação é capturada em uma atualização do Sprint Backlog. O progresso real no Sprint Backlog é visualizado, com base na quantidade de trabalho restante. Se o progresso atual impacta a projeção, o Development Team consultará o Product Owner.

À medida que a Sprint avança, um Incremento do produto surge do trabalho colaborativo da equipe. Se o Product Owner, como único representante dos stakeholders, considerar o Incremento útil, então o Incremento poderá ser lançado sem demora. No final da Sprint, o Incremento é inspecionado em uma Sprint Review; para verificar a adequação funcional para lançá-lo ou o uso real, se já lançado.

O Product Owner mantém um alto nível de transparência apresentando as evoluções do Product Backlog durante a Sprint em relação à visão do produto a longo prazo na Sprint Review. Ao analisar o Incremento do produto, todos os jogadores provavelmente descobrirão mudanças e receberão feedback e insights evolutivos da inspeção. Elas são processadas no Product Backlog para implementação futura, e a compreensão de que a data exata da implementação depende da ordenação do Product Owner e do progresso sustentável da equipe. O Sprint Review nunca leva mais de quatro horas.

A Sprint é concluída com uma Sprint Retrospective, na qual o Scrum Team inspeciona e reflete sobre o ‘processo’ completo. O evento abrange todos os aspectos do trabalho, por exemplo, conveniência no lançamento do produto, tecnologia, aspectos sociais, o processo Scrum, práticas de desenvolvimento, colaboração, qualidade do produto, etc. O evento é basicamente sobre estabelecer o que foi bem, onde há espaço para melhoria e quais experimentos podem ser realizados de forma útil para aprender e construir um produto melhor.

Como parte da melhoria contínua, o Scrum Team entra em acordo sobre o que manter, ajustar, experimentar e melhorar para a próxima Sprint. Uma Sprint Retrospective nunca leva mais de três horas.

 

A duração da Sprint é mantida estável ao longo de várias Sprints por razões de cadência. É a pulsação do desenvolvimento e é útil para a equipe entender quanto trabalho pode ser feito durante uma Sprint.

A quantidade de trabalho que pode ser feita em uma Sprint é, às vezes, chamada de Velocidade. A velocidade é uma indicação da quantidade de trabalho que uma equipe conseguiu criar em Sprints anteriores. A velocidade é a soma das unidades de esforço ou custo que foram concluídas em uma Sprint e é típica de uma equipe e da composição da mesma.

A duração da Sprint é adequada para aproveitar oportunidades de negócios emergentes e não previstas anteriormente. A Sprint Review colaborativa fornece ao Product Owner as melhores informações possíveis sobre como as Sprints adicionais podem melhorar ainda mais o valor do produto, levando em consideração um equilíbrio entre risco, esforço, orçamento e coesão.

A duração da Sprint também pode depender de quanto tempo uma equipe pode trabalhar sem consultar os stakeholders na Sprint Review. A Sprint Review é uma oportunidade para se adaptar a novas direções estratégicas ou de mercado.

Uma equipe sofrerá com oportunidades reduzidas de aprendizado e adaptação quando não estiver consultando os stakeholders e conhecendo mercados, evoluções de negócios e novas estratégias pelo menos a cada quatro semanas. Sprints podem ser mais curtas do que quatro semanas, mas nunca mais longas.

 

2.5.3 Acompanhamento do progresso

 

O progresso geral do trabalho é rastreado e visualizado, a fim de conhecer as tendências do progresso para fins de previsões, olhando para o futuro incerto com base no passado comprovado e observável.

A fim de medir continuamente e adaptar à realidade e alcançar as melhores previsões possíveis, sempre levando em conta a complexidade, o trabalho restante é reestimado honestamente e regularmente:

❖ Progresso da Sprint: Dentro de uma Sprint, o progresso é rastreado

diariamente. O Sprint Backlog sempre mantém o plano mais preciso e

realista do restante do trabalho para implementar o objetivo da Sprint. ❖ Progresso do produto: A indicação de progresso em nível de Product

Backlog é atualizada e revisada no mínimo na Sprint Review. O Product

Owner talvez empacote itens do Product Backlog e incrementos em

versões candidatas. O progresso comprovado das últimas Sprints fornece

ao Product Owner e aos seus stakeholders uma data de entrega prevista

para releases, funcionalidades individuais ou conjuntos de recursos.

A abordagem clássica do Scrum para visualizar o progresso é um gráfico de Burn-down, um gráfico mostrando a evolução do trabalho remanescente total:

No entanto, a equipe decide a melhor maneira de representar o progresso. Este pode ser um gráfico de burn-down, um quadro físico de Scrum, um gráfico de burn-up (por exemplo, em valor), ou pode ser um diagrama de fluxo cumulativo para visualizar melhor o fluxo de trabalho:

2.5.4 O valor do Product Backlog

 

O valor do Product Backlog não está na integralidade, precisão, detalhe ou perfeição, nem na captura de todos os requisitos possíveis em todos os detalhes possíveis e em todos os possíveis horizontes de tempo. O valor do Product Backlog está na transparência, em deixar claro que trabalho precisa ser feito para criar um produto minimamente viável e valioso (ou Incremento do produto). O Product Backlog traz à tona todo o trabalho, desenvolvimento, conformidade e restrições com as quais uma equipe precisa lidar para criar versões de produto que podem ser liberadas.

O Product Backlog é uma lista ordenada de ideias, funcionalidades e opções para dar vida a um produto imaginado, para entregá-lo e subsequentemente sustentá-lo e expandi-lo. A lista é obrigada a incluir todas as funcionalidades e recursos, mas naturalmente também inclui correções, trabalho de manutenção, trabalho de arquitetura, trabalho a ser gasto em segurança, escalabilidade, estabilidade e desempenho, etc. No momento da criação de um item no Product Backlog, o item é supostamente valioso para um cliente ou contribui para a capacidade de agregar valor.

Cada item no Product Backlog contém apenas detalhes suficientes para deixar claro qual valor que ele representa. Um item é intencionalmente incompleto para incentivar discussões adicionais e explícitas sobre ele. Cada item do Product Backlog serve como um espaço reservado para discussão no momento apropriado.

O Product Owner tem responsabilidade sobre o Product Backlog. Um Product Owner, no entanto, ainda levará em conta a contribuição técnica e de desenvolvimento do Development Team. Um Product Owner ainda levará em conta dependências, requisitos não funcionais e expectativas organizacionais.

O Product Backlog é gradualmente refinado, introduzindo assim o gerenciamento incremental dos requisitos do produto:

 

Conforme o desenvolvimento avança, o Product Backlog é refinado, ajustado e atualizado. O Product Backlog é continuamente ordenado e reordenado pelo Product Owner. Os itens são regularmente refinados em conjunto com o Development Team. O Product Backlog é um artefato vivo. O Product Owner procura equilibrar as necessidades de todos os stakeholders, internos e externos, que devem ser representadas para o Scrum Team. Continuamente adere às descrições e design do trabalho apenas ‘suficientes’, ou seja, deixando de fora detalhes desnecessários, garantindo que nenhum tempo e dinheiro excessivos serão desperdiçados se o item não for criado ou for implementado bem mais tarde ou de maneira diferente.

O nível de descrição e detalhe de um item do Product Backlog está em algum lugar entre o que é desejo e o que costumava ser um requisito. Um “desejo” é muito confuso para se trabalhar e um “requisito” (tradicional) é super especificado e super detalhado. A especificação excessiva no desenvolvimento impede o uso ideal da tecnologia, bloqueia a capacidade de capitalizar sinergias entre diferentes funções e é um desperdício de dinheiro em situações de turbulência ou mudança mínimas. Portanto, o termo ‘desequisito’ é adequado para descrever a granularidade de um item do Product Backlog.

‘Desequisitos’ são transferidos do Product Backlog via Sprint Backlog para Incrementos de produto funcionando. Embora a ordem do Product Backlog dependa de uma combinação complexa de fatores como custo/esforço, dependências, prioridade, coesão e consistência, é essencial também ter uma visão do valor assumido de um item do Product Backlog.

Os fatores centrais para um item do Product Backlog são custo e valor:

❖ Custo: O custo ou o esforço de um item do Product Backlog geralmente é

expresso em uma unidade relativa. Sprints passadas mostram à equipe

quanto trabalho, expresso na unidade escolhida, pode ser convertido, em

média, em um Incremento durante uma Sprint. Com base nesse dado

empírico, uma expectativa pode ser criada quando um item do Product

Backlog atual pode se tornar disponível como parte de um produto em

evolução. É uma projeção, sem mover os jogadores para o campo das

previsões exatas, entendendo que qualquer expectativa desse tipo é

limitada pelo conhecimento e pelas circunstâncias atuais. ❖ Valor: Um princípio importante do Ágil é “satisfazer o cliente por meio

da entrega adiantada e contínua de software de valor”. [Beck, et. Al,

2001] Sem um atributo para o valor (de negócio) nos itens do Product A definição de Pronto é essencial para entender e planejar o trabalho necessário para criar um Incremento liberável durante a Sprint Planning e para a inspeção desse Incremento durante a Sprint Review. A definição de Pronto serve à transparência exigida no Scrum em termos do trabalho a ser feito e do trabalho realmente realizado.

Backlog, um Product Owner não faz ideia de quanto valor uma

funcionalidade, uma ideia ou um conjunto de funcionalidades leva

presumivelmente ao cliente que ele representa dentro do Scrum Team. O

valor dependerá do tipo de empresa, do tipo de produto e do mercado. O

valor de um item do Product Backlog pode ser indireto, pois em não

escolher um item do Product Backlog poderá reduzir o valor do sistema

ou até mesmo da organização, ou que não ordenando o item no topo do

Product Backlog poderá produzir um valor negativo ou prejudicar a

capacidade futura de criar valor.

A noção de valor ajuda os Product Owners e seus stakeholders a se afastarem da (falsa ideia de) perfeição de um produto total que deve ser completamente construído antes mesmo de considerar seu lançamento. O foco muda para um lançamento de produto mínimo comercializável e o mínimo trabalho necessário para efetivamente trazer valor ao mercado. O Product Backlog pode ser usado para agrupar itens, funcionalidades e requisitos não funcionais em conjuntos de funcionalidades coesas.

 

2.5.5 A importância do Pronto

 

Em uma definição de ‘Pronto’, as qualidades e os critérios são expressos e precisam ser atendidos por um Incremento do produto para que ele seja ‘lançável, para poder lançá-lo em produção. A definição de Pronto possui as qualidades do produto e, muitas vezes, as atividades, critérios, tarefas e trabalho que precisam ser executados em um pedaço funcional de um produto para que ele esteja em um estado de qualidade de produção. ‘Pronto’ é uma qualidade do Incremento e, portanto, faz parte dos artefatos do Scrum.

No entanto, o prefixo ‘potencial’ é adicionado ao ‘Incremento lançável’. Isso se refere à responsabilidade do Product Owner em decidir sobre o lançamento real de um Incremento; uma decisão que provavelmente será baseada na coesão do negócio e na utilidade funcional, conforme observado durante a Sprint ou na Sprint Review. No entanto, a decisão de lançamento pelo Product Owner não deve ser restringida pelo trabalho de ‘desenvolvimento’, portanto, todo o trabalho necessário para atingir o nível de Pronto é executado antes da Sprint Review dentro da Sprint.

O empirismo do Scrum só funciona bem com transparência. A transparência exige padrões comuns para referência de trabalho e inspeção. A definição de Pronto define o padrão para lançável e deve ser conhecida por todos os jogadores. Transparência não significa apenas visível, mas também compreensível. O conteúdo da definição de Pronto deve ser autoexplicativo.

Espera-se que uma organização que prospera e dependa de produtos e serviços tenha uma definição vigente das qualidades do produto e as expresse por meio de padrões, diretrizes, regras, níveis de serviço e outras expectativas. Uma organização profissional define qualidade. Os Development Teams do Scrum, formados por desenvolvedores profissionais de produto, são parte integrante de uma organização, em vez de serem gangues isoladas de codificadores arruaceiros dentro da organização. Espera-se que os tais Development Teams sigam os padrões gerais do produto como definido pela organização.

Se, como seria de esperar, a definição mínima de Pronto é fornecida pela organização, um Development Team irá ainda complementá-la com elementos específicos do contexto; o produto, uma versão ou tecnologia. Na ausência de tais diretrizes organizacionais, um Development Team deve, como profissionais, criar uma definição apropriada de Pronto para o seu trabalho.

Através de uma definição acordada de Pronto, a qualidade está no centro do Scrum. Nenhum trabalho incompleto (não Pronto) faz parte de um Incremento. Nenhum trabalho incompleto é colocado em produção. Nunca. A partir da inspeção do Incremento com base na definição de Pronto, a conversa colaborativa durante a Sprint Review pode incluir qualidade e requisitos com relação à definição de qualidade na organização. Isso ajuda a equipe a considerar a definição de Pronto conveniente na subsequente Sprint Retrospective. A condução auto organizada do Development Team fará com que eles incluam tudo o que for realmente possível e, mais, levará em conta o feedback dos stakeholders.

A propriedade primária da definição de Pronto está com o Development Team, da mesma forma que a propriedade primária do Product Backlog está com o Product Owner. O Development Team é responsável pelo trabalho árduo relacionado ao fornecimento de versões funcionais de produtos que atendem à definição de Pronto. Uma definição de Pronto não pode ser reduzida por forças externas ao Development Team. O Development Team basear-se-á nas expectativas e definições gerais da organização (incluindo as áreas de desenvolvimento, engenharia, qualidade ou operações). O Development Team adicionará qualidades específicas do produto e, obviamente, incorporará as expectativas de qualidade funcionais ou de negócio do Product Owner.

Decisões sobre a definição de Pronto talvez dependam da presença de habilidades, autorizações e disponibilidade de sistemas, serviços e interfaces. Embora dependências em sistemas externos ou interfaces possam levar a uma reordenação do trabalho no Product Backlog, um Development Team prefere progredir. Uma equipe pode usar stubs, mock-ups ou simuladores para sistemas não disponíveis ou dependências técnicas não resolvidas. Mas todas as partes continuam conscientes de que o trabalho não está realmente pronto, pois a definição de Pronto não se reflete trabalho lançável. Isso aumenta a independência da equipe, mas não elimina a dependência. Há uma quantidade imprevisível de trabalho oculto no sistema e ele deve ser executado em algum momento para lançar o produto. Enquanto isso, o Product Owner está impedido de tomar essa decisão. Felizmente, a Sprint Review em última instância revela essas informações para os stakeholders também, então as chances são maiores de que ações apropriadas sejam tomadas dentro da organização.

 

OceanofPDF.com