Solucionado
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.
hoje, com a Alura e o Google Gemini
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 ?
Algum input novo ?