Acordao Legado 116247

TRIBUNAL DE CONTAS DA UNIO TC 010.
663/2013-4

1

GRUPO I CLASSE V PLENRIO
TC 010.663/2013-4
Natureza: Levantamento de Auditoria
Interessado: Tribunal de Contas da Unio
Unidades: Tribunal Superior do Trabalho (TST); Banco Central do
Brasil (Bacen); Instituto do Patrimnio Histrico e Artstico
Nacional (Iphan); Instituto Nacional de Estudos e Pesquisas
Educacionais Ansio Teixeira (Inep); Supremo Tribunal Federal
(STF)

SUMRIO: LEVANTAMENTO DE AUDITORIA.
CONHECIMENTO ACERCA DA UTILIZAO DE MTODOS
GEIS NAS CONTRATAES PARA DESENVOLVIMENTO
DE SOFTWARE PELA ADMINISTRAO PBLICA
FEDERAL. CUMPRIMENTO DOS OBJETIVOS.
ARQUIVAMENTO.

RELATRIO

Transcrevo a seguir o relatrio de levantamento elaborado no mbito da Secretaria de
Fiscalizao de Tecnologia da Informao - Sefti (pea 177), registrado no Sistema Fiscalis sob o
nmero 290/2013, aprovado pelos dirigentes daquela unidade tcnica:
1. 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.
2. Uma vez que a Secretaria de Fiscalizao de Tecnologia da Informao (Sefti) julga ainda
no deter a expertise necessria para atuar em fiscalizaes que envolvam esse tipo de metodologia,
esta unidade tcnica props a realizao de levantamento com vistas a conhecer as bases tericas do
processo de desenvolvimento de software com mtodos geis, bem como conhecer experincias
prticas de contratao realizadas por instituies pblicas federais, objetivando o aprendizado desta
secretaria em relao ao tema.
3. Com esse intuito, a Sefti, juntamente com a Secretaria de Solues de TI (STI) deste
Tribunal, unidade que j possui certo conhecimento em mtodos geis em decorrncia de experincia
em desenvolvimento de softwares realizado internamente utilizando essa metodologia, identificou
instituies pblicas que possuem contratos cujo objeto de interesse desta fiscalizao e visitou
algumas delas. As visitas serviram para colher informaes, por meio de relatos informais, acerca da
adoo do paradigma de desenvolvimento em comento em seus contratos, bem como inteirar-se do
contedo dos instrumentos convocatrios que os originaram.
4. Como resultado do levantamento realizado, este relatrio apresenta conceitos que
abrangem a essncia das metodologias geis de desenvolvimento de software, descreve as principais
metodologias atualmente utilizadas pelas instituies pblicas brasileiras visitadas durante a
execuo do levantamento, relata aspectos das contrataes analisadas e, por fim, relaciona alguns
riscos inerentes passveis de materializao nas contrataes com metodologias geis.
2. Introduo

TRIBUNAL DE CONTAS DA UNIO TC 010.663/2013-4

2

5. Ao longo dos ltimos anos, as contrataes realizadas por instituies pblicas federais
para construo de sistemas informatizados tm se baseado em metodologias de desenvolvimento de
software aliceradas, em sua maioria, no Processo Unificado de desenvolvimento de sistemas e suas
variaes.
6. Observa-se, contudo, o aumento da popularidade do uso de metodologias geis de
desenvolvimento de software no mercado nacional e internacional. Essa realidade, somada s
insatisfaes frequentes das contrataes de servios geradas pelo uso do modelo corrente, tem
levado algumas instituies pblicas a acreditarem que podem obter melhores resultados com o uso
das metodologias geis. Nesse cenrio, instituies pblicas iniciaram investimentos nessa rea,
capacitando seus servidores e instituindo internamente em suas equipes de tecnologia da informao,
quando possvel, mtodos geis para o desenvolvimento de suas solues. Passado esse movimento
inicial, algumas dessas instituies comearam a realizar contrataes para desenvolvimento de
software, seja para projetos especficos, seja para fbricas de software, fundamentadas em
metodologias geis.
7. Com esse contexto e dada a falta de conhecimento aprofundado acerca do tema por esta
Secretaria de Fiscalizao de Tecnologia da Informao (Sefti) que possibilite bem desempenhar seu
poder fiscalizador, urgiu buscar a expertise necessria para suas futuras atuaes quando
demandada.
8. Nessa esteira, previamente realizao desta fiscalizao, membros da Sefti foram
capacitados por meio de participao em curso presencial relativo ao Scrum, uma das metodologias
geis mais adotadas atualmente em projetos de desenvolvimento de software. Em seguida, esta
unidade tcnica submeteu proposta ao Ministro Jos Mcio Monteiro visando realizao de
levantamento para a aquisio de maior conhecimento acerca do tema, a qual foi prontamente
deferida.
9. A submisso da proposta ao Relator decorreu do fato de o Banco Central do Brasil (Bacen),
instituio integrante de sua clientela, ser uma instituio pblica reconhecidamente possuidora de
experincia no desenvolvimento de softwares por meio de mtodos geis.
10. Para complementar e enriquecer as informaes deste levantamento, outras organizaes
pblicas com experincia na execuo de projetos utilizando mtodos geis foram visitadas durante
esta fiscalizao.
11. Unindo esforos conjuntos da Sefti e da Secretaria de Solues de TI (STI) deste Tribunal,
o presente levantamento foi executado, buscando-se absorver conceitos tericos em diversas fontes,
como publicaes fsicas e eletrnicas, e observar relatos baseados na vivncia prtica de algumas
instituies pblicas federais que investiram, nos anos recentes, na contratao de desenvolvimento de
software com metodologias geis.
12. Como resultado do trabalho empreendido, na primeira parte deste relatrio a equipe do
presente levantamento consolidou diversas informaes, definies e conceitos colhidos relativos a
metodologias de desenvolvimento de software, geis ou no, de forma a construir o embasamento
terico necessrio ao entendimento dos relatos das experincias vividas pelas instituies pblicas
visitadas. Na segunda parte, o relatrio descreve aspectos tcnicos das contrataes realizadas pelas
instituies pblicas que receberam a equipe. Por ltimo, este relatrio ainda confronta os valores
que norteiam as metodologias geis com os princpios que orientam a Administrao Pblica, bem
como apresenta alguns riscos inerentes ao tipo de contratao em estudo.
13. Impende ressaltar que este trabalho no tem o intuito de esgotar as discusses sobre as
caractersticas e os riscos da utilizao de metodologias geis mediante o arcabouo normativo
brasileiro. Trata-se de uma viso geral e primeira sobre o assunto, que subsidia esta Secretaria a
tratar com o tema de maneira mais precisa.
2.1. Deliberao que originou o trabalho
14. A presente fiscalizao foi originada de proposta elaborada pela Secretaria de
Fiscalizao de Tecnologia da Informao (Sefti) no mbito do TC 009.890/2013-0, com fins


3

realizao de levantamento acerca da utilizao de mtodos geis nas contrataes para
desenvolvimento de software pela Administrao Pblica Federal.
15. Em 19/4/2013, por meio de despacho, o Ministro-Relator Jos Mcio Monteiro autorizou a
proposta formulada pela Sefti (pea 17).
2.2. Objetivo e escopo
16. A presente fiscalizao tem por objetivo descrever a definio da essncia dos mtodos
geis, os quais se constituem em uma metodologia para o desenvolvimento de softwares.
Adicionalmente, este trabalho objetiva descrever como algumas instituies pblicas federais esto
realizando contrataes utilizando mtodos geis, assim como apresentar alguns riscos associados a
essas contrataes.
17. A anlise dos contratos identificados no mbito desta fiscalizao, luz da conformidade
legislao vigente, no faz parte do escopo deste trabalho.
2.3. Metodologia e limitaes
18. Inicialmente, em concordncia com os padres de levantamento definidos pelo TCU, por
meio de pesquisas na internet e em virtude do conhecimento tcnico da Secretaria de Solues de TI
(STI), a equipe de fiscalizao identificou quatorze instituies pblicas federais que potencialmente
teriam contratos de desenvolvimento de software utilizando mtodos geis. Dessas instituies,
conforme o tempo existente para a fase de execuo da fiscalizao e utilizando o critrio de
localizao geogrfica, beneficiando as instituies com sede em Braslia/DF, foram selecionadas
sete para visitao e entrevistas com os gestores dos contratos, a saber:
18.1. Tribunal Superior do Trabalho (TST);
18.2. Banco Central do Brasil (Bacen);
18.3. Instituto do Patrimnio Histrico e Artstico Nacional (Iphan);
18.4. Instituto Nacional de Estudos e Pesquisas Educacionais Ansio Teixeira (Inep);
18.5. Supremo Tribunal Federal (STF);
18.6. Departamento de Informtica do Sistema nico de Sade (Datasus); e
18.7. Empresa Brasileira de Servios Hospitalares (EBSERH).
19. Das instituies visitadas, verificou-se que somente as cinco primeiras possuam objeto de
interesse para este trabalho. Diante disso, a equipe de fiscalizao obteve, para anlise, os
respectivos editais de licitao.
20. Alm dos rgos supracitados, a equipe de fiscalizao tambm se reuniu com o Servio
Federal de Processamento de Dados (Serpro), o qual foi contratado para desenvolver mdulos do
sistema Novo Siafi para a Secretaria do Tesouro Nacional utilizando mtodos geis. Uma vez que,
contratualmente, no foi definida a utilizao da metodologia gil, o contrato balizador do ajuste no
foi analisado.
21. Como limitao para o presente trabalho, pode-se citar que, ainda que a equipe de
fiscalizao tenha obtido, em certa medida, conhecimento terico e prtico, o pleno conhecimento
sobre as metodologias geis abrange um vasto domnio que no pde ser atingido pela equipe durante
a execuo deste trabalho, devido ao reduzido perodo de tempo para a sua realizao.
3. Viso geral do objeto
22. O presente trabalho trata de levantamento acerca da viabilidade da adoo de
metodologias geis de desenvolvimento de software por instituies pblicas federais em suas
contrataes, considerando suas caractersticas e seus principais riscos mediante o arcabouo
jurdico vigente. Para melhor entender o objeto desta fiscalizao, inicialmente faz-se necessria a
abordagem de conceitos tericos e das origens de algumas metodologias de desenvolvimento de
sistemas de informao que tm sido largamente utilizadas na histria recente da engenharia de
software.
3.1. Metodologias de desenvolvimento de software
Produto de Software


4

23. A ISO/IEC 12207-1998 uma norma tcnica elaborada pela International Organization
for Standardization (ISO) que trata de processos de ciclo de vida de software. Ela define conceitos e
prope uma estrutura comum para padronizar a discusso em torno de procedimentos, mtodos,
ferramentas e ambientes de desenvolvimento e de gerncia de software.
24. Segundo a norma citada, produto de software um conjunto de programas de computador,
procedimentos e possvel documentao e dados associados, enquanto servio de software a
execuo de atividades, trabalho ou obrigaes relacionados ao produto de software, tais como seu
desenvolvimento, manuteno e operao.
25. Para efeitos didticos, neste texto tratar-se- software como sinnimo de produto de
software.
Metodologia de desenvolvimento de software
26. De acordo com o dicionrio Aurlio, no campo da literatura, metodologia definida como
o conjunto de tcnicas e processos utilizados para ultrapassar a subjetividade do autor e atingir a
obra literria. J o dicionrio Webster, no ramo da computao, conceitua metodologia como um
conjunto organizado de procedimentos e guias documentados para a execuo de uma ou mais fases
do ciclo de vida do software.
27. Alinhando-se a essas definies, em engenharia de software, uma metodologia de
desenvolvimento comumente entendida como um conjunto estruturado de prticas que pode ser
repetvel durante o processo de produo do sistema ou, ainda, a forma de se utilizar um conjunto de
prticas, mtodos ou processos para se desenvolver ou manter um produto de software, de modo que
se evite subjetividade na execuo do trabalho. O uso de metodologias visa produtividade das
equipes e qualidade do produto.
28. As metodologias de desenvolvimento de software surgiram em um contexto tecnolgico
muito diferente do atual, baseado apenas em solues para computadores de grande porte
(mainframes) e terminais burros, poca na qual o custo para se fazer alteraes e correes nos
sistemas era muito elevado. Isso se deu em decorrncia do limitado acesso aos computadores e da
inexistncia de modernas ferramentas de apoio ao desenvolvimento.
29. Por sua vez, a definio de processo de software se assemelha de metodologia de
desenvolvimento de software, conforme se depreende da leitura combinada dos conceitos de processo
e de software constante das normas NBR ISO/IEC 15504-1 e 12207: conjunto de atividades que se
inter-relacionam ou que interagem entre si, que transforma entradas em um conjunto de programas de
computador, procedimentos, possvel documentao e dados associados.
30. Atualmente, modelos de melhoria de processos de software, como o CMMI e o MPS-Br,
bem como a jurisprudncia deste Tribunal (Acrdos 953/2009, 1.233/2012, 3.132/2012 e 1.167/2013,
todos do Plenrio do TCU), tm utilizado o termo processo de software em detrimento a
metodologia de desenvolvimento de software, embora as definies de ambos sejam, em essncia,
idnticas.
31. De todo modo, este trabalho utilizar, excepcionalmente, o termo metodologia de
desenvolvimento de software, no intuito de se aproximar da linguagem utilizada pelos especialistas
em mtodos geis, objeto deste trabalho.
Metodologia em cascata ou clssica
32. Nos anos 1970 difundiu-se internacionalmente uma das mais conhecidas metodologias de
desenvolvimento de software, o modelo em cascata (waterfall), tambm conhecido como clssico ou
linear. Nessa metodologia, largamente utilizada at o incio da dcada de 1990, o sistema todo
planejado e documentado, seguindo diversas fases, sequencialmente, antes de ser implementado. As
atividades do processo de desenvolvimento so estruturadas em uma ordem fixa de fases (cascata), na
qual as sadas de cada fase geralmente documentos aps aprovadas, tornam-se entradas para a
prxima. Espera-se, no fim da ltima fase, que o produto de software esteja pronto, baseando-se na
premissa de que o trabalho nas fases anteriores foi realizado de maneira correta e gerou os produtos
que delas se esperava.


5

33. Embora tenha auxiliado a engenharia de software quando 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 s
necessidades emergentes. Fomentaram-se, ento, diversas crticas a esse modelo, como a
impossibilidade de retornar de modo simples execuo de atividades em fases anteriores e a
excessiva produo de documentao nas fases iniciais do projeto. Isso causava, respect ivamente,
uma elevao significativa do custo das mudanas no projeto e demora na disponibilizao do
software.
Metodologia baseada em prototipao
34. Frequentemente, dado o dinamismo dos problemas empresariais sobre os quais o sistema
atuar, o cliente possui um conjunto de objetivos genricos para o software, geralmente conhecidos, e
um conjunto de detalhes especficos, no identificados minuciosamente no momento de sua concepo.
Por outro lado, em alguns casos, o desenvolvedor necessita assegurar a eficincia de um algoritmo, a
adaptabilidade de um sistema operacional ou a forma que a interao homem-mquina deve ter no
sistema a ser construdo.
35. Para auxiliar nessas questes, surgiu a prototipao, que consiste em um processo no qual
o desenvolvedor pode criar um modelo do software que deve ser construdo. O modelo pode assumir
vrias formas, inclusive a construo de um prottipo que implementa um subconjunto das
funcionalidades requeridas do software desejado.
36. O processo de prototipao iterativo, repetindo-se fases bem definidas, basicamente para
colher e refinar requisitos. Portanto, o objetivo construir o prottipo e obter o feedback do cliente
em fases iniciais do projeto. O prottipo serve como mecanismo para identificar os requisit os do
software, raramente servindo como produto final, uma vez que foi construdo s pressas, sem
considerar importantes aspectos do software, como sua qualidade geral a longo prazo, seu
desempenho e sua usabilidade.
37. Por isso, a prototipao tem como grande problema a criao da expectativa do cliente
que enxerga o prottipo como uma verso funcional do software, enquanto o mesmo foi fragilmente
construdo de modo a validar um conjunto de requisitos iniciais. Esse 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.
Metodologia Espiral
38. O modelo em espiral, proposto em 1988, foi desenvolvido para abranger as melhores
caractersticas do modelo clssico (cascata) e do modelo de prototipao, adicionando, ao mesmo
tempo, a anlise de riscos, no presente nessas outras metodologias.
39. Como o prprio nome referencia, o modelo representado por uma espiral na qual, para o
desenvolvimento do software, atividades de quatro fases (planejamento, 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 engenharia de software. A cada
iterao dessas fases, uma verso construda e, medida que as iteraes avanam, as verses
tornam-se mais completas, de forma progressiva.
40. O modelo em espiral aproxima o cliente do processo de desenvolvimento ao permitir que,
de sua avaliao do produto, surjam sugestes e modificaes, isto , a avaliao do cliente
fundamenta as prximas etapas de planejamento e anlise de riscos.
41. Essa metodologia apresenta como principal problema o risco da perpetuao do
desenvolvimento, dado o seu carter evolutivo.
Metodologia de Processo Unificado
42. Em paralelo ao aparecimento do modelo clssico, no final da dcada de 1960, em projeto
desenvolvido por Ivar Jacobson na empresa de telefonia Ericsson, surgiram as origens da
metodologia de desenvolvimento denominada Processo Unificado (Unified Process UP). Em 1987,
ao sair da Ericsson, Jacobson fundou a empresa Objectory Systems, renomeada, em 1991, para


6

Objectory AB. Essa companhia despendeu anos de esforos para o desenvolvimento do ObjectOry, o
qual consistia em um mtodo de desenvolvimento de softwares orientado a objetos.
43. Em 1995, com a experincia adquirida ao longo de seus projetos, Jacobson lanou o livro
Object-Oriented Engineering, no qual propunha a idia de que os requisitos do cliente deveriam ser a
fora diretiva mais importante no desenvolvimento de software, alm de mostrar a gnese da nfase
do Processo Unificado na arquitetura dos sistemas. Ainda naquele ano, a empresa Rational Software
Corporation adquiriu a Objectory Systems e, no mbito do produto Rational Objectory Process
(ROP), continuou o desenvolvimento do ObjectOry, expandindo-o para reas ainda no abordadas,
como ferramentas de gerenciamento e de desenvolvimento de projetos.
44. medida que o ROP progredia, a empresa Rational continuava a adquirir empresas
fabricantes de ferramentas de desenvolvimento de software ou a elas se fundir. As ferramentas
adquiridas agregaram valor ao produto ROP e, em 1998, a Rational alterou o seu nome para
Rational Unified Process (RUP). Assim, passou a consistir em uma verso comercial do UP,
framework ou metodologia de desenvolvimento que foi construda praticamente de forma simultnea
ao RUP, tambm pela empresa Rational.
45. Contrapondo-se ao modelo em cascata, o UP props-se como uma metodologia de
desenvolvimento iterativa e incremental, caractersticas herdadas do modelo espiral. No UP, as
quatro fases de desenvolvimento do sistema (concepo, elaborao, construo e transio) so
repetidas em ciclos, obtendo-se, ao trmino de cada ciclo, uma verso funcional do software. Em
acrscimo, o UP tambm se props a ser adaptativo, de forma a atender s necessidades especficas
de cada projeto.
46. O surgimento do Processo Unificado trouxe diversas vantagens ao processo de
desenvolvimento de softwares quando comparado ao modelo em cascata. Algumas delas so: a
entrega de verses com mais constncia, precipitando o feedback sobre o produto; a antecipao em
identificar as mudanas, diminuindo o custo das alteraes no decorrer do desenvolvimento; o
controle dos riscos inerentes ao projeto; o foco no produto; e o aumento da qualidade do produto
final
47. Contudo, as organizaes que produzem e contratam projetos de construo de software,
na tentativa de adotar o UP e suas variantes, como o RUP, no raramente desvirtuam suas principais
caractersticas (iteratividade e incrementalidade), e terminam por realizar adaptaes nas quais a
prpria essncia do modelo se perde. Nesses casos, as atividades de construo de software, que
deveriam ser executadas vrias vezes em vrios ciclos, passam a ser executadas uma nica vez, de
maneira puramente sequencial, similar ao que ocorre no modelo em cascata, desvirtuando o conceito
fundamental relacionado gerao incremental que agregue valor ao negcio.
Metodologias geis
48. Alm das metodologias anteriormente citadas, atualmente est em voga a utilizao de
metodologias geis.
49. As metodologias geis so representadas por um conjunto de valores e princpios a ser
utilizado no processo de desenvolvimento de sistemas. Esse conjunto de valores e princpios foi
externado em 2001, por meio da divulgao do Manifesto para Desenvolvimento gil de Software,
criado por um grupo de dezessete especialistas em processos de desenvolvimento de software que,
individualmente, j utilizavam prticas e teorias adaptadas.
50. O Manifesto para Desenvolvimento gil de Software, tambm conhecido apenas como
Manifesto gil, foi alicerado em um pequeno conjunto de princpios que, segundo os autores,
pareciam ter sido recorrentemente respeitados nos casos de sucesso dos seus projetos.
51. Embora alguns profissionais acreditem que a essncia e as prticas adotadas pelas
metodologias geis sejam modernas e inovadoras, pode-se dizer que sua origem remonta aos anos que
sucederam Segunda Guerra Mundial, no mbito da empresa Toyota. Naquela poca, a indstria
japonesa tinha uma produtividade muito baixa e uma enorme falta de recursos, o que dificultava a
adoo do modelo de produo em massa. Nesse contexto, a Toyota desenvolveu um sistema de


7

produo chamado de Lean Manufacturing (produo enxuta) ou Toyota Production System (TPS)
Sistema de Produo Toyota, em portugus cujo objetivo consistia em aumentar a eficincia da
produo pela eliminao contnua de desperdcios. O TPS contemplava diversas caractersticas ou
prticas incorporadas s metodologias geis, entre as quais se destacam:
51.1. construir apenas o que necessrio, eliminando desperdcios;
51.2. realizar entregas rpidas e contnuas;
51.3. estar sempre aberto s mudanas.
52. O Manifesto gil, transcrito a seguir, apresenta e descreve a essncia de um conjunto de
abordagens para desenvolvimento de software que vem sendo adotado desde a dcada de 1990.
Manifesto gil
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e
ajudando outros a faz-lo. Atravs deste trabalho, passamos a valorizar:
Indivduos e interao entre eles mais que processos e ferramentas
Software em funcionamento mais que documentao abrangente
Colaborao com o cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.
53. Alm dos valores expressos no manifesto, foram formulados os princpios que os
sustentam, apresentados a seguir:
54. Princpio 1: nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e
contnua de software de valor.
54.1. A priorizao na construo das funcionalidades que o software deve possuir feita com
base na importncia que elas tm para o cliente e no seu valor para o negcio, e no em outros
critrios, como a complexidade da funcionalidade a ser implantada.
54.2. A entrega de verses intermedirias do software deve existir e ser incremental,
antecipando ao mximo a sua utilizao pelos usurios, a fim de aferir, pelo efetivo uso, se o seu
funcionamento atende a suas expectativas. Essa caracterstica tambm possibilita planejar melhor a
construo dos requisitos seguintes, j que a equipe e os usurios possuiro uma experincia na
utilizao do que j est pronto.
55. Princpio 2: aceitar mudanas de requisitos, mesmo ao fim do desenvolvimento. Processos
geis se adquam a mudanas para que o cliente possa tirar vantagens competitivas.
55.1. A entrega frequente de partes do software em pleno funcionamento e o mais cedo
possvel possibilita que se construa um ambiente de constante feedback a respeito das necessidades do
cliente. Observa-se que tal feedback normalmente fomenta mudanas recorrentes dos requisitos por
parte do cliente.
55.2. Os processos ditos geis tratam a mudana nas necessidades do cliente como algo
natural e necessrio para a construo de um software adequado. Tanto melhor for a percepo do
usurio na utilizao real do sistema, formas melhores de resolver problemas ao longo do projeto
podem ser idealizadas e construdas em conjunto.
56. Princpio 3: entregar software funcionando com frequncia, na escala de semanas at
meses, com preferncia aos perodos mais curtos.
56.1. Durante o projeto de desenvolvimento, recomenda-se que entregas parciais e funcionais
sejam feitas com a maior frequncia possvel, para assegurar, o quanto antes, se o que est sendo
construdo realmente atende s necessidades dos clientes e dos usurios, mitigando, portanto, alguns
riscos do projeto.
57. Princpio 4: pessoas relacionadas a negcios e desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o curso do projeto.
57.1. No cerne desse princpio, est o acesso e a comunicao entre as pessoas da equipe que,
independente do papel de cada uma, deve ser o mais simples possvel. Ferramentas automatizadas e


8

encontros frequentes devem ser utilizados a fim de que a transferncia de conhecimento no acontea
apenas por meio de produo e leitura de documentos, e sim por meio da comunicao informal.
57.2. Alm disso, esse princpio materializa a posio de que o sucesso do projeto depende da
dedicao e disponibilidade das pessoas envolvidas. Isso inclui uma maior participao do cliente em
todas as fases do projeto, a fim de elucidar os requisitos, definir regras de negcio, dirimir dvidas
durante a construo das funcionalidades e avaliar prontamente o funcionamento dos softwares
intermedirios que forem sendo construdos.
58. Princpio 5: construir projetos ao redor de indivduos motivados, dando a eles o ambiente
e suporte necessrio, e confiar que faro seu trabalho.
58.1. A motivao dos membros da equipe advm da disponibilizao de um ambiente de
trabalho saudvel, constitudo de ferramentas e instrumentos adequados para a execuo do seu
trabalho. Por sua vez, a confiana entre os membros da equipe necessria para promover o
ambiente colaborativo. E no ambiente colaborativo que surgem solues com qualidade.
59. Princpio 6: o mtodo mais eficiente e eficaz de transmitir informaes, para e por dentro
de um time de desenvolvimento, atravs de uma conversa cara a cara.
59.1. A produo de documentos, planilhas, modelos e diagramas no deve substituir o dilogo
contnuo entre o cliente e a equipe de desenvolvimento. responsabilidade primordial da equipe
tcnica prover as melhores solues tecnolgicas e do cliente transmitir adequadamente as
necessidades e regras do negcio. Segundo os princpios, por meio da colaborao entre os membros
da equipe, aumentam consideravelmente as chances de se alcanar os objetivos do projeto.
60. Princpio 7: software funcional a medida primria de progresso.
60.1. A principal medida de sucesso e progresso de um projeto de desenvolvimento de software
ter o programa de computador em operao, com as funcionalidades sendo homologadas pelo
cliente.
60.2. Este princpio no dispensa a elaborao da documentao produzida pelas equipes,
nem mesmo d menos importncia aos profissionais que no produzam programas de computador
propriamente ditos. A proposta que no se considere que o projeto est evoluindo com sucesso tendo
como base somente a produo de documentao. Programas em funcionamento, em ltima instncia,
so o que definem o progresso do projeto de desenvolvimento de software.
61. Princpio 8: processos geis promovem um ambiente sustentvel. Os patrocinadores,
desenvolvedores e usurios devem ser capazes de manter, indefinidamente, passos constantes.
61.1. Recomenda-se que se mantenha, de forma equilibrada durante o projeto, o atendimento a
todos os princpios. O sucesso dos projetos vem do equilbrio e da constncia na adoo de cada um
dos princpios.
62. Princpio 9: contnua ateno excelncia tcnica e ao bom design aumenta a agilidade.
62.1. Aumentar a agilidade significa, entre outras coisas, que o retorno do investimento em um
projeto seja maximizado. Atentar-se excelncia tcnica, em paralelo a todos os outros princpios,
aumenta as chances de gerar um produto de qualidade e, por consequncia, 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.
63. Princpio 10: simplicidade, ou seja, a arte de maximizar a quantidade de trabalho que no
precisou ser feito.
63.1. importante que sejam desenvolvidas funcionalidades no software exatamente como
foram solicitadas, resistindo-se tentao de desenvolver funcionalidades para atender a futuros
problemas que ainda no existem.
64. Princpio 11: as melhores arquiteturas, requisitos e designs emergem de times auto-
organizveis.
64.1. A auto-organizao baseia-se na idia de que necessrio horizontalizar as decises de
um time de alto desempenho. O modelo onde um gerente pensa de modo restrito nas tarefas de um
projeto e as distribui para o restante da equipe no favorece a concepo de boas solues. A ordem


9

se constri com a participao ativa dos membros da equipe, independentemente do seu papel, e da
construo de um senso de grupo. baseado nessa mesma teoria que, hoje, softwares de nvel
mundial so desenvolvidos de maneira livre (open-source), com colaborao remota de membros, sem
que pessoas tenham que controlar quem faz o qu.
64.2. Com o estudo deste princpio, observa-se que a gerncia 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.
65. Princpio 12: em intervalos regulares, o time reflete sobre como se tornar mais efetivo.
Ento, ajustam-se e otimizam seu comportamento de acordo.
65.1. Nenhum processo de software perfeito. Recomenda-se que, de tempos em tempos, as
pessoas reflitam sobre o processo, identificando pontos falhos e possveis oportunidades de melhoria.
A idia que o aperfeioamento peridico do processo permite a melhoria contnua no processo de
trabalho, a fim de produzir software de qualidade.
66. Nessa esteira, entende-se como Metodologia gil de desenvolvimento de software o
conjunto de mtodos, processos e frameworks que so norteados pelos valores e princpios acima
descritos.
67. Com fins puramente didticos, ao longo deste relatrio, as metodologias no gei s sero
agrupadas em um conjunto que se convencionou denominar metodologias tradicionais.
3.2. Principais metodologias geis de desenvolvimento de software
68. Atualmente, vrias metodologias geis so utilizadas pelo mercado mundial para o
desenvolvimento de software, tais como: eXtreme Programming, Scrum, Feature Driven
Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software
Development (ASD), Crystal, Pragmatic Programming, Test Driven Development (TDD), Kanban,
entre outras.
69. No Brasil, segundo o Relatrio Tcnico RT MAC-2012-03 do Departamento de Cincia da
Computao do Instituto de Matemtica e Estatstica da Universidade de So Paulo (IME-USP), de
maio de 2012 (pea 18), fundamentado em pesquisa sobre a adoo de prticas em times e
organizaes brasileiras, as metodologias mais utilizadas so Scrum, eXtreme Programming (XP) e
a combinao entre elas. Uma vez que o trabalho em campo identificou que essas metodologias,
acrescidas do Kanban, so as mais utilizadas nas instituies pblicas visitadas, elas sero descritas
sucintamente a seguir.
3.2.1. Scrum
70. Em 1986, Takeuchi e Nonaka publicaram um artigo na revista Harvard Business Review,
descrevendo uma nova abordagem para desenvolvimento de produtos. Empresas como 3M e Canon
inovaram na forma de desenvolver seus produtos, a fim de que o processo produtivo fosse mais rpido
e os produtos chegassem ao mercado o quanto antes. A organizao das equipes nessas empresas se
assemelhava formao scrum dos times nos jogos de rugby, com composio multidisciplinar,
constante interao entre os membros, que trabalhavam juntos do incio ao fim do processo produtivo
para entregar um produto.
71. Inspirados nesse artigo, Ken Schwaber e Jeff Sutherland desenvolveram o Scrum, que
consiste em um framework que pode ser utilizado para desenvolver e manter produtos complexos. Sua
definio encontrada no Guia do Scrum (pea 19), no qual seus criadores documentam como o
framework foi desenvolvido e mantido por eles por mais de vinte anos. livre e oferecido por seu
Guia, que pode ser obtido gratuitamente no stio eletrnico www.scrum.org. Por tal motivo, as
definies e informaes a seguir apresentadas, foram extradas de seu prprio guia oficial.
72. Segundo a viso geral do Guia, o Scrum pode ser definido como:
Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e
adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possvel.
Scrum :
- Leve


10

- Simples de entender
- Extremamente difcil de dominar
Scrum um framework estrutural que est sendo usado para gerenciar o desenvolvimento de
produtos complexos desde o incio de 1990. Scrum no um processo ou uma tcnica para construir
produtos; em vez disso, um framework dentro do qual voc pode empregar vrios processos ou
tcnicas. O Scrum deixa claro a eficcia relativa das prticas de gerenciamento e desenvolvimento de
produtos, de modo que voc possa melhor-las. (pea 19, p. 3)
73. O Scrum fundamentado nas teorias empricas de controle de processo, ou empirismo,
segundo o qual o conhecimento vem da experincia e de tomada de decises baseada no que
conhecido. Tambm emprega uma abordagem iterativa e incremental para aperfeioar a
previsibilidade e o controle de riscos (pea 19, p. 4).
74. O Scrum consiste nas equipes ou times Scrum, as quais so associadas a papeis, eventos,
artefatos e regras. Cada componente dentro do framework serve a um propsito especfico e
essencial para o uso e sucesso da metodologia. Suas regras integram os eventos, papeis e artefatos,
administrando as relaes e interaes entre eles (pea 19, p. 5).
Papeis do Scrum
Time Scrum
75. Um time Scrum composto pelo Product Owner (PO), pela equipe de desenvolvimento e
pelo Scrum Master. Os times so auto-organizveis e multifuncionais. Equipes auto-organizveis
escolhem a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de
fora da equipe. Equipes multifuncionais possuem todas as competncias necessrias para completar o
trabalho sem depender de outros que no fazem parte da equipe. O modelo de equipe projetado para
aperfeioar a flexibilidade, criatividade e produtividade (pea 19, p. 5).
76. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as
oportunidades de feedback. Entregas incrementais de produto pronto garantem que uma verso
potencialmente funcional do produto do trabalho esteja sempre disponvel (pea 19, p. 5).
Product Owner
77. O Product Owner (PO), ou dono do produto, o responsvel por maximizar o valor do
produto e do trabalho da equipe de desenvolvimento. A maneira como isso feito pode variar
amplamente entre as organizaes, times Scrum e indivduos. O PO a nica pessoa responsvel por
gerenciar o backlog do produto, por meio de tarefas que incluem (pea 19, p. 5):
77.1. expressar claramente os itens do backlog do produto;
77.2. ordenar ou priorizar esses itens para melhor alcanar as metas e misses;
77.3. garantir o valor do trabalho realizado pelo time de desenvolvimento;
77.4. garantir que o backlog do produto seja visvel, transparente, claro para todos, e mostrar
no que o time Scrum trabalhar a seguir; e
77.5. garantir que a equipe de desenvolvimento entenda os itens do backlog do produto no
nvel necessrio.
78. O backlog do produto definido nos itens 106 a 110 deste relatrio.
79. O Product Owner pode desempenhar essas atividades ou deleg-las para que a equipe de
desenvolvimento as faa. No entanto, o PO continua sendo o responsvel. Importa ressaltar que o
Product Owner uma pessoa e no um comit. Ele pode representar o desejo de um comit no
backlog do produto, mas aqueles que desejarem uma alterao nas prioridades dos itens de backlog
devem convencer o PO a tomar essa deciso. Para que o Product Owner tenha sucesso, toda a
organizao deve respeitar as suas decises, que so visveis no contedo e na priorizao do backlog
(pea 19, p. 5-6).
Equipe de desenvolvimento
80. A equipe de desenvolvimento consiste de profissionais que realizam o trabalho de entregar
uma verso potencialmente utilizvel que incrementa o produto pronto ao final de cada sprint.


11

Somente integrantes da equipe de desenvolvimento criam incrementos do produto de software (pea
19, p. 6).
81. As equipes de desenvolvimento so estruturadas e autorizadas pela instituio para
organizar e gerenciar seu prprio trabalho. A sinergia resultante aperfeioa a sua eficincia e
eficcia como um todo. Elas possuem as seguintes caractersticas (pea 19, p. 6):
81.1. so auto-organizadas, isto , ningum (nem mesmo o Scrum Master) diz equipe como
transformar o backlog do produto em incrementos de funcionalidades potencialmente utilizveis;
81.2. so multifuncionais, possuindo todas as habilidades necessrias, enquanto equipe, para
criar o incremento do produto;
81.3. o Scrum no reconhece ttulos para os integrantes da equipe que no seja o de
desenvolvedor, independentemente do trabalho que est sendo realizado pela pessoa, no havendo
excees para esta regra;
81.4. individualmente, os integrantes da equipe de desenvolvimento podem ter habilidades
especficas e reas diferentes de especializao, mas a responsabilidade pertence equipe como um
todo;
81.5. equipes de desenvolvimento no contm subequipes dedicadas a domnios especficos de
conhecimento, tais como teste ou anlise de negcios.
Scrum Master
82. O Scrum Master o responsvel por garantir que o Scrum seja entendido e aplicado, de
forma a assegurar que o time Scrum adere teoria, prticas e regras da metodologia. um servo-
lder para o time. Ainda tem como atribuio ajudar aqueles que esto fora do time a entender quais
as suas interaes com o time so teis e quais no so, objetivando maximizar o valor criado pelo
time Scrum (pea 19, p. 7).
83. O Scrum Master trabalha para atender s necessidades do Product Owner, encontrando
tcnicas para o gerenciamento efetivo do backlog do produto; comunicando claramente a viso,
objetivo e itens do backlog do produto para a equipe de desenvolvimento; ensinando o time Scrum a
criar itens de backlog do produto de forma clara e concisa; compreendendo, a longo prazo, o
planejamento do produto no ambiente emprico; compreendendo e praticando a agilidade; e
facilitando os eventos Scrum conforme exigidos ou necessrios (pea 19, p. 7).
84. Por sua vez, trabalha tambm para auxiliar a equipe de desenvolvimento, treinando-a em
autogerenciamento e interdisciplinaridade; ensinando-a e liderando-a na criao de produtos de alto
valor; removendo impedimentos para o seu progresso; facilitando os eventos Scrum conforme
exigidos ou necessrios; e treinando a equipe de desenvolvimento em ambientes organizacionais nos
quais o Scrum no totalmente adotado e compreendido (pea 19, p. 7).
85. Por fim, o Scrum Master tambm trabalha auxiliando a instituio, liderando e treinando
a organizao na adoo da metodologia; planejando implementaes Scrum dentro da organizao;
ajudando funcionrios e partes interessadas a compreender e tornar aplicvel o Scrum e o
desenvolvimento de produto emprico; causando mudanas que aumentam a produtividade do time; e
trabalhando com outro Scrum Master para aumentar a eficcia da aplicao da metodologia na
organizao (pea 19, p. 7).
Eventos do Scrum
86. Eventos prescritos so usados para criar uma rotina e minimizar a necessidade de reunies
no definidas. O Scrum usa eventos time-boxed, ou seja, espaos de tempo nos quais todo evento
tem uma durao mxima definida, garantindo que uma quantidade adequada de tempo seja gasta no
planejamento, sem permitir perdas ao longo desse processo (pea 19, p. 8).
87. Alm da sprint, que um container para outros eventos, cada evento no Scrum uma
oportunidade formal para inspecionar e adaptar alguma coisa, sendo especificamente projetado para
permitir transparncia e inspeo criteriosa. A no incluso de qualquer um dos eventos resultar na
reduo da transparncia e na perda de oportunidade para inspecionar e adaptar (pea 19, p. 8).
Sprint


12

88. O corao do Scrum a sprint, um time-box de um ms corrido ou menos, durante o qual
uma verso incremental potencialmente utilizvel do produto (pronto) criada. Sprints tem
duraes coerentes em todo o esforo de desenvolvimento. Uma nova sprint inicia-se imediatamente
aps a concluso da anterior. So compostas por uma reunio de planejamento, reunies dirias,
trabalho de desenvolvimento, reviso e retrospectiva (pea 19, p. 8).
89. Quando o horizonte temporal da sprint muito longo, a definio do que ser construdo
pode mudar, a complexidade pode aumentar e o risco pode crescer. Com curtos perodos, permitem
uma previsibilidade que garante a inspeo e adaptao do progresso em direo meta pelo menos
a cada ms corrido (pea 19, p. 8).
90. Durante a sprint, no so feitas mudanas que podem afetar seu objetivo, a composio da
equipe de desenvolvimento permanece constante, as metas de qualidade no diminuem e o escopo
pode ser esclarecido e renegociado entre o Product Owner e a equipe de desenvolvimento medida
que seja melhor entendido (pea 19, p. 8).
91. Cada sprint pode ser considerada um projeto com prazo no maior que um ms, que
contempla a definio do que deve ser construdo e um plano projetado e flexvel para guiar a
construo, o trabalho e o resultado do produto (pea 19, p. 8).
92. Embora incomum, uma sprint pode ser cancelada antes do seu time-box (tempo previsto)
terminar. Porm, somente o PO tem a autoridade para cancel-la, embora possa fazer isso sob
influncia das partes interessadas, da equipe de desenvolvimento ou do Scrum Master. O
cancelamento ocorre se o seu objetivo se tornar obsoleto, ou seja, quando no fizer mais sentido sua
execuo s dadas circunstncias (pea 19, p. 8-9).
Reunio de planejamento da sprint
93. O trabalho a ser realizado na sprint planejado na reunio de planejamento com o
trabalho colaborativo de todo o time Scrum. Possui tempo mximo estabelecido e consiste em duas
partes, cada uma ocupando a metade desse tempo (pea 19, p. 9).
94. Na primeira parte da reunio, define-se o que ser entregue como resultado do incremento
da sprint, sendo atribuio da equipe de desenvolvimento, e somente dela, selecionar os itens
ordenados do backlog do produto previamente apresentado pelo PO que sero implementados (pea
19, p. 9).
95. Aps a equipe de desenvolvimento escolher os itens que sero entregues, o time Scrum
determina a meta da sprint, que consiste em um objetivo que ser conhecido por meio da
implementao do backlog do produto, fornecendo orientao relativa acerca da motivao do
incremento (pea 19, p. 9-10).
96. Na segunda parte da reunio de planejamento, define-se como o trabalho necessrio para
entregar o incremento ser realizado. Os itens de backlog do produto selecionados para a sprint junto
com o plano de entrega desses itens chamado de backlog da sprint (pea 19, p. 10).
Reunio diria
97. A reunio diria do Scrum um evento de no mximo quinze minutos, destinado equipe
de desenvolvimento para sincronizar as atividades e criar um plano para as prximas 24 horas.
feita para inspecionar o trabalho desde a ltima reunio diria, e prever o trabalho que dever ser
feito antes da prxima reunio diria (pea 19, p. 10-11).
98. As reunies dirias melhoram a comunicao, eliminam outras reunies, identificam e
removem impedimentos para o desenvolvimento, destacam e promovem rpidas tomadas de deciso, e
melhoram o nvel de conhecimento da equipe de desenvolvimento (pea 19, p. 11).
Reviso da sprint
99. A reviso da sprint uma reunio informal executada ao seu trmino para inspecionar o
incremento e adaptar o backlog do produto, se necessrio. Assim como os outros eventos, possui
durao mxima pr-estabelecida. Nela, o incremento produzido apresentado, destinando-se a
motivar, obter comentrios e promover a colaborao (pea 19, p. 11).


13

100. Durante a reviso da sprint, o time Scrum e as partes interessadas colaboram sobre o
que foi executado. Com base nisso e em qualquer mudana no backlog do produto, os participantes
colaboram nas prximas tarefas que precisam ser prontas (pea 19, p. 11).
101. Em suma, na reunio de reviso, o PO identifica o que ficou pronto e o que no ficou
pronto; a equipe de desenvolvimento discute o que foi bem durante a sprint, quais problemas
ocorreram e como foram resolvidos; a equipe de desenvolvimento demonstra o trabalho que est
pronto e responde as questes sobre o incremento; o PO discute o backlog do produto tal como est
e projeta as provveis datas de concluso baseado no progresso corrente; e o grupo todo colabora
sobre o que fazer a seguir, fornecendo valiosas entradas para a reunio de planejamento da prxima
sprint (pea 19, p. 12).
102. O resultado da reunio de reviso da sprint um backlog do produto revisado que define
o provvel backlog do produto para a prxima sprint. O backlog tambm pode ser ajustado
completamente para atender novas oportunidades (pea 19, p. 12).
Retrospectiva da sprint
103. A retrospectiva da sprint uma oportunidade para o time Scrum revisar a si prprio e
criar um plano de melhorias a serem aplicadas na prxima sprint. Ocorre depois da reunio de
reviso e antes da reunio de planejamento da prxima sprint. uma reunio com durao mxima
pr-estabelecida (pea 19, p. 12).
104. Durante cada reunio de retrospectiva, o time Scrum planeja formas de aumentar a
qualidade do produto, adaptando a definio de pronto, quando apropriado. Ao seu final, o time
Scrum dever ter identificado melhorias que sero implementadas na prxima sprint (pea 19, p. 12).
Artefatos do Scrum
105. Os artefatos do Scrum representam o trabalho ou o valor de vrias maneiras teis para
prover transparncia e oportunidades para inspeo e adaptao. Os artefatos definidos no Scrum
so especificamente projetados para maximizar a transparncia das informaes-chave necessrias
para assegurar que o time Scrum tenha sucesso na entrega do incremento pronto (pea 19, p. 12).
Backlog do produto
106. O backlog do produto uma lista ordenada ou priorizada de tudo que deve ser necessrio
no produto, e uma origem nica dos requisitos para qualquer mudana a ser feita nele. O PO
responsvel pelo backlog do produto, incluindo seu contedo, disponibilidade e ordenao ou
priorizao (pea 19, p. 13).
107. Partindo-se da premissa de que os primeiros desenvolvimentos apenas estabelecem os
requisitos inicialmente conhecidos e melhor entendidos, entende-se que o backlog do produto nunca
est completo. Ao contrrio, ele evolui tanto quanto o produto e o ambiente no qual ele ser utilizado
evoluem. Tambm dinmico, mudando constantemente para identificar o que o produto necessita
para ser mais apropriado, competitivo e til. Existe enquanto perdurar o produto (pea 19, p. 13).
108. O backlog do produto lista todas as caractersticas, funes, requisitos, melhorias e
correes que formam as mudanas que devem ser feitas no produto em futuras verses, consistindo
de um grupo de itens com atributos de descrio, ordem e estimativa. Geralmente, esses itens so
ordenados por valor, risco, prioridade e necessidade. Os itens no topo da lista do backlog do produto
determinam as atividades de desenvolvimento mais imediatas. Quanto maior sua posio no topo da
lista, mais o item deve ser considerado e mais consenso existe em relao a ele e ao seu valor para o
produto (pea 19, p. 13).
109. Uma vez que os itens do backlog do produto de ordem mais alta devem ser os primeiros a
serem implementados, eles devem ser mais claros e detalhados que os itens de ordem mais baixa,
possibilitando estimativas mais precisas. Os itens do backlog do produto que iro ocupar o
desenvolvimento na prxima sprint so mais refinados, tendo sido decompostos de modo que todos os
seus componentes possam ser prontos dentro da sprint seguinte. Os itens do backlog do produto que
podem ser implementados pela equipe de desenvolvimento so considerados como disponveis ou
executveis para seleo durante a reunio de planejamento (pea 19, p. 13).


14

110. A preparao do backlog do produto (grooming) o ato de adicionar detalhes, estimar e
ordenar ou priorizar seus itens. um processo contnuo exercido em tempo parcial e de forma
colaborativa entre o PO e a equipe de desenvolvimento. Contudo, somente a equipe de
desenvolvimento, responsvel pela efetiva construo do produto, que tem a atribuio de realizar
as estimativas (pea 19, p. 14).
Backlog da sprint
111. O backlog da sprint um conjunto de itens do backlog do produto selecionados para a
sprint, adicionado do plano para entrega do incremento do produto a ser utilizado, intencionando o
alcance do objetivo da sprint. a previso da equipe de desenvolvimento sobre qual funcionalidade
estar no prximo incremento e do trabalho necessrio para entreg-la (pea 19, p. 14).
Incremento
112. O incremento a soma de todos os itens do backlog do produto concludos durante a
sprint, acrescido de todos os outros das sprints anteriores. Ao final da sprint, um novo incremento
deve estar pronto, o que significa que deve estar na condio utilizvel e atender a definio de
pronto do time Scrum. Este deve estar na condio utilizvel independentemente do Product Owner
decidir por liber-lo ou no (pea 19, p. 15).
113. Alm dos papis, eventos e artefatos do Scrum, o conceito de pronto tambm
explorado no Guia do Scrum.
114. Quando o item do backlog do produto ou um incremento descrito como pronto, todos
devem entender o que o pronto significa. Embora possa variar significativamente entre diversos
times Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho
estar completo, assegurando a transparncia. Essa a Definio de Pronto para o time, usada para
avaliar se o incremento do produto est, de fato, concludo (pea 19, p. 14).
115. A mesma definio deve orientar a equipe de desenvolvimento na avaliao de quantos
itens do backlog do produto podem ser selecionados na reunio de planejamento da sprint (pea 19,
p. 14).
116. medida que times Scrum amadurecem, esperado que a definio de pronto seja
expandida para incluir critrios mais rigorosos que assegurem maior qualidade ao produto.
117. Por fim, cumpre registrar que, de acordo com o Guia do Scrum, seus papeis, artefatos,
eventos e regras so imutveis e, embora seja possvel implementar somente partes da metodologia, o
resultado no Scrum, que existe somente na sua totalidade, funcionando bem como um container
para outras tcnicas, metodologias e prticas (pea 19, p. 16).
3.2.2 eXtreme Programming (XP)
118. Em 1996, Kent Beck, um dos signatrios do Manifesto gil, se tornou gerente responsvel
pelo Chrysler Comprehensive Compensation System, projeto de desenvolvimento para substituio
dos softwares que processavam a folha de pagamento da empresa Chrysler, tambm conhecido como
C3. A partir de ento, Kent comeou a refinar os mtodos que utilizava para desenvolver programas e
passou a escrever o primeiro livro sobre a metodologia batizada por ele como eXtreme
Programming, mais conhecida como XP.
119. O software que foi desenvolvido era um estudo de caso de adoo de programao
orientada por objetos, e Kent Beck foi inicialmente convidado a fazer parte da equipe com objetivo de
realizar melhorias de desempenho na aplicao. No entanto, ao assumir a liderana da equipe,
introduziu prticas nas quais acreditava que trariam melhoria para o software em desenvolvimento.
Assim nasceu o XP, como uma compilao das melhores prticas utilizadas no projeto C3.
120. Atualmente, vrias dessas prticas evoluram e o XP j pode ser adotado em situaes
que no guardam muita relao com o contexto no qual surgiu. Ao contrrio de Scrum, que foca
principalmente nas prticas relacionadas gerncia, XP d mais ateno s tarefas de programao
em si.
121. Apesar de ser considerado um conjunto de melhores prticas, XP traz, na sua proposta,
tambm valores e princpios. Os valores so critrios gerais e abstratos, enquanto as prticas so


15

claras e concretas. Os princpios, por sua vez, fazem a ligao entre os valores e as prticas. A seguir,
os valores, princpios e prticas so apresentados sucintamente.
Valores
122. Valor 1: comunicao.
122.1. Enquanto os clientes tm viso dos problemas que desejam solucionar, os
desenvolvedores dominam as tcnicas que influenciam a forma de resolver o problema apresentado
pelo cliente. O resultado do software to bom quanto a capacidade de ambos se comunicarem.
122.2. Existem diversas formas para se estabelecer essa comunicao, mas algumas se
apresentam como melhores do que outras. Dilogos so mais eficazes que videoconferncias que, por
sua vez, so melhores que telefonemas, sendo esses mais expressivos que emails e assim
sucessivamente. O dilogo presencial evita que problemas de m compreenso e ambiguidades
comprometam negativamente o produto final.
123. Valor 2: coragem.
123.1. Durante o desenvolvimento de um software, natural que as funcionalidades
inicialmente imaginadas pelo cliente e desenvolvidas pela equipe sofram alteraes, seja porque os
clientes imaginaram outras formas de resolver o problema, seja porque o time descobriu novas
solues. um aprendizado natural, mas que, em metodologias tradicionais, envolve uma tendncia
da equipe se proteger de mudanas, buscando garantias de que os rumos mantenham-se inalterados.
123.2. Este valor do XP preza pela proteo. A equipe estabelece mecanismos para evitar que
uma alterao futura seja um transtorno ou represente um risco grande ao projeto. Algumas prticas
foram propostas com esse fim.
124. Valor 3: feedback.
124.1. sabido que, quanto mais cedo um problema descoberto, menos prejuzos ele pode
causar e maiores so as chances de resolv-lo de forma barata em um projeto de desenvolvimento de
software. Por isso, XP incentiva que se encurte ao mximo a defasagem de tempo entre o momento em
que uma ao executada e que o seu resultado observado. Assim, existe um incentivo ao constante
feedback, mesmo que, pra isso, as entregas de novas funcionalidades sejam realizadas no menor
prazo possvel.
125. Valor 4: respeito.
125.1. Outro valor do XP o respeito, no apenas pelos outros membros da equipe, mas
tambm respeito a si prprio. Alteraes que comprometam negativamente o trabalho de outros
desenvolvedores no devem ser feitas. E cada desenvolvedor deve se comprometer entregando o
produto com a maior qualidade possvel.
126. Valor 5: simplicidade.
126.1. Simplicidade guarda relao com a mxima difundida pela Toyota a partir da dcada
de 1950: no se deve produzir mais que o necessrio. Concluiu-se que o Princpio de Pareto tambm
se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou
mais do benefcio esperado. um grande desperdcio entregar funcionalidades que no agregam
valor ao negcio.
Princpios
127. O princpio da auto-semelhana sugere que, quando equipes XP encontrarem solues
que funcionem em um contexto, tambm devem procurar adot-las em outras situaes, mesmo que em
escalas diferentes. O princpio do benefcio mtuo, por sua vez, prega que prticas que no beneficiem
todos os envolvidos so capazes de destruir relacionamentos e criar mais dificuldades ainda nos
projetos.
128. Outro ponto a assuno de que, em se tratando de software, diferentes abordagens para
um mesmo problema podem implicar em enormes diferenas no tempo e custo de implementao da
soluo. O princpio da diversidade ajuda a complementar as solues e torn-las mais ricas.


16

129. Quando duas abordagens para resolver um problema parecerem equivalentes,
recomenda-se testar as duas e no ter medo de errar. O princpio da falha preceitua que com os erros
advm novos conhecimentos.
130. Por outro lado, o princpio da economia estabelece que, ao se desenvolver software,
importante implementar as funcionalidades que puderem gerar maior retorno financeiro o mais cedo
possvel. Ao mesmo tempo, o princpio da fluidez estabelece que, ao invs de impor obstculos, por
meio de etapas bem definidas, deve-se permitir que o desenvolvedor aprenda sobre um requisito 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 princpio da melhoria preceitua que, no se deve buscar a perfeio em cada uma dessas etapas,
mas sim aperfeioar esses e outros aspectos dos projetos, em um processo de melhoria contnua.
131. O princpio da oportunidade considera que problemas eventualmente encontrados devem
ser vistos como oportunidades de aprendizado e mudana, levando a atitudes mais proveitosas para
todos os envolvidos. Errar algo natural em qualquer projeto e ocorre de tempos em tempos. Erros
no devem ser temidos, a abrangncia dos mesmos e o tempo necessrio para descobri-los que deve
ser uma preocupao. Quando os erros so descobertos rapidamente e abrangem um escopo pequeno
do trabalho, solucion-los torna-se mais fcil. Por isso, segundo o princpio dos passos de beb ou
pequenos passos, melhor avanar um pouco de cada vez, ao invs de tentar grandes passos sem
validar suas consequncias. Todos esses princpios conduzem ao princpio da qualidade, que deve ser
o foco durante todo o projeto de desenvolvimento do software. Existe uma crena de que alta
qualidade significa gastos mais elevados. No h dvidas de que qualidade tenha preo, mas a falta
dela tem um preo ainda maior.
132. Ainda com foco na qualidade, o princpio da redundncia apresenta-se como outra
maneira de garanti-la. Os problemas difceis e crticos em desenvolvimento de software devem ser
resolvidos de vrias formas diferentes. Mesmo que uma soluo falhe completamente, as outras iro
prevenir um desastre. O custo da redundncia pago pela economia de no ter um desastre. O
princpio da reflexo recomenda que as equipes no apenas faam seu trabalho, mas tambm pensem
sobre como esto trabalhando e por que motivos esto-no fazendo. Devem analisar o porqu de terem
resultado em sucesso ou fracasso. No devem tentar esconder seus erros, mas exp-los e aprender
com eles.
133. Finalmente, o princpio da responsabilidade define que esta no pode ser atribuda, s
pode ser aceita. Quando uma responsabilidade atribuda a um indivduo, somente ele pode decidir
se a aceita ou no.
Prticas
134. Em XP, as prticas distinguem-se em dois grupos: primrias e corolrias. As primeiras
podem ser adotadas imediatamente, de forma segura, para melhorar o esforo de desenvolvimento de
software. Por sua vez, as prticas corolrias so mais difceis de serem implementadas antes de se
adotarem as prticas primrias. Assim, devem ser usadas com maior cautela e com segurana de que
a equipe e o ambiente encontram-se maduros para tal.
135. So prticas primrias: Ambiente Informativo, Build de Dez Minutos, Ciclo Semanal,
Ciclo Trimestral, Desenvolvimento Orientado a Testes, Design Incremental, Equipe Integral, Folga,
Histrias, Integrao Contnua, Programao em Par, Sentar-se Junto e Trabalho Energizado.
136. So prticas corolrias: Anlise da Raiz do Problema, Base de Cdigo Unificada, Cdigo
Coletivo, Cdigo e Testes, Continuidade da Equipe, Contrato de Escopo Negocivel, Envolvimento do
Cliente Real, Equipes que Encolhem, Implantao Diria, Implantao Incremental e Pagar Por Uso.
3.2.3 Kanban
137. Kanban uma palavra japonesa e significa carto visual. Essa palavra utilizada para
descrever o sistema que a empresa Toyota utiliza desde a dcada de 1950 para controlar a linha de
produo de seus veculos. Como mencionado anteriormente (item 51), o Sistema de Produo Toyota
objetiva aumentar a eficincia da produo pela eliminao contnua de desperdcios.


17

138. A metodologia Kanban para desenvolvimento de software foi proposta por David J.
Anderson e define um framework para melhoria incremental de processos e sistemas em
organizaes. A adoo do Kanban ancorada na filosofia de que, para aperfeioar um processo,
deve-se comear com o que se est fazendo agora, concordar em buscar mudanas incrementais e
evolucionrias, alm de respeitar o processo atual, com seus papeis, responsabilidades e cargos.
Destaca-se tambm a necessidade de fomentar a postura de liderana em todos os nveis da
organizao.
139. A metodologia no define um conjunto especfico de passos ou de funes que 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 j utilizados, para posterior estmulo
melhoria contnua.
140. O aperfeioamento do sistema obtido por meio da melhoria contnua e incremental no
processo. Mudanas radicais no so bem vindas, pois apesar de parecerem mais efetivas, elas tm
probabilidade de erro maior porque a organizao tende a resistir. A idia estimular pequenos
incrementos no processo a fim de se alcanar grandes melhorias no sistema.
141. Respeitar o processo corrente, os papeis, as responsabilidades e os ttulos da organizao
dissipa o medo inicial de adoo de uma nova forma de trabalho, e a iniciativa de implantao da
metodologia se estabelece.
142. O Kanban uma metodologia para impulsionar mudana, mas pouco prescritivo, o que
o diferencia de mtodos como XP e Scrum. No se define, de antemo, como trabalhar ou quais
papis devem ser adotados pela organizao. Conforme declarado por Andersen, o design do sistema
Kanban um processo de pensamento; no uma cpia ou modelo de implementao de processo.
Tambm no substituto para adoo de Scrum ou XP. A adoo de Scrum pode ser utilizada como
ponto de partida para a utilizao de Kanban, e este pode ser um catalisador da melhoria do processo
adotado.
143. Tendo como base esses valores, a adoo de Kanban contempla as seguintes prticas:
Visualizar o trabalho em andamento
144. A visualizao do trabalho em andamento tem como objetivos manter o foco no todo,
estimular a transparncia no progresso das atividades e identificar desperdcios.
145. Para alcanar tais objetivos, deve-se entender o que est sendo feito atualmente; resistir
tentao de realizar mudanas inicialmente; mapear o fluxo de trabalho, identificando estgios e o
tempo que se espera entre eles; e criar um quadro (eletrnico ou fsico) com uma raia para cada
estgio.
Limitar o trabalho em progresso
146. O objetivo dessa prtica identificar gargalos no fluxo, aumentando a produtividade.
Nesse ponto, faz-se necessrio esclarecer os seguintes conceitos:
146.1. sistema kanban (k minsculo): sistema de aperfeioamento de processos de trabalho
baseado na metodologia Kanban (k maisculo);
146.2. tempo de ciclo: tempo que um item leva para passar pelo sistema kanban. Exemplo:
quantas semanas uma histria de usurio leva para ser entregue desde que foi identificada;
146.3. Work In Progress (WIP): total de trabalho em progresso no sistema kanban. Exemplo:
quantidade de histrias de usurio que esto atualmente em progresso;
146.4. produo (throughput): mdia do nmero de itens produzidos em um determinado
perodo de tempo. Exemplo: duas histrias produzidas por semana;
146.5. tempo mdio de ciclo: razo entre total de WIP e produo (WIP/produo). Para
reduzir o tempo mdio, pode-se aumentar a produo ou diminuir o WIP. Aumentar a produtividade
da equipe no o mais fcil, e por isso limitar o WIP aparece como soluo para diminuir o tempo
mdio.
147. A definio do WIP de cada estgio deve seguir o bom senso e as particularidades da
equipe, mas cinco podem ser usados como ponto de partida. Os limites iniciais so apenas palpites


18

que so dados em momentos de pouca informao. medida que se obtm informaes sobre o
sistema e que a forma de trabalho aprimorada, os limites so ajustados.
148. Para evitar gargalos, o tamanho dos itens tambm considerado, pois itens grandes
bloqueiam recursos por muito tempo, enquanto itens pequenos fluem mais rapidamente pelo sistema.
Quebrar histrias de usurios em partes pequenas mnimo de funcionalidade vendvel requer
habilidade.
Explicitar as polticas que esto sendo seguidas
149. A importncia que se d qualidade vem do alto custo de encontrar e corrigir defeitos em
um item depois de sua entrega.
150. As polticas so representadas por padres e listas de verificao para completar uma
tarefa.
151. Para deixar explcitas, as polticas so acrescentadas ao quadro, observando que estgios
podem ser inteiramente dedicados garantia da qualidade.
152. O objetivo final dessa prtica a melhoria na qualidade do produto.
Medir e gerenciar o fluxo
153. O sistema de entrega de software tem capacidade limitada. Pressionar alm da
capacidade tem como consequncia a queda da qualidade.
154. Estimativas de capacidade realizadas no incio de um projeto so palpites baseados em
projetos anteriores. Em um sistema kanban, planos so usados como guias e no como critrio de
sucesso.
155. Para obter um sistema de entrega estvel e previsvel e suportar a tomada de deciso a
respeito de prazos, dependncias, pessoal e escopo, a medio do progresso importante desde o
incio. Porm, toda medio realizada atrelada a um objetivo para evitar medies desnecessrias.
156. So vrios os tipos de medies que podem ocorrer, mas a maioria deles diz respeito
quantidade de trabalho realizado ou que falta ser realizado, tempo de durao do ciclo, ndice de
defeitos do produto e itens bloqueados em estgios no sistema. Grficos com as medies so expostos
junto ao quadro.
157. A fila de entrada dos itens a serem tratados deve estar sempre ordenada de acordo com a
prioridade, a fim de que as pessoas possam puxar os itens que estejam no topo. Para fazer a
priorizao, so levados em considerao diversos fatores: riscos e incertezas; necessidades bsicas,
como infraestrutura; manuteno de tamanho dos itens equilibrados para um fluxo constante; tipos de
histria tambm equilibrados, para manuteno do fluxo de entrega de valor; e dependncias entre os
itens. Definir um item como prioritrio significa abrir mo de priorizar outro. As escolhas devem ser
conscientes.
158. Para buscar a melhoria do sistema, a anlise se apia em filtros de deciso. Os filtros
ajudam a manter o foco na melhoria do fluxo como um todo e no em atividades individuais.
Incentivar a melhoria contnua
159. A adoo das prticas anteriores j permite a identificao de oportunidades de
aperfeioamento, mas o Kanban atinge processo contnuo de melhoria com a adoo de eventos de
retrospectiva de forma cadenciada e regular. Com as reunies de retrospectiva, o time concentra-se
no fluxo e identifica oportunidades de mudanas estruturais maiores.
160. Na Figura 1, observa-se imagem de um quadro fsico extrado do livro Kanban em 10
passos. O sistema apresentado utilizado para aperfeioamento de um processo de desenvolvimento
de software. Os estgios identificados esto dispostos nas raias: Inbox, Specification, Ready for
Development, Development, Code Review, Teste Locally, Test on PreProduction, Ready for Release.
Os nmeros em vermelho, logo abaixo do nome do estgio, representam o limite de WIP para aquele
estgio. Na parte abaixo do quadro, esto as polticas de cada estgio. Os itens esto distribudos em


19

cartes pelas raias. Assim, os grficos acima do quadro deixam transparentes as medies realizadas.

Figura 1: Exemplo de quadro kanban para processo de desenvolvimento de software.
161. O livro Kanban, de David J. Anderson, descreve a abordagem Kanban para sistemas de
aperfeioamento de processos de desenvolvimento de software.
3.3. Comparao entre metodologias geis e metodologias tradicionais
162. Comparando-se as metodologias tradicionais com a essncia que fundamenta os mtodos
geis, possvel destacar quais as diferenas e semelhanas entre as duas metodologias.
Processo adaptativo x processo preditivo
163. 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
que devem ser adaptados, identificar quais desses passos so dispensveis dentro de um determinado
projeto quase sempre se mostra uma tarefa complexa.
164. Os mtodos geis, por outro lado, apresentam-se como ferramentas e mtodos
adaptativos, com poucos procedimentos e papeis, reforando seu foco em melhores prticas,
princpios e valores. Para que um projeto adote uma metodologia gil, necessrio trazer e adaptar
os valores apresentados para o contexto do projeto. Dessa maneira, enquanto as metodologias
tradicionais so chamadas de preditivas, as geis so consideradas adaptativas.
Comunicao direta
165. As metodologias tradicionais so tambm chamadas de pesadas ou orientadas
documentao. Alm de detalharem as atividades que se deve executar 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.
166. Essa abordagem no dispensada pelas metodologias geis, mas h uma valorizao
maior na interao direta entre as pessoas de uma equipe a fim de melhorar a transmisso e
disseminao de conhecimento entre os indivduos.


20

Aceitao da mudana
167. Os mtodos geis introduziram no desenvolvimento de software alguns recursos que
permitem uma maior liberdade para experimentao. Ao invs de exigir do cliente que ele saiba
exatamente qual o comportamento ideal do software a ser desenvolvido logo no incio, como no
modelo cascata, mecanismos foram estabelecidos para que suas funcionalidades sejam revistas, caso
se descubra uma maneira mais adequada para constru-lo, assemelhando-se, em certa medida, ao
modelo em espiral. O processo de experimentao e adaptao incentivado pelos mtodos geis tende
a produzir programas mais adequados s necessidades dos usurios.
Incentivo a ciclos curtos e entregas constantes
168. Apesar de terem sido propostos como iterativos e incrementais, as metodologias baseadas
no processo Unificado (UP) nem sempre atingiram tal objetivo.
169. Por outro lado, os mtodos geis sugerem ciclos de desenvolvimento bastant e curtos,
quase nunca superiores a um ms, incentivando ao mximo que softwares sejam desenvolvidos de
forma iterativa e incremental. Os ciclos curtos tambm possibilitam feedback constante, o que reflete
em maior qualidade para o processo e para o produto.
170. Ainda com objetivo de experimentar e obter feedback, os mtodos geis ressaltam a
importncia de liberar o software em ambiente de produo o mais rpido possvel, de preferncia ao
final de cada ciclo de desenvolvimento, mesmo que poucas funcionalidades tenham sido
implementadas. A certeza de que a evoluo do sistema est acontecendo de maneira adequada s
constatada com o retorno positivo dos usurios reais do produto.
4. Os valores geis e os princpios da Administrao Pblica
171. A essncia dos mtodos geis para desenvolvimento de software baseia-se nos valores
fundamentais contidos no Manifesto gil. Confrontando-se esses valores com os princpios da
Administrao Pblica consignados em dispositivos legais, a exemplo da Constituio Federal e da
Lei de Licitaes e Contratos, possvel avaliar o alinhamento da essncia gil com o ordenamento
jurdico vigente sob a perspectiva da terceirizao pelos rgos pblicos federais, objeto principal
desta fiscalizao. Importa observar que a interpretao desses valores subjetiva, e que a exposta a
seguir corresponde tica de controle desta unidade tcnica.
Indivduos e interao entre eles, mais que processos e ferramentas
171.1. A maior valorizao de indivduos e interao entre eles em detrimento de processos
e ferramentas constitui pilar basilar das equipes de desenvolvimento gil. Contudo, pode entrar em
atrito com o princpio da eficincia por possibilitar que os processos da instituio possam ser
relegados. Adicionalmente, uma vez que o princpio em epgrafe valoriza as pessoas, a substituio de
membros da equipe durante a execuo de um projeto contrasta com o princpio da eficincia, haja
vista que pode acarretar prejuzos produtividade da equipe gil.
171.2. Alm disso, o destaque para os indivduos 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 Tribunal Superior do Trabalho (TST) em seu
Enunciado 331.
Software em funcionamento, mais que documentao abrangente
171.3. A maior valorizao de software em funcionamento em detrimento de documentao
abrangente, embora possa vir ao encontro do princpio da eficincia, possibilitando a incorporao,
de forma mais clere, de sistemas informatizados necessrios misso da Administrao Pblica,
paradoxalmente tambm o fere. Menosprezar a adequada documentao do software contratado pode
ocasionar problemas para a sua manutenibilidade e, por consequncia, a continuidade de
seufuncionamento de modo adequado.
171.4. Para mitigar esse risco, um conjunto mnimo de artefatos entre eles documentos
essenciais sustentao dos softwares deve ser exigido no instrumento convocatrio. Para auxiliar
a tarefa de definio dos artefatos que devem acompanhar o sistema entregue pela contratada a cada


21

iterao, a instituio pode utilizar sua Metodologia de Desenvolvimento de Sistemas (MDS) ou seu
processo de software, adaptado e construdo segundo sua realidade especfica.
Colaborao com o cliente, mais que negociao de contratos
171.5. A maior valorizao da colaborao com o cliente em prejuzo da negociao de
contratos, em primeira anlise, entra em atrito com o princpio da vinculao ao instrumento
convocatrio, uma vez que pode fazer com que a contratada execute servios no cobertos pelo
contrato, ocasionando enriquecimento sem causa da Administrao. Em contrataes pblicas,
imperativo que essa prtica seja abolida.
Responder a mudanas, mais que seguir um plano
171.6. A valorizao de responder a mudanas em detrimento de seguir um plano
contrasta, de imediato, com o princpio fundamental do planejamento, o qual estampado no inciso I
do art. 6 do Decreto-Lei 200/1967, e pode ser conflitante com o princpio da economicidade,
insculpido no art. 70 da Carta Magna de 1988.
171.7. Em tese, fere o princpio do planejamento por permitir que a tarefa de desenvolvimento
de software se afaste das diretrizes e metas inicialmente estipuladas ou, at mesmo, em extremada
circunstncia, a elaborao do planejamento seja desprezada. Adicionalmente, mudanas constantes
podem revelar esforo de planejamento inadequado para a definio dos requisitos do software
contratado.
171.8. Por sua vez, a maior valorizao da resposta a mudanas ope-se ao princpio da
economicidade por exigir da empresa contratada retrabalho para o ajuste s mudanas, podendo
acarretar novos desembolsos ao errio.
171.9. Entretanto, o valor gil em epgrafe tambm vai ao encontro do princpio constitucional
da eficincia ao permitir, por exemplo, a incorporao de novos requisitos oriundos de necessidades
prementes no software em desenvolvimento.
172. Embora em primeira anlise possa transparecer que a utilizao de mtodos geis em
contrataes pblicas para desenvolvimento de software seja impossibilitada pelo conflito existente
entre os seus valores e os princpios da Administrao Pblica, a anlise dos editais e contratos das
instituies pblicas federais visitadas demonstra que, na prtica, possvel alinhar a sua utilizao
aos preceitos legais que regem a esfera pblica.
5. Terceirizao de desenvolvimento de software com mtodos geis nas instituies da
Administrao Pblica Federal visitadas
173. A equipe de fiscalizao visitou cinco rgos que possuam contratos de desenvolvimento
de software utilizando mtodos geis para sua construo, consistindo no objeto de interesse para o
presente levantamento. Ressalte-se que das oito instituies inicialmente selecionadas, apenas cinco
possuam contratos de interesse.
174. A seguir, so apresentados relatos acerca das contrataes analisadas quanto a questes
pertinentes fiscalizao, como mtrica utilizada, forma de gerir as demandas e a execuo dos
servios e nveis de servio estabelecidos. Em adio, relatado o motivo pelo qual algumas das
instituies visitadas no apresentaram interesse ao levantamento.
5.1.Viso geral dos contratos de terceirizao
175. Dos rgos visitados que possuam objeto de interesse para a presente fiscalizao, cabe
observar que alguns possuem boa estrutura interna de TI, como o Tribunal Superior do Trabalho
(TST), Banco Central do Brasil (Bacen) e Supremo Tribunal Federal (STF). Essas trs instituies
possuem equipes de servidores do prprio quadro que atuam no desenvolvimento de software
utilizando mtodos geis.
176. Por outro lado, o Instituto do Patrimnio Histrico e Artstico Nacional (Iphan) possui
grande carncia de profissionais de TI em seu quadro. Todo o desenvolviment o de novos sistemas de
informao executado por empresas terceirizadas. J o Instituto Nacional de Estudos e Pesquisas
Educacionais Ansio Teixeira (Inep), sob a perspectiva de pessoal da rea de TI, encontra-se em
situao momentaneamente mais confortvel do que o Iphan. A rea de TI do Inep, quando da visita


22

da equipe de fiscalizao, contava com cinco servidores do quadro, alm de trinta e sete profissionais
com Contratos Temporrios da Unio (CTU). Contudo, alguns desses profissionais devero deixar o
Instituto no prximo ano em virtude do trmino da vigncia de seus contratos temporrios de
trabalho, no havendo previso de que venham a ser substitudos.
Tribunal Superior do Trabalho (TST)
177. O TST, aps adquirir experincia interna em desenvolvimento de software utilizando
Scrum, publicou, em 2012, o edital do Prego Eletrnico 146/2012, o qual teve por objeto a
contratao de Horas de Servio Tcnico (HST) de desenvolvimento de sistemas para os ambientes do
Tribunal (pea 20, p. 1).
178. Os servios abarcados pelo objeto do prego em comento constituram-se de iniciao de
sustentao de sistema, sustentao programada, sustentao emergencial e implantao, os quais
deveriam ser cotados separadamente pelas licitantes (pea 20, p. 2).
179. A sustentao programada englobou manutenes evolutivas e corretivas, cujo modelo de
execuo dos servios foi descrito no Anexo 2 (Modelo de Sustentao de Sistemas do TST) do termo
de referncia do edital (pea 20, p. 49-63). Esse modelo baseou-se fundamentalmente no framework
Scrum. Entretanto, o TST incluiu em seu detalhamento diferenciaes do modelo original, tais como
as previstas nos subitens 3.6 e 9.1 (pea 20, p. 50 e 56).
180. Segundo o subitem 3.6, cada sprint pode permitir o agrupamento de manutenes de
vrios sistemas diferentes. Como consequncia, um time de desenvolvimento Scrum provavelmente
dever interagir com mais de um Product Owner (PO) e coordenar atividades distintas de sistemas
diversos, o que pode trazer ineficincia ao processo de desenvolvimento.
181. O subitem 9.1 define o papel do PO e, ao contrrio do preceituado no framework Scrum,
prev que este poder ser desempenhado por mais de uma pessoa. Essa caracterstica do modelo
desenhado pelo TST pode trazer conflitos na definio da viso do produto, na gerncia/priorizao
dos requisitos e na aceitao do produto entregue, acarretando ineficincia ao processo.
182. O Contrato 146/2012, decorrente do Prego Eletrnico 146/2012, foi celebrado com a
empresa Squadra Tecnologia em Software Ltda., em 31/12/2012, ao custo de R$ 1.572.740,00. A
empresa deve executar os servios demandados em suas prprias dependncias, sendo que,
eventualmente, atividades como reunies de ponto de controle, definio de requisitos, entrega e
demonstrao dos produtos das ordens de servio devem ser feitas nas dependncias do TST (pea 20,
p. 26).
183. Quando da visita da equipe de fiscalizao ao TST, foi verificado que nenhuma ordem de
servio ainda havia sido emitida. Tal fato impediu a coleta de informaes acerca da experincia do
TST com a gesto contratual.
Banco Central do Brasil (Bacen)
184. O Bacen, assim como o TST, inicialmente introduziu os conceitos das metodologias geis
para desenvolvimento de sistemas em suas equipes internas. Em 2012, por meio do Prego Eletrnico
Demap 7/2012, 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 21, p. 1).
185. Os servios de desenvolvimento e manuteno dos sistemas de informao do Bacen
seguem o Processo de Desenvolvimento gil do Bacen (PDS-gil) elaborado pela prpria instituio,
cujo fluxo de trabalho apresentado no diagrama constante em documento especfico que descreve a
metodologia (pea 27, p. 3).
186. A metodologia concebida pelo Bacen fortemente influenciada pelo Scrum,incorporando
conceitos e prticas desse framework, como product backlog, Product Owner e reunies dirias; e
pelo XP, a exemplo de simplicidade da soluo implementada, integrao contnua, programao em
par, refatorao, desenvolvimento orientado por testes (Test Driven Development TDD) e
desenvolvimento orientado por testes de aceitao (Acceptance Test Driven Development ATDD).


23

187. Embora o PDS-gil esteja sendo empregado pela contratada para fornecer os servios
demandados pelo Bacen, observa-se da definio de escopo na verso atualmente utilizada que essa
metodologia de desenvolvimento destina-se ao uso interno e, havendo subcontratao, pode ser
aplicada s atividades no subcontratadas e a todos os produtos gerados (pea 27, p. 10, subitem
3.2). Entretanto, o PDS-gil no especifica quais atividades podem ser objeto de subcontratao. Em
adio, os papis nela definidos no vislumbram participao de atores externos ao Bacen (pea 27,
p. 10-12).
188. A empresa vencedora do Prego Eletrnico Demap 7/2012 foi a Politec Tecnologia da
Informao S.A., que celebrou o Contrato Bacen/Deinf 50.412/2012 em 22/4/2012, com vigncia
compreendendo o perodo entre 23/4/2012 e 22/4/2013, ao custo de R$ 7.605.511,20 (pea 21, 143).
Os servios so prestados nas dependncias da contratada, de modo remoto, podendo ser executados,
a critrio do Bacen, os servios de projeto de construo, total ou parcialmente, em suas prprias
dependncias em Braslia (pea 21, p. 23).
189. Em 22/4/2013, foi celebrado o primeiro termo aditivo do referido ajuste visando
prorrogar a vigncia contratual at 22/4/2014 e reajustar o valor unitrio do ponto de funo,
elevando o valor estimado da contratao para R$ 8.085.254,40 (pea 21, p. 144).
Instituto do Patrimnio Histrico e Artstico Nacional (Iphan)
190. O Iphan teve sua primeira experincia com mtodos geis por meio do Prego Eletrnico
12/2011. Esse certame teve por objeto o desenvolvimento do Sistema Integrado de Conhecimento e
Gesto (SICG), estimado em dois mil pontos de funo (pea 22, p. 5-6). Na ocasio, sagrou-se
vencedora a empresa EGL Engenharia Ltda., a qual celebrou o Contrato 28/2011 em 2/12/2011, com
vigncia estabelecida at 1/9/2013 e ao custo de R$ 990.000,00 (pea 22, 59). Segundo o contrato
firmado, os servios constantes de seu objeto devem ser executados nas instalaes da contratada,
sendo que algumas reunies de controle inerentes metodologia de gesto do projeto do Iphan devem
ocorrer nas dependncias do Iphan (pea 22, p. 52).
191. A forma de execuo dos servios, exposta no subitem 7.4 do termo de referncia do
citado prego, previu o desenvolvimento do projeto em ciclos e a realizao de cerimnias bem
definidas, assemelhando-se ao framework Scrum (pea 22, p. 29-33).
192. poca da visita da equipe de fiscalizao ao Iphan, o rgo estava elaborando edital
para a contratao de fbrica de software para o desenvolvimento e manuteno de seus sistemas
(pea 27, 470-541). Segundo a minuta do termo de referncia, esses servios devem ser executados em
conformidade com a Metodologia Iphan de Gesto de Demandas de Desenvolvimento gil de
Softwares (Midas pea 27, p. 476). O modelo de gesto estabelecido na Midas baseado no Scrum,
com poucas alteraes (pea 22, p. 68).
Instituto Nacional de Estudos e Pesquisas Educacionais Ansio Teixeira (Inep)
193. O Inep, diferentemente das demais instituies visitadas, atualmente encontra-se em seu
segundo contrato de fbrica de software para desenvolvimento de sistemas com uso de mtodos geis.
194. O Contrato 1/2011, decorrente do Prego Eletrnico 11/2010, foi a primeira iniciativa do
Instituto de contratao de desenvolvimento de sistemas de informao com mtodos geis. Teve por
objeto 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
R$ 6.984.000,00 (pea 23, p. 3 e pea 23, 383). Esses servios deveriam ser executados segundo a
orientao da Metodologia de Gesto e Desenvolvimento de Sistemas do Inep (MGDS), a qual
baseada na combinao de prticas advindas do XP e do Scrum (pea 23, p. 89).
195. A empresa Squadra Tecnologia em Software Ltda. sagrou-se a vencedora do certame.
Porm, segundo relatado na reunio com representantes da rea de TI do Inep, essa experincia no
produziu os resultados esperados. O principal motivo para o fracasso da iniciativa foi a
disponibilizao de equipe composta basicamente de analistas juniores e o seu desconhecimento em
desenvolvimento de sistemas utilizando mtodos geis. Ao final do contrato, a empresa Squadra optou


24

por no renovar a vigncia contratual, alegando que o preo cotado para o contrato no serviria para
cobrir seus custos.
196. A segunda experincia do Inep, atualmente em execuo, decorre do Prego Eletrnico
14/2012 (pea 24, 1-498), realizado em substituio ao contrato resultante do Prego Eletrnico
11/2010. Esse segundo prego teve como vencedora a empresa Cast Informtica S.A., a qual celebrou,
em 10/9/2012, o Contrato 33/2012, com perodo de vigncia compreendido entre 10/9/2012 a
9/9/2013 e ao custo anual de R$ 12.000.000,00 (pea 24, 499). O objeto do novo contrato manteve os
mesmos servios abarcados pelo Contrato 1/2011 (pea 24, p. 3), tambm devendo ser executado nas
instalaes do Inep de acordo com a MGDS do Inep (pea 24, p. 40).
197. Conforme relatado pelos representantes do Inep em reunio com os membros da equipe
desta fiscalizao, esse segundo contrato, aps o perodo de adaptao da empresa contratualmente
estabelecido em noventa dias, tem sido executado a contento, atendendo s necessidades do Instituto.
Supremo Tribunal Federal (STF)
198. Inicialmente, o STF implantou o desenvolvimento de sistemas utilizando metodologia gil,
baseada no Scrum, em suas equipes internas. Em 2012, lanou o edital do Prego Eletrnico
84/2012, cujo objeto consistiu na contratao de empresa para prestao de servios de
desenvolvimento gil de solues de software (pea 25, p. 2). Sagrou-se vencedora do certame a
empresa Basis Tecnologia da Informao S.A., celebrando o Contrato 27/2013 em 6/5/2013, ao custo
anual de R$ 2.295.000,00, devendo prestar os servios nas instalaes e com recursos de
infraestrutura tecnolgica do STF (pea 25, p. 73 e pea 25, p. 33).
199. A forma de execuo dos servios definida no item 9 (Gerenciamento da Contratao) do
termo de referncia do edital do Prego Eletrnico 84/2012 baseou-se no framework Scrum (pea 25,
p. 27-42). Quando realizada a visita ao STF, o rgo ainda no tinha iniciado a execuo contratual,
impedindo a equipe de fiscalizao de colher de informaes relativa sua experincia.
Departamento de Informtica do Sistema nico de Sade (Datasus)
200. Em abril de 2013, poca da visita da equipe de fiscalizao ao Datasus, verificou-se que o
rgo possua dois contratos vigentes relativos ao desenvolvimento de sistemas. Um deles, celebrado
com a empresa CTIS Tecnologia S.A. destinava-se ao levantamento de requisitos, enquanto o outro,
celebrado com a empresa Cast Informtica S.A., tinha como objetivo a implementao do sistema
especificado pela primeira. Quando 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 houvesse previso no instrument o
convocatrio para que a empresa assim procedesse. Por tal motivo, os contratos e editais originrios
no foram solicitados.
201. Em adio, verificou-se que, como o contrato com a empresa CTIS estaria prximo do
trmino de sua vigncia, o Datasus realizou o Prego Eletrnico 19/2013 com o intuito de contratar
empresas especializadas para prestao de servios tcnicos de desenvolvimento e manuteno de
sistemas de informao estimados em 130.000 pontos de funo e contagem de outros 210.000 (pea
26, p. 1).
Empresa Brasileira de Servios Hospitalares (EBSERH)
202. Quando a equipe de fiscalizao visitou a EBSERH, foi apresentada a metodologia
adotada pelo Hospital de Clnicas de Porto Alegre para sustentao do Aplicativo de Gesto para
Hospitais Universitrios (AGHU), no havendo tempo hbil para a apresentao da metodologia
utilizada no desenvolvimento de sistemas, objeto do presente levantamento. Por tal motivo, a equipe
de fiscalizao no solicitou maiores informaes acerca dos instrumentos convocatrio e contratual.
Servio Federal de Processamento de Dados (Serpro)
203. A visita da equipe de fiscalizao ao Serpro serviu para coleta de informaes referentes
utilizao de mtodos geis pelo lado do fornecedor. O Serpro desenvolveu o sistema Novo Siafi
para a Secretaria do Tesouro Nacional (STN) utilizando o framework Scrum. Uma tentativa


25

fracassada usando metodologia tradicional, baseada no Unified Process (UP), antecedeu essa
experincia.
204. Na primeira tentativa, o Serpro basicamente produziu documentaes relativas ao
levantamento de requisitos, sem, contudo, entregar o sistema contratado. Devido ao fracasso da
metodologia empregada, o Serpro props STN a execuo do servio utilizando mtodos geis, o
que foi por ela aceito. Grande parte dos requisitos j especificados na tentativa anterior foi utilizada
na construo do Novo Siafi, diminuindo o esforo de levantamento de requisitos e construo do
backlog do produto.
205. A seguir, apresentado quadro que sintetiza as informaes acerca das contrataes
identificadas pela equipe de fiscalizao.
rgo

Prego

Tipo do
objeto da
contratao

Empresa
contratada

Base do
framework
de gerncia
utilizado
Interessa ao
levantamento

TST

Prego Eletrnico
146/2012
Fbrica de
software

Squadra
Tecnologia em
Software Ltda.
Scrum

Sim

Bacen

Prego Eletrnico
Demap 7/2012
Fbrica de
software

Politec Tecnologia
da Informao S.A.
Scrum

Sim

Iphan

Prego Eletrnico
2/2011
Projeto EGL Engenharia
Ltda.
Scrum

Sim

TR em elaborao Fbrica de
software
No se aplica Scrum

Sim

Inep

Prego Eletrnico
1/2010

Fbrica de
software

Squadra
Tecnologia em
Software Ltda.
Scrum

Sim

Prego Eletrnico
14/2012
Fbrica de
software
Cast Informtica
S.A.
Scrum

Sim

STF

Prego Eletrnico
84/2012
Fbrica de
software
Basis Tecnologia
da Informao S.A.
Scrum

Sim

Datasus

No obtido

Fbrica de
software
levantamento
de requisitos
CTIS Tecnologia
S.A.

Metodologia
tradicional

No

No obtido

Fbrica de
software -
construo
Cast Informtica
S.A.

Metodologia
tradicional

No

Prego Eletrnico
19/2013
Fbrica de
software
CTIS Tecnologia
S.A.
Scrum

No

EBSERH

Informao no
obtida
Fbrica de
software
Informao no
obtida
No obtido

No

Serpro

Dispensa de
licitao

Projeto

No se aplica
(Serpro
fornecedor)
Scrum

No

Quadro 1 Resumo das contrataes identificadas pela equipe de fiscalizao
5.2. Mtricas de tamanho e esforo
206. Da anlise dos editais, contratos e extratos de contratos obtidos das instituies (de
interesse a este trabalho) visitadas (peas 20 a 25), verifica-se que, exceo do TST, todas elas


26

utilizaram pontos de funo para dimensionar e pagar os servios contratados, conforme apresentado
na tabela seguinte.
rgo

Contrato

Mtrica

Quantitativo
Anual
Valor
Unitrio
(R$)
Valor Total
(R$)
TST

146/2012 Horas de servio
tcnico (HST)

1.060 49,00 1.572.740,00
24.000 49,00
4.200 62,38
1.380 60,00
Bacen
50.412/2012 Pontos de funo

16.560 459,27 7.605.511,20
1 Aditivo 488,24 8.085.254,40
Iphan
28/2011 Pontos de funo 2.000 495,00 990.000,00
Em planejamento Pontos de funo 5.000 - -
Inep
1/2011 Pontos de funo 20.000 349,20 6.984.000,00
33/2012 20.000 625,00 12.500.000,00
STF 27/2013 Pontos de funo 5.000 459,00 2.295.000,00
Quadro 2 Mtricas utilizadas nos contratos das instituies visitadas
207. No edital do Prego Eletrnico 146/2012, o TST utilizou horas de servio tcnico (HST)
para mensurar o esforo e remunerar a contratada pelos servios prestados, cotando em separado
valores para cada um dos servios estabelecidos no edital, quais sejam iniciar sustentao de sistema,
sustentao programada, sustentao emergencial e implantao (pea 20 Edital TST, p. 2-4).
5.3. Planejamento, gesto de demandas, aceitao do produto e forma de pagamento
208. A maior parte dos instrumentos convocatrios analisados contm formas de
planejamento, gesto de demandas, aceitao do produto e pagamento semelhantes. A demanda para
construo do produto precedida pelo planejamento do produto, o qual pode ser feito apenas pela
instituio contratante ou em conjunto, entre essa e a empresa contratada. Alm do planejamento do
produto em si, algumas instituies tambm fazem o planejamento das funcionalidades que sero
implementadas no prximo ciclo, iterao ou sprint, atividade preceituada no Scrum.
209. A equipe de fiscalizao tambm observou que as instituies visitadas emitem uma
ordem de servio por ciclo, iterao ou sprint, ou por release de software, sendo mais comum o
primeiro caso.
210. Quanto aceitao do produto entregue pela contratada, embora no framework Scrum
seja preceituado que ocorra na reunio de reviso da sprint, essa prtica no executada nos
contratos estudados, at mesmo por impedimento normativo, como disciplinado no art. 73 da Lei
8.666/1993. Nessa ocasio, algumas instituies apenas verificam se os artefatos exigidos foram
entregues, caracterizando o recebimento provisrio.
211. Acerca da forma de pagamento da contratada, constatou-se que algumas instituies
remuneram os servios de planejamento quando realizados, enquanto outras remuneram apenas os
servios de construo do software.
212. A entrega adiantada e contnua de software, conforme postulado nos princpios dos
mtodos geis, foi observada em algumas das instituies visitadas. Para alcanar esse objetivo, elas
paralelizam as atividades de preparao, execuo e homologao, isto : em um dado perodo de
tempo, enquanto a empresa contratada executa a construo do software em um ciclo, iterao ou
sprint, a contratante prepara os itens do backlog do produto que sero implementados no prximo
ciclo e homologa o produto entregue no ciclo anterior.
213. A forma de planejamento, gesto de demandas, aceitao do produto e forma de
pagamento pelos servios executados nos contratos examinados so apresentados a seguir.
214. No TST, a execuo do servio de sustentao programada, um dos objetos do Contrato
146/2012, baseada no Scrum, sendo realizada em sprints, cujo acompanhamento dado pela


27

atualizao de quadros kanban (pea 20, p. 50 e 61). Para que um sistema do Tribunal possa sofrer
esse tipo de interveno pela empresa contratada, inicialmente ele passa pelo processo de iniciao
da sustentao, no qual a contratada gera seus respectivos manual de produo e documento de
arquitetura (pea 20, p. 51). A partir desse momento, a sustentao programada no sistema d-se por
meio de sprints.
215. Cada sprint do servio de sustentao programada precedida por uma Solicitao de
Sustentao Programada, a qual formalizada por ordem de servio (OS). O real objetivo desse tipo
de solicitao planejar a sprint, gerando como artefato o Plano da Sprint (pea 20, p. 52). Esse
artefato contm, entre outros elementos, as histrias de usurio (backlog da sprint) e os respectivos
critrios de aceite, datas de incio e fim da sprint e data, hora e local da reunio de apresentao dos
seus resultados (pea 20, p. 57-58). O TST, a seu critrio, identifica histrias de usurios essenciais,
que devem ser implementadas em cada sprint (pea 20, p. 26). Caso uma dessas histrias no seja
entregue ao final da sprint, ela dada como fracassada. Cada histria de usurio medida em pontos
de funo com vistas apurao da produo e da remunerao da contratada (pea 20, p. 53).
216. Com o Plano da Sprint preparado, inicia-se a sustentao programada propriamente
dita, na qual as funcionalidades especificadas no planejamento devem ser codificadas, testadas,
documentadas e apresentadas ao TST (pea 20, p. 53). Na apresentao dos produtos, o Product
Owner, assessorado pela equipe tcnica, verifica se todos os produtos previstos na solicitao de
sustentao foram entregues (pea 20, p. 62). Posteriormente, os produtos entregues so avaliados
pelo TST com vistas emisso do termo de recebimento definitivo da Ordem de servio (pea 20,
p. 30).
217. As ordens de servio das sprints relativas sustentao programada so remuneradas
conforme o esforo, dado em Horas de Servio Tcnico (HST). O esforo (E) obtido a partir do
produto do tamanho em pontos de funo da sprint (T) pela produtividade estabelecida pelo TST (10
HST/ponto de funo) para a contratada (E = T x P) (pea 20, p. 100).
218. Alm da prestao dos servios de desenvolvimento propriamente dito, a contratada
tambm demandada em outras atividades, como recebimento e planejamento da ordem de servio.
219. No recebimento, a contratada deve analisar a OS e verificar se as informaes nela
expressas so suficientes para a execuo do servio (pea 20, p. 27). No planejamento, a contratada
deve estimar o esforo, prazo e custo necessrios para a concluso da OS (pea 20, p. 99). O esforo
despendido pela contratada em ambos os servios no objeto de remunerao (pea 20, p. 32).
220. No Contrato 50.412/2012 do Bacen, os servios so demandados por Ordens de servio
cujo fluxo apresentado em figura constante na pgina 27 do edital do prego eletrnico Demap
7/2012 (pea 21). Segundo o fluxo estabelecido, o Banco cria e especifica o problema a ser resolvido
na ordem de servio e a envia para a contratada, a quem cabe a elaborao de proposta de soluo.
Estando de acordo com a proposta da contratada, o Bacen autoriza a execuo da OS.
221. As ordens de servio emitidas para o desenvolvimento de sistemas identificam qual o
Processo ou metodologia deve ser usado pela contratada (pea 20, p. 29). Conforme demonstram as
OS j emitidas no mbito do Contrato 50.412/2012, o processo utilizado o Processo de
Desenvolvimento gil do Bacen (PDS-gil; pea 27, p. 55-469).
222. A contratada dever entregar os produtos resultantes de uma ordem de servio somente
aps a execuo completa de todos os servios nela requeridos. Contudo, a critrio do Bacen,
podero ser acordadas entregas parciais de servios para uma OS de projeto de construo. Uma
entrega parcial em servios de desenvolvimento e manuteno constitui-se de uma release de cdigo,
juntamente com a documentao associada, que implementa um conjunto de funcionalidades
quantificveis e que tenham significado para o solicitante do servio (pea 21, p. 40).
223. A remunerao da contratada observa o estabelecido no documento Distribuio de
Esforo por Disciplina (pea 27, p. 52-55). Quanto ao PDS-gil, ao elaborar o levantamento de
requisitos e aps t-lo aprovado pelo Bacen, a contratada recebe 14,375% do valor correspondente


28

aos pontos de funo estimados para a respectiva ordem de servio. A fase de levantamento de
requisitos compreende a elaborao do modelo de negcio, documento de viso, prottipo de
interface, especificao de teste de aceitao e glossrio (pea 27, p. 54).
224. Aps a fase de implementao a qual abrange a elaborao de documento de
arquitetura, modelo de dados, classes de testes de unidade, cdigo fonte, instrumentao de testes,
script de teste, relatrio de teste, ajuda do sistema, roteiro de operao e manual de usurio a
contratada faz jus aos 85,625% restantes, a depender do aceite definitivo dos produtos gerados (pea
27, p. 54).
225. A fase de validao da ordem de servio divide-se em provisria e definitiva. A OS
provisoriamente validada quando for confirmada a entrega dos servios prestados. Caso seja
rejeitada, a OS devolvida contratada para os ajustes necessrios, repetindo-se esse procedimento
at ocorrer a validao provisria (pea 21, p. 42).
226. Uma vez validada provisoriamente, a ordem de servio passa pela validao definitiva, a
qual compreende a anlise detalhada dos produtos e dos resultados gerados para os servios
requeridos na OS e a verificao do atendimento aos critrios de aceitao nela estabelecidos e
segundo os padres e processos de trabalho do Bacen (pea 21, p. 42).
227. Na validao definitiva, a ordem de servio pode ser validada, validada com restries ou
rejeitada (pea 21, p. 42). validada com restries quando for identificada alguma ocorrncia em
um ou mais produtos ou resultados, mas que permitam a validao da OS pelo Bacen. Ordens de
servios validadas com restries so devolvidas contratada para ajustes, concedendo-se prazo de
at 50% do originalmente previsto para sua execuo. Por sua vez, a ordem de servio rejeitada
devolvida contratada para correo, havendo tantas devolues e entregas quantas necessrias at
a validao definitiva do servio. A seu critrio, o Bacen pode prorrogar o prazo de concluso da
ordem de servio rejeitada, uma nica vez, em at 50% do prazo originalmente previsto para sua
execuo (pea 21, p. 42-43).
228. O Contrato 28/2011 previu o desenvolvimento do Sistema Integrado de Conhecimento e
Gesto (SICG) de forma iterativa e incremental por meio de ciclos, com durao mxima de trs
semanas cada um, executados mediante ordens de servio dimensionadas por meio de pontos de
funo brutos (pea 22, p. 27 e 29).
229. O primeiro ciclo estabelecido no termo de referncia consiste no ciclo de planejamento, o
qual 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 22, p. 30).
230. A execuo de cada ciclo precedida por uma reunio de planejamento, na qual a
contratada apresenta ao Iphan uma proposta de Ordem de servio contendo o planejamento proposto
para o ciclo. Caso aprovada pelo Iphan, a OS devidamente formalizada e entregue contratada
para dar incio s atividades previstas no ciclo (pea 22, p. 34).
231. Cada ciclo finalizado pela reunio de encerramento, oportunidade em que os produtos
resultantes da OS so apresentados (pea 22, p. 34). O prazo para a aceitao definitiva dos produtos
entregues pelo Iphan, dada pela emisso de pareceres tcnico e negocial favorveis, consiste no prazo
de execuo do prximo ciclo (pea 22, p. 35).
232. A remunerao da contratada para os ciclos de desenvolvimento baseia-se na quantidade
de pontos de funo executados no ciclo (pea 22, p. 35). O termo de referncia do Prego Eletrnico
12/2011 previu que 75% do valor do contrato seriam destinados aos ciclos de desenvolvimento, ou
seja, na realidade a contratada recebe apenas 75% do valor dos pontos de funo brutos da contagem
final de cada ciclo de desenvolvimento (pea 22, p. 37).
233. Por seu turno, aos ciclos de projeto (planejamento, implantao e encerramento), no
mensurveis por pontos de funo, foram destinados 5%, 10% e 10% da quantidade estimada de dois
mil pontos de funo brutos. O valor pago referente ao ciclo de planejamento pode sofrer reviso,


29

uma vez que a quantidade final de pontos de funo do SICG pode no corresponder aos dois mil
pontos inicialmente estimados (pea 22, p. 37).
234. Acerca da futura contratao de fbrica de software para o desenvolvimento e
manuteno de sistemas informatizados do Iphan, o modelo de remunerao da contratada previsto
na minuta do termo de referncia assemelha-se ao do Contrato 28/2011.
235. No novo contrato, as demandas sero solicitadas por meio de Ordens de Servio, cuja
remunerao ser calculada considerando a quantidade de pontos de funo a serem produzidos e a
fase do desenvolvimento. Na fase de planejamento, caber 5% dos pontos de funo estimados,
enquanto nas fases de desenvolvimento e encerramento caber contratada receber 80% e 15%,
respectivamente, dos pontos de funo efetivamente produzidos (pea 27, p. 496).
236. No Contrato 33/2012, atualmente vigente, o fluxo do processo de desenvolvimento ou
manuteno programada de sistemas detalhado na Metodologia de Gesto e Desenvolvimento de
Sistemas (MGDS; pea 24, p. 513-551). Segundo a MGDS, a definio da viso do novo sistema a ser
desenvolvido ou de sistema legado a sofrer manuteno d-se na etapa de iniciao, fase que pode ser
executada com ou sem auxlio da contratada.
237. A iniciao constitui-se no planejamento propriamente dito. Nessa fase, alm da
elaborao da viso do produto e do estabelecimento da definio de pronto, tambm so definidos
os requisitos que constaro do backlog do produto (pea 24, p. 513). Caso haja necessidade de
participao da contratada na iniciao, uma Ordem de servio especfica aberta para a realizao
de atividades de levantamento preliminar de escopo junto ao cliente ou de detalhamento da demanda.
Nesse tipo de ocorrncia, a contratada tem remunerao correspondente a 10% da quantidade de
pontos de funo estimada para a respectiva OS (pea 24, p. 69).
238. A fase de iniciao encerrada quando a demanda planejada, seja desenvolvimento de
novo sistema, seja manuteno de sistema legado, repassada para a contratada com a finalidade de
alinhar o entendimento do negcio entre o Inep e a contratada (pea 24, p. 519).
239. Na sequncia, inicia-se a fase de execuo, que desenrolada segundo os preceitos do
framework Scrum, com reunio de planejamento da sprint, na qual emitida OS para a sua execuo
pela contratada, e reunio de reviso, na qual a contratada entrega os produtos da sprint, alm da
reunio de retrospectiva (pea 24, p. 521-526). Para a execuo da sprint, a contratada remunerada
em 100% do total obtido na medio final dos pontos de funo da iterao entregue e aceita (pea
24, p. 69).
240. Ao final da fase de execuo tambm pode se dar a implantao, no ambiente de
produo, do produto gerado na sprint, quando aceito e homologado pelo Inep e solicitado pelo
Product owner (pea 24, p. 526).
241. A ltima fase do processo de desenvolvimento ou manuteno de sistemas, de acordo com
a MGDS, consiste no encerramento, que tem como objetivo encerrar as ordens de servio de iniciao
e da sprint (pea 24, p. 537-538). No encerramento, ocorre a aceitao definitiva das Ordens de
Servio, habilitando-as para faturamento pela contratada.
242. Antes da execuo da fase de encerramento, a MGDS prev a homologao dos artefatos
produzidos pela contratada em atendimento s Ordens de servio de iniciao e da sprint em dois
momentos. No primeiro, a avaliao da qualidade dos artefatos realizada pela rea de TI quanto
conformidade com os padres estabelecidos pelo Inep (pea 24, p. 528-530). No segundo, a avaliao
feita sob o ponto de vista do negcio pelo cliente demandante (pea 24, p. 535-536).
243. No Contrato 24/2013, as demandas so encaminhadas empresa contratada por meio de
ordens de servio, as quais so formalizadas na reunio de abertura da OS (pea 25, p. 34).
244. Aps a reunio de abertura da OS, inicia-se a etapa de preparao da sprint, que serve,
basicamente, para garantir o entendimento, por parte da contratada, do servio solicitado e facilitar o
planejamento da execuo. Nessa etapa, apresentado contratada um subconjunto de histrias de


30

usurio, que consiste em parte do product backlog, para que sejam selecionadas aquelas que
comporo o backlog da sprint (pea 25, p. 34).
245. Aps a preparao, inicia-se a etapa de execuo, a qual consiste na sprint propriamente
dita para a construo do produto. O prazo da sprint fixado em quinze dias, podendo ser alterado
ao longo da vigncia contratual (pea 25, p. 31). A execuo, por sua vez, inicia-se com a reunio de
planejamento da sprint e encerra-se com a reunio de demonstrao (pea 25, p. 30).
246. Na reunio de planejamento, criado o backlog da sprint, as histrias de usurio so
detalhadas em tarefas a executar, a contratada assegura o entendimento tcnico e negocial da
demanda, o tamanho e critrios de aceitao so definidos e a definio de pronto estabelecida
(pea 25, p. 35).
247. Na reunio de demonstrao, os produtos construdos com base nas histrias de usurio
selecionadas para a sprint so apresentados em ambiente de homologao. Nessa reunio, a
contratada tambm deve entregar a documentao prevista no instrumento convocatrio, a exemplo
de documento de arquitetura, modelo de dados e plano de implantao. Nessa reunio, conforme
interesse do STF, a contratada deve detalhar e repassar todo o conhecimento tcnico utilizado na
construo dos produtos (pea 25, p. 36 e 44).
248. Sucede a etapa de execuo a avaliao, perodo em que o produto verificado funcional
e tecnicamente (pea 25, p. 30). No havendo inconformidades e ocorrncias, o produto
homologado e a ordem de servio originria encerrada (pea 25, p. 38).
249. O pagamento das ordens de servio calculado com base no tamanho funcional do
produto homologado em pontos de funo brutos e na efetiva execuo do servio. Ele feito em duas
etapas: a primeira, correspondente a 90%, realizada aps o recebimento definitivo da OS referente
ltima sprint de cada produto; a segunda, correspondente a 10%, realizada somente ao final do
perodo de garantia, estipulado em 180 dias (pea 25, p. 21 e 39).
5.4. Mudanas de requisitos e escopo
250. A filosofia dos mtodos geis para desenvolvimento de software foi concebida para
absorver mudanas, conforme expresso no manifesto gil e em seus princpios, especificamente no
valor responder a mudanas, mais que seguir um plano e no princpio aceitar mudanas de
requisitos, mesmo no fim do desenvolvimento. Tal mudana pode acontecer inclusive durante as
iteraes, ciclos ou sprints. No Scrum, durante a sprint, no so feitas mudanas que possam afetar
seu objetivo, porm o escopo pode ser esclarecido e renegociado entre o Product Owner e a equipe de
desenvolvimento medida que for melhor entendido.
251. Entretanto, foi constatado que a maioria das instituies contratantes no permite
mudanas durante a execuo das iteraes. Exemplo dessa prtica pode ser visto na pgina 32 do
edital do Prego Eletrnico 12/2011 do Iphan (pea 22), na qual consta que uma vez que o ciclo
tenha sido aprovado pela CONTRATANTE e a Ordem de servio tenha sido emitida, nenhuma das
partes poder alterar o escopo do ciclo at que ele finalize.
252. Quando identificadas, as mudanas so colocadas no backlog do produto para que, em
momento oportuno, conforme a priorizao da rea de negcios, sejam introduzidas em iteraes
seguintes.
253. Por outro lado, no Bacen, a possibilidade de alterao do escopo de uma Ordem de
servio est explicitamente prevista no edital do Prego Eletrnico Demap 7/2012 por meio do
documento Solicitao de Mudana, no qual a mudana de escopo solicitada, com respectiva anlise
de impacto no tamanho, prazo e custo (pea 21, p. 21).
5.5. Nveis de servio
254. Da anlise dos editais das contrataes, observa-se que quase todas as instituies
visitadas instituram vrios nveis de servio a serem atendidos pela contratada. Em suma, o no
atendimento a critrios mnimos aceitveis implica a reduo do valor a ser pago contratada. Dos
nveis de servio analisados, verificou-se a preocupao quase comum das contratantes com o prazo
para o cumprimento das iteraes, ciclos ou sprints, e com a qualidade dos produtos entregues.


31

255. No TST, por exemplo, foi institudo o ndice de Atraso na Entrega de OS, o qual tem por
objetivo garantir a entrega da OS no prazo estimado para a sua concluso (pea 20, p. 37). Embora a
meta estabelecida para esse indicador seja de 0%, o TST estipulou que atrasos inferiores a 10% do
prazo previsto para a entrega da OS encontram-se em um limite aceitvel. Isto , no contrato do TST
h tolerncia para atrasos na entrega dos produtos demandados, afastando-se dos preceitos do
framework Scrum, no qual uma sprint deve ser executada no prazo estabelecido.
256. Quanto aferio da qualidade, o TST criou o indicador Desconformidade na OS (DOS)
para assegurar a conformidade das Ordens de servio aos requisitos de qualidade, 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 20, p. 63, 65-95). A meta do
indicador DOS 0%, significando que caso alguma desconformidade seja detectada, o produto, e,
consequentemente, a Ordem de servio, rejeitada.
257. Por sua vez, o Bacen instituiu indicador referente ao Atraso na Entrega da OS de projeto
de construo, tolerando, assim como o TST, pequenos atrasos, uma vez que esse indicador deve ser
menor ou igual a 0,1 (pea 21, p. 63). Para aferir a qualidade dos artefatos entregues pela contratada
em projetos de construo, o Bacen definiu o ndice de Defeitos por Pontos de Funo da OS e o
ndice de Defeitos Impeditivos por Pontos de Funo da OS. Para o primeiro indicador, h tolerncia
para a aceitao da OS, enquanto para o segundo a tolerncia zero (pea 21, p. 63-64).
258. De forma diferente das outras instituies visitadas, o Iphan, no Contrato 28/2011,
institui apenas dois indicadores de nvel de servio, sendo que somente um deles refere-se ao servio
de desenvolvimento, executado nos ciclos de desenvolvimento, o qual denominado de ndice de
Pontos Executados (IPE). O IPE destina-se a avaliar a qualidade dos produtos entregues, medindo a
quantidade de pontos de funo brutos executados e aceitos da ordem de servio. Caso o IPE seja
inferior ou igual a 80%, multas podem ser aplicadas contratada (pea 22, p. 45-46).
259. A instituio do IPE no instrumento convocatrio do Iphan no se confunde com a
aceitao de Ordens de servio contendo produtos em desconformidade com os padres de qualidade
estabelecidos. Caso algum produto construdo no ciclo no seja aprovado, este poder ser
considerado perdido, devendo um novo ciclo ser iniciado para adequao desse produto (pea 22,
p. 33).
260. Acerca do atraso na entrega dos produtos demandados nas ordens de servio, ou seja,
atraso nos ciclos, o Iphan no prev tal situao no termo de referncia do Prego Eletrnico
12/2011. No Contrato 28/2011, ao final de cada ciclo, a contratada deve entregar os produtos que
porventura tenha produzido, os quais sero avaliados pelo IPE. Caso no tenha produtos a entregar,
assim como os produtos no aprovados, eles devero ser objeto de outro ciclo.
261. O edital em elaborao do Iphan para a contratao de fbrica de software para
desenvolvimento e manuteno de sistemas com mtodos geis tambm mantm o mesmo indicador
(IPE) para a avaliao dos produtos entregues (pea 27, p. 496-497).
262. No Inep, no mbito do Contrato 33/2012, os critrios de avaliao da qualidade dos
produtos entregues possuem indicadores distintos para a avaliao a cargo da rea de TI e a da rea
de negcios. A rea de TI avalia a conformidade da qualidade dos produtos sob o aspecto tcnico,
homologando-os tecnicamente. A rea de negcios avalia a conformidade dos produtos sob o aspecto
negocial, homologando-os negocialmente. Segundo o instrumento convocatrio, havendo no
conformidades nessas etapas, so concedidos prazos (48 horas na homologao tcnica e 24 na
homologao negocial) consecutivos para a contratada adequar os produtos qualidade exigida,
avaliando-se negativamente a contratada a cada novo prazo dado (pea 24, p. 55-56, Tabela 1, itens
1, 2, 4 e 5).


32

263. Acerca do cumprimento do prazo para a execuo das Ordens de Servio, segundo o
termo de referncia, h tolerncia quando ocorre o descumprimento do cronograma estabelecido
para a concluso dos servios. Entretanto, a contratada avaliada de forma negativa quando atrasa a
entrega dos produtos especificados na Ordem de servio, concedendo-se sucessivos prazos de 24
horas para finaliz-los, nos quais a penalizao da contratada agravada (pea 24, p. 56, Tabela 1,
itens 6 e 7).
264. O STF aplica dois tipos de redutores s Ordens de servio pagas empresa contratada. O
primeiro refere-se aos nveis de servio propriamente ditos, enquanto o segundo relaciona-se aos
critrios gerais de avaliao (pea 25, p. 52-53). Entre os nveis de servio, encontra-se o ndice de
Desconformidade do Produto, o qual afere a qualidade dos produtos entregues pela contratada. Por
sua vez, nos critrios gerais de avaliao consta a punio a ser aplicada contratada quando
ocorrer atraso no justificado nas datas definidas nas Ordens de Servio.
265. Ainda chama a ateno no Contrato 33/2012, do Inep, e no Contrato 24/2013, do STF, a
existncia de indicadores especficos de rotatividade da equipe da contratada (pea 24, p. 56-57, item
10 e pea 25, p. 47 e 52, item 1). Uma vez que o desenvolvimento de softwares com a utilizao de
mtodos geis tem foco voltado para os indivduos, em vez de processos, e na entrega de resultado de
forma adiantada, a substituio de membros da equipe da contratada, como o Scrum Master ou
membros da equipe de desenvolvimento, pode efetivamente diminuir a produtividade do fornecedor.
5.6. Compatibilizao dos valores geis nas contrataes examinadas
266. O exame dos contratos das instituies visitadas demonstra o nimo de impor a essncia
das metodologias geis, postuladas pelos valores do Manifesto gil, s contrataes realizadas,
compatibilizando-a com as normas vigentes.
267. Nesse sentido, constatou-se a preocupao de todas as instituies com relao entrega
de artefatos de documentao associados ao software produzido a cada iterao, facilitando, por
exemplo, futuras manutenes por terceiros alheios ao processo de desenvolvimento. Tambm foi
constatado que a relao contratual prevalece sobre a possvel colaborao entre as partes, em
harmonia com o princpio da vinculao ao instrumento convocatrio, e as mudanas propostas
mostraram-se restritas a novas iteraes, mitigando o risco de desembolsos no programados.
268. Entretanto, quanto pessoalidade forte aspecto das metodologias geis, fundamentado
na maior valorizao dos indivduos e interao entre eles em detrimento de processos e ferramentas,
e materializado na necessidade da constncia da composio da equipe de desenvolvimento do time
Scrum (item 90) foi constatada, pela existncia de nveis de servio vinculados rotatividade da
equipe de desenvolvimento da contratada em contratos de duas instituies, a preocupao com essa
caracterstica do mtodo.
6. Riscos na contratao de desenvolvimento de software com mtodos geis pelas instituies da
Administrao Pblica Federal
269. Com o conhecimento adquirido sobre mtodos geis, seja decorrente da anlise terica
ou das visitas realizadas pela equipe de fiscalizao a algumas instituies pblicas federais, seja
decorrente do exame dos contratos dessas instituies, possvel vislumbrar alguns riscos nas
contrataes pblicas para desenvolvimento de software por meio de mtodos geis.
270. Nesse sentido, a seguir so apresentados alguns riscos inerentes ao novo paradigma de
desenvolvimento de software que est sendo difundido nas contrataes da Administrao Pblica,
suas possveis causas e consequncias, bem como contrataes em que foram materializados, quando
for o caso. Para fins didticos, os riscos elencados esto reunidos em trs grupos distintos: processos,
produtos e pessoas.
271. Cumpre frisar que no se trata de enumerao exaustiva de riscos, e sim de um
subconjunto identificado com o conhecimento adquirido. Tambm importante observar que alguns
dos riscos expostos no so inerentes somente ao uso de mtodos geis, podendo ocorrer tambm com
metodologias tradicionais de desenvolvimento de software.


33

Riscos relativos a processos
272. Risco 1: contratao de desenvolvimento de software com adaptao de metodologia gil
que desvirtue sua essncia.
272.1. Uma vez que a utilizao estrita da doutrina gil pode ser conflitante com algum
dispositivo constante dos diversos normativos e jurisprudncia vigentes ou no atender totalidade
dos interesses da instituio pblica contratante, esta pode incorrer em adaptaes de uma
metodologia gil j consolidada no mercado com o intuito de mold-la sua realidade. Essa prtica
pode ter como consequncias, entre outras:
272.1.1. diminuio da competitividade da licitao, pois a utilizao de metodologias
adaptadas pode no despertar o interesse de fornecedores que j adotam uma metodologia especfica,
preferindo no realizar contratos que apresentem risco para o seu negcio;
272.1.2. conflitos com a empresa contratada, uma vez que podem surgir interpretaes
equivocadas pelas partes quanto ao emprego dos processos, atividades e papeis estabelecidos no
instrumento convocatrio, no havendo organizao que suporte a metodologia adaptada, a qual
possa ser utilizada para dirimir eventuais dvidas e, por consequncia, eliminar os conflitos;
272.1.3. conflitos entre membros da instituio contratante devido a falhas na atribuio dos
papeis a serem desempenhados;
272.1.4. entrega de produtos de baixa qualidade, caso a adaptao da metodologia suprima
elementos do processo de elaborao do software servveis construo e aferio da qualidade do
produto;
272.1.5. diminuio da eficincia/produtividade da equipe de desenvolvimento da empresa
contratada, caso a adaptao feita na metodologia anule ou atenue prticas que visem eficincia;
272.2. Algumas das consequncias vislumbradas no risco em destaque podem vir a ocorrer no
Contrato 146/2012 do TST. O framework adotado nessa instituio o Scrum. Entretanto, segundo o
subitem 3.4 (pea 20, p. 50), vrios sistemas podem ser agrupados em uma mesma sprint:
3.4 O Processo de Sustentao Programada ser executado 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 Sprint. (grifo nosso)
272.3. uma vez que 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
execuo de atividades diversas pulverizadas em vrios sistemas, interagir com POs distintos durante
a execuo de uma nica sprint, sua eficincia pode sofrer prejuzos.
272.4. O TST tambm inovou ao especificar, no termo de referncia, que o papel do Product
Owner pode ser desempenhado por mais de uma pessoa (pea 20, p. 56):
9.1 O Dono do Produto pode ser um profissional, ou um grupo de profissionais, da CDS e/ou
das reas de negcio do TST.
272.5. Nesse caso, as posies dos donos do produto podem ser divergentes, gerando, por
exemplo, problemas na gerncia do backlog do produto e na avaliao das funcionalidades entregues.
272.6. Por seu turno, a Metodologia Iphan de Gesto de Demandas de Desenvolvimento gil
de Softwares (Midas), a qual ser adotada na futura contratao de fbrica de software que se
avizinha, define a existncia de dois Scrum Masters no modelo de gerncia do desenvolvimento de
software, sendo um da contratada e o outro do prprio Iphan. No framework Scrum, esperado que
tal papel seja desempenhado pela contratada. Tal fato pode gerar problemas de competncia com a
empresa contratada.
273. Risco 2: alterao da metodologia gil adotada no instrumento convocatrio no decorrer
da execuo contratual.
273.1. A alterao da metodologia gil adotada no instrumento convocatrio durante a
execuo contratual pode ocorrer devido pouca experincia da instituio pblica contrat ante na
utilizao de mtodos geis. Essa prtica pode ter como consequncias conflitos de ordem financeira
com a empresa contratada, uma vez que o seu preo, apresentado poca da licitao, pode vir a no


34

cobrir novos custos decorrentes de alteraes introduzidas pela contratante, trazendo distores
manuteno do equilbrio econmico-financeiro do contrato. Alm disso, afronta o princpio da
vinculao ao instrumento convocatrio institudo no art. 3 da Lei 8.666/1993.
273.2. Uma variao do risco em epgrafe a incluso de clusulas e condies no
instrumento convocatrio e no contrato dele decorrente, as quais prevem que a metodologia
especificada pode sofrer alteraes durante a vigncia contratual. Nesse caso, alm de trazer
distores manuteno do equilbrio econmico-financeiro do contrato, tal prtica pode configurar
afronta ao art. 14 da lei de licitaes e contratos, que veda a contratao sem a adequada
caracterizao de seu objeto.
273.3. No Bacen, algumas das clusulas do instrumento convocatrio que originou o Contrato
50.412/2012 apresentam essa caracterstica, como exemplificado a seguir.
8.1.4 A critrio do Bacen os padres, processos de trabalho e artefatos podero sofrer
alteraes. A Contratada dever se adaptar s mudanas no prazo mximo de 30 dias corridos
contados da comunicao pelo Bacen. (pea 21, p. 25)
8.1.5 A critrio do Bacen, durante a execuo contratual, podero ser acrescentadas ao
conjunto de processos de desenvolvimento, manuteno e documentao vigentes, outras
metodologias, prticas, artefatos e tecnologias (frameworks, ambiente operacional e de
desenvolvimento, arquitetura dentre outros) que sejam aderentes s formas de mensurao, de
pagamento e de servios previstas neste Edital. (pea 21, p. 24-25)
17.2.1.2 O Bacen poder estipular, na prpria Ordem de servio, em funo de suas
caractersticas especficas, outros critrios de validao dos servios, adicionais ou substitutivos aos
descritos nos padres e processos de trabalho do Bacen. (pea 21, p. 42)
273.4. As alteraes previstas nesses casos, quanto ao desenvolvimento de sistemas no Bacen,
afetam basicamente o Processo de Desenvolvimento gil do Bacen (PDS-gil).
274. Risco 3: ausncia de definio dos artefatos ou alterao dos artefatos exigidos da
contratada no instrumento convocatrio durante a execuo contratual.
274.1. O risco em evidncia, assim como o anteriormente citado, pode decorrer da pouca
experincia da instituio pblica contratante na utilizao de mtodos geis.
274.2. A ausncia da definio dos artefatos exigidos da contratada no instrumento
convocatrio pode elevar os custos da contratao, uma vez que a empresa contratada, por no
conhecer a totalidade dos produtos demandados para a construo do software poca da licitao,
pode apresentar proposta de preos majorada em virtude da insegurana inerente ao
desconhecimento.
274.3. alm de ser potencialmente lesiva economicidade da contratao, a materializao do
risco em epgrafe pode configurar afronta ao art. 14 da lei de licitaes e contratos, que veda a
contratao sem a adequada caracterizao de seu objeto.
274.4. Por sua vez, a alterao dos artefatos exigidos da contratada no instrumento
convocatrio no decorrer da execuo contratual afronta o princpio da vinculao ao instrumento
convocatrio institudo no art. 3 da Lei 8.666/1993 e pode gerar conflitos com a empresa contratada
por vir a introduzir novos custos no vislumbrados no edital, ferindo a manuteno do equilbrio
econmico- financeiro do contrato. Em acrscimo, tambm fere o art. 14 da lei citada.
274.5. No Bacen, os subitem 8.1.4 e 8.1.5 do termo de referncia do Prego Eletrnico
Demap 7/2012, transcritos a seguir, apresentam essa caracterstica:
8.1.4 A critrio do Bacen os padres, processos de trabalho e artefatos podero sofrer
alteraes. A Contratada dever se adaptar s mudanas no prazo mximo de 30 dias corridos
contados da comunicao pelo Bacen. (pea 21, p. 25)
8.1.5 A critrio do Bacen, durante a execuo contratual, podero ser acrescentadas ao
conjunto de processos de desenvolvimento, manuteno e documentao vigentes, outras
metodologias, prticas, artefatos e tecnologias (frameworks, ambiente operacional e de


35

desenvolvimento, arquitetura dentre outros) que sejam aderentes s formas de mensurao, de
pagamento e de servios previstas neste Edital. (grifo nosso) (pea 21, p. 24-25)
275. Risco 4: exigncia de artefatos desnecessrios ou que se tornam obsoletos rapidamente.
275.1. A exigncia de artefatos desnecessrios pode ser oriunda da inexperincia da
instituio contratante, principalmente na transio do modelo de contratao para desenvolvimento
de software com metodologias tradicionais para mtodos geis.
275.2. Alguns artefatos exigidos no instrumento convocatrio podem, no novo paradigma, no
trazer utilidade contratante ou tornarem-se obsoletos rapidamente, de uma sprint para outra, como
manual do usurio. Alm disso, acrescentam custos empresa contratada, os quais possivelmente
foram repassados em sua proposta de preos, onerando de forma desarrazoada o ajuste contratual.
Dessa forma, a materializao do risco em tela afronta o princpio constitucional da economicidade.
276. Risco 5: utilizao de contrato para desenvolvimento de software por metodologias
tradicionais para desenvolvimento por mtodos geis.
276.1. A utilizao de contrato inicialmente concebido para ser executado segundo modelo de
desenvolvimento de software tradicional para o desenvolvimento de software por meio de mtodos
geis, em primeira anlise, conflita com o princpio da vinculao ao instrumento convocatrio,
estabelecido no art. 3 da Lei 8.666/1993. Nesse caso, trata-se de alterao no objeto do servio de
desenvolvimento de software, haja vista que a utilizao de mtodos geis pode alterar, em forma ou
em essncia, os produtos inicialmente descritos no contrato.
263.2. Potencialmente, a materializao do risco em tela pode gerar atritos entre a instituio
contratante e a fornecedora devido mudana do paradigma utilizado na execuo contratual, no
previsto inicialmente no instrumento convocatrio. Em adio, possvel que vrios elementos
constantes no ajuste contratual no se adequem utilizao de mtodos geis, como nveis de servio
e artefatos exigidos da contratada no decorrer da execuo contratual.
Riscos relativos a pessoas
277. Risco 6: falta de comprometimento ou colaborao insatisfatria do responsvel indicado
pela rea de negcios (Product Owner) no desenvolvimento do software.
277.1. O uso de mtodos geis exige grande comprometimento do responsvel indicado pela
rea de negcios da instituio pblica, conhecido como Product Owner no framework Scrum. A ele
atribudo o gerenciamento do produto de forma a assegurar o valor do trabalho executado pela
equipe de desenvolvimento da contratada.
277.2. Para que o processo de construo do produto possa fluir adequadamente, o
responsvel indicado pela rea de negcios deve desempenhar diversas atividades, como definir a
viso do produto, gerenciar suas funcionalidades, prioriz-las e aprovar ou rejeitar os artefatos
entregues a cada iterao. Alm disso, deve ter disponibilidade para atender, sempre que necessrio,
a equipe de desenvolvimento da contratada para que essa possa, por exemplo, elidir dvidas
emergentes.
277.3. A falta de comprometimento ou a colaborao insatisfatria do responsvel no processo
de construo do software, abdicando do exerccio das atividades a ele atribudas, pode ter como
consequncias a gerao de produtos de baixa qualidade que no atendam s reais necessidades dos
clientes, atrasos no desenvolvimento e at mesmo, em casos extremados, o cancelamento do projeto.
278. Risco 7: falta do conhecimento necessrio do indicado pela rea de negcios (Product
Owner) para o desenvolvimento do software.
278.1. O servidor indicado pela rea de negcios responsvel pela construo do software
para desempenhar o papel de Product Owner ou similar pode no deter os conhecimentos necessrios
dos processos de trabalho que sero apoiados pela soluo de TI a ser desenvolvida, podendo
acarretar definies e priorizaes de funcionalidades equivocadas, em detrimento das
funcionalidades essenciais.


36

278.2. Em acrscimo, outras consequncias potenciais da falta de conhecimento do Product
Owner indicado so esforos e custos posteriores para ajustar a soluo mal concebida ou, at
mesmo, o seu descarte, afrontando os princpios constitucionais da economicidade e da eficincia.
278.3. No caso da materializao desse risco, pode caber responsabilizao do Product
Owner e do responsvel pela sua indicao quanto aos recursos despendidos sem que o interesse
pblico tenha sido atendido.
278.4. No Iphan, em entrevista com o responsvel pelo Contrato 28/2011 e a equipe de
fiscalizao, foi revelado que o risco ora tratado materializou-se. Na ocasio, o fato foi devidamente
documentado nos autos do processo da contratao e comunicado instncia superior para o
adequado tratamento.
279. Risco 8: excessiva dependncia da viso do indicado pela rea de negcios (Product
Owner).
279.1. A falta de interao do Product Owner com os demais usurios do software em
construo e, at mesmo, o desconhecimento desses acerca do projeto, pode vir a criar excessiva
dependncia de sua viso na concepo do produto. Como efeito desse risco, o sistema de informao
construdo pode no atender s expectativas dos usurios e, por consequncia, no atender
necessidade da contratao.
266.2. Outro aspecto relacionado dependncia excessiva do Product Owner refere-se a seus
afastamentos da instituio em decorrncia, por exemplo, de frias e licenas. Nesse caso, uma
possvel consequncia a suspenso da execuo do projeto, acarretando atrasos na entrega do
produto final. No Iphan, segundo relatos, quando o Product Owner afastou-se, em decorrncia de
frias, o andamento do projeto executado no mbito do Contrato 28/2011 foi suspenso. Nessa ocasio,
a empresa contratada aproveitou o perodo de afastamento do PO para introduzir melhorias tcnicas
no software.
280. Risco 9: equipe da empresa contratada no ter expertise em desenvolvimento de software
com mtodos geis.
280.1. Em licitaes pblicas, para mitigar o risco da licitante vencedora do certame no
possuir a capacidade tcnica necessria para a execuo do objeto, a Lei 8.666/1993 prov, em seu
art. 30, mecanismos para que a futura contratada comprove estar tecnicamente apta para a prestao
dos servios. Isso se d, notadamente, por meio da apresentao de atestados de capacidade tcnica
que demonstrem a execuo de servios pertinentes e compatveis em caractersticas, quantidades e
prazos com o objeto da licitao.
280.2. Em relao ao risco em destaque, ainda que a licitante apresente os atestados exigidos
no instrumento convocatrio comprovando que j produziu sistemas utilizando mtodos geis, e ainda
que se faam diligncias para comprovar sua veracidade, h a possibilidade de que os resultados
demonstrados por esses documentos no sejam reproduzidos na nova contratao. Isso pode
acontecer em virtude, por exemplo, de alocao, pela contratada, de equipe inexperiente,
principalmente em contrataes de fbrica de software.
280.3. As consequncias possveis, quando da materializao do risco ora exposto, so atrasos
constantes na entrega dos produtos e gerao de produtos de baixa qualidade, resultando, em ltima
anlise, no no atendimento da necessidade da contratao.
280.4. Na primeira experincia do Inep de contratao de desenvolvimento de software com
mtodos geis (Contrato 1/2011 pea 23, p. 383), o risco em epgrafe materializou-se, conforme
relatado por membros da rea de TI equipe de fiscalizao. A equipe da empresa contratada
alocada para a prestao do objeto do contrato no detinha o conhecimento necessrio para o
cumprimento dos servios demandados, embora o instrumento convocatrio exigisse dos perfis
profissionais da contratada conhecimento em Scrum, entre outros (pea 23, p. 45-54).
281. Risco 10: dificuldade de comunicao entre a equipe de desenvolvimento da contratada
com o indicado pela rea de negcios (Product Owner).


37

281.1. A maior valorizao de indivduos e a interao entre eles em detrimento de processos e
ferramentas, expressa no Manifesto gil; o princpio no qual pessoas relacionadas a negcios e
desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto; e o
princpio no qual estabelecido que o mtodo mais eficiente e eficaz de transmitir informaes para, e
por dentro de um time de desenvolvimento, por meio de uma conversa cara a cara, deixam
evidente que a comunicao entre as pessoas envolvidas no processo de desenvolvimento do software
tem importncia fundamental.
281.2. Conforme preceituado pelo valor Comunicao do eXtreme Programming (XP),
dilogos presenciais so mais eficazes que videoconferncias, que, por sua vez, so melhores que
telefonemas, sendo esses mais expressivos que emails e assim sucessivamente (item 122.2). O dilogo
presencial evita que problemas de m compreenso e ambiguidades comprometam negativamente o
produto final.
281.3. Ainda que o indicado pela rea de negcios (Product Owner) da instituio contratante
tenha disponibilidade para atender o time de desenvolvimento da contratada, necessria a existncia
de canais de comunicao eficazes entre ambos. Nesse sentido, a alocao da equipe da contratada
nas instalaes da contratante tende a facilitar o processo de comunicao, ao passo que a
operacionalizao dos servios de desenvolvimento em uma localizao remota tende a dificult-lo.
268.4. A dificuldade de comunicao entre os membros do time de desenvolvimento com o
indicado pela rea de negcios tem como potenciais consequncias elaborao de produtos de baixa
qualidade, atrasos na entrega dos produtos e, em ltima anlise, traduz-se no no atendimento da
necessidade da contratao.
Riscos relativos a produtos
282. Risco 11: alterao constante da lista de funcionalidades do produto.
282.1. Uma vez que a mudana de requisitos durante o projeto bem aceita no
desenvolvimento de software com mtodos geis, conforme se constata da leitura do Manifesto gil e
de seus princpios, a lista de funcionalidades do produto pode ser constantemente alterada para
incluir, ainda no desenvolvimento, novas caractersticas inicialmente no planejadas, previstas ou
vislumbradas.
282.2. A alterao constante e descontrolada da lista de funcionalidades do produto durante o
contrato pode levar a instituio contratante a exceder prazos e custos de desenvolvimento
preliminarmente estimados. Por consequncia, a materializao do risco ora em destaque pode
conduzir execuo de desembolsos excessivos, contrapondo-se ao princpio constitucional da
economicidade e ao princpio do planejamento, bem como a atrasos na entrega do produto final ao
cliente (rea demandante), opondo-se ao princpio constitucional da eficincia.
283. Risco 12: iniciao de novo ciclo sem que os produtos construdos na etapa anterior
tenham sido validados.
283.1. O processo de construo do software por mtodos geis comumente d-se de forma
contnua ao longo de ciclos, iteraes ou sprints, nos quais um conjunto de funcionalidades
implementado. Algumas vezes, as funcionalidades a serem implementadas em um ciclo so
dependentes do funcionamento de outras, implementadas em ciclos anteriores.
283.2. Nesse tipo de situao, possvel que o ciclo no qual as funcionalidades previamente
implementadas ainda no tenha sido validado, isto , o produto gerado ainda no teve seu
recebimento definitivo efetivado pela instituio contratante. Caso esse produto no seja aceito, o
novo ciclo cujas funcionalidades so interdependentes e j iniciado fica prejudicado, ocasionando
potenciais atrasos na construo do software.
284. Risco 13: falta de planejamento adequado do software a ser construdo.
284.1. A doutrina gil pode levar instituies pblicas com equipes inexperientes ou sem nvel
de conhecimento tcnico adequado ao entendimento equivocado de seu uso, relegando o adequado
planejamento do produto a ser construdo. O planejamento pode ser iniciado, de forma global, pela


38

elaborao de documento da viso do produto e, de forma especfica, pela preparao do backlog do
produto (grooming), conforme estabelecido, por exemplo, no framework Scrum (item 110).
284.2. A rea tcnica da instituio contratante, por exemplo, pode entender que as f ases de
levantamento e de definio dos requisitos do software devem ocorrer, unicamente, durante as
iteraes de desenvolvimento. Tal entendimento pode ter como consequncias possveis a falta de
consistncia e de detalhamento da lista de funcionalidades a serem desenvolvidas (backlog do
produto), bem como a necessidade de alteraes do produto, comprometendo sua qualidade e
elevando o custo do projeto.
285. Risco 14: pagamento pelas mesmas funcionalidades do software mais de uma vez, em
virtude de funcionalidades impossveis de serem implementadas em um nico ciclo, ou em virtude da
alterao de funcionalidades ao longo do desenvolvimento do software.
285.1. A construo do software utilizando mtodos geis usualmente d-se em ciclos,
iteraes ou sprints, os quais possuem prazo fixo para seu trmino (time-box). Nesses ciclos,
funcionalidades do produto so selecionadas para serem implementadas. Podem existir
funcionalidades cujo prazo da iterao no seja suficiente para sua implementao completa, sendo
necessrios outros ciclos para a sua concluso. Nesses casos, os ciclos trataro de desenvolver novas
funcionalidades para aquelas parcialmente implementadas. Tambm possvel que, para a
implementao de uma nova funcionalidade, uma outra j implementada necessite ser ajustada.
285.2. Essas situaes, caso no previstas adequadamente no instrumento convocatrio,
podem fazer com que a instituio contratante efetue pagamentos pelas mesmas funcionalidades do
software repetidas vezes, conflitando com o princpio constitucional da economicidade.
286. Risco 15: no disponibilizao do software em ambiente de produo para a utilizao e
avaliao dos reais usurios.
286.1. Um dos objetivos dos mtodos geis a satisfao do cliente por meio da entrega
adiantada e contnua de software funcional.
286.2. Uma das formas de avaliar a satisfao do cliente disponibilizando o software no
ambiente de produo, mesmo que para um reduzido grupo de usurios, em um projeto piloto. O
objetivo dessa ao permitir que os usurios validem e opinem acerca das funcionalidades do
produto, construdas predominantemente segundo a viso do indicado pela rea de negcios (Product
Owner).
286.3. O uso do software pelos reais usurios possibilita a verificao de sua aderncia s
necessidades do negcio. Dessa forma, a demora na disponibilizao do software para a validao
junto aos usurios tem como consequncia potencial a deteco tardia de erros de concepo, com
consequente desperdcio de recursos e esforo.
273.4. Quando a equipe de fiscalizao visitou o Bacen, constatou-se que o Banco j tinha
finalizado alguns projetos no mbito do Contrato 50.412/2012, nos quais foram gerados softwares
que ainda no tinham sido disponibilizados no ambiente de produo.
287. Risco 16: forma de pagamento no baseada em resultados.
287.1. A mtrica popularmente adotada nas contrataes para produo de software pelas
instituies pblicas o ponto de funo. O ponto de funo mede o tamanho funcional do software, e
no o esforo envolvido em sua concepo e construo.
287.2. Esse fato comumente criticado pelas empresas fornecedoras, uma vez que a utilizao
do ponto de funo para remunerar os produtos por elas construdos pode no ser compatvel com o
esforo despendido e, por consequncia, com os recursos financeiros por ela consumidos em sua
produo.
287.3. No mbito de contrataes privadas, comum a utilizao de outras formas de
remunerao do fornecedor, como pagamento por iteraes ou sprints e pagamento por linhas de
cdigo (Source Lines of Code SLOC), que consiste em uma mtrica utilizada para mensurar o
tamanho de um software. Cumpre observar que algumas das formas adotadas na esfera privada no


39

consideram o resultado gerado pelo produto entregue. A remunerao da contratada por iteraes ou
sprints, por exemplo, constitui-se, na realidade, em pagamento por disponibilidade de mo de obra.
287.4. De forma a utilizar especificaes usuais praticadas no mercado, conforme preceitua o
2 do art. 3 do Decreto 3.555/2000, o qual regulamenta o prego, a instituio contratante pode ver-
se impelida a instituir em seu instrumento convocatrio modelo de remunerao desvinculado da
mensurao por resultados, em afronta farta jurisprudncia deste Tribunal de Contas, a qual se
encontra consolidada na Smula TCU 269:
Nas contrataes para a prestao de servios de tecnologia da informao, a remunerao
deve estar vinculada a resultados ou ao atendimento de nveis de servio, admitindo-se o pagamento
por hora trabalhada ou por posto de servio somente quando as caractersticas do objeto no o
permitirem, hiptese em que a excepcionalidade deve estar prvia e adequadamente justificada nos
respectivos processos administrativos. (grifo nosso)
274.5. Uma possvel consequncia da materializao do risco do pagamento somente pela
disponibilizao de mo de obra reside no recebimento de produtos de software sem qualidade,
resultando no no atendimento da necessidade da contratao.
7. Concluso
288. O conhecimento adquirido neste levantamento permitiu entender a essncia que orienta
as metodologias geis de desenvolvimento de software, as quais voltam seu foco, primordialmente,
para o atendimento das necessidades do cliente por meio da entrega contnua de softwares funcionais
e de qualidade.
289. Por sua vez, as anlises empreendidas no decorrer da execuo 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 que tm sido amplamente utilizadas ao longo dos ltimos anos.
290. Como em todo processo de contratao, h riscos que precisam ser considerados e
mitigados. Contudo, no caso especfico de adoo de mtodos geis, tratados como novidade no
mercado especializado nacional, sobretudo no mbito da APF, a gesto de riscos inerentes s
caractersticas do mtodo merece ateno especial, no sentido de possibilitar que as instituies
pblicas possam fazer uso das prticas previstas sem incorrer em descumprimento dos normativos
vigentes.
291. Por fim, cumpre registrar que o presente trabalho de fiscalizao cumpriu o objetivo
inicialmente vislumbrado, consistindo seu benefcio em servir de instrumento que suporte eventuais
fiscalizaes que tratem desse tema a serem realizadas por esta unidade tcnica especializada, no
havendo benefcios pecunirios.
8. Proposta de encaminhamento
292. Diante do exposto, prope-se o encaminhamento dos autos ao gabinete do Ministro Jos
Mcio Monteiro com as propostas que seguem:
292.1. levantar o sigilo deste processo em virtude de conter informaes relevantes s
instituies pblicas quanto s contrataes de servios de desenvolvimento de software utilizando
mtodos geis, mantendo-se o sigilo da pea 27 destes autos, uma vez que contm documentos que no
foram tornados pblicos pelas respectivas instituies proprietrias;
292.2. enviar, para conhecimento, cpia do acrdo que vier a ser proferido Secretaria de
Solues de TI e Secretaria de Controle Externo de Aquisies Logsticas, ambas vinculadas a este
Tribunal de Contas;
292.3. arquivar os presentes autos, com fulcro no art. 169, inciso V, do RITCU.

o relatrio.

VOTO


40

Em anlise, levantamento de auditoria realizado pela Sefti com o objetivo de conhecer a
utilizao de mtodos geis nas contrataes para desenvolvimento de software pela Administrao
Pblica Federal. Os trabalhos foram efetuados em entidades pblicas que j detm conhecimento
acerca dessa metodologia, dentre as quais se incluem o Banco Central do Brasil (Bacen), o Tribunal
Superior do Trabalho (TST), o Instituto do Patrimnio Histrico e Artstico Nacional (Iphan), o
Instituto Nacional de Estudos e Pesquisas Educacionais Ansio Teixeira (Inep) e o Supremo Tribunal
Federal (STF).
2. Os mtodos geis constituem um novo paradigma para a construo de sistemas
informatizados, ainda pouco difundidos nacionalmente, principalmente no mbito das instituies
pblicas. No entanto, sua adoo tem se mostrado crescente. Dessa forma, a Sefti entendeu necessrio
aprofundar seu conhecimento terico acerca do tema, verificar de que forma esto ocorrendo as
contrataes pblicas para desenvolvimento de software com base nesses mtodos, bem como
identificar riscos associados a essas contrataes.
3. As metodologias relacionadas a esse conceito propem diversas simplificaes com relao
aos mtodos tradicionais de desenvolvimento de software. Em essncia, buscam um processo mais
eficiente, por meio da eliminao de desperdcios e da entrega de produtos mais cleres e frequentes.
Seus fundamentos preceituam: a valorizao de indivduos e sua interao mais que processos e
ferramentas; a colaborao entre contratante e cliente acima da negociao de contratos ; e a aceitao
natural de mudanas de requisitos do produto, ante a obrigao de se seguir um plano. Essa nova
abordagem pressupe prticas como planejamento breve, execuo por iteraes, reduo expressiva
da documentao de software e maior autonomia dos desenvolvedores. O presente trabalho descreve
de forma detalhada os fundamentos tericos e tcnicas das metodologias geis que tm sido
recentemente empregadas em contrataes pblicas de sistemas de informao, denominadas Scrum,
eXtreme Programming (XP) e Kanban.
4. Essa simplificao proposta pelo modelo pode, sob certos aspectos, ser conflitante com as
particularidades inerentes s contrataes pblicas, em especial, com a necessidade de planejamento e
os princpios da impessoalidade e da vinculao ao instrumento convocatrio. No entanto, a anlise de
experincias empreendidas pelas entidades fiscalizadas permitiu verificar a existncia dessa
preocupao e que, mediante certas cautelas, possvel alinhar a utilizao dos mtodos geis aos
preceitos legais que regem a esfera pblica.
5. Complementado o levantamento, a unidade tcnica identificou uma srie de riscos inerentes
adoo dessa nova abordagem no setor pblico, dentre os quais destaco a possibilidade de se preterir
um planejamento adequado e de se adotar forma de pagamento no baseada em resultados. Acerca
deste ltimo, observa-se que a remunerao da contratada por iteraes, que constitui uma forma de
pagamento por disponibilidade de mo de obra, comum na esfera privada. Essa prtica, no entanto,
tratada como excepcionalidade pela jurisprudncia desta Corte, consubstanciada na Smula TCU 269:
Nas contrataes para a prestao de servios de tecnologia da informao, a remunerao
deve estar vinculada a resultados ou ao atendimento de nveis de servio, admitindo-se o pagamento
por hora trabalhada ou por posto de servio somente quando as caractersticas do objeto no o
permitirem, hiptese em que a excepcionalidade deve estar prvia e adequadamente justificada nos
respectivos processos administrativos.
6. Feitas essas consideraes, entendo que o levantamento realizado pela Sefti atendeu a
contento seus objetivos, que se restringem ao estudo da nova metodologia e sua aplicao nas
contrataes pblicas, razo pela qual acolho a proposta de arquivamento dos autos, sem prejuzo da
retirada do sigilo de suas peas, exceo da nmero 27, em face da relevncia das informaes para
as instituies que procederem s mencionadas contrataes.


41

Ante o exposto, voto por que o Tribunal adote o acrdo que ora submeto ao Plenrio.

TCU, Sala das Sesses Ministro Luciano Brando Alves de Souza, em 28 de agosto de 2013.

JOS MCIO MONTEIRO
Relator

ACRDO N 2314/2013 TCU Plenrio

1. Processo n TC 010.663/2013-4
2. Grupo I Classe V Levantamento de Auditoria
3. Interessado: Tribunal de Contas da Unio
4. Unidades: Tribunal Superior do Trabalho (TST); Banco Central do Brasil (Bacen); Instituto do
Patrimnio Histrico e Artstico Nacional (Iphan); Instituto Nacional de Estudos e Pesquisas
Educacionais Ansio Teixeira (Inep); Supremo Tribunal Federal (STF)
5. Relator: Ministro Jos Mcio Monteiro
6. Representante do Ministrio Pblico: no atuou
7. Unidade Tcnica: Secretaria de Fiscalizao de Tecnologia da Informao - Sefti
8. Advogado constitudo nos autos: no h

9. Acrdo:
VISTOS, relatados e discutidos estes autos de levantamento de auditoria realizado pela Sefti
com o objetivo de conhecer a utilizao de mtodos geis nas contrataes para desenvolvimento de
software pela Administrao Pblica Federal,
ACORDAM os Ministros do Tribunal de Contas da Unio, reunidos em Sesso do Plenrio,
com fundamento no art. 4, 2 da Resoluo 254/2013 do TCU, art. 169, inciso V do Regimento
Interno do TCU, e ante as razes expostas pelo Relator, em:
9.1. levantar o sigilo deste processo, por conter informaes relevantes s instituies pblicas
quanto s contrataes de servios de desenvolvimento de software utilizando mtodos geis,
exceo da pea 27, uma vez que contm documentos que no foram tornados pblicos pelas
respectivas instituies proprietrias;
9.2. determinar Sefti que aprofunde os estudos, inclusive com realizao de fiscalizaes, se
forem necessrias, visando a identificar, com maior preciso, os riscos envolvidos na utilizao dos
mtodos geis na contratao de desenvolvimento de software pela Administrao Pblica Federal,
segundo o modelo atual de contratao, de maneira a orientar adequadamente os jurisdicionados deste
Tribunal;
9.3. dar cincia desta deciso Secretaria de Solues de TI e Secretaria de Controle Externo
de Aquisies Logsticas deste Tribunal de Contas;
9.4. arquivar os presentes autos.

10. Ata n 33/2013 Plenrio.
11. Data da Sesso: 28/8/2013 Ordinria.
12. Cdigo eletrnico para localizao na pgina do TCU na Internet: AC-2314-33/13-P.
13. Especificao do quorum:


42

13.1. Ministros presentes: Aroldo Cedraz (na Presidncia), Walton Alencar Rodrigues, Benjamin
Zymler, Raimundo Carreiro, Jos Jorge, Jos Mcio Monteiro (Relator) e Ana Arraes.
13.2. Ministro-Substituto presente: Augusto Sherman Cavalcanti.

(Assinado Eletronicamente)
AROLDO CEDRAZ
JOS MCIO MONTEIRO
na Presidncia Relator
Fui presente:

PAULO SOARES BUGARIN
Procurador-Geral

Acordao Legado 116247

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Acordao Legado 116247

Uploaded by

Copyright:

Available Formats

TRIBUNAL DE CONTAS DA UNIO TC 010.

You might also like