O Grande problema dos processos e metodologias

Nos últimos 30 anos fomos bombardeados de processos e metodologias de desenvolvimento de software. Mas mesmo nos dias de hoje existe muita discussão sobre o assunto e bem como graves problemas de interpretação das coisas como elas são.

Para começar gostaria de deixar bem claro que esse não é um artigo a favor do RUP e contra as metodologias ágeis ou vice-versa. Recomendo que os leitores que tem maior clamor religioso por metodologias que leiam a frase anterior pelo menos umas 10x. :)

Agora gostaria de estabelecer dois marcos segundo o próprio Per Kroll. Uma coisa é o modelo de cliclo de vida de um projeto que pode ser cascata, sashimi, iterativo incremental, prototipação evolutiva , etc. Outra questão é o grau de formalismo de um projeto. No grau de formalismo as coisas podem variar do RUP ao XP. Essas metodologias tem um contraste de formalismo grande.

Isso pode ser representado pela figura a baixo:




Qual é um erro crasso que as pessoas cometem ao usar RUP? Não adaptar o processo. O próprio RUP enfatiza que quem utiliza o RUP deve adaptar o processo. O Processo unificado foi a unificação de 3 metodologias mais utilizadas na época, a idéia não foi ruim, eu particularmente gosto de vários aspectos do RUP porem também gosto muito de SCRUM e de certas práticas do XP.

O fato é que as pessoas usaram o RUP de maneira errada e simplesmente instanciaram todo o processo e isso acarretou em pilhas de documentos inúteis mas repito a culpa não é do processo. O mesmo problema acontece com métodos ágeis. Se você ler o manifesto ágil até se emociona! Mas uma diferença do manifesto ágil para o RUP é que o RUP especifica tudo e o manifesto ágil não especifica nada. Mas eu não estou dizendo que isso necessariamente é um problema. São abordagens diferentes.

Mas as pessoas que erraram com o RUP vão errar com o XP e com as metodologias ágeis também. Por que o problema é a falta das práticas e do tailoring da coisa. Um dos engenheiros da Google e um dos responsáveis pelo TestNG já diz também que prefere encarar metodologias ágeis como uma caixa de ferramentas ao invés de uma ferramenta. Muitas vezes nem todas as práticas ágeis são aplicáveis a todos os projetos. Eu estou utilizando SCRUM ultimamente em uma grande corporação e lá nos não seguimos os SCRUM a risca por que muitas coisas do SCRUM simplesmente não fazem sentido no nosso ambiente.

Em que ponto que o RUP peca? Peca por que em alguns pontos ele não evolui, ele continua com uma séria de artefatos e atividades que hoje em dia não tem muito sentido. Um exemplo é que o RUP diz que o arquiteto de software deve participar de qualquer criação de uma interface, hoje em dia com a programação para interfaces isso se torna inviável e sem sentido.

Em que ponto o XP peca? Peca por que trata os requisitos de software de maneira muito simplista e dependendo do projeto isso seria um tiro no pé. Existe um grande número de projetos que usaram XP e falharam também.

Hoje em dia uma metodologia promissória e que me atrai muito é o Open Up. Que é uma metodologia que parte de um subset do RUP e agrega valor principalmente do SCRUM e práticas ágeis. Porem o Open Up também não pode ser instanciado sem o tailoring.

Até a próxima. :)

Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java