Veja também:

• [Filosofia] KISS – Keep it stupid simple
• Adobe Flex : porque usar remoting?
• Mas que raios é esse tal de BPEL?!
• Configurando o seu ambiente de desenvolvimento para Flex e Java : desenvolvimento com Maven
• Construindo aplicações Web e Desktop com BlazeDS e AMF

Twitter!

Impressões sobre o Evento do Google para Desenvolvedores

São Paulo foi escolhida como a primeira cidade para cediar o Google Developer Day, e não foi por acaso. O Google deixou bem claro em seu KeyNote que está acreditando muito no mercado brasileiro no que diz respeito a desenvolvimento de software, e não é uma mera crença, mas sim um argumento baseado em dados que o CTO do Google faz questão de mostrar pra todo mundo em sua palestra. Dentre tais números está a marca impressionante de 500.000 (quinhentas mil) ativações de dispositivos Android no mundo por dia e crescendo, sendo que um dos maiores mercados é o Brasil.






Para participar do GDD era preciso se inscrever no site, e resolver uma provinha com um problema simples de programação. Acertando as questões da provinha, suas chances de ser convidado aumentavam consideravelmente. E foi assim que eu fui convidado.
Trata-se de um evento voltado principalmente para desenvolvedores, com brindes, comida e Wi-Fi de graça, ou seja, o paraíso para muito Nerd entusiasta Google. Com direito a tendinhas e logos do Google espalhados por todo Hall de eventos do Hotel Sheraton.
Fiquei espantado com a quantidade de pessoas, e principalmente com a quantidade de pessoas usando algum smartphone top de linha (com Android claro) no mesmo ambiente. Ambiente esse que tocava música 8 bits dos video games antigos (bons tempos… =) ). E para começar o evento e dar início a maratona de palestras, o CTO do Google pessoalmente ministrou o KeyNote.
O KeyNote deixou todo mundo bem curioso sobre o que estava por vir ao longo do dia nas palestras separadas por tracks como Android, Google AppEngine, Google Chrome e talvez o mais esperado Html 5.

Android

Nada de muito novo com as palestras sobre Android. O pessoal do Google fez questão de manter o suspense sobre qual seria a versão do novo Android (Ice Cream Sandwich), mas que agora já foi revelado que será a 4.0.
Foram feitas algumas palestrar sobre usabilidade de Apps para Android, e passado bem por cima as features novas da plataforma, dentre elas o que acredito fosse o mais esperado é a integração total entre celulares e tablets, ou seja, o mesmo apk para ambos os dispositivos.
Para tornar fácil tal integração, foi adicionado o conceito de Fragment, que nada mais é do que uma porção específica da interface do dispositivo, que varia de acordo com o tamanho da tela. Por exemplo um tablet, pode possuir 3 Fragments padrão, sendo um uma barra de tarefas, outro uma listagem e um uma área de trabalho todos mostrados ao mesmo tempo, mas a mesma aplicação em um celular iria do Fragment de listagem para o Fragment com a área de trabalho por meio de uma transição, pois não cabem os 3 fragments na tela ao mesmo tempo.
Falou-se muito de In App Billing, ou seja, compra de artefatos dentro das próprias aplicações e não diretamente no market. Foram mostrados números bem convincentes, como por exemplo: do top 10 de aplicações mais rentáveis na AppMarket, 9 usam In App Billing. Números no mínimo tentadores para arriscar com a tecnologia.
Acredito que o Google tem muito mais novidade guardada para o Android, mas não falaram nada no GDD, porque o foco do evento foi outro, como veremos.

Google AppEngine

A procura pelas palestras sobre AppEngine foi muito grande, tanto que não consegui entrar em uma delas pois a sala lotou logo depois do anúncio do começo do evento.
O Google definitivamente acredita que seu Cloud é o futuro no que diz respeito a hospedagem de serviços para as Apps Mobile. O foco principal no GDD foi mostrar como que é fácil desenvolver para a AppEngine todos os tipos de aplicativos, incluindo jogos (foi reservada uma palestra apenas para falar de jogos usando a AppEngine).
Acredito que a intenção do Google é difundir mais o uso da AppEngine aqui no Brasil. Acredito que apesar do crescimento que foi obtido, eles percebem que o crescimento pode ser muito maior. Não acompanhei muito o track sobre AppEngine, então não consigo entrar muito em detalhes sobre o que mais foi abordado.

Google Chrome

Eu não esperava que fosse ser dada tanta atenção ao Google Chrome como foi dada no GDD.
Em todas as palestras o Google Chrome era referenciado como principal porta de entrada para a Web e as novas tecnologias. Foram apresentadas ferramentas de produtividade e desenvolvimento para criar aplicativos específicos do Google Chrome.
Acredito que o Google está preparando terreno, e já quer ter em mãos muitos aplicativos compatíveis com o Google Chrome quando chegar a hora de lançar o Chrome OS. E o discurso deles é muito convincente para os desenvolvedores. Eu ouvi muita gente impressionada com as possibilidades e facilidades de desenvolver aplicativos Chrome.

Html 5

Html 5 foi a estrela do evento. Não tinha uma pessoa que os olhos não brilhavam ao ver o trailer de Era do Gelo em 3D no Youtube, ou alguns avatares dançando conforme a música que tocava no ambiente de maneira dinâmica. E todo mundo ficou impressionado quando descobriu que todos os slides de todas as palestras estavam sendo passados no Chrome, e foram feitos em Html 5.
Foram mostradas muita features de Html 5 que ainda estão em teste, e que não necessariamente irão dar certo, mas a idéia não era conseguir algum tipo de vantagem, e sim mostrar o potencial do que está por vir.
Foi apresentado um framework muito interessante em Java: PlayN!. Uma biblioteca para construir jogos que podem ser jogados em Html 5, Android ou até mesmo Java nativo.
Muitas melhorias com tratamento de áudio e vídeo foram mostradas, e do jeito com que os palestrantes demonstraram, é difícil não acreditar que Html 5 ditará o ritmo das aplicações Web em um futuro próximo.





Espero que eu tenha despertado a curiosidade de alguns sobre as tecnologias do Google e da Comunidade que estão por vir. E de uma coisa eu estou convencido, preciso conhecer mais Html 5 .

Por @Gust4v0_H4xx0r

Twitter!

Impressões sobre o Evento do Google para Desenvolvedores

São Paulo foi escolhida como a primeira cidade para cediar o Google Developer Day, e não foi por acaso. O Google deixou bem claro em seu KeyNote que está acreditando muito no mercado brasileiro no que diz respeito a desenvolvimento de software, e não é uma mera crença, mas sim um argumento baseado em dados que o CTO do Google faz questão de mostrar pra todo mundo em sua palestra. Dentre tais números está a marca impressionante de 500.000 (quinhentas mil) ativações de dispositivos Android no mundo por dia e crescendo, sendo que um dos maiores mercados é o Brasil.






Para participar do GDD era preciso se inscrever no site, e resolver uma provinha com um problema simples de programação. Acertando as questões da provinha, suas chances de ser convidado aumentavam consideravelmente. E foi assim que eu fui convidado.
Trata-se de um evento voltado principalmente para desenvolvedores, com brindes, comida e Wi-Fi de graça, ou seja, o paraíso para muito Nerd entusiasta Google. Com direito a tendinhas e logos do Google espalhados por todo Hall de eventos do Hotel Sheraton.
Fiquei espantado com a quantidade de pessoas, e principalmente com a quantidade de pessoas usando algum smartphone top de linha (com Android claro) no mesmo ambiente. Ambiente esse que tocava música 8 bits dos video games antigos (bons tempos… =) ). E para começar o evento e dar início a maratona de palestras, o CTO do Google pessoalmente ministrou o KeyNote.
O KeyNote deixou todo mundo bem curioso sobre o que estava por vir ao longo do dia nas palestras separadas por tracks como Android, Google AppEngine, Google Chrome e talvez o mais esperado Html 5.

Android

Nada de muito novo com as palestras sobre Android. O pessoal do Google fez questão de manter o suspense sobre qual seria a versão do novo Android (Ice Cream Sandwich), mas que agora já foi revelado que será a 4.0.
Foram feitas algumas palestrar sobre usabilidade de Apps para Android, e passado bem por cima as features novas da plataforma, dentre elas o que acredito fosse o mais esperado é a integração total entre celulares e tablets, ou seja, o mesmo apk para ambos os dispositivos.
Para tornar fácil tal integração, foi adicionado o conceito de Fragment, que nada mais é do que uma porção específica da interface do dispositivo, que varia de acordo com o tamanho da tela. Por exemplo um tablet, pode possuir 3 Fragments padrão, sendo um uma barra de tarefas, outro uma listagem e um uma área de trabalho todos mostrados ao mesmo tempo, mas a mesma aplicação em um celular iria do Fragment de listagem para o Fragment com a área de trabalho por meio de uma transição, pois não cabem os 3 fragments na tela ao mesmo tempo.
Falou-se muito de In App Billing, ou seja, compra de artefatos dentro das próprias aplicações e não diretamente no market. Foram mostrados números bem convincentes, como por exemplo: do top 10 de aplicações mais rentáveis na AppMarket, 9 usam In App Billing. Números no mínimo tentadores para arriscar com a tecnologia.
Acredito que o Google tem muito mais novidade guardada para o Android, mas não falaram nada no GDD, porque o foco do evento foi outro, como veremos.

Google AppEngine

A procura pelas palestras sobre AppEngine foi muito grande, tanto que não consegui entrar em uma delas pois a sala lotou logo depois do anúncio do começo do evento.
O Google definitivamente acredita que seu Cloud é o futuro no que diz respeito a hospedagem de serviços para as Apps Mobile. O foco principal no GDD foi mostrar como que é fácil desenvolver para a AppEngine todos os tipos de aplicativos, incluindo jogos (foi reservada uma palestra apenas para falar de jogos usando a AppEngine).
Acredito que a intenção do Google é difundir mais o uso da AppEngine aqui no Brasil. Acredito que apesar do crescimento que foi obtido, eles percebem que o crescimento pode ser muito maior. Não acompanhei muito o track sobre AppEngine, então não consigo entrar muito em detalhes sobre o que mais foi abordado.

Google Chrome

Eu não esperava que fosse ser dada tanta atenção ao Google Chrome como foi dada no GDD.
Em todas as palestras o Google Chrome era referenciado como principal porta de entrada para a Web e as novas tecnologias. Foram apresentadas ferramentas de produtividade e desenvolvimento para criar aplicativos específicos do Google Chrome.
Acredito que o Google está preparando terreno, e já quer ter em mãos muitos aplicativos compatíveis com o Google Chrome quando chegar a hora de lançar o Chrome OS. E o discurso deles é muito convincente para os desenvolvedores. Eu ouvi muita gente impressionada com as possibilidades e facilidades de desenvolver aplicativos Chrome.

Html 5

Html 5 foi a estrela do evento. Não tinha uma pessoa que os olhos não brilhavam ao ver o trailer de Era do Gelo em 3D no Youtube, ou alguns avatares dançando conforme a música que tocava no ambiente de maneira dinâmica. E todo mundo ficou impressionado quando descobriu que todos os slides de todas as palestras estavam sendo passados no Chrome, e foram feitos em Html 5.
Foram mostradas muita features de Html 5 que ainda estão em teste, e que não necessariamente irão dar certo, mas a idéia não era conseguir algum tipo de vantagem, e sim mostrar o potencial do que está por vir.
Foi apresentado um framework muito interessante em Java: PlayN!. Uma biblioteca para construir jogos que podem ser jogados em Html 5, Android ou até mesmo Java nativo.
Muitas melhorias com tratamento de áudio e vídeo foram mostradas, e do jeito com que os palestrantes demonstraram, é difícil não acreditar que Html 5 ditará o ritmo das aplicações Web em um futuro próximo.





Espero que eu tenha despertado a curiosidade de alguns sobre as tecnologias do Google e da Comunidade que estão por vir. E de uma coisa eu estou convencido, preciso conhecer mais Html 5 .

Por @Gust4v0_H4xx0r

Ol? Pessoal.

Este ? o segundo post de uma s?rie de post's que estou fazendo, em formato de resenha. Como partida, estou lendo o livro Management 3.0 Leading Agile Developers, Developing Agile Leaders e sintetizando ele aqui. Confira aqui a parte 1.

Teoria dos sistemas complexos

A teoria dos sistemas complexos ? uma teoria advinda da matem?tica que se concentra em entender porque alguns tipos de sistemas s?o est?veis e porque alguns outros tipos n?o s?o. Levando para o campo de desenvolvimento de software a referida teoria nos ajuda a explicar porque alguns projetos s?o est?veis e porque outros n?o s?o.

Desenvolvimento de software pode ser visto como um sistema complexo adaptativo, onde as intensas intera??es e feedbacks fornecem oportunidade de melhoria aprendizado e conhecimento.

MULTIDISCIPLINARIDADE

A ideia de segregar pessoas que fazem trabalhos diferente oferece um impacto negativo ? performance da organiza??o. Esse tipo de segrega??o promove silos/feudos funcionais que dificultam a comunica??o e a amplifica??o do aprendizado e conhecimento na dimens?o ontol?gica da organiza??o (veja a teoria da cria??o do conhecimento). Corroborando com os princ?pios do manifesto ?gil, a teoria da complexidade tamb?m ? a favor da forma??o de equipes multidisciplinares.

O CORPO DE CONHECIMENTO DE SISTEMAS

N?o h? uma ?nica defini??o gen?rica para explicar a complexidade, cada sistema ? diferente, peculiar e por vezes suas defini??es s?o complementares, as vezes sobrepostas e as vezes contradit?rias. No entanto, existem v?rios estudos que se concentram em diferentes ?reas e que trouxeram uma contribui??o significativa para o campo dos sistemas complexos: Entre esses estudos est?o: a teoria evolucion?ria (evolutionary theory), a teoria dos jogos (game theory) a teoria do caos (chaos theory), a teoria dos sistemas din?micos (dynamical systens theory), entre outras. A figura abaixo apresenta o corpo de conhecimento de sistemas.

SIMPLICIDADE: UM NOVO MODELO

“Simplicidade normalmente est? relacionada com peso (o qu?o dif?cil ?) para algu?m tentar explicar ou entender algo. Qualquer coisa que ? f?cil de entender ou explicar ? simples, em contraste com algo complicado.”

Antes de discutir simplicidade, faz-se necess?rio entender cada terminologia abaixo:

• Simples: f?cil de entender
• Complicado: muito dif?cil de entender

• Ordenado: totalmente previs?vel
• Complexo: um pouco previs?vel (mas com muitas surpresas)
• Ca?tico: completamente imprevis?vel

Na literatura, alguns modelos diferenciam a referida terminologia, como os modelos de David Snowden, que descreve um modelo contendo quatro dom?nios(simples, complicado, complexo e ca?tico) e modelo de Ralph Stacey que cria algo similar. Ele mostra o simples, complicado, complexo, e ca?tico, como quatro ?reas com base em duas dimens?es: o grau de concord?ncia e o grau de incerteza.

A NOVA ERA: PENSAMENTO COMPLEXO (COMPLEXITY THINKING)

Quando voc? aplica a teoria de sistemas complexos (complex systems theory) em desenvolvimento e gerenciamento de software, voc? est? tratando sua organiza??o como um sistema.

A din?mica do sistemas(System dynamics) – n?o confunda com a teoria dos sistemas din?micos(dynamical systems theory), foi uma das primeiras t?cnicas criadas para mostrar como eventos aparentemente simples podem causar comportamentos inesperadas na organiza??o.

A System dynamics percebe a organiza??o como uma estrutura interligada e mutuamente dependente das partes. A System dynamics tem ajudados os gestores ? melhorar sua compreens?o dos processo de neg?cio.

Uma outra t?cnica similar ? chamada de pensamento sist?mico (systems thinking), popularizada no livro The Fifth Discipline (que tamb?m pretendo fazer resenhas dele aqui no blog ). Essa t?cnica aborda o entendimento de como o pensamento influencia o outras partes como um todo e defende que o primeiro passo para se tornar uma organiza??o de aprendizagem ? ela compreender, como um sistema hol?stico, o que ela faz e como realmente faz.

O estudo da complexidade em sistemas sociais ? chamado de complexidade social (social complexity). A complexidade social ? o estudo de grupos sociais em sistemas adaptativos complexos.

System dynamics e systems thinking percebem a n?o linearidade, mas eles ainda partem da ideia que, de alguma forma, a alta ger?ncia constr?i o “tipo certo” de organiza??o que produz o “tipo certo” de resultado. Entretanto, atualmente os gestores percebem que para gerenciar a complexidade social, eles precisam entender como as coisas “emergem” e n?o como elas s?o “constru?das”. O modelo de gest?o 3.0 aplica o pensamento complexo (complexity thinking) e assume que os gestores n?o podem construir nem dirigir uma equipe auto-organizada. Em vez disso, a equipe deve emergir naturalmente. O modelo reconhece que organiza??es produtivas n?o s?o gerenciadas dirigidas por modelos e planos. Em vez disso, deve emergir atrav?s do poder da evolu??o da auto-organiza??o.

Obs: Para mim esses assuntos s?o complicados. Portanto, sinta-se a vontade para criticar, corrigir ou acrescentar valor nos coment?rios.

Ol? Pessoal.

Este post ? o primeiro de uma s?rie de posts que pretendo publicar, em formato de resenha, sobre “livros que estou lendo“. Como partida, fiz a primeira de v?rias outras do livro Management 3.0 Leading Agile Developers, Developing Agile Leaders. O livro pretende mostrar como ser um bom gerente ?gil. A base para isso ? o entendimento sobre pessoas e sistemas e a maneira como as pessoas pensam sobre sistemas. Antes de tudo, os gerentes devem compreender como sistemas sociais funcionam.

GEST?O 1.0 = HIER?RQUICA

Representada por organiza??es hierarquizadas, onde o comando parte da alta ger?ncia funcional, de cima para baixo. Aqueles que est?o no alto da hieraquia tem altos sal?rios, grandes egos. em contrapartida, aqueles que est?o na base da hierarquia normalmente tem baixos sal?rios, poucas responsabilidades (especializado), e pouca motiva??o para fazer um bom trabalho. Fortemente baseada nos modelos fordistas e tayloristas do in?cio do s?culo. Sua gest?o ? focada no comando controle.

GEST?O 2.0 = MODISMO

S?o as organiza??es essencialmente “Gest?o 1.0”, mas que cont?m pessoas que j? perceberam que esse modelo n?o funciona bem “fora da caixa”. Ent?o s?o criados v?rios modelos adicionais de servi?os e processos como BSB, six-sigma, ITIL, Cobit, Qualidade total, entre outros.

GEST?O 3.0 = COMPLEXIDADE

? uma ger?ncia que percebeu que a organiza??o ? uma rede, formada por pessoas, seus relacionamentos e sua complexidade social e n?o por divis?es funcionais hier?rquicas. Abomina o comando-controle e advoga por uma cultura de lideran?a, hol?stica, org?nica, enxergando a organiza??o como um sistema (complexo) vivo e n?o apenas como uma m?quina.

CAUSALIDADE

O determinismos causal infere que as coisas que acontecem hoje s?o causadas por outras coisas que aconteceram antes. Podemos utilizar o determinismo causal, por exemplo, para prever com precis?o quando ser? a pr?xima vez que o cometa Halley passar? pr?ximo da atmosfera terrestre, com base na ?ltima vez que ele passou. Nesse sentido, o determinismo causal habilita que os desenvolvedores ? projetar, planejar e prever tudo o que dever? ser feito no projeto de desenvolvimento de software. Se abstra?rmos qualquer problema de bug, altera??o de requisitos ou cat?strofe interplanet?ria, a causalidade pemite prever com bastante precis?o. Pena que n?o podemos utilizar tamb?m c?lculos astron?micos para determinar a complexidade sist?mica onde projetos de software est?o inseridos. lol.

COMPLEXIDADE

Complexidade n?o tem rela??o com v?rias coisas pra fazer simultaneamente ou com em fazer coisas grandes, a complexidade ? intr?nseca. N?o obstante, v?rias teorias como por exemplo: teoria dos sistemas din?micos (Dynamical systems theory), teoria do caos (chaos theory), teoria dos jogos(game theory), tentam explicar por que alguns fen?menos s?o imprevis?veis e n?o podem ser calculados apenas com a experi?ncia e observa??es emp?ricas. O campo da ci?nica que estouda esses fen?menos ? nomeada como teoria da complexidade (complexity theory).

A teorias da complexidade, de certa forma, ? um “conforto” para gerentes, lideres de time e gestores em organiza??es que desenvolvem software. Isso significa que nem tudo est? perdido, h? um novo paradigma cient?fico, baseado na complexidade de sistemas, que ajuda a entender o problema da volatilidade e incertezas em desenvolvimento de softwares.

REDUCIONISMO

O reducionismo ? a abordagem que se baseia na desconstru??o de algo em partes menores, para analis?-las e a? sim entender o todo,. Entendimento do sistema pelo entendimento das partes. Essa t?cnica pode ser utilizada, por exemplo, para desconstruir um computador para entender como ele funciona, para dissecar um animal para entender como seus org?os internos funcionam. No entanto, em algumas ?reas, onde a imprevisibilidade ? uma constante, a utiliza??o da abordagem reducionista n?o ? capaz de determinar, por meio da desconstru??o e an?lise das partes, o entendimento do todo. Enquadra-se nisso, estudos sobre: organismos, consci?ncia humana, as economias, climas, e projetos de software

HOLISMO

O Holismo ? a ideia de que o comportamento do sistema n?o pode ser completamente determinado pelos seus componentes isolados. A vis?o hol?stica pode ser vista como o oposto ao reducionismo, onde a vis?o do sistema como um todo determina comportamentos importantes para ele.

GERENCIAMENTO ?GIL

Uma das bases do desenvolvimento ?gil de software est? na teoria da complexidade. Os valores e princ?pios ?geis corroboram para reconhecer que o determinismo causal ? insuficiente para entregar projetos de sucesso. Conceitos bem conhecidos como auto-organiza??o, multi-disciplinaridade, autonomia s?o oriundos da ci?ncia da complexidade.

O MODELO DA GEST?O 3.0

O modelo da gest?o 3.0 mostra como gerenciar equipes sabendo que os sistemas s?o complexos, n?o lineares, n?o previs?veis e carentes de adaptabilidade. Para o entendimento de sistemas complexos, ? necess?rio, a priori, uma vis?o hol?stica do todo como objetivo de estudar a complexidade social. A gest?o 3.0 ? um modelo de gest?o ?gil que aplica a teoria dos pensamentos complexos (complexity thinking) em equipes de desenvolvimento de software ?gil. Sob o olhar do pensamento dial?tico, esse modelo compreende os encalsos do reducionismo no ambiente de desenvolvimento de software (tese), aceita a oposi??o e acredita em uma vis?o hol?stica, sist?mica e social (ant?tese), para criar uma nova ideia denominada gest?o 3.0 (s?ntese). A figura abaixo ilustra o modelo de gest?o 3.0.

Olá pessoal, que tal trabalhar com Adobe Flex e Java na cidade maravilhosa?

A Avanti Prima Engenharia está com oportunidades para trabalho com Adobe Flex/Java no Rio de Janeiro.

Segue abaixo informações sobre a vaga:

Experiência Exigida

• Experiência mínima comprovada de 3 anos no desenvolvimento de software na linguagem Adobe Flex, preferencialmente integrando com Java;
• Experiência em análise e modelagem de sistemas, utilizando UML;
• Conhecimento de padrões de projetos orientados a objetos;
• Conhecimento em Hibernate, JSF (front-end), EJB (back-end).
• Conhecimento em especificação de casos de uso;

Interessados, enviar seus CV para: stefan.horochovec@avantiprima.com.br ou para eric.sander@avantiprima.com.br

Por muito tempo o teste de software foi visto como uma atividade do processo de desenvolvimento de software que no papel era extremamente importante e necess?ria para atingir a qualidade do produto de software, mas na pr?tica, por muitas empresas, tornou-se uma das atividades mais negligenciada. Por esse motivo enraizou-se uma p?ssima cultura em rela??o ? atividades de testes, que, quanto a import?ncia, ficou ? margem da constru??es do software e que, se desse tempo, era executada. A neglig?ncia, por muito tempo da referida atividade gerou algumas “afirma??es” que hoje soam como piadas:

• “…Implemente, se der tempo agente testa.”
  
• “o importante ? entregar… os testes, deixa que o cliente faz pra gente…”
  
• “o prazo vai estourar…Ent?o sacrifique os testes…”
  
• “entregue com bugs, mas entregue em dia, depois agente arruma…”
  
• “sabemos que nosso software est? cheio de bugs, ent?o vamos cobrar uma manuten??o mensal do nosso cliente para consert?-los…”
  
• “testar n?o ? uma atividade importante…”
  
• ”…como vamos testar se n?o temos tempo?”
  
• “…testar pra que? perda de tempo.”
  
• “pra desenvolver sem teste ? X, com teste ? X²…'“

Fico impressionado! D? at? medo! Imagine se a ind?stria de avia??o fosse igual a de software. Quantos avi?es cairiam por dia? Imagine se a ind?stria farmac?utica fosse igual a de software. Voc? confiaria nos rem?dios? Imagine se o projeto do modelo do seu carro fosse constru?do como esses softwares? Voc? andaria em um elevador que foi constru?do com essa mesma metodologia? “Instale o elevador a?… depois o cliente testa pra gente…”

Quando fala de teste, estou me referindo tamb?m a qualidade do software. Apesar de n?o serem sin?nimos, mas com certeza o n?vel de qualidade dos teste de software ? um fator, entre v?rios outros que definem a qualidade do produto final.

Por outro lado, do ponto de vista do profissional, o teste de software possuia alguns PRE-conceitos:

• “testar ? uma atividade chata e cansativa…”
• “testar paga mal…”
  
• “n?o gosto e n?o sei programar… logo vou trabalhar na ?rea de teste…”
  
• “minha empresa n?o valoriza a ?rea de testes…”
  
• “testar ? ficar encontrando erros dos outros…”
  
• “maus programadores viram testadores…”
• “…subatividade?”
  
• “qualquer um pode testar…”
  

Hoje, no entanto, o teste “virou o jogo” com a populariza??o de processos emergentes de desenvolvimento de software como eXtreme Programming. Pr?ticas como TDD e BDD fornecem uma novo paradigma no desenvolvimento. Hoje, com a ascens?o do teste de software, novas “afirma??es” foram geradas:

• “a qualidade do produto ? inegoci?vel…”
• “primeiro escrevemos nossos testes unit?rios, depois implementamos…”
  
• “entregar software sem um boa cobertura de teste unit?rio tornou-se amadorismo…”
  
• “aus?ncia de teste unit?rio ? anti?tico… “
  
• “n?o consegue executar teste de carga, performance e seguran?a no seu sistema? Sua equipe est? com d?bito t?cnico…”
  
• “nossa integra??o ? cont?nua e automatizada…”
  
• “nossos testes s?o automatizados…”
  
• “temos cada linha de c?digo da aplica??o, temos tr?s linhas de teste…”
  
• “nos preocupamos com a cobertura dos testes, com casos de teste que refletem os requisitos de neg?cio…”
  
• “enquanto os testes n?o passarem 100% o produto n?o ? entregue…”
  
• “entregue menos, mas entregue funcionando…”
  
• “quem quebrar o deploy paga dez flex?es…”
  

No começo de 2007 eu (Daniel) fiz a escolha de trabalhar por conta própria ao invés de continuar na estabilidade de um emprego. Desde o inicio, minha intenção era poder experimentar mercados diferentes, conhecer novas tecnologias, aprendizado e também retornos financeiros.

Assim comecei a Área Criações em sociedade com a Designer Tânia Azze. A empresa correu muito bem durante os anos que trabalhamos juntos e sempre fizemos desenvolvimento de sotware em paralelo com design em geral.

No entanto, apesar de também trabalhar como designer em nossos projetos o meu maior interesse sempre foi a área digital e no campo de design de interface com foco em desenvolvimento de software.

Tenho me especializado o máximo possível nessas áreas nos últimos anos e por essa razão, eu e minha antiga sócia, optamos por interromper as atividades da Área Criações e cada um voltar suas atenções para seus campos de maior interesse.

Objetiva Software

Eu ainda contínuo com os mesmos objetivos de 2007 e ainda não pretendo trabalhar como contratado em um futuro próximo.

Em 2010 tive a oportunidade de trabalhar novamente com o meu amigo Jeffry Degrande. Um excelente desenvolvedor com bastante experiência em Agile e Ruby, com quem eu já tínhamos trabalhado em projetos no passado e em 2010 fizemos parte da mesma equipe do Rails Rumble.

A partir dos bons resultados dos nossos trabalhos em equipe e dos interesses semelhantes, eu e Jeffry, resolvemos juntar nossa vontade em criar software de qualidade e fundamos uma nova empresa chamada Objetiva Software.

Nosso foco é unir a experiência que temos em desenvolvimento de software e design de interfaces para criar produtos que possuam alta qualidade em todos os aspectos, desde o código, testes, infra-estrutura até o posicionamento dos elementos na tela e aparência do sistema.

Seja através da criações de produtos para startup, coaching, treinamento ou desenvolvimento de projetos já existentes, o nosso objetivo é sempre manter os princípios que acreditamos na indústria de software e fazer o melhor trabalho possível.

A parte boa de tudo isso que apesar de apenas alguns meses de vida, nosso novo negócio tem corrido muito bem e já estamos alocados para vários projetos nos próximos meses, então aguardem algumas novidades em pouco tempo.

Nosso blog

No antigo site da Área Criações, eu era o responsável pelo blog, que movimentei com assuntos técnicos desde 2007. Muito do material que escrevi ainda é válido, principalmente os posts relacionados a Ruby e desenvolvimento em geral.

Por essa razão nós resolvemos importar alguns dos posts que condizem mais com as atividade da Objetiva e evitar a perda de todo esse material que ainda possui bastante utilidade. Nos próximos dias o site da Área Criações sairá do ar mas grande parte do material já está importado para o novo blog da Objetiva.

Mas vamos precisar que vocês atualizam os feeds para o novo endereço

De acordo com a norma ISO – 8402, qualidade é:  a totalidade das características de uma entidade, que lhe confere a capacidade de satisfazer as necessidades implícitas e explícitas. No entanto, qualidade é um conceito relativo, está fortemente relacionada à conformidade com os requisitos  à satisfação do cliente e ao atendimento as suas expectativas.

Muito se fala que a implantação de um Programa de Qualidade começa pela definição e implantação de um processo de software. Aborto esse assunto um pouco mais no post  Qualidade em Processo de Desenvolvimento de Software. Qualidade do produto de software não se atinge de forma espontânea. A qualidade do produto depende fortemente da qualidade do processo de desenvolvimento. Um bom processo não garante que os produtos produzidos são de boa qualidade, mas é um indicativo de que a organização é capaz de produzir bons produtos. Nesse sentido, a NBR ISO/IEC 9126, sob o título geral “Engenharia de software – Qualidade do produto”, enfatiza que um processo de qualidade influencia a os atributos de qualidade interna do produto de software, que por sua vez influencia os atributos de qualidade externa desse mesmo produto, e,  que consequentemente influenciam os atributos de qualidade em uso  percebidos pelo usuário.

NBR ISO/IEC 9126 descreve um modelo de qualidade do produto de software, composto de duas partes: a) qualidade interna e qualidade externa e b) qualidade em uso. A primeira parte do modelo especifica seis características para qualidade interna e externa, as quais são por sua vez subdivididas em sub características. Estas sub características são manifestadas externamente, quando o software é utilizado como parte de um sistema computacional, e são resultantes de atributos internos do software.

A segunda parte do modelo especifica quatro características de qualidade em uso, mas não apresenta o modelo de qualidade em uso além do nível de característica. Qualidade em uso é, para o usuário, o efeito combinado das seis características de qualidade do produto de software.