SCRUM e RUP, qual é melhor? São realmente muito diferentes?
Talvez não sejam tão diferentes. Mas o SCRUM é a bola da vez, e o RUP já foi. Porque será?
Construção de Software
Construir software. Na realidade atual, a complexidade na construção aumenta progressivamente à medida que mais artefatos precisam ser confeccionados.
Para demonstrar que quanto mais escopo a produzir mais complexo um sistema fica, vamos fazer uma analogia entre um ser humano e um robô.
Imaginemos o Robocop, um policial androide. Como vemos nos filmes, é um policial que é programado para executar a lei, que quando depara-se com uma situação em que deve atuar, roda uma série de programas em sua “mente” baseada em inteligência artificial, onde cada programa que a compõe possui milhões de If’s, While’s, For’s etc. para decidir qual ação tomar.
Enquanto um robô, sua tomada de decisão está limitada ao o que sua mente robótica está programada para fazer, ou seja, logicamente, ha um limite de ponderações que são feitas até chegar ao resultado final.
Imaginemos agora um policial humano. Quando ele depara-se com uma situação em que deve executar a lei, da mesma forma roda uma série de processos automáticos em sua mente para tomar sua decisão, mas não ha, necessariamente, um limite de ponderações que podem ser feitas até chegar-se ao resultado final.
O fator emoção ilustra isso bem. Compreende-se então que, se o ser humano possui mais recursos que o Robocop, este deveria ser mais eficiente e eficaz no seu trabalho, certo?
Teoricamente sim, na prática, não. Mas porque?
Simples, o ser humano ainda não sabe utilizar todas ferramentas que tem e por esta ignorância, quando tenta usá-las, se atrapalha.
Mas porque um policial robô é mais eficiente e eficaz que um policial humano, se a mente do humano é praticamente ilimitada (logo, mais poderosa que a do robô)? Aí está o pulo do gato para entendermos este post.
Uma ferramenta para quem não sabe utilizá-la
Dê uma faca de açougueiro a uma criança de dois anos e peça a ela para cortar carne. Dê a mesma faca a um açougueiro experiente e peça a mesma coisa. O resultado será muito, muito diferente. Vamos entender melhor a relação disso com o uso de metodologia para desenvolvimento de sistema.
Alguns defendem que quando construir software baseava-se em o usuário sentar ao lado do programador e falar o que precisava, e o programador traduzia isso em código, e as coisas funcionavam melhor. Obviamente, é um processo curto, e do ponto de vista de entrega.
Pensando apenas no tempo de entrega, funcionava melhor mesmo, pois entregávamos software mais rápido pois menos etapas eram necessárias, logo, entregávamos mais software.
Mas isso não significa software de melhor qualidade, e para quem já viveu isso e teve a oportunidade de viver em um ambiente mais organizado, sabe que minha afirmativa se aplica.
Então vieram os processos, metodologias etc. taxados como solução para o problema de software de baixa qualidade.
Mas quando esse movimento começou, o mesmo profissional que codificava com o usuário no seu ouvido foi o cara que ficou responsável por assimilar a metodologia e colocá-la em produção. A natureza não dá saltos, e não foi diferente em nossa área, pois o antigo codificador de pé de ouvido ficou responsável por rodar a metodologia.
Uma das metodologias, ou modelo de processo, que foram taxados de solução para o problema da qualidade foi o Rational Unified Process, o RUP. Então aqueles que se definiam como a “vanguarda” em termos de expertise em metodologia começaram a vender RUP em larga escala, e os que estavam no caos do “pé do ouvido” começaram a comprar consultoria e tentar rodá-lo “no peito e na raça”.
Depois de muito quebrar a cabeça, o mercado rotulou o RUP de modelo muito inchado, muito caro etc., pois não resolveu o problema da qualidade, e inverteu a realidade da entrega. Antes não havia qualidade mas havia entrega, e depois não havia entrega (me refiro ao tempo de entrega, passou a demorar muito), e o pouco que havia de entrega, era com qualidade ruim.
Neste momento, várias outras coisas aconteciam.
Consultorias traziam outras soluções mágicas, os departamentos de TI criavam suas próprias versão do RUP, os clientes não queriam sair da moda da “metodologia” pois falar que tinham RUP era estar na dianteira.
Mas, no fim, o RUP “fracassou”. Então, apareceu uma nova solução mágica, o SCRUM. De uns dez anos pra cá o RUP tornou-se uma solução “lenta”, e o Scrum uma solução “ágil”.
A moda da Agilidade
Hoje a moda é ser ágil! Obs.: eu estou na moda!
É entregar mais software com mais qualidade.
Na minha opinião, o grande lance do SCRUM é ser iterativo e incremental, e limitar suas entregas em Sprints que variam entre uma semana (no mínimo) e quatro semanas (no máximo), focando em entregar algo de valor para o negócio num curto prazo, obter feedback do usuário e seguir assim até acabar.
Mas, também na minha opinião, o grande lance do RUP é ser iterativo e incremental, entregar em pedaços pequenos (Iterações), focando em entregar algo de valor para o negócio num curto prazo, obter feedback do usuário e seguir assim até acabar.
Iteração e Sprint, Valor para o Negócio e Rupturas
Fundamentalmente, não há diferença sob este ponto de vista. Mas sob este ponto de vista, se não ha diferença entre SCRUM e RUP, porque o primeiro é melhor que o segundo?
Retornemos ao passado.
Filosoficamente, o progresso, de um modo geral, quando se dá pra valer, é iniciado a partir de uma forte quebra de paradigma, onde se está no 8 e deseja-se ir para o 80. Isso é ruptura.
Romper, de fato, é sair do 8 e ir para o 80. Sair do 50 e ir para o 80 não é ruptura, é uma mudança de baixo impacto.
Quando o mercado tentou sair do “programador de pé de ouvido” e ir para o mundo dos “processos altamente resolvedores de problema”, houve uma ruptura.
O mercado estacionou um tempo sobre os processos altamente resolvedores de problema, mas concluiu que isso não resolvia, pois antes entregava-se sem qualidade mas era rápido, agora nem entrega-se mais.
Aí há a tentativa de uma nova ruptura, que é sair do mundo dos processos altamente resolvedores de problema e ir para o mundo do programador de pé de ouvido novamente.
Considerando esta lógica, teremos amanhã o mesmo cenário de ontem, pois o SCRUM resolverá o problema da entrega, mas não o da qualidade (será que o RUP 2.0 será a solução?).
Não quero dizer que SCRUM é exatamente programar com o usuário ao pé do ouvido, mas é muito disso, se analisarmos o framework em sua essência.
Menos documento, mais código, Product Owner falando direto para desenvolvedores.
Isso é retornar às origens!
É legal? Sim, muito. Equipes auto-organizadas, com desenvolvedores que se auto-supervisionam, são maduros emocionalmente, responsáveis, conhecem muito bem de engenharia, arquitetura, construção, testes, deploy, infra etc.
Seria ótimo se fosse possível. Infelizmente, em 95% das organizações, não é.
Equipe auto-organizada, em escala, ainda não existiu, e ainda não existe. É pedir demais do ser humano, em seu perfil padrão, mas não é impossível que assim seja, mas não por agora.
Mas então o que houve que fez com que o RUP, em essência, tão parecido com o SCRUM, tenha sido jogado por terra?
Novamente, não saber utilizar a ferramenta
Para usar uma faca, primeiro é necessário saber o que é uma faca, o que é cortar, o que é se machucar etc.
Aprendido isso, entender como cortar, pois se é necessário cortar uma semente de soja não deve-se utilizar uma faca de açougueiro, se é para cortar uma costela de boi, uma faca para cortar semente de soja não atende.
Aprendido qual faca usar, pensar em como cortar é essencial, pois não se deve cortar uma picanha como se deve cortar um músculo.
Quando o RUP começou a ganhar mercado fora da Rational/IBM, um erro primário de implantação de processo aconteceu em larga escala: empacotar o processo inteiro, inseri-lo na organização, trabalhar totalmente orientado a ele, e esperar o milagre.
Para que serve uma metodologia?
Metodologias são guias, não coleiras.
A que serve para um, não necessariamente servirá para outro. A versão que atende hoje, não atenderá amanhã (melhoria contínua). A customização que serviu para um, não necessariamente servirá para outro.
As empresas são diferentes. Não há mágica, nem com o RUP, nem com o SCRUM.
O momento em que o RUP emplacou era um momento de ruptura, onde conclui-se que entregar somente não resolvia, tinha que entregar com qualidade. Aí profissionais sem maturidade no assunto decidiram vender o sonho, mas entregaram pesadelo.
A culpa é do RUP? Não! Se bem customizado, enxugado, eu acho excelente!
Dar um modelo de processo como o RUP para profissionais que não sabem utilizá-lo é como dar a faca de açougueiro para a criança de 2 anos. O problema não é a faca, e sim o despreparo da criança para utilizá-la.
Concluindo
O SCRUM resolverá o problema da qualidade e da entrega? Também não!
A solução está no bom senso, no entendimento de que para uma empresa o RUP é a melhor solução, para outra o SCRUM é a melhor solução, mas para ambos os casos, desde que implantado/mantido/utilizado por quem sabe o que está fazendo, senão, fica como moda, vem e vai.
Abraços!