Waterfall, Agile… Lean!? Uma avaliação de paradigmas – EDIT. – Disruptive Digital Education

Waterfall, Agile… Lean!? Uma avaliação de paradigmas

Artigo

Rui Vinhas, R&D Team Leader na Coriant, Inc. e tutor do workshop Lean Agile Development na EDIT. Lisboa apresenta, neste artigo, uma avaliação de paradigmas de gestão de desenvolvimento de software: Waterfall, Agile e Lean.

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.

Waterfall

  • O cliente sabe exatamente aquilo que pretende logo no início do projeto.
  • É possível saber-se tudo o que é necessário para implementar o produto logo no início do projeto.
  • Tipicamente não é necessário grande interação com o cliente até se atingir o final do projeto.
  • As diversas partes interessadas podem inferir qual o estado do projeto através da declaração formal das diferentes milestones (apoiadas em documentação como evidência).
  • Grupos diferentes podem fazer análise, desenho, código e testes no produto de forma independente sem que haja perda de informação durante as transições entre grupos.
  • Transições entre diferentes grupos podem ser eficientes se for registado aquilo que se fez em cada uma das fases.
  • É possível testar apenas no final do projeto e atingir o nível de qualidade pretendido.
  • A camada de gestão pode exigir e esperar que determinada quantidade de trabalho seja executado num determinado período de tempo.
  • A participação em diferentes projetos ajuda a atingir uma produtividade de 100%, uma vez que toda a gente está constantemente ocupada.

Agile

  • Não é possível saber no início do projeto tudo aquilo que é necessário para criar um produto de software.
  • No início do projeto, os clientes não conseguem indicar com exatidão tudo aquilo que vai ser necessário introduzir no produto.
  • É importante obter feedback do cliente de forma regular e o mais cedo possível. É importante passar esse feedback à equipa.
  • A forma mais precisa de medir o progresso de um projeto é através do código que esteja a funcionar consoante aquilo que foi pedido.
  • Mover a fase de teste para o início do ciclo de desenvolvimento melhora a partilha de informação entre developers, clientes e testers, o que terá um impacto positivo no código que é entregue.
  • A forma como o trabalho é feito é da responsabilidade da equipa que o vai desenvolver.
  • Trabalhar num projeto de cada vez melhora a produtividade da equipa.

Será que estas crenças são princípios universais ou apenas um conjunto de regras e práticas que devem ser seguidos?

Uma aproximação pragmática

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.

Um novo paradigma

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.

Lean

  • A maioria dos problemas provém do sistema usado ao invés das pessoas que nele trabalham.
  • As pessoas que fazem o trabalho são as que melhor percebem como aperfeiçoar o sistema em uso.
  • Ad-hoc não é um processo aceitável.
  • A análise de toda a cadeia de execução, e como está montado o encadeamento das diversas fases é mais vantajoso do que garantir que individualmente, cada uma das fases é o mais eficiente possível. Ou seja, o sistema deve ser otimizado como um todo e não apenas as suas fases.
  • A eficiência do sistema é medida pelo período decorrido desde o surgimento da ideia até que a mesma seja concretizada em valor acrescentado para o cliente.
  • A camada de gestão deve trabalhar em conjunto com a equipa de maneira a aperfeiçoar o seu método e deste modo aumentar a sua eficiência.
  • As equipas são mais eficientes quando a quantidade de trabalho está limitada à sua capacidade.

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:

  1. Com base na lista de crenças elementares do paradigma Waterfall, quais as que consideram verdadeiras?
  2. Com base na lista de crenças elementares do paradigma Agile, quais as que consideram verdadeiras?
  3. Com base na lista de crenças elementares do paradigma Lean, quais as que consideram verdadeiras?


Partilhar:

    Fale conosco

    Interesses

      Subscrever Newsletter

      Interesses