ANDRÉ DOMINGUES PAIS

DESENVOLVIMENTO DO PLANO DE NEGÓCIO

UTILIZANDO O SCRUM

LONDRINA
2018
 ANDRÉ DOMINGUES PAIS

DESENVOLVIMENTO DO PLANO DE NEGÓCIO

UTILIZANDO O SCRUM

Trabalho de Conclusão de Curso apresentado

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

Orientador: Prof. Dr. Rodolfo Miranda de

Barros

LONDRINA
2018
Ficha de identificação da obra elaborada pelo autor, através do Programa de Geração
Automá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 da
Computaçã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ÓCIO

UTILIZANDO O SCRUM

Trabalho de Conclusão de Curso apresentado

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

BANCA EXAMINADORA

Orientador: Prof. Dr. Rodolfo Miranda de

Barros
Universidade Estadual de Londrina

Prof(a). Dr(a). Jandira Guenka Palma

Universidade Estadual de Londrina – UEL

Prof. Ms. Fábio Cezar Martins

Universidade 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 Pais
e Agnaldo Roni Pais, e a minha irmã Ariany Domingues Pais, por todo o apoio e por
sempre acreditarem em mim, mesmo quando tudo parecia estar perdido.
Agradeço a minha noiva Natalia Novelli Pergo, por toda a paciência e apoio nestes
anos de graduação.
Agradeço a todos os professores que fizeram parte desta etapa da minha vida, em
especial 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 de
Computação, por estes anos de graduação.
E finalmente, agradeço as amizades que formei nestes anos e que irei levar para o
resto da vida, por todo conhecimento compartilhado, por todas as madrugadas acordados
juntos estudando para as provas, pelas brincadeiras e histórias que escrevemos nesta
graduação.
 “Não vos amoldeis às estruturas deste
mundo, mas transformai-vos pela renovação
da mente, a fim de distinguir qual é a
vontade 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) – Universidade
Estadual de Londrina, Londrina, 2018.

RESUMO

Desenvolver um negócio de software sem um planejamento prévio é muito arriscado, pois

sem uma preparação o empreendedor estará colocando em jogo tudo o que acredita e
almeja. 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 plano
para 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 de

Negó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 without
preparation 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 presence
in the market, and manage to organize financially. In this way, it is proposed in this work
the development of the business plan focused on software products, based on the agile
Scrum 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 . . 19

Figura 2 – Ilustração Modelo Tradicional. Fonte: http://alexpagernet.blogspot.com 22
Figura 3 – Ciclo do Desenvolvimento Ágil. Fonte: http://metodologiaagil.com . . . 25
Figura 4 – Diferenças entre Metodlogias Ágeis x Tradicional. Fonte: slideplayer.com.br 27
Figura 5 – Ciclo do Scrum. Fonte: https://www.youtube.com/watch?v=vg1S1WYZa6o 32
Figura 6 – Tabela de Organização do Product backlog. Fonte: Autor . . . . . . . . 39
Figura 7 – Tabela do Sprint. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . 40
Figura 8 – Tabela representativa do Sprint: Sumário Executivo. Fonte: Autor . . . 40
Figura 9 – Tabela representativa do Sprint: Análise de Mercado. Fonte: Autor . . 41
Figura 10 – Tabela representativa do Sprint: Plano de Marketing. Fonte: Autor . . 41
Figura 11 – Tabela representativa do Sprint: Plano Operacional. Fonte: Autor . . . 41
Figura 12 – Tabela de Organização dos Releases. Fonte: Autor . . . . . . . . . . . . 42
Figura 13 – Tabela de Releases do Plano de Negócios. Fonte: Autor . . . . . . . . . 42
Figura 14 – Linha do Tempo. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . 43
Figura 15 – Desenvolvimento do Sprint de Sumario Executivo. Fonte: Autor . . . . 43
Figura 16 – Finalização do Sprint de Sumário Executivo e Entrega do Incremento
do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 17 – Desenvolvimento do Sprint de Análise de Mercado. Fonte: Autor . . . . 44
Figura 18 – Finalização do Sprint de Análise de Mercado e Entrega do Incremento
do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 19 – Desenvolvimento do Sprint de Plano de Marketing. Fonte: Autor . . . . 45
Figura 20 – Finalização do Sprint de Plano de Marketing e Entrega do Incremento
do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 21 – Desenvolvimento do Sprint de Plano Operacional. Fonte: Autor . . . . 46
Figura 22 – Finalização do Sprint de Plano Operacional e Entrega do Incremento
do Produto. Fonte: Autor . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 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 . . . . . . . . . . . . . . . . . 16
2.1 Plano de Negócios . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Importância do Plano de Negócios . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Etapa 1: Elaboração do Plano de Negócios . . . . . . . . . . . . . . . 17
2.1.3.1 Sumário Executivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3.2 Análise de Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3.3 Plano de Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3.4 Plano Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Metodologias Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Manifesto Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Metodologia Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.4 Metodologia Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.5 Metodologi Ágil x Tradicional . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5.1 Orientação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5.2 Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5.3 Tipo de Garantia de Confiança . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.5.4 Gerente de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.5.5 Time de Desenvolvedores . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.5.6 Participação do Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.5.7 Abordagem (Figura 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2.1 Escolha o Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2.2 Escolha o Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2.3 Defina a Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2.4 Criação do Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2.5 Planejamento e desenvolvimento do Product Backlog . . . . . . . . . . . . 30
2.3.2.6 Planejamento do Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2.7 Acompanhando a evolução do Projeto . . . . . . . . . . . . . . . . . . . 31
2.3.2.8 Reuniões diárias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.2.9 Sprint Review (entrega parcial do produto) . . . . . . . . . . . . . . . . . 31
2.3.2.10 Retrospectivas dos Sprints . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.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 . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1 Definindo Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1.1 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.1.2 Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.1.3 Equipe (Dev Team) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Estudando o Product Backlog de um Produto de Software . . 35
3.2.1 Informações Sobre o Negócio . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Analise do Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3 Estratégias de Comercialização e Marketing . . . . . . . . . . . . . . . 36
3.2.4 Projeções Financeiras . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.5 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.6 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Releases Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.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 de

forma estruturada, sendo capaz de absorver constantes mudanças e de conseguir prever
imprevistos, é altamente necessário o desenvolvimento de um plano de negócios. Ainda
mais 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 nos
negócios.
Criar um plano de negócio não é tarefa simples, porém é um passo extremamente
necessá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 áreas
inconstante e que devem ser analisadas com atenção, pois se hoje existe alguma empresa
ou 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 de
novos conceitos e serviços até o simples fato de determinado nicho não estar mais no gosto
das 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 à surgir
dú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 altamente
adaptável à estas variações, prevendo obstáculos ou até mesmo se moldando para que os
mesmos passem a não afetarem seu negócio?
A resposta para estas perguntas é um ponto importante deste trabalho, assim
entã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 deve
responder 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, por
trás de cada uma existe um estudo cuidadoso. Pois, se uma delas não for bem definida, o
plano 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ância
do desenvolvimento do plano de negócios, é preciso meter a mão na massa, e colocar em
prática tudo o que será apresentado daqui em diante.
Este trabalho será organizado da seguinte maneira: na seção 2, será abordada a
fundamentação teórica para a compreensão do trabalho, na seção 3, será apresentado o
passo a passo para o desenvolvimento do plano de negócios utilizando o Scrum, na seção
4, 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 estes
objetivos sejam alcançados. Dentre estes objetivos destaca-se a diminuição dos riscos e
incertezas, pois através do plano de negócio é possível prever inconsistências no mercado
antes mesmo de ocorrerem, consequentemente gera-se estratégias preventivas para desviar
de 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ão
individualmente 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ísticas
deste negócio, como por exemplo: o nicho do mercado, os serviços e produtos que serão
oferecidos, o público alvo, os fornecedores, e até mesmo os concorrentes, evidenciando os
pontos 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 muito
mais segura. Baseado em [2, 3, 4, 5], pode-se destacar algumas vantagens e características
do plano de negócios:
∙ É um documento que ajudará com o processo de validação de uma ideia, através
do qual o empreendedor obtém dados estatísticos ou concretos para decidir se deve o seu
negócio é viável ou não.
∙ É um documento importantíssimo no qual o empreendedor possui para analisar
sobre o seu negócio e tirar algumas conclusões: O meu negócio é viável? Meu público alvo
está 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 uma
nova ideia.
∙ O plano de negócios é um mapa para guiar o empreendedor, é como uma bússola
e 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áculos
sejam vencidos ou evitados.
∙ Por meio do plano de negócios é possível diminuir consideravelmente os riscos
e incerteza sobre o negócio. Como já visto nos motivos anteriores, ao elaborar um plano
de negócios o empreendedor consegue identificar a viabilidade do seu negócio e por meio
disso 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, evita
esforç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 deve
ser ajustável e moldável conforme as novas exigências do próprio negócio e as constantes
mudanç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 plano

de 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. Em
outras palavras pode-se dizer ser o resumo do plano de negócios. Por isso, é de extrema
importâ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 de

atuação do seu produto de software, além de verificar pontos fortes e fracos que podem
impactar diretamente no sucesso ou fracasso do empreendedor.
Através desta análise, obtemos dados importantíssimos sobre como deverá ser a
atuação no mercado. As definições então se baseiam em alguns aspectos que deve-se
analisar, 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 no
mercado para enfrentar a concorrência [7].
Em outras palavras, a análise de mercado é uma etapa essencial para o surgimento
do 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 o
negócio um sucesso.
É essencial que o empreendedor acredite no potencial do seu produto, porém, tão
importante quanto isso, é ter a certeza do valor do seu negócio. Portanto é necessário
analisar 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 de

elaboração do plano de negócios, a etapa da criação do plano de marketing, mais detalhes
deste processo será abordado a seguir.
O plano de marketing é a etapa de planejamento das ações publicitárias que serão
tomadas para impulsionar o negócio, independentemente de quais forem os objetivos o
empreendedor tem que estar preparados para alcançá-los, como por exemplo: alcançar
um público alvo, atrair fornecedores ou clientes, movimentar vendas ou simplesmente
promover um produto ou serviço. Em todo caso, o plano de marketing definirá as ações
estraté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 competitivo
no mercado, algumas vezes ainda considerando o plano de marketing como ferramenta de
gestão. Através de boas estratégias de marketing é possível alavancar um negócio de um
dia para o outro, mas para isso é muito importante que o empreendedor conheça bem o
mercado de atuação, pois, se é de seu conhecimento os pontos fortes e fracos, ficará muito
mais 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ível
pensar 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 realizadas
pela equipe de colaboradores, buscando assim gerar resultados em pequenos períodos de
tempo e visando sempre os objetivos do negócio [11].
Em palavras mais simples, o plano operacional será o guia sobre o que fazer e como
fazer, como por exemplo, cuidar das atividades de rotina da empresa, assegurando que os
papéis de cada membro da equipe sejam realizados com sucesso, sempre de acordo com
as políticas e conformidades.
Destaca-se também que o plano operacional pode: identificar recursos necessários
para 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 sobre
as 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 o

mercado vai mudando as necessidades dos clientes também vão, e atender estas demandas
dos clientes de forma dinâmica, flexível e com alta produtividade costuma ser um problema
muitas vezes difícil de resolver.
A metodologia Ágil ou Agile, como o próprio nome sugere, surgiu então como uma
solução alternativa para enfrentar os desafios encontrados no desenvolvimento de software
que se utilizam de técnicas de gestão dos modelos tradicionais. Existem diferentes tipos
de 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 altamente
dinâmica, com uma abordagem iterativa, onde todo o desenvolvimento é realizado em
etapas de curto prazo que passam por analises e se obtém um feedback, para que caso seja
necessá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 desenvolvimento
de software, assinado em 2001 em Utah [14].
Nesse evento participaram 17 desenvolvedores, que ao verificarem as dificuldades
pelas quais os desenvolvedores de sistemas passavam, se reuniram para discutirem os
pilares do desenvolvimento de software, e que apesar de estarem testando abordagens
e métodos diferentes, compartilhavam dos mesmos fundamentos, descrevendo assim o
Manifesto [14].
O Manifesto é um documento que reuniu as diferentes visões desses profissionais
acerca dos processos de desenvolvimento de software e condensou esses valores em 4, além
de criar 12 princípios a serem seguidos.
No Manifesto existem frases que determinam a importância de algumas coisas em
relação a outras, essas frases são dispostas no formato A mais que B, de modo a tornar
claro o que é prioritário. Vale ressaltar que independentemente das frases dizer que A
mais que B não significa que o B seja totalmente irrelevante, porém que o A deve ser
considerado 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 do

cliente;

∙ Entregas constantes de software devem ser realizadas;

∙ Deve existir cooperação diária entre os desenvolvedores e quem tem conhecimento

acerca 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 de

se 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 de
softwares. O modelo foi proposto por Royce em 1970, que na época identificou que o custo
para se realizar alterações e correções nos códigos era exorbitante, uma vez que o acesso
as maquinas era limitados e não existia ferramentas modernas que poderiam ser usadas
como apoio ao desenvolvimento de software. Por este motivo então que antes do software
ser implementado ele era todo planejado e então documentado, sendo considerado assim
um modelo mais "rígido"[15, 13].
Atualmente ainda são utilizadas em diversos projetos, mas está aceitação se da pelo
fato 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 modelo
tradicional o software é construído em uma sequencia de etapas, sendo que uma depende
da conclusão da anterior, com exceção da primeira, assim como representado na figura 2
pelo 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 a
fase 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 do
desenvolvimento 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 e
riscos 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 mais
complexos, 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 flexibilidade
no 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 sempre
deve 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 um
melhor 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 desenvolvidos
e qual a ordem que eles devem ser realizados, maximizando o valor do produto para
o cliente.
- Scrum Master: é conhecido como facilitador, seu papel é ajudar a todos os
membros do time à entenderem os valores, princípios e práticas do Scrum. Sua
participação é como a de um coach, ajudando na liderança do processo, porém o
Scrum Master não é chefe de ninguém.
- Dev Team: são os profissionais que desenvolverão no projeto, no Scrum quem
decide como fazer as coisas é o time. A principal ideia é que o time se auto-organize
para 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 definidas
quais 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ções

das funcionalidades que entram na Sprint, cabe ao Dev Team decidir como serão
realizadas e quem ficara com determinadas tarefas.
- Sprint Execution: neste evento ocorrerá a execução do Sprint, inicialmente com
o backlog já definido por prioridade, são selecionadas e iniciadas as funcionalidades
que 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. Conforme
a 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 ao
Product backlog conforme sua prioridade. Este processo se repete até que o produto
como um todo esteja finalizado.
- Daily Scrum: é uma reunião que ocorre diariamente e que possui pouco tempo
de duração, com máximo de 15 minutos, onde todo o time participa informando
como está o desenvolvimento, deixando assim todos informados sobre o progresso
do Sprint. Estas reuniões são marcadas por 3 perguntas que todos os membros do
time devem responder, sendo elas: o que você fez ontem? o que vai fazer hoje? tem
algum impedimento que o impede de progredir?
- Sprint Review Meeting: neste evento o Scrum Team se reúne para analisar se
o que está sendo feito está correspondendo com as expectativas esperadas, por meio
do Sprint Review o time verifica como está sendo o andamento do Sprint. É neste
evento que ocorrem as mudanças e o Product backlog é atualizado.
- Sprint Retrospective: nesta etapa o Scrum Team analisa como foi o andamento
do Sprint, seus pontos fortes e fracos, o que deve ser melhorado e o que deve ser
descontinuado. Na retrospectiva do Sprint todos devem analisar como foi o decorrer
do 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 ser
desenvolvidas. O PO com o auxílio do Scrum Master, organiza estas funcionalidades
por ordem de prioridade, vale destacar que a prioridade é proporcional ao valor que
ela agregará ao produto.
- Sprint backlog: no Sprint backlog está inserido um grupo de funcionalidades
que serão desenvolvidas no tempo do Sprint, lembrando que este tempo é de no
máximo 4 semanas, também conhecido como time-boxed e que as funcionalidades
estã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ças

entre 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 bem
definidos.

∙ Á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 sendo

o 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 de
desenvolvimento 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 desafios
encontrados 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 valor
ao 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 uma
lista com funcionalidades ordenadas por prioridade, essa etapa então que definirá o que
será o nosso produto, conhecida como Product backlog [19].
 28

O Product backlog, possuirá em ordem de prioridade as funcionalidades do produto

ou 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 uma
vez particionados, sendo estas partições conhecidas como Sprints, que são a entrega de
algumas funcionalidades em um curto prazo de tempo e que vão agregando valor ao
produto, estas etapas sempre que finalizadas passam por um feedback, podendo ser dado
pela equipe de desenvolvimento, por gestores ou pelo próprio cliente [19, 17].
Um ponto importantíssimo do Scrum, é que devido sua autonomia e entregas
incrementais, possíveis ajustes que venham a aparecer podem ser realizados com muita
facilidade em Sprints futuros, destacando que isto ocorre sem prejudicar o andamento do
projeto.
Outro ponto interessante do Scrum, são as reuniões diárias, as chamadas Daily
Scrum, onde toda a equipe participa, destacando o desenvolvimento individual de cada
um, expondo desafios e inteirando todos de como está indo o andamento do projeto.
Vale ressaltar que no desenvolvimento ágil Scrum, cada membro do time possui
funções dinâmicas, isso não significa que não exista responsabilidades individuais, mas que
todos são livres para trocar informações, se ajudar, compartilhar conhecimento e resolver
problemas comuns. A participação do time é quase total, podendo partir de tomadas de
decisões no projeto até reorganização de tarefas, estas muitas vezes decididas nas reuniões
diarias onde analisam como esta o decorrer do Sprint [16].
Um papel importantíssimo é o do Scrum Master, o líder do projeto, possui a
função de facilitador, intermediando muitas vezes o contato do time. É o Scrum Master
que muitas vezes fornece as informações técnicas para o time e ainda é responsável por
sanar todas as duvidas que impedem o progresso no desenvolvimento. Apesar dele possuir
um cargo de liderança ele não é chefe de ninguém.
O time é composto, basicamente, em três papeis distintos, sendo eles: o Scrum
Master (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 o

passo a passo de cada elemento necessário para o seu desenvolvimento. Identificando os
papéis fundamentais da metodologia, a criação do Product backlog, o planejamento dos
Sprints, 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. Para
assumir tal responsabilidade o PO deve possuir amplo conhecimento do negócio e precisa
entender as demandas do cliente. Em outras palavras o PO será a ponte entre o cliente e
o Dev Team.

2.3.2.2 Escolha o Scrum Master

Para assumir uma posição de Scrum Master no time é necessario que goste de
trabalhar com equipe, além de precisar cohecer muito bem os principios e praticas do
Scrum, pois o Scrum Master terá como responsabilidade passar estes valores para a equipe.
Portanto a caracteristica de liderança é impressidivel, assim que reconhecido estas
caracteristicas será escolhido o Scrum Master, que atuará como facilitador em meio ao
time, buscando orientar e solucionar possíveis problemas que estejam comprometendo o
progresso do projeto.

2.3.2.3 Defina a Equipe

Um dos principais pontos do Scrum é a definição do Dev Team, pois é por meio
dele 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 tomadas
de decisões simples à criação de estratégias mais complexas, ou seja, o time possui papel
fundamenta nos rumos tomados pelo projeto. As habilidades, características e experiencias
de cada membro é de extrema importância para que as metas estabelecidas pelo PO sejam
alcançadas.
Esta diversidade no time é muito interessante, pois, somadas todas as experiencias
individuais, conseguimos um time muito mais preparado para enfrentar os desafios que
surgirão no meio do caminho. Mas para isso acontecer, vale ressaltar a importância de que
todos os membros possuam ao menos o mínimo conhecimento necessário para garantir a
entrega das metas estabelecidas pelo PO.
Outro ponto importante para o Dev Team é a união dos integrantes, podemos
comparar isso a um time de futebol, ou seja, o sucesso de um é o sucesso de todos, assim
como, o fracasso de um, também é o fracasso de todos. É necessário que o time esteja
unido para aprimorar o entrosamento, e conforme vão passando pelos desafios juntos, as
metas 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 se
torna 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 que
deverão ser desenvolvidas para a conclusão do projeto. Estas funcionalidades são ordenas
por prioridade, e isto representa diretamente o valor de cada uma delas no projeto, ou
seja, 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 é ele
quem representa o cliente na equipe, desta forma é importantíssimo que as funcionalidades
atendam 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 cada
funcionalidade do projeto, informando qual a dificuldade do desenvolvimento de cada uma
delas.
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 grande
dor 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 desenvolvimento
da mesma, ou simplesmente concluir que ainda não possuem as informações suficientes
para 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 cada
funcionalidade com grau de dificuldade (fácil, moderado ou difícil) ou ainda basendo-se
em produtividades anteriores. É necessário que a equipe entre em comum acordo para
que as estimativas sejam concluidas.

2.3.2.6 Planejamento do Sprint

Com todas as funcionalidades devidamente identificadas, ordenadas por prioridade

e com tempo de desenvolvimento estimado, é possível passar assim para a nossa próxima
etapa, 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 tem
duraçã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íveis
desafios que irão enfrentar para desenvolve-las.
 31

Vale lembrar que o que está definido no Sprint Planning não necessariamente deve
ser 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 insignificantes
e desnecessárias.

2.3.2.7 Acompanhando a evolução do Projeto

É muito interessante que a equipe possua um acompanhamento do andamento do

projeto de forma visual, esta técnica é característica do desenvolvimento ágil e é muito
utilizada nos dias de hoje, pois através dela a equipe consegue ver o que está sendo
desenvolvido, 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 equipe
participa, e cada membro responde a três perguntas essenciais: - O que você fez ontem
para ajudar o time a atingir a meta do Sprint? - O que você vai fazer hoje para ajudar o
time a atingir a meta do Sprint? - Existe algum impedimento que me impeça de atingir
a meta do Sprint?
Estas reuniões geralmente são feitas de pé, por se tratarem de reuniões que devem
ser 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ção
e é 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 foi
feito no decorrer do Sprint, esta analise é chamada de Sprint Review. Nesta reunião o
time apresenta tudo o que foi desenvolvido e aponta os problemas enfrentados durante o
Sprint, 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 maneira
cumprindo com o papel do Scrum e agregando valor ao produto, nesta reunião todos
devem 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ão

com toda a equipe, agora sem o cliente, para apontar o que deu certo e o que não deu tão
certo 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óximos
Sprints.
Esta reunião não é feita para apontar culpados, mas para analisar o que não foi
bom para o projeto e aprender com os erros, consequentemente isso acarretará na melhora
da 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, para

entender "como integrar o Scrum à um plano de negócios".
O plano de Negócios é algo de extrema importância para que uma empresa possa
se tornar competitiva, possuir estrategias de marketing, reconhecer o público alvo, analisar
o mercado, estudar os concorrentes e se preparar para possiveis obstaculos e dificuldades
que irá encontrar no caminho.
No Capítulo 3 será analisado cada etapa da elaboração do plano de negócios
como 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 do
Scrum 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 desenvolvimento

do 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 assim
o que buscamos: o ambiente ágil do Scrum.
Primeiramente é preciso conhecer muito bem o time, as características de cada
um, 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 o
Scrum, é necessário criar uma situação hipotética, a partir de agora será assumido que
existe uma equipe de no mínimo 3 desenvolvedores, cada um com suas características
particulares, 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 desenvolvedores
envolvidos, 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 para

os empreendedores, é importante lembrar que no Scrum o PO não pode assumir outros
papéis, porém não existe restrições para o modelo, pois de acordo com o Serasa Experian
milhares 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 do
Scrum, é necessário analisar todos os papéis individualmente mas isso não restringe o
empreendedor 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 cliente
no 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 por
exemplo: capacidade de gerenciar, boa comunicação, deve ser visionário para enxergar
boas 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ção
2.1 o mercado é inconstante, as coisas mudam muito rapidamente e as necessidades devem
ser atendidas no mesmo ritmo. Portanto o empreendedor deve ser ágil, saber reconhecer
os desafios rapidamente significa tomar atitudes rápidas para solucioná-los e acima de
tudo 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 ou
o cargo que ele irá assumir na sua empresa, pois se conseguir compreender que nada se
cria sózinho, as coisas acontecem. É neste perfil de empreendedor que o Scrum Master se
encaixa.

3.1.1.3 Equipe (Dev Team)

O Dev Team, ou time de desenvolvimento, são os empreendedores responsáveis por

transformar os requisitos estabelecidos pelo PO no plano de negócios, é através deles que
o principal objetivo deste modelo se concretiza, assim como os desenvolvedores que por
ventura tenham assumido os papéis de PO e Scrum Master o Dev Team precisa possuir
amplo conhecimento do mercado de atuação, pois eles devem ser capazes de identificar
falhas 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 repensar
a 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ão
pessoas com experiencias profissionais distintas, que ao juntarem o conhecimento são
capazes de elaborar um plano de negócios consistente e estratégico para se manter forte
na 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 software

a 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 do
nosso plano de negócio.
Assim que respondida a pergunta, o Product Owner entra em ação, definindo os
requisitos necessários para a elaboração do negócio. É então que as funcionalidades vão
sendo 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 e
informaçõ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 que
todo 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 vez
receberão prioridades menores, e isso determina o que o Dev Team com auxílio do Scrum
Master deverão se preocupar primeiro. Dentre estes pontos destaca-se 3, sendo eles: análise
de 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, identificar
funcionalidades e classificá-las por prioridade.
- Scrum Master: estudar o negócio, realizar uma analise de possíveis desafios e
caso 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 dos

principais pontos a serem analisados é o mercado de atuação, bem como os fatores que
podem impactar diretamente no sucesso ou fracasso do negócio.
 36

Uma análise minuciosa do mercado fornece informações importantes como por

exemplo: 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 o
negócio e torná-lo um sucesso.
Um ponto importante resultante da análise de mercado é a possibilidade de criar
estratégias de comercialização e marketing, esta etapa será analisada mais a fundo no
pró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 o
software ou o produto de software possui demanda, qual público-alvo, quais os meios de
publicidade explorar, entre diversos outros pontos que permitem o produto seja colocado
em posição de destaque no mercado.
Vale ressaltar que a análise de mercado deve ser realizada constantemente e não
somente 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 empreendedores
fiquem 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 desafios
financeiros, como: taxa participativa dos fornecedores, potencial de escalabilidade
do produto, atuação da concorrência, entres outros; e com isso auxiliar o PO com
as priorizações das funcionalidades.
- Dev Team: estudar o mercado e ajudar o Scrum Master a buscar soluções para
os 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 de

estraté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çado
no mercado, este ponto será determinante para o sucesso do negócio.
É importante lembrar que não adianta possuir um produto de alta qualidade se
nã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 noite
para 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 sentimento

das 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 de
empreendedores deve conhecer bem o mercado, as necessidades dos clientes devem ser
priorizadas pelo PO no Product backlog, pois todo este planejamento rodará em volta
destas necessidades. Vale ressaltar que quando se é tratado de clientes na elaboração do
plano 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 uma
analise sobre como alcançar o público consumidor e qual a melhor forma de fazer
isso. Com isso, deverão realizar boas estratégias de comercialização e marketing.
- Product Owner: reconhecendo as necessidades e desejos dos clientes o PO deve
priorizar 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 caixa
e estimativa de resultados. Estes levantamentos são realizados hipoteticamente, uma vez
que 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 iniciar
o 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 perdas
financeiras. 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 se
organizar uma projeção financeira real é necessário que possuam todas as informações
que impactem diretamente no sistema financeiro do negócio. Dentre as projeções que o
time deve se preocupar estão: projeção de entrada e saída de capital, projeção de despesas
fixas, projeção do capital de giro, projeção de faturamento, entre outras.
 38

Em [7] é possivel identificar algumas dicas importantes sobre como elaborar uma
projeçã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ções
do negócio. Portanto é muito importante não esquecer de elaborar a projeção do capital
de 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 de
software, mesmo que ainda não possua resultados próprios, os empreendedores devem se
questionar 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 devem
ser 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 e
nas estrategias de marketing elaboradas pela equipe, o PO com o auxílio do Scrum
Master deve identificar projeções necessários e de forma estratégica classificá-las por
prioridade.
- Scrum Master: o Scrum Master deverá agir como um coach, auxiliando o PO
na identificação das projeções necessárias para determinar os objetivos financeiros
do 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 todas
as 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 desenvolvimento
do Product backlog, o PO estará altamente preparado para sair dos conceitos e passar para
a 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 podem
ser realizados em um determinado intervalo de tempo, irá compor os Releases, que são
entregas 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 em
desenvolvimento neste trabalho ser um plano de negócios, isso se aplica a todo tipo de
projeto.

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 a
análise dos Sprints que os compõem, cada Sprint possui uma Lista de funcionalidades e
estas por sua vez são ordenadas por prioridades, a estrutura de visualização irá ficar da
seguinte forma:

Figura 7 – Tabela do Sprint. Fonte: Autor

No desenvolvimento do plano de negócios de produtos de software, existirão 4

Sprints principais, também chamados de pilares, por serem essenciais em todos os planos
de negócio, são eles: Sumário Executivo, Analise de Mercado, Plano de Marketing e Plano
Operacional.
Todos os Sprints poderão assumir N funcionalidades, ficando representativamente
desta 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ção
de até 8 semanas cada. Os Releases são desenvolvidos pelo Dev Team, com o auxílio do
Scrum 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á a
organizaçã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ção
do 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, qualquer

membro do time pode identificar falhas, erros ou necessidades. O caso é levantado nas
reuniõ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 e

dos 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. Portanto
a primeira parte do plano de negócios é entregue:

Figura 16 – Finalização do Sprint de Sumário Executivo e Entrega do Incremento do

Produto. 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 o
que 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, para
este Sprint foi criada uma situação hipotética em que o time no Sprint Review identificou
uma 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 para
melhorá-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, este

contendo toda a Análise de Mercado e sua criação. As modificações serão representadas
em linhas vermelhas, como segue:

Figura 18 – Finalização do Sprint de Análise de Mercado e Entrega do Incremento do

Produto. 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 devem
acontecer. 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ções
serão representadas em linhas vermelhas, como segue:

Figura 20 – Finalização do Sprint de Plano de Marketing e Entrega do Incremento do

Produto. Fonte: Autor

E por fim, mas não menos importante, ao final do terceiro Sprint a equipe se reúne
novamente 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 último
Sprint, 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 desta
forma preparado para qualquer desafio.
 48

4 OBJETIVO

O objetivo deste trabalho é conseguir realizar todos os passos do desenvolvimento

de um plano de negócios voltado para empresas de software, baseando-se no framework
Scrum.
Tratando dos empreendedores como um Scrum Team, definindo para cada um um
papel 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ém
o mais recomendado seria entre 2 ou mais sócios no negócio para o melhor aproveitamento
do ambiente ágil.
Definindo os Sprints baseando-se nos pilares do desenvolvimento de um plano de
negócio. Buscando nesta etapa, o desenvolvimento ágil, as reuniões de análise e as tomadas
de 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 a
tempo e qualidade para a preparação do desenvolvimento de uma empresa ou negócio de
software. Após todas estas etapas, é esperado que o desenvolvimento do plano de negócios
até 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 produtos

e serviços que surgem todos os dias, e isso pode ser um problema para quem deseja
destacar um produto ou se manter na briga por mercado. Portanto é preciso se preparar
para 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ário
uma 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 de
Negócio.
Mesmo sabendo de todos os desafios do mundo dos negócios. De acordo com o
IBGE são pouquíssimas as empresas que desenvolvem um plano de negócios antes de
iniciar suas atividades, e consequentemente muitas das empresas que não se preparam
fecham 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 plano
de 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 de
negó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 de

negócios. 3ed. ed. [S.l.]: Elsevier, Campus, 2005.

[2] SCHWEITZER, M. B. Plano de negócios para a pro engenharia ltda. Universidade

Federal 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ção

de 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 Operacional

e Plano de Marketing. 1ed. ed. [S.l.]: Palhoça: UnisulVirtual, 2012.

[12] MARUPING, L. M.; VENKATESH, V.; AGARWAL, R. A control theory perspective

on agile methodology use and changing user requirements. Information Systems
Research, INFORMS, v. 20, n. 3, p. 377–399, 2009.

[13] SOARES, M. dos S. Comparação entre metodologias Ágeis e tradicionais para o

desenvolvimento 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 o

desenvolvimento de software. INFOCOMP, v. 3, n. 2, p. 8–13, 2004.

[15] ALMEIDA, G. A. M. de. Fatores de escolha entre metodologias de software

tradicionais 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 de

Desenvolvimento. 1ed. ed. [S.l.]: UFSC, 2014.

[17] LEIDEMER, R. H. Implantação de Scrum em uma empresa de desenvolvimento de

Software. [S.l.]: UNIVATES, Curso de Sistema de Informação, 2013.
 51

[18] ABRAHAMSSON O. SALO, J. R. P.; WARSTA, J. Agile Software Development

Methods: 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