[quote=Gerente]
escrever catálogo de requerimentos é como um jogo de xadrez, você tem que fechar tudo o máximo possível para o cliente não te dar um xeque-mate[/quote]
Acabo de ouvir isso. Que tal? Essa é a realidade que todos vivem?
(ps: um dia eu aidna escrevo um título de topico corretamente 
)
Creio que sim, mas e se ao invés de trabalhar com escopos fechados, trabalhar-se com escopos menos fechados? partes de um todo? creio que seria melhor, além de mais dinâmico, poderá antecipar falhas. fechar todo o escopo é praticamente impossível.
Ele tá muito defensivo ou assustado. Não é assim também…
(se bem que depende do gerente e, principalmente, do cliente :roll: )
[quote=MarcioTavares]
(se bem que depende do gerente e, principalmente, do cliente :roll: )[/quote]
E também de quem está levantando os requisistos não??? Se o cara estiver boiando no assunto a coisa piora ainda mais.
Na minha opinião o analista tem que chegar na hora de levantar os requisitos com um pré-estudo do que será levantado, não? Para poder realmente discutir o assunto.
Vc erra assim na hora de codificar tb???
[quote=fzampa]
Vc erra assim na hora de codificar tb???[/quote]
Zahl save ctrl+espaço 
Olá
Está correto e é assim mesmo que funciona, a menos que o projeto seja usando XP e o cliente concorde com isto.
Acrescento mais, antes de fechar os requisitos, é sempre bom dar uma enxugada. Retirar as perfumarias prometidas ao cliente em devaneios durante alguma reunião mas que na verdade não fazem parte do principal foco do projeto mas que podem acarretar riscos no prazo. Não é trabalhar com escopo fechado mas combinar com o cliente o que realmente ele precisa e faze-lo entender que é isto que ele está pagando.
O escopo pode abrir durante o projeto mas se o cliente sabe que o projeto está sendo alterado fica mais fácil cobrar por isto.
[]s
Luca
Oi,
[quote=Luca]
O escopo pode abrir durante o projeto mas se o cliente sabe que o projeto está sendo alterado fica mais fácil cobrar por isto. [/quote]
Mesmo que não se esteja oficialmente utilizando uma metodologia ágil, assinar contrato com sangue não ajuda muito a viver em paz com o cliente.
Fechar o escopo dessa maneira é se negar a oferecer o cliente o que ele quer, e ele só sabe o que vai querer conforme as coisas vão andando. Terminar no prazo e no orçamento (o que nós sabemos que não acontece de qualquer jeito) um sistema que o cliente requisitou quando nem sabia o que queria só pra fazer a consultoria faturar rápido não costuma deixar clientes satisfeitos.
Claro que muitos clientes querem se aproveitar de cada brecha num contrato para fazer o que quiser com menos esforço, mas contratos com escopo flexível, que agradem ambas as partes, não precisam ser lacrados num cofre em Genebra, basta ser bem redigido e que ambos tenham consciência do que estão fazendo.
Essa pressa de entregar o mínimo possível, mesmo que não seja o que o cliente espera (porque ele só descobriu o que esperar agora!) me frusta bastante. De que adianta implementar cada folinha daquele catálogo de 1000 requisitos se no meio do caminho o cliente não quer mais nada daquilo, só vai aceitar porque já pagou e vai encostar num canto (“fazendo testes internos”) enquanto muda os requisitos na segunda “fase de análise”.
Se for possível, Contrato de Escopo Variável, se não der (e quase nunca dá) pelo menos alguém com uma cabeça que permita saber que a relação visa produzir mais dinheiro para ambas as empresas, o cliente quer usar o sistema, nós queremos entregar o sistema e continuar fazendo sistemas. Gerenciar mudanças não é tão complicado se bem organizado e metótico.
O que eu vejo acontecer demais é alguém fazer um “tabuleiro de xadrez” tão bem amarrado no catálogo de requisitos que depois que se descobre que para implementar aquilo é impraticável (claro, foi o “analista” que fez o catálogo em dois meses trancado no cliente), e não se tem para onde fugir.
Tenha escopo fechado se precisar/quiser/gostar, mas não tenha escopo sagrado. Preocupe-se em entregar valor, não binários.
[]s
O problema é que os donos do dinheiro só aceitaram uma parte da diferença entre engenharia de software e civil.
Primeiro, com escopo fixo e bem definido é muito facil calcular custos e prazo, o pessoal da construção civil faz isso muito bem. O problema é que a “engenharia de software” é alguns séculos mais nova, isso significa que sabemos muito menos de como funcionam os processos de produção de software.
Segundo, de forma antagônica a construção civil, mudar um software no meio do caminho é factivel; mas ninguém começa fazendo um prédio e termina com uma ponte.
Ai vem o grande problema, todos querem comprar como se fosse um prédio, mas que seja executado com toda flexibilidade.
Eu acredito que escopo fechado seja possivel, custa muito caro, pois é preciso gastar muito tempo com documentação e análise.
Mas vale lembrar que em alguns casos o modelo agil poder ser mais caro e demorado que o modelo waterfall. Com sistemas legados, mainframes por exemplo, não ter um escopo entalhado na pedra antes de começar a programar e ter um processo rigoso de verificação e inspeção de código antes de ir testar, significa um custo muito grande, já que o ambiente de execução custa CARO, um desktop custa energia elétrica e espaço, um mainframe custa por MIPS/transação.
Escopos fechados são muito mais legal para o pessoal da área financeira. Pergunta para eles qual área é melhor de orçar, material de escritorio ou sinistros envolvendo funcionarios.
Por isso que a parte mais dificil do XP não é convencer o gerente sobre pair programming, gastar 10mil com servidores de integração continuada ou nunca quebrar as 40horas semanais, mas sim criar a coragem nele e no cliente. Ganhar a confiança.
Eu acho que metodologias ageis é algo tão fora da realidade brasileira para empresas de medio porte em dia. Outro dia mesmo eu estava tentando explicar a algumas pessoas que refactoring não é retrabalho, que TDD não é só “faça a coisa mais porca que possivelmente funcione” e a relação das duas levando ao mesmo resultado que toneladas de horas de design só que com menor margem de erro.