Visando o controle da produção de um produto bem especificado e com níveis seguros de qualidade o projeto CarDefense adota uma adaptação da metodologia ágil Scrum.
A adaptação foi realizada não porque o Scrum em si não possa suprir todas as necessidades do projeto mais sim porque o projeto será desenvolvido em um contexto acadêmico onde alguns fatores externos impedem a aplicação total da metodologia.
A seguir estão listadas os aspectos do Scrum que serão seguidos pela equipe:

• - Desenvolvimento divido em ciclos
• - Revisão de Sprints
• - Retrospectiva de Sprints
• - Planejamentos de Sprints
• - Encontros Diários (adaptado)
• - Backlog de Produto e Backlog de Projeto

A equipe de projeto, visando alcançar todos os pontos de produção de um sistema, é dividida em papeis bem definidos. Estes papéis são:

Arquiteto de Software

É o papel responsável em desenhar e manter a arquitetura do sistema de acordo com os requisitos do próprio.
Tem como principais funções:

- Definir e validar documento de Arquitetura
- Definir Tecnologias e ferramentas a serem usadas no desenvolvimento do projeto
- Propor modelo de arquitetura a ser seguido no projeto
- Construir integração entre microsserviços
- Aplicar o fluxo de gitflow
- Criar Banco de dados e acesso ao mesmo
- Monitoramento contínuo da arquitetura para que o modelo decido seja seguido
- Propor e acompanhar a integração das diversas funcionalidades pelas equipes em um único aplicativo.

DevOps

É o papel que tem como responsabilidade a manutenção das entregas contínuas do projeto de uma maneira clara e rastreável
Tem como principais funções:

- Elaborar política de contribuição
- Elaborar e implementar a integração contínua
- Elaborar e implementar o deploy contínuo
- Padronizar configurações do projeto
- Aplicar o fluxo de gitflow
- Automatização do processo de desenvolvimento
- Monitoramento de desempenho de aplicações
- Gerar .apk da aplicação

Product Owner

É o papel que tem como foco a visão do negócio e do produto final do projeto.
Tem como principais funções:

- Visão de Mercado do Produto
- Criar Canvas do Produto
- Visão de Negócio do Produto
- Levantamento de Requisitos
- Avaliar o que foi entregue de acordo com os critérios de aceitação estabelecidos pelo mesmo
- Elaborar Termo de Abertura, EAP, Roadmap e toda documentação da visão de negócio
- Avaliar os protótipos
- Procurar investidores

Scrum Master

É o papel responsável por fazer com que a metodologia funcione e que a equipe produza.
Tem como principais funções:

- Garantir a máxima produção da equipe
- Afastar as influências negativas
- Inspecionar Artefatos
- Coletar métricas da equipe e do projeto
- Resolver problemas relacionados às relações interpessoais
- Facilitar Reuniões
- Trabalhar Planejamento, Controle e Monitoramento
- Proteger as Práticas Ágil

Desenvolvedor

É o papel responsável por codificar, testar e fazer a manutenção/refatoramento das features do projeto.
Tem como principais funções:

- Garantir que as histórias de usuário sejam efetuadas
- Garantir que as features sejam adequadas aos requisitos solicitados
- Trabalhar em equipe visando sempre o nivelamento de conhecimento
- Produzir as features do sistema seguindo boas as boas práticas de programação
- Codificar sempre em par visando, também, o nivelamento de conhecimento

Engenharia de Produto de Software

Métodos de Desenvolvimento de Software

A metodologia Scrum possui vários rituais vitais para seu total funcionamento. A equipe deste projeto seguira os seguintes rituais:

Sprint Planning

Neste ritual a equipe se reune presencialmente tendo como foco principal a construção do backlog da sprint visando as prioridades do projeto e os objetivos da sprint.
Tal ritual tem o limite de 2 horas para acontecer entretanto por causa do tempo da equipe tal ritual ocorre, neste projeto, nas segundas feiras das 13:00 as 14:00 horas.

Sprint Retrospective

Nesta reunião a equipe também se reune presencialmente tendo como objetivo a Retrospectiva da sprint onde os membros discutem os pontos positivos e negativos da sprint. É importante que todo ponto negativo tenha sempre ao menos uma solução. Um ponto negativo nunca pode deixar de ser resolvido numa sprint retrospective. O tempo máximo desse ritual de é de 15 minutos e, para este projeto, ocorre nas segundas feiras das 12:30 as 12:45.

Sprint Review

Este ritual acontece com a união da equipe logo após o ritual de sprint retrospective. Tem como principal objetivo a análise de todas as tarefas do backlog da sprint validando se elas foram realizadas ou não. Caso uma história seja realizada com sucesso sua issue é fechada do backlog de sprint e caso ela não seja completada a própria fica como dívida técnica para a próxima sprint. Esse ritual também tem o time-box de 15 minutos e, para este projeto, ocorre nas segundas feiras das 12:45 as 13:00 horas.

Daily Meetings

São reuniões feitas sempre em pé e tem como forte característica o fato de ocorrerem rapidamente. O seu principal objetivo são os feedbacks de cada um dos membros da equipe sobre as suas respectivas tarefas. Cada membro relata o que fez, o que vai fazer e os problemas encontrados até o momento. Para esta equipe o daily ficou impossibilitado de acontecer em todos os dias da semana então ocorre nas quintas, terças e sextas feiras da semana. Sendo que nas quintas e terças ocorre das 15:50 as 16:00 horas e na sexta feira das 12:30 as 12:40.

Visando a necessidade do entendimento do que é "pronto" para o nosso projeto foram formalizadas as seguintes definições:

Documentação pronta:

Um documento é considerado pronto dentro da nossa metodologia quando o mesmo foi validado por seus responsáveis e interessados em questão. Vale ressaltar que caso um documento que tenha sido dado como pronto precisar de alguma refatoração ou adição o mesmo pode ser refatorado entretanto necessita, novamente, da validação de seus responsáveis e interessados.

História de Usuário pronta:

Uma história de usuário é considerada pronta somente se possui todos os critérios de aceitação do Product Owner. Entretanto o P.O. tem poder de ter uma história como pronta mesmo não tendo cumprido todos os critérios de aceitação. O P.O. é o maior interessado do projeto por isso espera-se que o próprio tenha o bom senso de fazer tal decisão.

História Técnica pronta:

Uma história técnica é considerado pronta quando a própria cumpriu todos os critérios de aceitação. Entretanto os interessados por tal tarefa tem o poder de decidir, de acordo com o bom senso, se tal história foi realizada com sucesso.

1 PP - Pequenas alterações de código/front - estilização CSS
2 P - CRUD, bugfix em CRUD, documentação pequena
3 M - refatoração de código, nova função de back, nova função de front, documentação extensa
5 G - Nova feature (back/front), alteração de arquitetura, alteração de DevOps
8 GG - Bugfix complexo, geração de relatório complexo