Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Amparo
  • wiki
  • Wiki
  • processo

processo · Changes

Page history
Update processo authored Sep 22, 2023 by Martin Ferreira's avatar Martin Ferreira
Hide whitespace changes
Inline Side-by-side
processo.md
View page @ 927d14b6
...@@ -197,8 +197,100 @@ Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papé ...@@ -197,8 +197,100 @@ Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papé
--- ---
## Plano de Riscos ## Plano de Riscos
| Risco | Prevenção | Contingência | Estratégia |
|-------|-----------|--------------|------------| <table>
| Atingir limite de uso gratuito da AWS (Exemplo) | Utilizar servidores apenas para validação, desligando-os quando não utilizados (Exemplo) | Alterar ambiente para outra conta de usuário (Exemplo) | Transferir (Exemplo) | <tr>
| TBD... | TBD... | TBD... | TBD... | <td>
**Risco**
</td>
<td>
**Probabilidade**
</td>
<td>
**Impacto**
</td>
<td>
**Severidade**
</td>
<td>
**Estratégia**
</td>
<td>
**Plano A**
</td>
<td>
**Plano B**
</td>
</tr>
<tr>
<td>Mudança no escopo</td>
<td>4</td>
<td>4</td>
<td>16</td>
<td>Mitigar</td>
<td>Definir o escopo no inicio do projeto com a aprovação do cliente. Utilizar o Backlog do projeto para caso falte tarefas em uma Sprint.</td>
<td>Deixar claro o plano de desenvolvimento da equipe para as 4 Sprints de desenvolvimento. Caso surjam novas alterações, coloca-las no Product Backlog do projeto.</td>
</tr>
<tr>
<td>Entrega não realizada</td>
<td>4</td>
<td>5</td>
<td>20</td>
<td>Mitigar</td>
<td>Acompanhar o time durante o desenvolvimento nas Sprints, buscando encontrar possíveis problemas e/ou dificuldades para melhor auxiliar o time.</td>
<td>Alertar o stakeholder durante a apresentação os motivos que nos levaram a uma entrega incompleta. Apresentar os próximos passos do time para adaptar o débíto técnico na próxima Sprint</td>
</tr>
<tr>
<td>Mudança na EAP do projeto</td>
<td>4</td>
<td>3</td>
<td>12</td>
<td>Mitigar</td>
<td>Apresentar para a equipe e os Stakeholders a EAP proposta para o projeto, com marcos e entregas que devem ser feitas em cada Sprint. Analisar na Retrospectiva os próximos passos para o projeto, e verificar a viabilidade com o time do que deverá ser feito para a próxima entrega.</td>
<td>Caso seja necessário realizar alguma alteração durante a Sprint de desenvolvimento, alertar os skateholders via canal de comunicação do Slack, explicando o motivo da necessidade.</td>
</tr>
<tr>
<td>Conflito na execuçao de atividades por squads diferentes</td>
<td>5</td>
<td>4</td>
<td>20</td>
<td>Transferir</td>
<td>Divisão e delegação de tarefas de forma coletiva com todas as squads envolvidas no desenvolvimento. Além disso, manter dados de controle, status e responsáveis registrados e atualizados na ferramenta Trello</td>
<td>Verificar no momento da planning quais tasks podem ser conflitantes no desenvolvimento, e manter o cuidado na hora de realizar o merge para o projeto. O merge request deverá ser aprovado e nenhum conflito deve existir para ser aprovado.</td>
</tr>
<tr>
<td>Comunicação interna nas Squads</td>
<td>5</td>
<td>5</td>
<td>25</td>
<td>Mitigar</td>
<td>Gestores (AGES IV) procurarem integrar outros colegas de squad afim de criar um clima de comprometimento e companherismo. Registro de impeditivos levantados em dailies. Deixar claro os marcos das sprints. Gestores fazerem one-to-one (informal) com integrantes das suas squads para coletar feedbacks.</td>
<td>Ter sempre presente um AGES 4 em cada squad para facilitar a comunicação do time como um todo, usando os AGES 4 como interface do grupo para a squad. Canais de comunicação devem sempre estar ativos.</td>
</tr>
<tr>
<td>Divisão e distribuição de tarefas</td>
<td>5</td>
<td>4</td>
<td>20</td>
<td>Explorar</td>
<td>Divisão das tarefas feitas junto a squad responsável. Garantir que cada membro da squad tenha ao menos uma tarefa sob sua responsabilidade.</td>
<td>Incentivar o pair-programming de tarefas mais complexas dentro das squads, caso não tenham tarefas suficientes, a fim de encaixar todos membros para desenvolvimento</td>
</tr>
<tr>
<td>Falta de conhecimento das tecnologias</td>
<td>4</td>
<td>3</td>
<td>12</td>
<td>Mitigar</td>
<td>Realização de workshop com colegas de squads para fazer boilerplates e o kickoff de desenvolvimento de cada sprint. Pair-programming para auxíliar no desenvolvimento e aprendizado. Registro de impeditivos nas reuniões de dailies.</td>
<td>Impulsionar trabalhos em grupo para o desenvolvimento das tarefas mais complexas, e aos poucos ir separando individualmente cada task entre os membros de cada squad.</td>
</tr>
</table>
Clone repository
  • arquitetura
  • banco_dados
  • codigo
  • configuracao
  • design_mockups
  • escopo
  • Home
  • processo
  • qualidade
  • utilizacao