Sem querer ‘causas’, mas sim ouvir os comentários/opiniões do pessoal, o que acham o artigo:
Li e senti que ele quis simplificar o imutável ‘o cliente quer tudo pra ontem…’ e e colocou isso como agilidade e igualou siglas de metodologia X,Y,Z como se elas resolver o problema da msm forma que se aplicar MA em projeto, para no final dizer que metodologia é metodologia e qualquer uma resolve bem sua situação…
foi essa minha interpretação posso estar sendo radical, mas sem do a ideia ou a filosofia do ‘manifesto ágil’ acho difícil evoluirmos no desenvolvimento de projetos se não observarmos as os erros e acertos pessoal outros que já trilharam o ‘caminho das pedras’.
bauda, comecei a ler o artigo já pensando nas pedradas, mas o autor tem noção sim do que ele está falando e concordo com ele. A culpa quase nunca é do RUP, CMMI, PMBOK e etc… o problema é que existem muitos especialistas fakes nesses modelos.
Só acho que o autor “perfumou demais” isso aqui:
Não é bem isso que acontece. Na minha opinião (e pelo que vejo no mercado) as organizações são bem burras com relação a desenvolvimento e retenção de talentos. Existe uma tendência a padronizar e colocar recursos todos no mesmo saco. As organizações hoje não são ágeis pois priorizam processos ao invés de pessoas.
Por outro lado, vejo as coisas do outro lado!! O nome “ágil” surgiu de um manifesto contra coisas erradas (como Waterfall). Então, digo que não existe escolha entre ágil e “alguma outra coisa” que funciona. Por isso que não compreendo quando vem gente aqui no fórum e se ressente quando citamos técnicas ágeis. Existe outra maneira de se fazer software eficientemente sem usar práticas ágeis?
[quote=rodrigoy]bauda, comecei a ler o artigo já pensando nas pedradas, mas o autor tem noção sim do que ele está falando e concordo com ele. A culpa quase nunca é do RUP, CMMI, PMBOK e etc… o problema é que existem muitos especialistas fakes nesses modelos.
…
[/quote]
Rodrigo:
Na minha opinião, a essência de qualquer modelo (seja de um sistema, de processos,
uma teoria científica) deve ser entendida facilmente. Para isso é que eles são criados.
Se a maioria das pessoas da área não pega o espírito de quem propõe o modelo, ele
não serve como tal, mesmo que algumas idéias possam ser resgatadas.
Quando vc fala “a culpa é quase nunca do ABC, XYZ”, eu interpreto isso como
uma afirmação de que os modelos em si não têm influência sobre supostos praticantes
que deturpam esse modelo.
Modelos existem para comunicar: modelos que precisam de muita explicação são como
piadas que precisam de muita explicação. A prática daqueles que dizem usar um dado
modelo é o modelo que é comunicado e percebido pela comunidade: a documentação
"oficial" dos seus criadores fica praticamente irrelevante.
Portanto, se o modelo não comunica, ele tem falhas, sim. Segue um link
(antigo) sobre o CMM que tenta explicar sua essência, e que na
minha opinião, acaba sendo uma confissão de que ele falhou como modelo:
Pô Jorge… não dá pra concordar com você. Os modelos estão lá e estão claros. Qualquer livro do RUP logo na primeira página diz que é um processo iterativo. Imagine a situação das empresas aplicarem cascata e falarem que estão praticando o RUP. É culpa do RUP?
Se vc conta uma piada muita boa para uma loira e ela não rí, é culpa da piada? Na minha opinião o mercado não está preparado para esses modelos.
[quote=rodrigoy]Pô Jorge… não dá pra concordar com você. Os modelos estão lá e estão claros. Qualquer livro do RUP logo na primeira página diz que é um processo iterativo. Imagine a situação das empresas aplicarem cascata e falarem que estão praticando o RUP. É culpa do RUP?
[/quote]
Sim, em parte. RUP era uma metodologia proprietária: o material de treinamento da Rational
era bem waterfallish, focava demais em geração de artefatos feitos com as ferramentas CA$E deles.
Improvável uma equipe trabalhar com iterações razoavelmente curtas se a principal fonte de
informação era esse material.
Para quem queremos comunicar o modelo ? Seguindo o exemplo da piada, o sujeito da piada normalmente
é externo ao grupo para o qual vc conta a piada. Contar piadas de português não é uma boa maneira de
iniciar uma palestra em Lisboa…
Se o público ao qual é dirigido o modelo não o entende, existe um problema com o modelo
ou, para ser mais suave, com a maneira como esse modelo é comunicado. Os modelos dos quais
falamos já têm anos de estrada, e não foram compreendidos até agora pela maioria.
Bom como o outro tópico foi bloqueado eu repetirei meu post aqui.
Acabo de ler e tenho pontos de discórdia:
Isso não é verdade. Todas as empresas que trabalhei que tinham esses modelos pesados pregavam que com os processos bem definidos os “recursos” podem ser trocados. Vejam, “recursos” e não pessoas. Quando começa assim já está tudo errado.
IMO, não explicou muito essa frase.
Aqui ele coloca duas opções: (1) Desenvolver tudo e fazer uma única entrega, o que sabemos que não tem nada de ágil e (2) Releases curtos. Achei contraditório com o tema do artigo.
Sinceramente ele quis filosofar muito. Agile surgiu pois as metodologias da época eram pesadas. Agora juntar tudo no mesmo saco não dá.
Por que sempre que vejo alguém defendendo que CMMx, MPS.br ou o que for é eficiente essa pessoa é um consultor ou um gerente? Porque é tão raro (só lembro de acotnecer uma vez aqui n GUJ, por exemplo) ermos um desenvlvedor ou tech lead defendendo estes modelos?
Eu já entrevistei muita gente e sempre que alguém vinha de uma empresa CMMx ele colocava no seu curriculum que tinha CMMx nível 20. Quando eu perguntava o que isso significava no seu dia-adia ele não sabia dizer ao certo mas sabia que as coisas icavam “mais controladas”. Quand erguntava o que isso queria dizer ele descrevia os 30 documentos que tinha que escrever. Quando perguntava se documentos eram atualizados frequentemente e se eles tinham valor eu reparava que a pessoa nunca tinha pensado sobe isso, ele apenas escrevia o documento porque uma lógica simplista diz que isso é o certo.
Acabo de assumir um projeto novo. O projeto faz parte de um programa que está trocando 100% dos sistemas de uma grande empresa de telecom, o meu pequeno projeto hoje é o responsável por interar os sistemas novos da matriz com os sistemas novos da filial, é algo bem complexo. Não tem nenhum documento, apenas código e testes. É um dos projetos de software mais bem documentados que já vi na vida, na primeira semana estávamos produzindo em leno vapor e sempre que fazemos alguma besteira um teste quebra.
É bom saber que alguma empresa de telecom esteja trabalhando certo…
Para eles, TI é muito crítico, só que a maioria das empresas foca em
coisas que não são importantes, ou até contraproduzentes.
Esse setor é um dos mais conservadores em termos de processos: o
refrão que eu mais ouvia era mesmo “meu CMMzão é maior que o seu CMMzinho”.
Por que sempre que vejo alguém defendendo que CMMx, MPS.br ou o que for é eficiente essa pessoa é um consultor ou um gerente? Porque é tão raro (só lembro de acotnecer uma vez aqui n GUJ, por exemplo) ermos um desenvlvedor ou tech lead defendendo estes modelos?
[/quote]
[quote=Jorge Diz][quote=pcalcado]Eu tenho uma pergunta.
Por que sempre que vejo alguém defendendo que CMMx, MPS.br ou o que for é eficiente essa pessoa é um consultor ou um gerente? Porque é tão raro (só lembro de acotnecer uma vez aqui n GUJ, por exemplo) ermos um desenvlvedor ou tech lead defendendo estes modelos?
[/quote]
Porque pimenta no nariz dos outros é refresco…
[/quote]
Ah… sei lá… eu já vejo que os modelos são mal compreendidos. Tem determinados ambientes que tive contato que realmente era necessário ter um processo mais maduro, principalmente com relação a GCM (como exemplo é o desenvolvimento de SO para celulares). Não que o CMMI seja necessário. Não concordo com tudo que existe no CMMI e não acho que o processo precisa ser maduro para ter bons resultados finais. Mas determinados ambientes precisam de maturidade (tem outros riscos e prejuízos envolvidos).
Eu vivi, ou deveria dizer sobrevivi, ou deveria dizer rastejei, num ambiente desses por 5 longos anos,
justamente nesse tipo de aplicação que vc está citando. Não ajudou, e os resultados em termos de qualidade
do produto final eram, para usar uma palavra suave, lacrimogêneos.
A adoção de processos paquidêrmicos atrapalha muito, os projetos eram multi-site (equipes no planeta inteiro).
Interessante: os sites que tinham níveis mais altos das certificações (ops , “assessments”= avaliações) de maturidade eram os sites mais imaturos nas práticas que fazem alguma diferença positiva e na qualidade
interna do software gerado (“nível 5: ihhh, lá vem pedrada”).
Ferramentas de gerência de configuração podem ser usadas de forma errada, de maneiras que nem
Satanás consegue imaginar, mas que aconteciam no nosso dia-a-dia. Por mais poluída que uma mente
seja, é dificil conceber todas as barbaridades que dá para fazer com um ClearyCrazy (ou CriaCaso).
Ou as pessoas envolvidas com isso entenderam tudo errado naquela organização, ou essa
interpretação de maturidade é furada: riscos não eram amenizados, mas potencializados.
Já ouvi falar de lugares onde adotar um desses modelos trouxe uma diferença para melhor,
vejo valor em alguns conceitos apresentados, mas a minha vivência foi essa que estou relatando
(e não apenas naquela empresa).
Eu não diria que algo é ruim ou mal planejado porque não é compreendido. Muitas pessoas não têm a menor noção do que é orientação a Objetos e fazem burradas históricas, isso não é culpa do paradima.
Eu acho que modelos de maturidade são é mal planejados, não mal compreendidos.
Só tenho uma coisa a dizer: Eu nunca ouvi falar de uma empresa que implantou RUP realmente iterativo. Eu não to nem falando de maturidade, que no caso aqui é o CMMI. É um exemplo pra ver como tem coisas que realmente não foram bem elaboradas, IMO.
Existem sim… já trabalhei em pelo menos 5 projetos que usavam RUP de fato (customizado, iterativo). Já usei até o OpenUP numa visão UP bem ágil (tinha uns 4 papéis, esquecemos as fases e o modelo de artefato era enxuto).
Mas, como sempre digo, já ví mais de 100 “especialistas” em RUP, mas especialistas de fato em RUP aqui no Brasil eu conheço 6.
Ainda assim, estou passando por uma fase “meio XP”. Vejo que o XP se encaixaria melhor na maioria dos projetos que tenho tido contato. O que impede isso é a falta de maturidade em práticas ágeis das equipes.
As duas empresas que trabalhei que “aplicavam” RUP, não sabiam nem o que era processo iterativo.
No ponto que o Rodrigo diz que nem sem a culpa é do XYZ eu tbm concordo, por pior que o processo possa ser, geralmente ele fazem com que eles sejam ainda piores pois não sabem os aplicar.
E concordando com o shoes tbm, os modelos de maturidade são (muito) mal planejados.
Discordando do autor agora, até hoje não tive contato com ninguém que trabalhou em alguma empresa que usava waterfall falar que os modelos priorizavam pessoas, isso nas “grandes” empresas aqui em são paulo é conversa pra boi dormir.