Leopoldo Barreiro

Estou a algum tempo investindo horas de desenvolvimento no framework em PHP, denominado CleanGab. Esse framework está implementando o padrão MVC clássico, com camadas de controle, modelo e visão. O CleanGab também está implementando uma versão própria de JSTL para o PHP.

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.

No dia a dia de uma fábrica de software, por vezes nos deparamos com algumas questões práticas referentes à construção do produto de software. Uma das questões mais cuidadosamente tratadas é a escolha de uma arquitetura e de um framework.

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.

É 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.