Olá pessoal,
É possível conciliar metodologias ágeis e CMMi, trabalhar com Scrum/XP e também seguir os processos do CMMi?
Qual é a opinião de vocês?
A motorola tem CMMI5 e utiliza SCRUM… maturidade do processo não tem muita relação com práticas de engenharia como um todo. Mas o CMMI tem algumas coisas chatas que agilistas naturalmente não gostam e creio que o XP não atende naturalmente. Uma delas é a matriz de rastreabilidade dos requisitos.
(agilistas gostam de manter muita coisa no código, agilistas gostam de considerar os testes como sendo os próprios requisitos. já tentou alguma vez explicar isso para alguém que tem sangue CMMi correndo na veia?)
você até consegue usar uma metodologia para desenvolver rapido e tudo mais, mas quando cair na documentação do CMMI, tudo oque você fez rapido vai por agua abaixo…
Na CPM é CMMI 5, até se desenvolve um sistema rapido, mas quando chega na doc… lagrimas!!!
abrçs
[quote=rodrigoy]A motorola tem CMMI5 e utiliza SCRUM… maturidade do processo não tem muita relação com práticas de engenharia como um todo. Mas o CMMI tem algumas coisas chatas que agilistas naturalmente não gostam e creio que o XP não atende naturalmente. Uma delas é a matriz de rastreabilidade dos requisitos.
(agilistas gostam de manter muita coisa no código, agilistas gostam de considerar os testes como sendo os próprios requisitos. já tentou alguma vez explicar isso para alguém que tem sangue CMMi correndo na veia?)
[/quote]
Exatamente!
Sinceramente é tentar adaptar uma coisa para encaixar na outra e não ter sucesso … mundos completamente diferentes, vai perder muito o principal das metologias ágeis - agilidade.
Aliás, isso me lembrou o famoso quadro da troca de lâmpadas com CMMI5:
1 pessoa para descrever o problema
1 pessoa para avaliar o problema e propôr um conjunto de soluções técnicas
1 pessoa para criar uma especificação sobre a tarefa a ser desenvolvida
1 pessoa para validar a especificação
1 pessoa para avaliar o prazo e o esforço da tarefa
1 pessoa para avaliar o impacto e o custo da tarefa
1 pessoa para controlar o estoque de lâmpadas e fornecer � equipe uma lâmpada de uma versão adequada para a tarefa
1 pessoa para conseguir uma escada
1 pessoa para subir na escada, remover a lâmpada queimada e efetuar a troca pela nova
1 pessoa para criar casos de testes para verificar se o objetivo da tarefa fora cumprido
1 pessoa para avaliar a qualidade da troca da lâmpada
1 pessoa para realimentar a base histórica de métricas da empresa afim de fornecer dados mais apurados sobre tempo/esforço/custo para futuras tarefas similares
1 pessoa para notificar ao cliente que o problema fora resolvido
Testes? Vc diz testes unitários??? Eu sempre achei que o requisito deveria definir como os testes devem ser feitos, e não o contrário… Incluside existe o conceito de RBT (Requiment Based Testing). Alguém já trabalhou em algum ambiente em que os testes são os requisitos?
[quote=microfilo][quote=rodrigoy]
(agilistas gostam de manter muita coisa no código, agilistas gostam de considerar os testes como sendo os próprios requisitos. já tentou alguma vez explicar isso para alguém que tem sangue CMMi correndo na veia?)
[/quote]
Testes? Vc diz testes unitários??? Eu sempre achei que o requisito deveria definir como os testes devem ser feitos, e não o contrário… Incluside existe o conceito de RBT (Requiment Based Testing). Alguém já trabalhou em algum ambiente em que os testes são os requisitos?[/quote]
Não. Quando ele diz ‘testes’ não quer dizer unicamente ‘testes unitários’. Ele fala também de testes de integração, de aceitação, de regressão, etc.
[quote=ZehOliveira][quote=microfilo][quote=rodrigoy]
(agilistas gostam de manter muita coisa no código, agilistas gostam de considerar os testes como sendo os próprios requisitos. já tentou alguma vez explicar isso para alguém que tem sangue CMMi correndo na veia?)
[/quote]
Testes? Vc diz testes unitários??? Eu sempre achei que o requisito deveria definir como os testes devem ser feitos, e não o contrário… Incluside existe o conceito de RBT (Requiment Based Testing). Alguém já trabalhou em algum ambiente em que os testes são os requisitos?[/quote]
Não. Quando ele diz ‘testes’ não quer dizer unicamente ‘testes unitários’. Ele fala também de testes de integração, de aceitação, de regressão, etc.[/quote]
Ótimo, mas mesmo nesse caso ainda acho que não servem como requisitos.
[quote=microfilo][quote=ZehOliveira][quote=microfilo][quote=rodrigoy]
(agilistas gostam de manter muita coisa no código, agilistas gostam de considerar os testes como sendo os próprios requisitos. já tentou alguma vez explicar isso para alguém que tem sangue CMMi correndo na veia?)
[/quote]
Testes? Vc diz testes unitários??? Eu sempre achei que o requisito deveria definir como os testes devem ser feitos, e não o contrário… Incluside existe o conceito de RBT (Requiment Based Testing). Alguém já trabalhou em algum ambiente em que os testes são os requisitos?[/quote]
Não. Quando ele diz ‘testes’ não quer dizer unicamente ‘testes unitários’. Ele fala também de testes de integração, de aceitação, de regressão, etc.[/quote]
Ótimo, mas mesmo nesse caso ainda acho que não servem como requisitos.[/quote]
O “requisito” que você se refere é só a especificação do requisito.
Requisito é o que precisa ser implementado. Como ele é documentado depende do projeto. Já trabalhei em projeto onde cada funcionalidade era resumida em uma frase e especificada num teste de aceitação automatizado. O requisito definiu o teste, com a vantagem que não precisamos de um documento a mais pra ser atualizado. Além disso neste caso o teste sempre vai estar atualizado com o sistema, e ainda vai sempre dar o feedback que está tudo funcionando como esperado. Pra que mais documentação?
[quote=microfilo]
Ótimo, mas mesmo nesse caso ainda acho que não servem como requisitos.[/quote]
Imagine que vc escreve:
O sistema não deve permitir a aprovação de pedidos com desconto maior que 15%.
Agora, imagine que vc escreve (este código não compila):
/** Este método testa a regra que pedidos não podem ter desconto maior que 15% */
public void testPedidoDesconto() {
Pedido pedido = new Pedido()
...
(preenche o pedido)
...
pedido.setDesconto(0.151);
try {
pedido.aprovar();
// se chegou até aqui não funcionou
assert(false);
} catch (AprovacaoException e) {
// a regra está funcionando!!!
assert (true);
}Qual a diferença na sua opinião?
Você concorda que não existe requisitos primeiro, design depois, codificacao depois, teste depois? Será que não existe uma maneira de fazer tudo isso ao mesmo tempo?
Por mais ágil que sua metodologia ou ambiente de desenvolvimento for, acredito sim no primeiro momento do projeto, deve-se definir escopo\levantar requisitos, nem que isso seja feito num “alto nível”. É claro que com o passar do tempo, no ciclo de vida dos projetos, esses requisitos vão sendo detalhados, aperfeiçoados e corrigidos, isso fatalmente será necessário. Mas é óbvio que um levamento de requisitos\escopo incial é feito. E acho que isso deve ser armazenado de alguma forma e usado, de alguma maneira, como subsidio na hora de desenvolvimento.
Mas de qualquer maneiro, ainda sim vejo a importância de algo que documente os requisitos do software e não acho um teste (no seu exemplo, um teste unitário) a melhor maneira de fazer isso. O cara vai ter que saber programar em Java para entender o requisito?
É claro que a forma como os requisitos são elaborados e armazenados\gerenciados não deve ser algo totalmente amarrado, com textos quilometricos e redundantes.
[quote=microfilo]Por mais ágil que sua metodologia ou ambiente de desenvolvimento for, acredito sim no primeiro momento do projeto, deve-se definir escopo\levantar requisitos, nem que isso seja feito num “alto nível”. É claro que com o passar do tempo, no ciclo de vida dos projetos, esses requisitos vão sendo detalhados, aperfeiçoados e corrigidos, isso fatalmente será necessário. Mas é óbvio que um levamento de requisitos\escopo incial é feito. E acho que isso deve ser armazenado de alguma forma e usado, de alguma maneira, como subsidio na hora de desenvolvimento.
[/quote]
Sim, mas não é isso que está em discussão. A discussão é se é possível tomar os testes como requisitos. Não importando se são testes unitários. Aliás, senti um tom de desprezo por sua parte com relação aos testes unitários (posso estar errado) :oops: . Se a sua aplicação está baseada num domain model rico 100% das regras de negócio podem ser cobertas com testes unitários. Se vc quiser fazer um teste dos objetivos vc concentra os testes na façade e o efeito vai ser o mesmo. 
Investimento em concepção existe sim, mas na maioria dos projetos não toma mais que 4 horas. É de altíssimo nível. Se vc passar 1 hora com o Sponsor do projeto e sair dessa reunião com uma lista macro de funcionalidade ordenada por business value a concepção acabou alí mesmo. A partir disso é desenvolvimento iterativo com pouquíssima atividade up-front.
OK… toda solução existe efeito colateral, mas como vc colocou, é a sua opinião… mas para manifestar a minha opinião, NÃO VEJO O MÍNIMO SENTIDO EM CONTRATAR UM CARA QUE NÃO PROGRAME EM JAVA SE O PROJETO É EM JAVA.
[quote=rodrigoy][quote=microfilo]Por mais ágil que sua metodologia ou ambiente de desenvolvimento for, acredito sim no primeiro momento do projeto, deve-se definir escopo\levantar requisitos, nem que isso seja feito num “alto nível”. É claro que com o passar do tempo, no ciclo de vida dos projetos, esses requisitos vão sendo detalhados, aperfeiçoados e corrigidos, isso fatalmente será necessário. Mas é óbvio que um levamento de requisitos\escopo incial é feito. E acho que isso deve ser armazenado de alguma forma e usado, de alguma maneira, como subsidio na hora de desenvolvimento.
[/quote]
Sim, mas não é isso que está em discussão. A discussão é se é possível tomar os testes como requisitos. Não importando se são testes unitários. Aliás, senti um tom de desprezo por sua parte com relação aos testes unitários (posso estar errado) :oops: . Se a sua aplicação está baseada num domain model rico 100% das regras de negócio podem ser cobertas com testes unitários. Se vc quiser fazer um teste dos objetivos vc concentra os testes na façade e o efeito vai ser o mesmo.
Investimento em concepção existe sim, mas na maioria dos projetos não toma mais que 4 horas. É de altíssimo nível. Se vc passar 1 hora com o Sponsor do projeto e sair dessa reunião com uma lista macro de funcionalidade ordenada por business value a concepção acabou alí mesmo. A partir disso é desenvolvimento iterativo com pouquíssima atividade up-front.
[/quote]
Só pra reforçar a sua opinião: levantamento inicial de requisitos deve servir apenas pra “vender” o projeto. O grande erro é que as pessoas têm pena de depois substituir estes documentos por testes (que pro desenvolvimento agregam MUITO mais) e querem ficar carregando-os até o fim do projeto só pra não sentir que o trabalho dos analistas foi “jogado fora” 
[quote=mcbarsotti]você até consegue usar uma metodologia para desenvolver rapido e tudo mais, mas quando cair na documentação do CMMI, tudo oque você fez rapido vai por agua abaixo…
[/quote]
Desenvolvimento rápido e desenvolvimento ágil são coisas diferentes.
[quote=mcbarsotti]
Na CPM é CMMI 5, até se desenvolve um sistema rapido, mas quando chega na doc… lagrimas!!!
abrçs[/quote]
“Quando chega na documentação”? Nossa, vocês ainda usam waterfall?
Cuidado: http://blog.fragmental.com.br/2007/07/24/contratando-agilistas-retardatarios/
Esse tipo de pergunta parece o seguinte: uma empresa passa por uma certificação CMMI e optar por ter um processo tão engessado que qualquer outro tipo de metodologia é incompatível.
Ou seja, algumas pessoas não entenderam o que é o CMMI, elas queriam uma receita de bolo pra conseguir o selinho. Essas mesmas pessoas tem o poder de demitir e não raro acham que algo ágil é algo bagunçado e feito de qq forma.
[quote=peczenyj]Esse tipo de pergunta parece o seguinte: uma empresa passa por uma certificação CMMI e optar por ter um processo tão engessado que qualquer outro tipo de metodologia é incompatível.
Ou seja, algumas pessoas não entenderam o que é o CMMI, elas queriam uma receita de bolo pra conseguir o selinho. Essas mesmas pessoas tem o poder de demitir e não raro acham que algo ágil é algo bagunçado e feito de qq forma.[/quote]
Apesar de achar os critérios exigidos por CMMi, MPS.br e derivados tendenciosos (à burocratização) e completamente fora do foco concordo com você.
Esse assunto pega fogo quando se propõe usar um e-mail ou foto digital como evidência, ao invés de um documento bem formatado.
Olha, não creio que isso seja problema do modelo de maturidade, mas sim, das consultorias que dizem “te ajudar a chegar no nível de maturidade”. Tudo no mercado é mal interpretado (CMMI, XP, RUP, SCRUM, PMBOK, TOC). 
Se a gente conseguisse fazer um arquivo .java abrir legalzinho no Word com cabeçalho com logo da empresa e etc é bem capaz que você consiga CMMI com XP.
[quote=Kenobi]Sinceramente é tentar adaptar uma coisa para encaixar na outra e não ter sucesso … mundos completamente diferentes, vai perder muito o principal das metologias ágeis - agilidade.
Aliás, isso me lembrou o famoso quadro da troca de lâmpadas com CMMI5:
[code]
1 pessoa para descrever o problema
1 pessoa para avaliar o problema e propôr um conjunto de soluções técnicas
1 pessoa para criar uma especificação sobre a tarefa a ser desenvolvida
1 pessoa para validar a especificação
1 pessoa para avaliar o prazo e o esforço da tarefa
1 pessoa para avaliar o impacto e o custo da tarefa
1 pessoa para controlar o estoque de lâmpadas e fornecer � equipe uma lâmpada de uma versão adequada para a tarefa
1 pessoa para conseguir uma escada
1 pessoa para subir na escada, remover a lâmpada queimada e efetuar a troca pela nova
1 pessoa para criar casos de testes para verificar se o objetivo da tarefa fora cumprido
1 pessoa para avaliar a qualidade da troca da lâmpada
1 pessoa para realimentar a base histórica de métricas da empresa afim de fornecer dados mais apurados sobre tempo/esforço/custo para futuras tarefas similares
1 pessoa para notificar ao cliente que o problema fora resolvido
[/code][/quote]
Desculpe o Up… Mas é q achei tao interessante o post…
abs,