Como você demonstra um software sem interface de usuário na Sprint Review?

Estamos desenvolvendo software ágil, basicamente seguindo o Scrum. Estamos tentando fazer revisões de sprint, mas achamos difícil. Nosso software está processando muito dados e as histórias costumam mudar várias regras.

Quais são algumas opções para demonstrar as alterações que ocorreram no sprint quando não há uma alteração na interface do usuário ou no fluxo de trabalho visível, mas a alteração é uma regra de negócios sutil em um trabalho de processamento que pode levar 10 segundos ou até algumas horas ?

Durante o sprint, você cria valor. Sempre há alguma diferença entre o que você tinha no início e no final do sprint. Normalmente, mesmo de uma maneira perceptível pelo cliente. Então apenas mostre a diferença.

em alguns casos, o sprint lida com descobertas ou reorganizações internas que podem parecer sutis, mas você deve ser capaz de mostrar a diferença e explicar ao público por que você acha que é bom e qual é o benefício de todo o esforço envidado. Na esquina, você pode consultar Edison, que descobriu mais de mil maneiras de como NÃO é possível fazer uma lâmpada funcionar.)

Se o processamento real demorar, não há problema em mostrar um vídeo com zíper ou apenas uma tabela de figuras. Ou saída pré-coletada de resultados.

Minha preferência pessoal por coisas que funcionam de back-end é encontrar a alteração do usuário final. Se os dados que você está processando acabarem em um relatório, mostre as diferenças antes / depois no relatório.

Estou assumindo que o desejo pela mudança veio de uma necessidade. Qual foi o problema que desencadeou a necessidade de fazer a história? O 'formulário de voz' da sua história de usuário deve indicar como você poderá demonstrar o problema agindo como o usuário da sua história (por exemplo, como Joanne, preciso visualizar o relatório sem os usuários que estão na Europa).

Além disso, você pode procurar sua equipe de teste para ajudá-lo nesse caso. Deve ter havido alguma maneira de a equipe de teste ter sido capaz de verificar se a história foi concluída. Como eles fizeram isso? Você é capaz de mostrar esse processo na demonstração?

Como você sabe que um recurso está funcionando? Quando você o implanta, como garantir que ele realmente funcione?

Se você não conseguir responder a essas perguntas, terá problemas maiores do que uma Revisão da Sprint. Você deve poder mostrar isso na sua demonstração.

No Scrum, durante uma demonstração, o Dono do produto revisa cada uma das histórias em desenvolvimento e as aceita ou as devolve ao desenvolvimento. Você precisa provar que um recurso está funcionando; isso normalmente é melhor feito com um teste automatizado. Você pode escolher os testes automatizados que correspondem aos testes de aceitação e destacar as principais alterações?

O Dono do produto também deve poder ajudar; eles devem ter um entendimento detalhado do produto em desenvolvimento. Eles não precisam entender os detalhes completos da implementação, mas precisam compreendê-los bem o suficiente para poderem defender uma explicação do objetivo (ou valor comercial) de cada recurso. Afinal, o Product Owner é a pessoa que pediu para você implementar a história em primeiro lugar!

Uma opção que considero potencialmente satisfatória para os negócios (BSA, BA, gerentes e outros) é fornecer uma apresentação de cinco a dez slides sobre o que era esperado e o que foi realizado. E, se houver um método significativo de exibir os resultados do trabalho realizado, como um despejo de dados ou resultados de consultas SQL e tempo para explicá-los um pouco, acho que as partes interessadas geralmente ficam satisfeitas.

Muitas vezes, é difícil fornecer uma demonstração significativa para não programadores / equipe não técnica em sistemas do tipo back-end. Eu tentei o exposto algumas vezes e sinto que as partes interessadas estavam mais satisfeitas em sua resposta do que quando eu simplesmente executei o software e mostrei os resultados.

Concedido no entanto, isso pode ser mais trabalho do que vale a pena para você. Você precisará ponderar o benefício e o trabalho necessário para que isso aconteça.

Você pode usar o powerpoint ou algo gráfico para transmitir a mudança. Por exemplo, se houver uma regra comercial adicionada que dependa do valor em uma célula de uma planilha, você poderá mostrar qual célula é e explicar como foi alterada.

Se houver várias alterações de back-end, nenhuma alteração na interface do usuário, basta percorrer a lista que a explica e mostrar uma alteração geral. Se você pode criar um gráfico ou gráfico que destaque as diferenças, isso pode ser suficiente. Pisque algumas alterações de código ou uma lista de alterações / confirmações trabalhadas no sprint.

Se sua alteração for "back-end", provavelmente haverá uma interface de usuário definitiva em que as alterações se manifestem. Você pode mostrar isso. Minha equipe não gosta de fazer isso porque não "possui" esse sistema, mas no final do dia, se é assim que seus clientes interagem com suas alterações, você precisa estar ciente dessa interface do usuário e conhecê-la bem o suficiente para mostrar o produto acabado.