Metodologias ágeis e CMMi combinam?

This message was edited 1 time. Last update was at 05/09/2007 12:58:32

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

JavaEvangelist Membro desde: 11/05/2006 12:10:38 Mensagens: 329 Offline

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

JavaEvangelist Membro desde: 11/05/2006 12:10:38 Mensagens: 329 Offline

rodrigoy wrote: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?)

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

rodrigoy wrote:
(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?)

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?

microfilo wrote:

rodrigoy wrote:
(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?)

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?

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.

ZehOliveira wrote:

microfilo wrote:

rodrigoy wrote:
(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?)

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?

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.

Ótimo, mas mesmo nesse caso ainda acho que não servem como requisitos.

http://www.ddj.com/architect/201202684

This message was edited 1 time. Last update was at 04/09/2007 12:48:07

microfilo wrote:

ZehOliveira wrote:

microfilo wrote:

rodrigoy wrote:
(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?)

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?

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.

Ótimo, mas mesmo nesse caso ainda acho que não servem como requisitos.

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?

microfilo wrote:
Ótimo, mas mesmo nesse caso ainda acho que não servem como requisitos.

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

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.

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

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)

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

microfilo wrote:
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?

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.

rodrigoy wrote:

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

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

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"

This message was edited 1 time. Last update was at 05/09/2007 20:10:55

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

Desenvolvimento rápido e desenvolvimento ágil são coisas diferentes.

http://www.agilemanifesto.org

mcbarsotti wrote:
Na CPM é CMMI 5, até se desenvolve um sistema rapido, mas quando chega na doc... lagrimas!!!

abrçs

"Quando chega na documentação"? Nossa, vocês ainda usam waterfall?

Cuidado: http://blog.fragmental.com.br/2007/07/24/contratando-agilistas-retardatarios/

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