Capítulo 25 — Ateliê de projeto em equipe
Mapa da aula
Aula 25 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["25.1 O enunciado do ateliê"]
N1["25.2 Dividindo o trabalho"]
N2["25.3 Revisões"]
N3["25.4 Comunicação da situação"]
N4["25.5 Caso resolvido"]
N5["25.6 Atividade prática"]
N6["25.7 Acordos de trabalho"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["25.1 O enunciado do ateliê"]
N1["25.2 Dividindo o trabalho"]
N2["25.3 Revisões"]
N3["25.4 Comunicação da situação"]
N4["25.5 Caso resolvido"]
N5["25.6 Atividade prática"]
N6["25.7 Acordos de trabalho"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[25.1 O enunciado do ateliê]
|
v
[25.2 Dividindo o trabalho]
|
v
[25.3 Revisões]
|
v
[25.4 Comunicação da situação]
|
v
[25.5 Caso resolvido]
|
v
[25.6 Atividade prática]
|
v
[25.7 Acordos de trabalho]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) trabalhar em equipe para planejar e executar uma fatia da migração; (2) dividir o trabalho por camada e por dependência; (3) usar revisões e evidências compartilhadas; e (4) comunicar a situação com clareza.
25.1 O enunciado do ateliê
Equipes de quatro pessoas assumem um fluxo da KLS — SFTP dos parceiros, VPN do escritório, API do cliente ou malha interna — e entregam uma réplica migrada em laboratório, com inventário, configuração, testes, monitoramento, runbook e avaliação.
Cada equipe recebe as mesmas restrições: apenas laboratório, dados sintéticos, os perfis da KLS como ponto de partida e cinco semanas. A entrega é julgada como um fluxo inteiro, então uma configuração perfeita sem monitoramento ou sem runbook não é aprovada. As equipes escolhem o seu fluxo na primeira semana e não podem mudá-lo depois que o inventário estiver concluído, o que força decisões cedo sobre o escopo.
25.2 Dividindo o trabalho
Divida por camada (rede, plataforma, aplicação, PKI) e por dependência: as tarefas que desbloqueiam as outras (ambiente de laboratório, inventário) vêm primeiro. Mantenha um quadro compartilhado com donos e definições de pronto.
Na equipe do SFTP, o dono do laboratório e do inventário terminou primeiro, porque o trabalho de configuração precisava dos dois; o dono da matriz de clientes preparou os clientes de teste em paralelo. O quadro compartilhado lista cada tarefa com dono, dependência e definição de pronto, para que uma tarefa bloqueada mostre pelo que está esperando.
Quando o dono da matriz de clientes ficou esperando as credenciais de teste de um parceiro, o quadro mostrou a dependência, e a regra de escalonamento de bloqueios em 24 horas da equipe do SFTP (Seção 25.7) levou o pedido ao gerente de parceiros na reunião diária da manhã seguinte.
25.3 Revisões
Toda mudança de configuração recebe uma revisão por pares em relação ao perfil central; toda afirmação da avaliação precisa de uma evidência que um revisor possa executar de novo. As revisões apanham a lista de grupos mal ordenada e o controle negativo ausente.
As equipes formam pares de revisores entre camadas, de modo que o especialista em rede revisa o trabalho do dono da PKI e vice-versa. Um comentário de revisão precisa apontar para uma evidência, como o perfil renderizado, uma linha de log ou a saída de um script, e o autor responde com uma mudança ou com um motivo. As revisões são acompanhadas no quadro, com a data em que foram pedidas e respondidas.
25.4 Comunicação da situação
Situação semanal: feito, próximo, bloqueado, riscos. Os bloqueios nomeiam o que é necessário e de quem. Evite números de percentual concluído que escondem riscos.
Um bloqueio se lê assim: "Precisamos da imagem do cliente do parceiro v3.2, do gerente de parceiros, até quinta-feira; sem ela, a matriz fica sem dois tipos de cliente." Os riscos nomeiam o que poderia mudar o plano. Um relatório que diz "70 % feito" não diz nada ao leitor sobre se o fluxo estará pronto, então os relatórios do ateliê nunca usam percentuais.
Cada risco é escrito com um gatilho e uma resposta, para que o leitor também saiba o que a equipe faria.
25.5 Caso resolvido
Equipe "SFTP": semana 1, laboratório e inventário (dono A); semana 2, atualização do OpenSSH e configuração da KEX (B); semana 3, matriz de clientes dos parceiros — seis tipos de cliente, dois apenas clássicos (C); semana 4, monitoramento e runbook (D); semana 5, avaliação. Bloqueada na semana 3 esperando a imagem do cliente de um parceiro; escalado ao instrutor, no papel de gerente de parceiros; substituída por uma emulação documentada.
A emulação só foi uma substituta razoável porque a equipe documentou os seus limites: o cliente emulado usava a versão da biblioteca do parceiro, mas não o seu proxy, então a avaliação marcou os resultados desse tipo de cliente como de menor confiança.
25.6 Atividade prática
Forme uma equipe, escolha um fluxo, escreva o plano e o primeiro relatório de situação.
Escreva o plano como uma lista de tarefas ordenada por dependência, com dono, definição de pronto e o artefato que cada uma produz. Inclua o ambiente de laboratório, o inventário e o rastreamento, a configuração, a matriz de clientes, o monitoramento, o runbook e a avaliação. O primeiro relatório de situação usa os quatro títulos feito, próximo, bloqueado e riscos. Se nada estiver bloqueado na primeira semana, diga o que você espera que fique bloqueado mais tarde e o que está fazendo agora para evitar isso.
25.7 Acordos de trabalho
Combine como a equipe vai trabalhar antes de começar: como as decisões são tomadas e registradas, como as revisões são pedidas e com que rapidez são respondidas, como os segredos usados no laboratório são guardados e o que acontece quando alguém fica bloqueado por mais de um dia. Os acordos escritos evitam as falhas mais comuns do ateliê — bloqueios silenciosos e mudanças sem revisão — e espelham a forma como as equipes de plataforma de produção operam.
O acordo da equipe do SFTP fixou as revisões em até um dia útil e o escalonamento de bloqueios depois de 24 horas.
25.8 Erros comuns e limites
- Todos trabalhando na mesma camada.
- Revisões puladas sob pressão de tempo.
- Relatórios de situação sem bloqueios.
Numa turma do ateliê, uma equipe de quatro pessoas trabalhou inteira na configuração do OpenSSH na segunda semana; ninguém montou a matriz de clientes, e a avaliação ficou sem dados. Outra equipe pulou as revisões na última semana e entregou um perfil com o híbrido listado em segundo lugar, o mesmo erro de ordem que o Laboratório T detecta. Uma terceira reportou "no prazo" toda semana até o prazo final, sem mencionar a imagem de parceiro que faltava. Cada falha é uma falha de processo, não técnica, e é por isso que o ateliê avalia o processo.
Exercícios
- EX049 — Ordem de dependências. Ordene cinco tarefas da equipe do SFTP por dependência e justifique. Rubrica: 3 = laboratório/inventário antes da configuração, configuração antes da matriz, monitoramento antes da avaliação.
- EX050 — Relatório de situação. Escreva um relatório de situação para a semana 3 do caso resolvido. Rubrica: 3 = feito, próximo, bloqueado com pedido, riscos.
Síntese
Os projetos de ateliê praticam a implementação em equipe: divisão do trabalho atenta às dependências, revisões baseadas em evidências e comunicação clara da situação.
Continue estudando — capítulo 25 de 30
← Capítulo 24 · Índice de capítulos do curso · Capítulo 26 →
Siga para a próxima lição escrita.