Minha dúvida: a equipe de desenvolvimento deve ser blindada durante uma Sprint. Ok. Nessa questão, entendi que, digamos, o as tarefas que serão desenvolvidas deverão ser cumpridas. Isso também está ok. Porém se, digamos, numa Sprint de 4 semanas, no início da segunda semana da Sprint o cliente chega e quer mudar uma funcionalidade, porque percebeu que ela esta errada. Que não era bem aquilo que ele está precisando. Mesmo assim essa mudança não poderá ser inserida na Sprint? Ou seja: a funcionalidade será construida de forma errada, para depois ser corrigida? Isso não irá gerar retrabalho, de algo que poderia ser evitado.? Ou essa funcionalidade (tarefa) deverá ser abortada? Mas, ela sendo a equipe deixará de estar blindada?
1
resposta
resposta
Blindagem da Sprint
Processos de desenvolvimento Scrum são projetos pra aceitar mudanças. Uma vez aceito isso, o importante aqui é entender o COMO aceitar essa mudança. Primeiramente, vale pontuar que é o PO quem vai analisar a funcionalidade, entender a criticidade a ponto de excluir o desenvolvimento dessa funcionalidade específica nessa Sprint ou até cancelar a Sprint.
Mas o ponto aqui é, NÃO, você não estará deixando seu time descoberto, pois o que você está trazendo como exemplo faz parte do gerenciamento de mudanças. Gerenciar mudanças é natural, faz parte e é esperado.
-> Responder a mudanças, ao invés de seguir um plano.
Blindar o time é não permitir o time trabalhar em nada que não seja aquilo que o PO priorizou e que o time acordou e estimou numa planning. Blindar um time significa que, se um Diretor, CIO, CEO solicitar qualquer coisa diretamente ao time, peça-o para falar com o PO, para que o mesmo possa coletar a necessidade e priorizar a demanda.
RESUMINDO: O time não trabalha em nada além daquilo que o PO prioriza e o SM mantém o curso assim