Extreme Programming (XP e XP2)

No XP, Dyba e Dingsøyr (2008, p. 835) argumentam que essa metodologia concentra- se em melhores práticas para o desenvolvimento de software, dentre essas:

o jogo de planejamento; lançamentos de pequeno porte; metáfora; design simples; testes; refatoração; programação em pares; propriedade coletiva;

integração contínua, de 40 h por semana, no local; clientes e padrões de codificação.

Já a prática XP2, foca nas seguintes práticas primárias: a equipe deve-se sentar-se junta, espaço de trabalho informativo, o trabalho energizado, programação em pares, histórias,

ciclo semanal, ciclo trimestral, folga de 10 minutos de criação, integração contínua, teste de primeira programação e design incremental.

2.1.1.6 Scrum

Para Deemer et al. (2010) os métodos ágeis surgiram a partir de uma abordagem mais fundamentada na realidade humana, onde o desenvolvimento de produtos de aprendizagem, inovação e mudança renderia melhores resultados. O desenvolvimento ágil se concentra em equipes multifuncionais com poderes para tomadas de decisões. Centra-se em iteração rápida, e com atendimento contínuo ao cliente. Segundo os autores, a metodologia mais popular é o Scrum, pois foi fortemente influenciado pelo artigo The New New Product Development Game (1986). Nesse documento o termo “Rugby4” foi introduzido, e que mais tarde se transformou em “Scrum”. Segundo Deemer et al. (2010), Scrum é hoje utilizado por grandes e pequenas empresas, incluindo: Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne e a US Federal Reserve. De acordo com os autores, Scrum é um framework iterativo e incremental para projetos e produtos ou desenvolvimento de aplicação. A Figura 1 detalha a visão geral do Scrum, segundo Deemer et al. (2010):

4 _{Trata-se de um esporte coletivo, onde há um tipo de formação para disputa pela bola. Em caso de penalidades} ou faltas, todos os jogadores se reúnem para reiniciar o jogo. Fonte: <http://www.portaldorugby.com.br/entenda- o-rugby/historia-do-rugby>. Acesso em: 15 maio 2012.

Figura 1 - Visão geral do Scrum

Fonte: Deemer et al. (2010).

Em seguida, esse assunto foi formalizado por Ken Schwaber e Jeff Sutherland.

Segundo Schwaber e Sutherland (2011), o Scrum é 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 onde é difícil planejar com antecedência e se utiliza de mecanismos de controle de processos empíricos, onde 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.

2.1.1.6.1 Teoria do Scrum

De acordo com Schwaber e Sutherland (2011, p. 4), o Scrum é fundamentado nas teorias empíricas de controle de processo. Eles afirmam que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. Declaram, também, que o Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. Esse método se apoia em três pilares para a implementação de controle de processo, sendo eles: transparência, inspeção e adaptação.

Transparência determina que os processos devem estar visíveis aos responsáveis pelos resultados, requerendo aspectos definidos por um padrão comum para que os envolvidos compartilhem um mesmo entendimento do que está sendo visto. Na inspeção, os usuários devem, frequentemente, inspecionar os artefatos do Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações. Nas adaptações, caso necessitem de ajustes, estes devem ser realizados o mais breve possível para minimizar mais desvios e para que o resultado do produto seja aceitável.

Schwaber e Sutherland (2011, p. 4) descrevem 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 sprints utilizam o mesmo modelo de Scrum e todas as sprints têm como resultado um incremento do produto final que é potencialmente “entregável”. Cada sprint começa imediatamente após a anterior (Ibid., p. 8).

2.1.1.6.2 Time Scrum

De acordo com Schwaber e Sutherland (2011, p. 5), o time Scrum é composto por: (1) product owner; (2) equipe de desenvolvimento e (3) 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.

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 “pronto5_{”, ao final} de cada sprint. A equipe não contém sub-equipes dedicadas a domínios específicos de conhecimento, tais como de testes ou de análise de negócios. Esta 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.

2.1.1.6.3 Eventos Scrum

Conforme descrevem Schwaber e Sutherland (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. O Quadro 4 descreve os principais eventos do Scrum.

Quadro 4 - Principais eventos do Scrum

Eventos Descrição

Sprint

É o coração do Scrum, ou seja, um time-box de um mês ou menos, durante o qual um “pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprints têm durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia-se imediatamente após a conclusão da sprint anterior. As sprints são compostas por uma reunião de planejamento da sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da sprint e a restrospectiva da sprint.

Eventos Descrição

Durante a sprint, não são feitas mudanças que podem afetar o objetivo da sprint. Cada sprint pode ser considerada um projeto com intervalo não maior que um mês. Cada sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

Reunião de planejamento da sprint

É um time-box de oito horas para uma sprint de um mês de duração. Para sprints menores, este evento deve ser proporcionalmente menor. Nessa reunião preveem- se as funcionalidades que serão desenvolvidas durante a sprint e a equipe de desenvolvimento decide como irá construir essas funcionalidades durante a sprint e transformá-las em um incremento de produto “pronto”.

Reunião diária

É um evento time-boxed de 15 minutos, para que a equipe de desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Essa reunião é feita para inspecionar o trabalho desde a última reunião diária, e prever o trabalho que deverá ser feito antes da próxima reunião diária. A reunião diária é mantida no mesmo horário e local todo dia para reduzir a complexidade. Reuniões diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento da equipe de desenvolvimento.

Revisão da sprint

É executada no final da sprint para inspecionar o incremento e adaptar o backlog do produto, se necessário. Durante a reunião de revisão da sprint, o time Scrum e as partes interessadas colaboram sobre o que foi feito na sprint. Com base nisso, e em qualquer mudança no backlog do produto durante a sprint, os participantes colaboram nas próximas atividades que precisam ficar prontas. Esta é uma reunião informal; a apresentação do incremento destina-se a motivar, obter comentários e promover a colaboração.

Retrospectiva da sprint

É uma oportunidade para o time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima sprint. Ocorre depois da revisão da sprint e antes da reunião de planejamento da próxima sprint. É uma reunião time- boxed de três horas para uma sprint de um mês. Proporcionalmente um tempo menor é alocado para sprints menores.

Fonte: A autora, a partir de Schwaber e Sutherland (2011).

2.1.1.6.4 Artefatos do Scrum

Schwaber e Sutherland (2011, p. 12), descrevem que os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave necessárias para assegurar que o time Scrum tenha sucesso na entrega do incremento “pronto”. Argumentam ainda que os artefatos estão divididos em backlog do produto e backlog da sprint.

O backlog do produto é uma lista ordenada de tudo que deve ser necessário no produto e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O product owner é responsável pelo backlog do produto, incluindo seu conteúdo, disponibilidade e ordenação. Contém, ainda, a lista de todas as características, funções, requisitos, melhorias e correções, que formam as mudanças a serem feitas no produto nas futuras versões. Os itens do backlog do produto possuem os atributos da descrição, ordem e estimativa.

Já o backlog da sprint é um conjunto de itens do backlog do produto selecionados para a sprint, juntamente com o plano de entrega do incremento do produto que deve atingir o objetivo da sprint. É a previsão da equipe de desenvolvimento sobre qual funcionalidade estará no próximo incremento, e do trabalho necessário para entregar a funcionalidade. Também define qual trabalho a equipe de desenvolvimento realizará para converter os itens do backlog do produto em um incremento “pronto”. Além disso, torna visível todo o trabalho que a equipe de desenvolvimento identifica como necessário para atingir o objetivo da sprint, sendo um plano com detalhes suficientes para que as mudanças em progresso sejam entendidas durante a reunião diária.

Na adoção da metodologia Scrum, em consonância ao que diz a IN 04/2010, será necessário a aplicação principalmente do artigo 2º, parágrafo XXII, que trata do PDTI como “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”, servindo de referência aos itens a serem priorizados do backlog da sprint.

2.2 IN 04/2010

A IN 04/2010 (BRASIL, 2010) 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. Anteriormente, no ano de 2008, foi criada a sua versão primeira, porém tratava somente sobre o processo de contratação de serviços de TI pela APF, seja direta, autárquica ou fundacional.

Nesse enfoque:

apesar de recente, a IN - SLTI 4/2010 não altera leis ou regulamentos sobre licitações, mas as complementa e fornece uma estrutura de processo, conceitos e artefatos que orientam as compras de soluções de TI, com bastante ênfase no planejamento. Logo, a falta de conformidade com a mesma poderia indicar uma falha grave no cumprimento de leis, assim como deficiências na governança e planejamento de TI. (SANTOS; NETO, 2013, p. 102).

Para expressar em maiores detalhes a disposição da IN 04/2010, foram criados mapas mentais6 _{com a descrição de suas especificidades e com o apoio de cores e marcadores, que} são características presentes em mapas mentais. Nos mapas citados para esta IN 04/2010, especificamente, as cores estão distribuídas da seguinte maneira: cinza para identificar o

6

Os mapas mentais foram desenvolvidos pelo inglês Tony Buzan, que realizou um estudo sobre o cérebro humano. Imaginou criar uma visão, uma forma gráfica de trabalho, onde se consegue permitir a criatividade. O mapa mental se abre em todas as direções, formando uma ferramenta visual e estruturada.

título, no caso a IN 04/2010; a cor laranja para representar os incisos; a cor vermelha para destaque ao parágrafo único, a cor azul apresentando os artigos; e, por fim, a cor verde, para apresentar as seções.

No seu artigo 1º, parágrafo único observa-se que a IN 04/2010 não se aplica a todos os órgãos da APF, conforme destacado nos incisos I e II, apresentado na Figura 2.

Figura 2 - Contratações de soluções de TI

Fonte: IN 04/2010 (BRASIL, 2010), adaptado pela autora.

Também no Capítulo I, Apêndice A, em seu artigo 2º, descreve a definição dos diversos termos que são utilizados para significar as denominações das diversas áreas. Ainda nesse artigo, em seu inciso XXII, observa-se a necessidade do 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 04/2010, em seu artigo 4º, parágrafo único, descreve que:

inexistindo o planejamento estratégico formalmente documentado, será utilizado o documento existente no órgão ou entidade, a exemplo do Plano Plurianual ou instrumento equivalente, registrando no PDTI a ausência do planejamento estratégico do órgão ou entidade e indicando os documentos utilizados. (IN 04/2010, p. 3).

No entanto, faz-se necessário um planejamento para que a APF cumpra a obrigação para realização de contratação de solução de TI. Por isso, ainda no artigo 4º, Apêndice B, o órgão integrante deve considerar que as contratações de que trata a IN 04/2010 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, apresentado na Figura 3, 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.

Figura 3 - Processo de contratação

Fonte: IN 04/2010 (BRASIL, 2010), adaptado pela autora.

O órgão tem como prerrogativa, diante de uma contratação, a necessidade de redução de custos, no sentido de utilizar recursos de forma a estabilizar situações instáveis, observando ainda o que diz o decreto Lei 200/67 (BRASIL, 1967), em seu artigo 6º, destacando o planejamento, a descentralização e o controle. 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.

A seção I, Apêndice C, descreve as necessidades relacionadas com o planejamento da contratação. O planejamento da contratação, de acordo com o artigo 3º da Lei 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º, apresentado na Figura 4, todos os incisos devem ser observados, com ênfase no inciso I, que trata da análise de viabilidade da contratação, onde é notório que conhecendo melhor a demanda, será possível decidir sobre a viabilidade ou não da contratação de software. Então, faz-se necessário levantar os requisitos para manter, evoluir e suportar um determinado software.

Figura 4 - Fase de planejamento da contratação

Fonte: IN 04/2010 (BRASIL, 2010), adaptado pela autora.

Na seção I acrescenta ainda a necessidade de analisar as características do software a ser desenvolvido/manutenido, avaliando sua viabilidade, de modo a embasar a decisão por sua continuidade e pela melhor estratégia de desenvolvimento. No inciso II, alínea b, apresentado no Apêndice D, 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.

No Apêndice E, 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.

Ainda na seção I, conforme o Apêndice F, que contempla o artigo 13, no inciso VI a contratada deve atentar para a experiência profissional da equipe que projetará, implementará e implantará a solução de TI, referindo-se à natureza da experiência profissional exigida e às respectivas formas de comprovação dessa experiência.

Para o artigo 15, apresentado no Apêndice G, vale ressaltar que será necessário investir em soluções de software que possam garantir a viabilidade, a sustentação e o aperfeiçoamento das atividades dos órgãos públicos, levantando riscos e recursos envolvidos na manutenção do uso de um software após a sua entrega.

Também no artigo 15, apresentado no Apêndice H, no inciso VII e alínea c, no caso de uma contratação específica, será importante definir a possibilidade de considerar mais de um atestado relativo ao mesmo quesito de capacidade técnica, quando necessário para a comprovação da aptidão. Pois assim será mais bem definida a eficácia da contratação.

Para o disposto no artigo 16, conforme Figura 5, na análise de riscos devem ser identificado os riscos que possam comprometer o sucesso da contratação e da gestão contratual, bem como os riscos da solução não alcançar os resultados que atendam às necessidades da contratante. Ainda cabe ressaltar que a análise de riscos da contratação permeia todas as fases do processo de planejamento da contratação e deverá ser consolidada no documento final, denominado análise de riscos.

Figura 5 - Análise de riscos

Fonte: IN 04/2010 (BRASIL, 2010), adaptado pela autora.

No artigo 18 do Apêndice I, ressalta-se ainda que é obrigatória a execução da fase de planejamento da contratação, independentemente do tipo de contratação, inclusive nos casos de inexigibilidade; dispensa de licitação ou licitação dispensada e criação ou adesão à Ata de Registro de Preços. Em soluções de TI, o objetivo é promover o conjunto de boas práticas para contratações, o que requer planejamento.

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 8.666/93 (BRASIL, 1993), artigo 3º. Na seção II, denominada seleção do fornecedor, apresentada no Apêndice J, deve-se conduzir o processo de licitação para selecionar o fornecedor que dará prosseguimento às demais fases. 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 esta IN 04/2010, preferencialmente na forma eletrônica.

A seção III, denominada de gerenciamento do contrato, em seu inciso II e alínea a do artigo 25, descrevem que haja uma definição e especificação dos serviços a serem realizados ou bens a serem fornecidos, conforme Apêndice K. Também é no artigo 25, seção III,

conforme Apêndice L, que determina-se 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