Estou há tempos devendo um post sobre o artigo do Ivar Jacobson (um dos inventores do RUP e pai da UML) e seus colegas, primeiramente publicado numa série de artigos da Dr. Dobb's e depois num paper no JOLT. No geral eu concordo com o seu ponto de vista, mas antes de ouvirem (lerem?) o que tenho a dizer, sugiro fortemente ler o artigo original. Pronto? Agora podem continuar a ler meus comentários…
Terminologia
Antes de falar sobre o artigo, queria esclarecer algumas coisas sobre o termo “processo”. Essa palavra geralmente vem carregada de uma série de significados que podem não ser os mesmos de pessoa para pessoa. Se você ler o
Manifesto Ãgil, verá que “IndivÃduos e interações são mais importantes que processos e ferramentas”. Que tipo de processo o Manifesto se refere? Aquele mega-processo formalizado que todos precisam seguir ou, como diz o Tim Lister, processo é tudo aquilo que você faz no dia-a-dia, quando ninguém está olhando (ou avaliando) ou mesmo quando está sobre pressão? Recentemente, a
Mary me fez repensar sobre o assunto e ela sugere a palavra “sistema” ao invés de “processo”. Como não é a primeira vez que ela me faz repensar algumas coisas, prestei atenção e concordo com a sua colocação, afinal de contas, independentemente de seguirmos algo padronizado ou não, todos acabamos fazemos alguma coisa no nosso dia-a-dia (alguns podem chamar isso de processo ou não). O “processo” do ponto de vista Lean e o “processo” na definição do Tim Lister não são o mesmo “processo” que o Ivar Jacobson está criticando. Daqui pra frente, quando eu falar em “processo”, estou me referindo ao mesmo processo do Ivar Jacobson.
O inventor do RUP está dizendo que o RUP não funciona?
Não sou o único que acredita que (e conhece) muitas empresas que implantaram o RUP de forma errada. Gostei do
exemplo do
Vinicius, comparando o RUP com um grande supermercado de processos, onde você faz suas compras (agora, com o
OpenUP você pode fazer compras de graça) e coloca no carrinho as coisas que acha mais convenientes. Isso gerou uma série de malefÃcios na indústria, que vou tentar citar abaixo (alguns não são culpa direta do RUP e, pelo que vi, o OpenUP parece estar bem mais ágil):
- Processo pesado demais: “Não sei se preciso disso, mas na dúvida é melhor não ficar sem” (quando se trata de comida, minha mãe sempre disse que é melhor sobrar do que faltar) :-)
- Disfarce para Cascata: Incepção = Levantamento de Requisitos, Elaboração = Análise, Construção = Implementação/Testes e Transição = Implantação. Cabe aqui dizer que já ouvi gente reclamando que o RUP não lida com a fase de manutenção (que seria a próxima fase do Cascata que não aparece nos quadradinhos). Minha resposta para essa pergunta vale outro post, mas precisamos parar de pensar que desenvolver e dar manutenção são coisas totalmente diferentes. O software deve estar em constante manutenção.
- Processo pelo processo: “Que bom! Já tenho templates de documentos prontos para tudo! É só alocar alguém para prenchê-los”. Pior, eu já vi gente fazendo “RUP” escrevendo toda essa documentação DEPOIS só para seguir o processo. Alguém escreve Use Case depois que já tem algo implementado?!?!
- Decomposição em especialidades: “Sou apenas arquiteto, não escrevo código” ou “Esse documento é responsabilidade do arquiteto! Não ouse duvidar da sua validade, mero desenvolvedor”
- Gerenciamento voltado para alocação de papéis e tarefas: “Essas baleias fazem sentido. Não preciso de desenvolvedores no começo e o arquiteto vai estar livre para outro projeto na terça-feira da segunda semana do mês que vem…”
- Modelagem voltada para documentação: “Preciso gerar esses Use Cases. Preciso gerar os diagramas de classe. Preciso gerar os diagramas de seqûências, …”
Resumindo, concordo com o inventor do RUP que esse tipo de processo precisa acabar e que as pessoas não lêem os livros antes de aplicar os conceitos.
Meu processo é diferente do seu
Como é muito bem colocado no artigo, existem semelhanças entre os diversos processos. Mas o importante é que o processo seja
“adaptativo, extensÃvel e capaz de absorver boas idéias” (destaque meu). Ao estudar Lean, você verá que o processo existe apenas para ser desafiado. As pessoas devem ter o poder de mudá-lo sempre que encontrarem desperdÃcios ou pontos de melhoria. Se você estava atrás de um processo que resolveria todos os seus problemas, O processo que seria padrão da empresa, sinto informar que ele não existe (e não sou nem eu que estou dizendo, o
Fred Brooks já
disse isso há bastante tempo). Definir um comitê para definição DO processo é, no mÃnimo, um desrespeito ao intelecto das pessoas que irão seguÃ-lo. Como um grupo de pessoas que não está trabalhando (e usando o processo), pode definir o melhor jeito que algo deve ser feito?
Além disso, os Métodos Ãgeis já sabiam dessas coisas há um certo tempo. Crystal coloca a reflexão como uma das bases da metodologia e, mais pra frente, as reuniões de Retrospectiva foram incorporadas em outros processos como Scrum e XP. Hoje em dia, utilizo retrospectivas em vários contextos! É uma ótima forma de aprender com nossos acertos e erros e de melhorar para o futuro.
Concordo com todas as crÃticas aos processos colocadas por Ivar Jacobson: que têm diversos pontos em comum, que nunca serão totalmente completos em todos os aspectos, que nunca serão adotados de forma completa ou
by-the-book, que não transmitem o conhecimento de forma eficiente e que podem ser estúpidos em alguns casos.
Usem práticas!
A solução do Jacobson é não focar mais em processos completos e pesados, mas sim em catalogar uma coleção de práticas. Cada prática deve ser isolada e atacar um aspecto especÃfico do desenvolvimento. Dessa forma, cada “metodologista” (como ele diz) pode montar (e mudar) o seu processo conforme suas necessidades. O que eu achei legal na definição dele é que cada prática deve se “auto-verificar”. Em outras palavras, ela deve estabelecer um objetivo claro e uma forma de avaliar se esse objetivo foi atingido. As
métricas de acompanhamento podem ajudar bastante aqui.
Apenas práticas resolvem?
Apesar de eu concordar com a mudança de foco (processos para práticas), ainda acredito que só as práticas em si não são tudo. Em XP, as 12 práticas originais dobraram (13
práticas primárias + 11
práticas corolárias). E isso foi feito com base nos valores e princÃpios da metodologia. XP se baseia nos valores da
comunicação,
feedback,
simplicidade,
coragem e
respeito. São a forma como avaliamos uma determinada situação (seja desenvolvendo software ou arrumando a casa). Valores são amplos, enquanto práticas são especÃficas. Não consigo convencer minha empregada a usar TDD ou Programação Pareada para limpar meu quarto, mas posso conversar de forma respeitosa e mostrar que não faz sentido guardar um pé do tênis junto com um pé do sapato. Você pode chamar isso da prática do Calçado Pareado se quiser :-)
Na
segunda edição do livro de XP, Kent Beck define melhor ainda os
princÃpios da metodologia, que ajudam a traduzir os valores (amplos) em práticas (especÃficas). Acredito que para adaptar um processo de forma consciente e eficiente, não basta olhar apenas para um repositório de práticas e sair escolhendo. Precisamos dessas ferramentas mentais para auxiliar a adaptação para nossa situação. No livro
Lean Software Development, por exemplo, a Mary e o Tom se focam quase exclusivamente nos princÃpios. A GM e A Ford tentaram copiar as práticas da Toyota e não conseguiram atingir os mesmos resultados.
Eliminamos os processos. E as ferramentas?
Minha última crÃtica ao artigo do Jacobson é que ele dá todos os argumentos contra os processos e, no final, mostra uma nova ferramenta, o EssWork, para gerenciar o repositório das práticas (e seus cartões), para organizar a forma de trabalho da equipe (seu processo) e para integrá-lo com as ferramentas de desenvolvimento da equipe. Não que eu seja totalmente contra o uso de ferramentas, mas assinei o manifesto e prefiro valorizar indivÃduos e interações. Até chegar nessa parte eu estava gostando da idéia dele de utilizar cartões para representar as práticas e para montar o processo da equipe. Digamos que me decepcionei um pouco no final, mas nada que invalidasse o resto das coisas que havia gostado.
Acredito que ouvir uma opinião dessas de um cara tão respeitado pelos mais “tradicionalistas” é muito encorajador para nós. Segundo ele mesmo coloca, estamos numa fase de transição para uma nova era da engenharia de software e acredito que os Métodos Ãgeis servirão como uma excelente base para mudarmos o cenário da nossa indústria.
Twitter
LinkedIn
Facebook
Flickr
Github
