| ... | @@ -5,71 +5,63 @@ |
... | @@ -5,71 +5,63 @@ |
|
|
|
|
|
|
|
_Acesso rápido_
|
|
_Acesso rápido_
|
|
|
|
|
|
|
|
- [Matriz de responsabilidades](#matriz-de-responsabilidades)
|
|
- [Termo de abertura do projeto](#termo-de-abertura-do-projeto)
|
|
|
- [Plano de Comunicação](#plano-de-comunicação)
|
|
|
|
|
- [Cronograma](#cronograma)
|
|
|
|
|
- [Escopo](#escopo)
|
|
- [Escopo](#escopo)
|
|
|
- [Estrutura analítica de projeto (EAP)](#estrutura-analítica-de-projeto-eap)
|
|
- [Estrutura analítica de projeto (EAP)](#estrutura-analítica-de-projeto-eap)
|
|
|
- [User stories e story mapping](#user-stories-e-story-mapping)
|
|
- [User stories e story mapping](#user-stories-e-story-mapping)
|
|
|
- [Termo de abertura do projeto](#termo-de-abertura-do-projeto)
|
|
- [Cronograma](#cronograma)
|
|
|
|
- [Plano de comunicação](#plano-de-comunicação)
|
|
|
- [Qualidade](#qualidade)
|
|
- [Qualidade](#qualidade)
|
|
|
|
- [Matriz de responsabilidades](#matriz-de-responsabilidades)
|
|
|
- [Plano de riscos](#plano-de-riscos)
|
|
- [Plano de riscos](#plano-de-riscos)
|
|
|
|
|
|
|
|
## Matriz de responsabilidades
|
|
## Termo de abertura do projeto
|
|
|
|
|
|
|
|
[🔗 Acompanhamento do status das atividades](https://docs.google.com/spreadsheets/d/1OdzgkQhVz7zNXtZKjigir0L3WSbKFyctkAdeIjew7XM/edit?usp=sharing)
|
|
[🔗 Versão PDF](resources/gp-termo-de-abertura.pdf)
|
|
|
|
|
|
|
|
As responsabilidades foram, no geral, atribuídas de acordo com os papéis da AGES (I, II, III e IV); como a sprint 0 é a iniciação do projeto, e possui atividades diferentes das demais sprints, a matriz foi quebrada em duas: uma com atividades da sprint 0, e outra com as atividades das outras sprints.
|
|
**Stakeholder:** Melissa Streck ([website](https://melissastreck.com/), [Lattes](http://lattes.cnpq.br/5624943469970998))
|
|
|
|
|
|
|
|
### Sprint 0
|
|
**Justificativa:** a população idosa é a que mais cresce em países comoo Brasil, tendo impacto no aumento do consumo de smartphones e apps. Porém muitos apps são difíceis de utilizar para as gerações mais idosas, que necessitam de ajuda de terceiros para poderem realizar tarefas (como postar ou comentar uma foto em rede social) ou executar alguma configuração. A proposta do APPOIO é auxiliar usuários idosos a entenderem como funcionam apps que estão instalados em seus smartphones, além de configurações de apps bem como sobre gerenciamento do sistema operacional. Esta ajuda seria através de conteúdos colaborativos e específicos sobre cada app instalado.
|
|
|
|
|
|
|
|
**Atividades em negrito são prioritárias.**
|
|
_Obs.:_ a proposta tem origem em uma tese de doutorado defendida no PPGCOM da PUCRS em 2020, tendo o projeto também feito parte do Programa Famecos Tecnopuc Startups (FAST) e do Startup Garagem online (maio/junho 2020).
|
|
|
|
|
|
|
|
| **Atividade** | **AGES I** | **AGES II** | **AGES III** | **AGES IV** |
|
|
**Objetivos:** desenvolver um app que apresente conteúdo de auxílio sobre apps instalados e questões do respectivo sistema operacional para usuários idosos. Proporcionar auxílio digital através de interface fácil e intuitiva.
|
|
|
|-----------------------------------------------|:----------:|:-----------:|:------------:|:-----------:|
|
|
|
|
|
| Alimentar a wiki | R | R | R | R |
|
|
|
|
|
| Definir ferramenta de mockups | C | R | A | A |
|
|
|
|
|
| **Desenvolver mockups** | C | R/A | C | A |
|
|
|
|
|
| Definir tecnologias (front/back) | C | C | R/A | A |
|
|
|
|
|
| **Criar projeto inicial (front/back)** | I | I | R/A | A |
|
|
|
|
|
| Definir estratégia de Verificação e Validação | I | C | R/A | C/A |
|
|
|
|
|
| Documentar projeto/arquitetura inicial | I | I | R/A | A |
|
|
|
|
|
| **Criar User Stories** | C | C | C | R/A |
|
|
|
|
|
| Realizar estudos dirigidos | R | R | R | R |
|
|
|
|
|
| Definir plano de comunicações | I | I | I | R/A |
|
|
|
|
|
| Definir organização do time | I | I | C | R/A |
|
|
|
|
|
| **Documentação de requisitos** | R/A | C | C | A |
|
|
|
|
|
| **Modelar o BD (conceitual/lógico)** | I | R/A | R/A | A |
|
|
|
|
|
| Apresentar no dia 31/08 | C | C | C | R |
|
|
|
|
|
|
|
|
|
|
### Sprint 1, 2, 3 e 4
|
|
**Descrição em alto nível:**
|
|
|
|
- cadastro – idade, localização, gênero;
|
|
|
|
- tela inicial com principais funcionalidades – conteúdos (tutoriais/dicas) sobre apps instalados e gerenciamento do sistema operacional;
|
|
|
|
- deve encontrar informações por palavras chave. A busca deve funcionar por digitação ou voz;
|
|
|
|
- feedbacks devem ser muito claros;
|
|
|
|
- navegação fácil;
|
|
|
|
- ajuste de contraste, tamanhos de fontes;
|
|
|
|
- interface intuitiva e simples de usar;
|
|
|
|
- criar uma rede de colaboração no desenvolvimento de conteúdos.
|
|
|
|
|
|
|
|
| **Atividade** | **AGES I** | **AGES II** | **AGES III** | **AGES IV** |
|
|
**Não está no escopo:** versão paga – formas de pagamento.
|
|
|
|-----------------------------|:----------:|:-----------:|:------------:|:-----------:|
|
|
|
|
|
| Alimentar a wiki | R | R | R | R |
|
|
|
|
|
| Definir squads | C | C | C | R |
|
|
|
|
|
| Definir marcos da sprint | I | I | C | R/A |
|
|
|
|
|
| Quebra de tasks | C | C | R | R/A |
|
|
|
|
|
| Desenvolvimento | R | R | R/A | C/A |
|
|
|
|
|
| Code review | C | C | R/A | C |
|
|
|
|
|
| Executar testes funcionais* | A | A | C/A | C/A |
|
|
|
|
|
| Deploy da aplicação | I | I | R | A |
|
|
|
|
|
| Apresentação da review | C | C | C | R |
|
|
|
|
|
|
|
|
|
|
* A cada sprint, diferentes pessoas foram designadas para executar os testes funcionais. De acordo com a definição das squads, pessoas que não participaram do desenvolvimento de uma US foram designadas como responsáveis (R) pelos testes funcionais da mesma.
|
|
**Tecnologia:** app mobile.
|
|
|
|
|
|
|
|
A alocação das pessoas, de acordo com as sprints, pode ver vista abaixo:
|
|
## Escopo
|
|
|
|
|
|
|
|
| **Sprint** | **Pessoas (R)** |
|
|
Informações adicionais podem ser encontradas na página [📄 Escopo](escopo)
|
|
|
|:----------:|:---------------:|
|
|
|
|
|
| 1 | Bianca |
|
|
### User stories e story mapping
|
|
|
| 2 | A ser definido |
|
|
|
|
|
| 3 | A ser definido |
|
|
|
|
|
| 4 | A ser definido |
|
|
|
|
|
|
|
|
|
|
## Plano de Comunicação
|
|
Durante a sprint 0, a partir das anotações obtidas na reunião de levantamento de requisitos, foi desenvolvido um user story mapping para auxiliar na visualização do fluxo dos usuários pela aplicação, assim como das funcionalidades acessadas por cada usuário.
|
|
|
|
|
|
|
|
As user stories foram desenvolvidas com base no user story mapping e no fluxo base de telas da aplicação (presente na página [📄 Mockups](mockups)). As stories foram agrupadas em épicos de acordo com a funcionalidade que implementavam (_Criar tutorial_ e _Login/Cadastro_, por exemplo).
|
|
|
|
|
|
|
|
[🔗 PDF](http://tools.ages.pucrs.br/appoio/appoio-wiki/raw/master/images/gp/Appoio___Plano_de_Comunicação_-_Plano_de_Comunicação.pdf)
|
|
O user story mapping desenvolvido na sprint 0 e as user stories atualizadas encontram-se na página [📄 Escopo](escopo).
|
|
|
|
|
|
|
|
### Estrutura analítica de projeto (EAP)
|
|
|
|
|
|
|
|
A EAP em projetos ágeis permite visualizar, com facilidade, todo o escopo do projeto, agrupado pelas entregas feitas à cliente (por sprint). No Appoio, as stories foram agrupadas de acordo com seus épicos (quando possível, respeitando a sintaxe da EAP); apenas a sprint 0 não possui USs como pacotes de trabalho.
|
|
|
|
|
|
|
|
A EAP é desenvolvida no início do projeto e atualizada conforme mudanças de escopo são feitas. A versão mais atualizada encontra-se abaixo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
O status de entrega de cada US encontra-se na página [📄 Escopo](Escopo).
|
|
|
|
|
|
|
|
## Cronograma
|
|
## Cronograma
|
|
|
|
|
|
| ... | @@ -133,66 +125,74 @@ Além das datas principais de cada sprint, as sprints de desenvolvimento (1, 2, |
... | @@ -133,66 +125,74 @@ Além das datas principais de cada sprint, as sprints de desenvolvimento (1, 2, |
|
|
- 02/12: one-on-one;
|
|
- 02/12: one-on-one;
|
|
|
- 07/12: one-on-one.
|
|
- 07/12: one-on-one.
|
|
|
|
|
|
|
|
## Escopo
|
|
## Plano de comunicação
|
|
|
|
|
|
|
|
Informações adicionais podem ser encontradas na página [📄 Escopo](escopo)
|
|
|
|
|
|
|
|
|
|
### User stories e story mapping
|
|
|
|
|
|
|
|
|
|
Durante a sprint 0, a partir das anotações obtidas na reunião de levantamento de requisitos, foi desenvolvido um user story mapping para auxiliar na visualização do fluxo dos usuários pela aplicação, assim como das funcionalidades acessadas por cada usuário.
|
|
|
|
|
|
|
|
|
|
As user stories foram desenvolvidas com base no user story mapping e no fluxo base de telas da aplicação (presente na página [📄 Mockups](mockups)). As stories foram agrupadas em épicos de acordo com a funcionalidade que implementavam (_Criar tutorial_ e _Login/Cadastro_, por exemplo).
|
|
|
|
|
|
|
|
|
|
O user story mapping desenvolvido na sprint 0 e as user stories atualizadas encontram-se na página [📄 Escopo](escopo).
|
|
|
|
|
|
|
|
|
|
### Estrutura analítica de projeto (EAP)
|
|
|
|
|
|
|
|
|
|
A EAP em projetos ágeis permite visualizar, com facilidade, todo o escopo do projeto, agrupado pelas entregas feitas à cliente (por sprint). No Appoio, as stories foram agrupadas de acordo com seus épicos (quando possível, respeitando a sintaxe da EAP); apenas a sprint 0 não possui USs como pacotes de trabalho.
|
|
|
|
|
|
|
|
|
|
A EAP é desenvolvida no início do projeto e atualizada conforme mudanças de escopo são feitas. A versão mais atualizada encontra-se abaixo.
|
|
[🔗 Versão PDF](resources/gp-plano-de-comunicação.pdf)
|
|
|
|
|
|
|
|
|
|
## Qualidade
|
|
|
|
|
|
|
|
O status de entrega de cada US encontra-se na página [📄 Escopo](Escopo).
|
|
A qualidade do processo e do produto foram averiguadas e acompanhadas pelos AGES IV durante todo o projeto, através de atividades realizadas em diferentes momentos das sprints.
|
|
|
|
|
|
|
|
## Termo de abertura do projeto
|
|
Para garantir a qualidade do produto sendo desenvolvido, ao fim de cada sprint, foram executados testes funcionais manuais com base nos critérios de aceite das user stories. Após a integração final das user stories e geração da versão de homologação, foram executados testes manuais sobre o app, tendo como guia os critérios de aceite das user stories da sprint. O processo completo (e seus resultados a cada sprint) são descritos na página [📄 Qualidade](qualidade).
|
|
|
|
|
|
|
|
[🔗 Versão PDF](resources/gp-termo-de-abertura.pdf)
|
|
Também, como indicador de qualidade, foi considerada a quantidade de USs aceitas pela cliente durante as sprint reviews, e a quantidade de critérios de aceite que passaram nos testes funcionais.
|
|
|
|
|
|
|
|
**Stakeholder:** Melissa Streck ([website](https://melissastreck.com/), [Lattes](http://lattes.cnpq.br/5624943469970998))
|
|
Para garantir a qualidade do processo, alguns artefatos e cerimônias foram usados:
|
|
|
|
|
|
|
|
**Justificativa:** a população idosa é a que mais cresce em países comoo Brasil, tendo impacto no aumento do consumo de smartphones e apps. Porém muitos apps são difíceis de utilizar para as gerações mais idosas, que necessitam de ajuda de terceiros para poderem realizar tarefas (como postar ou comentar uma foto em rede social) ou executar alguma configuração. A proposta do APPOIO é auxiliar usuários idosos a entenderem como funcionam apps que estão instalados em seus smartphones, além de configurações de apps bem como sobre gerenciamento do sistema operacional. Esta ajuda seria através de conteúdos colaborativos e específicos sobre cada app instalado.
|
|
- sprint retrospective: cerimônia padrão do processo AGES, realizada após a entrega de cada sprint à stakeholder. Por meio dessa cerimônia, é possível perceber as partes do processo que estão boas e o que pode ser melhorado. Itens de ação são criados a partir dos pontos de melhoria, para que sejam executados na sprint seguinte e que o processo evolua;
|
|
|
|
- formulário de reconhecimentos e organização do time: formulário aplicado após a sprint review, originalmente se destinava a eleger os membros do time que se destacaram durante a sprint então-finalizada, mas também serviu como fonte de sugestões de melhorias na organização do time.
|
|
|
|
|
|
|
|
_Obs.:_ a proposta tem origem em uma tese de doutorado defendida no PPGCOM da PUCRS em 2020, tendo o projeto também feito parte do Programa Famecos Tecnopuc Startups (FAST) e do Startup Garagem online (maio/junho 2020).
|
|
## Matriz de responsabilidades
|
|
|
|
|
|
|
|
**Objetivos:** desenvolver um app que apresente conteúdo de auxílio sobre apps instalados e questões do respectivo sistema operacional para usuários idosos. Proporcionar auxílio digital através de interface fácil e intuitiva.
|
|
[🔗 Acompanhamento do status das atividades](https://docs.google.com/spreadsheets/d/1OdzgkQhVz7zNXtZKjigir0L3WSbKFyctkAdeIjew7XM/edit?usp=sharing)
|
|
|
|
|
|
|
|
**Descrição em alto nível:**
|
|
As responsabilidades foram, no geral, atribuídas de acordo com os papéis da AGES (I, II, III e IV); como a sprint 0 é a iniciação do projeto, e possui atividades diferentes das demais sprints, a matriz foi quebrada em duas: uma com atividades da sprint 0, e outra com as atividades das outras sprints.
|
|
|
- cadastro – idade, localização, gênero;
|
|
|
|
|
- tela inicial com principais funcionalidades – conteúdos (tutoriais/dicas) sobre apps instalados e gerenciamento do sistema operacional;
|
|
|
|
|
- deve encontrar informações por palavras chave. A busca deve funcionar por digitação ou voz;
|
|
|
|
|
- feedbacks devem ser muito claros;
|
|
|
|
|
- navegação fácil;
|
|
|
|
|
- ajuste de contraste, tamanhos de fontes;
|
|
|
|
|
- interface intuitiva e simples de usar;
|
|
|
|
|
- criar uma rede de colaboração no desenvolvimento de conteúdos.
|
|
|
|
|
|
|
|
|
|
**Não está no escopo:** versão paga – formas de pagamento.
|
|
### Sprint 0
|
|
|
|
|
|
|
|
**Tecnologia:** app mobile.
|
|
**Atividades em negrito são prioritárias.**
|
|
|
|
|
|
|
|
## Qualidade
|
|
| **Atividade** | **AGES I** | **AGES II** | **AGES III** | **AGES IV** |
|
|
|
|
|-----------------------------------------------|:----------:|:-----------:|:------------:|:-----------:|
|
|
|
|
| Alimentar a wiki | R | R | R | R |
|
|
|
|
| Definir ferramenta de mockups | C | R | A | A |
|
|
|
|
| **Desenvolver mockups** | C | R/A | C | A |
|
|
|
|
| Definir tecnologias (front/back) | C | C | R/A | A |
|
|
|
|
| **Criar projeto inicial (front/back)** | I | I | R/A | A |
|
|
|
|
| Definir estratégia de Verificação e Validação | I | C | R/A | C/A |
|
|
|
|
| Documentar projeto/arquitetura inicial | I | I | R/A | A |
|
|
|
|
| **Criar User Stories** | C | C | C | R/A |
|
|
|
|
| Realizar estudos dirigidos | R | R | R | R |
|
|
|
|
| Definir plano de comunicações | I | I | I | R/A |
|
|
|
|
| Definir organização do time | I | I | C | R/A |
|
|
|
|
| **Documentação de requisitos** | R/A | C | C | A |
|
|
|
|
| **Modelar o BD (conceitual/lógico)** | I | R/A | R/A | A |
|
|
|
|
| Apresentar no dia 31/08 | C | C | C | R |
|
|
|
|
|
|
|
|
A qualidade do processo e do produto foram averiguadas e acompanhadas pelos AGES IV durante todo o projeto, através de atividades realizadas em diferentes momentos das sprints.
|
|
### Sprint 1, 2, 3 e 4
|
|
|
|
|
|
|
|
Para garantir a qualidade do produto sendo desenvolvido, ao fim de cada sprint, foram executados testes funcionais manuais com base nos critérios de aceite das user stories. Após a integração final das user stories e geração da versão de homologação, foram executados testes manuais sobre o app, tendo como guia os critérios de aceite das user stories da sprint. O processo completo (e seus resultados a cada sprint) são descritos na página [📄 Qualidade](qualidade).
|
|
| **Atividade** | **AGES I** | **AGES II** | **AGES III** | **AGES IV** |
|
|
|
|
|-----------------------------|:----------:|:-----------:|:------------:|:-----------:|
|
|
|
|
| Alimentar a wiki | R | R | R | R |
|
|
|
|
| Definir squads | C | C | C | R |
|
|
|
|
| Definir marcos da sprint | I | I | C | R/A |
|
|
|
|
| Quebra de tasks | C | C | R | R/A |
|
|
|
|
| Desenvolvimento | R | R | R/A | C/A |
|
|
|
|
| Code review | C | C | R/A | C |
|
|
|
|
| Executar testes funcionais* | A | A | C/A | C/A |
|
|
|
|
| Deploy da aplicação | I | I | R | A |
|
|
|
|
| Apresentação da review | C | C | C | R |
|
|
|
|
|
|
|
|
Também, como indicador de qualidade, foi considerada a quantidade de USs aceitas pela cliente durante as sprint reviews, e a quantidade de critérios de aceite que passaram nos testes funcionais.
|
|
* A cada sprint, diferentes pessoas foram designadas para executar os testes funcionais. De acordo com a definição das squads, pessoas que não participaram do desenvolvimento de uma US foram designadas como responsáveis (R) pelos testes funcionais da mesma.
|
|
|
|
|
|
|
|
Para garantir a qualidade do processo, alguns artefatos e cerimônias foram usados:
|
|
A alocação das pessoas, de acordo com as sprints, pode ver vista abaixo:
|
|
|
|
|
|
|
|
- sprint retrospective: cerimônia padrão do processo AGES, realizada após a entrega de cada sprint à stakeholder. Por meio dessa cerimônia, é possível perceber as partes do processo que estão boas e o que pode ser melhorado. Itens de ação são criados a partir dos pontos de melhoria, para que sejam executados na sprint seguinte e que o processo evolua;
|
|
| **Sprint** | **Pessoas (R)** |
|
|
|
- formulário de reconhecimentos e organização do time: formulário aplicado após a sprint review, originalmente se destinava a eleger os membros do time que se destacaram durante a sprint então-finalizada, mas também serviu como fonte de sugestões de melhorias na organização do time.
|
|
|:----------:|:---------------:|
|
|
|
|
| 1 | Bianca |
|
|
|
|
| 2 | A ser definido |
|
|
|
|
| 3 | A ser definido |
|
|
|
|
| 4 | A ser definido |
|
|
|
|
|
|
|
|
## Plano de riscos
|
|
## Plano de riscos
|
|
|
|
|
|
| ... | | ... | |
