Acordao Legado 116247

TRIBUNAL DE CONTAS DA UNIO
TC 010.663/2013-4
GRUPO I CLASSE V PLENRIO TC 010.663/2013-4 Natureza: Levantamento de Auditoria Interessado: 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 1
TC 010.663/2013-4
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 2
TC 010.663/2013-4
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 3
TC 010.663/2013-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. 4
TC 010.663/2013-4
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, respectivamente, 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 requisitos 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 5
TC 010.663/2013-4
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 6
TC 010.663/2013-4
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 7
TC 010.663/2013-4
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 autoorganizveis. 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 8
TC 010.663/2013-4
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 geis 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 9
TC 010.663/2013-4
- 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. 10
TC 010.663/2013-4
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 servolder 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 11
TC 010.663/2013-4
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). 12
TC 010.663/2013-4
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). 13
TC 010.663/2013-4
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 14
TC 010.663/2013-4
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.
15
TC 010.663/2013-4
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. 16
TC 010.663/2013-4
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 17
TC 010.663/2013-4
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
18
TC 010.663/2013-4
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. 19
TC 010.663/2013-4
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 bastante 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 20
TC 010.663/2013-4
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 desenvolvimento 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 21
TC 010.663/2013-4
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). 22
TC 010.663/2013-4
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 23
TC 010.663/2013-4
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 instrumento 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 24
TC 010.663/2013-4
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 Empresa Base do Interessa ao objeto da contratada framework levantamento contratao de gerncia utilizado TST Prego Eletrnico Fbrica de Squadra Scrum Sim 146/2012 software Tecnologia em Software Ltda. Bacen Prego Eletrnico Fbrica de Politec Tecnologia Scrum Sim Demap 7/2012 software da Informao S.A. Iphan Prego Eletrnico 2/2011 TR em elaborao Prego Eletrnico 1/2010 Prego Eletrnico 14/2012 Prego Eletrnico 84/2012 No obtido Projeto Fbrica de software Fbrica de software Fbrica de software Fbrica de software Fbrica de software levantamento de requisitos Fbrica de software construo Fbrica de software Fbrica de software Projeto EGL Engenharia Ltda. No se aplica Squadra Tecnologia em Software Ltda. Cast Informtica S.A. Basis Tecnologia da Informao S.A. CTIS Tecnologia S.A. Cast Informtica S.A. CTIS Tecnologia S.A. Informao no obtida Scrum Scrum Scrum Scrum Scrum Metodologia tradicional Metodologia tradicional Scrum No obtido Sim Sim Sim Sim Sim No
Inep
STF Datasus
No obtido Prego Eletrnico 19/2013 Informao no obtida Dispensa de licitao
No No No
EBSER H Serpro
No se aplica Scrum No (Serpro fornecedor) 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 25
TC 010.663/2013-4
utilizaram pontos de funo para dimensionar e pagar os servios contratados, conforme apresentado na tabela seguinte. rgo Contrato Mtrica Quantitativo Valor Valor Total Anual Unitrio (R$) (R$) 146/2012 Horas de servio 1.060 49,00 1.572.740,00 tcnico (HST) 24.000 49,00 TST 4.200 62,38 1.380 60,00 50.412/2012 Pontos de funo 16.560 459,27 7.605.511,20 Bacen 1 Aditivo 488,24 8.085.254,40 28/2011 Pontos de funo 2.000 495,00 990.000,00 Iphan Em planejamento Pontos de funo 5.000 1/2011 Pontos de funo 20.000 349,20 6.984.000,00 Inep 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. Tribunal Superior do Trabalho (TST) 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 26
TC 010.663/2013-4
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). Banco Central do Brasil (Bacen) 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 27
TC 010.663/2013-4
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). Instituto do Patrimnio Histrico e Artstico Nacional (Iphan) 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, 28
TC 010.663/2013-4
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). Instituto Nacional de Estudos e Pesquisas Educacionais Ansio Teixeira (Inep) 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). Supremo Tribunal Federal (STF) 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 29
TC 010.663/2013-4
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. 30
TC 010.663/2013-4
Tribunal Superior do Trabalho (TST) 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. Banco Central do Brasil (Bacen) 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). Instituto do Patrimnio Histrico e Artstico Nacional (Iphan) 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). Instituto Nacional de Estudos e Pesquisas Educacionais Ansio Teixeira (Inep) 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). 31
TC 010.663/2013-4
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). Supremo Tribunal Federal (STF) 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. 32
TC 010.663/2013-4
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 contratante 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 33
TC 010.663/2013-4
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 34
TC 010.663/2013-4
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. 35
TC 010.663/2013-4
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). 36
TC 010.663/2013-4
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 37
TC 010.663/2013-4
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 fases 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 38
TC 010.663/2013-4
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 39
TC 010.663/2013-4
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.
40
TC 010.663/2013-4
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: 41
TC 010.663/2013-4
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) (Assinado Eletronicamente)
AROLDO CEDRAZ na Presidncia Fui presente:

(Assinado Eletronicamente)
JOS MCIO MONTEIRO Relator
PAULO SOARES BUGARIN Procurador-Geral
42

Acordao Legado 116247

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Acordao Legado 116247

Enviado por

Direitos autorais:

Formatos disponíveis

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

No obtido Prego Eletrnico 19/2013 Informao no obtida Dispensa de licitao

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

TRIBUNAL DE CONTAS DA UNIO

AROLDO CEDRAZ na Presidncia Fui presente:

JOS MCIO MONTEIRO Relator

PAULO SOARES BUGARIN Procurador-Geral

Você também pode gostar