APPLICATION OF THE SCRUM AGILE FRAMEWORK TO THE MANAGEMENT PROCESS OF SOFTWARE DEVELOPMENT OUTSOURCING IN A BRAZILIAN GOVERNMENT AGENCY Luiz Pereira de Souza Sobrinho (Centro de Qualidade e Teste de Software/Universidade de Brasília/Faculdade Gama, Distrito Federal, Brasil) lpdess@gmail.com.br Rejane Maria da Costa Figueiredo (Centro de Qualidade e Teste de Software/Universidade de Brasília/Faculdade Gama, Distrito Federal, Brasil) RejaneCosta@unb.br Elaine Venson (Centro de Qualidade e Teste de Software/Universidade de Brasília/Faculdade Gama, Distrito Federal, Brasil) ElaineVenson@unb.br Luiz Carlos Miyadaira Ribeiro Jr (Centro de Qualidade e Teste de Software/Universidade de Brasília/Faculdade Gama, Distrito Federal, Brasil) LCarlos@unb.br Colaboradores: Thatiany Lima de Souza (Centro de Qualidade e Teste de Software/Universidade de Brasília/Faculdade Gama, Distrito Federal, Brasil) Thaty_Sousa13@hotmail.com Ricardo Ajax Dias Kosloski (Centro de Qualidade e Teste de Software/Universidade de Brasília/Faculdade Gama, Distrito Federal, Brasil) RicardoAjax@unb.br The Federal Government is one of the main contractors of information technology services. In this scenario, some organizations are adopting agile methodologies expecting better results. The objective of this study was to identify and adapt Framework Scrum practices in order to support the establishment of a management process of software development projects. A case study was applied in a Federal Government agency contracting the software factory service. As a result, a process based on Scrum was proposed including adjustments based on successful cases reported in the literature, among which are the establishment of three levels of control and adjustments in artifacts, roles and Scrum events. As future work, we suggest guidance with criteria for the definitions of Ready and Done and the evaluation of this proposal through a pilot project. Keywords: Scrum, Public Administration, Procurement, Software Development, Adaptation. 4943
A APLICAÇÃO DO FRAMEWORK ÁGIL SCRUM EM UM PROCESSO DE GESTÃO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE POR TERCEIROS EM UM ÓRGÃO PÚBLICO FEDERAL BRASILEIRO A Administração Pública Federal é uma das principais contratantes de serviços de Tecnologia da Informação. Algumas organizações estão adotando metodologias ágeis para obter melhores resultados. O objetivo deste trabalho foi identificar e adequar as práticas do Framework Scrum com o intuito de apoiar a definição de um processo de gestão de demandas de desenvolvimento de software. Foi utilizada a técnica de estudo de caso, o objeto foi um órgão do Governo Federal que contrata o serviço de fábrica de software. Como resultado foi proposto um processo baseado no Scrum, com algumas adaptações baseadas em casos bem sucedidos reportados na literatura, tais como o estabelecimento de três níveis de controle e as adaptações nos artefatos, papéis e eventos do Scrum. Como trabalhos futuros, o desenvolvimento de um guia com critérios de definição dos conceitos de Ready e Done e a sua validação em um projeto piloto. Palavras-Chave: Scrum, Administração Pública, Contratação, Desenvolvimento de Software, Adaptação. Agradecimentos: Esta pesquisa foi realizada no Centro de Qualidade e Teste de Software CQTS da FGA/UnB e financiada parcialmente pelo projeto de P&D com o Ministério das Comunicações. 1. INTRODUÇÃO A Administração Pública Federal (APF) é uma das principais contratantes de serviços de TI. Em 2012 foram movimentados cerca de R$ 430,8 milhões em contratações desse tipo por meio de processos licitatórios (BRASIL, 2012), o que leva as organizações públicas que recorrem à contração de bens e serviços de TI a atuarem como responsáveis pela gestão desses contratos (BRASIL, 2010). Cruz et al. (2011) ressaltam que as contratações de serviços de Tecnologia da Informação (TI) devem estar alinhadas à legislação relacionada a essa atividade (Lei n o 8.666, 1993; Lei n o 10.520, 2002; BRASIL, 2010). Porém, historicamente, o setor público brasileiro desenvolveu uma estrutura rígida e burocrática de gestão e acompanhamento (Biazzi, Muscat, & Biazzi, 2009). A insatisfação das organizações públicas brasileiras com o modelo corrente utilizado para a gestão e/ou desenvolvimento de software tem motivado a mudança com a adoção de metodologias ágeis (BRASIL, 2013). Alguns estudos empíricos (Downey & Sutherland, 2013; Mundra, Misra, & Dhawale, 2013; Williams, Brown, Meltzer, & Nagappan, 2011) indicam que o uso de metodologias ágeis tem proporcionado melhoria na qualidade do produto de software, aumento da taxa de entrega e maior satisfação dos clientes. 4944
Instituições do governo americano, britânico e brasileiro publicaram relatórios sobre o uso de metodologias ágeis no governo que sugerem ou avaliam a sua aplicação juntamente com as adaptações aplicadas ao contexto (BRASIL, 2013; Estados Unidos da América [EUA] & Government Accoutability Office [GAO], 2012; INGLATERRA & National Audit Office [NAO], 2012). Segundo Dingsøyr, Dybå & Abrahamsson (2008), as metodologias ágeis mais pesquisadas são o Scrum e o Extreme Programming (XP). Segundo Dybå & Dingsøyr (2008) o Scrum é um método ágil popular na indústria, e segundo Melo et al.(2013), no Brasil tem sido um dos frameworks mais utilizados para a gestão de projetos. Ele é definido como um Framework com variadas estratégias de uso, sendo adaptativo e composto por papéis, artefatos e eventos (Schwaber & Sutherland, 2013). Várias estratégias de uso do Scrum são encontradas na literatura (Aker et al., 2013; Hong, Yoo, & Cha, 2010; Honious & Clark, 2006; Rautiainen, [s.d.]; Rautiainen, Lassenius, & Sulonen, 2002; Vanhanen, Itkonen, & Sulonen, 2003; Vlaanderen, Jansen, Brinkkemper, & Jaspers, 2011; Zieris & Salinger, 2013). Hong et al. (2010) adicionaram o evento Master Sprint Planning. Zieris & Salinger (2013) utilizaram dois Scrum Master, um no cliente e outro no fornecedor. Honious & Clark (2006) fizeram uso da estratégia learn by doing como forma de diminuir o tempo de treinamento. E Vlaanderen et al. (2011) propuseram um processo ágil de gerenciamento de produtos de software que prevê a preparação do Backlog do produto até metade da sprint de desenvolvimento. Maurer & Melnik (2007) destacam que um desafio no contexto de contratação é a adequação da metodologia ágil ao ambiente contratual. Já Boehm & Turner (2003) destacam que nesse cenário é necessário realizar o balanceamento entre agilidade e disciplina, através de adaptações. Batra (2009) apresenta uma pesquisa na qual ressalta a necessidade de adaptação das metodologias ágeis em contextos rígidos e de contratação. Dado o cenário do crescente uso do Framework Scrum e da demanda pelas organizações públicas, a questão de pesquisa definida neste trabalho foi: Como empregar o Framework Scrum na definição de um processo de gestão de projetos de desenvolvimento ágil de software em um órgão do governo federal brasileiro que terceiriza o desenvolvimento? Este trabalho teve como objetivo identificar e adequar as práticas associadas ao Framework Scrum com o intuito de apoiar a definição de um processo para gestão de demandas de desenvolvimento ágil de software. Para alcançar o propósito estabelecido, conduziu-se uma pesquisa aplicada, qualitativa e descritiva apoiada pelos procedimentos bibliográficos, documental e o emprego de estudo de caso (caso único). A partir da unidade de análise selecionada, que foi um Órgão do Governo Federal que contrata o serviço de Fábrica de Software e estuda a adoção de metodologia ágil para realizar a gestão dos projetos que são encaminhadas à contratada, utilizaram-se os procedimentos de análise documental para caracterização. Como elicitação, foram realizadas visitas ao órgão e entrevistas não estruturadas com servidores para identificar quais os principais problemas enfrentados até então. 4945
Em paralelo à fase de caracterização do órgão, foi executada uma revisão bibliográfica em livros associados ao Framework Scrum e nas bases acadêmicas, como IEEExplorer, Science Direct, Springer e ACM, buscando artigos científicos que envolviam práticas associadas ao framework Scrum relacionadas a contextos similares do objeto de estudo. Dadas as características do objeto de estudo e as práticas identificadas realizou-se a análise qualitativa para a definição de quais das propostas identificadas se aplicariam ao estudo de caso. Considera-se como contribuição deste trabalho a possibilidade de utilização dos resultados relatados por outras organizações públicas, servindo como base e orientação para futuras análises e intervenções que busquem aplicar tal framework. O artigo está organizado em seções. Nas Seções 2 a 4 apresentam-se o referencial teórico sobre contratações de serviços de TI, a adoção de metodologias ágeis pelo governo e o Framework Scrum, respectivamente. Na Seção 5 descrevem-se a metodologia de trabalho e a caracterização do órgão. Na Seção 6 descreve-se o estudo de caso realizado: inicialmente, apresenta-se o processo proposto, seguido das principais adaptações propostas. Por fim, na Seção 7, apresentam-se as conclusões e trabalhos futuros. 2. CONTRATAÇÕES DE SERVIÇOS DE TECNOLOGIA DA INFORMAÇÃO A legislação brasileira (Decreto-Lei N o 200, 1967) estabelece que a administração pública deve recorrer sempre que possível à execução indireta dos serviços que apoiem à sua área fim, mediante contrato. A Lei nº 8.666/93 (1993) estabelece o processo licitatório para realizar contratações na Administração Pública. Esse processo é composto por: edital; habilitação; julgamento e classificação; homologação e adjudicação e permite a escolha do fornecedor que apresente a proposta mais vantajosa (menor custo e maior qualidade) para o governo (BRASIL, 2010). A licitação possui quatro tipos de modalidades, sendo o Pregão a modalidade obrigatória para a contratação de bens e serviços comuns (Lei n o 10.520, 2002), como é o caso dos serviços de TI. Dada a necessidade de alinhamento à legislação, as contratações de serviços de TI requerem atenção das instâncias de controle (Cruz et al., 2011). O Tribunal de Contas da União (TCU), em seu trabalho fiscalizador, identificou irregularidades em algumas contratações de TI e, diante disso, recomendou a elaboração de um modelo de licitações e contratações de TI com processos mais maduros (Cruz et al., 2011). Em razão dessa recomendação, em 2008, a SLTI (Secretaria de Logística e Tecnologia da Informação) publicou a Instrução Normativa MP/SLTI nº04 (IN04/2010) que dispõe sobre o processo de Contratação de Soluções de TI pelos órgãos integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação (SISP). A norma foi atualizada em 2010 (BRASIL, 2010) e nela são definidas três fases para a realização das contratações: Planejamento da Contratação, Seleção do Fornecedor e Gerenciamento do Contrato. Também em 2008, Cruz definiu um Quadro-Referencial Normativo para contratações de TI na APF. Para cada fase e atividade, do ciclo básico de contratações, Cruz (2008) associou a legislação pertinente. 4946
Para apoiar as organizações durante o processo de contratação, em 2011, a SLTI lançou o Guia Prático para Contratação de Soluções de TI (BRASIL, 2011), nomeado de Modelo de Contratação de Soluções de TI (MCTI), no qual são detalhados os processos, atividades, artefatos e atores de cada fase descrita na IN04/2010. Cruz et al. (Cruz et al., 2011) divulgaram o Processo de Contratação de Serviços de TI (PCSTI). Já o TCU, em 2012, publicou o Guia de Boas Práticas em Contratação de Soluções de TI (BRASIL, 2012) para apoiar os gestores de contratos no planejamento das contratações. No guia são apresentados sessenta e seis riscos relacionados ao Planejamento da Contratação e para cada risco, são identificadas as possíveis ações de controle interno. Segundo a IN04/2010, cada contratação de TI do órgão deve ocorrer em função do planejamento conjunto das contratações de soluções de TI e do orçamento de TI da organização (PDTI). Para isso, inicialmente é feito o planejamento da contratação. Em seguida, ocorre a fase de seleção do fornecedor. Finalizando, ocorre a fase de gestão de contrato. Em paralelo a essas fases, ocorrem os processos de governança de TI, mediante os quais a alta administração definiu diretrizes e na execução, acompanha o alinhamento e implementação dessas (BRASIL, 2012). O gerenciamento do contrato fica a cargo da organização, dado que o gerenciamento dos processos de TI não pode ser objeto de contratação (BRASIL, 2010). Nessa fase, a organização é responsável por monitorar a execução do contrato a fim de garantir a adequada prestação dos serviços e/ou o fornecimento dos bens contratados (BRASIL, 2010). 3. ADOÇÃO DE METODOLOGIAS ÁGEIS PELO GOVERNO O aumento da popularidade dos métodos ágeis tem motivado a realização de pesquisas sobre a adoção e adaptação de metodologias ágeis (Dingsøyr, Nerur, Balijepally, & Moe, 2012). Essas metodologias têm sido introduzidas no governo por suas promessas de entrega mais rápida, com maior valor para o cliente e melhor qualidade (Jamieson, Vinsen, & Callender, 2005). Como consequência, instituições do governo americano, britânico e brasileiro publicaram relatórios que avaliam e incentivam o uso de metodologias ágeis no governo, resguardadas as adaptações necessárias (BRASIL, 2013; EUA & GAO, 2012; INGLATERRA & NAO, 2012). Em adição, Hajjdiab, Taleb & Ali (2012) e Aker et al. (2013) publicaram trabalhos relatando iniciativas de adoção de ágeis no governo dos Emirados Árabes e na Organização do Trabalho do Atlântico Norte (OTAN/NATO), respectivamente. Como resultado, Hajjdiab, Taleb & Ali (2012) apresentaram oito possíveis motivos causadores de falhas na adoção de ágeis e Aker et al. (2013) reportaram dezesseis lições aprendidas sobre a aplicação de princípios ágeis na terceirização do desenvolvimento de software. Na Tabela 1: Práticas recomendadas em casos governamentais, as práticas recomendadas pelos autores dos casos relatados são apresentadas e categorizadas em: 4947
adoção de ágeis; capacitação das pessoas; planejamento; requisitos; e monitoramento e controle. Tabela 1: Práticas recomendadas em casos governamentais Monitoramento e Acompanhamento Planejamento Capacitação Adoção de ágeis 1. Definir estratégia de adoção ágil (EUA, & GAO, 2012) adaptando-a se necessário, porém sem comprometer a eficiência e eficácia (Hajjdiab et al., 2012); 2. Planejar um projeto piloto de tamanho médio, não crítico. Ter o apoio de um coach experiente em desenvolvimento ágil. E diminuir aceitação de novos projetos por seis meses, para trabalhar na mudança de comportamento (Hajjdiab et al., 2012); 3. Ter gerentes de nível médio para orientar a equipe de desenvolvimento assim como gerentes de garantia da qualidade experientes com autoridade e participante da equipe (Aker et al., 2013) e; 4. Ter áreas de trabalho colaborativas (INGLATERRA & NAO, 2012). 1. Melhorar a migração do processo então vigente para os conceitos ágeis usando termos e exemplos ágeis (EUA, & GAO, 2012); 2. Capacitar equipes pequenas, multifuncionais (EUA, & GAO, 2012); 3. Prever a evolução do time e não esperar a perfeição na primeira iteração (Hajjdiab et al., 2012); 4. Contratar alguns profissionais experientes em ágeis e ministrar constantemente cursos ágeis (Hajjdiab et al., 2012); 1. Planejar a participação do usuário e prever a necessidade de participação de especialistas no negócio (Aker et al., 2013); 2. Definir uma estratégia para gerenciar os requisitos e design (Aker et al., 2013); 1. Procurar identificar e resolver os impedimentos nos níveis da organização e do projeto (EUA, & GAO, 2012); 2. Ganhar a confiança, demonstrando valor, no final de cada iteração (EUA, & GAO, 2012); 3. Realizar Reuniões Diárias, Acompanhar o progresso utilizando métricas e Manter métricas e quadro de atividades visíveis (EUA, & GAO, 2012; INGLATERRA & NAO, 2012); 4. Ao equilibrar as filosofias ágeis e cascata, os gerentes de projeto devem especificar quais detalhes serão definidos na fase de desenvolvimento ágil e o que precisa ser acordado na revisão crítica do design (Aker et al., 2013); 5. É necessário rastrear com acurácia a porcentagem de completude do design e do desenvolvimento com o objetivo de orientar a decisão de Trade-off entre o escopo e qualidade quando o cronograma é fixo (Aker et al., 2013). 4948
Tabela 2: Práticas recomendadas em casos governamentais (cont.) Requisitos 1. Obter feedback dos interessados/cliente com frequência e de perto (EUA, & GAO, 2012); 2. Incluir requisitos relacionados com a segurança e monitoramento do progresso na sua fila de trabalhos não concluídos (EUA, & GAO, 2012); 3. Diminuir a quantidade de documentação não necessária, com a aprovação da alta gerência (Hajjdiab et al., 2012); 4. Conflito entre requisitos ágeis e especificação tradicional deve ser gerenciado pelos gerentes de projeto (Aker et al., 2013); 5. Ao desenvolver com metodologia ágil em um ambiente de contratação "cascata" utilizar as fases planejadas para estudar os requisitos em profundidade, capacidade por capacidade, a cada iteração (Aker et al., 2013); 6. Com o detalhamento dos requisitos por fase, o nível de detalhe na transferência de conhecimento deve ser gerenciado (Aker et al., 2013); 7. A priorização do escopo do projeto deve ser desenvolvida inicialmente e acompanhada com rigorosos padrões de qualidade para aceitação (Aker et al., 2013); 8. Realizar desenvolvimento centrado na interface do usuário garante que usuários operacionais estejam envolvidos na implementação do sistema (Aker et al., 2013); 9. Ambos, contratada e contratante, devem garantir que os resultados dos workshops de apresentação de interface do usuário são consistentes com os requisitos contratuais e padrão visual da empresa (Aker et al., 2013). Percebe-se que a adoção de metodologias ágeis embora recomendada deve ser cuidadosamente planejada e acompanhada de boas práticas adicionais para que se obtenha sucesso e os resultados mencionados. 4. FRAMEWORK SCRUM O Scrum foi criado na década de 90 (Sutherland, Jakobsen, & Johnson, 2008). Schwaber & Sutherland (2013) o definem como um Framework com variadas estratégias de uso, em que vários processos ou técnicas podem ser empregados. Ele é um framework adaptativo, composto por papéis, artefatos e eventos, que propõe o uso de iterações curtas (Sprints) para a construção do produto de software (Schwaber & Sutherland, 2013). São três os artefatos principais: Backlog do Produto, no qual estão, os requisitos de forma priorizada e expressos em histórias de usuário; Backlog da Sprint, composto pelas 4949
tarefas relacionadas as histórias selecionadas para serem desenvolvidas na Sprint; e Incremento de Software, parte do software funcional e integrada, entregue ao final de cada Sprint. O Time Scrum é composto por três papéis fundamentais: Product Owner (PO), responsável por especificar os requisitos (histórias de usuário), tomar decisões sobre o projeto e garantir o entendimento do Backlog do Produto; Scrum Master, responsável por garantir a compreensão e uso correto do Scrum; e Time de Desenvolvimento, composto por profissionais responsáveis por produzirem o Incremento de Software. Por fim, os eventos do framework são time-boxed, ou seja, possuem tempo definido para a sua execução, e dividem-se em: Planejamento da Sprint (4 a 8 horas), Sprint (1 a 4 semanas); Reunião Diária (15 minutos), Revisão da Sprint (4 horas) e Retrospectiva da Sprint (3 horas) (Schwaber & Sutherland, 2013). O fluxo de trabalho do Scrum é apresentado na Figura 1: Fluxo de trabalho do. Figura 1: Fluxo de trabalho do Scrum (Leffingwell, 2011, adaptado) No início de cada Sprint, o Time Scrum realiza a Reunião de Planejamento da Sprint com o objetivo de definir a meta, o escopo e as tarefas da Sprint com prazo e responsáveis. Depois, inicia-se um novo ciclo de desenvolvimento (Release), composto por uma ou mais Sprints. A cada Sprint, o Time de Desenvolvimento desenvolve um Incremento de Software e realiza, juntamente com o Scrum Master, Reuniões Diárias com o objetivo de acompanhar o progresso do trabalho e resolver possíveis impedimentos. E o PO, acompanha a execução e esclarece eventuais dúvidas ao longo de toda a Sprint (Schwaber & Sutherland, 2013). Ao final de cada Sprint, o Time Scrum e os Stakeholders, convidados pelo PO, realizam a reunião de Revisão da Sprint para a apresentação do Incremento de Software produzido. A revisão do Backlog do Produto deixa claro o que ficou pronto, ou não. Posteriormente, o Time Scrum realiza a Retrospectiva da Sprint com o objetivo de identificar oportunidades de melhoria para o próximo ciclo de desenvolvimento. No Scrum, durante os eventos, são utilizados dois conceitos, Ready (Preparado) e Done (Pronto). O primeiro estabelece o sinal verde para os requisitos do Backlog do 4950
Produto entrarem para a Sprint. E o segundo apresenta critérios para a aceitação dos itens de backlog selecionados para a Sprint (Schwaber & Sutherland, 2013). No Guia Scrum também são apresentados meios de acompanhamento do projeto, como, por exemplo, o Gráfico Burndown (Schwaber & Sutherland, 2013). A ausência de recomendações mais precisas condiz com o princípio de foco maior nas pessoas e as ideias de autogerenciamento e auto-organização do Time Scrum, como definido no Manifesto Ágil (Beck et al., 2001). Devido à variedade de estratégias de uso do Scrum, na subseção seguinte são apresentadas algumas alternativas encontradas na literatura. 4.1. ESTRATÉGIAS DE USO DO SCRUM Sutherland (2005) apresenta três esquemas de sobreposição das fases de desenvolvimento. No primeiro, há um intervalo de tempo entre as Sprints. No segundo, ao longo da Sprint, o Backlog da próxima é construído. No terceiro, o planejamento é revisto constantemente e todas as atividades são sobrepostas. Ainda Sutherland (2005) indica que estes níveis estão associados a experiência dos times com o Scrum. Inicialmente dissociado do Scrum Cooper (1990) propôs o modelo Stage-Gate (estágios de controle) baseado em decisões (Gates). Nele, a diretoria da organização aprova a continuação do projeto ou a repetição da fase ou o cancelamento do projeto. Cohn (2010)ao avaliar este modelo afirma que sua aplicação junto a metodologias ágeis visa alinhar o projeto aos objetivos da organização. Similar a proposta de Cooper (1990) o PRINCE 2 (Projects In Controlled Enviroments) é outro modelo de gestão de projetos estruturado com três níveis de controle: Conselho do Projeto, Gerente do Projeto e Gerente do Time, desenvolvido pelo governo britânico (Turley, 2010). Já Sutherland, Harrison, e Riddle (2014) apresentam nove padrões associados ao uso do Scrum que foram definidos empiricamente. Davis (2013) propõe a definição de Done incremental nos níveis de História, Sprint e Release. Já Jakobsen & Sutherland (2009) relatam o uso de Releases mensais de duas Sprints. E Leffinggwell (2007, 2011) define o Scaled Agile Framework (SAFe), um framework ágil como o Scrum, mas adaptado para aplicação em organizações, com três níveis de planejamento (portfólio, programa e time) e para cada nível, define papéis, artefatos e eventos. Ozawa & Zhang (2013) definem o papel do PO Proxy, responsável por auxiliar a comunicação e resolver questões culturais entre o PO do Japão e o Time de Desenvolvimento da China. Na próxima Seção apresenta-se a metodologia utilizada para realizar a adaptação do Framework Scrum para uma Organização Pública Federal Brasileira. 5. METODOLOGIA Buscando responder a questão de pesquisa, este estudo foi classificado, segundo a abordagem de Gil (2008), como de natureza aplicada e abordagem qualitativa, em que a análise dos dados foi realizada indutivamente pelos pesquisadores. 4951
Quanto ao tipo foi classificada como descritiva, pois descreve uma proposta de aplicação do Framework Scrum a partir da revisão bibliográfica e da legislação brasileira. Quanto aos procedimentos técnicos, foram utilizados o bibliográfico e o documental, seguido do emprego de estudo de caso. O estudo de caso deste trabalho enquadra-se em um estudo de caso único, dado que o objetivo foi propor a aplicação do Scrum para um órgão público federal brasileiro. Quanto aos procedimentos de coletas de dados, neste estudo foram empregadas entrevistas não estruturadas, análise documental e revisão bibliográfica. Para a realização da pesquisa foram definidas três fases: Planejamento, Coleta de Dados e Análise dos Dados. Na fase de Planejamento da pesquisa, definiu-se a questão de pesquisa, a seleção metodológica e o estudo de caso. Para o estudo de caso, a unidade de análise selecionada foi a Coordenação-Geral de Tecnologia da Informação (CGTI) de um Órgão do Governo Federal que recorre à contratação de fábrica de software. Durante a fase de Coleta de Dados, a revisão bibliográfica foi realizada em bases de dados eletrônicas com o objetivo de caracterizar as adaptações do Scrum existentes; a análise documental teve o objetivo de caracterizar as contratações de serviços de TI para organizações públicas e a unidade de análise; e a caracterização do objeto de estudo foi apoiada pela realização de entrevistas não estruturadas com servidores do órgão. Finalizando, com a Análise dos Dados coletados foi definida uma proposta de aplicação do Framework Scrum para a unidade de análise selecionada e de acordo com as propostas coletadas na literatura com contexto similar. 5.1. CARACTERIZAÇÃO DA UNIDADE DE ANÁLISE A unidade de análise selecionada apresenta baixo quantitativo de servidores de TI (18%), reconhecidamente baixo pela própria organização, que possui planos para aumentar o seu quantitativo de servidores. A maioria da força de trabalho é composta por funcionários terceirizados (98%) (BRASIL, 2014). O que se justifica, pois a organização recorre à contratação de alguns serviços de TI, ficando a cargo apenas da gestão dos contratos. Este órgão possui Plano Diretor de Tecnologia da Informação (PDTI), como sugere a Instrução Normativa nº04 (BRASIL, 2010). Em avaliação interna o mesmo reconhece a necessidade de mais servidores e apresenta planejamento para aquisição destes nos anos seguintes (BRASIL, 2014). Atualmente, a TI gerencia cerca de três contratos relacionados a: Fábrica de Software, responsável pelo desenvolvimento e manutenção de software e localizada em outra região, com exceção da equipe de manutenção; Qualidade, responsável por verificar a qualidade dos produtos entregues pela fábrica e realizar a contagem de pontos de função; e Infraestrutura de TI, responsável pelo ambiente de infraestrutura da organização. O processo atual utilizado pelo órgão é baseado no OpenUP com pagamentos percentis para cada fase, sendo a Análise de Pontos de Função a métrica de tamanho funcional utilizada (BRASIL, 2011a, 2011b). 4952
A partir das entrevistas, pôde-se identificar a organização das equipes de desenvolvimento que estão alocadas em um outro estado tendo no órgão apenas analistas de requisitos e um líder de projetos, que por vezes é o mesmo analista como apresentado a Figura 2- Organização atual das equipes de desenvolvimento. Figura 2- Organização atual das equipes de desenvolvimento (Fonte: Autor) No que concerne as práticas de gestão, o órgão também emprega a Metodologia de Gestão de Projetos de TI (MGPTI), baseada no PRINCE 2 e no PMBoK (BRASIL, 2012). A metodologia MGPTI estabelece um ciclo de gerenciamento de projetos de TI dividido em fases (Figura 3: Fluxo da MGPTI (BRASIL, 2012)), no qual, no final de cada fase são realizadas reuniões de decisões que autorizam a continuidade ou não do projeto para a próxima fase e a aprovação ou não da fase atual. 4953
Figura 3: Fluxo da MGPTI (BRASIL, 2012) As decisões da MGPTI são Decisão de Alinhamento e Viabilidade (DAV), Decisão de Abertura do Projeto (DAP), Decisão de Desenvolvimento da Solução (DDS), Decisão de Validação (DV), Decisão de Disponibilização (DD), Decisão de Encerramento do Projeto (DEP) e Decisão de Operação Continuada (DOC), sendo a primeira e a última opcionais segundo norma operacional do órgão (BRASIL, 2012) Apesar dessas iniciativas, a organização vem enfrentando algumas dificuldades. Durante a realização das entrevistas foram relatados problemas como: qualidade sendo aferida em documentos e não no código, baixa qualidade do software entregue, atrasos nas entregas e falta de sincronia entre os resultados da fábrica de software e da empresa de qualidade. Devido à insatisfação com o modelo corrente utilizado na gestão dos contratos, o órgão objetiva adotar metodologias ágeis para realizar a gestão dos projetos de desenvolvimento de software. Em decorrência disso e com o apoio da revisão bibliográfica e análise documental, sugeriu-se o uso do Scrum com adaptações que foram apresentadas nas seções anteriores deste trabalho. 6. PROPOSTA DE APLICAÇÃO DO FRAMEWORK SCRUM Para atender a necessidade da organização, definiu-se o Processo de Gestão de Demandas de Desenvolvimento Ágil de Software (ProGeDDAS). Esse processo foi desenhado com base no Framework Scrum e nas características da organização. Dessa forma, o ProGeDDAS está alinhado aos preceitos legais, à MGPTI e ao Scrum e suas adaptações, observadas na literatura. Sua aplicação deve seguir as recomendações para a adoção de ágeis definidas na Tabela 1. Considerando que o exposto no ProGeDDAS, pode ser novamente adaptado como recomenda Hajjdiab et al. (2012) e deve ser acompanhado de uma estratégia para a adoção do ágil que descreva como as práticas serão adotadas, qual o período considerado para adaptação, quem serão os envolvidos na organização e quais tecnologias serão utilizadas para apoiar o processo de adoção, conforme observado em EUA, & GAO (2012). 4954
No Estudo de Caso não foi possível adotar, a curto prazo, o item 3, que trata de possuir gestores ágeis e de qualidade, haja vista a limitação de servidores do próprio órgão, apresentada anteriormente. Conforme apresentado na Figura 2- Organização atual das equipes de desenvolvimento (Fonte: Autor), o ambiente colaborativo, recomendado no item 4 da referida tabela, não seria possível, a não ser que fosse digital, sendo neste caso consideradas as suas limitações. De forma similar aos itens de adoção os de capacitação são anteriores, estruturantes ou de apoio ao processo de desenvolvimento, não sendo inseridos na proposta, sendo que dos quatro descritos o primeiro é atendido pela descrição do processo com o uso de termos próprios que indica a mudança de metodologia. No entanto, os itens 2 e 4 são recomendações a fábrica contratada, e entende-se fora do domínio da contratante. E o item 3 que recomenda o gerenciamento de expectativas com relação a produtividade do time de desenvolvimento que depende de ações da estratégia de adoção recomendada anteriormente e que não está no escopo deste trabalho que se limita a definição do processo para gestão de projetos desenvolvidos de forma terceirizada. 6.1. O PROCESSO DE GESTÃO DE DEMANDAS DE DESENVOLVIMENTO ÁGIL DE SOFTWARE (PROGEDDAS) O propósito do ProGeDDAS é orientar a organização no relacionamento com a contratada, servindo como referência na atividade de gestão dos projetos de desenvolvimento de software. Na Figura 4: Macroprocesso do ProGeDDAS apresenta-se o Macroprocesso do ProGeDDAS modelado na notação BPMN (Bussiness Process Model and Notation) e alinhado à MGPTI. 4955
Figura 4: Macroprocesso do ProGeDDAS As cores dos subprocessos representam as fases do processo e os pontos de decisão representam as decisões da MGPTI, similar ao modelo Stage-Gate definido por Cooper (1990) em concordância com o PRINCE2 (Turley, 2010). As reuniões de decisão da MGPTI são representadas por Gates em que apenas um caminho pode ser tomado (OBJECT MANAGMENT GROUP, 2001). A reunião de acompanhamento do projeto reúne a DDS, DV e DD, permitindo a sobreposição das fases de desenvolvimento das Releases como aconselha Sutherland (2005). Esse paralelismo é permitido através do gate Estratégia de Desenvolvimento, o qual permite que um ou mais caminhos sejam tomados simultaneamente (OBJECT MANAGMENT GROUP, 2001). Em relação ao alinhamento à MGPTI, o subprocesso Pré-Projeto representa a fase de Pré-Projeto. Os subprocessos Revisão do Planejamento e Planejamento da Release representam a fase de Planejamento. O subprocesso Execução representa a fase de Desenvolvimento da Solução. Já as fases de Validação e Disponibilização são representadas pelos subprocessos Homologação e Implantação, respectivamente. O Framework Scrum está representado nos subprocessos Planejamento da Release e Execução. Nesses subprocessos os papéis, artefatos e eventos do Scrum são distribuídos. As atividades do ProGeDDAS são time-box. Na Tabela 3: Atividades e Time-Box dos 4956
subprocessos são apresentadas todas as atividades do processo agrupadas por subprocessos. É apresentado, também, o time-box de cada subprocesso, representado pela soma do time-box de cada atividade. Tabela 3: Atividades e Time-Box dos subprocessos Subprocesso Atividades Time-Box Definir Visão da Solução Estabelecer Protocolo de Pesquisa para Alternativas de Solução Propor Software de Mercado Pré-Projeto Propor Software Livre 15,5 horas ~ 2 Estimar o Desenvolvimento dias Definir Quantidade de Releases Consolidar Análise da Solução Verificar Qualidade da Análise da Solução Resolver Não Conformidades Planejamento do Projeto Planejamento da Release Execução Homologação Implantação Revisar Visão da Solução Workshop da Solução Planejar Release e Priorizar Sprint Escrever Histórias de Usuário da Primeira Sprint Verificar Qualidade Resolver Não Conformidades Preparar para DDS Planejar Sprint Colaborar com o Time de Desenvolvimento Escrever Histórias de Usuário da Próxima Sprint Resolver Impedimentos e Monitorar Status Executar Sprint Receber Provisoriamente o Incremento de Software Verificar Qualidade do Incremento de Software Realizar Reunião de Revisão da Sprint Resolver Não Conformidades Verificar Resolução de Não Conformidades Transferir para o Ambiente de Homologação Evoluir Backlog do Produto Homologar Release Definir/Revisar Estratégias de Implantação Corrigir Defeitos Implantar em ambiente de produção Treinar Usuário Divulgar Solução 10 horas ~ 1dia e ¼ 6,5 horas + Quantidade de horas definidas pelo PO para a atividade de Escrever histórias 2 semanas a 4 meses Depende do planejamento Depende do planejamento Assim como o tamanho máximo recomendado para a Sprint por Schwaber & Sutherland (2013) é de quatro semanas, o tamanho máximo proposto para as Releases é de quatro Sprints. Dessa forma o time-box de uma release varia entre uma semana a quatro meses. 4957
Segundo os relatos de funcionários do órgão a média de tempo atual dos projetos da organização é de oito meses Com a aplicação da metodologia um projeto com essa duração no pior caso terá duas releases de quatro Sprints com um mês de duração cada. O Scrum é adaptativo às mudanças. O ProGeDDAS permite adaptações, aceitação de mudança, em relação ao Backlog do Produto, desde que não fira os princípios da APF (Lei n o 8.666, 1993) nem altere a Meta do Produto estabelecida. Em relação ao processo, é necessário levar em consideração que a legislação veta a alteração do objeto contratual, dos critérios de qualidade e dos componentes do Incremento de Software (BRASIL, 2013), devendo assim haver um processo específico, definido em contrato para a evolução dos critérios de qualidade associados as questões contratuais (glosa e multa). No caso do Backlog da Sprint sua alteração não é permitida, ocorrendo apenas o esclarecimento de detalhes deste recorte do escopo. Qualquer novo requisito deve ser inserido no Backlog do Produto, devendo a Sprint ser cancelada caso seja essencial a mudança de seu escopo. Dessa forma, se o escopo da Sprint precisar mudar, esta deve ser cancelada e outra Sprint, com outro escopo deve ser planejada. 6.2. AS ADAPTAÇÕES SUGERIDAS PARA O FRAMEWORK SCRUM Para atender as características da organização foi necessário realizar algumas adaptações nos papéis, artefatos e eventos do Scrum. Além disso, foi proposto o uso de dois níveis de controle de qualidade. A proposta se resume na Figura 5 Aplicação do Scrum para um Órgão Público Federal brasileiro - é explicada ao longo desta seção. Estabelecimento de Níveis de Controle de Qualidade A inspeção no ProGeDDAS ocorre em dois níveis, processo e produto. No primeiro, o controle é realizado através de atividades, presentes em cada subprocesso, voltadas para avaliação da qualidade. Como resultado, o responsável emite parecer através do relatório de qualidade. Esse parecer irá determinar ou não a convocação da reunião prevista pela MGPTI. No segundo nível, adaptou-se a proposta de Davis (2013) através do estabelecimento de três níveis de conceito de Ready e Done. Os níveis são de Produto, Release e Sprint (Leffingwell, 2011; Turley, 2010). Esse estabelecimento permite o controle e o acompanhamento da qualidade como recomenda a legislação (Lei n o 8.666, 1993). 4958
Figura 5 Aplicação do Scrum para um Órgão Público Federal brasileiro 4959
Adaptações nos Artefatos Os artefatos previstos pelo Scrum continuam presentes no ProGeDDAS. São adicionados: a Estratégia de Desenvolvimento, o Roadmap e a Agenda do PO. Alinhando à MGPTI, acrescenta-se ainda: o Documento de Visão da Solução, o Documento de Arquitetura, as Lições Aprendidas e as Apresentações da MGPTI. E por fim, visando o controle de três níveis, têm-se os Relatórios de Qualidade de cada fase. Devido à restrição de pessoal e tempo da organização, o PO é responsável por estabelecer os dias e os horários, através da Agenda do PO, que ele terá disponível para colaborar com o Time de Desenvolvimento, garantindo que ao menos uma vez por semana esteja disponível para o time de desenvolvimento, atendendo de forma parcial e adequada a realidade do órgão o recomendado por EUA, & GAO (2012), no item 1 da linha de requisitos da Tabela 1. Os únicos artefatos que terão a aprovação da alta gerência são os próprios da MGPTI que são uma apresentação em slides com as decisões a serem tomadas nesta reunião, a lista dos produtos produzidos naquela fase, o que atende a recomendação de requisitos número 3 da Tabela 1. Adaptações nos Papéis Os papéis do ProGeDDAS foram definidos de acordo com as recomendações e adaptações encontradas na bibliografia, além de levar em conta os papéis estabelecidos pela IN04/2010 e a estrutura interna do órgão. Os papéis do ProGeDDAS incluem os papéis previstos no Scrum e os apresentados na Tabela 4. Tabela 4: Papéis auxiliares no ProGeDDAS Papel Equipe de Qualidade Escritório de projetos Infraestrutura de TI Product Owner Partner TI da Contratante Usuários-chave Exercido por Contratada Contratante Contratada Não pode ser da Contratada Contratante Contratante O Time Scrum no ProGeDDAS segue a recomendação do Framework Scrum (Schwaber & Sutherland, 2013). O PO é um usuário-chave da área de negócio com poder sobre o projeto e a interface oficial entre o negócio e o Time de Desenvolvimento e o responsável por indicar os Usuários-Chave da área de negócio. O Time de Desenvolvimento é exercido por funcionários da contratada localizada em outro estado. Na proposta de aplicação do Scrum, a comunicação entre o PO e o Time ocorrerá através de e- 4960
mails, telefone e/ou videoconferências. Já o Scrum Master é exercido pelo funcionário da contratada alocado no órgão, podendo ou não haver outro Scrum Master da contratada junto ao time de desenvolvimento em outro estado, similar ao proposto por Zieris & Salinger (2013). A principal adaptação nos papéis é a inclusão do Comitê Gestor do Projeto e do Product Owner Partner. Segundo a MGPTI (BRASIL, 2012), o Comitê Gestor do Projeto é o responsável por realizar as decisões do projeto no nível organizacional, decidindo sobre a continuidade do projeto, liberação de recursos e resolução de impedimentos organizacionais. Ele não é apresentado na Tabela 4 por participar apenas dos pontos de decisões e ser composto pelos papéis já definidos e outros servidores com nível hierárquico mais forte. O Product Owner Partner (POP) tem a função de auxiliar tecnicamente o PO durante a execução do processo, especificamente nas escritas das histórias, priorização do Backlog do Produto e uso do Scrum, realizando as atividades que seriam do Scrum Master com relação ao PO, sem lhe retirar a responsabilidade. É um papel de caráter temporário, proposto a partir dos relatos de imaturidade dos usuários-chave com desenvolvimento de software. O POP serve como guardião do processo, mantendo o comprometimento do PO e ajudando-o a defender seus interesses nas discussões técnicas que venham a ocorrer, comuns nesse tipo de processo, onde tudo acontece de uma vez. O POP assemelha-se ao PO Proxy apresentado por Ozawa & Zhang (2013), considerando que não existem barreiras culturais a serem superadas e sim de conhecimento técnico sobre o processo de desenvolvimento, e a infraestrutura de TI do órgão. Adaptações nos Eventos Por meio da análise da Tabela 3: Atividades e Time-Box dos subprocessos é possível observar que dois eventos do Scrum foram adaptados no ProGeDDAS, que são: Reunião Diária e a Retrospectiva da Sprint. A Reunião Diária foi substituída pela atividade Reportar Impedimentos e Status da Sprint garantindo assim o atendimento ao item 1 de monitoramento e acompanhamento da Tabela 1 recomendado por EUA, & GAO (2012). No ProGeDDAS o reporte de impedimentos e status é realizado pelo Scrum Master da contratada ao Escritório de Projetos do órgão, sendo executado por servidores com poder gerencial. Considerando a melhoria no relacionamento entre o PO e o Time de desenvolvimento, foi proposto, também, a integração das atividades Retrospectiva da Sprint e Reunião de Revisão da Sprint. Dessa forma, intenta-se realizar a sobreposição das fases do Scrum que Sutherland et al. (2014) propõem. Outra adaptação foi a criação da atividade Colaborar com o Time de Desenvolvimento, na qual o PO fica disponível, conforme definido na Agenda do PO, para possíveis esclarecimentos. Essa atividade foi criada devido à restrição de tempo do PO, a distância geográfica entre ele o Time de Desenvolvimento e em atendimento as recomendações de (Aker et al., 2013) na seção de planejamento da Tabela 1 sendo que o 4961
segundo item (definir uma estratégia para gerenciar os requisitos e design) é de responsabilidade conjunta do Scrum Master e do PO. 7. CONCLUSÕES E TRABALHOS FUTUROS Neste artigo foi apresentada uma proposta de uso do Framework Scrum para um estudo de caso de um Órgão do Governo Federal Brasileiro. Que retrata uma forma de se aplicar o Framework Scrum em um órgão público federal brasileiro desde que consideradas as práticas recomendadas em casos governamentais apresentadas na Tabela 1: Práticas recomendadas em casos governamentais Uma das contribuições deste trabalho é a possível utilização dos resultados obtidos por outras organizações públicas, servindo como base e orientação para futuras análises e intervenções ou o uso direto das adaptações relacionadas a casos bem sucedidos aqui apresentadas. Para alcançar o objetivo estabelecido, foi necessário realizar algumas adaptações no uso do Framework, corroborando com a afirmação de Batra (2009). Além disso, foi necessário realizar uma revisão bibliográfica sobre as possíveis adaptações e estratégias de uso do Scrum. A unidade de análise do estudo de caso caracterizava-se como um órgão que recorre à contratação de serviços de TI, com baixo quantitativo de pessoal e necessidade de alinhamento à sua metodologia de gerenciamento de projetos chamada MGPTI. A não necessidade de adaptação dos artefatos da MGPTI demostra a busca pela simplicidade da alta gerência e um espírito condizente com os princípios ágeis na medida do possível para o contexto público. Entretanto, o alinhamento com a MGPTI foi fator determinante para a realização das adaptações, contribuindo, em certos momentos, para a distanciação do que é estabelecido no Scrum. Uma dificuldade encontrada durante a definição do processo foi a representação do paralelismo entre os subprocessos. O controle da qualidade será realizado continuamente no processo, ao longo de todas as fases. Isso será permitido devido aos níveis de controle estabelecidos. Acredita-se que isso permitirá que os padrões de qualidade possam evoluir de acordo com a maturidade do órgão e do contrato. Já a agenda do PO é classificada como um artefato importante, pois facilita a interação entre o PO e o Time de desenvolvimento, estabelecendo claramente quando o PO estará disponível. Conclui-se que as adaptações variam de acordo com cada contexto organizacional e a proposta de aplicação terá maior êxito se utilizada em conjunto com os princípios apresentados no Manifesto Ágil. Para realizar a adoção de ágeis as organizações devem estar abertas e comprometidas com as mudanças. E para que o desenvolvimento ágil possa ocorrer, a organização precisa tornar-se ágil internamente para que seja capaz de receber os produtos de forma mais rápida e possa resolver os impedimentos que surjam. Como trabalhos futuros, sugere-se a criação de um guia com critérios para as definições de Done e Ready para os três níveis de serviço definidos e a avaliação das adaptações sugeridas através da execução de um projeto piloto. A criação das definições pode ser apoiada pela análise dessas definições em outros órgãos públicos, identificando as 4962
similaridades existentes entre elas e propondo um padrão dessas definições em forma de checklists. Esse padrão poderia ser compartilhado no setor público através do SISP. REFERÊNCIAS Aker, S., Audin, C., Lindy, E., Marcelli, L., Massart, J.-P., & Okur, Y. (2013). Lessons learned and challenges of developing the NATO air command and control information services. In Systems Conference (SysCon), 2013 IEEE International (p. 791 800). doi:10.1109/syscon.2013.6549974 Batra, D. (2009). Modified Agile Practices for Outsourced Software Projects. Commun. ACM, 52(9), 143 148. doi:10.1145/1562164.1562200 Beck, K., Beedle, M., Cockburn, A., Bennekum, A. van, Cunningham, W., Fowler, M., Thomas, D. (2001). Manifesto para Desenvolvimento Ágil de Software. Recuperado de http://agilemanifesto.org/iso/ptbr/ Boehm, B., & Turner, R. (2003). Observations on balancing discipline and agility (p. 32 39). IEEE. doi:10.1109/adc.2003.1231450 Decreto-Lei N o 200, de 25 de Fevereiro de 1967. Dispõe sôbre a organização da Administração Federal, estabelece diretrizes para a Reforma Administrativa e dá outras providências. Recuperado de http://www.planalto.gov.br/ccivil_03/decreto-lei/del0200.htm Lei n o 8.666, de 21 de junho de 1993. Regula 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. Recuperado de http://www.planalto.gov.br/ccivil_03/leis/l8666cons.htm Lei n o 10.520, de 17 de junho de 2002. Institui, no âmbito da União, Estados, Distrito Federal e Municípios, nos termos do art. 37, inciso XXI, da Constituição Federal, modalidade de licitação denominada pregão, para aquisição de bens e serviços comuns, e dá outras providências. Recuperado de http://www.planalto.gov.br/ccivil_03/leis/2002/l10520.htm BRASIL, & Ministério das Comunicações [MC]. (2011a, junho 12). Anexo II - Modelo de Desenvolvimento de Software - Edital de Pregão Eletrônico N. o 038/2011 MC. BRASIL, & Ministério das Comunicações [MC]. (2011b, junho 12). Anexo I - Termo de Referência - Edital de Pregão Eletrônico N. o 038/2011 MC. BRASIL, & Ministério das Comunicações [MC]. (2012). Norma Operacional SPOA No 006, de 10 de Setembro de 2012. Dispõe sobre a Metodologia de Gerenciamento de Projetos de Tecnologia da Informação - MGP-TI, utilizada no âmbito do Ministério das Comunicações. 4963
BRASIL, & Ministério das Comunicações [MC]. (2014). Plano Estratégico de Tecnologia da Informação (PETI) e Plano Diretor de Tecnologia da Informação (PDTI) 2013-2015. Recuperado de http://www.mc.gov.br/index.php BRASIL, & Secretaria de Logística de Tecnologia da Informação [SLTI]. (2012). Informações Gerenciais de Contratações Públicas de Bens e Serviços de Tecnologia da Informação. Recuperado de http://www.comprasnet.gov.br/ajuda/manuais/04-01_a_12_informativo%20comprasnet_comprasti.pdf BRASIL, & Secretaria de Logística e Tecnologia da Informação [SLTI]. (2010). Instrução Normativa N o 04, de 12 de novembro de 2010. Dispõe sobre o processo de contratação de Soluções de Tecnologia da Informação pelos órgãos integrantes do Sistema de Administração dos Recursos de Informação e Informática (SISP) do Poder Executivo Federal. Recuperado de http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no- 04-de-12-de-novembro-de-2010/download BRASIL, & Secretaria de Logística e Tecnologia da Informação [SLTI]. (2011). Guia Prático para Contratação de Soluções de Tecnologia da Informação. Recuperado de http://www.governoeletronico.gov.br/biblioteca/arquivos/guia-pratico-paracontratacao-de-solucoes-de-ti-mcti BRASIL [TCU]. (2010). ncia do TCU. BRASIL, & Tribunal de Contas da União [TCU]. (2012). Guia de Boas Práticas em Contratação de Soluções de Tecnologia da Informação. Recuperado de http://www.governoeletronico.gov.br/biblioteca/arquivos/guia-de-boas-praticasem-contratacao-de-solucoes-de-tecnologia-da-informacao-tcu BRASIL, & Tribunal de Contas da União [TCU]. (2013). Acórdão N o 2314/2013. Levantamento de Auditoria. Conhecimento Acerca da Utilização de Metodologias Ágeis nas Contratações de Software Pela Administração Pública Federal. Recuperado de https://contas.tcu.gov.br Cohn, M. (2010). Succeeding with agile: software development using Scrum. Upper Saddle River, NJ: Addison-Wesley. Cooper, R. G. (1990). Stage-gate systems: a new tool for managing new products. Business horizons, 33(3), 44 54. Cruz, C. S. da. (2008). Governança de TI e conformidade legal no setor público : um quadro referencial normativo para a contratação de serviços de TI (Dissertação de Mestrado). Universidade Católica de Brasília, Brasília. Recuperado de http://portal2.tcu.gov.br/portal/pls/portal/docs/2054320.pdf Cruz, C. S. da, Andrade, E. L. P. de, & Figueiredo, R. M. da C. (2011). Processo de Contratação de Serviços de Tecnologia da Informação para Organizações Públicas. Brasília. 4964