| ... | ... | @@ -197,8 +197,100 @@ Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papé |
|
|
|
---
|
|
|
|
|
|
|
|
## Plano de Riscos
|
|
|
|
| Risco | Prevenção | Contingência | Estratégia |
|
|
|
|
|-------|-----------|--------------|------------|
|
|
|
|
| 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) |
|
|
|
|
| TBD... | TBD... | TBD... | TBD... |
|
|
|
|
|
|
|
|
<table>
|
|
|
|
<tr>
|
|
|
|
<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>
|
|
|
|
|
