Quando falamos de alguma área científica em rápida evolução, fatalmente encontramos problemas com a *definição* de termos. Profissionais podem nomear a mesma coisa de formas diferentes, especialmente quando há diferenças culturais e de idioma. Na TI, não é diferente; especialmente no Brasil, aonde uma boa parte de conceitos modernos ainda não foram introduzidos em nossos ambientes acadêmicos e, em função disso, não fazem parte de um entendimento consensual entre todos os profissionais e instituições. São frequentes acaloradas discussões sobre um assunto até se perceber que, por exemplo, que o que alguém entendia como “ágil”, outra pessoa nomeava como “iterativo”, ou ainda “rápido”.

Para evitar este tipo de acontecimento, vamos hoje definir e exemplificar como se estruturam as fases de desenvolvimento de software na Canção Nova, da forma como são (ou serão) adotadas pelos nossos times de desenvolvimento – *Desenvolvimento*, *Integração*, e *Testes*.

h2. Desenvolvimento

É a etapa na qual os comprometidos com um projeto efetivamente o *constróem*, usando as habilidades que forem pertinentes.

É um processo altamente pessoal e *individualizado*, geralmente envolvendo muita tentativa e erro. Cada envolvido utiliza ferramentas e métodos que mais o agradam, portanto, esta etapa é tradicionalmente realizada sem interferência externa, tanto da parte de pessoas quanto de estruturas _(eg. outros equipamentos e ferramentas além dos do profissional)_.

Logicamente que existem alguns padrões a serem observados por todos – por exemplo, a necessidade de documentação, de uso de sistemas de versionamento, comentários, etc; mas todos estes não eliminam a realidade altamente pessoal desta etapa.

Na Canção Nova, esta etapa é feita localmente _(no equipamento de uso do comprometido)_.

h2. Integração

Nesta etapa, os vários comprometidos com um projeto *entregam* seu trabalho a um local comum e os integram, criando um todo.

O profissional submete seu trabalho a integração somente quando este já possui algum *significado* – por exemplo, quando um programador consegue descrevê-lo como adicionando um benefício claro e completo ao projeto, ao invés de simplesmente “mais cinquenta linhas de código”, ou algo incompleto.

Integração, por definição, envolve a centralização das partes trabalhadas em uma estrutura comum. É uma etapa delicada, que é muito auxiliada por ferramentas como sistemas de controle de versão (que facilitam o fluxo de trabalho e distribuição de responsabilidades) e desenvolvimento baseado em testes (que garante o funcionamente de cada uma das partes integradas e checa se não existem problemas quando elas trabalham em conjunto).

Na Canção Nova, trabalho será integrado em um servidor único; que recebe pedaços do projeto através do GIT, um sistema de controle de versões.

h2. Testes

Na etapa de testes, o produto passa por vários procedimentos, com intuito de testar e *vivenciar* o *comportamento* real do mesmo. Cada um destes procedimentos geralmente atende uma necessidade específica, dentre elas:

* *Testes de execução*: o produto, por padrão, é efetivamente construído e inserido em um *ambiente* que *simula* com o máximo de fidelidade possível as condições nas quais o mesmo seria *consumido*. No caso de aplicativos Web, por exemplo, é feito deployment do mesmo em servidores com infraestrutura similar à real. Estes testes permitem a contemplação de aspectos técnicos do projeto; o que possibilita melhorias e melhor planejamento estrutural.

* *Testes de campo*: geralmente conhecidos como testes de usabilidade, visam observar a *interação* de pessoas (representativas do público-alvo desejado) com o produto. No caso de aplicativos Web, envolve a navegação e uso dos mesmos. Estas observações, por serem totalmente empíricas – baseadas em casos reais – agregam grande valor ao design destes, principalmente quando realizados cedo.

* *Testes de aceitação*: envolvem o *cliente* (solicitante) do produto, que averigua se o mesmo se enquadra nos *requerimentos* e acordos estabelecidos. São muito importantes, pois permitem que falhas sejam detectadas e corrijidas rapidamente, e são especialmente vitais em projetos gerenciados por metodologias ágeis; aonde estes processos acontecem com muita frequência.

Deve-se observar que esta etapa não inclui testes característicos de desenvolvimento baseado a testes e/ou comportamentos que sejam de natureza mecânica: estes testes são executados constantemente na etapa de desenvolvimento pelo próprio desenvolvedor (no caso de testes unitários) ou na etapa de integração (no caso de testes de aceitação).