Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações
mitigadoras
Xxxx Xxxxx xx Xxxxx
Universidade Católica de Brasília (UCB)
Xxxx Xxxxx Xxxx
Universidade Católica de Brasília (UCB)
Esta pesquisa teve como objetivo identificar ações de mitigação de riscos para a administração pública federal na contratação de soluções de desenvolvimento de software com a metodologia ágil Scrum. Para isso, foi realizada uma pesquisa bibliométrica sobre métodos ágeis, desenvolvimento de software, fábrica de software e terceirização de TI. Em seguida, foram criados mapas mentais para explicitar a IN nº 04/2014 e descreveu-se a metodologia Scrum e o Acórdão no 2314/2013 TCU/Plenário. A aplicação de survey permitiu identificar os cinco riscos de maior importância na contratação de desenvolvimento de software com métodos ágeis pela administração pública federal. Em seguida, foi realizado um grupo de foco para discutir a mitigação dos riscos apresentados, que contextualizou as informações apresentadas no survey. Mesmo havendo poucos instrumentos legais específicos para apoio, concluiu-se que é possível uma contratação de desenvolvimento de software com a metodologia Scrum, desde que sejam considerados aspectos como: a IN nº 04/2014, o Acórdão no 2314/2013, os demais instrumentos legais disponíveis e, ainda, as ações de mitigação apresentadas neste estudo.
Palavras-chave: administração federal, tecnologia da informação, gestão de risco, gestão de pessoas
Artigo submetido em fevereiro de 2014. Versão final em setembro de 2014.
97
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Contratación del desarrollo ágil de software en la administración pública federal: riesgos y acciones mitigadoras
Esta investigación tuvo como objetivo identificar acciones para mitigar los riesgos para la administración pública federal en la contratación de soluciones de desarrollo de software con la metodología ágil Scrum. Para ello, fue realizada una investigación bibliométrica sobre métodos ágiles, desarrollo de software, fábrica de software y tercerización de TI (IT Outsourcing). A continuación, fueron creados mapas mentales para elucidar la Instrucción Normativa (IN) 04/2014, y se describió la metodología ágil Scrum y la Sentencia 2314/2013 TCU/Pleno. La aplicación de la encuesta permitió que se identificaran los cinco riesgos más importantes en la contratación de desarrollo de software con métodos ágiles por la administración pública federal. Luego, un grupo de discusión se llevó a cabo para discutir la mitigación de los riesgos presentados, y las informaciones contextualizadas en la encuesta. Incluso con pocos instrumentos legales específicos al apoyo, se concluyó que es posible la contratación del desarrollo de software con la metodologia Scrum, desde que sean considerados los aspectos como: la IN 04/2014, o la Sentencia 2314/2013 TCU/Pleno, los demás instrumentos legales disponibles e incluso las acciones de mitigación presentadas en este estudio.
Palabras clave: administración federal, software, tecnología de la información, gestión de riesgo, gestión de personas
Hiring software development with agile methods in the Brazilian Federal Administration: key risks and mitigations
This research aimed to identify actions to mitigate risks to the Brazilian Federal Administration in hiring software development solutions with the agile Scrum methodology. For this, a bibliometric research on agile methods, software development and IT outsourcing was performed. Then, mind maps were created to explain the IN 04/2010 Normative Instruction. Also, the Scrum methodology and the 2314/2013 Judgment of the Court of Accounts were described. A survey was applied to identify the five most important risks in hiring software development with agile methods in the Brazilian Federal Administration. Next, a focus group was held to discuss the mitigation of the presented risks, and contextualized information presented in the survey. Even with few specific legal instruments to support, we conclude that it is possible to hire software development with Scrum, as long as some aspects are considered: the IN 04/2010 Normative Instruction, the 2314/2013 Judgment of the Court of Accounts, other legal instruments available and mitigation actions presented in this study.
Keywords: federal government, software, information technology, risk management, people management
98 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Introdução
A administração pública federal (APF) é regida por princípios legais, conforme o artigo 37 da Constituição Federal Brasileira (CF), de 5 de outubro 1988 (Brasil, 1988), que estabelece que a administração pública direta e indireta de qualquer um dos Poderes da União, dos Estados, do Distrito Federal e dos Municípios deve obedecer aos princípios da legalidade, impessoalidade, moralidade, publicidade e eficiência. Assim, esses princípios regulam o modo de agir da administração pública, ou seja, eles “são necessários para nortear o direito, embasando como deve ser”. (Xxxxxx; Xxxxxx, 2012, p. 1-2).
Enquanto os princípios legais são os norteadores da administração pública, o Decreto-Lei nº 200/1967 (Brasil, 1967) dispõe sobre a organização da administração federal. O seu artigo 6º estabelece que as atividades da administração federal atendam aos princípios fundamentais de planejamento, coordenação, descentralização, delegação de competência e controle. A partir da vigência desse decreto é que a contratação de serviços terceirizados passou a ser regulamentada por norma legal, conforme Xxxxxx (2013, p. 17-18):
A partir do Decreto nº 200/1967 (Brasil, 1967), onde se diz que a APF deve se concentrar nas tarefas de planejamento, coordenação, descentralização, delegação de competência e controle, é que os serviços como transporte, informática e copeiragem devem ser feitos por terceiros. A tecnologia da informação, por sua vez, vem sendo terceirizada sem critérios.
A terceirização de serviços deve seguir esses princípios, levando em consideração, também, a Lei nº 8.666/1993 (Brasil, 1993), que institui normas para licitações e contratos na administração pública. No âmbito da tecnologia da informação (TI), foi criada a Instrução Normativa MP/SLTI n° 04/2008 (Brasil, 2008), pela Secretaria de Logística e Tecnologia da Informação (SLTI), que tem, entre suas atribuições, a competência de planejar, coordenar, supervisionar e orientar, normativamente, as atividades do Sistema de Administração dos Recursos de Tecnologia da Informação (SISP), propondo políticas e diretrizes de tecnologia da informação no âmbito da administração pública federal direta, autárquica e fundacional. A referida Instrução Normativa (IN), que objetiva estabelecer o processo de contratação de soluções de TI pelos órgãos integrantes do SISP, no âmbito do Poder Executivo federal (Brasil, 2008), foi atualizada pela IN MP/SLTI nº 04/2014 (Brasil, 2014), neste artigo identificada por IN nº 04/2014.
A IN nº 04/2014 trouxe algumas melhorias ao processo de contratação. Dentre essas, segundo a SLTI, destacam-se: (I) O foco renovado no alinhamento ao Plano Diretor de Tecnologia da Informação (PDTI) e na atuação do Comitê de TI. (II) A revisão
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015 99
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
das exceções de aplicação da IN, como a definição de serviços estratégicos para contratação de empresas públicas e a definição de serviços que possam comprometer a segurança nacional, no sentido da aplicação de nova regulamentação. (III) A melhoria na eficiência do processo com a redução do número de artefatos e simplificação dos seus trâmites, e aproximação ao descrito na legislação. (VI) O detalhamento e aprimoramento dos elementos contidos no termo de referência e no projeto básico.
(VII) A definição de modelos de execução e gestão do contrato. As principais alterações da IN nº 04/2014 consistiram em:
• No capítulo I, artigo 2º, Inciso III foi definido que a área administrativa terá competência para planejar, coordenar, supervisionar e executar as atividades relacionadas aos processos de contratação. Também no capítulo I, artigo 3º, foi atualizada a redação e acrescentado o decreto nº 7.579, de 2011 que dispõe sobre o Sistema de Administração dos Recursos de Tecnologia da Informação. Já no artigo 4º, foram acrescentados os parágrafos 1º ao 7º detalhando a importância da utilização do PDTI, EGTIC, PPA, Comitê de Segurança da Informação, dentre outros.
• No capítulo II, houve alteração na fase do processo de contratação, artigo 9º, onde foram definidas, de maneira detalhada, as suas etapas e também reformula o texto, explicitando a leitura e interpretação. Continuando nesse mesmo capítulo, o artigo 16 passa a detalhar a justificativa para uma contratação. Já o artigo 18 descreve o que deverá ser observado na definição das responsabilidades da contratante, da contratada e do órgão gerenciador do registro de preços, quando aplicável. Ainda no capítulo II, na seção II, que trata da seleção do fornecedor, houve alteração no artigo 30, descrevendo que essa fase se encerrará com a assinatura do contrato e com a nomeação do: (I) Gestor do Contrato; (II) Fiscal Técnico do Contrato; (III) Fiscal Requisitante do Contrato e (IV) Fiscal Administrativo do Contrato.
Conforme Xxxxxx (2013), a principal dificuldade da APF para aplicar a IN nº 04 é a falta de servidores com capacidade de interpretá-la de forma adequada. O Tribunal de Contas da União (TCU), desse modo, publicou o Guia de Boas Práticas em Contratação de Soluções de Tecnologia da Informação (Brasil, 2012), com o objetivo de contribuir no planejamento de contratações de bens e serviços de TI nos órgãos e entidades da APF, para o aprimoramento de suas operações e entrega dos resultados desejados pela sociedade.
O artigo 4º da IN nº 04/2014 estabelece, por exemplo, que as contratações de TI devem ser precedidas de planejamento, elaboradas em harmonia com o PDTI do órgão, que deve estar alinhado com o planejamento estratégico institucional. De acordo com o Guia de Boas Práticas em Contratação de Soluções de Tecnologia da Informação (Brasil, 2012), o planejamento da contratação é fundamental para que:
(i) a contratação agregue valor ao órgão; (ii) os riscos envolvidos sejam gerenciados;
100 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
(iii) a contratação esteja alinhada com o planejamento do órgão governante superior, ao qual esteja vinculado o órgão contratante e de TI desse órgão; (iv) os recursos envolvidos sejam bem utilizados, não só os recursos financeiros, mas também os recursos humanos. Cabe destacar que o planejamento do processo de contratação de soluções de TI, conforme a IN nº 04/2014, deve seguir três fases: (i) planejamento da contratação; (ii) seleção do fornecedor; e (iii) gestão do contrato.
No contexto normativo do planejamento, adquire relevância a contratação do desenvolvimento de software com a adoção de métodos ágeis, cada vez mais considerados como uma proposta alternativa aos métodos tradicionais, possuindo características próprias e atraindo cada vez mais seguidores pelos resultados satisfatórios. Porém, a sua implantação requer cuidados. No Brasil, por exemplo, um estudo apresentado por Xxxx x Xxxxxxxx (2010) permitiu observar que as principais dificuldades enfrentadas na implantação de métodos ágeis não estão relacionadas ao aprendizado de suas práticas, mas, sim, à necessidade de mudança da cultura organizacional. Ressalta, também, que, enquanto apenas o projeto de desenvolvimento de software for gerenciado de forma ágil e o restante da organização mantiver os vícios e hábitos culturais derivados dos processos tradicionais, não será possível usufruir plenamente dos seus benefícios. As autoras do estudo declaram, ainda, que, para os métodos ágeis serem adotados em uma organização, são necessários diversos passos de planejamento e uma execução cuidadosa.
Recentemente, o TCU publicou o Acórdão nº 2314/2013 TCU/Plenário, advindo do levantamento de auditoria em órgãos da APF com o objetivo de conhecer a utilização de métodos ágeis nas contratações para desenvolvimento de software. Nesse levantamento, o TCU “identificou uma série de riscos inerentes à adoção dessa nova abordagem no setor público, dentre os quais se destaca a possibilidade de se preterir um planejamento adequado e de se adotar forma de pagamento não baseada em resultados” (Brasil, 2013b, p. 40).
Referencial teórico
A IN nº 04 foi criada em 12 de novembro de 2010, com objetivo de estabelecer o processo de contratação de soluções de TI pelos órgãos integrantes do SISP.
Nesse documento observa-se a necessidade do Plano Diretor de Tecnologia da Informação (PDTI), que é um instrumento de diagnóstico, planejamento e gestão dos recursos e processos de TI, que visa atender às necessidades tecnológicas e de informação de um órgão ou entidade para um determinado período. Em se tratando de PDTI, o órgão da APF deve estar alinhado com o seu Planejamento Estratégico Institucional (PEI), pois a IN nº 04/2014, no próprio artigo 4º, descreve que:
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
101
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
“inexistindo o planejamento estratégico institucional, sua ausência deverá ser registrada no PDTI e deverá ser utilizado um documento equivalente, como o Plano Plurianual – PPA”. (IN nº 04/2014, p. 4).
Por isso, o órgão integrante deve considerar que as contratações de que trata a IN nº 04/2014 deverão ser precedidas de um planejamento elaborado em harmonia com o PDTI e alinhado ao planejamento estratégico do órgão ou entidade. No capítulo II, denominado de processo da contratação, contemplam-se as fases que deverão ser seguidas para as diversas contratações de solução de TI. O capítulo está dividido em três seções, que abordam todo o procedimento para a execução das fases. Para que uma contratação seja efetuada, as três fases deverão ser contempladas, obedecendo à sequência de planejamento da contratação, seleção de fornecedor e, por fim, o gerenciamento da contratação.
O artigo 9º, que abre a seção I, descreve as necessidades relacionadas com o planejamento da contratação. O planejamento da contratação, de acordo com
o artigo 3º da Lei nº 8.666/93 (Brasil, 1993), trata de licitações e da seleção da alternativa de contratação mais vantajosa para a APF, em subordinação aos princípios da motivação, da isonomia, da legalidade, da impessoalidade, da moralidade, da igualdade, da publicidade, da eficiência, da probidade administrativa, da vinculação ao instrumento convocatório e do julgamento objetivo, bem como às diretrizes de ampliação da competitividade e de garantia ao atendimento do interesse público, da finalidade e da segurança da contratação.
No artigo 10, todos os incisos devem ser observados, com ênfase no inciso I, que trata da análise de viabilidade da contratação. Destaca-se, também, o inciso IV por tratar da escolha da solução de TI e da justificativa da escolha, com base nas necessidades de negócio. É importante que se faça o alinhamento e identificação dos benefícios a serem alcançados com a solução escolhida em termos de eficácia, eficiência, efetividade e economicidade. No inciso II, alínea b, cobra-se a consulta ao Portal do Software Público Brasileiro, para verificar se já há soluções disponíveis para os órgãos da APF.
A seleção de fornecedor deve ser realizada de forma que a contratação seja a mais vantajosa possível, garantindo o tratamento isonômico ao mercado, em consonância à Lei nº 8.666/93 (Brasil, 1993), artigo 3º. Quando trata de TI, em consequência da padronização existente no mercado de tecnologia da informação, é recomendada a utilização da modalidade pregão para as contratações de que trata essa IN nº 04/2014, preferencialmente na forma eletrônica.
A seção III intitula-se gerenciamento do contrato. Nela, o artigo 25, em seu inciso II e alínea a, prevê que haja uma definição e especificação dos serviços a serem realizados ou bens a serem fornecidos. Também é no artigo 25 que se determina
102 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
acompanhar e garantir a adequada prestação dos serviços e o fornecimento dos bens que compõem a solução de TI, durante todo o período de execução do contrato. Já no artigo 26, dessa mesma seção, são considerados os processos realizados para controlar a execução do projeto, de forma que possíveis problemas possam ser identificados no momento adequado e que possam ser tomadas as ações corretivas, quando necessário.
Métodos ágeis
Os métodos ágeis surgiram a partir do manifesto ágil1, em 2001, e seus princípios estão focados em resultados rápidos e entregas constantes. As suas principais características estão relacionadas à entrega rápida e objetiva, iterações curtas e documentação leve, permitindo alterações imediatas. O manifesto enfatiza, ainda, a prioridade dos projetos e a documentação mínima e eficiente.
De acordo com Xxxx (2008), desenvolver um software sem nenhuma sistematização é um verdadeiro caos; entretanto, utilizar processos pesados também se torna oneroso em relação aos custos e ao tempo dispendido no projeto. Assim, a metodologia ágil de desenvolvimento de software representa uma solução, pois define regras e rotinas que não “pesam” no desenvolvimento, mas tornam o ambiente controlado e mais rápido. O autor argumenta, também, que a maioria dos métodos ágeis possui uma característica em comum: iterações de curto período de tempo, por exemplo, uma semana ou um mês. Segundo Xxxxxxx e Xxxxx (2009), os métodos ágeis têm sido adotados para aumentar a efetividade das equipes de desenvolvimento de produto, criando sistemas que agregam valor ao negócio do cliente.
Conforme Sommerville (2011, p. 39), a ideia de desenvolvimento e entregas rápidas de software realmente “decolou” no final da década de 1990, com o desenvolvimento da noção de abordagens ágeis. Ainda para Sommerville (2011), essas abordagens são de desenvolvimento incremental, com incrementos pequenos, e, normalmente, as novas versões do sistema são criadas e disponibilizadas aos clientes assim que estiverem concluídas. Sendo assim, envolvem os clientes no processo de desenvolvimento para obtenção de feedback rápido sobre a evolução dos requisitos. A documentação mínima decorre da prevalência da comunicação informal sobre reuniões formais com documentos escritos.
1 Manifesto ágil - valores e princípios que fundamentam o desenvolvimento ágil de software. Disponível em:
<xxxx://xxxxxxxxxxxxx.xxx.xx/>
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
103
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Misra et al. (2011) descrevem que as metodologias de desenvolvimento de software ágeis são atualmente uma abordagem de engenharia de software emergente, que se constituiu de um conjunto de princípios defendidos inicialmente por um grupo de dezessete profissionais de software, e agora é praticada por muitos profissionais da área. Ainda de acordo com Xxxxx et al. (2011), as metodologias ágeis são baseadas em um conjunto de princípios que orientam a natureza genérica de todas as diferentes metodologias ágeis. Os doze princípios enunciados no manifesto ágil são descritos por Xxxxx et al. (2011, p. 975):
1) A maior prioridade é dada à satisfação do cliente por meio da entrega adiantada e contínua de software valioso.
2) Mudanças de requisitos são bem-vindas, mesmo tardiamente, durante o desenvolvimento. Mudança ágil nos processos é o cerne da vantagem competitiva do negócio do cliente.
3) Software de trabalho é entregue com frequência, a partir de um par de semanas ou de um par de meses, com preferência para a escala de tempo mais curta.
4) Pessoas de negócios e desenvolvedores trabalham juntos diariamente durante o projeto.
5) Os projetos são construídos em torno de indivíduos motivados. Eles recebem o ambiente e o apoio de que precisam.
6) O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento é a conversa face a face.
7) O software de trabalho é a principal medida de progresso.
8) Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante, indefinidamente.
9) A atenção contínua, a excelência técnica e o bom design aumentam a agilidade.
10) A simplicidade é essencial.
11) As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.
12) O sucesso é alcançado quando, em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, e então ajusta seu comportamento de acordo.
Segundo Xxxx e Xxxxxxxxxxx (2008, p. 58), as metodologias ágeis mais conhecidas são XP e Scrum, sendo que a Scrum está mais relacionada a uma boa gestão do projeto,
104 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
aumentando a possibilidade de sucesso no desenvolvimento do software. Por outro lado, o XP tem foco nas atividades relacionadas à implantação do software. Dyba e Dingsøyr (2008), por sua vez, consideram metodologias ágeis as seguintes: Metodologias Crystal, Método de desenvolvimento de software dinâmico, Desenvolvimento Guiado por Funcionalidades (FDD), Desenvolvimento de software Lean, Extreme Programming (XP e XP2) e Scrum.
O método Scrum foi desenvolvido por Schwaber e Sutherland (2011) e, segundo eles, esse método é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de 1990. Centra-se na gestão de projetos em situações em que é difícil planejar com antecedência e se utiliza de mecanismos de controle de processos empíricos, em que laços de feedback constituem o elemento central. O software é desenvolvido por uma equipe auto- organizada, em incrementos chamados Sprints, começando com o planejamento e terminando com um comentário ou revisão.
Os recursos a serem implementados no sistema devem ser registrados em um documento. Em seguida, o proprietário do produto decide quais itens registrados devem ser desenvolvidos na Sprint seguinte. Os membros da equipe devem coordenar o seu trabalho em um encontro, desde que seja uma reunião diária rápida. Um membro da equipe, o Scrum master, é encarregado de resolver os problemas que impedem a equipe de funcionar eficazmente.
Schwaber e Xxxxxxxxxx (2011, p. 4) esclarecem que o Scrum apresenta quatro oportunidades formais para inspeção e adaptação, que são: reunião de planejamento da Sprint, reunião diária (Daily Scrum), reunião de revisão da Sprint, retrospectiva da Sprint. Para eles:
o coração do Scrum é a Sprint, que é uma iteração de um mês ou menos, de duração consistente com o esforço de desenvolvimento. Todas as Sprint utilizam o mesmo modelo de Scrum e todas as Sprint têm como resultado um incremento do produto final que é potencialmente entregável. Cada Sprint começa imediatamente após a anterior (Schwaber; Sutherland, 2011, p. 8).
De acordo com Xxxxxxxx e Xxxxxxxxxx (2011, p. 5), o time Scrum é composto por: product owner, equipe de desenvolvimento e Scrum master. Esse time deve ser auto-organizável, por escolher qual a melhor forma de trabalho, e multifuncional, por possuir todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de equipe do Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. A entrega de produtos acontece de forma iterativa e incremental, maximizando as oportunidades de realimentação.
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
105
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
O primeiro a compor o time Scrum é o product owner, ou dono do produto, que é o responsável por maximizar o valor do produto e do trabalho da equipe de desenvolvimento. Ele é a única pessoa responsável por gerenciar o backlog do produto. Esse gerenciamento inclui expressar claramente os itens do backlog do produto; ordenar os itens do backlog do produto para alcançar as metas; garantir o valor do trabalho realizado pelo time de desenvolvimento; garantir que o backlog do produto seja visível, transparente e claro para todos; mostrar o que o time Scrum vai trabalhar a seguir; e garantir que a equipe de desenvolvimento entenda os itens do backlog do produto no nível necessário.
A equipe de desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão utilizável que, potencialmente, incrementa o produto “pronto” ao final de cada Sprint. A equipe não contém subequipes dedicadas a domínios específicos de conhecimento, tais como de testes ou de análise de negócios. Essa deve ser pequena o suficiente para se manter ágil, e grande o suficiente para completar uma parcela significativa do trabalho. Já o Scrum master é o responsável por garantir que o Scrum seja entendido e aplicado, ajudando aqueles que estão fora do time Scrum a entender quais as suas interações com o time.
Conforme descrevem Xxxxxxxx e Xxxxxxxxxx (2011, p. 7), os eventos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões. Deve-se garantir que uma quantidade adequada de tempo seja gasta no planejamento, sem permitir perdas nesse processo. Cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. Esses eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa.
Gestão de riscos na APF
A norma brasileira de gestão de riscos de segurança da informação, ABNT NBR ISO/IEC 27005:2011 (ABNT, 2011), define em detalhes, no seu Capítulo 6 – Procedimentos, uma abordagem sistemática do processo geral de gestão de riscos, que é composto pelas etapas de definições preliminares, análise/avaliação dos riscos, plano de tratamento dos riscos, aceitação dos riscos, implementação do plano de tratamento dos riscos, monitoração e análise crítica, melhoria de todo o processo e comunicação do risco. Essa abordagem geral, sistemática, pode ser aplicada a riscos de qualquer tipo.
No caso específico dos órgãos da APF, a Norma Complementar nº 04/IN01/ DSIC/GSI/PR, do Gabinete de Segurança Institucional (Brasil, 2013a), que tem por objetivo estabelecer diretrizes para o processo de gestão de riscos de segurança da informação e comunicação nos órgãos ou entidades da administração pública federal, direta ou indireta, também pode ser aplicada, pois se baseia na mesma norma da ABNT.
106 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Acórdão nº 2314/2013 TCU/Plenário (BRASIL, 2013b)
Em 2013, o TCU realizou um levantamento acerca da utilização de contratações de métodos ágeis para o desenvolvimento de software nos órgãos da APF, motivado pelo fato de diversos órgãos já terem iniciado processos de contratação desse tipo. Desse relatório de levantamento, originou-se o Acórdão nº 2314/2013 TCU/Plenário.
Segundo o Acórdão nº 2314/2013 TCU/Plenário, a Secretaria de Fiscalização de Tecnologia da Informação (SEFTI) propôs a realização desse levantamento com o objetivo de conhecer as bases teóricas do processo de desenvolvimento de software com métodos ágeis e, ainda, conhecer as práticas desse tipo de contratação realizadas na APF. O Acórdão nº 2314/2013 TCU/Plenário é composto de conceitos teóricos e das origens de algumas metodologias de desenvolvimento de sistemas de informação, envolvendo tanto metodologias tradicionais quanto métodos ágeis.
Conforme o Acórdão nº 2314/2013 TCU/Plenário (Brasil, 2013b, p. 21), em relação à terceirização de desenvolvimento de software com métodos ágeis nas instituições da APF visitadas, alguns órgãos “possuem boa estrutura interna de TI, como o Tribunal Superior do Trabalho (TST), Banco Central do Brasil (Bacen) e Supremo Tribunal Federal (STF). Essas três instituições possuem equipes de servidores do próprio quadro que atuam no desenvolvimento de software utilizando métodos ágeis”. Por outro lado:
o Instituto do Patrimônio Histórico e Artístico Nacional (Iphan) possui grande carência de profissionais de TI em seu quadro. Todo o desenvolvimento de novos sistemas de informação é executado por empresas terceirizadas. Já o Instituto Nacional de Estudos e Pesquisas Educacionais Xxxxxx Xxxxxxxx (Inep), sob a perspectiva de pessoal da área de TI, encontra-se em situação momentaneamente mais confortável do que o Iphan. A área de TI do Inep, quando da visita da equipe de fiscalização, contava com cinco servidores do quadro, além de 37 profissionais com contratos temporários da União (CTU). Contudo, alguns desses profissionais deverão deixar o instituto no próximo ano em virtude do término da vigência de seus contratos temporários de trabalho, não havendo previsão de que venham a ser substituídos (Brasil, 2013, p. 21).
A equipe de fiscalização visitou, também, o Serpro para coletar informações referentes à utilização de métodos ágeis pelo lado do fornecedor, pois esse desenvolveu o sistema Novo Siafi para a Secretaria do Tesouro Nacional (STN), fazendo uso do framework Scrum. Cabe ressaltar que, num primeiro momento, o Serpro adotou uma metodologia tradicional, que fracassou. Em seguida, o Serpro propôs à STN a execução do serviço utilizando métodos ágeis, o que foi prontamente aceito. Grande parte dos requisitos já especificados na tentativa
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
107
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
anterior foi utilizada na construção do Novo Siafi, diminuindo o esforço do levantamento de requisitos e a construção do backlog do produto. O Quadro 1 sintetiza as informações acerca das contratações identificadas pela equipe de fiscalização.
Quadro 1: Resumo das contratações identificadas pela equipe de fiscalização
Órgão | Pregão | Tipo do objeto da contratação | Base do framework de gerência utilizado | Interessa ao levantamento |
TST | Pregão Eletrônico 146/2012 | Fábrica de software | Scrum | Sim |
Bacen | Pregão Eletrônico Demap 7/2012 | Fábrica de software | Scrum | Sim |
Iphan | Pregão Eletrônico 2/2011 | Projeto | Scrum | Sim |
TR em elaboração | Fábrica de software | Scrum | Sim | |
Inep | Pregão Eletrônico 1/2010 | Fábrica de software | Scrum | Sim |
Pregão Eletrônico 14/2012 | Fábrica de software | Scrum | Sim | |
STF | Pregão Eletrônico 84/2012 | Fábrica de software | Scrum | Sim |
Datasus | Não obtido | Fábrica de software – levantamento de requisitos | Metodologia tradicional | Não |
Não obtido | Fábrica de software – construção | Metodologia tradicional | Não | |
Pregão Eletrônico 19/2013 | Fábrica de software | Scrum | Não | |
EBSERH | Informação não obtida | Fábrica de software | Não obtido | Não |
Serpro | Dispensa de licitação | Projeto | Scrum | Não |
Fonte: Acórdão nº 2314/2013 TCU/Plenário (BRASIL, 2013b, p. 25), adaptado pelos autores
108 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Segundo o TCU, verificou-se, para as métricas de tamanho e esforço, que, à exceção do TST, todos os órgãos utilizaram pontos de função para dimensionar e pagar os serviços contratados.
Quando a equipe de fiscalização tratou de planejamento, gestão de demandas, aceitação do produto e forma de pagamento, percebeu-se que:
• Os órgãos possuem a maior parte desses instrumentos e a demanda para construção do produto é precedida pelo planejamento do produto, o qual pode ser feito apenas pela instituição contratante ou em conjunto, entre essa e a empresa contratada. Além do planejamento do produto, algumas instituições fazem o planejamento das funcionalidades que serão implementadas no próximo ciclo, iteração ou Sprint, atividade preceituada no Scrum.
• As instituições visitadas emitem uma ordem de serviço por ciclo, iteração ou
Sprint, ou por release de software, sendo mais comum o primeiro caso.
• Quanto à aceitação do produto entregue pela contratada, embora no framework Scrum seja preceituado que ocorra na reunião de revisão do Sprint, essa prática não é executada nos contratos estudados, até mesmo por impedimento normativo, conforme disciplinado no art. 73 da Lei nº 8.666/1993. Nessa ocasião, algumas instituições apenas verificam se os artefatos exigidos foram entregues, caracterizando o recebimento provisório.
• Quanto à forma de pagamento da contratada, constatou-se que algumas instituições remuneram os serviços de planejamento (quando realizados), enquanto outras remuneram apenas os serviços de construção do software.
• A entrega adiantada e contínua de software, conforme postulado nos princípios dos métodos ágeis, foi observada em algumas das instituições visitadas. Para alcançar esse objetivo, elas executaram em paralelo as atividades de preparação, execução e homologação, isto é: em um dado período de tempo, enquanto a empresa contratada executava a construção do software em um ciclo, iteração ou Sprint, a contratante preparava os itens do backlog do produto que seriam implementados no próximo ciclo e homologava o produto entregue no ciclo anterior (Brasil, 2013b, p. 26).
Além disso, encontra-se no Acórdão nº 2314/2013 TCU/Plenário (Brasil, 2013b,
p. 32): “constatou-se a preocupação de todas as instituições com relação à entrega de artefatos de documentação associados ao software produzido a cada iteração, facilitando, por exemplo, futuras manutenções por terceiros alheios ao processo de desenvolvimento”. Também foi constatado que “a relação contratual prevalece sobre a possível colaboração entre as partes, em harmonia com o princípio da vinculação ao instrumento convocatório, e as mudanças propostas mostraram-se restritas a novas iterações, mitigando o risco de desembolsos não programados” (Brasil, 2013b, p. 32).
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
109
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Quadro 2: Riscos apresentados pelo Acórdão nº 2314/2013 TCU/Plenário
Classificação dos riscos | Riscos | Explicação |
Riscos relativos a processos | Risco 1: contratação de desenvolvimento de software com adaptação de metodo- logia ágil que desvirtue sua essência. | Consiste em incorrer em adaptações de uma metodologia ágil já consolidada no mercado, com o intuito de moldá-la à realidade do órgão. |
Risco 2: alteração da metodologia ágil adotada no instrumento convocatório no decorrer da execução contratual. | Essa alteração pode ocorrer devido à pouca experiência da instituição pública contratante na utilização de métodos ágeis. | |
Risco 3: ausência de definição dos arte- fatos ou alteração dos artefatos exigidos da contratada no instrumento convoca- tório durante a execução contratual. | Pode decorrer da pouca experiência da instituição pública contratante na utilização de métodos ágeis. | |
Risco 4: exigência de artefatos desneces- sários ou que se tornam obsoletos rapi- damente. | A exigência de artefatos desnecessários pode ser oriunda da inexperiência da instituição contratante. | |
Risco 5: utilização de contrato para de- senvolvimento de software por metodo- logias tradicionais, para desenvolvimento por métodos ágeis. | Trata-se de alteração no objeto do serviço de desenvolvimento de software, haja vista que a utilização de métodos ágeis pode al- terar, em forma ou em essência, os produ- tos inicialmente descritos no contrato. | |
Riscos relativos a pessoas | Risco 6: falta de comprometimento ou colaboração insatisfatória do responsável indicado pela área de negócios (Product Owner) no desenvolvimento do software. | O uso de métodos ágeis exige grande comprometimento do responsável indi- cado pela área de negócios da institui- ção pública, conhecido como Product Owner no framework Scrum. |
Risco 7: falta do conhecimento neces- sário do indicado pela área de negócios (Product Owner) para o desenvolvimento do software. | O servidor indicado pela área de negó- cios, para ser responsável pela constru- ção do software e desempenhar o papel de Product Owner, pode não deter os conhecimentos necessários dos proces- sos de desenvolvimento do software. | |
Risco 8: excessiva dependência da visão do indicado pela área de negócios (Product Owner). | A falta de interação do Product Owner com os demais usuários do software em construção pode vir a criar excessiva de- pendência de sua visão na concepção do produto. | |
Risco 9: equipe da empresa contratada não ter expertise em desenvolvimento de software com métodos ágeis. | São os mecanismos para que a futura contratada comprove estar tecnicamen- te apta para a prestação dos serviços. | |
Risco 10: dificuldade de comunicação entre a equipe de desenvolvimento da contratada com o indicado pela área de negócios (Product Owner). | Tem como potenciais consequências a elaboração de produtos de baixa quali- dade, atrasos na entrega dos produtos e, em última análise, traduz-se no não aten- dimento da necessidade da contratação. |
110 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Classificação dos riscos | Riscos | Explicação |
Riscos relativos a produtos | Risco 11: alteração constante da lista de funcionalidades do produto. | A lista de funcionalidades do produto pode ser constantemente alterada para incluir, ainda no desenvolvimento, novas características inicialmente não planejadas, previstas ou vislumbradas. |
Risco 12: iniciação de novo ciclo sem que os produtos construídos na etapa anterior tenham sido validados. | O processo de construção do software por métodos ágeis comumente dá-se de forma contínua, ao longo de ciclos, iterações ou Sprints, nos quais um conjun- to de funcionalidades é implementado. | |
Risco 13: falta de planejamento adequado do software a ser construído. | A doutrina ágil pode levar instituições públicas, com equipes inexperientes ou sem nível de conhecimento técnico adequado, ao entendimento equivo- cado de seu uso, relegando a segundo plano o adequado planejamento do produto a ser construído. | |
Risco 14: pagamento pelas mesmas fun- cionalidades do software mais de uma vez, em virtude de funcionalidades impossíveis de serem implementadas em um único ciclo, ou em virtude da alteração de funcionalidades ao longo do desenvolvi- mento do software. | A construção do software utilizando métodos ágeis usualmente dá-se em ciclos, iterações ou Sprints, os quais possuem prazo fixo para seu término (time-box). | |
Risco 15: não disponibilização do software em ambiente de produção para a utiliza- ção e avaliação dos reais usuários. | Um dos objetivos dos métodos ágeis é a satisfação do cliente por meio da entrega adiantada e contínua de software funcional. | |
Risco 16: forma de pagamento não baseada em resultados. | A métrica popularmente adotada nas contratações para produção de softwa- re pelas instituições públicas é o ponto de função. A remuneração deve estar vinculada a resultados ou ao atendi- mento de níveis de serviço. |
Fonte: Acórdão 2314/2013 TCU/Plenário, adaptado pelos autores
Quanto à pessoalidade, foi observado um sólido aspecto das metodologias ágeis, que é o seu embasamento na maior valorização dos indivíduos e na interação entre eles, em detrimento de processos e ferramentas, e a necessidade de constância na composição da equipe de desenvolvimento do time Scrum. Observou-se, ainda, a existência de níveis de serviço vinculados à rotatividade da equipe de desenvolvimento da contratada em contratos de duas instituições.
Na parte dos riscos na contratação de desenvolvimento de software com métodos ágeis pelas instituições da APF, 16 riscos foram elencados, que, no caso deste artigo, fizeram parte do modelo da pesquisa.
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
111
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Para concluir, segundo o Acórdão nº 2314/2013 TCU/Plenário, as análises empreendidas no decorrer da execução da fiscalização demonstraram a viabilidade da adoção de métodos ágeis em contratações destinadas ao desenvolvimento de software pela APF. Argumentou-se que:
como em todo processo de contratação, há riscos que precisam ser considerados e mitigados. Contudo, no caso específico de adoção de métodos ágeis, tratados como novidade no mercado especializado nacional, sobretudo no âmbito da APF, a gestão de riscos inerentes às características do método merece atenção especial, no sentido de possibilitar que as instituições públicas possam fazer uso das práticas previstas, sem incorrer em descumprimento dos normativos vigentes. (ACÓRDÃO nº 2314/2013 TCU/PLENÁRIO, p. 39).
Para melhor compreender os riscos apresentados pelo Acórdão nº 2314/2013 TCU/ Plenário, diante de uma contratação de solução de TI envolvendo o desenvolvimento de software com a utilização de métodos ágeis, foi elaborado o Quadro 2, que busca explicar, de maneira sucinta, os pontos críticos apresentados para cada risco.
De acordo com o Acórdão nº 2314/2013 TCU/Plenário (Brasil, 2013b, p. 32), “não se trata de enumeração exaustiva de riscos, e sim de um subconjunto identificado com o conhecimento adquirido”. É importante observar que alguns dos riscos expostos não são inerentes somente ao uso de métodos ágeis, podendo ocorrer também com metodologias tradicionais de desenvolvimento de software. Sendo assim, para este estudo, o Acórdão nº 2314/2013 TCU/Xxxxxxxx colaborou na compreensão da importância de se analisar os riscos de contratação de desenvolvimento de software com métodos ágeis pelos órgãos da APF.
Metodologia
A análise bibliométrica, conforme Tague-Sutcliffe (1992, p. 1), pode ser definida como “[...] o estudo dos aspectos quantitativos da produção, disseminação e uso da informação registrada. Desenvolve padrões e modelos matemáticos para medir processos, usando seus resultados para elaborar previsões e apoiar tomada de decisões”.
Para a realização da análise bibliométrica, foram utilizadas técnicas para quantificar artigos, livros, bases de dados e outros meios de comunicação. Os termos da análise estão relacionados aos seguintes temas: métodos ágeis e desenvolvimento de software, fábrica de software e terceirização de TI. A pesquisa foi realizada durante os meses de outubro, novembro e dezembro de 2012, com a finalidade de quantificar as ocorrências dos termos definidos na pesquisa. Foram utilizadas as bases de publicações – artigos, dissertações e teses – da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (Capes), do Google Acadêmico e da Biblioteca Digital Brasileira de Teses e Dissertações (BDTD).
112 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Do ponto de vista dos procedimentos técnicos, a partir de Xxx (2010), essa pesquisa pode ser classificada como pesquisa bibliográfica, porque foi elaborada a partir de material já publicado, constituído principalmente do Acórdão nº 2314/2013 TCU/Plenário (Brasil, 2013b), da IN nº 04/2014 (Brasil, 2014), de livros e de artigos de periódicos. Também é classificada como pesquisa documental, pois, segundo Xxx (1991), essa técnica vale-se de materiais que não receberam ainda um tratamento analítico ou que ainda podem ser reelaborados de acordo com os objetos da pesquisa.
Conforme Xxxxx e Xxxxxxx (2005, p. 20), a forma de abordagem do problema pode ser classificada como qualitativa e quantitativa. Em se tratando da presente pesquisa, a abordagem é classificada como pesquisa qualitativa, por considerar que há uma relação dinâmica entre o mundo real e o sujeito, isto é, um vínculo indissociável entre o mundo objetivo e a subjetividade do sujeito, que não pode ser plenamente traduzido em números. A interpretação dos fenômenos e a atribuição de significados são básicas no processo desta pesquisa, em que o pesquisador tende a analisar seus dados indutivamente.
As entrevistas constituem outro método de obtenção de dados qualitativos (Malhotra, 2012, p. 121). Para este estudo, a entrevista foi um grupo de foco, que contribuiu no tratamento mais sistemático dos dados que se pretendia analisar. Para Malhotra (2012), um grupo de foco é uma entrevista realizada por um moderador, de forma não estruturada e natural, com um pequeno grupo de entrevistados, em que o objetivo principal é obter uma visão aprofundada do público-alvo, que detém propriedade ao falar sobre os problemas que interessam a uma determinada pesquisa.
Esta pesquisa também é definida como uma pesquisa quantitativa, por considerar que tudo pode ser razoavelmente quantificável, traduzindo em números as opiniões e informações, para classificá-las e analisá-las. Essa abordagem requer, também, o uso de recursos e de técnicas estatísticas. Neste estudo, foi aplicado um survey, cujo objetivo foi analisar a ordem de importância dos “riscos na contratação de desenvolvimento de software com métodos ágeis pelas instituições da administração pública federal”, descritos no Acórdão nº 2314/2013 TCU/Plenário.
Resultados obtidos
Para Xxxxxxx e Xxxxxxx (2011, p. 287), aos resultados somam-se inferências e interpretações, de modo que se pode: (i) evidenciar a observação e a valorização dos fenômenos; (ii) estabelecer suposições ou ideias, resultantes da observação e valorização realizadas; (iii) demonstrar e provar em que grau as suposições ou ideias têm fundamentos; (iv) fazer revisões às tais suposições ou ideias baseadas nas provas das análises; (v) sugerir novas observações e valorações para esclarecer, modificar, consolidar e/ou fundamentar as suposições e ideias, inclusive para generalizar outras.
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
113
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Para a realização do survey, o público-alvo foram profissionais vinculados à área de TI ou da área de contratação de solução de TI. Foi utilizada neste survey uma escala Likert, com valores de 1 a 5, com o objetivo de analisar a ordem de importância dos “riscos na contratação de desenvolvimento de software com métodos ágeis pelas instituições da administração pública federal”, descritos no Acórdão nº 2314/2013 TCU/Plenário.
Os cinco riscos considerados pelos respondentes como os mais importantes, em ordem decrescente de importância, foram (a numeração dos riscos é a do Quadro 2):
i) Risco 13: falta de planejamento adequado do software a ser construído.
ii) Risco 7: falta do conhecimento necessário do indicado pela área de negócios (Product Owner) para o desenvolvimento do software.
iii) Risco 6: falta de comprometimento ou colaboração insatisfatória do responsável indicado pela área de negócios (Product Owner) no desenvolvimento do software.
iv) Risco 10: dificuldade de comunicação entre a equipe de desenvolvimento da contratada e o indicado pela área de negócios (Product Owner).
v) Risco 16: forma de pagamento não baseada em resultados.
A Figura 1 apresenta os resultados do survey, onde no eixo X estão representados os dezesseis tipos de riscos, de R1 a R16, conforme Acórdão 2314/2013 plenário/TCU. Já no eixo Y, mostra-se a ordem de importância de cada um desses dezesseis riscos.
Fonte: Elaboração própria
Figura 1: Resultado do survey
Em seguida, no grupo de foco, foram discutidas ações de mitigação para os cinco riscos considerados de maior importância. O Quadro 3 apresenta as ações de mitigação sugeridas pelos especialistas no grupo de foco.
114 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Quadro 3: Ações de mitigação para contratação de desenvolvimento de software
com metodologia ágil Scrum
Classificação dos riscos | Riscos por ordem de importância | Ações de mitigação |
Riscos relativos a produtos | Risco 13: falta de planejamento adequado do software a ser construído. | • Definir previamente processos e critérios com a área de desenvolvimento. • Considerar a essência da metodologia ágil, que contempla a constante alteração na definição dos requisitos. |
Riscos relativos a pessoas | Risco 7: falta do conhecimento neces- sário do indicado pela área de negócios (Product Owner) para o desenvolvimen- to do software. | • Capacitar a área de TI e a área de negócio em metodologia ágil. • Incentivar a prática de equipes multifuncionais para que haja a troca de papéis, se necessário. • Contratar coaching para orientar os gestores de TI e de negócio na aplicação de metodologia ágil. |
Risco 6: falta de comprometimento ou colaboração insatisfatória do respon- sável indicado pela área de negócios (Product Owner) no desenvolvimento do software. | • Gerenciar o engajamento do Product Owner. • Monitorar, avaliar e melhorar continuamente o desempenho do Product Owner. | |
Risco 10: dificuldade de comunicação entre a equipe de desenvolvimento da contratada com o indicado pela área de negócios (Product Owner). | • Estabelecer um plano de comunicação, definindo os meios de comunicação e os papéis das partes interessadas. • Reservar antecipadamente a agenda dos participantes para todas as reuniões necessárias. | |
Riscos relativos a produtos | Risco 16: forma de pagamento não baseada em resultados. | • Utilização do Planning Poker2, viabilizando assim uma forma de medição. • O contratante deve controlar o que está sendo entregue como produto ou serviço em cada release. • Adaptação do ponto de função para a essência da metodologia ágil, estabelecendo formas de avaliar as entregas e formas de se efetuar o pagamento pelos serviços. |
Fonte: Acórdão 2314/2013 TCU/plenário, adaptado pelos autores.
2 Planning Poker é uma técnica baseada no consenso para estimar esforço ou tamanho relativo de estórias de usuários no desenvolvimento de software. Os membros do grupo fazem estimativas jogando cartas numeradas de face para baixo na mesa. Os cartões são revelados e as estimativas são, então, discutidas. Disponível em:
<xxxx://xxx.xxxxxxxxxxxxx.xxx/>.
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
115
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Essas ações de mitigação dos cinco riscos mais importantes serão, certamente, úteis para os profissionais da área de TI, tanto da contratante quanto da contratada, para que o processo de desenvolvimento com métodos ágeis tenha uma maior probabilidade de sucesso.
Conclusões
O principal objetivo deste artigo foi identificar ações de mitigação de riscos para a APF na contratação de soluções de desenvolvimento de software com a metodologia ágil Scrum. Para atingir o objetivo, primeiramente foi realizada uma pesquisa bibliométrica para identificar documentos que referenciassem a temática. No segundo momento, foi realizado um survey com o propósito de identificar os cinco riscos mais importantes, entre os 16 riscos apresentados pelo Acórdão nº 2314/2013 TCU/Plenário. Em seguida, foi realizado um grupo de foco, que discutiu e apresentou algumas ações para mitigação de riscos na contratação de soluções de desenvolvimento de software com a metodologia ágil Scrum.
O primeiro achado foi a identificação dos cinco riscos de maior importância para uma contratação de desenvolvimento de software com a metodologia Scrum, levando em consideração o Acórdão nº 2314/2013 TCU/Plenário. O segundo achado foi uma lista de possíveis ações de mitigação para os cinco riscos selecionados no survey, sendo que três desses riscos foram classificados como relativos a pessoas e os demais relativos a produtos. Cabe ainda ressaltar que, para este estudo, os riscos relativos a processos não foram apontados entre os cinco de maior importância, conforme o survey.
Para os achados referentes aos riscos relativos a pessoas, que abordaram a falta do conhecimento, a falta de comprometimento e a dificuldade de comunicação, percebeu-se que a gestão de partes interessadas mostra-se fundamental para o sucesso de um projeto com métodos ágeis. Nesse contexto, desenvolver e gerir as relações com as partes interessadas é essencial para a obtenção dos resultados em uma contratação de desenvolvimento de software com a metodologia Scrum, agregando valor à contratação.
Importante ressaltar que a IN nº 04/2014 (Brasil, 2014) não trata até o momento de como realizar uma contratação de desenvolvimento de software com a metodologia Scrum e nem aponta formas de mitigação de riscos na contratação. Também no guia do Scrum, não há orientações sobre ações para mitigação de riscos.
Conclui-se que, mesmo havendo poucos instrumentos legais específicos para apoio, é possível uma contratação de desenvolvimento de software com a metodologia Scrum, desde que sejam considerados aspectos como: a IN nº 04/2014 (Brasil, 2014), o Acórdão nº 2314/2013 TCU/Plenário, os demais instrumentos legais disponíveis e ainda as ações de mitigação apontadas neste estudo.
116 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
Nessa perspectiva de mitigação de riscos, observou-se que os órgãos da APF enfrentam vários desafios; dentre esses, destaca-se a gestão adequada das pessoas envolvidas no processo. Nesse enfoque, sugerem-se algumas ações como: realizar capacitação para a área de TI e também para a parte da área de negócio envolvida; contratar coaching para orientação dos gestores de TI e de negócio; incentivar a prática de equipes multifuncionais para que haja constante troca de informações entre as equipes; estabelecer um plano de comunicação, definindo os meios de comunicação e os papéis das partes interessadas; e gerir o conhecimento, de forma a identificar, agregar e valorizar o capital intelectual.
Consoante a isso, a APF publicou a Estratégia Geral de Tecnologia da Informação
– EGTI (2013-2015), em que se contemplam, entre seus objetivos, a gestão de pessoas e a promoção da gestão do conhecimento, de forma a incentivar a cultura do compartilhamento e a amplificação do acesso à informação na APF.
É interessante observar que os dois mais importantes frameworks de governança e de gestão de TI do mercado, o Cobit 5 e o PMBoK 5, abordam esses mesmos tópicos. O Cobit 5 tem processos para a gestão das partes interessadas, a gestão da comunicação e a gestão do conhecimento, ao passo que o PMBoK 5, que é o guia de boas práticas para o gerenciamento de projetos, traz uma área de conhecimento exclusiva para gerenciamento do engajamento das partes interessadas.
Como limitações deste estudo, cabe destacar que foram analisados somente cinco riscos, dos 16 elencados no Acórdão nº 2314/2013 TCU/Plenário; que a complexidade do Acórdão nº 2314/2013 TCU/Plenário restringiu a disponibilidade de especialistas com conhecimento do tema; que a pesquisa não levou em consideração a opinião de fornecedores que atuam em contratações de soluções de desenvolvimento de software com a metodologia ágil Scrum.
Sugere-se, como estudos futuros: a avaliação de ações de mitigação para os demais riscos que não foram contemplados neste estudo; a elaboração de um modelo de contratação de soluções de desenvolvimento de software com métodos ágeis na APF, que utilize como referência o Acórdão nº 2314/2013 TCU/Plenário; a ampliação do debate teórico sobre as abordagens de engajamento de partes interessadas, apresentadas no PMBoK 5 e no Cobit 5, acrescentando novas reflexões ao tema.
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
117
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Referências bibliográficas
Associação Brasileira de Normas Técnicas. NBR ISO/IEC 27005:2011 – Gestão de Riscos de Segurança da Informação. Rio de Janeiro: ABNT, 2011. 87p.
Agile Alliance. Manifesto for Agile Software Development. 2001. Disponível em:
<xxxx://xxx.xxxxxxxxxxxxxx.xxx/xxx/xxxx/>. Acesso em: 10 maio 2012.
Brasil. Decreto-Lei nº 200, de 25 de fevereiro de 1967. Dispõe sobre a organização da administração federal, estabelece diretrizes para a reforma administrativa e dá outras providências. Diário Oficial [da] República Federativa do Brasil, Poder Executivo, Brasília, DF, 27 fev. 1967, Seção 1. Disponível em: <xxxx://xxx.xxxxxxxx. xxx.xx/xxxxxx_00/Xxxxxxx-Xxx/Xxx0000.xxx>. Acesso em: 24 maio 2012.
. Lei nº 8.666, de 21 de junho de 1993. Regulamenta o art. 37, inciso XXI, da Constituição Federal, institui normas para licitações e contratos da administração pública e dá outras providências. Diário Oficial [da] República Federativa do Brasil, Poder Executivo, Brasilia, DF, 26 jun. 1993, Seção 1. Disponível em: <xxxx://xxx. xxxxxxxx.xxx.xx/xxxxxx_00/Xxxx/X0000xxxx.xxx>. Acesso em: 23 maio 2012.
. Constituição (1998). Xxxxxxxxxxxx xx Xxxxxxxxx Xxxxxxxxxx xx Xxxxxx. Xxxxxxxx, XX: Presidência da República, 1988. Disponível em: <xxxx://xxx.xxxxxxxx. xxx.xx/xxxxxx_00/xxxxxxxxxxxx/xxxxxxxxx%X0%X0xx.xxx>. Acesso em: 23 maio 2012.
. Departamento de Segurança da Informação e Comunicações. Norma Complementar 04/IN01/DSIC/GSI/PR. Brasília: Gabinete de Segurança Institucional, 2013a. Disponível em: <xxxx://xxxx.xxxxxxxx.xxx.xx/xxxxxxxxxx/xx_00_xxxxx.xxx >. Acesso em: 31 jul. 2014.
. Ministério do Planejamento, Orçamento e Gestão. Instrução Normativa 04/2008-SLTI/MP. Dispõe sobre o processo de contratação de serviços de tecnologia da informação pela administração pública federal direta, autárquica e fundacional. Diário Oficial [da] República Federativa do Brasil, Poder Executivo, Brasília, DF. 20 maio. 2008, Seção 1, p. 95. Disponível em: <xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx.xx/
x-xxx.xx/xxxxxxxxxx/xxxxxxxxx-xxxxxxxxx>. Acesso em: 22 abr. 2012.
. Ministério do planejamento, orçamento e gestão. Instrução normativa 04/2010 SLTI/MPOG. Dispõe sobre os procedimentos para a modificação da unidade de exercício dos servidores da carreira de especialista em políticas públicas e gestão governamental. Diário Oficial [da] República Federativa do Brasil, Poder Executivo, Brasília, DF. 18 de jan. 2010, seção 1, p. 134. Disponível em: <xxxx://xxx. xxxxxxxxxxxxxxxxx.xxx.xx/xxxx-xxxxxxxx/xxxxxx-xx-xxxxxxxxxxxx-xx-xx/xxxxxx-xx- contratacoes-normativos-e-documentos-de-referencia/instrucao-normativa-mp- slti-no04>. Acesso em: 22 abr. 2012.
. Ministério do planejamento, orçamento e gestão. Instrução normativa 04/2014-SLTI/MPOG. Altera a Instrução Normativa nº 4, de 11 de setembro de
118 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
Xxxx Xxxxx xx Xxxxx e Xxxx Xxxxx Xxxx
2014. Diário Oficial [da] República Federativa do Brasil, poder executivo, Brasília, DF. 12 de set. 2014, seção 1, p. 96-99. Disponível em: <xxxx://xxx.xxxxxxxxxxxxxxxxx. xxx.xx/xxxxxxxxxx/xxxxxxxx/xxxxxxxxx-xxxxxxxxx-xx0-0-xx-00-xx-xxxxxxx-xx-0000>. Acesso em: 28 fev. 2015.
. Ministério do planejamento, orçamento e gestão. Material do Curso Oficina IN 4/2014. Disponível em: <xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxx/ arquivos/material-do-curso-oficina-in-4-2014/view>. Acesso em: 28 fev. 2015.
. Tribunal de Contas da União. Guia de boas práticas em contratação de soluções de tecnologia da informação: riscos e controles para o planejamento da contratação/Tribunal de Contas da União. v 1.0, 527p., Brasília, 2012. Disponível em: <xxxx://xxxxxx0.xxx.xxx.xx/xxxxxx/xxxx/xxxxxx/XXX/xxxxxxxxxxx/xxxxxxxxxx_ informacao/contratacao_ti/Guia%20de%20contrata%C3%A7%C3%A3o%20de%20 solu%C3%A7%C3%B5es%20de%20TI.pdf>. Acesso em: 10 maio 2012.
. Tribunal de Contas da União. Acórdão nº 2314/2013 TCU/Plenário. Brasília: Tribunal de Contas da União, 2013b. Disponível em: <xxxx://xxxxxx.xxx.xxx. br/portaltextual/MostraDocumento?qn=1&doc=1&dpp=20&p=0>. Acesso em: 30 ago. 2013.
Dybå Tore; Díngsøyr X. Empirical studies of agile software development: A
systematic review. Information and Software Techology, v. 50, no 9, p. 833-859, 2008. Disponível em: <xxxx://xxxxxxx.xxx-xx.xxxx.xx/xxx/XxxxXxxXxxXxx/Xxxxxxxxx/ dyba.pdf>. Acesso em: 12 maio 2012.
Xxxxxxx, Xxxxx Xxxxxxx; Xxxxx, Xxxxxxxxx Xxxxxxxxx. Discussão sobre Motivação de equipes na implementação de métodos ágeis no desenvolvimento de sistemas na administração pública federal. Brasília: Universidade Católica de Brasília, Fundação Universa, 2009. Disponível em: <xxxx://xxxxxx0.xxx.xxx.xx/xxxxxx/xxx/ portal/docs/2053980.PDF>. Acesso em: 14 jun. 2012.
Garcıa, Xxxxxx Xxxxxxx; Xxxxxx, Xxxxxxx Xxxxxx de. Os princípios da administração pública no sistema jurídico brasileiro. Âmbito Jurídico, v. XV, no 96, jan 2012. Disponível em: <xxxx://xxx.xxxxxx-xxxxxxxx.xxx.xx/xxxx/xxxxx.xxx?x_xxxxxxxxxxxx_ artigos_leitura&artigo_id=11022>. Acesso em: 01 set. 2013.
Xxx, Xxxxxxx Xxxxxx. Métodos e técnicas de pesquisa social. 6. ed. São Paulo: Atlas, 2010.
Xxxx, Xxxxx J. R. Curso de Engenharia de Software. São Paulo: Digerati Books, 2008. 42 p.
Malhotra, Naresh K. Pesquisa de marketing: uma orientação aplicada. 6. ed. Porto Alegre, 2012.
Marconı, M. de A.; Xxxxxxx, x. M. Metodologia científica. 6. ed. São Paulo: Editora Atlas, 2011.
Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015
119
Contratação do desenvolvimento ágil de software na administração pública federal: riscos e ações mitigadoras
Xxxx, Xxxxxxx X.; Xxxxxxxx, Xxxxxx. R. M. Adoção de métodos ágeis em uma instituição pública de grande porte: um estudo de caso. Conference on Agile Methods. Agile
Brazil 2010. São Paulo, 2010. Disponível em: <xxxx://xxxx.xxx.xxx.xx/xxxxxxxx/xxxxx/ WBMA_Melo_e_Ferreira.pdf>. Acesso em: 25 maio 2012.
Mısra, Xxxxxx et al. Agile software development practices: evolution, principles, and criticisms. International Journal of Quality & Reliability Management Emerald Article,
v. 29, no 9, p. 972-980, set. 2011. Disponível em: < xxxx://xxx.xxxxxxxxxxxxxx.xxx/ journals.htm?articleid=17047676&show=abstract>. Acesso em: 14 nov. 2012.
Xxxx, X; Xxxxxxxxxxx, P. Agile methods in european embedded software development organizations: a survey on the actual use and usefulness of Extreme Programming and Scrum. IET Software, v. 50, no 4, p. 58–64, mar. 2008.
Xxxxxx, Xxxx Xxxxxxx xxx. Proposta de melhoria do processo de contratação de serviços de TI e da gestão dos contratos na administração pública federal. Revista Eixo, Brasília, DF, v. 2, no 1, p. 17-38, jan./jun. 2013. Disponível em: <xxxx://xxxxxxxxxxx.xxx.
xxx.xx/xxxxx.xxx/XxxxxxxXxxx/xxxxxxx/xxxx/000/00>. Acesso em: 13 ago. 2013. Xxxxxxxx, Xxx; Xxxxxxxxxx, Xxxx. The Scrum guide. New York: Xxxxx.xxx, 2011.
Xxxxx, Xxxx Xxxxx xx; Xxxxxxx, Xxxxxx Xxxxxxx. Metodologia da pesquisa e elaboração de dissertação. 4. ed. Florianópolis: UFSC, 2005.
Xxxxxxxxxxx, Xxx. Engenharia de software. 9. ed. São Paulo: Pearson Addison-Wesley, 2011.
Tague-Sutclıffe, Jean. An introduction to informetrics. Information. Processing and Management, v. 28, nº 1, p. 1-3, 1992.
Xxxx Xxxxx xx Xxxxx
Xxxx Xxxxx Xxxx
120 Revista do Serviço Público Brasília 66 (1) 97-120 jan/mar 2015