Algo que eu achei vexatório durante bastante tempo é como é comum para muitos na indústria usar termos como “Scrum mas …” num sentido pejorativo, implicando que as equipas só devem seguir o pequeno conjunto de práticas que fazem parte do Scrum. A realidade é que para que qualquer equipe Ágil seja capaz de entregar software de trabalho repetidamente durante qualquer período de tempo significativo, Scrum por si só não é suficiente. Quer percebam ou não, a grande maioria das equipes que se chamam equipes Scrum estão operando como um híbrido Scrum-XP, ou um híbrido Scrum-Kanban-XP, onde empregam pelo menos um subconjunto das práticas técnicas que se originaram com XP.
Deixe-me registrar e dizer que equipes que estão apenas seguindo as práticas Scrum têm poucas probabilidades de sucesso a longo prazo, pois pelo menos um subconjunto das práticas técnicas XP é uma necessidade para o sucesso contínuo como uma equipe de entrega Agile.
Eu tenho observado que não há pessoas suficientes que entendam o que Scrum faz e não inclui, então vamos começar por aí.
O que Scrum é – um conjunto de práticas de gerenciamento
Scrum é a aplicação do controle empírico de processos, que é uma forma extravagante de dizer que devemos estar tomando decisões baseadas na experiência, não baseadas em algum conjunto hipotético de suposições que não estão fundamentadas na realidade.
Simplesmente dito, Scrum consiste em um pequeno conjunto de práticas de gerenciamento que visam ajudar as equipes a colaborar efetivamente e entregar trabalho de forma iterativa (deixe-me enfatizar mais uma vez – não existem práticas técnicas no Scrum).
Para resumir brevemente o conteúdo do Scrum Guide:
- Existe uma Equipe Scrum, que é composta por Desenvolvedores, o Proprietário do Produto, e o Scrum Master.
- Existem os Eventos Scrum, que consistem no Sprint, Sprint Planning, o Scrum Diário (aka Daily Standup, em XP), Sprint Review, e Sprint Retrospective.
- Existem os artefatos Scrum, que consistem no Backlog do Produto, o Sprint Backlog e o Incremento, onde um Incremento existe assim que um item do Sprint Backlog atende à Definição de Done.
- Existe uma Definição de Done, onde qualquer equipe Scrum tem um entendimento compartilhado do que significa “feito” para qualquer item do Backlog do Produto. Note que, ao contrário dos Acceptance Criteria, a Definição de Done é globalmente aplicada, enquanto Acceptance Criteria é específica para itens individuais do Product Backlog.
O que Scrum não é
Contrário à crença popular, nenhuma das seguintes coisas fazem parte do Scrum:
- Estórias de usuários. Os itens de trabalho em um dado Backlog de Produtos ou Sprint Backlog da equipe Scrum são escritos como histórias de usuários (muitas vezes no formato “Como um <persona/role>, eu quero <goal>, para que <resultado desejado>”), mas Scrum não exige nenhuma construção ou formato em particular. Note que as histórias de usuários são parte da XP.
- Estimativa. Mesmo que a grande maioria das equipes Scrum façam estimativas em algum nível, a prática da estimativa não faz parte do Scrum.
- Velocidade. Velocity também não faz parte do Scrum; a noção de velocidade do projeto faz parte do XP.
- Práticas técnicas. Como foi observado acima, não há noção de práticas técnicas (CI, CD, programação de pares, TDD, etc.) no Scrum. A grande maioria das práticas técnicas que as equipes normalmente seguem originou-se com XP.
O que é Programação Extrema?
Foi mais de duas décadas desde que a primeira equipe de Programação Extrema (XP) foi formada, onde eles trabalharam em um projeto chamado Chrysler Comprehensive Compensation (C3). Os métodos que a equipe empregou tiveram origem em grande parte nos anos 80, quando Kent Beck e muitos outros estavam experimentando melhores formas de desenvolver software, ou seja, uma alternativa à abordagem “cascata” que se tornou dominante naquela época.
O trabalho visual tem sido sempre uma forma importante de informar como as equipes Ágeis trabalham. Portanto, como uma introdução à EXP, recomendo que qualquer pessoa que queira aprender mais seria bem servida começando com estes diagramas:
- Projeto de Programação Extrema (diagrama end-to-end)
- Iteração (diagrama focando no que acontece dentro de uma iteração; note que o que o XP chama de iteração é conceitualmente similar ao que Scrum chama de Sprint)
- Desenvolvimento (diagrama focando nas interações e atividades de desenvolvimento)
- Propriedade de Código Coletivo (diagrama focando nas práticas técnicas centrais)
Nota: Para um visual que combina muitos dos elementos dos diagramas acima em uma página, veja a Visão Geral da Programação Extrema de Bill Wake.
Leitura adicional sobre XP
Se o visual acima intriga você o suficiente para querer ler mais sobre XP, veja as seguintes fontes de informação, que estão listadas mais ou menos em ordem de menor para ler > mais longo para ler:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (ver também Regras de Simplicidade Xp)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (aka the 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (aka the WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Referências Adicionais
Todas as referências nesta secção são do site XP de Don Wells, a menos que seja indicado o contrário.
- Os Modelos Ágeis são Pinturas, não Fotografias (todos os modelos estão errados; alguns são úteis)
- Agile Process Proverbs (palavras para qualquer equipe viver)
- Bill Wake, Arrange, Act, Assert (padrão para escrever testes unitários)
- Bill Wake, Sudoku Solver (variação interessante em TDD)
- Bill Wake, Testes de um Chapéu (uma abordagem criativa para escrever testes unitários)
- Planos Honestos (como se parece a estimativa na prática)
- Gerencie Seus Objetivos ao invés de Atividades (principais diferenças entre Cascata e Desenvolvimento Ágil)
- Os Valores da Programação Extrema (Simplicidade, Comunicação, Feedback, Respeito, Coragem)
- XP e Bases de Dados (um padrão baseado em ouro > prata > bases de dados em bronze)