ANDRÉ DOMINGUES PAIS

DESENVOLVIMENTO DO PLANO DE NEGÓCIOUTILIZANDO O SCRUM

LONDRINA2018

ANDRÉ DOMINGUES PAIS

DESENVOLVIMENTO DO PLANO DE NEGÓCIOUTILIZANDO O SCRUM

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

Orientador: Prof. Dr. Rodolfo Miranda deBarros

LONDRINA2018

Ficha de identificação da obra elaborada pelo autor, através do Programa de GeraçãoAutomática do Sistema de Bibliotecas da UEL

Pais, André Domingues.Desenvolvimento do plano de negócio utilizando o Scrum / André Domingues Pais. -Londrina, 2018.57 f.

Orientador: Prof. Dr. Rodolfo Miranda de Barros.Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) -

Universidade Estadual de Londrina, Centro de Ciências Exatas, Graduação em Ciência daComputação, 2018.

Inclui bibliografia.

1. Plano de Negócios - TCC. 2. Metodologia Ágil Scrum - TCC. I. Barros, Prof. Dr.Rodolfo Miranda de. II. Universidade Estadual de Londrina. Centro de Ciências Exatas.Graduação em Ciência da Computação. III. Título.

ANDRÉ DOMINGUES PAIS

DESENVOLVIMENTO DO PLANO DE NEGÓCIOUTILIZANDO O SCRUM

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

BANCA EXAMINADORA

Orientador: Prof. Dr. Rodolfo Miranda deBarros

Universidade Estadual de Londrina

Prof(a). Dr(a). Jandira Guenka PalmaUniversidade Estadual de Londrina – UEL

Prof. Ms. Fábio Cezar MartinsUniversidade Estadual de Londrina – UEL

Londrina, 18 de dezembro de 2018.

Este trabalho é dedicado à minha família.

AGRADECIMENTOS

Agradeço Primeiramente a Deus, por ter me dado forças para chegar até aqui.

Agradeço imensamente à minha família, aos meus pais, Alvacely Domingues Paise Agnaldo Roni Pais, e a minha irmã Ariany Domingues Pais, por todo o apoio e porsempre acreditarem em mim, mesmo quando tudo parecia estar perdido.

Agradeço a minha noiva Natalia Novelli Pergo, por toda a paciência e apoio nestesanos de graduação.

Agradeço a todos os professores que fizeram parte desta etapa da minha vida, emespecial ao meu orientador Rodolfo Miranda de Barros, por todo conhecimento passado,as broncas e aos trabalhos e provas adiadas para que tivessemos chances.

Agradeço a Universidade Estadual de Londrina, em especial ao Departamento deComputação, por estes anos de graduação.

E finalmente, agradeço as amizades que formei nestes anos e que irei levar para oresto da vida, por todo conhecimento compartilhado, por todas as madrugadas acordadosjuntos estudando para as provas, pelas brincadeiras e histórias que escrevemos nestagraduação.

“Não vos amoldeis às estruturas destemundo, mas transformai-vos pela renovação

da mente, a fim de distinguir qual é avontade de Deus: o que é bom, o que Lhe é

agradável, o que é perfeito.“(Bíblia Sagrada, Romanos 12, 2)

PAIS, A. D.. Desenvolvimento do plano de negócio utilizando o Scrum. 2018. 53f.Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) – UniversidadeEstadual de Londrina, Londrina, 2018.

RESUMO

Desenvolver um negócio de software sem um planejamento prévio é muito arriscado, poissem uma preparação o empreendedor estará colocando em jogo tudo o que acredita ealmeja. Um plano de negócio vai além de estabelecer objetivos, através dele o empreen-dedor pode compreender suas formas de operações, definir estratégias, definir um planopara conquistar sua presença no mercado, além de conseguir se organizar financeiramente.Desta forma, propõe-se neste trabalho o desenvolvimento do plano de negócio voltado àprodutos de software, baseando-se na metodologia ágil Scrum. Fazendo com que o empre-endedor assuma um ou mais papéis fundamentais, característicos da metodologia.

Palavras-chave: Negócio de Software. Plano de Negócio. Desenvolvimento do Plano deNegócio. Produtos de Software. Scrum.

PAIS, A. D.. Development of the business plan using Scrum. 2018. 53p. Final Pro-ject (Bachelor of Science in Computer Science) – State University of Londrina, Londrina,2018.

ABSTRACT

Developing a software business without prior planning is very risky, because withoutpreparation the entrepreneur will be putting at stake everything he believes and desires.A business plan goes beyond setting objectives, through which the entrepreneur can un-derstand their forms of operations, define strategies, define a plan to gain their presencein the market, and manage to organize financially. In this way, it is proposed in this workthe development of the business plan focused on software products, based on the agileScrum methodology. Making the entrepreneur assume one or more fundamental roles,characteristic of the methodology.

Keywords: Software Business. Business plan. Development of the Business Plan. Soft-ware Products. Scrum.

LISTA DE ILUSTRAÇÕES

Figura 1 – Exemplo genérico do Plano de Negócios. Fonte: venturycapital.com . . 19Figura 2 – Ilustração Modelo Tradicional. Fonte: http://alexpagernet.blogspot.com 22Figura 3 – Ciclo do Desenvolvimento Ágil. Fonte: http://metodologiaagil.com . . . 25Figura 4 – Diferenças entre Metodlogias Ágeis x Tradicional. Fonte: slideplayer.com.br 27Figura 5 – Ciclo do Scrum. Fonte: https://www.youtube.com/watch?v=vg1S1WYZa6o 32Figura 6 – Tabela de Organização do Product backlog. Fonte: Autor . . . . . . . . 39Figura 7 – Tabela do Sprint. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . 40Figura 8 – Tabela representativa do Sprint: Sumário Executivo. Fonte: Autor . . . 40Figura 9 – Tabela representativa do Sprint: Análise de Mercado. Fonte: Autor . . 41Figura 10 – Tabela representativa do Sprint: Plano de Marketing. Fonte: Autor . . 41Figura 11 – Tabela representativa do Sprint: Plano Operacional. Fonte: Autor . . . 41Figura 12 – Tabela de Organização dos Releases. Fonte: Autor . . . . . . . . . . . . 42Figura 13 – Tabela de Releases do Plano de Negócios. Fonte: Autor . . . . . . . . . 42Figura 14 – Linha do Tempo. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . 43Figura 15 – Desenvolvimento do Sprint de Sumario Executivo. Fonte: Autor . . . . 43Figura 16 – Finalização do Sprint de Sumário Executivo e Entrega do Incremento

do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 44Figura 17 – Desenvolvimento do Sprint de Análise de Mercado. Fonte: Autor . . . . 44Figura 18 – Finalização do Sprint de Análise de Mercado e Entrega do Incremento

do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 19 – Desenvolvimento do Sprint de Plano de Marketing. Fonte: Autor . . . . 45Figura 20 – Finalização do Sprint de Plano de Marketing e Entrega do Incremento

do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 46Figura 21 – Desenvolvimento do Sprint de Plano Operacional. Fonte: Autor . . . . 46Figura 22 – Finalização do Sprint de Plano Operacional e Entrega do Incremento

do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 47Figura 23 – Plano de Negócios Finalizado. Fonte: Autor . . . . . . . . . . . . . . . 47

LISTA DE TABELAS

LISTA DE ABREVIATURAS E SIGLAS

PO Product Owner

Dev Team Development Team

ABNT Associação Brasileira de Normas Técnicas

IBGE Instituto Nacional de Geografia e Estatística

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 162.1 Plano de Negócios . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.2 Importância do Plano de Negócios . . . . . . . . . . . . . . . . . . . . 162.1.3 Etapa 1: Elaboração do Plano de Negócios . . . . . . . . . . . . . . . 172.1.3.1 Sumário Executivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3.2 Análise de Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3.3 Plano de Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3.4 Plano Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Metodologias Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.2 Manifesto Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3 Metodologia Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.4 Metodologia Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.5 Metodologi Ágil x Tradicional . . . . . . . . . . . . . . . . . . . . . . 252.2.5.1 Orientação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.5.2 Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.5.3 Tipo de Garantia de Confiança . . . . . . . . . . . . . . . . . . . . . . . 262.2.5.4 Gerente de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.5.5 Time de Desenvolvedores . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.5.6 Participação do Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.5.7 Abordagem (Figura 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.2.1 Escolha o Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.2.2 Escolha o Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.2.3 Defina a Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.2.4 Criação do Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . 302.3.2.5 Planejamento e desenvolvimento do Product Backlog . . . . . . . . . . . . 302.3.2.6 Planejamento do Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.2.7 Acompanhando a evolução do Projeto . . . . . . . . . . . . . . . . . . . 312.3.2.8 Reuniões diárias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.2.9 Sprint Review (entrega parcial do produto) . . . . . . . . . . . . . . . . . 31

2.3.2.10 Retrospectivas dos Sprints . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.3 Como integrar o Scrum à um plano de negócios . . . . . . . . . . . . . 32

3 ELABORAÇÃO DO PLANO DE NEGÓCIOS DE PRODU-TOS DE SOFTWARE UTILIZANDO O SCRUM . . . . . . . 33

3.1 Equipe de Desenvolvedores . . . . . . . . . . . . . . . . . . . . . . 333.1.1 Definindo Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.1.1 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.1.2 Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.1.3 Equipe (Dev Team) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Estudando o Product Backlog de um Produto de Software . . 353.2.1 Informações Sobre o Negócio . . . . . . . . . . . . . . . . . . . . . . . 353.2.2 Analise do Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.3 Estratégias de Comercialização e Marketing . . . . . . . . . . . . . . . 363.2.4 Projeções Financeiras . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.5 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.6 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3 Releases Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.4 Finalização e Entrega . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

APÊNDICES 52

ANEXOS 53

14

1 INTRODUÇÃO

Para que uma ideia ou produto de software consiga se estabelecer no mercado deforma estruturada, sendo capaz de absorver constantes mudanças e de conseguir preverimprevistos, é altamente necessário o desenvolvimento de um plano de negócios. Aindamais quando pensa-se que a cada dia que passa o mercado se torna mais competitivo,com empresas concorrentes super preparadas para manter-se na luta por mais espaço nosnegócios.

Criar um plano de negócio não é tarefa simples, porém é um passo extremamentenecessário, pelo simples fato de estar apostando suas fichas, sonhos e tudo o que acredita,em algo que ainda não tem certeza se irá dar frutos em um futuro próximo.

Sabe-se que tanto o mundo dos negócios quanto o mercado de software são áreasinconstante e que devem ser analisadas com atenção, pois se hoje existe alguma empresaou produto de software que está em alta, amanhã ou depois pode ser que as mesmas jánão estejam tão interessante assim. Esta instabilidade pode ocorrer por inúmeros motivos,desde surgimento de novos produtos de software, inovações tecnológicas, surgimento denovos conceitos e serviços até o simples fato de determinado nicho não estar mais no gostodas pessoas, isto ocorre no surgimento de novos produtos de software, como por exemplo,redes sociais e aplicativos.

Reconhecendo a importância de criar um plano de negócios, pode vir à surgirdúvidas a respeito de sua organização e planejamento, um dos objetivos deste trabalho érespondê-las.

Então que forma melhor do que, criar seu plano de negócios de maneira altamenteadaptável à estas variações, prevendo obstáculos ou até mesmo se moldando para que osmesmos passem a não afetarem seu negócio?

A resposta para estas perguntas é um ponto importante deste trabalho, assimentão, são apresentadas as Metodologias Ágeis, dentre elas esta o foco principal deste tra-balho, o Scrum. Toda definição, características e vantagens do Scrum, serão apresentadasà seguir. De acordo com [1] existem 9 perguntas essenciais que todo empreendedor deveresponder ao longo da elaboração do plano de negócio, dentre elas gostaria de destacar 6,sendo:

1. Qual é o meu negócio?

2. Aonde desejo chegar?

3. Qual o meu público alvo?

4. Que estratégias utilizarei para alcançar meus objetivos?

15

5. Como conquistarei espaço no mercado?

6. Que retorno meu negócio pode me proporcionar?

Estas perguntas são muito interessantes, já que apesar de parecerem simples, portrás de cada uma existe um estudo cuidadoso. Pois, se uma delas não for bem definida, oplano de negócios pode estar comprometido, porém se realizado conforme a MetodologiaÁgil Scrum, estas desatenções podem ser facilmente corrigidas.

Assim, pode-se responder as perguntas levantadas acima e entender a importânciado desenvolvimento do plano de negócios, é preciso meter a mão na massa, e colocar emprática tudo o que será apresentado daqui em diante.

Este trabalho será organizado da seguinte maneira: na seção 2, será abordada afundamentação teórica para a compreensão do trabalho, na seção 3, será apresentado opasso a passo para o desenvolvimento do plano de negócios utilizando o Scrum, na seção4, será apresentada a conclusão, referências bibliográficas, apêndices e anexos.

16

2 FUNDAMENTAÇÃO TEÓRICA

2.1 Plano de Negócios

2.1.1 Definição

Um Plano de Negócio é um documento descritivo onde são abordados os obje-tivos de um negócio, definindo assim as estratégias que serão utilizadas para que estesobjetivos sejam alcançados. Dentre estes objetivos destaca-se a diminuição dos riscos eincertezas, pois através do plano de negócio é possível prever inconsistências no mercadoantes mesmo de ocorrerem, consequentemente gera-se estratégias preventivas para desviarde tais obstáculos ou ao menos minimizar o seu impacto [2].

’Plano’ então como o próprio nome sugere, representa todos os passos que serãoindividualmente estudados e analisados para evitar erros estratégicos.

Em outras palavras, de acordo com [3] o plano de negócio será o mapa de percurso.Ele irá ajudar a definir se a ideia é viável ou não, e deixará mais claro as característicasdeste negócio, como por exemplo: o nicho do mercado, os serviços e produtos que serãooferecidos, o público alvo, os fornecedores, e até mesmo os concorrentes, evidenciando ospontos fortes e fracos do negócio.

2.1.2 Importância do Plano de Negócios

Como já apresentado, a criação de um plano de negócios é algo de extrema im-portância para que o empreendedor consiga se estabelecer no mercado de maneira muitomais segura. Baseado em [2, 3, 4, 5], pode-se destacar algumas vantagens e característicasdo plano de negócios:

∙ É um documento que ajudará com o processo de validação de uma ideia, atravésdo qual o empreendedor obtém dados estatísticos ou concretos para decidir se deve o seunegócio é viável ou não.

∙ É um documento importantíssimo no qual o empreendedor possui para analisarsobre o seu negócio e tirar algumas conclusões: O meu negócio é viável? Meu público alvoestá bem definido? Terei condições de disputar mercado com os meus concorrentes?

∙ Assim que finalizado, o plano de negócios permite definir diversas estratégias,desde reformulação do plano até mesmo a criação de um novo plano de negócios para umanova ideia.

∙ O plano de negócios é um mapa para guiar o empreendedor, é como uma bússolae os objetivos são o Norte, por meio dele você sabe como chegar lá, mas não está preso a

17

um único sentido, onde mudanças de caminho podem ser propositais para que obstáculossejam vencidos ou evitados.

∙ Por meio do plano de negócios é possível diminuir consideravelmente os riscose incerteza sobre o negócio. Como já visto nos motivos anteriores, ao elaborar um planode negócios o empreendedor consegue identificar a viabilidade do seu negócio e por meiodisso criar ações preventivas contra possíveis obstáculos que irá enfrentar.

∙ Por meio dele é possível analisar a fundo o mercado e os potenciais clientes, evitaesforços desnecessários, investimentos improdutivos e gastos sem sentido.

∙ É um documento importantíssimo para analisar as necessidades iniciais do ne-gócio, como recursos e investimento.

∙ Pensando de maneira ágil, a documentação criada para o plano de negócios deveser ajustável e moldável conforme as novas exigências do próprio negócio e as constantesmudanças do mercado.

2.1.3 Etapa 1: Elaboração do Plano de Negócios

Nesta etapa será realizado alguns passos importantes do desenvolvimento do planode negócio.

2.1.3.1 Sumário Executivo

O sumario executivo é a parte mais significativo do plano de negócios, pois épor meio dele que será fornecido informações e detalhes minuciosos sobre o negócio. Emoutras palavras pode-se dizer ser o resumo do plano de negócios. Por isso, é de extremaimportância a realização de um sumário executivo bem elaborado. De acordo com [1, 6],no sumário executivo irá constar:

∙ Resumo dos principais pontos do plano de negócio.

∙ Dados dos empreendedores, experiência profissional e atribuições.

∙ Dados do empreendimento ou do produto de software.

∙ Missão da empresa.

∙ Setores de atividades.

∙ Forma jurídica.

∙ Enquadramento tributário.

∙ Capital social.

∙ Fonte de recursos.

Alguns destes temas serão abordados mais a fundo futuramente no projeto.

18

2.1.3.2 Análise de Mercado

A análise de mercado tem como objetivo adquirir informações sobre o mercado deatuação do seu produto de software, além de verificar pontos fortes e fracos que podemimpactar diretamente no sucesso ou fracasso do empreendedor.

Através desta análise, obtemos dados importantíssimos sobre como deverá ser aatuação no mercado. As definições então se baseiam em alguns aspectos que deve-seanalisar, como por exemplo: quais as estratégias para alcançar o público-alvo, como seráa participação dos fornecedores e finalmente como conquistar um espaço competitivo nomercado para enfrentar a concorrência [7].

Em outras palavras, a análise de mercado é uma etapa essencial para o surgimentodo negócio, pois é ela que determinará os caminhos que deverão ser tomados. Através delaé possível entender as atividades que merecem atenção e que, de fato, poderão tornar onegócio um sucesso.

É essencial que o empreendedor acredite no potencial do seu produto, porém, tãoimportante quanto isso, é ter a certeza do valor do seu negócio. Portanto é necessárioanalisar se de fato, as pessoas comprarão este produto [8].

2.1.3.3 Plano de Marketing

Após a criação do sumário executivo, é alcançada uma nova etapa do processo deelaboração do plano de negócios, a etapa da criação do plano de marketing, mais detalhesdeste processo será abordado a seguir.

O plano de marketing é a etapa de planejamento das ações publicitárias que serãotomadas para impulsionar o negócio, independentemente de quais forem os objetivos oempreendedor tem que estar preparados para alcançá-los, como por exemplo: alcançarum público alvo, atrair fornecedores ou clientes, movimentar vendas ou simplesmentepromover um produto ou serviço. Em todo caso, o plano de marketing definirá as açõesestratégicas do negócio, em especial da marca [9, 10].

Empresas muitas vezes investem pesado em suas ações publicitárias, pois reconhe-cem a importância das mesmas, um dos principais motivos está em se manter competitivono mercado, algumas vezes ainda considerando o plano de marketing como ferramenta degestão. Através de boas estratégias de marketing é possível alavancar um negócio de umdia para o outro, mas para isso é muito importante que o empreendedor conheça bem omercado de atuação, pois, se é de seu conhecimento os pontos fortes e fracos, ficará muitomais fácil desenvolver um bom plano de marketing [9, 10].

Bom primeiramente defina seus objetivos, pois todas as decisões tomadas na ela-boração do plano de marketing irão influenciar diretamente seus resultados, é possívelpensar grande mas é crucial executar com cautela, então estude o mercado, veja sua

19

situação atual, busque os meios de divulgação conforme o público que deseja atingir [9].

Se todos os passos forem bem executados o seu crescimento de mercado se tornaráconsequência, o seu público aumentará, o seu produto circulará e uma hora ou outra,quem sabe, o seu negócio e dinheiro trabalhem sozinhos para você.

2.1.3.4 Plano Operacional

O plano operacional é a etapa onde são descritas as tarefas que serão realizadaspela equipe de colaboradores, buscando assim gerar resultados em pequenos períodos detempo e visando sempre os objetivos do negócio [11].

Em palavras mais simples, o plano operacional será o guia sobre o que fazer e comofazer, como por exemplo, cuidar das atividades de rotina da empresa, assegurando que ospapéis de cada membro da equipe sejam realizados com sucesso, sempre de acordo comas políticas e conformidades.

Destaca-se também que o plano operacional pode: identificar recursos necessáriospara a manutenção do negócio, direcionar as atividades para determinados setores da em-presa, dividir as tarefas da equipe definindo as responsabilidades e os responsáveis sobreas mesmas. Desta maneira maximizando os resultados do negócio[11].

Figura 1 – Exemplo genérico do Plano de Negócios. Fonte: venturycapital.com

20

2.2 Metodologias Ágeis

2.2.1 Definição

Atualmente estar na gestão de um projeto é um grande desafio, pois conforme omercado vai mudando as necessidades dos clientes também vão, e atender estas demandasdos clientes de forma dinâmica, flexível e com alta produtividade costuma ser um problemamuitas vezes difícil de resolver.

A metodologia Ágil ou Agile, como o próprio nome sugere, surgiu então como umasolução alternativa para enfrentar os desafios encontrados no desenvolvimento de softwareque se utilizam de técnicas de gestão dos modelos tradicionais. Existem diferentes tiposde métodos ágeis, para este trabalho em questão será abordado a fundo 1 deles: o Scrum,nos próximos capítulos será possível entender mais sobre este método [12].

No modelo ágil o gerenciamento de projetos é realizado de uma forma altamentedinâmica, com uma abordagem iterativa, onde todo o desenvolvimento é realizado emetapas de curto prazo que passam por analises e se obtém um feedback, para que caso sejanecessário os devidos ajustes possam ser realizados. Diferentemente da metodologia tra-dicional, pela qual todo o desenvolvimento é documentado ainda na fase de planejamento[13].

2.2.2 Manifesto Ágil

As metodologias ágeis são abordagens para o desenvolvimento de produtos que es-tão alinhadas com os valores e princípios descritos no Manifesto Ágil para desenvolvimentode software, assinado em 2001 em Utah [14].

Nesse evento participaram 17 desenvolvedores, que ao verificarem as dificuldadespelas quais os desenvolvedores de sistemas passavam, se reuniram para discutirem ospilares do desenvolvimento de software, e que apesar de estarem testando abordagense métodos diferentes, compartilhavam dos mesmos fundamentos, descrevendo assim oManifesto [14].

O Manifesto é um documento que reuniu as diferentes visões desses profissionaisacerca dos processos de desenvolvimento de software e condensou esses valores em 4, alémde criar 12 princípios a serem seguidos.

No Manifesto existem frases que determinam a importância de algumas coisas emrelação a outras, essas frases são dispostas no formato A mais que B, de modo a tornarclaro o que é prioritário. Vale ressaltar que independentemente das frases dizer que Amais que B não significa que o B seja totalmente irrelevante, porém que o A deve serconsiderado primeiro.

Vamos aos 4 valores, e 12 princípios descritos no Manifesto Ágil para desenvolvi-

21

mento de software.

Valores:

∙ Indivíduos e Interações 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.

Princípios:

∙ A satisfação do cliente por meio de entrega contínua de software deve ser priorizada;

∙ O aceite de mudança de requisitos pode ser realizado para garantir os requisitos docliente;

∙ Entregas constantes de software devem ser realizadas;

∙ Deve existir cooperação diária entre os desenvolvedores e quem tem conhecimentoacerca do negócio;

∙ Manter os indivíduos motivados e confiantes é necessário para que os projetos pos-sam ser realizados com excelência;

∙ A comunicação deve ser direta;

∙ Um sistema funcionando é a única maneira de medir o progresso;

∙ Ambientes sustentáveis são promovidos por meio de projetos ágeis;

∙ Manter atenção sobre a técnica e design aumenta a agilidade;

∙ Manter a simplicidade é fundamental;

∙ Arquitetura, projetos e requisitos de excelência surgem de times auto organizados;

∙ Buscar a realização de reuniões constantes entre a equipe para encontrar meios dese tornarem mais efetivos.

22

2.2.3 Metodologia Tradicional

A metodologia tradicional, também conhecida como "orientada a documentação",são modelos que possuem uma documentação pré-estabelecida para o desenvolvimento desoftwares. O modelo foi proposto por Royce em 1970, que na época identificou que o custopara se realizar alterações e correções nos códigos era exorbitante, uma vez que o acessoas maquinas era limitados e não existia ferramentas modernas que poderiam ser usadascomo apoio ao desenvolvimento de software. Por este motivo então que antes do softwareser implementado ele era todo planejado e então documentado, sendo considerado assimum modelo mais "rígido"[15, 13].

Atualmente ainda são utilizadas em diversos projetos, mas está aceitação se da pelofato de ser um modelo orientado a documentação, podendo variar em diferentes formatos,como por exemplo: textos, representações gráficas, diagramas, entre outras. No modelotradicional o software é construído em uma sequencia de etapas, sendo que uma dependeda conclusão da anterior, com exceção da primeira, assim como representado na figura 2pelo modelo Cascata [15, 13].

Figura 2 – Ilustração Modelo Tradicional. Fonte: http://alexpagernet.blogspot.com

Assim que finalizada a primeira etapa, onde é feita a análise, então é iniciada afase de Projeto, e assim consecutivamente, sempre que uma etapa chega ao fim a pró-xima é iniciada, mas nunca antes da anterior finalizar. Em outras palavras a evolução dodesenvolvimento se dá de maneira sequencial.

23

2.2.4 Metodologia Ágil

A metodologia ágil surgiu como solução para diversos problemas que desenvolve-dores encontravam no modelo tradicional, dentre eles a diminuição drástica dos custos eriscos do desenvolvimento de software.

Entre as metodologias ágeis está o famoso Scrum, que hoje é mundialmente reco-nhecido pelas empresas de tecnologia, e muito utilizado, pois sua forma de implantaçãoé simples e facilita diversos processos no desenvolvimento. Devido a estas características,muitas empresas o utilizam para controlar e gerenciar as etapas de desenvolvimentos maiscomplexos, tendo como objetivo agregar valor ao cliente [16].

A forma como é empregada é reconhecida como desenvolvimento cíclico, os chama-dos Sprints, que possuem duração de até 4 semanas. Apesar do alto grau de flexibilidadeno desenvolvimento ágil, é importante que mudanças desnecessárias sejam desconsidera-das a partir do momento que afetam o objetivo do Sprint, portanto a modificação sempredeve ser discutida pelo PO e o Dev Team antes de serem realizadas [17].

Em um ambiente de desenvolvimento que utiliza o Scrum como metodologia ágil,existem equipes que geralmente são compostas por até 10 pessoas para que haja ummelhor gerenciamento e organização do projeto, associado a equipe ainda temos: papéis,eventos e artefatos. Destacarei separadamente cada um deles nos baseando em [18, 17],porém é no tópico do Scrum que nos aprofundaremos no assunto:

∙ Papéis: em uma equipe ágil, os membros são classificados em três papéis diferentes,sendo eles:

- Product Owner: é o ponto central com poderes de liderança sobre o produto, ele éo responsável por definir quais as funcionalidades e recursos que serão desenvolvidose qual a ordem que eles devem ser realizados, maximizando o valor do produto parao cliente.

- Scrum Master: é conhecido como facilitador, seu papel é ajudar a todos osmembros do time à entenderem os valores, princípios e práticas do Scrum. Suaparticipação é como a de um coach, ajudando na liderança do processo, porém oScrum Master não é chefe de ninguém.

- Dev Team: são os profissionais que desenvolverão no projeto, no Scrum quemdecide como fazer as coisas é o time. A principal ideia é que o time se auto-organizepara chegar ao objetivo e atender a meta estabelecida pelo PO.

∙ Eventos: no total são definidas cinco cerimônias:

- Sprint Planning: antes da Sprint começar, é realizada uma reunião de pla-nejamento dos Sprints, também chamada de Sprint Planning, onde são definidasquais serão as funcionalidades que irão compor o backlog da Sprint, tomando como

24

base a capacidade e velocidade do time para desenvolve-las. Ao final das definiçõesdas funcionalidades que entram na Sprint, cabe ao Dev Team decidir como serãorealizadas e quem ficara com determinadas tarefas.

- Sprint Execution: neste evento ocorrerá a execução do Sprint, inicialmente como backlog já definido por prioridade, são selecionadas e iniciadas as funcionalidadesque estão propostas para o Sprint, ao seu termino é esperado que uma parte do pro-duto seja entregue, desta forma agregando valor do produto ao cliente. Conformea execução das funcionalidades vão sendo realizadas o PO pode identificar necessi-dades de mudanças, caso isso ocorra a mudança identificada deve ser adicionada aoProduct backlog conforme sua prioridade. Este processo se repete até que o produtocomo um todo esteja finalizado.

- Daily Scrum: é uma reunião que ocorre diariamente e que possui pouco tempode duração, com máximo de 15 minutos, onde todo o time participa informandocomo está o desenvolvimento, deixando assim todos informados sobre o progressodo Sprint. Estas reuniões são marcadas por 3 perguntas que todos os membros dotime devem responder, sendo elas: o que você fez ontem? o que vai fazer hoje? temalgum impedimento que o impede de progredir?

- Sprint Review Meeting: neste evento o Scrum Team se reúne para analisar seo que está sendo feito está correspondendo com as expectativas esperadas, por meiodo Sprint Review o time verifica como está sendo o andamento do Sprint. É nesteevento que ocorrem as mudanças e o Product backlog é atualizado.

- Sprint Retrospective: nesta etapa o Scrum Team analisa como foi o andamentodo Sprint, seus pontos fortes e fracos, o que deve ser melhorado e o que deve serdescontinuado. Na retrospectiva do Sprint todos devem analisar como foi o decorrerdo desenvolvimento e se necessário se reorganizar para os próximos Sprints.

∙ Artefatos: é possível destacar 2 principais artefatos que utilizaremos:

- Product backlog: o Product backlog são todas as funcionalidades que deverão serdesenvolvidas. O PO com o auxílio do Scrum Master, organiza estas funcionalidadespor ordem de prioridade, vale destacar que a prioridade é proporcional ao valor queela agregará ao produto.

- Sprint backlog: no Sprint backlog está inserido um grupo de funcionalidadesque serão desenvolvidas no tempo do Sprint, lembrando que este tempo é de nomáximo 4 semanas, também conhecido como time-boxed e que as funcionalidadesestão ordenadas por prioridade.

25

Figura 3 – Ciclo do Desenvolvimento Ágil. Fonte: http://metodologiaagil.com

2.2.5 Metodologi Ágil x Tradicional

Agora que sabe-se sobre ambas as metodologias, destaca-se as principais diferençasentre si, a partir de [15, 13] é possível identificar algumas delas, sendo estas:

2.2.5.1 Orientação

∙ Tradicional: Orientado por atividade e centrado em processo.

∙ Ágil: Orientado por produtos e centrado em pessoas.

2.2.5.2 Projetos

∙ Tradicional: Projetos estáveis e com baixo ou nenhum tipo de mudança.

∙ Ágil: Projetos Dinâmicos, com mudanças constantes e desenvolvimento ágil.

26

2.2.5.3 Tipo de Garantia de Confiança

∙ Tradicional: A documentação é a garantia de confiança do projeto.

∙ Ágil: A comunicação é a garantia de confiança do projeto.

2.2.5.4 Gerente de Projeto

∙ Tradicional: Possui controle total do projeto.

∙ Ágil: Possui papel de facilitador, sempre ajudando e coordenando o time.

2.2.5.5 Time de Desenvolvedores

∙ Tradicional: Cada membro possui participação no projeto com papéis claros e bemdefinidos.

∙ Ágil: A equipe como um todo possui participações colaborativas em todas as ati-vidades do projeto.

2.2.5.6 Participação do Cliente

∙ Tradicional: O cliente participa apenas das fases iniciais no levantamento de re-quisitos e na fase final para validação do produto entregue.

∙ Ágil: A participação do cliente é essencial em todo o decorrer do desenvolvimento.Deve ser considerado como parte integrante do time, interagindo junto aos desen-volvedores e ao gerente de projeto para agregar valor nas entregas dos Sprints.

2.2.5.7 Abordagem (Figura 4)

∙ Tradicional: A abordagem é feita de forma preditiva, rígida e burocrática.

∙ Ágil: A abordagem é feita de forma Adaptativa, flexível e simplista.

27

Figura 4 – Diferenças entre Metodlogias Ágeis x Tradicional. Fonte: slideplayer.com.br

2.3 Scrum

Nesta seção será abordado o que é e para que serve o Scrum.

2.3.1 Definição

Em nosso desenvolvimento do plano de negócios utilizaremos o Scrum como sendoo alicerce para sua elaboração.

O Scrum é uma metodologia ágil, muito conhecida e utilizada em diversas em-presas, projetos e negócios, por ser uma forma altamente eficiente quando falamos dedesenvolvimento dinâmico [19].

Possui grande destaque no mercado, principalmente em empresas de desenvolvi-mento de software, por ser relativamente simples de implementar e por contornar desafiosencontrados pelos times de desenvolvimento [16].

Entre suas principais características, é possível destacar: desenvolvimento de quali-dade, interação cliente/time de desenvolvedores, entregas incrementais que agregam valorao produto, desenvolvimento dinâmico e trabalho em equipe, concentrando-se principal-mente no gerenciamento de tarefas [19, 17].

No desenvolvimento de software baseado no Scrum, destaca-se três principais ní-veis: Release Planning, Sprint Planning e Product. Através deles então, é formulado umalista com funcionalidades ordenadas por prioridade, essa etapa então que definirá o queserá o nosso produto, conhecida como Product backlog [19].

28

O Product backlog, possuirá em ordem de prioridade as funcionalidades do produtoou negócio, que por sua vez é dividido em subconjuntos pelo qual é conhecido por Release,que serão entregas “parceladas” de todo o produto, estes Realeases ainda são mais umavez particionados, sendo estas partições conhecidas como Sprints, que são a entrega dealgumas funcionalidades em um curto prazo de tempo e que vão agregando valor aoproduto, estas etapas sempre que finalizadas passam por um feedback, podendo ser dadopela equipe de desenvolvimento, por gestores ou pelo próprio cliente [19, 17].

Um ponto importantíssimo do Scrum, é que devido sua autonomia e entregasincrementais, possíveis ajustes que venham a aparecer podem ser realizados com muitafacilidade em Sprints futuros, destacando que isto ocorre sem prejudicar o andamento doprojeto.

Outro ponto interessante do Scrum, são as reuniões diárias, as chamadas DailyScrum, onde toda a equipe participa, destacando o desenvolvimento individual de cadaum, expondo desafios e inteirando todos de como está indo o andamento do projeto.

Vale ressaltar que no desenvolvimento ágil Scrum, cada membro do time possuifunções dinâmicas, isso não significa que não exista responsabilidades individuais, mas quetodos são livres para trocar informações, se ajudar, compartilhar conhecimento e resolverproblemas comuns. A participação do time é quase total, podendo partir de tomadas dedecisões no projeto até reorganização de tarefas, estas muitas vezes decididas nas reuniõesdiarias onde analisam como esta o decorrer do Sprint [16].

Um papel importantíssimo é o do Scrum Master, o líder do projeto, possui afunção de facilitador, intermediando muitas vezes o contato do time. É o Scrum Masterque muitas vezes fornece as informações técnicas para o time e ainda é responsável porsanar todas as duvidas que impedem o progresso no desenvolvimento. Apesar dele possuirum cargo de liderança ele não é chefe de ninguém.

O time é composto, basicamente, em três papeis distintos, sendo eles: o ScrumMaster (como já visto, líder de projeto), o Product Owner (representa o cliente no time)e o Dev Team (equipe de desenvolvimento).

2.3.2 Funcionamento

Nesta seção será abordado o funcionamento do Scrum na prática, destacando opasso a passo de cada elemento necessário para o seu desenvolvimento. Identificando ospapéis fundamentais da metodologia, a criação do Product backlog, o planejamento dosSprints, os eventos e artefatos gerados [20].

29

2.3.2.1 Escolha o Product Owner

Antes de mais nada deve-se definir quem será o PO do projeto, esta escolha éimportantissima pois o PO deve representar o cliente na comunicação com a equipe. Paraassumir tal responsabilidade o PO deve possuir amplo conhecimento do negócio e precisaentender as demandas do cliente. Em outras palavras o PO será a ponte entre o cliente eo Dev Team.

2.3.2.2 Escolha o Scrum Master

Para assumir uma posição de Scrum Master no time é necessario que goste detrabalhar com equipe, além de precisar cohecer muito bem os principios e praticas doScrum, pois o Scrum Master terá como responsabilidade passar estes valores para a equipe.

Portanto a caracteristica de liderança é impressidivel, assim que reconhecido estascaracteristicas será escolhido o Scrum Master, que atuará como facilitador em meio aotime, buscando orientar e solucionar possíveis problemas que estejam comprometendo oprogresso do projeto.

2.3.2.3 Defina a Equipe

Um dos principais pontos do Scrum é a definição do Dev Team, pois é por meiodele que o negócio ganhará vida, e isso determinará seu sucesso ou fracasso.

O Dev Team participa de praticamente todas as etapas do Scrum, desde tomadasde decisões simples à criação de estratégias mais complexas, ou seja, o time possui papelfundamenta nos rumos tomados pelo projeto. As habilidades, características e experienciasde cada membro é de extrema importância para que as metas estabelecidas pelo PO sejamalcançadas.

Esta diversidade no time é muito interessante, pois, somadas todas as experienciasindividuais, conseguimos um time muito mais preparado para enfrentar os desafios quesurgirão no meio do caminho. Mas para isso acontecer, vale ressaltar a importância de quetodos os membros possuam ao menos o mínimo conhecimento necessário para garantir aentrega das metas estabelecidas pelo PO.

Outro ponto importante para o Dev Team é a união dos integrantes, podemoscomparar isso a um time de futebol, ou seja, o sucesso de um é o sucesso de todos, assimcomo, o fracasso de um, também é o fracasso de todos. É necessário que o time estejaunido para aprimorar o entrosamento, e conforme vão passando pelos desafios juntos, asmetas estabelecidas pelo PO tendem a ser alcançadas mais facilmente.

Além da diversidade entre os membros do time, outra característica importante éo tamanho da equipe, geralmente composta de 3 a 10 pessoas no máximo, isso porque setorna fácil o autogerenciamento.

30

2.3.2.4 Criação do Product Backlog

O Product backlog é uma lista onde são adicionadas todas as funcionalidades quedeverão ser desenvolvidas para a conclusão do projeto. Estas funcionalidades são ordenaspor prioridade, e isto representa diretamente o valor de cada uma delas no projeto, ouseja, quanto maior a prioridade maior o valor agregado ao negócio [19, 17].

O responsável por desenvolver o Product backlog é o PO, que como já citado é elequem representa o cliente na equipe, desta forma é importantíssimo que as funcionalidadesatendam as demandas exigidas pelo cliente. O Scrum Master atuando como um coach,pode auxiliar o PO nesta tarefa, para garantir a produtividade do Dev Team.

2.3.2.5 Planejamento e desenvolvimento do Product Backlog

Chegou a hora do time se organizar para desenvolver as funcionalidades estabele-cidas pelo PO, a responsabilidade da entrega destas funcionalidades é de toda a equipe.Portanto é realizada uma reunião, onde são definidas estimativas para a realização de cadafuncionalidade do projeto, informando qual a dificuldade do desenvolvimento de cada umadelas.

Reconhecer se uma funcionalidade é possível de ser desenvolvida é algo extrema-mente importante, pois uma vez que dito ser possível, voltar a trás poderá dar uma grandedor de cabeça. Por isso que cada funcionalidade deve estar detalhada o máximo possível,para desta forma o time poder analisar com maior precisão o tempo de desenvolvimentoda mesma, ou simplesmente concluir que ainda não possuem as informações suficientespara desenvolve-las[16, 17].

Existem diferentes maneiras de estimar o tempo gasto para desenvolver cada funci-onalidade, pode ser baseando-se na opinião de cada membro da equipe, classificando cadafuncionalidade com grau de dificuldade (fácil, moderado ou difícil) ou ainda basendo-seem produtividades anteriores. É necessário que a equipe entre em comum acordo paraque as estimativas sejam concluidas.

2.3.2.6 Planejamento do Sprint

Com todas as funcionalidades devidamente identificadas, ordenadas por prioridadee com tempo de desenvolvimento estimado, é possível passar assim para a nossa próximaetapa, o planejamento do Sprint. Está tarefa e realizada pelo PO e pelo Scrum Master,que identificam quais as funcionalidades podem ser entregues no prazo do Sprint, que temduração de até 4 semanas, este processo é conhecido como Sprint Planning.

No Sprint Planning são definida as responsabilidades de cada membro da equipe,visto que já analisaram a dificuldade de cada funcionalidade e de que reconhecem possíveisdesafios que irão enfrentar para desenvolve-las.

31

Vale lembrar que o que está definido no Sprint Planning não necessariamente deveser seguido a risca, uma vez que o desenvolvimento ágil permite aos desenvolvedores reali-zar melhorias ao identificar problemáticas, desde que não seja modificações insignificantese desnecessárias.

2.3.2.7 Acompanhando a evolução do Projeto

É muito interessante que a equipe possua um acompanhamento do andamento doprojeto de forma visual, esta técnica é característica do desenvolvimento ágil e é muitoutilizada nos dias de hoje, pois através dela a equipe consegue ver o que está sendodesenvolvido, o que já foi finalizado e oque falta ser desenvolvido.

2.3.2.8 Reuniões diárias

Outra maneira muito importante de acompanhamento do desenvolvimento do pro-jeto são as reuniões diárias, também chamadas de Daily Scrum, na qual toda a equipeparticipa, e cada membro responde a três perguntas essenciais: - O que você fez ontempara ajudar o time a atingir a meta do Sprint? - O que você vai fazer hoje para ajudar otime a atingir a meta do Sprint? - Existe algum impedimento que me impeça de atingira meta do Sprint?

Estas reuniões geralmente são feitas de pé, por se tratarem de reuniões que devemser realizadas rapidamente, com duração de no máximo 15 minutos, e servem para iden-tificar impedimentos no desenvolvimento, caso isso ocorra o Scrum Master entra em açãoe é responsável por buscar uma solução para o problema [19].

2.3.2.9 Sprint Review (entrega parcial do produto)

Ao final de cada Sprint é realizado uma reunião de analise de tudo o que foifeito no decorrer do Sprint, esta analise é chamada de Sprint Review. Nesta reunião otime apresenta tudo o que foi desenvolvido e aponta os problemas enfrentados durante oSprint, para desta forma buscarem uma solução ou adaptação para as problemáticas.

Nesta etapa deve ser apresentada uma parte funcional do projeto, desta maneiracumprindo com o papel do Scrum e agregando valor ao produto, nesta reunião todosdevem estar presentes, incluindo o cliente.

2.3.2.10 Retrospectivas dos Sprints

Ao final do Sprint e após a entrega parcial do produto, é realizada uma reuniãocom toda a equipe, agora sem o cliente, para apontar o que deu certo e o que não deu tãocerto assim, e que poderia ser melhorado [19, 16].

32

Melhorando desta forma a postura do time em relação a alguns pontos deficitários,e se organizando para utilizar o que foi aprendido com o Sprint passado nos próximosSprints.

Esta reunião não é feita para apontar culpados, mas para analisar o que não foibom para o projeto e aprender com os erros, consequentemente isso acarretará na melhorada qualidade das futuras entregas.

Figura 5 – Ciclo do Scrum. Fonte: https://www.youtube.com/watch?v=vg1S1WYZa6o

2.3.3 Como integrar o Scrum à um plano de negócios

Finalmente podemos nos aprofundar rapidamente no conteúdo deste trabalho, paraentender "como integrar o Scrum à um plano de negócios".

O plano de Negócios é algo de extrema importância para que uma empresa possase tornar competitiva, possuir estrategias de marketing, reconhecer o público alvo, analisaro mercado, estudar os concorrentes e se preparar para possiveis obstaculos e dificuldadesque irá encontrar no caminho.

No Capítulo 3 será analisado cada etapa da elaboração do plano de negócioscomo citados a cima seguindo os fundamentos do Scrum citados na seção 2.3.2.

33

3 ELABORAÇÃO DO PLANO DE NEGÓCIOS DE PRODU-TOS DE SOFTWARE UTILIZANDO O SCRUM

Esta é a etapa do desenvolvimento do plano de negócios de produtos de software,onde o principal objetivo é realizar um desenvolvimento de forma organizada e ágil, fa-zendo com que os empreendedores/desenvolvedores assumam os papéis fundamentais doScrum e criando o ambiente ágil através das Sprints, dos Releases e reuniões caracterís-ticas da metodologia.

3.1 Equipe de Desenvolvedores

Neste Capítulo será abordada uma parte importantíssima para o desenvolvimentodo plano de negócio, pois nele são definidos os papéis dos desenvolvedores (ou também,empreendedores) envolvidos, delegando responsabilidades para cada um e criando assimo que buscamos: o ambiente ágil do Scrum.

Primeiramente é preciso conhecer muito bem o time, as características de cadaum, as qualidades, os defeitos, a comunicação, o temperamento, pois isso tudo mostraráem qual dos papéis cada um melhor se encaixa.

Seguindo o passo a passo do desenvolvimento do plano de negócios utilizando oScrum, é necessário criar uma situação hipotética, a partir de agora será assumido queexiste uma equipe de no mínimo 3 desenvolvedores, cada um com suas característicasparticulares, e baseando nesta premissa é possível seguir para a definição de papéis.

É importante destacar que será assumido uma equipe de no mínimo 3 pessoas,porém isso não é regra, pois independente de qual for a quantidade de desenvolvedoresenvolvidos, o desenvolvimento do plano de negócios para o produto de software se mantém,sendo possível um desenvolvedor assumir um ou mais papéis fundamentais do Scrum.

3.1.1 Definindo Papéis

Nesta etapa do planejamento do plano de negócios serão definidos os papéis paraos empreendedores, é importante lembrar que no Scrum o PO não pode assumir outrospapéis, porém não existe restrições para o modelo, pois de acordo com o Serasa Experianmilhares de negócios criados no Brasil e no mundo, são de empreendedores individuais,ou seja, sem sociedade.

Portanto, o empreendedor poderá assumir um ou mais papéis fundamentais doScrum, é necessário analisar todos os papéis individualmente mas isso não restringe oempreendedor a apenas um deles.

34

3.1.1.1 Product Owner

Como nós já vimos na seção 2.3.2.2, o Product Owner é quem representa o clienteno projeto, neste modelo o cliente são os próprios empreendedores, ou seja, o PO deveráatender aos seus próprios requisitos e aos dos sócios.

Portanto é importante que o empreendedor que assumir esta responsabilidade pos-sua amplo conhecimento do negócio, além de algumas características essenciais, como porexemplo: capacidade de gerenciar, boa comunicação, deve ser visionário para enxergarboas melhorias no projeto, entre outras características de gestão.

3.1.1.2 Scrum Master

O Scrum Master é um ponto chave para este modelo, pois como foi visto na seção2.1 o mercado é inconstante, as coisas mudam muito rapidamente e as necessidades devemser atendidas no mesmo ritmo. Portanto o empreendedor deve ser ágil, saber reconheceros desafios rapidamente significa tomar atitudes rápidas para solucioná-los e acima detudo deve gostar de trabalhar com pessoas.

Em [21] SILVA, F.A.da, criador da Wise Up, destaca que é necessário que o em-preendedor reconheça o valor das pessoas ao seu redor, independente de quem ela seja ouo cargo que ele irá assumir na sua empresa, pois se conseguir compreender que nada secria sózinho, as coisas acontecem. É neste perfil de empreendedor que o Scrum Master seencaixa.

3.1.1.3 Equipe (Dev Team)

O Dev Team, ou time de desenvolvimento, são os empreendedores responsáveis portransformar os requisitos estabelecidos pelo PO no plano de negócios, é através deles queo principal objetivo deste modelo se concretiza, assim como os desenvolvedores que porventura tenham assumido os papéis de PO e Scrum Master o Dev Team precisa possuiramplo conhecimento do mercado de atuação, pois eles devem ser capazes de identificarfalhas no plano de negócios e proporem melhorias.

Contando com o auxilio do Scrum Master o Dev Team ao identificar estas falhas,deve buscar boas soluções para o problema, podendo chegar ao ponto de ter que repensara estratégia que tomarão para a parte do plano de negócios em questão.

Vale ressaltar que os empreendedores que formam o Dev Team muitas vezes sãopessoas com experiencias profissionais distintas, que ao juntarem o conhecimento sãocapazes de elaborar um plano de negócios consistente e estratégico para se manter fortena briga por mercado.

35

3.2 Estudando o Product Backlog de um Produto de Software

Quando se fala em elaboração de um plano de negócio para um produto de softwarea primeira coisa que deve ser pensada é: qual é o meu produto? Pois tudo o que seráorganizado, planejado e executado se originará através desta resposta.

Esta pergunta determinará quais rumos o planejamento deverá tomar, quais as es-tratégias comerciais serão necessárias elaborar, qual o público-alvo, qual o nível de escala-bilidade do produto, como será realizado o marketing, quais serão as projeções financeiras,entre tantos outros questionamentos que serão definidos no decorrer do planejamento donosso plano de negócio.

Assim que respondida a pergunta, o Product Owner entra em ação, definindo osrequisitos necessários para a elaboração do negócio. É então que as funcionalidades vãosendo classificadas com o grau de prioridade e as metas vão sendo estabelecidas.

3.2.1 Informações Sobre o Negócio

Após identificado o produto, é extremamente importante que o time de desen-volvedores passe a estudar mais afundo sobre o negócio. A busca de conhecimento einformações sobre o mercado que irão atuar, poderá definir o sucesso ou fracasso do ne-gócio, pois um time despreparado não saberá como agir frente aos inúmeros desafios quetodo empreendimento esta sujeito a enfrentar.

Existem diversos pontos a serem estudados e planejados, alguns destes serão clas-sificados pelo PO no Product backlog com auto grau de prioridade, outros por sua vezreceberão prioridades menores, e isso determina o que o Dev Team com auxílio do ScrumMaster deverão se preocupar primeiro. Dentre estes pontos destaca-se 3, sendo eles: análisede mercado, estratégias de comercialização e marketing e projeções financeiras.

∙ Participação do time:

- Product Owner: estudar o negócio, retirar informações relevantes, identificarfuncionalidades e classificá-las por prioridade.

- Scrum Master: estudar o negócio, realizar uma analise de possíveis desafios ecaso identificados, buscar soluções para os mesmos.

- Dev Team: estudar o negócio.

3.2.2 Analise do Mercado

Enquanto ocorre o processo de obtenção de informações sobre o negócio, um dosprincipais pontos a serem analisados é o mercado de atuação, bem como os fatores quepodem impactar diretamente no sucesso ou fracasso do negócio.

36

Uma análise minuciosa do mercado fornece informações importantes como porexemplo: o potencial da escalabilidade do produto de software, assim como do público-alvo, a taxa participativa dos fornecedores, e ainda, o posicionamento da concorrência.Desta forma é possível destacar e priorizar atividades que são capazes de alavancar onegócio e torná-lo um sucesso.

Um ponto importante resultante da análise de mercado é a possibilidade de criarestratégias de comercialização e marketing, esta etapa será analisada mais a fundo nopróximo tópico, porém alguns pontos estão ligados diretamente ao estudo do mercado,como por exemplo: qual será o valor do produto, como será oferecido este produto, se osoftware ou o produto de software possui demanda, qual público-alvo, quais os meios depublicidade explorar, entre diversos outros pontos que permitem o produto seja colocadoem posição de destaque no mercado.

Vale ressaltar que a análise de mercado deve ser realizada constantemente e nãosomente para a elaboração do plano de negócio, pois o mercado como já vimos é incons-tante, a mudança do cenário ocorre rapidamente, fazendo com que os empreendedoresfiquem atentos aos autos e baixos do mercado.

∙ Participação do time:

- Product Owner: estudar o mercado, analisar e destacar pontos importantes,identificar funcionalidades e classificá-las por prioridade.

- Scrum Master: estudar o mercado, realizar uma analise de possíveis desafiosfinanceiros, como: taxa participativa dos fornecedores, potencial de escalabilidadedo produto, atuação da concorrência, entres outros; e com isso auxiliar o PO comas priorizações das funcionalidades.

- Dev Team: estudar o mercado e ajudar o Scrum Master a buscar soluções paraos desafios identificados por ele.

3.2.3 Estratégias de Comercialização e Marketing

Assim que realizada uma análise de mercado, a próxima etapa é a preparação deestratégias de comercialização e marketing. Se preocupar com esta etapa no desenvolvi-mento do plano de negócio é essencial, pois é por meio dela que o produto será lançadono mercado, este ponto será determinante para o sucesso do negócio.

É importante lembrar que não adianta possuir um produto de alta qualidade senão possuirmos um bom planejamento de marketing que seja capaz de alcançar os con-sumidores.

Boas estratégias de marketing, podem determinar o sucesso de um negócio da noitepara o dia, basta conquistar os clientes de tal forma que eles pagariam pelo seu produto.

37

Nesta etapa da elaboração do plano de negócios estaremos trabalhando com o sentimentodas pessoas, com as necessidades e desejos, e isto deve ser usado a favor do negócio.

Na elaboração das estratégias de comercialização e marketing, todo o time deempreendedores deve conhecer bem o mercado, as necessidades dos clientes devem serpriorizadas pelo PO no Product backlog, pois todo este planejamento rodará em voltadestas necessidades. Vale ressaltar que quando se é tratado de clientes na elaboração doplano de negócios neste método, estamos falando do próprio time de desenvolvedores,incluindo o PO.

∙ Participação do time:

- Time: nesta etapa é importante que toda a equipe se reúna para realizar umaanalise sobre como alcançar o público consumidor e qual a melhor forma de fazerisso. Com isso, deverão realizar boas estratégias de comercialização e marketing.

- Product Owner: reconhecendo as necessidades e desejos dos clientes o PO devepriorizar as atividades necessárias para a execução das estratégias criadas pelo time.

- Scrum Master: identificar os desafios das estratégias de comercialização e mar-keting criadas pelo time, além de auxiliar o PO na priorização das atividades.

- Dev Team: buscar soluções para os desafios identificados pelo Scrum Master,respeitando as atividades priorizadas pelo PO.

3.2.4 Projeções Financeiras

Esta etapa é muito importante, as projeções financeiras, que são estimativas finan-ceiras a respeito do negócio, dentre elas é possível destacar: capital de giro, fluxo de caixae estimativa de resultados. Estes levantamentos são realizados hipoteticamente, uma vezque em muitos casos não existem resultados concretos.

Através da projeção financeira é possível ter uma visão muito próxima da real an-tecipadamente. Existem diversas vantagens de se realizar estas projeções antes de iniciaro negócio, pois por meio delas os empreendedores são capazes de aumentar a produti-vidade da empresa, consequentemente aumentando os lucros, além de reduzir as perdasfinanceiras. Vale destacar que a organização miniminiza a taxa de erros drasticamente.

O papel da equipe é conhecer muito bem o mercado de atuação, pois para seorganizar uma projeção financeira real é necessário que possuam todas as informaçõesque impactem diretamente no sistema financeiro do negócio. Dentre as projeções que otime deve se preocupar estão: projeção de entrada e saída de capital, projeção de despesasfixas, projeção do capital de giro, projeção de faturamento, entre outras.

38

Em [7] é possivel identificar algumas dicas importantes sobre como elaborar umaprojeção financeira. São dicas simples, mas que podem fazer toda a diferença nos resul-tados, sendo elas:

1 - Trabalhe com dados realistas:

É bom ser realista na hora de realizar sua projeção financeira. Nada é impossível,porém é preciso tomar cuidado, se preparar para crises também faz parte do negócio.

2 - Priorize o capital de giro:

O capital de giro é muito importante para financiar a continuidade das operaçõesdo negócio. Portanto é muito importante não esquecer de elaborar a projeção do capitalde giro, para desta forma evitar surpresas indesejadas.

3 - Elabore uma projeção de vendas e despesas:

Outra dica importante é a projeção das vendas e despesas do nosso produto desoftware, mesmo que ainda não possua resultados próprios, os empreendedores devem sequestionar sobre algumas coisas, como por exemplo: há comércio para o meu produto?Os meus ganhos abaterão minhas despesas? Terei lucro?

A resposta destas questões são determinantes, pois o retorno das vendas devemser capazes de manter o negócio vivo, independentemente das despesas.

∙ Participação do Time:

- Product Owner: com base nas informações obtidas na analise de mercado enas estrategias de marketing elaboradas pela equipe, o PO com o auxílio do ScrumMaster deve identificar projeções necessários e de forma estratégica classificá-las porprioridade.

- Scrum Master: o Scrum Master deverá agir como um coach, auxiliando o POna identificação das projeções necessárias para determinar os objetivos financeirosdo negócio, e também auxiliando o Dev Team na elaboração destas projeções.

- Dev Team: com a orientação do Scrum Master, o Dev Team irá elaborar todasas projeções determinadas pelo PO, respeitando sempre a prioridade das mesmas.

39

3.2.5 Product Backlog

Após ter passado por todas as etapas da seção 4.2 do método de desenvolvimentodo Product backlog, o PO estará altamente preparado para sair dos conceitos e passar paraa prática tudo o que foi devidamente levantado, organizado e priorizado.

O Product backlog, será uma lista extensa de funcionalidades devidamente priori-zadas, que por sua vez serão distribuídas nos Sprints. A junção de Sprints que podemser realizados em um determinado intervalo de tempo, irá compor os Releases, que sãoentregas de incrementos do produto prontos. Ao final da entrega de todos os Releases,o produto estará finalizado como um todo e vale lembrar que apesar do produto emdesenvolvimento neste trabalho ser um plano de negócios, isso se aplica a todo tipo deprojeto.

Figura 6 – Tabela de Organização do Product backlog. Fonte: Autor

40

3.2.6 Sprints

Assim que definido os Releases que o time deverá entregar, é iniciada então aanálise dos Sprints que os compõem, cada Sprint possui uma Lista de funcionalidades eestas por sua vez são ordenadas por prioridades, a estrutura de visualização irá ficar daseguinte forma:

Figura 7 – Tabela do Sprint. Fonte: Autor

No desenvolvimento do plano de negócios de produtos de software, existirão 4Sprints principais, também chamados de pilares, por serem essenciais em todos os planosde negócio, são eles: Sumário Executivo, Analise de Mercado, Plano de Marketing e PlanoOperacional.

Todos os Sprints poderão assumir N funcionalidades, ficando representativamentedesta forma:

- Sumário Executivo:

Figura 8 – Tabela representativa do Sprint: Sumário Executivo. Fonte: Autor

41

- Análise de Mercado:

Figura 9 – Tabela representativa do Sprint: Análise de Mercado. Fonte: Autor

- Plano de Marketing:

Figura 10 – Tabela representativa do Sprint: Plano de Marketing. Fonte: Autor

- Plano Operacional:

Figura 11 – Tabela representativa do Sprint: Plano Operacional. Fonte: Autor

3.3 Releases Planning

Releases Planning é o planejamento da entrega de um ou mais incrementos finali-zados do produto, no Scrum é frequente a realização de Releases, geralmente com duraçãode até 8 semanas cada. Os Releases são desenvolvidos pelo Dev Team, com o auxílio doScrum Master.

Os principais objetivos da realização dos Releases são: receber feedback nas entre-gas, gerar valor ao produto e analisar como está o andamento do projeto.

Finalmente a etapa de ajuste dos Releases Planning é alcançada, nela ocorrerá aorganização da entrega dos Releases da seguinte forma:

42

Figura 12 – Tabela de Organização dos Releases. Fonte: Autor

Dependendo do tamanho do projeto poderá existir quantos Releases forem neces-sários, e dentro de cada Release é possível ter diversos Sprints, contanto que a duraçãodo Release não ultrapasse 2 meses.

Especialmente neste projeto teremos apenas 2 Releases, sendo que cada um pos-suirá 2 Springs. Estes Releases contaram com os 4 principais pilares do plano de negócio,sendo eles: sumário executivo, análise de mercado, plano de marketing e plano operacional,portanto a tabelá ficará da seguinte forma:

Figura 13 – Tabela de Releases do Plano de Negócios. Fonte: Autor

- Modificações no Product backlog: Em meio ao desenvolvimento, qualquermembro do time pode identificar falhas, erros ou necessidades. O caso é levantado nasreuniões diárias ou no Sprint Planning, e dependendo da situação uma modificação éadicionada no Product backlog conforme sua prioridade.

43

3.4 Finalização e Entrega

Esta etapa mostrará a evolução do desenvolvimento, a finalização dos Sprints edos Releases e por fim a conclusão do plano de negócio e a entrega.

Evolução do Desenvolvimento:

Para analisar como está a evolução e desenvolvimento do plano de negócios, énecessário demonstrar hipoteticamente seu decorrer, assim como segue:

Existirá inicialmente uma data inicial e uma final, na qual os Sprints se encaixarão,sendo necessário definir o tempo:

Figura 14 – Linha do Tempo. Fonte: Autor

Uma vez que determinado as datas inicial e final, a execução dos Sprints se inici-ará, o primeiro Sprint será o Sumário Executivo:

Figura 15 – Desenvolvimento do Sprint de Sumario Executivo. Fonte: Autor

44

Finalizado o primeiro Sprint, é esperado que uma parcela do produto seja entre-gue, para este caso seriam todas as analises do Sumário Executivo e sua criação. Portantoa primeira parte do plano de negócios é entregue:

Figura 16 – Finalização do Sprint de Sumário Executivo e Entrega do Incremento doProduto. Fonte: Autor

Ao final do primeiro Sprint, a equipe se reúne para analisar como foi o seu anda-mento, esta reunião também é conhecida como Sprint Review, onde a equipe aponta oque foi bom, o que foi ruim e se ocorrerá alguma mudança para os próximos Sprints.

Desta forma é possível partir para o próximo Sprint, a Análise de Mercado, paraeste Sprint foi criada uma situação hipotética em que o time no Sprint Review identificouuma necessidade de mudança, estas mudanças serão representadas com a cruz verme-lha. Isto não prejudica o produto, muito pelo contrário, estas mudanças são feitas paramelhorá-lo, ou seja agregando mais valor ao produto final.

Figura 17 – Desenvolvimento do Sprint de Análise de Mercado. Fonte: Autor

45

Finalizada o segundo Sprint, é feita a entrega de um incremento do produto, estecontendo toda a Análise de Mercado e sua criação. As modificações serão representadasem linhas vermelhas, como segue:

Figura 18 – Finalização do Sprint de Análise de Mercado e Entrega do Incremento doProduto. Fonte: Autor

Ao final do segundo Sprint, a equipe se reúne novamente para outra Sprint Review,apontando o que foi bom, o que foi ruim e se ocorrerá alguma mudança para os próxi-mos Sprints, lembrando que as modificações são hipotéticas e não necessariamente devemacontecer. Desta forma é possível partir para o próximo Sprint, o Plano de Marketing:

Figura 19 – Desenvolvimento do Sprint de Plano de Marketing. Fonte: Autor

46

Finalizada o terceiro Sprint, é feita a entrega do incremento do produto, este con-tendo todo o Plano de Marketing e as estratégias de comercialização. As modificaçõesserão representadas em linhas vermelhas, como segue:

Figura 20 – Finalização do Sprint de Plano de Marketing e Entrega do Incremento doProduto. Fonte: Autor

E por fim, mas não menos importante, ao final do terceiro Sprint a equipe se reúnenovamente para outra Sprint Review, apontando o que foi bom, o que foi ruim e se ocor-rerá alguma mudança para o próximo Sprint. Desta forma é possível partir para o últimoSprint, o Plano Operacional.

Figura 21 – Desenvolvimento do Sprint de Plano Operacional. Fonte: Autor

47

Finalizada o último Sprint, é feita a entrega do incremento do produto, este con-tendo todo o Plano Operacional e as estratégias organizacionais, como segue:

Figura 22 – Finalização do Sprint de Plano Operacional e Entrega do Incremento do Pro-duto. Fonte: Autor

E finalmente, após todos os processos até aqui apresentados, o objetivo é alcançado:"O Plano de Negócio Está Pronto!".

Figura 23 – Plano de Negócios Finalizado. Fonte: Autor

É importante saber que o desenvolvimento é baseado em uma metodologia ágil,e sempre que necessário, é possivel voltar e reajustar o plano de negócio, estando destaforma preparado para qualquer desafio.

48

4 OBJETIVO

O objetivo deste trabalho é conseguir realizar todos os passos do desenvolvimentode um plano de negócios voltado para empresas de software, baseando-se no frameworkScrum.

Tratando dos empreendedores como um Scrum Team, definindo para cada um umpapel fundamental da metodologia, desta forma designando obrigações e responsabilida-des. Não é necessário possuir uma quantidade mínima de empreendedores no time, porémo mais recomendado seria entre 2 ou mais sócios no negócio para o melhor aproveitamentodo ambiente ágil.

Definindo os Sprints baseando-se nos pilares do desenvolvimento de um plano denegócio. Buscando nesta etapa, o desenvolvimento ágil, as reuniões de análise e as tomadasde decisões, a fim de agregar valor ao negócio e fortalecendo seus pilares.

O principal objetivo deste trabalho é conseguir um melhor ganho em relação atempo e qualidade para a preparação do desenvolvimento de uma empresa ou negócio desoftware. Após todas estas etapas, é esperado que o desenvolvimento do plano de negóciosaté sua conclusão tenha ocorrido de forma estruturada e adaptável.

49

5 CONCLUSÃO

Conhecendo o mercado de software é possível identificar a quantidade de produtose serviços que surgem todos os dias, e isso pode ser um problema para quem desejadestacar um produto ou se manter na briga por mercado. Portanto é preciso se prepararpara evitar desafios ou até mesmo enfrentá-los, buscando assim alcançar seus objetivos.

Portanto uma surpresa pode representar o fim do negócio. Ou seja, é necessáriouma preparação para que isso não ocorra, e apesar de não ser nenhuma novidade jáexiste algo que pode ser feito para minimizar estes impactos, conhecemos como Plano deNegócio.

Mesmo sabendo de todos os desafios do mundo dos negócios. De acordo com oIBGE são pouquíssimas as empresas que desenvolvem um plano de negócios antes deiniciar suas atividades, e consequentemente muitas das empresas que não se preparamfecham antes dos primeiros 5 anos de vida. Estes dados são representados em [3, 4, 6].

Reconhecendo estes desafios, e buscando uma maneira de se preparar para enfrentá-los, destaca-se então as metodologias ágeis, que apesar de terem sido criadas para o desen-volvimento de software, podem ser de grande valia quando deseja-se organizar um planode negócios para um produto de software, pois há a possibilidade de sua organização,execução e adaptatividade alcançar o necessário para o desenvolvimento de um plano denegócio confiável e capaz de manter-se vivo e forte, indeterminadamente.

50

REFERÊNCIAS

[1] RAMAL CESAR SIMõES SALIM, N. H. A. C.; RAMAL, S. Construindo planos denegócios. 3ed. ed. [S.l.]: Elsevier, Campus, 2005.

[2] SCHWEITZER, M. B. Plano de negócios para a pro engenharia ltda. UniversidadeFederal de Santa Catarina, Curso de Administração, v. 1, n. 1, p. 1–126, 2007.

[3] ROSA, C. A. Como Elaborar um Plano de Negócios. 1ed. ed. [S.l.]: SEBRAE, 2013.

[4] ROSA, C. A. Como Elaborar um Plano de Negócios. 2ed. ed. [S.l.]: SEBRAE, 2007– 2013.

[5] BRANDãO, F. G. Plano de negócios: Material de apoio para a fase de pré-incubaçãode empresas. Universidade Estadual do Rio Grande do Sul, UERGS, v. 1, n. 1, p.1–41, 2013.

[6] TOUCHE, D. . Writing an Effective Business Plan. 4ed. ed. [S.l.]: accelerator, 2003.

[7] NETO, A. A. Finanças corporativas e valor. [S.l.]: Atlas, 2003.

[8] SILVESTRE, M. Os 10 mandamentos da Prosperidade. 1ed. ed. [S.l.]: Faro Editorial,2015.

[9] GOMES, I. M. Como Elaborar uma Pesquisa de Mercado. 3ed. ed. [S.l.]: SEBRAE -MG, 2013.

[10] OLIVEIRA, M. R. de. Análise de Mercado. 1ed. ed. [S.l.]: UFSCar, 2015.

[11] BOCCHETTI, G. W. G.; HERMANN, I. L. Plano de Negócios: Plano Operacionale Plano de Marketing. 1ed. ed. [S.l.]: Palhoça: UnisulVirtual, 2012.

[12] MARUPING, L. M.; VENKATESH, V.; AGARWAL, R. A control theory perspectiveon agile methodology use and changing user requirements. Information SystemsResearch, INFORMS, v. 20, n. 3, p. 377–399, 2009.

[13] SOARES, M. dos S. Comparação entre metodologias Ágeis e tradicionais para odesenvolvimento de software. Universidade Presidente Antônio Carlos, UNIPAC,v. 1, n. 1, p. 1–6, 2013.

[14] SOARES, M. dos S. Comparação entre metodologias ágeis e tradicionais para odesenvolvimento de software. INFOCOMP, v. 3, n. 2, p. 8–13, 2004.

[15] ALMEIDA, G. A. M. de. Fatores de escolha entre metodologias de softwaretradicionais e Ágeis. Escola Politécnica, v. 1, n. 1, p. 1–105, 2017.

[16] SOUZA, D. R. de. Implantação da Metodologia Ágil Scrum em um Ambiente deDesenvolvimento. 1ed. ed. [S.l.]: UFSC, 2014.

[17] LEIDEMER, R. H. Implantação de Scrum em uma empresa de desenvolvimento deSoftware. [S.l.]: UNIVATES, Curso de Sistema de Informação, 2013.

51

[18] ABRAHAMSSON O. SALO, J. R. P.; WARSTA, J. Agile Software DevelopmentMethods: Review and Analysis. 1ed. ed. [S.l.]: VTT, Espoo, 2002.

[19] SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. [S.l.]:Prentice Hall Upper Saddle River, 2002. v. 1.

[20] SKARIN, H. K. . M. Kanban e Scrum obtendo o melhor de ambos. 1ed. ed. [S.l.]:C4Media, 2009.

[21] SILVA, F. A. da. Geração de Valor. 1ed. ed. [S.l.]: Sextante, 2014.

Apêndices

Anexos