🎯 ATIVIDADE 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. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, 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

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

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.

📊 Jornada de uma Tarefa no Kanban Ágil

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.

🛠️ Prática Obrigatória 2: Papéis e Cadência

Cenário: Estruturação da equipe.

1. Definição de Papéis: Baseado nas suas Personas e no seu cenário da Atividade 01, liste quem ocuparia o papel de PO (Quem dita o que tem valor) e quem seria o Scrum Master / Time.
2. Cadência: Se escolheu Scrum, defina o tamanho da sua Sprint (ex: 1 semana, 2 semanas). Por que esse tempo?

🏁 Resultado Esperado (Para sua Referência)

Um arquivo de documentação (Markdown ou PDF) listando os atores do projeto e o calendário de entregas.

📤 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

[!IMPORTANT] 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). 🧠🛡️