Dsenvolvimento Tradicional X Desenvolviemnto ágil

Desenvolvimento tradicional x desenvolvimento ágil de software

Vou começar o meu primeiro artigo abordando um tema que gera muitas controvérsias hoje em dia na área desenvolvimento de software: desenvolvimento tradicional x desenvolvimento ágil.

Quando falar em desenvolvimento tradicional, vou falar do UP – Unified Process, melhor personificado na figura do IRUP – IBM Rational Unified process, da IBM. Muitos poderiam entender por desenvolvimento tradicional o famoso método Cascata, mas é uma forma de desenvolvimento que caiu em desuso (mas acredito que dependendo do produto o Cascata iterativo possa ser aplicável). Por outro lado, quando estiver falando de desenvolvimento ágil vou focar no SCRUM que é o método mais difundido hoje, apesar de existir vários outros como XP, KANBAN e por aí vai.

Ainda acredito que a qualidade do software não depende de qual modelo de desenvolvimento de software é utilizado, mas sim como o processo de software é feito. Há pouco tempo tive um desafio quando um gerente chegou para mim e disse assim: ‘O cliente deseja que o sistema dele seja feito de forma ágil. Ele quer o software pronto o quanto antes, pouca documentação, enfim, quer ver o negócio pronto logo!’. Sempre fui um entusiasta de engenharia de software e processos, sejam eles lean – outro termo que anda em voga no mercado – ou simplesmente, enxuto, ou tradicionais (para alguns isso quer “pesado”). A primeira coisa que perguntei foi: ‘O cliente tem a culta de utilizar processos ágeis?’. A resposta, como eu previa, foi um enorme não.

Algumas pessoas acham que os métodos ágeis irão resolver tudo e que o desenvolvimento tradicional acaba por ‘engessar’ as coisas, produzir documentação para nada. Fred Brooks costuma dizer que não existe bala de prata (There is no silver bullet). Também concordo que isso tudo é utopia. O fato de usar IRUP ou SCRUM não garante que o seu projeto terá sucesso nem quer será um fracasso. Da mesma forma que se as boas práticas de gerenciamento presentes no PMOK forem usadas seu projeto será uma sucesso ou contrário. Acredito que tudo existe seu momento e lugar para ser usado. Uma das coisas que acho bem interessante lendo o PMBOK é que em todas as áreas de conhecimento existe como entrada ‘Ativos de processos organizacionais’. Acho que cultura da organização e estrutura dela influencia e muito na aderência de uma metodologia de desenvolvimento de software ou outra qualquer, como mostrado no caso de metodologia de gerenciamento de projetos.

A primeira coisa que se diz do IRUP é que ele é pesado, muitos artefatos precisam ser produzidos e por aí vai. A primeira frase que existe no livro do IRUP é algo do tipo: ‘O processo deve ser customizado as necessidades de sua organização’. Portanto, não é IRUP que manda que muitos artefatos sejam produzidos, a única coisa que é preconizada é que existem quatro fases: concepção, elaboração, construção e transição.

Outra coisa que é obrigatória é o fato do processo ser iterativo, o que para mim é que cada iteração é análogo ao Sprint do SRUM. Os papéis do IRUP são relativos a competências como gerente de projetos (o SCRUM Master), arquiteto, analista de requisitos, desenvolver e por ai vai. No caso do SCRUM é requerida uma equipe multidisciplinar, mas de qualquer forma esses papéis vão existir, porém não formalmente como no IRUP. Uma figura que existe no SCRUM forte é o PO – Product Owner. Acho sensacional isso, pois no caso do IRUP existem vários PO’s o que dificulta demais o trabalho. Alguém pode vir dizer por o SCRUM ser ágil não tem documentação, não tem