Leitura obrigatória para todo programador, especialmente para os pragmáticos. O Programador Pragmático se concentra no processo fundamental do desenvolvimento de software: a partir de um requisito, produzir código funcional e de fácil manutenção que agrade valor aos usuários sem se ater a uma tecnologia específica, esta obra aborda tópicos que vão do desenvolvimento da carreira a técnicas de projeto para manter seu código flexível e fácil de adaptar

Uma das dúvidas mais comuns que chegam até mim, vindas dos alunos da Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis é como implantar o Scrum na empresa que eles trabalham.  Bom então sem conversar muito, segue um excelente auxílio. Três exemplos de Scrum checklist onde você poderá se orientar se o que você está implementando é Scrum ou ScrumBut. 

Neste sábado, dia 17/03, fizemos o nosso primeiro Coding Dojo com nossos alunos de ADS do 3º, 4º e 5º períodos dos campus Barreiro e Barro Preto da UNA. Tivemos a grata surpresa de 20 alunos presentes que ficaram programando, de forma entusiasmada, das 10:00h às 14:30 do sábado. Como desafio, fizemos um dos exercícios que passei para a turma do 3º período de POO.

Nas práticas do Coding Dojo incluem práticas de XP entre outras como: Programação em par, baby steps, TDD(Desenvolvimento Dirigido por Teste) refatoração e design simples. O nosso Dojo foi no estio KATA, onde o problema é resolvido ao vivo e o piloto e copiloto se alternam a cada 5 a 10 minutos. Os alunos saíram bastante motivados e ansiosos para o próximo sábado.

Este Dojo está acontecendo na UNA, campus Aimorés, 5º andar. Quem tiver interesse em participar, entre na lista do dojo no google groups e se mantenha informado dos próximos encontros.  https://groups.google.com/group/dojo-una

Obs: Este Coding Dojo é aberto à comunidade!  

O enunciado e o código fontes estão no github: https://github.com/edgarddavidson/DojoUna01

Veja em anexo as fotos de como foi e a retrospectiva. 

Em meus últimos post tenho falando bastante sobre qualidade. Já falei um pouco sobre  Qualidade em Processo de Desenvolvimento de Software e sobre Qualidade com Foco no Produto de Software. Neste post concentro em o que deve ser feito para obter qualidade no código fonte.

Recentemente eu tive a oportunidade de palestrar no devday 2011. Minha palestra foi sobre "Qualidade de código: boas práticas, princípios e padrões". Neste post, abordo o mesmo assunto da palestra, mas antes disso, vou apontar alguns "code smell" (mal cheiro) que são frequentemente encontrados nos códigos dos programadores. Muitos dos referidos "code smell" são causados por uma má gestão das dependências no código. Baixa coesão e alto acoplamento são um dos fatores fundamentais para aumentar a dependência, dificultar a manutenção, expansão e alteração. No livro  Agile Principles, Patterns, and Practices in C#, o Robert Martin (uncle bob) destaca alguns "code smell" causados por esse tipo de deficiência:

Olá Pessoal.

Este é o segundo post de uma série de post's que estou fazendo, em formato de resenha. Como partida, estou lendo o livro Management 3.0 Leading Agile Developers, Developing Agile Leaders e sintetizando ele aqui. Confira aqui a parte 1. 

Olá Pessoal.

Este post é o primeiro de uma série de posts que pretendo publicar, em formato de resenha, sobre "livros que estou lendo". Como partida, fiz a primeira de várias outras do livro Management 3.0 Leading Agile Developers, Developing Agile Leaders.  O livro pretende mostrar como ser um bom gerente ágil. A base para isso é o entendimento sobre pessoas e sistemas e a maneira como as pessoas pensam sobre sistemas. Antes de tudo, os gerentes devem compreender como sistemas sociais funcionam.

Na definição da teoria da criação do conhecimento organizacional [Nonaka e Takeuchi, 1995] definiram duas dimensões para a criação do conhecimento: 

i) a dimensão epistemologica: onde é feita uma distinção entre o conhecimento tácito e o explícito para a criação do conhecimento. Essa distinção corrobora com a estabelecida por [Polanyi, 1967]. O conhecimento tácito é individual, pertence a pessoa é específico ao contexto e é difícil de ser registrado e compartilhado. Já o conhecimento explícito pode ser registrado em meios físicos ou digitais em linguagem natural, formal, ou sistêmica;

ii) a dimensão ontológica: onde enfatiza a criação do conhecimento organizacional em oposição à criação do conhecimento individual, passando por vários níveis de criação do conhecimento (individual, grupal, organizacional e inter-organizacional).  

Princípio da única Responsabilidade:

"Nunca deve haver mais de um motivo para uma classe ser alterada"

Cada responsabilidade constitui-se uma dimensão de mudanças.  Se uma classe tem mais de uma responsabilidade, então haverá mais de uma razão para alterá-la.  Quanto mais responsabilidades há numa classe, mais frágil (maior risco de para de funcionar) torna-se o projeto.