Acordao Legado 116247

TRIBUNAL DE CONTAS DA UNIO TC 010.
663/2013-4
GRUPO I CLASSE V PLENRIO
TC 010.663/2013-4
Natureza: Levantamento de Auditoria
Interessado: Tribuna de Contas da !ni"o
!nidades: Tribuna #u$erior do Traba%o &T#T'( )an*o Centra do
)rasi &)a*en'( Instituto do +atrim,nio -ist.ri*o e Art/sti*o
Na*iona &I$%an'( Instituto Na*iona de 0studos e +es1uisas
0du*a*ionais An/sio Tei2eira &Ine$'( #u$remo Tribuna 3edera
&#T3'
#!456I7: L08ANTA40NT7 90 A!9IT76IA.
C7N-0CI40NT7 AC06CA 9A !TILI:A;<7 90 4=T797#
5>0I# NA# C7NT6ATA;?0# +A6A 90#0N87L8I40NT7
90 SOFTWARE +0LA A94INI#T6A;<7 +@)LICA
30906AL. C!4+6I40NT7 97# 7)A0TI87#.
A6B!I8A40NT7.
60LATC6I7
Trans*revo a seDuir o reat.rio de evantamento eaborado no Embito da #e*retaria de
3is*aizaF"o de Te*nooDia da InGormaF"o - #eGti &$eFa 1HH'I reDistrado no #istema 3is*ais sob o
nJmero 2K0/2013I a$rovado $eos diriDentes da1uea unidade tL*ni*a:
M1. Apresentao
Atualmente, diversos rgos da Administrao Pblica Federal iniciam investimentos para
adotar contrataes de servios de desenvolvimento de software utilizando mtodos geis, ainda
pouco difundidos nacionalmente, principalmente entre instituies pblicas
! "ma vez #ue a $ecretaria de Fiscalizao de %ecnologia da &nformao '$efti( )ulga ainda
no deter a expertise necessria para atuar em fiscalizaes #ue envolvam esse tipo de metodologia,
esta unidade tcnica prop*s a realizao de levantamento com vistas a con+ecer as bases tericas do
processo de desenvolvimento de software com mtodos geis, bem como con+ecer e,peri-ncias
prticas de contratao realizadas por instituies pblicas federais, ob)etivando o aprendizado desta
secretaria em relao ao tema
. /om esse intuito, a $efti, )untamente com a $ecretaria de $olues de %& '$%&( deste
%ribunal, unidade #ue ) possui certo con+ecimento em mtodos geis em decorr-ncia de e,peri-ncia
em desenvolvimento de softwares realizado internamente utilizando essa metodologia, identificou
instituies pblicas #ue possuem contratos cu)o ob)eto de interesse desta fiscalizao e visitou
algumas delas As visitas serviram para col+er informaes, por meio de relatos informais, acerca da
adoo do paradigma de desenvolvimento em comento em seus contratos, bem como inteirar0se do
contedo dos instrumentos convocatrios #ue os originaram
1 /omo resultado do levantamento realizado, este relatrio apresenta conceitos #ue
abrangem a ess-ncia das metodologias geis de desenvolvimento de software, descreve as principais
metodologias atualmente utilizadas pelas instituies pblicas brasileiras visitadas durante a
e,ecuo do levantamento, relata aspectos das contrataes analisadas e, por fim, relaciona alguns
riscos inerentes pass2veis de materializao nas contrataes com metodologias geis
2. Introduo
1
TRIBUNAL DE CONTAS DA UNIO TC 010.663/2013-4
3 Ao longo dos ltimos anos, as contrataes realizadas por instituies pblicas federais
para construo de sistemas informatizados t-m se baseado em metodologias de desenvolvimento de
software aliceradas, em sua maioria, no Processo "nificado de desenvolvimento de sistemas e suas
variaes
4 5bserva0se, contudo, o aumento da popularidade do uso de metodologias geis de
desenvolvimento de software no mercado nacional e internacional 6ssa realidade, somada 7s
insatisfaes fre#uentes das contrataes de servios geradas pelo uso do modelo corrente, tem
levado algumas instituies pblicas a acreditarem #ue podem obter mel+ores resultados com o uso
das metodologias geis 8esse cenrio, instituies pblicas iniciaram investimentos nessa rea,
capacitando seus servidores e instituindo internamente em suas e#uipes de tecnologia da informao,
#uando poss2vel, mtodos geis para o desenvolvimento de suas solues Passado esse movimento
inicial, algumas dessas instituies comearam a realizar contrataes para desenvolvimento de
software, se)a para pro)etos espec2ficos, se)a para fbricas de software, fundamentadas em
metodologias geis
9 /om esse conte,to e dada a falta de con+ecimento aprofundado acerca do tema por esta
$ecretaria de Fiscalizao de %ecnologia da &nformao '$efti( #ue possibilite bem desempen+ar seu
poder fiscalizador, urgiu buscar a expertise necessria para suas futuras atuaes #uando
demandada
: 8essa esteira, previamente 7 realizao desta fiscalizao, membros da $efti foram
capacitados por meio de participao em curso presencial relativo ao Scrum, uma das metodologias
geis mais adotadas atualmente em pro)etos de desenvolvimento de software 6m seguida, esta
unidade tcnica submeteu proposta ao ;inistro <os ;cio ;onteiro visando 7 realizao de
levantamento para a a#uisio de maior con+ecimento acerca do tema, a #ual foi prontamente
deferida
= A submisso da proposta ao >elator decorreu do fato de o ?anco /entral do ?rasil '?acen(,
instituio integrante de sua clientela, ser uma instituio pblica recon+ecidamente possuidora de
e,peri-ncia no desenvolvimento de softwares por meio de mtodos geis
@A Para complementar e enri#uecer as informaes deste levantamento, outras organizaes
pblicas com e,peri-ncia na e,ecuo de pro)etos utilizando mtodos geis foram visitadas durante
esta fiscalizao
@@ "nindo esforos con)untos da $efti e da $ecretaria de $olues de %& '$%&( deste %ribunal,
o presente levantamento foi e,ecutado, buscando0se absorver conceitos tericos em diversas fontes,
como publicaes f2sicas e eletr*nicas, e observar relatos baseados na viv-ncia prtica de algumas
instituies pblicas federais #ue investiram, nos anos recentes, na contratao de desenvolvimento
de software com metodologias geis
@! /omo resultado do trabal+o empreendido, na primeira parte deste relatrio a e#uipe do
presente levantamento consolidou diversas informaes, definies e conceitos col+idos relativos a
metodologias de desenvolvimento de software, geis ou no, de forma a construir o embasamento
terico necessrio ao entendimento dos relatos das e,peri-ncias vividas pelas instituies pblicas
visitadas 8a segunda parte, o relatrio descreve aspectos tcnicos das contrataes realizadas pelas
instituies pblicas #ue receberam a e#uipe Por ltimo, este relatrio ainda confronta os valores
#ue norteiam as metodologias geis com os princ2pios #ue orientam a Administrao Pblica, bem
como apresenta alguns riscos inerentes ao tipo de contratao em estudo
@. &mpende ressaltar #ue este trabal+o no tem o intuito de esgotar as discusses sobre as
caracter2sticas e os riscos da utilizao de metodologias geis mediante o arcabouo normativo
brasileiro %rata0se de uma viso geral e primeira sobre o assunto, #ue subsidia esta $ecretaria a
tratar com o tema de maneira mais precisa
2.1. Deliberao que originou o trabalho
@1 A presente fiscalizao foi originada de proposta elaborada pela $ecretaria de
Fiscalizao de %ecnologia da &nformao '$efti( no Bmbito do %/ AA=:=AC!A@.0A, com fins 7
2
realizao de levantamento acerca da utilizao de mtodos geis nas contrataes para
desenvolvimento de software pela Administrao Pblica Federal
@3 6m @=C1C!A@., por meio de despac+o, o ;inistro0>elator <os ;cio ;onteiro autorizou a
proposta formulada pela $efti 'pea @9(
2.2. b!eti"o e escopo
@4 A presente fiscalizao tem por ob)etivo descrever a definio da ess-ncia dos mtodos
geis, os #uais se constituem em uma metodologia para o desenvolvimento de softwares
Adicionalmente, este trabal+o ob)etiva descrever como algumas instituies pblicas federais esto
realizando contrataes utilizando mtodos geis, assim como apresentar alguns riscos associados a
essas contrataes
@9 A anlise dos contratos identificados no Bmbito desta fiscalizao, 7 luz da conformidade 7
legislao vigente, no faz parte do escopo deste trabal+o
2.#. $etodologia e limita%es
@: &nicialmente, em concordBncia com os padres de levantamento definidos pelo %/", por
meio de pes#uisas na internet e em virtude do con+ecimento tcnico da $ecretaria de $olues de %&
'$%&(, a e#uipe de fiscalizao identificou #uatorze instituies pblicas federais #ue potencialmente
teriam contratos de desenvolvimento de software utilizando mtodos geis Dessas instituies,
conforme o tempo e,istente para a fase de e,ecuo da fiscalizao e utilizando o critrio de
localizao geogrfica, beneficiando as instituies com sede em ?ras2liaCDF, foram selecionadas
sete para visitao e entrevistas com os gestores dos contratos, a saberE
@:@ %ribunal $uperior do %rabal+o '%$%(F
@:! ?anco /entral do ?rasil '?acen(F
@:. &nstituto do Patrim*nio Gistrico e Art2stico 8acional '&p+an(F
@:1 &nstituto 8acional de 6studos e Pes#uisas 6ducacionais An2sio %ei,eira '&nep(F
@:3 $upremo %ribunal Federal '$%F(F
@:4 Departamento de &nformtica do $istema Hnico de $ade 'Datasus(F e
@:9 6mpresa ?rasileira de $ervios Gospitalares '6?$6>G(
@= Das instituies visitadas, verificou0se #ue somente as cinco primeiras possu2am ob)eto de
interesse para este trabal+o Diante disso, a e#uipe de fiscalizao obteve, para anlise, os
respectivos editais de licitao
!A Alm dos rgos supracitados, a e#uipe de fiscalizao tambm se reuniu com o $ervio
Federal de Processamento de Dados '$erpro(, o #ual foi contratado para desenvolver mdulos do
sistema 8ovo $iafi para a $ecretaria do %esouro 8acional utilizando mtodos geis "ma vez #ue,
contratualmente, no foi definida a utilizao da metodologia gil, o contrato balizador do a)uste no
foi analisado
!@ /omo limitao para o presente trabal+o, pode0se citar #ue, ainda #ue a e#uipe de
fiscalizao ten+a obtido, em certa medida, con+ecimento terico e prtico, o pleno con+ecimento
sobre as metodologias geis abrange um vasto dom2nio #ue no p*de ser atingido pela e#uipe
durante a e,ecuo deste trabal+o, devido ao reduzido per2odo de tempo para a sua realizao
#. &iso geral do ob!eto
!! 5 presente trabal+o trata de levantamento acerca da viabilidade da adoo de
metodologias geis de desenvolvimento de software por instituies pblicas federais em suas
contrataes, considerando suas caracter2sticas e seus principais riscos mediante o arcabouo
)ur2dico vigente Para mel+or entender o ob)eto desta fiscalizao, inicialmente faz0se necessria a
abordagem de conceitos tericos e das origens de algumas metodologias de desenvolvimento de
sistemas de informao #ue t-m sido largamente utilizadas na +istria recente da engen+aria de
software
#.1. $etodologias de desen"ol"imento de software
Produto de Software
3
!. A &$5C&6/ @!!A90@==: uma norma tcnica elaborada pela International rgani'ation
for Standardi'ation 'IS( #ue trata de processos de ciclo de vida de software 6la define conceitos e
prope uma estrutura comum para padronizar a discusso em torno de procedimentos, mtodos,
ferramentas e ambientes de desenvolvimento e de ger-ncia de software
!1 $egundo a norma citada, produto de software um con)unto de programas de computador,
procedimentos e poss2vel documentao e dados associados, en#uanto servio de software a
e,ecuo de atividades, trabal+o ou obrigaes relacionados ao produto de software, tais como seu
desenvolvimento, manuteno e operao
!3 Para efeitos didticos, neste te,to tratar0se0 software como sin*nimo de Iproduto de
softwareJ
;etodologia de desenvolvimento de software
!4 De acordo com o dicionrio Aurlio, no campo da literatura, metodologia definida como
o con)unto de tcnicas e processos utilizados para ultrapassar a sub)etividade do autor e atingir a
obra literria < o dicionrio Kebster, no ramo da computao, conceitua metodologia como um
con)unto organizado de procedimentos e guias documentados para a e,ecuo de uma ou mais fases
do ciclo de vida do software
!9 Alin+ando0se a essas definies, em engen+aria de software, uma metodologia de
desenvolvimento comumente entendida como um con)unto estruturado de prticas #ue pode ser
repet2vel durante o processo de produo do sistema ou, ainda, a forma de se utilizar um con)unto de
prticas, mtodos ou processos para se desenvolver ou manter um produto de software, de modo #ue
se evite sub)etividade na e,ecuo do trabal+o 5 uso de metodologias visa 7 produtividade das
e#uipes e 7 #ualidade do produto
!: As metodologias de desenvolvimento de software surgiram em um conte,to tecnolgico
muito diferente do atual, baseado apenas em solues para computadores de grande porte
'mainframes( e terminais burros, poca na #ual o custo para se fazer alteraes e correes nos
sistemas era muito elevado &sso se deu em decorr-ncia do limitado acesso aos computadores e da
ine,ist-ncia de modernas ferramentas de apoio ao desenvolvimento
!= Por sua vez, a definio de processo de software se assemel+a 7 de metodologia de
desenvolvimento de software, conforme se depreende da leitura combinada dos conceitos de processo
e de software constante das normas 8?> &$5C&6/ @33A10@ e @!!A9E con)unto de atividades #ue se
inter0relacionam ou #ue interagem entre si, #ue transforma entradas em um con)unto de programas
de computador, procedimentos, poss2vel documentao e dados associados
.A Atualmente, modelos de mel+oria de processos de software, como o /;;& e o ;P$0?r,
bem como a )urisprud-ncia deste %ribunal 'Acrdos =3.C!AA=, @!..C!A@!, .@.!C!A@! e
@@49C!A@., todos do Plenrio do %/"(, t-m utilizado o termo Iprocesso de softwareJ em detrimento a
Imetodologia de desenvolvimento de softwareJ, embora as definies de ambos se)am, em ess-ncia,
id-nticas
.@ De todo modo, este trabal+o utilizar, e,cepcionalmente, o termo Imetodologia de
desenvolvimento de softwareJ, no intuito de se apro,imar da linguagem utilizada pelos especialistas
em mtodos geis, ob)eto deste trabal+o
;etodologia em cascata ou clssica
.! 8os anos @=9A difundiu0se internacionalmente uma das mais con+ecidas metodologias de
desenvolvimento de software, o modelo em cascata 'waterfall(, tambm con+ecido como clssico ou
linear 8essa metodologia, largamente utilizada at o in2cio da dcada de @==A, o sistema todo
plane)ado e documentado, seguindo diversas fases, se#uencialmente, antes de ser implementado As
atividades do processo de desenvolvimento so estruturadas em uma ordem fi,a de fases 'cascata(, na
#ual as sa2das de cada fase L geralmente documentos L aps aprovadas, tornam0se entradas para a
pr,ima 6spera0se, no fim da ltima fase, #ue o produto de software este)a pronto, baseando0se na
premissa de #ue o trabal+o nas fases anteriores foi realizado de maneira correta e gerou os produtos
#ue delas se esperava
4
.. 6mbora ten+a au,iliado a engen+aria de software #uando de seu surgimento, oferecendo
uma forma disciplinada para a construo de solues, com o advento de novas tecnologias, como
microcomputadores utilizados em larga escala, o modelo em cascata passou a no atender 7s
necessidades emergentes Fomentaram0se, ento, diversas cr2ticas a esse modelo, como a
impossibilidade de retornar de modo simples 7 e,ecuo de atividades em fases anteriores e a
e,cessiva produo de documentao nas fases iniciais do pro)eto &sso causava, respectivamente,
uma elevao significativa do custo das mudanas no pro)eto e demora na disponibilizao do
software
;etodologia baseada em prototipao
.1 Fre#uentemente, dado o dinamismo dos problemas empresariais sobre os #uais o sistema
atuar, o cliente possui um con)unto de ob)etivos genricos para o software, geralmente con+ecidos, e
um con)unto de detal+es espec2ficos, no identificados minuciosamente no momento de sua
concepo Por outro lado, em alguns casos, o desenvolvedor necessita assegurar a efici-ncia de um
algoritmo, a adaptabilidade de um sistema operacional ou a forma #ue a interao +omem0m#uina
deve ter no sistema a ser constru2do
.3 Para au,iliar nessas #uestes, surgiu a prototipao, #ue consiste em um processo no #ual
o desenvolvedor pode criar um modelo do software #ue deve ser constru2do 5 modelo pode assumir
vrias formas, inclusive a construo de um prottipo #ue implementa um subcon)unto das
funcionalidades re#ueridas do software dese)ado
.4 5 processo de prototipao iterativo, repetindo0se fases bem definidas, basicamente para
col+er e refinar re#uisitos Portanto, o ob)etivo construir o prottipo e obter o feedbac( do cliente
em fases iniciais do pro)eto 5 prottipo serve como mecanismo para identificar os re#uisitos do
software, raramente servindo como produto final, uma vez #ue foi constru2do I7s pressasJ, sem
considerar importantes aspectos do software, como sua #ualidade geral a longo prazo, seu
desempen+o e sua usabilidade
.9 Por isso, a prototipao tem como grande problema a criao da e,pectativa do cliente
#ue en,erga o prottipo como uma verso funcional do software, en#uanto o mesmo foi fragilmente
constru2do de modo a validar um con)unto de re#uisitos iniciais 6sse fato pode levar o desenvolvedor
a comprometer a implementao visando disponibilizar um prottipo funcional rapidamente, sem se
preocupar em desenvolver o produto em si nas fases posteriores
;etodologia 6spiral
.: 5 modelo em espiral, proposto em @=::, foi desenvolvido para abranger as mel+ores
caracter2sticas do modelo clssico 'cascata( e do modelo de prototipao, adicionando, ao mesmo
tempo, a anlise de riscos, no presente nessas outras metodologias
.= /omo o prprio nome referencia, o modelo representado por uma espiral na #ual, para o
desenvolvimento do software, atividades de #uatro fases 'plane)amento, anlise de riscos, construo
e avaliao do cliente( so realizadas linearmente, como no modelo em cascata, porm de forma
iterativa, dando uma abordagem evolucionria ou incremental 7 engen+aria de software A cada
iterao dessas fases, uma verso constru2da e, 7 medida #ue as iteraes avanam, as verses
tornam0se mais completas, de forma progressiva
1A 5 modelo em espiral apro,ima o cliente do processo de desenvolvimento ao permitir #ue,
de sua avaliao do produto, sur)am sugestes e modificaes, isto , a avaliao do cliente
fundamenta as pr,imas etapas de plane)amento e anlise de riscos
1@ 6ssa metodologia apresenta como principal problema o risco da perpetuao do
desenvolvimento, dado o seu carter evolutivo
;etodologia de Processo "nificado
1! 6m paralelo ao aparecimento do modelo clssico, no final da dcada de @=4A, em pro)eto
desenvolvido por &var <acobson na empresa de telefonia )ricsson, surgiram as origens da
metodologia de desenvolvimento denominada Processo "nificado '*nified +rocess L *+( 6m @=:9,
ao sair da )ricsson, <acobson fundou a empresa b!ector, S,stems, renomeada, em @==@, para
N
b!ector, A- 6ssa compan+ia despendeu anos de esforos para o desenvolvimento do b!ectr,, o
#ual consistia em um mtodo de desenvolvimento de softwares orientado a ob)etos
1. 6m @==3, com a e,peri-ncia ad#uirida ao longo de seus pro)etos, <acobson lanou o livro
b!ect.riented )ngineering, no #ual propun+a a idia de #ue os re#uisitos do cliente deveriam ser
a fora diretiva mais importante no desenvolvimento de software, alm de mostrar a g-nese da -nfase
do Processo "nificado na ar#uitetura dos sistemas Ainda na#uele ano, a empresa /ational Software
0orporation ad#uiriu a b!ector, S,stems e, no Bmbito do produto /ational b!ector, +rocess
'/+(, continuou o desenvolvimento do b!ectr,, e,pandindo0o para reas ainda no abordadas,
como ferramentas de gerenciamento e de desenvolvimento de pro)etos
11 M medida #ue o /+ progredia, a empresa /ational continuava a ad#uirir empresas
fabricantes de ferramentas de desenvolvimento de software ou a elas se fundir As ferramentas
ad#uiridas agregaram valor ao produto /+ e, em @==:, a /ational alterou o seu nome para
/ational *nified +rocess '/*+( Assim, passou a consistir em uma verso comercial do *+,
framewor( ou metodologia de desenvolvimento #ue foi constru2da praticamente de forma simultBnea
ao /*+, tambm pela empresa /ational
13 /ontrapondo0se ao modelo em cascata, o *+ prop*s0se como uma metodologia de
desenvolvimento iterativa e incremental, caracter2sticas +erdadas do modelo espiral 8o *+, as
#uatro fases de desenvolvimento do sistema 'concepo, elaborao, construo e transio( so
repetidas em ciclos, obtendo0se, ao trmino de cada ciclo, uma verso funcional do software 6m
acrscimo, o *+ tambm se prop*s a ser adaptativo, de forma a atender 7s necessidades espec2ficas
de cada pro)eto
14 5 surgimento do Processo "nificado trou,e diversas vantagens ao processo de
desenvolvimento de softwares #uando comparado ao modelo em cascata Algumas delas soE a
entrega de verses com mais constBncia, precipitando o feedbac( sobre o produtoF a antecipao em
identificar as mudanas, diminuindo o custo das alteraes no decorrer do desenvolvimentoF o
controle dos riscos inerentes ao pro)etoF o foco no produtoF e o aumento da #ualidade do produto
final
19 /ontudo, as organizaes #ue produzem e contratam pro)etos de construo de software,
na tentativa de adotar o *+ e suas variantes, como o /*+, no raramente desvirtuam suas principais
caracter2sticas 'iteratividade e incrementalidade(, e terminam por realizar adaptaes nas #uais a
prpria ess-ncia do modelo se perde 8esses casos, as atividades de construo de software, #ue
deveriam ser e,ecutadas vrias vezes em vrios ciclos, passam a ser e,ecutadas uma nica vez, de
maneira puramente se#uencial, similar ao #ue ocorre no modelo em cascata, desvirtuando o conceito
fundamental relacionado 7 gerao incremental #ue agregue valor ao negcio
;etodologias Ngeis
1: Alm das metodologias anteriormente citadas, atualmente est em voga a utilizao de
metodologias geis
1= As metodologias geis so representadas por um con)unto de valores e princ2pios a ser
utilizado no processo de desenvolvimento de sistemas 6sse con)unto de valores e princ2pios foi
e,ternado em !AA@, por meio da divulgao do ;anifesto para Desenvolvimento Ngil de Software,
criado por um grupo de dezessete especialistas em processos de desenvolvimento de software #ue,
individualmente, ) utilizavam prticas e teorias adaptadas
3A 5 ;anifesto para Desenvolvimento Ngil de Software, tambm con+ecido apenas como
;anifesto Ngil, foi alicerado em um pe#ueno con)unto de princ2pios #ue, segundo os autores,
pareciam ter sido recorrentemente respeitados nos casos de sucesso dos seus pro)etos
3@ 6mbora alguns profissionais acreditem #ue a ess-ncia e as prticas adotadas pelas
metodologias geis se)am modernas e inovadoras, pode0se dizer #ue sua origem remonta aos anos
#ue sucederam 7 $egunda Ouerra ;undial, no Bmbito da empresa %oPota 8a#uela poca, a indstria
)aponesa tin+a uma produtividade muito bai,a e uma enorme falta de recursos, o #ue dificultava a
adoo do modelo de produo em massa 8esse conte,to, a %oPota desenvolveu um sistema de
6
produo c+amado de 1ean $anufacturing 'produo en,uta( ou 2o,ota +roduction S,stem '2+S(
L $istema de Produo %oPota, em portugu-s L cu)o ob)etivo consistia em aumentar a efici-ncia da
produo pela eliminao cont2nua de desperd2cios 5 2+S contemplava diversas caracter2sticas ou
prticas incorporadas 7s metodologias geis, entre as #uais se destacamE
3@@ construir apenas o #ue necessrio, eliminando desperd2ciosF
3@! realizar entregas rpidas e cont2nuasF
3@. estar sempre aberto 7s mudanas
3! 5 ;anifesto Ngil, transcrito a seguir, apresenta e descreve a ess-ncia de um con)unto de
abordagens para desenvolvimento de software #ue vem sendo adotado desde a dcada de @==A
I;anifesto Ngil
6stamos descobrindo maneiras mel+ores de desenvolver software fazendo0o ns mesmos e
a)udando outros a faz-0lo Atravs deste trabal+o, passamos a valorizarE
&ndiv2duos e interao entre eles mais #ue processos e ferramentas
Software em funcionamento mais #ue documentao abrangente
/olaborao com o cliente mais #ue negociao de contratos
>esponder a mudanas mais #ue seguir um plano
5u se)a, mesmo +avendo valor nos itens 7 direita, valorizamos mais os itens 7 es#uerdaJ
3. Alm dos valores e,pressos no manifesto, foram formulados os princ2pios #ue os
sustentam, apresentados a seguirE
31 Princ2pio @E nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e
cont2nua de software de valor
31@ A priorizao na construo das funcionalidades #ue o software deve possuir feita com
base na importBncia #ue elas t-m para o cliente e no seu valor para o negcio, e no em outros
critrios, como a comple,idade da funcionalidade a ser implantada
31! A entrega de verses intermedirias do software deve e,istir e ser incremental,
antecipando ao m,imo a sua utilizao pelos usurios, a fim de aferir, pelo efetivo uso, se o seu
funcionamento atende a suas e,pectativas 6ssa caracter2stica tambm possibilita plane)ar mel+or a
construo dos re#uisitos seguintes, ) #ue a e#uipe e os usurios possuiro uma e,peri-ncia na
utilizao do #ue ) est pronto
33 Princ2pio !E aceitar mudanas de re#uisitos, mesmo ao fim do desenvolvimento Processos
geis se ad#uam a mudanas para #ue o cliente possa tirar vantagens competitivas
33@ A entrega fre#uente de partes do software em pleno funcionamento e o mais cedo
poss2vel possibilita #ue se construa um ambiente de constante feedbac( a respeito das necessidades
do cliente 5bserva0se #ue tal feedbac( normalmente fomenta mudanas recorrentes dos re#uisitos
por parte do cliente
33! 5s processos ditos geis tratam a mudana nas necessidades do cliente como algo
natural e necessrio para a construo de um software ade#uado %anto mel+or for a percepo do
usurio na utilizao real do sistema, formas mel+ores de resolver problemas ao longo do pro)eto
podem ser idealizadas e constru2das em con)unto
34 Princ2pio .E entregar software funcionando com fre#u-ncia, na escala de semanas at
meses, com prefer-ncia aos per2odos mais curtos
34@ Durante o pro)eto de desenvolvimento, recomenda0se #ue entregas parciais e funcionais
se)am feitas com a maior fre#u-ncia poss2vel, para assegurar, o #uanto antes, se o #ue est sendo
constru2do realmente atende 7s necessidades dos clientes e dos usurios, mitigando, portanto, alguns
riscos do pro)eto
39 Princ2pio 1E pessoas relacionadas a negcios e desenvolvedores devem trabal+ar em
con)unto e diariamente, durante todo o curso do pro)eto
39@ 8o cerne desse princ2pio, est o acesso e a comunicao entre as pessoas da e#uipe #ue,
independente do papel de cada uma, deve ser o mais simples poss2vel Ferramentas automatizadas e
H
encontros fre#uentes devem ser utilizados a fim de #ue a transfer-ncia de con+ecimento no acontea
apenas por meio de produo e leitura de documentos, e sim por meio da comunicao informal
39! Alm disso, esse princ2pio materializa a posio de #ue o sucesso do pro)eto depende da
dedicao e disponibilidade das pessoas envolvidas &sso inclui uma maior participao do cliente em
todas as fases do pro)eto, a fim de elucidar os re#uisitos, definir regras de negcio, dirimir dvidas
durante a construo das funcionalidades e avaliar prontamente o funcionamento dos softwares
intermedirios #ue forem sendo constru2dos
3: Princ2pio 3E construir pro)etos ao redor de indiv2duos motivados, dando a eles o ambiente
e suporte necessrio, e confiar #ue faro seu trabal+o
3:@ A motivao dos membros da e#uipe advm da disponibilizao de um ambiente de
trabal+o saudvel, constitu2do de ferramentas e instrumentos ade#uados para a e,ecuo do seu
trabal+o Por sua vez, a confiana entre os membros da e#uipe necessria para promover o
ambiente colaborativo 6 no ambiente colaborativo #ue surgem solues com #ualidade
3= Princ2pio 4E o mtodo mais eficiente e eficaz de transmitir informaes, para e por dentro
de um time de desenvolvimento, atravs de uma conversa Icara a caraJ
3=@ A produo de documentos, planil+as, modelos e diagramas no deve substituir o
dilogo cont2nuo entre o cliente e a e#uipe de desenvolvimento Q responsabilidade primordial da
e#uipe tcnica prover as mel+ores solues tecnolgicas e do cliente transmitir ade#uadamente as
necessidades e regras do negcio $egundo os princ2pios, por meio da colaborao entre os membros
da e#uipe, aumentam consideravelmente as c+ances de se alcanar os ob)etivos do pro)eto
4A Princ2pio 9E software funcional a medida primria de progresso
4A@ A principal medida de sucesso e progresso de um pro)eto de desenvolvimento de software
ter o programa de computador em operao, com as funcionalidades sendo +omologadas pelo
cliente
4A! 6ste princ2pio no dispensa a elaborao da documentao produzida pelas e#uipes,
nem mesmo d menos importBncia aos profissionais #ue no produzam programas de computador
propriamente ditos A proposta #ue no se considere #ue o pro)eto est evoluindo com sucesso tendo
como base somente a produo de documentao Programas em funcionamento, em ltima instBncia,
so o #ue definem o progresso do pro)eto de desenvolvimento de software
4@ Princ2pio :E processos geis promovem um ambiente sustentvel 5s patrocinadores,
desenvolvedores e usurios devem ser capazes de manter, indefinidamente, passos constantes
4@@ >ecomenda0se #ue se manten+a, de forma e#uilibrada durante o pro)eto, o atendimento a
todos os princ2pios 5 sucesso dos pro)etos vem do e#uil2brio e da constBncia na adoo de cada um
dos princ2pios
4! Princ2pio =E cont2nua ateno 7 e,cel-ncia tcnica e ao bom design aumenta a agilidade
4!@ Aumentar a agilidade significa, entre outras coisas, #ue o retorno do investimento em um
pro)eto se)a ma,imizado Atentar0se 7 e,cel-ncia tcnica, em paralelo a todos os outros princ2pios,
aumenta as c+ances de gerar um produto de #ualidade e, por conse#u-ncia, diminui os riscos na
sustentao futura do software Assim, o retorno do investimento tende a se manter positivo durante
todo o ciclo de vida do produto de software
4. Princ2pio @AE simplicidade, ou se)a, a arte de ma,imizar a #uantidade de trabal+o #ue no
precisou ser feito
4.@ Q importante #ue se)am desenvolvidas funcionalidades no software e,atamente como
foram solicitadas, resistindo0se 7 tentao de desenvolver funcionalidades para atender a futuros
problemas #ue ainda no e,istem
41 Princ2pio @@E as mel+ores ar#uiteturas, re#uisitos e designs emergem de times auto0
organizveis
41@ A auto0organizao baseia0se na idia de #ue necessrio +orizontalizar as decises de
um time de alto desempen+o 5 modelo onde um gerente pensa de modo restrito nas tarefas de um
pro)eto e as distribui para o restante da e#uipe no favorece a concepo de boas solues A ordem
O
se constri com a participao ativa dos membros da e#uipe, independentemente do seu papel, e da
construo de um senso de grupo Q baseado nessa mesma teoria #ue, +o)e, softwares de n2vel
mundial so desenvolvidos de maneira livre 'open.source(, com colaborao remota de membros,
sem #ue pessoas ten+am #ue controlar #uem faz o #u-
41! /om o estudo deste princ2pio, observa0se #ue a ger-ncia estrita perde lugar para a
orientao, a definio e atribuio de tarefas passam a ser responsabilidade de todos, e as metas so
do time e no mais individuais
43 Princ2pio @!E em intervalos regulares, o time reflete sobre como se tornar mais efetivo
6nto, a)ustam0se e otimizam seu comportamento de acordo
43@ 8en+um processo de software perfeito >ecomenda0se #ue, de tempos em tempos, as
pessoas reflitam sobre o processo, identificando pontos fal+os e poss2veis oportunidades de mel+oria
A idia #ue o aperfeioamento peridico do processo permite a mel+oria cont2nua no processo de
trabal+o, a fim de produzir software de #ualidade
44 8essa esteira, entende0se como ;etodologia Ngil de desenvolvimento de software o
con)unto de mtodos, processos e framewor(s #ue so norteados pelos valores e princ2pios acima
descritos
49 /om fins puramente didticos, ao longo deste relatrio, as metodologias no geis sero
agrupadas em um con)unto #ue se convencionou denominar metodologias tradicionais
#.2. +rincipais metodologias 3geis de desen"ol"imento de software
4: Atualmente, vrias metodologias geis so utilizadas pelo mercado mundial para o
desenvolvimento de software, tais comoE e4treme +rogramming, Scrum, 5eature Dri"en
De"elopment '5DD(, D,namic S,stems De"elopment $ethod 'DSD$(, Adapti"e Software
De"elopment 'ASD(, 0r,stal6 +ragmatic +rogramming, 2est Dri"en De"elopment '2DD(, 7anban,
entre outras
4= 8o ?rasil, segundo o >elatrio %cnico >% ;A/0!A@!0A. do Departamento de /i-ncia da
/omputao do &nstituto de ;atemtica e 6stat2stica da "niversidade de $o Paulo '&;60"$P(, de
maio de !A@! 'pea @:(, fundamentado em pes#uisa sobre a adoo de prticas em times e
organizaes brasileiras, as metodologias mais utilizadas so Scrum, e4treme +rogramming '4+( e
a combinao entre elas "ma vez #ue o trabal+o em campo identificou #ue essas metodologias,
acrescidas do 7anban, so as mais utilizadas nas instituies pblicas visitadas, elas sero descritas
sucintamente a seguir
#.2.1. Scrum
9A 6m @=:4, %aReuc+i e 8onaRa publicaram um artigo na revista 8ar"ard -usiness /e"iew,
descrevendo uma nova abordagem para desenvolvimento de produtos 6mpresas como .; e 0anon
inovaram na forma de desenvolver seus produtos, a fim de #ue o processo produtivo fosse mais rpido
e os produtos c+egassem ao mercado o #uanto antes A organizao das e#uipes nessas empresas se
assemel+ava 7 formao scrum dos times nos )ogos de rugb,, com composio multidisciplinar,
constante interao entre os membros, #ue trabal+avam )untos do in2cio ao fim do processo produtivo
para entregar um produto
9@ &nspirados nesse artigo, Sen $c+Taber e <eff $ut+erland desenvolveram o Scrum, #ue
consiste em um framewor( #ue pode ser utilizado para desenvolver e manter produtos comple,os $ua
definio encontrada no Ouia do Scrum 'pea @=(, no #ual seus criadores documentam como o
framewor( foi desenvolvido e mantido por eles por mais de vinte anos Q livre e oferecido por seu
Ouia, #ue pode ser obtido gratuitamente no s2tio eletr*nico www.scrum.org Por tal motivo, as
definies e informaes a seguir apresentadas, foram e,tra2das de seu prprio guia oficial
9! $egundo a viso geral do Ouia, o Scrum pode ser definido comoE
I"m framewor( dentro do #ual pessoas podem tratar e resolver problemas comple,os e
adaptativos, en#uanto produtiva e criativamente entregam produtos com o mais alto valor poss2vel
Scrum E
0 Ueve
K
0 $imples de entender
0 6,tremamente dif2cil de dominar
Scrum um framewor( estrutural #ue est sendo usado para gerenciar o desenvolvimento de
produtos comple,os desde o in2cio de @==A Scrum no um processo ou uma tcnica para construir
produtosF em vez disso, um framewor( dentro do #ual voc- pode empregar vrios processos ou
tcnicas 5 Scrum dei,a claro a eficcia relativa das prticas de gerenciamento e desenvolvimento de
produtos, de modo #ue voc- possa mel+or0lasJ 'pea @=, p .(
9. 5 Scrum fundamentado nas teorias emp2ricas de controle de processo, ou empirismo,
segundo o #ual o con+ecimento vem da e,peri-ncia e de tomada de decises baseada no #ue
con+ecido %ambm emprega uma abordagem iterativa e incremental para aperfeioar a
previsibilidade e o controle de riscos 'pea @=, p 1(
91 5 Scrum consiste nas e#uipes ou times Scrum, as #uais so associadas a papeis, eventos,
artefatos e regras /ada componente dentro do framewor( serve a um propsito espec2fico e
essencial para o uso e sucesso da metodologia $uas regras integram os eventos, papeis e artefatos,
administrando as relaes e interaes entre eles 'pea @=, p 3(
Papeis do Scrum
%ime Scrum
93 "m time Scrum composto pelo +roduct wner '+(, pela e#uipe de desenvolvimento e
pelo Scrum $aster 5s times so auto0organizveis e multifuncionais 6#uipes auto0organizveis
escol+em a mel+or forma para completarem seu trabal+o, em vez de serem dirigidos por outros de
fora da e#uipe 6#uipes multifuncionais possuem todas as compet-ncias necessrias para completar o
trabal+o sem depender de outros #ue no fazem parte da e#uipe 5 modelo de e#uipe pro)etado
para aperfeioar a fle,ibilidade, criatividade e produtividade 'pea @=, p 3(
94 %imes Scrum entregam produtos de forma iterativa e incremental, ma,imizando as
oportunidades de feedbac( 6ntregas incrementais de produto IprontoJ garantem #ue uma verso
potencialmente funcional do produto do trabal+o este)a sempre dispon2vel 'pea @=, p 3(
+roduct wner
99 5 +roduct wner '+(, ou dono do produto, o responsvel por ma,imizar o valor do
produto e do trabal+o da e#uipe de desenvolvimento A maneira como isso feito pode variar
amplamente entre as organizaes, times Scrum e indiv2duos 5 + a nica pessoa responsvel por
gerenciar o bac(log do produto, por meio de tarefas #ue incluem 'pea @=, p 3(E
99@ e,pressar claramente os itens do bac(log do produtoF
99! ordenar ou priorizar esses itens para mel+or alcanar as metas e missesF
99. garantir o valor do trabal+o realizado pelo time de desenvolvimentoF
991 garantir #ue o bac(log do produto se)a vis2vel, transparente, claro para todos, e mostrar
no #ue o time Scrum trabal+ar a seguirF e
993 garantir #ue a e#uipe de desenvolvimento entenda os itens do bac(log do produto no
n2vel necessrio
9: 5 bac(log do produto definido nos itens @A4 a @@A deste relatrio
9= 5 +roduct wner pode desempen+ar essas atividades ou deleg0las para #ue a e#uipe de
desenvolvimento as faa 8o entanto, o + continua sendo o responsvel &mporta ressaltar #ue o
+roduct wner uma pessoa e no um comit- 6le pode representar o dese)o de um comit- no
bac(log do produto, mas a#ueles #ue dese)arem uma alterao nas prioridades dos itens de bac(log
devem convencer o + a tomar essa deciso Para #ue o +roduct wner ten+a sucesso, toda a
organizao deve respeitar as suas decises, #ue so vis2veis no contedo e na priorizao do
bac(log 'pea @=, p 304(
6#uipe de desenvolvimento
:A A e#uipe de desenvolvimento consiste de profissionais #ue realizam o trabal+o de entregar
uma verso potencialmente utilizvel #ue incrementa o produto IprontoJ ao final de cada sprint
10
$omente integrantes da e#uipe de desenvolvimento criam incrementos do produto de software 'pea
@=, p 4(
:@ As e#uipes de desenvolvimento so estruturadas e autorizadas pela instituio para
organizar e gerenciar seu prprio trabal+o A sinergia resultante aperfeioa a sua efici-ncia e
eficcia como um todo 6las possuem as seguintes caracter2sticas 'pea @=, p 4(E
:@@ so auto0organizadas, isto , ningum 'nem mesmo o Scrum $aster( diz 7 e#uipe como
transformar o bac(log do produto em incrementos de funcionalidades potencialmente utilizveisF
:@! so multifuncionais, possuindo todas as +abilidades necessrias, en#uanto e#uipe, para
criar o incremento do produtoF
:@. o Scrum no recon+ece t2tulos para os integrantes da e#uipe #ue no se)a o de
desenvolvedor, independentemente do trabal+o #ue est sendo realizado pela pessoa, no +avendo
e,cees para esta regraF
:@1 individualmente, os integrantes da e#uipe de desenvolvimento podem ter +abilidades
espec2ficas e reas diferentes de especializao, mas a responsabilidade pertence 7 e#uipe como um
todoF
:@3 e#uipes de desenvolvimento no contm sube#uipes dedicadas a dom2nios espec2ficos de
con+ecimento, tais como teste ou anlise de negcios
Scrum $aster
:! 5 Scrum $aster o responsvel por garantir #ue o Scrum se)a entendido e aplicado, de
forma a assegurar #ue o time Scrum adere 7 teoria, prticas e regras da metodologia Q um servo0
l2der para o time Ainda tem como atribuio a)udar a#ueles #ue esto fora do time a entender #uais
as suas interaes com o time so teis e #uais no so, ob)etivando ma,imizar o valor criado pelo
time Scrum 'pea @=, p 9(
:. 5 Scrum $aster trabal+a para atender 7s necessidades do +roduct wner, encontrando
tcnicas para o gerenciamento efetivo do bac(log do produtoF comunicando claramente a viso,
ob)etivo e itens do bac(log do produto para a e#uipe de desenvolvimentoF ensinando o time Scrum a
criar itens de bac(log do produto de forma clara e concisaF compreendendo, a longo prazo, o
plane)amento do produto no ambiente emp2ricoF compreendendo e praticando a agilidadeF e
facilitando os eventos Scrum conforme e,igidos ou necessrios 'pea @=, p 9(
:1 Por sua vez, trabal+a tambm para au,iliar a e#uipe de desenvolvimento, treinando0a em
autogerenciamento e interdisciplinaridadeF ensinando0a e liderando0a na criao de produtos de alto
valorF removendo impedimentos para o seu progressoF facilitando os eventos Scrum conforme
e,igidos ou necessriosF e treinando a e#uipe de desenvolvimento em ambientes organizacionais nos
#uais o Scrum no totalmente adotado e compreendido 'pea @=, p 9(
:3 Por fim, o Scrum $aster tambm trabal+a au,iliando a instituio, liderando e treinando
a organizao na adoo da metodologiaF plane)ando implementaes Scrum dentro da organizaoF
a)udando funcionrios e partes interessadas a compreender e tornar aplicvel o Scrum e o
desenvolvimento de produto emp2ricoF causando mudanas #ue aumentam a produtividade do timeF e
trabal+ando com outro Scrum $aster para aumentar a eficcia da aplicao da metodologia na
organizao 'pea @=, p 9(
6ventos do Scrum
:4 6ventos prescritos so usados para criar uma rotina e minimizar a necessidade de
reunies no definidas 5 Scrum usa eventos time.boxed, ou se)a, Iespaos de tempoJ nos #uais todo
evento tem uma durao m,ima definida, garantindo #ue uma #uantidade ade#uada de tempo se)a
gasta no plane)amento, sem permitir perdas ao longo desse processo 'pea @=, p :(
:9 Alm da sprint, #ue um container para outros eventos, cada evento no Scrum uma
oportunidade formal para inspecionar e adaptar alguma coisa, sendo especificamente pro)etado para
permitir transpar-ncia e inspeo criteriosa A no incluso de #ual#uer um dos eventos resultar na
reduo da transpar-ncia e na perda de oportunidade para inspecionar e adaptar 'pea @=, p :(
Sprint
11
:: 5 corao do Scrum a sprint, um time.box de um m-s corrido ou menos, durante o #ual
uma verso incremental potencialmente utilizvel do produto 'IprontoJ( criada Sprints tem
duraes coerentes em todo o esforo de desenvolvimento "ma nova sprint inicia0se imediatamente
aps a concluso da anterior $o compostas por uma reunio de plane)amento, reunies dirias,
trabal+o de desenvolvimento, reviso e retrospectiva 'pea @=, p :(
:= Vuando o +orizonte temporal da sprint muito longo, a definio do #ue ser constru2do
pode mudar, a comple,idade pode aumentar e o risco pode crescer /om curtos per2odos, permitem
uma previsibilidade #ue garante a inspeo e adaptao do progresso em direo 7 meta pelo menos
a cada m-s corrido 'pea @=, p :(
=A Durante a sprint, no so feitas mudanas #ue podem afetar seu ob)etivo, a composio da
e#uipe de desenvolvimento permanece constante, as metas de #ualidade no diminuem e o escopo
pode ser esclarecido e renegociado entre o +roduct wner e a e#uipe de desenvolvimento 7 medida
#ue se)a mel+or entendido 'pea @=, p :(
=@ /ada sprint pode ser considerada um pro)eto com prazo no maior #ue um m-s, #ue
contempla a definio do #ue deve ser constru2do e um plano pro)etado e fle,2vel para guiar a
construo, o trabal+o e o resultado do produto 'pea @=, p :(
=! 6mbora incomum, uma sprint pode ser cancelada antes do seu time.box 'tempo previsto(
terminar Porm, somente o + tem a autoridade para cancel0la, embora possa fazer isso sob
influ-ncia das partes interessadas, da e#uipe de desenvolvimento ou do Scrum $aster 5
cancelamento ocorre se o seu ob)etivo se tornar obsoleto, ou se)a, #uando no fizer mais sentido sua
e,ecuo 7s dadas circunstBncias 'pea @=, p :0=(
>eunio de plane)amento da sprint
=. 5 trabal+o a ser realizado na sprint plane)ado na reunio de plane)amento com o
trabal+o colaborativo de todo o time Scrum Possui tempo m,imo estabelecido e consiste em duas
partes, cada uma ocupando a metade desse tempo 'pea @=, p =(
=1 8a primeira parte da reunio, define0se o #ue ser entregue como resultado do incremento
da sprint, sendo atribuio da e#uipe de desenvolvimento, e somente dela, selecionar os itens
ordenados do bac(log do produto previamente apresentado pelo P5 #ue sero implementados 'pea
@=, p =(
=3 Aps a e#uipe de desenvolvimento escol+er os itens #ue sero entregues, o time Scrum
determina a meta da sprint, #ue consiste em um ob)etivo #ue ser con+ecido por meio da
implementao do bac(log do produto, fornecendo orientao relativa acerca da motivao do
incremento 'pea @=, p =0@A(
=4 8a segunda parte da reunio de plane)amento, define0se como o trabal+o necessrio para
entregar o incremento ser realizado 5s itens de bac(log do produto selecionados para a sprint
)unto com o plano de entrega desses itens c+amado de bac(log da sprint 'pea @=, p @A(
>eunio diria
=9 A reunio diria do Scrum um evento de no m,imo #uinze minutos, destinado 7 e#uipe
de desenvolvimento para sincronizar as atividades e criar um plano para as pr,imas !1 +oras Q
feita para inspecionar o trabal+o desde a ltima reunio diria, e prever o trabal+o #ue dever ser
feito antes da pr,ima reunio diria 'pea @=, p @A0@@(
=: As reunies dirias mel+oram a comunicao, eliminam outras reunies, identificam e
removem impedimentos para o desenvolvimento, destacam e promovem rpidas tomadas de deciso, e
mel+oram o n2vel de con+ecimento da e#uipe de desenvolvimento 'pea @=, p @@(
>eviso da sprint
== A reviso da sprint uma reunio informal e,ecutada ao seu trmino para inspecionar o
incremento e adaptar o bac(log do produto, se necessrio Assim como os outros eventos, possui
durao m,ima pr0estabelecida 8ela, o incremento produzido apresentado, destinando0se a
motivar, obter comentrios e promover a colaborao 'pea @=, p @@(
12
@AA Durante a reviso da sprint, o time Scrum e as partes interessadas colaboram sobre o
#ue foi e,ecutado /om base nisso e em #ual#uer mudana no bac(log do produto, os participantes
colaboram nas pr,imas tarefas #ue precisam ser prontas 'pea @=, p @@(
@A@ 6m suma, na reunio de reviso, o + identifica o #ue ficou IprontoJ e o #ue no ficou
IprontoJF a e#uipe de desenvolvimento discute o #ue foi bem durante a sprint, #uais problemas
ocorreram e como foram resolvidosF a e#uipe de desenvolvimento demonstra o trabal+o #ue est
IprontoJ e responde as #uestes sobre o incrementoF o + discute o bac(log do produto tal como est
e pro)eta as provveis datas de concluso baseado no progresso correnteF e o grupo todo colabora
sobre o #ue fazer a seguir, fornecendo valiosas entradas para a reunio de plane)amento da pr,ima
sprint 'pea @=, p @!(
@A! 5 resultado da reunio de reviso da sprint um bac(log do produto revisado #ue define
o provvel bac(log do produto para a pr,ima sprint 5 bac(log tambm pode ser a)ustado
completamente para atender novas oportunidades 'pea @=, p @!(
>etrospectiva da sprint
@A. A retrospectiva da sprint uma oportunidade para o time Scrum revisar a si prprio e
criar um plano de mel+orias a serem aplicadas na pr,ima sprint 5corre depois da reunio de
reviso e antes da reunio de plane)amento da pr,ima sprint Q uma reunio com durao m,ima
pr0estabelecida 'pea @=, p @!(
@A1 Durante cada reunio de retrospectiva, o time Scrum plane)a formas de aumentar a
#ualidade do produto, adaptando a definio de IprontoJ, #uando apropriado Ao seu final, o time
Scrum dever ter identificado mel+orias #ue sero implementadas na pr,ima sprint 'pea @=, p @!(
Artefatos do Scrum
@A3 5s artefatos do Scrum representam o trabal+o ou o valor de vrias maneiras teis para
prover transpar-ncia e oportunidades para inspeo e adaptao 5s artefatos definidos no Scrum
so especificamente pro)etados para ma,imizar a transpar-ncia das informaes0c+ave necessrias
para assegurar #ue o time Scrum ten+a sucesso na entrega do incremento IprontoJ 'pea @=, p @!(
-ac(log do produto
@A4 5 bac(log do produto uma lista ordenada ou priorizada de tudo #ue deve ser
necessrio no produto, e uma origem nica dos re#uisitos para #ual#uer mudana a ser feita nele 5
+ responsvel pelo bac(log do produto, incluindo seu contedo, disponibilidade e ordenao ou
priorizao 'pea @=, p @.(
@A9 Partindo0se da premissa de #ue os primeiros desenvolvimentos apenas estabelecem os
re#uisitos inicialmente con+ecidos e mel+or entendidos, entende0se #ue o bac(log do produto nunca
est completo Ao contrrio, ele evolui tanto #uanto o produto e o ambiente no #ual ele ser utilizado
evoluem %ambm dinBmico, mudando constantemente para identificar o #ue o produto necessita
para ser mais apropriado, competitivo e til 6,iste en#uanto perdurar o produto 'pea @=, p @.(
@A: 5 bac(log do produto lista todas as caracter2sticas, funes, re#uisitos, mel+orias e
correes #ue formam as mudanas #ue devem ser feitas no produto em futuras verses, consistindo
de um grupo de itens com atributos de descrio, ordem e estimativa Oeralmente, esses itens so
ordenados por valor, risco, prioridade e necessidade 5s itens no topo da lista do bac(log do produto
determinam as atividades de desenvolvimento mais imediatas Vuanto maior sua posio no topo da
lista, mais o item deve ser considerado e mais consenso e,iste em relao a ele e ao seu valor para o
produto 'pea @=, p @.(
@A= "ma vez #ue os itens do bac(log do produto de ordem mais alta devem ser os primeiros a
serem implementados, eles devem ser mais claros e detal+ados #ue os itens de ordem mais bai,a,
possibilitando estimativas mais precisas 5s itens do bac(log do produto #ue iro ocupar o
desenvolvimento na pr,ima sprint so mais refinados, tendo sido decompostos de modo #ue todos os
seus componentes possam ser IprontosJ dentro da sprint seguinte 5s itens do bac(log do produto #ue
podem ser implementados pela e#uipe de desenvolvimento so considerados como Idispon2veisJ ou
Ie,ecutveisJ para seleo durante a reunio de plane)amento 'pea @=, p @.(
13
@@A A preparao do bac(log do produto 'grooming( o ato de adicionar detal+es, estimar e
ordenar ou priorizar seus itens Q um processo cont2nuo e,ercido em tempo parcial e de forma
colaborativa entre o + e a e#uipe de desenvolvimento /ontudo, somente a e#uipe de
desenvolvimento, responsvel pela efetiva construo do produto, #ue tem a atribuio de realizar
as estimativas 'pea @=, p @1(
-ac(log da sprint
@@@ 5 bac(log da sprint um con)unto de itens do bac(log do produto selecionados para a
sprint, adicionado do plano para entrega do incremento do produto a ser utilizado, intencionando o
alcance do ob)etivo da sprint Q a previso da e#uipe de desenvolvimento sobre #ual funcionalidade
estar no pr,imo incremento e do trabal+o necessrio para entreg0la 'pea @=, p @1(
&ncremento
@@! 5 incremento a soma de todos os itens do bac(log do produto conclu2dos durante a
sprint, acrescido de todos os outros das sprints anteriores Ao final da sprint, um novo incremento
deve estar IprontoJ, o #ue significa #ue deve estar na condio utilizvel e atender a definio de
IprontoJ do time Scrum 6ste deve estar na condio utilizvel independentemente do +roduct wner
decidir por liber0lo ou no 'pea @=, p @3(
@@. Alm dos papis, eventos e artefatos do Scrum, o conceito de IprontoJ tambm
e,plorado no Ouia do Scrum
@@1 Vuando o item do bac(log do produto ou um incremento descrito como IprontoJ, todos
devem entender o #ue o IprontoJ significa 6mbora possa variar significativamente entre diversos
times Scrum, os integrantes devem ter um entendimento compartil+ado do #ue significa o trabal+o
estar completo, assegurando a transpar-ncia 6ssa a IDefinio de ProntoJ para o time, usada para
avaliar se o incremento do produto est, de fato, conclu2do 'pea @=, p @1(
@@3 A mesma definio deve orientar a e#uipe de desenvolvimento na avaliao de #uantos
itens do bac(log do produto podem ser selecionados na reunio de plane)amento da sprint 'pea @=,
p @1(
@@4 M medida #ue times Scrum amadurecem, esperado #ue a definio de IprontoJ se)a
e,pandida para incluir critrios mais rigorosos #ue assegurem maior #ualidade ao produto
@@9 Por fim, cumpre registrar #ue, de acordo com o Ouia do Scrum, seus papeis, artefatos,
eventos e regras so imutveis e, embora se)a poss2vel implementar somente partes da metodologia, o
resultado no Scrum, #ue e,iste somente na sua totalidade, funcionando bem como um container
para outras tcnicas, metodologias e prticas 'pea @=, p @4(
#.2.2 e4treme +rogramming 94+:
@@: 6m @==4, Sent ?ecR, um dos signatrios do ;anifesto Ngil, se tornou gerente responsvel
pelo 0hr,sler 0omprehensi"e 0ompensation S,stem, pro)eto de desenvolvimento para substituio
dos softwares #ue processavam a fol+a de pagamento da empresa 0hr,sler, tambm con+ecido como
/. A partir de ento, Sent comeou a refinar os mtodos #ue utilizava para desenvolver programas e
passou a escrever o primeiro livro sobre a metodologia batizada por ele como e4treme
+rogramming, mais con+ecida como 4+
@@= 5 software #ue foi desenvolvido era um estudo de caso de adoo de programao
orientada por ob)etos, e Sent ?ecR foi inicialmente convidado a fazer parte da e#uipe com ob)etivo de
realizar mel+orias de desempen+o na aplicao 8o entanto, ao assumir a liderana da e#uipe,
introduziu prticas nas #uais acreditava #ue trariam mel+oria para o software em desenvolvimento
Assim nasceu o 4+, como uma compilao das mel+ores prticas utilizadas no pro)eto /.
@!A Atualmente, vrias dessas prticas evolu2ram e o 4+ ) pode ser adotado em situaes
#ue no guardam muita relao com o conte,to no #ual surgiu Ao contrrio de Scrum, #ue foca
principalmente nas prticas relacionadas 7 ger-ncia, 4+ d mais ateno 7s tarefas de programao
em si
@!@ Apesar de ser considerado um con)unto de mel+ores prticas, 4+ traz, na sua proposta,
tambm valores e princ2pios 5s valores so critrios gerais e abstratos, en#uanto as prticas so
14
claras e concretas 5s princ2pios, por sua vez, fazem a ligao entre os valores e as prticas A seguir,
os valores, princ2pios e prticas so apresentados sucintamente
Walores
@!! Walor @E comunicao
@!!@ 6n#uanto os clientes t-m viso dos problemas #ue dese)am solucionar, os
desenvolvedores dominam as tcnicas #ue influenciam a forma de resolver o problema apresentado
pelo cliente 5 resultado do software to bom #uanto a capacidade de ambos se comunicarem
@!!! 6,istem diversas formas para se estabelecer essa comunicao, mas algumas se
apresentam como mel+ores do #ue outras Dilogos so mais eficazes #ue videoconfer-ncias #ue, por
sua vez, so mel+ores #ue telefonemas, sendo esses mais e,pressivos #ue emails e assim
sucessivamente 5 dilogo presencial evita #ue problemas de m compreenso e ambiguidades
comprometam negativamente o produto final
@!. Walor !E coragem
@!.@ Durante o desenvolvimento de um software, natural #ue as funcionalidades
inicialmente imaginadas pelo cliente e desenvolvidas pela e#uipe sofram alteraes, se)a por#ue os
clientes imaginaram outras formas de resolver o problema, se)a por#ue o time descobriu novas
solues Q um aprendizado natural, mas #ue, em metodologias tradicionais, envolve uma tend-ncia
da e#uipe se proteger de mudanas, buscando garantias de #ue os rumos manten+am0se inalterados
@!.! 6ste valor do 4+ preza pela proteo A e#uipe estabelece mecanismos para evitar #ue
uma alterao futura se)a um transtorno ou represente um risco grande ao pro)eto Algumas prticas
foram propostas com esse fim
@!1 Walor .E feedbac(
@!1@ Q sabido #ue, #uanto mais cedo um problema descoberto, menos pre)u2zos ele pode
causar e maiores so as c+ances de resolv-0lo de forma barata em um pro)eto de desenvolvimento de
software Por isso, 4+ incentiva #ue se encurte ao m,imo a defasagem de tempo entre o momento em
#ue uma ao e,ecutada e #ue o seu resultado observado Assim, e,iste um incentivo ao constante
feedbac(, mesmo #ue, pra isso, as entregas de novas funcionalidades se)am realizadas no menor
prazo poss2vel
@!3 Walor 1E respeito
@!3@ 5utro valor do 4+ o respeito, no apenas pelos outros membros da e#uipe, mas
tambm respeito a si prprio Alteraes #ue comprometam negativamente o trabal+o de outros
desenvolvedores no devem ser feitas 6 cada desenvolvedor deve se comprometer entregando o
produto com a maior #ualidade poss2vel
@!4 Walor 3E simplicidade
@!4@ $implicidade guarda relao com a m,ima difundida pela %oPota a partir da dcada
de @=3AE no se deve produzir mais #ue o necessrio /oncluiu0se #ue o Princ2pio de Pareto tambm
se aplica ao desenvolvimento de software, onde !AX das funcionalidades costumam gerar :AX ou
mais do benef2cio esperado Q um grande desperd2cio entregar funcionalidades #ue no agregam
valor ao negcio
Princ2pios
@!9 5 princ2pio da auto0semel+ana sugere #ue, #uando e#uipes 4+ encontrarem solues
#ue funcionem em um conte,to, tambm devem procurar adot0las em outras situaes, mesmo #ue
em escalas diferentes 5 princ2pio do benef2cio mtuo, por sua vez, prega #ue prticas #ue no
beneficiem todos os envolvidos so capazes de destruir relacionamentos e criar mais dificuldades
ainda nos pro)etos
@!: 5utro ponto a assuno de #ue, em se tratando de software, diferentes abordagens para
um mesmo problema podem implicar em enormes diferenas no tempo e custo de implementao da
soluo 5 princ2pio da diversidade a)uda a complementar as solues e torn0las mais ricas
1N
@!= Vuando duas abordagens para resolver um problema parecerem e#uivalentes,
recomenda0se testar as duas e no ter medo de errar 5 princ2pio da fal+a preceitua #ue com os erros
adv-m novos con+ecimentos
@.A Por outro lado, o princ2pio da economia estabelece #ue, ao se desenvolver software,
importante implementar as funcionalidades #ue puderem gerar maior retorno financeiro o mais cedo
poss2vel Ao mesmo tempo, o princ2pio da fluidez estabelece #ue, ao invs de impor obstculos, por
meio de etapas bem definidas, deve0se permitir #ue o desenvolvedor aprenda sobre um re#uisito e
avance rapidamente para a sua implementao Para isso, ele far um pouco de anlise, de design, de
teste, de implementao, e voltar a fazer um pouco mais de anlise, teste, design, etc Por seu turno,
o princ2pio da mel+oria preceitua #ue, no se deve buscar a perfeio em cada uma dessas etapas,
mas sim aperfeioar esses e outros aspectos dos pro)etos, em um processo de mel+oria cont2nua
@.@ 5 princ2pio da oportunidade considera #ue problemas eventualmente encontrados devem
ser vistos como oportunidades de aprendizado e mudana, levando a atitudes mais proveitosas para
todos os envolvidos 6rrar algo natural em #ual#uer pro)eto e ocorre de tempos em tempos 6rros
no devem ser temidos, a abrang-ncia dos mesmos e o tempo necessrio para descobri0los #ue deve
ser uma preocupao Vuando os erros so descobertos rapidamente e abrangem um escopo pe#ueno
do trabal+o, solucion0los torna0se mais fcil Por isso, segundo o princ2pio dos Ipassos de beb-J ou
pe#uenos passos, mel+or avanar um pouco de cada vez, ao invs de tentar grandes passos sem
validar suas conse#u-ncias %odos esses princ2pios conduzem ao princ2pio da #ualidade, #ue deve ser
o foco durante todo o pro)eto de desenvolvimento do software 6,iste uma crena de #ue alta
#ualidade significa gastos mais elevados 8o + dvidas de #ue #ualidade ten+a preo, mas a falta
dela tem um preo ainda maior
@.! Ainda com foco na #ualidade, o princ2pio da redundBncia apresenta0se como outra
maneira de garanti0la 5s problemas dif2ceis e cr2ticos em desenvolvimento de software devem ser
resolvidos de vrias formas diferentes ;esmo #ue uma soluo fal+e completamente, as outras iro
prevenir um desastre 5 custo da redundBncia pago pela economia de no ter um desastre 5
princ2pio da refle,o recomenda #ue as e#uipes no apenas faam seu trabal+o, mas tambm pensem
sobre como esto trabal+ando e por #ue motivos esto0no fazendo Devem analisar o por#u- de terem
resultado em sucesso ou fracasso 8o devem tentar esconder seus erros, mas e,p*0los e aprender
com eles
@.. Finalmente, o princ2pio da responsabilidade define #ue esta no pode ser atribu2da, s
pode ser aceita Vuando uma responsabilidade atribu2da a um indiv2duo, somente ele pode decidir
se a aceita ou no
Prticas
@.1 6m 4+, as prticas distinguem0se em dois gruposE primrias e corolrias As primeiras
podem ser adotadas imediatamente, de forma segura, para mel+orar o esforo de desenvolvimento de
software Por sua vez, as prticas corolrias so mais dif2ceis de serem implementadas antes de se
adotarem as prticas primrias Assim, devem ser usadas com maior cautela e com segurana de #ue
a e#uipe e o ambiente encontram0se maduros para tal
@.3 $o prticas primriasE Ambiente &nformativo, -uild de Dez ;inutos, /iclo $emanal,
/iclo %rimestral, Desenvolvimento 5rientado a %estes, Design &ncremental, 6#uipe &ntegral, Folga,
Gistrias, &ntegrao /ont2nua, Programao em Par, $entar0se <unto e %rabal+o 6nergizado
@.4 $o prticas corolriasE Anlise da >aiz do Problema, ?ase de /digo "nificada, /digo
/oletivo, /digo e %estes, /ontinuidade da 6#uipe, /ontrato de 6scopo 8egocivel, 6nvolvimento do
/liente >eal, 6#uipes #ue 6ncol+em, &mplantao Diria, &mplantao &ncremental e Pagar Por "so
#.2.# 7anban
@.9 7anban uma palavra )aponesa e significa Icarto visualJ 6ssa palavra utilizada para
descrever o sistema #ue a empresa %oPota utiliza desde a dcada de @=3A para controlar a lin+a de
produo de seus ve2culos /omo mencionado anteriormente 'item 3@(, o $istema de Produo %oPota
ob)etiva aumentar a efici-ncia da produo pela eliminao cont2nua de desperd2cios
16
@.: A metodologia 7anban para desenvolvimento de software foi proposta por David <
Anderson e define um framewor( para mel+oria incremental de processos e sistemas em
organizaes A adoo do 7anban ancorada na filosofia de #ue, para aperfeioar um processo,
deve0se comear com o #ue se est fazendo agora, concordar em buscar mudanas incrementais e
evolucionrias, alm de respeitar o processo atual, com seus papeis, responsabilidades e cargos
Destaca0se tambm a necessidade de fomentar a postura de liderana em todos os n2veis da
organizao
@.= A metodologia no define um con)unto espec2fico de passos ou de funes #ue deve ser
seguido no processo de desenvolvimento A adoo de um sistema de aperfeioamento baseado na
metodologia comea com a organizao dos passos e processos ) utilizados, para posterior est2mulo
7 mel+oria cont2nua
@1A 5 aperfeioamento do sistema obtido por meio da mel+oria cont2nua e incremental no
processo ;udanas radicais no so bem vindas, pois apesar de parecerem mais efetivas, elas t-m
probabilidade de erro maior por#ue a organizao tende a resistir A idia estimular pe#uenos
incrementos no processo a fim de se alcanar grandes mel+orias no sistema
@1@ >espeitar o processo corrente, os papeis, as responsabilidades e os t2tulos da organizao
dissipa o medo inicial de adoo de uma nova forma de trabal+o, e a iniciativa de implantao da
metodologia se estabelece
@1! 5 7anban uma metodologia para impulsionar mudana, mas pouco prescritivo, o #ue
o diferencia de mtodos como 4+ e Scrum 8o se define, de antemo, como trabal+ar ou #uais
papis devem ser adotados pela organizao /onforme declarado por Andersen, Io design do sistema
7anban um processo de pensamentoF no uma cpia ou modelo de implementao de processoJ
%ambm no substituto para adoo de Scrum ou 4+ A adoo de Scrum pode ser utilizada como
ponto de partida para a utilizao de 7anban, e este pode ser um catalisador da mel+oria do
processo adotado
@1. %endo como base esses valores, a adoo de 7anban contempla as seguintes prticasE
Wisualizar o trabal+o em andamento
@11 A visualizao do trabal+o em andamento tem como ob)etivos manter o foco no ItodoJ,
estimular a transpar-ncia no progresso das atividades e identificar desperd2cios
@13 Para alcanar tais ob)etivos, deve0se entender o #ue est sendo feito atualmenteF resistir
7 tentao de realizar mudanas inicialmenteF mapear o flu,o de trabal+o, identificando estgios e o
tempo #ue se espera entre elesF e criar um #uadro 'eletr*nico ou f2sico( com uma raia para cada
estgio
Uimitar o trabal+o em progresso
@14 5 ob)etivo dessa prtica identificar gargalos no flu,o, aumentando a produtividade
8esse ponto, faz0se necessrio esclarecer os seguintes conceitosE
@14@ sistema (anban 'R minsculo(E sistema de aperfeioamento de processos de trabal+o
baseado na metodologia 7anban 'R maisculo(F
@14! tempo de cicloE tempo #ue um item leva para passar pelo sistema (anban 6,emploE
#uantas semanas uma +istria de usurio leva para ser entregue desde #ue foi identificadaF
@14. ;or( In +rogress ';I+(E total de trabal+o em progresso no sistema (anban 6,emploE
#uantidade de +istrias de usurio #ue esto atualmente em progressoF
@141 produo 'throughput(E mdia do nmero de itens produzidos em um determinado
per2odo de tempo 6,emploE duas +istrias produzidas por semanaF
@143 tempo mdio de cicloE razo entre total de ;I+ e produo ';I+Cproduo( Para
reduzir o tempo mdio, pode0se aumentar a produo ou diminuir o ;I+ Aumentar a produtividade
da e#uipe no o mais fcil, e por isso limitar o ;I+ aparece como soluo para diminuir o tempo
mdio
@19 A definio do ;I+ de cada estgio deve seguir o bom senso e as particularidades da
e#uipe, mas cinco podem ser usados como ponto de partida 5s limites iniciais so apenas palpites
1H
#ue so dados em momentos de pouca informao M medida #ue se obtm informaes sobre o
sistema e #ue a forma de trabal+o aprimorada, os limites so a)ustados
@1: Para evitar gargalos, o taman+o dos itens tambm considerado, pois itens grandes
blo#ueiam recursos por muito tempo, en#uanto itens pe#uenos fluem mais rapidamente pelo sistema
Vuebrar +istrias de usurios em partes pe#uenas L Im2nimo de funcionalidade vendvelJ L re#uer
+abilidade
6,plicitar as pol2ticas #ue esto sendo seguidas
@1= A importBncia #ue se d 7 #ualidade vem do alto custo de encontrar e corrigir defeitos
em um item depois de sua entrega
@3A As pol2ticas so representadas por padres e listas de verificao para completar uma
tarefa
@3@ Para dei,ar e,pl2citas, as pol2ticas so acrescentadas ao #uadro, observando #ue
estgios podem ser inteiramente dedicados 7 garantia da #ualidade
@3! 5 ob)etivo final dessa prtica a mel+oria na #ualidade do produto
;edir e gerenciar o flu,o
@3. 5 sistema de entrega de software tem capacidade limitada Pressionar alm da
capacidade tem como conse#u-ncia a #ueda da #ualidade
@31 6stimativas de capacidade realizadas no in2cio de um pro)eto so palpites baseados em
pro)etos anteriores 6m um sistema (anban, planos so usados como guias e no como critrio de
sucesso
@33 Para obter um sistema de entrega estvel e previs2vel e suportar a tomada de deciso a
respeito de prazos, depend-ncias, pessoal e escopo, a medio do progresso importante desde o
in2cio Porm, toda medio realizada atrelada a um ob)etivo para evitar medies desnecessrias
@34 $o vrios os tipos de medies #ue podem ocorrer, mas a maioria deles diz respeito 7
#uantidade de trabal+o realizado ou #ue falta ser realizado, tempo de durao do ciclo, 2ndice de
defeitos do produto e itens blo#ueados em estgios no sistema Orficos com as medies so
e,postos )unto ao #uadro
@39 A fila de entrada dos itens a serem tratados deve estar sempre ordenada de acordo com a
prioridade, a fim de #ue as pessoas possam pu,ar os itens #ue este)am no topo Para fazer a
priorizao, so levados em considerao diversos fatoresE riscos e incertezasF necessidades bsicas,
como infraestruturaF manuteno de taman+o dos itens e#uilibrados para um flu,o constanteF tipos de
+istria tambm e#uilibrados, para manuteno do flu,o de entrega de valorF e depend-ncias entre os
itens Definir um item como prioritrio significa abrir mo de priorizar outro As escol+as devem ser
conscientes
@3: Para buscar a mel+oria do sistema, a anlise se apia em filtros de deciso 5s filtros
a)udam a manter o foco na mel+oria do flu,o como um todo e no em atividades individuais
&ncentivar a mel+oria cont2nua
@3= A adoo das prticas anteriores ) permite a identificao de oportunidades de
aperfeioamento, mas o 7anban atinge processo cont2nuo de mel+oria com a adoo de eventos de
retrospectiva de forma cadenciada e regular /om as reunies de retrospectiva, o time concentra0se
no flu,o e identifica oportunidades de mudanas estruturais maiores
@4A 8a Figura @, observa0se imagem de um #uadro f2sico e,tra2do do livro I7anban em @A
passosJ 5 sistema apresentado utilizado para aperfeioamento de um processo de desenvolvimento
de software 5s estgios identificados esto dispostos nas raiasE Inbox, Specification, /ead, for
De"elopment, De"elopment, 0ode /e"iew, 2este 1ocall,, 2est on +re+roduction, /ead, for /elease
5s nmeros em vermel+o, logo abai,o do nome do estgio, representam o limite de ;I+ para a#uele
estgio 8a parte abai,o do #uadro, esto as pol2ticas de cada estgio 5s itens esto distribu2dos em
1O
cartes pelas raias Assim, os grficos acima do #uadro dei,am transparentes as medies realizadas
Figura @E 6,emplo de #uadro (anban para processo de desenvolvimento de software
@4@ 5 livro 7anban, de David < Anderson, descreve a abordagem 7anban para sistemas de
aperfeioamento de processos de desenvolvimento de software
#.#. 0omparao entre metodologias 3geis e metodologias tradicionais
@4! /omparando0se as metodologias tradicionais com a ess-ncia #ue fundamenta os mtodos
geis, poss2vel destacar #uais as diferenas e semel+anas entre as duas metodologias
Processo adaptativo , processo preditivo
@4. A maioria das metodologias tradicionais se apresenta como processos preditivos, onde
vrias atividades, tarefas, papis e artefatos so definidos Apesar de serem vendidas como processos
#ue devem ser adaptados, identificar #uais desses passos so dispensveis dentro de um determinado
pro)eto #uase sempre se mostra uma tarefa comple,a
@41 5s mtodos geis, por outro lado, apresentam0se como ferramentas e mtodos
adaptativos, com poucos procedimentos e papeis, reforando seu foco em mel+ores prticas,
princ2pios e valores Para #ue um pro)eto adote uma metodologia gil, necessrio trazer e adaptar
os valores apresentados para o conte,to do pro)eto Dessa maneira, en#uanto as metodologias
tradicionais so c+amadas de preditivas, as geis so consideradas adaptativas
/omunicao direta
@43 As metodologias tradicionais so tambm c+amadas de pesadas ou orientadas 7
documentao Alm de detal+arem as atividades #ue se deve e,ecutar durante o desenvolvimento do
software, tambm incentivam a confeco de nmero considervel de documentos, como modelos,
diagramas e especificaes Desta forma, a principal maneira de comunicao entre as pessoas
baseada em documentos formais
@44 6ssa abordagem no dispensada pelas metodologias geis, mas + uma valorizao
maior na interao direta entre as pessoas de uma e#uipe a fim de mel+orar a transmisso e
disseminao de con+ecimento entre os indiv2duos
1K
Aceitao da mudana
@49 5s mtodos geis introduziram no desenvolvimento de software alguns recursos #ue
permitem uma maior liberdade para e,perimentao Ao invs de e,igir do cliente #ue ele saiba
e,atamente #ual o comportamento ideal do software a ser desenvolvido logo no in2cio, como no
modelo cascata, mecanismos foram estabelecidos para #ue suas funcionalidades se)am revistas, caso
se descubra uma maneira mais ade#uada para constru20lo, assemel+ando0se, em certa medida, ao
modelo em espiral 5 processo de e,perimentao e adaptao incentivado pelos mtodos geis tende
a produzir programas mais ade#uados 7s necessidades dos usurios
&ncentivo a ciclos curtos e entregas constantes
@4: Apesar de terem sido propostos como iterativos e incrementais, as metodologias baseadas
no processo "nificado '*+( nem sempre atingiram tal ob)etivo
@4= Por outro lado, os mtodos geis sugerem ciclos de desenvolvimento bastante curtos,
#uase nunca superiores a um m-s, incentivando ao m,imo #ue softwares se)am desenvolvidos de
forma iterativa e incremental 5s ciclos curtos tambm possibilitam feedbac( constante, o #ue reflete
em maior #ualidade para o processo e para o produto
@9A Ainda com ob)etivo de e,perimentar e obter feedbac(, os mtodos geis ressaltam a
importBncia de liberar o software em ambiente de produo o mais rpido poss2vel, de prefer-ncia ao
final de cada ciclo de desenvolvimento, mesmo #ue poucas funcionalidades ten+am sido
implementadas A certeza de #ue a evoluo do sistema est acontecendo de maneira ade#uada s
constatada com o retorno positivo dos usurios reais do produto
<. s "alores 3geis e os princ=pios da Administrao +>blica
@9@ A ess-ncia dos mtodos geis para desenvolvimento de software baseia0se nos valores
fundamentais contidos no ;anifesto Ngil /onfrontando0se esses valores com os princ2pios da
Administrao Pblica consignados em dispositivos legais, a e,emplo da /onstituio Federal e da
Uei de Uicitaes e /ontratos, poss2vel avaliar o alin+amento da ess-ncia gil com o ordenamento
)ur2dico vigente sob a perspectiva da terceirizao pelos rgos pblicos federais, ob)eto principal
desta fiscalizao &mporta observar #ue a interpretao desses valores sub)etiva, e #ue a e,posta a
seguir corresponde 7 tica de controle desta unidade tcnica
&ndiv2duos e interao entre eles, mais #ue processos e ferramentas
@9@@ A maior valorizao de Iindiv2duos e interao entre elesJ em detrimento de Iprocessos
e ferramentasJ constitui pilar basilar das e#uipes de desenvolvimento gil /ontudo, pode entrar em
atrito com o princ2pio da efici-ncia por possibilitar #ue os processos da instituio possam ser
relegados Adicionalmente, uma vez #ue o princ2pio em ep2grafe valoriza as pessoas, a substituio de
membros da e#uipe durante a e,ecuo de um pro)eto contrasta com o princ2pio da efici-ncia, +a)a
vista #ue pode acarretar pre)u2zos 7 produtividade da e#uipe gil
@9@! Alm disso, o desta#ue para os indiv2duos e suas interaes pode contribuir para a
construo de uma relao de pessoalidade entre os funcionrios da contratada e os gestores da
instituio contratante, prtica condenada pelo %ribunal $uperior do %rabal+o '%$%( em seu
6nunciado ..@
Software em funcionamento, mais #ue documentao abrangente
@9@. A maior valorizao de Isoftware em funcionamentoJ em detrimento de Idocumentao
abrangenteJ, embora possa vir ao encontro do princ2pio da efici-ncia, possibilitando a incorporao,
de forma mais clere, de sistemas informatizados necessrios 7 misso da Administrao Pblica,
parado,almente tambm o fere ;enosprezar a ade#uada documentao do software contratado pode
ocasionar problemas para a sua manutenibilidade e, por conse#u-ncia, a continuidade de
seufuncionamento de modo ade#uado
@9@1 Para mitigar esse risco, um con)unto m2nimo de artefatos L entre eles documentos
essenciais 7 sustentao dos softwares L deve ser e,igido no instrumento convocatrio Para au,iliar
a tarefa de definio dos artefatos #ue devem acompan+ar o sistema entregue pela contratada a cada
20
iterao, a instituio pode utilizar sua ;etodologia de Desenvolvimento de $istemas ';D$( ou seu
processo de software, adaptado e constru2do segundo sua realidade espec2fica
/olaborao com o cliente, mais #ue negociao de contratos
@9@3 A maior valorizao da Icolaborao com o clienteJ em pre)u2zo da Inegociao de
contratosJ, em primeira anlise, entra em atrito com o princ2pio da vinculao ao instrumento
convocatrio, uma vez #ue pode fazer com #ue a contratada e,ecute servios no cobertos pelo
contrato, ocasionando enri#uecimento sem causa da Administrao 6m contrataes pblicas,
imperativo #ue essa prtica se)a abolida
>esponder a mudanas, mais #ue seguir um plano
@9@4 A valorizao de Iresponder a mudanasJ em detrimento de Iseguir um planoJ
contrasta, de imediato, com o princ2pio fundamental do plane)amento, o #ual estampado no inciso &
do art 4Y do Decreto0Uei !AAC@=49, e pode ser conflitante com o princ2pio da economicidade,
insculpido no art 9A da /arta ;agna de @=::
@9@9 6m tese, fere o princ2pio do plane)amento por permitir #ue a tarefa de desenvolvimento
de software se afaste das diretrizes e metas inicialmente estipuladas ou, at mesmo, em e,tremada
circunstBncia, a elaborao do plane)amento se)a desprezada Adicionalmente, mudanas constantes
podem revelar esforo de plane)amento inade#uado para a definio dos re#uisitos do software
contratado
@9@: Por sua vez, a maior valorizao da resposta a mudanas ope0se ao princ2pio da
economicidade por e,igir da empresa contratada retrabal+o para o a)uste 7s mudanas, podendo
acarretar novos desembolsos ao errio
@9@= 6ntretanto, o valor gil em ep2grafe tambm vai ao encontro do princ2pio constitucional
da efici-ncia ao permitir, por e,emplo, a incorporao de novos re#uisitos oriundos de necessidades
prementes no software em desenvolvimento
@9! 6mbora em primeira anlise possa transparecer #ue a utilizao de mtodos geis em
contrataes pblicas para desenvolvimento de software se)a impossibilitada pelo conflito e,istente
entre os seus valores e os princ2pios da Administrao Pblica, a anlise dos editais e contratos das
instituies pblicas federais visitadas demonstra #ue, na prtica, poss2vel alin+ar a sua utilizao
aos preceitos legais #ue regem a esfera pblica
?. 2erceiri'ao de desen"ol"imento de software com m@todos 3geis nas institui%es da
Administrao +>blica 5ederal "isitadas
@9. A e#uipe de fiscalizao visitou cinco rgos #ue possu2am contratos de desenvolvimento
de software utilizando mtodos geis para sua construo, consistindo no ob)eto de interesse para o
presente levantamento >essalte0se #ue das oito instituies inicialmente selecionadas, apenas cinco
possu2am contratos de interesse
@91 A seguir, so apresentados relatos acerca das contrataes analisadas #uanto a #uestes
pertinentes 7 fiscalizao, como mtrica utilizada, forma de gerir as demandas e a e,ecuo dos
servios e n2veis de servio estabelecidos 6m adio, relatado o motivo pelo #ual algumas das
instituies visitadas no apresentaram interesse ao levantamento
?.1.&iso geral dos contratos de terceiri'ao
@93 Dos rgos visitados #ue possu2am ob)eto de interesse para a presente fiscalizao, cabe
observar #ue alguns possuem boa estrutura interna de %&, como o %ribunal $uperior do %rabal+o
'%$%(, ?anco /entral do ?rasil '?acen( e $upremo %ribunal Federal '$%F( 6ssas tr-s instituies
possuem e#uipes de servidores do prprio #uadro #ue atuam no desenvolvimento de software
utilizando mtodos geis
@94 Por outro lado, o &nstituto do Patrim*nio Gistrico e Art2stico 8acional '&p+an( possui
grande car-ncia de profissionais de %& em seu #uadro %odo o desenvolvimento de novos sistemas de
informao e,ecutado por empresas terceirizadas < o &nstituto 8acional de 6studos e Pes#uisas
6ducacionais An2sio %ei,eira '&nep(, sob a perspectiva de pessoal da rea de %&, encontra0se em
situao momentaneamente mais confortvel do #ue o &p+an A rea de %& do &nep, #uando da visita
21
da e#uipe de fiscalizao, contava com cinco servidores do #uadro, alm de trinta e sete profissionais
com /ontratos %emporrios da "nio '/%"( /ontudo, alguns desses profissionais devero dei,ar o
&nstituto no pr,imo ano em virtude do trmino da vig-ncia de seus contratos temporrios de
trabal+o, no +avendo previso de #ue ven+am a ser substitu2dos
%ribunal $uperior do %rabal+o '%$%(
@99 5 %$%, aps ad#uirir e,peri-ncia interna em desenvolvimento de software utilizando
Scrum, publicou, em !A@!, o edital do Prego 6letr*nico @14C!A@!, o #ual teve por ob)eto a
contratao de Goras de $ervio %cnico 'G$%( de desenvolvimento de sistemas para os ambientes do
%ribunal 'pea !A, p @(
@9: 5s servios abarcados pelo ob)eto do prego em comento constitu2ram0se de iniciao de
sustentao de sistema, sustentao programada, sustentao emergencial e implantao, os #uais
deveriam ser cotados separadamente pelas licitantes 'pea !A, p !(
@9= A sustentao programada englobou manutenes evolutivas e corretivas, cu)o modelo de
e,ecuo dos servios foi descrito no Ane,o ! ';odelo de $ustentao de $istemas do %$%( do termo
de refer-ncia do edital 'pea !A, p 1=04.( 6sse modelo baseou0se fundamentalmente no framewor(
Scrum 6ntretanto, o %$% incluiu em seu detal+amento diferenciaes do modelo original, tais como
as previstas nos subitens .4 e =@ 'pea !A, p 3A e 34(
@:A $egundo o subitem .4, cada sprint pode permitir o agrupamento de manutenes de
vrios sistemas diferentes /omo conse#u-ncia, um time de desenvolvimento Scrum provavelmente
dever interagir com mais de um +roduct wner '+( e coordenar atividades distintas de sistemas
diversos, o #ue pode trazer inefici-ncia ao processo de desenvolvimento
@:@ 5 subitem =@ define o papel do + e, ao contrrio do preceituado no framewor( Scrum,
prev- #ue este poder ser desempen+ado por mais de uma pessoa 6ssa caracter2stica do modelo
desen+ado pelo %$% pode trazer conflitos na definio da viso do produto, na ger-nciaCpriorizao
dos re#uisitos e na aceitao do produto entregue, acarretando inefici-ncia ao processo
@:! 5 /ontrato @14C!A@!, decorrente do Prego 6letr*nico @14C!A@!, foi celebrado com a
empresa Squadra %ecnologia em Software Utda, em .@C@!C!A@!, ao custo de >Z @39!91A,AA A
empresa deve e,ecutar os servios demandados em suas prprias depend-ncias, sendo #ue,
eventualmente, atividades como reunies de ponto de controle, definio de re#uisitos, entrega e
demonstrao dos produtos das ordens de servio devem ser feitas nas depend-ncias do %$% 'pea !A,
p !4(
@:. Vuando da visita da e#uipe de fiscalizao ao %$%, foi verificado #ue nen+uma ordem de
servio ainda +avia sido emitida %al fato impediu a coleta de informaes acerca da e,peri-ncia do
%$% com a gesto contratual
?anco /entral do ?rasil '?acen(
@:1 5 ?acen, assim como o %$%, inicialmente introduziu os conceitos das metodologias geis
para desenvolvimento de sistemas em suas e#uipes internas 6m !A@!, por meio do Prego 6letr*nico
Demap 9C!A@!, promoveu licitao para a contratao de servios tcnicos de tecnologia da
informao para desenvolvimento, documentao e manuteno de sistemas de informao,
dimensionados por meio de pontos de funo, em regime de fbrica de software 'pea !@, p @(
@:3 5s servios de desenvolvimento e manuteno dos sistemas de informao do ?acen
seguem o Processo de Desenvolvimento Ngil do ?acen 'PD$0Ngil( elaborado pela prpria instituio,
cu)o flu,o de trabal+o apresentado no diagrama constante em documento espec2fico #ue descreve a
metodologia 'pea !9, p .(
@:4 A metodologia concebida pelo ?acen fortemente influenciada pelo Scrum,incorporando
conceitos e prticas desse frameTorR, como product bac(log, +roduct wner e reunies diriasF e
pelo 4+, a e,emplo de simplicidade da soluo implementada, integrao cont2nua, programao em
par, refatorao, desenvolvimento orientado por testes '2est Dri"en De"elopment L 2DD( e
desenvolvimento orientado por testes de aceitao 'Acceptance 2est Dri"en De"elopment L A2DD(
22
@:9 6mbora o PD$0Ngil este)a sendo empregado pela contratada para fornecer os servios
demandados pelo ?acen, observa0se da definio de escopo na verso atualmente utilizada #ue essa
metodologia de desenvolvimento destina0se ao uso interno e, +avendo subcontratao, pode ser
aplicada 7s atividades no subcontratadas e a todos os produtos gerados 'pea !9, p @A, subitem
.!( 6ntretanto, o PD$0Ngil no especifica #uais atividades podem ser ob)eto de subcontratao 6m
adio, os papis nela definidos no vislumbram participao de atores e,ternos ao ?acen 'pea !9,
p @A0@!(
@:: A empresa vencedora do Prego 6letr*nico Demap 9C!A@! foi a Politec %ecnologia da
&nformao $A, #ue celebrou o /ontrato ?acenCDeinf 3A1@!C!A@! em !!C1C!A@!, com vig-ncia
compreendendo o per2odo entre !.C1C!A@! e !!C1C!A@., ao custo de >Z 94A33@@,!A 'pea !@, @1.(
5s servios so prestados nas depend-ncias da contratada, de modo remoto, podendo ser e,ecutados,
a critrio do ?acen, os servios de pro)eto de construo, total ou parcialmente, em suas prprias
depend-ncias em ?ras2lia 'pea !@, p !.(
@:= 6m !!C1C!A@., foi celebrado o primeiro termo aditivo do referido a)uste visando
prorrogar a vig-ncia contratual at !!C1C!A@1 e rea)ustar o valor unitrio do ponto de funo,
elevando o valor estimado da contratao para >Z :A:3!31,1A 'pea !@, p @11(
&nstituto do Patrim*nio Gistrico e Art2stico 8acional '&p+an(
@=A 5 &p+an teve sua primeira e,peri-ncia com mtodos geis por meio do Prego 6letr*nico
@!C!A@@ 6sse certame teve por ob)eto o desenvolvimento do $istema &ntegrado de /on+ecimento e
Oesto '$&/O(, estimado em dois mil pontos de funo 'pea !!, p 304( 8a ocasio, sagrou0se
vencedora a empresa 6OU 6ngen+aria Utda, a #ual celebrou o /ontrato !:C!A@@ em !C@!C!A@@, com
vig-ncia estabelecida at @C=C!A@. e ao custo de >Z ==AAAA,AA 'pea !!, 3=( $egundo o contrato
firmado, os servios constantes de seu ob)eto devem ser e,ecutados nas instalaes da contratada,
sendo #ue algumas reunies de controle inerentes 7 metodologia de gesto do pro)eto do &p+an devem
ocorrer nas depend-ncias do &p+an 'pea !!, p 3!(
@=@ A forma de e,ecuo dos servios, e,posta no subitem 91 do termo de refer-ncia do
citado prego, previu o desenvolvimento do pro)eto em ciclos e a realizao de cerim*nias bem
definidas, assemel+ando0se ao framewor( Scrum 'pea !!, p !=0..(
@=! M poca da visita da e#uipe de fiscalizao ao &p+an, o rgo estava elaborando edital
para a contratao de fbrica de software para o desenvolvimento e manuteno de seus sistemas
'pea !9, 19A031@( $egundo a minuta do termo de refer-ncia, esses servios devem ser e,ecutados em
conformidade com a ;etodologia &p+an de Oesto de Demandas de Desenvolvimento Ngil de
Softwares ';idas L pea !9, p 194( 5 modelo de gesto estabelecido na ;idas baseado no Scrum,
com poucas alteraes 'pea !!, p 4:(
&nstituto 8acional de 6studos e Pes#uisas 6ducacionais An2sio %ei,eira '&nep(
@=. 5 &nep, diferentemente das demais instituies visitadas, atualmente encontra0se em seu
segundo contrato de fbrica de software para desenvolvimento de sistemas com uso de mtodos geis
@=1 5 /ontrato @C!A@@, decorrente do Prego 6letr*nico @@C!A@A, foi a primeira iniciativa do
&nstituto de contratao de desenvolvimento de sistemas de informao com mtodos geis %eve por
ob)eto a contratao de fbrica de software para a prestao de servios tcnicos de tecnologia da
informao, compreendendo desenvolvimento e manuteno de sistemas de informao ao custo de
>Z 4=:1AAA,AA 'pea !., p . e pea !., .:.( 6sses servios deveriam ser e,ecutados segundo a
orientao da ;etodologia de Oesto e Desenvolvimento de $istemas do &nep ';OD$(, a #ual
baseada na combinao de prticas advindas do 4+ e do Scrum 'pea !., p :=(
@=3 A empresa Squadra %ecnologia em Software Utda sagrou0se a vencedora do certame
Porm, segundo relatado na reunio com representantes da rea de %& do &nep, essa e,peri-ncia no
produziu os resultados esperados 5 principal motivo para o fracasso da iniciativa foi a
disponibilizao de e#uipe composta basicamente de analistas )uniores e o seu descon+ecimento em
desenvolvimento de sistemas utilizando mtodos geis Ao final do contrato, a empresa Squadra optou
23
por no renovar a vig-ncia contratual, alegando #ue o preo cotado para o contrato no serviria
para cobrir seus custos
@=4 A segunda e,peri-ncia do &nep, atualmente em e,ecuo, decorre do Prego 6letr*nico
@1C!A@! 'pea !1, @01=:(, realizado em substituio ao contrato resultante do Prego 6letr*nico
@@C!A@A 6sse segundo prego teve como vencedora a empresa /ast &nformtica $A, a #ual
celebrou, em @AC=C!A@!, o /ontrato ..C!A@!, com per2odo de vig-ncia compreendido entre @AC=C!A@!
a =C=C!A@. e ao custo anual de >Z @!AAAAAA,AA 'pea !1, 1==( 5 ob)eto do novo contrato manteve
os mesmos servios abarcados pelo /ontrato @C!A@@ 'pea !1, p .(, tambm devendo ser e,ecutado
nas instalaes do &nep de acordo com a ;OD$ do &nep 'pea !1, p 1A(
@=9 /onforme relatado pelos representantes do &nep em reunio com os membros da e#uipe
desta fiscalizao, esse segundo contrato, aps o per2odo de adaptao da empresa contratualmente
estabelecido em noventa dias, tem sido e,ecutado a contento, atendendo 7s necessidades do &nstituto
$upremo %ribunal Federal '$%F(
@=: &nicialmente, o $%F implantou o desenvolvimento de sistemas utilizando metodologia gil,
baseada no Scrum, em suas e#uipes internas 6m !A@!, lanou o edital do Prego 6letr*nico
:1C!A@!, cu)o ob)eto consistiu na contratao de empresa para prestao de servios de
desenvolvimento gil de solues de software 'pea !3, p !( $agrou0se vencedora do certame a
empresa -asis %ecnologia da &nformao $A, celebrando o /ontrato !9C!A@. em 4C3C!A@., ao custo
anual de >Z !!=3AAA,AA, devendo prestar os servios nas instalaes e com recursos de
infraestrutura tecnolgica do $%F 'pea !3, p 9. e pea !3, p ..(
@== A forma de e,ecuo dos servios definida no item = 'Oerenciamento da /ontratao( do
termo de refer-ncia do edital do Prego 6letr*nico :1C!A@! baseou0se no framewor( Scrum 'pea
!3, p !901!( Vuando realizada a visita ao $%F, o rgo ainda no tin+a iniciado a e,ecuo
contratual, impedindo a e#uipe de fiscalizao de col+er de informaes relativa 7 sua e,peri-ncia
Departamento de &nformtica do $istema Hnico de $ade 'Datasus(
!AA 6m abril de !A@., poca da visita da e#uipe de fiscalizao ao Datasus, verificou0se #ue
o rgo possu2a dois contratos vigentes relativos ao desenvolvimento de sistemas "m deles,
celebrado com a empresa /%&$ %ecnologia $A destinava0se ao levantamento de re#uisitos, en#uanto
o outro, celebrado com a empresa 0ast &nformtica $A, tin+a como ob)etivo a implementao do
sistema especificado pela primeira Vuando necessrio, de acordo com um dos responsveis do rgo
pelo servio de desenvolvimento do Datasus, o segundo contrato era utilizado para o desenvolvimento
integral de sistemas por meio de mtodos geis, embora no +ouvesse previso no instrumento
convocatrio para #ue a empresa assim procedesse Por tal motivo, os contratos e editais originrios
no foram solicitados
!A@ 6m adio, verificou0se #ue, como o contrato com a empresa /%&$ estaria pr,imo do
trmino de sua vig-ncia, o Datasus realizou o Prego 6letr*nico @=C!A@. com o intuito de contratar
empresas especializadas para prestao de servios tcnicos de desenvolvimento e manuteno de
sistemas de informao estimados em @.AAAA pontos de funo e contagem de outros !@AAAA 'pea
!4, p @(
6mpresa ?rasileira de $ervios Gospitalares '6?$6>G(
!A! Vuando a e#uipe de fiscalizao visitou a 6?$6>G, foi apresentada a metodologia
adotada pelo Gospital de /l2nicas de Porto Alegre para sustentao do Aplicativo de Oesto para
Gospitais "niversitrios 'AOG"(, no +avendo tempo +bil para a apresentao da metodologia
utilizada no desenvolvimento de sistemas, ob)eto do presente levantamento Por tal motivo, a e#uipe
de fiscalizao no solicitou maiores informaes acerca dos instrumentos convocatrio e contratual
$ervio Federal de Processamento de Dados '$erpro(
!A. A visita da e#uipe de fiscalizao ao $erpro serviu para coleta de informaes referentes
7 utilizao de mtodos geis pelo lado do fornecedor 5 $erpro desenvolveu o sistema 8ovo $iafi
para a $ecretaria do %esouro 8acional '$%8( utilizando o framewor( Scrum "ma tentativa
24
fracassada usando metodologia tradicional, baseada no *nified +rocess '*+(, antecedeu essa
e,peri-ncia
!A1 8a primeira tentativa, o $erpro basicamente produziu documentaes relativas ao
levantamento de re#uisitos, sem, contudo, entregar o sistema contratado Devido ao fracasso da
metodologia empregada, o $erpro prop*s 7 $%8 a e,ecuo do servio utilizando mtodos geis, o
#ue foi por ela aceito Orande parte dos re#uisitos ) especificados na tentativa anterior foi utilizada
na construo do 8ovo $iafi, diminuindo o esforo de levantamento de re#uisitos e construo do
bac(log do produto
!A3 A seguir, apresentado #uadro #ue sintetiza as informaes acerca das contrataes
identificadas pela e#uipe de fiscalizao
Argo +rego 2ipo do
ob!eto da
contratao
)mpresa
contratada
-ase do
framewor(
de gerBncia
utili'ado
Interessa ao
le"antamento
%$% Prego 6letr*nico
@14C!A@!
Fbrica de
software
Squadra
%ecnologia em
Software Utda
Scrum $im
?acen Prego 6letr*nico
Demap 9C!A@!
Fbrica de
software
Politec %ecnologia
da &nformao $A
Scrum $im
&p+an Prego 6letr*nico
!C!A@@
Pro)eto 6OU 6ngen+aria
Utda
Scrum $im
%> em elaborao Fbrica de
software
8o se aplica Scrum $im
&nep Prego 6letr*nico
@C!A@A
Fbrica de
software
Squadra
%ecnologia em
Software Utda
Scrum $im
Prego 6letr*nico
@1C!A@!
Fbrica de
software
/ast &nformtica
$A
Scrum $im
$%F Prego 6letr*nico
:1C!A@!
Fbrica de
software
?asis %ecnologia
da &nformao $A
Scrum $im
Datasus 8o obtido Fbrica de
software L
levantamento
de re#uisitos
/%&$ %ecnologia
$A
;etodologia
tradicional
8o
8o obtido Fbrica de
software 0
construo
/ast &nformtica
$A
;etodologia
tradicional
8o
Prego 6letr*nico
@=C!A@.
Fbrica de
software
/%&$ %ecnologia
$A
Scrum 8o
6?$6>
G
&nformao no
obtida
Fbrica de
software
&nformao no
obtida
8o obtido 8o
$erpro Dispensa de
licitao
Pro)eto 8o se aplica
'$erpro
fornecedor(
$crum 8o
Vuadro @ L >esumo das contrataes identificadas pela e#uipe de fiscalizao
?.2. $@tricas de tamanho e esforo
!A4 Da anlise dos editais, contratos e e,tratos de contratos obtidos das instituies 'de
interesse a este trabal+o( visitadas 'peas !A a !3(, verifica0se #ue, 7 e,ceo do %$%, todas elas
2N
utilizaram pontos de funo para dimensionar e pagar os servios contratados, conforme apresentado
na tabela seguinte
Argo 0ontrato $@trica Cuantitati"o
Anual
&alor
*nit3rio
9/D:
&alor 2otal
9/D:
%$%
@14C!A@! Goras de servio
tcnico 'G$%(

@A4A 1=,AA @39!91A,AA
!1AAA 1=,AA
1!AA 4!,.:
@.:A 4A,AA
?acen
3A1@!C!A@! Pontos de funo @434A 13=,!9 94A33@@,!A
@Y Aditivo 1::,!1 :A:3!31,1A
&p+an
!:C!A@@ Pontos de funo !AAA 1=3,AA ==AAAA,AA
6m plane)amento Pontos de funo 3AAA 0 0
&nep
@C!A@@ Pontos de funo !AAAA .1=,!A 4=:1AAA,AA
..C!A@! !AAAA 4!3,AA @!3AAAAA,AA
$%F !9C!A@. Pontos de funo 3AAA 13=,AA !!=3AAA,AA
Vuadro ! L ;tricas utilizadas nos contratos das instituies visitadas
!A9 8o edital do Prego 6letr*nico @14C!A@!, o %$% utilizou +oras de servio tcnico 'G$%(
para mensurar o esforo e remunerar a contratada pelos servios prestados, cotando em separado
valores para cada um dos servios estabelecidos no edital, #uais se)am iniciar sustentao de sistema,
sustentao programada, sustentao emergencial e implantao 'pea !A L 6dital %$%, p !01(
?.#. +lane!amento6 gesto de demandas6 aceitao do produto e forma de pagamento
!A: A maior parte dos instrumentos convocatrios analisados contm formas de
plane)amento, gesto de demandas, aceitao do produto e pagamento semel+antes A demanda para
construo do produto precedida pelo plane)amento do produto, o #ual pode ser feito apenas pela
instituio contratante ou em con)unto, entre essa e a empresa contratada Alm do plane)amento do
produto em si, algumas instituies tambm fazem o plane)amento das funcionalidades #ue sero
implementadas no pr,imo ciclo, iterao ou sprint, atividade preceituada no Scrum
!A= A e#uipe de fiscalizao tambm observou #ue as instituies visitadas emitem uma
ordem de servio por ciclo, iterao ou sprint, ou por release de software, sendo mais comum o
primeiro caso
!@A Vuanto 7 aceitao do produto entregue pela contratada, embora no framewor( Scrum
se)a preceituado #ue ocorra na reunio de reviso da sprint, essa prtica no e,ecutada nos
contratos estudados, at mesmo por impedimento normativo, como disciplinado no art 9. da Uei
:444C@==. 8essa ocasio, algumas instituies apenas verificam se os artefatos e,igidos foram
entregues, caracterizando o recebimento provisrio
!@@ Acerca da forma de pagamento da contratada, constatou0se #ue algumas instituies
remuneram os servios de plane)amento #uando realizados, en#uanto outras remuneram apenas os
servios de construo do software
!@! A entrega adiantada e cont2nua de software, conforme postulado nos princ2pios dos
mtodos geis, foi observada em algumas das instituies visitadas Para alcanar esse ob)etivo, elas
paralelizam as atividades de preparao, e,ecuo e +omologao, isto E em um dado per2odo de
tempo, en#uanto a empresa contratada e,ecuta a construo do software em um ciclo, iterao ou
sprint, a contratante prepara os itens do bac(log do produto #ue sero implementados no pr,imo
ciclo e +omologa o produto entregue no ciclo anterior
!@. A forma de plane)amento, gesto de demandas, aceitao do produto e forma de
pagamento pelos servios e,ecutados nos contratos e,aminados so apresentados a seguir
2ribunal Superior do 2rabalho 92S2:
!@1 8o %$%, a e,ecuo do servio de sustentao programada, um dos ob)etos do /ontrato
@14C!A@!, baseada no Scrum, sendo realizada em sprints, cu)o acompan+amento dado pela
26
atualizao de #uadros (anban 'pea !A, p 3A e 4@( Para #ue um sistema do %ribunal possa sofrer
esse tipo de interveno pela empresa contratada, inicialmente ele passa pelo processo de iniciao
da sustentao, no #ual a contratada gera seus respectivos manual de produo e documento de
ar#uitetura 'pea !A, p 3@( A partir desse momento, a sustentao programada no sistema d0se por
meio de sprints
!@3 /ada sprint do servio de sustentao programada precedida por uma $olicitao de
$ustentao Programada, a #ual formalizada por ordem de servio '5$( 5 real ob)etivo desse tipo
de solicitao plane)ar a sprint, gerando como artefato o Plano da Sprint 'pea !A, p 3!( 6sse
artefato contm, entre outros elementos, as +istrias de usurio 'bac(log da sprint( e os respectivos
critrios de aceite, datas de in2cio e fim da sprint e data, +ora e local da reunio de apresentao dos
seus resultados 'pea !A, p 3903:( 5 %$%, a seu critrio, identifica +istrias de usurios essenciais,
#ue devem ser implementadas em cada sprint 'pea !A, p !4( /aso uma dessas +istrias no se)a
entregue ao final da sprint, ela dada como fracassada /ada +istria de usurio medida em pontos
de funo com vistas 7 apurao da produo e da remunerao da contratada 'pea !A, p 3.(
!@4 /om o Plano da Sprint preparado, inicia0se a sustentao programada propriamente
dita, na #ual as funcionalidades especificadas no plane)amento devem ser codificadas, testadas,
documentadas e apresentadas ao %$% 'pea !A, p 3.( 8a apresentao dos produtos, o +roduct
wner, assessorado pela e#uipe tcnica, verifica se todos os produtos previstos na solicitao de
sustentao foram entregues 'pea !A, p 4!( Posteriormente, os produtos entregues so avaliados
pelo %$% com vistas 7 emisso do termo de recebimento definitivo da 5rdem de servio 'pea !A,
p .A(
!@9 As ordens de servio das sprints relativas 7 sustentao programada so remuneradas
conforme o esforo, dado em Goras de $ervio %cnico 'G$%( 5 esforo '6( obtido a partir do
produto do taman+o em pontos de funo da sprint '%( pela produtividade estabelecida pelo %$% '@A
G$%Cponto de funo( para a contratada '6 [ % , P( 'pea !A, p @AA(
!@: Alm da prestao dos servios de desenvolvimento propriamente dito, a contratada
tambm demandada em outras atividades, como recebimento e plane)amento da ordem de servio
!@= 8o recebimento, a contratada deve analisar a 5$ e verificar se as informaes nela
e,pressas so suficientes para a e,ecuo do servio 'pea !A, p !9( 8o plane)amento, a contratada
deve estimar o esforo, prazo e custo necessrios para a concluso da 5$ 'pea !A, p ==( 5 esforo
despendido pela contratada em ambos os servios no ob)eto de remunerao 'pea !A, p .!(
!!A 8o /ontrato 3A1@!C!A@! do ?acen, os servios so demandados por 5rdens de servio
cu)o flu,o apresentado em figura constante na pgina !9 do edital do prego eletr*nico Demap
9C!A@! 'pea !@( $egundo o flu,o estabelecido, o ?anco cria e especifica o problema a ser resolvido
na ordem de servio e a envia para a contratada, a #uem cabe a elaborao de proposta de soluo
6stando de acordo com a proposta da contratada, o ?acen autoriza a e,ecuo da 5$
!!@ As ordens de servio emitidas para o desenvolvimento de sistemas identificam #ual o
Processo ou metodologia deve ser usado pela contratada 'pea !A, p !=( /onforme demonstram as
5$ ) emitidas no Bmbito do /ontrato 3A1@!C!A@!, o processo utilizado o Processo de
Desenvolvimento Ngil do ?acen 'PD$0NgilF pea !9, p 33014=(
!!! A contratada dever entregar os produtos resultantes de uma ordem de servio somente
aps a e,ecuo completa de todos os servios nela re#ueridos /ontudo, a critrio do ?acen,
podero ser acordadas entregas parciais de servios para uma 5$ de pro)eto de construo "ma
entrega parcial em servios de desenvolvimento e manuteno constitui0se de uma release de cdigo,
)untamente com a documentao associada, #ue implementa um con)unto de funcionalidades
#uantificveis e #ue ten+am significado para o solicitante do servio 'pea !@, p 1A(
!!. A remunerao da contratada observa o estabelecido no documento Distribuio de
6sforo por Disciplina 'pea !9, p 3!033( Vuanto ao PD$0Ngil, ao elaborar o levantamento de
re#uisitos e aps t-0lo aprovado pelo ?acen, a contratada recebe @1,.93X do valor correspondente
2H
aos pontos de funo estimados para a respectiva ordem de servio A fase de levantamento de
re#uisitos compreende a elaborao do modelo de negcio, documento de viso, prottipo de
interface, especificao de teste de aceitao e glossrio 'pea !9, p 31(
!!1 Aps a fase de implementao L a #ual abrange a elaborao de documento de
ar#uitetura, modelo de dados, classes de testes de unidade, cdigo fonte, instrumentao de testes,
script de teste, relatrio de teste, a)uda do sistema, roteiro de operao e manual de usurio L a
contratada faz )us aos :3,4!3X restantes, a depender do aceite definitivo dos produtos gerados 'pea
!9, p 31(
!!3 A fase de validao da ordem de servio divide0se em provisria e definitiva A 5$
provisoriamente validada #uando for confirmada a entrega dos servios prestados /aso se)a
re)eitada, a 5$ devolvida 7 contratada para os a)ustes necessrios, repetindo0se esse procedimento
at ocorrer a validao provisria 'pea !@, p 1!(
!!4 "ma vez validada provisoriamente, a ordem de servio passa pela validao definitiva, a
#ual compreende a anlise detal+ada dos produtos e dos resultados gerados para os servios
re#ueridos na 5$ e a verificao do atendimento aos critrios de aceitao nela estabelecidos e
segundo os padres e processos de trabal+o do ?acen 'pea !@, p 1!(
!!9 8a validao definitiva, a ordem de servio pode ser validada, validada com restries
ou re)eitada 'pea !@, p 1!( Q validada com restries #uando for identificada alguma ocorr-ncia
em um ou mais produtos ou resultados, mas #ue permitam a validao da 5$ pelo ?acen 5rdens de
servios validadas com restries so devolvidas 7 contratada para a)ustes, concedendo0se prazo de
at 3AX do originalmente previsto para sua e,ecuo Por sua vez, a ordem de servio re)eitada
devolvida 7 contratada para correo, +avendo tantas devolues e entregas #uantas necessrias at
a validao definitiva do servio A seu critrio, o ?acen pode prorrogar o prazo de concluso da
ordem de servio re)eitada, uma nica vez, em at 3AX do prazo originalmente previsto para sua
e,ecuo 'pea !@, p 1!01.(
!!: 5 /ontrato !:C!A@@ previu o desenvolvimento do $istema &ntegrado de /on+ecimento e
Oesto '$&/O( de forma iterativa e incremental por meio de ciclos, com durao m,ima de tr-s
semanas cada um, e,ecutados mediante ordens de servio dimensionadas por meio de pontos de
funo brutos 'pea !!, p !9 e !=(
!!= 5 primeiro ciclo estabelecido no termo de refer-ncia consiste no ciclo de plane)amento, o
#ual sucedido do ciclo de transio para os ciclos de desenvolvimento, ciclos de desenvolvimento,
ciclo de transio para o ciclo de implantao, ciclo de implantao, ciclo de transio para o ciclo
de encerramento e ciclo de encerramento 'pea !!, p .A(
!.A A e,ecuo de cada ciclo precedida por uma reunio de plane)amento, na #ual a
contratada apresenta ao &p+an uma proposta de 5rdem de servio contendo o plane)amento proposto
para o ciclo /aso aprovada pelo &p+an, a 5$ devidamente formalizada e entregue 7 contratada
para dar in2cio 7s atividades previstas no ciclo 'pea !!, p .1(
!.@ /ada ciclo finalizado pela reunio de encerramento, oportunidade em #ue os produtos
resultantes da 5$ so apresentados 'pea !!, p .1( 5 prazo para a aceitao definitiva dos produtos
entregues pelo &p+an, dada pela emisso de pareceres tcnico e negocial favorveis, consiste no prazo
de e,ecuo do pr,imo ciclo 'pea !!, p .3(
!.! A remunerao da contratada para os ciclos de desenvolvimento baseia0se na #uantidade
de pontos de funo e,ecutados no ciclo 'pea !!, p .3( 5 termo de refer-ncia do Prego 6letr*nico
@!C!A@@ previu #ue 93X do valor do contrato seriam destinados aos ciclos de desenvolvimento, ou
se)a, na realidade a contratada recebe apenas 93X do valor dos pontos de funo brutos da contagem
final de cada ciclo de desenvolvimento 'pea !!, p .9(
!.. Por seu turno, aos ciclos de pro)eto 'plane)amento, implantao e encerramento(, no
mensurveis por pontos de funo, foram destinados 3X, @AX e @AX da #uantidade estimada de dois
mil pontos de funo brutos 5 valor pago referente ao ciclo de plane)amento pode sofrer reviso,
2O
uma vez #ue a #uantidade final de pontos de funo do $&/O pode no corresponder aos dois mil
pontos inicialmente estimados 'pea !!, p .9(
!.1 Acerca da futura contratao de fbrica de software para o desenvolvimento e
manuteno de sistemas informatizados do &p+an, o modelo de remunerao da contratada previsto
na minuta do termo de refer-ncia assemel+a0se ao do /ontrato !:C!A@@
!.3 8o novo contrato, as demandas sero solicitadas por meio de 5rdens de $ervio, cu)a
remunerao ser calculada considerando a #uantidade de pontos de funo a serem produzidos e a
fase do desenvolvimento 8a fase de plane)amento, caber 3X dos pontos de funo estimados,
en#uanto nas fases de desenvolvimento e encerramento caber 7 contratada receber :AX e @3X,
respectivamente, dos pontos de funo efetivamente produzidos 'pea !9, p 1=4(
!.4 8o /ontrato ..C!A@!, atualmente vigente, o flu,o do processo de desenvolvimento ou
manuteno programada de sistemas detal+ado na ;etodologia de Oesto e Desenvolvimento de
$istemas ';OD$F pea !1, p 3@.033@( $egundo a ;OD$, a definio da viso do novo sistema a ser
desenvolvido ou de sistema legado a sofrer manuteno d0se na etapa de iniciao, fase #ue pode ser
e,ecutada com ou sem au,2lio da contratada
!.9 A iniciao constitui0se no plane)amento propriamente dito 8essa fase, alm da
elaborao da viso do produto e do estabelecimento da definio de IprontoJ, tambm so definidos
os re#uisitos #ue constaro do bac(log do produto 'pea !1, p 3@.( /aso +a)a necessidade de
participao da contratada na iniciao, uma 5rdem de servio espec2fica aberta para a realizao
de atividades de levantamento preliminar de escopo )unto ao cliente ou de detal+amento da demanda
8esse tipo de ocorr-ncia, a contratada tem remunerao correspondente a @AX da #uantidade de
pontos de funo estimada para a respectiva 5$ 'pea !1, p 4=(
!.: A fase de iniciao encerrada #uando a demanda plane)ada, se)a desenvolvimento de
novo sistema, se)a manuteno de sistema legado, repassada para a contratada com a finalidade de
alin+ar o entendimento do negcio entre o &nep e a contratada 'pea !1, p 3@=(
!.= 8a se#u-ncia, inicia0se a fase de e,ecuo, #ue desenrolada segundo os preceitos do
framewor( Scrum, com reunio de plane)amento da sprint, na #ual emitida 5$ para a sua e,ecuo
pela contratada, e reunio de reviso, na #ual a contratada entrega os produtos da sprint, alm da
reunio de retrospectiva 'pea !1, p 3!@03!4( Para a e,ecuo da sprint, a contratada
remunerada em @AAX do total obtido na medio final dos pontos de funo da iterao entregue e
aceita 'pea !1, p 4=(
!1A Ao final da fase de e,ecuo tambm pode se dar a implantao, no ambiente de
produo, do produto gerado na sprint, #uando aceito e +omologado pelo &nep e solicitado pelo
+roduct owner 'pea !1, p 3!4(
!1@ A ltima fase do processo de desenvolvimento ou manuteno de sistemas, de acordo com
a ;OD$, consiste no encerramento, #ue tem como ob)etivo encerrar as ordens de servio de iniciao
e da sprint 'pea !1, p 3.903.:( 8o encerramento, ocorre a aceitao definitiva das 5rdens de
$ervio, +abilitando0as para faturamento pela contratada
!1! Antes da e,ecuo da fase de encerramento, a ;OD$ prev- a +omologao dos artefatos
produzidos pela contratada em atendimento 7s 5rdens de servio de iniciao e da sprint em dois
momentos 8o primeiro, a avaliao da #ualidade dos artefatos realizada pela rea de %& #uanto 7
conformidade com os padres estabelecidos pelo &nep 'pea !1, p 3!:03.A( 8o segundo, a avaliao
feita sob o ponto de vista do negcio pelo cliente demandante 'pea !1, p 3.303.4(
!1. 8o /ontrato !1C!A@., as demandas so encamin+adas 7 empresa contratada por meio de
ordens de servio, as #uais so formalizadas na reunio de abertura da 5$ 'pea !3, p .1(
!11 Aps a reunio de abertura da 5$, inicia0se a etapa de preparao da sprint, #ue serve,
basicamente, para garantir o entendimento, por parte da contratada, do servio solicitado e facilitar o
plane)amento da e,ecuo 8essa etapa, apresentado 7 contratada um subcon)unto de +istrias de
2K
usurio, #ue consiste em parte do product bac(log, para #ue se)am selecionadas a#uelas #ue
comporo o bac(log da sprint 'pea !3, p .1(
!13 Aps a preparao, inicia0se a etapa de e,ecuo, a #ual consiste na sprint propriamente
dita para a construo do produto 5 prazo da sprint fi,ado em #uinze dias, podendo ser alterado
ao longo da vig-ncia contratual 'pea !3, p .@( A e,ecuo, por sua vez, inicia0se com a reunio de
plane)amento da sprint e encerra0se com a reunio de demonstrao 'pea !3, p .A(
!14 8a reunio de plane)amento, criado o bac(log da sprint, as +istrias de usurio so
detal+adas em tarefas a e,ecutar, a contratada assegura o entendimento tcnico e negocial da
demanda, o taman+o e critrios de aceitao so definidos e a definio de IprontoJ estabelecida
'pea !3, p .3(
!19 8a reunio de demonstrao, os produtos constru2dos com base nas +istrias de usurio
selecionadas para a sprint so apresentados em ambiente de +omologao 8essa reunio, a
contratada tambm deve entregar a documentao prevista no instrumento convocatrio, a e,emplo
de documento de ar#uitetura, modelo de dados e plano de implantao 8essa reunio, conforme
interesse do $%F, a contratada deve detal+ar e repassar todo o con+ecimento tcnico utilizado na
construo dos produtos 'pea !3, p .4 e 11(
!1: $ucede a etapa de e,ecuo a avaliao, per2odo em #ue o produto verificado funcional
e tecnicamente 'pea !3, p .A( 8o +avendo inconformidades e ocorr-ncias, o produto
+omologado e a ordem de servio originria encerrada 'pea !3, p .:(
!1= 5 pagamento das ordens de servio calculado com base no taman+o funcional do
produto +omologado em pontos de funo brutos e na efetiva e,ecuo do servio 6le feito em duas
etapasE a primeira, correspondente a =AX, realizada aps o recebimento definitivo da 5$ referente
7 ltima sprint de cada produtoF a segunda, correspondente a @AX, realizada somente ao final do
per2odo de garantia, estipulado em @:A dias 'pea !3, p !@ e .=(
?.<. $udanas de requisitos e escopo
!3A A filosofia dos mtodos geis para desenvolvimento de software foi concebida para
absorver mudanas, conforme e,presso no manifesto gil e em seus princ2pios, especificamente no
valor Iresponder a mudanas, mais #ue seguir um planoJ e no princ2pio Iaceitar mudanas de
re#uisitos, mesmo no fim do desenvolvimentoJ %al mudana pode acontecer inclusive durante as
iteraes, ciclos ou sprints 8o Scrum, durante a sprint, no so feitas mudanas #ue possam afetar
seu ob)etivo, porm o escopo pode ser esclarecido e renegociado entre o +roduct wner e a e#uipe
de desenvolvimento 7 medida #ue for mel+or entendido
!3@ 6ntretanto, foi constatado #ue a maioria das instituies contratantes no permite
mudanas durante a e,ecuo das iteraes 6,emplo dessa prtica pode ser visto na pgina .! do
edital do Prego 6letr*nico @!C!A@@ do &p+an 'pea !!(, na #ual consta #ue Iuma vez #ue o ciclo
ten+a sido aprovado pela /58%>A%A8%6 e a 5rdem de servio ten+a sido emitida, nen+uma das
partes poder alterar o escopo do ciclo at #ue ele finalizeJ
!3! Vuando identificadas, as mudanas so colocadas no bac(log do produto para #ue, em
momento oportuno, conforme a priorizao da rea de negcios, se)am introduzidas em iteraes
seguintes
!3. Por outro lado, no ?acen, a possibilidade de alterao do escopo de uma 5rdem de
servio est e,plicitamente prevista no edital do Prego 6letr*nico Demap 9C!A@! por meio do
documento $olicitao de ;udana, no #ual a mudana de escopo solicitada, com respectiva
anlise de impacto no taman+o, prazo e custo 'pea !@, p !@(
?.?. E="eis de ser"io
!31 Da anlise dos editais das contrataes, observa0se #ue #uase todas as instituies
visitadas institu2ram vrios n2veis de servio a serem atendidos pela contratada 6m suma, o no
atendimento a critrios m2nimos aceitveis implica a reduo do valor a ser pago 7 contratada Dos
n2veis de servio analisados, verificou0se a preocupao #uase comum das contratantes com o prazo
para o cumprimento das iteraes, ciclos ou sprints, e com a #ualidade dos produtos entregues
30
%ribunal $uperior do %rabal+o '%$%(
!33 8o %$%, por e,emplo, foi institu2do o \ndice de Atraso na 6ntrega de 5$, o #ual tem por
ob)etivo garantir a entrega da 5$ no prazo estimado para a sua concluso 'pea !A, p .9( 6mbora a
meta estabelecida para esse indicador se)a de AX, o %$% estipulou #ue atrasos inferiores a @AX do
prazo previsto para a entrega da 5$ encontram0se em um limite aceitvel &sto , no contrato do %$%
+ tolerBncia para atrasos na entrega dos produtos demandados, afastando0se dos preceitos do
framewor( Scrum, no #ual uma sprint deve ser e,ecutada no prazo estabelecido
!34 Vuanto 7 aferio da #ualidade, o %$% criou o indicador Desconformidade na 5$ 'D5$(
para assegurar a conformidade das 5rdens de servio aos re#uisitos de #ualidade, determinados nos
modelos a serem utilizados para a elaborao dos artefatos produzidos pela contratada, bem como
nas listas de verificao para a avaliao desses artefatos 'pea !A, p 4., 430=3( A meta do
indicador D5$ AX, significando #ue caso alguma desconformidade se)a detectada, o produto, e,
conse#uentemente, a 5rdem de servio, re)eitada
!39 Por sua vez, o ?acen instituiu indicador referente ao Atraso na 6ntrega da 5$ de pro)eto
de construo, tolerando, assim como o %$%, pe#uenos atrasos, uma vez #ue esse indicador deve ser
menor ou igual a A,@ 'pea !@, p 4.( Para aferir a #ualidade dos artefatos entregues pela contratada
em pro)etos de construo, o ?acen definiu o \ndice de Defeitos por Pontos de Funo da 5$ e o
\ndice de Defeitos &mpeditivos por Pontos de Funo da 5$ Para o primeiro indicador, + tolerBncia
para a aceitao da 5$, en#uanto para o segundo a tolerBncia zero 'pea !@, p 4.041(
!3: De forma diferente das outras instituies visitadas, o &p+an, no /ontrato !:C!A@@,
institui apenas dois indicadores de n2vel de servio, sendo #ue somente um deles refere0se ao servio
de desenvolvimento, e,ecutado nos ciclos de desenvolvimento, o #ual denominado de \ndice de
Pontos 6,ecutados '&P6( 5 &P6 destina0se a avaliar a #ualidade dos produtos entregues, medindo a
#uantidade de pontos de funo brutos e,ecutados e aceitos da ordem de servio /aso o &P6 se)a
inferior ou igual a :AX, multas podem ser aplicadas 7 contratada 'pea !!, p 13014(
!3= A instituio do &P6 no instrumento convocatrio do &p+an no se confunde com a
aceitao de 5rdens de servio contendo produtos em desconformidade com os padres de #ualidade
estabelecidos /aso algum produto constru2do no ciclo no se)a aprovado, este poder ser
considerado perdido, devendo um novo ciclo ser iniciado para ade#uao desse produto 'pea !!,
p ..(
!4A Acerca do atraso na entrega dos produtos demandados nas ordens de servio, ou se)a,
atraso nos ciclos, o &p+an no prev- tal situao no termo de refer-ncia do Prego 6letr*nico
@!C!A@@ 8o /ontrato !:C!A@@, ao final de cada ciclo, a contratada deve entregar os produtos #ue
porventura ten+a produzido, os #uais sero avaliados pelo &P6 /aso no ten+a produtos a entregar,
assim como os produtos no aprovados, eles devero ser ob)eto de outro ciclo
!4@ 5 edital em elaborao do &p+an para a contratao de fbrica de software para
desenvolvimento e manuteno de sistemas com mtodos geis tambm mantm o mesmo indicador
'&P6( para a avaliao dos produtos entregues 'pea !9, p 1=401=9(
!4! 8o &nep, no Bmbito do /ontrato ..C!A@!, os critrios de avaliao da #ualidade dos
produtos entregues possuem indicadores distintos para a avaliao a cargo da rea de %& e a da rea
de negcios A rea de %& avalia a conformidade da #ualidade dos produtos sob o aspecto tcnico,
+omologando0os tecnicamente A rea de negcios avalia a conformidade dos produtos sob o aspecto
negocial, +omologando0os negocialmente $egundo o instrumento convocatrio, +avendo no
conformidades nessas etapas, so concedidos prazos '1: +oras na +omologao tcnica e !1 na
+omologao negocial( consecutivos para a contratada ade#uar os produtos 7 #ualidade e,igida,
avaliando0se negativamente a contratada a cada novo prazo dado 'pea !1, p 33034, %abela @, itens
@, !, 1 e 3(
31
!4. Acerca do cumprimento do prazo para a e,ecuo das 5rdens de $ervio, segundo o
termo de refer-ncia, + tolerBncia #uando ocorre o descumprimento do cronograma estabelecido
para a concluso dos servios 6ntretanto, a contratada avaliada de forma negativa #uando atrasa
a entrega dos produtos especificados na 5rdem de servio, concedendo0se sucessivos prazos de !1
+oras para finaliz0los, nos #uais a penalizao da contratada agravada 'pea !1, p 34, %abela @,
itens 4 e 9(
!41 5 $%F aplica dois tipos de redutores 7s 5rdens de servio pagas 7 empresa contratada
5 primeiro refere0se aos n2veis de servio propriamente ditos, en#uanto o segundo relaciona0se aos
critrios gerais de avaliao 'pea !3, p 3!03.( 6ntre os n2veis de servio, encontra0se o \ndice de
Desconformidade do Produto, o #ual afere a #ualidade dos produtos entregues pela contratada Por
sua vez, nos critrios gerais de avaliao consta a punio a ser aplicada 7 contratada #uando
ocorrer atraso no )ustificado nas datas definidas nas 5rdens de $ervio
!43 Ainda c+ama a ateno no /ontrato ..C!A@!, do &nep, e no /ontrato !1C!A@., do $%F, a
e,ist-ncia de indicadores espec2ficos de rotatividade da e#uipe da contratada 'pea !1, p 34039, item
@A e pea !3, p 19 e 3!, item @( "ma vez #ue o desenvolvimento de softwares com a utilizao de
mtodos geis tem foco voltado para os indiv2duos, em vez de processos, e na entrega de resultado de
forma adiantada, a substituio de membros da e#uipe da contratada, como o Scrum $aster ou
membros da e#uipe de desenvolvimento, pode efetivamente diminuir a produtividade do fornecedor
?.F. 0ompatibili'ao dos "alores 3geis nas contrata%es examinadas
!44 5 e,ame dos contratos das instituies visitadas demonstra o Bnimo de impor a ess-ncia
das metodologias geis, postuladas pelos valores do ;anifesto Ngil, 7s contrataes realizadas,
compatibilizando0a com as normas vigentes
!49 8esse sentido, constatou0se a preocupao de todas as instituies com relao 7 entrega
de artefatos de documentao associados ao software produzido a cada iterao, facilitando, por
e,emplo, futuras manutenes por terceiros al+eios ao processo de desenvolvimento %ambm foi
constatado #ue a relao contratual prevalece sobre a poss2vel colaborao entre as partes, em
+armonia com o princ2pio da vinculao ao instrumento convocatrio, e as mudanas propostas
mostraram0se restritas a novas iteraes, mitigando o risco de desembolsos no programados
!4: 6ntretanto, #uanto 7 pessoalidade L forte aspecto das metodologias geis, fundamentado
na maior valorizao dos indiv2duos e interao entre eles em detrimento de processos e ferramentas,
e materializado na necessidade da constBncia da composio da e#uipe de desenvolvimento do time
Scrum 'item =A( L foi constatada, pela e,ist-ncia de n2veis de servio vinculados 7 rotatividade da
e#uipe de desenvolvimento da contratada em contratos de duas instituies, a preocupao com essa
caracter2stica do mtodo
F. /iscos na contratao de desen"ol"imento de software com m@todos 3geis pelas institui%es da
Administrao +>blica 5ederal
!4= /om o con+ecimento ad#uirido sobre mtodos geis, se)a decorrente da anlise terica
ou das visitas realizadas pela e#uipe de fiscalizao a algumas instituies pblicas federais, se)a
decorrente do e,ame dos contratos dessas instituies, poss2vel vislumbrar alguns riscos nas
contrataes pblicas para desenvolvimento de software por meio de mtodos geis
!9A 8esse sentido, a seguir so apresentados alguns riscos inerentes ao novo paradigma de
desenvolvimento de software #ue est sendo difundido nas contrataes da Administrao Pblica,
suas poss2veis causas e conse#u-ncias, bem como contrataes em #ue foram materializados, #uando
for o caso Para fins didticos, os riscos elencados esto reunidos em tr-s grupos distintosE processos,
produtos e pessoas
!9@ /umpre frisar #ue no se trata de enumerao e,austiva de riscos, e sim de um
subcon)unto identificado com o con+ecimento ad#uirido %ambm importante observar #ue alguns
dos riscos e,postos no so inerentes somente ao uso de mtodos geis, podendo ocorrer tambm com
metodologias tradicionais de desenvolvimento de software
32
>iscos relativos a processos
!9! >isco @E contratao de desenvolvimento de software com adaptao de metodologia gil
#ue desvirtue sua ess-ncia
!9!@ "ma vez #ue a utilizao estrita da doutrina gil pode ser conflitante com algum
dispositivo constante dos diversos normativos e )urisprud-ncia vigentes ou no atender 7 totalidade
dos interesses da instituio pblica contratante, esta pode incorrer em adaptaes de uma
metodologia gil ) consolidada no mercado com o intuito de mold0la 7 sua realidade 6ssa prtica
pode ter como conse#u-ncias, entre outrasE
!9!@@ diminuio da competitividade da licitao, pois a utilizao de metodologias
adaptadas pode no despertar o interesse de fornecedores #ue ) adotam uma metodologia espec2fica,
preferindo no realizar contratos #ue apresentem risco para o seu negcioF
!9!@! conflitos com a empresa contratada, uma vez #ue podem surgir interpretaes
e#uivocadas pelas partes #uanto ao emprego dos processos, atividades e papeis estabelecidos no
instrumento convocatrio, no +avendo organizao #ue suporte a metodologia adaptada, a #ual
possa ser utilizada para dirimir eventuais dvidas e, por conse#u-ncia, eliminar os conflitosF
!9!@. conflitos entre membros da instituio contratante devido a fal+as na atribuio dos
papeis a serem desempen+adosF
!9!@1 entrega de produtos de bai,a #ualidade, caso a adaptao da metodologia suprima
elementos do processo de elaborao do software serv2veis 7 construo e 7 aferio da #ualidade do
produtoF
!9!@3 diminuio da efici-nciaCprodutividade da e#uipe de desenvolvimento da empresa
contratada, caso a adaptao feita na metodologia anule ou atenue prticas #ue visem 7 efici-nciaF
!9!! Algumas das conse#u-ncias vislumbradas no risco em desta#ue podem vir a ocorrer no
/ontrato @14C!A@! do %$% 5 framewor( adotado nessa instituio o Scrum 6ntretanto, segundo o
subitem .1 'pea !A, p 3A(, vrios sistemas podem ser agrupados em uma mesma sprintE
I.1 5 Processo de $ustentao Programada ser e,ecutado na forma de Sprints, como
definido no mtodo de desenvolvimento gil Scrum, com a principal diferena de permitir o
agrupamento de manutenes de vrios sistemas diferentes em um mesmo SprintJ 'grifo nosso(
!9!. uma vez #ue o mesmo time de desenvolvimento Scrum deve estimar e realizar a
contagem dos pontos de funo relativos a novas funcionalidades de mais de um sistema, gerenciar a
e,ecuo de atividades diversas pulverizadas em vrios sistemas, interagir com +s distintos durante
a e,ecuo de uma nica sprint, sua efici-ncia pode sofrer pre)u2zos
!9!1 5 %$% tambm inovou ao especificar, no termo de refer-ncia, #ue o papel do +roduct
wner pode ser desempen+ado por mais de uma pessoa 'pea !A, p 34(E
I=@ 5 Dono do Produto pode ser um profissional, ou um grupo de profissionais, da /D$ eCou
das reas de negcio do %$%J
!9!3 8esse caso, as posies dos donos do produto podem ser divergentes, gerando, por
e,emplo, problemas na ger-ncia do bac(log do produto e na avaliao das funcionalidades entregues
!9!4 Por seu turno, a ;etodologia &p+an de Oesto de Demandas de Desenvolvimento Ngil
de Softwares ';idas(, a #ual ser adotada na futura contratao de fbrica de software #ue se
avizin+a, define a e,ist-ncia de dois Scrum $asters no modelo de ger-ncia do desenvolvimento de
software, sendo um da contratada e o outro do prprio &p+an 8o framewor( Scrum, esperado #ue
tal papel se)a desempen+ado pela contratada %al fato pode gerar problemas de compet-ncia com a
empresa contratada
!9. >isco !E alterao da metodologia gil adotada no instrumento convocatrio no decorrer
da e,ecuo contratual
!9.@ A alterao da metodologia gil adotada no instrumento convocatrio durante a
e,ecuo contratual pode ocorrer devido 7 pouca e,peri-ncia da instituio pblica contratante na
utilizao de mtodos geis 6ssa prtica pode ter como conse#u-ncias conflitos de ordem financeira
com a empresa contratada, uma vez #ue o seu preo, apresentado 7 poca da licitao, pode vir a no
33
cobrir novos custos decorrentes de alteraes introduzidas pela contratante, trazendo distores 7
manuteno do e#uil2brio econ*mico0financeiro do contrato Alm disso, afronta o princ2pio da
vinculao ao instrumento convocatrio institu2do no art .Y da Uei :444C@==.
!9.! "ma variao do risco em ep2grafe a incluso de clusulas e condies no
instrumento convocatrio e no contrato dele decorrente, as #uais prev-em #ue a metodologia
especificada pode sofrer alteraes durante a vig-ncia contratual 8esse caso, alm de trazer
distores 7 manuteno do e#uil2brio econ*mico0financeiro do contrato, tal prtica pode configurar
afronta ao art @1 da lei de licitaes e contratos, #ue veda a contratao sem a ade#uada
caracterizao de seu ob)eto
!9.. 8o ?acen, algumas das clusulas do instrumento convocatrio #ue originou o /ontrato
3A1@!C!A@! apresentam essa caracter2stica, como e,emplificado a seguir
I:@1 A critrio do ?acen os padres, processos de trabal+o e artefatos podero sofrer
alteraes A /ontratada dever se adaptar 7s mudanas no prazo m,imo de .A dias corridos
contados da comunicao pelo ?acenJ 'pea !@, p !3(
I:@3 A critrio do ?acen, durante a e,ecuo contratual, podero ser acrescentadas ao
con)unto de processos de desenvolvimento, manuteno e documentao vigentes, outras
metodologias, prticas, artefatos e tecnologias 'framewor(s, ambiente operacional e de
desenvolvimento, ar#uitetura dentre outros( #ue se)am aderentes 7s formas de mensurao, de
pagamento e de servios previstas neste 6ditalJ 'pea !@, p !10!3(
I@9!@! 5 ?acen poder estipular, na prpria 5rdem de servio, em funo de suas
caracter2sticas espec2ficas, outros critrios de validao dos servios, adicionais ou substitutivos aos
descritos nos padres e processos de trabal+o do ?acenJ 'pea !@, p 1!(
!9.1 As alteraes previstas nesses casos, #uanto ao desenvolvimento de sistemas no ?acen,
afetam basicamente o Processo de Desenvolvimento Ngil do ?acen 'PD$0Ngil(
!91 >isco .E aus-ncia de definio dos artefatos ou alterao dos artefatos e,igidos da
contratada no instrumento convocatrio durante a e,ecuo contratual
!91@ 5 risco em evid-ncia, assim como o anteriormente citado, pode decorrer da pouca
e,peri-ncia da instituio pblica contratante na utilizao de mtodos geis
!91! A aus-ncia da definio dos artefatos e,igidos da contratada no instrumento
convocatrio pode elevar os custos da contratao, uma vez #ue a empresa contratada, por no
con+ecer a totalidade dos produtos demandados para a construo do software 7 poca da licitao,
pode apresentar proposta de preos ma)orada em virtude da insegurana inerente ao
descon+ecimento
!91. alm de ser potencialmente lesiva 7 economicidade da contratao, a materializao do
risco em ep2grafe pode configurar afronta ao art @1 da lei de licitaes e contratos, #ue veda a
contratao sem a ade#uada caracterizao de seu ob)eto
!911 Por sua vez, a alterao dos artefatos e,igidos da contratada no instrumento
convocatrio no decorrer da e,ecuo contratual afronta o princ2pio da vinculao ao instrumento
convocatrio institu2do no art .Y da Uei :444C@==. e pode gerar conflitos com a empresa contratada
por vir a introduzir novos custos no vislumbrados no edital, ferindo a manuteno do e#uil2brio
econ*mico0 financeiro do contrato 6m acrscimo, tambm fere o art @1 da lei citada
!913 8o ?acen, os subitem :@1 e :@3 do termo de refer-ncia do Prego 6letr*nico
Demap 9C!A@!, transcritos a seguir, apresentam essa caracter2sticaE
I:@1 A critrio do ?acen os padres, processos de trabal+o e artefatos podero sofrer
alteraes A /ontratada dever se adaptar 7s mudanas no prazo m,imo de .A dias corridos
contados da comunicao pelo ?acenJ 'pea !@, p !3(
I:@3 A critrio do ?acen, durante a e,ecuo contratual, podero ser acrescentadas ao
con)unto de processos de desenvolvimento, manuteno e documentao vigentes, outras
metodologias, prticas, artefatos e tecnologias 'framewor(s, ambiente operacional e de
34
desenvolvimento, ar#uitetura dentre outros( #ue se)am aderentes 7s formas de mensurao, de
pagamento e de servios previstas neste 6ditalJ 'grifo nosso( 'pea !@, p !10!3(
!93 >isco 1E e,ig-ncia de artefatos desnecessrios ou #ue se tornam obsoletos rapidamente
!93@ A e,ig-ncia de artefatos desnecessrios pode ser oriunda da ine,peri-ncia da
instituio contratante, principalmente na transio do modelo de contratao para desenvolvimento
de software com metodologias tradicionais para mtodos geis
!93! Alguns artefatos e,igidos no instrumento convocatrio podem, no novo paradigma, no
trazer utilidade 7 contratante ou tornarem0se obsoletos rapidamente, de uma sprint para outra, como
manual do usurio Alm disso, acrescentam custos 7 empresa contratada, os #uais possivelmente
foram repassados em sua proposta de preos, onerando de forma desarrazoada o a)uste contratual
Dessa forma, a materializao do risco em tela afronta o princ2pio constitucional da economicidade
!94 >isco 3E utilizao de contrato para desenvolvimento de software por metodologias
tradicionais para desenvolvimento por mtodos geis
!94@ A utilizao de contrato inicialmente concebido para ser e,ecutado segundo modelo de
desenvolvimento de software tradicional para o desenvolvimento de software por meio de mtodos
geis, em primeira anlise, conflita com o princ2pio da vinculao ao instrumento convocatrio,
estabelecido no art .Y da Uei :444C@==. 8esse caso, trata0se de alterao no ob)eto do servio de
desenvolvimento de software, +a)a vista #ue a utilizao de mtodos geis pode alterar, em forma ou
em ess-ncia, os produtos inicialmente descritos no contrato
!4.! Potencialmente, a materializao do risco em tela pode gerar atritos entre a instituio
contratante e a fornecedora devido 7 mudana do paradigma utilizado na e,ecuo contratual, no
previsto inicialmente no instrumento convocatrio 6m adio, poss2vel #ue vrios elementos
constantes no a)uste contratual no se ade#uem 7 utilizao de mtodos geis, como n2veis de servio
e artefatos e,igidos da contratada no decorrer da e,ecuo contratual
>iscos relativos a pessoas
!99 >isco 4E falta de comprometimento ou colaborao insatisfatria do responsvel indicado
pela rea de negcios '+roduct wner( no desenvolvimento do software
!99@ 5 uso de mtodos geis e,ige grande comprometimento do responsvel indicado pela
rea de negcios da instituio pblica, con+ecido como +roduct wner no framewor( Scrum A ele
atribu2do o gerenciamento do produto de forma a assegurar o valor do trabal+o e,ecutado pela
e#uipe de desenvolvimento da contratada
!99! Para #ue o processo de construo do produto possa fluir ade#uadamente, o
responsvel indicado pela rea de negcios deve desempen+ar diversas atividades, como definir a
viso do produto, gerenciar suas funcionalidades, prioriz0las e aprovar ou re)eitar os artefatos
entregues a cada iterao Alm disso, deve ter disponibilidade para atender, sempre #ue necessrio,
a e#uipe de desenvolvimento da contratada para #ue essa possa, por e,emplo, elidir dvidas
emergentes
!99. A falta de comprometimento ou a colaborao insatisfatria do responsvel no
processo de construo do software, abdicando do e,erc2cio das atividades a ele atribu2das, pode ter
como conse#u-ncias a gerao de produtos de bai,a #ualidade #ue no atendam 7s reais
necessidades dos clientes, atrasos no desenvolvimento e at mesmo, em casos e,tremados, o
cancelamento do pro)eto
!9: >isco 9E falta do con+ecimento necessrio do indicado pela rea de negcios '+roduct
wner( para o desenvolvimento do software
!9:@ 5 servidor indicado pela rea de negcios responsvel pela construo do software
para desempen+ar o papel de +roduct wner ou similar pode no deter os con+ecimentos
necessrios dos processos de trabal+o #ue sero apoiados pela soluo de %& a ser desenvolvida,
podendo acarretar definies e priorizaes de funcionalidades e#uivocadas, em detrimento das
funcionalidades essenciais
3N
!9:! 6m acrscimo, outras conse#u-ncias potenciais da falta de con+ecimento do +roduct
wner indicado so esforos e custos posteriores para a)ustar a soluo mal concebida ou, at
mesmo, o seu descarte, afrontando os princ2pios constitucionais da economicidade e da efici-ncia
!9:. 8o caso da materializao desse risco, pode caber responsabilizao do +roduct
wner e do responsvel pela sua indicao #uanto aos recursos despendidos sem #ue o interesse
pblico ten+a sido atendido
!9:1 8o &p+an, em entrevista com o responsvel pelo /ontrato !:C!A@@ e a e#uipe de
fiscalizao, foi revelado #ue o risco ora tratado materializou0se 8a ocasio, o fato foi devidamente
documentado nos autos do processo da contratao e comunicado 7 instBncia superior para o
ade#uado tratamento
!9= >isco :E e,cessiva depend-ncia da viso do indicado pela rea de negcios '+roduct
wner(
!9=@ A falta de interao do +roduct wner com os demais usurios do software em
construo e, at mesmo, o descon+ecimento desses acerca do pro)eto, pode vir a criar e,cessiva
depend-ncia de sua viso na concepo do produto /omo efeito desse risco, o sistema de informao
constru2do pode no atender 7s e,pectativas dos usurios e, por conse#u-ncia, no atender 7
necessidade da contratao
!44! 5utro aspecto relacionado 7 depend-ncia e,cessiva do +roduct wner refere0se a seus
afastamentos da instituio em decorr-ncia, por e,emplo, de frias e licenas 8esse caso, uma
poss2vel conse#u-ncia a suspenso da e,ecuo do pro)eto, acarretando atrasos na entrega do
produto final 8o &p+an, segundo relatos, #uando o +roduct wner afastou0se, em decorr-ncia de
frias, o andamento do pro)eto e,ecutado no Bmbito do /ontrato !:C!A@@ foi suspenso 8essa
ocasio, a empresa contratada aproveitou o per2odo de afastamento do P5 para introduzir mel+orias
tcnicas no software
!:A >isco =E e#uipe da empresa contratada no ter e,pertise em desenvolvimento de software
com mtodos geis
!:A@ 6m licitaes pblicas, para mitigar o risco da licitante vencedora do certame no
possuir a capacidade tcnica necessria para a e,ecuo do ob)eto, a Uei :444C@==. prov-, em seu
art .A, mecanismos para #ue a futura contratada comprove estar tecnicamente apta para a prestao
dos servios &sso se d, notadamente, por meio da apresentao de atestados de capacidade tcnica
#ue demonstrem a e,ecuo de servios pertinentes e compat2veis em caracter2sticas, #uantidades e
prazos com o ob)eto da licitao
!:A! 6m relao ao risco em desta#ue, ainda #ue a licitante apresente os atestados e,igidos
no instrumento convocatrio comprovando #ue ) produziu sistemas utilizando mtodos geis, e ainda
#ue se faam dilig-ncias para comprovar sua veracidade, + a possibilidade de #ue os resultados
demonstrados por esses documentos no se)am reproduzidos na nova contratao &sso pode
acontecer em virtude, por e,emplo, de alocao, pela contratada, de e#uipe ine,periente,
principalmente em contrataes de fbrica de software
!:A. As conse#u-ncias poss2veis, #uando da materializao do risco ora e,posto, so atrasos
constantes na entrega dos produtos e gerao de produtos de bai,a #ualidade, resultando, em ltima
anlise, no no atendimento da necessidade da contratao
!:A1 8a primeira e,peri-ncia do &nep de contratao de desenvolvimento de software com
mtodos geis '/ontrato @C!A@@ L pea !., p .:.(, o risco em ep2grafe materializou0se, conforme
relatado por membros da rea de %& 7 e#uipe de fiscalizao A e#uipe da empresa contratada
alocada para a prestao do ob)eto do contrato no detin+a o con+ecimento necessrio para o
cumprimento dos servios demandados, embora o instrumento convocatrio e,igisse dos perfis
profissionais da contratada con+ecimento em Scrum, entre outros 'pea !., p 13031(
!:@ >isco @AE dificuldade de comunicao entre a e#uipe de desenvolvimento da contratada
com o indicado pela rea de negcios '+roduct wner(
36
!:@@ A maior valorizao de indiv2duos e a interao entre eles em detrimento de processos
e ferramentas, e,pressa no ;anifesto NgilF o princ2pio no #ual pessoas relacionadas a negcios e
desenvolvedores devem trabal+ar em con)unto e diariamente, durante todo o curso do pro)etoF e o
princ2pio no #ual estabelecido #ue o mtodo mais eficiente e eficaz de transmitir informaes para,
e por dentro de um time de desenvolvimento, por meio de uma Iconversa cara a caraJ, dei,am
evidente #ue a comunicao entre as pessoas envolvidas no processo de desenvolvimento do software
tem importBncia fundamental
!:@! /onforme preceituado pelo valor /omunicao do e4treme +rogramming '4+(,
dilogos presenciais so mais eficazes #ue videoconfer-ncias, #ue, por sua vez, so mel+ores #ue
telefonemas, sendo esses mais e,pressivos #ue emails e assim sucessivamente 'item @!!!( 5 dilogo
presencial evita #ue problemas de m compreenso e ambiguidades comprometam negativamente o
produto final
!:@. Ainda #ue o indicado pela rea de negcios '+roduct wner( da instituio contratante
ten+a disponibilidade para atender o time de desenvolvimento da contratada, necessria a
e,ist-ncia de canais de comunicao eficazes entre ambos 8esse sentido, a alocao da e#uipe da
contratada nas instalaes da contratante tende a facilitar o processo de comunicao, ao passo #ue
a operacionalizao dos servios de desenvolvimento em uma localizao remota tende a dificult0lo
!4:1 A dificuldade de comunicao entre os membros do time de desenvolvimento com o
indicado pela rea de negcios tem como potenciais conse#u-ncias elaborao de produtos de bai,a
#ualidade, atrasos na entrega dos produtos e, em ltima anlise, traduz0se no no atendimento da
necessidade da contratao
>iscos relativos a produtos
!:! >isco @@E alterao constante da lista de funcionalidades do produto
!:!@ "ma vez #ue a mudana de re#uisitos durante o pro)eto bem aceita no
desenvolvimento de software com mtodos geis, conforme se constata da leitura do ;anifesto Ngil e
de seus princ2pios, a lista de funcionalidades do produto pode ser constantemente alterada para
incluir, ainda no desenvolvimento, novas caracter2sticas inicialmente no plane)adas, previstas ou
vislumbradas
!:!! A alterao constante e descontrolada da lista de funcionalidades do produto durante o
contrato pode levar a instituio contratante a e,ceder prazos e custos de desenvolvimento
preliminarmente estimados Por conse#u-ncia, a materializao do risco ora em desta#ue pode
conduzir 7 e,ecuo de desembolsos e,cessivos, contrapondo0se ao princ2pio constitucional da
economicidade e ao princ2pio do plane)amento, bem como a atrasos na entrega do produto final ao
cliente 'rea demandante(, opondo0se ao princ2pio constitucional da efici-ncia
!:. >isco @!E iniciao de novo ciclo sem #ue os produtos constru2dos na etapa anterior
ten+am sido validados
!:.@ 5 processo de construo do software por mtodos geis comumente d0se de forma
cont2nua ao longo de ciclos, iteraes ou sprints, nos #uais um con)unto de funcionalidades
implementado Algumas vezes, as funcionalidades a serem implementadas em um ciclo so
dependentes do funcionamento de outras, implementadas em ciclos anteriores
!:.! 8esse tipo de situao, poss2vel #ue o ciclo no #ual as funcionalidades previamente
implementadas ainda no ten+a sido validado, isto , o produto gerado ainda no teve seu
recebimento definitivo efetivado pela instituio contratante /aso esse produto no se)a aceito, o
novo ciclo cu)as funcionalidades so interdependentes e ) iniciado fica pre)udicado, ocasionando
potenciais atrasos na construo do software
!:1 >isco @.E falta de plane)amento ade#uado do software a ser constru2do
!:1@ A doutrina gil pode levar instituies pblicas com e#uipes ine,perientes ou sem n2vel
de con+ecimento tcnico ade#uado ao entendimento e#uivocado de seu uso, relegando o ade#uado
plane)amento do produto a ser constru2do 5 plane)amento pode ser iniciado, de forma global, pela
3H
elaborao de documento da viso do produto e, de forma espec2fica, pela preparao do bac(log do
produto 'grooming(, conforme estabelecido, por e,emplo, no framewor( Scrum 'item @@A(
!:1! A rea tcnica da instituio contratante, por e,emplo, pode entender #ue as fases de
levantamento e de definio dos re#uisitos do software devem ocorrer, unicamente, durante as
iteraes de desenvolvimento %al entendimento pode ter como conse#u-ncias poss2veis a falta de
consist-ncia e de detal+amento da lista de funcionalidades a serem desenvolvidas 'bac(log do
produto(, bem como a necessidade de alteraes do produto, comprometendo sua #ualidade e
elevando o custo do pro)eto
!:3 >isco @1E pagamento pelas mesmas funcionalidades do software mais de uma vez, em
virtude de funcionalidades imposs2veis de serem implementadas em um nico ciclo, ou em virtude da
alterao de funcionalidades ao longo do desenvolvimento do software
!:3@ A construo do software utilizando mtodos geis usualmente d0se em ciclos,
iteraes ou sprints, os #uais possuem prazo fi,o para seu trmino 'time0bo,( 8esses ciclos,
funcionalidades do produto so selecionadas para serem implementadas Podem e,istir
funcionalidades cu)o prazo da iterao no se)a suficiente para sua implementao completa, sendo
necessrios outros ciclos para a sua concluso 8esses casos, os ciclos trataro de desenvolver novas
funcionalidades para a#uelas parcialmente implementadas %ambm poss2vel #ue, para a
implementao de uma nova funcionalidade, uma outra ) implementada necessite ser a)ustada
!:3! 6ssas situaes, caso no previstas ade#uadamente no instrumento convocatrio,
podem fazer com #ue a instituio contratante efetue pagamentos pelas mesmas funcionalidades do
software repetidas vezes, conflitando com o princ2pio constitucional da economicidade
!:4 >isco @3E no disponibilizao do software em ambiente de produo para a utilizao e
avaliao dos reais usurios
!:4@ "m dos ob)etivos dos mtodos geis a satisfao do cliente por meio da entrega
adiantada e cont2nua de software funcional
!:4! "ma das formas de avaliar a satisfao do cliente disponibilizando o software no
ambiente de produo, mesmo #ue para um reduzido grupo de usurios, em um pro)eto piloto 5
ob)etivo dessa ao permitir #ue os usurios validem e opinem acerca das funcionalidades do
produto, constru2das predominantemente segundo a viso do indicado pela rea de negcios '+roduct
wner(
!:4. 5 uso do software pelos reais usurios possibilita a verificao de sua ader-ncia 7s
necessidades do negcio Dessa forma, a demora na disponibilizao do software para a validao
)unto aos usurios tem como conse#u-ncia potencial a deteco tardia de erros de concepo, com
conse#uente desperd2cio de recursos e esforo
!9.1 Vuando a e#uipe de fiscalizao visitou o ?acen, constatou0se #ue o ?anco ) tin+a
finalizado alguns pro)etos no Bmbito do /ontrato 3A1@!C!A@!, nos #uais foram gerados softwares
#ue ainda no tin+am sido disponibilizados no ambiente de produo
!:9 >isco @4E forma de pagamento no baseada em resultados
!:9@ A mtrica popularmente adotada nas contrataes para produo de software pelas
instituies pblicas o ponto de funo 5 ponto de funo mede o taman+o funcional do software, e
no o esforo envolvido em sua concepo e construo
!:9! 6sse fato comumente criticado pelas empresas fornecedoras, uma vez #ue a utilizao
do ponto de funo para remunerar os produtos por elas constru2dos pode no ser compat2vel com o
esforo despendido e, por conse#u-ncia, com os recursos financeiros por ela consumidos em sua
produo
!:9. 8o Bmbito de contrataes privadas, comum a utilizao de outras formas de
remunerao do fornecedor, como pagamento por iteraes ou sprints e pagamento por lin+as de
cdigo 'Source 1ines of 0ode L S10(, #ue consiste em uma mtrica utilizada para mensurar o
taman+o de um software /umpre observar #ue algumas das formas adotadas na esfera privada no
3O
consideram o resultado gerado pelo produto entregue A remunerao da contratada por iteraes ou
sprints, por e,emplo, constitui0se, na realidade, em pagamento por disponibilidade de mo de obra
!:91 De forma a utilizar especificaes usuais praticadas no mercado, conforme preceitua o
]!Y do art .Y do Decreto .333C!AAA, o #ual regulamenta o prego, a instituio contratante pode
ver0se impelida a instituir em seu instrumento convocatrio modelo de remunerao desvinculado da
mensurao por resultados, em afronta 7 farta )urisprud-ncia deste %ribunal de /ontas, a #ual se
encontra consolidada na $mula %/" !4=E
I8as contrataes para a prestao de servios de tecnologia da informao, a remunerao
deve estar vinculada a resultados ou ao atendimento de n2veis de servio, admitindo0se o pagamento
por +ora trabal+ada ou por posto de servio somente #uando as caracter2sticas do ob)eto no o
permitirem, +iptese em #ue a e,cepcionalidade deve estar prvia e ade#uadamente )ustificada nos
respectivos processos administrativosJ 'grifo nosso(
!913 "ma poss2vel conse#u-ncia da materializao do risco do pagamento somente pela
disponibilizao de mo de obra reside no recebimento de produtos de software sem #ualidade,
resultando no no atendimento da necessidade da contratao
G. 0oncluso
!:: 5 con+ecimento ad#uirido neste levantamento permitiu entender a ess-ncia #ue orienta
as metodologias geis de desenvolvimento de software, as #uais voltam seu foco, primordialmente,
para o atendimento das necessidades do cliente por meio da entrega cont2nua de softwares funcionais
e de #ualidade
!:= Por sua vez, as anlises empreendidas no decorrer da e,ecuo desta fiscalizao
demonstram a viabilidade da adoo de metodologias geis em contrataes destinadas ao
desenvolvimento de software pela Administrao Pblica Federal 'APF(, assim como outras tantas
metodologias #ue t-m sido amplamente utilizadas ao longo dos ltimos anos
!=A /omo em todo processo de contratao, + riscos #ue precisam ser considerados e
mitigados /ontudo, no caso espec2fico de adoo de mtodos geis, tratados como novidade no
mercado especializado nacional, sobretudo no Bmbito da APF, a gesto de riscos inerentes 7s
caracter2sticas do mtodo merece ateno especial, no sentido de possibilitar #ue as instituies
pblicas possam fazer uso das prticas previstas sem incorrer em descumprimento dos normativos
vigentes
!=@ Por fim, cumpre registrar #ue o presente trabal+o de fiscalizao cumpriu o ob)etivo
inicialmente vislumbrado, consistindo seu benef2cio em servir de instrumento #ue suporte eventuais
fiscalizaes #ue tratem desse tema a serem realizadas por esta unidade tcnica especializada, no
+avendo benef2cios pecunirios
H. +roposta de encaminhamento
!=! Diante do e,posto, prope0se o encamin+amento dos autos ao gabinete do ;inistro <os
;cio ;onteiro com as propostas #ue seguemE
!=!@ levantar o sigilo deste processo em virtude de conter informaes relevantes 7s
instituies pblicas #uanto 7s contrataes de servios de desenvolvimento de software utilizando
mtodos geis, mantendo0se o sigilo da pea !9 destes autos, uma vez #ue contm documentos #ue
no foram tornados pblicos pelas respectivas instituies proprietriasF
!=!! enviar, para con+ecimento, cpia do acrdo #ue vier a ser proferido 7 $ecretaria de
$olues de %& e 7 $ecretaria de /ontrole 6,terno de A#uisies Uog2sticas, ambas vinculadas a este
%ribunal de /ontasF
!=!. ar#uivar os presentes autos, com fulcro no art @4=, inciso W, do >&%/".P
= o reat.rio.
87T7
3K
0m anQiseI evantamento de auditoria reaizado $ea #eGti *om o obRetivo de *on%e*er a
utiizaF"o de MmLtodos QDeisP nas *ontrataFSes $ara desenvovimento de software $ea AdministraF"o
+Jbi*a 3edera. 7s traba%os Goram eGetuados em entidades $Jbi*as 1ue RQ detTm *on%e*imento
a*er*a dessa metodooDiaI dentre as 1uais se in*uem o )an*o Centra do )rasi &)a*en'I o Tribuna
#u$erior do Traba%o &T#T'I o Instituto do +atrim,nio -ist.ri*o e Art/sti*o Na*iona &I$%an'I o
Instituto Na*iona de 0studos e +es1uisas 0du*a*ionais An/sio Tei2eira &Ine$' e o #u$remo Tribuna
3edera &#T3'.
2. 7s MmLtodos QDeisP *onstituem um novo $aradiDma $ara a *onstruF"o de sistemas
inGormatizadosI ainda $ou*o diGundidos na*ionamenteI $rin*i$amente no Embito das instituiFSes
$Jbi*as. No entantoI sua adoF"o tem se mostrado *res*ente. 9essa GormaI a #eGti entendeu ne*essQrio
a$roGundar seu *on%e*imento te.ri*o a*er*a do temaI veriGi*ar de 1ue Gorma est"o o*orrendo as
*ontrataFSes $Jbi*as $ara desenvovimento de software *om base nesses mLtodosI bem *omo
identiGi*ar ris*os asso*iados a essas *ontrataFSes.
3. As metodooDias rea*ionadas a esse *on*eito $ro$Sem diversas sim$iGi*aFSes *om reaF"o
aos mLtodos tradi*ionais de desenvovimento de software. 0m essTn*iaI bus*am um $ro*esso mais
eGi*ienteI $or meio da eiminaF"o de des$erd/*ios e da entreDa de $rodutos mais *Leres e Gre1uentes.
#eus Gundamentos $re*eituam: a vaorizaF"o de indiv/duos e sua interaF"o mais 1ue $ro*essos e
Gerramentas( a *oaboraF"o entre *ontratante e *iente a*ima da neDo*iaF"o de *ontratos( e a a*eitaF"o
natura de mudanFas de re1uisitos do $rodutoI ante a obriDaF"o de se seDuir um $ano. 0ssa nova
abordaDem $ressu$Se $rQti*as *omo $aneRamento breveI e2e*uF"o $or iteraFSesI reduF"o e2$ressiva
da do*umentaF"o de software e maior autonomia dos desenvovedores. 7 $resente traba%o des*reve
de Gorma deta%ada os Gundamentos te.ri*os e tL*ni*as das metodooDias QDeis 1ue tTm sido
re*entemente em$reDadas em *ontrataFSes $Jbi*as de sistemas de inGormaF"oI denominadas ScrumI
eXtreme Proramm!" &XP' e #a"$a".
4. 0ssa sim$iGi*aF"o $ro$osta $eo modeo $odeI sob *ertos as$e*tosI ser *onGitante *om as
$arti*uaridades inerentes Us *ontrataFSes $Jbi*asI em es$e*iaI *om a ne*essidade de $aneRamento e
os $rin*/$ios da im$essoaidade e da vin*uaF"o ao instrumento *onvo*at.rio. No entantoI a anQise de
e2$eriTn*ias em$reendidas $eas entidades Gis*aizadas $ermitiu veriGi*ar a e2istTn*ia dessa
$reo*u$aF"o e 1ueI mediante *ertas *auteasI L $oss/ve ain%ar a utiizaF"o dos MmLtodos QDeisP aos
$re*eitos eDais 1ue reDem a esGera $Jbi*a.
N. Com$ementado o evantamentoI a unidade tL*ni*a identiGi*ou uma sLrie de ris*os inerentes
U adoF"o dessa nova abordaDem no setor $Jbi*oI dentre os 1uais desta*o a $ossibiidade de se $reterir
um $aneRamento ade1uado e de se adotar Gorma de $aDamento n"o baseada em resutados. A*er*a
deste JtimoI observa-se 1ue a remuneraF"o da *ontratada $or iteraFSesI 1ue *onstitui uma Gorma de
$aDamento $or dis$onibiidade de m"o de obraI L *omum na esGera $rivada. 0ssa $rQti*aI no entantoI L
tratada *omo e2*e$*ionaidade $ea Ruris$rudTn*ia desta CorteI *onsubstan*iada na #Jmua TC! 26K:
M8as contrataes para a prestao de servios de tecnologia da informao, a remunerao
deve estar vinculada a resultados ou ao atendimento de n2veis de servio, admitindo0se o pagamento
por +ora trabal+ada ou por posto de servio somente #uando as caracter2sticas do ob)eto no o
permitirem, +iptese em #ue a e,cepcionalidade deve estar prvia e ade#uadamente )ustificada nos
respectivos processos administrativosP
6. 3eitas essas *onsideraFSesI entendo 1ue o evantamento reaizado $ea #eGti atendeu a
*ontento seus obRetivosI 1ue se restrinDem ao estudo da nova metodooDia e U sua a$i*aF"o nas
*ontrataFSes $Jbi*asI raz"o $ea 1ua a*o%o a $ro$osta de ar1uivamento dos autosI sem $reRu/zo da
retirada do siDio de suas $eFasI U e2*eF"o da nJmero 2HI em Ga*e da reevEn*ia das inGormaFSes $ara
as instituiFSes 1ue $ro*ederem Us men*ionadas *ontrataFSes.
40
Ante o e2$ostoI voto $or 1ue o Tribuna adote o a*.rd"o 1ue ora submeto ao +enQrio.
TC!I #aa das #essSes 4inistro Lu*iano )rand"o Aves de #ouzaI em 2O de aDosto de 2013.
A7#= 4@CI7 47NT0I67
6eator
ACC69<7 NV 2314/2013 W TC! W +enQrio
1. +ro*esso nV TC 010.663/2013-4
2. >ru$o I W Casse 8 W Levantamento de Auditoria
3. Interessado: Tribuna de Contas da !ni"o
4. !nidades: Tribuna #u$erior do Traba%o &T#T'( )an*o Centra do )rasi &)a*en'( Instituto do
+atrim,nio -ist.ri*o e Art/sti*o Na*iona &I$%an'( Instituto Na*iona de 0studos e +es1uisas
0du*a*ionais An/sio Tei2eira &Ine$'( #u$remo Tribuna 3edera &#T3'
N. 6eator: 4inistro AosL 4J*io 4onteiro
6. 6e$resentante do 4inistLrio +Jbi*o: n"o atuou
H. !nidade TL*ni*a: #e*retaria de 3is*aizaF"o de Te*nooDia da InGormaF"o - #eGti
O. AdvoDado *onstitu/do nos autos: n"o %Q
K. A*.rd"o:
8I#T7#I reatados e dis*utidos estes autos de evantamento de auditoria reaizado $ea #eGti
*om o obRetivo de *on%e*er a utiizaF"o de MmLtodos QDeisP nas *ontrataFSes $ara desenvovimento de
software $ea AdministraF"o +Jbi*a 3ederaI
AC769A4 os 4inistros do Tribuna de Contas da !ni"oI reunidos em #ess"o do +enQrioI
*om Gundamento no art. 4VI X 2V da 6esouF"o 2N4/2013 do TC!I art. 16KI in*iso 8 do 6eDimento
Interno do TC!I e ante as razSes e2$ostas $eo 6eatorI em:
K.1. evantar o siDio deste $ro*essoI $or *onter inGormaFSes reevantes Us instituiFSes $Jbi*as
1uanto Us *ontrataFSes de serviFos de desenvovimento de software utiizando MmLtodos QDeisPI U
e2*eF"o da $eFa 2HI uma vez 1ue *ontLm do*umentos 1ue n"o Goram tornados $Jbi*os $eas
res$e*tivas instituiFSes $ro$rietQrias(
K.2. determinar U #eGti 1ue a$roGunde os estudosI in*usive *om reaizaF"o de Gis*aizaFSesI se
Gorem ne*essQriasI visando a identiGi*arI *om maior $re*is"oI os ris*os envovidos na utiizaF"o dos
MmLtodos QDeisP na *ontrataF"o de desenvovimento de software $ea AdministraF"o +Jbi*a 3ederaI
seDundo o modeo atua de *ontrataF"oI de maneira a orientar ade1uadamente os Rurisdi*ionados deste
Tribuna(
K.3. dar *iTn*ia desta de*is"o U #e*retaria de #ouFSes de TI e U #e*retaria de Controe 02terno
de A1uisiFSes LoD/sti*as deste Tribuna de Contas(
K.4. ar1uivar os $resentes autos.
10. Ata nY 33/2013 W +enQrio.
11. 9ata da #ess"o: 2O/O/2013 W 7rdinQria.
12. C.diDo eetr,ni*o $ara o*aizaF"o na $QDina do TC! na Internet: AC-2314-33/13-+.
13. 0s$e*iGi*aF"o do 1uorum:
41
13.1. 4inistros $resentes: Arodo Cedraz &na +residTn*ia'I Zaton Aen*ar 6odriDuesI )enRamin
:[merI 6aimundo CarreiroI AosL AorDeI AosL 4J*io 4onteiro &6eator' e Ana Arraes.
13.2. 4inistro-#ubstituto $resente: AuDusto #%erman Cava*anti.
&Assinado 0etroni*amente'
A67L97 C096A:
A7#= 4@CI7 47NT0I67
na +residTn*ia 6eator
3ui $resente:
+A!L7 #7A60# )!>A6IN
+ro*urador->era
42

Acordao Legado 116247

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Acordao Legado 116247

Enviado por

Direitos autorais:

Formatos disponíveis

TRIBUNAL DE CONTAS DA UNIO TC 010.

Você também pode gostar