Como posso rastrear atributos de qualidade no Kanban da minha equipe?

Minha equipe usa um sistema Kanban para rastrear o progresso diário e funcionou muito bem para entender o progresso dos recursos (capturados como histórias de usuários). Em grande parte, permitimos que o design do nosso sistema emergisse à medida que desenvolvíamos recursos que funcionaram bem até recentemente. Nas últimas duas semanas, tivemos várias discussões sobre trade-offs de arquitetura especificamente relacionados a atributos de qualidade de desempenho e modificabilidade.

Acho que o que está acontecendo é que, ao implementarmos recursos e projetar o sistema, estamos implicitamente tomando decisões sobre a arquitetura, mas não considerando essas decisões em termos de nossos requisitos de atributos de qualidade conhecidos. Seria ótimo se eu pudesse rastrear / capturar / retratar visualmente como essas importantes decisões de design estão sendo tomadas, para que os membros da equipe tenham uma chance melhor de não criar tensão adicional na arquitetura do sistema à medida que ela está sendo implementada. E, é claro, para complicar ainda mais as coisas, nossos recursos não são exclusivamente funcionais e às vezes escondem a complexidade da arquitetura!

Como acompanhar visualmente o progresso dos atributos de qualidade (ou outras decisões relevantes da arquitetura) no Kanban da minha equipe?

tomamos decisões implicitamente sobre a arquitetura, mas não as consideramos em termos de nossos requisitos de atributos de qualidade conhecidos.

Eu acho que você pode visualizar isso criando uma etapa de "revisão arquitetônica" no seu fluxo de trabalho. A etapa seria representada por uma coluna do quadro Kanbad com seu próprio limite WIP. O limite do WIP dependerá de quantos arquitetos / designers você tiver para participar dessas revisões.

A equipe de desenvolvimento é responsável pelo fluxo horizontal da esquerda para a direita das histórias de usuários. O (s) arquiteto (s), na maioria dos casos, tocará nas histórias somente quando elas estiverem na coluna de revisão técnica / arquitetural. A interseção da coluna com uma raia horizontal visualiza a reunião do (s) desenvolvedor (es) e arquiteto (s).

Uma das equipes em que trabalho tem uma etapa semelhante na qual faz uma revisão do esquema do banco de dados com o arquiteto-chefe de dados. Eles não usam o Kanban, mas, se o fizessem, provavelmente teriam essa coluna no quadro.

Os atributos de qualidade conhecidos podem então ser representados como:

• a definição de concluído para a etapa de revisão arquitetônica.
• testes de aceitação em torno das histórias de usuários já concluídas que representam requisitos não funcionais. Então, a definição de concluído para uma nova história de usuário incluiria não quebrar esses testes.

ADICIONADO : A etapa de "revisão da arquitetura" do fluxo de trabalho pode ser suspeita de um problema chamado tragédia dos bens comuns . Aqui está um ótimo post sobre como a visualização Kanban pode ajudar a lidar com isso e com as possíveis soluções.

Há realmente duas partes nessa questão. Uma parte é: como sabemos quando a arquitetura é alterada. A segunda parte é: como sabemos que a arquitetura ainda é boa.

Para esta primeira parte: como você sabe quando a arquitetura é alterada?

O objetivo aqui é pegar algo que está sendo feito implicitamente e torná-lo explícito

• A sugestão de Alexei é uma opção. Crie uma coluna no quadro para revisão da arquitetura. Em seguida, mova um cartão para lá, se for necessário tomar decisões arquitetônicas
• Outra opção é criar uma política explícita sobre como lidar com isso: "Se precisamos alterar a arquitetura, precisamos emparelhar com outra pessoa" é um exemplo de uma dessas políticas. Em um projeto, tínhamos uma política de que alterações de código em determinados módulos especializados precisavam ser feitas emparelhando-se com pessoas específicas. Quando alguém queria mudar o código lá, chamava um par e se juntava. O resto do trabalho foi feito sozinho. Você pode fazer algo semelhante com a arquitetura.

Você provavelmente iria com o primeiro, se muitos cartões exigirem revisão, ou se o arquiteto não fizer parte da equipe e for necessária uma transferência, ou se a revisão for detalhada o suficiente para levar algum tempo no qual você deseja acompanhar o quadro. Esta última é uma opção se apenas algumas placas tocam a arquitetura e é fácil encontrar um par sob demanda.

Agora, voltando à segunda pergunta: como sabemos que a arquitetura ainda é boa?

Eu sou um grande fã de visualização. Você pode ter um gráfico no quadro branco com notas post-it descrevendo os componentes e a arquitetura.

Existem também analisadores estáticos que analisam a base de código e geram uma imagem com gráfico de dependência de vários componentes. Você pode executá-lo, tirar uma impressão e colá-lo na parede uma vez por semana, aproximadamente. Talvez as duas últimas impressões possam estar na parede, para que você possa ver se alguma coisa mudou na última semana.

O que isso permite que você faça é tornar sua arquitetura e design visíveis. Os membros da equipe olham para ele de vez em quando e comentam se algo pode ser alterado, refatorado ou feito de uma maneira melhor.

Eu já vi esse problema também. Tomada de decisão implícita! Se a implicitude for o problema, torná-lo o mais explícito possível resolverá o problema? O que eu sugiro é ajustar um pouco o processo de arquitetura para 'começar a explicar' os pensamentos implícitos que progridem para se tornar decisões. O objetivo da etapa adicional do processo é fazer com que os membros da equipe entendam que todos estão propensos a tomar decisões arquitetônicas implícitas. Este passo manterá a decisão implícita fora da pista.

Manter as "Explicando decisões implícitas" como parte do Kanban para cada um dos cenários pode ajudar.

O que eu vou sugerir pode ser complicado. Mas se o processo estiver mapeado para um conjunto de itens kanban e se for trazido para o quadro para cada cenário de arco, isso não ajudará a acompanhá-lo. Eu sugiro que você também possa mapeá-los para o modelo de cenário de seis partes e improvisar o quadro Kanban para acomodar as descobertas; os QAs podem ser rastreados.

Vikram.

Esse é um dos riscos de adiar as decisões de arquitetura nas equipes Agile. Obviamente, a coisa mais responsável por ser ágil é adiar as decisões de arquitetura até o último momento responsável . Mas é provável que o último momento responsável possa (ou deva) acontecer desde o início.

Uma coisa que ajuda é delinear claramente cedo seus principais requisitos de direção; coisas que você sabe claramente que deve ter (mas não precisa necessariamente implementar no momento). Sua arquitetura em evolução (que tenta ser minimalista e flexível) deve acomodar o suporte existente ou futuro a esses requisitos.

Mais importante, porém, sua arquitetura em evolução NÃO DEVE implementar artefatos que obtenham (ou possam obter) no caminho de suportar esses requisitos principais de direção, mesmo que esses artefatos sejam destinados à resolução de requisitos atuais. Podemos nos referir a esses artefatos como artefatos interferentes , artefatos que entregam um valor real (à medida que implementam uma solução para os requisitos existentes), mas cuja presença dificulta / onerosa a implementação de um futuro requisito chave de acionamento.

Nos casos em que você deve implementar um artefato interferente, sua tarefa seria planejar sua remoção em algum momento (para que você possa implementar o requisito de acionamento principal que está sendo interferido).

Obviamente, tudo isso é esotérico sem um contexto real e tangível (como um projeto real). Porém, mais ou menos seu modelo de processo de desenvolvimento e sua arquitetura em evolução devem levar essas considerações em consideração.

Os requisitos implícitos acabam com as arquiteturas. Tudo deve ser explicitado, tanto os principais requisitos de direção quanto os auxiliares. Você não precisa implementar um requisito desde o início. Você só precisa poder dar conta disso.

PS. Por requisito, quero dizer requisitos de arquitetura no nível do sistema e não necessariamente os requisitos efêmeros no nível do aplicativo que podem ser acomodados sem alterações substanciais na arquitetura. Espero que ajude.