FACULDADE FORTIUM

LUCAS MENEZES

OS DESAFIOS NA ADOO DA ABORDAGEM GIL

PARA O DESENVOLVIMENTO DE PROJETOS
GOVERNAMENTAIS

BRASLIA-DF
2015

LUCAS MENEZES

Os Desafios na Adoo da Abordagem gil para o

Desenvolvimento de Projetos Governamentais

Trabalho de Concluso de Curso apresentado

ao curso de Ps-Graduao em Gesto de TI na
Administrao Pblica da Faculdade Fortium,
como requisito parcial para obteno do ttulo
de Especialista em Gesto de TI na
Administrao Pblica.
Orientador: MSc. Csar Augusto Borges de
Andrade.

BRASLIA-DF
2015

LUCAS MENEZES

Os Desafios na Adoo da Abordagem gil para o

Desenvolvimento de Projetos Governamentais

Trabalho de Concluso de Curso apresentado

ao curso de Ps-Graduao em Gesto de TI na
Administrao Pblica da Faculdade Fortium,
como requisito parcial para obteno do ttulo
de Especialista em Gesto de TI na
Administrao Pblica.
Aprovado em _____/_____/______.
Banca Examinadora
_______________________________________________________________
Presidente: Prof. MSc. Csar Augusto Borges de Andrade - Faculdade Fortium
(Orientador)
____________________________________________________________________
Membro Titular: Prof. Dr. Marcio de Carvalho Victorino - Universidade de Braslia
_______________________________________________________________
Membro Titular: Prof. MSc. Rmulo Ferreira dos Santos - Faculdade Fortium
_______________________________________________________________
Membro Suplente: Prof. MSc. Gleyson Azevedo da Silva - Faculdade Fortium

BRASLIA-DF
2015

Os Desafios na Adoo da Abordagem gil para o

Desenvolvimento de Projetos Governamentais
Lucas Menezes
Faculdade FORTIUM - Especializao em Gesto de TI na Administrao Pblica
SGAS, Quadra 616, Mdulo 114, Asa Sul - Braslia/DF - CEP 70.200-760.
lucasmenezes00@gmail.com

Abstract. This paper describes the challenges that can be found in the
adoption of agile approach to software development in government projects.
The work doesnt consider the agile utilization under hiring perspective, but
rather as internal development, with governmental infrastructure and own
team. It is performed a comparison between the practices and principles of
agile methods and previous methods and, from that, are described the
difficulties encountered in their implementation, based on the characteristics
of public administration.
Keywords: Agile; Government IT; Software Development.
Resumo. Este artigo descreve os desafios que podem ser encontrados na
adoo da abordagem gil para o desenvolvimento de software em projetos
do governo. O trabalho no leva em considerao a utilizao do gil sob a
perspectiva de contratao, mas, sim, como desenvolvimento interno, com
infraestrutura governamental e equipe prpria. realizada uma comparao
entre as prticas e princpios dos mtodos geis e dos mtodos precedentes e,
a partir disso, so descritas dificuldades encontradas em sua aplicao, com
base nas caractersticas da administrao pblica.
Palavras-chave: gil; TI do Governo; Desenvolvimento de Software.

1. Introduo
Com a evoluo das prticas da Engenharia de Software, as reas responsveis
pela tecnologia da informao em rgos pblicos tm se esforado para buscar a
melhor maneira de desenvolver e gerenciar seus produtos, sempre com a
responsabilidade de encontrar um bom equilbrio entre custo, prazo e qualidade final.
Os resultados obtidos em pesquisas recentes comprovam o bom desempenho dos
mtodos geis em relao a abordagens tradicionais de processos de software, conforme
visto no relatrio de The Standish Group (2011, p. 25). Isso explica o aumento na
adoo dessas prticas por empresas setor pblico e privado que trabalham com
desenvolvimento de software. No entanto, o setor pblico possui caractersticas
diferentes do setor privado e, para que as chances de sucesso sejam maiores, essas
caractersticas devem ser levadas em considerao na definio da forma de trabalho.

H duas maneiras de desenvolver software em organizaes pblicas:

desenvolvimento interno, com equipe e infraestrutura prpria, ou atravs da contratao
de empresas prestadoras de servios. Este trabalho analisa os mtodos geis como
escolha para desenvolvimento interno e no como forma de terceirizao de servios.
Sero descritas as caractersticas de abordagens tradicionais e abordagens geis, assim
como as diferenas entre o setor pblico e o setor privado e, com base nesses aspectos,
sero levantadas possveis dificuldades encontradas na adoo de mtodos geis para
desenvolvimento de projetos governamentais.
O trabalho est organizado da seguinte forma: aps a introduo, na seo 2, so
discutidos os conceitos relacionados a processos e metodologias de desenvolvimento de
software. Na seo 3, a definio de modelos tradicionais apresentada e, nas suas
subsees 3.1 e 3.2, essa definio exemplificada. Na seo 4, a definio para
mtodos geis apresentada, seguida de exemplos nas subsees 4.1 e 4.2. Na seo 5,
realizada uma comparao entre as caractersticas do setor pblico e do setor privado.
A seo 6 aborda os possveis desafios encontrados na adoo da abordagem gil em
projetos governamentais. Em seguida, a seo 7 descreve casos de sucesso em empresas
do setor pblico que passaram a adotar a abordagem gil. Para encerrar, a seo 8
apresenta a concluso do trabalho as consideraes finais.

2. Processo de Software
Um processo de desenvolvimento de software pode ser definido como um
agrupamento de atividades, aes e tarefas realizadas com o objetivo de obter um
produto de software. A finalidade entregar software com qualidade dentro de um prazo
e custo razoveis para satisfazer os seus usurios finais e patrocinadores, conforme visto
em Pressman (2011, p. 53-58).
Segundo Sommerville (2007, p. 42-43), processos de software so adaptveis e
permitem que sejam escolhidas as aes e tarefas apropriadas para o desenvolvimento.
No existe um processo ideal, os processos podem ser mais ou menos adequados,
dependendo do tipo de software que se pretende produzir.
Como exemplo de que a escolha do processo de software varia de um caso para
o outro est o desenvolvimento de um software para o controle de uma aeronave, em
que a necessidade de obter um controle rigoroso sobre os requisitos muito maior, pois
qualquer erro pode colocar muitas vidas em risco. Por outro lado, para o
desenvolvimento de um software para rea financeira, talvez seja melhor um processo
mais adaptvel e suscetvel a mudanas, j que os requisitos do mercado financeiro
tendem a mudar com mais frequncia.
Uma metodologia de processo estabelece a estrutura para um processo de
engenharia de software, atravs da identificao de atividades estruturais e de suporte,
que devem ser executadas para obteno do produto de software. A Figura 1 ilustra a
estrutura bsica de um processo de software.

Figura 1. Estrutura de um Processo de Software

Fonte: (PRESSMAN, 2011, p. 53).

3. Modelos Tradicionais
Antigamente, de acordo com Sommerville (2007, p. 42 - 44), havia um
entendimento de que a melhor maneira de obter software de qualidade era por meio de
um projeto detalhado, apoiado por ferramentas e controlado por um rigoroso processo
de desenvolvimento de software. Tal entendimento se deve ao fato de que boa parte dos
sistemas era classificada como crtica, com requisitos complexos, e desenvolvida por
grandes equipes. Essas equipes muitas vezes se encontravam separadas
geograficamente, o que fazia com que esse controle fosse realmente necessrio.
Neste trabalho, vamos utilizar o termo modelos tradicionais para nos referir a
modelos precedentes s metodologias geis, que enfatizam um planejamento inicial

detalhado ou que possibilitam, atravs de sua estrutura, um nvel de formalidade maior,

utilizando os artefatos disponveis para documentar o projeto.
Como exemplo de modelos tradicionais esto o Modelo Cascata, que prev um
planejamento inicial de todo trabalho a ser executado, e o RUP (Rational Unified
Process), que possui um grande nmero de artefatos que podem ser utilizados para
documentar os mais diversos aspectos encontrados no projeto.
3.1 Modelo Cascata
O modelo Cascata, tambm conhecido como modelo Clssico, foi o primeiro
modelo publicado e tem a finalidade de produzir software de maneira sistemtica. Esse
modelo descreve um conjunto de fases que devem ser executadas sequencialmente, de
tal modo que uma fase somente dever ser executada se a fase anterior tiver sido
totalmente finalizada, tal como explicado por Sommerville (2007, p. 44).
Trata-se de um modelo utilizado para projetos com escopo bem definido e cujos
requisitos no mudam, pois estes so especificados no comeo do projeto e servem
como base para todo o desenvolvimento. Caso ocorram mudanas aps o levantamento
de requisitos, um grande retrabalho ser gerado, j que etapas como planejamento,
modelagem e construo foram executadas em cima do requisito inicial e sua correo
implica em um grande esforo. Por causa desse esforo, o custo de mudanas no modelo
Cascata muito alto e essas devem ser evitadas.
Existem vrias verses do modelo Cascata, cada um com suas prprias fases. A
Figura 2 ilustra a verso de Pressman (2011, p. 60), cujas fases do modelo so:
Comunicao, Planejamento, Modelagem, Construo e Emprego.

Figura 2. Fases do Modelo Cascata

Fonte: (PRESSMAN, 2011, p. 60).

3.2 Rational Unified Process (RUP)

O Rational Unified Process definido como um framework de processos, pois
possui uma extensa e complexa estrutura de processos, atividades, papis e artefatos que
pode ser adaptada e ampliada para criar processos mais especficos de engenharia de
software. Tem como suas principais caractersticas: o desenvolvimento iterativo e

incremental, baseado em componentes e centrado na arquitetura; a utilizao de casos de

uso como guia de desenvolvimento e principal artefato de comunicao com o cliente; e
o planejamento baseado em riscos.
O RUP, como dito anteriormente, iterativo e incremental. Isso significa que
so definidos perodos de tempo, chamados de iterao, e, nesses perodos, so
entregues pequenos incrementos de software com base em um grupo de requisitos
selecionados para aquela iterao. Isso ocorre at que o projeto seja concludo.
Para facilitar o entendimento, Somerville (2007, p. 54-56) divide a estrutura do
RUP em trs perspectivas: a dinmica, que contm as fases do projeto; a esttica, que
contm as disciplinas que sero executadas em cada iterao; e a prtica, onde so
sugeridas boas prticas que devem ser adotadas durante o processo.
As fases do RUP tm objetivos diferentes e demonstram a nfase que dada ao
projeto em um determinado momento. As disciplinas contm um conjunto de atividades
que devem ser executadas para a criao de artefatos, tambm chamados de produtos de
trabalho. Uma iterao corresponde a uma passagem completa pelas disciplinas e uma
fase pode contemplar vrias iteraes. A Figura 3 ilustra bem os conceitos descritos
acima.

Figura 3. Viso geral do RUP

Fonte: (IBM CORPORATION, s.d.).

Apesar de ter uma estrutura complexa de processos, o RUP foi criado para que
seja adaptado de acordo com a necessidade da organizao. Essa caracterstica permite
que seja utilizado para projetos pequenos sem maiores problemas. O fato de ser

conhecido como um processo pesado se deve mais a m utilizao do que a sua

grande estrutura.
3.2.1 Fases
O RUP est dividido nas seguintes fases:

Iniciao (Concepo): A fase de iniciao deve avaliar a viabilidade do

projeto. Possui foco na delimitao do escopo do projeto e busca um
entendimento comum das partes interessadas sobre as necessidades que ele vir
atender.

Elaborao: Na fase de elaborao, o objetivo definir a arquitetura do sistema

e um plano de desenvolvimento para o software.

Construo: A fase de construo est relacionada implementao

propriamente dita, ou seja, tem mais nfase nas disciplinas de implementao e
teste.

Transio: a fase em que o sistema construdo implantado e entra em

funcionamento no ambiente real ficando disponvel para os interessados. Possui
foco nas atividades da disciplina de implantao.

3.2.2 Disciplinas
O RUP composto por nove disciplinas que so descritas abaixo:

Modelagem de Negcios: o objetivo desta disciplina modelar o negcio da

empresa, utilizando casos de uso de negcios.

Requisitos: so identificados os atores que interagem com o sistema e os casos

de uso so elaborados para modelar os requisitos do sistema.

Anlise e projeto: o objetivo da disciplina de anlise e projeto compreender o

problema e transformar os requisitos em um projeto executvel, com arquitetura
definida.

Implementao: a disciplina de implementao tem como objetivo a

codificao, testes de unidade e a integrao dos resultados produzidos ao
sistema executvel.

Teste: a disciplina de teste garante a qualidade do sistema atravs da execuo

de testes de sistema e testes de integrao.

Implantao: descreve atividades para garantir que o produto ser

disponibilizado aos usurios finais.

Gerenciamento de configurao e mudanas: gerencia os inmeros artefatos

criados evitando verses conflitantes entre as pessoas que trabalham no projeto.

Gerenciamento de projetos: concentra atividades que auxiliam

gerenciamento do projeto e melhora a liberao de software bem-sucedido.

Ambiente: concentra atividades relacionadas configurao do processo para a

execuo do projeto.

no

3.2.3 Boas prticas

Desenvolvimento iterativo: consiste em planejar o software em incrementos, de

modo que esses incrementos sejam realizados em perodos de tempo chamados
de iterao. Os requisitos escolhidos para a iterao devem ser priorizados pelo
cliente e levar em considerao as funcionalidades que so mais importantes.

Gerenciamento de requisitos: realizar o controle dos requisitos e manter o

acompanhamento de suas mudanas.

Arquitetura baseada em componentes: uma arquitetura baseada em

componentes reduz a necessidade de desenvolver partes novas de cdigo,
minimizando a quantidade de erros criados na codificao.

Verificao da qualidade do software: garantir que o software atenda os

padres de qualidade definidos anteriormente.

Controle de mudanas: gerenciar as mudanas do software.

4. Mtodos geis
A abordagem gil surgiu para resolver dificuldades encontradas quando
abordagens pesadas e baseadas em planejamento eram aplicadas a sistemas de pequenas
e mdias empresas. Essas abordagens tradicionais causavam um retrabalho muito
grande, pois muitas vezes o tempo gasto para determinar um plano de como o sistema
deveria ser desenvolvido acabava sendo maior do que o empregado para
desenvolvimento e testes.
O descontentamento com a alta porcentagem de fracasso dos projetos de
software, conforme visto no relatrio apresentado pelo The Standish Group (2001) e a
complexidade das abordagens de desenvolvimento encontradas na poca fizeram com
que, em fevereiro de 2001, um grupo de desenvolvedores se reunisse e criasse um
conjunto de princpios para melhorar a maneira de como desenvolver software de
qualidade. Esse conjunto de princpios foi batizado como Manifesto gil e serve como
embasamento para a maioria dos mtodos geis existentes. Segundo a Agile Alliance
(2001), os princpios que compem o Manifesto gil so:

Indivduos e interaes mais que processos e ferramentas.

Software em funcionamento mais que documentao abrangente.

Colaborao com o cliente mais que negociao de contratos.

Responder a mudanas mais que seguir um plano.

O Manifesto gil esclarece que por mais que nos princpios citados
anteriormente haja valor nos itens direita, os itens esquerda devem ser mais
valorizados, conforme definido pela Agile Alliance (2001). A maioria dos mtodos
geis possuem caractersticas em comum, como por exemplo, desenvolvimento iterativo
e incremental, envolvimento do cliente com a equipe de desenvolvimento, aceitao das
mudanas e foco na simplicidade.

O SCRUM e o XP (Extreme Programming) so duas das abordagens geis mais

utilizadas e sero descritas para enfatizar as diferenas em relao s abordagens
tradicionais.
4.1 SCRUM
Segundo Schwaber (2009), O SCRUM um framework cuja finalidade
orientar as atividades de trabalhos complexos. definido como framework, pois
disponibiliza vrios processos e tcnicas que podem ser empregados durante o projeto.
O SCRUM reconhece que a eficcia das prticas de gerenciamento e desenvolvimento
relativa, e pode ser melhorada. Dessa forma, encoraja o emprego desses processos ou
tcnicas de forma personalizada, permitindo que cada organizao selecione aquilo que
se aplica a sua necessidade.
O SCRUM um mtodo iterativo e incremental que se apoia em trs pilares:
transparncia, inspeo e adaptao. baseado em teorias empricas, ou seja, seu
conhecimento vem de experincias prticas anteriores, conforme explicado por
Schwaber (2009).
No SCRUM, as iteraes so chamadas de Sprints e devem ter entre 2 a 4
semanas de durao. O trmino da Sprint marcado pela entrega de um pedao
funcional de software. Esse pedao de software construdo com base em requisitos
priorizados anteriormente pelo cliente e selecionados para essa Sprint.
As responsabilidades pelas tarefas que devero ser executadas correspondem aos
papis e estes devem ser atribudos aos participantes do projeto. Alm dos papis,
existem eventos programados que orientam a execuo do trabalho e auxiliam na
criao e gerenciamento de artefatos. A Figura 4 ilustra resumidamente as etapas do
processo.

Figura 4. Viso Geral do SCRUM

Fonte: (BRQ, s.d.)

4.1.1 Papis

Product Owner: o responsvel por priorizar quais requisitos devero ser

implementados, de acordo com o risco e o valor que ser agregado ao negcio.
Deve ser uma nica pessoa, cujo time de desenvolvimento considera o dono do
produto. para o Product Owner que as entregas so feitas e pertence a ele a
responsabilidade de garantir o entendimento dos requisitos pelo time de
desenvolvimento.

Time de Desenvolvimento: o conjunto de profissionais responsveis por

realizar o trabalho definido em cada Sprint, gerando incrementos de software
utilizveis ao trmino dela. O tamanho do time de desenvolvimento deve ser de
5 a 9 pessoas.

Scrum Master: o responsvel escolhido para fazer com que os princpios do

SCRUM sejam seguidos. Ele deve garantir que os participantes do projeto
tenham pleno entendimento e sigam as prticas e regras do processo.
A Figura 5 ilustra os papis descritos acima.

Figura 5. Principais papis do SCRUM

Fonte: (RUBIN, 2012)

4.1.2 Eventos

Sprint: O SCRUM prega que o trabalho deve ser dividido iteraes e que cada
iterao deve entregar incrementos de software utilizveis. Essas iteraes so
chamadas de Sprint e definem um perodo de tempo entre uma entrega e outra.
Para cada Sprint so definidos um conjunto de requisitos que devem ser
implementados e ao trmino da Sprint realizada a entrega de um incremento de
software. Com base na entrega, o time de desenvolvimento recebe o feedback do
Product Owner e planeja a prxima Sprint. As Sprints devem ser definidas com
um ms ou menos.

Reunio de Planejamento da Sprint: uma reunio realizada com todos os

envolvidos para que sejam definidos os objetivos da Sprint, o que deve ser
entregue como incremento ao seu trmino e como o trabalho ser realizado. O
Backlog da Sprint gerado na Reunio de Planejamento da Sprint.

Reunio Diria: um evento dirio que tem durao mxima de 15 minutos e

serve para que os membros da equipe possam sincronizar o andamento das suas
atividades. Os desenvolvedores respondem a trs perguntas:
1)

O que fez ontem desde o trmino da ltima reunio diria?

2)

O que far hoje?

3)

H algum obstculo que te impea de realizar o trabalho planejado?

Reviso da Sprint: a reunio de final de Sprint em que ao time de

desenvolvimento apresenta o incremento de software ao Product Owner e s
demais partes interessadas e recebe o feedback.

Retrospectiva da Sprint: A retrospectiva da Sprint o momento em que a

equipe debate os erros e acertos e traa um plano de melhoria para a continuao
do projeto.

4.1.3 Artefatos

Backlog do Produto: O Backlog do Produto a lista de tudo que dever ser

construdo no projeto, todos os requisitos e necessidades. O Backlog deve ser
mantido pelo Product Owner que define quando um item foi entregue e a sua
prioridade.

Backlog da Sprint: O Backlog da Sprint o artefato que contm os itens do

Backlog do Produto selecionados para serem desenvolvidos durante a Sprint
corrente.

4.2 Extreme Programming (XP)

Idealizada por Kent Beck, a Extreme Programming (XP) um mtodo gil que
descreve que as boas prticas de desenvolvimento devem ser realizados em nveis
extremos para se obter um produto de qualidade. Foi concebida para contemplar s
necessidades do desenvolvimento de software com equipes pequenas, em ambientes
com requisitos vagos e suscetveis a mudanas, conforme explicado por Beck (2004).
A XP possui um conjunto de valores que utiliza para guiar o desenvolvimento.
So os seguintes:

Comunicao: para que o desenvolvimento corra de maneira satisfatria

preciso ter comunicao entre as partes envolvidas no projeto. O cliente, que
possui o conhecimento do negcio, e a equipe de desenvolvimento, que possui o
conhecimento tcnico, precisam interagir para melhorar o entendimento a
respeito dos objetivos e das dificuldades tcnicas existentes.

Coragem: em projetos de software ocorrem alteraes a todo instante. Os

requisitos podem mudar e a XP acredita que isso no deve ser uma preocupao,
pois um risco comum em todos os projetos. Por isso, necessrio ter coragem
para enfrentar esse risco e aplicar as prticas recomendadas para se adaptar s
mudanas.

Feedback: o feedback considerado um dos valores mais importantes da XP,

pois uma das formas utilizadas para minimizar o risco de o produto entregue
no ser o desejado pelo cliente. As entregas em curtos perodos possibilitam
descobrir os erros mais rapidamente, permitindo a correo do curso do projeto.

Respeito: o respeito a base para uma boa comunicao. Os membros da equipe

precisam se importar uns com os outros e ter conhecimento de que o ponto de
vista de todos importante para que o projeto seja bem sucedido.

Simplicidade: o conceito de simplicidade da XP determina que a equipe faa

somente aquilo que essencial e, dessa forma, concentre o esforo naquilo que
agrega valor para o cliente, evitando perdas de tempo.

A XP tambm possui um conjunto de prticas que se enquadram nos princpios

geis e podem ser utilizadas em conjunto com o SCRUM. As prticas devem ser
utilizadas somente se houver um propsito, de acordo com a necessidade de cada
projeto. A XP incentiva as seguintes prticas:

Planejamento incremental: os requisitos do projeto so divididos em artefatos

chamados cartes de histrias do usurio. Essas histrias tem uma prioridade,
definida pelo cliente, e um esforo necessrio para sua implementao, definido
pelo time de desenvolvimento. Com base nesses aspectos, so selecionadas para
serem entregues em uma determinada iterao e iro compor um incremento de
software.

Pequenas releases: so as pequenas entregas realizadas. Incluem um mnimo

til de funcionalidades que agregam valor ao negcio e so incrementadas s
releases anteriores.

Metforas: so tcnicas utilizadas para facilitar a comunicao e melhorar o

entendimento a respeito das histrias que devero ser implementadas.

Projeto simples: realizado simplesmente o trabalho necessrio para atender os

requisitos selecionados para aquela release.

Desenvolvimento orientado a testes: os testes so escritos primeiro que a

funcionalidades. Assim, a funcionalidade construda de modo que passe nos
testes definidos.

Refatorao: o cdigo deve ser melhorado imediatamente, assim que a

possibilidade de melhoria for identificada.

Programao em pares: uma prtica em que dois desenvolvedores trabalham

juntos em um nico computador. Enquanto um programa, o outro faz a
verificao do cdigo e fornece apoio.

Propriedade coletiva: os desenvolvedores trabalham em todas as partes do

cdigo para que o conhecimento sobre uma determinada parte no fique
concentrado em apenas alguns membros da equipe. Todos tm permisso para
mudar qualquer parte do cdigo.

Integrao contnua: quando uma release for completada, deve ser integrada
imediatamente para evitar problemas com integrao no final do projeto. A ideia
provocar o erro o quanto antes, a fim de poder corrigi-lo o mais rpido
possvel.

40 horas semanais: recomendado que os membros da equipe trabalhem

somente 40 horas semanais, uma vez que a XP argumenta que a sobrecarga de
trabalho tende a diminuir a produtividade e a qualidade do servio produzido.

Cliente presente: necessrio que um responsvel pela rea do negcio do

sistema a ser desenvolvido esteja sempre presente junto equipe de

desenvolvimento. Assim, as dvidas referentes aos requisitos podem ser

removidas imediatamente.

Padres de codificao: so padres de cdigos definidos para que a equipe

trabalhe de maneira uniforme, facilitando a compreenso do cdigo nas
mudanas ou manutenes e at as verificaes realizadas na programao em
pares.

5. Diferenas entre o setor pblico e o setor privado

Existem diferenas fundamentais entre o setor pblico e o setor privado. Essas
diferenas precisam ser compreendidas a fim de identificar as dificuldades que podem
ser encontradas na utilizao de mtodos geis para desenvolvimento de software em
projetos governamentais, j que podem influenciar diretamente na maneira que a equipe
de desenvolvimento se comporta.
Segundo Sethibe, Campbell e McDonald (2007, p. 836-838), os entes da
administrao pblica tm foco em verificaes, contabilidade e sistemas de valores que
enfatizam questes ticas e cdigos de conduta, j que so prestadores de servios e
responsveis pelo zelo dos bens pblicos. No setor privado, o ambiente encontrado um
pouco diferente, uma vez que orientado a negcios e movido pelo lucro e
competitividade e, por isso, est sujeito s mudanas do mercado financeiro.
O setor pblico tem como caractersticas a transparncia nas informaes e a
prestao de contas ao pblico em geral, como cidados, governo, Ministros, entre
outros, cada um com seu legtimo interesse, mas no necessariamente com direito a
propriedade. J no setor privado, a prestao de contas se restringe aos scios e clientes
que tem participao na administrao. De acordo com Sethibe, Campbell e McDonald
(2007, p. 836-838), a principal diferena conceitual entre eles que o setor privado tem
foco no resultado, na competitividade, enquanto que no setor pblico h a busca pela
conformidade,.
A forte concorrncia existente no setor privado justifica o alto investimento em
tecnologias de ponta, j que isso pode proporcionar uma vantagem competitiva e at
retorno financeiro. No setor pblico, a contratao de pessoas e a obteno de recursos
esto sujeitas a regulamentaes especficas como processos seletivos e licitaes. Essa
caracterstica faz com que o governo apresente atraso nas reas de desenvolvimento e
que os recursos disponveis sejam mais escassos.
Outra diferena que existe relacionada s presses institucionais internas e
externas cujo esto submetidos os setores pblico e privado. No setor privado, os
objetivos que devem ser alcanados so mais claros e sofrem influncia de um nmero
menor de pessoas, normalmente das pessoas relacionadas direo da empresa, pois a
inteno buscar ter competitividade no mercado e retorno financeiro. J no setor
pblico, existem as necessidades dos cidados que precisam ser observadas, bem como
a responsabilidade de lidar com o dinheiro pblico, obtido atravs da arrecadao de
impostos. Por isso, os interessados so muitos, o que pode dificultar a priorizao de
objetivos. A complexidade na tentativa de gerenciar as mltiplas partes interessadas
muito grande, porque todos desejam ter os seus desejos atendidos pelo governo.

Devido a questes burocrticas e restries legais so encontradas dificuldades

na concesso de incentivos significativos para o desempenho individual. Conforme visto
em Caudle, Gorr e Newcomer (1991), existem estudos que comprovam que funcionrios
do setor pblico tm menos satisfao no trabalho, o que pode contribuir para alta
rotatividade em relao ao setor privado. A Tabela 1 ilustra a diferenas entre as
caractersticas do setor pblico e do setor privado.
Tabela 1: Diferenas entre o setor pblico e privado
Fator

Setor Pblico

Setor Privado

Objetivos

Mltiplos e intangveis

Especficos e tangveis

Produto

Prestao de servios e bens

pblicos

Lucro

Sucesso
medido por

Eficincia poltica e sucesso nas

metas polticas

Rentabiliidade financeira e
eficincia

Menos incentivos para

produtividade

Mais incentivos

Mais restries formais e legais

burocracia

Sem burocracia

Influncias polticas

Influncias do mercado

Ambiente

Fonte: (SETHIBE, CAMPBELL, MCDONALD, 2007, adaptada).

6. Os Desafios na adoo de Metodologias geis na Administrao Pblica

6.1 Mudana cultural
Como vimos anteriormente, a abordagem tradicional d uma nfase maior a um
planejamento inicial e documentaes mais elaboradas. Em contrapartida, os mtodos
geis incentivam uma maior colaborao entre os indivduos e a resposta rpida a
mudanas mais do que seguir um plano. Nesse novo cenrio proposto pela abordagem
gil, a mudana cultural pode ser considerada o maior desafio encontrado pelas
organizaes.
Na maioria dos casos, as empresas do governo tm como caracterstica uma
estrutura organizacional rgida, com um processo de deciso centralizado e mais lento,
que pode envolver diversos nveis hierrquicos. Considerando o fato de que as
metodologias geis idealizam iteraes curtas, permitindo realizar entregas frequentes, a
necessidade de aguardar decises da alta gesto pode significar atrasos e o fracasso do
projeto.
H de se considerar que talvez o setor pblico ainda no possua a maturidade
para dar as repostas rpidas que o gil necessita para funcionar, pois, alm de possuir as
mesmas caractersticas de outros tipos de organizao, tambm possui especificidades
como: apego s regras e rotinas, supervalorizao da hierarquia, paternalismo nas
relaes, apego ao poder.
A dificuldade em conceber incentivos individuais tambm um problema na
aplicao dos mtodos geis, uma vez que os membros da organizao pblica
apresentam um alto ndice de descontentamento e isso pode prejudicar a produtividade
da equipe. Os mtodos geis dependem do empenho e colaborao de todos os
envolvidos para conseguir alcanar os objetivos planejados, mas para isso ocorra,
preciso que os participantes estejam devidamente motivados.
Para neutralizar esses empecilhos, essencial conseguir o apoio e a compreenso
dos profissionais da alta administrao, para que as decises sejam tomadas de forma
mais rpida e para que os envolvidos no projeto tenham mais autonomia para tomar
decises. Alm disso, tambm importante que os envolvidos com a metodologia sejam
treinados para que possam compreender a nova forma de trabalho e contribuir de
maneira mais efetiva.
6.2 Dificuldades no planejamento
Como vimos anteriormente, devido a sua facilidade de se adaptar s mudanas,
as metodologias geis so ideais para projetos cujos requisitos sejam instveis. Essa
caracterstica de adaptao minimiza os riscos, pois utiliza o feedback do cliente para
construir um produto ajustado s necessidades da empresa, permitindo que erros sejam
corrigidos mais rapidamente e evitando que seja construdo algo que no satisfaz as
necessidades do negcio.
Por outro lado, as vrias alteraes permitidas pelas metodologias geis podem
impossibilitar a organizao de determinar a viabilidade do projeto, j que existe a
dificuldade de descobrir o custo e o tempo que o projeto levar para ser executado. Isso

ocorre, pois as estimativas so baseadas no esforo necessrio para implementar os

requisitos levantados, requisitos esses que podem aumentar ou diminuir de tamanho, de
acordo com as mudanas que vierem a surgir.
A imprevisibilidade aumenta o risco dos recursos necessrios no estarem
disponveis para a utilizao durante toda a execuo do projeto. Apesar de no ser um
risco exclusivamente da abordagem gil, a caracterstica de utilizar equipes pequenas e
trabalhar com iteraes sofre impacto direto da falta de recursos, prejudicando o
andamento do projeto.
No setor privado, a obteno de novos recursos geralmente mais fcil, pois no
submetida aos mesmos mecanismos que nas empresas pblicas. No setor pblico, a
contratao de um funcionrio, ferramenta ou consultoria est normalmente sujeita a
realizao de certames pblicos e regulamentaes mais rgidas.
A imprevisibilidade no que diz respeito ao custo do projeto tambm pode ser um
empecilho, j que os rgos do governo possuem oramento direcionado e condicionado
capacidade prpria de arrecadao tributria, conforme a Lei de Responsabilidade
Fiscal. No saber o quanto um projeto de desenvolvimento de software custar pode ser
um motivo para indeferir sua viabilidade.
6.2 Influncias ambientais
Uma das principais diferenas encontradas entre o setor pblico e o setor privado
so os fatores ambientas as quais so submetidas. As empresas privadas esto
diretamente relacionadas a aspectos financeiros e sua sobrevivncia est na busca pelo
retorno do capital investido. J as empresas pblicas tm como objetivo o fornecimento
de servios pblicos e sofrem influncia do ambiente poltico a qual esto inseridas.
Devido a esse ambiente poltico, as empresas pblicas esto sujeitas a
interferncias externas e internas. Essas interferncias podem ser vistas como um
dificultador no s na adoo de mtodos geis, mas no desenvolvimento de software
como um todo, pois as prioridades podem mudar a qualquer momento, colocando em
risco as chances de sucesso em alcanar os objetivos propostos inicialmente.
Os mtodos geis sustentam que a equipe de desenvolvimento deve ser blindada
quanto a interferncias, pois isso pode prejudicar a capacidade da equipe de realizar os
objetivos definidos para aquela iterao. O problema que nem sempre possvel
fornecer tal proteo devido ao ambiente poltico existente no setor pblico. Trocas de
favores realizadas por gestores em busca de influncia acabam refletindo no sucesso do
desenvolvimento, uma vez que profissionais so alocados em projetos de menos
importncia apenas para satisfazer o interesse de pessoas.

7. Casos de sucesso da abordagem gil no governo

Apesar das dificuldades que podem ser encontradas no setor pblico, j existem
diversos casos de sucesso na utilizao de mtodos geis para desenvolvimento de
projetos governamentais. Um deles foi a escolha da abordagem para um projeto da
Secretaria de Gesto Pblica do governo do estado de So Paulo. O projeto envolvia a
reestruturao do Departamento de Percias Mdicas do Estado e teve a avaliao
classificada como positiva, pois a abordagem atende a expectativas de melhor ajuste de

esforos s condies reais que se apresentaram para a realizao do projeto (DIAS,

2014).
O SERPRO (2014) Servio de Processamento de Dados Federal tambm
teve experincias bem sucedidas com a utilizao do mtodo gil para desenvolvimento
do Novo Siafi (Sistema Integrado de Administrao Financeira) e do Sigepe (Sistema de
Gesto de Pessoas do Governo Federal) e recentemente divulgou que pretende adotar os
mtodos geis para todas as reas da empresa.
Outras instituies como Secretaria do Tesouro Nacional (STN), Instituto
Nacional de Estudos e Pesquisas (INEP), Tribunal Superior do Trabalho (TST), Instituto
do Patrimnio Histrico Artstico e Nacional (IPHAN) e o Banco Central do Brasil
(BACEN) utilizam ou j utilizaram mtodos geis, seja como abordagem para
desenvolvimento interno ou para contrao de prestao de servios. Dentre elas,
podemos destacar o IPHAN (2014), que desenvolveu sua prpria metodologia para
acompanhar o servio das contratadas, chama-se MIDAS (Metodologia IPHAN de
gesto de demandas de desenvolvimento gil de softwares).
Alm das instituies brasileiras, rgos fiscalizadores dos governos dos Estados
Unidos e Reino Unido desenvolveram relatrios e diretrizes para utilizao da
abordagem gil para departamentos governamentais, conforme pode ser visto em Hastie
(2013). O relatrio americano estabelece dez prticas e princpios para uma aplicao
eficiente de mtodos geis de desenvolvimento de software a projetos de tecnologia da
Informao (GOVERNMENT ACCOUNTABILITY OFFICE OF UNITED STATES,
2012, p. 9 15). Conforme abaixo:

Comear com diretrizes geis e uma estratgia de adoo de gil;

Reforar a adoo dos conceitos geis utilizando termos do Agile,
tais como histrias do usurio; alm de fornecer exemplos geis, por
exemplo, demonstrar como escrever essas histrias;
Melhorar continuamente a adoo do Agile tanto no nvel de projetos
quanto no nvel organizacional;
Buscar identificar e resolver impedimentos em nvel organizacional e
de projetos;
Obter frequentemente feedback dos clientes e partes interessadas;
Empoderar equipes e encorajar a formao de equipes pequenas e
interdisciplinares;
Incluir requisitos relacionados segurana e ao monitoramento do
progresso na fila de trabalho no concludo (o backlog);
Conquistar confiana por meio da demonstrao de valor ao final de
cada iterao;
Monitorar o progresso utilizando ferramentas e mtricas, diariamente
e de forma visual.

O relatrio britnico, por sua vez, elencou quatro princpios que foram definidos
por entrevistados como fatores de sucesso para a abordagem gil (NATIONAL AUDIT
OFFICE OF UNITED KINGDOM, 2012, p. 9-10):

A governana deve espelhar a filosofia dos mtodos geis - executar

uma tarefa apenas se agregar valor ao negcio, sem introduzir
atrasos;

Equipes geis devem decidir a respeito de metas empricas de

desempenho e acompanhamento a serem utilizadas;
A gerncia snior, assessores externos, usurios e a equipe de TI
devem atuar em parceria para garantir a qualidade do projeto; essa
abordagem colaborativa uma mudana essencial na forma de
pensar e agir;
A avaliao externa e as revises das entregas geis devem focar nos
comportamentos das equipes, no apenas em processos e
documentao.

Com base nas experincias descritas acima, h motivos para acreditar que a
abordagem gil pode ser utilizada para projetos de desenvolvimento de software do
governo. Os casos de sucesso em instituies de grande expresso no cenrio nacional e
internacional reforam a tendncia na utilizao das prticas geis.

8. Concluso
Conforme dito anteriormente, existem vrios modos de desenvolver software,
cada um com suas mais variadas caractersticas. No existe um modelo ideal, que
sempre garanta o sucesso do desenvolvimento. preciso avaliar as caractersticas da
organizao, bem como as do modelo que se pretende utilizar e, a partir dessa anlise,
decidir qual abordagem seguir de acordo com o cenrio encontrado.
Os modelos de processo de desenvolvimento de software possuem focos
diferentes, pois tm sido criados para resolver problemas especficos. Existem modelos
elaborados para tentar sistematizar o desenvolvimento de software, como o caso do
modelo Cascata, outros para disponibilizar uma estrutura de processos formal que
suporte todas as etapas do desenvolvimento, como o caso do RUP, e h tambm os
modelos flexveis a mudanas, conhecidos como mtodos geis.
As caractersticas comumente encontradas no setor pblico tambm devem ser
analisadas. O setor pblico se diferencia do setor privado por ter uma preocupao
maior com transparncia, com responsabilidade fiscal e cdigos de conduta. Busca a
prestao de servios de qualidade, sempre em conformidade com a regulamentao
vigente e est sujeito a influncias de um ambiente poltico que muda constantemente.
Os mtodos geis possuem algumas prticas que podem dificultar a sua
utilizao em projetos governamentais devido s caractersticas do setor pblico citadas
acima. No entanto, essa abordagem no deve ser descartada porque cada organizao
possui uma maior ou menor acentuao em determinadas caractersticas, apesar de todas
possurem caractersticas em comum.
Por outro lado, os mtodos tradicionais tambm possuem suas fragilidades e
seus pontos fortes e no possvel afirmar que sua utilizao seria mais adequada que a
dos mtodos geis sem antes fazer um estudo de onde seriam aplicados. Assim como
existem caractersticas que dificultam a adoo de mtodos geis, tambm podem existir
caractersticas que prejudicam a adoo dos mtodos tradicionais.
Conclui-se que, apesar das dificuldades que podem ser encontradas, todos os
modelos devem ser considerados. As caractersticas encontradas no setor pblico nem
sempre sero impeditivas para a abordagem gil. Cabe aos responsveis realizar a

anlise adequada para compreender o cenrio e escolher o mtodo que melhor satisfaa
suas necessidades.

Referncias
BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: Embrace
Change. 2 Edio. Addison-Weasley, 26 de Novembro de 2004
BRQ.
Metodologias
geis
SCRUM.
Disponvel
<http://www.brq.com/metodologias-ageis>. Acesso em: 15 dez. 2014.

em:

CAUDLE, Sharon L.; GORR, Wilpen L.; NEWCOMER, Kathryn E. Key information
systems management issues for the public sector. MIS Quarterly, junho 1991
DIAS, Isabel de Meiroz. Projetos geis no setor pblico, 28 de Mar. 2012. Disponvel
em:
<http://igovsp.net/sp/projetos-ageis-no-setor-publico>. Acesso em: 15 dez. 2014.
GOVERNMENT ACCOUNTABILITY OFFICE OF UNITED STATES. Software
Development: Effective Practices and Federal Challenges in Applying Agile
Methods, Jul. 2012. Disponvel em:
<http://www.gao.gov/assets/600/593091.pdf>. Acesso em: 15 dez. 2014.
HASTIE, Shane. Governo dos EUA e Reino Unido adotam prticas geis como
soluo
mais
eficaz,
07
de
Jan.
2013.
Disponvel
em:
<http://www.infoq.com/br/news/2013/01/agile-governo-eua-reinounido>.
Acesso
em: 15 dez. 2014.
IBM
CORPORATION.
Rational
Unified
Process.
Disponvel
em:
<http://www.wthreex.com/rup/v711_sp_ptbr/index.htm>. Acesso em: 15 dez. 2014.
IPHAN. Metodologia IPHAN de Gesto de Demandas de Desenvolvimento gil de
Softwares. Disponvel em: <http://www.iphan.gov.br/cgti/midas/MIDAS.pdf>.
Acesso em: 15 dez. 2014.
NATIONAL AUDIT OFFICE OF UNITED KINGDOM. Governance for Agile
delivery, Jul. 2012. Disponvel em:
<http://www.nao.org.uk/wp-content/uploads/2012/07/governance_agile_delivery.pdf>.
Acesso em: 15 dez. 2014.
PRESSMAN, Roger S. Engenharia de Software: Uma Abordagem Profissional. 7
Edio. Porto Alegre: AMGH Editora Ltda, 2011.
RUBIN, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile
Process. 1 Edio. Addison-Weasley, 05 de Agosto de 2012
SCHWABER, Ken. Guia do SCRUM, Mai. 2009. Disponvel em:
<http://www.trainning.com.br/download/GUIA_DO_SCRUM.pdf>. Acesso em: 15 dez.
2014.
SERPRO. Serpro decide adotar mtodo gil, 16 de Jun. 2014. Disponvel em:

<https://www.serpro.gov.br/noticias/serpro-decide-adotar-metodo-agil>. Acesso em: 15

dez. 2014.
SETHIBE, Tsholofelo; CAMPBELL, John; MCDONALD, Craig. IT Governance in
Public and Private Sector Organisations: Examining the Differences and
Defining Future Research Directions. In: 18 AUSTRALASIAN CONFERENCE
ON INFORMATION SYSTEMS, 2007, Toowoomba.
SOMMERVILLE, Ian. Engenharia de Software. 8 Edio. So Paulo: Pearson
Addison-Wesley, 2007.
THE AGILE ALLIANCE. Manifesto para Desenvolvimento gil de Software, Fev.
2001. Disponvel em:
<http://www.agilemanifesto.org/iso/ptbr/>. Acesso em 15 dez. 2014.
THE STANDISH GROUP. CHAOS Manifesto 2011: The Laws of CHAOS and the
CHAOS
100
Best
PM
Practices,
2011.
Disponvel
em:
<http://www.versionone.com/assets/img/files/ChaosManifest_2011.pdf>. Acesso em:
15 dez. 2014.
THE STANDISH GROUP. Extreme CHAOS, 2001. Disponvel em:
<https://courses.cs.ut.ee/MTAT.03.243/2014_spring/uploads/Main/standish.pdf>.
Acesso em: 15 dez. 2014.