AgileZ

Se você programa em alguma linguagem de programação orientada a objeto, com certeza conhece os termos “Private”, “protected” e “public” e muito provavelmente sabe para que eles servem. Métodos ou membros públicos são aqueles que podem ser acessados por outras classes, os protegidos apenas pelos descendentes e os privados só possuem visibilidade local, ou seja, dentro da própria classe. Parece simples, porém, é muito comum encontrar programadores que parecem não seguir critério algum ao definir o nível de visibilidade dos membros de suas classes, ou então aplicam alguma metodologia aleatória para este fim. Propriedades que eram protegidas são publicadas durante o desenvolvimento de outras classes clientes, conforme a necessidade. Classes “amigáveis” (class friendly) são criadas para permitir acesso a funções protegidas. Práticas como essas acabam por criar uma arquitetura extremamente confusa, com componentes de difícil entendimento, difíceis de serem testados e expandidos. Qual seria então o melhor critério para evitar esse tipo de problema?

Leia mais…

Há alguns anos, quando a internet ainda estava distante, o conhecimento era compartilhado por meio de livros ou de boca-a-boca. Era raro alguém possuir conhecimento aprofundado em vários segmentos e por isso o conhecimento era sinônimo de sucesso, garantia de emprego e prestígio social.

Com o decorrer dos anos e o surgimento da internet, um novo canal de compartilhamento de informações nasceu. Quanto mais popular e acessível a rede mundial de computadores ficava, mais fácil e palpável o conhecimento se tornava. Enquanto o autodidata de outrora era limitado pelos livros disponíveis – muitas vezes caros e em idioma estrangeiro – o autodidata dos tempos atuais tem a sua disposição bilhões de fontes de conteúdo a um clique do mouse. Começava então uma era onde o conhecimento se tornava comum e, consequentemente, deixava de ser considerado como critério de classificação e diferenciação entre as pessoas.

Se o conhecimento se tornou tão ordinário, qual seria então o novo parâmetro para diferenciação? Inteligência? Leia mais…

Seguindo a tendência do artigo anterior (Sua equipe de desenvolvimento está no caminho certo?) vou falar um pouco sobre algumas questões que nem sempre são observadas pelos programadores, mas competem para a sua imagem como bom profissional.
É muito comum, principalmente entre programadores mais novos, o ideal do código perfeito. Muitas vezes o programador novato trabalha suas habilidades com a meta de se tornar um melhor codificador a cada dia. Essa fase é plenamente justificável, e faz parte do desenvolvimento do profissional, entretanto, conforme o programador for ganhando maturidade e experiência, é necessário que ele trabalhe outras habilidades não relacionadas à codificação, que podemos chamar de habilidades não técnicas.

Desenvolvi uma lista com algumas questões que devem ser observadas por todo programador. (lista baseada no artigo de Alberto Gutierrez ).

1. Seja disciplinado:
No nosso dia-a-dia nos deparamos com diversas interrupções e tarefas paralelas. Telefone tocando, email, mensagem instantânea, colega chamando e diversas outras. Ser disciplinado significa estabelecer uma metodologia para que essas interrupções prejudiquem o menos possível o seu desempenho e produtividade. Utilização de técnicas como a técnica do pomodoro, por exemplo, é uma excelente metodologia para manter o foco em uma tarefa por vez.

Leia mais…

É difícil descrever todas as responsabilidades de uma equipe de desenvolvimento. Análise, documentação, testes, refatoração e etc. São muitas as competências exigidas, e, se cada uma delas não estiver clara para todo mundo, a chance de algo não sair conforme o esperado é grande. Pensando nisso, me baseei no artigo do Alberto Gutierrez para criar esse checklist com algumas coisas que você deve fazer para ter uma boa equipe.

1. Focar no cliente
O cliente é a razão de tudo. Sem ele não existiria o seu departamento, e, provavelmente, a sua empresa. Por isso, tenha em mente que você deve satisfazer o cliente, entregando coisas que agregam valor para ele. Focar no cliente também inclui abrir a mão de algumas coisas para entregar o que ele precisa. Por exemplo: se aquela refatoração vai atrasar a entrega de uma funcionalidade exigida pelo cliente, abra mão dela por enquanto (faça-a em outro momento mais oportuno).

Leia mais…

Você se considera uma pessoa produtiva no trabalho ou em sua vida pessoal? Quanto tempo consegue se concentrar em uma determinada tarefa antes de ser interrompido ou mudar o foco? A produtividade de uma pessoa está diretamente ligada a capacidade que ela tem de manter o foco. Quanto mais focada for, melhor e mais rápida vai atingir o objetivo, seja no campo profissional ou pessoal.

Porém, nem sempre ‘mais’ significa ‘melhor’. O cérebro humano tem um limite, e não consegue produzir com qualidade satisfatória após um determinado tempo de esforço contínuo. Cada pessoa tem um ritmo e os intervalos regulares são necessários, seja pra ver emails, conversar, fazer uma ligação ou tomar um café. Leia mais…

Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.

Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. Neste artigo vou apresentar a que é mais utilizada por equipes que empregam metodologias ágeis: o Planning Poker.

Antes de começar, devo introduzir um conceito que pode não ser conhecido ou aceito por todos: uma estimativa é da equipe e não de um programador ou analista em específico, ou seja, o ato de estimar é uma atividade de TODA a equipe, e esse detalhe é primordial para o sucesso do Planning Poker. Com isso em mente, vamos à definição:

Leia mais…

Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).

Em um cenário de desenvolvimento ágil, sem uso de TDD, o programador geralmente não conta com um modelo de classes em forma de diagramas – como outras metodologias pesadas. Por isso é comum a modelagem ser feita apenas mentalmente, em algum outro formato (rascunho em papel de pão?) ou até mesmo diretamente no código. As classes, operações e atributos vão surgindo conforme a necessidade, e são constantemente alterados e implementados até a conclusão da tarefa associada. Eventualmente, alguns testes de unidade são implementados baseando-se nas classes já prontas. Leia mais…

Quando trabalhamos com equipes mais enxutas, utilizando metodologias ágeis (como o Scrum), temos um considerável poder de decisão e planejamento sobre o que será implementado em cada build. Digo considerável pois existem vários fatores que influenciam o que fará parte do seu sprint (sprint é uma interação que segue o ciclo PDCA e entrega incremento de software pronto), como a priorização do Product Owner (o cliente), tamanho estimado para cada uma das user stories que farão parte da interação, restrições técnicas e outras.

Durante o processo de estimativa, é comum decompormos as user stories em várias tarefas menores, com o objetivo de facilitar a pontuação de cada uma delas. Esse processo é adequado e, se bem feito, aumenta muito a precisão das estimativas, porém, ao quebrar uma solicitação em atividades menores, corremos um sério risco de perdermos de vista o real objetivo de cada uma das tarefas, que é contribuir para a conclusão de um recurso solicitado pelo cliente. Convém não esquecermos que, para o cliente, essas pequenas atividades geralmente não possuem valor por si, a não ser que todas sejam feitas e a feature solicitada seja entregue. Leia mais…

Programar muitas vezes é considerado como sinônimo de codificar, ou seja, escrever código para ser compilado. A importância de um bom algoritmo na qualidade final de um software é indiscutível e não pretendo levantar discussões a este respeito por aqui, mas colocar em pauta outro aspecto – que também é programação – porém nem sempre tem a atenção merecida: a interface gráfica, ou, mais precisamente, a interface de usuário (IU).

Assim como a parte que fica por debaixo dos panos (o código) a interface gráfica tem uma importância fundamental para o sucesso de seu sistema. Padrões de projeto (Design Patterns), Grasp, POO, POA e etc. São inúmeras as técnicas existentes para auxiliar a construção de excelentes softwares. Mas, quantos de vocês conhecem alguma para desenhos de interfaces gráficas? O que deve ter em mente o programador ou projetista de interface para construir uma boa IU?

Leia mais…

A programação orientada a objetos é, de longe, o paradigma mais utilizado em programação. Com várias décadas de existência, (apesar de muita gente não saber, a OO surgiu com as linguagens SIMULA I (1962-65) e Simula 67 (1967)) evoluiu bastante, porém, é muito comum encontrar projetos com problemas de arquitetura dos mais diversos tipos, entre eles, problemas de coesão, acoplamento desnecessários, generalizações inconsistentes e outras.

O intenção deste artigo é introduzir o conceito de GRASP (General Responsibility Assignment Software Patterns), que, conforme o nome já diz, tem o objetivo de tornar a distribuição de responsabilidade entre as classes uma tarefa mais criteriosa e eficiente, melhorando de forma significativa a qualidade de seu projeto e reduzindo os problemas de arquitetura mais comuns.

Leia mais…