Benefícios do código limpo e o custo total de ser proprietário de uma bagunça

Se você já foi um programador por algum tempo, provavelmente já teve de codificar mais lentamente devido a código ruim e mal feito. O grau de lentidão varia e muitas vezes é significativo. Equipes que se movem rapidamente no início do projeto podem se encontrar mancando a passos de tartaruga alguns meses depois. É aquela situação em que qualquer mudança, por mais trivial que seja, quebra outras partes do código e é feita com medo do impacto que irá gerar.

Conforme o tempo vai passando a bagunça e o lixo aumentam e se tornam tão grandes e tão profundos que ninguém mais consegue limpá-los. Quanto mais a bagunça do código cresce, mais a produtividade do time cai. Os gerentes acham que podem ajudar e fazem a única coisa que está em seu poder: contratam mais gente para manter o sistema. Porém, esse novo pessoal não conhece os meandros do sistema. E o pior, para conhecerem vão levar muitos meses e ainda impactar nas atividades dos desenvolvedores que conhecem (essa é a famosa lei de Brooks: "Incluir mais gente em um projeto atrasado vai atrasá-lo ainda mais"). Vão ainda gerar mais bagunça e mais código macarrônico.

Eventualmente a equipe e/ou os gerentes se revoltam e declaram que não conseguem mais trabalhar com essa base de código odiosa. A alta gerência não quer gastar tanto para refazer todo o sistema, mas também sabe e percebe que a produtividade é horrenda. Eventualmente acabam aceitando e construindo um sistema do zero, mas com as mesmas funcionalidades, para substituir o código antigo. Eu já vi esse filme algumas vezes na minha vida profissional. Você também já viu? Quem já viu sabe, portanto, que manter o código limpo de forma contínua não é apenas mais barato que deixar bagunça. É também uma questão de sobrevivência profissional.


Muitas vezes os programadores são pressionados para fazer o código de qualquer jeito, para atender seus prazos e cronogramas. Muitas vezes precisam também passar horas em claro vomitando linhas e linhas de código ruim. Temos que frisar outro ponto importante, tanto para desenvolvedores como para seus gerentes: Vocês NÃO cumprirão o prazo fazendo bagunça e escrevendo código porcaria. Pelo contrário, a sujeira vai te atrasar instantaneamente e irá forçá-lo a estourar o prazo. A ÚNICA forma de cumprir o prazo e a única forma de se mover rápido é manter o código o mais limpo possível o tempo todo.

Portanto, para ser um excelente programador siga sempre a regra dos escoteiros: Deixe a área do acampamento ainda mais limpo do que quando você a encontrou. Isto é, não limpe só o seu código mas também o código de outros que você precisa modificar. Não precisa ser uma mudança gigantesca. Mude o nome de uma variável para algo que faça mais sentido, quebre um método que esteja muito grande, elimine alguma duplicação de código, refatore um conjunto de ifs encadeados. Se todos limparem um pouquinho de código a cada check-in, a base de código sempre se manterá organizada e limpa.

Vamos supor que agora você acredite que escrever código tosco, ruim, fedido e macarrônico gera impedimentos significativos. Vamos dizer que você aceita a idéia de que a única forma de desenvolver com velocidade alta é ter uma base de código limpo. Você então deve estar se perguntando: "Como eu posso escrever código limpo? E mais, como posso identificar se um código é limpo ou não?". Bom, é aí que entra algo que todos os desenvolvedores deveriam fazer mais em suas carreiras: LER!

Algumas dicas iniciais de livros (há muitos mais, mas é melhor começar com os melhores :-) !) que te farão um melhor programador (confie em mim e leia os livros abaixo todinhos. Mas não leia apenas... ATUE no seu dia a dia usando o que aprendeu):

- Clean Code de Robert Martin
- Code Complete de Steve McConnell
- Emergent Design de Scott Bain

Vamos buscar uma maior qualidade e produtividade para a área de TI e todos sairão ganhando: clientes, fornecedores, desenvolvedores e o Brasil.

Usando o Rational Team Concert ( RTC ) para desenvolver aplicações C e C++

Escrevi já dois artigos sobre o Rational Team Concert (RTC). O primeiro artigo fala da solução de uma maneira geral. O segundo artigo mostra as novas funcionalidades da versão 1.0.1 e a novidade do uso do Rational Team Concert com o mainframe. Hoje vou comentar um pouco do uso do Rational Team Concert para projetos desenvolvidos em C e C++.

Primeiro, devemos lembrar que o Rational Team Concert possui uma série de ferramentas colaborativas em sua base e um tripé formado por: sistema de planejamento de projeto baseado em um issue tracker, controle de versões integrado com o planejamento e um sistema de integração contínua para builds automatizados também integrado com o controle de versões e o planejamento de projeto.

Utilizar o RTC para desenvolver e controlar colaborativamente um projeto nas linguagens C e C++ é muito fácil. O primeiro passo seria ter no seu ambiente Eclipse o cliente do Rational Team Concert instalado (não esquecer de instalar e configurar o servidor Jazz!), bem como o famoso plugin Eclipse CDT. O Eclipse CDT é um plugin para o Eclipse que facilita bastante o desenvolvimento de aplicações C e C++.

Toda a fundação colaborativa e mais o sistema de controle de versões e o sistema de gestão de incidências funciona da mesma forma para desenvolver as aplicações C e C++. Todo o modelo de planejamento e controle de versões é igual e está integrado diretamente no Eclipse e em seus plugins.

O que muda, mas não gera tanto trabalho, é configurar o sistema de integração contínua para compilar e gerar o executável da aplicação em C e C++. O Rational Team Concert permite a customização da gestão automatizada de builds. Você pode configurar quantas vezes ele irá executar, em que períodos, etc. Mas, o mais importante é que ele permite que você execute qualquer aplicação de linha de comando. Não necessariamente devem ser as ferramentas de build Ant ou Maven. Portanto, você pode facilmente configurar a execução de um makefile!

Usando o Rational Team Concert em seus projetos C e C++ você ganhará produtividade, qualidade, o uso de processos ágeis de desenvolvimento de software ( como o Scrum ou o OpenUP ) e ainda a governança do seu desenvolvimento de software com pouquíssima burocracia e chateação para os desenvolvedores!

Caso tenha interesse em mais detalhes sobre o Rational Team Concert (na solução Java, C, C++ ou .NET) é só deixar seu comentário ou entrar em contato direto comigo.

O que impede uma organização de mudar do desenvolvimento tradicional para a agilidade e o pensamento lean?

Acabei de finalizar a leitura do livro recém lançado The Art of Lean Software Development: A Practical and Incremental Approach de Curt Hibbs, Steve Jewett e Mike Sullivan.

No capítulo 2 os autores fazem a grande pergunta: se está claro (através de diversas pesquisas e casos reais) que o desenvolvimento tradicional e cascata frequentemente falha e que o desenvolvimento ágil e lean ( enxuto ) aumenta as chances de sucesso, o que impede as pessoas e organizações de fazer a troca?

Há muitas razões, mas os autores acreditam que duas são as principais: Medo e Confusão. Se manter no mesmo padrão de desenvolvimento pode parecer um caminho mais seguro (o antigo ditado "ninguém jamais foi demitido por comprar da IBM" pode ser adaptado para esse caso). Lutar pela implantação de um processo ágil e enxuto pode dar a sensação de ir atrás do novo e expor a carreira a um risco.

As pessoas podem se imaginar convencendo o chefe a adotar práticas ágeis e lean, vendendo a promessa de alta produtividade e maior qualidade. Agora é o pescoço dessa pessoa que está na corda para provar que isso pode acontecer. Há tantas novas práticas para entender e implementar (algumas que requerem treinamento técnico específico como o TDD, por exemplo). Além disso, a gerência ainda pode acabar inconscientemente (ou até conscientemente) sabotando o projeto ao periodicamente "pegar emprestados" recursos para outras tarefas ou amentando o escopo do projeto sem eliminar outras funcionalidades. E pior, a pessoa pode ainda não ter experiência suficiente para reconhecer os impactos que essas e outras ações terão nas promessas feitas.

No final, a pessoa possui medo de ser declarada a culpada de entregar o projeto fora do prazo e com orçamento estourado. E tudo porque ela insistiu em usar essa "nova onda de processos ágeis"!

Esse é o tipo de medo que acaba segurando muitas pessoas. É o mesmo medo que encontra-se em empresas que preferem não inovar para não canibalizar seus produtos existentes. É o medo clássico que dificulta qualquer tipo de mudança organizacional em empresas de qualquer porte. E é o medo que acaba levando muitas empresas a desaparecer por falta de inovação e criatividade.

Some a isso a confusão que uma pessoa tem quando entra no campo de conhecimento do desenvolvimento ágil e enxuto ao se deparar com centenas de livros, artigos, ofertas e soluções.

Concluindo, o medo e a confusão juntas se tornam a receita perfeita para a paralisia! Mostrar os benefícios já comprovados de se adotar metodologias ágeis e conseguir o comprometimento de toda a organização para a adoção é um passo essencial para eliminar o medo. Os livros sobre mudança organizacional de John Kotter podem ajudar nessa tarefa hercúlea. A confusão pode ser mitigada utilizando-se livros, treinamentos e consultoria especializada em processos ágeis e enxutos. Estes instrumentos podem acelerar uma adoção com menos percalços.

Em próximos artigos pretendo comentar sobre as diferenças conceituais dos termos Lean e Agile. Também pretendo tratar de um assunto pouco comentado nos círculos ágeis e que considero fundamental: a agilidade e o pensamento enxuto como instrumentos para alcanlçar resultados relacionados à estratégia competitiva de uma organização que desenvolve software como atividade meio ou atividade fim .

Artigos sobre Agile em publicações do PMI

Alguns artigos tratando sobre o desenvolvimento ágil e gestão ágil e enxuta (lean) de projetos apareceram em publicações ligadas ao PMI (Project Management Institute).

Leitura interessante, para reforçar o que está perceptível nos países desenvolvidos: Agile virou mainstream e, apesar de percalços e erros de adoção, já é discutida por uma grande fatia do mercado de lá. É interessante notar também que muitos dos gerentes de projeto que estão adotando processos ágeis são PMPs.

No artigo Agile Software Development Projects Enable Adaptability and Success (subtítulo: Agile may be the cure for overdue, high-cost software development projects) o PMI descreve como o número de projetos de desenvolvimento de software entregues no prazo, no custo e com os requisitos necessários aumentou graças à maior adoção de processos ágeis. Eles utilizam o Chaos Report como evidência desse aumento de projetos bem sucedidos.

O outro artigo pode ser encontrado na revista PM Network, que é distribuída para os associados do PMI. Ele pode ser encontrado online na edição de janeiro de 2009. Procure, clicando em Contents, pelo título do artigo: "The Incredible Shrinking Team".

Agora basta a adoção aumentar aqui no Brasil, para não ficarmos para trás em produtividade e qualidade de software. Senão o melhor é ficar só exportando commodities agrícolas mesmo, porque não teremos chance de competir :-) !!!

Livros sobre o papel do Product Owner

Robert Galen está escrevendo um livro sobre como se tornar um excelente Product Owner. O livro ainda está na fase de draft e está disponível online gratuitamente. Já possui um pouco mais de uma centena de páginas e é uma leitura fortemente recomendada para quem vai assumir esse crucial papel dentro de um projeto ágil.

Outra autora, Ana Forss, também escreveu uma introdução sobre o papel do Product Owner. O título do ensaio é Confessions of a Serial Product Owner .

Só para relembrar: o papel do Product Owner, dentro um projeto Scrum ou ágil, é o de definir as necessidades e requisitos do produto e também determinar o valor para o negócio e as prioridades de cada requisito. É ele quem gerencia o valor do Product Backlog.