F4NT0| Home | Sprints | Requisitos | Arquitetura e Tecnologias | Configuração | Endpoints | Mockups | Problemas | [Cronograma] (Cronograma) | [Gestao] (Plano de Gestão) |
|---|
SCRUM
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.
No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.
Ref: www.desenvolvimentoagil.com.br & www.manifestoagil.com.br
Comunicação
Intruções básicas:
Como se comunicar com o time:
Slack (Channel #team) -> WhatsApp -> Email
Como se comunicar com os stakeholder:
Slack -> Channel #General
- Deixar os Ages 4 ciente da conversa para monitoramento e evitar problemas.
Como monitorar as atividades:
Todas as tasks estão sendo gerenciadas pela ferramenta ClubHouse, lá também há informações das tasks e comentários do andamento.
| Evento | Objetivos | Responsável | Participantes | Frequência | Duração | Meio |
|---|---|---|---|---|---|---|
| Sprint Planning | Alinhar o que será trabalhado na sprint e quebrar as user stories em pequenas tarefas a serem executadas. | GP | Time de desenvolvimento e Stakeholder | A cada 2 semanas | 1 hora e meia | Presencial |
| Daily Meeting | Melhorar a comunicação do time, remover impedimentos e acompanhar a evolução da sprint. | Scrum Master | Time de desenvolvimento, Scrum Master e GP | Quartas e Sextas | 15 minutos | Presencial nas sextas e whatsapp nas quartas |
| Sprint Retro | Analisar erros e acertos da equipe, buscando uma melhoria constante no desenvolvimento do projeto. | GP | Time de desenvolvimento, Scrum Master e GP | A cada 2 semanas | 30 minutos | Presencial |
Plano de Gerenciamento de Riscos
| Risco | Mitigação | Contigência |
|---|---|---|
| Motivação do time diminuir | Se comunicar com Scrum Master frequentemente | Restrospectivas e integrações |
| Falta de conhecimento em MongoDB impactar nas entregas | Filipe e Gabriel que já trabalharam com a tecnologia poderiam suportar o time | Trocar para banco relacional |
| Escolha das tecnologias impactar nas entregas | Estudo dirigido sobre a tecnologia escolhida | Estudar a viabilidade de trocar de tecnologia |
| Falta de documentação | Garantir e revisar documentações na wiki | Criar tasks destinadas aatualização da wiki |
| Código depender de uma integrante com maior conhecimento | Integrante com maior conhecimento designar tasks para os demais de acordo com dificuldade | Integrante com maior conhecimento fazer design sessions explicando o código e como utilizá-lo |
| Saída de um integrante da equipe que tenha um maior conhecimento | Pair Progamming, estudos dirigidos e nivelamento do conhecimento | Integrantes devem aprofundar conhecimento para suprir a perda |
Planejamento Releases
Planejamento dos Sprints
A cada duas semanas os stakeholders estarão presente para reunião, o time deve mostrar o que foi feito e o que não foi feito (deixando como pendência técnica e concluir na próxima Sprint), também é realizado as definições das próximas tasks a serem entregues, assim, eles podem acompanhar o andamento do projeto e sugerir possíveis melhorias, além de manter o alinhamento entre time <-> projeto <-> stakheolder.
Daily
Basicamente são reuniões diárias, onde o desenvolvedor deve responder três perguntas básicas:
- O que foi feito para atingir o objetivo?
- O que vai ser executado hoje?
- Há algum problema que esteja atrapalhando para atingir o objetivo?
Esta reunião costuma ocorrer no mesmo local, no mesmo horário, com participação de todos do time envolvido no projeto, porém, fizemos uma adaptação aplicando a Daily Wednesday, ou seja, toda quarta-feira é . O Scrum Master - Ages 2, Ramon - é responsável por realizar a intermediação dos problemas, porém, nessa situação os Ages 4 fazer um suporte para o Scrum Master.
Recursos Humanos
É importante o time ter total transparência com os colegas e os stakeholders, mantendo o engajamento e comprometimento com a Agência Expermental. Como tal, entendemos que o mapeamento do conhecimento e habilidades devem ser descritos para que outros membros do time possam requistar um aos outros para troca de conhecimento.
| Membro | Back-end | Front-end | Ops | Obs |
|---|---|---|---|---|
| Gian | * * * | * * * * | * * * | Abriu de aplicar seu conhecimento em back-end para aprender front-end |
| Munaretto | * | * * * * * | * | Suportando o projeto/time ajudando com Angular |
| Rodrigo | * * * * * | * * | * * | Responsável pelo start projeto (Core/API), porém, a partir do sprint 3 começou a apoiar o front-end. |
| Alexandre | - | - | - | Ror ser ages 1 tem pouco conhecimento e engajamento, é necessário pair-programming com outro membro da equipe. |
| Gustavo | - | * * | - | por ser ages 1 tem pouco conhecimento nas tecnologias utilizadas, porém, está aprendendo e pegando tasks sozinhas |
| Guerra | - | * * * | - | Conhecimento em Angular está crescendo, já está pegando tarefas sozinhos de forma independente. |
| Ramon | * * * * | * * * | * * * * * | Faz tudo, porém, aprendendo Angular |
| Lucas | * * * * | - | * | Focado na API |