Termo de Abertura (TAP)
Índice
1. Introdução
Este documento tem com principal objetivo evidenciar aspectos importantes do projeto CarDefense, um app de monitoramento de carros. Aqui serão expostos os custos, riscos, cronograma e outros.
2. Descrição do Projeto
Como dito anteriormente, CarDefense é um aplicativo comunitário voltado para o monitoramento de carros sendo esse em tempo real, tendo como local piloto a UnB campus Gama (FGA).
3. Justificativa
O monitoramento de carros atual do campus UnB Gama varia de muito pouco a quase nenhum. Os carros estacionados passam um longo período de tempo parados sendo fiscalizados apenas por câmeras e poucos seguranças que precisam fazer a rota de todo o campus. Em caso de ocorrências, não existe um meio de comunicação direta com o proprietário do veículo para que haja um aviso. O aplicativo CarDefense visa criar esse canal de comunicação direta, ou seja, uma vez cadastrada o proprietário e a placa do seu veículo qualquer pessoa pode fazer esse aviso por meio de notificações que chegarão em tempo real ao smartphone.
4. Objetivo do Projeto
O objetivo do aplicativo é proporcionar um meio de monitoramento de carros mais eficiente e fácil para que assim o usuário possa tomar decisões de forma rápida, tendo como cenário inicial auxiliar a comunidade acadêmica do campus Gama da UnB.
5. Restrições
Para a utilização do aplicativo, é necessário:
- Ter acesso à internet.
6. Requisitos de Alto Nível
CarDefense será desenvolvido como uma plataforma mobile. Tendo os seguintes requisitos de alto nível:
- O aplicativo deve possuir um uso fácil para o usuário.
- Deve possuir o requisito não funcional de confidencialidade e armazenar as informações de modo seguro.
- Deve possuir um sistema de notificações que identifica diversos cenários já prontas e de fácil escolha para o usuário.
7. Riscos
| Riscos | Impactos | Ação Preventiva | Ação Reativa |
|---|---|---|---|
| Inexperiência da equipe de desenvolvimento | Pode acarretar em atraso na entrega do produto | Realização de treinamento sobre as tecnologias e metodologias necessárias para a realização do projeto. | Promover um pareamento visando o nivelamento da experiência da equipe |
| Inadaptação da equipe de desenvolvimento às tecnologias utilizadas | Não haverá entrega do produto final. | A realização de treinamento de tecnologias e solução de dúvidas entre a própria equipe. | Procurar a troca das tecnologias utilizadas (em ultimo caso!) |
| Inexperiência do scrum master | Pode proporcinar uma má gerência de metodolgia e má gerência de risco. | Este papel deve orientar-se pelo seu roadmap, pela tabela de valores ágil e estar em constante comunicação com a equipe visando solucionar qualquer problema ou risco. | Caso a medida preventiva não funcione este papel deve procurar um scrum master mais experiente visando sanar as dúvidas e/ou os problemas |
| Inexperiência do product owner | Pode acarretar em uma má visão de projeto pela equipe. | Este papel deve orientar-se por seu roadmap, pela elicitação de requisitos e constante comunicação com a equipe procurando sempre elucidar as dúvidas sobre o projeto final. | Caso a medida preventiva não funcione este papel deve procurar um engenheiro de produto mais experiente visando sanar as dúvidas e/ou os problemas |
| Inexeperiência do Arquiteto | Pode acarretar em uma má gestão de serviços utilizados no projeto | Este papel deve orienta-rse pelo seu roadmap, estudar sobre a arquitetura de microserviços, procurar entender as necessidades do projeto e as adequar à arquitetura utilizada. | Caso a medida preventiva não funcione este papel deve procurar um arquiteto de software mais experiente visando sanar as dúvidas e/ou os problemas |
| Inexperiência do DeVops | Pode acarretar em problemas/atrasos na entrega contínua do projeto, assim, afetando o princípio ágil de entregas constantes | Este papel deve sempre orientar-se pelo seu roadmap, estudar sobre DevOps e suas ferramentas envolvidas além de verificar, sempre, se a arquitetura em desenvolvimento se adequa ao processo ou não | Caso a medida preventiva não funcione este papel deve procurar um DevOps mais experiênte visando sanar as dúvidas e/ou os problemas |
| Evasão de algum membro da equipe de desenvolvimento | Atraso da entrega do projeto final por causa da sobrecarga de tarefas aos membros restantes da equipe | Quebrar as tarefas mais complexas em tarefas menores evitando a sobrecarga de esforço por tarefa além de gerir tais tarefas visando tal problema constantemente. Além de procurar motivar a equipe e mante-la em constante sintonia | Caso essa evasão ocorra durante uma sprint o serviço assinado por este membro deve ser dividido entre os membros restantes da equipe visando a menor sobrecarga de esforço possível |
| Evasão do arquiteto ou do DevOps | Pode acarretar em problemas relacionados a comunicação dos serviços (no caso do arquiteto) ou na entrega contínua do projeto (no caso do devops). | Procurar manter não só o arquiteto ou o DevOps motivados mas também toda a equipe. | Como são dois papéis que durante a execução do projeto
caminham
juntos caso um dos dois seja evadido do projeto pode
ocorrer
uma das duas alternativas a seguir:
O devops passa a ser responsável também pela arquiteturaou O arquiteto passa a ser responsável também pelas tarefas do devops |
| Evasão do scrum master ou do engenheiro de produto | Pode acarretar em problemas relacionados a visão de produto (no caso do engenheiro de produto) ou problemas relacionados a metodologia e riscos (no caso do scrum master) | Procurar manter não só o scrum master ou o Engenheiro de Produto motivados mas também toda a equipe | Como são dois papéis que durante a execução do projeto
caminham
juntos caso um dos dois seja evadido do projeto pode
ocorrer
uma das duas alternativas a seguir:
O scrum master passa a ser responsável também pela engenharia de produtoou O engenheiro de produto passa a ser responsável também pelas tarefas do scrum master |
| União do serviço 'CarDefense' ao App geral da FGA | Pode acarretar uma não entrega do serviço no app final | Deve ocorrer uma comunicação constante tanto da parte do devops quanto da parte da arquitetura com tais partes dos outros serviços envolvidos em tal app. Esta comunicação deve sempre visar os melhores padrões para que os serviços se relacionem entre si | Caso a medida preventiva não funcione o aplicativo 'CarDefense' deverá ser entregue separadamente do projeto do App Geral da FGA (somente em último caso!) |
| Problemas relacionados a infraestrutura necessária ao projeto | Pode acarretar no atraso ou na não entrega do projeto final além de afetar a gerência do mesmo | Procurar sempre desenvolver ou se reunir em um local com a infraestrutura básica para a execução do projeto | Caso a medida preventiva não funcione não será possível produzir o projeto |
| Risco de greve | Pode acarretar em um grave atraso na produção do projeto | Gerir o backlog de sprints e a produção do projeto visando a inexistência ou a minima quantidade de dívidas técnicas para a próxima sprint | Caso a medida preventiva não funcione é importante que todo o backlogo seja reformulado visando e diminuição do escopo para que seja possível entregar o projeto na data correta. (Caso não haja possibilidade de troca de adiamento da data de entrega) |
| Escopo mal definido | Acarreta na entrega de um projeto que não satisfaz ao cliente/usuário | Visar construir o projeto/produto possuindo uma comunicação constante com o cliente/usuário procurando entender e documentar as suas necessidades | Caso a medida preventiva não funcione a equipe deverá rever todo o processo de elicitação e produzir um novo backlog de projeto |
| Falta de Comprometimento | Pode acarretar em dívidas técnicas de uma sprint para outra acarretando em atrasos na produção do projeto (no caso da equipe de desenvolvimento) como também pode acarretar em desfalques na arquitetura, na visão de projeto, no devops ou na metodologia | Procurar a motivação entre os membros da equipe, manter a comunicação constante, procurar trazer todos os problemas 'a tona' antes que possam piorar | Motivar a equipe ou o membro que está descomprometido e caso isso não funcione em último caso promover a demissão do membro da equipe |
| Dependência de atividades | Pode acarretar em um atraso grave na entrega do projeto | Procurar priorizar o backlog de projeto visando tanto a urgência de implementação da feature quanto as dependências entre elas | Caso a medida preventiva não funcione procurar colocar ambas atividades em uma mesma sprint promovendo a união entre dois pares responsáveis pela entrega de ambas tarefas |
| Falta de comunicação | Pode acarretar na falta de relatos de problemas ou dúvidas causando, também, atraso da entrega do projeto | Possuir um plano de comunicação concreto visando comunicação rápida e constante e de fácil acesso por todos os membros da equipe | Caso a medida preventiva não funcione deve haver um novo planejamento da comunicação da equipe do projeto |
| Mal planejamento das sprints | Pode acarretar em um atraso grave na entrega do projeto | Procurar montar o backlog das sprints utilizando a priorização do backlog geral e a pontuação médida gerada pelo velocity | Caso a medida preventiva não funcione é necessário que seja revista a maneira como a sprint está sendo planejada procurando encontrar e solucionar os defeitos e falhas de tal planejamento. |
| Atrasar entregas | Pode acarretar na não entrega do projeto ou em uma entrega incompleta do mesmo | Procurar gerenciar corretamente o backlog das sprints visando a inexistencia ou quantidade mínima de dívidas técnicas para a proxima sprint | Caso a medida preventiva não funcione a sprint que vier logo após ao atraso deve ser formulada visando a entrega das atividades em atraso como também atividades que exijam menos pontuação tentando adequaro o atraso ao cronograma de entregas |
| Perda de equipamento | Pode acarretar em atrasos no projeto | Manter todo o equipamento bem guardado além de sempre possuir backup de todo o projeto tanto na nuvem quanto em equipamentos pessoais da equipe | Caso a medida preventiva não funcione o membro que foi afetado pela perda de equipamento deve parear com os outros membros da equipe até que sua situação seja resolvida |
8. Cronograma e Entregas
O projeto possui duas grandes entregas, sendo essas as Releases.
| Descrição | Data |
|---|---|
| Release 1 | 02 de outubro de 2018 |
| Release 2 | 27 de novembro de 2018 |
9. Custo Estimado
Aqui será abordado o custo estimado de mercado para um 1 mês de trabalho da equipe.
9.1 Custo de Pessoal
| Função | Quantidade | Horas de Trabalho | Valor Mensal | Valor Total |
|---|---|---|---|---|
| Equipe Full Stack | 4 | 10h | R$ 6.000 | R$ 24.000 |
| Equipe de Desenvolvimento | 6 | 10h | R$ 3.000 | R$ 18.000 |
9.2 Custo de Aquisição
| Equipamento/Serviço | Quantidade | Motivo | Valor | Valor Total |
|---|---|---|---|---|
| Notebook | 10 | Desenvolvimento | R$ 2.220 (média) | R$ 22.200 |
| Transporte | Média de 2 ou 4 linhas ônibus (10 membros) | Transporte da equipe para o efetuar o desenvolvimento | R$ 5.00 x 4 = R$ 20 (uma pessoa por dia) | R$ 4.000 |
| Espaço para Trabalho - Coworking | 5 dias por semana | Desenvolvimento | R$ 160 (média por semana) | R$ 1.600 por mês |
Observações:
9.3 Ferramentas
Para sabe a finalidade ou descrição, acesse a página de Ferramentas.
| Ferramentas | Custo |
|---|---|
| GitHub | R$ 0 |
| GoogleDrive | R$ 0 |
| Visual Studio Code | R$ 0 |
| Telegram | R$ 0 |
| Ubuntu | R$ 0 |
| Draw.io | R$ 0 |
9.4 Custo Total Estimado
| Recurso | Valor |
|---|---|
| Custo de Pessoal | R$ 42.000 (por mês) |
| Custo de Aquisição | R$ 272.400 (por mês, sem contar valor dos notebook que são fixos) |
| Ferramentas | R$ 0 |
| Valor por 4 meses (tempo da disciplina) + 15% dos Riscos | R$ 244.490 |
10. Stakeholders
| Nome | Papel | GitHub | |
|---|---|---|---|
| Lucas Souza | Gerência - Scrum Master | lucas.soaresouza@gmail.com | @lucassoaresouza |
| Taynara Carvalho | Gerência - DevOps | tayhcarvalho@gmail.com | @tayh |
| Stéfane Souza | Gerência - PO/Engenheira do Produto | stefanesouza04@gmail.com | @stefanesouza |
| Mateus Vieira | Gerência - Arquiteto | mateusvroriz6b@gmail.com | @mateusvroriz |
| João Gabriel Rossi | Desenvolvedor | bielrossiborba@gmail.com | @bielrossi15 |
| João Gabriel Antunes | Desenvolvedor | jg.antunes.medeiros@gmail.com | @flyerjohn |
| Paulo Vítor Coelho | Desenvolvedor | paulovitorrocha.unb@gmail.com | @PauloVitorRocha |
| Ivan Diniz | Desenvolvedor | ivandinizdobbin2@gmail.com | @darmsDD |
| João Matheus | Desenvolvedor | joaomatheus.152013@gmail.com | @rjoao |
| Lieverton Santos | Desenvolvedor | lievertom@gmail.com | @lievertom |
| Carla Rocha | Orientadora | rocha.carla@gmail.com | @RochaCarla |