RUP x Metodologias Ágeis: uma análise crítica
Autor: Lizandra | Publicado: 2011-04-06T14:08:00-03:00

ResumoEm sua obra Agile Testing, Lisa Crispin e Janet Gregory (2009) destacam que "Agile is a buzzword", ou seja, “Ágil é uma palavra da moda”. De fato, observa-se um interesse crescente por estas metodologias ágeis para desenvolvimento de software com a expectativa de que sejam mais “leves” e menos burocráticas do que as metodologias tradicionais. Este texto apresenta uma análise crítica do processo de desenvolvimento de software RUP, comparado com práticas e princípios de metodologias ágeis, com base em uma breve pesquisa bibliográfica. 1. As Metodologias Ágeis Para Abrahamsson (2002), uma metodologia é ágil quando o desenvolvimento do software é feito de forma incremental (liberação de pequenas versões, em iterações de curta duração), colaborativa (cliente e desenvolvedores trabalhando juntos, em constante comunicação), direta (o método em si é simples de aprender e modificar) e adaptativa (capaz de responder às mudanças até o último instante).  Para Crispin e Gregory (2009), o desenvolvimento ágil reconhece a realidade de que os desenvolvedores só possuem algumas horas boas e produtivas em um dia ou semana, e que não podem planejar além da inevitabilidade da mudança.   Entre as principais metodologias ágeis destacam-se o XP (eXtreme Programming, ou Programação Extrema), que prega desenvolvimento orientado a testes (TDD) e programação em pares, entre outras práticas; o FDD (Feature Driven Development), orientado a funcionalidades; o Scrum, voltado para o gerenciamento de projetos; Crystal, que é uma família de metodologias um pouco menos disciplinadas que o XP; Método para Desenvolvimento de Sistemas Dinâmicos (DSDM), com forte envolvimento dos clientes e testes tratados fora do escopo do ciclo de vida do projeto.   Estas metodologias têm seus princípios apoiados no Manisfesto Ágil, que é um conjunto de valores elaborados em 2001 por um grupo de importantes profissionais de software, entre eles Martin Fowler, Kent Beck e Alistair Cockburn (Beck, 2001). O Manifesto Ágil preconiza que devem ser valorizados os seguintes princípios:   “Indivíduos e interações mais que processos e ferramentas.Software em funcionamento mais que documentação abrangente.Colaboração com o cliente mais que negociação de contratos.Responder a mudanças mais que seguir um plano.”  Ou seja, mesmo havendo valor nos itens à direita, são mais valorizados os itens à esquerda.  Crispin e Gregory (2009) traçam um comparativo, sob a ótica de testes, entre times ágeis e times “tradicionais”. Segundo as autoras, em times tradicionais há uma Ilusão de controle (sem controle de como o código é escrito e se os programadores testam o código) enquanto que em times ágeis há um entendimento detalhado dos requisitos devido à proximidade do cliente e especialistas no negócio. Da mesma forma, enquanto nos times tradicionais entrega-se o que foi acordado nos requisitos, nos times ágeis o foco está no valor a ser entregue. Cada pessoa do time ágil é focada em entregar um produto de alta qualidade que forneça valor de negócio. 2. O RUP O IBM Rational Unified Process (RUP) é um framework de processo de engenharia de software que fornece um conjunto de práticas testadas na indústria para desenvolvimento de software e gerência de projetos (Shuja, 2007). Trata-se de um processo proprietário, desenvolvido pela Rational Software, atualmente subsidiária da IBM, que usa abordagem orientada a objetos e preconiza a utililização da notação UML (Unified Modeling Language) para documentação. É organizado em disciplinas (workflows) onde são distribuídas tarefas e responsabilidades e gerados produtos de trabalho (artefatos). O ciclo de vida é dividido em fases seqüenciais, as quais podem ser subdivididas em iterações.  Estas duas dimensões do processo podem ser observadas na Figura 1. O eixo horizontal representa o tempo, expresso em termos de fases, iterações e marcos (milestones). O eixo vertical expressa as atividades, artefatos e papéis. O preenchimento do gráfico, representa o volume de cada atividade ao longo das fases e iterações. Figura 1  - Overview do RUP (Suhja, 2007).  O RUP, em suas versões iniciais apoiou-se em melhores práticas observadas na indústria, a saber: Desenvolvimento  de software iterativo (melhor adequação a mudanças).Gerenciamento  de requisitos (identificar e especificar as necessidades do usuário  final).Uso  de arquitetura baseada em componente (visando reuso de componentes).Modelagem  visual de software (abstração do modelo de negócio, por meio de  UML).Verificação  da qualidade do software (planejamento, projeto e execução de  testes).Controle  de alteração no software (controle, rastreamento e monitoração  de mudanças).             Por mais de uma década, estas melhores práticas foram base para a evolução de ferramentas e processos na IBM/Rational (Kroll, 2005). Na versão 7.0 do RUP, as melhores práticas passaram por um amadurecimento e foram substituídas por princípios chave orientado a negócios, propondo-se o RUP 7.0 a ser um processo mais genérico e capaz de suportar o desenvolvimento ágil. Os princípios chave são os seguintes (Kroll, 2005 e Suhja, 2007):   Adaptar  o processo (identificar quanto processo é necessário ao projeto) ;  Balancear  as prioridades dos investidores (compreender e priorizar os  requisitos conforme as necessidades de negócios);  Colaborar  através de equipes (comunicação e ambientes de colaboração);  Demonstrar  valor iterativamente ( feedback inicial e contínuo, adaptar os  planos, gerenciar alterações);  Elevar  o nível de abstração (reduzir a complexidade e a quantidade de  documentação por meio de reutilização de recursos existentes);Focalizar  continuamente na qualidade (testes, integração contínua,  automação de testes incremental).              3. Análise Crítica dos trabalhos relacionados  Um estudo interessante encontrado foi o de Petersen e Wohlin (2010) em que avaliam os impactos da migração de uma abordagem de desenvolvimento orientada ao planejamento para uma abordagem ágil, com base em estudos e entrevistas na indústria, em projetos de pequeno porte. Os autores classificam o RUP, como metodologia orientada ao planejamento, da mesma forma que classificam Waterfall e Modelo-V, na qual as funcionalidades desejadas devem ser conhecidas de antemão, e um plano construído e seguido até o final.   Os resultados da revisão sistemática de Petersen (2010) apontam que a vantagem do RUP é a clara definição de papéis, e as desvantagens são o fato de ser muito extenso e de difícil aprendizado. Outro resultado demonstrou que 76% dos trabalhos relacionados são focados em XP, sendo, possivelmente a metodologia mais popular entre as ágeis e destaca como vantagens desta metodologia, a comunicação e o feedback, iterações pequenas e interação com o cliente. Como ponto negativo das práticas ágeis, os autores destacam o pouco foco na a arquitetura.   Diversos foram os estudos e publicações encontrados realizando comparações entre metodologias de desenvolvimento, especialmente RUP versus XP, sendo que a grande maioria considera o RUP na versão2003.    Tanaka (2008), apresenta uma comparação baseada nos valores do Manifesto Ágil e os princípios chave do RUP 7.0, do qual destacam-se as seguintes relações:   “Indivíduos e  interações valem mais do que processos e ferramentas”: para este  valor o RUP 7 traz o princípio  chave “Colaborar Através de Equipes”, o qual preconiza a  colaboração que tem sido foco das comunidades de desenvolvimento  ágil.“Software  funcional vale mais do que uma documentação completa”: embora o  RUP também afirme que a finalidade de um projeto de software é  gerar um produto, apresenta uma lista dos diversos documentos que  podem ser necessários ao projeto, deixando para o usuário escolher  o que for mais adequado. Neste ponto os autores destacam o vínculo  entre o RUP e a UML. Na versão de 2003 o RUP trazia como uma de  suas melhores práticas “Modele Visualmente”, afirmando este  vínculo. O RUP 7.0, por sua vez, em seu princípio chave “Elevar  o nível de abstração”, sugere reduzir a complexidade através  do uso de ferramentas, estruturas e linguagens de mais alto nível,  aconselhando o uso de notações como a UML, mas sem que seja a  única opção.“A colaboração  do cliente vale mais do que a negociação de um contrato”: como  não existe um papel efetivo para o cliente no RUP, os autores  defendem que o princípio chave “Balancear as Prioridades dos  Investidores”, para o qual é necessário compreender e priorizar  as necessidades do cliente, é o que mais se aproxima com a  colaboração do cliente ou o representante de serviços no projeto  para garantir que seja possível compreender quais são essas  necessidades.“Responder às  mudanças vale mais do que seguir um plano”: no RUP 7.0, ao invés  de “Desenvolver Iterativamente” como era na versão 2003, o  princípio chave vai mais além e coloca “Demonstrar o valor  iterativamente”, onde nota-se claramente a influência do  Manifesto Ágil sobre o RUP.          Assim como Petersen e Wohlin (2010), Tanaka e Banki (2008) também observaram em seus estudos que o RUP 7.0 destaca a necessidade de focalizar na arquitetura logo no início, como uma forma efetiva de gerenciar a complexidade do sistema, sendo esta uma diferença conceitual em relação a metodologias ágeis como o XP, que confiam na refatoração contínua do código como uma forma de obter naturalmente a arquitetura mais adequada para o software. 4. Conclusão Como pode ser observado nas seções anteriores, os principais valores preconizados nas metodologias ágeis são relacionados a pessoas, iterações, participação do cliente e adaptação às mudanças.  A abordagem dada ao RUP na sua versão 7.0 incorpora esses valores e princípios que foram difundidos, principalmente a partir do Manifesto Ágil. Este fato reafirma a premissa do RUP de ser “um conjunto de práticas testadas na indústria para desenvolvimento de software”, pois os conceitos das metodologias ágeis alteraram as práticas de mercado e as comunidades de desenvolvimento de software, e o RUP adaptou sua própria abordagem.  Acredita-se que o grande objetivo a ser buscado com metodologias de desenvolvimento seja a capacidade de adaptação e de responder rapidamente a mudanças, e não simplesmente agilidade ou desburocratização dos processos. Sobre a inevitabilidade das mudanças nos projetos, Rex Black (2010) citou em palestra no ano de 2010 que “é preciso dar boas vindas às mudanças de requisitos porque elas vão acontecer mesmo que você não queira. Ágil não significa estável, temos que abraçar as mudanças” quando comparou o movimento ágil com o movimento comunista no qual se utilizava a frase “você pode não estar interessado na revolução, mas a revolução está interessada em você”. Mudar é natural e é um reflexo da evolução humana. O usuário de software muda de idéia a medida em que conhece mais o contexto e a tecnologia do sistema.  A participação e o feedback do cliente continuam sendo a grande “chave” dos projetos e independem das metodologias. No estudo de Tanaka (2008) fica evidente que o claro envolvimento do cliente ainda é uma oportunidade de evolução para o RUP, mesmo na versão 7.0. Acredita-se que, com uma maior participação do cliente, algumas atividades poderiam ser mais produtivas e até o volume de artefatos poderia ser reduzido.  No que tange à adaptação do RUP e sua aplicação como metodologia ágil, Shuja (2007) ilustra na figura reproduzida abaixo que muitos fatores, tais como, tamanho do projeto, distribuição da equipe, número de partes interessadas, conformidade dos requisitos e a fase em que o projeto se encontra, influenciam na decisão sobre quão disciplinado (nível de “cerimônia” ou formalismo) um processo deve ser. É o princípio chave do RUP 7.0, “Adaptar o Processo”, que viabiliza esta adaptação.  Figura 2 - Fatores chave que afetam o processo (Shuja, 2007).   Devido a sua característica de ser um framework o qual pode ser adaptado, o RUP pode ser aplicado desde uma forma mais tradicional, como ciclo de vida em cascata, até formas iterativas e ágeis, bastando “enxugar” o volume de atividades e artefatos (Fowler, 2005).5. Referências   Abrahamsson, P. et al. (2002), Agile software development methods: Review and analysis.VTT Publications 478. Oulu, Finland: VTT Publications. Beck, K. et. Al. (2001), Manifesto for Agile Software Development. Disponível em: &lt;http://agilemanifesto.org/iso/ptbr/&gt;. Acesso em 29/11/2011. Black, R. (2010). Agile Testing Chalenges: Successful testing on agile projects. Palesta, CINTEQ 2010. São Paulo. Crispin, L. e Gregory, J. (2009), Agile Testing: A practical guide for testers and agile teams. Addison-Wesley. Fowler, M.. The New Methodology. (2005). Disponível em: &lt;http://www.martinfowler.com/articles/newMethodology.html&gt;. Acesso em: 28/13/2011. Kroll, P., Royce, W. (2005), Key principles for business-driven development. IBM DeveloperWorks. Disponível em : &lt;http://www.ibm.com/developerworks/rational/library/oct05/kroll/index.html&gt;. Acesso em 29/03/2011. Petersen, K., Wohlin, C. (2010). The effect of moving from a plan-driven to an incremental software development approach with agile practices. An industrial case study. Published online: 10 July 2010. Springer Science+Business Media, LLC 2010. Editor: Forrest Shull. Disponível em: &lt;http://portal.acm.org/citation.cfm?id=1861404&gt;  . Acesso em 28/11/2011. Shuja, A. K., Krebs, J. (2007), IBM Rational Unified Process Reference and Certification Guide. Solution Design. Prentice Hall.Tanaka, S. A., Banki, A. (2008), Alinhamento do RUP 7.0 aos Valores do Movimento Ágil. E-Tech: Atualidades Tecnológicas para Competitividade Industrial, Florianópolis, v. 1, n. 1, p. 4-17, 1º. sem., 2008. Disponível em: &lt;http://revista.ctai.senai.br/index.php/edicao01/article/view/19/17&gt; . Acessado em 27/03/2011.