Agile e "tradicional": pingos nos i's.

domingo, 21 de novembro de 2010

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.  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 métodos Á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!

Bookmark and Share

5 comentários:

Juan disse...

Caro Peter,

Teu post me fez relembrar minhas discussões intermináveis no CMM-Brasil alguns anos atras... pena que o conteúdo do forum foi apagado depois de fecharem o grupo.

Acho que o problema todo não é o que as coisas são, e sim o que a maioria das pessoas pensa que são.

Acabou ficando grande a resposta e acabou dando um post no meu blog que estou hoje fazendo o segundo post....

http://blog.bernabo.com.br/2010/11/o-que-rup-cmmi-e-pmbok-sao-para-1-e.html

Abraços,
Juan.

Thiago Ghisi disse...

Peter, excelente texto, realmente precisamos colocar os pingos nos is!

Tem muita gente que fala sem ter fundamento nenhum. Essa semana mesmo, vi vários "agilistas" detonando o CMMI e o MPS.BR no twitter sem mesmo ter noção de que são apenas modelos. É triste!

Querer comparar CMMI/MPS.BR com Scrum/Agile é a maior besteira do mundo!

Fosse super-esclarecedor sobre essas comparações bestas que muitos fazem por desconhecimento ou por interpretações errôneas desses modelos/metodologias.

O Carlos Barbieri vai gostar muito desse seu post!
Ele já bate nessa tecla há anos:

http://improveit.com.br/podcast/improvecast-8-entrevista-carlos-barbieri-mpsbr

http://blogdobarbi.blogspot.com/

Parabéns!

Abs,

P.S: Também sou implementador MPS.BR, quando quiser trocar algumas idéias: thiago.ghisi@gmail.com.

Peter disse...

@Juan
Grande Juan! Fico feliz de saber que você leu o post e mais ainda de que aprovou. Obrigado pelo comentário e pelo apoio. Seu post também é muito bom, um alerta para a comunidade.
@Thiago
Este podcast é antigo, hein? :-) Eu lembro quando foi postado! E o Blog do Barbieri é um dos que acompanho na área. Acho o trabalho que ele está fazendo formidável! Já viu o mapeamento que ele está fazendo entre Scrum e MPS.BR? Muito bom, né?
Vamos bater um papo sim! Até breve! Obrigado pela atenção e pelo comentário.

Vinicius Morgado disse...

Peter,

Excelente post!

Um dos grandes males da nossa área é essa "síndrome de torcida de time de futebol", aquilo que faz o camarada falar mal de qualquer coisa que seja fora do "time" dele. É de chorar alguns comentários que ouvimos no nosso dia a dia...

Posts como esse são para pendurar na parede. Servem pra mostrar pra essa galerinha que lugar de torcida é no estádio(e sem violência rs).

Parabéns!

Grande abraço,
Vinicius

Thiago Ghisi disse...

@Peter

Realmente, esse podcast é antigo, mas ainda é uma aula e tanto. Eu tbm assiste ele logo que saiu em 2007, foi muito bom ouvir a conversa desses dois monstros naquela época.

Eu vi o mapeamento sim, no geral eu gostei, mas acho que ele poderia se aprodundar um pouco mais em certos pontos.

O próprio guia de implementação do MPS.BR poderia ser um pouco mais completo. Por exemplo: As RAPS 11 e 12, tem duas linhas de detalhamento...Vergonha isso..

@Vinicius

Comentário Sensasional! Fui obrigado a compartilhar essa tua celebre frase no twitter!

Postar um comentário

 
addthis_config = { data_ga_tracker: pageTracker }