Processos Ágeis: Scrum na Prática

• Nomear as três responsabilidades, os cinco eventos e os três artefatos do Scrum precisamente, como definidos pelo seu próprio guia oficial, não por como um curso de certificação os comercializa.
• Enunciar exatamente para o que cada evento serve, e o que especificamente dá errado quando ele é pulado ou reduzido a uma reunião de status.
• Explicar o trade-off central do Scrum: um timebox fixo compra planejamento e cadência de revisão previsíveis ao custo de adiar trabalho recém-descoberto até o próximo Sprint.
• Distinguir as prescrições de fato do Scrum de maus usos comuns e informais do termo (uma reunião diária que não é um Daily Scrum real, um backlog que não é um Product Backlog real).

software-process-models-waterfall-and-its-real-history estabeleceu a falha estrutural que processos ágeis existem para corrigir: uma suposição de que os requisitos podem ser totalmente conhecidos antes de a implementação começar. O Scrum é a resposta concreta mais amplamente adotada a essa falha, e vale tratá-lo com a mesma precisão que esta disciplina deu ao waterfall, definido pela sua própria especificação oficial em vez de pela versão informal e frequentemente diluída que muitas equipes praticam sob o seu nome. O Scrum Guide, mantido e publicado diretamente por Ken Schwaber e Jeff Sutherland, os próprios originadores do Scrum, é um documento curto, preciso e livremente disponível, e este conceito trabalha a partir dele diretamente em vez de a partir de paráfrase de segunda mão.

As três responsabilidades

O Scrum define exatamente três responsabilidades dentro de um Scrum Team, não mais:

text
DEVELOPERS:      As pessoas comprometidas a criar qualquer aspecto de um
                  Increment usável a cada Sprint.

PRODUCT OWNER:   Responsável por maximizar o valor do
                  produto resultante do trabalho dos
                  Developers; responsável por gerenciar o
                  Product Backlog.

SCRUM MASTER:    Responsável por estabelecer o Scrum como definido
                  no Scrum Guide; ajuda todos a entender a
                  teoria e a prática do Scrum, e ajuda a equipe
                  a focar em criar Increments de alto valor.

Notavelmente ausente desta lista: um papel de gerente de projeto atribuindo tarefas individuais, ou um "líder de equipe" separado distinto do Scrum Master. O Scrum deliberadamente concentra a tomada de decisão sobre o que construir no Product Owner e sobre como construir nos Developers como um grupo autogerenciado.

Os cinco eventos

text
O SPRINT:            Um timebox de comprimento fixo (um mês ou menos)
                      contendo todos os outros eventos; produz um
                      Increment usável e potencialmente lançável.

SPRINT PLANNING:     Inicia o Sprint. O Scrum Team decide
                      por que este Sprint é valioso, o que pode ser
                      feito neste Sprint, e como o trabalho escolhido
                      será feito.

DAILY SCRUM:         Um evento de 15 minutos, todo dia útil,
                      para os Developers inspecionarem o progresso
                      em direção ao Sprint Goal e adaptarem o
                      plano para o próximo dia.

SPRINT REVIEW:       O Scrum Team apresenta resultados aos
                      stakeholders, inspeciona o Increment, e
                      adapta o Product Backlog com base no
                      feedback.

SPRINT RETROSPECTIVE: O Scrum Team inspeciona como o último
                      Sprint foi (indivíduos, interações,
                      processo, ferramentas) e planeja melhorias
                      concretas para o próximo Sprint.

Cada evento é um ponto genuíno de inspecionar-e-adaptar, não um relatório de status; o Daily Scrum em particular é especificado como sendo para os próprios Developers replanejarem o seu próprio próximo dia, não uma reunião de reportar-para-cima a um gerente.

Os três artefatos

text
PRODUCT BACKLOG:  Uma lista emergente e ordenada de tudo o que é
                   necessário para melhorar o produto; a única
                   fonte de trabalho.

SPRINT BACKLOG:   O Sprint Goal, os itens do Product Backlog
                   selecionados para o Sprint, e o plano para
                   entregá-los; de propriedade inteiramente dos
                   Developers.

INCREMENT:        Uma pedra de passagem concreta em direção ao Product
                   Goal; cada Increment tem de atender à Definition
                   of Done e ser usável, independentemente de o
                   Product Owner escolher lançá-lo.

A Definition of Done, referenciada pelo artefato Increment, é exatamente o tipo de checklist concreto que conecta diretamente a unit-integration-and-system-testing (software-construction): uma Definition of Done real tipicamente exige que o código do Increment passe pelos seus testes automatizados, entre outras condições, amarrando o próprio artefato do Scrum diretamente de volta à disciplina de teste de nível unitário coberta na irmã deste currículo.

O trade-off real: um timebox fixo

O Sprint do Scrum é um timebox fixo, e essa fixidez é um trade-off genuíno e deliberado, não um padrão neutro. Ele compra à equipe e aos stakeholders uma cadência previsível para planejamento e revisão, já que todos sabem exatamente quando a próxima oportunidade de repriorizar ou inspecionar um Increment ocorrerá. Ele custa à equipe a habilidade de repriorizar no meio do Sprint sem disromper o Sprint Goal com o qual a equipe já se comprometeu; trabalho novo genuinamente urgente descoberto no meio do Sprint ou tem de esperar pelo próximo Sprint Planning, ou, se for disruptivo o bastante, força o Product Owner a considerar cancelar o Sprint inteiramente, uma válvula de escape real, especificada mas raramente usada no próprio Scrum Guide. kanban-and-flow-based-process, o próximo conceito nesta disciplina, é construído especificamente em torno do trade-off oposto.

Exemplo 1: um "Daily Scrum" que não é um

Uma equipe realiza uma reunião diária de 15 minutos onde cada Developer reporta o seu status individual ao Scrum Master, que toma notas e acompanha privadamente qualquer um atrasado. Isto parece um Daily Scrum no calendário, mas inverte o propósito de fato especificado: o Scrum Guide define o Daily Scrum como os Developers inspecionando o progresso em direção ao Sprint Goal e adaptando o seu próprio plano juntos, não um relatório de status para cima a qualquer indivíduo responsável único. Uma reunião com o nome certo e a estrutura errada obtém nenhum do benefício de fato do evento (uma equipe auto-organizada replanejando o seu próprio próximo dia) enquanto ainda custa os 15 minutos completos.

Exemplo 2: pulando a Sprint Retrospective sob pressão de prazo

Uma equipe enfrentando um prazo externo apertado decide pular a Sprint Retrospective "só desta vez" para economizar a hora que ela levaria. Três Sprints depois, o mesmo problema recorrente (um passo de implantação lento e manual que ninguém consertou) ainda está custando à equipe aproximadamente a mesma hora, a cada único Sprint, porque o único evento especificamente projetado para trazer à tona e consertar exatamente este tipo de fricção recorrente foi o único evento repetidamente cortado. O custo da retrospectiva é visível e imediato (uma hora, agora mesmo); o seu benefício (consertar um problema que de outra forma se repete a cada Sprint indefinidamente) é invisível até ela ser pulada frequentemente o bastante para o padrão se tornar óbvio.

Exemplo 3: o trade-off de Sprint-fixo, tornado concreto

No meio do Sprint, uma vulnerabilidade de segurança crítica é descoberta numa dependência de terceiro. O Sprint Backlog, já comprometido com um Sprint Goal específico, não tem espaço alocado para isto. O Product Owner enfrenta o trade-off real que a Teoria Central nomeia: ou o conserto espera até o Goal do Sprint atual ser atendido e a próxima sessão de Sprint Planning, um atraso real e às vezes inaceitável, ou o Product Owner exerce a válvula de escape especificada do Scrum e cancela o Sprint atual de imediato para replanejar em torno da vulnerabilidade imediatamente, o que em si tem um custo real (o trabalho do Sprint Goal parcialmente completado é posto de lado). Nenhuma opção é gratuita; o timebox fixo do Scrum troca exatamente este tipo de flexibilidade no meio do Sprint em troca da previsibilidade que ele compra em todo lugar mais.

• "Um standup diário é a mesma coisa que um Daily Scrum." O Exemplo 1 mostra que uma reunião pode ter o nome certo, o comprimento certo e a cadência diária certa e ainda falhar o propósito de fato especificado se ela é estruturada como um relatório de status para cima em vez dos Developers replanejando juntos; o rótulo sozinho não garante nada.
• "Retrospectivas são a primeira coisa a cortar quando o tempo é curto." O Exemplo 2 mostra que a retrospectiva é especificamente o mecanismo para consertar fricção de processo recorrente; cortá-la sob pressão rotineiramente preserva a exata fricção da qual essa pressão veio em primeiro lugar.
• "O Scrum tem um papel de gerente de projeto." As três responsabilidades na Teoria Central são Developers, Product Owner e Scrum Master; nenhuma destas mapeia sobre um gerente de projeto tradicional atribuindo tarefas individuais, e tratar o Scrum Master como um é uma má aplicação comum e real do framework como oficialmente definido.

O Scrum, como definido pelo seu próprio guia oficial (Schwaber e Sutherland, 2020), prescreve exatamente três responsabilidades (Developers, Product Owner, Scrum Master), cinco eventos (o próprio Sprint, Sprint Planning, o Daily Scrum, a Sprint Review, a Sprint Retrospective) e três artefatos (Product Backlog, Sprint Backlog, Increment), cada um com um propósito preciso e especificado que uma reunião ou documento superficialmente similar mas estruturado de forma diferente pode falhar em entregar mesmo enquanto corresponde ao vocabulário do Scrum. O Sprint do Scrum como um timebox fixo é um trade-off genuíno e deliberado: cadência previsível de planejamento e revisão, ao custo de adiar trabalho recém-descoberto para o próximo Sprint (ou forçar um cancelamento de Sprint explícito e custoso para qualquer coisa urgente o bastante para não esperar). kanban-and-flow-based-process, o próximo nesta disciplina, é construído em torno de escolher o lado oposto desse mesmo trade-off.