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 projeto de sistemas é um exercício de projeto 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 complexas. Também conhecido como kata de arquitetura ou kata arquitetônico, esse formato foi criado por Ted Neward como um workshop e está documentado, com suas regras e o papel do moderador, na página de katas arquitetônicos de Neal Ford . A pergunta motivadora de Neward, citada lá, é como as organizações podem formar grandes arquitetos quando os engenheiros têm menos de meia dúzia de oportunidades para arquitetar em suas carreiras. Um kata oferece a eles repetições extras sem o 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.

Pratique. 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 craques.

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

Feedback. Vincule o feedback às decisões, não a uma pontuação total. "Vocês migraram para duas regiões, mas não disseram o que acontece com um pedido feito durante a transição" é mais útil do que "3 de 5".

Contribuição 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 sua posição. 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 solicita um serviço de reservas capaz de lidar com esse pico de vendas. O projeto: 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 mudou. No meio do processo, o organizador acrescenta: as vendas devem continuar se um dos centros de dados ficar offline, e nenhum ingresso poderá ser vendido duas vezes.

Uma primeira tentativa. "Adicionar um segundo centro de dados e replicar 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 nova tentativa. O facilitador pede à equipe que nomeie os dois objetivos em conflito e qual deles protegeriam em caso de divisão da rede. Na nova tentativa, eles devem escolher um e 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. Partimos do princípio de que a divisão de ingressos é rara e breve, e gostaríamos que o organizador confirmasse que uma 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 uma de acordo com critérios aprovados, não com base na arquitetura preferida do revisor. 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 de segurança ou proteção de dados declarado, 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 projetar práticas interativas com feedback útil aborda como escrever feedback que esteja vinculado às decisões.

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 imparciais.

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 usar 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 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.