tds-as

Aula - FrameWord Scrum - Parte 2 3

Professor: Mauro Borges França

Objetivos da Aula

Nesta aula serão trabalhados dois artefatos importantes do Scrum:

• Artefato 1 — Documento de Visão do Projeto;

• Artefato 2 — Product Backlog.

Documento de Visão do Projeto

Antes do desenvolvimento de um software, é necessário entender se vale a pena investir no produto.

Algumas perguntas importantes são:

• Vale a pena investir no produto?

• Por que investir nele e não em outro produto?

• O retorno do produto justifica o investimento?

No Scrum, o responsável por organizar essas necessidades é o Product Owner.

O Product Owner transforma as necessidades dos usuários em uma visão sistêmica do software, buscando:

• Amadurecer a ideia;

• Atender às necessidades dos usuários.

Necessidades dos Usuários e Stakeholders

Os usuários e stakeholders apresentam necessidades nas mais diversas áreas de atuação.

Essas necessidades são analisadas pelo Product Owner, que transforma as demandas em um Produto de Software.

Exemplo Utilizado na Aula

Será utilizado um exemplo prático para facilitar o entendimento.

Modelo utilizado:

Instituto de Pesquisa XYZ

Mini Cenário do Modelo

No Departamento de Pesquisa do Instituto XYZ, o servidor entrega toda a documentação do projeto.

O funcionário:

• confere a documentação;

• emite um protocolo de recebimento;

• digitaliza os documentos;

• encaminha os arquivos para um avaliador;

• arquiva a documentação impressa.

O avaliador:

• recebe os arquivos;

• realiza a análise;

• emite um parecer contendo a pontuação atribuída;

• preenche um formulário de trabalho;

• devolve toda a documentação ao Instituto XYZ.

Após isso:

• o Departamento de Pesquisa divulga o resultado no site institucional;

• o setor financeiro realiza o pagamento do avaliador.

Primeiro Passo no Scrum

O primeiro passo é o Product Owner entender todos os detalhes desejados pelos usuários envolvidos no processo.

Esse entendimento é necessário para elaborar o Documento de Visão do Projeto.

O Documento de Visão é considerado o primeiro artefato do Scrum.

O que é a Visão do Produto

A visão do produto descreve:

• o objetivo do produto;

• a intenção de sua criação;

• o que ele pretende alcançar;

• quais problemas ele irá resolver.

A visão do produto representa o estado futuro desejado do software.

Um projeto Scrum normalmente começa com uma visão clara do produto ou sistema a ser desenvolvido.

O Product Owner é o responsável pela criação, manutenção e gerenciamento dessa visão.

Partes Interessadas do Exemplo

As principais partes interessadas do sistema são:

• Pesquisadores;

• Funcionários;

• Avaliadores;

• Financeiro.

Trabalho Manual versus Informatização

O objetivo da informatização é:

• modernizar processos;

• reduzir atividades manuais;

• melhorar o controle das informações;

• aumentar a eficiência organizacional.

Declaração da Visão do Projeto

Exemplo de visão do projeto:

“Desenvolver um sistema web para permitir aos pesquisadores cadastrar seus projetos a serem avaliados e geridos pelo Instituto XYZ.”

Nome do projeto exemplo:

SGPP — Sistema de Gerenciamento de Projetos de Pesquisa.

Estrutura do Documento de Visão

Modelo 1 de Documento de Visão:

1. Título;

2. Objetivo;

3. Justificativa;

4. Descrição Geral;

5. Equipe;

6. Partes Interessadas;

7. Premissas;

8. Restrições;

9. Escopo Excluído;

10. Riscos.

Termo de Abertura do Projeto (TAP)

Outro documento utilizado para representar a visão do projeto é o Termo de Abertura do Projeto.

O TAP é:

• uma declaração oficial dos objetivos do projeto;

• um documento que formaliza o início do projeto;

• uma autorização oficial para início dos trabalhos.

Estrutura do TAP

Modelo 2:

1. Identificação;

2. Resumo;

3. Justificativa;

4. Objetivos;

5. Requisitos;

6. Custos;

7. Partes Interessadas;

8. Equipe;

9. Premissas;

10. Riscos.

O Papel do Product Owner

O Product Owner possui várias responsabilidades importantes:

• Criar a visão do produto;

• Manter a visão do produto;

• Comunicar a visão para o time;

• Representar a voz do cliente;

• Garantir o ROI (Retorno sobre o Investimento);

• Ajudar no entendimento do que deve ser feito;

• Definir metas das Sprints;

• Validar entregas;

• Aceitar ou rejeitar funcionalidades.

ROI significa “Return on Investment”, ou seja, Retorno sobre o Investimento.

Product Backlog

Após a definição da visão do projeto, o Product Owner, com apoio do Scrum Master, cria a primeira versão do Product Backlog.

O Product Backlog é o segundo artefato do Scrum.

Ele concentra todos os requisitos do sistema.

No Scrum, os requisitos normalmente são representados por Histórias de Usuário.

O backlog possui prioridades definidas pelo Product Owner.

O que é Product Backlog

O Product Backlog é:

• uma lista contendo todas as funcionalidades desejadas para o produto;

• único para cada produto;

• constantemente atualizado.

O backlog pode ser criado por:

• histórias de usuário;

• casos de uso;

• funcionalidades do produto.

Características do Product Backlog

• O Product Backlog é a única fonte de trabalho a ser realizado no produto pelo time de desenvolvimento;

• Pode conter correções de problemas ou

• Novas funcionalidades;

• O Product Backlog está em constante evolução e, assim, nunca está terminado ou completo. Conforme o produto evolui, o Product Backlog é frequentemente modificado com a adição, subtração, reordenamento e modificação de seus itens.

• Existem softwares especializados que permitem essa manipulação do Product Backlog, mas uma planilha ou até mesmo notas adesivas em um quadro branco podem funcionar muito bem.

Histórias de Usuário

• As histórias de usuário representam necessidades das partes interessadas.

• Formato mais comum:

  • “Como um ATOR eu quero AÇÃO para FINALIDADE.”

• Exemplo:

  • “Como pesquisador eu gostaria de realizar meu autocadastro para manter meus dados corretos na base do Instituto.”

Uma User Story deve ser:

• Independente;

  • Uma história sempre traduzirá em uma funcionalidade;

• Negociável e negociada;

  • Necessita ser interpretada para ser discutida;

• Valiosa;

  • Deve representar valor de negócio;

• Estimável;

  • Deve ser interpretada tanto pelo usuários quanto pelos devs para estimar o trabalho a ser desenvolvido.

• Pequena (objetiva).

  • Mais próxima do desenvolvimento;

• Testável

  • Verificar e confirmar o que foi proposto.

Encerramento

Nesta aula foram apresentados:

• Documento de Visão do Projeto;

• Termo de Abertura do Projeto;

• Papel do Product Owner;

• Product Backlog;

• Histórias de Usuário;

• Exemplo prático aplicado ao Scrum.