Apresentação resultados - Unidade 4 (Vídeo)
| O problema | Dificuldade, dos alunos da UnB, em organizar a agenda quanto às aulas e quanto às demais atividades do dia-a-dia. |
| Afeta | Alunos da UnB. |
| Cujo Impacto é | Menor desempenho acadêmico. |
| Uma solução de sucesso seria | Uma agenda personalizada para esse público. |
Apesar de existirem muitas agendas no mercado, nenhuma delas é voltada e personalizada para o público que o produto apresentado pretende atingir. Dessa forma, o nosso produto destaca-se em meio aos demais devido à forma que se atentará aos problemas dos discentes. Para isso haverá, na aplicação Web, por exemplo, uma maior facilidade de se agendar eventos conforme a grade horária da instituição acadêmica.
| Para | Alunos da UnB. |
| Quem | Possuem dificuldade em se organizar |
| O (nome do projeto) | FGAgenda |
| Que | Será personalizado para o público-alvo, facilitando, por exemplo, enquadrar seus afazeres dentro da Grade horária seguida pela instituição acadêmica. |
| Ao contrário | Do google agenda, que não é personalizado para os estudantes da UnB. |
| Nosso Produto | Será sincronizado com a grade da UnB, cada evento possuirá uma To-Do List do que o usuário necessita realizar. Além disso, terá notificações para informar que o prazo para a realização de determinada meta está acabando. Finalmente, outras pessoas poderão enviar convites de eventos (ex.: monitoria) e serão apresentadas as porcentagens cumpridas das tarefas. |
O produto visa facilitar a organização pessoal do usuário com relação a seu tempo, por meio da junção, na aplicação, de todos os eventos e metas do usuário, sendo todos esses bem detalhados na própria aplicação. Mais especificamente, o produto visa o público alvo de alunos da UnB e, dessa forma, objetiva que esses usuários possam adicionar eventos que seguem a grade horária da faculdade mais facilmente, diferentemente de outros tipos de eventos.
| ÉPICO | FEATURE | ID | HISTÓRIA | PRIORIDADE | PONTUAÇÃO |
|---|---|---|---|---|---|
| Usuários | Autenticação | US - 01 | Eu, como usuário do produto, desejo cadastrar uma nova conta na plataforma, para poder utilizá-la | ALTA | |
| US - 02 | Eu, como usuário do produto, desejo realizar login na plataforma, para que eu possa ter acesso às funcionalidades da mesma | ALTA | |||
| US - 03 | Eu, como usuário do produto, desejo realizar logout, para que eu possa desconectar a minha conta da plataforma | ALTA | |||
| Agenda | Gerenciamento de Metas | US - 04 | Eu, como usuário do produto, desejo cadastrar uma Meta na minha agenda, para saber ao certo o dia que preciso terminar determinada tarefa | ALTA | |
| US - 05 | Eu, como usuário do produto, desejo editar minhas Metas, para que elas possam estar sempre atualizadas | ALTA | |||
| US - 06 | Eu, como usuário do produto, desejo marcar como completa uma Meta realizada | ALTA | |||
| US - 07 | Eu, como usuário do produto, desejo remover uma Meta, caso eu queira, para poder organizar minha agenda | ALTA | |||
| Gerenciamento de Eventos | US - 08 | Eu, como usuário do produto, desejo cadastrar um Evento na minha agenda, para saber ao certo o dia e hora que tal Evento ocorrerá | ALTA | ||
| US - 09 | Eu, como usuário do produto, desejo editar meus Eventos, para que eles possam estar sempre atualizados | ALTA | |||
| US - 10 | Eu, como usuário do produto, desejo poder remover um Evento, caso eu queira, para organizar melhor minha agenda | ALTA | |||
| US - 11 | Eu, como usuário do produto, desejo receber notificações de qualquer Evento com antecedência para que eu possa me programar. | BAIXA | |||
| US - 12 | Eu, como usuário do produto, desejo escolher tipo de aula ou evento. | ALTA | |||
| US - 13 | Eu, como usuário do produto, desejo adicionar aula por código ou horário. | ALTA | |||
| Gerenciamento de TO-DO list | |||||
| US - 14 | Eu, como usuário do produto, desejo criar uma lista de tarefas (TO-DO LIST) para estar sempre informado dos meus afazeres | ALTA | |||
| US - 15 | Eu, como usuário do produto, desejo editar uma lista de tarefas (TO-DO LIST) para que ela esteja sempre atualizada | ALTA | |||
| US - 16 | Eu, como usuário do produto, excluir uma lista de tarefas (TO-DO LIST), caso eu queira, para poder organizar minha agenda | ALTA | |||
| US - 17 | Eu, como usuário do produto, desejo saber qual a porcentagem das tarefas que já realizei, para que possa ter uma noção da minha evolução nelas | MÉDIA |
| Legenda (prioridades) | Definição |
|---|---|
| Alta | Requisitos sem os quais a aplicação é considerada incompleta |
| Média | Requisitos importantes que podem ser postergados |
| Baixa | Requisitos sem os quais o Sistema funciona de maneira satisfatória |
| Requisitos Não Funcionais (Classificação) | RNf |
|---|---|
| Requisitos de Implementação | O backend do produto deve ser desenvolvido em Django |
| O frontend do produto será desenvolvido em HTML/CSS | |
| O protótipo do front end será feito no Figma | |
| A responsidade do produto será feita utilizando a aplicação PWA | |
| Requisitos Legislativos | O produto esteja de acordo com a LGPD (Lei geral de proteção de dados) |
| Requisito de segurança da informação | A senha do login do usuário deverá ser criptografada |
| Requisitos de Usabilidade | A agenda deve ser organizada em uma tabela (linhas e colunas), para uma melhor visualização das minhas atividades |
| O produto deve fazer uso de pop-ups | |
| Deve ser possível ver tanto a agenda da semana quanto do mês | |
| O produto deve ser acessível via mobile e Desktop | |
| O sistema deve apresentar um calendário em formato Gregoriano | |
| O sistema deve funcionar apenas com acesso a internet | |
| Requisito de Portabilidade | O produto deve funcionar nos seguintes Browsers: Chrome 85 |
O MVP, dentro dos Requisitos Funcionais (RFs) são:
- Usuários:
- US-01: Cadastrar uma nova conta na plataforma;
- US-02: Realizar login na plataforma;
- US-03: Realizar logout;
- Agenda:
- US-04: Cadastrar uma Meta;
- US-05: Editar Metas;
- US-06: Marcar meta como completa;
- US-07: Remover uma Meta;
- US-08: Cadastrar um Evento;
- US-09: Editar Eventos;
- US-10: Remover Evento;
- US-12: Escolher tipo aula ou evento;
- US-13: Adicionar aula por código/horário;
- US-14: Criar uma TO-DO list;
- US-15: Editar uma TO-DO list;
- US-16: Excluir uma lista de tarefas (TO-DO lists);
Quadro Canvas MVP:
A partir dos fatores propostos por Sommerville (SOMMERVILLE, 2011), para avaliação quanto a utilização de uma abordagem dirigida a plano ou ágil, a equipe utilizou os seguintes:
-
- Sistema.
-
Nas questões técnicas, o sistema a ser desenvolvido é considerado médio-grande devido ao escopo da aplicação, a qual será realizada para a Web (responsiva) e possui vida útil até o final do semestre 2021/2, pois o produto é focado, principalmente, para os alunos na UnB, portanto, contará com funcionalidades específicas para o público-alvo. Além do que, as atividades do sistema não precisará passar por análise com o objetivo de verificar se estão de acordo com as normas estabelecidas pelo Governo por Lei, ou seja, não será auditável.
-
- Equipe.
-
O nível de competência da equipe é satisfatório para as tecnologias escolhidas para produzir a aplicação, e como ocorrerá a rotatividade dos desenvolvedores do back-end e do front-end, a equipe pode ser considerada full-stack, ainda tendo como suporte para o sistema as tecnologias: Django/Python, HTML/CSS, PWA, Git/GitHub, Figma, Microsoft Teams, ZenHub.
-
- Organização.
-
Nos aspectos organizacionais, não é necessário uma especificação detalhada dos requisitos antes de começar a implementação, além do que o Product Owner será parte da equipe, e com a entrega de uma funcionalidade da aplicação por semana, o objetivo principal é a valorização do produto como um todo.
De acordo com as características do produto com relação às questões técnicas, humanas e organizacionais, a metodologia escolhida pela equipe foi a Metodologia Ágil, e dentro dela, o Framework Scrum.
- Tendo em vista os aspectos do sistema, o Scrum possibilita desenvolver, de maneira mais eficiente, uma aplicação a partir do tamanho do escopo definido, médio-grande, em um prazo curto-médio, de 4 a 5 meses, pois a Framework utiliza-se, principalmente, da construção de um Backlog e de Sprints.
Com base nos aspectos da equipe, o Scrum se alinha com o conhecimento prévio possuído pelos desenvolvedores. Dado que todos envolvidos no projeto possuem pouca experiência na concepção de softwares complexos, o scrum certamente é uma boa ideia por possibilitar, com certa facilidade, o melhor planejamento da resolução de pendências que eventualmente surgirem no fim de cada sprint.
Considerando os aspectos da organização, o Scrum possibilita um desenvolvimento do produto sem ter todas as etapas especificadas previamente, isso facilitaria o planejamento de todo o projeto. Além disso, com as sprints semanais a equipe teria uma melhor produtividade e organização de todo o desenvolvimento do produto.
As principais práticas, baseadas no método Scrum, que serão utilizadas pela equipe são: planejamento da sprint, daily scrum, sprints de uma semana de duração, retrospectiva da sprint, com sprint review ao final de cada sprint, rotatividade dos papéis de Product Owner e Scrum Master com o objetivo de que cada membro ganhe experiência diferentes de não apenas ser Desenvolvedor, utilização do quadro kanban que será o ZenHub do GitHub, além de pair pairing e planning poker.
| Atividade | Objetivo | Papel | Método | Ferramenta |
|---|---|---|---|---|
| Estabelecer escopo do produto | Estabelecer funcionalidades e definir as características que devem estar presentes no produto. | Product Owner e Equipe de desenvolvimento | Reunião em que será definido o escopo do produto e organizá-lo em uma planilha | Google Sheets |
| Organizar sprint | Planejar o Backlog da Sprint. | Product Owner, Scrum master e Equipe de desenvolvimento | Reuniões no começo da semana para definir o backlog e alinhamento da equipe | GitHub/ZenHub |
| Executar Sprint | Concluir todas as atividades determinadas pelo Backlog | Equipe de Desenvolvimento | Distribuição dos requisitos para os membros da equipe | GitHub/ZenHub e Django/Python |
| Reuniões Diárias | Acompanhar o desenvolvimento das funcionalidades da Sprint. | Equipe de desenvolvimento | Exposição das atividades realizadas no dia e planejamento do dia seguinte. | Microsoft Teams |
| Controlar Versões do Produto | Administrar os diferentes branches do produto para que seja possível voltar à versões mais estáveis caso necessário. | Desenvolvedor | Desenvolvimento de novas funcionalidades através do versionamento do projeto. | Git/GitHub |
| Definição de protótipo de baixa/média fidelidade | Criar protótipos de telas que serão utilizadas como base para desenvolvimento da aplicação web. | Desenvolvedor | Elaborar páginas que servirão de base para desenvolver front-end. | Elaborar páginas que servirão de base para desenvolver front-end. |
| Criar interface da tela | Concluir as telas da aplicação WEB | Desenvolvedor | Códigos html buscando desenvolver a interface de acordo com o protótipo de baixa/média fidelidade | HTML/CSS |
| Deployment | Criar um link para o projeto poder ser acessado por qualquer pessoa. | Desenvolvedor | Deploy no Github Pages | GitHub Pages |
| Entregar o produto | Entregar produto (MVPs) para o cliente | Product Owner | Commit no Github | GitHub |
| Papel | Atribuições | Responsável | Participantes |
|---|---|---|---|
| Desenvolvedor Front-End | Codificar o produto, codificar testes unitários, realizar refatoração | Taynara/Luís | Leonardo, Luis, Marcos, Pedro, Taynara |
| Desenvolvedor Back-End | Codificar funcionalidades e fluxo de controle da aplicação | Marcos | Leonardo, Luis, Marcos, Pedro, Taynara |
| Líder/Coordenador da equipe de desenvolvimento | Atualizar o escopo do produto, organizar o escopo das sprints, validar as entregas | Leonardo | Leonardo, Luis, Marcos, Pedro, Taynara |
| Testador de Software | Detectar erros, falhas, bugs e outros tipos de problemas. | Pedro | Leonardo, Luis, Marcos, Pedro, Taynara |
Planejamento das Fases e/ou Iterações do Projeto
Versão inicial:
| Sprint | Produto (Entrega) | Data Início | Data Fim |
|---|---|---|---|
| Sprint 1 | Definição do Produto | 18/01/22 | 03/02/22 |
| Sprint 2 | MVP e Planejamento do Projeto | 08/02/22 | 24/02/22 |
| Sprint 3 | Protótipo de Tela , Ajustar Ambiente de Desenvolvimento | 28/02/22 | 06/03/22 |
| Sprint 4 | Cadastrar um Evento(US-08), Editar Evento(US-09) e Remover Evento(US-10) | 07/03/22 | 13/03/22 |
| Sprint 5 | Enviar notificações de Eventos, Escolher tipo Aula ou apenas Evento, Adicionar aula por código ou horário | 14/03/22 | 20/03/22 |
| Sprint 6 | Cadastrar uma Meta(US-04), Editar Metas(US-05), Cadastrar uma TO-DO list em uma Meta | 21/03/22 | 27/03/22 |
| Sprint 7 | Remover uma Meta(US-07), Criar uma TO-DO list(US-12) | 28/03/22 | 03/04/22 |
| Sprint 8 | Cadastrar tarefa na TO-DO list, Editar tarefa na TO-DO list | 04/04/22 | 10/04/22 |
| Sprint 9 | Excluir uma lista de tarefas (TO-DO lists), Calcular porcentagem das tarefas que já realizadas | 11/04/22 | 17/04/22 |
| Sprint 10 | Cadastrar uma nova conta na plataforma(US-01), Realizar login na plataforma(US-02), Realizar logout(US-03) | 18/04/22 | 27/04/22 |
Devido ao atraso no planejamento original, tivemos de replanejar o nosso trabalho, dessa vez, em nove semanas, Percebemos que, devido ao fato de TO-DO List ser um atributo de Meta e evento a mesma deve ser produzida primeiro e, por isso, interrompemos a programação da parte dos eventos para, primeiro, configurar corretamente o funcionamento das TO-DO Lists. Além disso, houve um atraso devido à inexperiência dos envolvidos com a tecnologia Django.
versão 2.0:
| Sprint | Produto (Entrega) | Data Início | Data Fim |
|---|---|---|---|
| Sprint 1 | Definição do Produto | 18/01/22 | 03/02/22 |
| Sprint 2 | MVP e Planejamento do Projeto | 08/02/22 | 24/02/22 |
| Sprint 3 | Protótipo de Tela , Ajustar Ambiente de Desenvolvimento | 28/02/22 | 06/03/22 |
| Sprint 4 | Criar TO-DO List (US-14), Editar TO-DO List (US-15) e excluir TO-DO List (US-16) | 07/03/22 | 20/03/22 |
| Sprint 5 | Cadastrar meta (US-04), editar meta (US-05), excluir meta (US-07) e marcar meta como completa (US-06) | 21/03/22 | 27/03/22 |
| Sprint 6 | Cadastrar usuário na plataforma (US-01), editar meta (US-05), excluir meta (US-07) e marcar meta como completa (US-06) | 28/03/22 | 03/04/22 |
| Sprint 7 | Realizar login na plataforma (US-02), Realizar Logout na plataforma (US-03) | 04/04/22 | 10/04/22 |
| Sprint 8 | Escolher tipo aula ou evento (US-12), adicionar aula por código/horário (US-13) | 11/04/22 | 17/04/22 |
| Sprint 9 | Calcular porcentagem da TO-DO List (US-17) | 18/04/22 | 27/04/22 |
| Descrição | Área/Envolvidos | Periodicidade | Produtos Gerados |
|---|---|---|---|
| Reunião diária para alinhamento da equipe e para levantar dúvidas e avançar com a sprint | Equipe do Projeto | Diário | Não serão gerados produtos. |
| Reunião semanal para acompanhamento da sprint | Equipe do Projeto | Semanal | Funcionalidades da aplicação |
| Apresentação do progresso da equipe | Equipe | Professor | Ao fim de cada Módulo |
- Não conseguir entregar o Backlog da sprint
- Buscar justificativas do responsável pelas partes não entregues e fornecer a ele o apoio necessário para que consiga realizar suas obrigações na próxima sprint.
- Membro da equipe trancar a matéria
- Comunicação constante entre os membros da equipe para que os outros membros sejam informados com antecedência
- Baixa Produtividade em semana de prova
- Aumentar a produtividade na semana anterior
O produto será replanejado caso entenda-se que o escopo está inadequado, isto é, grande ou pequeno demais para o tempo da matéria e tamanho da equipe. Assim, o replanejamento pode ocorrer caso um aluno saia da matéria, caso as sprints finalizem, com uma frequência alta, incompletas ou caso o produto esteja pronto antes do prazo esperado.
O Padrão de Projeto adotado em Phyton se divide em 3 finalidades:
- Padrão criacional: Builder que permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
- Padrão estrutural: Adapter permite que classes com interfaces incompatíveis trabalhem juntas.
- Padrão comportamental: Interador permite que você percorra elementos de uma coleção sem expor as representações estruturais deles.
A arquitetura a ser utilizada é a MVT (Model View Template) e é dividida em três partes:
- Template: É a parte da arquitetura que define como serão apresentados os dados ao usuário. Geralmente é aqui que se encontra o HTML a ser apresentado pelo projeto e, de acordo com a arquitetura, essa parte do projeto se comunica diretamente com o View
- View: Essa é a parte do projeto que define Quais dados serão apresentados ao usuário, mandando os dados requisitados, por meio de formulários, para o Template. Basicamente, o View é o intermediário entre o Model e o Template.
- Model: Essa é a parte da arquitetura que se comunica diretamente com o Banco de dados. Aqui serão descritas as características dos dados, como eles serão armazenados.
O MVT é baseado na arquitetura conhecida como MVC mas, aqui, O Controller é a arquitetura do Django em si.
Tela de cadastro - US 01, 02:
Tela de login - US 01, 02:
Página principal - US 03, 04, 08:
Página para o usuário selecionar se deseja criar meta ou evento - US 04, 07, 08:
Página para criar evento - US 08, 09, 10, 12, 14:
Página para criar meta - US 04, 05, 07, 12, 14:
- Agenda:
- US-04: Cadastrar uma Meta;
- US-05: Editar Metas;
- US-06: Marcar meta como completa;
- US-07: Remover uma Meta;
- US-12: Criar uma TO-DO list;
- US-13: Editar uma TO-DO list;
- US-14: Excluir uma lista de tarefas (TO-DO lists);
- Organização:
- O projeto iniciou e foram definidas 2 duplas, sendo uma delas para o back-end (Leonardo e Luís) e a outra para o front-end (Taynara e Pedro), restando então 1 integrate da equipe, Marcos, o qual apoiaria o a 2ª dupla. O critério de formação das duplas foi quem tinha maior afinidade com as tecnologias utilizadas, visando aumentar a produtividade.
- A dupla do back-end, realizou pair paring aos sábados e domingos durante 2h para realização da sprint da semana, sendo o Leonardo o piloto e Luís o co-piloto, invertendo os papéis a cada fim de semana. Foi introduzido a refatoração do código, para deixa-lo mais facil de entender e melhor de achar eventuais bugs.
- A dupla de front-end (Taynara e Pedro) não realizou o Pair Pairing, decidiu dividir as atividades em tarefas individuais diárias, tirando a duvida de qualquer eventual dificuldades nas reuniões.
As principais lições aprendidas pela equipe Gama foram: organização e pré-concepção de um projeto de software, diferença entre abordagens ágeis e dirigidas a plano, disciplinas de Engenharia de Software, Framework Scrum. As ações a serem tomadas para melhorar são: o ambiente de desenvolvimento, execução das reuniões diárias, definição dos requisitos, criação de protótipos de telas para basear a codificação do site da aplicação e nivelamento dos conhecimentos da equipe.
As principais lições aprendidas pela equipe Gama foram: entender o que são os requisitos de um software, identificar e abstrair os requisitos funcionais e não-funcionais do produto, refinar os requisitos funcionais para deixá-los no mesmo nível de granulação, criação do product backlog da aplicação, organizar o backlog conforme a estrutura do SAFE.
As ações a serem tomadas para melhorar são: diminuição do tempo de duração das reuniões, melhoramento na distribuição de tarefas, criação de protótipos de telas para basear a codificação do site da aplicação, nivelamento dos conhecimentos da equipe, desenvolvimento do frontend e backend, acompanhamento do desenvolvimento das issues e realização das sprints semanais conforme cronograma.
As principais funções aprendidas nessa unidade foram: Como planejar melhor, e de maneira lógica, as etapas de de nosso produto, como funciona a arquitetura do Django e como reunir a equipe de maneira mais eficiente, delegando tarefas mais adequadamente.
Ponto à melhorar para a próxima unidade: Fazer com que todos os membros da equipe estejam presentes nas apresentações ao professor e aulas, dividir melhor as issues e acelerar o ritmo produtivo da equipe
SOMMERVILE, I. Processos de software. In: SOMMERVILLE, I. Engenharia de software. 9. ed. rev. São Paulo: Pearson, 2011.