As origens do Agile

Mesmo que sua equipe de desenvolvimento ainda não tenha migrado para métodos ágeis como Scrum ou Extreme Programming, é muito provável que pelo menos estejam considerando isso. "Agile" realmente aborda alguns dos maiores problemas que afligem equipes de software há décadas. No entanto, muitos gerentes de produto, designers e também pessoas de garantia de qualidade ficam inicialmente confusos com Agile, porque ainda não estão realmente familiarizados com seus papéis nos métodos ágeis. Esses métodos definitivamente exigem esses papéis, mas atribuo a confusão às origens dos métodos ágeis. Para esclarecer os problemas que "Agile" pretende resolver e descobrir quais desafios ainda persistem, é útil explicar as origens do Agile.

Muitas pessoas ficam surpresas ao descobrir há quanto tempo o Scrum – o método ágil mais conhecido – já existe. Ele surgiu em 1986 no Japão. (Um exemplo de quanto tempo pode levar até uma nova ideia finalmente conseguir se estabelecer.)

As origens do Agile estão no software personalizado

O mais importante, porém, é que esses métodos vêm do mundo do software personalizado (Custom Software).

Desenvolver software personalizado, ou seja, software para um propósito específico e para um cliente específico, foi por muito tempo uma forma extremamente difícil de desenvolvimento de software. Em parte, isso se deve ao fato de que os clientes notoriamente não sabem exatamente o que querem. No entanto, eles têm uma necessidade de algo e então assinam um contrato com uma empresa de software personalizado ou se reúnem com seu pessoal interno de TI, que então deve trabalhar nisso. Mas quando algo é entregue, os clientes basicamente dizem que não era o que queriam e tudo recomeça do zero, com a frustração naturalmente aumentando. A necessidade básica, porém, continua existindo e isso garantiu emprego para inúmeros desenvolvedores de software, empresas e prestadores de serviços.

Além disso, no desenvolvimento de software personalizado, muitas vezes se levou desvantagem quando se tratava de contratar pessoas e garantir os melhores talentos de software. Isso provavelmente se deve em parte ao fato de que os profissionais preferem trabalhar em empresas que desenvolvem software para milhares ou até milhões de clientes. Uma razão para isso é que os profissionais recebem salários mais altos nas empresas onde a equipe de produto deve desenvolver produtos de software que muitas pessoas querem, porque de outra forma não ganham dinheiro. Essas empresas sabem que precisam contratar boas pessoas para criar produtos de sucesso e, consequentemente, a remuneração também reflete isso. No entanto, apenas uma pequena porcentagem de desenvolvedores de software trabalha em software padrão; a maioria desenvolve software personalizado.

A vantagem do Agile?

Como o cliente, no caso de software personalizado, presume saber o que quer, raramente se encontra o papel do gerente de produto. Da mesma forma, quase nunca se encontram designers de User Experience. As razões para isso são bastante complexas e incluem um certo grau de desconhecimento (poucos no mundo do software personalizado sabem o que os designers de UX fazem e para que são necessários) e sensibilidade aos custos (reduzir custos deixando os desenvolvedores fazerem o design). Para ser justo, os poucos designers que existem em nossa indústria são imediatamente contratados pelas empresas de produtos que entenderam a importância dos designers. Portanto, quase não sobram designers para equipes que desenvolvem software personalizado, quando os líderes finalmente percebem que precisam deles. Da mesma forma, quase não existe garantia de qualidade como disciplina separada no software personalizado, e espera-se que os desenvolvedores também assumam os testes.

Outro ponto importante para entender o mundo do software personalizado é que a maioria dos projetos de software personalizado é relativamente pequena e destina-se a apoiar as atividades internas de uma empresa – por exemplo, recursos humanos, faturamento, produção etc. Ou seja, todas as áreas onde há apenas um número limitado de usuários e coisas como escalabilidade e desempenho normalmente não são tão importantes.

O processo em cascata

Antigamente, no software personalizado, era necessário o processo em cascata porque os diversos stakeholders precisavam de uma forma de acompanhar o progresso durante o longo processo de desenvolvimento das aplicações desejadas. Na verdade, o método cascata também teve sua origem aqui.

No software padrão, que é comprado por seu desempenho e benefícios, alguns papéis foram introduzidos. O gerente de produto deve coletar e representar as necessidades de todos os clientes. Os designers devem criar experiências de usuário utilizáveis e desejáveis, e os testadores de garantia de qualidade devem verificar se o software funciona como prometido ao cliente na publicidade.

A solução dos problemas do cascata veio com os métodos ágeis

No software personalizado, no entanto, os mesmos problemas continuavam surgindo quando se tratava de criar algo que satisfizesse os clientes. Especialmente para essas equipes, os métodos ágeis representam uma forte melhoria. A comunicação entre clientes e desenvolvedores melhora. O risco é consideravelmente reduzido através de iterações menores e mais frequentes. Os clientes podem descobrir muito mais rapidamente se gostam de algo do que se continuassem esperando pelo fim de um longo processo. Além disso, os métodos ágeis ajudam a introduzir conceitos modernos de teste de software e poupam às equipes horas de criação de documentos que quase ninguém lê e que rapidamente ficam desatualizados.

Agile para software personalizado e padrão

Fundamentalmente, essas vantagens também se aplicam ao software padrão, mas sempre enfatizo que algumas coisas precisam ser adaptadas. Outra área onde houve dificuldades é a arquitetura de software ou design de software.

Os métodos ágeis encorajam os desenvolvedores a não se apegarem demais à sua forma de implementação, pois tudo deve poder ser rapidamente e facilmente revisado ou reorganizado. Embora isso frequentemente funcione bem no software personalizado, essa abordagem é, por exemplo, ingênua demais para grandes serviços de internet que têm centenas, milhares ou milhões de usuários.

Portanto, não é surpresa que muitas equipes de software padrão tenham tido problemas com os métodos ágeis, já que as origens dos métodos ágeis estão no software personalizado. Os muitos livros, artigos e cursos que não mencionam gerentes de produto nem designers de User Experience (designers de interação e designers visuais) não são destinados ao desenvolvimento de software padrão.

Equipes que querem migrar para métodos ágeis no desenvolvimento de software devem, portanto, verificar antecipadamente se a empresa que vai ajudar sua organização também entende o que é necessário para software padrão. Nem sempre é o caso, mas muitas vezes é.