CEP's BRASILEIROS

- SQL com lista de CEP's brasileiros.

Atualizada em meados de 2009.
Não é a mais atual, mas já é um primeiro passo, concordam?
Vai que não pode consumir web service em seu sistema...resta-lhe colocar tudo dentro do banco!

Arquivo: ceps.zip

Sintomas da necessidade de um novo projeto

Venho por meio deste, fazer uma denuncia! Diante da situação do sistema encontrado na empresa “X”, torna-se necessária uma analise de criticidade do projeto de software adotado atualmente. O mesmo expõe vários sintomas que nos fazem acreditar que o projeto esta apodrecendo e embora ele ainda funcione corretamente por um tempo, vem se tornando uma bomba relógio.

O software citado acima possui as seguintes características:

Rigidez

Um projeto errôneo de estrutura da informação acarreta uma mudança em um módulo que provoca outras mudanças no formato cascata em módulos subseqüentes. No cenário atual, um erro “infantil” causa grande transtorno quando se torna necessária uma mudança em pequenos blocos de conteúdo no layout do sistema em questão. Conteúdos estáticos que poderiam ser resolvidos com uma simples “masterpage” e estilos CSS, alterados módulos a módulos.

Fragilidade

As falhas seguem e notamos que a falta de padrão de projeto é visível. Uma simples mudança de usuário, senha ou mesmo nome de base de dados implica em seguidos erros de conexão dentro do projeto, visto que para há varias formas a mesma e não há um arquivo de configuração único para armazenar tais detalhes.

Imobilidade

A falta de padrão peca em mais alguns detalhes do projeto. Vários desenvolvedores participaram de se desenvolvimento, cada um com o que eles próprios chamavam de POO e naturalmente desenvolveram tinham milhares de dependências ou mesmo, eram tão específicos que os impediam de ser reutilizados em outro projeto semelhante.

Viscosidade

Alterações em determinados módulos se tornam tão custosas que são evitadas ou até mesmo, se arruma um “jeitinho” para evitar uma refatoração de código que levaria um tempo considerável diante da situação atual, mesmo sendo uma opção válida para a situação.

Requisitos Variáveis

A falha na comunicação durante o levantamento de requisitos torna ainda mais difícil lidar com os requisitos variáveis do projeto. As idas e vindas de uma regra ou outra de negócio e a guerra de “egos” entre os stakeholders para atender ou não um requisito violam o projeto original, e tudo termina por alterações grosseiras de código para criar uma funcionalidade e atender uma especificidade de uma determinada área.

Gerenciamento de Dependências

Podemos notar que o projeto em questão convive diariamente com os quatro cenários acima, nos fazendo repensar a continuidade de seu desenvolvimento. A falta de planejamento e padrões durante o seu desenvolvimento tornou alguns dos mais importantes módulos desnecessariamente dependentes de outros menores.

OCP

O principio base desta técnica garante a criação de “módulos” que são extensíveis, sem serem alterados. Com um pouco de planejamento podemos adicionar funcionalidades ao código, sem alterá-lo, apenas adicionando novo código.

LCP

Garante que um objeto de uma classe base deve continuar a funcionar corretamente se o mesmo é instanciado através de uma classe derivada. Outro principio que deveria ser observado durante o desenvolvimento do projeto.

Túlio César Gaio

User Story Mapping

Como podemos definir tal técnica? É uma receita de bolo? Podemos dizer que é mais uma “bala de prata”? Ou um constante desafio, dependendo do contexto? Podemos dizer que o mais interessante é sua característica colaborativa que propicia uma discussão entre a equipe sobre as funcionalidades, incluindo uma ótica da experiência de uso dos usuários. Dificilmente destacaremos apenas vantagens de uma metodologia, embora em um cenário com premissas favoráveis, notam-se muitas vantagens em sua adoção.

Vale salientar alguns detalhes que se destacam em sua adoção. A técnica ajuda a equipe a escolher um conjunto de funcionalidades que sejam imediatamente valiosas do ponto de vista do negócio e ao mesmo tempo úteis para os usuários, desde que a equipe seja multidisciplinar ou tenha papéis bem definidos com poder para tomada de decisão. Ajudando na priorização e no planejamento de releases, obtemos detalhes sobre o usuário, freqüência de uso da funcionalidade e valor que ela tem para o negócio.

Os dois últimos itens acima merecem atenção especial, visto que, para projetos que temos uma prévia experiência sobre o assunto, seja ela fruto do conhecimento da equipe ou mesmo de outros projetos presentes no mercado, tais variáveis são mais simples de mensurar. Do contrário, em um projeto inovador, uma vez que o modelo ainda não está estável o suficiente, não existe dentro da equipe um consenso em relação a tais variáveis, tornando sua avaliação complexa e passível de outros métodos de análise, como pesquisas de campo, questionários, entre outros.

Ao realizar as etapas, algumas delas acarretaram discussões acaloradas. Ao realizar descrição das tarefas realizadas pelo usuário, ao adicionar informações quanto à freqüência de uso, a cada uma das tarefas das user stories, e na definição de valor para o negócio de cada user story, sendo essa de fundamental importância a participação de uma pessoa que tenha mais visão de retorno de investimento do sistema. Vale lembrar que toda equipe (e os stakeholders) podem participar destas etapas, o que naturalmente em alguns cenários torna o processo um pouco complicado de se chegar a um consenso, pois os interessados podem convergir o desenvolvimento de suas funcionalidades primeiro e sem critérios, o que necessariamente requer certa intervenção.

A idéia é contar uma história de como o sistema funciona, ajustando os cartões por criticidade verticalmente seguidos pela freqüência de uso horizontalmente, o que nos da uma visão muito clara e compartilhada do sistema como um todo, alinhando expectativas e idéias entre a equipe, afinal nesse momento no nosso mapa, sabemos as funcionalidades que não poderiam ficar de fora do release, principalmente quando estas representavam uma tarefa que fazia parte de um fluxo de uma atividade importante para os usuários.

Na definição de release o mais importante neste momento é a percepção de que todos compreendem melhor o produto que será desenvolvido. Esta visão compartilhada ajudará nas etapas posteriores de desenvolvimento do produto, quando novas idéias de funcionalidades apareceram e novos releases precisaram ser replanejados.

E finalmente e não menos importante tal técnica em sintonia com a abordagem ágil, ajuda a evitar o desenvolvimento de funcionalidades inúteis, e a manter a simplicidade da interface com o usuário. Como podemos perceber, a técnica oferece recursos para facilitar processos em metodologias ágeis, se fazendo presente e varias etapas destes processos. Mas não posso deixar de questionar: seria valido adotá-la em um processo tradicional? Seria possível usá-la isoladamente de qualquer abordagem? Creio que sim, e de forma empírica, aprender a lidar com as implicações que estariam por vir. Mas esta questão vale outra discussão!

Túlio César Gaio