Na Myfreecomm temos alguns programadores lentos, graças a Deus. Conversando sobre isso com o Henrique, ele disse que merecia um post. Atendendo a pedidos, aí está.

Depois de bastante tempo sem programar, eu passei dois dias escrevendo um pequeno sistema para integrar a parte de pagamento de uma aplicação com o Paypal.

O fato de ter voltado a programar, depois de mais de um ano apenas gerenciando projetos e equipes, e estudando metodologias ágeis, me fez optar por escrever uma aplicação 100% testada, em Ruby, utilizando Sinatra. Gostaria de aproveitar para agradecer o Rafael Souza que me ajudou bastante no início.

A escolha de Ruby (ao invés de Python por exempo) e Sinatra (ao invés de Rails por exemplo), não importa. O que importa é que eu poderia fazer tudo “scriptado” (aka cuspido), mas achei que não deveria. O primeiro motivo é que se trata de um middleware para um processo crítico que não pode falhar, o pagamento. Segundo, por que na minha cabeça não fazia sentido cuspir um código e fazer funcionar o mais rápido possível.

Isso me fez pensar sobre o paradoxo da qualidade x velocidade. A conclusão que tirei das minhas reflexões é que os programadores que se dizem lentos, na verdade não são lentos.

Para você dizer que alguém é lento, você tem que comparar com outra pessoa. Lentidão é relativo. Você não é lento e ponto final, você pode ser lento se comparado com outras pessoas.

Minha conclusão foi que na verdade o “programador lento” faz as coisas no tempo em que elas realmente precisam para serem feitas da maneira que funciona. Na verdade, os outros que são rápidos de mais. Adianta ser rápido e ter bug?

Analisando sob essa ótica, e considerando a premissa de que a maioria das pessoas (rápidas) fazem errado, vide relatório Chaos Report do Standish Group, posso dizer que programadores lentos são bem-vindos.

Hoje, eu vejo essa característica como um sintoma de que ele programa com boas práticas e com o cuidado necessário para o software funcionar.

No final da conversa eu disse para o Henrique: “Se em uma entrevista de emprego, um programador me diz que é lento, eu vou vê-lo com bons olhos”.

Abraço e até a próxima.

Na minha última palestra, no Ceará On Rails, eu tive que preparar tudo de um dia para o outro e não pude organizar melhor as idéias colocadas nos slides. Em um deles eu escrevi “A procura da batida perfeita”, no momento que eu ia falar sobre as características de uma aplicação web ideal, da maneira que eu busco.

De lá pra cá eu venho pensando sobre o termo “batida perfeita” e relacionando com os acontecimentos do dia-a-dia na minha vida.

Então me veio a pergunta: Qual seria a batida perfeita para a gestão de uma empresa de desenvolvimento de software?

Antes de responder, é bom lembrar que a batida perfeita é aquela que dá gosto de ouvir.

Respondendo a pergunta acima, na minha opinião, a batida perfeita para gestão em software, envolve em parte o seguinte:

Utilização de metodologias ágeis

Se eu pudesse dar uma só dica sobre o futuro, seria esta: use metodologia ágeis
Os benefícios a longo prazo do uso de metodologias ágeis estão provados e comprovados pela ciência; já o resto de meus conselhos não tem outra base confiável além de minha própria experiência errante.

As metodologias ágeis começaram a ter força no Brasil, neste ano de 2009. O Scrum, Lean, Kanban, XP foram as filosofias e metodologias mais faladas entre os Brasileiros. Eu estou convicto de que o agile, como é chamado pelos íntimos, é mais eficiente que as metodologias adotadas atualmente, assim como sou convicto que haverá metodologias melhores no futuro próximo. O legal é que o agile já é o primeiro passo para se aceitar mudanças com velocidade.

Fixar qualidade, negociar escopo. Preço e prazo são consequência
É muito importante que você fixe a qualidade do serviço, seja para clientes externos ou clientes internos. Negociar o escopo é chave para o sucesso de projetos de desenvolvimento de software, pois assim fica garantido que o que foi feito vai funcionar, que é um dos maiores problemas neste setor.

Entendimento do perfil do desenvolvedor
Em geral, o desenvolvedor é um funcionário um pouco diferente dos demais. Um amigo meu já disse uma vez “É mais fácil tocar uma indústria com 600 funcionários do que uma empresa de software com 10”. É claro que não passa de uma opinião, mas o que ele queria dizer é que desenvolvedores são problemáticos.

O primeiro problema que deixa qualquer gestor neurótico é o horário. Difícil fazer o Daily Meeting no horário todos os dias, não é mesmo!?

Confiar no desenvolvedor é importante, principalmente nos prazos dados. É sério, eles sabem dar prazos. Os gestores que não sabemos aceitar.

Escolha de uma tecnologia para trabalhar
Escolher um ambiente e as tecnologias para as soluções que serão desenvolvidas é indispensável. Pequenas empresas principalmente precisam fazer uma escolha e segui-la.

As opções são inúmeras, dentre elas temos: software desktop, software para Windows, aplicações para mainframe, sistemas web na plataforma Windows, sistemas Ruby on Rails, etc. Perceba que não existe um critério, você pode deixar mais abrangente dizendo desktop x web ou especificar que será só pra Windows ou usando o framework X.

Embora não seja aconselhável você se prender a uma tecnlogia, quanto mais você especificar com o que deseja trabalhar, é melhor para evitar ficar perdido e gastar energia com falsas oportunidades.

Estes foram apenas quatro pontos que estavam na minha cabeça e resolvi colocar em um post. A batida perfeita não pára por aí evidentemente. Muitos outros fatores são relevantes, inclusive aqueles que dizem respeito à programação em si.

Havendo oportunidades escreverei sobre abatida perfeita para desenvolvimento de código de programação e fatalmente falarei sobre os tópicos abaixo:

Framework, Programação orientada a testes (TDD), Deployment automatizado, Integração contínua, Controle de versão distribuído, Definição de um Commit Pattern, Ambiente de Staging, etc.

Conforme eu for descobrindo características importantes, vou escrevendo aqui. Por enquanto é só.

Abraço e até a próxima

Estamos desenvolvendo na Myfreecomm um sistema de cobrança que está ficando muito interessante. Ele irá resolver um problema real e trará muita conveniência no dia-a-dia das empresas que realizam cobrança com integração com os bancos.

O sistema está quase pronto e estamos neste momento definindo aqueles detalhes que fazem toda a diferença.

A concepção foi baseada em um fluxo único de uso, de forma que os itens de menu contemplassem as ações que o usuário irá realizar, como se o sistema todos fosse um grande wizard. As páginas acessórias são acessadas apenas por links contextuais. Não temos menu e submenu, nem breadcrumb. E te digo, fazer o sistema assim é um desafio!

A interface ficou bem simples, sem muitas opções e com links no lugar certo e na hora certa. Quando fazemos sistemas deste gênero as palavras e termos utilizados nos itens de menu, nos títulos e nos links são muito importantes. É preciso que o usuário consiga se situar de forma rápida e entenda o que irá acontecer a cada clique.

O Allan é o responsável por fazer com que o sistema seja entendido pelos usuários. Ele está escrevendo o manual, pensando em que lugares existirão links para o manual, quais são os pontos que podem gerar dúvidas, etc. E nesse processo ele está revendo os termos utilizados a todo momento. Inclusive nas interações chegamos a perceber e incluir na histórias novos status para determinada entidade e tudo.

Hoje ele levantou uma bola que gerou uma discussão muito saudável. Uma das ações do usuário no sistema é juntar várias cobranças para que elas sejam enviadas para o sistema do banco. Até hoje, o termos utilizado para esse conjunto de cobranças era Remessa. Tínhamos termos tais como: Preparar Remessa, Enviar Remessa, Remessas Pendentes e Remessas Enviadas.

A questão levantada foi: “Não deveria ser Lote ao invés de Remessa?”

A conclusão imediata depois de um rápido brainstorm foi de que tanto faz, afinal dá no mesmo, lote e remessa são a mesma coisa. Bem, depois de muita conversa e esclarecimento sobre entidades, estados, tempos, etc chegamos a uma opinião diferente.

Buscamos definições de lote e remessa no Google, depois fomos aos dicionários priberam e Aurélio. Mais alguns minutos de discussão e desenho foram neecessários para concluirmos que Remessa é algo que foi enviado, ou seja, que já passou pelo processo de envio. Se existe algo que pode ser remetido, mas ainda não o foi, isso não pode ser chamado de Remessa.

Donde se concluí que  dizer “Enviar Remessa” está errado e o termo “Remessa enviada” é um pleonasmo. Se é Remessa, é por que já foi enviado.

No meio da discussão chegamos a lembrar que muitas vezes não importa o “certo” e “errado” na gramática formal e que o mais importante é o entendimento do usuário. Mas é o que eu digo, se podemos usar o correto de acordo com a gramática sem afetar o entendimento do usuário, melhor. Se, usando o termo gramaticalmente corrento, ainda assim facilitamos o entendimento do usuário, como foi o caso, melhor ainda!

Por fim decidimos usar o termo Lote ao invés de Remessa e mudaremos para “Preparar Lote”, “Enviar Lote”, “Lotes pendentes” , “Lotes enviados” e outros termos presentes na interface. Como escrevemos todo código de programação em inglês, não tivemos maiores problemas.

Essa experiência foi muito interessante, pois foi legal estudar e discutir sobre o significado destas palavras e foi incrível perceber como uma mudança simples pode ao mesmo tempo melhorar o sistema e facilitar nosso trabalho. Ficará mais fácil agora escrever o manual. É aquela velha história: Se está difícil, está errado!

Uma vez eu li um post da 37signals extamente sobre isso. Agora eu entendo perfeitamente o que eles queriam passar com o post, e é o que eu espero deixar de recado também.

A definição de termos corretos e fáceis de serem compreendidos pelo usuário é fundamental para a boa usabilidade do sistema.

Além disso, escolher as palavras certas facilita a compreensão da relação do que elas representam com o sistema como um todo.

São diversos fatores que tornam um sistema bom ou ruim, difícil ou fácil de usar e complexo ou simples. Usar palavras corretas e de simples entendimento é um fator muito importante. Às vezes parece que está tudo bom, e que as palavras estão certas e serão compreendidas, mas nem sempre é verdade.

Pense no sistema que você usa ou está desenvolvendo. Será que mudando alguns termos não ficaria muito mais fácil de usar? Você tem algum caso similar? Deixe sua história nos comentários!

Abraços e até a próxima.

Quando estava desenvolvendo o BielBid, eu criei uma série de tabelas com dados úteis para internacionalização de software. Não sei por que não disponibilizei isso antes!

Faça o download clicando no link abaixo:

Dados de Iocalização, idioma, moeda, países, estados e cidades

Você irá encontrar neste arquivo:

• Tabela de locales com todos os locales com o country e language
• Tabela de idiomas com todos os idiomas, relação com locale e nomes em inglês
• Tabela de moedas com Real e Dólar
• Tabela de países com todos os países e seus códigos
• Tabela de regiões com todos os estados do Brasil e dos Estados Unidos em português e inglês
• Tabela de cidades com todas as cidades do Brasil e relação com estados

Se ela for útil para você, deixe um comentário

Abraços e até a próxima!

Commercial pressures of today’s economy result in imposed deadlines being the norm for technology projects. Yet the nature of software projects demands that teams deal with the constant dynamics of change. This creates extreme degrees of project risk and perpetuates the so-called “software crisis,” whereby a large percentage of projects are canceled, delivered late, over budget, and/or poor quality. However, knowing the nature of these dynamics empowers managers to make decisions on promised functionality, thereby controlling the very factors that degrade software quality and reliability.

Fonte: http://www.cutter.com/workshops/03.html