Após mais de dois anos de trabalho em uma estrutura de departamento de desenvolvimento altamente isolada, "lobo solitário", estamos adotando o Agile SCRUM. Ótimo. Eu gosto de ágil; como desenvolvedor, ele mantém você concentrado, ocupado e produtivo, sem que inúmeras partes interessadas empurram projetos após projetos, com a expectativa de que todos sejam feitos ontem.
Há, no entanto, um aspecto de mudar para o SCRUM versus o nosso "modelo" atual, que acho que as pessoas fora do Desenvolvimento não vão gostar nem um pouco. Essa é a capacidade atual deles de nos fazer pequenas mudanças "enquanto você espera". Uma grande parte do nosso desenvolvimento é apenas para consumo interno, e estamos todos no mesmo prédio. Por isso, é prática comum há anos que um líder ou gerente de departamento em outro lugar chegue ao "proprietário da base de código" de um aplicativo específico e peça coisas pequenas (às vezes não tão pequenas, mas somos muito bons em não assumir três) projetos semanais baseados nesses "drive-bys"). Até nosso chefe às vezes transmite as coisas trazidas a ele dessa maneira. Muitas vezes, se estivermos trabalhando na base de código em questão no momento, podemos simplesmente exibir o arquivo de origem,
Com uma metodologia básica do Agile SCRUM, esses ajustes seriam registrados como defeitos (não atendemos a um requisito especificado em uma matéria anteriormente consumida) ou novas pequenas histórias (atendemos a todos os requisitos declarados, mas esses requisitos eram incompletos, vagos ou incorretos , ou eles foram alterados após a entrega quando os usuários viram os novos recursos). De qualquer maneira, a grande maioria seria um ponteiros na maioria, se não zero, e de prioridade relativamente baixa (o sistema é utilizável em seu estado atual, mas seria assim muito mais frio se ...), tornando-os pouco provável que seja trouxe um sprint ao trabalhar a lista pendente de cima para baixo.
Essa possibilidade foi levantada em uma reunião de desenvolvimento como uma fonte de oposição ativa ao nosso processo Agile por outros departamentos, que o considerariam menos "ágil" do que nossa capacidade atual de fazer pequenos ajustes, mediante solicitação. É uma preocupação válida IMO; as partes interessadas por trás do OP nem sempre concordam com o que é mais importante, porque nem todas têm o mesmo ponto de vista; no entanto, normalmente são apenas os gerentes que tomam a decisão final e, portanto, seu viés é o que mostra na lista de pendências do produto.
Foi então proposta uma solução, que foi provisoriamente chamada de "jarra de doces" (outro termo descartado foi "molheira"). Pequenos ajustes solicitados pelos "pequenos rapazes" nos vários departamentos, que não são defeitos em uma história existente, estimados por consenso ou aclamação dentro da equipe, levam menos da metade de um dia do desenvolvedor, e isso teria um impacto imediato, significativo e positivo na experiência do usuário, na opinião do usuário final, é colocado em uma lista paralelamente ao backlog principal. Eles seriam identificados como "histórias", mas seriam mantidos separados do backlog principal de histórias "grandes" sujeitas a priorização. Se, a qualquer momento durante o progresso normal de um sprint, estivermos trabalhando em uma área do sistema na qual um desses ajustes pode ser feito, Tornando o ajuste trivial, podemos introduzi-lo no sprint e codificá-lo ao longo da história maior. Fazendo issonão deve comprometer a conclusão de uma história maior ou qualquer outro trabalho comprometido. O PO também teria acesso a essa lista e, se eles estivessem trabalhando em uma história de usuário futura, abordando o recurso básico que envolve o ajuste, eles poderiam dobrá-la na história como um requisito e, em seguida, atenderíamos ao requisito como qualquer outro de outros. Pensou-se que isso aumentaria a probabilidade de ajustes mais cedo ou mais tarde.
Isso desencadeou a reação entre nós com o treinamento ScrumMaster de "uh-uh". Há uma lista de pendências. Dois atrasos introduzem a questão de qual item nº 1 é realmente o mais importante, quais itens da lista determinam a velocidade real e em qual dos dois atrasos uma história realmente pertence (qualquer demarcação de tamanho / complexidade terá alguns casos que caem relativamente arbitrariamente para um lado ou para o outro). "Deixe o processo funcionar", dissemos; se a mudança for realmente significativa para os usuários finais, eles farão barulho suficiente para que os chefes de departamento tomem decisões de tempo / dinheiro a bordo, e isso trará à consciência da equipe de desenvolvimento o topo da lista de pendências.
Pensei em colocar a pergunta no plenário: na sua opinião, uma lista paralela de histórias "pequenas" teria valor em obter mudanças pequenas, úteis, mas, em última análise, de baixa prioridade, mais rápidas ou, em geral, é uma decisão melhor dobrá-los no backlog principal e deixar que o processo básico governe sua inclusão em um sprint?