Friday, November 10, 2006

Mais uma coisa legal que li no forum UML-BR. Segue na íntegra o post do membro:

“ Pessoal,

Gostaria de compartilhar com vocês um desabafo sobre como tenho visto a implantação de RUP aqui no Brasil o que tem feito dele um pequeno monstruinho, presumo que na maioria das empresas...

Alguns dos malentendidos classicos:

** Processo prescritivo vs. consultivo **

O malentendido vem da ideia vem de que um processo em outras engenharias, em processos fabris, tem que ser usado ipsis literis, passo a passo, e no desejo dos executivos e gerentes de tornar "desenvolvimento" em uma atividade menos riscosa, onde processos fossem o centro, ferramentas fissesem a transformação da matéria prima, e trabalhadores especializados operassem essas ferramentas que transformam a materia prima em produtos terminados... o paradigma da "Fabrica"...

Quanto será que esta custando este pequeno erro conceitual para as empresas...?

Já vi o Jacobson falando que maior e melhor *quando* vc tem mais informação para consultar e não mais processo para seguir... no RUP tem guidelines sobre unit testing e outras centenas de asuntos excelentes, tem checklists que tiram muitas duvidas, tem descrição de atividades com profundidade muito detalhadas... mais o espirito é fazer software não documentos... e a ideia era ter um corpo de conhecimento que pudesse ser consultado e não seguido...

** As 4 Fases do RUP = 4 etapas do Waterfall **

Outro malentendido, 10% das pessoas leem os livros os outros 90% so olham as figurinhas e não passam do primeiro capitulo, e ainda tiam conclusões dos titulos dos outros capitulos o que devem ser os conceitos la definidos.

RUP que usa modelo waterfall é uma abominação, e iterações que não entregam software so poderiam existir na primeira fase de Inception, mais eu prefiro que não existam para não descambar em processos de desenvolvimento de documentos e não de software.

** Iteratividade vs.. Waterfall **

Se o pessoal parte de que as 4 fases se asemelham ao modelo waterfall, então iteratividade é completamente abolida do projeto, ou fica como milestone de entregas de "artefatos" e não de software.

Uma insanidade!!!!

** Fase de Construção vs. Etapa Construção do Waterfall**

Lamentavelmente quem ve nas fases as etapas do modelo waterfall (analise, projeto, construção, teste) ve nesta fase a programação e na anterior o projeto. Em software o codigo é um tipo de projeto de baixo nivel (low level design), UML pode ser usado para projeto de alto nivel (high level design), enquanto que a construção (build) como em

outras engenharias não equivale a programação e sim a compilação + linkedição, que já é automatizada a muito tempo.

Ahi esta fase se confunde e o nome ajuda com a etapa waterfall de construção, ou seja o pessoal acha que a programação = construção e não programação = low level design, e ahi tenta que o a elaboração seja a etapa de projeto, onde em outras engenharias existe o conceito de "Projetar sem construir" e na seguinte etapa "Construir sem

projetar" ou "Construir seguindo o projeto".

Se procurar nos "principios do RUP" fala em software executavel é essencial desde o inicio na primeira fase incluida, probas de conceito, com mais enfase para a etapa de elaboração, protótipo arquitetural executavel e evolutivo, onde apartir de ahi cada iteração entrega software executavel que vai evoluindo, jamais documentos....

** Gestão de Projetos **

Sobre gestão de projetos simplesmente passa a bola para o pessoal do PMI, fala para dar uma olhada no PMBOK, mais com as "suposições" acima sobre Waterfall e a pressão por manter o investimento sobre controle e "custos fixos" + "escopo fixo" + "tempo fixo" so resta mesmo inflar o triangulo ate o ponto que exploda, e fique totalmente descontrolado em algum dos lados dele e tambem como "qualidade" é uma coisa para inglês ver, ou no minimo um condimento que se coloca no final na maioria das organizações o projeto acaba se ajustando por la...

Para gerenciar projetos RUP sempre usei processos como Scrum para fazer a gestão de projeto, incrivelmente simples, mais incrivelmente anti-intuitivo para quem espera gerenciar "escopo fixo definido no inicio", "tarefas definidas", "custo fixo", novamente o problema do paradigma...

** Papeis vs. Cargos **

A ultima desgraça foram os papeis, que foram interpretados como cargos funcionais, separados em estruturas funcionais, quando dentro do RUP claramente fala dos problemas que isso pode criar, tem um guideline sobre como alocar os papeis aos cargos funcionais da sua organização, e claramente aconselha que devem ser criardas equipes multifuncionais e pessoas devem adotar varios papeis, como "developer" + "use case specifier" ou como "system analist" + "architect"..

Bom a ideia do Jacobsom era boa... ter muita informação para que mentes bem informadas pudessem consultar, adequar a sua realidade, eliminar aquilo que não agregasse valor e criar processos sob medida para suas organizações.. acho que nunca entendeu mesmo da realidade das empresas onde a força dos paradigmas dominantes torçem qualquer ideia boa, mais diferente, para se adequar aos modelos conhecidos. Bom acho que se tocou porque agora saiu com EssUP (Essential UP) que é uma versão minimalista do RUP.

É uma pena... mais é a realidade das empresas... tambem já vi empresas que chamabam de XP a codificar como macacos loucos sem se preocupar com qualidade, nem refactoring, nem porcaria nenhuma... essa ideia de pegar 1 ideia, tiara-la do contexto e depois justificar para fazer o que realmente se queria fazer no inicio é lamentavel... e depois ver como "não funciona" e se queixar de que o RUP é muito burocratico... enorme.. ou o XP gera codigo sem documentação e com baixa qualidade...etc.

Acho que poucos viram o artigo onde compara RUP como um self-service.. la tem muita comida, mais do que uma pessoa pode consumir e muita mais variedade do que sensatamente pode se combinar numa unica refeição... a ideia no self-service é que tem que pegar um pratinho e escolher aquilo que esta dentro da sua dieta na variedade e quantidade certas... ou vai dar uma bela de uma indigestão...

É so realmente tentar olhar la dentro... mais o pessoal gosta de ver so as figurinhas.. e não lee as letrinhas... Just scale it down!!! Acho que RUP lamentavelmente tenta falar para um publico responsavel e maduro, que vai realmente decidir de forma responsavel, despois de ter conhecimento completo sobre o assunto, bom é so dar uma olhada no

Dilbert para ver como a maior parte das empresas são...

Abordagens ágeis já vem com um pouco de este aprendizado, uma abordagem minimalista, a idea de scale it up, um conjunto minimo e quem souber acrescenta, mais da trabalho acrescentar... assim não há problema.. antes daba trabalho tirar.. agora vai dar trabalho para acrescentar... ou seja que vai ter menos incentivos para criar monstruinhos.. mais que havera não tenho duvida disso... a mediocridade é muito criativa e se expressa usando todos os tipos de

artes e ciencias conhecidas e ainda inventa outras novas...

Se me ocorrem algumas peguntas nesta hora:

Você esta usando RUP? e WUP? (Waterfall Unified Process) Esta tendo alguns daqueles probleminhas sitados acima? Vocês estão criando castelos de papel? Que custo de oportunidades esta criando para sua empresa? Melhorou? Piorou? Vai melhorar? O GP já contratou uma empresa de segurança para os guardacostas fazer a escolta da equipe de projeto proximo da data da entrega? Cansaram ou ainda vão continuar tentado?

Voce gostaria de conhecer alguma alternativa mas razoavel?

Então pode dar uma olhada no OpenUP:

http://www.eclipse.org/epf/downloads/openup/openup_downloads.php

Para gestão de projetos é bom dar uma olhada em Scrum é simples e

funciona muito bem com OpenUP, XP ou mesmo com RUP:

http://www.controlchaos.com/about/

Abraços,

Juan.

NOTA: Ainda não consegui me desvensilhar do habito de escrever longas

mensagens... quem não gostar, please me perdõe.. espero melhorar no

futuro...

--

Juan Esteban Bernabó

Tel: (11) 7685-5259

TeamWare do Brasil

Especialistas em Processos Ágeis e

Engenharia de Software

No comments: