Não? Prometa (e cumpra, logicamente) prazos, custos e esforços menores pra ver se ele não topa e beija seus pés. Ofereça a ele time-to-market, ROI, liberdade para mudar de idéia, qualidade, manutebilidade, etc pra ver se ele não solta fogos quando você chegar na empresa dele. Não que isso seja impossível com processos e metodologias engessadas, mas é que é bem mais natural com as ágeis. E não estou querendo dizer de maneira alguma que acho tudo isso uma tarefa fácil; muito pelo contrário. É trabalhoso e pode dar errado se a empresa não estiver preparada. Não tem nada de aventureiro na adoção de metodologias ágeis (muito pelo contrário). Eu estou sentindo isso na pele, agora que estou só tentando falar e disseminar metodologias ágeis aqui na minha empresa (conservadora e tradicionalista).[/quote]
Não consegui seguir seu raciocínio aqui. Você está tendo problemas para disseminar processos ágeis ou estão beijando os seus pés quando você traz as boas novas? Você tem que se aventurar e correr riscos planejados na hora de mudar os seus processos ou não?
A propósito, achei um ensaio relevante aqui: http://www.zedshaw.com/essays/c2i2_hypothesis.html
Na verdade, como alguns já disseram aqui, CMM é garantia que a metologia de desenvolvimento do software é precisa. Mais ou menos assim: se uma fábrica de palitos tem qualidade total, significa que todos seus palitos serão feitos da “mesma” forma e que terá “alguma” forma no controle da qualidade do produto. No caso de palitos, basta comparar (por amostragem) o palito “ideal” com os palitos que estão sendo produzidos.
Já trabalhei em empresa CMM 5 que a qualidade do produto, muito mais difícil que ser averiguado do que no caso do palitos, era jogado para debaixo do tapete.
Para mim, caso de uso descreve a interação do usuário com uma “caixa preta”. Isso, muito se assemelha a um teste de aceitação, que pode ser escrito usando arcabouços de testes unitários, por exemplo.
[quote=rubinelli]
Unit tests podem ser a especificação técnica, se escritos com esse fim em mente. (e aí BDD e os *Spec ajudam bastante)[/quote]
Por favor, fale mais sobre BDD e os *Spec
Na verdade, eu pensei um pouco mais e Behaviour-Driven Development não se encaixa totalmente aí, porque nele (como no TDD) o desenvolvimento dos testes e do código que satisfaz esses testes é um processo bem iterativo. A idéia de testes como especificação seria menos flexível nesse ponto, porque o analista desenvolveria todo um conjunto de testes antes de passá-lo para o programador. Mas ainda assim dá pra adaptar.
Você pode ver um mini-tutorial do GSpec (para Groovy) aqui. Eu acho que não dá para escrever uma interface fluente como essa em Java puro, mas alguém mais cedo ou mais tarde vai tentar. 
Olá Rodrigo,
Os testes unitários garantem que teu software funciona. Ainda, te dá confiança para mudar, visto que, em um projeto de grande escopo, ele te alerta sobre falha em supostas dependências.
Estimativas são feitas quebrando teu sistema em diversos pedaços, adiando decisões mais críticas e entregando sempre releases funcionais. Isto garante boa relação com teu cliente. Ele está vendo que o sistema tá andando e se tiver algo para mudar ele vai se sentir muito a vontade para falar com você (até diretamente)
Testes podem ser gerados muito rapidamente, vide TestNG ou Junit4. Muito mais rápido do que balões e bonecos que eu fazia no jardim da infãncia que descrevem os atores.
O conhecimento é adquirido ao longo do projeto, não através de documentos, pois ele é disseminado entre a equipe constantemente através de conversas informais entre os programados, e ainda vários outros tipos de informação, através do famigerado tracker
Bem, é bom ressaltar que adotar 100% XP não é viável em projetos enormes e equipes muito numerosas.
Cara, na real mesmo, ter o espírito XP te faz um profissional melhor. Se a empresa não adota formalmente, você assumindo atitudes XP naturalmente te fará despontar na empresa onde você trabalha.
Ah, não consegui ver a relação dos testes com casos de uso. Também não vi como comparar CMM5 com XP, Scrum ou Crystal, que seja
Quem contrata uma empresa que usa XP, pensa na qualidade e, ainda, paga por UM SERVIÇO, não por UM PRODUTO.
De qualquer modo, quanto aos prazos, planejamento, etc… Deve-se perceber que a relação com o cliente é outra! Existe um bom senso, claro, mas se teu cliente tá acompanhando o andamento do projeto, recebendo releases funcionais constantemente, está sempre conversando e adaptando o que foi definido no início, etc. Ele estará muito mais propenso a elastecer o prazo de entrega(caso esteja bem definido). É muito normal iniciar um projeto e, ao chegar no fim, o cliente ver que não era bem isso. Quem paga o pato ($$) ? A empresa? Ou deixamos o cliente insatisfeito, um fod@-se literalmente?!!
Quem contrata empresas com tal metodologia deve ter isso em mente.
