Uma passagem de arquitetura dá às equipes contexto suficiente para implementar a solução sem redescobrir suas decisões importantes. Deve incluir uma apresentação conjunta e responsabilidades claras, não apenas um documento enviado ao fim do projeto.
Uma passagem de arquitetura dá às equipes contexto suficiente para implementar a solução sem redescobrir suas decisões importantes. Deve incluir uma apresentação conjunta e responsabilidades claras, não apenas um documento enviado ao fim do projeto.
Mantenha esses itens em uma fonte versionada que as equipes possam atualizar. Vincule contratos e requisitos oficiais, em vez de criar uma cópia separada que passe a divergir.
Em um portal de devoluções, acompanhe uma devolução desde o envio pelo cliente até a confirmação do armazém. Peça à equipe de implementação que explique a política de duplicatas, à equipe de suporte que explique como encontrar uma devolução parada e à equipe de testes que explique como verificar os critérios de aceitação.
Se a interface do armazém ainda for incerta, identifique seu responsável, o experimento necessário e a data em que a resposta passa a afetar a implementação. Identifique explicitamente uma premissa temporária; não a apresente como capacidade verificada.
Acorde quais mudanças exigem revisão arquitetural e quais a equipe pode fazer localmente. Programe revisões em torno de integrações arriscadas ou da primeira fatia funcional, em vez de esperar o lançamento final. Atualize decisões quando evidências da implementação contradisserem as premissas originais.
Uma passagem bem-sucedida se demonstra quando as equipes conseguem explicar e implementar o comportamento pretendido, e questões pendentes têm responsáveis. Contar páginas ou apenas coletar uma assinatura não comprova esse entendimento. Prescrição excessiva atrasa a implementação, enquanto restrições ausentes levam a escolhas incompatíveis.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar