Viabilidade Técnica
Metodologia e Definições
Metodologia adotada no projeto
Foi adotado como base o framework scrum onde empregamos processos e técnicas aos papéis, eventos, artefatos e regras, adaptando às necessidades da equipe.O objetivo do Scrum no projeto é permitir o controle do trabalho a ser realizado por meio de uma gestão dinâmica, assim identificar obstáculos durante o processo de desenvolvimento e reagir a eles. A abordagem iterativa e incremental empregada otimiza a previsão e monitoramento de riscos.
Também adotamos o uso do Kanban para controle do fluxo de produção da equipe, para a otimização do mesmo foi utilizado a ferramenta ZenHub nos repositórios do projeto.
O XP foi uma das metodologias adotadas pelo conjunto de práticas que são ditas como boas na engenharia de software como pareamento, refatorar o tempo todo, testar o tempo todo, entre outros.
Representante dos papéis
- Product Owner: João Egewarth- Scrum Master: Isaque Alves
- DevOps: Eliseu Egewarth
- Arquitetura: Gabriela Alves
- Desenvolvedores: Beatriz Hanae, Ezequiel De Oliveira, Felipe Campos, Gabriela Guedes, Guilherme Deusdará, Vitor Leal.
Scrum Master
- Responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras;- Ajuda o Time Scrum e a organização a adotarem o Scrum;
- Educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade;
- Ajuda o Time Scrum a ser auto-organizável;
- Resolver impedimentos;
- Buscar produtividade máxima do time por meio de treinamentos, análise dos risco, qualidade da produção e valor agregado;
- Estar à frente da gestão de riscos e EVM;
- Documentar as sprints;
- Preparar as reuniões e conduzir-las;
Product Owner
- Responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time;- Manter o Backlog do Produto e garante que ele está visível para todos;
- Informar a todos quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar;
- Definir e priorizar os itens do Backlog do Produto;
- Vender o produto;
- Intermediário entre o cliente e a equipe;
- Valor de negocio;
- Visão de negócio;
- Negociar com o time e com o cliente;
- Canvas.
DevOps
- Garantir que todas as alterações de código e configurações sejam feitas usando mecânismos automatizados e rastreáveis;- Automatizar a Infraestrutura;
- Automatizar e garantir a integração contínua;
- Facilitar o processo de desenvolvimento;
- Organizar os pipeline do produto;
- Pipeline de desenvolvimento;
- Ambiente de desenvolvimento;
- Ambiente de testes;
- Ambiente de homologação;
- - Gerar `.apk` e `.ipa`
- pipeline completo de deploy;
- Analizar viabilidade de publicação de aplicativo nas lojas (PlayStore, AppStore);
- Especificar que o deploy será feito a partir das tags do repositório, não da branch master;
- Integração contínua;
Software Architect
- Planejamento e desenvolvimento da arquitetura que melhor atende a necessidade do projeto;- Tomar decisões sobre ferramentas e métodos de desenvolvimento;
- Liderar o desenvolvimento do sistema, estando um passo a frente na visão do mesmo;
- Lidar com a aplicação e o seu fluxo de dados.
Developers
- Transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint;- Os conhecimentos que os membros do Time devem compartilhar é a habilidade de pegar um requisito e transformá-lo em um produto utilizável;
- Todos contribuem, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas;
- Ninguém - nem mesmo o ScrumMaster - diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis;
- Cada membro do Time aplica seu conhecimento a todos os problemas.
Ritos Adotados
Os ritos adotados para a sprint, estão definidosMétricas e Indicadores
As métricas e indicadores do projeto auxiliaram no controle das atividades e evolução do time, elas podem ser encontradasDefinição de Pronto
História de Usuário
Uma história estará finalizada quando a funcionalidade for implementada, testada, e validada junto ao PO, além de manter ou aumentar a cobertura dos testes.Feature
Uma feature é considerada finalizada quando todas as histórias derivadas estão todas implementadas com a cobertura de testes aumentada ou mantida.Sprint
Uma sprint conclui após 7 dias de trabalho. Caso as histórias não forem finalizadas e mescladas na branch master devem ser alocadas para a próxima Sprint como dévida técnico. Os riscos identificados devido as dificuldades enfrentadas são mapeados na documentação da sprint.Artefato
Um artefato é considerado pronto quando for finalizado e feito o pull request com as validações presentes no guia de contribuição.Comunicação
Telegram
Comunicação interna da equipe e com os colaboradores externos ao projeto.
GitHub
O GitHub é essencial na transparência interna da equipe e externa junto ao cliente, a orientadora do projeto (Carla Rocha) e a comunidade em geral. Foi feito um uso extensivo das issues para comunicação entre os membros da equipe, para dúvidas sobre a issue e para mostrar o andamento do projeto.
Pontuação das histórias e tarefas
A pontuação foi baseada no esforço necessário para concluir as tarefas.Pontuação |
Duração |
Risco |
Máximo |
| 0 | 30 minutos | 30 minutos | 1 hora |
| 1 | 2 hora | 1 hora | 3 horas |
| 2 | 3 horas | 1 hora | 4 horas |
| 3 | 4 horas | 2 horas | 6 horas |
| 5 | 8 horas | 2 horas | 10 horas |
| 8 | 12 horas | 4 horas | 16 horas |
| 13 | 20 horas | 6 horas | 26 horas |
| 21 | 30 horas | 10 horas | 40 horas |
Tarefas com pontuação igual ou superior a 8 devem ser quebradas em uma ou mais tarefas.
Pontuação dos Riscos
Para pontuar os riscos haverá a combinação de Impácto e Probabilidade que auxiliam na priorização do risco de acordo com sua significância.Impácto
| Escala | Descrição |
| 1 | Irrelevante |
| 2 | Baixo |
| 3 | Moderado |
| 4 | Alto |
| 5 | Extremo |
Probabilidade
| Escala | Descrição |
| 0 | Nenhum |
| 1 | Raro |
| 2 | Improvável |
| 3 | Pouco Provável |
| 4 | Muito provável |
| 5 | Quase Certo |