Leopoldo Barreiro

Este año mi hijo único estuvo aprendiendo muchas cosas en la escuela. Uno de los objetivos era aprender a escribir y leer en letras corridas, en cursiva. No me acuerdo exáctamente cómo era en mi época, pero sé que aprendí a escribir en cursiva en los primeros años de primario.

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.

Neste post pretendo descrever, sob o ponto de vista de um analista de sistemas, duas atividades que considero muito importantes para uma entrega de software bem sucedida. Tratam-se de duas atividades realizadas pelo pessoal da qualidade de software (Q&A): Smoke Test e Sanity Test.

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 motivação para escrever este post foi minha recente leitura de notícias e e-mails relatando golpes em comércio eletrônico. É um problema que vem aumentando junto com o próprio comércio eletrônico no Brasil.

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.

Um grande desenvolvedor com o qual convivo me comentou que só trabalha com Java. Eu particularmente gosto muito de PHP. Já outro puxa para o lado do .NET. E nós três estamos trabalhando na mesma empresa.

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.

É interessante como nós, os seres humanos, tentamos complicar as coisas as vezes. Em desenvolvimento de software não é diferente. Especialmente quando estamos precisando que o cliente nos abasteça de problemas para resolver em seu negócio. É muito comum não conseguir entender o que o cliente expõe, para depois estabelecer um consenso daquilo que o software precisa resolver.

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.

Faz umas semanas atrás reencontrei um velho amigo meu, ex-colega em um projeto em que participei. Como sempre, puxamos assunto falando sobre nossos trabalhos atuais. Foi aí que começamos a conversar sobre o dia-a-dia no desenvolvimento de software em nossas equipes. Ele me contou entusiasmado que eles começaram a utilizar Kanban para uma visibilidade das entregas de software. Foi então que resolvi falar um pouco sobre o assunto.

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.