Processo Unificado vs Ágil: Ser ou não ser, eis a questão!!

Quem não conhece a famosa frase Ser ou não ser, eis a questão (no original, To be or not to be, that’s the question) que vem da peça A tragédia de Hamlet, príncipe da Dinamarca, de William Shakespeare? Incrível como até nos dias de hoje muitas vezes somos assombrados por essa dúvida cruel, principalmente nós meros mortais da área de desenvolvimento de software.

Em conversas de bares regados a chopp e salgadinhos com meus estimados amigos de trabalho e até mesmo lendo seus blogues (Gustavo Serafim, Marcelo da Costa Araújo, Philip Calçado, GUJ) sobre metodologia, processo unificado, processo ágil, RUP, XP, Scrum e as várias outras combinações do alfabeto, percebi que em muitas vezes ficamos apertando a mesma tecla e nunca saímos do lugar. Sempre vejo grandes batalhas serem travadas para chegar à conclusão de qual metodologia/processo é a melhor. Uns dizem que ser ágil é que trará os melhores resultados para os projetos, de forma que para essas pessoas devemos jogar fora toda papelada e se ligar no que realmente traz agilidade que é codificar/testar/refatorar. Já outros defendem que um processo onde não exista documentação apropriada, não se pode ter um maior controle sobre o andamento do projeto e seus inevitáveis desvios de prazo e orçamento, seja quando a equipe é grande ou ela está particionada em diversos lugares ou o projeto envolve diversas tecnologias e blá, blá, blá.

Vejo nos blogues e em muitos lugares grandes entusiastas para não dizer “religiosos” que crêem veementemente que o processo utilizado por eles é melhor do que aquele que eles não usam e que uma determinada metodologia é melhor do que a outra e blá, blá, blá. Mas nunca vejo demonstrarem a verdadeira preocupação que devemos ter ao lidar com metodologia/processo de desenvolvimento de software que é o pilar Pessoas/Boas Práticas/Ferramentas, ou seja, ao invés de ficarmos dizendo que uma é melhor que a outra, devemos nos atentar que sem pessoas treinadas para conhecer, praticar e respirar o processo, sem pessoas que utilizam de boas práticas de desenvolvimento de software e sem uma equipe com ferramentas disponíveis que apóie o processo, não adiantará de nada e continuaremos a bater cabeça contra a parede em cada projeto. E com isso todos nós nos veremos fazendo a mesma pergunta de sempre: Processo Unificado ou Processo Ágil, RUP ou XP, fazer análise ou não, modelar ou não, ser ou não ser. Essa com certeza é a grande questão dos dias de hoje para nós desenvolvedores de software.

Pilar do Desenvolvimento de Software

No nosso dia-a-dia podemos usar Use Case ou User Stories, ferramentas para UML ou rascunho no quadro, reuniões longas e chatas ou uma breve reunião diária (Standup Meeting), DDD, TDD, MDA, diagrama disso, diagrama daquilo, SOA, SCA, RUP, XP, AUP, EUP, Scrum e todas as várias outras combinações do alfabeto, que se não existir as premissas do pilar que mencionei, se as pessoas não aderirem às boas práticas de um processo de desenvolvimento, pode juntar tudo isso e jogar na lata de lixo. Eu sou uma pessoa que nos últimos anos vem tentando entender esse dilema que passamos e cheguei à conclusão que o melhor dos mundos não está em seguir somente um processo unificado ou somente um processo ágil, até mesmo porque podemos ser ágil sem usar XP ou Scrum e usando um RUP. Podemos tanto usar um RUP e customizá-lo para a necessidade de um projeto, podemos usar um XP/Scrum dependendo da situação, como também podemos usar um pouco de cada, utilizando as partes onde cada um é mais forte em determinadas situações. No final das contas o mais importante são as pessoas dentro do processo e as práticas utilizadas para chegar ao objetivo que é o software funcionando e o cliente feliz da vida.

Mas enquanto não aprendermos a usar o que realmente é necessário descartando o que não é essencial e abrir a mente para entendermos que cada situação requer estratégias diferentes e até processos diferentes, sempre estaremos nos perguntando: Ser ou não ser, eis a questão!

“Vida Longa e próspera.”