🎯 ATIVIDADE 02: MODELOS DE PROCESSO DE SOFTWARE
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
Em projetos acadêmicos e startups, a incerteza é gigante. Escolher metodologias ágeis é quase um instinto de sobrevivência!
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.
- Declare qual modelo seu projeto vai seguir: Scrum, Kanban ou Cascata.
- 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:
- Salve o arquivo de documentação com o nome
Atividade_02.mdna pastaes-atv-02-processos/do seu repositório GitHub. - Certifique-se de fazer o commit e push para o repositório público.
- Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.
💡 Checkpoint de Lógica
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. |