Conforme foi descrito anteriormente, esta pesquisa quanto aos meios é bibliográfica, e quanto aos procedimentos adotados para a coleta de dados: é bibliográfica, documental (Gil, 2007). Antes de entrar no detalhamento dos procedimentos de coleta e tratamento de dados, é requerido entender alguns conceitos da engenharia de software; porque foram adaptados às ciências sociais e particularmente ao turismo e sua governança.
Engenharia de software é o processo de criação e utilização de sólidos princípios de engenharia para obter sistemas de informação computadorizados que sejam confiáveis e que trabalhem eficientemente em máquinas reais. Tem por objetivo apoiar o desenvolvimento profissional de software (Sommerville, 2011). Usa uma abordagem sistemática e disciplinada que inclui: custos aceitáveis, gerenciamento do processo de desenvolvimento, garantia do trabalho em equipe e a construção de software com qualidade (Pressman, 2011).
O processo de software é um conjunto de atividades e resultados associados, que auxiliam no desenho, desenvolvimento, implantação, manutenção, suporte e evolução dos sistemas. Criando metodologias, procedimentos e métodos de construção de sistemas (Pressman, 2011). Segundo o Institute of Electrical and Electronics Engineers, é: “a aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento, operação e manutenção do software” (IEEE, 1990, p. 67). Enquanto, Pádua-Filho (2009) define como: “um conjunto de ações e atividades inter-relacionadas realizadas para obter um conjunto especificado de produtos, resultados ou serviços” (Pádua-Filho, 2009, p. 39).
As metodologias de desenvolvimento de software são classificadas em duas categorias, 1) sequencial (também conhecidas por tradicionais ou em cascata), o desenvolvimento de produtos é divido em etapas bem definidas e isoladas e o resultado é apresentado todo de uma única vez. Ver figura 10.
A segunda categoria é o modelo iterativo e incremental, que possui iterações curtas, onde o resultado é medido através de uma sequência de pequenos produtos prontos. O modelo de entrega ágil é baseado em vários ciclos iterativos e incrementais, isto permite a flexibilidade e adaptabilidade. Uma característica desta metodologia é a constante inspeção e adaptação dos ciclos e iterações, voltados para a melhoria contínua. Apresentada Na figura 10. Este modelo foi escolhido neste trabalho, porque é mais moderno, flexível e apresenta rápido resultado em iterações.
Embora não haja a “melhor metodologia”, mas sim a solução mais adequada dentro de um determinado contexto, a escolha de uma metodologia pode variar para cada projeto (Sommerville, 2011):
1) Modelo sequencial, são orientados ao planejamento (tradicionais), refere- se os processos no qual todas as atividades são planejadas previamente, abordagem sistemática linear, como consequência, são burocráticos e demoram certo tempo até se obter algum resultado. Tem a definição de passos sequenciais bem definidos onde o passo seguinte depende da conclusão da atividade anterior (Pressman, 2011).
Este tipo de metodologia é útil para pequenos projetos, com poucas pessoas no desenvolvimento e tendo apenas 2 ou 3 pessoas como líderes do projeto por parte do cliente (Pádua-Filho, 2009). Para o professor Denis Rezende (2005) esta abordagem é ideal para centralizar o controle do software contratado. Embora o ônus seja a dependência de uma ou duas pessoas, mas o resultado quando o produto é especialmente para essas pessoas tende a ser muito bom.
Geralmente as metodologias científicas para desenvolvimento de trabalhos universitários seguem esta linha. Bem planejadas, com abordagem linear, com vários documentos para serem preenchidos e analisados sequencialmente. Finalmente, o trabalho é entregue de uma única vez (tudo ou nada). E em alguns casos, seção após seção (Creswell, 2010).
Figura 10 - Modelo de desenvolvimento de software em cascata
Fonte: https://engenhariasoftware.files.wordpress.com/2013/01/cascata.png
2) Modelo iterativo e incremental (metodologias Ágeis), nestes modelos o planejamento é feito gradativamente, possui menos burocracia em relação aos
processos tradicionais o modelo fraciona o trabalho de desenvolvimento em partes que incorporam alguma funcionalidade necessária para o cliente a cada iteração (SOMMERVILLE, 2011). Complementando, Rubin (2017) destaca que: “O desenvolvimento incremental é baseado em um antigo princípio de construir um pouco antes de construir o todo” (Rubin, 2017, p. 28).
A diferença desta metodologia em relação ao modelo sequencial, é a proposta de entregar “pequenos resultados de software” em cada ciclo. No caso das metodologias de desenvolvimento de trabalhos científicos, não se trata de partes da tese, por exemplo: seção 1, depois da seção 2 e assim por diante. A proposta da metodologia ágil é fazer entrega bem estruturada de “pedaços” de várias seções em cada ciclo. A primeira versão entrega uma parte da seção 1, 2, 3 e/ou 4 de uma única vez, porém estas seções complementados e melhorados nas próximas versões (Schwaber & Sutherland, 2013).
A estrutura global do trabalho é entregue no primeiro ciclo. As entregas subsequentes aumentam e complementam as seções posteriores (1, 2, 3 e 4 respectivamente). Assim, em vários ciclos até as seções finais (5 e 6) terem sido concluídas. Todos as seções são evoluídos ao longo do tempo em cada entrega parcial. A filosofia é diferente do modelo sequencial, porque pequenas partes completas são entregues em cada ciclo (Rubin, 2017).
As metodologias ágeis focam no trabalho colaborativo que prioriza resultados concretos, entrega de valor e minimização de desperdícios, pregam por simplicidade, rapidez, e vão contra processos burocráticos de documentação. Os princípios dos modelos ágeis deram origem ao Manifesto Ágil (Agile, 2011).
Figura 11 - Modelo iterativo e incremental
Fonte:
LIFICADO_UMA_PROPOSTA_DE_PROCESSO_PARA_O_CEFET- RNDATINF/figures?lo=1
Cesar Brod, autor do livro “Scrum Guia Prático para Projetos Ágeis” (2015), descreve que o termo “metodologias ágeis”, tornou-se popular desde 2001, quando 17 engenheiros de software se reuniram e estabeleceram princípios comuns para simplificar o processo em desenvolvimento de sistemas. O resultado foi a criação do “The Agile Manifesto”. Este documento, foi elaborado com o intuito unir diferentes metodologias ágeis. O manifesto ágil (traduzido do inglês) define quatro princípios básicos:
1) Indivíduos e interações, são mais importantes do que processos e ferramentas;
2) Software em funcionamento, é mais importante do que documentação abrangente;
3) Colaboração com cliente, é mais importante do que negociações contratuais;
4) Responder às mudanças, é mais importante do que seguir um plano (Brod, 2015 p. 31; Agile, 2011).
As principais diferenças entre as duas metodologias são: As tradicionais são projetadas para entregar o produto ao cliente somente quando estiver totalmente concluído. Sendo assim, o cliente só perceberá resultado quando produto estiver finalizado. Essa metodologia, segue uma abordagem linear e o resultado só aparece no final da sequência. O risco é que pode ser um grande problema, se houver um erro de definição em algum estágio inicial (Rezende, 2005).
Além disso, o tempo decorrido entre o primeiro contato até a entrega do produto pode levar a um desinteresse por parte do cliente. O risco de não atender conforme desejado aumenta com o passar do tempo (Pressman, 2011). Cabe destacar que esta metodologia é adequada quando se tem um processo de software bem definido (Pádua-Filho, 2009).
Diferentemente, as metodologias ágeis, que permitem várias entregas parciais do produto. O cliente recebe constantemente e mais rápido algum artefato que será incrementado ao longo do tempo. Embora não seja o produto acabado, em cada ciclo algumas funções que agregam valor ao produto são acrescentadas. Os produtos entregues são melhorados ou concluídos e o cliente recebe uma versão (realise) no máximo a cada mês (Pressman, 2011; Sommerville,2011;).
Rezende (2005), destaca ainda que algumas das práticas e dos procedimentos mais conhecidos nas metodologias ágeis são: 1) desenvolvimento incremental do sistema usando ciclos de curtas iterações. 2) Priorização do que tem mais valor para o cliente antes de cada iteração. 3) Adaptabilidade às necessidades específicas da equipe. 4) Releases (versões) frequentes, simplicidade no aprendizado. 5) Grande envolvimento do cliente como membro da equipe.
Nesse contexto, destaca-se o Scrum, por ter uma abordagem enxuta, que usa os princípios da melhoria contínua e que serve para o desenvolvimento de qualquer produto. Tendo algumas famosas empresas que usam, tais como: Honda, Canon e Fuji-Xerox (Rubin, 2017). Trata-se de um processo ágil para a construção de produtos/serviços ou para administrar qualquer trabalho iterativo e incremental que aumenta a produtividade e diminui o tempo de entrega e desenvolvimento, o custo e os riscos no desenvolvimento (Rising & Janoff, 2000).
O Scrum se tornou um dos métodos ágeis mais difundidos na engenharia de
software, criado por Ken Schwaber e Jeff Sutherland no final dos anos 1990, o processo de trabalho baseia-se na interação e o feedback rápido (Rubin, 2017). Tem o objetivo de ser adaptável e prover retorno rápido aos envolvidos. O Scrum adota uma abordagem flexível para acelerar a entrega de valor e para gerenciar incertezas, por entender que algumas tarefas não podem ser previstas antes do desenvolvimento do sistema (Sommerville, 2011).
A abordagem Scrum está fundamentada no conceito de blocos de tempo, sendo o projeto organizado em interações chamadas de sprints. Com a peculiaridade que todas as sprints de um projeto possuem a mesma duração. O trabalho não finalizado em uma sprint, deve ser transferido para a sprint seguinte. Mas respeitando a duração fixa das sprints do projeto (Scrum, 2019; Agile, 2011).
A figura 12 apresenta a estrutura do framework Scrum, que se apoia em três princípios fundamentais: transparência, inspeções e adaptação. Apoiados neles, criam o ambiente propício para implementação de projetos ágeis (Scrum, 2019). O trabalho em equipe e a transparência são essenciais, as equipes se concentram em uma tarefa por vez, com o objetivo de obter mais velocidade e de entregar com qualidade.
Figura 12 - Fundamentos do Scrum
Fonte: https://www.elirodrigues.com/2016/06/08/os-pilares-do-scrum/
O Scrum não é o um processo, nem um modelo, mas sim um framework sobre o qual se devem construir os processos e técnicas para desenvolver produtos complexos. Semelhantemente ao PMBOK que tampouco é um manual, e sim um guia (PMI-AG, 2017). No guia do Scrum (Scrum, 2019). são descritos os três pilares nos quais a metodologia é suportada, estes pilares funcionam em conjunto, e são:
1) Transparência; clareza de informação e de comunicação, deve criar-se um ambiente de responsabilidade coletiva e progresso contínuo organizado e padronizado. Todos devem ter o mesmo entendimento, uma visão do produto e de tudo que está acontecendo, onde os envolvidos possuem conhecimento dos processos e do andamento do projeto.
2) Inspeção; avaliação da satisfação do cliente com cada artefato entregue, avaliação do esforço para desenvolver e principalmente das dificuldades encontradas. Também é requerido um monitoramento constante do andamento do projeto. São realizadas reuniões diárias de apenas 15 minutos em pé, para acompanhar o andamento de cada artefato. No final de cada sprint, é realizada uma reunião chamada de Sprint Review para avaliar os resultados e obter as lições aprendidas. O objetivo é garantir que o que está sendo construído está agregando valor ao produto.
3) Adaptação. flexibilidade para mudar os processos ou os artefatos de acordo com a necessidade; Ocorre toda vez que o inspetor identifica desvios que possam tornar o resultado inaceitável, pode ser devido às mudanças constantes nos projetos, ou pela realidade da empresa desenvolvedora.
O Scrum é um framework aplicável a portfólios, programas ou projetos de qualquer tamanho ou complexidade; e pode ser aplicado de forma eficaz em qualquer indústria, para criar um produto, serviço ou outro resultado. E é recomendado para tarefas que tenham muitas mudanças ou incertezas no momento da concepção e/ou sofram de alterações durante sua construção. (Schwaber & Sutherland, 2016).
Além das características de toda metodologia ágil supracitadas, se apoia nos seguintes fatores críticos de sucesso:
1) Escalabilidade, agilidade e capacidade de adaptação; 2) É usado por players internacionais no mundo todo;
3) É uma metodologia usada consistentemente na engenharia de software há mais de uma década;
4) Trata-se de uma metodologia robusta, que reduz significativamente a necessidade de preenchimento de vários de documentos e reduz a burocracia dos modelos clássicos de gestão;
5) A importância dada pelo PMI na sexta edição do seu guia, usando os métodos ágeis nas suas tarefas (PMI-AG, 2017; Schwaber & Sutherland, 2016).
Diante desse quadro de afirmações, o desafio foi usar esta metodologia (nada usual nas ciências sociais e humanas) para a elaboração deste trabalho. Que fosse capaz de nortear o caminho para produzir uma tese com consistência e ainda fosse capaz de entregar valor para a academia.
Para este fim, o Scrum, teve que ser adaptado à metodologia de pesquisa científica com vistas a dar mais uma opção de metodologia para desenvolvimento de trabalhos científicos, amparado pelas experiências empíricas da indústria.
Embora soubesse-se da presença de incertezas ao longo do desenvolvimento, mas, diante de um tema tão recente como é a performance da governança nos destinos turísticos inteligentes, onde, na sua essência está a inovação, o empreendedorismo e as novas tecnologias; não poderia deixar de se lançar mão de um novo desafio. Inovador na área das ciências sociais, contemporâneo e principalmente desafiador, características básicas da disrupção.
Na obra intitulada “Scrum Essencial: Um guia prático para o mais popular processo ágil” de Kenneth S. Rubin (2017), o autor define três (3) os papéis que devem ser
desempenhados pelos participantes do projeto. Estes mesmos papeis são reafirmados no guia do Scrum (Schwaber & Sutherland, 2016):
1) Product Owner, é a ponte entre o cliente e a equipe, define o cronograma para a liberação dos módulos do sistema, faz a validação final para constatar que o sistema segue as características definidas no escopo do projeto. Suas responsabilidades são: 1) Representar o cliente (quando este não está presente); 2) Gerenciar o Product Backlog; 3) Garantir o ROI; 4) Definir a visão do produto; 5) Gerenciar a entrada de novos requisitos e definir sua ordem; 6) Gerenciar o plano de releases; 7) Gerenciar o orçamento e riscos do produto ou projeto; 8) Aceitar ou rejeitar o que será entregue ao final de cada sprint;
2) Scrum Master, é o líder técnico da equipe de desenvolvimento do software. É o facilitador e responsável por garantir que a entrega do produto será feita com êxito. É um especialista na metodologia, não tem autoridade para controlar a equipe, diferentemente do papel tradicional de gerente, apenas guia a equipe na metodologia Scrum, faz o trabalho de um coach. Suas responsabilidades são: 1) Orientar o Product Owner na criação e ordenação do Product Backlog; 2) Garantir que as regras do Scrum estejam sendo cumpridas e que seus valores estejam sendo seguidos; 3) Remover impedimentos que possam atrapalhar a Equipe de Desenvolvimento; 4) Proteger a Equipe de Desenvolvimento; 5) Ser um facilitador da Equipe de Desenvolvimento, buscando sua produtividade; 6) Garantir a colaboração entre os diversos papéis e funções; 7) Aplicar os valores e as práticas do Scrum.
3) Development Team, equipe Scrum, são os desenvolvedores do produto de software. Equipe multidisciplinar composta geralmente por 5 a 9 pessoas e auto organizada (arquiteto, programador, testador, administrador de banco de dados etc.). Responsáveis por projetar, construir, testar e manter em funcionamento o produto; definem a melhor forma de trabalhar, as atividades e as suas prioridades para cada sprint.
Suas responsabilidades são: 1) Desenvolver os incrementos potencialmente entregáveis do produto; 2) Estimar os itens do Product Backlog; 3) Garantir a qualidade do
produto; 4) Apresentar o produto ao cliente ou Product Owner; 5) Definir como seu trabalho será executado. (Scrum, 2019; Rubin, 2017).
O quadro 18 apresenta a adaptação da metodologia ágil aplicado às metodologias científicas usadas na academia para a elaboração de teses. Onde, na coluna da esquerda estão as descrições dos papeis e suas responsabilidades de acordo com o Scrum. E na coluna da direita, estão as adaptações e responsabilidades dos orientadores no caso das teses.
Nas duas primeiras linhas estão descritas as atribuições do Product Owner que é a interface entre o cliente (aquele que vai pagar os produtos) e a empresa que irá desenvolvê- los. No caso da tese, a nomenclatura foi mantida, Product Owner seriam os interessados em que a pesquisa seja realizada. Tanto o discente propondo o projeto de pesquisa, quanto os orientadores (orientador e coorientador quando for o caso) nas suas linhas de pesquisa.
Na coluna da esquerda estão relacionadas as tarefas que o Scrum determina, enquanto na coluna da direita e em fonte cor azul, aparecem as adaptações que foram idealizadas para atender à metodologia científica. Na primeira linha aparece a vocábulo em inglês Product Owner, o “dono do produto” (algo na prática que funciona como um procurador do cliente) tem relação com o produto a ser construído usando a metodologia ágil Scrum.
Quadro 17 - Responsabilidades do Product Owner
Product Owner - Suas responsabilidades são:
Ser a ponte entre o cliente e a equipe de trabalho; definir o cronograma para a liberação dos módulos do sistema; fazer a validação final para constatar que o sistema segue as características definidas do escopo do projeto.
Product Owner da Tese. São principalmente os professores orientadores (o orientador e o
coorientador, quando houver) inicialmente o discente também.
Para o caso da tese, há uma mescla alternada de pessoas para esta atribuição. Inicialmente o aluno apresenta o projeto de tese, os orientadores avaliam, corrigem e melhoram, entram em um ciclo de melhorias consecutivo até aprovar ou definitivamente descartar a projeto.
Por vezes a tese é um pouco ambígua no início, mas após diversos refinamentos, o objetivo e a metodologia ficam claros. A partir desse instante os orientadores assumem integralmente esse papel, sempre em constantes interações com o discente.
Os primeiros erros ou problemas (faltas de conformidade) são detectados pelos orientadores que também são responsáveis pelo acompanhamento do macro cronograma e de fazer ajustes caso necessário.
Scrum Para a Tese
1
Representar o cliente (quando este não estiver
presente);
A academia exige da tese uma pesquisa própria da área científica, com os instrumentos metodológicos específicos. Além disso, a tese deve fornecer uma contribuição suficientemente original a respeito do tema pesquisado; Deve representar um progresso para a área científica em que se situa e precisa fazer a ciência crescer (ou avançar);
Trazer benefícios tais como: recursos e/ou credibilidade para novas pesquisas.
Atores: orientador e coorientador. 2 Gerenciar o
Product Backlog;
Definir funcionalidades e artefatos a serem elaborados, atribuir-lhes prioridades para serem apresentados em cada etapa. Melhorar os artefatos Atores: discente, orientador e coorientador.
3
Garantir o ROI (Retorno do Investimento);
Houve um investimento do contribuinte, ao permitir o afastamento do discente das suas tarefas. A tese deve ser defendida e deve trazer algum avanço na ciência.
O PPGTur , o CERES e a UFRN também devem perceber os frutos deste trabalho.
Atores: orientador e coorientador.
4 Definir a visão do produto;
Defender a tese com nota máxima, que tenha alta qualidade e traga inovação, que seja relevante e tenha rigor científico, que seja elaborada dentro do tempo previsto;
Que contribua para a evolução do PPGTur, da UFRN e da ciência; Que gere publicações;
Que tenha continuidade;
Que tenha aplicabilidade no mercado; Patente seria um plus desejado.
Atores: orientador, coorientador e discente.
5
Gerenciar a entrada de novos requisitos e definir sua ordem;
Identificar falhas, faltas e incorformidades;
Determinar quais e quando mudanças devem acontecer no projeto; Identificar a prioridade das mudanças;
Atores: orientador, coorientador e discente
6 Gerenciar o plano de releases;
Após concluída a tese, o framework deve ser evoluído, um modelo elaborado para implantação confeccionado e colocado no mercado; A cada melhoria significativa uma nova versão será lançada ao mercado. A tese deve também evoluir, mestrandos devem trabalhar em projetos
empíricos e doutorandos ampliando o framework.
Convênios e outras parcerias devem ser realizadas para melhoria e intercâmbio de experiências.
Atores: orientador e coorientador
7
Gerenciar o orçamento e riscos do produto ou projeto;
Gerenciamento do orçamento: não se aplica;
Gerenciamento dos riscos: concluir no tempo previsto; manter o rigor da metodologia; manter a alta qualidade; dar continuidade à tese;
Atores: orientador e coorientador.
8
Aceitar ou rejeitar o que será entregue ao final de cada
sprint.
Verificar e validar os artefatos entregues ao final de cada sprint; Avaliar o andamento das entregas;
Orientar as atividades da equipe. Atores: orientador e coorientador.
Fonte: Elaborado pelo autor (2019) adaptado de Rising e Janoff (2000); Rubin (2017); Schwaber e Sutherland (2016).
Na coluna da direita estão definas as atividades que foram adaptadas do Scrum para a metodologia científica. No final de cada atividade estão os atores responsáveis por esta, a ordem na qual aparecem também é importante neste caso, porque determina a ordem de importância da opinião do ator em cada atividade. É possível que algum ator em qualquer momento não consiga emitir uma opinião, nesse caso o voto de maior peso será o do seguinte ator (adaptado de Scrum, 2019).
Com relação às responsabilidades que o especialista em Scrum deve ter, estão relacionadas no quadro 19. Seguindo o padrão anterior, na coluna da esquerda está a atividade definida pelo Scrum e na coluna da direita está a adaptação feita para atender à metodologia científica desta tese.
Quadro 18 - Adaptação das responsabilidades do Scrum Master
Scrum Master - Suas responsabilidades são:
É o líder técnico da equipe de desenvolvimento do software. É o facilitador e responsável por garantir que a entrega do produto será feita com êxito. É um especialista na metodologia, não tem autoridade para controlar a equipe, diferentemente do papel tradicional de gerente, apenas guia a equipe na metodologia Scrum, faz o trabalho de um coach.
Scrum master da tese. Teoricamente é o coorientador, trata-se de uma pessoa que conhece bem as
técnicas do Scrum. Mas com o passar do tempo, orientador adquirirá estas habilidades e poderá dispensar o coorientador.
É o líder técnico com amplo conhecimento nas metodologias científicas e no Scrum. Age como um guia na metodologia Scrum para apoiar o discente nos rituais, faz o trabalho de coacher.
Scrum Para a Tese
1
Orientar o Product
Owner na criação e