Arquivo da tag: Qualidade

Lançamento: Giran Soluções e Ensino

Pessoal, é com uma enorme satisfação que escrevo este post e comunico a vocês o lançamento oficial da minha empresa junto com meu grande amigo-irmão-parceiro e agora sócio, Léo Hackin, e claro, com a participação incondicional e incansável da minha adorada esposa que, literalmente, tirou a coisa da informalidade e ‘nos deu asas’.

A empresa já está registrada há algum tempinho e, também, em atividade. Porém, hoje está sendo o seu lançamento oficial, basicamente com a marca e o site temporário pois a sede ainda está em fase final da reforma da sala e o site em ajustes finais para ir ao ar, muito em breve escreverei sobre a sede e como ela ficou.

Há algum tempo, muita gente não entendeu o meu pedido de saída da globo.com, mesmo tendo eu, acabado de entrar. O principal motivo que me trouxe de volta a Vitória foi exclusivamente pessoal e particular, não cabem comentários aqui no blog. Com o retorno, aproveitei o tempo ocioso e dei início ao trabalho que era também um sonho antigo, assim como entrar na globo.com, e agora o sonho saiu do papel e, literalmente, caiu no mundo real.

Giran Soluções e Ensino

giran_mini1Giran é o nome da nossa empresa. Durante quase 2 meses nós procuramos um nome, inventamos códigos e nomes estranhos, nomes ao contrário, nomes em japonês, em chinês, enfim, tentamos de um todo, mas nenhum deles tinha o domínio livre. Apesar de se tratar do nosso lado profissional e de ser agora a nossa cara, nossa marca e identidade ‘na rua’, o nome é algo muito especial, e não poderia deixar de ser algo nerd, afinal somos nerds. Darei uma pista e quem descobrir a origem do nome ganhará o direito de disputar uma partida de xbox na nossa nova sede; a dica: é um nome retirado de um rpg, mais especificamente de um mmorpg!

Conheça: Giran Soluções e Ensino

Na Giran o nosso foco de trabalho serão contratos de consultoria e coaching em projetos java e rails, gerenciamento de projetos com Scrum e, também, ensino e treinamento especializados em java, php e rails. Quando o site estiver no ar muitas outras informações e detalhes sobre nossa área de atuação serão disponibilizadas.

A criação e lançamento da Giran ocorreu, antes de tudo, após uma longa conversa sobre valores, princípios, visão e expectativas para a empresa e sobre como faríamos para criar e manter uma empresa jovem e descontraída e ao mesmo tempo profissional e comprometida. Nós não poderíamos simplesmente abrir uma outra ‘old big company’ baseada em velhas e obsoletas idéias e trabalhar de forma caótica e improdutiva, na nossa empresa usaremos o que há de ponta para o desenvolvimento e gestão dos nossos projetos e treinamentos, estudaremos cada caso com o máximo de detalhes, cada cliente, cada projeto afim de aplicar o que for melhor para cada situação, exatamente igual fazemos em nosso dia-a-dia e em nossa evolução pessoal+profissional.

Na Giran todo o nosso trabalho será pautado e muito fortemente baseado nos valores e princípios de Extreme Programming, especialmente em alguns que temos uma certa predileção:

  • Respeito – Pois este é a base para todos os outros valores e princípios, é o motivo pelo qual nascemos e pelo qual prosperaremos.
  • Coragem – Não seremos reativos à mudanças, não cortaremos a nossa criatividade e de nossos funcionários. Lidaremos com o risco de forma aberta, transparente e responsável; e erraremos o quanto for preciso para chegar o mais próximo possível da perfeição e continuar sempre no caminho da evolução e da melhoria contínua.
  • Simplicidade – Seremos pragmáticos, sempre! Não queremos fazer mais do que a concorrência, não queremos fazer o desnecessário, não queremos ser ‘grande e flácido’, nós queremos resolver o seu problema.
  • Comunicação – Somos emocionais, queremos olhar nos seus olhos, conversar e sentir as suas emoções, tom de voz, expressões faciais, gestos e postura, não vamos trocar uma visita por um e-mail ou telefonema.
  • Qualidade – Não pode haver desperdício. Não pode haver software ruim ou de má qualidade. Prezamos fortemente pelo código que escrevemos e sabemos que ele é o nosso produto, não se trata de nível de qualidade, o objetivo é a altíssima qualidade, e é isso que importa.

Outro ponto de grande realização para nós com a abertura da Giran é poder participar e atuar de uma forma ainda mais forte e ativa no desenvolvimento de projetos open source e nos grupos e comunidades da nossa região. Poder agora, como empresa, dedicar tempo remunerado a estes projetos, incentivar e bancar a participação dos nossos funcionários, poder viabilizar eventos e outras atividades e muito mais. Hoje nós já participamos fortemente como membros e coordenadores no ESJUG, Agile-ES, PHP-ES, Linux-ES e EESL e estamos iniciando a participação no Vitória Perl Mongers.

E é isso, agora é correr atrás e tentar aplicar tudo que eu disse para meus antigos chefes/gerentes e ver, na prática, se será bom ou ruim, fácil ou difícil, lucrativo ou não e por aí vai. Agora o sonho acabou, virou realidade!

E a qualidade, como você garante?

Durante minhas apresentações sobre Testes de Software existem algumas perguntas que são clássicas, sempre fazem no mínimo uma delas. Por exemplo:

  • Mas com testes, demora mais?
  • E se demora mais, não fica mais caro?
  • E se demora mais e fica mais caro, por que testar?
  • Como eu vou mostrar para o meu cliente um relatório de execução de testes? Pirou!?

Pra quase todas eu respondo sim. Sim, simplesmente escrevendo testes ou trabalhando com TDD/BDD é um pouco mais demorado (medindo exclusivamente em tempo) sim, principalmente no começo de um projeto. Podemos pensar que se demora mais, inicialmente, também fica mais caro, afinal de contas, tempo é dinheiro. Mas depois deste movimento inicial e saindo da inércia o fator de tempo se inverte e o desenvolvimento no projeto torna-se mais rápido e mais barato. Assim como a manutenção do projeto.

Após responder sim para esses questionamentos, intencionalmente, eu inicio a discussão com uma pergunta, desta vez sou eu quem pergunto ao congressista: Como você garante a qualidade do seu produto?

Eis que então abro as portas para chegar no ponto principal desta apresentação sobre Testes de Software, conscientizar as pessoas de que é necessário testar, pois, esta é a forma menos dolorosa para mantermos não só a qualidade, mas também a vida dos nossos produtos. Mesmo assim eu sempre tomo cuidado para não vender a idéia de que testes são a solução pra tudo, muito menos que pelo simples fato de escrever testes para todas as funcionalidades do seu sistema que ele não terá bugs ou problemas, muito pelo contrário. Mas então por que testar? Pois até hoje, testar é a forma mais barata e eficiente que encontramos para evitar que os problemas cheguem ao cliente/usuário. Eis então aí a qualidade do seu produto. E quando eu deixo de falar em “testes” para falar de “qualidade” eu consigo a atenção de todos, inclusive de quem não irá escrever testes, mas quem decidirá se o desenvolvedor terá espaço para escrever testes ou não, os gestores/líderes.

Geralmente quando você não escreve testes qual é a forma utilizada para garantir que o que será entregue ao cliente está funcionando de acordo com o que foi especificado (comportamento)? Não sabe responder!? Bom, então como você faz para garantir que o produto ao menos funciona, esqueça aqui o modelo de negócios, as telas ao menos abrem? O usuário não vai receber nenhuma NullPointerException na cara? Também não sabe responder!? Não tem segurança para responder!? Não fique triste, infelizmente tem muita gente na mesma situação que a sua.

Na maioria das vezes os projetos de software começam com funcionalidades e datas de entrega pré-definidas, contratos rígidos, multas astronômicas, e o pior, fases pré-definidas: requisitos de sistemas, requisitos de software, análise, design, codificação, testes e implantação. Acho que não preciso falar muito do modelo em cascata, o que todos sabemos é que as fases iniciais sempre são feitas pelos “analistas de sistemas” da empresa, na maior moleza gastando mais da metade do tempo e verba do projeto sem gerar nada de útil para o desenvolvimento. O que acontece? Os desenvolvedores simplesmente chutarão os testes (e muitas outras coisas) pois: – não temos tempo agora; – depois eu testo; – a entrega é daqui a 15 dias; – está funcionando sem testes. E o pior, tentarão justificar a ausência de testes devido a este modelo cultural e organizacional falho.

Então o projeto, de fato, começa. Mas e os releases, como ficam? Como você garante que o que será entregue ao seu cliente está funcionando? E que está atendendo a tudo que ele especificou? (estou me repetindo, eu sei, mas é por uma boa causa). Melhor, se sua equipe trabalhou na correção de um bug ou na implementação de uma nova feature, como você garante que o que foi feito está ok e que todo o restante continua funcionando como antes? Certamente o seu cliente não espera que você entregue um relatório de execução da sua suite de testes, mas ele também não espera que você entregue um certificado de garantia ou algo parecido, ele simplesmente confia em você e espera que você faça por merecer.

E você no começo faz questão de parar um desenvolvedor ou analista para testar a funcionalidade que está sendo desenvolvida, ele executa a aplicação, faz um caso que funciona e outro que não funciona, te responde ok em cerca de 45 minutos. Passam-se alguns dias e já existem 5 funcionalidades, o mesmo desenvolvedor vai testar e te da ok em cerca de 4 horas ou mais. Mais algumas semanas e ele já não testa mais todos os casos, só os que funcionam e eventualmente pula uma ou outra funcionalidade pra terminar os testes mais rapidamente, depois de 3 dias ou mais ele te da o ok. Imagine depois que o sistema estiver grande (é mania das empresas querer fazer sistemas gigantes), você vai parar um desenvolvedor por duas semanas ou mais para testar? Ou você vai manter uma equipe de “testadores”? E como você vai explicar as regras de negócio de um sistema de controle de transações comerciais para 5 ou 6 novos funcionários para depois testarem o seu produto? Será que eles saberão o que fazer e como fazer? Pense em muitos problemas aqui.

Essa prática é demorada. Se acontecer (e vai acontecer) um problema seríssimo em produção e você precisar corrigir e entregar rápido, no mesmo dia, como você vai fazer para testar todo o resto do sistema em algumas horas? Certamente você vai pensar (e rezar) que esta alteração foi pontual e que não afetará mais nada no sistema e vai entregar sem testar. Se as novas solicitações forem de features pequenas você não vai querer testar todo o sistema, não vai se preocupar em fazer um teste de regressão, e vai, novamente, rezar e fazer promessas acreditando nos poderes sobrenaturais dos seus desenvolvedores. E o pior é que se alguma vez isso funcionar, esta poderá se tornar uma prática comum na empresa: alterou; compilou? Então está pronto, pode entregar ao cliente.

Se você precisar economizar ou cortar custos, a primeira equipe a dançar será a de “testadores” ou se ela não existir, será o tempo gasto pelo desenvolvedor que fazia os testes manuais. E com isso você não cortará somente custos, nesta altura do campeonato este é o seu menor problema, ou deveria ser a sua menor preocupação, você estará cortando diretamente a qualidade do seu produto! E sem qualidade a confiança que o seu cliente tem em você começará a diminuir, a imagem da sua empresa junto ao cliente começará a perder o brilho e num determinado momento o cliente se dará conta que você entregou o produto em 4 meses e está a 2 anos tentando deixá-lo totalmente funcional, sem muito sucesso.

Não são somente os testes automatizados que irão garantir a qualidade do seu produto, você tem outras alternativas e a mais conhecida são os testes manuais feitos pelo desenvolvedor ou por sua equipe de testadores, porém esta não é uma alternativa barata e nem rápida, isso não é sustentável ao longo da vida de um projeto.

Se você e seu cliente não se importam em esperar 15 dias para uma release sair, tudo bem, não escreva testes; se você não se importa com o alto custo de manter uma dúzia de pessoas para preencher campos e dar ok, tudo bem, continue sem testes; se o seu cliente te paga 5 vezes mais para fazer o produto funcionar do que o ele pagou para ter o produto, tudo bem também, continue sem testes; ou se os seus desenvolvedores são especiais e possuem poderes além da nossa compreensão e isto permite que você não teste, ótimo, você é um sortudo, pode continuar assim. Se alguma forma sem testes automatizados funciona pra você e você consegue garantir qualidade assim e ainda consegue ser uma organização lucrativa, sorte a sua (e coitado do seu cliente). Só que as coisas nem sempre são assim.

Você deve verificar o seu código, sempre! Você deve testar rápido, pois precisa entregar rápido. Você deve ter segurança para alterar, pois sua equipe pode ser nova ou com pessoas que não conhecem o projeto. Você precisa testar tudo o que foi alterado e todo o resto para saber se algo não deixou de funcionar com alguma alteração. E você precisa fazer tudo isso pra ontem, afinal, você está no mesmo planeta que o resto das pessoas.

Se no início do projeto você tivesse feito o que era necessário, se tivesse investido em testes e automatizado todos eles, após a entrega do produto você poderia dedicar os próximos 2 anos que iria passar dando manutenção em código legado (lembre-se que código sem testes já nasce legado) prospectando novos clientes e projetos. Se aqueles minutinhos para escrever os testes não tivessem sido cortados, hoje, quando o produto tiver milhões de linhas de código e centenas de funcionalidades, após uma alteração qualquer, feita por um estagiário que chegou ontem e nem conhece o produto, você conseguirá saber em questão de minutos (ou no máximo horas) o resultado e impacto desta alteração, com um simples click você saberá se pode entregar a release para o cliente, ou não.

Ao final do projeto, sim, este projeto terá um fim e será concluído de verdade, aquele tempinho que parecia estar sendo perdido com testes, pensando que testar uma funcionalidade antes mesmo dela existir é coisa de maluco, pensando que o melhor a se fazer é correr e correr e correr pra entregar logo qualquer coisa ao cliente, tudo isso vai se converter num ganho inestimável para sua organização, você poderá desenvolver novas features, trabalhar em outros projetos ou clientes, movimentar as pessoas entre as equipes, contratar gente nova e inseri-los rapidamente no ‘ritmo’ de trabalho, e o melhor de tudo, o seu cliente manterá a confiança em você, na sua organização e no seu trabalho.

Então, Assim eu termino a discussão: – É mais rápido entregar um produto em 3 meses e levar mais 24 meses ajustando-o para o tornar funcional ou é mais rápido entregá-lo em 4 meses? Ou entregá-lo em 3 meses com menos funcionalidades? – É mais barato arriscar a imagem e confiabilidade da sua organização entregando algo sem qualidade ou é mais barato escrever e automatizar testes?