tcc - utilização de metodologias Ágeis para adaptação de um processo de desenvolvimento de...

CENTRO UNIVERSITÁRIO LUTERANO DE SANTARÉM CURSO DE SISTEMAS DE INFORMAÇÃO

FELIPE DOS SANTOS NASCIMENTO

UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA ADAPTAÇÃO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES WEB

SANTARÉM 2012



Trabalho de Conclusão de Curso apresentado para obtenção do Grau de Bacharel em Sistemas de Informação pelo Centro Universitário Luterano de Santarém. Orientadora: Profª. Msc. Marla Teresinha Barbosa Geller

SANTARÉM 2012



Trabalho de Conclusão de Curso apresentado para obtenção do Grau de Bacharel em Sistemas de Informação pelo Centro Universitário Luterano de Santarém.

Data de Apresentação: _____/_____/_____

_________________________________ ___________ Conceito

_________________________________ ___________ Conceito

_________________________________ ___________ Conceito

Esta obra é dedicada a toda minha família,

em especial aos meus pais Gilson e Luzia,

minha irmã Fernanda e meus professores e

amigos que contribuíram no meu

aprendizado enquanto acadêmico.

AGRADECIMENTOS

Primeiramente a Deus que me deu forças, estrutura e entendimento ao longo

dessa trajetória.

A minha família, em especial aos meus pais e irmã, que sempre me apoiaram,

dando o máximo para que eu pudesse atingir meus objetivos.

A minha orientadora professora Marla Geller pelo apoio e confiança e por ter

contribuído grandemente com sua experiência e didática neste trabalho.

Ao Júnior Tapajós, Diretor Comercial da W3Mais Comunicação Interativa, por

ter me dado a oportunidade de alcançar um dos meus objetivos de trabalhar com

desenvolvimento web, além de ter contribuído indiretamente com este trabalho.

A todos os meus amigos e colegas pelo incentivo e colaboração no decorrer

deste trabalho.

Não devemos ter medo dos confrontos.

Até os planetas se chocam e do caos

nascem as estrelas.

Charles Chaplin

RESUMO

Com a crescente demanda por aplicações web e a dificuldade de empresas que trabalham com esse tipo de serviço, de manter um processo organizacional e gerencial no decorrer do desenvolvimento de um produto, de forma a criar somente o necessário quando for preciso, muitas tem adotado metodologias ágeis. Porém, seguem o mesmo padrão do desenvolvimento de software, o que ainda gera transtornos, pois muitas vezes as equipes não conseguem assimilar o que deve ser feito e nem conseguem se tornar ágeis. Diante do exposto problema, este trabalho tem como objetivo propor um processo ágil específico para o desenvolvimento de aplicações web. O WAAPRO (Processo Ágil para Desenvolvimento de Aplicações Web) utiliza fundamentos de metodologias ágeis como XP, Scrum e P@PSI, porém direcionadas para web. Além de utilizar princípios do Lean, que visa mudar a cultura das equipes de desenvolvimento no que diz respeito ao desenvolvimento enxuto. Para validação do processo ágil WAAPRO foi realizado um estudo de caso, através do desenvolvimento do Portal Guarany, para mostrar a utilização do processo ágil. Palavras-chave: Metodologia Ágil. Customização de Processo. Aplicação Web.

ABSTRACT

With the growing demand for web applications and the difficulty of companies that work with this type of service, to maintain an organizational and managerial process during the development of a product, to create only what you need when you need it, many companies have adopted agile methodologies. However, follow the same pattern of software development, which still generates disorders, as teams often fail to grasp what should be done and can not become agile. Considering the above problem, this paper aims to propose a specific agile process for developing web applications. The fundamentals of WAAPRO (Agile Process for Web Application Development) uses agile methodologies like XP, Scrum and P@PSI, but directed to the web. In addition to using Lean principles, a way to change the culture of development teams regarding the lean development. To validate the agile process WAAPRO was conducted a case study through the development of the Portal Guarany to show the use of agile process. Keywords: Agile Methodology. Process Customization. Web Application.

LISTA DE ILUSTRAÇÕES

Figura 1 - Exemplo de Diagrama de Caso de Uso .................................................... 25 Quadro 1 - Descrição dos Casos de uso mostrados na figura 1. .............................. 25

Figura 2- Exemplo de Diagrama de Classes. ............................................................ 26 Figura 3 - Exemplo de Diagrama ER ......................................................................... 27

Figura 4 - Exemplo de Diagrama de Sequência. ....................................................... 28 Figura 5 - Wireframe da página inicial de um site. .................................................... 30 Quadro 2 - Exemplo de uma Planilha de Requisitos ................................................. 29 Figura 6 - Template da aplicação web Dinheirama Online ........................................ 31

Figura 7 - Visão geral do WAAPRO .......................................................................... 41 Figura 8 - Diagrama de Caso de Uso do Portal Guarany. ....................................... 44 Quadro 3 - Descrição dos Casos de Uso do Portal Guarany. ................................... 44 Figura 9 - Diagrama de Caso de Uso do Sistema de Administração do Portal Guarany..................................................................................................................... 45 Quadro 4 - Descrição dos Casos de Uso do Sistema de Administração do Portal Guarany..................................................................................................................... 46 Figura 10 - Wireframe da página inicial do Portal Guarany. ...................................... 47

Figura 11 - Template do site Portal Guarany. ............................................................ 48 Figura 12 - Sistema de Administração do Portal Guarany. ........................................ 49

Figura 13 - Diagrama de Classe da funcionalidade Notícia....................................... 51 Figura 14 - Diagrama de Classe da funcionalidade Rádio Interativo ......................... 52

Figura 15 - Diagrama de Classe da funcionalidade Mural de Recados ..................... 52 Figura 16 - Diagrama ER - Notícia. ........................................................................... 53

Figura 17 - Diagrama ER - Rádio Interativo. ............................................................. 54 Figura 18 - Diagrama ER - Mural de Recados. ......................................................... 54

Figura 19 - Diagrama de Sequência da ação comentar Notícia ................................ 56 Figura 20 - Diagrama de Sequência da ação comentar Rádio Interativo .................. 57

Figura 21 - Diagrama de Sequência da ação de enviar recado através do Mural de Recados .................................................................................................................... 58

SUMÁRIO

1 INTRODUÇÃO ....................................................................................................... 12

2 VISÃO GERAL DO DESENVOLVIMENTO DE UMA APLICAÇÃO WEB ............. 14

2.1 INÍCIO DO PROJETO ......................................................................................... 14

2.2 PROGRAMAÇÃO ................................................................................................ 15 2.3 FINALIZAÇÃO ..................................................................................................... 15

2.4 MANUTENÇÃO ................................................................................................... 15

3 METODOLOGIAS ÁGEIS UTILIZADAS NA CUSTOMIZAÇÃO DO PROCESSO WEB WAAPRO ......................................................................................................... 17

3.1 PROCESSOS CUSTOMIZADOS PARA APLICAÇÕES WEB ............................ 17

3.2 PROGRAMAÇÃO EXTREMA (XP) ..................................................................... 18 3.2.1 O Jogo do Planejamento ............................................................................... 19

3.2.2 Entregas Frequentes ...................................................................................... 20 3.2.3 Projeto Simples .............................................................................................. 20

3.2.4 Design Incremental ........................................................................................ 21 3.2.5 Programação em Pares .................................................................................. 21

3.2.6 Propriedade Coletiva ...................................................................................... 22 3.2.7 Contrato de escopo negociável .................................................................... 22

3.3 SCRUM ............................................................................................................... 22 3.3.1 Ciclos ............................................................................................................... 23

3.3.2 Produto Total .................................................................................................. 24

3.4 P@PSI................................................................................................................. 24 3.4.1 Diagrama de Caso de Uso ............................................................................. 24 3.4.2 Diagrama de Classes ..................................................................................... 26

3.4.3 Diagrama ER ................................................................................................... 26 3.4.4 Diagrama de Sequência ................................................................................. 27

3.5 OUTROS RECURSOS PARA DOCUMENTAÇÃO NO WAAPRO ...................... 28 3.4.1 Planilha de Requisitos ................................................................................... 28 3.4.2 Documento de Design Funcional .................................................................. 29

3.4.3 Template .......................................................................................................... 30

4 APLICAÇÃO DO LEAN NO PROCESSO ............................................................. 32

4.1 PRINCÍPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE ............... 33 4.1.1 Elimine o desperdício .................................................................................... 33

4.1.2 Amplifique o aprendizado .............................................................................. 33 4.1.3 Entregue o mais rápido possível .................................................................. 33

4.1.4 Respeito .......................................................................................................... 34 4.1.5 Construa com integridade ............................................................................. 34

4.1.6 Visualize o todo .............................................................................................. 34

4.2 OS BENEFÍCIOS DO LEAN ................................................................................ 34

5 MODELO DE CUSTOMIZAÇÃO DO PROCESSO ÁGIL PARA APLICAÇÕES WEB - WAAPRO ...................................................................................................... 37

5.1 O QUE É WAAPRO?........................................................................................... 37

5.2 PLANEJAMENTO................................................................................................ 37 5.3 DESENVOLVIMENTO ......................................................................................... 38

5.4 FINALIZAÇÃO ..................................................................................................... 39

5.5 MANUTENÇÃO ................................................................................................... 40

6 ESTUDO DE CASO ............................................................................................... 42

6.1 O CLIENTE ......................................................................................................... 42

6.2 O PROJETO ........................................................................................................ 42 6.3 PLANEJAMENTO................................................................................................ 43 6.3.1 Levantamento e Análise de Requisitos ........................................................ 43 6.3.2 Proposta de desenvolvimento....................................................................... 46

6.3.3 Briefing ............................................................................................................ 47 6.3.4 Template .......................................................................................................... 47

6.4 DESENVOLVIMENTO ......................................................................................... 49 6.4.1 Coleta de conteúdo ........................................................................................ 50 6.4.2 Diagramação do Template ............................................................................. 50

6.4.3 Codificação ..................................................................................................... 50

6.5 FINALIZAÇÃO ..................................................................................................... 58 6.5.1 Revisão do Produto ........................................................................................ 59 6.5.2 Apresentação do produto ao cliente ............................................................ 59

6.5.3 Entrega do produto ........................................................................................ 59 6.5.4 Treinamento .................................................................................................... 59

6.6 MANUTENÇÃO ................................................................................................... 60

7 CONCLUSÃO ........................................................................................................ 61

REFERÊNCIAS ......................................................................................................... 63

ANEXOS ................................................................................................................... 65

12

1 INTRODUÇÃO

Com o crescimento do número de empresas que produzem negócios para seus

clientes na internet, e consequentemente, o grande envolvimento de profissionais da

área, torna-se necessário encontrar uma maneira de gerenciar o trabalho desses

profissionais a fim de gerar produtos de qualidade que agreguem valor ao negócio

do cliente. Lidar com pessoas, e nesse caso, clientes, é uma tarefa difícil, pois as

mudanças que ocorrem no que se refere a características e requisitos do sistema,

durante o desenvolvimento de aplicações web afetam os custos, prazos e muitas

vezes a qualidade do produto. Para acompanhar essas mudanças é preciso uma

organização. É nesse aspecto que a modelagem ágil ajuda os desenvolvedores e,

também, o cliente a compreender o escopo do produto antes, durante e após a

finalização do mesmo. É preciso entregar um produto que satisfaça as necessidades

do cliente, afinal, esse é o primeiro objetivo do desenvolvimento de software.

A utilização de metodologias ágeis é uma proposta que vem sendo estudada

há anos no desenvolvimento de software. Basicamente, todas tentam definir um guia

de desenvolvimento, identificando quem está fazendo o quê, onde, por que, como e

quando. Jacyntho (2008), afirma que um processo de software é definido com um

conjunto de atividades interdependentes que visam desenvolver, manter e gerenciar

sistemas de software. Sendo que cada atividade pode ser composta de outras

atividades e são executadas por atores que desempenham um papel no processo

(programador, gerente, cliente, etc.). O resultado das atividades são artefatos

(código, documentação, modelos) que servem de entrada para outras atividades

para produzir novos artefatos. Sem um processo de software, o risco de falha do

projeto se torna muito alto, em especial para as aplicações web modernas cuja

complexidade não para de crescer.

Com a proposta de desenvolver projetos de maneira capaz de responder rápido às mudanças, com foco nas pessoas e na colaboração com o cliente, surgiram as metodologias ágeis que, devido às suas características, possibilitam gerar produto com maior valor agregado e ao mesmo tempo manter pessoas motivadas dentro das corporações (AKITA, 2009 apud TANIGUCHI; CORREA, 2009).

A partir da concepção das metodologias ágeis é possível criar um processo ágil

voltado para desenvolvimento de aplicações web, que por sua vez, têm foco no

13

produto em si, ou seja, sendo mais importante entregar algo de qualidade sem se

prender em intermináveis documentos, eliminando desperdícios e desenvolvendo

somente o necessário e quando necessário. Pois, assim como no desenvolvimento

de software tradicional, aplicações web estão constantemente sofrendo mudanças

durante e após sua implementação, trabalhando assim com releases iterativos e

incrementais de entrega.

Segundo Bohem e Turner (2004 apud JACYNTHO, 2008) não existe um

processo correto ou incorreto, tanto processos rigorosos quanto processos ágeis,

ambos têm suas vantagens e desvantagens. Ou seja, é preciso encontrar um ponto

de equilíbrio entre as duas abordagens para cada tipo de projeto, e assim definir um

processo híbrido que traga benefícios reais.

Diante da necessidade de um processo de desenvolvimento voltado para

ambientes e aplicações web, será mostrado neste trabalho um processo ágil

customizado a partir de metodologias ágeis já existentes, sendo elas: Programação

Extrema (XP), Scrum e P@PSI. Este trabalho também cita o conceito Lean, uma

metodologia voltada para o desenvolvimento de produtos de forma a eliminar

desperdícios e criar um ambiente de aprendizado constante a partir de expectativas

da equipe e feedback dos clientes, assim produzindo somente o que gera valor para

o cliente.

Este trabalho está organizado em capítulos, onde após a introdução o segundo

capítulo apresenta uma visão geral do desenvolvimento de uma aplicação web, o

terceiro capítulo apresenta as metodologias ágeis utilizadas na customização do

processo web WAAPRO, o quarto capítulo mostra a aplicação do Lean no processo

proposto, o capítulo cinco exemplifica o modelo de customização do WAAPRO e o

capítulo seis apresenta um estudo de caso utilizando como processo ágil o

WAAPRO no desenvolvimento de um site.

14

2 VISÃO GERAL DO DESENVOLVIMENTO DE UMA APLICAÇÃO WEB

O tópico a seguir descreve a experiência do autor no desenvolvimento de

aplicações web e o processo utilizado desde o início de um projeto, passando pela

finalização até a manutenção após entrega do produto ao cliente.

2.1 INÍCIO DO PROJETO

O projeto de desenvolvimento de uma aplicação web se inicia com uma reunião

preliminar com o cliente, a fim de se obter informações sobre a real necessidade

para se criar o produto. Neste primeiro momento, é decidido o tipo de produto,

podendo variar desde um website informativo, apresentando informações acerca da

empresa do cliente, por exemplo, quanto a sites de venda de produtos on-line,

conhecido como e-commerce.

No desenvolvimento web existem outros produtos como hotsites, que

geralmente são sites pequenos e específicos para um determinado evento ou ação

publicitária. E, também, sistemas on-line, como grandes portais de conteúdo que

possuem diversas funcionalidades.

Definido o tipo de aplicação a ser desenvolvida, é feito um levantamento de

requisitos junto ao cliente. Primeiro, para conhecer suas necessidades ao procurar

este tipo de produto e, segundo, para saber quais funcionalidades a aplicação irá

conter.

Com essas informações em mãos é, então, elaborada uma proposta de

desenvolvimento, contendo todas as informações necessárias para iniciar o

desenvolvimento do produto. Esta proposta inclui informações detalhadas de cada

funcionalidade, as páginas que serão criadas, custo total do projeto, tempo de

desenvolvimento e, também o que não será produzido, pois após o contrato fechado

o que for solicitado como mudança fora do escopo não fará parte do valor fixado no

contrato, este sofrerá um acréscimo.

Esta proposta é apresentada ao cliente. Caso haja algum item em

discordância, este tem a total liberdade de pedir a reformulação até chegar a um

ponto comum com a equipe responsável pelo desenvolvimento da aplicação web.

Sendo a proposta aprovada, o início do desenvolvimento dá-se pela criação do

layout baseado nas informações previamente coletadas. O layout baseia-se,

15

principalmente, na harmonia de cores e localização das informações. A equipe

responsável tem total liberdade para criar algo dentro dos padrões web de

usabilidade e, posteriormente, esse layout passa pela aprovação do cliente.

2.2 PROGRAMAÇÃO

Uma vez que o layout é finalizado, e o cliente se satisfaça com a localização de

cada funcionalidade e informação que a aplicação irá conter, inicia-se o processo de

programação, ou seja, a codificação dos requisitos. Durante esta etapa os requisitos

podem sofrer alterações, fazendo-se necessário o uso de padrões web de

programação que facilitam a manutenção dos códigos a fim de se evitar desperdício

de tempo.

2.3 FINALIZAÇÃO

Após a finalização da programação de toda a aplicação, esta é testada por

completo localmente (off-line), e depois é enviada para um servidor on-line para

testes finais. Caso existam falhas, estas são corrigidas, senão, uma nova reunião

com o cliente é realizada para apresentação do produto final. Se aprovada, a

aplicação fica disponível para o público geral, senão volta para a etapa de

programação.

2.4 MANUTENÇÃO

No desenvolvimento web, após a entrega da aplicação funcionando

corretamente, se inicia mais uma etapa, que é a manutenção do mesmo. Esta etapa

engloba desde a atualização do conteúdo, layout e até mesmo mudanças nos

requisitos iniciais, como a inclusão de novas funcionalidades.

Essa fase de Manutenção deve ser especificada em contrato de forma

coerente, pois o cliente pode eventualmente achar que pode requerer qualquer

mudança após a finalização do projeto, o que é um equívoco. O desenvolvedor irá

realizar qualquer mudança no escopo descrito em contrato, caso seja acrescentada

uma nova funcionalidade, o valor do projeto passa por um reajuste. Para isso, há

uma negociação prévia com o cliente, para que fique tudo bem claro. É importante

16

ressaltar, que qualquer manutenção solicitada pelo cliente passa pelo gerente de

projetos primeiro. Ele, junto com a equipe de desenvolvimento analisa o que pode

ser feito e as consequências de tal mudança antes de entrar em processo de

implementação. Nem todas as alterações poderão ser realizadas após a finalização

do projeto, pois podem comprometer muitas funções. Por isso é importante uma

análise de requisitos bem criteriosa, no início do desenvolvimento do projeto.

17

3 METODOLOGIAS ÁGEIS UTILIZADAS NA CUSTOMIZAÇÃO DO PROCESSO

WEB WAAPRO

Metodologias ágeis são vistas como as melhores alternativas às abordagens

tradicionais de desenvolvimento de software. Uma vez que métodos tradicionais

surgiram em um contexto de desenvolvimento de software baseado apenas em um

mainframe e terminais burros (ROYCE, 1970 apud SOARES, 2004), onde não

existiam ferramentas de apoio ao desenvolvimento de software, e todo o projeto era

baseado em documentos produzidos antes de o software ser implementado.

Essas metodologias surgiram para mudar o conceito de desenvolvimento de

software baseado somente em documentos. Com isso, passou-se a se preocupar

com as pessoas que compõe os projetos, principalmente, desenvolvedores e

clientes. A partir disso, houve uma melhoria no processo de codificação, passando a

ser guiado por testes e utilizando de forma mais eficiente as práticas da Engenharia

de Software.

Este capítulo se divide na breve descrição de alguns processos customizados

para desenvolvimento de aplicações web, e algumas das principais metodologias

ágeis utilizadas no desenvolvimento de software, sendo elas, o Scrum, XP e P@PSI

com foco na implantação em ambientes que ainda não utilizam metodologias ágeis

como parte do processo de desenvolvimento de software. Essas metodologias

serviram de base para a customização do Processo Ágil para Desenvolvimento de

Aplicações Web, denominado WAAPRO.

3.1 PROCESSOS CUSTOMIZADOS PARA APLICAÇÕES WEB

Existem algumas propostas de processos voltados para aplicações web, como

o XWebProcess que foi criado adaptando elementos do XP para lidar com

importantes questões de sistemas web, tais como: interfaces com usuário

complexas, navegação, requisitos não-funcionais, testes e suporte de infraestrutura

(SAMPAIO, 2004 apud JACYNTHO, 2008). Outro processo é o OPEN-Web Process,

e foi adaptado para desenvolvimento web a partir do OPEN (Object-Oriented

Process, Environment, and Notation) que é um meta-processo e abrange o ciclo de

vida completo de desenvolvimento, incluindo aspectos de negócio e de software

(HAIRE et tal, 2001 apud JACYNTHO, 2008). Além desses, também pode-se citar o

18

WebPraxis que como propósito ser utilizado no desenvolvimento de aplicativos que

rodem em ambientes web e não simplesmente sites estáticos ou dinâmicos

(ÁLVARES, 2001). Foi proposto a partir do Praxis, por ser um processo genérico

para produção de aplicativos interativos e orientados a objetos. Assim, o WebPraxis

herda as características usadas para desenvolvimento de aplicativos comuns

desktop e insere outras para atender às necessidades do desenvolvimento web.

3.2 PROGRAMAÇÃO EXTREMA (XP)

A Programação Extrema (XP) é uma metodologia para equipes de

desenvolvimento pequenas, de duas a dez pessoas, que desenvolvem softwares

onde os requisitos do usuário são vagos e que se modificam rapidamente. Segundo

Beck (2004), o desenvolvimento de software tem falhas, sendo estas na entrega e

nos valores entregues. Essas falhas geralmente são vistas quando o software já

está em produção, o que ocasiona em impactos econômicos e humanos. A XP visa

eliminar os erros durante os processos de desenvolvimento de software, por isso

encoraja o diálogo entre membros da equipe e, principalmente, com o cliente, tendo

assim feedback diário.

A XP segue quatro variáveis, sendo elas: custo, tempo, qualidade e escopo.

Além de se basear em cinco valores para conduzir o desenvolvimento, sendo:

comunicação, coragem, feedback e simplicidade. Dessa forma, ela tenta prever os

problemas antes que estes aconteçam e assim achar a melhor solução para resolvê-

los de forma rápida.

“Como programadores, nos habituamos a antecipar problemas. Quando eles

aparecem mais tarde, ficamos felizes. Quando não aparecem, nem notamos.”

(BECK, 2000 apud TELES, 2005).

Junto com essas características, foram utilizadas no WAAPRO o ciclo codificar,

testar, ouvir e projetar, que são as quatro atividades básicas da XP. Segundo Beck

(2004), o código serve como meio de comunicação que expressa intenções táticas e

descreve algoritmos; os testes servem tanto como recurso quanto a uma

responsabilidade, pois dizem quando se terminou de codificar; ouvir faz com que o

feedback do programador ajude o cliente a entender melhor seus problema; e por

final, projetar é desenvolver o que foi planejado de forma organizada, ou seja, o

19

código tem que ser projetado para suportar modificações de forma que o sistema

seja impactado o mínimo possível em outras partes.

No WAAPRO buscou-se utilizar práticas XP que pudessem ser utilizadas

também no desenvolvimento web como: Jogo do Planejamento, Entregas

Frequentes, Projeto Simples, Design Incremental, Programação em Pares,

Propriedade Coletiva e Contrato de escopo negociável.

3.2.1 O Jogo do Planejamento

O Jogo do Planejamento determina brevemente o escopo do projeto

combinando prioridades de negócios e estimativas técnicas.

O desenvolvimento web, assim como o desenvolvimento de software é um

diálogo evolutivo entre o possível e o desejável. Assim, segundo Beck (2004) as

pessoas da área do negócio precisam decidir sobre:

Escopo – o objetivo de um projeto é entregar um produto que gere valor de

negócio ao cliente, porém quanto de um problema precisa ser resolvido para

que o sistema tenha valor em produção? A pessoa da área de negócios

precisa estar apta a responder questionamentos como esse, entendendo o

quanto não é suficiente e o quanto é demais.

Prioridade – está ligado a escolhas, às vezes é preciso escolher entre

funcionalidades a serem desenvolvidas primeiro. A pessoa da área de

negócios está em posição de decidir isso, muito mais do que um

programador, por exemplo.

Composição das versões – basicamente, é preciso saber quanto da

aplicação web precisa ser feita para que o produto comece a entregar valor

ao cliente.

Datas de entrega – datas são importantes, pois servem como metas.

A área técnica está diretamente ligada com a área de negócios, pois fornece a

matéria-prima para a tomada de decisão. Portanto, as pessoas da área técnica

decidem sobre:

Estimativas – informação sobre quanto tempo levará para implementar uma

funcionalidade, por exemplo.

20

Consequências – existem decisões estratégicas de negócios que devem

ser tomadas apenas quando há informações sobre as consequências

técnicas. Por exemplo, um caso de uso muda durante o desenvolvimento e

este atinge pelo menos outra funcionalidade, podendo fazer o sistema parar

por alguns instantes. A área de desenvolvimento precisa explicar as

consequências.

Processo – a equipe de trabalho precisa ser organizada, para isso é

importante programar bem a aplicação web sem se prender a uma cultura

fechada.

Cronograma detalhado – os programadores precisam de liberdade para

dizer o que deve ser feito primeiro na aplicação web, a fim de reduzir o risco

total do projeto.

3.2.2 Entregas Frequentes

No desenvolvimento web as mudanças são muito rápidas e os usuários finais

esperam sempre algo novo. A prática de Entregas Frequentes diz que se possível,

coloque um sistema simples rapidamente em produção e depois libere novas

versões em ciclos curtos.

Cada versão entregue deve ter o menor tamanho possível, contendo os

requisitos de maior valor para o negócio. Beck (2004) ainda afirma que a entrega

precisa fazer sentido como um todo, de nada adianta entregar versões malfeitas, ou

seja, implementar meia função e entregá-la, só para tornar mais curto o ciclo de

entrega.

3.2.3 Projeto Simples

Basicamente, a XP propõe uso de métodos que tornem o projeto de

desenvolvimento mais simples, onde programadores podem utilizar recursos como

padrões de projeto e framework na codificação, por exemplo. Tufte (1992 apud

BECK, 2004) propõe um exercício para designers gráficos. “Desenhe um gráfico da

forma que você quiser. Então apague todos os elementos, desde que você não

remova nenhuma informação. O que restar quando você não puder apagar mais

nada é o design certo para o gráfico”.

21

Para que um projeto se torne simples é necessário ter funcionalidades ou

casos de usos bem definidos, o que nem sempre acontece, pois as mudanças fazem

parte do escopo e podem acontecer em qualquer estágio do projeto. Mas é

importante fazer somente o que for preciso quando realmente precisar, ou seja,

evitar criar algo que não será usado ou que a falta deste não irá ter grandes

impactos.

3.2.4 Design Incremental

O objetivo do Design Incremental é sempre tornar o código e design mais

simples, legível e preparado para mudanças. Deve ter suporte de outras práticas,

como a refatoração1 e os teste automatizados para garantir que a equipe seja capaz

de solucionar os problemas futuros com mais rapidez. Sato (2009) alerta para a

interpretação dessa prática, “seu objetivo não é minimizar o investimento com design

no curto prazo, mas sim manter esse investimento proporcional às necessidades do

sistema conforme ele evolui”. Para que isso funcione existe padrões de

desenvolvimento web que podem ser seguidos e que melhoram a legibilidade dos

códigos e consequentemente a performance da aplicação, como por exemplo, uso

de frameworks.

3.2.5 Programação em Pares

Na Programação em Pares existem dois papéis em cada par. O primeiro é

aquele indivíduo com o teclado e o mouse que está pensando qual a melhor forma

de implementar um método específico. O segundo pensa de forma estratégica:

Essa abordagem como um todo vai funcionar?

Que outros casos de testes podem não funcionar?

Existe uma maneira de simplificar todo o sistema para que o problema

simplesmente desapareça?

Isso promove o trabalho coletivo e colaborativo, une a equipe e melhora,

também, a comunicação e a qualidade do código (SATO, 2009). O aprendizado é

1 Para Beck (2004), refatorar um código significa alterar seu comportamento a fim de remover

duplicidade, melhorar a comunicação, simplificar e acrescentar flexibilidade.

22

sempre repassado para toda a equipe, assim há uma maior comunicação de todos

que passam a compartilhar de técnicas e ideias novas.

3.2.6 Propriedade Coletiva

Mesmo que um programador tenha levado dias em um código, a XP sugere

que qualquer um da equipe pode modificar tal código. Isso quer dizer que, não há

um dono, “a qualquer momento, qualquer um que perceba uma oportunidade de

acrescentar valor a alguma parte do código é obrigado a fazê-lo” (BECK, 2004).

A XP sugere que todos sejam donos do sistema inteiro. Obviamente, nem

sempre todos da equipe irão conhecer todas as partes do código, mas podem saber

um pouco sobre cada parte. Isso dá uma visão mais ampla do sistema, facilitando a

execução de refatoração e espalhando conhecimento por toda a equipe. No

desenvolvimento web, onde toda a equipe está conectada diretamente ao código,

isso é importante, pois não se deve perder tempo solicitando mudanças quando o

próprio programador puder melhorar o código.

3.2.7 Contrato de escopo negociável

Contratos devem ter fixados tempo, custo e qualidade, deixando o escopo das

funcionalidades em aberto para negociação. Isso porque no desenvolvimento de

aplicações web as mudanças no decorrer do projeto são frequentes, sendo que em

XP, o escopo é revisado o tempo todo para garantir que a equipe esteja sempre

trabalhando no que é mais importante para o cliente. Com o escopo das

funcionalidades em aberto, o cliente pode solicitar mudanças conforme a evolução

da aplicação e, também, do seu aprendizado.

3.3 SCRUM

O objetivo da metodologia ágil Scrum é definir um processo para projeto e

desenvolvimento de software orientado a objetos, que seja focado nas pessoas e

que seja indicado para ambientes em que os requisitos surgem e mudam

rapidamente. O Scrum também é considerado um método específico para o

gerenciamento de processo de desenvolvimento de software (LUNA; COSTA; DE

23

MOURA, 2011). Surgiu a partir de um estudo feito por Takeuchi & Nonaka, no qual,

notaram que projetos de curta duração, usando equipes pequenas e

multidisciplinares, produzem melhores resultados (DE CARVALHO, 2009).

Scrum é uma metodologia baseada em simplicidade e adaptabilidade. Um fundamento dessa filosofia é a manutenção da base desse conceito: equipes gerenciáveis. A maioria dos livros aponta equipes de no máximo 9 pessoas, multidisciplinar e motivada. Mas é inescapável a existência de projetos onde essa força de trabalho tem de ser multiplicada, devido ao tamanho do sistema sendo desenvolvido (GOLÇALVES, 2011).

Tudo o que acontece sob Scrum é realizado em um período limitado de tempo,

denominado Time Boxing. Isso é fundamental para entregar software no menor

tempo possível. Além do mais, o Scrum busca a simplicidade. Isso se reflete nos

papéis que cada pessoa tem durante o processo de desenvolvimento, são apenas

três e não há nenhuma hierarquia entre elas: Product Owner (dono do produto),

Scrum Master (coordenador da equipe) e o Scrum Team (equipe de

desenvolvimento). Com essa simplicidade a equipe se esforça em planejar menos e

realizar mais, sendo objetivo nas atividades a serem executadas (GONÇALVES,

2011). O WAAPRO busca a simplicidade dos projetos web, por isso foi um princípio

utilizado na customização deste processo, além de imaginar como será o produto

final.

3.3.1 Ciclos

No processo ágil WAAPRO foi utilizado o elemento Ciclo da gestão iterativa e

incremental, que no Scrum é chamado Sprint. Cada Sprint é o período de tempo em

que um ou mais incrementos reais são desenvolvidos e, ao final, tais incrementos

devem ser demonstrados ao cliente. Essa é uma forma de tornar o cliente presente

no desenvolvimento e diminuir o risco de mudanças nos requisitos após a finalização

do projeto. O importante aqui é o tempo de vida de um Ciclo, que não deve

ultrapassar quatro semanas.

No desenvolvimento web a velocidade de desenvolvimento é acelerada, quanto

mais rápido se desenvolve uma funcionalidade mais rápido será o feedback da

equipe e do cliente.

24

3.3.2 Produto Total

As funcionalidades no Scrum são vistas primeiro como um todo, chamado

Product backlog, ou seja, tudo o que a aplicação irá conter. Depois disso, passa por

um processo de avalição para priorizar as funcionalidades a serem desenvolvidas

naquele Sprint, gerando assim um Sprint backlog.

No WAAPRO foi adotado a mesma ideia, é necessário visualizar a aplicação

web como um todo, não com todas as funcionalidade que pode conter, mas sim o

que é necessário para a aplicação se tornar funcional e gerar valor para o cliente. A

partir dessa ideia é que as funcionalidades são priorizadas e implementadas no fluxo

de desenvolvimento.

3.4 P@PSI

“Pode-se descrever o [..] P@PSI, como sendo gerenciado pelo Scrum,

adotando práticas XP e com fluxos do Processo Unificado.” (GELLER; KNEBEL;

BENTES JÚNIOR, 2007).

O processo ágil P@PSI foi criado em 2008 pelo Grupo de Trabalho Ágil (GTA)

do Centro Universitário Luterano de Santarém (CEULS/ULBRA), e surgiu com o

propósito de auxiliar desenvolvedores de softwares em pequenos projetos para

empresas que buscam soluções personalizadas.

Por ser um processo ágil customizado, o P@PSI possui algumas práticas já

testadas como o uso de modelos para representar aspectos do sistema e também o

ciclo iterativo oriundo do Processo Unificado. Alguns desses recursos também

podem ser utilizados no desenvolvimento de aplicação web e foram utilizados,

principalmente, para servir de documentação dos projetos. Serão apresentados os

diagramas mais comuns que podem facilitar a documentação no processo ágil

WAAPRO.

3.4.1 Diagrama de Caso de Uso

Um recurso da UML muito utilizado em desenvolvimento de software é o

Diagrama de Casos de Uso (figura 1), que permite agrupar o comportamento

esperado do sistema em rotinas de limites muito bem definidos, que farão a

25

interação com os usuários (MELO, 2009). O caso de uso é utilizado para representar

os requisitos do sistema, ou seja, o que a aplicação deve fazer a fim de atender as

necessidades dos interessados, principalmente os clientes.

Através de um caso de uso é possível descrever o funcionamento de uma

funcionalidade de maneira informal, sendo de fácil assimilação por clientes que

acompanham um projeto. Os principais conceitos associados ao Diagrama de Caso

de Uso são: atores, e casos de uso.

Figura 1 - Exemplo de Diagrama de Caso de Uso

Fonte: Arquivo pessoal, 2012.

Além da forma visual, é bom utilizar um quadro descritivo (quadro 1) para cada

caso de uso, assim, mesmo depois de muito tempo da finalização de um projeto,

caso surja alguma alteração, o desenvolvedor saberá exatamente porque aquele

caso de uso foi feito e o que ele representa na aplicação web.

Quadro 1 - Descrição dos Casos de uso mostrados na figura 1.

Fazer Login O usuário efetuará Login para ter acesso ao sistema

Fazer Cadastro O usuário faz seu cadastro no sistema.

Comprar Produto O usuário efetua a compra de um produto.

Validar Dados Verificar se os dados do usuário já estão na base de dados e se estão corretos.

Dar Desconto O sistema valida a compra e fornece para o usuário um campo para inserir seu código de desconto.


26

3.4.2 Diagrama de Classes

O Diagrama de Classes (figura 2) é utilizado para modelar a visão estática do

projeto de um sistema. Nele mostra-se um conjunto de classes, interfaces e

colaborações e seus relacionamentos de dependência, generalização e associação

(BOOCH; RUMBAUGH; JACOBSON, 2005). Também ajuda a visualizar a estrutura

de classes antes de implementá-las, e assim, corrigir eventuais erros. Cada classe

funciona em colaboração com outras e não sozinhas, a fim de se fazer sentido.

Figura 2- Exemplo de Diagrama de Classes.


3.4.3 Diagrama ER

A partir do Diagrama de Classes (figura 2) pode ser feito um mapeamento das

classes em tabelas através do Diagrama ER (figura 3), em que este representa o

modelo relacional das tabelas. Dependendo do padrão de codificação, com a base

de dados pronta, fica mais simples codificar as classes do projeto. Porém, são

necessários ambos os diagramas para modelar as aplicações web antes de

qualquer codificação.

27

Principalmente no desenvolvimento web, a modelagem da base de dados é

muito importante, pois a partir dela o sistema pode responder de forma rápida ou

não. Por exemplo, às vezes os desenvolvedores não se preocupam com a

quantidade de usuários que a aplicação pode suportar simultaneamente, uma

modelagem da base de dados errada junto com uma programação malfeita pode

comprometer toda a aplicação, podendo às vezes, ficar inacessível ou lenta.

Figura 3 - Exemplo de Diagrama ER


3.4.4 Diagrama de Sequência

Um Diagrama de Sequência é um artefato que ilustra - para um cenário

específico de um caso de uso, com o auxílio das classes identificadas num modelo

de classes - os eventos de entrada e saída relacionados num sistema, como troca

de mensagens, dentro de uma linha de tempo sequencial. Na modelagem do

Diagrama de Sequência (figura 4) cada item descrito nos cenários principais e

alternativos é representado por mensagens. Essas mensagens podem ser

expressas do ator para o sistema, ou da interface para os objetos (MELO, 2009).

28

Figura 4 - Exemplo de Diagrama de Sequência.

Fonte: GELLER, 2012.2

O P@PSI também possui uma herança do Processo Unificado que são os

fluxos iterativos, no qual o processo possui: Planejamento, Desenvolvimento e

Encerramento. No WAAPRO também foram utilizados fluxos iterativos, porém os

fluxos são Planejamento, Desenvolvimento, Finalização e Manutenção, sendo

descritos no capítulo 5.

3.5 OUTROS RECURSOS PARA DOCUMENTAÇÃO NO WAAPRO

Alguns recursos são válidos no desenvolvimento de aplicações web, tais como

Planilha de Requisitos, Documento de Design Funcional e Template.

3.4.1 Planilha de Requisitos

A planilha de requisitos, como mostra o quadro 2, é um artefato para

armazenar as informações feitas no levantamento de requisitos. Esse recurso é

importante para orientar os desenvolvedores sobre as funcionalidades do sistema

que interagem entre si, facilitando a manutenção dos mesmos, em caso de

modificações durante ou após a implementação. Para isso, a planilha especifica um

código único para cada funcionalidade ou ação que a aplicação irá conter, além de

2 Geller, Marla. (Centro Universitário Luterano de Santarém). Comunicação pessoal. Santarém, 2012.

29

um campo descritivo, categoria que indica o tipo do requisito, prioridade, dificuldade,

status se o requisito já foi implementação ou não, e comentários adicionais. Essa

planilha é atualizada a cada iteração do projeto, assim se tem um maior controle do

que está sendo feito e principalmente quais os requisitos mais urgentes que devem

ser priorizados.

Quadro 2 - Exemplo de uma Planilha de Requisitos

Aplicação web

Cod Requisito Prioridade Dificuld

ade Atendido Comentários

F001 Inserir/Alterar/Excluir Enquete. Baixo Baixo Não

F002 Todo comentário deve gravar o IP do usuário Alto Baixo Sim

IP não deve ser exibido para usuário.

F003 Listar Notícias por Categoria Médio Médio Não

F004 Somente usuário nível "Master" pode cadastrar Novos usuários Alto Alto Sim


3.4.2 Documento de Design Funcional

O Documento de Design Funcional é um conjunto de Wireframes onde cada

um representa cada página da aplicação. O Wireframe (figura 5) representa a

arquitetura de uma página web com a disposição dos elementos, mas não é função

demonstrar a estética, como conjunto de cores e fontes, por exemplo. Entretanto,

serve como esboço para o designer produzir os Templates da aplicação.

30

Figura 5 - Wireframe da página inicial de um site.


3.4.3 Template

O Template, também chamado de Protótipo de Interface, como mostra a figura

6, pode representar parte da aplicação a ser implementada, uma funcionalidade, ou

uma proposta de layout, feita pelo designer. Para isso, o designer precisa utilizar o

Documento de Design Funcional ou parte dele para ter uma base de como será o

posicionamento de cada elemento na aplicação. Além disso, este recurso fornece ao

cliente uma prévia, ainda que não funcional, de como será a interface da aplicação,

demonstrando principalmente o conjunto de cores. Por isso é importante o cliente

aprovar o Template antes de este ser implementado.

31

Figura 6 - Template da aplicação web Dinheirama Online

Fonte: DINHEIRAMA ONLINE, 2012.

Como visto no capítulo, o WAAPRO possui vários recursos que tem origem em

processos já existentes. Outros foram inseridos para atender às características de

aplicações web.

32

4 APLICAÇÃO DO LEAN NO PROCESSO

A maioria das empresas que querem adotar processos ágeis não fazem uso de

boas práticas de engenharia de software, e adotar qualquer procedimento pode ser

difícil. Por esse motivo, criou-se um conceito que tem como objetivo auxiliar as

empresas a equilibrar corretamente o uso de práticas, princípios e valores em todos

os níveis de uma organização, promovendo assim, uma mudança segura e

sustentável na cultura interna e nos métodos de desenvolvimento e assim criar uma

empresa efetivamente ágil e enxuta.

O suporte à mudança precisa ser geral, não somente da gerência executiva, mas também do chão de fábrica. Normalmente, a primeira reação das pessoas é a resistência – sendo assim, imposição nunca será o melhor caminho. É preciso abrir espaço, dar as ferramentas adequadas e criar um ambiente que seja propício à mudança (CRESCÊNDIO, 2011).

O Lean é uma filosofia de negócio baseada no Sistema Toyota de Produção.

Durante 25 anos a Toyota aperfeiçoou seu sistema enxuto e provou que pode ser

competitiva, tornando-se a maior e mais lucrativa montadora de automóveis. Através

desse pensamento Lean, é possível identificar o que gera valor na visão dos clientes

e usuários.

O ponto inicial para o pensamento Lean é reconhecer que apenas uma fração

do tempo total e esforço de uma organização adicionam, de fato, valor ao cliente.

Apesar dos princípios e conceitos gerais sobre essa abordagem já terem mais de 50

anos, só recentemente é que estes passaram a ser conhecidos e terem uma devida

aceitação. Isso mostra que a economia mundial afeta muitas empresas, deixando

muitas em dificuldades para sobreviver, lutando para reduzir custos sem prejudicar a

qualidade e serviço ao cliente.

A visão do Lean além de evitar o desperdício é produzir serviços ou produtos

de qualidade e que gerem valor para o cliente. De forma simplificada, valor consiste

nas características perceptíveis ao cliente, que cada produto ou serviço proporciona

ao seu negócio. Por exemplo: preço, qualidade, prazo de entrega, atendimento

prestado, funcionalidades de acordo com as necessidades especificadas. Ou seja, o

produto ou serviço exatamente como o cliente deseja.

33

4.1 PRINCÍPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE

Neste tópico são mostrados os princípios do Lean direcionados para o

desenvolvimento de aplicações web, tais como, eliminar o desperdício, amplificar o

aprendizado, entregar o mais rápido possível, respeitar, integrar e visualizar o todo.

4.1.1 Elimine o desperdício

Evite fazer mais que o necessário. Elimine qualquer coisa que não agregue

valor ao produto e que não são percebidas pela cliente. Por exemplo, se o time

entrega funcionalidades incompletas, se produz documentação de análise apenas

para estar em concordância com o processo, se não prioriza casos de uso e

implementa mais funcionalidade que o necessário de imediato. Isso tudo é

desperdício.

4.1.2 Amplifique o aprendizado

É importante ter um processo de desenvolvimento que encoraje a sistemática

de aprendizagem ao longo do ciclo de desenvolvimento. Os desenvolvedores têm

que ter a capacidade de responder rapidamente a mudanças de requisitos por parte

do cliente. Um código sofre constantes mudanças, portanto, é preciso codificar de

forma simples, geralmente orientado a testes.

Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de redução de variações, e por essa razão, aprender a abordagem de desenvolvimento resulta em práticas que são bastante diferentes do que aprender abordagens de práticas de produção (DAVIDSON, 2010).

4.1.3 Entregue o mais rápido possível

Segundo Crescêndio (2011), há duas grandes razões para entregar rápido:

para que o cliente não mude de ideia enquanto um projeto está em desenvolvimento

e para que o concorrente não entregue antes. Além disso, reduzir os ciclos e

entregar rápido e de forma incremental permite feedback e aprendizado sobre o que

34

está sendo feito. Assim, é que preciso descobrir como entregar uma aplicação

funcional tão rápido que clientes não tenham tempo para mudar suas ideias.

4.1.4 Respeito

Respeitar as pessoas do ponto de vista do Lean não significa aplicar apenas o

bom senso e a boa educação. A forma como uma equipe se organiza influencia

profundamente no respeito às pessoas. Fazer o simples como dar visibilidade do

trabalho feito, prover e aceitar feedback, errar o quanto antes e deixar todo mundo

saber, são exemplos de respeito. “Um ambiente Lean dá espaço para que todos

possam aprender abertamente sobre esse tipo de problema e assim resolvê-los de

uma forma adequada” (CRESCÊNDIO, 2011).

4.1.5 Construa com integridade

Existem dois tipos de integridade, sendo: Conceitual é aquela que só os

construtores sabem que existe. Percebida é aquela que os usuários podem notar.

Para que se tenha integridade, é preciso uma comunicação efetiva, criando assim,

um fluxo contínuo de informações entre desenvolvedores, usuários e clientes.

4.1.6 Visualize o todo

Este princípio valoriza o aprendizado do ambiente de desenvolvimento, todas

as pessoas precisam enxergar e compreender o todo e criar uma organização que

contribua para a melhoria de seus processos. Por exemplo, se uma equipe tem

especialistas em certas partes de um código e só eles conseguem mexer lá,

certamente as demais pessoas da equipe não estão vendo o todo.

4.2 OS BENEFÍCIOS DO LEAN

Mesmo com origem em um ambiente de produção industrial, o Lean passou a

ser aplicado em empresas de diversos setores e atividades. De modo geral, é

possível identificar os mais significativos benefícios resultantes da aplicação

“pensamento Lean” nas empresas, que podem ser resumidos da seguinte forma:

35

Crescimento do negócio;

Aumento da produtividade;

Aumento da satisfação do cliente;

Aumento da qualidade e do serviço prestado ao cliente;

Maior envolvimento, motivação e participação das pessoas;

Redução das áreas de trabalho;

Aumento da capacidade de resposta;

Redução do lead time (tempo em que se recebe um requisito até a entrega

da funcionalidade).

O caminho para que uma empresa ou um uma equipe de desenvolvimento se

torne Lean nem sempre é fácil, requer o envolvimento e o compromisso de todos.

Nesse tempo, as empresas passam por vários estágios de desenvolvimento, e

nessas etapas é necessário estabelecer metas e objetivos, quantificar resultados e

atuar em função de desvios. Alguns requisitos para o sucesso são:

Envolvimento da gestão de topo;

Aderir ao conceito “O cliente em primeiro lugar”;

Estar consciente em relação aos problemas;

Gerenciar o processo através de resultados e fatos;

Criar qualidade em tudo que se faz;

Implementar as mudanças envolvendo todas as pessoas.

As metodologias ágeis são um processo de melhoria que uma empresa pode

adotar para desenvolver aplicações web com melhor qualidade, seguindo um padrão

para documentação do que está sendo construído, eliminando desperdícios, erro e

até com um custo menor. A grande dificuldade é como implementar essa abordagem

de forma eficiente e sem causar grande impacto na empresa. Por exemplo, a equipe

de desenvolvimento pode sentir dificuldade em aplicar muitas práticas e acabar

atrasando o cronograma de entrega do produto. É preciso saber quando usar cada

recurso das metodologias ágeis. Uma solução apresentada para esse problema é a

prática Lean, que surge com a finalidade de ser o caminho para a mudança do

estado atual da empresa (sem práticas ágeis) até o uso efetivo de uma metodologia

ágil. Acredita-se que o Lean junto com o processo ágil WAAPRO pode tornar uma

36

equipe mais eficiente ao produzir aplicações web que gerem valor de negócios para

o cliente.

37

5 MODELO DE CUSTOMIZAÇÃO DO PROCESSO ÁGIL PARA APLICAÇÕES

WEB - WAAPRO

Diante da crescente necessidade de um processo de desenvolvimento ágil

voltado para aplicações web, foi proposto um modelo capaz de suprir os objetivos

dos desenvolvedores, no que diz respeito a uma melhor organização dos projetos.

A seguir, será descrito o processo WAAPRO (Processo Ágil para

Desenvolvimento Aplicações Web) e as características utilizadas do XP, SCRUM e

P@PSI.

5.1 O QUE É WAAPRO?

WAAPRO é um processo ágil customizado com o objetivo de tornar projetos de

aplicações web organizados, no que diz respeito aos ciclos de desenvolvimento e

documentação utilizada, e ser de fácil aceitação para desenvolvedores com pouca

ou nenhuma experiência no desenvolvimento de projetos utilizando metodologias

ágeis. O WAAPRO é dividido em quatro fases, Planejamento, Desenvolvimento,

Finalização e Manutenção, como mostra a figura 7. A seguir serão explicadas as

fases do processo.

5.2 PLANEJAMENTO

A fase de Planejamento se inicia com o Levantamento e Análise de Requisitos.

Neste momento, ocorre a primeira entrevista com o cliente, onde este expõe suas

necessidades e seus objetivos com o desenvolvimento de uma aplicação web. É

extremamente importante a equipe levantar todas as informações que possam ser

utilizadas no decorrer do projeto.

Com as informações coletadas, a equipe começa a trabalhar nas estórias de

usuário, ou seja, analisam cada situação proposta pelo cliente e as transformam em

uma funcionalidade como, por exemplo, “Cadastrar Notícia”, representando através

de um diagrama de caso de uso. Esse é o início da documentação do projeto.

Com base nesses dados, é elaborada uma Proposta de Desenvolvimento, que

é um documento que expressa todas as informações do projeto, no que diz respeito

ao tempo de desenvolvimento, funcionalidades a serem desenvolvidas, mídias e

38

conteúdos a serem inseridos, o que o projeto não irá conter, ou seja, o que não faz

parte do escopo do projeto, e o custo total.

Em seguida, é realizada uma nova reunião com o cliente para apresentar a

Proposta de Desenvolvimento. Neste momento, o cliente decide se dará ou não

continuidade ao projeto. Caso ele não esteja de acordo com alguma especificação

no documento, pode solicitar alteração. Sendo aprovado, o projeto segue para o

início da criação do briefing. De acordo com Waiteman (2005 p. 38), briefing consiste

em:

[...] no máximo, duas páginas com informações dissecadas e organizadas, que representam tudo o que o cliente deseja da agência. O briefing explica o problema, sugere caminhos de posicionamento e faz o pedido de trabalho. A você, cabe transforma o problema descrito no briefing em uma solução [...].

O briefing é o documento que auxilia todos da equipe a ter conhecimento sobre

o cliente e, mais, serve para os responsáveis pela criação do template produzirem

as interfaces com base nas informações contidas no briefing.

Durante a criação do template é necessário, também, criar um modelo de

organização, uma forma de melhor exibir as informações para o usuário, tornando a

aplicação fácil de utilizar e navegar. Após o template finalizado, é necessária a

aprovação do cliente, havendo alterações, o processo retorna para a etapa de

Criação do template e Modelo de Organização, caso contrário é iniciado a etapa de

Desenvolvimento.

5.3 DESENVOLVIMENTO

Com o início da fase de Desenvolvimento, o template passa por um

refinamento, ou seja, são coletadas e ajustadas as mídias e conteúdos que serão

implementados na aplicação web. É o conteúdo solicitado previamente ao cliente,

como imagens, vídeos, produção de textos, etc.

Após o refinamento do template se inicia o ciclo de codificação dos casos de

uso, que está divido em três etapas e não deve ultrapassar o período de quatro

semanas, sendo:

Codificar funcionalidades, propriamente dito, escrever os códigos e toda a

logica de programação, independente das ferramentas e tecnologias utilizadas, a

39

codificação tem que ser simples e de fácil manutenção. Para isso, são utilizados

alguns padrões de desenvolvimento, como programação orientada a objetos,

frameworks de desenvolvimento ágil, padrões de programação para uso de banco

de dados, entre outros. Para cada código escrito, são feitos testes, a fim de se

certificar, que além de estar funcionando devidamente, não possui problemas

quando for relacionado com outros elementos da aplicação.

Com a funcionalidade devidamente codificada, segue-se para a fase de

implementação. Nesse momento, o código vai ser integrado a outros, podendo ser,

ao código principal da aplicação. Em caso de erros, estes são corrigidos e vários

testes são feitos para que ao final do ciclo, a aplicação não apresente problemas.

Para que não haja nenhuma falha, a funcionalidade ainda passa por mais testes,

são os Testes de Funcionalidade.

Nesse momento, a funcionalidade já está ativa na aplicação, mas é necessário

certificar que tudo está em perfeita ordem para uso pelos usuários. Os testes servem

para encontrar falhas, assim são simuladas as ações do usuário, caso seja

encontrado algum erro, o ciclo não é finalizado e retorna para a implementação, ou

se necessário, para a codificação da funcionalidade.

Para finalizar o processo de Desenvolvimento, é preciso fazer a integração das

mídias e conteúdo às funcionalidades. Por exemplo, seguindo o exemplo dado

anteriormente com a funcionalidade “Cadastrar notícia”, os itens necessários para

cadastrar uma notícia seriam: texto, imagens, vídeos. Feito a inserção desse

material, a funcionalidade está concluída e o ciclo continua até que todos os casos

de uso sejam concluídos.

5.4 FINALIZAÇÃO

Na fase de Finalização entende-se que o produto já está completo,

necessitando apenas de revisão. Nesse primeiro momento, são realizados testes em

todo o produto, testando cada funcionalidade e revisando todos os textos, bem como

revisão ortográfica nas palavras.

Se tudo estiver pronto, o produto é então apresentado para o cliente. Caso, o cliente

não esteja satisfeito com algum detalhe, o produto então retorna para o Refinamento

do Template (fase de Desenvolvimento), para que os detalhes possam ser

reavaliados e as alterações sejam feitas. Não havendo nenhum questionamento por

40

parte do cliente, o produto é então entregue, sendo necessário apenas o

treinamento para utilização da plataforma de administração da aplicação web,

quando necessário.

5.5 MANUTENÇÃO

No modelo tradicional de desenvolvimento de software, o produto geralmente é

finalizado na fase de encerramento, não tendo uma fase que contemple a

manutenção do mesmo. Porém, no desenvolvimento web, as mudanças são

contínuas, e não se pode dizer que o produto está finalizado após a entrega ao

cliente e ao seu treinamento. Pois mesmo após essas etapas, a aplicação pode

sofrer mudanças. Para solucionar esse problema é necessária uma fase de

Manutenção.

Nessa fase é solicitada pelo cliente a alteração em alguma funcionalidade.

Quando isso acontece, a funcionalidade volta para fase de Desenvolvimento, mais

especificadamente para a etapa Refinar Template, passando pelo ciclo de

desenvolvimento completo, depois para revisão da alteração, na fase de Finalização,

até a apresentação da alteração para o cliente.

Assim, pode-se dizer que a manutenção é uma consequência da entrega do

produto, porém cada mudança solicitada termina na fase de Finalização, porque

passa por todas as etapas dessa fase em um ciclo contínuo.

40

Figura 7 - Visão geral do WAAPRO

Fonte: Arquivo Pessoal, 2012.

42

6 ESTUDO DE CASO

Este capítulo apresenta um estudo de caso, onde o processo ágil WAAPRO foi

utilizado na empresa W3Mais Comunicação Interativa, para o desenvolvimento de

um site interativo para a empresa Sistema Guarany de Comunicação. O site pode

ser visualizado através do link <http://www.portalguarany.com.br>.

6.1 O CLIENTE

O Sistema Guarany de Comunicação é um grupo formado pela Rádio Guarany

FM, TV e Portal Guarany.

A Rádio Guarany FM foi inaugurada em 1981 com a ideia de expandir os

trabalhos que foram iniciados com o serviço de propaganda volante Guarany e

cobertura de eventos religiosos. Atualmente a rádio opera na frequência 100,3 Mhz

e tem ouvintes de todas as faixas etárias, sendo a mais popular na cidade de

Santarém (PORTAL GUARANY, 2012).

Retransmissora da Rede Record de Televisão, a TV Guarany, “desde sua

formação proporciona entretenimento, descontração e jornalismo opinativo de

credibilidade mais perto do povo.” (PORTAL GUARANY, 2012).

O Portal Guarany foi criado para suprir a necessidade de uma comunicação

mais ampla via internet com os ouvintes, telespectadores e internautas. Assim, a

Rádio Guarany FM passou a ser ouvida por pessoas do mundo todo.

6.2 O PROJETO

A finalidade do Portal Guarany é ser um elo interativo entre os ouvintes da

Rádio Guarany e os apresentadores dos programas, bem como servir como portal

de conteúdo com notícias regionais e do território brasileiro. As funcionalidades

principais são: Rádio Interativo, Notícias, Mural de Recados e Programação da

Rádio. Outras funcionalidades secundárias também fizeram parte do projeto, como:

Galeria de fotos, Feed de posts do Twitter, Feed de notícias do Portal R73, sistema

3 Portal de conteúdo da Rádio e Televisão Record S/A.

43

de Publicidade, código de rastreamento do Google Analytics e também, o link para

ouvir a rádio on-line.

6.3 PLANEJAMENTO

A fase de Planejamento inicia-se através do contato com o cliente, no caso o

cliente é o Sistema Guarany de Comunicação. Esta fase inclui o Levantamento e

Análise de Requisitos para entender as necessidades do cliente e quais

funcionalidades o site irá conter; Proposta de Desenvolvimento que é a elaboração

de um documento com as informações sobre o projeto e Briefing que é um recurso

útil para o Designer criar um Template que se adeque a proposta do cliente.

6.3.1 Levantamento e Análise de Requisitos

A fase inicial do projeto diz respeito à avaliação da situação e das

necessidades do cliente. Na primeira reunião o cliente expôs suas necessidades.

Primeiramente, o site deveria ter uma seção específica em que o usuário pudesse

responder a questionamentos diários, sempre uma pergunta polêmica sobre a

atualidade. Esses comentários seriam lidos pelo apresentador do programa Rádio

Interativo ao vivo, portanto os dados deveriam ser validados de modo que um

usuário não se passasse por outro. Segundo, uma seção tipo mural de recados,

onde os usuários pudessem enviar mensagens para qualquer pessoa. Terceiro, uma

área especial de notícias com quatro categorias específicas (Santarém, Pará, Brasil,

Mundo). Quarto, mostrar o programa que a rádio estaria apresentando no momento

em que o usuário acessasse o site, além de um link que ao ser clicado, o usuário

pudesse ouvir a rádio ao vivo.

Outras necessidades também foram mencionadas, como ter uma galeria de

fotos, onde o administrador pudesse cadastrar fotos dos eventos do Sistema

Guarany de Comunicação. Uma forma de exibir as notícias do Portal R7 e as

publicações feitas no Twitter pela conta oficial do Portal Guarany. E, um sistema de

publicidade, que empresas interessadas em anunciar no site pudessem ter seu

banner exposto de forma simples.

De posse dessas informações foi necessário transformar essas estórias de

usuário em funcionalidades que o site iria conter. Para isso, foi elaborado um

44

Diagrama de Caso de Uso, que serviu para melhorar a visualização de todos os

recursos que o site poderia oferecer. A figura 8 mostra as funcionalidades exibidas

para os usuários, ou seja, o front-end4 do site.

Figura 8 - Diagrama de Caso de Uso do Portal Guarany.


Para que o diagrama fique mais bem explicado, estão descritos todos os casos

de uso (quadro 3).

Quadro 3 - Descrição dos Casos de Uso do Portal Guarany.

Comentar Mural de Recados Apresenta as mensagens enviadas de um usuário para outro.

Visualizar Notícias

Exibe as notícias de todas as categorias em ordem de postagem. Todas as notícias tem formulário para postagem de comentários com moderação pelo administrador.

Comentar Rádio Interativo

Uma pergunta com opção para o usuário comentar com os campos: nome, bairro e comentário. O comentário só fica visível após a

4 Área pública visualizada pelo usuário de um site.

45

liberação pelo administrador.

Visualizar Programação ao vivo

Exibe o programa da rádio transmitido no momento e uma foto do apresentador. Também exibe um link para o usuário ouvir o programa on-line.

Ouvir Rádio on-line Link externo para o usuário ouvir a rádio on-line.

Visualizar Feed Twitter Exibe postagens da conta @portalguarany no Twitter.

Visualizar Feed Portal R7 Exibe notícias do Portal R7.

Visualizar Galeria de fotos Exibe fotos separadas por galerias (álbuns).


O Portal Gurany possui funcionalidades que apenas podem ser vistas pelos

administradores do site. Para não haver confusão no desenvolvimento, foi feito um

novo Diagrama de Caso de Uso, mostrado na figura 9, apresentando as

funcionalidades acessíveis para os usuários da administração do site. Como mais de

uma pessoa teria acesso, foi solicitado que os usuários tivessem níveis de acesso.

Portanto, ficou definido que o nível Master teria acesso a todas as funcionalidades

do sistema de administração e o nível Web Master teria acesso apenas à liberação

de conteúdo, não podendo cadastrar novos usuários, por exemplo.

Figura 9 - Diagrama de Caso de Uso do Sistema de Administração do Portal Guarany.


46

Quadro 4 - Descrição dos Casos de Uso do Sistema de Administração do Portal Guarany.

Manter Notícias Possibilita inserir, alterar, excluir e consultar notícias publicadas.

Manter Administrador Possibilita inserir, alterar, excluir os administradores do site.

Manter Destaque Possibilita inserir, alterar e excluir imagens em destaque na página inicial (slideshow) do site.

Manter Programação ao vivo Possibilita inserir, alterar, excluir e consultar os programas da Rádio Gurany FM.

Manter Galeria de fotos Possibilita inserir, alterar, excluir e consultar galerias de fotos publicadas no site.

Manter Rádio Interativo

Possibilita consultar, publicar e excluir comentários publicados pelos ouvintes. Além de poder inserir, alterar status e excluir as perguntas.

Manter Publicidade Possibilita inserir e excluir as publicidades do site.

Manter Mural de recados Possibilita publicar e excluir comentários feitos pelos internautas do site.

Fazer Login É através desta funcionalidade que o administrador pode ser acesso ao sistema administrativo.


6.3.2 Proposta de desenvolvimento

Nesta etapa foi elaborada uma proposta de desenvolvimento (ver anexo A),

que visa mostrar para o cliente quais funcionalidades seriam desenvolvidas e o que

elas fariam (como exemplificado no Quadro 4), além de tempo e custo total de

desenvolvimento.

Sabendo que o site iria ter páginas informativas e estáticas, como conteúdo

sobre a empresa, serviços, área comercial e formulário de contato, esses itens foram

inseridos na proposta.

Algo muito importante é a verificação de disponibilidade do domínio do site. O

domínio deveria ser portalguarany.com.br, que foi verificado e comprado junto ao

site Registro.br, responsável pelo registro de domínios brasileiros.

47

6.3.3 Briefing

Após a aprovação da Proposta de Desenvolvimento pelo cliente foi necessário

elaborar um briefing (ver anexo B) com informações relevantes para o

desenvolvimento do site, como informações sobre o Sistema Guarany de

Comunicação, a identidade visual, e o que seria utilizado no design do site. Essas

informações são úteis no processo criativo do designer responsável por criar o

Template do site e das páginas que este contém.

6.3.4 Template

Para o desenvolvimento da parte visual do site foi utilizado o recurso wireframe.

A equipe de desenvolvimento fez um rascunho do layout do site com as

funcionalidades descritas no Diagrama de Caso de Uso. O wireframe só representa

a disposição do layout e pode ser visto abaixo, na figura 10.

Figura 10 - Wireframe da página inicial do Portal Guarany.


48

A partir do wireframe o designer começou a trabalhar na parte estética do site,

ou seja, o desenho com as cores e imagens dispostas no layout. Essa etapa exigiu

bastante criatividade, mas com o briefing em mãos a tarefa de construir o template

ficou mais fácil, pois já se sabia que a cor principal seria um tom de verde e cores

variadas que indicassem cada seção do site, como mostra a figura 11.

Terminado o template, este precisou ser aprovado pelo cliente. Para isso, em

uma reunião o template foi apresentado e com poucos questionamentos, logo foi

aprovado, dando sequência ao desenvolvimento.

Figura 11 - Template do site Portal Guarany.


49

Também é necessário criar o layout para o sistema de administração do site,

como mostra a figura 12. Nesse caso, não foi necessário passar pela aprovação do

cliente, pois essa parte do sistema apenas foi adaptada para o site Portal Guarany,

uma vez que a tecnologia é licenciada pela W3Mais Comunicação Interativa

mediante contrato. Isso gera um ganho de tempo na inclusão e exclusão de

funcionalidades no desenvolvimento de novas aplicações.

Figura 12 - Sistema de Administração do Portal Guarany.


6.4 DESENVOLVIMENTO

O projeto Portal Guarany possui muitas funcionalidades, portanto foi necessário

priorizar algumas para iniciar a fase de desenvolvimento. O WAAPRO permitiu ao

projeto ser feito em módulos. Neste trabalho é apresentado, na etapa de codificação,

o módulo que consiste em três funcionalidades, sendo elas: Mural de Recados,

Notícias e Rádio Interativo.

Na etapa de desenvolvimento foi testado um princípio do Lean que é adotar

medidas preventivas em tudo o que é feito, como um ciclo onde se planeja, executa,

verifica e faz algo funcionar, seja um código ou uma funcionalidade inteira.

50

6.4.1 Coleta de conteúdo

Antes do início do desenvolvimento é necessário ter todo o conteúdo das

páginas. É especificado no contrato de desenvolvimento que o cliente tem um prazo

para entregar todo o material necessário para o desenvolvimento do site, isso inclui

textos, imagens, vídeos ou qualquer conteúdo que precise estar no site no ato da

entrega (alguns conteúdos podem ser inseridos pelo próprio usuário através do

sistema de administração). Com o conteúdo em mãos o desenvolvimento foi

passado para a fase de codificação.

6.4.2 Diagramação do Template

A primeira etapa da codificação do site é transformar o Template – que é uma

imagem – em código. Isso requer o uso de alguns recursos web como a linguagem

de folhas de estilos CSS e o XHTML que é uma linguagem de marcação semântica.

No CSS ficam as regras do que será exibido das páginas, como cores, fundos,

tamanhos de divs5, posicionamento de divs, fonte do texto, etc. Cabe ao XHTML

separar o conteúdo semanticamente para receber os estilos do CSS.

O site fica exatamente igual ao desenho feito pelo designer, porém em forma

de códigos prontos para serem implementados em linguagem dinâmica, que

especificamente nesse projeto foi utilizado o PHP.

6.4.3 Codificação

No Portal Guarany foi utilizado alguns padrões de desenvolvimento como

orientação a objetos, MVC e DAO. Isso traz alguns benefícios, como a rapidez na

manutenção do código.

Para início da codificação das funcionalidades priorizadas foi utilizado

Diagrama de Classes para modelar as classes de cada funcionalidade.

Basicamente, cada diagrama representa a classe seus atributos e uma classe

auxiliar com os métodos de controle.

5 Elemento HTML que define uma divisão na página e pode ter variadas formatações.

51

A funcionalidade Notícia exemplificada pelo diagrama da figura 13 representa

que cada notícia tem apenas uma categoria, podendo ser Santarém, Pará, Brasil,

Mundo. Além disso, cada notícia pode receber comentários.

Figura 13 - Diagrama de Classe da funcionalidade Notícia


A funcionalidade Rádio Interativo, representada na figura 14, mostra que há um

relacionamento entre uma questão e um comentário, onde a questão pode receber

vários comentários, porém os comentários possuem um status do tipo boolean, que

indica que o administrador do sistema é quem publica ou não o comentário.

52

Figura 14 - Diagrama de Classe da funcionalidade Rádio Interativo


A terceira funcionalidade priorizada foi a Mural de Recados (figura 15). Aqui

pode-se ver que apenas uma classe faz o controle dessa funcionadade. O usuário

pode enviar um comentário para um outro usuário, porém esse comentário só fica

visível mediante publicação do administrador do sistema, por isso o uso do atributo

status com tipo de dado boolean.

Figura 15 - Diagrama de Classe da funcionalidade Mural de Recados


53

Também foi utilizado o Diagrama ER para modelar o banco de dados e para

definir as tabelas necessárias para armazenamento de conteúdo. Este tipo de

artefato ajuda a entender melhor os relacionamentos entre tabelas. Como mostram

as figuras 16, 17 e 18, representando as funcionalidades Notícia, Rádio Interativo e

Mural de Recados respectivamente. A partir disso, foi possível criar todo um

conjunto de classes que permitem manipular os dados das tabelas.

Figura 16 - Diagrama ER - Notícia.


54

Figura 17 - Diagrama ER - Rádio Interativo.


Figura 18 - Diagrama ER - Mural de Recados.


A modelagem do sistema foi realizada de forma iterativa, pois os modelos

criados foram surgindo conforme a necessidade de registrar o que se produzia. Essa

forma de trabalhar é característica das metodologias ágeis.

55

Durante o desenvolvimento do Portal Guarany algumas funcionalidades ficaram

um pouco confusas na hora da codificação, uma delas foi o caso de uso Rádio

Interativo, responsável direto pela interação dos usuários do site com a Rádio

Guarany FM. De fato, o cliente queria que cada pessoa que comentasse na Rádio

Interativo fosse única e esses comentários deveriam ser moderados pela

administração. O problema era como fazer isso da forma mais simples possível e

que não dificultasse a forma de interação do usuário com o site. Ao se tentar fazer o

que o cliente queria, perdeu-se muito tempo desenvolvendo uma funcionalidade de

forma que não gerava valor algum para o cliente e ainda dificultava a interação como

usuário. Seguindo a ideia de processo enxuto Lean, para criar algo que realmente

trouxesse valor para o negócio do cliente foi feita uma análise de como o Rádio

Interativo funcionaria. Uma forma de solucionar o problema foi visualizá-lo melhor

com diagramas de sequência. Não só para a funcionalidade Rádio Interativo, mas

nesse módulo procurou-se fazer também para a funcionalidade Notícia e Mural de

Recados.

Na funcionalidade Notícia, representada pelo diagrama de sequência na figura

19, foram discutidos quais campos seriam preenchidos pelo usuário e se o

comentário seria moderado pelo administrador ou não. Por fim, a equipe concordou

que todos os comentários seriam moderados pelo administrador, onde este poderia

apenas excluir ou publicar o comentário, ficando impedido de alterar qualquer

informação. Essa análise foi fundamental para desenvolver outras funcionalidades

que teriam o mesmo princípio.

56

Figura 19 - Diagrama de Sequência da ação comentar Notícia


Quando foi necessário fazer a codificação da funcionalidade Rádio Interativo,

houve uma dificuldade em tentar encontrar a forma mais simples de um usuário

comentar um questionamento. O cliente queria que o sistema pudesse identificar

fraude em um comentário, ou seja, um usuário não poderia comentar com o nome

ou outra informação pessoal igual à outra pessoa. A solução final, e mais simples, foi

que o usuário teria três campos para inserir dados, sendo Nome, Bairro e

Comentário, pois são as informações que o apresentador do Programa Rádio

Interativo lê ao vivo. Todos os comentários são moderados pelo administrador do

sistema. Somente após a publicação os comentários ficam visíveis para o usuário e

somente enquanto o questionamento estiver no ar. A representação do diagrama de

sequência pode ser vista na figura 20.

57

Figura 20 - Diagrama de Sequência da ação comentar Rádio Interativo


Quando a funcionalidade Mural de Recados foi codificada, já se tinha um

conhecimento de como ela iria se comportar, porém ainda foi representada através

de um diagrama de sequência (figura 21) que mostra a ação de enviar um recado e

a publicação do mesmo pelo administrador do sistema. Aqui a funcionalidade segue

a mesma ideia das outras, o recado só fica visível após a permissão pelo

administrador, e este pode excluir o comentário a qualquer momento, mesmo após a

publicação.

58

Figura 21 - Diagrama de Sequência da ação de enviar recado através do Mural de Recados


Como pôde ser notado no decorrer do processo de desenvolvimento, o

WAAPRO permitiu gerar conhecimento para toda a equipe discutir sobre como uma

funcionalidade iria se comportar e assim gerar conhecimento para funcionalidades

futuras. Os diagramas foram muito importantes para esclarecer dúvidas, pois muitas

vezes uma pessoa da equipe não conseguia visualizar, ou mesmo, fazer o cliente

entender como determinada ação acontecia.

6.5 FINALIZAÇÃO

Na etapa de Finalização busca-se fazer testes de toda a funcionalidade ou do

projeto inteiro pronto a fim de encontrar erros. Também, é caracterizada pela

entrega da aplicação para o cliente e o treinamento do mesmo.

59

6.5.1 Revisão do Produto

Cada funcionalidade foi testada a fim de localizar erros. Quando uma

funcionalidade apresentava um erro, ela voltava para a fase de Desenvolvimento até

estar pronta para ser testada com o site todo. Essa revisão do produto é importante

por simular a ação do usuário ao acessar o site, bem como o administrador do

sistema no momento de gerenciá-lo. O Portal Guarany tem muitas funcionalidades e

na hora de testar tudo algumas coisas não saíram como planejado, como o caso de

uso Ver Programação ao Vivo. No momento do teste percebeu-se que o fuso horário

do servidor era diferente do fuso horário brasileiro (Brasília), assim tendo que voltar

para o Desenvolvimento até ser corrigido e pronto para apresentar ao cliente.

6.5.2 Apresentação do produto ao cliente

O Portal Guarany foi apresentado através de uma reunião da equipe de

desenvolvimento com o cliente. Foi demonstrada cada funcionalidade em

funcionamento. Após o término da apresentação o cliente deu seu parecer sobre o

produto, no final gostou do que viu. Vale ressaltar que o site já estava em sua

hospedagem oficial, porém acessível apenas para a equipe de desenvolvimento.

6.5.3 Entrega do produto

A entrega do produto foi feita a partir do momento em que o site foi liberado

para que todos pudessem acessá-lo, deixando-o visível na web.

6.5.4 Treinamento

A administração do site possui muitas funcionalidades, tudo intuitivo, porém o

cliente queria que fosse ministrado um treinamento para duas pessoas responsáveis

pela administração do Portal Guarany. O treinamento foi feito de forma presencial e

foi realizado em dois dias.

60

6.6 MANUTENÇÃO

A fase de Manutenção existiu nesse projeto apenas para edição de alguns

textos em páginas estáticas e manutenção de funcionalidades e do banco de dados

que vez ou outra ocorria erros. Dessa forma, qualquer item a ser mudado no site

passava por todo o processo de Desenvolvimento até a Finalização.

61

7 CONCLUSÃO

O processo ágil WAAPRO se mostrou eficiente no desenvolvimento de

aplicações web, como pôde ser constatado no desenvolvimento do Portal Guarany.

O uso de etapas permitiu melhor controle do que se estava fazendo e não deixando

a equipe se perder quando ocorriam mudanças nos requisitos.

Em algumas etapas do projeto ficou evidente que o uso de um processo ágil

ajuda a minimizar desperdícios de tempo, regra fundamental de um processo Lean.

Como por exemplo, durante a codificação da funcionalidade Rádio Interativo, os

requisitos mudaram diversas vezes, a primeira vez foi produzido algo que o cliente

queria, porém não gerava valor algum. Isso foi constatado quando o site foi ao ar

durante alguns dias para testes com usuários iniciais. Durante aproximadamente 1

semana, não houve nenhum comentário na Rádio Interativo, isso significava que

algo de errado estava acontecendo. Portanto, a funcionalidade foi refeita mais duas

vezes, e somente na terceira mudança é que os comentários começaram a

aparecer. Para isso, tudo que dificultava a ação de comentar foi retirado. O usuário

simplesmente comentava e esperava o comentário ser publicado pelo administrador.

O Lean passou a ser fundamental junto com o processo ágil WAAPRO, pois

toda a equipe pôde aprender melhor como realizar as atividades focando no produto

e no usuário, além de fazer somente o que gerava valor para o cliente. Entretanto a

visão do Lean foi superficial. Percebe-se que para o aprendizado de uma

metodologia ágil e uma mudança de cultura numa empresa que não utiliza esse tipo

de processo de desenvolvimento leva bastante tempo, porque no início é difícil

assimilar o funcionamento do processo e mais difícil ainda é abandonar alguns

vícios, como o “pensar e fazer”, sem planejar cada etapa do processo de

desenvolvimento.

O uso de metodologias ágeis como o XP e o Scrum foram de extrema

importância para se ter uma visão mais ampla do que poderia ser utilizado como

característica para a criação do WAAPRO, uma vez que essas metodologias já

foram bastante testadas. O P@PSI permitiu ter uma melhor ideia de como um

processo ágil pode ser customizado e quais seus benefícios.

Procurou-se mostrar o funcionamento do WAAPRO através de um estudo de

caso para ter a validação do processo ágil junto com uma equipe de

desenvolvedores que não utilizavam nenhum tipo de processo específico nos

62

projetos, assim pôde-se ter um feedback quanto às vantagens do processo ágil junto

com o processo enxuto Lean em uma empresa. O resultado foi positivo, a equipe

conseguiu assimilar a ideia, porém levou bastante tempo. Não foi possível verificar o

lead time6 em todas as etapas, pois não tinha como comparar com outro estudo de

caso ou outro projeto feito a partir do WAAPRO.

Assim, o WAAPRO foi customizado para ser um processo simples de ser

utilizado por equipes inexperientes, mas que tenham interesse por um processo para

organizar e gerenciar melhor o desenvolvimento de uma aplicação web. É

importante ressaltar que para que um processo ágil se torne eficiente precisa partir

de uma mudança de cultura numa empresa ou na equipe de desenvolvimento. O

Lean sugere principalmente para empresas pequenas, uma série de princípios e

recursos para que desenvolvedores possam adquirir conhecimento para aplicar junto

com um processo ágil no decorrer de um projeto. Portanto, a fim de evitar

desperdícios, fazer somente o necessário quando for necessário e ter uma

organização e gerenciamento melhor dos projeto web, o WAAPRO surge com essa

alternativa.

Mesmo tendo sido visto superficialmente como forma de introduzir o processo e

gerar conhecimento para a equipe, com o Lean pôde-se comprovar uma melhora no

diálogo e na percepção de erros antes da implementação ou mudança de requisito.

Ainda é necessário um aprofundamento na visão Lean para verificar as reais

mudanças dentro de uma empresa que utiliza um processo ágil como o WAAPRO, a

fim de verificar em que pontos ela se torna realmente enxuta. Neste trabalho a única

etapa testada foi o Desenvolvimento, tendo resultados positivos. São necessários

mais testes com WAAPRO no desenvolvimento de aplicações web, para se ter uma

ideia se todas as etapas funcionam e o que precisa ser melhorado, a partir da visão

de outros desenvolvedores.

Espera-se, que a partir deste trabalho apresentado sobre a utilização de

metodologias ágeis na customização do processo web WAAPRO, possam surgir

projetos relacionados com o tema. Pois o mesmo oferece muitos benefícios para os

desenvolvedores que queiram manter seus projetos enxutos.

6 Tempo em que se recebe um requisito até a entrega da funcionalidade.

63

REFERÊNCIAS

ÁLVARES, Patrícia Marques Rodrigues de Sousa. WebPraxis – Um processo personalizado para projetos de desenvolvimento para a Web. 2001. 105p.

Dissertação (Pós-Graduação em Ciência da Computação). Instituto de Ciências Exatas da Universidade Federal de Minas Gerais. Belo Horizonte, 2001. Disponível em: <http://homepages.dcc.ufmg.br/~wilson/pesquisa/DissertacaoPatricia.pdf>. Acesso em 08 dez. 2011. BECK, Kent. Programação Extrema (XP) explicada: Acolha as mudanças. Porto

Alegre: Bookman, 2004. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. 6 ed. Rio de Janeiro: Elsevier, 2005. CRESCÊNDIO, Samuel. A Pirâmide Lean: O equilíbrio das Forças Ágeis. Edição

38. Devmedia Group, 2011. Disponível em: <http://www.devmedia.com.br/esmag>. Acesso em 28 abr. 2012. ISSN 1983127-7. DAVIDSON, Edgard. Princípios do Pensamento Lean. Disponível em:

<http://edgarddavidson.com/?p=1070>. Acesso em 23 nov. 2011. DE CARVALHO, Bernardo Vasconcelos. Aplicação do método ágil Scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnológica. 2009. 100p. Dissertação (Mestrado em Engenharia de Produção). Universidade Federal de Itajubá, Itajubá, 2009. Disponível em: <http://adm-net-a.unifei.edu.br/phl/pdf/0034997.pdf>. Acesso em 25 nov. 2011. DINHEIRAMA ONLINE. Dinheirama – Gerenciador de Conteúdo Financeiro. Disponível em: <https://www.dinheiramaonline.com.br>. Acesso em: 28 abr. 2012. GELLER, Marla; KNEBEL, Clóvis; BENTES JÚNIOR, João. GTA – Grupo de Trabalho Ágil – Desenvolvimento Ágil de Software através da customização de processos. III Congresso Sul Catarinense de Computação. Criciúma – SC, 2007.

GOLÇALVES, Geraldo Magela Dutra. A gerência de projetos de software em duas perspectivas – Parte 2: Scrum. Edição 38. Devmedia Group, 2011. Disponível em: <http://www.devmedia.com.br/esmag>. Acesso em 28 abr. 2012. ISSN 1983127-7. JACYNTHO, Mark Douglas de Azevedo. Processos para Desenvolvimento de Aplicações Web. 2008. 25p. Monografias em Ciência da Computação Rio de

Janeiro, Pontifícia Universidade Católica. 2008. Disponível em: <ftp://ftp.inf.puc-rio.br/pub/docs/techreports/09_23_jacyntho.pdf>. Acesso em 02 jun. 2012. LUNA, Alexandre; COSTA, Cleyverson; DE MOURA, Hermano. A necessidade de ser ágil: Uma análise crítica sobre nove métodos ágeis. Edição 27. Devmedia

64

Group, 2011. Disponível em: <http://www.devmedia.com.br/esmag>. Acesso em 28 abr. 2012. ISSN 1983127-7. MELO, Ana Cristina. UML – Diagrama de Sequências: Descobrindo como modelar um diagrama de sequências. Edição 15. Devmedia Group, 2009.

Disponível em: <http://www.devmedia.com.br/esmag>. Acesso em 23 abr. 2012. ISSN 1983127-7. PORTAL GUARANY. Sistema Guarany de Comunicação. Disponível em

<http://portalguarany.com.br/sgc.php>. Acesso em 26 mai. 2012. SATO, Danilo. Introdução à Programação Extrema (XP). Engenharia de Software Magazine. Edição 10. Devmedia Group, 2009. Disponível em: <http://www.devmedia.com.br/esmag>. Acesso em 22 abr. 2012. ISSN 1983127-7. SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis Tradicionais para o Desenvolvimento de Software. Infocomp: Jornal of Computer

Science. v 3, n 2, nov. 2004. Disponível em: <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em 25 nov. 2011. TANIGUCHI, Kenji; CORREA, Fernando Eugenio. Metodologias Ágeis e a Motivação de Pessoas em Projetos de Desenvolvimento de Software: Aplicando práticas de SCRUM e XP para promover a motivação de equipes de projetos de desenvolvimento de software. São Paulo, v. 4, n. 4, 2009. Disponível em: <http://sare.unianhanguera.edu.br/index.php/rcext/article/viewFile/1612/953>. Acesso em 02 jun. 2012. TELES, Vinícius Manhães. Um Estudo de Caso da adoção das práticas e valores do Extreme Programming. 2005. 179p. Dissertação (Mestrado em Informática)

Universidade Federal do Rio de Janeiro, Núcleo de Computação Eletrônica, Rio de Janeiro, 2005. Disponível em: <http://www.improveit.com.br/xp/dissertacaoXP.pdf>. Acesso 21 nov. 2011. WAITEMAN, Flávio. Manual Prático de Criação Publicitária: O dia-dia da Criação em uma Agência. São Paulo: Nobel, 2006. p 38. ISBN 85-213-1309-8.

65

ANEXOS

66

ANEXO A – PROPOSTA DE DESENVOLVIMENTO PORTAL GUARANY

Agência: W3MAIS COMUNICAÇÃO INTERATIVA

Cliente: PORTAL GUARANY

Proposta para desenvolvimento e administração de Site

I – NOSSA EMPRESA

A W3MAIS é uma agência web legalmente constituída, associada à

Associação Comercial e Empresarial de Santarém (ACES).

Para conhecer um pouco mais da agência é só acessar o site

www.w3mais.com.br e conhecer nossas soluções.

II – NOSSA PROPOSTA

Nossa proposta consiste no desenvolvimento de um site para o Portal Guarany,

incluindo layout personalizado. Segue abaixo as sugestões das sessões do site.

Seção Função

Principal Página inicial com chamadas para as principais seções do site.

SGC Apresenta descrição da empresa incluindo missão, visão e

valores.

Notícias Lista todas as notícias em ordem de publicação.

Serviços Apresenta todos os serviços úteis para os usuários (ex: número

do telefone do CIOP, Hospital Regional, PSM, Bancos, etc).

Participe Lista links Mural de Recados, Rádio Interativo e Redes Sociais.

Fotos Lista as galerias de fotos dos eventos da empresa.

Comercial Seção destinada para apresentação das empresas do grupo

SGC e informações para anunciantes.

Fale conosco Exibe as formas de contato da empresa: telefones, e-mails e

endereço.

Rádio

Interativo

Interação com os usuários através de uma pergunta principal

com opção para comentários.

Mural de

Recados Interação entre usuários por meio de comentários,

67

Programação Exibe o programa que está sendo transmitido no momento em

que usuário está acessando o site.

III – INVESTIMENTO

Desenvolvimento

Opções de parcelamento R$ Valor Total R$

Administração

(valor) mensal com os seguintes serviços inclusos:

Painel administrativo para cadastro, exclusão ou edição de conteúdo;

Hospedagem do site;

Relatório de visitas;

Monitoramento do site;

05 Contas de e-mail personalizado ([email protected]);

Suporte técnico em horário comercial sempre que solicitado;

O prazo para desenvolvimento e publicação do site é de 45 (quarenta e cinco)

dias.

Santarém – PA, 17 de Novembro de 2011

W3mais Comunicação Interativa Ltda.

E-mail: [email protected]

Telefones: (93) 3522.5689 / 9131.1989 Obs.: Esta proposta é válida por 10 (dez) dias

68

ANEXO B – BRIEFING PARA CRIAÇÃO DO TEMPLATE DO PORTAL GUARANY

Agência: W3MAIS COMUNICAÇÃO INTERATIVA

Cliente: PORTAL GUARANY

Briefing para criação do template do Portal Guarany.

1. Sobre o cliente

O Portal Guarany é o terceiro elemento do Sistema Guarany de Comunicação que

envolve Rádio, TV e Portal.

2. Serviços oferecidos

Notícias das cidades, Programação da TV Guarany e Interatividade com a rádio.

3. Referência de sites (outras empresas)

http://www.baladain.com.br/ (ver formato como os parceiros são exibidos).

http://www.baladacerta.com.br/

4. Público alvo

Todas as idades

5. O site vai ter os seguintes itens no menu

Principal, SGC, Notícias, Serviços, Participe, Fotos, Comercial, Fale Conosco.

6. Informações importantes sobre a página inicial do site

- No topo do site deve ter um botão “Ouça ao Vivo a Rádio Guarany”

- Banner com revezamento do mesmo tamanho de http://rederecord.r7.com/ e com o

mesmo formato: Foto + Título dentro da foto.

- Notícias: Lista as últimas 5 notícias com foto.

- 1 Banner Publicitário do tipo retângulo.

- Mural de Recados: Exibe os últimos dois recados do mural.

- Rádio Interativo: É uma enquete com perguntas. Ex: “O que você acha da situação

das ruas de Santarém? Você acha que está faltando mais atenção dos

governantes?”. E em seguida coloca dos botões. 1- Dê sua opinião 2- Leia os

comentários.

- Fotos: Exibe uma galeria de fotos.

69

- Twitter: Exibe os dois últimos posts do twitter parecido com o que tem em

www.saoraimundo.com.br

- No rodapé deve ter os logotipos do Sistema Guarany de Comunicação, da TV

Guarany (afiliada a Rede Record – Logotipo), Rádio Guarany.

7. Cores

Pode manter as cores do site anterior.

Background: #F9F9FC;

Menu: #667E00;

Títulos: cores sortidas em cada seção.

8. Imagem a ser transmitida para os usuários

Jovialidade e alegria (sem ser infantil).

tcc - utilização de metodologias Ágeis para adaptação de um processo de desenvolvimento de...

Education