Agilidade Com Responsabilidade

Agilidade Com Responsabilidade serviços mensuráveis entregando mais e com maior frequencia Paulo Caroli and Ismael Melo

Agilidade Com Responsabilidade serviços mensuráveis entregando mais e com maior frequencia Paulo Caroli and Ismael Melo 2015 Paulo Caroli and Ismael Melo

Contents Agradecimentos........................ 1 Prefácio............................. 2 Introdução........................... 3 Quem deve ler este livro.................. 3 De que trata este livro................... 3 Como aproveitar bem este livro.............. 4 Capítulo 1 - Desenvolvimento de Software Ágil...... 5 1.1. Lean........................... 10 1.2. Scrum.......................... 10 1.3. Kanban......................... 13 1.4. Produto Mínimo Viável................ 13 Capítulo 2 - Métricas de Software.............. 17 2.1. Análise de Pontos de Função.............. 17 2.2. SNAP.......................... 19 2.3. Métricas Derivadas................... 19 2.4. Outras Métricas..................... 20 Capítulo 3 - Outsourcing e o Desenvolvimento de Software Ágil.......................... 22 3.1 - Gerenciando um Portfólio Ágil............ 22 3.2 - Escritório de Projetos Ágeis.............. 23 3.2 - Escritório de Métricas................. 23

CONTENTS 3.3 - Práticas de Contratação................ 24 Capítulo 4 - Métricas no Contexto Ágil para Outsourcing 25 4.1 - Contagem da Iteração................. 25 4.2 - Contagem Incremental Consolidada......... 25 Capítulo 5 - Documentando o Ágil............. 28 Considerações Finais..................... 30 Ser Ágil........................... 30 Ser Responsável....................... 30 Bibliografia........................... 31 Termos e Definições...................... 32

Agradecimentos Aos familiares, amigos e colegas de trabalho que de alguma forma contribuíram com insights, dicas e/ou experiências sobre o tema abordado. Agradecemos também, à Join Tecnologia da Informação, que auxiliou na validação e pilotou artefatos propostos neste livro em seu processo ágil (SCRUM).

Prefácio Motivados pela recorrência do assunto ágil versus pontos de função entre agilistas, especialistas em métricas e gestores de tecnologia da informação, decidimos publicar este livro como um guia para quem deseja aventurar-se junto aos benefícios deste casamento de opostos que, aliás, se atraem. Explica-se: enquanto um modelo tem foco na colaboração e valoriza as pessoas, o outro enaltece o controle e a impessoalidade nas contratações de serviços de desenvolvimento de software; no entanto, ambos juntos, fornecem transparência e previsibilidade às contratações de software, diminuindo conflitos e problemas de planejamento. Incluímos também, a partir de nossos estudos e experiências no mercado, outro ingrediente nesta relação: o SNAP. Esta é uma métrica recente, mantida pelo mesmo órgão que a APF (o IFPUG) e que atua sobre os requisitos não funcionais de software. Sua origem remete, portanto, à lacuna deixada pela APF, que trata apenas os requisitos funcionais de software. Pretendemos que esta publicação desperte o interesse das comunidades relacionadas pelo assunto e que ela realmente seja útil para as diferentes organizações que contratam serviços de desenvolvimento de software, sejam elas públicas ou privadas, pequenas ou de grande porte. Agora você poderá ler nosso livro e começar a contratar seus projetos ágeis com segurança, transparência e alta capacidade de gerenciamento. E isso com o mínimo impacto possível, na essência da metodologia.

Introdução Ponto de Função (PF) tem sido nos últimos anos, alvo de discussões em relação a sua aplicabilidade no contexto ágil. Já possui adeptos nos órgãos do governo e em grandes corporações, que têm utilizado a APF como métrica para contratos firmados com base no método Scrum, com relativo sucesso, mas ainda sentimos que ainda há oportunidades para melhorias em ambos os métodos. Neste livro, vamos compartilhar o resultado de um trabalho que mostra uma forma efetiva para a conexão de métodos ágeis com a Análise de Pontos de Função (e também com o SNAP), não restrita, mas com foco em contratos de outsourcing. Quem deve ler este livro Este livro foi escrito para gestores de TI, consultores e espevialistas do mundo ágil e de métricas de software. Também pode ser proveitoso no entanto, aos entusiastas e demais interessados nos referidos assuntos. De que trata este livro Este livro apresenta uma abordagem empítica sobre assuntos recentes na contratações de projetos cujo desenvolvimento é iterativo incremental. detalhar os capitulos com breve descricao

Introdução 4 Como aproveitar bem este livro É necessário que você compreenda bem os conceitos apresentados nos capítulos iniciais para facilitar o entendimento do modelo proposto. Ao seu final, esta publicação possui Termos e Referências gerais, sobre os assuntos abordados, o que poderá ajudar a compreender o texto de forma mais dinâmica se você não tiver intimidade com ele.

Capítulo 1 - Desenvolvimento de Software Ágil Desenvolvimento de software ágil é tipicamente iterativo e incremental. Os requisitos de software são separados em pequenas funcionalidades e planejados em iterações. O software é construído de forma incremental, com funcionalidades recém-desenvolvidas sendo adicionadas ao software já existente. A figura abaixo descreve a natureza do desenvolvimento ágil de software. O ciclo de trabalho O desenvolvimento de software ágil avança em pequenos ciclos de desenvolvimento, que normalmente duram de uma a quatro semanas. Como você pode ver na figura acima, há várias atividades que ocorrem dentro de um ciclo de desenvolvimento. Essas atividades diferem, dependendo do estilo e da maturidade da metodologia ágil dentro da sua organização. A entrega incremental de funcionalidades proporciona o aumento

Capítulo 1 - Desenvolvimento de Software Ágil 6 do valor do produto ao longo do tempo, enquanto que o processo de desenvolvimento de software tradicional adiciona valor apenas na entrega do produto final idealizado. Esta é a diferença primária para a contagem de pontos no estilo ágil, ou tradicional. A figura abaixo ilustra entrega incremental típica de métodos ágeis por meio de iterações consecutivas. Entregando gradualmente A figura acima ilustra três iterações consecutivas. Os requisitos do produto são organizados em um backlog, uma lista dos pequenos pedaços de requisitos. Em seguida, a partir do backlog, uma certa quantidade de trabalho tipicamente é selecionada para uma iteração. Scrum chama esses backlogs respectivamente de backlog do produto e backlog da iteração (Sprint). Subsequentemente, à medida que o trabalho progride, este é continuamente integrado com o trabalho concluído anteriormente. Por fim, o trabalho realizado dentro da iteração ou é contabilizado, ou espera por um trabalho complementar de iterações futuras para ser contabilizado. O gráfico de funcionalidade em função do tempo (abaixo) fornece uma representação visual eficaz para comparar métodos ágeis e estilos de desenvolvimento tradicional. Neste gráfico, o eixo X representa o tempo decorrido, e o eixo Y representa a funcionalidade entregue. A seta azul representa o momento no tempo.

Capítulo 1 - Desenvolvimento de Software Ágil 7 Funcionalidade gráfico em função do tempo O gráfico acima representa o projeto no início. Neste caso, nenhuma funcionalidade foi concluída ainda. E esta é a mesma situação para o desenvolvimento ágil ou tradicional. As figuras a seguir mostram o que é entregue no estilo ágil comparado com equipes de desenvolvimento de software tradicionais. Sequencia no desenvolvimento tradicional: desenvolvimento tradicional 1

Capítulo 1 - Desenvolvimento de Software Ágil 8 desenvolvimento tradicional 2 Sequencia ágil: desenvolvimento tradicional 3

Capítulo 1 - Desenvolvimento de Software Ágil 9 desenvolvimento ágil 1 desenvolvimento ágil 2

Capítulo 1 - Desenvolvimento de Software Ágil 10 desenvolvimento ágil 3 Esta sequencia mostra como entregas ágeis incrementam funcionalidade ao longo do tempo, enquanto o estilo de desenvolvimento de software mais tradicional entrega o todo somente no final. 1.1. Lean 1.2. Scrum Scrum é um framework ágil para a conclusão de projetos complexos. Scrum foi inicialmente formalizado para projetos de desenvolvimento de software, mas tem sido aplicado para qualquer âmbito de projetos complexos, e trabalhos inovadores. O Scrum é especialmente adequado para projetos com requisitos quem mudam rapidamente ou são altamente emergentes. O desenvolvimento de software com Scrum progride através de uma série de iterações chamados de Sprints, que duram, tipicamente, de uma a quatro semanas. O modelo Scrum sugere que cada sprint começe com uma breve

Capítulo 1 - Desenvolvimento de Software Ágil 11 reunião de planejamento, e termine com uma reunião de revisão do trabalho realizado na Sprint. Estes são os princípios do gerenciamento de projetos Scrum: ciclos curtos e cadenciados com reuniões de alinhamenot e acompannhamento da evolução do trabalho e adequação e melhoria do time. Além das reuniões de (1) planning e (2) review, Scrum sugere mais duas reuniões que acontecem a cada Sprint. Essa são: (3) retrospectiva, a reunião que promove o momento kaizen, onde o time busca a melhoria contínua em relação ao processo, entrega, e interação entre as pessoas; e (4) grooming, a reunião onde o backlog do produto é revisitado buscando o entendimmento dos próximos requisitos, candidatos ao próximo Sprint. Sprint promove uma cadencia de semanas (de uma a quatro semanas, dependendo da preferencia do time). Mas diariamente o time realiza uma reunião para verificar o andamento das tarefas de trabahlo. Esta reunião (5) é a Daily Sprint. Nesta, basicamente todos os membros do time ficam de pé e respondem a tres perguntas, as quais auxiliam o time a se auto-organizar, buscando o alinhamento diário para realizar todo trabalho da Sprint. As tres perguntas são: o que fiz ontem, o que vou fazer hoje e o que está impedindo o progresso do meu trabalho. No mundo ágil Scrum, evitamos descrições completas e detalhadas sobre como tudo deverá ser feito pelo. Muito é deixada para o time de desenvolvimento Scrum decidir. Isso porque o time vai saber a melhor forma de resolver o problema em questão. É por isso que a reunião de planejamento do sprint é descrita em termos de metas e resultado desejado. O resultado é um compromisso com um conjunto de funcionalidades a serem desenvolvidas no próximo sprint. Buscando assim o equilíbrio entre automonia e flexibilidade e comprometimento do time. Scrum depende de uma equipe multifuncional e auto-organizada. O time scrum é auto-organizado pois não deve existir um líder de equipe que decide quem vai fazer qual tarefa e como. Tarefas e

Capítulo 1 - Desenvolvimento de Software Ágil 12 problemas são levantados por todos, e essas são questões decididas pela equipe como um todo. Os times Scrum são apoiados por dois papéis específicos. O primeiro é um ScrumMaster, alguém experiente com o framework que pode ajudar o time a usar o processo de Scrum para alcançar seus objetivos de alto nível. Os melhores Scrum Masters são aquelas pessoas que sentem mais satisfação de facilitar o sucesso dos outros do que seus próprios. O Scrum Master deve se sentir confortável e seguro com o frameowrk a ponto de dar todo controle em relação ao produto para o Product Owner(PO), e todo controle em relação ao desenvolvimento a sua equipe. O segundo papel específico é o Product Owner(ou PO). O PO representa o negócio, os clientes ou usuários, e orienta a equipe para a construção do produto certo. O Product Owner deve liderar o esforço de desenvolvimento, através de esclarecimentos e priorizações sobre o trabalho. Tipicamente, o PO trabalha com o Product Backlog, a lista mestre ods requisitos do produto a ser criado. É sua função priorizar o backlog com base no valor do negócio, e no alinhamento entre as partes interessadas, tanto internas quanto externas a equipe Scrum. Como tal, o Product Owner deve estar disponível para a equipe para responder a perguntas e direcionar o time a cada momento ou indagação. Esta combinação de autoridade e disponibilidade para a equipe de desenvolvimento faz com que o PO chave do framework. Scrum valoriza a auto-organização e autonomia do time; portanto, o Product Owner deve respeitar o direcionamento e a capacidade da equipe para criar o seu próprio plano de ação.

Capítulo 1 - Desenvolvimento de Software Ágil 13 1.3. Kanban 1.4. Produto Mínimo Viável Produto mínimo viável (em inglês, Minimum Viable Product MVP) é a versão mais simples de um produto que pode ser disponibilizada para a validação de um pequeno conjunto de hipóteses sobre o negócio. Basicamente, você não quer desperdiçar tempo, dinheiro e esforço construindo um produto que não vai atender as suas expectativas. Para isso, é preciso entender e validar as hipóteses sobre o negócio. O MVP ajuda essa validação e aprendizado da forma mais rápida possível. Diferentemente de produtos criados da forma tradicional, normalmente com um período longo de criação de protótipo, análise e elaboração, o objetivo do MVP é somente a validação do primeiro passo, do produto mínimo, bem menos elaborado do que a versão final. O MVP foca no produto mínimo, mas viável para verificar se o direcionamento está correto. O conjunto inicial de funcionalidades necessário para o processo de validação de hipóteses e aprendizagem sobre o negócio. 1.4.1. Origem A ideia de MVP está originalmente vinculada às ideias popularizadas pelo estilo Toyota de manufatura enxuta ¹ ² ³. Steve Blank, um empreendedor do Vale do Silício, criou uma metodologia ⁴ baseada no desenvolvimento do cliente. Este foi o início do movimento Lean ¹Womack, James P.; Daniel T. Jones, and Daniel Roos. (1990) The Machine That Changed the World. ²Ohno, Taiichi. (1988) Toyota Production System. Productivity Press ³Womack, James P.; Daniel T. Jones. (2003) Lean Thinking. Free Press. ⁴Blank, Steve G. (2013) The four steps to the epiphany: successful strategies for products that win.

Capítulo 1 - Desenvolvimento de Software Ágil 14 Startup, o qual teve seu ápice com Eric Ries e o lançamento do seu livro ⁵, com o mesmo nome do movimento. Enquanto Eric Ries popularizou o MVP desde a publicação do seu livro Lean StartUp, o termo estava em uso vários anos antes do surgimento do movimento Lean Startup, especialmente entre as startups, com seus empreendedores e investidores do Vale do Silício. A expressão minimum viable product apareceu pela primeira vez em 2000 em um artigo de Willin Junk ⁶, de título O equilíbrio dinâmico entre Custo, Cronograma, Recursos e Qualidade em Projetos de Desenvolvimento de Software, em português. 1.4.2. Criação evolutiva do MVP MVP não significa que o produto não vá evoluir e incrementar suas funcionalidades. Muito pelo contrário, a ideia por trás de MVP é o incremento validado e guiado pelos resultados iniciais. A correção ou a confirmação do curso é que vai guiar os incrementos a seguir. Incrementos estes que são MVP: novos produtos mínimos adicionados aos produtos mínimos já validados. Mais uma vez, produtos mínimos, entretanto viáveis para fazer novas verificações sobre o direcionamento. O produto, agora, é mais elaborado, talvez com uma base maior de usuários, permitindo validar novas hipóteses, ainda mais elaboradas. É muito importante compreender que o MVP promove uma criação evolutiva. Logo, a arquitetura, bem como o ferramental de construção do produto, deve permitir esta característica de evolução gradual e contínua. Jez Humble e David Farley, em 2010, publicaram o livro Continuous ⁵Ries, Eric. (2011) The Lean Startup: How Today s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing. ⁶Willian, S. Junk. (2000) The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects, Computer Science Dept., University of Idaho, SEPM-001.

Capítulo 1 - Desenvolvimento de Software Ágil 15 Delivery ⁷. Neste livro, os autores elaboram sobre um processo de entrega rápido e de baixo custo, permitindo a criação incremental de produtos de software. Eles definem Continuous Delivery (em português, Entrega Contínua) como uma disciplina de desenvolvimento de software que promove entregas mais rápidas e com maior frequência. Apesar do livro Continuous Delivery entrar em detalhes sobre produtos de software e o fluxo de trabalho para sua criação, a essência da ideia de Entrega Contínua é a mesma que Eric Ries recomenda no livro Lean StartUp: ciclos rápidos para validação das hipóteses. Ciclos rápidos e frequentes, permitindo tempos de liberação muito curtos e com baixos custos de experimentação. No livro Direto Ao Ponto ⁸ Paulo Caroli descreve uma receita com atividades de análise e planejamento efetivo baseado em MVP. Esta proposta que comibna APF com métodos ágeis toma como base o entendimmento e planejamento dos MVPs e suas features de acordo com a proposta DiretoAoPonto. 1.4.3. Incrementando MVPs O produto é construído de forma incremental, com MVPs recémcriados sendo adicionados ao produto consolidado já existente. A entrega contínua e incremental proporciona o aumento do valor do produto ao longo do tempo, enquanto que o processo de criação de produto tradicional não fornece qualquer valor até o final, quando todo o produto está pronto. ⁷Jez Humble and David Farley. (2010) Continuous Delivery, Addison-Wesley. ⁸Paulo Caroli. (2014) Direto Ao Ponto, criando produtos de forma enxuta, LeanPub.

Capítulo 1 - Desenvolvimento de Software Ágil 16 MVPs para cortar grama Esta figura mostra como MVP oferece pequenas validações ao longo do tempo, enquanto o estilo de criação do produto mais tradicional só oferece a validação do todo no final. Primeiramente o tesourão forma o primeiro MVP. Há realmente grama para cortar? Alguém vai utilizar tal aparato? A validação dessas hipóteses impulsiona a evolução do produto para o próximo MVP. Talvez um aparato mais cômodo, com um cabo. Depois rodar. E assim adiante até que o produto evolua de MVP a MVP, sempre incrementando e validando tais incrementos. O MVP promove uma abordagem incremental, em que apenas uma pequena parte de um requisito ou ideia mais abrangente são tratadas ao mesmo tempo. Cada um desses incrementos é projetado, criado e preparado para ser adicionada ao produto, adicionando mais funcionalidades ao mesmo. Em essência, uma ideia de produto de softwate é sequenciada em uma série de hipóteses menores, mais simples e, logo, mais fácil de entender, criar e contabilizar. E cabe lembrar que felizmente software não é manufatura: no mundo se software, um cortador de grama pode ser criado adicionando-se rodas e cabo a um tesourão.

Capítulo 2 - Métricas de Software 2.1. Análise de Pontos de Função A Análise de Pontos de Função (APF) é o método padrão do IFPUG (International Function Points Users Group) para a medição funcional de software. Sua função é quantificar a funcionalidade solicitada e entregue sob o ponto de vista do usuário, em termos de tarefas, serviços e estruturas de dados, independentemente da tecnologia utilizada e da forma como a solução foi projetada. O método considera em sua composição, funções de transação e funções de dados, num total de cinco tipos de função (Quadro 1) e três níveis de complexidade (Quadro 2). Para cada tipo e complexidade, há uma ponderação a qual chamamos contribuição. A relação de complexidade versus contribuição pode ser visualizada no Quadro 3. Quadro 1 - Tipos de Função na APF Quadro 2 - Complexidade de um Função na APF Quadro 3 - Complexidade versus Contribuição (IFPUG). Diferentemente de uma indicação ou estimativa de tamanho (abordagem NESMA, que será explicada a seguir), uma medição de tamanho funcional necessita de um maior detalhamento dos requisitos para ser executada, mas é mais confiável, visto que possibilita a quantificação ponderada dos itens do escopo de um projeto. O Manual de Práticas de Contagem de Pontos de Função do IFPUG, atualmente publicado na versão 4.3.1, é o documento que descreve as regras que permeiam uma contagem de pontos de função e orienta apenas a medição do tamanho funcional envolvido em um

Capítulo 2 - Métricas de Software 18 projeto de software. Para que se contratar utilizando esta métrica, é importante, embora não essencial, estabelecer convenções locais e deflatores de produtividade para cada tipo de manutenção. As convenções visam estabelecer uma relação de linearidade entre as medidas de tamanho e as estimativas de esforço e/ou custo. No Brasil, um exemplo de guia de orientações de métricas bastante conhecido é o que suporta os contratos de prestação de serviços de desenvolvimento de software mantidos pela Caixa Econômica Federal (CEF) com seus fornecedores, os quais são estabelecidos com um baseline de pontos de função e diversas adequações em relação ao método original publicado pelo IFPUG. O Governo Federal inclusive, através do Ministério do Planejamento, publicou um guia com diversas necessidades consideradas comuns, o Roteiro de Métricas do SISP. Ele é aderente à Instrução Normativa 04/2010, que orienta que os contratos de software sejam mantidos com base em critérios objetivos, critérios pelos quais a APF se destaca. Com a Instrução Normativa, o Governo passa a ter um maior controle sobre o que está sendo contratado, um processo maduro, auditável e repetível (com os mesmos resultados e diferentes profissionais, pode-se chegar a um mesmo quantitativo da unidade de pontos de função). No Brasil, entre as organizações mais conhecidas que utilizam a Análise de Pontos de Função (APF) podemos citar: BACEN, Bradesco, Oi, TAM, Santander, Caixa Econômica Federal (CEF), Embratel, Porto Seguro, SERPRO, SICREDI, DATAPREV, Infraero, Petrobras, Correios, Tribunal de contas da união (TCU), Ministério das Cidades, Aeronáutica, Marinha do Brasil, Centro de Desenvolvimento da Tecnologia Nuclear, Comissão nacional de energia nuclear, INEP, Ministério da Cultura, Ministério do Trabalho, Ministério da Educação, dentre outras. Além do método padrão do IFPUG, existem no entanto, outras métricas para estimativa e medição de tamanho funcional, tais como: as técnicas NESMA Indicativa, Estimativa e de Melhoria,

Capítulo 2 - Métricas de Software 19 Mark II, COSMIC, entre outras. Veremos conceitos básicos destas métricas posteriormente neste capítulo, visando complementar o seu entendimento sobre estimativas de software e melhor abordarmos os tópicos inerentes ao Escritório de Métricas no Capítulo 4. 2.2. SNAP O Processo de Avaliação Não Funcional de Software (SNAP) do IFPUG, publicado na versão 2.1, é um framework para avaliar e quantificar os requisitos não funcionais de software, sendo complementar à APF. O modelo consiste em 4 categorias e 14 subcategorias de medição, onde os requisitos não funcionais são mapeados para sub-categorias relevantes. Assim como o método funcional do IFPUG, o SNAP tem um manual de contagem próprio e possui critérios objetivos. 2.3. Métricas Derivadas A APF e o SNAP são métricas que calculam unidades base, ou seja podem ser derivadas ou convertidas, assim como ocorre por exemplo com a unidade base da construção civil, o metro quadrado. Note, que tanto o ponto de função como o metro quadrado podem ser utilizados como referência para a predição, acompanhamento e controle de produtividade (em horas por PF ou metro quadrado produzido) e que ambas também podem convencionar um valor unitário como parâmetro de custos para seus projetos (o valor do PF ou o valor do CUB).

Capítulo 2 - Métricas de Software 20 2.4. Outras Métricas Há diversas outras métricas em relação a APF e poucas que atuam sobre o escopo relacionado ao SNAP, porém ou obsoletas ou pouco conhecidas e utilizadas, ou ainda vistas como uma tendência por alguns. Há ainda, métricas que podem ser utilizadas em situações específicas, onde a capacidade de predição é ainda limitada pelo alto nível de incerteza na concepção do escopo do produto que será atendido pelo projeto de software. Veremos essas métricas a seguir. 2.4.1. Estimativa NESMA O método de Estimativa NESMA (mantido pelo órgão com este nome) foi concebido com base na APF. Ele atribui a complexidade baixa para todas as funções de dados (repositórios, definidos como ALI ou AIE) e a complexidade média para todas as funções de transação (definidas como EE, CE ou SE) resultando na contribuição obtida pela análise do Quadro 4. Quadro 4 - Tipo de Função versus Contribuição (NESMA). Este método normalmente é utilizado em fases iniciais do ciclo de vida do desenvolvimento de software, especialmente quando ainda não é possível visualizar o detalhamento das funcionalidades do escopo, embora seja possível identificar a maioria delas. 2.4.2. Indicativa NESMA Há também uma forma para a realização de estimativas de software em altíssimo nível, chamado de método holandês, ou ainda, Indicativa NESMA. Neste método, somente as funções de dados são contadas, sendo que um ALI contribui com 35 pontos de função e um AIE, com 15 pontos de função (Quadro 5). É um método

Capítulo 2 - Métricas de Software 21 pouco preciso e pouco utilizado, mas ainda útil para uma contagem antecipada. Quadro 5 - Tipo de Função versus Contribuição (NESMA). 2.4.3. COSMIC O COSMIC é um método para estimativa e medição de software que tem chamado a atenção pela sua simplicidade e aplicabilidade, pois atua sobre qualquer manutenção em que funcionalidades específicas são mexidas (mesmo as que seriam classificadas como não funcionais na APF). O COSMIC tem como principais características: o tamanho flutuante para cada funcionalidade e a possibilidade de estabelecer níveis de granularidade diferentes do que a APF utiliza (visão do usuário). Embora parte do mercado visualize este método como tendência, ainda a pouca referência sobre o assunto e indredubilidade de alguns como algo que realmente possa ser utilizado com benefícios adicionais a APF no estabelecimento de acordos comerciais.

Capítulo 3 - Outsourcing e o Desenvolvimento de Software Ágil O outsourcing, ou tercerização, é o modelo de contratação de produtos e serviços onde o contratante transfere a responsabilidade sobre parte de suas atividades (as que não são propriamente o foco da operação ou core da organização). Este formato, mesmo com a aplicação do método de pontos de função, é amplamente utilizado para contratação de serviços de desenvolvimento ou manutenção de software seguindo o processo de desenvolvimento tradicional, porém não é comum o casamento da APF com métodos ágeis, embora existam casos de aplicação com sucesso no mercado. 3.1 - Gerenciando um Portfólio Ágil Um portfólio refere-se a projetos, programas, subportfólios e operações, gerenciados como um grupo para atingir objetivos específicos. [2] Projetos ágeis são propensos a um gerenciamento ágil, embora nada venha a impedir uma abordagem de gestão de portfólio tradicional. Sugere-se escalar a utilização do Kanbam e suas ferramentas (lead time e work in progress), também como uma maneira de visualizar e gerenciar o portfólio. É uma forma visual onde programas, projetos e subprojetos podem ser facilmente acompanhados pelo Escritório de Gerenciamento de Projetos e/ou Comitê de TI.

Capítulo 3 - Outsourcing e o Desenvolvimento de Software Ágil 23 3.2 - Escritório de Projetos Ágeis Um Escritório de Gerenciamento de Projetos (EGP, ou em inglês PMO) é uma estrutura organizacional que padroniza os processos de governança relacionados a projetos, facilitando o gerenciamento de recursos, metodologias, técnicas e ferramentas. [2] O PMO é responsável pelo apoio ao gerenciamento de projetos, mas não está restrito a este escopo. Em projetos ágeis com a utilização de métricas de software, o PMO ganha em capacidade de gestão dos projetos sob sua responsabilidade, pois viabiliza-se a mensuração tamanho de cada pedaço de software impactado, de forma normalizada. A normalização possibilita a realização de comparações matemáticas e estatísticas que facilitam o controle da operação, a detecção de tendências e apóiam a avaliação de desempenho da organização e fornecedores, além de viabilizar análises relacionadas às metas mapeadas no alinhamento estratégico da TI organizacional. 3.2 - Escritório de Métricas O Escritório de Métricas é uma estrutura física ou conceitual, complementar ao Escritório de Projetos, que atua como mediadora sobre assuntos relacionados às estimativas de software, como um braço especialiazado que atesta o tamanho de software com vistas a sua correta precificação frente aos contratos firmados com base em métricas. Dependendo do porte e estrutura de cada organização, cabe aos gestores avaliar se será necessário criar uma estrutura formal física ou se deverá ser contratada uma empreza especializada em métricas para assumir suas atribuições.

Capítulo 3 - Outsourcing e o Desenvolvimento de Software Ágil 24 3.3 - Práticas de Contratação Para que se colham os benefícios providos pela utilização de métricas, algumas práticas devem, ou ao menos os autores assim entendem, ser cuidadosamente estabelecidas, antes mesmo da contratação de um fornecedor. Vamos explorar mais isso durante este subcapítulo. Primeiramente, segundo Neto [1], as relações cliente-fornecedor não devem ser pontuadas apenas pela concorrência de preços, pois isoladamente não há sentido sem compará-lo a qualidade experada pelo produto serviço sendo contratado. 3.3.1 - Homologação de Fornecedores Um processo de homologação 3.3.2 - Gestão de Demandas Em um cenário de full outsourcing, com um processo uniforme e definida uma metodologia de desenvolvimento específica,

Capítulo 4 - Métricas no Contexto Ágil para Outsourcing 4.1 - Contagem da Iteração Como a maioria das referências encontradas para aplicação de pontos de função em contextos ágeis utiliza a abordagem do Scrum, se identificou padrões de mercado, principalmente quando analisado o cenário público no âmbito do governo federal. Neste modelo, cada Sprint é contada separadamente, ao seu início e ao seu final. 4.2 - Contagem Incremental Consolidada Esta é uma proposta dos autores, a qual consolida o tamanho funcional e não funcional incrementalmente, com foco no valor que o trabalho executado agregou ao produto sendo desenvolvido ou mantido, o que é aderente à perspectiva ágil. A abordagem sugerida visa também, fornecer uma melhor capacidade de predição do orçamento e visibilidade em relação ao momento atual do projeto sendo portanto, um importante instrumento para o acompanhamento de budget e progresso pelo responsável pelo projeto. Considerando a utilização dos conceitos de feature driven e MVP, o modelo aplica-se de forma consistente e abrangente em conjunto com as métricas APF e SNAP, com vistas ao faturamento dos serviços prestados e no modelo de pagamento contra-a-entrega. O modelo ágil proposto nesta publicação será simplificado para fins