🎯 ATIVIDADE 02: MODELOS DE PROCESSO DE SOFTWARE

📖 Fundamentação Teórica

Para realizar este laboratório com sucesso, certifique-se de ter compreendido os conceitos apresentados no:
👉 CAPÍTULO 02: MODELOS DE PROCESSO DE SOFTWARE

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria, definindo as engrenagens de como a sua equipe vai trabalhar. 🛡️🧩


🎯 Objetivos de Aprendizagem do Laboratório

Ao final deste laboratório prático (estimativa: 4 horas presenciais / autoguiadas), você será capaz de:

  • Diferenciar modelos Preditivos (Cascata/Waterfall) de modelos Adaptativos (Ágeis, Scrum, Kanban).
  • Justificar tecnicamente a escolha de um processo de software com base no nível de incerteza do escopo.
  • Definir papéis gerenciais e operacionais (ex: Product Owner, Scrum Master, Dev Team).

🏢 O Cenário Prático (Seu Desafio)

A diretoria da TecProExpress aprovou o escopo do seu "App de Rastreamento" (Atividade 01). Agora, o Gerente de Projetos quer saber: "Como vocês vão construir isso?"

Um diretor mais antigo sugeriu o uso do Modelo Cascata, exigindo que a equipe entregue o software completo apenas daqui a 6 meses. O seu time de desenvolvimento, no entanto, acredita que o mercado é muito volátil e prefere o Scrum para fazer entregas mensais.

"Seu desafio é vestir a camisa de Scrum Master / Agile Coach, escolher oficialmente qual modelo o projeto da sua equipe (criado na Atividade 01) vai seguir, e apresentar uma justificativa técnica blindada contra argumentos antigos."


🧠 Fundamentos: A Teoria Traduzida

Não existe um "melhor" modelo de processo de software. Existe o modelo que melhor lida com o nível de risco do seu projeto.

Preditivo vs Adaptativo

  • Cascata (Preditivo): Você tem que saber 100% do que o cliente quer no dia 1. Se o cliente mudar de ideia no meio, o projeto falha. Ideal para: Softwares de aviões ou satélites.
  • Ágil/Scrum (Adaptativo): Você assume que o cliente não sabe o que quer e vai mudar de ideia. O software é feito em "fatias" (Sprints) e o cliente testa mensalmente. Ideal para: Apps, Sistemas Web, Startups.

📊 Visualizando a Lógica

Dica

Em projetos acadêmicos e startups, a incerteza é gigante. Escolher metodologias ágeis é quase um instinto de sobrevivência!

```mermaid flowchart LR subgraph Cascata A1["Requisitos"] --> B1["Design"] --> C1["Código"] --> D1["Testes"] --> E1["Morte se o cliente mudar de ideia"] end
subgraph Scrum
A2(("Sprint 1")) --> B2(("Sprint 2")) --> C2(("Sprint 3"))
end

---

## 📖 Exemplo Guiado
Abaixo, veja como estruturar a escolha de um processo.

| Passo | Ação de Engenharia | Resultado Esperado |
| :--- | :--- | :--- |
| 01 | Analisar a Incerteza | Alta incerteza (O motorista do App não sabe bem o que quer). |
| 02 | Escolher o Modelo | Scrum. |
| 03 | Definir Papéis | Quem é o Dono do Produto (PO)? Quem programa? |

#### 📊 Jornada de uma Tarefa no Kanban Ágil
```mermaid
flowchart LR
    B["Backlog (Ideias)"] --> TD["To Do (Sprint)"]
    TD --> IP["In Progress"]
    IP --> CR["Code Review"]
    CR --> QA["Testing/QA"]
    QA --> DN["Done (Produção)"]

    style B fill:#eceff1,stroke:#607d8b
    style TD fill:#e1f5fe,stroke:#0288d1
    style IP fill:#fffde7,stroke:#fbc02d
    style CR fill:#f3e5f5,stroke:#8e24aa
    style QA fill:#e8f5e9,stroke:#2e7d32
    style DN fill:#e0f2f1,stroke:#004d40,stroke-width:2px

🛠️ Exemplo de Documentação

# Processo Escolhido: Scrum

**Justificativa:** 
Optamos pelo Scrum porque o aplicativo de rastreio tem alta incerteza. Como não sabemos se os motoristas terceirizados vão se adaptar à interface, precisamos de feedback constante (Sprints de 2 semanas) para corrigir a rota antes do orçamento acabar, coisa que o Cascata não permitiria.

**Papéis no Scrum:**
* **Product Owner (PO):** O Gerente de Logística (Dono do processo).
* **Scrum Master:** O Líder Técnico do projeto.
* **Dev Team:** Os programadores e designers.

🔍 Detalhamento da Documentação:

  • A Justificativa não é "porque é mais moderno". É uma defesa baseada na Incerteza e no Custo do Erro.
  • O PO (Product Owner) não é um programador. É a pessoa que entende de logística e sabe o que dá dinheiro para a empresa.

🛠️ Prática Obrigatória 1: Escolha e Justificativa

Cenário: O projeto semestral da sua equipe.

  1. Declare qual modelo seu projeto vai seguir: Scrum, Kanban ou Cascata.
  2. Escreva um parágrafo de no mínimo 4 linhas justificando tecnicamente sua escolha, usando as palavras "Incerteza" e "Feedback".

🏁 Resultado Esperado (Para sua Referência)

Texto argumentativo profissional validando o modelo de trabalho escolhido.


💻 Simulador de Sprint & Burndown em Python

Para vivenciar a cadência de uma Sprint ágil, execute o simulador em Python abaixo:

# simulador_sprint.py
class SprintScrum:
    def __init__(self, nome_sprint: str, duracao_dias: int, total_story_points: int) -> None:
        self.nome_sprint = nome_sprint
        self.duracao_dias = duracao_dias
        self.pontos_restantes = total_story_points
        self.historico = [total_story_points]

    def queimar_pontos_dia(self, dia: int, pontos_entregues: int) -> None:
        self.pontos_restantes = max(0, self.pontos_restantes - pontos_entregues)
        self.historico.append(self.pontos_restantes)
        print(f"📅 Dia {dia:02d}: Entregues {pontos_entregues:02d} pts | Restam: {self.pontos_restantes:02d} pts")

if __name__ == "__main__":
    print("=" * 60)
    print("🏃 SIMULADOR DE BURNDOWN DE SPRINT (SCRUM) - TECPROEXPRESS")
    print("=" * 60)

    sprint = SprintScrum(nome_sprint="Sprint 01 - Autenticação & MVP", duracao_dias=10, total_story_points=34)
    print(f"Meta: {sprint.nome_sprint} | Duração: {sprint.duracao_dias} dias | Backlog: 34 pts\n")

    sprint.queimar_pontos_dia(dia=2, pontos_entregues=5)
    sprint.queimar_pontos_dia(dia=4, pontos_entregues=8)
    sprint.queimar_pontos_dia(dia=7, pontos_entregues=13)
    sprint.queimar_pontos_dia(dia=10, pontos_entregues=8)

    print("-" * 60)
    if sprint.pontos_restantes == 0:
        print("🎉 SPRINT CONCLUÍDA COM 100% DOS PONTOS ENTREGUES!")
    print("=" * 60)

🖥️ Saída Esperada no Terminal:

============================================================
🏃 SIMULADOR DE BURNDOWN DE SPRINT (SCRUM) - TECPROEXPRESS
============================================================
Meta: Sprint 01 - Autenticação & MVP | Duração: 10 dias | Backlog: 34 pts

📅 Dia 02: Entregues 05 pts | Restam: 29 pts
📅 Dia 04: Entregues 08 pts | Restam: 21 pts
📅 Dia 07: Entregues 13 pts | Restam: 08 pts
📅 Dia 10: Entregues 08 pts | Restam: 00 pts
------------------------------------------------------------
🎉 SPRINT CONCLUÍDA COM 100% DOS PONTOS ENTREGUES!
============================================================

🌐 Exemplo de Payload JSON para Criação de Sprint (Swagger /docs)

{
  "nome": "Sprint 01 - Autenticação e Gestão de Entregas",
  "data_inicio": "2026-03-01",
  "data_fim": "2026-03-14",
  "story_points_alvo": 34,
  "product_owner": "Carlos Eduardo (Gerente de Logística)",
  "scrum_master": "Mariana Silva (Líder Técnica)",
  "itens_backlog": [
    {"id": "US-01", "titulo": "Login do Motorista via Token JWT", "pontos": 5},
    {"id": "US-02", "titulo": "Lista de Pacotes Atribuídos", "pontos": 8},
    {"id": "US-03", "titulo": "Atualização de Status de Entrega", "pontos": 13}
  ]
}

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas:

  1. Salve o arquivo de documentação com o nome Atividade_02.md na pasta es-atv-02-processos/ do seu repositório GitHub.
  2. Certifique-se de fazer o commit e push para o repositório público.
  3. Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

Importante

Reflexão Profissional: Se a sua equipe (Dev Team) atrasar uma entrega importante e reclamar que foi por causa de uma interrupção não programada, quem deveria intervir e protegê-los de distrações externas? O Product Owner ou o Scrum Master? (Resposta: O Scrum Master é o escudo do time contra o caos corporativo). 🧠🛡️

---

📊 Rubrica Formativa de Avaliação

Critério de Avaliação Insuficiente (0% - 40%) Regular (41% - 70%) Excelente (71% - 100%)
Escolha do Processo & Justificativa Escolhe uma metodologia sem justificativa ou com explicação incoerente. Justifica brevemente mas sem relacionar com incerteza ou feedback. Argumentação técnica sólida de no mínimo 4 linhas usando 'Incerteza' e 'Feedback'.
Divisão de Papéis e Cadência Confunde os papéis de PO, Scrum Master e Dev Team. Define os papéis mas sem definir cadência de Sprints/reuniões. Mapeia os papéis do time com clareza e estabelece cadência realista para o semestre.
Entrega no GitHub Entrega fora da pasta `es-atv-02-processos/` ou com arquivo ausente. Arquivo entregue mas com formatação Markdown inconsistente. Arquivo `Atividade_02.md` publicado no repositório com formatação limpa e validada.