Exemplo de DSM — Dependências com Liberação de Múltiplas Tasks¶

Exemplo preenchido: Este exemplo mostra uma situação em que a conclusão de uma tarefa habilita duas ou mais tarefas seguintes. O cenário continua baseado no contexto da plataforma de pedidos para pescadores.

⬇️ Baixar / Copiar Código Fonte do Exemplo

1. Visão Geral¶

2. Elementos do Sistema¶

3. Matriz DSM¶

Marque com X quando o elemento da linha depende do elemento da coluna.

4. Grafo de Dependências¶

Neste exemplo, a conclusão do Painel principal habilita mais de uma task seguinte.

graph TD
    A[Cadastro] --> B[Login]
    B --> C[Painel Principal]
    C --> D[Registro de Pedido]
    C --> E[Listagem de Pedidos]
    C --> F[Atualizacao de Status]
    D --> E
    E --> F

Leitura do grafo¶

• Login depende de Cadastro
• Painel Principal depende de Login
• quando o Painel Principal fica pronto, ele libera mais de uma frente:
• Registro de Pedido
• Listagem de Pedidos
• Atualização de Status
• depois, algumas dessas tasks ainda se conectam entre si:
• Listagem de Pedidos depende do registro dos pedidos
• Atualização de Status depende da existência e visualização dos pedidos

5. Interpretação do Exemplo¶

Tarefa que habilita múltiplas tasks¶

Neste exemplo, a task Painel Principal é um ponto de bifurcação.

Quando ela é concluída, a equipe pode avançar em paralelo com:

1. registro de pedido
2. listagem de pedidos
3. atualização de status

Isso é importante porque mostra que uma tarefa estrutural pode destravar várias frentes de trabalho.

Dependências críticas¶

Elementos que podem ser desenvolvidos em paralelo¶

• refinamento visual do painel
• validação do formulário de pedido
• estrutura inicial da listagem

Elementos que devem vir antes¶

1. cadastro
2. login
3. painel principal

6. Impactos no Planejamento¶

Ordem sugerida de implementação¶

1. cadastro de usuário
2. login
3. painel principal
4. registro de pedido e listagem em paralelo
5. atualização de status

Riscos de acoplamento¶

• tentar implementar status antes de existir pedido real
• criar listagem sem definir os dados mínimos do pedido
• alterar o painel principal depois de várias funcionalidades já dependerem dele

Decisões arquiteturais importantes¶

• definir cedo a estrutura do painel principal
• estabelecer o modelo de dados do pedido antes da listagem avançar
• separar responsabilidades para que tarefas paralelas não gerem conflito

7. Relação com as Features Fim a Fim¶

8. Conclusão¶

Principais aprendizados¶

O DSM ajuda a perceber que algumas tasks não apenas dependem de outras, mas também funcionam como pontos de liberação para várias frentes seguintes.

Ajustes necessários no backlog ou arquitetura¶

O backlog deve tratar o painel principal como elemento estruturante, pois sua conclusão destrava múltiplas implementações posteriores.