/* CODIFICANDO */

Em meu emprego atual eu assumo diversos papéis diferentes: Eu sou o analista de sistemas para aplicações que já estão em produção, DBA para os respectivos bancos de dados e analista/desenvolvedor para uma nova aplicação de médio porte. Este último item é minha atividade principal na empresa no momento.
Este cenário de “equipe de um homem só” tem me mostrado que, assim como muitas outras coisas na vida, desenvolvimento de software não é algo tão exato. Não existe uma receita pronta e infalivel para que se cumpra as tarefas. Desde a disciplina de Engenharia de Software na faculdade, até o Livro do Craig Larman, passando por outros pontos de estudo, aprendi os diversos aspectos de um projeto que devem ser especificados, controlados e seguidos, bem como a divisão natural de responsabilidades. Mas ao tentar aplicar ao pé da letra estes conceitos em meu projeto atual percebi, mais uma vez, que a prática está longe de ser igual à teoria.
Isso me leva a analisar de uma maneira mais prática os diversos tipos de documentação utilizados em projeto de desenvolvimento de software. Dentre eles cito dois que considero apresentarem problemas para o tipo de projeto que estou desenvolvendo:
- Requisitos de Software: A análise de requisitos é um dos pontos mais importantes de qualquer projeto, pois ali são traduzidas as reais necessidades do cliente. Para que os requisitos sejam coletados é necessário um trabalho de “entrevistas” com o cliente, para tentar coletar o máximo de informação em relação às funcionalidades da aplicação. Mas qual é o nível ideal de detalhamento para os requisitos? Quando o material coletado é suficiente? Segundo minha humilde experiência, diz que o nível de detalhamento depende de dois pontos críticos: O conhecimento do contexto do problema por parte da equipe e a facilidade de novas “entrevistas” quando necessário.
No meu caso, como trabalho diretamente dentro do cliente, tenho uma facilidade muito grande de a qualquer momento tirar qualquer tipo de dúvida, logo os requisitos vão naturalmente tendo seu nível de detalhamento sendo incrementado. Como o único envolvido de maneira próxima no desenvolvimento sou eu, a maneira como os requisitos são escritos também é mais simples, uma vez que já estou bem a par do contexto de utilização da aplicação. Isso me poupa tempo com burocracias e controles que de outra forma poderiam até memso atrasar meus prazos.
- Diagramas UML: UML é uma ótima ferramenta para modelar o problema.
Pode ser utilizada desde a fase de coleta de requisitos, com diagramas de caso de uso, até a fase de criação dos componentes de software, classes e padrões de projeto utilizados. Entretanto, saber dosar a quantidade de diagramas a utilizar, quais pontos do projeto deverão ser abordados com esta técnica e qual o nível de detalhamento dos diagramas é uma tarefa que pode poupar muito tempo. Vejo também que a utilização da UML não tem por objetivo servir apenas como documentação após a aplicação ter sido posta em produção. Acho que sua melhor utilização é servir como um eficiente meio de comunicação entre os desenvolvedores que fazem parte da equipe do projeto. Através dos diagramas, é muito mais simples para o desenvolvedor perceber o que deverá ser implementado naquele ciclo de desenvolvimento. Para quem trabalha sozinho, entretanto, ter que criar diversos diagramas somente porque as “boas práticas” dizem que isso deve ser feito, não agrega valor algum ao projeto. Obviamente a UML deve também ser utilizada por profissionais que assumem sozinhos todo o desenvolvimento, por ser uma ferramenta de análise muito poderosa, mas também é uma ferramenta que exige bom senso para ser utilizada.

Dentre diversos outros pontos, os citados acima mostram que para desenvolver de maneira ágil devemos ter em mente que devemos controlar nossos projetos, que devemos documentá-los e que devemos utilizar ferramentas de análise para nos auxiliar, porém a melhor ferramenta de todas é o bom senso. Em muitas situações a experiência vai falar mais alto, em outras teremos que utilizar somente nosso “faro”. Fica a conclusão de que controle nenhum é terrível e não funciona, mas controle em excesso é improdutivo e pode até mesmo levar o projeto ao fracasso. Os prazos estão lá, não há como mudá-los de maneira simples. O desenvolvimento deve ser ágil e eficiente. Não deve haver retrabalho desnecessário, ai está a maior razão para controlar e documentar todo o processo. Mas quando você percebe que está criando documentação demais e produzindo de menos, e que essa documentação está servindo apenas para atender ao que está escrito naquele livro que você leu, está na hora de você repensar suas prioridades.