Archive for the ‘atualidades’ Category

Será que o sistema Toyota é falho?

fevereiro 12th, 2010

Acontecimentos recentes no mercado de automóveis, de uma forma surpreendente, tem colocado em xeque o modelo da Toyota que ficou famoso se tornou  uma referência em gestão e processos na última década.  O pessoal que tem lido jornal tem visto esses dias várias notícias informando a enorme quantidade de recall que a fábrica toyota e suas afiliadas estão fazendo no Japão e no mundo, decorrente de erros nos seus processo de fabricação,  laudos fradulentos de segurança, etc.  Tudo isso colocou em dúvida a verdadeira eficiência do modelo que se tornou a nova moda dos hippies da administração e processos do mundo.

No início do século XX  o mundo vivia sua revolução industrial impulsionado pela novo modelo Ford de produção em escala.  Em detrimento ao maneiro artesanal e caseira da fazer as coisas que tornavam os produtos “incrivelmente caros”, agora tudo é feito em grande quantidade e de forma seriada. Surge as fábricas.   Esse modelo ultrapassa o contexto industrial e começa a permear todo o comportamento social:  convívios, formas de negócio,  gestão e administração, etc.  Tudo agora deve ser grande; gigante… Não existe espaço mais para pequenos atos.  Empresa familiares dão lugar para grandes corporações, pequenos negócios de esquina agora fazem parte de cadeias de lojas e por aí seguimos.

Com a vinda da segunda guerra mundial, em nome do esforço de guerra, esse modelo de grande escala ganha mais força: tudo deve ser feito aos milhões.  Pequenos defeitos e erros de cálculos são tolerados pois, estatisticamente, representam uma porcentagem infinitesimal frente ao todo.  Porém do outro lado do mundo, ao final do conflito, existia um Japão arrasado, sem homens, sem recursos naturais abundantes, sem espaço, destruído por duas bombas nucleares.  Nesse país um sonhador  vindo de uma família de empreendedores tenta construir um futuro. Assim nasce a Toyota.

A Toyota, (diversas fontes dizem que ela foi fundada em 1937, porém acredito que a sombra da empresa que conhecemos hoje começou no pós-guerra)  ao contrário da Ford (a grande Ford com suas imensas indústrias no USA)  estava num contexto de escassez. Tudo faltava.  Não havia aço, não havia homens, faltava tudo… Não existia espaço para desperdício. Não havia margens para erro.  Usando toda a herança cultural japonesa de perfeição,  a Toyota criou todo um universo de processos visando a redução e até a eliminação total de todo e qualquer processo ou coisa que não gerasse valor para o cliente final dela.

Nos anos que seguiram esse conjunto de boas práticas e regras se mostrou extremamente vencedor e hoje a Toyota é maior fabricante de carros do mundo superando  de longe qualquer outra.  Hoje eles são os melhores, a referência,  a meta a atingir.

Assim como o modelo Ford, nos seus áureos tempos, ultrapassou os limites  das fábricas para fazer parte de tudo na cotidiano das pessoas, o modelo toyota também achou seu caminho em outras áreas como administração, gestão de projetos, desenvolvimento, etc.  Da década de 80 a até atuais dias passou a ser o hippie do momento, o novo frisson dos intelectuais e vanguardistas do mercado.  Não tardou para que a “forma Toyota” de fazer as coisas fosse traduzida para outras realidades. Principalmente em desenvolvimento de softwares que até esse momento era predominantemente  do jeito Ford com conceito de fábricas de software e encadeamento de atividades (o famigerado cascata – waterfall).

Logo nosso dia a dia de desenvolvedores e gestores de projetos deixou de ser sopas de letrinhas como PMI, CMM, RUP, UML , etc para ser JIT (Just in Time – o justo na hora certa),  KANBAN,  cadeia de valores, etc.

Entretanto, nos últimos anos, notícias de que a Toyota estaria fazendo recalls se tornaram frequentes nos jornais do mundo. Recall é o processo que a empresa chamada todos os usuários (compradores) de um determinado produto a o levarem de volta para consertar algo que possua um defeito de fabricação oriundo de erros de projeto, processo, etc.   por mais transparente e honesto que seja o processo, ele sempre acaba manchando a reputação da empresa… Isso só fica pior quando falamos de uma empresa que “vende” que tudo que faz é perfeito (isso também vem da própria cultura japonesa).  Tais fatos sairam do ambito da economia para entrarem no ambito da gestão, pois  muito se vendeu nos últimos tempos que o processo Ford não funciona e que a salvação era o Sistema Toyota.

Seguidores  estão em panico pois tais fatos colocam em xeque seu grande salvador.  Mas será que realmente que esses acontecimentos são o sinal que esse processo não é tão bom quanto pensávamos? Será que devemos procurar um novo jeito? Será que devemos voltar ao que “funcionava” antes? E agora quem poderá nos ajudar?

Confesso que gostaria de ter essa resposta mas acho que somente o tempo dirá, embora, acredite numa máxima de Buda : ” o caminho sempre será o equilíbrio” . Possívelmente esse seja um processo pelo qual o mercado precise passar para deixar de criar “balas de prata” e passe a usar a inteligencia de seus profissionais para resolver cada problema.  Não existe solução única. Existe é inteligência, criatividade e vontade de evoluir.

Agora tais problemas também podem ser  culpa de um processo mal gerido de crescimento onde os atuais administradores da empresa esteja rompendo com as bases culturais que nortearam a empresa até hoje.  Eu vi um processo semelhante a esse acontecer dentro da michelin com a morte dos herdeiros naturais da empresa.  Por isso, mais uma vez a cautela e prudência são as melhores amigas nesse momento ao analisar os fatos.

Penso que é preciso olhar com a mente aberta aos fatos e se permitir questionar. Fé cega a gente deixa para as religiões.

Vagas para analista java e analista c#

fevereiro 9th, 2010

Pessoal, hoje recebi um email sobre uma vaga de emprega. Não conheço a empresa nem a pessoa que está divulgando, entretanto, como conheço a lista onde ela foi postada, reproduzo aqui para que o pessoal que acompanha o blog possa saber:

Olá Pessoal.

Estou com uma vaga urgente, mas eu não consigo encontrar profissionais no mercado, gostaria muito de pedir a gentileza quem tiver alguns profissionais para me indicar eu ficarei muito grata, ou mesmo encaminhar para a lista de contatos de vocês pedindo que entrem em contato comigo.

Segue abaixo o perfil da minha vaga:

Quantidade: 01 vaga

Perfil: Analista Desenvolvedor C# .Net

Nível: Pleno

Requisitos Indispensáveis: Windows Forms, Web Services, Orientação a Objetos, Oracle.

Requisitos Desejáveis: Conhecimento em Seguro Saúde.

Contrato: PJ hora aberta.

Início: Imediato

Período: projeto de 10 meses com possibilidade de prorrogação.

Local: São Paulo – Morumbi.

Quantidade: 01 vaga

Perfil: Analista Desenvolvedor Java

Nível: Pleno

Requisitos Indispensáveis: Java-Spring, Orientação a Objetos, UML, Oracle, Websphere/WSAD.

Requisitos Desejáveis: Conhecimento em Seguro Saúde.

Contrato: PJ – hora aberta

Início: IMEDIATO

Período: Projeto de 10 meses com possibilidade de prorrogação.

Local: Morumbi – São Paulo

Interessados ou indicações favor encaminhar o currículo para tania@dbsitservices.com.br.

Lumis contrata Analista Desenvolvedor Junior

fevereiro 8th, 2010

Não é algo que eu faça com certa freqüência mas acredito que a vaga seja boa e interessante para muitos que leêm o blog. A empresa é brasileira e tem como atividade principal um produto de portal. Essa ferramenta de portal é muito interessante e concorre em igualdade com outras existentes no mercado ( Vignette, Websphere Portal, Oracle, etc) .

Mande seu CV para lumisit@lumis.com.br , coloque no corpo do email que viu a vaga no meu blog.

Desenvolvedor Junior (Projeto)

Conhecimentos necessários:

  • Estar formado em Ciência de Computação, Engenharia de Computação, Informática ou
    correlatos;
  • Ter 6 meses de experiência de desenvolvimento em projetos Web;
  • Ter conhecimentos nas tecnologias – PHP, ASP e .NET
  • Conhecer os conceitos de orientação a objetos
  • Conhecer Infra-estrutura, configuração e manutenção de servidores Apache e IIS

Conhecimentos desejáveis:

  • Ter conhecimento da linguagem XML, XSLT, SQL e DHTML;
  • Conhecer os bancos de dados: SQL Server 2000/2005, e MySQL.

Habilidade:

  1. Transformar projeto em implementação;
  2. Escrever código fonte em PHP, ASP e .NET;
  3. Avaliar a implementação;
  4. Executar os testes;
  5. Avaliar a execução dos testes;
  6. Depurar problemas no código;
  7. Pesquisar soluções tecnológicas;
  8. Controlar e cumprir prazos de suas tarefas;
  9. Alertar com antecedência sobre problemas;

10.  Comunicar dúvidas ou questões encontradas.

Atividades do Cargo:

Trabalhará alocado Analista/Desenvolvedor, com conhecimento em portais utilizando a plataforma Lumis Portal Suite (ASP). Ter alguma experiência com PHP, ASP e .NET

Estamos trabalhando com pretensão salarial

usando o webdriver para fazer testes de aceitação

janeiro 27th, 2010

A pouco tempo consegui um brecha com ajuda da minha colega Arlene para implantarmos no projeto que estou trabalhando teste automatizados.  Com a carta de alforria em mãos partimos para pesquisar no mercado qual seria a melhor que se encaixaria em nosso contexto de aplicação.  Para que entenda,  trabalhamos com desenvolvimento de portal usando a ferramenta Lumis (eu trabalho na Lumis!!!).  Portais são aplicações bastante difíceis de serem testadas de forma automática; devido a questão do conteúdo dinâmico e pouco previsível não existe muita margem para que busque por padrões.

Com estas limitações em mãos, acabamos nos deparando com a api WebDriver . A um tempo atrás eu já tinha mexido um pouco com o selenium e adorei. Com isso, tentei achar algo que se assemelhasse a ele mas que me facilitasse a vida em relação a portais ( não tem muito como usar ids dos elementos no html, url não fixas, etc) . O webdriver, ao contrário do selenium, não é um javascript que executa dentro de uma página simulando a navegação… o webdriver é realmente um “envelope” em cima do seu navegador.  No caso do Firefox ele é uma extensão, no caso do Internet Explorer (blargh) ele usa as chamadas de control que ele proporciona, e por ai vai. Com isso, os teste ficam mais próximos da realidade de uso do usuário, e a api para escrever  os cenários mais simples.  Veja o trecho:

1
2
3
4
WebDriver driver = new FirefoxDriver();
driver.get("http://localhost:8080/");
HomePage homePage = new HomePage(webDriver);
String valor = homePage.searchFirstItemforMoreRead();
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import java.util.List;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;

public class HomePage  extends Page {
private static final String PAGE_TITLE = "teste";

public HomePage(WebDriver driver){
super(driver,PAGE_TITLE);
}

public AdminPage navegateToAdministration(){
webDriver.navigate().to(this.composeUrl("admin"));
return new AdminPage(webDriver);
}

public String searchOneTextOfDestaque3(){
return this.webDriver.findElement(By.xpath("//div[@class='destaques3']/h5/a")).getText();
}

public String searchFirstItemforMoreRead(){
return this.webDriver.findElement(By.xpath("//div[@class='aba_conteudo ativo']/ol[@class='mais_lidas']/li[@class='item1']/a/span")).getText();
}

public List searchDestaque3Texts(){
return this.webDriver.findElements(By.xpath("//div[@class='destaques3']/h5/a"));
}

}

Pelo exemplo acima fica fácil de ver o quão fácil é criar um teste em webdriver.  Recomendo experimentar

Mais um pouco sobre testes automatizados

janeiro 27th, 2010

Se você é um leitor assíduo do meu blog, já deve ter percebido o quanto gosto de testes automatizados. Não só gosto como acredito neles e no retorno que eles proporcionam. Sempre que tenho a oportunidade procuro “vender esse peixe”. O interessante é que com isso acabei escutando alguns exageros que chegam a ser engraçados.  Um exemplo foi após uma conversa em que até rolou uma  sessão de codificação em par com a pessoa, no final, ela soltou a seguinte pérola :”Agora então não preciso mais do pessoal de teste“.  Opa! Devagar com o andor que o santo é de barro, meu amigo.

Antes que concorde com isso,  deixa eu mostra meu ponto de vista.  Teste automatizados ajudam muito e realmente tornam a vida do desenvolvedor e do cliente melhores.  Torna a vida do desenvolvedor mais fácil quando permite que ele faça seus testes rapidamente e detecte um erro o mais cedo o possível.  Para o cliente significa que a automação mais testes podem ser executados num tempo menor e com isso mais qualidade com menor custo.  Mas e a história do cara de teste, onde entra? Calma.  Para automatizar os testes devemos fazer algumas considerações e escolhas.  Para facilitar o que quero ilustrar, imagine um portal. Portais são aplicações webs muito interessantes, pois a cada acesso o seu comportamento pode mudar e isso não é necessariamente um erro.  Por isso, testes automatizados, em ambientes como estes são bem complicados de serem feitos e levam a gente a fazer algumas “adaptações”. Com isso,  os teste acabam validando parte das coisas e logo, ainda temos a necessidade de uma pessoa testando.  Entretanto, agora, essa pessoa não precisa estar testando tudo e qualquer coisa. Ele pode focar um pouco mais, realizando apenas verificações pontuais.

Outra frase que sempre escuto é a questão do recurso e gastos.  Geralmente quando converso com os gerentes sobre testes – principalmente os ditos PMI – eles quase que instantaneamente dizem que isto é inviável e trabalhoso. Bom, primeiro devemos definir o contexto:  se imaginarmos os famosos “cowboys“, rapaziada que desenvolve a culhão e não teste se o objeto que eles estão pegando é nulo, realmente testes automatizados são trabalhosos, pois não fazem nenhum.  Para aqueles que pretendem o mínimo de qualidade, dá para dizer que, realmente, NO INÍCIO,  testes automatizados demandam mais tempos, mais se olharmos ao longo da linha tempo esse custo se dilui e tende a zero. Isso porque, após todos os casos criados, o trabalho será de executá-los e mantê-los atualizados.  Fora que, imagine o custo de pessoas, máquinas, tempo,  para que a cada alteração que um desenvolvedor fizesse na aplicação, toda ela fosse retestada.

Enfim,  caso ainda não acredite em mim quando digo que ferramentas de testes são legais e estão aí para nos ajudar,  experimente e tire suas próprias conclusões. Duvido, sendo você empresário, gerente pmi, coordenador, desenvolvedor, cliente, etc no final não ficará pelo menos tentado a usar algum no seu próximo projeto.

O bom, o feio e o mal em desenvolvimento – parte 2 – revisores e arquitetos?

janeiro 14th, 2010

E dando seguimento a serie sobre algumas coisas interessantes sobre o desenvolvimento, vamos para mais um novo capítulo.  [OFF] São tantas histórias vou acabar escrevendo um romance [/OFF].   Após a repercussão do primeiro artigo de mesmo nome, alguns conhecidos me procuraram para dizer que, existiam outras situações que poderia abordar dentro da série.  Uma dessas situações foi sobre estruturas de equipes de desenvolvimento e  com isso, acabei  me lembrando de uma época,  numa dada empresa, em que tínhamos a figura do revisor de códigos. É isso mesmo que você leu, meu amigo …revisor de código.

O revisor de código é o cara que após você ter implementado toda  a solução, antes de você colocar as sua alterações no CVS  (meu deus, antigo), ele vem e verifica se o seu código está bom, onde bom, significa dentro de um padrão que não está em lugar que não na cabeça dele.  Antes que me apedrejem em praça pública,  sei que nem todos são assim, e que em muitos tinha ou tem, regras de estilo bem claras e até automatizadas através de plugins em suas IDEs.

Revisar o código não é uma atividade ruim. Ter premissas de estilo e formatação é algo interessante pois padroniza e pode facilitar qualquer pessoa, que esteja acostumado com os padrões da empresa, ler o fonte e entender.  Essa preocupação, inclusive,  tem sido tema de discussões muito atuais e serve até de argumento para definir o uso ou não de linguagens ( sendo mais específico, são questões como expressividade, legibilidade, etc – suggar sintaxe) . A questão que eu coloco é isso passar o limite do bom senso e do razoável e se tornar uma ditadura sem direito de questionamento.

A própria situação de ter uma única pessoa responsável por zelar pela qualidade do código para mim já é algo péssimo.

Mas então? Qual é o melhor cenário?  O que pode ser feito, já que eu disse que qualidade e estilo são bons, se ter alguém revisando é péssimo?

Alguém aí, por acaso, disse … Programação em par!?!?!? Bingo!!!   Essa, no meu entender, é um bom caminho.  É bom, pois permite a troca, a interação. É bom, pois permite, que a responsabilidade seja de todos e não somente de uma única pessoa. Tira gargalos ( quem nunca ficou parada esperando o revisor ter tempo para ver e validar a implementação).  O time como um todo decide o que é melhor.

Nesse cenário as chances das coisas serem menos impostas e mais consenso são grandes. Não existe um ponto único e sim diversidade de visões.  O time fica aberto e sempre como abertura para melhorar ou experimentar, desde que todos concordem ou pelo menos seu par, que aquilo traz algum valor.

Observem – bem lembrado por um colega – que nem toquei no fato de revisão de tecnologia, arquitetura.  Na velhas e empoeiradas estruturas de fábrica,  tem casos em que além do revisor, tem ainda o grande e todo poderoso arquiteto que decide quais tabelas, quantas classes, como as classes são, qual linguagem, api, framework, qual papel higiênico, que  todos devem usar.  Para mim isso consegue ser pior que o revisor. Pois ele tolhe a inovação, o salto para frente.  não quero dizer com isso, que devemos fazer de nossos projetos um laboratório de novas linguagens e etc… estou dizendo que se existe algo que venha a facilitar porque não pelo menos olhar o que é …

Novamente transferir essa “responsabilidade ” para o time é a melhor coisa.  Pois se discute. Todos tem voz.  A chance de escolher algo interessante é maior… não fica a cargo de um louco que pode ser um tarado por novidades ou um louco que nunca deixará de usar Java 1.3.1 pois sempre funcionou e “não se mexe em time que está ganhando”.

Bem esse era meu recado… aguardo as opiniões de vocês.

Bases de Conhecimento

janeiro 13th, 2010

Hoje, na hora do almoço, tive uma conversa super legal com um colega do trabalho. Conversamos sobre a questão do conhecimento e como ele poderia ser difundido dentro da empresa.  o assunto surgiu do fato de termos identificado que muitas empresas por onde passamos de diferentes tamanhos cometeram o erro de não cuidar da “circulação” da inteligência coletiva da equipe.

Tenho certeza que a maioria que está lendo esse artigo agora tem um exemplo de algum projeto que várias soluções foram adotadas, usadas, criadas, etc e por alguma razão obscura não foram documentadas.  Daí um tempo depois um outro projeto precisa de algo parecido e ninguém lembra mais como foi feito aquela implementação e por fim, todos acabam salvos por algum tarado que guardou o código e lembrava de onde estava aquele algoritmo na montanha de classes. Exageros a parte, isso é um dos sintomas do problema que gostaria de conversar com vocês sobre.

Poucos times de desenvolvimento, pelo menos que eu conheço ou ouço falar – fora open source – tem um cuidado em manter o conhecimento. Manter conhecimento significa guardar esse aprendizado de alguma forma que permita que no futuro ele  esteja disponível e facilmente seja encontrado.  Quem pensou em base de conhecimento, acertou em cheio. Estou falando exatamente nisso.  Em tempos que a rotatividade dos profissionais nos locais e projetos é alta, guardar o conhecimento e “organizá-lo” tornou-se o diferencial, “o pulo do gato” !.  Os franceses tem uma excelente expressão para isso : “Savoir faire”…

Para fazer isso não precisa necessariamente ter uma mega ferramenta, com recursos mágicos e inteligência artificial. Podemos começar simples.  Um bom primeiro passo seria até mesmo um arquivo texto.

Antes que nossos colegas gerentes pensem que essa é mais uma oportunidade para desperdiçar seus valiosos recursos (odeio esse termo), os ganhos são grandes demais para ignorá-los.  Ao ter uma boa base de conhecimento a curva de produtividade de um novo membro é rápida; o cara novo “pertuba” menos os demais; etc.

Bem depois eu volto no assunto. Aguardo o comentários de vocês para enriquecer.

Objetos trocam mensagens

janeiro 12th, 2010

Mais uma vez, devido a uma outra troca de e-mails,  vi um outro assunto super legal que gostaria de dividir com vocês.  A um certo tempo atrás, no blog do Calcado, li um artigo sobre o fato de objetos não serem atributos + funções. Neste artigo, o Calcado, mostra que os objetos ao invés de possuírem atributos e funções, eles na verdade possuem estados e comportamentos.  Reproduzindo um trecho do artigo :

Objetos não possuem propriedades + funções, eles possuemestado + comportamento. Você provavelmente vai usar atributos (i.e. variáveis de instancia) e funções (de instancia também) para implementar isso mas é um detalhe de implementação, não algo que deva ser exposto [sic]

Uma outra coisa que penso é que além disso que ele comentou, uma outra dificuldade que vejo no pessoal que está “montando” a arquitetura de sistemas, é definir como será a interação entre objetos.  Quem nunca ficou horas pensando onde colocar determinado método – “o método calcular preço  é da loja ou do produto?“; nome do método,  se deveria expor dados por get e set, etc .  Essa dúvidas vem da nossa visão equivocada da troca de dados entre objetos.

Se considerarmos que objetos não possuem métodos ou funções( função me parece tão modular e não OO) e sim “portas de entradas”.   Essas portas são como caixas de correio por onde enviamos e/ou recebemos mensagens com pedidos ou informações.  Para ficar mais fácil de entender,  imaginemos a situação de uma grande rede de lojas.  Esse grande rede possui diversas lojas, que possuem diversos produtos e clientes.  De cara, podemos dizer que temos 3 entidades :  Cliente, Produto e Loja.

Agora a pergunta: como você implementaria a lógica de obter preço – o cliente vai na loja, pega um produto e quer saber o preço.  Tenho certeza que alguns diriam que colocariam um método getPreco na classe de produto.  Outros fariam um PrecoControlador que pegaria o custo do produto e faria a operação de cálculo pegando a margem de lucro da loja, custo da loja e por seguiria…. Outros inventariam a classe preço que diante a loja e produto se calcularia….  De novo fazendo assim ainda estamos pensando em objetos como conjunto de funções e atributos e esquecendo da troca de mensagens.

Uma forma que vejo mais simples e mais expressiva de fazer (logo fica mais claro para entender o sistema) seria de perguntar para a loja o preço. Sendo assim, o cliente teria um produto e perguntaria a loja o preço. A loja consulta sua tabela de preço e responde.

Cliente  – pega produto —  > Produto

Cliente — informa o produto a loja –> Loja

Loja — consulta tabela –> Tabela

Loja — responde ao cliente –>

Fica bem elegante não… Mas se ainda não conseguiu ver:

class Andre  extends Cliente

Produto lapis = new Lapis();

double preco = lojaAbobrinha.qualEhOPreco(lapis);

..

Abobrinha extends Loja

double qualEhOPreco(Produto produto)

minhaTabelaPreco.qualPrecoAtual(produto);

Quem for fazer a manutenção do código,  só de ler, já começa a entender oque está acontecendo e começa deduzir as demais interações.

algumas considerações sobre o mercado

janeiro 12th, 2010

A um tempo atrás uma empresa entrou em contato comigo para que eu os ajudassem num projeto deles. Para este projeto, dada a dificuldade deles em encontrar bons profissionais no mercado do rio de janeiro, eu teria a responsabilidade de montar a equipe ( recrutar e treinar – caso necessário) ,  gerir o desenvolvimento da ferramenta e ainda dar suporte posterior.  eu fiquei um bom tempo pensando na proposta e depois que as coisas não foram para frente me senti tentado a contar a história e aproveitar para passar algumas visões minhas.

A primeira coisa que me chamou muito a atenção na conversa que tive com o pessoal da empresa, foi o discurso deles de que não conseguiam contratar bons profissionais no rio de janeiro (inclusive eles iriam se mudar para outra cidade em função disso).  Eu discordo disso. Existem excelentes profissionais aqui, como em qualquer outro lugar. A questão é ver qual era o perfil que eles estavam buscando e a remuneração que ofereciam.  Uma coisa que aprendi com meu pai e com meu tio Luiz é que coisa boa é cara.  Pode parecer loucura ou até presunção da minha parte, mas concordo com isso.  Se quer um profissional que faça o “feijão com arroz” tem que estar disposto a pagar o “feijão com arroz”; agora se quer o melhor você tem que estar disposto a pagar pelo melhor.  Não estou dizendo que eles não pagavam bem até porque nunca soube os valores que eles pretendiam.  Outro ponto é o perfil: vem acontecendo uma transformação nos profissionais do rio que aos poucos vão fugindo do padrão e com isso, para que os não se atualizam e vivem com os olhos tapados, parece que não existem profissionais bons.  Os bons do Rio, estão fazendo coisas muito interessantes mas não usam terno, entendeu :D

Não adianta vir aqui e dizer que não tem cara bom se você quer obter os melhores buscando no refugo e pagando salário de estagiário. (Peguei pesado mas é isso mesmo) .

Outro aspecto da conversa com eles foi a visão ainda de fábrica de softwares deles. Confesso que na hora que ouvi isso levei um susto. FÁBRICA DE SOFTWARE !!!  Isso não.   Não sei quanto a vocês, mas não consigo mais me ver ou compreender a razão para um modelo de fabrica de software.  Eu realmente acredito no poder dos times. No poder dos pequenos e coesos times.  Essa coisa de quebrar em etapas, e um escreve a primeira letra e outro coloca o ponto e vírgula,  já foi ! Todos devem fazer tudo e mexer em tudo. Nada de especialista de porcas, especialistas de parafusos, etc.

Não consigo mais ver vantagem na multidão.  Hoje, se fosse montar uma equipe, e tivesse o recurso necessário, montaria uma equipe pequena, com bons skills e super coesa.  Não estou dizendo que só escolheria gênios. Muito pelo contrário, escolheria pela afinidade,  pela vontade de fazer algo melhor, pela disposição, e outros fatores afins.  E faria de tudo para a equipe se manter do mesmo jeito e pequena. Nada de crescimento.  Com certeza a comunicação iria fluir muito bem; os projetos iriam sair com qualidade;  tudo iria funcionar como um “relógio” não porque existem gênios mas porque o time é unido, coeso e a famosa história do conjunto ser melhor que a soma dos indivíduos.

Por fim quero deixar algumas conclusões:  [1] Existem bons profissionais em qualquer lugar. Pode ser que esteja procurando errado.  Realinhe seu foco, procure entender o mercado e retome as buscas; [2] Para se ter o melhor, você tem que estar disposto a dar o melhor – isso implica é muito mais coisa que salário; [3] Times pequenos são melhores que multidões. A força está no entrosamento. é muito mais difícil obter coesão de conjuntos enormes.  Se o projeto é grande, quebre-o em muitos pequenos times independentes e verá que será melhor.  [4] É preciso acompanhar as mudanças do mercado até mesmo para contratar.  Os perfis são outros e com isso as empresas tem que se adaptar.

Bem é isso. Aguardo o comentário de vocês. Até o próximo !!!

O bom, o feio e o mal em desenvolvimento – parte 1 – testes automatizados

janeiro 11th, 2010
Conversando com um colega do trabalho, discutíamos sobre a questão dos testes automatizados. Confesso, que nessa altura dos acontecimentos de TI, esse assunto estaria mais que esgotado, porém para minha surpresa, existe gente que ainda insiste dizer que é “perda de tempo” e outros termos menos lisonjeiros.
Esse colega me contou de um projeto onde existiam diversos problemas e que o cliente estava bastante insastifeito, entre outras coisas, com a qualidade das entregas. Isso porque, segundo o próprio cliente, várias vezes as alterações feitas ocasionavame na quebra de funcionamento em outras partes que aparentemente não tinham relação com a mudança pedida.
Quem um dia já trabalho com portais, por exemplo, sabe a encrenca que isso é: páginas, conteúdo dinâmico, caches primários e secundários, gestão de conteúdo instâncias de serviços, etc. Com isso, o entrelaçamento das coisas  é enorme e qualquer alteração implica, considerando situação ideal, no teste de todo o portal. Testar o portal inteiro significa, para uma pessoa, horas e até dias de trabalho (se considerarmos portais de notícias como o G1 e o R7). Agora imagina testar todo o portal a cada commit que for feito… impossível né! não quando automatizamos nossos testes ao invés de delegar isso para uma pessoa.
Antes que comecem o apedrejamento em praça pública de minha pessoa, não estou dizendo para demitir toda a sua equipe de testes (os famosos homologadores). Estou dizendo que as coisas podem ser feitas com um pouco mais de inteligência e maior valor agregado para o cliente.
Voltando a história do meu amigo, devido a questões de negócio, optaram por não “gastar” tempo em criar testes automatizados e o cliente se prontificou em testar tudo que era feito através de sua equipe interna de testadores profissionais. Nem preciso dizer que esta é a raiz da insatisfação do cliente com o quesito qualidade do projeto. Fazendo uso de um ditado popular : “Cão com muito dono ou nenhum, morre de fome de sede” .
Nessa história, quem tomava a decisão estava com uma visão antiga e com prazo de validade vencido sobre a questão de testes. Eles realmente acreditaram ( e acreditam – daqui a pouco chego lá) que investir em automatizar testes é custo e não investimento.  Esqueceram de considerar a qualidade… pensaram somente que precisavam colocar no ar o mais rápido o possível o sistema e os “fins justificariam os meios empregados”. Eles já estão pagando o preço pela péssima escolha, mas como todo “cego opcional” eles, pasmem vocês, não querem que “percamos” tempo em fazer esses bobeiras e culpam os desenvolvedores de todos os erros chamando-nos de incompetentes.
A minha resposta para este conhecido foi simples: mude de emprego. Faltou alguém de visão no projeto para entender que teste nunca é demais. Testes automatizados são um ganho e não perda de tempo. Vejam que nem estou falando em TDD, estou apenas considerando os testes !!!!
Quando “cercamos” nossas as aplicações testes, no mínimo estamos tentando protejar a consistencia da aplicação, evitando que mudanças quebrem-na. Claro que esse testes poderiam ser feitos por uma pessoa, mas imagine o custo (dinheiro mesmo !!!! tempo!!!) para que isso fosse feito num tempo hábil e com um retorno rápido para o desenvolvedor… Teste automatizados garantem isso. Sua aplicação pode ser testado o tempo todo e com isso, mesmo pequenas alterações levam a testar o todo verificando se a integridade não foi quebrada.
Isso, apesar de no começo representar mais trabalho, no final, gera um valor agregado imenso pois as coisas são entregues quando realmente estão prontas e com uma qualidade minima. Caso ainda queiram passar pela equipe de homologação, essa ficará livre para testar os requisitos e não se campo numérico aceita string.
Na literatura corrente, e por isso não foi me extender mais, existem diversos livros, artigos, blogs, textos, twitter, etc mostrando e provando porque devemos usar testes automatizados. Porém, me assusta o fato de ainda existirem gerentes, diretores e donos de empresa que consideram isso perda de tempo. Para estes a previsão é sombria. O mercado está aquecido por isso qualquer “bundão” consegue vender algo. Haverá um momento de retração e nova expansão e aí, somente quem estiver pronto, ágil e preparado sobreviverá… e não acredito que esses caras que eu citei estarão preparados.
Bem isso, até a próxima.