@ Joe "Somos uma loja" Agile ", então entendo que devemos ajustar o que não é, mas às vezes a mudança é grande e nada trivial".
Se o seu processo não permitir que você controle a taxa de alteração nos requisitos, ele não é ágil, mas aleatório. Agile não significa "pegar qualquer coisa que aparecer no meu caminho".
Para controlar a alteração / fluência de requisitos, você pode adotar - em seu processo - a noção de que um requisito não muda (uma noção de que está no coração do Scrum.) Trate uma alteração de requisito como substituindo um requisito antigo por um novo. Você precisa ter uma lista de requisitos e o usuário deve escolher quais deseja implementar.
Você queria X e Y em duas semanas, mas de repente você quer Z. Bem, então eu posso entregar todos os três em quatro semanas. Ou posso dar um par (X e Z) ou (X e Y) ou (Y e Z) em duas semanas e entregar o restante mais tarde. Escolher.
É assim que você negocia com os clientes. É assim que você comunica o custo da mudança de requisitos. Se o seu grupo não tem esse poder, você não está em uma loja ágil e não há nada que possa fazer. É péssimo, mas é verdade.
Caso você possa negociar, é necessário rastrear (com precisão) o tempo necessário para implementar requisitos e alterações de requisitos. Ou seja, você precisa coletar esses dados de projetos passados e presentes.
Você coleta a estimativa de tempo original e o tempo real de conclusão (além de recursos como a contagem de desenvolvedores) por solicitação (ou módulo afetado por N solicitações). Melhor ainda, estimar o tamanho da solicitação / alteração de solicitação (em termos de linhas de código ou pontos de função em projetos e solicitações anteriores).
Digamos que você tenha uma métrica com a qual possa conversar com o usuário. Você sabe que uma nova solicitação terá, digamos, 1K linhas de código ou 10 páginas da Web com uma média de 5 campos de entrada cada (50 pontos de função).
Depois, analisando dados históricos específicos de seus projetos anteriores (alguns por linhas de códigos, outros por páginas da Web, outros por pontos de função reais), e você pode estimar como cada um deles custa em termos de tempo absoluto de conclusão. Para aqueles com dados suficientes, você também pode identificar os requisitos que acompanham uma contagem real de desenvolvedores.
Então você usa isso e diz ao cliente que com base em dados históricos; você argumenta que as falhas do projeto tendem a seguir uma distribuição exponencial; e então você está armado com o seguinte argumento para seu cliente:
Com base nos dados de nossos projetos passados e presentes e nos recursos disponíveis, o requisito que você está solicitando terá
X tempo para concluir com uma probabilidade de falha de 25% (ou 75% de sucesso)
1,5 * X tempo para concluir com 5% de falha (ou 95% de sucesso)
0,5 * X quantidade de tempo para concluir com 95% de falha (ou 5% de sucesso)
A probabilidade de falha em função da quantidade de tempo que os recursos costumam atingir 95%, 25% e 5% (semelhante a uma distribuição exponencial). Você transmite a mensagem de que uma certa quantia da linha de base oferece uma chance um tanto decente de sucesso (mas com riscos reais ) 1,5 disso pode dar quase uma certa chance de sucesso com risco mínimo, mas muito menos do que isso (0,5 do original garante quase certa falha).
Você os deixa digerir sobre isso. Se eles ainda optarem pela proposição arriscada ( feita ontem! ), Pelo menos você tem por escrito que disse isso a eles. Se houver esperança de que seu grupo não seja apenas ágil, mas de engenharia, o cliente poderá considerar seriamente seus números e agendar essas e futuras solicitações de acordo.
É seu trabalho como engenheiro explicar em termos engenheiro, verificáveis e claros que solicitam alterações não são refeições gratuitas.