Em matéria de desenvolvimento de software, muito se tem dito sobre processos baseados em modelos explicitamente definidos como é o caso do Waterfall e processos baseados em modelos empíricos, mais próximos de metodologias ágeis tais como Scrum, FDD, Kanban, entre outros. Quais as vantagens de um tipo de paradigma relativamente ao outro, em que circunstâncias se devem usar um e não o outro, um sem número de discussões perpetuadas por adeptos fervorosos de ambos os lados esgrimindo razões sobre os benefícios de um sobre o outro.
Um paradigma representa um conjunto de valores, pressuposições, credos que definem a forma como se perceciona a realidade ou se encara determinada situação. Como representa o que é real e/ou verdadeiro, mudar o paradigma de alguém pode ser bastante difícil.
Eis algumas das crenças elementares em que assentam o Waterfall e o Agile.
Será que estas crenças são princípios universais ou apenas um conjunto de regras e práticas que devem ser seguidos?
Profissionais de desenvolvimento de software tendem a ser pragmáticos no sentido em que favorecem aquilo que funciona na prática sobre o que é representado como teoricamente “correto”. Isto não significa que a teoria seja algo mau, mas antes que toda essa teoria deva ser alicerçada em casos reais e que seja aplicável ao trabalho que se está a tentar executar.
Não basta pegar numa série de princípios e imitar práticas para se obterem os resultados desejados. O mesmo princípio pode ser materializado com execuções diferentes, no entanto essas práticas têm que ser adaptadas ao contexto, ou situação, em que estão a ser empregues.
A simples aplicação de um determinado princípio pode não obter os resultados desejados a não ser que estejamos a falar de algo que tenha sido já demonstrado e validado. Da mesma forma, a reprodução de práticas previamente usadas irá funcionar se as condições em que estamos a empregar essa prática forem similares.
Não existe uma receita que funcione de forma eficaz em todas as situações e a solução passa por ir adaptando a receita às circunstâncias. Essa adaptação deve seguir os princípios e regras que melhor se adequem à realidade.
Independentemente de qual a preferência de paradigma, se Agile ou Waterfall, nenhum destes paradigmas por si só é suficiente e precisam de ser suportados por outros mecanismos para poderem ser efetivos.
O Lean apresenta-nos uma série de princípios e práticas que podem ser imediatamente implementados em projetos de desenvolvimento de software. e pode ser aplicado quer ao nível das equipas de desenvolvimento quer ao nível organizacional de uma empresa.
O objetivo principal é otimizar o todo trazendo mais velocidade de produção mas que seja sustentável. A ideia é obter o menor tempo possível desde a geração da ideia até à entrega do produto ao cliente. Para isso o foco principal é o tempo e não quão bem estão os recursos a serem utilizados. Não significa isto que não se deva fazer uma utilização eficiente dos recursos disponíveis.
A abordagem sugerida está em linha com o modelo científico, em que se propõe uma hipótese e correm-se experiências para a validar ou invalidar.
Vejamos as crenças elementares em que assenta o Lean.
O principal foco do Lean é no processo usado pela equipa e esse processo deve ser o melhor possível que permita à equipa fazer o seu trabalho de forma eficiente.
O processo deixa de ser algo imposto e passa a ser algo que é propriedade coletiva da equipa (não só de desenvolvimento mas também de gestão). O propósito é que a equipa seja mais produtiva e o trabalho seja feito de forma mais agradável.
O Lean diz-nos para nos concentrarmos em melhorar o sistema de produção de software de forma holística, com particular enfoque no processo que suporta a equipa. É de extrema importância envolver a equipa na criação e adaptação desses processos, uma vez que são as pessoas que fazem o trabalho quem melhor conhece o sistema e sabe como o melhorar.
Imaginemos o sistema como uma linha de montagem onde a produção se desenrola. Qualquer evento ou circunstância que atrase a produção na linha traduz-se em desperdício e deve ser removido. Atrasos, erros, mal-entendidos, entre outros, são tipos de desperdício. O processo é melhorado procedendo à remoção destes impedimentos.
Juntem um grupo de pessoas da vossa organização e coloquem as seguintes questões:
Partilhar:
