Desenvolvimento ágil funciona?

Metodologias ágeis como scrum e extreme programming realmente funcionam?

No mundo do desenvolvimento de software, metodologias ágeis como scrum e extreme programming são a onda do momento. Mas será que elas funcionam mesmo?

Para tentar responder a pergunta, conversamos com Fabio Akita, um especialista no tema. Gerente de produtos da Locaweb e autor do blog Akita on Rails, ele trabalhou como desenvolvedor, integrador e gerente em diversos projetos de software.

Confira a seguir algumas das ideias que ele defende e tenta colocar em prática no seu dia-a-dia como gestor de projetos:

De onde surgiu a ideia de desenvolvimento ágil?
A crise do software vem desde a década de 70, não é recente. Desde os projetos militares da década de 60 todo mundo já sofria com os mesmo problemas. Mas a gente sempre vem fazendo do mesmo jeito desde então. Nos anos 90 diversos pensadores da área de engenharia de software se juntaram para tentar encontrar a metodologia correta para lidar com software e não chegaram a uma conclusão. Mas chegaram a um conjunto de valores importantes, que deram origem ao que chamamos de manifesto ágil.

Scrum e extreme programming são algumas metodologias ágeis que estão em voga no momento. Elas refletem o espírito deste manifesto ágil?
Com a nossa cultura de fast food, de querer achar uma receita mágica para tudo, o mundo ágil ganhou força dentro de um certo nicho de desenvolvimento. A gente ouve falar muito hoje de scrum, de extreme programming, mas se usam essas ferramentas apenas como ferramentas. Isso não funciona. Tem gente que até discute se o pico recente de scrum não foi mais negativo que positivo, porque muita gente está aplicando e não atinge os resultados, simplesmente porque usa o raciocínio antigo com ferramentas novas. Os valores não foram entendidos. Scrum é um template. Ele te diz que você tem esse papel chamado product owner, você tem este tempo chamado sprint, tem essa atividade chamada scrum diário, e essas coisas chamadas retrospectiva e backlog. Ele te dá nomes e elementos que você aplica. Mas não é só aplicar e ponto. Isso é só o começo. A grande mensagem da forma ágil de pensar é que o procedimento não é importante. É irrelevante se eu chamo o meu tempo de trabalho de sprint ou o dono do projeto de product owner. É absolutamente irrelevante, se eu não entendi os valores que são entregar valor ao cliente, criar uma organização de aprendizado, acreditar nas pessoas e dar suporte a elas. Esses princípios é que são importantes, mas não são explícitos. Em vez disso eu tenho papéis, cargos e atividades. Não se explicam os porquês e não entendendo os porquês você vai fazer exatamente a mesma coisa, mas em vez de chamar o sujeito de gerente de projeto você vai chamá-lo de product owner. Mas nada mudou.

Como funciona hoje o desenvolvimento de software e quais são os problemas desse modelo?
Existe aquela figura de um gerente que tem embaixo dele uma série de recursos – como pessoas e tecnologias - um escopo, um orçamento, prazos e parte-se do princípio que, havendo um bom gerente que coordene e dê ordens de cima para baixo, o projeto vai correr da forma como classicamente se espera e o projeto vai ser entregue com sucesso. Passando por vários projetos e observando tantos outros, é bastante claro para mim que a maioria não acaba exatamente com sucesso. Alguns são entregues pela metade, outros saem mais caro outros acabam atrasando. Se todos acabam de forma errada, qual é a vantagem de partir da premissa de que se eu fizer tudo como foi planejado passo a passo vai dar certo no final?

Porque as ferramentas tradicionais de gestão e controle não funcionam para software?
Instrumentos de controle como forecasting, cronogramas e business plan são ilusórios. Eles dão a ilusão de que eu tenho um controle que realmente não tenho. Software não é colocar um tijolo em cima do outro. É impossível ter dois programadores que vão fazer exatamente a mesma coisa, ao mesmo tempo, mesmo partindo dos mesmos princípios. Produzir software é uma atividade criativa. Você não pode pedir a um compositor: eu quero exatamente esta música neste dia. Ele vai trazer alguma coisa, mas a gente não sabe exatamente o que. Eu tenho uma noção de que quero uma música mais para rock do que para blues, mas exatamente com que notas eu não tenho como saber. Software segue um pouco este caminho. Por isso é difícil gerir software usando premissas que não foram feitas para isso.

O que pode funcionar então?
Em primeiro lugar, a empresa assumir que não sabe o que quer. Eu sei que tenho alguns pontos problemáticos no meu negócio que eu quero corrigir, um certo orçamento e um certo prazo a partir do qual não é viável mais esperar. Diante disso, vamos trazer o desenvolvedor e o cliente que tem o problema, que sabe onde o calo dele aperta, e fazer ambos trabalharem juntos. Em vez de gastar os próximos seis meses descrevendo o que se quer, vamos definir um prazo curto. Eu não consigo prever o futuro em longo prazo, mas talvez eu consiga controlar o curto prazo. Duas, três semas, E entender dentre os problemas que o cliente tem quais são os prioritários. Porque se eu atacar esse problema primeiro, vou ter muito valor. Começamos a desenvolver e no fim desse período curto, o cliente vai ter alguma coisa, mesmo que seja um pedaço de software, mas que funciona, que não está completo, mas que o cliente pode testar, usar e dizer se está no caminho que ele deseja, de tal forma que se não estiver, eu não perdi seis meses. Isso é minimizar o risco. Ninguém sabe qual é o jeito certo, mas dá para discutir o que não funciona desde o começo. É como fazer uma escultura. Primeira se faz cortes grosseiros e depois é que vem o acabamento. O código é dinâmico, não é estável e tudo que é entregue continua sendo mexido.

Qual é o papel do gerente em uma equipe que trabalha desta forma?
O gerente não controla se o João trabalha duas horas nesta tarefa ou Maria vai passar três horas naquela. Ele não vai fazer cronogramas. Vai controlar as expectativas e a comunicação. Vai garantir que o cliente esteja disponível para tirar as dúvidas do desenvolvedor, vai garantir que o desenvolvedor tenha os subsídios para desenvolver. Ele tem que retirar de si poderes e delegar a quem realmente tem capacidade de tomar decisão. Afinal, é o desenvolvedor que vai colocar a mão no código. A tomada de decisão vem de baixo. Scrum e extreme progaming prevêem tudo isso, mas se eu jogar de cima para baixo não funciona, porque até ontem os desenvolvedores recebiam ordens. É um processo que começa com a quebra de algumas premissas, com algumas discussões, que devem ser aplicadas uma de cada vez até que a equipe entenda a dinâmica e sinta a necessidade de puxar outras práticas.

Como funciona a aplicação prática desses valores no dia-a-dia?
Em empresas grandes, é como mover um elefante, porque elas estão em equilíbrio. É como um copo de água. Sozinho, ele não entra ebulição. É preciso entropia. Os gerentes do meio não têm nenhuma motivação para melhorar algo porque a sua carreira não depende disso, e ele não é o dono do dinheiro. Quando surge algo novo ele não vai ser o primeiro a tentar. Mesmo que o que ele faça está errado, ele acredita que não vai ser condenado por ter seguido a maioria. Em empresas menores onde tem o dono e mais cinco pessoas, o dinheiro que sai do bolso do dono é valioso. Ele não vai aplicar burocracia porque é bonito ter papel na mesa. Nos Estados Unidos, tem um mercado enorme de startups que são os primeiros a adotar essas novas tecnologias e novos jeitos de trabalhar. Elas dão o start para que chegue às grandes. Aqui tem muitas empresas que desenvolvem para outras empresas, portanto têm pouca liberdade. Lá, elas desenvolvem produtos próprios e é aí que está a diferença.

Fonte: Info Abril