Desenvolvimento de Software – Produto Manufaturado ou Intelectual?

8su4hy9ykdaewssjrv1l8xnaeO que é um produto manufaturado?

São produtos que devem ser entregues “exatamente iguais” para todos os clientes como por exemplo um Tênis Nike Flyknit Air Max. Não importa aonde você compre e quantos existam, a sua copia vai ser exatamente igual a todas outras existentes. Outro exemplo seria a construção de um bolo de chocolate por uma padaria seguindo um formato padrão que defini seu preço.

Uso de processo para produto manufaturado?

Definir um processo para a criação de um produto manufaturado foi umas das coisas mais fanáticas que aconteceram na humanidade (veja a revolução industrial). Quando se cria um produto manufaturado sem um processo rígido é possível que esse produto tenha grandes chances de não ficar no formato exato especificado para ele, ocasionando seu descarte, gerando desperdícios de tempo, recursos e material prima. Ou seja,  prejuízo total.

Por isso um processo prescritivo é fundamental para evitar qualquer tipo de erro ou desperdício. Um processo determinístico prescreve os passos, quantidades de matéria prima, o cronograma, o custo, data de inicio e data de fim. Aproveitando o exemplo do bolo de chocolate de uma padaria, poderíamos dizer que ao vender esse bolo por um preço X, o responsável já esteja fazendo o calculo do custo de produzi-lo. Mas se o confeiteiro não seguir o processo exato de construção e suas medidas utilizado para medir o preço, é bem provável que o cliente não recebe aquilo que realmente pagou.

Veja que o modelo de fabricação industrial é classificado com linear e tem o foco no determinismo voltado ao modelo de construção.

O que é um produto intelectual?

São produtos que devem ser entregues como “únicos para cada cliente” contendo caraterísticas particulares e especificas como por exemplo uma pintura de quadro, um livro ou uma música. Ninguém no mundo vai ter aquele mesmo produto igual. Em caso de isso acontecer nos os classificamos como plágio.

Uso de processo para produto intelectual?

Quando se cria um livro, o autor pode começa-lo pelo meio, ter possíveis ideias para o seu final e quando estiver escrevendo o final ter novas ideias para o inicio. E quando ele estiver escrevendo o inicio, ele pode ter novas ideias melhores no meio já escrito e assim voltar a alterar o conteúdo do meio. No final de tudo, ele ainda pode rever toda a sua obra e decidir mudar algo, acrescentar ou retirar algo depois de tudo não ficou do agrado.

Da mesma forma na criação de uma musica que pode ser iniciado pelo seu refrão e seguir outras partes. A musica depois de pronta, ainda pode ser alterada a qualquer momento para compor melhorias julgadas necessário pelo seu autor.

Diante disso, se entende que um produto intelectual não pode ser construído dentro um processo determinístico, uma vez que ele se torna um impedimento para a inspiração do seu autor.

Será que o próprio autor do livro não teria a liberdade de poder alterar o meio da história quando estivesse escrevendo o último capitulo?  Será que um pintor não poderia acrescentar mais cores no seu quadro quando estivesse terminando ele, julgando positivamente necessário? Se ambos seguissem um processo determinístico que o impedisse o alterar partes anteriores já prontas, eles não teriam como fazer. Agora eu te pergunto: Isso faz sentido para você?

Criar um produto intelectual é uma atividade puramente intelectual que se caracteriza pela necessidade de sucessivas revisões, alterações, correções até que o autor julgue a sua forma final. Diante disso, poderíamos afirmar que existe um processo para criar um produto intelectual e ele é chamado de Processo Adaptativo aonde o produto passar por constantes revisões e correções até assumir forma desejada.

Veja que o modelo de fabricação intelectual é classificado com não-linear e tem ausência de determinismo.

Desenvolvimento de software é um produto manufaturado ou intelectual?

Diante dessas informações, eu te pergunto novamente: No seu modelo mental atual, criar um software é uma atividade intelectual ou manufaturado? Será que o cliente não pode mudar de idéia quando ele receber aquele novo processo depois de implementado e testado? Sera que o cliente não pode ter novas idéias depois uma nova funcionalidade em produção?

Você é aquele gestor de projetos ou aquele programador que fica “irritadinho” quando o cliente muda o plano original depois de entregue? Isso só prova que você esta vivendo o desenvolvimento de software como um modelo de fabricação industrial  e seu cliente por sua vez, esta partindo do principio que esta construído uma obra intelectual particular. Veja que a consequência disso é que o custo, cronograma e funcionalidades nunca batem com o planejado. Assim ninguém fica feliz!

Existe duas formas para resolver isso: A primeira é dizer para o cliente que  o sistema não é uma obra intelectual, com processo definido é ele não pode mudar nada depois de pronto. Mas quem ta pagando o sistema? kkkkkkk……. Isso te deixa a última opção brother, sair da sua zona de conforto e adotar outra filosofia de gestão de projetos de software.

 “Novo mandamento vos dou: que vos ameis uns aos outros; assim como eu vos amei, que também vos ameis uns aos outros. Nisto conhecerão todos que sois meus discípulos: se tiverdes amor uns aos outros.” João 13:34-35

Java Frameworks – Transações

contrato-de-transaçãoSegue as opções de frameworks para gerenciar transações automáticas:

Gerenciador de Transação

Provedores de JTA

Para todas as informações, veja o post inicial.

“Vós sois a luz do mundo.  Assim brilhe também a vossa luz diante dos homens, para que vejam as vossas boas obras e glorifiquem a vosso Pai que está nos céus.” Mateus 5:14-16

Guia Front-End: O caminho das pedras para ser um dev Front-End

guia-frontend-featured_largeDúvidas, tempo, tecnologias, mercado, mais dúvidas. Será que existe um verdadeiro caminho das pedras que devemos percorrer para nos tornarmos bons e verdadeiros desenvolvedores front-end? O que estudar? Qual blog ler? Que fóruns acompanhar? Como participar da comunidade? Será que estou no caminho certo? Se você é desenvolvedor front-end, quer entrar na área ou busca se tornar um grande profissional, essas dúvidas já devem ter passado por sua cabeça.

Neste livro, Diego Eis nos guia sobre o mundo de desenvolvimento web através de uma análise franca e objetiva de diversas tecnologias adotadas, necessidades do mercado e postura profissional. Você não vai aprender diretamente sobre essas tecnologias aqui, mas certamente vai desenvolver um senso mais apurado e uma nova forma de olhar para elas, o que é fundamental nesse mundo de aprendizado não linear.

“Aquele, porém, que se gloria, glorie-se no Senhor. Porque não é aprovado quem a si mesmo se louva, e sim aquele a quem o Senhor louva.” 2 Coríntios 10:17-18

Extreme Programming – 5

146722381Auto-semelhança

O princípio da auto-semelhança sugere que, quando equipes XP encontrarem soluções que funcionem em um contexto, também procurem adotá-las em outros, mesmo que em escalas diferentes. Por exemplo, o ritmo básico de desenvolvimento em XP é escrever um teste que falha e então fazê-lo funcionar. Esse ritmo opera de forma semelhante em diferentes escalas. Em um trimestre, você lista os temas que quer abordar e então os aborda com histórias. Em uma semana, você lista as histórias que deseja implementar, escreve testes expressando as histórias e então os faz funcionar. Em poucas horas, você lista os testes que sabe que precisa escrever, então escreve um teste, faz funcionar, escreve outro teste, faz os dois funcionarem e assim por diante, até que todos da lista estejam feitos. Esse princípio também se aplica com a adoção de padrões de projeto, por exemplo.

Benefício Mútuo

As práticas do XP são estruturadas de modo a serem mutuamente benéficas para todos os envolvidos em um projeto de software. Programação em par, por exemplo, beneficia os programadores de inúmeras formas. Mas, também beneficia os clientes, porque costuma ser raro encontrar bugs em funcionalidades implementadas em par. Gerentes, por sua vez, também se beneficiam porque a programação em par ajuda a disseminar conhecimento na equipe, o que permite que ela supere mais facilmente a ausência de um de seus membros enquanto estiver de férias, por exemplo.

Benefício mútuo é um dos princípios mais importantes do XP e, ao mesmo tempo, um dos mais difíceis de serem adotados. Projetos de software são complexos e normalmente sofrem pressões de tempo e outras que podem levar a equipe a adotar práticas benéficas para uns, mas prejudiciais a outros. É preciso atenção. O bom funcionamento de uma equipe é algo frágil. Práticas que não beneficiem todos os envolvidos são capazes de destruir relacionamentos e criar ainda mais dificuldades nos projetos.

Fonte: http://desenvolvimentoagil.com.br/xp/

“Porque, se vivemos, para o Senhor vivemos; se morremos, para o Senhor morremos. Quer, pois, vivamos ou morramos, somos do Senhor.” Romanos 14:8