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.

Histórias Técnicas – eles devem estar no backlog?

janeiro 21st, 2010

Jack Milusnk, em seu blog The Agile Buddy Blog, escreveu um excelente post sobre a questão da histórica técnica. Em tomei a liberdade de escrever uma versão (não tradução) em português do texto. Para quem quiser ler o texto original, acesso o post aqui. Comentários com ajuda na tradução e opiniões são bem vindo.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>
A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog.
Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:
“O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”
Então, qual é a resposta correta?
Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.
Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:
Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog. Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:”O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”Então, qual é a resposta correta? Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Sprint Day para fazer o site do PythonCampus

janeiro 20th, 2010

Hoje, o pessoal da pythonOnRio, #horaextra, dojoRio, e muitos outros se encontraram na Myfreecomm para fazermos um Sprint Day para fazermos o site do PythonCampus. O PythonCampus é uma iniciativa da galera de levar uma caravana de pessoas apaixonadas por tecnologia para as universidades para mostrar que é possível transformar a paixão por tecnologia em uma carreira de sucesso.

Essa iniciativa vem desde do ano passado e já percorreu diversas entidades no rio e em outras cidades, sendo um sucesso por onde passa.  Mas sempre sentíamos falta de termos um canal de comunicação, mais precisamente, um site.  Um site onde pudéssemos colocar mais informações sobre essa galera, oque fazemos, como fazemos, como nos contactar, página de eventos, etc.  Tudo isso começa a se tornar possível graças a um dia como hoje.

Nesse dia, várias pessoas se juntaram no escritório da MyFreeComm, no rio de janeiro, em pleno feriado com dia ensolarado e com céu azul, para fazer um sprint de um dia onde o objetivo era fazer o máximo possível para colocar um site para a nossa comunidade no ar.

O primeiro desafio vou descobrir o que fazer. Henrique Bastos orquestrou os trabalhos e durante toda a manhã, promoveu brainstorms, backlog plaining, e outras coisas tão interessante quanto.  Apesar de termos demorado um pouco mais do que eu gostaria, o resultado não poderia ser melhor: começamos nossa tarde com um backlog muito bem definido, como a ideia geral do que queremos para o site e com todos os integrantes vibrando na mesma frequência.

Terminado nossa reunião partimos direto para colocarmos as coisas em prática.  Alguns estavam incrédulos quanto ao fato de conseguirmos entregar o site funcional em apenas um dia.  E foi exatamente isso que aconteceu.

Em breve coloco os links para as fotos do making off.     E para quem duvidou : pythoncampus.org

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.