Agile e "tradicional": pingos nos i's.
Autor: Peter Lupo | Publicado: 2010-11-21T01:52:00-02:00

Bom, como vocês podem já ter notado pelos meus posts, me interesso tanto Agile como não-agile. Inclusive já postei sobre o que eu considero ser Agile e não-agile (o que muitos chamam de tradicional). O caso é que desde que comecei a estudar processos e metodologias, estudo nos dois flancos. RUP, XP, PMBOK, MPS.BR, CMMI, Scrum, Kanban, Cascata, Iterativo e Incremental, etc.
Bom, pra quem conhece estas coisas, sabe que eu listei coisas que tem a ver e coisas que não tem a ver entre si. &nbsp;Entre processos, metodologias, modelos de maturidade, e afins, fiz uma mistura proposital.

Em muitas conversas, vejo pessoas comparando coisas diferentes, falando coisas sobre estes assuntos e tratando-os como sendo a mesma coisa ou fazendo outros tipos de confusões. Ok, são muitas siglas, eu sei. Se você se confunde, está perdido ou conhece muito pouco sobre estas coisas, chegou a hora de desfazer a confusão:



O modelo Cascata
Cascata não é um processo. Cascata não é uma metodologia. Cascata, assim como Iterativo e Incremental, é um Modelo de Ciclo de Vida.
O modelo cascata é aquele em que se faz toda a análise no início, depois se faz toda a modelagem, toda a codificação e todos os testes. Quaisquer que sejam as fases do seu processo, se em uma fase (por exemplo, análise) você faz tudo o que tem pra fazer do projeto (por exemplo, fez análise do projeto inteiro) não retorna a ela depois que entrou em outra (por exemplo, codificação), então você está seguindo um modelo em cascata.

O XP e o Scrum são metodologias que não adotam o modelo cascata pois depois de fazer codificação e testes, eles voltam para fazer análise e modelagem de funcionalidades que ainda não foram abordadas. O modelo que adotam é Iterativo e Incremental.

Notem que o cliclo de vida trata única e exlusivamente da ordem das atividades e não quais atividades são feitas. Por exemplo, você pode ter um processo em Cascata que se inicia com o registro de uma visão, um backlog de user stories, os testes delas e por último seu desenvolvimento com uma integração no final, quando então são feitos uma revisão e uma retrospectiva. Pode até desenvolver em pair programming. Notem que não é Scrum, pois o Scrum fala especificamente de outro modelo de ciclo de vida. No entanto, também não são utilizados casos de uso nem nada que tenha ganho popularidade com Agile.
Ao mesmo tempo posso ter todas as atividades mais tradicionais e ainda ter um processo em várias iterações, onde em cada uma eu escolho alguns requisitos e passo por todas as fases até gerar um release intermediário.

Vale lembrar que métodos ágeis não foram os primeiros a adotar o modelo iterativo e incremental. O RUP, um framework de processos, adota o mesmo modelo.


RUP
RUP não é um processo em si. O RUP, o Rational Unified Process, criado pela Rational (empresa que criou o Rational Rose, famosa ferramenta de modelagem), adquirida pela IBM, é um framework de processos de software.

Isto significa que o RUP apresenta vários artefatos, templates, atividades, fases, objetivando atender um grande escopo de necessidades.

Assim como todo framework, é necessário que em cada situação, a pessoa encarregada de construir o processo analise as suas necessidades e faça um recorte, uma escolha do que deve ser utilizado dentro do que o RUP apresenta.

Ou seja, o RUP pode dar origem a um processo extremamente burocrático ou até um processo leve e fácil de ser seguido. Como qualquer coisa na nossa área, depende de como é usado, por quem é usado e em que cenário foi usado.

Nota-se já que o RUP não é UM processo e que RUP e Cascata são coisas completamente distintas, embora o RUP possa ser mapeado para um processo em Cascata. Afinal, ninguém irá impedir ninguém de fazer adaptações, sejam boas ou ruins. Se você seguiu um processo baseado no RUP e não gostou, a culpa pode não ser do RUP.


PMBOK
O Project Management Body Of Knowledge (corpo de conhecimento em gerência de projetos) apenas organiza o conhecimento na área de gerência de projetos. Aborda temas como gerência de riscos, modelos de ciclo de vida, etc. Porque o Project Management Institute (PMI) resolveu organizar o conhecimento na área não quer dizer que você deve utilizar tudo o que se conhece na área em um projeto. Além disso, não há definição de seqüência de atividades, entradas e saídas. Não é um processo. É apenas o que o nome diz: um corpo de conhecimento.

Portanto, chamar PMBOK de processo é um erro. Assim como é um erro atrelá-lo ao modelo Cascata ou ao RUP.

Claro que como um projeto requer gerência, um framework de processos como o RUP irá incluir atividades de gerência que podem ser associadas a alguns conhecimentos presentes num corpo de conhecimento de gerência, pois se não estiverem associadas, significa que o corpo de conhecimento de gerência deixou de incluir alguma coisa.

Da mesma forma, é apresentado o modelo Cascata assim como o iterativo e incremental. É um corpo de conhecimento, como um catálogo.


CMMI e MPS.BR
CMMI e MPS.BR não são processos, não são métodos, não são metodologias, são modelos de maturidade.
Um modelo de maturidade apresenta um guia do que uma organização pode fazer para melhorar sua maturidade e sua capacidade.

Este guia apresenta "o que" fazer e não "como". Por exemplo, ele diz que você deve desenvolver seus requisitos. Se seus requisitos são casos de uso ou user stories, quem decide é você. Ele diz que você deve testar. Se você fará testes automatizados ou manuais, se utilizará TDD ou não, quem decide é você. Se o seu processo é cascata ou iterativo e incremental, quem decide é você. Se você faz sprint review e sprint retrospective ou não, quem decide é você.

O interessante destes modelos é que eles apresentam, a cada nível, novas áreas e novos requisitos para áreas introduzidas anteriormente, servindo como guias para aumentar a maturidade e a capacidade de se fazer software, reduzindo custos, prazos e aumentando a qualidade.

É cada vez mais comum atualmente encontrar organizações que utilizam métodos ágeis e são avaliadas seguindo modelos de maturidade, pois há um grande nível de compatibilidade.


Metodologias Ágeis
Metodologias ou&nbsp;métodos&nbsp;Ágeis são aqueles que estão alinhados com o Manifesto Ágil, ou seja, qualquer processo de desenvolvimento que valorize:
"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"

Os mais populares são Scrum, Extreme Programming (XP), FDD, OpenUP, Crystal e Kanban, mas além destes, qualquer processo que siga os valores acima pode ser considerado Ágil, independente das práticas e das atividades que são executadas. Logo, não há problema em ser Ágil e utilizar um processo baseado no RUP que atende um nível do MPS.BR num processo cuja gerência é orientada por práticas descritas no PMBOK.

Segue outra referência detalhada sobre Métodos Ágeis, em inglês.

Uma parte da comunidade Ágil atualmente rechaça vários destes conceitos como se fossem incompatíveis com a filosofia e não são. Pior, falam deles como se fossem o contrário de Ágil. Já vi inúmeras comparações entre Cascata e Scrum dizendo que o último é melhor. Dizem que MPS.BR e PMBOK são Cascata e por isso são ruins e outras coisas do gênero.

Escolhi estes tópicos em particular porque normalmente a comunidade Ágil faz referência a eles como "tradicional" numa alusão a uma forma tradicional de se fazer software. A questão é que eles não definem uma forma "tradicional" de se fazer software pois não há ruptura entre o movimento Ágil e estes conceitos, visto que não são antagônicos, não são incompatíveis. É como dizer que existe pizza antes e depois de existirem pizzarias, quando você antes podia comer uma pizza excelente em um restaurante que não seja especializado e pode até comer outras massas em uma pizzaria sem que os diferentes estabelecimentos se descaracterizem.

Mas há, dentro do movimento Ágil, este sentimento de ruptura. É inegável. Como em muitas conversas é necessário fazer referência às formas de se desenvolver anteriores ao movimento Ágil, eu uso "não-Ágil".

Espero ter contribuído para desfazer a confusão.

Abraço a todos!