Metodologia do Projeto
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 13/03/2018 | 0.1 | Criado estrutura inicial do documento | Luis Gustavo |
| 13/03/2018 | 0.2 | Adicionado Papel do scrum master e time de desenvolvimento, introdução e ritos | Luis Gustavo |
| 13/03/2018 | 0.3 | Adicionado nova responsabilidade para a equipe de desenvolvimento | Luis Gustavo |
| 15/03/2018 | 0.4 | Arrumado sumário | Luis Gustavo |
| 15/03/2018 | 0.5 | Adicionando papel arquitetura | Miguel Pimentel |
| 15/03/2018 | 0.6 | Adicionando metodologia XP e Scrum | Miguel Pimentel |
| 15/03/2018 | 0.7 | Adicionando papel DevOps | Miguel Pimentel |
Ao longo de todo o projeto será empregado metodologia de desenvolvimento ágil. No projeto será utilizado uma adaptação do Scrum e também será empregados práticas das frameworks XP e Kanban.
Durante a Release 1 o responsável por esse papel é o Luis Gustavo. São tarefas do Scrum Master:
- Fazer gestão de riscos;
- Garantir que os membros da equipe estejam executando a metodologia;
- Ficar responsável por conduzir as reuniões;
- Manter os stakeholders a par do projeto;
- Resolver ou designar membros da equipe para resolver impedimentos;
- Documentar o planejamento e resultados das sprints na Wiki;
- Garantir que nos ritos os dados sobre a equipe e a sprint estejam disponíveis;
- Garantir que as reuniões sejam preparadas e que não demore mais que o tempo estipulado;
Neste projeto foi definido como arquiteto devOps o membro Guilherme Baldissera que tem como responsabilidades:
- Engajar-se em operações como um cliente e parceiro, em que “uma das partes interessadas é a primeira classe”, - em desenvolvimento.
- Envolver os desenvolvedores em tratamento de incidentes.
- Garantir que todas as alterações de código e configurações sejam feitas usando mecanismos automatizados, rastreáveis e repetíveis.
- Implantação contínua de mudanças do check-in para produção.
- Infraestrutura como código.
No desenvolvimento do projeto foi definido como responsável pela arquitetura o membro Miguel Pimentel que tem como responsabilidade:
- Limitar as escolhas dentro do desenvolvimento em relação: A padrões de projetos a serem utilizados; Definir/Criar frameworks a serem utilizados no processo de desenvolvimento.
- Identificar pontos de reutilização de código no desenvolvimento do projeto por meio: Enxergar de forma mais abrangente; projeto baseando-se em componentes; e ter contato com todos os produtos desenvolvidos ao longo do projeto.
- Definir escolhas em relação: A arquitetura ser fragmentada em pequenos formatos como forma de diminuir a complexidade no processo de desenvolvimento;
- Ter domínio em relação: Função componentes; dependência de componentes; e comunicar arquitetura ao time de desenvolvimento.
São tarefas do time de desenvolvimento:
- Elaborar protótipos;
- Elaborar documento de visão, arquitetura e especificação suplementar;
- Desenvolver funcionalidades;
- Testar funcionalidades;
- Montar backlog da sprint;
- Elaborar folha de estilo;
Cada sprint se inicia ao domingo e termina ao sábado.
As daily scrum são reuniões diárias feitas pela equipe e tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado. Como os membros da equipe de desenvolvimento e os membros da equipe de gerência possuem horários muito diferentes, foi definido que as reuniões seriam da seguinte forma:
- Segunda e Quarta a reunião será via Hangouts às 21h30.
- Terça e Quinta a reunião será presencial, após a aula de EPS.
- Sexta e Domingo a reunião será feita via bot standuply no Slack, o bot poderá ser respondido de 20h até 23h59.
A reunião deverá durar até 15 minutos.
Ao final de cada sprint será feito uma reunião de revisão da sprint, o projeto será avaliado em relação aos objetivos da sprint, os será discutido o que foi concluído durante a sprint e, se necessário, o product backlog poderá ser alterado. A realização dessa reunião será feito durante a reunião de sábado da equipe e deverá durar até 45 minutos.
A retrospectiva da sprint ocorrerá ao final de cada sprint nela serão avaliados os pontos que funcionaram bem durante a sprint, as melhoras que a equipe teve, o que pode ser melhorado e as ações a serem tomadas. Essa reunião ocorrerá durante a reunião de sábado da equipe e deverá durar até 1h30.
Na reunião de planejamento de sprint será planejado todo o trabalho a ser feito na respectiva sprint, nela será definida o objetivo da sprint.Essa reunião ocorrerá durante a reunião de sábado da equipe e deverá durar até 2h.
Além do SCRUM, o desenvolvimento deste projeto adotou algumas práticas do Extreme Programming(XP) como forma de promover práticas que tenham impacto diretamente em código, destacando-se:
- Jogo de Planejamento (Planning Game)
- Fases pequenas (Small Releases)
- Metáfora (Metaphor)
- Design Simples (Simple Design)
- Testes de Aceitação (Customer Tests)
- Programação Pareada (Pair Programming)
- Padronização do Codigo (Coding Standards)
- Refatoração (Refactoring)
- Integração Contínua (Continuous Integration)
Oriundo do japonés KANBAN significa cartão ou sinalização. É um método para a implantação de mudanças que não prescreve papéis ou práticas específicas. No caso, ajudaria na nossa metodologia como algo suplementar, dando uma visão clara das tarefas, seus responsáveis e seu status. Para a implementação desta técnica, utilizou-se de ferramentas como o ZenHub e o taiga, ambos interligados ao Git e Slack.
O que é o Scrum?. Disponível em: http://www.desenvolvimentoagil.com.br/scrum/. Acessado em 13/03/2018
Scrum Guide. Disponível em: https://www.scrumguides.org/scrum-guide.html. Acessado em 13/03/2018
Extreme Programming Conceitos e Práticas. Disponível em: https://www.devmedia.com.br/extreme-programming-conceitos-e-praticas/1498. Acessado em 10/03/2018
Arquitetura de Software em DevOps. Disponível em: https://imasters.com.br/desenvolvimento/arquitetura-de-software-em-devops/?trace=1519021197&source=single. Acessado em 15/03/2018
