4. AS APLICAÇÕES WEB E O CENÁRIO GLOBAL
4.2 Desenvolvimento Web: Melhores Práticas
Uma vez que as características das Aplicações Web e de seu desenvolvimento já foram bem detalhadas no Capítulo 2 (Desenvolvimento de Aplicações Web), e a adequação de processos mais flexíveis (como os Processos Agile) ao cenário Web já foi discutida neste mesmo capítulo, o próximo passo é analisar como as condutas propostas por esses processos podem ser úteis na elaboração de uma metodologia para o desenvolvimento de Aplicações Web transacionais por times geograficamente distribuídos.
Como destaca Ginige [GINIGE, 2001c], os requisitos não-funcionais de uma Aplicação Web precisam ser considerados desde o início do projeto, pois a qualidade da aplicação é determinante para seu sucesso. Uma boa estratégia para atingir esse objetivo é adotar algumas recomendações dos Processos Agile [AMBLER, 2002a], como a participação direta do cliente junto à equipe de desenvolvimento, opinando e discutindo características do software, e a contínua realização de testes na aplicação.
Entretanto, em projetos distribuídos, pode não ser possível ter uma colaboração tão intensa do cliente com os desenvolvedores, que não estarão mais reunidos numa única sala, mas espalhados em diversos centros ao redor do globo. Por isso, faz-se necessário definir desde o início do projeto, não apenas as características funcionais da aplicação, mas também alguns critérios de aceitação, indicando as aspirações do cliente em relação aos aspectos não-funcionais do software.
Exemplos de critérios de aceitação em relação à performance da aplicação seriam a definição do tempo máximo para a exibição de uma página, ou a quantidade máxima de usuários simultâneos que a aplicação deve suportar. De forma semelhante, poderiam ser definidos critérios para cada um dos aspectos relacionados à qualidade das Aplicações Web descritos no Capítulo 2 (Desenvolvimento de Aplicações Web). Esses critérios de aceitação passariam a ser tratados como metas de qualidade durante o desenvolvimento, e poderiam ser utilizados pelos times distribuídos na realização de testes de qualidade, sem a necessidade da participação direta do cliente durante o processo.
Já no caso da realização contínua de testes, é importante ter em mente que as Aplicações Web requerem testes diferenciados que possam ajudar na verificação de requisitos como usabilidade e segurança. O Capítulo 6 (Testes e Ferramentas para o Desenvolvimento Web) apresenta em detalhes as principais categorias de testes Web.
Considerando agora as características do desenvolvimento de Aplicações Web, é preciso analisar de que forma a mudança constante de requisitos, a realização de ciclos menores de desenvolvimento, a participação de times multidisciplinares, e a necessidade contínua de manutenção podem ser tratadas em projetos de Desenvolvimento Global de Aplicações Web.
De um modo geral, a maioria das condutas dos Processos Agile e da metodologia proposta por Ginige e Murugesan [GINIGE, 2001c] para o desenvolvimento de Aplicações Web (vide 2.3) se aplica também a projetos distribuídos. Algumas dessas práticas merecem
destaque, uma vez que servirão como diretrizes na definição de uma metodologia para o desenvolvimento de Aplicações Web num cenário global. São elas: ciclos rápidos de desenvolvimento, participação do cliente, técnicas gerenciais, técnicas de desenvolvimento, modularização da aplicação, escalonamento de atividades por competências e ênfase na manutenção do software.
4.2.1 CICLOS RÁPIDOS DE DESENVOLVIMENTO
A definição de ciclos curtos com escopo reduzido e prioridades definidas de acordo com os interesses de negócio do cliente é uma excelente alternativa para lidar com a constante mudança de requisitos dos projetos Web. O desenvolvimento da aplicação como um todo poderá prever a realização de vários ciclos, cada um com duração estimada em três a quatro semanas, e as user stories propostas por eXtreme Programming (XP) poderão ser usadas como base para a definição do escopo de cada ciclo.
4.2.2 PARTICIPAÇÃO DO CLIENTE
Como pregam os Processos Agile [AMBLER, 2002a], o acompanhamento do desenvolvimento pelo cliente é de suma importância para que a aplicação atenda os requisitos funcionais e não-funcionais pretendidos. Equipes com acesso direto ao cliente podem solucionar dúvidas com rapidez e evitar desentendimentos. Além disso, o feedback do cliente mantém os desenvolvedores motivados por saberem que estão obtendo sucesso.
Nos projetos distribuídos, é provável que a participação do cliente não possa se dar de forma tão freqüente quanto em projetos presenciais, visto que diferentes clientes poderão estar envolvidos (representantes das diferentes organizações) e dificilmente poderão estar presentes em todos os centros de desenvolvimento. Para amenizar esse problema, uma boa estratégia seria tentar obter o máximo de detalhes sobre as metas do projeto na fase inicial do desenvolvimento, e utilizar tecnologias de comunicação como e-mail, fax, áudio e vídeo-conferência para agilizar os contatos remotos com o cliente sempre que necessário. 4.2.3 TÉCNICAS GERENCIAIS
Tanto Scrum [SCHWABER, 1995] como XP [BECK, 2000] propõem a realização de reuniões rápidas e diárias com todos os membros da equipe para avaliar o progresso do projeto e detectar possíveis riscos ou problemas que precisem ser resolvidos. Além de serem uma boa oportunidade para a coleta de métricas, essas reuniões permitem que todos os desenvolvedores tenham uma visão geral do projeto e percebam a importância de sua contribuição para o objetivo final, contribuindo para sua motivação. Essas reuniões costumam ser dirigidas por um dos membros da equipe designado como líder ou gerente de projeto (Scrum Master) para coordenar os demais participantes e acompanhar o desenvolvimento.
É importante destacar que a ênfase na comunicação entre os participantes como alternativa para reduzir a necessidade de documentação e agilizar o desenvolvimento proposta pelos Processos Agile pode não funcionar em projetos distribuídos, uma vez que a
distância e as diferenças culturais podem ser empecilhos para a integração total das equipes. Assim, o processo de desenvolvimento adotado na produção de Aplicações Web por times distribuídos deve prever uma documentação consistente para evitar falhas na comunicação e mal-entendidos.
4.2.4 TÉCNICAS DE DESENVOLVIMENTO
Como mostrou Frank Maurer [MAURER, 2002], as técnicas de desenvolvimento propostas por eXtreme Programming (planejamento, metáfora, projeto simples, testes, refatoramento, programação em pares, propriedade coletiva, integração contínua, quarenta horas semanais, presença do cliente e padrões de codificação) se ajustam muito bem às necessidades dos projetos Web. Entretanto, algumas técnicas precisam ser adaptadas para a realização de projetos distribuídos com foco em diferentes mercados.
É o caso, por exemplo, da técnica Projeto Simples, cuja proposta é incluir apenas o essencialmente necessário na hora em que a aplicação está sendo desenvolvida, sem adicionar código que antecipe futuras necessidades do cliente. Embora o objetivo dessa medida seja simplificar ao máximo a aplicação, essa simplicidade pode sair caro, caso a aplicação precise ser adaptada para mercados culturalmente heterogêneos posteriormente. Isto porque, caso não sejam adotadas desde o começo técnicas de Internacionalização como o isolamento entre a interface e o código da aplicação e o uso de padrões como o Unicode, os custos para adaptar a aplicação e o tempo necessário para essas modificações podem significar a perda de importantes oportunidades de negócios. Por isso, mesmo que a ampliação de mercados não seja a idéia inicial, é preciso considerar essa possibilidade e preparar o código de antemão para que as mudanças sejam feitas prontamente caso necessário.
Outra técnica que pode não ser viável em projetos distribuídos é a programação em pares, uma vez que os times estarão distribuídos e os poucos participantes presentes em cada centro de desenvolvimento poderão ter competências diferentes, participando assim de diferentes atividades dentro do ciclo. Embora haja relatos de projetos que adotaram a programação em pares distribuída, com a colaboração remota e simultânea dos participantes [KIRCHER, 2001], as dificuldades parecem sobrepor os benefícios, principalmente considerando-se que os participantes de projetos distribuídos podem apresentar diferenças culturais, a começar pelo idioma, consistindo em uma dificuldade adicional para a colaboração entre eles.
4.2.5 MODULARIZAÇÃO DA APLICAÇÃO
Ginige e Murugesan [GINIGE, 2001c] propõem que as Aplicações Web sejam vistas como uma composição de dois elementos distintos: o conteúdo das páginas (os dados, as mídias, etc) e o software necessário para exibir o conteúdo e oferecer serviços aos usuários. Essa é uma abordagem interessante, pois além de isolar os dados da interface na aplicação, facilitando o reuso e a adaptação do produto para diferentes mercados, permite a concepção do software como um conjunto de módulos que podem ser desenvolvidos
paralelamente por diferentes profissionais para depois comporem a aplicação final. É o uso do Desenvolvimento Baseado em Componentes na produção de Aplicações Web.
É possível ainda fazer uma distinção em relação ao software das Aplicações Web, considerando o código da interface propriamente dita (design das páginas, scripts para geração dinâmica de páginas, menus de navegação, etc) e o código para manipulação dos dados (scripts de acesso ao banco de dados para realização de consultas e atualizações, código para validação de dados, etc) como elementos independentes. Assim, seria possível aumentar as chances de paralelismo no desenvolvimento, com os componentes de cada elemento (conteúdo, interface e código) sendo produzidos por diferentes profissionais. 4.2.6 ESCALONAMENTO DE ATIVIDADES POR COMPETÊNCIAS
Assim como propõem a modularização das Aplicações Web, Ginige e Murugesan [GINIGE, 2001c] sugerem uma divisão nas equipes de desenvolvimento de acordo com as competências necessárias para a produção de cada elemento do software. Enquanto o conteúdo costuma ser gerado por jornalistas e profissionais com experiência em marketing e relações públicas, e o design das páginas é produzido por especialistas em computação gráfica e artes visuais, o código com as funcionalidades da aplicação e os bancos de dados são de responsabilidade de profissionais de Tecnologia da Informação e áreas afins. Assim, é possível aproveitar melhor as habilidades de cada profissional, contribuindo para uma melhor qualidade da aplicação como um todo.
Entretanto, apesar de bastante desejável, a adoção dessa estratégia pode não ser viável em projetos envolvendo equipes muito pequenas em que não seja possível alocar profissionais para cada perfil necessário. Nesses casos, os profissionais acabam acumulando papéis para atender as restrições do projeto.
É preciso ressaltar ainda que o envolvimento de participantes com diferentes perfis no projeto deve ser considerado na hora de escolher o processo de desenvolvimento que será adotado. Isto porque os profissionais de outras áreas costumam ter dificuldade em se adaptar aos formalismos da Engenharia de Software, como a produção excessiva de documentação. Assim, é desejável que o processo adotado seja simples e objetivo, com a simplificação de fases, nomenclaturas e artefatos, para que todos possam se adaptar mais facilmente.
4.2.7 ÊNFASE NA MANUTENÇÃO DO SOFTWARE
Ainda na metodologia proposta por Ginige e Murugesan [GINIGE, 2001c], há um destaque para a fase de manutenção da aplicação. Embora muitos processos de desenvolvimento considerem a manutenção apenas como uma atividade de pós-venda do software, no caso das Aplicações Web é preciso levar em conta que a manutenção ocorre constantemente, promovendo a evolução da aplicação de acordo com as necessidades do mercado. Assim, cada ciclo de manutenção corresponde ao início de um novo ciclo de desenvolvimento, onde as atividades serão definidas de acordo com as alterações necessárias na aplicação.
É preciso considerar ainda que existem diferentes tipos de manutenção. Ginige e Murugesan caracterizam três categorias principais que ocorrem em Aplicações Web: a manutenção de conteúdo (atualizações de dados, criação de novas mídias, etc), a manutenção de software (acréscimo de funcionalidades, mudança de tecnologias, etc) e a manutenção de hardware e de rede (correção de falhas, atualização de versões das ferramentas, etc). Técnicas como a modularização do software e o Desenvolvimento Baseado em Componentes ajudam a tornar os ciclos de manutenção mais ágeis, facilitando o reuso e a adaptação da aplicação aos novos requisitos.
4.2.8 ADAPTAÇÃO DAS SOLUÇÕES
Conforme visto, as principais soluções propostas pela comunidade de software para atender as necessidades do desenvolvimento de Aplicações Web podem também ser utilizadas em projetos distribuídos e com foco no mercado global, requerendo apenas alguns ajustes, que podem ser resumidos da seguinte maneira:
A adoção de técnicas de Internacionalização deve ocorrer desde o começo do projeto, mesmo que a adaptação da aplicação para diferentes mercados não esteja inicialmente prevista, em oposição à recomendação de Projeto Simples dos Processos Agile. Isto porque os custos para realizar as mudanças depois seriam muito altos, e o tempo necessário para adaptar a aplicação e gerar versões para outros mercados poderia limitar as oportunidades de negócios.
O uso de um código claro e bem comentado pode não ser suficiente para garantir o entendimento de todos os participantes do projeto, visto que eles se encontram separados por barreiras geográficas e culturais e não podem ter uma comunicação tão efetiva quanto os times ditos presenciais. Assim, é recomendado o uso de uma documentação mais consistente do projeto, na forma de relatórios ou comunicados, para estabelecer mudanças nos requisitos ou prazos previamente definidos, e permitir o acompanhamento remoto das atividades das equipes.