Um ótimo gerenciador de projetos, muito flexível, e com várias opções e “atrações” para sua equipe se integrar perfeitamente ao desenvolver seu projeto.
Ele é escrito em RoR (Rub on Rails).

De cara vi algumas coisas interessantes. Ele tem:
- Gerenciamento de multiplos projetos
- Multi usuario, com gravatar, e notificações por email
- Configuração de página incial como se fosse um Dashboard, com informações que você escolher.
- Controle de Issues por projeto
- Notícias
- Wiki por projeto
- Fóruns por projeto
- Adição de arquivos ( anexos ) por projeto
- Integrado ao controle de versão ( SVN, Git, etc… )
- Permissões específicas e configuráveis para cada item.
- Papéis de projeto
- Controle de Fluxo
- Campos customizados para projetos, usuários, issues
E várias outras coisas !

Só sei que achei o sistema para utilizar com meus projetos e para mim este é o melhor, me atendeu 100% ! E detalhe, o Redmine pelo que percebi é direcionado para projetos de software somente.

Link: http://www.redmine.org

Saiba mais no wiki do sistema: http://www.redmine.org/wiki/redmine/Features

Related posts:

1. Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
2. Qualidade de software – O quê ? Como ? Quando ? Onde ?
3. Qualidade de software. o que aprendi…

Bom, chegando de fato no que interessa, como podemos manter a qualidade de nosso software (aqui chamado de ‘sf’) ?

Definição/Análise:
+ Tudo começa do início, e o inicio de um software é a sua definição. O sf deve ser bem definido no inicio de cada etapa, para que não haja alterações em seu escopo, alterando assim em cascata todo o resto. Defina bem com o cliente tudo que ele quer, e todas as etapas de entregas, e ainda assim deixe uma gordurinha para poder mexer neste plano, pois ele irá alter , com certeza ! Mas quanto menos alterar, melhor.

Projeto
+ O projeto é um ponto importante. Se bem feito, o desenvolvedor tem toda a documentação necessária para montar o sf. O projeto tem que especificar cada detalhe das telas, das ações e validações do sf. Os icones e imagens utilizadas, de onde e para onde vai cada informação, o que é esperado que o usuário faça, as rotinas de background, tudo deve ser definido e detalhado no projeto. Uma boa prática para o projeto é se ter um documento com os padrões, ou seja, aquilo que é igual em qualquer lugar do sf. Assim teremos uma boa organização e consequentemente uma maior agilidade no desenvolvimento.

Desenvolvimento
+ O bom desenvolvimento depende de cada desenvolvedor. Cada pessoa tem sua característica e sua forma de trabalhar, o mais correto é agrupar os desenvolvedores de forma que sejam melhor aproveitados com o que mais sabem fazer. Tem gente que cria frameworks, tem gente que cuida de ambientes, tem gente que desenvolve rotinas background, tem gente que desenvolve telas e front-ends, e assim vai. O Gerente é que vai notando isto ao longo do tempo, com a comunicação com seu time. O gerente deve conhecer cada um para melhor aproveitá-lo neste passo. No desenvolvimento, a comunicação entre os desenvolvedorres é também algo muito importante, pois assim se transmite e recebe conhecimentos, principalmente dos detalhes da implementação.

Testes
+ Um sf bem testado é um sf funcional. A mania de testar o que se cria deve vir de berço. Cada desenvolvedor deve testar incansávelmente seu código, tentar melhorá-lo se possivel, e re-testar ! Existem vários métodos de teste: Testes Unitários, Testes de Caixa Branca, Testes de Caixa Preta, Testes de Integração, Testes Livres, entre outros, e se em cada etapa da liberação de um código, for aplicado um tipo de teste, ao chegar no build final o sf vai estar quase 100%. As vezes é bom trocar as pessoas que fazem os testes, porque teste vicia ! Isto mesmo, se a mesma pessoa for fazendo todos os testes, chega um ponto que, inconcientemente, ela não vai testar algumas partes so sf pq acha que já testou e que vai funcionar igual. Outro grave engado! Por isto temos várias formar de automatizar os testes, assim, uma vez criado o teste para um ponto específico, este sempre se repetirá, e assim vai pegar qualquer problema que possa ter sido gerado. Os bugs não devem ser pegos pelos clientes, mas sim ainda dentro da sua geração. E quanto mais cedo for descoberto este bug, mais barato vai se tornar para arrumá-lo, pois cada minuto de um desenvolvedor, analista, projetista, dba e gerente custa dinheiro para a empresa, e geralmente muito dinheiro, sendo assim, se o problema é pego pelo cliente vai se levar muito mais tempo para verificar o problema, ajustar o projeto se necessário, o desenvolvedor voltar a entender aquele pedaço de código e aí sim arrumar, sendo que se o desenvolvedor mesmo pegar seu bug quando ainda está com a lógica fresca na cabeça, vai demorar apenas alguns minutos para arrumá-lo.

Documentação
+ Tudo em um projeto de sf completo deve ser documentado. TUDO ! Não deixe que as pessoas tenham total ou algum domínio sobre o conhecimento do sf sem que isto esteja escrito e detalhado, pois um dia elas podem esquecer, ou de repente, outra pessoa não sabe o que fazer e se não tem na documentação, vai inventar! Desde processos para a criação do sf, para desenvolvimento, padrões de documentação, de projeto, de análise, de estatísticas, tudo deve estar disponível para todos do projeto. E também assim, qualquer mudança nestes documentos, afetarão a todos e as informações se propagarão muito mais fácil.

Storage
+ Defina onde vão ficar todos os artefatos e códigos do seu projeto. Deixe acessível a todos. Defina qual controle de versão irá utilizar, defina qual sistema de bugs irá utilizar, defina um lugar, obrigatóriamente com backup, e preferencialmente diário, onde ficarão seus documentos do projeto. Isto é muito importante e garante uma saúde para o projeto. Informe os dados e locais para todos.

Padronização
+ Em todos os processos do projeto de sf, a padronização é importantíssima. No código, nos documentos, nos processos, e é importante seguir rigorozamente esta padronização, para que se tenha total controle do que é feito e como é feito. Ficando muito mais fácil pegar qualquer deslize que possa gerar um problema maior mais a frente. Por exemplo, quando um novo desenvolvedor entra no projeto, este deverá aprender não a programar, mas sim os padrões do projeto, sendo que qualquer um poderá ensiná-lo sem pestanejar, e todos trabalharão da mesma forma, gerando agilidade e uma pequena curva de eprendizado. Se o padrão existe e está documentado, é pq, por algum motivo aquele padrão é o melhor para o projeto, e se todos seguirem, estarão fazendo o melhor possível. Claro, que padrões e processos são discutíveis, pq sempre queremos melhor! Mas estando definido, siga-o !

Eu acho que é isto aí pessoal, este são meus conhecimentos adquiridos ao longo da minha humilde carreira de desenvolvimento, e acho que é interessante compartilhá-lhos com vocês.
Comentem e digam o que vocês acham.

Vejam também: Desenvolver, mas com o quê ?

Related posts:

1. Qualidade de software – O quê ? Como ? Quando ? Onde ?
2. Crescimento do Ubuntu ( e software livre )
3. Desenvolver… mas com quê ?

Mas diferenças entra linguagens não é o foco do post, mas sim como escolher com o que programar para resolver o meu problema.

Acho que cada um sabe do seu problema melhor do que ninguém. Por exemplo, no foco da web ( que é onde estou neste momento ): devo utilizar uma linguagem/framework que me dê mais agilidade mas que me deixe muito fixo em uma linha de programação, ou uma linguagem/framework que me deixe livre para criar da maneira que quero, mas porém isto vai custar um tempo…

Bom, o que eu gosto de fazer, é seguir alguns padrões de desenvolvimento, que sempre é muito bom, pois facilita o entendimento da infraestrutura do aplicativo, e depois do ponta-pé inicial, torna-se mais fácil a manutenção do software, justamente popr seguir um padrão. Gosto de utilizar frameworks, pois também seguem algum tipo de padrão, assim , procuro definir com que frameworks meu software será desenvolvido, antes mesmo de iniciar a produzí-lo, e traçar uma linha de raciocínio, desenvolvendo-a até criar uma gama de processos mais maduros.

Mas qual framework utilizar ?
Escolha o fm que lhe dê as features necessárias, sem degringolar demais seu aplicativo. Ou seja, um fm que não tenha milhões de coisas a mais do que você precisa, honerando assim o poder de processamente, nem um fm que tenha somente a metade das coisas ou que gere muito trabalho a mais para conseguir montar o processo que você necessita. Ou seja, você deve avaliar os vários fm que tem para cada tipo de software e para cada tipo de atividade, e ver qual mais se encaixa ajustadamente eu seu propósito. Lembre-se: A melhor ferramenta é aquela que faz o que você precisa !

Aqui cito alguns frameworks que conheço, tanto de ter trabalhado já ou só de ouvir falar pela internet, e aqui, estou falando somente os poucos que conheço para desenvolvimento web, mas existem milhares de fm para todos os fins.
PS: Caso queiram citar mais alguns, de qq linguagem, por favor, comemtem abaixo que completo o post…
Java:
Spring Framework – Framework Completo para uma aplicação Web e não Web. Todo modular.
Struts – Framwork MVC para web somente.
Ruby:
Ruby on Rails – Conhecidíssimo pela sua agilidade para desenvolver, e média curva de aprendizado.
Python
Django – Não sei se é somente um framework, acho que na realidade é mais do que isto, é todo um ambiente de desenvolvimento de execução que também gera muita agilidade.

Mas qual padrão seguir ?
Padrões de projeto e de desenvolvimento são somente definições que nos ajudam a organizar melhor nosso projeto e nosso software ( neste caso ), sendo assim, se você for trabalhar com uma equipe média ou grande, e for desenvolver um software que vai ser necessário uma manutenção posterior, ou um contínuo desenvolvimento, é sempre bom seguir os padrões de dedsenvolvimento do mercado, onde temos muitos que são já bastante extressados e assim possuem uma maturidade importante em seus processos e definições. Agora, se você vai fazer um software pequeno, curto, com poucos pessoas ( você mais 2 ou 3 ) e que não tem tanta complexididade, talvez seja mais demorado aplicar todo um padrão de desenvolvimento de mercado emcima deste software, do que apenas definí-lo de uma forma clara, e desenvolve-lo assim que possivel, gerando assim mais produtividade.

Todas estas são opiniões pessoais.

Related posts:

1. Spring Framework – A real framework !