Comparaison et perspectives

2 REFERENCIAL TEÓRICO

Este capítulo tem o propósito de descrever os métodos ágeis, com ênfase na metodologia Scrum, apresentar os conceitos e as aplicações da IN 04/2010, e do Acórdão 2314 (BRASIL, 2013a).

2.1 _{MÉTODOS ÁGEIS}

Os métodos ágeis surgiram a partir do manifesto ágil, em 2001, e seus princípios estão focados na satisfação do cliente, através de 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. Enfatiza, ainda, a prioridade dos projetos e a documentação mínima e eficiente. Surgiram em contrapartida aos processos de desenvolvimento tradicional de software.

De acordo com Lobo (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 mais controlado e mais rápido. O autor argumenta, também, que a maioria das metodologias ágeis possui uma característica em comum: iterações em curto período de tempo, por exemplo, uma semana ou um mês. Segundo Gabardo e Gomes (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.

Para o manifesto ágil, alguns valores devem ser considerados para o desenvolvimento ágil de software, conforme Quadro 3, onde mesmo havendo valor nos itens à direita, valoriza- se mais os itens à esquerda.

Quadro 3 - Valores do manifesto ágil

VALORES DO MANIFESTO ÁGIL

Indivíduos e interação entre eles Mais que processos e ferramentas

Software em funcionamento Mais que documentação abrangente

Colaboração com o cliente Mais que negociação de contratos

Responder a mudanças Mais que seguir um plano

Fonte: Manifesto ágil. Disponível em: <http://manifestoagil.com.br/index.html>, adaptado pela autora.

2.1.1 _{Principais metodologias ágeis}

Misra et al. (2011) descrevem que as metodologias de desenvolvimento de software ágil 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 Misra 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 Misra et al. (2011, p. 975):

(1) A maior prioridade é dada para à satisfação do cliente através da entrega adiantada e contínua de software valioso.

(2) Mudanças de requisitos são bem-vindas, mesmo tardiamente, durante o desenvolvimento. Mudanças ágeis nos processos são 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 juntas 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) 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 Salo e Abrahamsson (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, aumentando a possibilidade de sucesso no desenvolvimento do software. Por outro lado, o XP tem por foco nas atividades relacionadas à implantação do software. Dyba e Dingsøyr (2008), por sua vez, consideram metodologias ágeis as seguintes:

2.1.1.1 Metodologias Crystal

Para Dyba e Dingsøyr (2008), esse método é executado para equipes de diferentes tamanhos e criticidade, utilizando as cores laranja claro, amarelo, vermelho e azul. É o método mais ágil, pois concentra-se na comunicação em pequenas equipes de desenvolvimento de software. Contém sete características: entrega frequente, melhoria reflexiva, comunicação osmótica, segurança pessoal, foco, fácil acesso a usuários experientes, e os requisitos para o ambiente técnico.

2.1.1.2 Método de desenvolvimento de software dinâmico (DSDM)

Nesse método, Dyba e Dingsøyr (2008, p. 835) descrevem que o projeto é divido em três fases: pré-projeto, projeto do ciclo de vida e pós-projeto. A DSDM possui nove princípios subjacentes:

envolvimento do usuário;

capacitação da equipe do projeto; entrega frequente;

atender às necessidades de negócios atuais; desenvolvimento iterativo e incremental; permitir alteração de escopo;

escopo de alto nível a ser fixado antes do início do projeto; testes ao longo do ciclo de vida e

2.1.1.3 Desenvolvimento Guiado por Funcionalidades (FDD)

Conforme, Dyba e Dingsøyr (2008), o FDD combina desenvolvimento orientado por modelo, é ágil, tem ênfase no modelo inicial de objeto, há divisão do trabalho em funções e design iterativo para cada recurso. Afirma ser adequado para o desenvolvimento de sistemas críticos. Uma iteração de um recurso consiste em duas fases: concepção e desenvolvimento.

2.1.1.4 Desenvolvimento de software Lean

O método Lean, de acordo com Dyba e Dingsøyr (2008, p. 835), é uma adaptação de princípios de produção magra e, em particular, relacionada com o sistema de produção Toyota aplicado ao desenvolvimento do software. Baseia-se em sete princípios: (i) eliminar perdas; (ii) ampliar a aprendizagem; (iii) decidir o mais tarde possível; (iv) entregar o mais rápido possível; (v) capacitar a equipe; (vi) construir, integridade; (vii) ver o todo.

2.1.1.5 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