Em que nível de PBI devo criar ramificações?

5

Eu cometi o erro de criar ramificações no nível de história do usuário. Consulte: Histórias do usuário! = Recursos .

Acredito que tenho feito dessa forma por causa da minha má prática na organização de Features e Epics, que são postagens organizacionais permanentes e realmente apenas para as histórias subjacentes ( EG. Improve Homepage \ Como um anunciante,. .. ).

Qual é a melhor maneira de criar epopeias e recursos?

.

Como venho usando o Epics and Features para organizar o backlog, meus colegas de trabalho & Eu tenho usado eles para determinar onde criar histórias de usuário. O problema com isso, creio eu, é mais do que ter apenas Estórias de Usuário órfãs, as quais eu, como designer, deveria estar determinando sob as quais as reportagens pertencem. Isso criou um fenômeno no qual as Estórias de Usuário são duplicadas porque o criador não percebe que já existe em um "Recurso" diferente.

Então, devo solicitar que as Estórias de Usuário sejam criadas como órfãs depois, determinando sob qual característica elas pertencem? Em vez de permitir que os proprietários de produtos decidam sob qual característica uma estória pertence.

.

Um medo adicional que tenho dessa mudança no planejamento é desenvolver com base nas Estórias de Usuário movidas com bastante rapidez, mesclando a ramificação Story na ramificação Main quando concluída e depois implantando.

Ainda posso manter implantações rápidas ao trabalhar com um ramo de recursos em vez de um ramo de história, fundindo-se com o principal no "fim" de cada história e continuando para a próxima história no ramo de recursos?

Além disso, talvez um método mais direto e poderoso, um exemplo, neste caso, pode fornecer mais contexto do que todas as respostas anteriores.

Forneça um exemplo real de uma ramificação e quaisquer Histórias, Recursos, Tarefas e épicos contidos em seus projetos de desenvolvimento do mundo real.

.

Aqui está um diagrama simulado do meu backlog

  • (E-#) Epic
    • (F-#) Feature
      • (S-#) Story | (B-#) BUG
        • (T-#) Task
  • (E-1) Sitewide Improvements
    • (F-2) CMS
      • (S-3) As a developer, I want to audit @inherits on cshtml pages, and see how I can better use Strongly Typing pages
      • (S-4) Upgrade to CMS Version 7.5.8
        • (T-5) backup
        • (T-6) Nuget upgrade
        • (T-7) run upgrader
        • (T-8) merge config files
  • (E-9) Improve Public facing site
    • (F-10) Improve Homepage
      • (S-11) As an advertiser, I want my ads to show on the homepage, so my ad have better visibility
    • (F-12) Improve Reviews
      • (S-13) As a traveler, I want to be able to sort reviews by # of stars, so I can look at reviews with the # I am interested in
        • (T-14) Create a sorting logic in a function to accomplish this
        • (T-15) Create the proper UX to request sorting
      • (S-16) As a traveler, I don't want to see old reviews, as they don't represent well
    • (F-17) Improve Articles Page
      • (S-18) As a reader, I want to articles tagged, so that I can view other articles with tags I am interested in.
  • (E-19) Improve Client backend portal site
    • (F-20) Account Management
      • (S-21) As a portal user, I want notification to be emailed to me, so that I know what is happening
    • (F-22) Ad Manager
      • (S-23) As an advertiser, I want to set budgets on a per advertisment basis, so that I can have greater control.
      • (S-24) As an advertiser, I want to be able to upload my on images, so that I can better customize my ads.
    • (F-25) Billing Manager
      • (S-26) As an portal admin, I want to be able to see past statements, so I can understand past charges.
    
por Devin Gleason Lambert 20.02.2017 / 20:19
fonte

1 resposta

5

Parece que você está combinando várias coisas que devem ficar separadas.

Primeiramente: sua estratégia de ramificação e sua estrutura de divisão de item de trabalho não precisam corresponder. A estratégia de ramificação deve ser usada como suporte para comunicar como você chegou ao código-fonte que você possui, mas isso não deve ter sido feito seguindo a divisão do item de trabalho.

Segundo: as histórias e os recursos do usuário não são necessariamente a granularidade na qual você implanta novas versões. Você pode precisar de um épico inteiro ou até mesmo vários épicos implementados antes de lançar uma nova versão para os clientes. Isso não significa que você precisa manter um ramo separado durante toda a implementação dessa epopeia; você pode muito bem querer lançamentos internos com muito mais freqüência, então você precisa se integrar regularmente. Isto é ajudado usando, e. recurso alterna.

Terceiro: a estrutura analítica do item de trabalho não é o melhor repositório para codificar o conhecimento de quais recursos foram implementados. Seria sensato, por exemplo, mantenha um documento na sua árvore de fontes que descreva todas as histórias de usuários que foram implementadas. Manter esse documento legível e bem organizado faz parte do seu trabalho de desenvolvimento e ajuda a responder à pergunta "como essa história de usuário se encaixa no resto do programa?", Com a qual você também parece se esforçar. Observe que não é ruim ter a mesma história de usuário em vários itens de trabalho; isso significa apenas que você vê que essa história de usuário precisa funcionar por vários motivos. Também pode ser que as ocorrências da mesma história de usuário sejam separadas no tempo por meses ... nesse caso, um documento em sua árvore de origem é muito preferível em relação ao histórico de itens de trabalho trabalhados. Para extras, você pode automatizar a verificação das histórias do usuário para que o documento se transforme em documentação viva.

Espero que isso limpe um pouco as coisas.

Uma coisa digna de nota é que você parece misturar níveis de abstração em seu backlog de produto; tentar manter o valor em mente ao escrever as histórias do usuário ajuda a evitar essa armadilha, e uma maneira de fazer isso é estourar a pilha do porquê. Por exemplo. no caso de "Como administrador do portal, quero poder ver as declarações anteriores, para que eu possa entender as cobranças anteriores", pergunte "Por que quero entender as cobranças anteriores?", e assim por diante, até o valor fornecida é cristalina.

    
por 20.02.2017 / 21:56
fonte