Visão Geral do Projeto
O time irá utilizar uma mistura do método RAD com a estrutura e organização do time Scrum.
Papéis do projeto e suas atribuições
| Papel |
Atribuições |
Responsável |
Participantes |
| Time de desenvolvimento |
Codificar o produto, codificar testes unitários, realizar refatoração e realizar a atividade de representação, e de organização e atualização de requisitos. |
Luis |
Arthur, Daniel, Guilherme, Luis, Vinicius, Yves |
| Dono do Produto |
Atualizar o escopo do produto, organizar o escopo das sprints, validar as entregas, realizando as seguintes atividades de requisitos: elicitação e descoberta, e de declaração dos requisitos. |
Yves |
Angela, Yves |
| Scrum Master |
Gerenciar o time, no que diz respeito aos rituais presentes no framework, tais como planejamento do backlog da sprint, retrospectiva, review, além de realizar as seguintes atividades de requisitos: Análise e consenso, e verificação e validação dos requisitos. |
Guilherme |
Arthur, Daniel, Guilherme, Luis, Vinicius, Yves |
| Cliente |
Dar feedback quanto ao protótipo e avaliação do produto. |
Angela |
Angela |
Atividades das Sprints
| Iteração |
Produto (Entrega) |
Data Início |
Data Fim |
| Sprint 1 |
Definição do problema e possível solução |
05/09/2023 |
18/09/2023 |
| Sprint 2 |
Definição de abordagem, ciclo de Vida, e processo |
19/09/2023 |
02/10/2023 |
| Sprint 3 |
Definição do Processo de Engenharia de Requisitos, atrelado ao Processo de Software |
03/10/2023 |
09/10/2023 |
| Sprint 4 |
Proposta de solução e feedback do cliente, além da lista inicial de requisitos |
10/10/2023 |
23/10/2023 |
| Sprint 5 |
Definição dos MVPs do projeto |
24/10/2023 |
06/11/2023 |
| Sprint 6 |
Desenvolvimento do primeiro MVP |
07/11/2023 |
20/11/2023 |
| Sprint 7 |
Desenvolvimento do segundo MVP |
21/11/2023 |
04/12/2023 |
| Sprint 8 |
Revisão do projeto, integração do sistema e finalização |
05/12/2023 |
13/12/2023 |
Matriz de Comunicação
| Descrição |
Papéis Envolvidos |
Periodicidade |
Produtos Gerados |
| Definição dos próximos objetivos, Sprint Backlog e acompanhamento do progresso do produto |
Time de Desenvolvimento |
Quinzenal |
Relatório de situação de projeto |
| Acompanhamento dos riscos, compromissos e ações pendentes |
Time de Desenvolvimento |
Quinzenal |
Relatório de riscos e pendências |
| Comunicação assíncrona entre membros via WhatsApp e Discord |
Time de Desenvolvimento |
Conforme necessidade |
N/A |
| Reunião com cliente para validação via WhatsApp e entrega de protótipo via e-mail e via WhatsApp |
Dono do Produto e Cliente |
Quinzenal |
Relatório de Feedbacks |
Gerenciamento de Riscos
| Risco |
Nível de Impacto |
Prevenção de Risco |
Gerenciamento de Risco |
| Trancamento da matéria por algum membro da equipe |
ALTO |
Manter comunicação constante entre os membros, buscando identificar dificuldades individuais. |
Redistribuir as atividades do antigo membro, para que nenhuma atividade permaneça incompleta. |
| Não entrega do Backlog Da Sprint |
ALTO |
Realizar o bom planejamento das histórias de usuário que serão trabalhadas na Sprint. Caso algum membro já tenha finalizado sua tarefa, o mesmo deve ser direcionado pelo Scrum Master, a auxiliar nas tarefas de outro membro determinado. |
Redistribuir as Histórias de Usuário não entregues para a próxima Sprint, de forma que não atrapalhe o desenvolvimento desta Sprint seguinte. |
| Produtividade insuficiente em semana de prova |
MÉDIO |
O planejamento das Sprints deve considerar as responsabilidades pessoais de cada membro. O trabalho das tarefas de cada membro deve ser planejado, tendo em mente as data das provas. |
As atividades do membro daquela semana serão reduzidos, mas o trabalho deve ser compensado após o término das provas. |
| Não participar das reuniões |
BAIXO |
As reuniões devem ser realizadas em datas e horários fixos, caso algum imprevisto ocorra, o membro deve avisar a equipe. |
Caso um membro não possa participar, a reunião deve ser gravada. Dessa forma, o membro faltante pode acompanhar as atividades da equipe. |
Os riscos foram avaliados de acordo com seu nível de impacto:
| Risco |
Nível de Impacto |
| ALTO |
Influência significativa no projeto, exigirão atenção imediata e um grande esforço do time para obter uma solução rápida. |
| MÉDIO |
Influência moderada no projeto, exigirão um maior esforço da equipe em sua contenção, mas ainda podem ser gerenciados. |
| BAIXO |
Influência pequena no projeto, podendo ser facilmente resolvidos ou contornados. |
Critérios de Replanejamento
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.
O projeto poderá ser replanejado caso haja:
- Abandono de membros da equipe
- Constante ausência de determinados membros da equipe
- Dificuldade de uso das ferramentas de desenvolvimento predefinidas
A seguir uma tabela mostrando quando exatamente ocorre e o passo a passo do que fazer:
| Critério de Replanejamento |
Quando Ocorre |
Passo a Passo |
| Abandono de membros da equipe |
Um ou mais membros trancam a matéria. |
1. Avisar ao professor imediatamente. |
| 2. Replanejar as Sprints em relação às entregas. |
| 3. Redistribuir tarefas. |
| Constante ausência de determinado membro da equipe |
Um ou mais membros deixam de participar das discussões, ir às aulas e impossibilitam contato não respondendo a mensagens privadas. |
1. Avisar ao professor imediatamente. |
| 2. Replanejar as Sprints em relação às entregas. |
| 3. Redistribuir tarefas. |
| Dificuldade de uso das ferramentas de desenvolvimento definidas |
Um ou mais membros não conseguem avançar na evolução das Histórias de Usuário, por conta da dificuldade no uso de alguma ferramenta específica. |
1. O membro deve buscar ajuda ao resto da equipe. |
| 2. Se o impacto for muito grande, as tarefas da Sprint devem ser redistribuídas. |
Padrões de codificação
Os padrões a serem seguidos serão algumas convenções já utilizadas nas tecnologias e linguagens de programação definidas pela equipe (clique no item para ver a fonte):
HTML :
- Atributos entre aspas duplas
- Lowercase (tudo minúsculo) para nomes de elementos e atributos.
- Nomes de classes/ID com múltiplas palavras em kebab-case (separação por hífen).
Exemplo: <img src="images/image.png" alt="exemplo-SS-em-requisitos" class="exemplo-kebab-case">
CSS :
- Comentários para explicar o que/onde está sendo aplicada a estilização, em português.
- Aspas duplas para valores (semelhante ao definido para HTML).
- Separar propriedades por linha ao invés de juntá-las em uma linha só.
Exemplo:
/* Formato dos comentários */
background-image: url("../valores/entre-aspas-duplas.png");
/* Fonte sans-serif em negrito tamanho 18 */
h2 {
font-weight: bold;
font-size: 18pt;
font-family: sans-serif;
}
JavaScript :
- Comentários single line, explicativos e em português para partes não-óbvias do código (funções cujos nomes não são significativos, funções complicadas e/ou grandes).
- Nomear funções em camelCase de forma descritiva.
- Definir Classes em PascalCase (camelCase porém com a primeira letra maiúscula) e Objetos em camelCase.
Exemplo:
// Comentário single line descritivo:
// Retorna status code 200:
function status(request, response) {
response.status(200).send({ requisitos: "SS Pentágono Cabeludo" });
}
// Nome em camelCase:
function agendaHorario() {
console.log("Horario agendado!");
}
// Classes e objetos:
const pentagonoCabeludo = new Equipe(5, "Requisitos", "SS");
const pentagonoCabeludo = {
membros: 5,
disciplina: "Requisitos",
mencao: "SS",
};
Histórico de Revisão
| Data |
Versão |
Descrição |
Autor |
| 27/09/2023 |
1.0 |
Definição da organização, planejamento das sprints, matriz de comunicação, gerenciamento de riscos e critérios de replanejamento do projeto. |
Todos |
| 22/10/2023 |
1.1 |
Alteração na parte do Gerenciamento de Riscos e Critérios de Replanejamento. |
Guilherme de Sá |
| 26/10/2023 |
1.2 |
Revisão e alteração na data das sprints finais de acordo com o calendário da disciplina. |
Vinícius |
| 06/11/2023 |
1.3 |
Adicionado novo membro da equipe nos planejamentos. |
Vinícius |
| 06/11/2023 |
1.4 |
Revisão da matriz de comunicação e ajustes na estrutura de documento. |
Yves |
| 20/11/2023 |
1.5 |
Definição de padrões de codificação para atender à Definition of Done. |
Vinicius |