Se a definição de pronto não é avançada a ponto de estar em produção, como lidar com as tarefas restantes que podem consumir tempo na próxima sprint? Como explicar para o usuário que a tarefa esta pronta, mas ainda vamos gastar tempo na próxima sprint seja porque um deploy pode levar mais tempo, por ser complexo, envolver diversos serviços, popular uma tabela nova com uma quantidade absurda de dados e que pode levar dias de um desenvolvedor acompanhando o processo até estar em produção? Criar tarefas de deploy e estimar? Deixar claro para o cliente que no final da sprint ele não vai poder usar a feature nova, somente na próxima? Ou devemos desvincular essa imagem de entregar valor é apenas quando o cliente final pode usar aquilo que foi entregue?
1
resposta
resposta
Se pronto não é em produção, como lidar com os possives problemas que podem surgir?
Ulysses, as definições de pronto podem variar. É questão de combinar (só não pode fazer uma que não inclua a parte de testes, por exemplo, pois aí ficaria muito pobre). Um esquema comum é fazer a definição de pronto chegar até o ambiente de homologação somente, e de tempos em tempos haver deploys para produção, contemplando os itens prontos e homologados de alguns sprints. Em situações onde há efetiva entrega em produção a cada sprint, pode fazer sentido fazer a definição de pronto chegar até o ambiente de produção então.