Ainda não tem acesso? Estude com a gente! Matricule-se
Ainda não tem acesso? Estude com a gente! Matricule-se

Solucionado (ver solução)

Mudança de requisitos toda hora

Professor,

Você citou na primeira aula que "o desenvolvedor não deve se ater apenas ao contrato mas também à conversa com o cliente".

Pois é, na minha opinião não deveria ser assim.

Ele deveria se a ter a um contrato flexível que permitisse uma certa margem para mudanças.

Sim porque garanto que o core do negócio dele não irá mudar do dia pra noite.

O que você acha ?

Na prática, em algum projeto, você já "desrespeitou" algum contrato ?

Obrigado.

3 respostas

Olá Marcelo,

Acredito que isso seja um tópico complicado de se definir certo ou errado, ou preto no branco, podemos usar como guia para entender essa situação o manifesto ágil que define "Indivíduos e interação entre eles mais que processos e ferramentas", "Colaboração com o cliente mais que negociação de contratos" e "Responder a mudanças mais que seguir um plano".

É importante ser flexível para as mudanças, essa é uma vantagem das metodologias ágeis contra as do modelo waterfall.

Na questão do requisito para minimizar este cenário ele deve ser bem levantado e entendido, mas não há como impedir um requisito de mudar, um exemplo legítimo por exemplo ocorreu em uma empresa que trabalho, onde por mudança na legislação e em normas bancárias da FENABAN o sistema de boletos teve seu requisito de emissão de boletos alterado para emitir apenas boletos registados.

Tanto a empresa quanto a própria TI tem que ver a TI como uma área parceira do negócio que tem como principal objetivo gerar valor para o negócio, se a geração de valor irá ocorrer a partir da mudança de algum requisito que seja, seria irresponsável e contra o manifesto ágil defender o plano original sendo que este não mais seria útil.

Um exemplo de onde isto pode ocorrer é dentro de uma Sprint do SCRUM, você pode estar desenvolvendo uma integração com um fornecedor, mas 2 dias adentro da Sprint o negócio rescinde o contrato com o fornecedor por abertura de falência ou quebra contratual ou algum outro motivo irreversível, neste caso que bem para o negócio fará trabalhar nessa integração por mais 5 ou 12 dias para terminar a integração se esta nunca será usada? Dependendo do impacto não seria melhor diminuir esta Sprint após terminar os demais itens?

É claro que esse cenário não quer dizer que as Sprints são inúteis, mas embora o Scrum diga que elas são imutáveis levar isso ao pé da letra pode ser prejudicial para o negócio como um todo e na maioria dos casos quando a empresa tem uma maturidade e um bom alinhamento estratégico dificilmente algo muda do dia para a noite de forma que seja necessário mudar um requisito em andamento.

Olá Rafael,

No caso que você citou da FENABAN , o contrato foi efetivamente alterado ou continuou a mesma coisa ?

solução

Algum input novo ?