Distintos (e poucos) leitores deste blog…

Encontramo-nos inseridos em um cenário onde os profissionais de TI são, muito provavelmente, os mais importantes e imprescindíveis na nossa sociedade e na nossa vida de um modo geral.

O dinheiro que entra e sai de sua conta, cada telefonema realizado, a partida dada no carro ou a passagem de um billhete único no metrô… tudo depende de um software rodando, seja ele pequeno, médio ou grande. Por detrás de cada pequena “mágica” que passa desapercebida no nosso dia a dia – lá está ele!

O que eu venho dizer aqui hoje é bastante relacionado com isso – e creio que esteja dentro do escopo deste blog (dado o público alvo, afinal, muito nerd, que é muito nerd, programa nem que seja por hobby).

Com a evolução da ciência e tecnologia ao longa da história, foram surgindo os grandes modelos de produção… do “Fordismo” e “Taylorismo” ao “Toyotismo” (que futuramente deu origem ao “Lean”). O mesmo é válido para o desenvolvimento de software.

A princípio, devido à própria origem dos desenvolvedores primordiais (em sua maior parte advindos de engenharias), a idéia era regrar e estruturar o máximo possível o processo de desenvolvimento – com fases bem definidas e sequenciais. Conceitos claramente aplicáveis e ideais para a construção de uma ponte, por exemplo – primeiro se desenha, se planeja, se calcula à exaustão… e só então se começa a realmente construir algo.

Tendo esta visão, surgiu aquele que foi o primeiro grande modelo dominante (e ainda perdura até os nossos dias em grande parte do mercado): o modelo Cascata (Waterfall).

Este modelo segue o mesmo princípio definido anteriormente para a construção de uma ponte, e é consideravelmente intuitivo e natural de se pensar. De fato, parece excelente o foco que este propicia em planejamento, cálculo, e na capacidade de mensurar tudo a priori.

Só que neste caso temos um grande problema. Ao contrário de um projeto para uma ponte, que por mais que demore anos para ficar pronta, dificilmente mudará – visto que a física não muda, a matemática (especialmente esta) não muda. Um software é outra história.

[Por mais que o universo acabe um dia... 1 + 1 continuará resultando em 2 (em um cálculo não vetorial)]

Um software reflete uma necessidade bem mais pessoal e subjetiva de um cliente (seja este uma pessoa ou empresa), e está sujeito a mudanças de escopo devido ao mercado e à evolução constante da tecnologia. De que adianta desenvolver um mega portal por 1 ano e, ao término, perceber -se que a internet mudou tanto neste meio tempo que as tecnologias utilizadas estão obsoletas e não atendem aos usuários?

De que adianta produzir pilhas e pilhas de documentação fadada a tornar-se rapidamente desatualizada com cada nova idéia de seu cliente? De que adianta sacrificar as necessidades verdadeiras de um cliente, obrigando-o, por força contratual, a não ter novas idéias até que o software solicitado (que já não lhe serve mais) seja entregue?

É claro que não podemos ser radicais. Documentação, contratos, processos, são coisas excelentes – mas devem ser seguidos apenas até o ponto em que passam a atrapalhar mais que ajudar.

Com essa visão, grandes figuras influentes do mundo do desenvolvimento elaboraram o “Manifesto Ágil”.

Traduzindo:
Indivíduos > Processos/Metodologias/Ferramentas
Software funcionando > Documentação completa
Colaborar > Contratar
Abraçar as mudanças (evoluir) > Se prender ao plano inicial

As grandes metodologias ágeis presentes no mercado hoje são originadas também de uma metodologia de produção de fábrica – o Lean.

O princípio básico das metodologias surgidas do Lean, de um modo geral, gira em torno de desenvolver (ou produzir) o menor pedaço de software (ou lote, ou produto) possível que tenha algum valor para o cliente. Nada de grandes entregas a cada 2, 3 meses (ou grandes estoques e produção em massa exacerbada).

Scrum

Uma das alternativas ágeis mais aceitas atualmente é o Scrum. Scrum é um termo que vem de “scrummage” – uma expressão vinda do Rugby – que diz respeito à reunião rápida dos jogadores para decidir o que vai ser feito para re-colocar a bola em jogo e qual será a estratégia para avançar o máximo possível na próxima jogada.

O Scrum defende bem claramente os princípios do manifesto ágil – priorizando entregas pequenas e constantes, e a COLABORAÇÃO entre cliente e desenvolvedores.

A cada sprint (jornada de desenvolvimento do Scrum – costuma variar de 1 a 4 semanas) a equipe de Scrum entrega pequenos “pedaços” de software funcionando que possuem valor claro e bem definido para o cliente.

A cada dia, a equipe se reúne por não mais que 15 minutos, para discutir o que foi feito por cada um no dia anterior, o que será feito hoje, e se há algo atrapalhando o time de alguma forma.

Quaisquer fatores que estejam prejudicando o andamento da equipe devem ser resolvidos o quanto antes pelo Scrum Master – mantendo o restante da equipe com foco total no desenvolvimento.

Como resumo disso tudo temos:
- Os métodos ágeis são muito mais “humanos” do que os métodos convencionais;
- Os métodos ágeis focam mais nas pessoas e menos nos processos; (o que não é necessariamente bom, nem ruim)
- Os métodos tradicionais focam mais nos processos e menos nas pessoas; (o que não é necessariamente bom, nem ruim)

Como opinião pessoal, fica:
- Em um modelo cascata, a própria metodologia defende que a necessidade de capacitação individual decresce á medida em que se “desce” um nível – o que não é de todo verdade;
- Não há processo nesse mundo que gere qualidade sem pessoas suficientemente boas;
- Não há processo nesse mundo que não gere qualidade com pessoas suficientemente boas;
- Processos rígidos tendem a nivelar melhor as equipes, ajudando aqueles abaixo da média – e atrapalhando aqueles acima;
- Desenvolvimento de software é uma arte, não uma ciência exata e “morta” (como as engenharias) – portanto requer esforço intelectual e criativo em todas as fases (não só no design e requisitos – como o modelo cascata defende);
- Métodos ágeis dependem mais da honestidade e colaboração entre as pessoas – o que, de um modo geral, está longe de ser a realidade quando se trata de seres humanos;
- Métodos ágeis não são para todos, pois necessitam de COOPERAÇÃO do cliente. Se o seu cliente não tem esse perfil, o mais correto é partir para um contrato super restritivo, cascata, e esfregar na cara dele a cada nova idéia que ele tiver .

 Imprimir esse artigo!
Leia também:

• Webcomics Downloader
• Windows on Rails?
• ‘Cause uncle Ben was so f*cking right
• Windows CMD – Going Beyond