Scrum

O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software que é mais utilizado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer.

Conforme atestam Schwaber e Sutherland [133], o Scrum é “leve, simples de entender e extremamente difícil de se dominar”, e afirmam:

“Scrum é um framework estrutural que está sendo utilizado para gerenciar o desenvolvimento de produtos complexos desde o início de 1990. O Scrum não é um processo ou uma técnica para construir produtos, em vez disto, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las.”

A.2.9.1 O Processo

(1) PAPÉIS E RESPONSABILIDADES

São 3 os papéis principais de um projeto envolvendo Scrum: o Product Owner, o Scrum Team, e o Scrum Master:

• Retorno financeiro (ROI) do produto;

• Priorizar os requisitos de acordo com o seu valor de mercado. Pode mudar os requisitos e prioridades a cada Sprint.

• Aceitar ou rejeitar o resultado de cada Sprint. Scrum Master:

• Garantir que o time esteja totalmente funcional e produtivo;

• Facilitar a colaboração entre as funções e áreas e eliminar os impedimentos do time;

• Proteger o time de interferências externas;

• Garantir a fluidez do projeto, participando das reuniões diárias, revisão da Sprint, e planejamento.

Scrum Team:

• Selecionar, entre os itens priorizados, os que irão ser executados durante a Sprint. Tem todo o direito de realizar o que quiser dentro da Sprint, com coerência. Equipe formada por 5 a 9 membros.

(2) COMO FUNCIONA

A metodologia divide os projetos em releases e sprints curtos. Cada sprint ocupa apenas a funcionalidade necessária e suficiente que é priorizada pelo cliente e que será entregue no tempo certo, de modo que no final de cada Sprint tem-se um produto de trabalho que pode ser liberado.

Os desenvolvedores e os testadores também participam da história escrita do usuário, que são os itens do backlog. Isso dá uma visão inicial do comportamento do produto para todos na equipe e também ajuda a chegar aos critérios de aceitação no início do próprio sprint.

A.2.9.1.1 Sprints:

No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um tempo definido dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que no Scrum são chamadas de Sprints e geralmente duram de 2 a 4 semanas. O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum. Reunião de planejamento da Sprint possui um time-box com no máximo

oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box

A.2.9.1.2 Product Backlog:

As funcionalidades a serem implementadas no projeto são mantidas em uma lista conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting (uma reunião de planejamento), na qual o Product Owner (quem representa os envolvidos) prioriza todos os itens do Product Backlog e a equipe seleciona as funcionalidades que ela será capaz de implementar durante o Sprint que se inicia. As funcionalidades atribuídas a um Sprint são transferidas do Product Backlog ao Sprint Backlog. O Backlog do Produto é dinâmico, mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. A Figura A.17 ilustra o processo.

Figura A.17: No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints [115].

(3) PRÁTICAS

As práticas ágeis utilizadas na metodologia Scrum não estão textualmente declaradas no Guia Definitivo de Schwaber e Sutherland [133], mas entendemos que elas estão presentes pela evidência dos trabalhos realizados no dia-a-dia. Podemos ainda notar que a maioria das práticas utilizadas pelas outras metodologias, normalmente, também fazem parte do rol de práticas do Scrum de uma maneira complementar, algo que está descrito no guia de uma forma diferente como uma prática a ser adotada, mas sem uma especificação clara de como fazer. Um bom exemplo disto é o Quadro Kanban, que antes de ser uma prática, é também uma metodologia, e quase que obrigatória em Scrum.

Abaixo, as principais práticas de Scrum, específicas de Scrum, lembrando que a metodologia utiliza várias práticas de outras metodologias, realizando as adaptações que cada projeto requer.

1. Quadro de Tarefas (Kanban); 2. Gráfico Burndown;

3. Estimativas 4. Planning Poker;

5. Plano de mitigação de riscos; 6. Entrega de 2 a 4 semanas.

Apêndice B

Práticas Ágeis de Desenvolvimento

de Software

Este apêndice descreve as principais práticas ágeis de desenvolvimento de software, sem contudo se preocupar a quais metodologias elas possam pertencer, focando, também, a evidência delas em referências bibliográficas de pesquisas empíricas e agrupando-as em cinco categorias por afinidades.

B.1 Agrupamento das Práticas Ágeis

As práticas sugeridas para comporem este trabalho foram agrupadas por similaridade, independente se estivessem ou não configuradas como valores ou princípios de determinadas metodologias. As práticas foram agrupadas, em um momento inicial, com 60 itens. Ao rodar o piloto de survey em pesquisa de campo, chegou-se a conclusão de que algumas práticas estariam redundantes entre si por significarem a mesma coisa, mas em metodologias diferentes. As redundâncias1_{foram eliminadas e a tabela ficou com a seguinte configuração:}

GERENCIAMENTO: 1 - Ampliar o conhecimento, 2 - Comunicação, 3 - Design incremental, 4 - Eliminação de desperdícios, 5 - Gráfico Burndown, 6 - Implantação diária, 7 - Integração contínua, 8 - Iterativo e incremental, 9 - Jogo do planejamento, 10 - Minimalismo, 11 - MosCow, 12 - Pagar por uso, 13 - Plano de mitigação de riscos, 14 - Quadro de tarefas, 15 - visibilidade, 16 - Discussão sobre o quadro branco (lousa).

TIME: 1 - Time com poder de decisão, 2 - Time completo 3 - Sentar junto, 4 - Reunião em pé, 5 - Área de trabalho informativa, 6 - Equipes que encolhem, 7 - Continuidade da equipe.

DESENVOLVIMENTO: 1 - Aprender fazendo, 2 - Cliente junto, 3 - Desenvolvimento orientado por características das funcionalidades, 4 - Estórias de usuários, 5 - Modelagem em objetos de domínio, 6 - Programação em pares, 7 - Propriedade coletiva, 8 - Prototipação, 9 - Refatoração.

TESTE: 1 - Teste primeiro (TDD), 2 - Testes integrados.

RELEASE: 1 - Retrospectiva ao término do ciclo, 2 - Entrega de 2 a 4 semanas, 3 - 40 horas semanais, 4 - Adiamento de decisões ao máximo, 5 - Estimativas 6 - Satisfação total do cliente.

1_{Os detalhes dessa abordagem estão retratados na seção que trata das ameaças à validade desta} pesquisa.