CMM (Capability Maturity Model) - Alguém conhece?

Assuntos Gerais
#161

[quote=“rbarioni”][quote=“richardpeder”]
Qualquer profissional que vc venha a perder e que tenha uma certa experiencia é ruim para a empresa…o pior mesmo é quando vc centraliza “tudo” da sua empresa no cara[/quote]

um dos pontos q o XP prioriza, por ex, eh q TODOS da equipe participem da codificacao…por ex, uma tela fica cada 2 horas com uma dupla…

q me lembre, o CMM nao diz nada sobre isso e nem sobre a parte tecnica…
por isso, q CMM nao garante software de qualidade, apenas garante q vc tem o processo legal…

nao importa se vc tem o processo q eh uma zona, contando q o software final seja mto bom…pq gastar rios de grana com isso entao? p/ “ficar bem na foto”?? fala serio…[/quote]

Se vc tem um processo usavel, basta treinar as pessoas para usa-los…a parte tecnica, cada um deve ter seu conhecimento…claro que, caso o cara precise de algo a empresa treina, sem duvidas.
Mas esse lance de duas pessoas fazendo o codigo eh legal sim…no CMM nao tem isso…no entanto, os codigos sao versionados e comentados…sem duvida, quem pegar o codigo continua…basta saber da regra negocial (tem especificacao para isso) e ter conhecimento tecnico…a empresa nao vai contratar para programar em java um sorveteiro nao eh mesmo?! :slight_smile: :wink:

ate mais…

#162

otimo…tem versoes e codigo comentado…mas se apenas 1 ou 2 infelizes fizeram toda a parte de relatorios do seu sistema e esses caras sao demitidos…como fica a manutencao e/ou criacao de novos relatorios, sendo q os unicos caras q manjavam da ferramenta foram demitidos??

ai a empresa perde mais alguns dias, talvez meses p/ outro cara aprender a gerar relatorios…perda de tempo…tempo = dinheiro…empresa perde dinheiro…tendo prejuizo, eh obrigada a cortar mais pessoas…numa dessas, o cara q aprendeu tudo akilo tb vai embora…

enfim, eh um circulo vicioso…facilmente resolvido com simples tecnicas de desenvolvimento implantadas…o q, isso sim, garante um bom software…

falow

#163

Esse é meu ponto.

Acabei de sair de uma empresa, após 12 meses. O carinha contratado para me substituir fica me buzinando no ICQ a cada cinco minutos, pergutando coisas [eu me pus a disposição]. Isso porque o projeto está altamente documentado, visto que eu já sabia que ia sair da empresa,e stava só esperando eles contratarem alguém.

Bom, legal, fiz diagramas e desenhozinhos, o cara entendeu razoavelmente, mas com uma abordagem ‘tipo XP’ eu tenho certeza que ele iria aprender mais rápido, e produziria enquanto aprende, com pair programming com alguém mais experiente.

A questão é, isso funciona numa equipe de bons programadores, e numa equipe de programadores intercalados com sorveteiros?

Não se iludam, existe isso sim. Às vezes a ‘equipe’ que você pdoe trabalhar pode até não ter nenhum sorveteiro, mas também não tem nenhum Knuth. A falta de alguém devidamente preparado para assumir um papel importante, definir a arquitetura do projeto, é problemática. Este ‘design em baixo nível’ [acho que foi o Miguel Uiliana que disse isso…] funciona bem numa equipe onde todos são bons, mas e numa equipe como a da maioria dos lugares?

[]s

#164

[quote=“rbarioni”][quote="richardpeder]
no entanto, os codigos sao versionados e comentados…sem duvida, quem pegar o codigo continua…basta saber da regra negocial (tem especificacao para isso) e ter conhecimento tecnico…a empresa nao vai contratar para programar em java um sorveteiro nao eh mesmo?
[/quote]

otimo…tem versoes e codigo comentado…mas se apenas 1 ou 2 infelizes fizeram toda a parte de relatorios do seu sistema e esses caras sao demitidos…como fica a manutencao e/ou criacao de novos relatorios, sendo q os unicos caras q manjavam da ferramenta foram demitidos??

ai a empresa perde mais alguns dias, talvez meses p/ outro cara aprender a gerar relatorios…perda de tempo…tempo = dinheiro…empresa perde dinheiro…tendo prejuizo, eh obrigada a cortar mais pessoas…numa dessas, o cara q aprendeu tudo akilo tb vai embora…

enfim, eh um circulo vicioso…facilmente resolvido com simples tecnicas de desenvolvimento implantadas…o q, isso sim, garante um bom software…

falow[/quote]

E porque um cara só vai aprender a fazer relatório?? Imagina…nada a ver isso!
Eu tenho toda a minha equipe que sabe mexer com relatórios…se o cara que fez o programa X que tinha implementação de relatorio, eu tenho outra pessoa para continuar mexendo e dando manutenção no código…sem problemas!
Não sou contra o lance de programação em pares do XP, apenas disse que alternativo a isso tb dá certo!

Obs: Tempo = dinheiro…aprendi isso…e muito mais no meu curso de PMBOK, fique tranquilo!! :slight_smile: 8) :twisted:

ate mais…

#165

[quote=“pcalcado”]Esse é meu ponto.

Acabei de sair de uma empresa, após 12 meses. O carinha contratado para me substituir fica me buzinando no ICQ a cada cinco minutos, pergutando coisas [eu me pus a disposição]. Isso porque o projeto está altamente documentado, visto que eu já sabia que ia sair da empresa,e stava só esperando eles contratarem alguém.

Bom, legal, fiz diagramas e desenhozinhos, o cara entendeu razoavelmente, mas com uma abordagem ‘tipo XP’ eu tenho certeza que ele iria aprender mais rápido, e produziria enquanto aprende, com pair programming com alguém mais experiente.

A questão é, isso funciona numa equipe de bons programadores, e numa equipe de programadores intercalados com sorveteiros?

Não se iludam, existe isso sim. Às vezes a ‘equipe’ que você pdoe trabalhar pode até não ter nenhum sorveteiro, mas também não tem nenhum Knuth. A falta de alguém devidamente preparado para assumir um papel importante, definir a arquitetura do projeto, é problemática. Este ‘design em baixo nível’ [acho que foi o Miguel Uiliana que disse isso…] funciona bem numa equipe onde todos são bons, mas e numa equipe como a da maioria dos lugares?

[]s[/quote]

Isso acontece muito amigo…geralmente quando o cara sai ele tem o dominio do que ele fazia…mas isso não pode ser “um parto” para a empresa…ela precisa, como eu ja disse, descentralizar as coisas dos profissionais e dar o subsidio para que ele faça o seu trabalho, mas colocar a empresa na mao do cara é uma loucura…

E o lance de pessoas com perfis…concordo…hj em dia tem sorveteiro programando…mas isso a empresa deve achar logo o cara e demiti-lo, senão não sai programa, sai sorvete!! :slight_smile: :wink:

ate mais…

#166

[quote=“richardpeder”]
E o lance de pessoas com perfis…concordo…hj em dia tem sorveteiro programando…mas isso a empresa deve achar logo o cara e demiti-lo, senão não sai programa, sai sorvete!! :slight_smile: :wink: [/quote]

E por que você acha que tanto sistema vive congelando ? :lol:

Voltando, acho que XP divide melhor as responsabilidades [fácil: A RESPOSABILIDADE É DE TODOS!] e cria uma ‘consciência coletiva’. mAs e numa equipe totalmente desnivelada? A gente demite os sorveteiros?

[]s

#167

[quote=“pcalcado”]A questão é, isso funciona numa equipe de bons programadores, e numa equipe de programadores intercalados com sorveteiros?

Não se iludam, existe isso sim. Às vezes a ‘equipe’ que você pdoe trabalhar pode até não ter nenhum sorveteiro, mas também não tem nenhum Knuth.[/quote]
Li certa vez um comentario sobre XP que considerei bastante interessante. Era algo como “XP é bom para equipes onde existem diferentes niveis de conhecimento, mas não de inteligencia”. Isso porque, em XP, prevê-se que, depois de certo tempo de interação, o conhecimento vai ser passado de uma pessoa para outra. E é aí que vejo a bronca de um sistema “a lá Taylor” como o CMM: o conhecimento não trafega entre os niveis de hierarquia. Ou trafega?!

Até.

#168

Não entendi o que vc quis dizer…! :?

ate mais…

#169

Mas nem pode, Barioni, porque isso sai fora do escopo do CMM. Cabe a aqueles que projetarem os processos prever e tentar evitar este problema.

#170

[quote=“Daniel Quirino Oliveira”][quote=“rbarioni”]
q me lembre, o CMM nao diz nada sobre isso e nem sobre a parte tecnica…
[/quote]

Mas nem pode, Barioni, porque isso sai fora do escopo do CMM. Cabe a aqueles que projetarem os processos prever e tentar evitar este problema.[/quote]

Existe uma KPA do nivel 2 chamada Gerenciamento de Configuração (SCM)…essa KPA ajuda na parte de manter os produtos de software e gerencia-los…parte técnica bem baixo nivel, acredito que não tenha mesmo…não vejo nisso uma falha, mas acredito que no momento de interpretar o modelo, a empresa pode estar ajustando a parte técnica dela tb.

ate mais…

#171

[quote=“richardpeder”][quote=“Daniel Quirino Oliveira”][quote=“rbarioni”]
q me lembre, o CMM nao diz nada sobre isso e nem sobre a parte tecnica…
[/quote]

Mas nem pode, Barioni, porque isso sai fora do escopo do CMM. Cabe a aqueles que projetarem os processos prever e tentar evitar este problema.[/quote]

Existe uma KPA do nivel 2 chamada Gerenciamento de Configuração (SCM)…essa KPA ajuda na parte de manter os produtos de software e gerencia-los…parte técnica bem baixo nivel, acredito que não tenha mesmo…não vejo nisso uma falha, mas acredito que no momento de interpretar o modelo, a empresa pode estar ajustando a parte técnica dela tb.

ate mais…[/quote]

Sim, Richard. Mas esta KPA não vai ajudá-lo se, como o Rafael comentou, alguém que possua muito conhecimento sobre o projeto pular fora da empresa :wink: . Gerenciamento de configuração só ajuda a controlar as alterações durante todo o processo de desenvolvimento (ou, como dizia Babich, “é a arte de coordenar o desenvolvimento de software para minimizar a confusão”).

#172

[quote=“Daniel Quirino Oliveira”][quote=“richardpeder”][quote=“Daniel Quirino Oliveira”][quote=“rbarioni”]
q me lembre, o CMM nao diz nada sobre isso e nem sobre a parte tecnica…
[/quote]

Mas nem pode, Barioni, porque isso sai fora do escopo do CMM. Cabe a aqueles que projetarem os processos prever e tentar evitar este problema.[/quote]

Existe uma KPA do nivel 2 chamada Gerenciamento de Configuração (SCM)…essa KPA ajuda na parte de manter os produtos de software e gerencia-los…parte técnica bem baixo nivel, acredito que não tenha mesmo…não vejo nisso uma falha, mas acredito que no momento de interpretar o modelo, a empresa pode estar ajustando a parte técnica dela tb.

ate mais…[/quote]

Sim, Richard. Mas esta KPA não vai ajudá-lo se, como o Rafael comentou, alguém que possua muito conhecimento sobre o projeto pular fora da empresa :wink: . Gerenciamento de configuração só ajuda a controlar as alterações durante todo o processo de desenvolvimento (ou, como dizia Babich, “é a arte de coordenar o desenvolvimento de software para minimizar a confusão”).[/quote]

Acho que, independente da empresa ter CMM ou nao, isso pode acontecer…o cara sair da empresa e levar o conhecimento…por isso que eu bato na tecla (que o CMM adota), que deve-se alimentar os processos, deixando-os inteligentes, para assim, a empresa depender dos processos, que sao delas e capacitar as pessoas para usa-los.
Acho que o correto eh nivelar a equipe em relacao ao conhecimento de um determinado projeto…dai, sai quem sair, o projeto continua numa boa! :slight_smile: :wink:

ate mais…

#173

bom dia …sou novo na area e precisaria urgentemente falar com o richard…nao consegui seu e-mail…desculpe se tiver sendi incomod mas preciso de uns conceitos que vi que o Richard possui…Richard, poderia ne dar uma dicas ou ate mesmo teoria basica sobre qualidade de software ( modelos de qualidade ( iso cmm cmmi, metodolgias epadroes, gerencia de projetos, testes de softwares, estimativas e metricas ( analise de pontos de função)…só o basico mesmo ou o que for mais importante,poderia me ajudar??? valeu!!!

#174

Fala amigo…tudo bem??

Meu e-mail: richardfonseca2005@yahoo.com.br
meu MSN: richardgp2003@hotmail.com

Caso me adicione no hotmail, identifique-se dizendo que é a pessoa que me procurou sobre o topico de CMM do GUJ ok? :wink:

Estou a disposição.

ate mais…

#175