Bianca Camargo Machado| Home | Escopo | Arquitetura | Configuração | Mockups | BD | Instalação | Gerência | Qualidade | Processo |
|---|
Gerenciamento do Projeto
Acesso rápido
- Termo de abertura do projeto
- Escopo
- Cronograma
- Plano de comunicação
- Qualidade
- Matriz de responsabilidades
- Plano de riscos
Termo de abertura do projeto
Stakeholder: Melissa Streck (website, Lattes)
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.
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).
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.
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.
Não está no escopo: versão paga – formas de pagamento.
Tecnologia: app mobile.
Escopo
Informações adicionais podem ser encontradas na página
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
O user story mapping desenvolvido na sprint 0 e as user stories atualizadas encontram-se na página
A ferramenta Airtable foi utilizada para gerenciar as user stories e épicos do projeto, sendo usado como "fonte da verdade" da descrição das USs e seus critérios de aceite. O status de cada US era atualizado conforme andamento da sprint. As imagens abaixo exemplificam a organização do Airtable usada.
User stories no Airtable
Épicos no Airtable
Da forma como organizado, foi possível ter uma visão geral simplificada do progresso de desenvolvimento dos épicos: quanto estava concluído e quanta faltava ser executado para completar.
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
Cronograma
Além das datas principais de cada sprint, as sprints de desenvolvimento (1, 2, 3 e 4) também contam um cronograma para a realização das principais atividades do time, como limite para a abertura de merge requests, período de integrações ao fim da sprint e período para a execução de testes funcionais manuais. Os marcos encontram-se na página
Iniciação | 10/08 a 12/08
- 10/08: apresentação da AGES;
- 12/08: apresentação do processo da AGES, Fluxo AGES e artefatos.
Sprint 0 | 12/08 a 02/09
- 12/08:
👥 integração do time; - 17/08:
🗓 apresentação do projeto pela stakeholder (reunião de levantamento de requisitos); - 31/08:
🌟 apresentação dos mockups e user stories à stakeholder (Sprint Review); - 02/09:
⚙ ️ Sprint Retrospective; - 02/09:
📝 entrega do relatório da sprint (❗ ️).
Sprint 1 | 02/09 a 23/09
- 31/08:
🗓 Sprint Planning; - 21/09:
🌟 Sprint Review; - 23/09:
⚙ ️ Sprint Retrospective; - 23/09:
📝 entrega do relatório da sprint (❗ ️).
Sprint 2 | 23/09 a 21/10
- 21/09:
🗓 Sprint Planning; - 28/09:
📜 entrega do relatório de andamento (‼ ️); - 30/09: one-on-one;
- 05/10: one-on-one;
- 07/10:
🌎 retrospectiva da AGES (‼ ️); - 19/10:
🌟 Sprint Review; - 21/10:
⚙ ️ Sprint Retrospective; - 21/10:
📝 entrega do relatório da sprint (❗ ️).
Sprint 3 | 21/10 a 11/11
- 19/10:
🗓 Sprint Planning; - 09/11:
🌟 Sprint Review; - 11/11:
⚙ ️ Sprint Retrospective; - 11/11:
📝 entrega do relatório da sprint (❗ ️).
Sprint 4 | 11/11 a 23/11
- 09/11:
🗓 Sprint Planning; - 23/11:
🌟 Sprint Review; - 23/11:
⚙ ️ Sprint Retrospective; - 23/11:
📝 entrega do relatório da sprint (❗ ️).
Encerramento | 23/11 a 07/12
- 25/11:
🌎 retrospectiva da AGES (‼ ️); - 30/11:
🌎 apresentação dos projetos para todos os times (‼ ️); - 02/12: one-on-one;
- 07/12: one-on-one.
Plano de comunicação
| Evento | Descrição | Responsável | Envolvidos | Frequência | Duração |
|---|---|---|---|---|---|
| Kickoff | A reunião de Kickoff é a primeira reunião entre o time e o cliente do projeto. Nela é apresentada a ideia geral do projeto e são respondidas dúvidas e questionamentos sobre o mesmo, possibilitanto um levantamento inicial dos requisitos do projeto por parte da equipe, com o auxílio do cliente, que detém o conhecimento sobre o produto a ser desenvolvido. | Cliente | AGES I, II, III, IV e Cliente | Uma vez | 1 hora e 30 minutos |
| Daily | Cada integrante do time atualiza os demais sobre o que fez desde o último encontro síncrono, o que pretende fazer em seguida, e se tem impedimentos, para que possam ser removidos. | AGES IV | AGES I, II, III, IV | Segundas e Quartas, 17:30 (início dos encontros síncronos) | 15 minutos |
| Sprint Review | Demonstra-se, revisa-se e discute-se aquilo que foi trabalhado durante a Sprint, fornecendo inputs importantes para a Sprint Planning. | AGES IV | AGES I, II, III, IV e Cliente | Aproximadamente a cada 3 semanas (final da Sprint) | 1 hora |
| Sprint Planning | Planeja-se o trabalho que será realizado durante a Sprint, priorizando-se itens do Product Backlog e movendo-os para o Sprint Backlog. | AGES IV | AGES I, II, III, IV e Cliente | Aproximadamente a cada 3 semanas (início da Sprint) | 30 minutos |
| Sprint Retrospective | A Retrospectiva da Sprint é uma oportunidade para o time se inspecionar e criar um plano de melhorias a serem implementadas durante a próxima Sprint. Durante o evento, a equipe discute o que correu bem na Sprint e o que pode ser melhorado na próxima Sprint. Embora melhorias possam ser implementadas a qualquer momento, a Retrospectiva da Sprint oferece uma oportunidade formal para focar na inspeção e adaptação. | AGES IV | AGES I, II, III, IV | Aproximadamente a cada 3 semanas (final da Sprint) | 1 hora e 30 minutos |
| Tasks Breakdown | Momento em que é realizada a quebra de cada User Story priorizada para a Sprint em tarefas técnicas específicas, mensuráveis, pequenas o suficiente e idealmente paralelizáveis. | AGES III e IV | AGES I, II, III, IV | Aproximadamente a cada 3 semanas (início da Sprint) | 1 hora |
| Squads Breakdown | Momento em que os Gerentes de Projeto se reunem para organizar o time dividindo-o em squads, considerando nessa divisão critérios que visem maximizar a produtividade e efetividade dos desenvolvedores para que assim atinjam o objetivo da entrega estipulada na Sprint. | AGES IV | AGES IV | Aproximadamente a cada 3 semanas (início da Sprint) | 1 hora |
Qualidade
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.
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
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.
Para garantir a qualidade do processo, alguns artefatos e cerimônias foram usados:
- 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.
Matriz de responsabilidades
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.
Sprint 0
Atividades em negrito são prioritárias.
| 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 |
Sprint 1, 2, 3 e 4
| 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 |
* 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.
A alocação das pessoas, de acordo com as sprints, pode ver vista abaixo:
| Sprint | Pessoas (R) |
|---|---|
| 1 | Bianca |
| 2 | Bianca e Rafael A. |
| 3 | Bianca e Rafael A. |
| 4 | Bianca e Rafael A. |
Plano de riscos
| Risco | Probabilidade | Impacto | Severidade | Estratégia | Ações |
|---|---|---|---|---|---|
| Alterações de escopo | 4 | 5 | 20 | Mitigar | Definir escopo no início do projeto e balancear aceitando apenas mudanças pequenas (que não exijam retrabalho) ao decorrer do projeto. |
| Falta de engajamento de membros | 4 | 5 | 20 | Mitigar | Manter comunicação ativa e conversas direcionadas quando isso acontecer. E caso ocorra e esteja impactando demais membros do time, reorganizar tarefas da forma necessária. |
| Falta de entrega de User Stories planejadas | 4 | 4 | 16 | Mitigar | 1. Acompanhar desenvolvimento do time; caso um possível atraso seja identificado, auxiliar no que for necessário. 2. Definir tempo de integração de tarefas, para que seja possível desenvolver algumas tarefas pendentes. |
| Problemas inesperados na demostração para o cliente | 4 | 5 | 20 | Eliminar | Realizar testes funcionais para cada contribuição de código e antes da entrega com a versão final da aplicação. |
| Falta de presença do stakeholder | 2 | 5 | 10 | Transferir | Mandar lembretes com 6h de antecedência e manter comunicação aberta e disponível com o stakeholder, assim fica a cargo do mesmo nos avisar com atencedência em caso de falta necessária |
| Entrega de User Stories planejadas antes do fim da sprint | 3 | 5 | 15 | Melhorar | Tendo entregue o que foi planejado, analisar capacidade para mais USs dentro do nosso planejamento da Sprint |
| Falta de créditos para AWS da AGES | 4 | 4 | 16 | Transferir | Transferir essa necessidade para o stakeholder, caso queira as entregas em homologação, disponibilizar conta AWS para que seja utilizada na AGES durante o andmento do projeto |