Como modelar a preparação de histórias para problemas abordados em vários projetos

Em nossa empresa, várias equipes trabalharão em diferentes componentes de vários projetos ao mesmo tempo. Por exemplo, uma equipe pode criar tipos específicos de software (ou hardware) para alguns projetos, outra equipe outro tipo específico de software. Usamos os projetos Jira para hospedar problemas para projetos específicos e os painéis Jira para sprints para diferentes equipes.

Enfrentamos o problema de evitar a duplicação de código nos projetos e desenvolvemos um conjunto de bibliotecas principais que usamos nesses projetos. Enquanto estiver trabalhando em um projeto, alguns desenvolvedores perceberão que um pedaço de código que eles escreveram é de maior interesse e deve ser extraído em uma biblioteca principal, ou que algum código principal que eles estão usando possui um erro, precisa de mais parametrização ou novo recurso ... o nome dele.

Portanto, eles criam um problema de biblioteca principal que entra no backlog do projeto principal. Todas essas questões são revisadas, priorizadas e estimadas em uma reunião central da biblioteca (uma vez por semana) e serão abordadas de acordo com a prioridade (ao lado de questões específicas do projeto) em alguns sprints futuros.

A priorização é feita através da classificação dos problemas e colocamos um sortedrótulo nos problemas classificados (para que possamos procurar por não classificados). Em seguida, colocamos manualmente um problema por componente principal no topo da lista de pendências para que eles sejam solucionados primeiro. Quando uma equipe coloca esse problema em seu sprint, eles precisam arrastar manualmente outro item para o topo da lista de pendências.

Isso é bastante propenso a erros. Basicamente, o que temos são os status de problemas adicionais "classificados" e "estimados" entre "aberto" e "em andamento". Refletir isso através do sortedrótulo e sua posição no quadro é bastante complicado e propenso a erros. (Por exemplo, se alguém mover um problema para cima e para baixo, isso será refletido no quadro principal, misturando silenciosamente a ordem dos problemas que a equipe poderia ter decidido em uma extensa discussão semanas antes.)

Então, qual seria a melhor maneira de implementar isso?

Se você deseja acompanhar isso no JIRA, eu o seguiria como se fosse uma nova tarefa.

Então, por exemplo:

Digamos que você tenha a história CORE-75: Foo the Bar .

Uma vez decidido qual equipe executará a tarefa, eles poderão criar uma nova tarefa: SUPPORT-123: Foo the Bar in Core .

Você pode então bloquear o CORE-75 com SUPPORT-123 . Quando o SUPPORT-123 terminar, você poderá voltar ao CORE-75 . Você pode mesclar as revisões ou revisar o código duas vezes (uma vez pela equipe designada, uma vez por uma equipe mais específica do núcleo).

É realmente o que você está fazendo de qualquer maneira: considere a biblioteca principal como seu próprio produto / cliente, não siga pela metade.

Uma abordagem é a equipe criar um novo problema para seu sprint, vinculado ao problema principal da biblioteca. É como se você estivesse fazendo uma subtarefa para uma tarefa, mas entre os quadros / pendências.

Outra abordagem é apenas rastrear isso separadamente fora do JIRA. Exporte o backlog existente como CSV ou planilha e organize-o.

Ao separar os problemas do JIRA, você tem flexibilidade para definir a prioridade na reunião de planejamento e não precisa se preocupar com o algoritmo de classificação do JIRA nos quadros e também não precisará usar rótulos.

Na reunião de planejamento de priorização da biblioteca principal, você pode criar uma lista restrita de tarefas a serem concluídas para a biblioteca principal e quem for responsável / responsável pela biblioteca principal pode garantir que essas tarefas sejam iniciadas pelas diferentes equipes do projeto e concluídas.

Há uma visão de que as principais bibliotecas que encapsulam muitas das funções comuns, mas não relacionadas, são uma 'coisa ruim' (tm)

Existem algumas razões para isso

• Eles puxam dependências e códigos que você não precisa
• Mudá-los causa alterações em todos os aplicativos
• Nenhum 'proprietário' único

No seu caso, acho que sua divisão de tarefas pelo aplicativo em que a alteração seria feita é a raiz do problema. Uma espécie de lei inversa de Conway.

Eu acho que a melhor solução para você seria deixar de ter 'Bibliotecas principais'. As bibliotecas devem ter um conjunto (pequeno) específico de funcionalidade agrupada logicamente. Deve ser possível completá-los. ou seja, JsonParser, LogWriter etc, raramente faz sentido adicionar um novo recurso.

No entanto, assumindo que essa seria uma tarefa longa e difícil, como solução secundária eu simplesmente manteria as tarefas principais da biblioteca com a equipe que precisa da funcionalidade. ie

Tarefa: adicionar o recurso X ao produto Y

Dev: hmm, parte do código do recurso X deve estar em uma biblioteca de corel .. vou colocá-lo lá como parte desta tarefa