Smarana

Discussões sobre Memória Organizacional em ambientes de desenvolvimento de Software

O perigo da agilidade

Se você está lendo esse post, provavelmente foi motivado, ao ler o título, por uma das duas reações a seguir:

  1. Que besteira esse cara tá falando? Ele não sabe nada de Agile! (Agilista)
  2. É isso mesmo! Agile é um bando de preguiçoso… quero ver o que esse cara escreveu. (Anti-Agilista)

Infelizmente (ou felizmente), ambos vão se decepcionar. Não sou contra o manifesto ágil, mas acho que ele tem uma lacuna que permite uma carga cultural extremamente nociva. Meu objetivo não é criticar o movimento, mas apenas levantar questões que não deveriam ser ignoradas ou observadas de modo leviano.  Tentarei ser breve, pois meu objetivo é apenas chamar a atenção para esses aspectos.

Em primeiro lugar, acredito que atualmente as palavras são ditas/atribuídas sem muita preocupação com seu significado. “Palavra tem poder”, defendo eu. Nesse sentido, fui ferrenho defensor da correção na tradução inicial que foi feita no Manifesto Ágil, que jogava no lixo tudo aquilo que era, na verdade, apenas para ser colocado em segundo plano. Aí uma série de pessoas vem me dizer: “ah… a intenção não era essa” ou “todo mundo entende…”. Mas não é bem assim. O que está escrito claramente pode ser observado de N formas, a depender da história de cada um, mas seu significado encerrado em si pode significar apenas o que não passa por uma avaliação teleológica da coisa dita/escrita.

Outra questão envolvida com a propriedade do termo é a assunção de que a agilidade está quase exclusivamente ligada aos métodos/processos utilizados. Isso é uma inverdade brutal! Claro que toda criação de ponto de controle provocará indubitavelmente um acréscimo no esforço para o atingimento do objetivo primário. O ponto de controle, no entanto, deve servir para atingimento de outros objetivos do projeto/organização. Então é inócuo traçar um paralelo entre agilidade e processo.

Não quero dizer que existam por aí processos extremamente pesados, mal escritos ou mal executados. Ao contrário, acredito que a ineficiência exista, mas que em grande parte é fruto da intervenção equivocada de pessoas. Minha defesa reside na crença de que o que deve ser feito é ajustar os processos (ou trocá-los) para funcionarem de forma mais eficiente. Seguir Agile é exatamente isso? Sim e não!

Sim porque passamos a seguir outros Messias, a usar modelos e práticas diferentes. Mas (daí o “não”) o fazemos de uma forma irracional na maioria das vezes, quase num rito de conversão, sem observar o cerne da ineficiência. Fazemos uma coisa certa por motivo tortuoso e o resultado é randômico. Essa conclusão leva a outro ponto crítico.

Agilidade é muito mais uma questão comportamental do que uma responsabilidade a ser atribuída aos processos e às metodologias. Tem mais a ver com “fazer o mesmo em menos tempo”. Então, se consideramos que não estamos fazendo as mesmas coisas, não podemos comparar agilidade, mas sim agilidade na “confecção do produto” – sim, um objetivo específico, que não é nem de longe uma redução válida do que é o desenvolvimento de software (voltarei a esse ponto). E, já que não podemos comparar assim, devemos observar pessoas realizando a mesma atividade. Assim, veremos muito claramente práticas – sem desviar do processo adotado – que levam um indivíduo A a produzir o mesmo resultado que um indivíduo B em um tempo mais reduzido. Eu vi muito disso acontecer quando elaborava e revisava requisitos… As pessoas escreviam demais, de forma incorreta, ambígua e repetitiva, o que levava a um esforço enorme (e nada tinha a ver com o processo). Já cheguei a reformar uma descrição de Caso de Uso para 30% de seu tamanho original, sem modificar o seu sentido.

A diferença entre o embromation em equipes que usam Agile e nas que usam os processos tradicionais é que a presença de mais atividades não associadas ao objetivo primário ao invés de promover o controle favorece o encostado. Mas isso não acontece por características do processo em si, mas pelo fato de não ser feita a devida gestão. A maioria das pessoas da área não acredita, não se interessa e/ou não é formada para valorizar epraticar gestão. Somado a isso, uma grande indefinição sobre métricas de software parece obscurescer ainda mais a visão, desestimulando a prática da gestão. Então vem a grande questão: qual a razão de se adotar práticas de um processo pesado se elas não agregarão valor à sua forma de gestão? Não tenho resposta para isso, porque acho que o que não for útil deve ser descartado (de uma forma consciente).

Voltando ao ponto deixado em suspenso, o desenvolvimento de software não pode ser reduzido à confecção estanque de um produto. Aquilo será mantido no futuro – nem sempre pelas mesmas pessoas. É preciso de um registro do negócio para que os futuros desenvolvedores compreendam os porquês. A instituição é quem precisa ter compreensão do negócio do cliente para desenvolver e manter a solução e não apenas o desenvolvedor, caso contrário, a cada mudança será necessário reinvestir tempo para que o negócio seja novamente compreendido – e, pior, incomodando o cliente (porque perguntar a mesma coisa repetidas vezes é incomodar). Documentar é gravar na memória de um ser intangível (organização) aquilo que é aprendido acerca dos interesses do cliente naquele produto. Ignorar isso é o mesmo que ignorar o quão relevante foi a criação da escrita como mecanismo de registro de memória das comunidades. Além disso, nós não somos robôs e não gostamos de ser chamados de imbecis… temos, enquanto seres humanos, a necessidade fundamental de compreender… cada vez que nos é negado o porquê de algo, nos tornamos mais ignorantes e, sendo mais ignorantes, não podemos desempenhar nosso papel de representar aquele conhecimento em outra forma.

Claro que o diálogo é importante. Claro que o relacionamento com as pessoas torna mais fácil a comunicação e a tomada de decisões. Mas isso não pode, jamais, relegar a escrita a um plano de burrocracia.

Precisamos, na verdade, (re)aprender a escrever. Precisamos também, (re)aprender a selecionar – a escolher o que é relevante e o que não é (em levantamento de requisitos, seleção e adaptação de processos e priorização de nosso trabalho). Isso sim é caminho para a agilidade.

Outro problema das promessas da agilidade é a criação de um ambiente muito cômodo para a associação de quem simplesmente quer cortar caminho ou codificar logo, sem entender bem as coisas. Sei que tem muita gente séria envolvida com Agile – e que não discorda do que digo -, mas é inegável que exista uma grande corrente do desenvolvimento apressado no meio dos defensores de Agile. E isso acaba prejudicando a imagem do movimento.

Por isso tudo vou acompanhar  o Manifesto for Software Craftsmanship…  Vamos ver que tendência ele toma. Ele (o manifesto… não o uso que fazem dele… isso é outra história) é mais comedido que o agile e traz de volta à mesa a preocupação com a comunidade (latu sensu… não apenas a de Software Livre… inclusive de desenvolvedores que atuarão futuramente). Mas apenas enquanto Manifesto. Não concordo com alçar esses manifestos à categoria de processo ou framework.

Anúncios

8 comentários em “O perigo da agilidade

  1. Marlon
    quarta-feira, setembro 8, 2010

    Muito interessante o ponto de vista. Nunca tinha pensado no agile por este lado. Para falar a verdade, nunca tinha feito um paralelo entre processos e o manifesto ágil.

    Percebo que os programadores são os que mais falam bem do agile. Pelo menos é o que percebo de twitter e comunidades afins. Certamente porque acham que com Agile não precisarão mais fazer os tão odiados casos de uso, diagramas de sequência e etc. Talvez imagine que o agile matou os processos…

    Mas aí começa a embolar um monte de assunto 😛

    • Rodrigo
      quarta-feira, setembro 8, 2010

      Esses são os grandes perigos: achar que agile matou os processos e embolar um monte de assunto… 😛

      Eu acho totalmente compatíveis agile e os processos tradicionais. Talvez porque eu enxergue agile mais comportamental do que qualquer coisa. Sempre usei técnicas adotadas no agile durante a execução de atividades de um processo baseado no RUP. E essa é a grande sacada – ao invés de culpar processos, achar em que pontos AS PESSOAS podem modificar e ser modificadas pelas práticas laborais.

  2. Joselito
    sexta-feira, outubro 21, 2011

    Concordo quando você diz que a ineficiência existe, independentemente de processo ou da falta dele, e concordo também quando você diz que a agilidade tem muito mais a ver com comportamento do que processos.
    E sim, um modelo ágil convive, até certo ponto, perfeitamente com outros modelos de gestão.

    Contudo pra quem conhece e trabalha/trabalhou num modelo ágil, a frase “Tem mais a ver com “fazer o mesmo em menos tempo”.” é completamente equivocada e soa como desconhecimento do modelo. Vejo que você tem uma visão do “desenvolvimento apressado” com relação ao ágil. Se isso estiver acontecendo na sua equipe, é porque tem gente equivocada nesse bolo.

    O cerne do ágil é justamente a arte de se fazer menos!
    Nada, nada, nada tem a ver com produzir em menos tempo, tampouco a mesma coisa que nos modelos em cascata.
    O cerne do ágil é fazer o que realmente importa, com qualidade, atendendo o que realmente interessa ao cliente, dando um valor de retorno ao seu investimento.
    Nesse ponto ele já se diferencia totalmente do RUP, o qual priorizava os use cases mais complexos arquiteturalmente, ou seja, priorizava qualidade interna e documentação ao invés de retorno de valor pro stakeholder, pro patrocinador do projeto.
    As práticas de engenharia, como teste, refactoring, TDD, programação em par, algumas não são novidade, apenas são explicitadas pois o ágil prioriza a qualidade do produto.
    Realmente os processos ágeis não são bala de prata pra tudo, mas eles surgiram pra corrigir um desvio histórico,
    que é a relegação da função do programador a uma tarefa secundária, não primordial, quando na verdade é justamente o contrário, a programação é a arte mais nobre nesse processo.
    Surgiram processos burocráticos, com foco no processo por si só e que não entregavam produtos com qualidade (vi isso ocorrer na Hype, na Unitech, na Petrobrás, no Serpro, no Bacen).

    Assim como você, estudei na UFBA e vi uma cultura crescente (me parece que oriunda dos livros de Pressman e outros teóricos) de que o trabalho do programador era algo desmotivante, baixo, querendo fazer um paralelo entre a computação x eng. civil, programador x pedreiro. Ouvi pessoas que não tinham sequer bagagem tecnológica dizerem que não queriam ou não gostavam de programar, tendo cerca de 2 ou 3 anos de faculdade.
    Foi a disseminação do maldito “Analista de Requisitos/Gerente de projeto que não sabe lhufas de tecnologia”.

    No Bacen, houve uma mudança explícita de abordagem e os resultados foram notórios, os clientes realmente ficaram satisfeitos com a mudança na forma de trabalho. No Serpro, trabalhei num modelo que se assemelha muito com o ágil (eu não tenho preocupações com designações ou silogismos, sim com resultados) e os clientes estavam sempre satisfeitos.
    abraço,
    Joselito

    • Rodrigo
      sexta-feira, outubro 21, 2011

      Grande Joselito! Vi que você leu, mas não se despiu de algumas prerrogativas, tentando defender uma visão que eu não ataquei para início de conversa. Vamos lá!

      Primeiramente quando conceituei ágil, estava fazendo uma regressão à propriedade da terminologia e não uma redefinição ou análise do que é estabelecido dentro do movimento ágil. A validade de uma comparação de agilidade não teria, segundo a minha avaliação do termo (veja bem, do termo), em essência nada a ver com fazer menos, pois isso é um desvio da percepção, gerando uma comparação inapropriada. Para exemplificar, seria como dizer que comer um sanduíche é mais ágil que um almoço preparado em casa – o que seria um total equívoco, pois é mais RÁPIDO, e não ÁGIL, pois enquanto este supre apenas um objetivo primário, aquele visa atingir objetivos secundários ou terciários e, por isso, mais trabalhoso e complexo.

      Fazer menos nem sempre é fazer melhor. Como digo em outros posts, não documentar os requisitos para produção é, em muitos cenários, um equívoco extremamente prejudicial a todos os envolvidos. É assim sempre? Claro que não! Mas negar que documentação se trata exclusivamente de qualidade interna é um grande equívoco. Como pode ver em outro post (espero que continue lendo o blog), seria o mesmo que falar que a escrita beneficia apenas a quem escreveu ou ao grupo a quem o escritor o destinou. Se assim o fosse, ruiria toda a concepção de transdisciplinaridade e de avanço transversal do conhecimento científico. A documentação é, da mesma forma, uma maneira de preservar a informação, gerando uma compreensão comunitária sobre aquilo que se produz. Se você tem isso como objetivo secundário e acredita, deve documentar – deve fazer mais! Isso contrariaria o princípio ágil! Claro que não! Veja que ele diz produto funcionando sobre (OVER) documentação extensiva… ou seja, o manifesto sugere um desvio de foco e não simplesmente “faça menos”.

      Aliás, o RUP também não prega uma série de coisas que a gente vê o povo fazer/disseminar. Ele não diz para fazer projetões – ao contrário, diz claramente para dimensionar bem os projetos e que projetos pequenos são mais gerenciáveis e tem desvio menor. Não diz também para adotá-lo na íntegra – ao contrário, alerta a necessidade de adaptação.

      Sobre o surgimento dos processos burocráticos, eu acho um tema extremamente complicado. Uma parte da minha visão é que as pessoas (não os procesos) não possuem maturidade para assumir suas decisões – tem outro post sobre isso (rs) e preferem gastar várias horas discutindo a criação de uma ficção para não “sair da linha”, gerando um “faz de conta” de que fez tudo conforme o processo quando na realidade não o fez. Outra parte compromete seriamente a formação e as decisões de gestão de pessoas: não se treina Analistas de Requisitos adequadamente e não se coloca as pessoas com perfil adequado para fazer a tarefa. O que mais vi foi gente que não queria ou não tinha o menor interesse na área ser jogada lá. Isso impacta em algumas coisas:

      – Estagnação pela falta de interesse em estudar e melhorar
      – Ingerência, pela visão de que qualquer um sabe de requisitos: cliente, gerente… coisa que hoje vejo claramente como principal fator para a construção de documentação de última qualidade (eu mesmo fui forçado, pelas circunstâncias, a construir documentações que definitivamente não tenho o menor orgulho)
      – Baixa qualidade, pelos motivos acima e pela falta de preparo
      – Ineficiência: leva-se muito tempo e escreve-se muito por desorganização e falta de método – sem falar na “validação documental”, em que se entrega uma bíblia para o cliente, que fica 4 meses repousando na mesa e finalmente é aprovada sem que 10% seja de fato lido… e todo mundo acha que tá tudo bem, que seguiram o RUP e documentaram bem. Quer fantasia maior que essa?

      E o agile não resolve o problema da formação. Joga o problema para debaixo do tapete. Mas eu já vi, por exemplo, uma user story de 8 páginas… mais do que eu escreveria em forma de Especificação de Casos de Uso! Tudo bem que eu revisava Casos de Uso e não era incomum cortar metade do conteúdo. Isso só serve para reforçar que a transição tradicional-agile não mudou o cenário, pois o problema residia nas pessoas – seu treinamento, seu esmero, sua vontade e por aí vai.

      Ótimo que tenham mudado e dado certo. Mas a grande questão do post não é atacar essa forma, mas alertar para o fato que as mudanças comportamentais podem surtir o efeito desejado com ou sem mudança de processo. Eu acho que a casuística formada em torno do agile não é determinante para o sucesso – tanto que hoje o foco voltou-se para a cultura, dado insucessos na implantação de agile. Esse alerta que eu quis passar. Se ficou na dúvida, lê de novo o post.

      Um abração!

      • Joselito
        sexta-feira, outubro 21, 2011

        Relendo seu post, tens razão.
        O foco do que foi escrito está na mudança de comportamento mesmo
        sendo possível sucesso em qualquer metodologia.
        abs!

  3. Joselito
    sexta-feira, outubro 21, 2011

    Também não gosto da forma como esse negócio tem sido vendido…
    O foda é que as mesmas pessoas que ficavam encostadas antes fingindo ser analista de requisitos, documentador, whatever, agora se intitulam “desenvolvedores ágeis” (sabe lá o que isso quer dizer pra eles!) e continuam sem produzir nada do mesmo jeito. Passo por isso no Senado no momento.

    • Rodrigo
      sexta-feira, outubro 21, 2011

      Você tá no Senado?! Não para quieto não? Tá parecendo comigo! rs

      • Joselito
        sexta-feira, outubro 21, 2011

        Pois é!
        Agora aposentei dessa vida de concurseiro!
        abs!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado em quarta-feira, setembro 8, 2010 por em Processos e Metodologias.

O Autor

Twitter

Erro: o Twitter não respondeu. Por favor, aguarde alguns minutos e atualize esta página.

Goodreads

Oath of non-allegiance

Oath of non-allegiance

Oath of non-allegiance

%d blogueiros gostam disto: