Sprint 0 - Pesquisas - Documentações

[Matheuspimentell]

Descrição

Pesquisar sobre as documentações a serem criadas para a sprint 1

Tarefas

Pesquisar sobre as seguintes documentações:

• [x] Termo de abertura do projeto
• [x] Documento de visão
• [x] Estrutura analítica do projeto
• [x] Documento de arquitetura
• [x] Roadmap

Critérios de aceitação

• [x] Postagem da ata de revisão da sprint
• [x] Atualização da tabela de conhecimentos

[gabrielm2q]

Documento de Visão

• Resumo
  • É um termo que busca apresentar uma visão geral do programa, definindo itens como o escopo do projeto, seu posicionamento, a descrição do público-alvo e uma série de restrições do produto. É importante para facilitar o entendimento do produto e o rumo que este tomará.
• Documentos de Visão - Exemplos
  • Doc. de Visão - IBM: o texto aborda todos os pontos relevantes para a concepção de um documento de visão, apresentando um breve resumo de cada componente.
  • Doc. de Visão - Acácia;
  • Doc. de Visão - CheeryUP;
  • Doc. de Visão - Hortum;
  • Doc. de Visão - Chatbot Nilo.

[AdneMoretti]

Documento de Visão

• O documento de visão tem como objetivo apresentar a visão geral do projeto, envolvendo o escopo, a problemática, o propósito e a solução apresentada para o problema, também descreve o que o projeto tem que atender.
• É composto pelos seguintes tópicos:

1. Introdução: Fornece uma visão geral de todo o documento, é composto pelo escopo, propósito e definições e acrônimos
2. Posicionamento: Descreve a oportunidade de negócios, instrução do problema e instrução de posição do produto
3. Descrição dos envolvidos e dos usuários: Descreve todos os envolvidos no processo e suas responsabilidades
4. Visão geral do produto: Fornece uma visão das capacidades do produto, é composto por Perspectiva do Produto, Funções do Produto, Suposições e Dependências.
5. Recursos: Descreve brevemente os recursos do produto
6. Restrições: Apresenta as restrições necessárias do produto
7. Requisitos: A lista de requisitos do produto
8. Referências

Documento de Visão- IBM : Apresenta todos os tópicos do documento de visão e a descrição de cada um deles.

[AdneMoretti]

Estrutura analítica do projeto:

• A estrutura analítica do projeto é responsável por organizar os objetivos e coisas a serem entregadas com o projeto de forma visual, é o plano de projeto baseado em suas dependências. Divide em partes menores para melhor visualização e gerenciamento.
• Para o desenvolvimento de uma EAP é necessário estabelecer as fases principais e em seguida apresentar as tarefas necessárias para alcançar os resultados.
• Uma EAP pode ser orientada a produtos ou ao ciclo de vida do projeto, e cabe ao gerente optar pelo que melhor se adapta a realidade do projeto
• Deve ser produzida depois que os requisitos e o termo de abertura do projeto já estão bem definidos.

  Importância

• Essa estrutura é importante pois ajuda a:

1. Definir as atividades necessárias para o desenvolvimento do projeto;
2. Controlar o andamento do projeto;
3. Facilitar a estimar custos, planejar recursos e identificar riscos;

Níveis de uma EAP

• Nível 1: Contém a tarefa principal do projeto, forma mais simplificada;
• Nível 2: O nível 2 contém dependências do nível 1;
• Nível 3: Distribui as dependências do nível 2 em subdependências e as tarefas necessárias para concluir o nível 2.

Links úteis

Exemplo de EAP- Post-Mortem EAP-euax EAP- artia:

[Matheuspimentell]

Roadmap

Descrição

Roadmap, como o nome sugere, é uma espécie de mapa, uma poderosa ferramenta visual e descritiva que apontará como será o produto ou projeto a cada período de sua evolução.

O roadmap, serve também para alinhar todos os stakeholders aos passos sequenciais para a finalização do projeto. E também orientar a equipe dos passos necessários para a execução do mesmo.

Objetivo

O objetivo de um roadmap é alinhar as visões de todo o time para responder de forma coordenada as 3 seguintes perguntas:

• Onde estamos ?
• Onde queremos chegar ?
• Como chegaremos ?

A principal função de um, roadmap é facilitar o processo de organização das próprias ideias do desenvolvedor do produto, a fim de que ele possa saber o que priorizar. Ainda assim, vale lembrar que um roadmap pode auxiliar a mensurar o possível orçamento do produto.

Ao final, o objetivo do Roadmap é guiar a equipe de desenvolvimento do produto para o MVP

Como fazer um roadmap?

Para a construção de um roadmap, é necessário tomar 4 passos:

• Transportar sua ideia para o papel e validá-la junto aos stakeholders
• Depois de validada, é hora do Brainstorm, onde todas as possíveis funcionalidades que podem resolver o problema de seus clientes devem ser listadas
• Etapa de Organização e hierarquização dos elementos listados no item anterior (Aqui é onde o roadmap é realmente construído): Deve-se confrontar os objetivos do projeto, as expectativas dos stakeholders e as limitações orçamentárias. A partir disso, pode-se organizar as funcionalidades, uma a uma, em cada ponto da sua linha do tempo.
• O roadmap deve ser revisto periodicamente, de acordo com as manifestações dos seus consumidores, mudanças tecnológicas, alterações de tendências ou detecção de falhas.

Links uteis:

Aqui segue uma lista de links úteis para a o melhor entendimento dos roadmaps e suas peculiaridades:

• https://endeavor.org.br/estrategia-e-gestao/roadmap/
• https://blog.runrun.it/o-que-e-roadmap/
• https://pt.venngage.com/blog/roadmap-de-produto/
• https://pt.venngage.com/blog/roadmap-de-produto/

Legendas

• stakeholder: Interessados no projeto (Clientes, usuários, etc...).
• MVP: Do inglês Minimum Viable Product, significa: Mínimo produto viável.
• Brainstorm: Uma "tempestade" de ideias, onde nenhuma ideia é descartada inicialmente. O objetivo é estimular a criatividade.

[MorettiGS]

Termo de Abertura do Projeto ( TAP )

• Resumo

  • O Termo de Abertura do Projeto, também chamado de Project Charter, é um documento que formaliza o início de um projeto, conferindo autorização ao gerente de projeto e agrupando todas as informações necessárias para a execução das atividades envolvidas, dessa forma abrindo formalmente o processo de desenvolvimento do mesmo.

• Entre outras, o documento possui como principais as seguintes seções:

  • Principais responsáveis pelo projeto: Onde estão citados todos os envolvidos na realização do projeto, geralmente com foco no gerente de projeto;
  • Descrição: Uma descrição curta e concisa sobre o que o projeto se trata e quais são suas principais características;
  • Justificativa: Um parágrafo com o objetivo de justificar o ínicio do projeto no tempo e condições presentes, geralmente servindo de termômetro caso o mesmo faça parte de uma lista de outros projetos, destacando sua prioridade.
  • Objetivos e metas do projeto: Uma lista do que a equipe planeja alcançar com o projeto. Preferencialmente, a escrita dessa seção deve ser de forma específica e objetiva, seguindo o conceito SMART;
  • Marcos: Um pequeno texto ou lista contendo as principais e mais importantes entregas do projeto;
  • Premissas: Composta de algumas suposições tomadas pela equipe responsável, como afirmações ou hipóteses que se consideram verdadeiras antes do início do projeto;
  • Restrições: Algumas limitações e riscos que podem afetar o desenvolvimento do processo ou dos participantes da equipe, alterando ou não o produto final;
  • Orçamento estimado para o projeto: Em projetos financiados, essa seção é responsável por apresentar ao patrocinador uma ideia de todos os aspectos financeiros do projeto.

Links Úteis

• Para melhor detalhamento do processo de criação e dos elementos de um TAP, segue os links utilizados para essa pesquisa, junto a alguns exemplos:
  • Conceitos, elementos e exemplos - TAP
  • Project Charter - O que é e quais são seus elementos?
  • TAP - O que é e como montar o seu.
  • TAP - O que é, como fazer, exemplo.
  • Exemplo - TAP
  • Exemplo 2 - TAP

[Matheuspimentell]

Documento de arquitetura

Definição

O documento de arquitetura de software fornece uma visão geral de arquitetura abrangente do sistema de software.

Objetivo

O principal objetivo do documento de arquitetura de software é servir como um meio de comunicação entre o arquiteto de software e outros membros da equipe de projeto, com relação a decisões arquiteturalmente significativas tomadas sobre o projeto.

Afinal, o que é arquitetura de software ?

A arquitetura de software é uma descrição do sistema que auxilia na compreensão de como o sistema irá se comportar.

Arquitetura é um meio de se obter uma análise antecipada para garantir que a abordagem de design apresentada produzirá um sistema que alcance os requisitos exigidos pelos stakeholders, tais como: Desempenho, segurança, disponibilidade, integridade e flexibilidade. Portanto, uma arquitetura de software consiste na definição de suas camadas, que podem envolver entidades como: componentes de software, aplicativos externos, sistemas legados e propriedades externas

Por que documentar a arquitetura de software?

A arquitetura do software deve ser documentada por um simples motivo: Por mais perfeita e adequada que seja a sua arquitetura, ela será inútil para outras pessoas e desenvolvedores que não a conhecem e que não podem entendê-la bem o suficiente para manuseá-la.

Estrutura do documento de arquitetura de software:

• Histórico de revisões
• Introdução
• Representação arquitetural
• Metas e Restrições arquiteturais
• Visão de casos de uso
• Visão lógica
• Visão de implementação
• Referências

Modelos de documento de arquitetura:

• https://fga-eps-mds.github.io/2020.2-Hortum/Documento_de_arquitetura/
• https://fga-eps-mds.github.io/2021.1-AlligaBot/2021/08/03/documento-de-arquitetura/
• https://fga-eps-mds.github.io/2019.2-Acacia/#/architecture_document
• https://fga-eps-mds.github.io/2020.1-Ziguen/
• http://www.facom.ufu.br/~flavio/pds1/files/2016-01/Documento%20de%20Arquitetura%20de%20Software%20do%20SPEU%201-Exemplo-RUP.pdf

Links úteis

• http://www.linhadecodigo.com.br/artigo/3343/como-documentar-a-arquitetura-de-software.aspx
• https://www.cin.ufpe.br/~gta/rup-vc/core.base_rup/workproducts/rup_software_architecture_document_C367485C.html
• https://www.cin.ufpe.br/~gta/rup-vc/core.base_rup/guidances/guidelines/software_architecture_document_F4C93435.html

[Matheuspimentell]

Issue fechada e tabela de conhecimentos atualizada.

[Matheuspimentell]

A Tabela de horários e conhecimentos pode ser vista por qualquer grupo!