rvf, software e mitos

Depois de um tempo sem postar (puderas, semanas de finalização de versões, instalações e suporte ao teste lá no trabalho, sim, tudo isso em paralelo e não necessariamente se referem ao mesmo projeto. Já disse que começou a faculdade?), venho deixar uma lembrança aos dois ou três (obrigado mãe!) navegantes que tenho por aqui: Sabe aqueles projetinhos simples, que seu chefe tirou lá do fundo do baú, que ninguém queria fazer e você foi o felizardo em “matar no peito”? É dele que quero falar hoje.

Quando você está envolvido num novo projeto, principalmente nas vezes em que você responderá pela arquitetura do mesmo, te vem na cabeça milhares de idéias que –a principio- estão fora do escopo do mesmo (e do cliente), em conjunto com as idéias, surge uma nuvem de frameworks na sua mente, e o tesão de integrá-los, utilizando o maior numero possível de jars, preferindo a escolha de um framework de validação para o “isBlank” (créditos ao Alex) ao invés de implementar a droga do método e, de quebra, tudo isso bombando com aspectos e injeções de dependências na testa. Pense sobre isso, e reflita: Você precisa disso tudo? Você vai precisar daquela coisa que você fez apenas para “SE UM DIA…” mesmo? Não e não!

Projetos simples devem ficar simples. Quanto mais simples ele ficar, melhor pra você, pro seu cliente e para o futuro desenvolvedor que irá dar manutenção no mesmo, pois não precisará aprender aquele bolo de tecnologias que você pensou em empurrar no seu projeto. Faça uso de ferramentas que vieram para facilitar, desde frameworks para desenvolvimento rápido e ágil: Grails, Django, Rails, .. até mesmo as boas e velhas IDEs, como o NetBeans, que já gera uma aplicação JSF a partir de entidades JPA, completinha e bonitinha. Dentre várias outras opções. Keep It Simple, Stupid!

Anúncios

Antes de falar sobre este assunto, vamos lembrar o significado da palavra ignorância, que não necessariamente significa que o ignorante é BURRO, pois este problema se cura com a informação, mas o pior ignorante é aquele que boicota sugestões, opiniões, etc. Ao pé da letra, ignora a informação.

Estimativas de itens no processo de desenvolvimento de software, costumam ser algo que não se tem receita definida, senão a própria experiência do desenvolvedor. Metodologias ágeis introduzem algumas orientações para se fazer isso, mas ainda assim não há mágica, a métrica normalmente vem da média anterior x complexidade de cada caso –e da competência de cada um-.

Estimar bugs não faz parte do cotidiano do desenvolvedor moderno, do homem sem defeitos. O problema é que muitos esquecem que são seres humanos, e que certamente, terão que alterar casos de uso, discutir com o analista de negócios, cliente, refatorar, testar e refatorar novamente item por item, bug por bug. E, sim, imprevistos irão aparecer, e eles devem ser considerados dentro da iteração.

Mas como eu vou estimar algo que não é certo que vai aparecer? O segundo parágrafo responde novamente esta questão. O importante aqui é: Sim, você deve considerar o tempo gasto com imprevistos dentro do seu item. Nem que considerar este tempo signifique separar tempo para prever a criação de uma nova estória para um futuro conserto em uma futura iteração, mas isso valerá com base no que você espera entregar ao fim da iteração, e normalmente algo indefinido/com defeito não faz parte deste plano. Lembrem-se: estimativas andam lado a lado com o cronograma e, por motivos óbvios, a idéia do cronograma não é atrasar. Se o cronograma da vez está apto a responder por 100 horas de itens, é mais fácil incluir 4 itens de 25 horas com testes, refatorações e correções de imprevistos inclusos na estimativa, do que incluir 5 itens de 20 horas, sendo necessário atrasar o cronograma ou pior, remover um item do mesmo para entregar.

Mas, se mesmo assim, esta estimativa imprevista sobrar? Há tanta coisa que você pode fazer se ficar idle, como: testes, melhorias no código, automatizar processos, etc. Mas isso já é assunto para outro post.

Então, sexta passada fui até o Carrefour comprar uma cadeira descente para o notebook daqui do apartamento, de modo compulsivo, acabei comprando uma mesinha também, andando com o carrinho de compras praticamente transbordando em direção ao caixa, visualizei de longe as tirinhas de Dilbert, você está demitido! E não resisti, já coloquei pra dentro, e logo ao lado, vi A Cabeça de Steve Jobs, ele parecia piscar para mim e não teve jeito, levei também. Esta é a parte ruim da história, sim, meu bolso.

A cabeça de Steve Jobs

Agora a parte boa, o livro é fantástico! Duhh! Óbvio, se tratando de Steve Jobs, qualquer coisa se torna fantástica e é exatamente disso que Leander Kahney retrata durante as 200 e poucas paginas, que você pode ler durante um carnaval, por exemplo. (sim, eu fiz isso durante o carnaval!). Kahney, inicia a obra dando um resumo geral do que viria pela frente, desde o inicio de Jobs na Apple, junto a Wozniak, até sua saída e, posteriormente, seu retorno a empresa –então a beira da falência-, quando Jobs a coloca no topo novamente (“O que tem de errado por aqui? São os produtos! Os produtos são uma #%$@*! – Steve, em seu pré-retorno a Apple”).

Mostra o que os funcionários temem, o conceito de ser “stevado” gira em torno da Apple, pois a figura de Jobs decreta que, ou você é um gênio ou é um idiota, e normalmente quem não se considera gênio, não gostaria de cruzar o caminho de Jobs pelos elevadores da empresa. Também descreve um Jobs perfeccionista, extremamente poderoso em marketing, com um potencial fantástico para criação de novos produtos, rigoroso com design, somado a uma personalidade tão forte, que ninguém consegue dizer “não” a ele, apenas o inverso acontece bastante. Há também umas boas pinceladas pelos principais produtos da Apple, principalmente os criados pela cabeça de Jobs, inclusive, sempre retratando números de lucros, vendas, etc. O autor detalha bem este aspecto, o que é algo bem interessante.

E principalmente, demonstra como um líder de verdade deve ser! Você deveria ler este livro…

Ei você, você mesmo! Eu sei que você pesquisa meu nome no google, talvez até você tenha sido meu gerente em uma empresa que estive, estou ou estarei. Vou te dar uma dica, lembra daquele esquema todo sobre cargos e salários em TI? Lembra? Bom, isso não importa, apenas LEIA ESTE EXCELENTE POST DO GC e aprenda de uma vez por todas que… homem é homem, menino é menino, macaco é macaco e veado é veado.

O que mais vejo nas comunidades que freqüento é gente perguntando coisas como “Vale a pena aprender X?”, “Tenho Y anos, ainda consigo aprender a tempo para entrar no mercado Z?”, “O que devo aprender primeiro para começar a trabalhar com XPTO?”. Depois de sempre responder prontamente este tipo de assunto, resolvi blogar sobre o mesmo. Então, vamos lá:

– O mercado de TI está escasso? Está! Mas não para profissionais ruins. Falta gente qualificada. Então sabichão, se você acha que é só fazer aquele cursinho de verão de Java da vida e já vai sair bombando no mercado, está muito enganado! O negócio é pontual: aprendizado contínuo. Você vai precisar estar sempre atualizado, lendo livros técnicos, estar por dentro das ultimas tecnologias do mercado, assinar blogs/feeds (já assinou meu blog?) sobre o assunto, ler as revistas em destaque relacionadas E, mesmo assim, ainda não será suficiente, pois faltará o ânimo para por tudo isso em prática (e acredite, esta é a parte mais difícil).

– Existe idade para começar na tecnologia X? Mas é obvio que não! Conforme respondido na questão anterior, o mercado de TI está escasso, então, se você for bom, não importa se você tem 10 ou 100 anos, apenas pare de perder tempo e encare logo.

– Vale a pena aprender XYZ? Pergunta juvenil! Se você quer ganhar dinheiro (e acho que é este o seu objetivo em querer aprender XYZ), olhe para o mercado, veja o que mais se pede, pois o que mais falta é o que mais viabiliza o retorno, por isso vá com cautela na escolha do seu próximo alvo, se XYZ está em falta, é claro que vale a pena.

– E o salário, é bom? Não, é ruim. Mas (em minha opinião), TI te da um retorno mais rápido, e o salário é melhor do que outras profissões mais comuns, além de faltar profissional bom (oferta > procura). Na verdade, acredito que quem trabalha em TI não é nem tanto pelo salário, e sim porque gosta da profissão, então se você está em dúvida por causa do salário, não creio que terá sucesso com TI.

– Vale a pena trocar A por B? Já disse, o mercado quem manda. Se a demanda de B for maior que A, vale, é claro.

Boa sorte a todos!

Então, assim, o blog é novo. O antigo (robsonfarias.info) está desativado temporariamente, o motivo é algumas complicações com a hospedagem. Fui no barato e me arrependi. Preferi sair e criar uma conta aqui no WP mesmo, pelo menos é mais garantido (mesmo tendo ainda um mês -que já foi inclusive pago- lá) . Quanto aos posts do outro blog, tentei importar, mas pelo jeito não rolou! Alguém tem alguma idéia do motivo? Enfim, vou tentar atualizar com os melhores posts de lá quando der. E, claro, vou tentar deixar este novo blog mais especifico a tecnologia (cheguei a esta conclusão, quando vi que meus posts referentes a bobagens da minha vida não davam muita audiência, senão para: curiosos visitando). Ah, já disse que estou saindo de férias? Ta bom, parei.

Valeu!

Este é um dos grandes problemas das empresas (de TI ou não), levando em consideração: custo x benefício no desenvolvimento de software. Quanto custa fazer software vs. quanto custa comprar software? Está é a análise de risco a ser feita antes de iniciar qualquer projeto. Claro, que quando se trata de projetos externos (para clientes) isso não importa muito, uma vez que seu interesse primário é lucrar e quem estará bancando é o cliente; Mas e quando o software de interesse é para uso interno? Vale mais a pena fazer ou comprar?

O cálculo que precisa ser feito é simples! Para fazer internamente: você terá –pelo menos- que alocar: um desenvolvedor, um analista de negócios e um testador, e o preço de manutenção deste sistema será a soma do salário destes profissionais com base na porcentagem de alocação dos mesmos no sistema. Agora, para comprar, na maioria dos casos: ou o sistema já existe ou precisa apenas de algumas customizações, normalmente você vai pagar um preço fixo mais um variável para customizar (até mesmo seus funcionários podem trabalhar na customização levando em consideração que o produto já existe e que a alocação será bem menor).

Resumidamente a lição que tiramos disso é: Gerentes, não hajam por impulso, olhem para o mercado antes de inicial qualquer projeto retaguarda e principalmente: não ignorem NUNCA a análise de risco.

Anúncios