Página Inicial > Uncategorized > Franchising de Metodologia – Poderemos Ser Escravos de Algum?

Franchising de Metodologia – Poderemos Ser Escravos de Algum?

Acompanhando blogs e listas de discussão sobre desenvolvimento de software, percebo que muitos profissionais parecem ter a expectativa de que os métodos e práticas propostos por alguma metodologia devam ser seguidos à risca. Parece até que, para eles, metodologia seja um produto fechado do qual são quase escravos. Neste post  procuro explicar porque não deveríamos ter esse tipo de expectativa.

Costumo comentar que a indústria de software, assim como as artes, tem a peculiaridade de lidar apenas com conceitos. Nossos produtos são sempre abstratos. O resultado de nosso produto pode ser “visualizado” ou “percebido” de uma forma mais concreta apenas durante sua utilização. Nem o mais experiente participante da equipe consegue ter essa percepção examinando o código, que seria nosso produto mais concreto. Nosso cliente então, nem pensar!

Diferente da maioria dos produtos disponíveis no mercado, o software não tem uma forma ou qualquer outra característica física que possa diferencia-lo de outro software. Diferente de outras indústrias, cada produto que entregamos é diferente de qualquer outro produto que já tenhamos entregue. Se pudermos utilizar em um produto um componente de outro produto, também não precisamos “fabricar” de novo esse componente. Também não temos o equivalente ao típico setor de engenharia de uma fábrica, que prepara ou modifica os equipamentos e ferramentas da linha de produção para que um novo modelo possa ser fabricado. Também não temos um setor de “design” que ao longo do tempo proponha modificações para que o setor de engenharia implemente.

Não somos uma fábrica, não temos uma linha de produção que produza repetidamente o mesmo item, mas somos tudo isso junto e ao mesmo tempo, produzindo cada item uma única vez. A cada produto ou componente a ser construído, devemos usar as práticas equivalentes às da arquitetura (para descobrir e definir uma estrutura para o produto e seus componentes), da engenharia (para identificar e utilizar os processos e ferramentas mais adequados para cada componente), e também construir o produto. As práticas são utilizadas de forma iterativa, num processo que é ao mesmo tempo aprendizado sobre o produto, aprendizado sobre a adequação dos métodos de produção ao produto, e aprendizado sobre a produção propriamente dita. Tanto o processo como as práticas podem e devem ser ajustados pela equipe.

Nas equipes em que trabalhei, já percebíamos há muito tempo que o processo para elaborar o produto vai surgindo ou sendo ajustado à medida que a equipe entende o produto a ser desenvolvido. Mesmo que o processo tenha muitas características semelhantes para diversos produtos, sempre haverá algumas adaptações para cada projeto. Nem sempre percebíamos tudo, claro. Já nos anos 70, depois de implantado o sistema, costumávamos nos perguntar o que faríamos diferente se tivéssemos que fazer tudo de novo: a lista costumava ter diversos itens, alguns com diferenças significativas.

Recordo também um fato ocorrido no final do anos 80. A empresa em que eu trabalhava tinha algumas equipes de desenvolvimento de software, cada uma responsável pelo atendimento de uma área especifica do negócio (Vendas, RH, etc.), e eu coordenava uma pequeno grupo de suporte a essas equipes. Nosso grupo funcionava como um “Escritório de Projetos” atual, mas com pouca ênfase no controle de projetos pois nosso foco era auxiliar e disseminar o uso de métodos e práticas de trabalho bem como dar suporte para as ferramentas utilizadas pelas equipes.

Utilizávamos uma metodologia desenvolvida internamente, que já necessitava de atualização. Uma alternativa considerada foi utilizarmos uma metodologia “pronta”, e para iniciar a avaliação de uma delas foi agendada uma reunião no escritório da consultoria responsável pela mesma. Meu gerente e eu passamos uma manhã assistindo demonstrações e explicações sobre as vantagens de se utilizar a metodologia. Tudo estava previsto, e havia uma riqueza de formulários, um para cada situação específica, como pudemos constatar quando nos foi mostrado, creio que com um certo orgulho e satisfação, os volumes encadernados da metodologia (documentos eletrônicos quase não eram utilizados). Ocupavam quase um metro de estante!

Enquanto voltávamos ao nosso escritório, um trajeto de uns quinze minutos a pé, concluímos que essa alternativa não era válida, iríamos gastar uma fortuna para adquirir um conjunto enorme de procedimentos detalhados que, em sua maioria não se aplicariam ao nosso ambiente. Nossa opção foi refazer nossa metodologia com o envolvimento das equipes, os principais interessados e os melhores conhecedores de nosso ambiente.

Desde essa época assumi que metodologia não é um produto, ou, melhor dizendo, metodologia como produto não deveria ser viável por falta de mercado. Entendo que as mudanças em um ambiente de desenvolvimento de software não podem ser conduzidas como uma revolução utilizando métodos elaborados a partir das práticas de outras equipes, de outros ambientes, que lidam com outros tipos de produtos, com diferentes necessidades de formalização, enfim, de contextos diferentes, eventualmente muito diferentes.

Entendo que métodos e práticas deveriam fazer parte do arsenal de ferramentas de cada profissional de desenvolvimento e deveriam ser utilizados e ajustados pela equipe conforme as necessidades do momento, tendo em vista os resultados esperados para o projeto.

Uma referência relevante é o Manifesto Ágil (http://manifestoagil.com.br/), que constitui a orientação básica de todo o movimento ágil, do qual transcrevo apenas o primeiro dos quatro valores e o último dos doze princípios. Creio que eles direcionam claramente para a responsabilidade da equipe pelos processos que são utilizados:

  1. valorizamos Indivíduos e interação entre eles mais que processos e ferramentas
  • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Espero que não seja necessário um adendo ao Manifesto, já sugerido por Chris Goldsbury:

valorizamos Indivíduos e interação entre eles mais que processos e ferramentas, inclusive os processos e ferramentas ágeis.

O atual processo de “flexibilização” do Scrum em andamento na Scrum.org também oferece uma oportunidade de se pensar sobre o assunto. No artigo Extensões do Scrum: dois meses depois, creio que o comentário de Joakim Sundén representa a parte da comunidade que se sente responsável pelo uso do Scrum, inclusive para efetuar as adaptações que julgar necessárias para o seu contexto:

A minha primeira reação foi positiva, mas depois me perguntei se isso não não seria muito pouco e tarde demais. Qual é a intenção de Jeff [Sutherland] e Ken [Schwaber]? No website é dito: “Se for aceita, a sua extensão será incorporada na Biblioteca de Extensões do Scrum, seguindo critérios exclusivos de Jeff e Ken.” Por que a comunidade sentiria a necessidade da aprovação de Jeff e Ken para uma extensão do Scrum?

De minha parte concordo plenamente com Joakim. Por que uma equipe qualquer necessitaria da aprovação da Scrum.org para o processo que ela vai utilizar? Por que alguma equipe deveria utilizar processos aprovados pela Scrum.org? Não é a equipe que deve ser responsável pelos processos que utiliza? Esses processos não devem ser melhorados continuamente pela própria equipe?

Outro aspecto preocupante é que a Scrum.org pode transformar o Scrum, que começou simples, em um método mais complexo e detalhista que o necessário, talvez tão complexo e detalhista quanto o RUP. Embora o RUP tenha sido muito criticado pelo seu “gigantismo”, a customização e inclusão de métodos para adequação ao projeto sempre foi incentivada, e nunca houve a pretensão de que deveriam ser aprovadas pela Rational ou IBM.

Ainda sobre o Manifesto Ágil, em um artigo na SD Times J.D.Hildebrand comenta sobre as análises efetuadas por alguns de seus 17 signatários originais, para a comemoração de 10 anos do Manifesto. Um deles, Andy Hunt, comenta a respeito de uma equipe ágil visitada por ele recentemente: “…But these weren’t productive developers freed from mindless process dogma. They were Agile slaves. …”. Veja o artigo em Agile Slaves.

Conclusão

Creio que devemos estar atentos para que as equipes que praticam Desenvolvimento de Software assumam efetivamente a responsabilidade pelo processo que utilizam. Devem procurar se manterem atualizadas sobre novos métodos e técnicas e se sentirem à vontade para utiliza-los e adapta-los conforme as necessidades do projeto. Entidades ou consultores externos podem ser úteis e necessários para auxiliar a utilização de alguns métodos e técnicas, mas não deveriam ser necessários como “aprovadores” do processo.

Caso os desenvolvedores não assumam essa responsabilidade, existirá o risco de que as metodologias sejam transformadas em PRODUTOS, e talvez tenhamos até que pagar uma taxa para utilizar uma determinada “franquia”. Poderemos também, quem sabe, estar sujeitos a uma avaliação periódica do franqueador para garantir que metodologia dele esteja sendo usada corretamente. Certamente estou exagerando na figura, mas, muito antes de se chegar a esse ponto, já poderemos ter nos tornado escravos da metodologia, seja ágil ou não.

Metodologia não é Franchising.

Não devemos ser escravos de uma metodologia, qualquer que seja ela.

E você, o que acha? Compartilhe sua opinião, ela é sempre benvinda.

Como curiosidade, o artigo “Abaixo Chapeuzinho” de João Ubaldo Ribeiro no O Globo desse domingo (11/12/2011), trata de forma humorística a tendência de alguns segmentos da sociedade desejarem definir o que é certo ou errado sobre os tópicos mais diversos. De certa forma, o assunto é o mesmo.

About these ads
CategoriasUncategorized
  1. Vladimir Ferraz de Abreu
    13/12/2011 às 14:21

    Grande Arísio, quanto tempo !
    Concordo com você em gênero, número e grau. Em tudo na vida, sempre existe algo que é “padronizável” e um outro tanto de aspectos que variam de acordo com o contexto. Geralmente, a primeira parte é composta daquilo que apreendemos uma (ou algumas) vez(es) e depois passamos a executar quase mecanicamente (grandes fases, processos e conceitos de alto nível, agrupamentos de informações afins etc.). A segunda parte é aquela que depende fundamentalmente de análise, de projeto, que transforma a maneira como utilizamos a primeira parte para criarmos o resultado único de iniciativas que podemos chamar de projetos.
    Na minha visão, uma metodologia deve estabelecer bem as fronteiras entre a primeira e a segunda partes, definir regras mais fortes para a primeira parte e proporcionar à segunda parte um grau de liberdade que permita que a criatividade dos arquitetos, engenheiros e construtores busque a melhor forma de materializar os requisitos imaginados e desejados pelos clientes.
    Desta forma, uma metodologia realmente útil é aquela que orienta e direciona, mais do que franqueia, obriga e impõe. Em outras palavras, como diz aquele velho chavão dos metodólogos, aquele que é “mais uma trilha do que um trilho”.
    Forte abraço,
    Vladimir (lembranças dos bons tempos da SQA).

    • 15/12/2011 às 12:29

      Vladimir Estamos de acordo. Eu ainda acrescentaria que a divisão entre a primeira e a segunda partes não deve ser padronizada, pois depende de muitas variáveis de cada contexto. Bons tempos aqueles, mas esses também são bons! Grande abraço, Arisio

      Em terça-feira, 13 de dezembro de 2011 14:21:56,

  2. 14/12/2011 às 11:44

    Hoje vemos muitos artigos, eventos e serviços sendo prestados para auxiliar na implantação da metodologia, mas infelizmente isto é voltado apenas para os processos / produto e suas ferramentas, deixando o Indivíduo e interação no cantinho da sala ou +- maqueado.

    Não tenho certeza se o comentário tem muito haver com o seu artigo. Parabéns pela publicação.

    • 16/12/2011 às 15:45

      Oi Alex.
      Tem a ver, sim.
      A premissa do post é que muitos de nos, desenvolvedores, temos a expectativa de que processos métodos e ferramentas sejam utilizados de forma homogênea, de acordo com critérios externos à equipe . Quando agimos com essa premissa, penso que haverá uma tendência de que as pessoas sejam consideradas como simples recursos que irão utilizar esses métodos, processos e ferramentas.
      Obrigado pela participação
      Abraços

  3. 16/12/2011 às 10:15

    Verdade que muitas pessoas no Scrum andam mais preocupadas em seguir a risca o que prega o Scrum Guide do que necessariamente desenvolver. Vejo nisso um desfoque do princípio a que se foi proposto. .Estamos trabalhando para entregar valor com qualidade mais cedo e não para fazer esse ou aquele método perfeitamente.

    “Indivíduos e interação entre eles mais que processos e ferramentas”

    Se focarmos no processo em si ou nos preocuparmos mais metodologia do que com o software não estamos sendo ágeis.

  4. 16/12/2011 às 15:40

    Correto, Miguel.
    Se nos dedicarmos realmente ao produto, em pouco tempo conseguiremos utilizar a dose certa de processo: nem pouco que afete a qualidade, e nem em excesso que apenas aumenta os custos.
    Um grande abraço

  1. No trackbacks yet.

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

%d blogueiros gostam disto: