Processo de Entrega de Soluções

h1. 4 Fase de Construção

A fase de Construção são realizadas as sprints em que as histórias de usuário são *preparadas*, *construídas* e *testadas*.( ver mais sobre Fase de [[2 - Construção]] ).

Segue abaixo *o que realizar na Fase de Construção* :

p. 4.1  Realizar a *reunião de abertura* (ou reunião de planejamento) da Sprint. 

*Participantes*: Líder do Projeto, Dono da Arquitetura, Gerente Técnico da Contratada, Dono do Produto.

> %{color:#3344ff}A reunião de planejamento da Sprint é composta de duas fases: planejamentos tático e operacional.%

>> %{color:#3344ff}I.	Planejamento Tático%

>>> %{color:#3344ff}Nesta fase, o Dono do Produto apresenta os objetivos da Sprint e as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas, após a reunião, na fase chamada de Planejamento Operacional.%

>> %{color:#3344ff}II.	Planejamento Operacional%

>>> %{color:#3344ff}Nesta fase, a equipe se encontra separadamente para conversar sobre o que ela escutou, decidir com quanto ela pode se comprometer a fazer na Sprint e quebrar as funcionalidades em tarefas. Em alguns casos, haverá negociação com o Dono do Produto, mas será sempre responsabilidade da equipe determinar com quanto ela será capaz de se comprometer.%

> %{color:RED}IMPORTANTE!!!% Os itens de backlog priorizados devem estar *preparados* antes da reunião. Itens que chegam à reunião sem detalhes suficientes podem colocar toda a sprint em risco.%

> %{color:#3344ff}O que é "preparado" ?%

> %{color:#3344ff}•É aquele item que foi trabalhado em sessões de Refinamento do Backlog%

> %{color:#3344ff}•Estimado%

> %{color:#3344ff}•Pequeno o suficiente (idealmente, estimativa não superior a 8 pontos de história)%

> %{color:#3344ff}•Com critérios de aceitação (apresentados como cenários) definidos%

p((. ☐ Definir os itens de trabalho da sprint a partir da visão do Dono do Produto

     ☐ Para cada item do backlog da Sprint deve-se informar a *descrição e a definição de pronto*

> %{color:RED}IMPORTANTE!!!% 

>>%{color:#3344ff} Definição de pronto% é o critério a ser usado pelo Dono do Produto e pela equipe para a aceitação do item como concluído no dia da entrega.%

>> %{color:#3344ff}Uma boa forma de encontrar a definição de pronto do item é pensar na resposta para a pergunta “como eu sei que isso está pronto?”.% 

>>> %{color:#3344ff}Por exemplo, para a preparação de uma história de usuário, a definição de item pronto pode ser a aprovação da história pelo Dono do Produto (antes da reunião de encerramento da Sprint, claro).%

>>> %{color:#3344ff}Para um item de construção de história de cadastro de usuário, a definição de pronto pode ser o cadastramento de um usuário com sucesso, com a demonstração das regras definidas para a história, durante a reunião de entrega.%

--- 

p. 4.2  Refinamento do Backlog   (Agendar no calendário dos participantes outras reuniões para o refinamento do backlog que será construído na próxima sprint)

> %{color:#3344ff}A equipe (ou parte da equipe, incluindo o Dono do Produto) se reúne regularmente para:%

>> %{color:#3344ff}•	decompor épicos e features%

>> %{color:#3344ff}•	preparar histórias de usuário%

>> %{color:#3344ff}•	dividir histórias de usuário priorizadas para caber em uma sprint%

>> %{color:#3344ff}•	realizar a estimativa de histórias que ainda não a possuem%

>> %{color:#3344ff}•	revisar as estimativas de histórias em função de informações recém-descobertas%

>> %{color:#3344ff}•	remover histórias de usuários que não são mais relevantes%

>> %{color:#3344ff}•	criar novas histórias de usuários em resposta às necessidades recém-descobertas%

>> %{color:#3344ff}•	reavaliar a prioridade relativa de histórias%

---

p. 4.2  A Contratada deve durante a realização da sprint:

>> %{color:#3344ff}• Construir as histórias;%

>> %{color:#3344ff}• Quando necessário, entrar em contato com o Líder do Projeto ou Dono do Produto para tirar dúvidas.%

>> %{color:#3344ff}• Para cada item do backlog da sprint deve-se identificar o "Status", conforme imagem abaixo:%

>>| !status_item.png! |

A ordem do fluxo de Status e o significado é :

!status_item_backlog.png!

---

p. 4.3  São identificados requisitos para outras áreas: infraestrutura, por e

---

p. 4.4  Líder do Projeto *deve acompanhar o trabalho da Contratada*, solicitando reportes diários ou semanais do andamento da Sprint, tendo a responsabilidade :

>> %{color:#3344ff}•	identificar impedimentos e atuar para saná-los%

>> %{color:#3344ff}•	verificar como as histórias de usuários estão sendo escritas pela Contratada%

>> %{color:#3344ff}•	verificar se a sprint será finalizada dentro do tempo previsto%

>> %{color:#3344ff}•	identificar riscos como mudança de equipe da Contratada, indisponibilidade do ambiente de desenvolvimento (DTH) onde as entregas deverão ser feitas obrigatoriamente, e etc.%

---

p. 4.5  Realizar a reunião de entrega (ou reunião de encerramento) da Sprint de Construção. 

*Participantes*: Líder do Projeto, Dono da Arquitetura, Gerente Técnico da Contratada, Dono do Produto.

> %{color:#3344ff}O encerramento da sprint é realizado também em duas fases: a revisão e a retrospectiva.%

>> %{color:#3344ff}I.	Revisão da Sprint%

>>> %{color:#3344ff}Ao final de cada Sprint é realizada a reunião de Revisão da Sprint, em que a equipe mostra o que foi alcançado durante a Sprint, no formato de uma demonstração das novas funcionalidades, e uma breve apresentação das ocorrências importantes da Sprint.%

>>> %{color:#3344ff}Durante a Revisão, o projeto é avaliado em relação aos objetivos da Sprint, determinados durante a reunião de Planejamento da Sprint.%

>>> %{color:red}IMPORTANTE!!!% Os itens desenvolvidos precisam ser demonstrados no ambiente do Ministério, e não no ambiente da Fábrica.

>> %{color:#3344ff}II.	Retrospectiva da Sprint%

>>> %{color:#3344ff}A reunião de Retrospectiva da Sprint ocorre ao final de uma Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.%

p((. ☐  A Contratada apresenta os itens do backlog da Sprint que foram realizados

     %{color:#3344ff} 8.2.4.1.12 Deverão constar na entrega de cada sprint, além dos artefatos de documentação e outros previstos para a sprint%, %{color:red}o código-fonte produzido, os testes unitários, de integração e de interface automatizados e suas evidências.%

     ☐  O Dono do Produto deve aceitar os produtos do backlog da Sprint que foram entregues conforme descrição e definição de pronto do item estabelecidos na reunião de abertura

     ☐ Os itens do backlog da sprint não entregues, não aceitos ou aceitos parcialmente devem ter esse estado registrado no seu atributo *Situação*. 

     _%{color:#3344ff}8.2.4.1.11 Os produtos entregues ao final da Sprint serão validados, na reunião de Revisão da Sprint, conforme a definição de pronto e a descrição dos itens definidas na Reunião de Planejamento da sprint.%_

     ☐ São criados novos itens de backlog do produto para os não entregues, não aceitos ou aceitos parcialmente em uma sprint com estimativa de pontos de história que reflita o esforço para executá-los. 

     ☐ Finalizar o preenchimento  do "Termo de Aceitação da Sprint" no SEI e solicitar assinaturas.

---

4.6 Caso no *final da última Sprint de Construção* ainda restem itens a serem construídos, o líder deverá  avaliar :

*"A não construção desses itens compromete o MVP (mínimo produto viável) da release ?"*

*Sim:*

☐ Criar uma *NOVA SPRINT DE CONSTRUÇÃO* com os itens faltantes;

☐ Replanejar a Sprint de Transição (nova data);

%{color:RED}IMPORTANTE!!!%  Não haverá remuneração para as sprints adicionais fora do planejamento.

*Não:*

☐ Os itens devem ir para o Backlog do Produto e deverão ser re-priorizados em uma nova Ordem de Serviço via novo Diagnóstico.

---

p. 4.7  Sempre que necessário realizar registros no Histórico da OS de fatos importantes que ocorreram durante a execução da sprint.