Como construir katas de projeto de sistemas que treinem engenheiros a avaliar as vantagens e desvantagens de arquiteturas.

Uma equipe projeta um serviço de venda de ingressos para um festival regional. O sistema lida com a carga esperada sem problemas, e a revisão do projeto termina com aprovação unânime. Então, o briefing muda: o organizador agora promete que a venda de ingressos deve continuar funcionando mesmo se um dos data centers ficar offline durante o período de vendas. O mesmo projeto agora apresenta um único ponto de falha, e os engenheiros que o desenvolveram precisam decidir o que mudar, o que descartar e como explicar a escolha.

Este é um cenário ilustrativo, não um incidente documentado. Trata-se da situação que um kata de projeto de sistemas visa simular: um projeto que funcionava bem sob um conjunto de restrições encontra um novo conjunto, e os engenheiros devem defendê-lo ou revisá-lo, apresentando justificativas. Este guia destina-se a líderes de capacitação de engenharia e gerentes de engenharia. Ele aborda o que é um kata de projeto de sistemas, como criá-lo, como executá-lo e avaliá-lo, e quando o treinamento deixa de ser a solução. Cada caso e critério deve ser validado por um engenheiro sênior antes de ser utilizado.

O que é um kata de projeto de sistemas?

Um kata de design de sistemas é um exercício de design curto e com tempo limitado. Uma pequena equipe recebe um problema de negócios descrito em um parágrafo, esboça uma arquitetura, apresenta-a aos colegas e responde a perguntas difíceis. Também é chamado de kata de arquitetura ou kata arquitetônico. O formato foi criado por Ted Neward como um workshop e está documentado, com suas regras e o papel do moderador, em [link para a documentação]. Página de katas arquitetônicos de Neal FordA questão motivadora de Neward, citada ali, é como as organizações devem formar grandes arquitetos quando os engenheiros têm a oportunidade de arquitetar menos de meia dúzia de vezes em suas carreiras. Um kata oferece a eles repetições extras sem risco de produção.

Fatos rápidos

1. Descreva o problema de desempenho.

Comece pela tarefa, não pelo tópico. A tarefa é defender uma arquitetura sob restrições variáveis. No trabalho real, isso acontece em revisões de projeto, acompanhamento de incidentes e reuniões de planejamento, onde um requisito muda: mais tráfego, uma promessa de disponibilidade mais rigorosa, uma nova regra de residência de dados, um orçamento mais restrito.

Muitos engenheiros conseguem desenhar uma arquitetura sensata. Menos ainda conseguem dizer o que sacrificariam quando dois objetivos colidem e que evidências os fariam mudar de ideia. Essa segunda habilidade é o que o kata pratica.

Escreva uma declaração de desempenho de uma frase e peça a um gerente de engenharia para revisá-la: "Dada uma arquitetura e uma restrição alterada, o engenheiro nomeia o que quebra, propõe uma alteração, descreve a compensação e indica o que ainda não sabe."

2. Diagnosticar as lacunas de aprendizagem e de contexto

Antes de construir qualquer coisa, compare a tarefa com o que seu programa pratica e avalia atualmente.

1. O treino utiliza a tarefa real? Se o treinamento ensina padrões isoladamente e a avaliação é um teste de múltipla escolha, ninguém praticou a defesa de uma escolha.
2. Qual é a demanda cognitiva? Na taxonomia revisada de Bloom, comparar opções com restrições se enquadra em "analisar e avaliar", e propor um projeto revisado se enquadra em "criar". Nosso guia para Alinhar as atividades de aprendizagem à Taxonomia de Bloom Mostra como adequar a atividade a esse nível.
3. Existe algo além da habilidade que esteja atrapalhando? Verifique se os engenheiros têm tempo para projetar, se alguém é responsável pelas decisões de arquitetura e se os requisitos estão documentados. Se uma decisão for tomada por alguém de fora da equipe, nenhum kata mudará o que a equipe pode fazer. Passe essas causas para as pessoas que podem resolvê-las.

3. Preparação e prática do projeto

Atribua uma função específica a cada etapa.

Preparação. Verifique os pré-requisitos com um breve diagnóstico: o vocabulário que sua equipe usa (disponibilidade, consistência, latência, custo), os conceitos básicos que se espera que eles conheçam e seu próprio modelo de revisão de projeto. O estudo individualizado é adequado para esta etapa, e uma verificação de memorização apenas confirma os pré-requisitos.

Prática. Execute o kata em si. No formato descrito no site de Neal Ford, após a formação da equipe, o exercício se divide em três fases: uma fase de discussão, onde a equipe define o que irá construir; uma fase de revisão por pares, onde cada equipe apresenta e responde a perguntas; e uma fase de votação, onde os colegas dão um sinal de positivo ("mandou bem"), um sinal de "mais ou menos" ("faltou alguma coisa") ou um sinal de negativo ("errou feio"). Algumas regras podem ser adotadas diretamente: as equipes podem fazer suposições sobre tecnologias desconhecidas, mas devem declará-las, e não podem presumir que conseguirão contratar uma equipe de especialistas.

Adicione a restrição variável. O kata padrão apresenta um problema fixo. Para treinar a habilidade descrita neste guia, adicione uma segunda carta na metade do processo: uma restrição alterada que a equipe deve assimilar. Essa é uma escolha de design nossa, não faz parte das regras originais, então teste-a.

Feedback. Vincule o feedback às decisões tomadas, e não à pontuação total. "Vocês expandiram para duas regiões, mas não explicaram o que acontece com os pedidos feitos durante essa transição" é uma informação mais útil do que "3 de 5".

Entrada ao vivo ou revisão assíncrona? A mediação ao vivo é mais proveitosa quando uma escolha é ambígua e os engenheiros aprendem com um colega mais experiente explicando por que manteriam a posição adotada. A revisão assíncrona é suficiente para comparar uma justificativa escrita com um exemplo anotado.

4. Analise um exemplo realista.

Ilustrativo. Um engenheiro sênior deve validar o caso e os critérios de resposta antes do uso.

O caso. Um festival regional vende 20,000 ingressos durante um fim de semana, com a maior parte das vendas concentrada nos primeiros dez minutos. A primeira versão do briefing solicitava um serviço de reservas capaz de lidar com esse pico de vendas. O projeto consistia em uma única camada web, um único banco de dados e uma chamada para o provedor de pagamentos no momento da finalização da compra.

A restrição foi alterada. Na metade do evento, o organizador acrescenta: as vendas devem continuar caso um dos centros de dados fique offline, e nenhum ingresso poderá ser vendido duas vezes.

Uma primeira tentativa. "Adicione um segundo centro de dados e replique o banco de dados." A equipe recorreu a um componente familiar, mas não explicou o que acontece com a regra de não venda dupla quando os dois sites não conseguem se comunicar.

Feedback e tentativa novamente. O facilitador pede à equipe que nomeie os dois objetivos em conflito e qual deles eles protegeriam em caso de divisão da rede. Na segunda tentativa, eles são solicitados a escolher um e a descrever a experiência do cliente.

Uma tentativa mais robusta. "Protegeríamos a regra de não venda dupla. Durante uma divisão de ingressos, apenas o site principal vende ingressos, enquanto o outro site exibe uma página de espera. Aceitamos uma disponibilidade menor por um curto período para evitar a venda do mesmo assento duas vezes. Presumimos que a divisão de ingressos seja rara e breve, e gostaríamos que o organizador confirmasse se a página de espera é aceitável. Caso seja necessário que ambos os sites vendam ingressos, alocaríamos blocos de assentos separados para cada site com antecedência, ao custo de alguns assentos não vendidos." Observe que esta resposta nomeia o conflito, escolhe um lado, indica o custo e sinaliza o que desconhece.

Por que cada resposta é defensável ou incompleta. Avalie cada um de acordo com critérios aprovados, não com base na arquitetura preferida de um avaliador. A primeira tentativa menciona um componente, mas não apresenta nenhuma compensação. A tentativa mais robusta é específica, declara suas premissas e oferece uma alternativa com seu respectivo preço.

5. Avaliar a capacidade e planejar a transferência.

A capacidade do engenheiro é comprovada pelo seu desempenho em um caso novo, nunca antes visto. A pontuação avalia o raciocínio de compensação e a resposta a uma nova restrição. Uma rubrica simples utiliza uma escala de 0 a 2 para cada critério.

Critérios de avaliação: 0 significa ausente ou sem suporte, 1 significa parcial com omissões relevantes e 2 significa completo e justificado de acordo com os critérios acordados. Defina erros críticos separadamente, como ignorar um requisito declarado de segurança ou proteção de dados, para que uma pontuação geral não os oculte. Esta rubrica é uma proposta, não um padrão de prontidão validado: adapte-a com um gerente de engenharia e teste-a. Nosso guia para Projetando práticas interativas com feedback útil Este artigo aborda como redigir feedback que esteja relacionado às decisões tomadas.

Transfira o planejamento de forma deliberada. Após o kata, peça a cada engenheiro que traga uma decisão de projeto em andamento para uma revisão e aplique as mesmas perguntas. Uma revisão imparcial de um incidente passado é outra boa ponte para o trabalho real; consulte nosso guia para conduzir revisões de incidentes sem culpabilização.

Onde a entrega interativa ajuda

Os formatos interativos são úteis quando todos devem se comprometer antes de ver o grupo. Em uma sessão de kata ao vivo, um facilitador pode mostrar a restrição alterada, pedir a cada membro da equipe que digite a compensação que faria e o porquê, e então revelar a distribuição de votos antes do início da discussão. A votação entre pares ao final do formato original é fácil de ser realizada da mesma maneira. O mesmo caso pode ser realizado em ritmo próprio para preparação ou para engenheiros que perderem a sessão. O AhaSlides oferece suporte ao aprendizado interativo e à transição entre apresentações ao vivo e em ritmo próprio. É uma ferramenta de apresentação e aprendizado, não um local para desenhar ou executar arquiteturas, portanto, mantenha os diagramas em um quadro branco ou em sua ferramenta de design. Verifique qualquer função específica de autoria, feedback ou relatório que você planeja utilizar em relação ao seu próprio fluxo de trabalho. Para obter orientações sobre a escolha de formatos, consulte nosso artigo sobre Quando usar o aprendizado adaptativo, interativo e ao vivo.

Meça o que mudou.

Decida antecipadamente o que demonstraria que os engenheiros conseguem defender uma arquitetura sob restrições variáveis. Compare o raciocínio de compensação em um caso inédito com uma linha de base obtida antes do programa. Defina quem está incluído, o denominador e o cronograma. Se os resultados melhorarem, analise o que mais mudou no mesmo período, como um novo modelo de revisão de projeto, uma alteração na equipe ou um incidente que chamou a atenção, antes de atribuir o crédito ao treinamento.

Restrições que podem permanecer

• Autoridade em design. Se a equipe não tomar a decisão, praticá-la terá efeito limitado.
• Tempo. Um kata leva horas; projetos reais levam semanas e envolvem dados que um kata não pode fornecer.
• Cobertura do caso. Um caso específico envolve algumas compensações. Uma pontuação não descreve o julgamento de um engenheiro em geral.
• Complexidade. Mais complexidade não significa necessariamente uma arquitetura melhor, portanto, não recompense o maior número de componentes.
• Transferência. Ter um bom desempenho em um workshop não é o mesmo que ter um bom desempenho em uma avaliação sob pressão, portanto, verifique o desempenho após o kata, no contexto real.

Informe esses problemas aos patrocinadores com antecedência e planeje correções separadas. Um kata aprimora o que os engenheiros podem explicar e defender. Ele não cria a autoridade nem o tempo necessário.

Perguntas frequentes

O que é um kata de projeto de sistemas?

Um exercício de design curto e com tempo limitado, no qual uma pequena equipe esboça uma arquitetura para um problema de negócios, apresenta-a aos colegas e responde a perguntas desafiadoras. Também é chamado de kata de arquitetura.

Quantas pessoas devem compor uma equipe?

O formato original utiliza pequenos grupos de 3 a 5 pessoas, geralmente como um dos 4 a 10 grupos em uma sala. Use grupos pequenos o suficiente para que todos possam falar.

Como você avalia um kata de projeto de sistemas?

Apresente um novo caso e avalie o raciocínio de compensação e a resposta a uma restrição alterada com base em critérios acordados. A votação dos colegas é um feedback útil, mas não uma pontuação por si só.

Por onde começar

Escolha uma decisão de design recorrente em sua organização e escreva um parágrafo de justificativa sobre ela. Adicione uma restrição alterada, peça a um gerente de engenharia para validar a justificativa e os critérios de resposta e elabore uma rubrica com três critérios e uma lista de erros críticos. Teste com uma equipe antes de implementar em larga escala.

Para ver como um kata pode ser executado ao vivo com sua própria equipe e reutilizado posteriormente em seu próprio ritmo, explore o AhaSlides.