Agile CMM

This message was edited 2 times. Last update was at 24/11/2007 00:43:36

seufagner wrote: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.

Bom, acho que podemos e devemos competir com empresas que vendem produtos (e não apenas serviços).

Acho que é legal, para o acionista da empresa, ter a estimativa do custo de um projeto (mesmo que seja em ordem de grandeza). As metodologias tradicionais utilizam a especificação de requisitos para fazer tais estimativas. Mas fazem do jeito delas (caso de uso, etc). Não considero isso nem de longe a maneira mais eficiente (ou precisa) de fazer estimativas.

Não acho que devemos abandonar todas práticas ágeis porque queremos algum tipo de estimativa!

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Sei que quem usa as metodologias ágeis vendem PRODUTOS e não serviços. Clientes de software nunca estão interessados em adquirir SERVIÇOS e sim PRODUTOS. O cara te contrata para que você entregue um sistema funcionando e um sistema é um produto.

MAs voltando à questão de Agile com CMM, isso é muito possível sim. A powerlogic, empresa baseada em OpenSource 2.0 utiliza Scrum e conseguiu certificação em MpsBR. Aliás, a Isabella que foi uma das pessoas responsáveis pelo processo de certificação escreveu um artigo que sairá na revista visão ágil agora no início de Dezembro. Acho que vai ajudar bastante nessa questão.

Vale lembrar que o CMM não apenas exige comprovação de qualidade do software como no caso dos testes e sim todo um workflow definido e bem etruturado, combrindo possíveis brechas para bad smells no projeto.

JavaEvangelist Membro desde: 26/04/2005 11:18:25 Mensagens: 469 Offline

Eu tenho a impressão de que os maiores obstáculos para integrar metodologias ágeis e CMM não são procedurais, e sim culturais e mercadológicos. O cliente que procura uma consultoria com CMM(i) 5 quer um processo de engenharia de software padrão, bem definido, com requisitos entrando de um lado e software saindo do outro. Ele não quer se preocupar se a fábrica de software fica na Birmânia ou na Patagônia, ou se emprega cérebros super-inteligentes em soluções eletrolíticas ou macacos treinados. O selo CMM 5 é a garantia que vai sair software do outro lado nas condições estipuladas.

O cliente que fecha um projeto com uma metodologia ágil, por outro lado, é mais aventureiro. Pra começar, porque em vez de mandar uma RFP e receber uma estimativa de "9 meses, 370 mil reais", ele trabalha num nível muito maior de imprecisão no começo. Um projeto ágil exige muito mais interação com o cliente, e de novo pode não ser o que alguém que compra uma solução de outsourcing está procurando.

Agora, quanto a outra discussão que se formou, minha posição é que testes não substituem de maneira alguma casos de uso. Casos de uso são ideais para a especificação funcional, porque contam uma história em vez de serem um apanhado de pré e pós condições sem um fio condutor. Unit tests podem ser a especificação técnica, se escritos com esse fim em mente. (e aí BDD e os *Spec ajudam bastante)

Debugger Membro desde: 23/06/2006 08:53:26 Mensagens: 72 Offline

rubinelli wrote:O cliente que procura uma consultoria com CMM(i) 5 quer um processo de engenharia de software padrão, bem definido, com requisitos entrando de um lado e software saindo do outro.

Bem, até onde eu sei, os clientes que procuram empresas que utilizam desenvolvimento Ágil também querem funcionalidades entrando de um lado e software saindo de outro (constantemente). Além disso, o processo de desenvolvimento de software Ágil é bem definido, a diferença é que ele não é estático, ele está melhorando continuamente.

rubinelli wrote:O selo CMM 5 é a garantia que vai sair software do outro lado nas condições estipuladas.

O selo é garantia que o software vai sair na condições estipuladas... mas qualquer necessidade fora das estipuladas, não serão garantidas.

rubinelli wrote:O cliente que fecha um projeto com uma metodologia ágil, por outro lado, é mais aventureiro. Pra começar, porque em vez de mandar uma RFP e receber uma estimativa de "9 meses, 370 mil reais", ele trabalha num nível muito maior de imprecisão no começo.

Aventureiro é boa

A maior parte dos clientes não gosta de gastar dinheiro em projetos "aventureiros"...
Além disso, porque um projeto Ágil não fornece uma estimativa de "9 meses e 370 mil reais" ? Nem todo projeto Ágil é feito com escopo aberto (IMHO, somente a minoria é). Desenvolvimento Ágil não encontra nenhum problema em estimar e definir um preço e um prazo para um projeto.
E sobre a imprecisão... tem muito projeto preciso por aí que está completamente perdido.

Terminando, as empresas que costumam se adaptar melhor ao desenvolvimento Ágil, são as empresas CMMi nível 5, elas já estão no patamar de melhoria contínua.

JavaEvangelist Membro desde: 26/04/2005 11:18:25 Mensagens: 469 Offline

mueller wrote:Bem, até onde eu sei, os clientes que procuram empresas que utilizam desenvolvimento Ágil também querem funcionalidades entrando de um lado e software saindo de outro (constantemente). Além disso, o processo de desenvolvimento de software Ágil é bem definido, a diferença é que ele não é estático, ele está melhorando continuamente.

A diferença é que o cliente de outsourcing que paga por uma consultoria CMM 5 quer uma caixa preta, e não é isso que, por definição, ele tem num processo ágil. Se você não tem o envolvimento constante do cliente, então não pode dizer que o seu processo é ágil.

mueller wrote:

rubinelli wrote:O selo CMM 5 é a garantia que vai sair software do outro lado nas condições estipuladas.

O selo é garantia que o software vai sair na condições estipuladas... mas qualquer necessidade fora das estipuladas, não serão garantidas.

A bem da verdade, o selo não é nem isso. Ele é como o selo do Ministério da Saúde no seu pacote de salsichas ou na caixinha de leite, um motivo reconfortante para não se preocupar como as coisas são feitas e assumir que estão sendo feitas com um mínimo de qualidade. Só que a verificação é feita periodicamente e por amostragem, e nessas você toma leite com água oxigenada e soda cáustica sem saber.

mueller wrote:Aventureiro é boa
A maior parte dos clientes não gosta de gastar dinheiro em projetos "aventureiros"...

Ok, não foi uma boa escolha de palavra.

O que eu quis dizer é que por mais que ágil tenha se tornado uma buzzword, os princípios por trás das metodologias ágeis ainda não são bem difundidos no mercado, então um cliente conservador não vai topar. Aliás, grandes clientes têm suas próprias metodologias, e se você não produz a documentação que eles pedem, não chega nem a concorrer.

Agora, concordo completamente com você quando diz que números precisos não são de maneira alguma necessariamente exatos. Se uma empresa faz uma oferta fixa desse tipo, ou está aceitando um risco calculado, ou está demonstrando que ninguém ali tem a menor idéia do que está fazendo. Esperamos que com CMM 5 trate-se do primeiro caso.

Para terminar, uma idéia que eu deixei de fora do meu primeiro post é essa: eu não vejo esses dois mundos se encontrando tão cedo, porque a ideologia por trás dos dois é completamente oposta. A resposta do movimento de Engenharia de Software para o aumento da complexidade dos projetos é tirar o foco em "heróis", porque heroísmo não funciona em escala, e criar processos que permitam que uma equipe de 50, 100 pessoas continuem funcionando. A resposta dos movimentos ágeis é quebrar o projeto em ciclos de cerca de um mês, para evitar o overhead de comunicação que um time grande traz.

rubinelli wrote:
Aliás, grandes clientes têm suas próprias metodologias, e se você não produz a documentação que eles pedem, não chega nem a concorrer.

É verdade. Isso acontece com certeza numa como Petrobras onde se exige que você preencha os documentos do processo dela e inclusive as tarefas de qualidade. Se brincar, exige até que você use os frameworks e classes reutilizáveis dela em dentrimento dos seus.

Não é fácil trabalhar com licitações, embora sejam grandes fontes de renda para empresas de software.

This message was edited 1 time. Last update was at 26/11/2007 14:02:45

feliperod wrote:
MAs voltando à questão de Agile com CMM, isso é muito possível sim. A powerlogic, empresa baseada em OpenSource 2.0 utiliza Scrum e conseguiu certificação em MpsBR. Aliás, a Isabella que foi uma das pessoas responsáveis pelo processo de certificação escreveu um artigo que sairá na revista visão ágil agora no início de Dezembro. Acho que vai ajudar bastante nessa questão.

Experiência similar: CMMi2 utilizando Scrum.
http://www.ddj.com/architect/201202684

E algumas certezas que tenho: o selo CMMi5 não garante que as funcionalidades contratadas serão entregues no prazo e no custo combinados. Trabalhei numa empresa CMMi5 e eram (ainda são) muito comuns as famosas reuniões para "renegociação de prazo", "renegociação de escopo" ou "renegociação de custo". Além disso desagradar demais o cliente, tem que mandar o(s) dono(s) da empresa para reunião. Ao invés dos caras ficarem trabalhando em planos estratégicos e novos negócios para a empresa (tarefas nas quais eles são muito bons, diga-se de passagem) eles têm que perder tempo perdendo os clientes (ou cedendo e arcando com o prejuízo).

então um cliente conservador não vai topar.

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).

Aliás, grandes clientes têm suas próprias metodologias, e se você não produz a documentação que eles pedem, não chega nem a concorrer.

Acho que aqui as metodologias ágeis ganham ponto. Elas se adaptam, você pode mudar, não está engessado por um monte de burocracias. Coloque no seu processo de desenvolvimento as necessidades do cliente, ora...

A diferença é que o cliente de outsourcing que paga por uma consultoria CMM 5 quer uma caixa preta, e não é isso que, por definição, ele tem num processo ágil. Se você não tem o envolvimento constante do cliente, então não pode dizer que o seu processo é ágil.

Será que é isso mesmo que ele quer? Na minha opinião, na maioria das vezes eles têm um problema e procuram uma solução. A única certeza que eles têm é do problema e não da solução. Acho que um dos papéis principais das empresas de software é ajudar o cliente na busca da solução para os seus problemas. E existe melhor maneira de fazer isso do que aos poucos, mostrando pra ele alguma coisa funcional e recebendo o feedback rapidamente? Ou você acha melhor mostrar tudo daqui a 2 anos e ver que todo o seu trabalho não ajudou o seu cliente em nada?
E sobre o envolvimento do cliente: cara, eu acho que ele está sim muito interessado em acompanhar o projeto. Você investiria R$100K na reforma da sua casa pra ver só daqui a 6 meses? Ou iria toda semana lá pra ver se está do jeito que você quer? Ninguém (a não ser gente doida) gosta de rasgar dinheiro. Se você criar mecanismos de envolvimento do cliente no seu projeto ele vai gostar e participar, pode ter certeza.
Ah.. mas na XP é necessário ter o cliente dentro da equipe, o tempo todo. E agora?? Bom, no Scrum existe o papel do Product Owner. Se você só pode usar XP, porque não adaptar e criar uma figura parecida com a do Product Owner no seu time XP? É adaptativo, você pode fazer isso. Você tem liberdade pra customizar e melhorar. Quer coisa melhor?? Ainda não conheço...

JavaEvangelist Membro desde: 26/04/2005 11:18:25 Mensagens: 469 Offline

Adolfo Rodrigues wrote:

então um cliente conservador não vai topar.

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).

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

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

rubinelli wrote:O selo CMM 5 é a garantia que vai sair software do outro lado nas condições estipuladas.

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.

rubinelli wrote:
Casos de uso são ideais para a especificação funcional, porque contam uma história em vez de serem um apanhado de pré e pós condições sem um fio condutor.

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.

rubinelli wrote:
Unit tests podem ser a especificação técnica, se escritos com esse fim em mente. (e aí BDD e os *Spec ajudam bastante)

Por favor, fale mais sobre BDD e os *Spec

JavaEvangelist Membro desde: 26/04/2005 11:18:25 Mensagens: 469 Offline

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.

Notícias, artigos e o maior fórum brasileiro sobre Java