⚙️ Atividade 02: Processos de Software

🎯 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

📖 Exemplo Guiado

Abaixo, veja como estruturar a escolha de um processo.

📊 Jornada de uma Tarefa no Kanban Ágil

🛠️ 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

📊 Rubrica Formativa de Avaliação