LPS – Linha de Produto de Software

Já escrevi muitas vezes que desenvolver software direito é muito anterior aos métodos ágeis, pois qualidade, orientação a objetos, componentização, reuso, conceitos aplicados de serviços. Para ampliar estes conceitos chegamos ao SOAP, protocolo de transferência de mensagens em XML para ambientes distribuídos e REST, um protocolo sem restrições ao formato da mensagem, apenas ao comportamento dos componentes.

Muitas empresas ainda não designam uma equipe ou profissionais responsáveis por estabelecer as regras mínimas para engenharia de software. Na maioria dos casos, cada projeto possui autonomia para reinventar a roda, desenvolvimento espaguete, ausência de boas práticas de reuso, ano de 2015 e ainda nos faltam boas e mínimas práticas de Linhas de Produto de Software.

A LPS propõe estabelecer um plano de reuso para famílias de produtos, modularização como acelerador para construção rápida de aplicações. Mais um conceito que devemos à indústria automobilística. Com a modularização, criaram as linhas de produção, com etapas síncronas e assíncronas. Hoje a mesma linha, com pequenas variações compartilha pessoas, ferramentas, peças, componentes e equipamentos para produzir diferentes produtos.

LPS-diagrama-2.

Com certeza é sonho de consumo da maioria das equipes de desenvolvimento, ter uma proposta clara em relação a componentização e reuso. Ano de 2015 e muitas empresas ainda não dominam nem entendem os benefícios de iniciar cada história ou funcionalidade tentando entender se tudo ou partes delas são comuns a outros de seus produtos, variáveis ou específico ao produto a ser construído.

O Standish Group falando em Small Project Philosophy desde 2012 e burburinho no conceito de micro-serviços e tem muita equipe sênior ainda construindo soluções enormes, monolíticas, as vezes sequer com três camadas independentes. A justificativa para esta resistência é porque tem uma curva inicial, o resultado não é imediato, não é como aspirina. É o mesmo paradoxo que enfrentamos em Agile, BDD, TDD, em tudo o que não é muito “fácinho”.

A curva de aprendizado é o escudo usado por muita gente para não adotar práticas que eram disruptivas a 20 anos atras, mas que até hoje muita gente se refere a elas como sendo uma novidade a ser avaliada. Na eSIG uma citação sobre LPS de 2007, Linden no artigo “Software Product Lines in Action” demonstra graficamente que a partir do terceiro sistema aplicando LPS há uma redução de custo e esforço para desenvolvimento de novos sistemas:

lps_figura1

Creio realmente ser possível construir uma curva parecida para uma variada gama de métodos, como SCRUM, Kanban, XP, de técnicas como BDD para especificação por exemplos, para TDD e em testes funcionais, mesmo assim tem muita gente boa que, por não trazerem resultados garantidos e imediatos, preferem continuar desenvolvendo da mesma forma que faziam a 15 anos atras.

No mesmo artigo, é importante esclarecer que LPS vai além de componentes de software, envolvendo artefatos de todo o ciclo de vida de uma solução, desde modelagem de negócio, personas, histórias de usuários, requisitos, testes em seus diferentes contextos, ambiente, bibliotecas, frameworks, etc.

Como disse Neal Ford em sua palestra no Agile Brazil de 2012, cada projeto de desenvolvimento de software possui dois usuários, aquele que se beneficia do produto e o usuário oculto, que são os próximos profissionais que irão dar manutenção futura no software que construímos … desculpa aí!

Isto me faz lembrar perguntas em cursos SCRUM sobre rastreabilidade, na verdade usar Agile é um desafio muito maior que ser iterativo-incremental, pois em ambientes complexos, corporativos, difícil abrir mão da construção de mecanismos de rastreabilidade de artefatos e componentes de uma linha de produtos de software, quer comuns, variáveis ou específicos.

Hoje a componentização já trancende até mesmo os muros das organizações, uma infinidade de componentes na nuvem resolvem necessidades pontuais utilizadas por aplicações dos mais variados portes. A cada ano intensifica-se o uso de serviços variados, reaproveitando o comum e permitindo que nos dediquemos no que realmente é o diferencial … pense nisso, chega de reinventar a roda!

A seguir uma tese de doutorado e um TCC sobre o tema:

1) Tese sobre LPS realizada por ELDER DE MACEDO RODRIGUES com orientação do Prof Dr Avelino Francisco Zorzo em 2013. Segundo seu resumo, a principal contribuição desta tese de doutorado é apresentar uma LPS de ferramentas de teste que suportam TBM (PLeTs) e um ambiente automatizado para apoiar a geração dessas ferramentas (PlugSPL):

PLETS – A PRODUCT LINE OF MODEL-BASED TESTING TOOLS

2) TCC realizado por Maicon Azevedo da Luz com orientação do Prof Dr Kleinner Silva Farias de Oliveira. Segundo seu resumo, o trabalho propõe uma LPS para aplicações Web, observando as principais funcionalidades encontradas em aplicações Web, o LPS-Web:

UMA LINHA DE PRODUTO DE SOFTWARE PARA APLICAÇÕES WEB

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s