Skip to content

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.

Fases do RUP - portugues.jpg

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 isso, não tem aquilo. Acredito que essa seja a maior distorção feita respeito. No SCRUM não existe a obrigatoriedade de artefatos, na verdade não existe não existe obrigatoriedade de nada. Apesar de não estar amparado num certificação de SCRUM Master, ao ler SCRUM e XP direto da trincheira, de Henrik Kniberg, fica bem claro que as estórias do SCRUM é qualquer tipo de atividade que precisa ser adicionada ao backlog do produto e que irá para o backlog do Sprint, de forma que poderá feito uma especificação de caso de uso, um diagrama de sequencia, um script de banco de dados, um documento de casos de testes ou mesmo sua execução, enfim, qualquer atividade que é necessária para produzir um entregavel no Sprint. Quero aproveitar essa passagem para dizer que entendo que a documentação em projeto é muito importante, pois as pessoas não são eternas e já tiver oportunidade de atuar em projetos de grandes organizações que é praticamente impossível fazer algo em uma aplicação, pois não existe nenhum tipo de documentação o que inviabiliza o atendimento de qualquer SLA – Service Level Agrement. A documentação tem que ser feita de forma objetiva e que irá agregar valor para a aplicação ao longo do seu ciclo de vida o que inclui a sua entrada em produção.

Já imaginou em um projeto “tradicional”, usando IRUP, fosse feito um planejamento de forma que a cada duas semanas fossem entregue alguma funcionalidade ou algo que seja definido como entregavel, que todos os dias a equipe se reunisse para fazer o acompanhamento do projeto, que no fim dessas duas semanas fossem verificados o que deu certo, o que deu errado, o que foi entregue, o que não, e que o plano de projeto e a lista de requisitos fosse alterada caso houvesse alguma alteração acordada e que, se fosse o caso, os entregáveis tivesse sua ordem de entrega alterada? Parece com algo que já conversamos, não é?

Para finalizar, a minha visão é essa, ágil está mais ligado o gerenciamento e condução dos projetos. Acredito que alguns projetos e organizações as características e valores ágeis serão mais fácies de ser implementados, em outros será o contrário. O importante é sempre estarmos aberto a novas ideias, novas formas de fazer as coisas e agregando o que de melhor cada um tem para o seu projeto, acredito que podemos evoluir e poder produzir software com melhor qualidade, custo e no prazo, o sonho de qualquer gestor.

Inté mais.

Posts relacionados:

13 mar 2013 | Postado por em Artigos | 0 Comentários

Deixe seu Comentário