AgileZ

Há alguns meses vi um post muito interessante e criativo sobre a montagem do agile board da BlueSoft. Os curiosos podem acessá-lo aqui. Desde então fiquei tentado a aplicar a idéia na empresa onde trabalho e montar para minha equipe um quadro magnético na parede. No entanto, não é uma solução muito barata, a sala é pequena, e se nossa equipe aumentar teremos que mudar de sala… e lá se vai todo o trabalho de pintura.

Utilizávamos um quadro de feltro verde que não recomendo. Por baixo do feltro o que existe é um papelão fajuto (isso mesmo!) que após alguns furos perde o tônus e não segura mais nada. Por sorte, encontramos uma alternativa bem legal e de baixo custo. São placas de cortiça auto-colante que podem ser fixadas diretamente na parede.

Na foto abaixo mostramos um pacote com 6 placas dessas. Cada pacote custa R$ 26,90 e cobre meio metro quadrado.

A montagem é muito simples; basta remover o plástico protetor e posicionar a placa no local desejado. Deve-se ter cuidado com a colocação da primeira, pois as outras placas serão alinhadas com ela. Se ela estiver torta o quadro ficará fora de prumo. Leia mais…

Existe uma cultura entre os programadores na qual a máxima ‘use comentários sempre que puder e deixe seu código bem explicado’ é praticamente uma lei fundamental da programação. Pouca gente discute isso, afinal, nada como um código bem documentado para torná-lo legível, certo? Nem sempre. E é sobre esta questão que eu vou falar neste artigo. Quando devemos usar comentários? Até que ponto comentar é uma boa prática? Existem outros artifícios que podemos usar para substituir um comentário?

Para começar, vamos voltar um pouco pela história. Há muito tempo, os compiladores tinham uma limitação de memória, onde existia um limite de caracteres por arquivo compilável. Em consequência disso, os programadores eram obrigados a serem muito seletivos e econômicos ao codificar, usando o menor número de caracteres para nomes de operações, variáveis e etc. Imagine um complexo código de ordenação onde todas as variáveis tivessem apenas um caractere. A primeira variável seria a variável ‘a’, a segunda ‘b’, a terceira ‘c’. Qual seria sua reação, ao ‘tentar’ ler esse código? Um pouco confuso, provavelmente. Nessa hora qualquer um rezaria por encontrar um código bem comentado. Leia mais…

Um conceito simples, mas nem sempre bem entendido e aplicado. ‘Programar para uma interface e não para uma implementação’, você sabe o que isto significa?

Apesar deste conceito ser aplicável a projetos de software, é mais antigo que ele, e é utilizado bem antes do primeiro compilador ser desenvolvido. Um exemplo bem obvio do que é isto, pode ser encontrado na casa de qualquer pessoa: um interruptor de luz. ‘Como assim José?’.

Um interruptor de luz é um exemplo muito bom. Consiste em um botão, que liga e desliga a luz. Uma interface simples, que esconde os detalhes de implementação de quem vai utilizá-la. Para ligar a luz, basta apertar o botão, e para desligá-la, adivinhem? Aperte novamente. A implementação está bem encapsulada – o usuário não precisa entender nada de pólo positivo, neutro, 127v, amperagem ou resistência. Qual foi o pensamento do designer ao projetar um interruptor de luz? Com certeza foi algo parecido com: ‘qual o mínimo possível de informação o usuário do meu produto precisa para usá-lo?’.

Leia mais…

O AgileZ surgiu de uma idéia, ou, pra ser mais preciso, de uma necessidade pessoal de dar vazão a grande quantidade de informação que recebo diariamente em decorrência de meu trabalho como analista e programador.

Entre os assuntos que você verá por aqui, encontrará artigos sobre metodologias ágeis (XP, Scrum, TDD) e conceitos de padrões de projeto (Design Patterns, Grasp) – tudo baseado em minhas experiências – e, ocasionalmente, de colegas colaboradores -  sempre procurando enfatizar o lado conceitual, de forma que a informação possa ser facilmente aplicada a qualquer linguagem ou equipe.