Bueno, de todas formas, mi chiquilín aprendió primero a escribir con letras de imprenta. La metodología exhigía que después de dominada esa forma de escrita, ahí sí los niños podrían aprender a escribir en cursiva. Los tiempos cambian y nosotros debemos ver todo de forma distinta, de a poco.

Creo que eso de la cursiva puede desaparecer con el paso del tiempo, pero sigue siendo algo importante para practicar y dominar. Mi hijo hace tres años que escribe, pero en cursiva nunca se puso a practicar. Hace pocos meses en la escuela empezaron a practicar a diario la cursiva. A mí me pareció muy bueno. Eso ayuda los niños a tener más control sobre los movimientos, ayuda incluso en la productividad. Imagínense escribir una redacción en media hora sin cursiva. Todo se vuelve más lento…

Llegamos en un punto donde mi hijo no veía mucha ventaja en aprender a escribir en cursiva. Eso a lo largo se podría volver en un problema, puesto que la escuela lo exigía. Entonces allá en casa, yo y mi mujer tuvimos una idea que nos pareció interesante, y después se confirmó suficiente para animarlo al pequeño. Hace tiempo el chiquilín me veía trabajando con programación informática. Todas las semanas estoy trabajando en algo, sea por un proyecto propio, sea por un trabajo encomendado. Aparte llevo unos buenos meses manteniendo mi blog personal, aunque aún no le estoy dando el tiempo que merece.

Bueno en suma, al chiquilín siempre le gustó la idea de tener un blog personal para él tambíen. Algo suyo, donde él pudiese escribir y publicar contenido proprio, de acuerdo a los intereses de un niño precoz de 7 años de edad. No tuvimos dudas en proponerle un cambio: él se dedica a dominar la cursiva y nosotros le preparamos un blog. Bueno, su blog ya está en línea y va muy bien: con posts regularmente publicados y propaganda de boca a boca en su escuela, en seguida va a alzar vuelos más altos, quizás.

Después de todo me pareció irónico todo eso, y me puse nostálgico. Antiguamente los niños aprendían cursiva de inicio. Hoy aprendemos a escribir como las máquinas (computadoras) y después en cursiva. Antiguamente los niños aprendíamos a mantener un diario, hoy es un blog. El mundo cambia y nosotros también debemos hacerlo. Bueno, mi generación tuvo que aprender a escribir en línea después de grande. Nuestros hijos ya tienen la oportunidad de participar de toda una vida en línea desde chicos (y deben hacerlo bajo supervisión de sus padres).

Si volvemos un poco más atrás en el tiempo, mi padre creció con una radio de madera en la sala su casa. Después de adulto tuvieron su primera televisión negra y blanca. Muchos años más tarde los colores invadieron las pantallas de la televisión. Internet para personas naturales sólo apareció cuando yo era adolescente.

Pienso que todas las generaciones precisan en un momento adaptarse a las nuevas tecnologías que empiezan a formar parte de nuestro dia a dia. Todo evoluciona y nosotros debemos mantener la mente abierta a los buenos cambios. A esos que nos permiten mejor calidad de vida. Pero siempre tenemos que luchar para mantener las antiguas cosas buenas. La letra en cursiva es una de esas que vale la pena practicar siempre. Allá en mi casa todos tenemos blogs, y todos escribimos en cursiva.

No CleanGab, além de proporcionar a navegação, a camada de controle estabelece a ponte entre as camadas de modelo e visão. Durante meu embasamento conceitual, buscando forças e inspirações para desenvolver esse framework, encontrei dois links muito bons a respeito de MVC, os quais compartilho com vocês:

O padrão MVC na teoria e prática

http://warp.povusers.org/programming/mvc.html

MVC: história, teoria e uso

http://amix.dk/blog/post/19615

Este último explica o conceito, mas também entra em questões de implementação usando Ruby on Rails.

Abraço e até a próxima.

Esse é o alicerce para qualquer sistema, porém às vezes não conseguimos despender o espaço no cronograma suficiente para essas questões, depois que o projeto inicia. Isso é natural, visto que o alicerce nunca é visto pelo cliente e pela área comercial da nossa empresa. Certamente a arquitetura e o framework escolhidos refletem na robustez e eficácia do produto de software, mas arquitetura e framework não são facilmente percebidos pelo cliente.

Eu acredito que devemos pensar em arquitetura e framework da solução desde um primeiro contato de apoio e pré-venda.

Imaginemos o cenário: a área comercial efetua a prospecção de um novo cliente para um projeto de software. A área técnica é acionada para prestar um apoio na pré-venda. Neste momento a área técnica já deve realizar um levantamento prévio de aspectos culturais e infra-estruturais do cliente, no intuito de escolher uma arquitetura adequada para o novo software. É aqui que devem ser revelados os primeiros requisitos.

Com base nos levantamentos realizados em uma sondagem prévia, a área técnica já consegue preparar-se para o futuro projeto de modo mais consistente. Ou seja, a área técnica deve aproveitar para recolher informações desde um primeiro contato com o cliente, de modo a obter com o máximo de antecedência informações que subsidiem os passos iniciais do projeto:

1. Definir a arquitetura do sistema – baseada em requisitos não funcionais (cultura ou infra-estrutura do cliente);
2. Avaliar frameworks para a construção do sistema – baseado na arquitetura escolhida
3. Escolher um framework dentre os avaliados

Neste ponto posso estar parecendo exagerado. A equipe precisa preocupar-se com a arquitetura e o framework do sistema desde um primeiro contato com o cliente? Resposta: Sim. Temos a obrigação de estar um passo à frente. Cada vez mais, nós os profissionais de T.I., precisamos nos aproximar da área comercial da nossa empresa e do nosso cliente. Apoiar a área comercial e ajudar o cliente a resolver seus problemas é um conceito-base para o bom profissional de T.I. hoje em dia.

Dito isso, uma segunda questão que deve surgir é a seguinte: Não é desperdício pensar em arquitetura e framework antes de fechar o contrato, antes de ter o projeto na pauta de desenvolvimento? A resposta é um redondo NÃO. Desperdício é ficar esperando de braços cruzados que o projeto chegue a nossa fila de trabalhos, para depois pensar como ele pode ser construído.

Se a equipe pretende receber projetos bons, trabalhar com bons padrões e progredir em boas práticas, deve sim aproveitar cada oportunidade para estudar, avaliar e comparar soluções em arquiteturas e frameworks.

Acredito que o melhor momento para pensar em arquitetura e framework é na pré-venda de um projeto de software. Depois que o cliente fechou o contrato com a nossa empresa, geralmente temos um cronograma apertado e, consequentemente, menos tempo para pensar no alicerce do sistema. O cliente e a área comercial precisam ver logo o sistema sendo construído. É um fator humano: precisamos ver para crer.

Fazendo uma analogia com a construção civil: quanto antes tivermos definido o melhor alicerce, de acordo com o terreno em que será construído o prédio, mais rápido poderemos começar a levantar as paredes.

Falando em evitar desperdício de tempo, ao mesmo tempo que devemos pensar em certos aspectos do projeto no momento de uma pré-venda, também precisamos evitar que toda a equipe esteja envolvida nesse penso. É recomendável incentivar que todos os membros da fábrica de software tenham a oportunidade de pensar em arquitetura e frameworks para um possível projeto a ser assumido, mas que apenas um ou dois profissionais sejam alocados para essa atividade por vez. O trabalho realizado em apoio a área comercial também deve ser considerado como parte das atividades diárias de uma fábrica de software. Essa visão é condizente com a realidade do mercado e é cada vez mais requerida pelas empresas de ponta.

Smoke Test
A origem do nome Smoke Test remonta do início da indústria de hardware. Traduzindo para o portguês, seria “Teste de Fumaça”. Após montar os componentes eletrônicos, ligava-se o equipamento na tomada. Se não surgisse fumaça, o equipamento tinha sido bem montado e os componentes estariam funcionando. Transportando esse conceito para o desenvolvimento de software, smoke test é um conjunto de testes básicos realizados pelos testadores para saber se o software que está sendo liberado possui algum problema saliente em suas funcionalidades mais básicas. É realizada uma navegação completa no sistema para verificar se tudo o que já funcionava antes segue funcionando corretamente.

Sanity Test
O sanity test ou “teste de sanidade”, é realizado quando um novo build com revisões pequenas é gerado. O objetivo do sanity test é garantir que os problemas resolvidos (listados no release notes) estão realmente corrigidos. Além disso, o sanity test garante que as correções entregues não geraram novos bugs. A suite de testes do sanity test é encarado como uma atividade anterior aos testes de regressão completos, ou mesmo em substituição a este quando a entrega é de baixa criticidade.

Links separados para leitura
Seguem alguns links interessantes que separei sobre smoke e sanity test.

1. geekswithblogs.net – apresenta os conceitos de cada atividade, bem como uma tabela comparativa dos dois.
2. softwaretestinghelp.com – confronta os dois tipos de testes de forma direta.

A pouco tempo atrás, o mercado brasileiro de comércio eletrônico estava exclusivamente formado por grandes portais. Hoje os grandes ainda concentram a maior fatia do mercado. No entanto, observa-se o surgimento de novos sites, comercializando produtos de empresas pequenas e médias. Eu mesmo estou tendo a oportunidade de trabalhar em dois projetos atualmente. Um deles de uma cadeia de lojas de shopping centers proeminente em Porto Alegre e Caxias do Sul, mas que em termos de Internet está começando a explorar um novo mercado. O outro cliente vende máquinas de porte industrial, e enxerga na Internet a possibilidade de expandir seu mercado consumidor.

Na medida em que os empresários empreendem novos rumos na Internet, seja para apoiar ou expandir seus negócios, proliferam-se as ofertas para o internauta, na qualidade de cliente qualificado. Para o consumidor, tornou-se muito fácil escolher seu produto na Internet. Não é necessário perambular por várias lojas, em busca do melhor custo benefício. Basta navegar por alguns sites e fazer sua própria comparação na tela do computador. Na Internet, o cliente pode estar em contato com os produtos desejados de forma muito mais simples, prática e rápida.

No entanto, existe o outro lado da moeda. A ausência de uma loja física pode mascarar problemas de idoneidade, logística e atendimento do lojista. Infelizmente não podemos definir com total precisão se uma loja virtual é ou não a melhor escolha para fazer a compra, mas podemos sim minimizar os riscos, com dois princípios básicos fundamentais:

1. Transparência das informações – verifique se o site possui todas as informações necessárias para descrever o produto, tais como características físicas, técnicas, preço, formas de pagamento, prazo de entrega. Pense que em uma loja convencional você não compraria determinado produto se não soubesse dessas informações todas.
2. Canal de comunicação com o Cliente – verifique se o site disponibiliza canais de comunicação bem estabelecidos: e-mail, formulário de contato, telefone, chat (citando os principais exemplos). Acima de tudo, é interessante testar esses canais de comunicação antes de uma compra. Pergunte, questione sobre o produto, coloque na mesa suas dúvidas e no final faça sua avaliação: as dúvidas foram esclarecidas? O pessoal do site soube dar um bom atendimento?

Nos próximos posts vou falar a respeito de investigar a identidade de uma loja virtual. É um processo simples mas ajuda a apoiar o consumidor eletrônico na escolha pela loja idônea.

Ora, se o software é um produto (e como tal precisa atender as pessoas que o usam) precisamos tentar abstrair ao máximo o bairrismo de uma ou outra plataforma, em busca de uma coexistência pacífica. Cada qual com sua soberania, e todos por um ideal maior. Não querendo ser sensacionalista, acredito que a busca pela integração sistêmica, reflete a necessidade primordial do mercado de sistemas de informação.

Existem tecnologias e abordagens muito boas para integrar sistemas, dentre as quais podemos citar webservices, SOA, SOAP. O que tenho visto que falta é um senso de universalização. Algo que permita ao mais ferrenho desenvolvedor .NET conversar com o seu parceiro Java e vice-versa.

O que importa é informação. A informação deve ser de boa qualidade e válida para o contexto onde está inserida. A comunicação entre sistemas já não é item de luxo. É necessidade de infra-estrutura básica.

É necessário ter mente aberta. Quem trabalha em T.I. precisa ser também vanguarda filosófica. Não se pode vender o peixe se não se acredita nos benefícios da carne branca, por exemplo.

Hoje em dia as empresas precisam de profissionais multi-plataforma. Não digo com isso que o especialista Java precisa também ser especialista .NET, ou vice-versa. O que sim precisa acontecer é que um profissional que prefira certa tecnologia possa naturalmente trabalhar em outra tecnologia, caso a ocasião o requeira.

Apenas com base em uma comunicação eficaz é possível dimensionar o problema do negócio e estabelecer os requisitos condizentes com a realidade. Se os envolvidos no processo não compartilham uma mesma visão sobre o assunto, é muito provável que as soluções propostas não sejam adequadas.

Conversando com um antigo amigo tempos atrás, percebi que a imagem que fazem de nós (profissionais de T.I.) é de que somos inalcançáveis, intangíveis pessoas com as quais ninguém consegue conversar. Não entendemos e não nos interessa entender o problema dos outros. Fazemos software para nossa própria diversão, para nosso deleite e os usuários devem adaptar-se ao software, e não o software aos usuários. É uma imagem caricaturizada lógico, mas acredito que se fossemos mais comunicativos, muita coisa mudaria. Em alguns anos não haverá mais espaço para pessoas que não se comunicam. Tudo está ficando mais competitivo, a informação adquire importância crucial para qualquer negócio. Com desenvolvimento de software não é diferente.

Hoje em dia se discute muito sobre os prejuízos causados pela falta de comunicação e erros de interpretação (entre o que o cliente precisa e o que a equipe achou que ele precisava). Prejuízos esses que afetam o cliente, mas também afetam a equipe de desenvolvimento. Profissionais de T.I. que realmente gostam do que fazem, sentem-se mal quando as expectativas do cliente não foram alcançadas. Por outro lado, existe uma motivação generalizada quando essas expectativas são conquistadas e transformadas em software de valor.

Outro dia, ao final de um sprint de desenvolvimento, a minha equipe (participo como analista de sistemas) foi coroada com um dia de premiação. Entregamos uma nova versão de software, foi organizada uma apresentação, o cliente elogiou muito e todos sairam edificados da reunião.

Houve uma satisfação geral: uma meta importante tinha sido conquistada. Esse dia foi apenas o feliz desfecho de todo um trabalho, baseada em comunicação constante. Comunicação entre os integrantes da equipe sim, mas também comunicação direta com o cliente.

Assiduamente o cliente era convidado a participar, acompanhar o processo de desenvolvimento. Decisões foram tomadas no intuito de priorizar aquilo que agregaria mais valor para o negócio do cliente. Nesse intuito, foram incluídas funcionalidades antes não planejadas e retiradas outras que não eram tão importantes para o momento.

O melhor de tudo: o cliente sempre estava participando das decisões, lado a lado com a equipe, como em uma parceria mesmo.

Não houve surpresas desagradáveis. Como tanto a equipe quanto o cliente sabiam de tudo e tinham corroborado sobre tudo antecipadamente, não houve desapontamentos. O que houve sim foram priorizações acertadas, mais qualidade e mais valor produzido, tudo isso traduzido em software funcional, entregue para o cliente.

Que legal essa tal de comunicação. Pode parecer básico, mas tem gente que ainda não pratica.

Kanban tem origem no Japão e significa “registro ou placa visível”. Trata-se de um quadro visível no ambiente de trabalho, onde a equipe consegue consultar o andamento da produção. Em se tratando de desenvolvimento de software, a equipe consegue visualizar no Kanban todos os componentes, as funcionalidades que fazem parte da entrega de um release de software.

O conceito por trás do Kanban é extremamente simples. No quadro, são delineadas algumas colunas, correspondendo às fases de entrega de uma funcionalidade. Por exemplo, colunas com os itens Especificação, Desenvolvimento, Testes, Entrega. Cada funcionalidade é um post-fix pendurado no quadro. A medida que a funcionalidade avança de fase, o post-fix é mudado de coluna no Kanban. Modo simples e eficaz para dar visibilidade a toda a equipe daquilo que está sendo feito e o que falta fazer.

Kanban foi idealizado pelos altos-executivos da Toyota há décadas, como um recurso para dar visibilidade na linha de produção. É uma ferramenta integrante da metodologia denominada just-in-time. Apesar de sua aplicação inicial ter sido idealizada para a indústria automobilística, a aplicação de just-in-time na indústria de software mostrou-se extremamente eficaz.

Tudo o que está fixado no Kanban deve ser movimentado. Uma funcionalidade de software nunca é empurrada para a próxima fase no Kanban. Pelo contrário, o time responsável pela fase seguinte é quem puxa a funcionalidade para si. Por exemplo, quando é concluída a fase de especificação de uma funcionalidade, ela permanece na coluna “Especificação” até que um desenvolvedor esteja livre para iniciar a fase de desenvolvimento. Somente aí é que a funcionalidade move-se no Kanban, passando para a fase “Desenvolvimento”.

De acordo com o just-in-time, nada deve empurrado na linha de produção. Não se deve formar estoques. Para software o mesmo: não devemos sobrecarregar os times, mas sim prover um fluxo organizado e estável de produção de software. É um caminho certo para a qualidade de software, tão almejada.

Além da conversa com meu amigo, outro motivo que me levou a escrever sobre Kanban foi uma boa notícia recebida esta semana no trabalho: começaremos a utilizar Kanban também lá na empresa. Eu conheço minha gerente de projetos há pouco tempo, mas já percebi sua inclinação para metodologias ágeis. Sinto que boas mudanças virão pela frente. O uso de Kanban lá na equipe vai proporcionar o domínio do problema para todos. Estaremos aptos a acompanhar em tempo real o andamento do projeto, das entregas de software em cada sprint e por fim cultivar a empatia pelo trabalho dos diferentes times que compõem nossa linha de produção de software.

Da próxima vez que eu encontrar esse meu amigo vou poder falar sobre a aplicação de Kanban em minha equipe de desenvolvimento também. Realmente, Kanban é muito legal.