Como em outro post já falamos de práticas ágeis de projeto, achei importante falar também das questões filosóficas que norteiam tais práticas. Então vamos a algumas delas:

Projetos ágeis são emergentes, eles não são definidos de imediato. A visão completa de todo o projeto será evoluída ao passo em que são levantados novos requisitos, e a medida que surjam novas tecnologias que possam ser úteis. Assim, não se faz necessário criar uma documentação completa do projeto antes de iniciar a implementação.
 
Os testes de unidade formam grande parte da documentação detalhada do projeto, ou seja, são especificações executáveis. É também por esse motivo que o TDD (desenvolvimento dirigido a testes) torna-se fundamental em projetos ágeis.
 
Basta que os modelos de projeto seja bons o suficiente, e que os detalhes de projetos sejam ajustados à medida que se codifica.
 
Diversos modelos. Devido à complexidade inerente ao desenvolvimento de software, os desenvolvedores necessitam de um amplo conjunto de modelos que permitam ter várias visões sobre o mesmo projeto.
 
Normalmente, só é necessário um subconjunto dos modelos para cada parte do trabalho a ser realizado durante a codificação do projeto.
 
Cada modelo pode ser usado para uma variedade de finalidades no processo de codificação.
 
Projetistas também deveriam codificar. Separar a fase de especificação do projeto da fase de codificação do projeto é arriscado, e isso também inclui as pessoas envolvidas em cada fase.
 
Modelo à prova. Sempre que possível, é importante por o modelo à prova, antecipando possíveis impactos ou obstáculos.
 
O feedback é seu amigo. Ser receptivo ao feedback, ou mesmo buscar ativamente o feedback, analisá-lo e agir em conformidade tornará o sistema melhor (de forma reflexiva, será melhor recebido pelos usuários), e provavelmente você irá aprender algo durante esse processo.
 
Às vezes, a ferramenta mais simples é uma ferramenta CASE complexa. Quando se trata de formalizar os requisitos levantados em modelos, às vezes é melhor usar ferramentas sofisticadas que possam gerar código.
 
Iterar repetidamente. Iterar entre as etapas, de forma que seja feito um pouco do trabalho em cada uma delas, de acordo com o necessário, ou mesmo iterar de frente para trás trabalhando em vários artefatos, cada um no momento certo.
 
Projetar é tão importante que deve ser feito todos os dias. Projetar não é apenas uma fase que se realiza no início do projeto antes de se chagar ao “trabalho real” de codificação.
 
Projetar no ambiente de implementação com bastante sensatez. É importante fazer uso das facilidades e recursos do ambiente de implementação, mas isso deve ser feito com muito cuidado para que não faça o sistema perder a portabilidade e tenha problemas quando o mesmo for instalado ou quando já estiver em produção.
 
Documentar o que for complicado. Se é complicado, então documente completamente, e invista um tempo para projetar bem um modelo.
 
Sem excessos na documentação. Como existe uma linha tênue entre documentar e se exceder nisso, apenas a prática lhe dirá como e até que ponto documentar.
 
Não se deixe enganar pelo pessoal tradicional em banco de dados. É importante compreender que a estrutura da base de dados também irá evoluir com o projeto, ela não será estática.
 

Referências: