USO DE METODOLOGIA ÁGIL NA CRIAÇÃO DE SITE WEB COM

INTEGRAÇÃO DE SOFTWARES INTERNOS

Marja Lena Kalinke1

Resumo

O objetivo deste trabalho é mostrar o uso da metodologia ágil como forma alternativa
aos ditos processos tradicionais na construção de site web com integração de sistemas
internos da empresa, no intuito de atendimento ao cliente. Os métodos ágeis estão cada
vez mais utilizados pelas empresas, como forma de adaptação ao mercado competitivo
atual. Serão discutidos aqui pontos fortes e fracos desses métodos. Estes têm sido os
métodos mais utilizados em empresas de pequeno e médio porte no âmbito Web, pois
permite a participação de equipes multifuncionais, com a inclusão dos clientes de forma
participativa. Sendo assim, o trabalho apresenta que é possível e benéfico para equipes
de desenvolvimento web utilizar métodos ágeis de construção sistêmica.

Palavras-chave: Metodologia ágil. Scrum. Criação web.

Abstract

The objective of this paper is showing the use of agile methodology as an alternative
way to the traditional process in a construction of a web page that integrates with
various internal softwares as a way to attend clients. Agile methods are becoming more
usual in companies, as a way to adapt the company to the actual competitive market.
This work will discuss the strong and weak points of these methods. These have been
the most used methods in small and medium web companies, because it allows to work
with multi functional teams and a more participatory role of the clients. Thus, this paper
shows that is possible and beneficial to web developers teams use systemic construction
agile methods. Thus, the paper shows that is possible and beneficial for web
development teams use agile methods in systemic construction.

Palavras-chave: Agile methods. Scrum. Web creation.

Introdução

Até o final da década de 90 o mercado de projetos e engenharias de softwares foi

dominado pelos métodos tradicionais, também conhecidos por metodologias pesadas,

1
Formada em Comunicação Social – Hab. em Publicidade e Propaganda pela Universidade Estadual do Centro-Oeste
(UNICENTRO), pós-graduada em Marketing e Gestão de Negócios pela ESIC – Business and marketing School e
acadêmica do curso de Pós Graduação em Análise de Processos de Negócios do Instituto de Gestão em tecnologia da
Informação. marjalenak@gmail.com.
uma vez que possuem características duras e pouco maleáveis. O método mais utilizado
até então é conhecido por Waterfall, em português, Cascata, pois possui como premissa
o desencadeamento de tarefas em subsequência, como uma cascata. Trabalhar com esse
método limita a troca de requisitos nas fases posteriores ao planejamento, deixando o
processo de criação mais duro e pouco adepto as mudanças de mercado atual.

Essa mudança de percepção de mercado fez com que mudasse também a

percepção de desenvolvimento das empresas, que passaram a enxergar novos processos
como solução. As ideias que norteiam o desenvolvimento ágil começaram antes mesmo
da década de 90, porém somente em 2001 foram publicados, sob forma de manifesto, os
princípios dessa metodologia (OLIVEIRA, 2003).

O Manifesto, Manifesto for Agile Software Developer (AGILE MANIFESTO),

define doze princípios da metodologia, a partir dos quais foram criadas metodologias
como Scrum, Extreme Programming etc. No manifesto, também são encontradas as
linhas orientadoras sob as quais surgiram as novas abordagens:

 Indivíduos e interações em vez de processos e ferramentas;

 Software que funciona em vez de documentação abrangente;

 Colaboração do Cliente em vez de negociação de contratos;

 Resposta a modificações em vez de seguir um plano.

A Standish Group publicou em 1995 um estudo, realizado com mais de oito mil
projetos de desenvolvimento de software, que revelava que, mesmo com as melhorias
obtidas na época, o setor ainda necessitava de mudanças.

O estudo mostra que a taxa de sucesso de projetos acima de US$10 milhões (com
mais de 500 pessoas e que aconteça por pelo menos 3 anos), é estatisticamente nula, ou
seja, não representa sucesso para o mercado. Para pequenos projetos (até US$ 750 mil),
a taxa de sucesso chega a 55%. Ainda no estudo é possível verificar que apenas 16,2%
dos projetos respeitaram o prazo de entrega, custos e todos os requisitos iniciais
pedidos. Quase 31% dos projetos foram cancelados, quase 53% foram entregues com
prazos maiores, com custos maiores e menos funcionalidades do que o especificado.
Considerando os projetos entregues no prazo e com custo maior apenas 61% (em
média) das funcionalidades especificadas foram desenvolvidas (JOHNSON, 1995).
 Nas Figuras 1 e 2 temos outras informações do estudo: aumento dos custos, atraso
de entrega, funcionalidades entregues e taxa de sucesso. Esta última refere-se a projetos
que resultaram em softwares utilizados pelo usuário final.

Fonte: Adaptado de Johnson (2001)

Figura 1 – Evolução dos parâmetros

Fonte: Adaptado de Johnson (2001)

Figura 2 – Taxa de sucesso de desenvolvimento

As metodologias ágeis forçam uma mudança no pensamento de cada empresa que

as adota, pois tiram o foco das documentações e planejamentos excessivos e transportam-
no para a visão cliente, interação e maleabilidade, trazendo consigo benefícios.

Essas mudanças de mercado, citadas anteriormente, também foram percebidas nas

aplicações web. Estas muito mais dinâmicas e voltadas a um público final mais
interativo, crítico e presente, acabam por perceber os retornos dos projetos
implementados, ou as consequências de más implementações, quando é o caso, com
maior antecedência e rapidez.

Segundo Ferrera (2014),

Com estes prazos, aumento de demanda e integração de novas tecnologias,

como o arquiteto de informação vai conseguir transitar dentro das fases do
projeto até sua entrega sem que exista um método oficial para integrar a
equipe? Neste momento entra o mocinho da historia: um método ágil
consegue fazer projetos de portais complexos em menos tempo e com
qualidade.

Ferrera (2014) ainda cita:

Hoje a gente vive num crescente descobrimento tecnológico voltado para a

internet. Desta forma fica difícil mensurar, em um modelo de gerenciamento
de projeto mais rígido, a complexidade dele como um todo, apenas em
algumas reuniões de levantamento de requisitos e imersões. Sem contar que o
cliente, que é também um usuário de internet, vê as tecnologias aplicadas em
outros sites e pode solicitar uma novidade que vai alterar o escopo a qualquer
momento.

É perceptível então, que os métodos duros de trabalho não atendem mais a

dinâmica do mercado de trabalho, onde as mudanças têm ocorrido constantemente e
quase sem possibilidade de previsão. O importante tem sido estar à frente e inovar,
como forma de se destacar perante a concorrência. Sendo assim, o presente artigo tem
como objetivo apresentar uma maneira de auxiliar as empresas nessa evolução de
mercado, não apenas inovando no produto final (entregue ao cliente de ponta), mas
também modificando seus procedimentos, métodos e visões internas, através do uso de
metodologias ágeis em suas aplicações web.

Este trabalho vai introduzir os conceitos de desenvolvimento de aplicações web e

particularidades na seção 2 e adjacentes. Logo após, apresentará a metodologia ágil,
seus benefícios e lacunas, apresentados na seção 3. Após, a seção 3.1 irá focar na
metodologia Scrum, um dos métodos ágeis mais utilizados nos dias atuais. Como
introdução ao estudo de caso, a seção 4 descreve a metodologia utilizada para o
desenvolvimento do presente artigo. E, finalmente, na seção 5 encontra-se um estudo de
caso em desenvolvimento web, que utilizou a metodologia scrum como método de
trabalho (metodologia apresentada na seção 3.1). Por meio desse estudo de caso é
possível perceber que uma equipe, mesmo que não acostumada com esse tipo de
metodologia, consegue se adaptar e entregar um site web com qualidade de requisitos
em curto espaço de tempo. Site que, neste caso de exemplo, ainda contém um grande
número de integração com diversos sistemas da empresa.
2. Aplicação Web

Um software tem como finalidade a entrega de valor ao cliente. Para que esta
entrega aconteça, um conjunto de atividades interdependentes deve ocorrer e gerenciar o
sistema. Estas atividades podem ser compostas de atividades menores que entregam um
tipo de artefato para alimentar alguma necessidade do sistema, gerando uma nova
entrega e assim por diante. Sem esse processo, o software entregue não teria
funcionalidade ou objetivo.

As aplicações web (sejam elas sites completos ou apenas um requisito do mesmo)

funcionam da mesma maneira e possuem o mesmo objetivo: a entrega de um sistema de
qualidade e interatividade para o cliente final.

Estas aplicações podem ocorrer em HTML, CSS e Java Script, contento simples
itens de textos e imagens ou interativas, contendo funcionalidades e serviços on-line,
como carrinhos de compra, autosserviços, visualizações dinâmicas, entre outras.

Seu desenvolvimento ocorre, em sua grande maioria, por equipes multidisciplinares

(arquitetos, designs, desenvolvedores, publicitários etc.) e com prazos curtos devido à
percepção/satisfação do cliente do projeto sobre o tempo e constante pressão de
concorrência e do mercado que exige das equipes agilidade, inovação e qualidade
convivendo no mesmo período de entrega. Ao que tange a tecnologia, os sistemas web
costumam ser ainda mais robustos e complexos do que softwares “comuns”, uma vez que
é necessário integrar os serviços exigidos (e que muitas vezes proveem de diferentes
sistemas) e exibi-los de forma amigável e transparente no front-end (JACYNTHO, 2009).

Outro ponto importante de ser citado é que cada página ou aplicação web
desenvolvido também deve levar em consideração a experiência do usuário e a
arquitetura de informação que está sendo disponibilizada, no que tange a linguagem da
programação, a formatação de textos e imagens, a inclusão de algoritmos do Google, de
pontos de visão do cliente na tela etc.

2.1 Diferenças entre aplicações web e aplicações convencionais

Para Jacyntho (2009) há características técnicas bem diferentes entre sistemas web
e convencionais que devem ser considerados no momento do desenvolvimento de um
sistema web:
  Diferenças relativas à aplicação:

 Conteúdo: além de propiciar a funcionalidade, deve-se ofertar um meio

de informação, dinâmico atualizado e gerenciável;

 Hipertexto: para estrutura a informação apresentada deve-se estabelecer

link e chamadas que interliguem todo o conteúdo;

 Apresentação: o front-end é o apelo principal da aplicação e mantem o

usuário “preso”;

 Requisitos não-funcionais de qualidade: disponibilidade 24/7,

desempenho, usabilidade, escalabilidade, robustez e segurança.

 Diferenças relativas ao uso:

 Disponibilização em diversos dispositivos: criação de diferentes visões

ou visão auto-adaptável para acesso pelos diversos meios;

 Infraestrutura: prever possíveis alterações as quais o usuário final tem

acesso e que podem afetar o desempenho da aplicação quando
desabilitadas, rejeitadas etc.

 Diferenças relativas ao desenvolvimento:

 Ambiente de desenvolvimento: flexível, adaptável e que aceite a

heterogeneidade;

 Integração com sistemas legados: capacidade de integração com sistemas

antigos, sem regras documentadas e que podem possuir diferentes
tecnologias de encapsulamento.

O mesmo autor (JACYNTHO, 2009) ainda faz citações sobre as diferenças

organizacionais para sistemas comuns e sistemas web e cita como principais:

 Incerteza dos clientes – devido à dinamicidade da web e ideias visionárias

que não correspondem à realidade de desenvolvimento atual;

 Alta volatilidade dos requisitos de negócio – à medida que a posição da

empresa na web muda, o próprio modelo de negócio da empresa pode mudar;

 Ciclos de desenvolvimentos curtos – prazos curtos para desenvolvimento;

 Alta competividade – mercado está em constante atualização;

  Equipes multidisciplinares – diferentes formações encapsulados num mesmo
projeto, tendo opiniões e ideias com objetivos contrários;

 Diversidade de tipo de usuário – por se tratar de um ambiente livre, qualquer

faixa etária, escolar etc. pode acessar e criticar o trabalho exposto;

 Sazonalidade – aplicações podem ter que respeitar períodos, promoções,

épocas de ano e por isso devem ser maleáveis.

Sampaio (2004) reforça essa mesma linha de pensamento ao dizer

As aplicações Web possuem algumas características especiais que demandam

um tratamento adequado por parte de seus processos de desenvolvimento
como, por exemplo, tratamento de requisitos não funcionais (concorrência,
segurança, carga na rede), envolvimento de diversas tecnologias de
desenvolvimento, interface gráfica mais rica, e testes mais complexos.

Apesar desta complexidade maior, na maioria dos casos a abordagem adotada

para a construção de aplicações Web ainda é ad-hoc. Nestes casos, o sucesso
do projeto depende muito das habilidades e conhecimento da equipe de
desenvolvimento e acaba normalmente requerendo esforço adicional para
cumprir prazos e orçamentos.

Um dos principais fatores responsáveis por essa forma desordenada no

desenvolvimento Web é o tempo de entrega. Como as aplicações Web
geralmente representam oportunidades de negócio estratégicas para a
empresa, o tempo de desenvolvimento e entrega normalmente é curto devido
à concorrência existente no mercado.

2.2 Processos de desenvolvimento web

Além das ponderações apresentadas nas seções anteriores, para que um projeto
web entregue real valor ao cliente (seja ele interno ou cliente final), deve-se avaliar
características do processo de desenvolvimento. Sendo assim, o sistema web deve dar
suporte à (JACHYNTO, 2009):

 Autoria (ou engenharia) de conteúdo;

 Autoria (ou engenharia) de navegação sobre o conteúdo;

 Autoria (ou engenharia) de apresentação (interface);

 Ubiquidade;

 Definição de arquitetura multicamadas

 Escolha, adaptação e utilização de frameworks e componentes;

 Integração com sistemas legados;

  Distribuição das camadas entre servidores;

 Definição do que roda no navegador e do que roda no servidor;

 Ciclos de vida de desenvolvimento curtos;

 Equipes multidisciplinares;

 Desenvolvimento concorrente de pequenas equipes em tarefas

interdependentes;

 Pesquisa de mercado;

 Incerteza do cliente e volatilidade dos requisitos;

 Reengenharia de modelos de negócio a partir de modelos da aplicação;

 Análise de negócio e avaliação junto ao usuário final;

 Diferentes perfis de usuário (personalização);

 Requisitos explícitos (funcionais e não-funcionais);

 Testes rigorosos com relação aos requisitos;

 Teste de performance, escalabilidade e resiliência;

 Autoria (engenharia) de Segurança

 Autorização por papéis de usuário (user role);

 Definição de quais transações são críticas (precisam de criptografia) e

não-críticas;

 Manutenção e evolução em granularidade fina.

3. Metodologia ágil

Durante décadas as empresas basearam-se nos métodos tradicionais de

desenvolvimento de softwares, planejando com antecedência e rigidez todo o trabalho a
ser realizado ao longo dos projetos. Devido a esse extremo planejamento, que norteava
custos, prazos e demais itens necessários para a gestão, poucas ou quase nulas eram as
alterações realizadas no decorrer do projeto, pois cada item a ser alterado desencadeava
uma lista de tarefas a ser alterada e revista. Com o passar do tempo e os visíveis fracassos
dos projetos nas empresas, alguns lideres passaram a adotar práticas não convencionais na
gestão dos projetos a serem desenvolvidos. Aos poucos, percebeu-se que essas
metodologias estavam trazendo mais benefícios que as aplicadas até então, pois não
trabalhavam nos conceitos duros conhecidos, permitindo mais liberdade. Devido a isso, as
mesmas passaram a ser conhecidas por metodologias leves, uma vez que evitavam a
burocracia e registro que as tradicionais empunham (PRESSMAN, 2006).

Alguns anos se passaram, até que em 2001, 17 destes líderes2 de projetos que
trabalhavam com suas metodologias leves se uniram em um final de semana, em uma
estação de ski em Utah, com o intuito de formar uma nova metodologia, unificando suas
formas de trabalho que, embora despadronizadas seguiam o mesmo conceito e ideias.
Após dois dias de debates, o grupo acabou chegando ao consenso de que não havia
como formar uma nova metodologia e que as mesmas deviam adaptar-se a cada cenário,
contextualizada pelas variáveis de cada projeto.

Mesmo sem produzir uma nova metodologia, eles divulgaram o que foi chamado de
Manifesto Ágil: uma cartilha com 12 conceitos básicos a serem seguidos para o bom
andamento de projetos de metodologias leves (AGILE MANIFESTO). Conforme segue:

 Garantir a satisfação do cliente entregando rapidamente e continuamente

softwares funcionais;

 Softwares funcionais entregues frequentemente;

 Softwares funcionais são a principal medida de progresso do projeto;

 Mudança de escopo, mesmo que tardias, são bem-vindas.

 Interação, no intuito de cooperar, constante entre pessoas que entendem do

negócio e desenvolvedores;

 Indivíduos motivados e relação de confiança de confiança entre todos;

 Design do software preservando excelência técnica;

 Simplicidade;

2
Kent Beck, Mike Beedle, Arie van Bennekun, Alistair Cockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andew Hunt, Roland Jeffries, Jon Kern, Brian Marick, Robert Martin, Steve Mellor, Ken
Schwaber, Jeff Sutherland e Dave Thomas.
  Rápida adaptação às mudanças;

 Indivíduos e interações mais do que processos e ferramentas;

 Software funcional mais do que documentação extensa;

 Colaboração com clientes mais do que negociação de contratos;

 Responder a mudanças mais do que seguir um plano.

As metodologias ágeis não apresentam tanta diferença das tradicionais no que tange
o desenvolvimento em si, porém mudam o enfoque do trabalho a ser realizado, dando
prioridade aos indivíduos e interações ao longo do projeto (LEAL, 2012). Engana-se
quem pensa que essas metodologias desprezam ou anulam as documentações, processos e
planejamento, pois isto não ocorre, apenas modifica-se o pensamento. Nas metodologias
ágeis estes itens são utilizados com menos intensidade, pois cedem espaço aos debates,
participação do cliente e a entrega rápida com qualidade.

Uma grande característica das metodologias ágeis é a adaptabilidade, que ganha

espaço em cima da predição das metodologias tradicionais. Ao invés de se passar meses
planejando todos os aspectos e possíveis acontecimentos do projeto, opta-se por adaptar
o software a qualquer alteração necessária durante o projeto.

Segundo Bassi (2008), algumas características de trabalho estão presente

independente da metodologia ágil a ser utilizada. Abaixo estão listadas estas
características juntamente ao benefício trazido por ela aos projetos:

 Testes – podem não ocorrer em fases distintas, como acontecia nas

metodologias tracionais. O mesmo desenvolvedor cria o código e o testa.

Benefício: percebem-se gaps de trabalho já nas fases iniciais do projeto, além

de ser possível realizar testes constantemente e até mesmo automatizá-los.

 Desenvolvimento iterativo – desenvolvimento realizado em ciclo (iteração),

que pode durar de horas a semanas, dependendo do requisito. No fim de cada
ciclo o requisito pode ser apresentado ao cliente para avaliação.

Benefício: flexibilidade para mudanças. Feedback constante do cliente.

 Desenvolvimento incremental – pode ocorrer de duas formas:

 agregando funcionalidades à medida que o software é desenvolvido;

  evoluindo funcionalidades junto ao sistema.

Benefício: evolução e entrega constante ao cliente, agilidade buscando o lucro

antes mesmo do fim do projeto.

 Cooperação – desenvolvedores, lideres, clientes e usuários trocam constantes

informações durante todas as etapas.

Benefício: facilidade de comunicação e melhora na percepção e todos os

envolvidos no projeto, evitando surpresas ou desentendimentos futuros.
Aumenta a colaboração e motivação da equipe.

 Estimativa – realizada para o projeto baseada no custo de cada requisito

pedido. Admite-se que pode haver discrepância no que foi estimado e no que
foi realizado devido às incertezas.

Benefício: todos apresentam sua visão de custo para os itens, que passam a
agregar desenvolvimento, teste, avaliação, necessidade etc., também avalia
tamanho de requisito x tempo de entrega. Costuma diminuir os riscos do
projeto.

 Priorização/negociação – ao longo de todo o projeto os requisitos são

priorizados, estimados e negociados. As mudanças podem depender da saída
de algum item ou da “sobra” calculada para o projeto.

Benefício: mantem o projeto dentro do prazo e dos custos avaliados.

Exatamente por acarretar essa mudança na visão de trabalho, o uso das metodologias
ágeis tem tornado os mais conservadores resistentes à mudança de métodos. Esses criticam
a falta de documentação, a necessidade de equipes multidisciplinares ou seniores,
dificuldade de negociações contratuais, principalmente entre empresas e terceiros etc. Por
isso, faz-se extremamente necessário à participação e incentivo dos superiores das empresas
na implementação das metodologias ágeis. Não basta pedir que suas equipes utilizem-nas,
sem que a empresa e suas doutrinas sejam adaptadas às mesmas.

Ainda assim, já são algumas as metodologias criadas a partir do manifesto, sendo

as de maior utilização no mercado de trabalho: Scrum, Extreme Programming e Lean
Development. Há ainda metodologias com menos adeptos, mas baseadas na mesma
maneira gerenciamento, como Feature Driven Development, Adaptive Software
Development, Crystal, Pragmatic Programming, Test Driven Development e Dynamic
Systems Development Method.

3.1 Scrum

Essa metodologia ágil apareceu pela primeira vez por volta de 1993, quando foi
aplicada na Easel Corporation por Jeff Sutherland, John Scumniotales e Jeff McKenna.
Estes se basearam na aplicação de Takeuchi e Nonaka, que escreveram sobre
gerenciamento de projetos em equipes pequenas no artigo The New Product
Developmnet Game (Harvard Business Review, Janeiro-Fevereiro de 1986).

Segundo Takeuchi e Nonaka (1986), equipes menores e multifuncionais

produziam requisitos melhores e com alta produtividade e compararam esse
desempenho ao scrum do jogo do Rugby, jogada que reinicia o jogo conforme algumas
regras. Somente em 1995, Ken Schwaber formalizou a definição de scrum, que então
começou a ser difundido no mundo todo.

Para Bissi (2007):

A Metodologia SCRUM apenas estabelece conjuntos de regras e práticas de

gestão que devem ser adotadas para garantir o sucesso de um projeto.
Centrado no trabalho em equipe, melhora a comunicação e maximiza a
cooperação, permitindo que cada um faça o seu melhor e se sinta bem com o
que faz o que mais tarde se reflete num aumento de produtividade.
Englobando processos de engenharia, este método não requer nem fornece
qualquer técnica ou método específico para a fase de desenvolvimento de
software.

Ferreira, Costa e Nunes (2006) citam como principais características do scrum:

 é um processo ágil para gerenciar e controlar o desenvolvimento de projetos;

 é um wrapper para outras práticas de engenharia de software;

 é um processo que controla o caos resultante de necessidades e interesses

conflitantes;

 é uma forma de aumentar a comunicação e maximizar a cooperação;

 é uma forma de detectar e remover qualquer impedimento que atrapalhe o

desenvolvimento de um produto;

 é escalável desde projetos pequenos até grandes projetos em toda empresa.

4. Metodologia

O presente trabalho visa fazer uma revisão bibliográfica, unificando opiniões,

estudos e experiências sobre o uso de metodologias ágeis no desenvolvimento de
softwares, bem como sobre aplicações web e suas diferenças para softwares
convencionais. Além disso, apresenta uma breve visão dos conceitos, com seus pontos
fortes e fracos, juntamente com uma explicação sobre a metodologia scrum.

Após, um estudo de caso é compartilhado, onde a própria autora descreve sua

experiência com um projeto de desenvolvimento de aplicação web utilizando
metodologia ágil de gerenciamento e desenvolvimento. A proposta foi acompanhar um
projeto web com metodologia scrum, por mais de um ano, inserida na equipe do projeto
e participar de todos os passos do mesmo, que foi desenvolvido de agosto de 2012 a
dezembro de 2013.

Como objetivo, este estudo buscava avaliar o desempenho do projeto (bem como
de seus participantes) sob a ótica dos principais pontos de atenção no desenvolvimento
web, conforme apontado nas seções 2 e 2.1. Estes foram apontados como meta para a
avaliação e estão dispostos abaixo:

 Convivência das equipes multidisciplinares – que devem convergir para um

único objetivo no projeto e focar na entrega de qualidade para o cliente.

Problema: avaliar se a equipe se adaptava aos métodos de trabalho scrum e se

o mesmo atenderia essa necessidade de múltiplas funções no mesmo local de
trabalho.

 Prazo curto – que tende a ser uma constante nas entregas de projetos web
devido à dinâmica do mercado e as pressões constantes de inovação frente à
concorrência.

Problema: planejar e cumprir o prazo acordado para entrega dos requisitos e

para a entrega da aplicação web completa.

 Mudanças de escopo constantes – que podem ocorrer devido às incertezas do

cliente, pelas mudanças de negócio da empresa ou pela própria percepção do
usuário final.

Problema: a metodologia se adaptaria bem as mudanças necessárias e

requisitadas pelo sponsor e pelos clientes indiretos?
  Percepção/satisfação do cliente do projeto – que exige entregas rápidas e de
alta qualidade com intuito de atender a demanda externa por informações e
serviços.

Problema: avaliar a satisfação do cliente interno com prazos, valores e

entrega (faseada e final).

 Usabilidade e experiência do cliente – percepção do cliente final (usuário da

aplicação) sobre o requisito/site entregue e sua permanência no canal.

Problema: avaliar se o projeto trouxe retorno para a empresa e acarretou em

entrega de valor real.

5. Estudo de caso

Em meados de agosto de 2012, a área de Marketing Digital, juntamente com a

área de Canais Eletrônicos da empresa XYZ (aqui nomeada assim para fins de
confidencialidade), sinalizou ao corpo executivo da empresa a necessidade de
renovação do site da empresa devido à defasagem de vendas que o canal proporcionava,
bem como à defasagem de atendimento para aqueles usuários já clientes da empresa.
Além disso, outro grande problema do portal era a dificuldade de alterações dentro do
mesmo, que sempre dependiam da equipe de TI, mesmo para coisas simples como uma
troca de texto. O site ainda apresentava lacunas de layout, apresentação, conteúdo e
serviços se comparado aos sites da concorrência.

Sendo assim, em outubro do mesmo ano, liberou-se uma equipe dedicada de TI

para a construção de um novo site. As equipes de marketing digital e canais eletrônicos,
responsáveis, respectivamente, pelas áreas de apresentação e vendas e áreas de
atendimento do site, disponibilizaram, inicialmente, cada uma, um recurso para
acompanhamento do desenvolvimento.

Nesse período, a empresa, que há algum tempo vinha estudando a possibilidade

do uso de metodologia ágil, aproveitou o projeto que se iniciava para utilizar como
“cobaia” na implementação da metodologia Scrum. Como era um ciclo que se iniciava e
não havia internamente muitos recursos treinados na metodologia, nenhum recurso no
projeto Novo Portal (como foi chamado o projeto do novo site), a empresa
disponibilizou um fornecedor especializado em metodologia ágil para acompanhamento
de todo o projeto.

A primeira medida tomada pelo corpo de gestores da área de TI foi montar uma
equipe multidisciplinar alocada exclusivamente para o desenvolvimento do site. Sendo
assim, a equipe contava com líder de projeto, arquitetos de solução, desenvolvedores
internos, desenvolvedores de empresa contratada para integração de plataforma de
gestão de conteúdo de sites, testadores da própria GVT, funcionários externos de
empresa especializada em testes de softwares e afins e até mesmo o clientes interno e
sponsor (recurso da equipe de Canais Eletrônicos). A princípio, por falta de recurso para
demais atividades da empresa, a equipe de Marketing Digital não disponibilizou recurso
para a equipe, porém, no decorrer do projeto e com a contratação de recursos foram
disponibilizadas duas pessoas, um designer e especialista em usabilidade e um gerente
de pauta, responsável pelo gerenciamento da agenda dos demais funcionários da área.

O projeto foi previsto, inicialmente para acontecer em 12 meses. O custo do

projeto não foi liberado para ser apresentado neste trabalho. É de conhecimento, porém,
que devido à troca de gerente da área de TI o orçamento e prazo foram revistos.

O trabalho começou com o levantamento de todos os requisitos as is (em

português, “como está”) do portal, sendo que nesse período muitas páginas do site
foram cortadas pelos stakeholders como forma de modernização, o que acarretou em
uma lista as is menor do que o site existente. Após, foram levantados os itens to be (em
português, “como deve ser”), onde a atuação da área responsável por atendimento, por
ser o patrocinador do projeto, teve mais voz ativa e requisitou melhorias em serviços e
criação de novos serviços para o cliente. A seguir, deu-se o desenvolvimento dos itens.

É importante ressaltar que durante todas as atividades realizadas, a equipe do

projeto teve o acompanhamento do fornecedor especializado em metodologia ágil. Esse
mesmo fornecedor ajudou nas definições de entregas, estimativas de custo, modelos de
reuniões etc.

Nesse sentido, o próximo passo foi a reunião de estimativas de requisitos, onde o

método escolhido foi o Planning Poker. Uma forma de validar os requisitos por “notas”,
onde cada participante recebe cartas (no modelo de um jogo de poker) para avaliar o
requisito conforme sua visão. Cada requisito foi avaliado e teve seu custo definido.
Após, uma lista de custos foi disponibilizada para os stakeholders e sobre esta foram
definidas as prioridades de entregas.

A sprint, nome dado aos ciclos de entrega do método, foram definidas em um

período de 15 dias, ou seja, a cada 15 dias, os clientes internos teriam requisitos prontos
para avaliar. Como forma de organização para gestores e para maior visibilidade, o líder
do projeto definiu uma quantidade meta de requisitos a serem entregues por sprint.

Uma grande dificuldade do projeto foi transmitir o método de trabalho às demais

áreas da empresa envolvidas, pois neste período, somente a área de TI tinha
conhecimento do novo método e o mesmo não tinha sido difundido nem explicado para
o resto da empresa. Assim, na visão dos stakeholders (exceto os que compunham a
equipe multidisciplinar) as atividades deveriam acontecer numa sequência, como no
método Cascata. Entretanto, no decorrer do projeto foi possível perceber que cada área
tornou-se menos resistente ao método e passou a contribuir mais.

Diariamente eram realizadas reuniões no começo da manhã, conhecidas no scrum

como stand-up meeting, com o intuito de cada membro apresentar suas atividades do
dia anterior, suas atividades do dia corrente e, principalmente, as dificuldades
encontradas que poderiam parar o processo de desenvolvimento.

As negociações de mudanças e trocas de requisitos aconteciam normalmente e

com boa aceitação por todos os membros, exceto naquelas em que havia contrato com a
empresa desenvolvedora externa, onde era muito difícil casar as necessidades com o que
estava firmado em contrato. Nesses casos, as negociações eram realizadas pelos
próprios gestores com base em sua visão.

A criação de um novo site com o uso de metodologia ágil tornou o processo de

criação do mesmo em algo muito mais simples, flexível e usual, pois agregou as
necessidades de design, usabilidade e visão cliente das áreas de marketing, com a
valorização que uma metodologia ágil, onde o cliente e o retorno são enfoque principal.

A todo o momento eram excluídas e incluídas páginas e serviços no portal e suas

funcionalidades avaliadas diretamente pelos clientes, facilitando a correção de
usabilidade, integração de sistemas e adaptando os itens as necessidades da empresa.

O projeto foi finalizado com cerca de 75% dos requisitos iniciais entregues, boa
qualidade de entrega, com apenas 30 dias de atraso e com o custo previsto. O projeto foi
avaliado posteriormente por todos os envolvidos e teve nota T+ (nas escalas da
empresa, do menor para o maior: N, T, T+ e S), devido à falta de um requisito muito
importante para as áreas de negócio que acabou não sendo entregue. Contudo, dadas às
circunstâncias do projeto ele foi considerado um sucesso pela entrega, prazo, pelo uso
pioneiro na empresa de método ágil e por utilizar em um campo diferente: web.

5.1 Avaliação das metas

Uma vez que o caso foi apresentado, no relato da seção 5, faremos aqui um
avaliação do caso, com base nas metas estabelecidas para análise do projeto. Cada meta
é avaliada, conforme percepção da autora, indicando o quanto a metodologia contempla
as necessidades do desenvolvimento web, conforme: não (não contempla), parcial
(contempla parcialmente), total (contempla totalmente).

 Convivência das equipes multidisciplinares: total

A equipe conviveu durante todo o tempo de projeto, reunindo-se não somente

nos momentos preparados para reuniões (daily mettings etc.), mas também a
qualquer momento de dúvida, necessidade de acordo etc.

 Prazo curto: parcial

As entregas de sprint ocorreram com certo atraso, em partes porque a equipe

não estava habituada ao formato de condução do projeto, mas também devido
a pequenos erros de planejamento de tempo de desenvolvimento de serviços.
O prazo total do projeto foi mantido, com atraso não considerável.

 Mudanças de escopo constantes: total

Mudanças ocorreram em todo o decorrer do projeto e foram facilmente

negociáveis.

 Percepção/satisfação do cliente do projeto: parcial

O projeto, embora bem avaliado pelo sponsor e pelos clientes, não alcançou
nota maior devido a não entrega de um requisito de alto impacto/valor para o
sponsor.

 Usabilidade e experiência do cliente: não se aplica

Com os dados apresentados não foi possível avaliar o ganho geral do projeto.
6. Conclusão

As metodologias ágeis têm sido cada vez mais aceitas no mercado de

desenvolvimento de softwares. Há também relatos de adaptações das metodologias para
o desenvolvimento de produtos e possíveis gerenciamentos de criações no meio de
fornecimento de serviços de consumo.

A proposta de gerenciamento das metodologias leves fornece uma visão muito

mais dinâmica e adaptável para as atuais necessidades de desenvolvimento, pois são
constantes as mudanças sofridas pelos softwares durante todo o projeto de criação. Num
projeto de site web essas mudanças podem não ser tão constantes em questões de layout
e diagramação de paginas, mas muda constantemente em questão de entregáveis,
usabilidade, percepção de cliente etc., o que torna ainda mais necessário um sistema de
entrega maleável e de alta qualidade. O site é uma das caras das empresas e quando
fornece ainda opções de atendimentos ao cliente, cuja complexidade de integração com
os sistemas da empresa é extremamente alta, ele se transforma ainda num canal de
comunicação, procura e resolução de solicitações e problemas entre cliente-empresa.

De maneira geral, pode-se verificar com o exposto neste artigo que as

metodologias ágeis fornecem toda essa ideologia existente no desenvolvimento de sites
web, uma vez que ambos (metodologia e site) trabalham em prol do mesmo objetivo: o
cliente e sua satisfação.

Segundo William,

Scrum é um método de gerenciamento de projetos muito usado atualmente

pela TI de diversas empresas para o desenvolvimento de softwares, mas que
tem um recente crescimento em áreas como Web Design e Marketing Digital
(mídias sociais).

No caso de estudo apresentado, é perceptível que metodologia, design,

desenvolvimento, integração de sistemas, usabilidade etc. convivem bem quando há um
gerenciamento claro e produtivo no uso de uma metodologia ágil, mesmo trabalhando
em tantas frentes diferentes simultaneamente.

Infelizmente não temos ainda estudos claros que comprovem esse tipo de
utilização da metodologia, principalmente em comparação com as entregas e resultados
das metodologias pesadas. Mas, pode-se concluir pela presente observação realizada
nesse estudo de caso que o uso de metodologias ágeis trouxe mais benefícios do que o
contrario para a criação de página web.
Referências

AGILE MANIFESTO. Disponível em: <http://agilemanifesto.org/>. Acesso em: 11

jul. 2014.
ARAUJO, Allan R. S.; SILVA, Juliana M.; MITTELBACH, Artur F. Scrum: Novas
Regras do Jogo. Jynix Playware: Brasil.
BASSI, Dairton Luiz. Experiências com desenvolvimento ágil. USP: São Paulo, 2008.
BISSI, Wilson. Scrum – metodologia de desenvolvimento ágil. CESUMAR: Paraná,
2007.
BRAZAN, Marina. Uma nova metodologia: marketing ágil. Disponível em:
<http://www.mirago.com.br/uma-nova-metodologia-marketing-agil/>. Acesso em: 26
set. 2014.
CHARETTE, R. Fair Fight? Agile Versus Heavy Methodologies. Cutter Consortium
E-project Management Advisory Service, 2001.
FERREIRA, Décio; COSTA, Felipe; ALONSO, Filipe; ALVES, Pedro; NUNES,
Tiago. SCRUM - Um Modelo Ágil para Gestão de Projetos de Software. Disponível
em: <http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_19.pdf>. Acesso em:
16 jul. 2014.
FERREIRA, Jennifer; NOBEL, James; BIDDLE, Robert. Agile Development
Iterations and UI Design. IEEE Computer Society: Toronto, 2007.
FERRERA, Iris. Perdeu o foco do projeto? Metodologias ágeis nele! Disponível em:
<http://imasters.com.br/desenvolvimento/gerencia-de-projetos/perdeu-o-foco-projeto-
metodologias-ageis-nele/>. Acesso em: 26 set. 2014.
GUSMÃO, Gustavo. 10 coisas que todo desenvolvedor web deve saber. Disponível
em: <http://exame.abril.com.br/carreira/noticias/10-coisas-que-todo-desenvolvedor-
web-deve-saber>. Acesso em: 25 set. 2014.
JACYNTHO, Mark D. de A. Processos para desenvolvimento de aplicações web.
PUC: Rio de Janeiro, 2009.
JOHNSON, Jim. The Chaos Report. The Standish Group International, Inc. West
Yarmouth, 1995.
LEAL, Igor Gonçalves. Requisitos de Metodologias de Teste de Software para
processos ágeis. UFMG: Belo Horizonte, 2012.
MELLO, Isabella. Conceitos básicos de linguagem de programação para web.
Disponível em: <http://www.trabalhosfeitos.com/ensaios/Conceitos-B%C3%A1sicos-
De-Linguagem-De-Programa%C3%A7%C3%A3o/630131.html>. Acesso em: 26 set.
2014.
MESZAROS, Gerard; ASTON, Janice. Adding Usability to an Agile Project. IEEE
Computer Society: Minneapolis, 2006.
OLIVEIRA, Ebenezer Silva de. Uso de Metodologias Ágeis no Desenvolvimento de
Software. UFMG: Belo Horizonte, 2003.
OLIVEIRA, Rafael. Lógica de programação – Conceitos e primeiros passos.
Disponível em: <http://www.7desenvolvimento.com/logica-de-programacao-conceitos-
e-primeiros-passos/>. Aceso em: 26 set. 2014.
PRESSMAN, Roger. Engenharia de Software. Mc Graw-Hill: São Paulo, 2006.
Princípios para o desenvolvimento Web acessível. Disponível em:
<http://warau.nied.unicamp.br/warauv2/?q=node/98>. Acesso em: 25 set. 2014.
RIZZON, Peter. Gerenciamento de projetos em agências web baseado no PMI e
metodologias ágeis. Disponível em: <http://www.administradores.com.br/producao-
academica/gerenciamento-de-projetos-em-agencias-web-baseado-no-pmi-e-
metodologias-ageis/6215/>. Acesso em: 27 set. 2014.
ROQUE, Aline. O que você sabe sobre metodologias ágeis e o marketing?
Disponível em: <http://www.implantandomarketing.com/voce-metodologias-ageis-
marketing/>. Acesso em: 17 set. 2014.
SAMPAIO, Américo. XWebProcess: Um processo ágil para o desenvolvimento de
aplicações Web. Universidade Federal de Pernambuco: Pernambuco, 2004.
Scrum na gestão de projetos web: uma poderosa ferramenta para agilizar processos.
Disponível em: <http://www.internetinnovation.com.br/blog/ferramentas/scrum-na-
gestao-de-projetos-web-uma-poderosa-ferramenta-para-agilizar-processos/>. Acesso
em: 30 set. 2014.
SCRUM. Disponível em: <http://pt.wikipedia.org/wiki/Scrum>. Acesso em: 16 jul.
2014.
SOUZA, Thais. Lean UX: metodologia ágil para User Experience Design. Disponível
em: <http://www.uxdesign.blog.br/user-experience/lean-ux/>. Acesso em: 28 set. 2014.
TAVARES, Tatiana Aires; VEIGA, Elba Guimarães. Um Modelo de Processo para o
Desenvolvimento de Programas para TV Digital e Interativa baseado em
Metodologias Ágeis. NUPERC: Salvador, 2012.
VILLAS BOAS, Simone. Criação + Scrum: como encaixar UX nas metodologias
ágeis. Disponível em: <http://s1mone.net/blog/2012/11/criacao-scrum-como-encaixar-
ux-nas-metodologias-ageis/>. Acesso em: 30 set. 2014.
WILLIAM, Arthur. Scrum no desenvolvimento de sites e ações de Marketing
Digital. Disponível em: <http://arturoilha.com.br/scrum-no-desenvolvimento-de-
websites-e-acoes-multimidia/>. Acesso em: 25 set. 2014.