Quick Eng: RUP x Scrum

Olá pessoal!

Neste post finalizo uma pequena série de três posts sobre os processos de desenvolvimento de software mais populares da atualidade: o RUP e o Scrum. Caso você não tenha lido os dois posts anteriores, recomendo que o faça: RUP / Scrum. Neste post registro minha opinião / sentimento pessoal quanto a tais processos e como enxergo as discussões que têm surgido atualmente no mercado e na comunidade de desenvolvimento de software. Ressalto então que o está descrito excepcionalmente neste post não foi embasado por nenhuma literatura ou trabalho científico, tratando-se, portanto, de uma análise empírica pessoal. Com este post gostaria de abrir uma discussão, convidando-o a opinar sobre o assunto, postando seu comentário.

RUPÉ fato que não é tarefa simples suportar um processo demorado por conta de levantamentos de negócios, seguido por um levantamento de requisitos e produção de documentações ostensivas. Com as cobranças constantes por entregas mais rápidas, os clientes vêm maior valor no produto entregue do que em um escopo bem fechado e documentado. Muitos profissionais de TI também não enxergam este valor ou deixam de enxergar com o passar do tempo, quando percebem que manter toda uma documentação produzida não é trivial ou mesmo quando são cobrados frequentemente por fins sem necessariamente justificar os meios. Além disso, existem também outros problemas que são enfrentados na maioria dos projetos, como por exemplo, a não aderência do produto entregue às reais necessidades do usuário, frequentes mudanças de escopo no decorrer do desenvolvimento, demora na entrega dos primeiros resultados e/ ou atraso na entrega do produto completo, o que taxa a área de TI como uma área muito demorada.

Eis que surge então a resposta para todos os problemas. Um processo que não define nenhuma documentação e/ou passo de modelagem e que vem a endossar esta prática que antes era apenas uma ideia ou fruto das pressões mencionadas. Um processo que privilegia os produtos entregues ante as documentações ostensivas, que proporciona entrega de resultados rápidos para o cliente, que não impõe a existência de muitos papéis específicos, sendo desta forma facilmente incorporado por qualquer time de desenvolvimento. Eis que surge o Scrum.

Scrum

Diversas consultorias surgem então para explorar este que é vendido como a bala de prata, a bola da vez. Outras consultorias que vendiam outros tipos de treinamento passam a se adaptar à nova onda, para não perder market share. Completando o cenário, diversos Scrum Masters se formam e passam a influenciar comunidades, que passam a levar as ideias ágeis para suas empresas, como solução para seus problemas. Não que isso seja privilégio do Scrum. Acredito que o mesmo tenha acontecido com o RUP anteriormente e com diversas outras siglas e acrônimos que vão e vem no nosso mercado o tempo todo. Com toda essa catequização, o RUP passa a se consolidar então como um processo burocrático, antiquado, e que não atende às expectativas dos clientes.

O que não é lembrado por muitos, no entanto, é que o RUP também é um processo iterativo e incremental assim como o Scrum, de forma que com ele também é possível fazer entregas rápidas, coletando feedbacks logo no inicio do projeto, assim mitigando os riscos antecipadamente. Nada impede também que o RUP seja customizado para cada realidade. Existe, por exemplo, o RUP for small projects, que traz um apanhado mais enxuto com relação à sua versão original. Outra possibilidade ainda é criação do seu próprio processo, selecionando um conjunto de artefatos, papéis e conceitos do RUP que façam sentido para a sua organização.

Já outro ponto nas metodologias ágeis que muitas vezes é mal interpretado é quanto à ausência de especificações e/ou documentações. O manifesto ágil não diz que nenhuma documentação ou especificação deve ser feita. Ele diz apenas que o software funcionando é mais prioritário do que uma documentação abrangente. No livro “Utilizando UML e Padrões”, Craig Larman fala sobre uma abordagem de modelagem que ele chama de “modelagem ágil e desenho leve UML”. Nesta abordagem os diagramas UML são desenhados para proporcionar entendimento e comunicação ao invés de documentação. Além disso, os diagramas são feitos em quadros brancos ou folhas de aderência, de forma que eles sejam posteriormente digitalizados através de fotos e programas específicos.

Pessoalmente acredito que um levantamento inicial de requisitos e que diagramas de casos de uso ajudam bastante no entendimento e na concepção inicial de um projeto, bem como na visualização do seu tamanho e escopo. Além disso, diversos diagramas da UML também agregam com visões que são importantes para a maioria dos projetos, como por exemplo, as dependências entre componentes, a modularidade e separação de responsabilidades, demostradas pelo diagrama de componentes e a distribuição dos mesmos dentre os diversos nodes de uma arquitetura distribuída, demonstrada por um diagrama de implantação.

Qual é então o processo mais adequado para cada organização? Acredito que ambos os processos e suas variantes ou customizações podem atender às necessidades de diferentes tipos de organizações, dependendo da sua cultura, necessidade e porte. Empresas que optam pelo RUP, por sua customização ou por um processo baseado nele, normalmente possuem cultura séria / rígida, onde constantes auditorias exigem documentos e práticas registradas, possuindo também uma estrutura de profissionais robusta. Já as organizações que possuem cultura descontraída e que optam ou que só podem ter times pequenos que atendam responsabilidades específicas, normalmente melhor se adaptam ao Scrum e aos demais processos e conceitos ágeis.

E você, o que acha? A sua empresa adota um destes processos de forma satisfatória?

Deixe um comentário

O seu endereço de e-mail não será publicado.