ADAPTAÇÃO DO FRAMEWORK SCRUM EM DISCIPLINAS … · This study had the purpose of making a Scrum...

UNIVERSIDADE FEDERAL DO CEARÁ

CAMPUS QUIXADÁ

BACHARELADO EM SISTEMAS DE INFORMAÇÃO

DANILO ALMEIDA FELIPE

ADAPTAÇÃO DO FRAMEWORK SCRUM EM DISCIPLINAS INICIAIS DE

PROJETO INTEGRADO DO CURSO DE DESIGN DIGITAL

QUIXADÁ

2018


ADAPTAÇÃO DO FRAMEWORK SCRUM EM DISCIPLINAS INICIAIS DE PROJETO

INTEGRADO DO CURSO DE DESIGN DIGITAL

Monografia apresentada no curso de Sistemasde Informação da Universidade Federal doCeará, como requisito parcial à obtenção dograu de bacharel em Sistemas de Informação.Área de concentração: Computação.

Orientadora: Profa. Dra. Tânia Saraivade Melo Pinheiro

QUIXADÁ

2018

Dados Internacionais de Catalogação na Publicação Universidade Federal do Ceará

Biblioteca UniversitáriaGerada automaticamente pelo módulo Catalog, mediante os dados fornecidos pelo(a) autor(a)

F353a Felipe, Danilo Almeida. Adaptação do Framework Scrum em disciplinas iniciais de Projeto Integrado do curso de Design Digital/ Danilo Almeida Felipe. – 2018. 68 f. : il. color.

Trabalho de Conclusão de Curso (graduação) – Universidade Federal do Ceará, Campus de Quixadá,Curso de Sistemas de Informação, Quixadá, 2018. Orientação: Profa. Dra. Tânia Saraiva de Melo Pinheiro.

1. Engenharia de Software. 2. Desenvolvimento de software ágil. 3. Educação (Superior). 4.Interdisciplinaridade. I. Título. CDD 005


ADAPTAÇÃO DO FRAMEWORK SCRUM EM DISCIPLINAS INICIAIS DE PROJETO

INTEGRADO DO CURSO DE DESIGN DIGITAL

Monografia apresentada no curso de Sistemasde Informação da Universidade Federal doCeará, como requisito parcial à obtenção dograu de bacharel em Sistemas de Informação.Área de concentração: Computação.

Aprovada em: / /

BANCA EXAMINADORA

Profa. Dra. Tânia Saraiva de Melo Pinheiro (Orientadora)Universidade Federal do Ceará (UFC)

Prof. Me. Aníbal Cavalcante de OliveiraUniversidade Federal do Ceará (UFC)

Profa. Ma. Antônia Diana Braga NogueiraUniversidade Federal do Ceará (UFC)

AGRADECIMENTOS

À minha família, especialmente minha mãe, por ter sido companheira, compreensiva

e batalhadora e ter formado a pessoa que sou hoje. Te amo, mãe!

À minha orientadora, Profa. Tânia Pinheiro, que me forneceu a melhor orientação

que eu poderia ter. Muito obrigado, Tânia! Palavras não definem o quanto lhe sou grato.

À banca examinadora pelas contribuições neste trabalho, composta pelo Prof. Paulo

Victor na defesa do projeto de pesquisa, Prof. Aníbal Oliveira também presente no projeto de

pesquisa e defesa final e a Profa. Diana Braga que esteve na defesa final, em especial, gostaria

de agradecê-la por ter sido sempre acolhedora e atenciosa desde que a conheci na graduação.

Meu muito obrigado!

Aos meus amigos da Sprint por todo momento de descontração, conforto e compa-

nheirismo compartilhado. Sou grato a todos vocês.

À toda comunidade acadêmica da UFC - Campus Quixadá.

RESUMO

Este trabalho teve como finalidade realizar uma adaptação do framework Scrum para as disci-

plinas iniciais de Projeto Integrado do curso de graduação em Design Digital da Universidade

Federal do Ceará, de modo a tornar o desenvolvimento de projetos em equipe nestas disciplinas

mais formalizado e agradável, além de ser um instrumento para melhor índice de aprovação

nessas disciplinas. Para isso, a metodologia foi pautada em princípios da pesquisa-ação, na qual

o pesquisador conheceu a realidade do ambiente e propõe, em conjunto com o seu represen-

tante, soluções para resolver os problemas de uma realidade. O trabalho teve como resultado

a elaboração de um guia, o framework PiScrum, que foi resultado de uma primeira avaliação

do mesmo perante uma execução no semestre 2018.1. Problemas encontrados nessa avaliação

foram resolvidos a partir de novos subsídios teóricos, e assim foi gerada uma adaptação refinada.

Palavras-chave: Engenharia de Software. Desenvolvimento ágil de software. Educação (Supe-

rior). Interdisciplinaridade.

ABSTRACT

This study had the purpose of making a Scrum framework adaptation for beginning classes of

Integrated Project of undergraduate courses in Digital Design of the Federal University of Ceará,

to make the development of team projects more formalized and pleasant, besides of being an

instrument for a better index of approval in these subjects. The methodology was based on

principles of action research, in which the researcher knows the reality of the environment and

proposes, together with its representant, solutions to solve the problems of such reality. The

study resulted in a guide, the PiScrum framework, which was the result of its first evaluation

before execution in semester 2018.1. Problems encountered in this evaluation were solved from

new theoretical subsidies, and thus a refined adaptation was generated.

Keywords: Software Engineering. Agile Software Development. Higher Education. Interdisci-

plinarity.

LISTA DE ILUSTRAÇÕES

Figura 1 – Ciclo de vida do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figura 2 – Fluxograma dos passos metodológicos . . . . . . . . . . . . . . . . . . . . 28

Figura 3 – Uso do Trello por uma equipe . . . . . . . . . . . . . . . . . . . . . . . . . 36

Figura 4 – Descrição da Reunião de Retrospectiva da Sprint . . . . . . . . . . . . . . . 42

Figura 5 – Sprint 01 visível na ferramenta para cada equipe . . . . . . . . . . . . . . . 42

Figura 6 – Quadro de tarefas da Sprint 01 da Equipe 04 . . . . . . . . . . . . . . . . . 43

Figura 7 – Módulo Problemas da ferramenta Taiga . . . . . . . . . . . . . . . . . . . . 45

Figura 8 – Aplicativo Scrum Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figura 9 – Ciclo de vida do PiScrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

LISTA DE QUADROS

Quadro 1 – Comparação entre os trabalhos relacionados e o presente trabalho . . . . . 25

Quadro 2 – Fases da pesquisa-ação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Quadro 3 – Comparativo de entregáveis . . . . . . . . . . . . . . . . . . . . . . . . . 32

Quadro 4 – Sprints e itens de backlog priorizados . . . . . . . . . . . . . . . . . . . . 33

Quadro 5 – Atende ao Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Quadro 6 – Atende as demandas da disciplina? . . . . . . . . . . . . . . . . . . . . . 38

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Gerenciamento de projetos . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Framework Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3 Cerimônias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Disciplina(s) Projeto Integrado . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Framework eduScrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . 23

3.1 Metodologia do Design para Web: Uma Proposta de Unificação das Me-

todologias Projeto E e Scrum . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Metodologia Scrum como mobilizadora da prática pedagógica: um olhar

sobre a Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . 24

4 PROCEDIMENTOS METODOLÓGICOS . . . . . . . . . . . . . . . . 26

4.1 Descrever atividades da disciplina em consonância ao Scrum . . . . . . 26

4.2 Fazer uma primeira adaptação . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Incluir Scrum no planejamento da disciplina . . . . . . . . . . . . . . . 27

4.4 Planejar e Aplicar o Scrum na disciplina Projeto Integrado I . . . . . . 28

4.5 Adaptação proposta do Scrum para as disciplinas Projeto Integrado I e II 28

5 PRIMEIRA PROPOSTA PARA USO DO SCRUM EM PROJETO I E II 29

5.1 Análise entre Projeto I e Projeto II - PiScrum . . . . . . . . . . . . . . . 30

5.1.1 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1.1.1 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1.1.2 Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1.3 Time de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.3 Cerimônias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Configuração de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . 36

6 APLICAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Sprint 01 - Definição do Problema Social a ser resolvido . . . . . . . . . 40

6.2 Sprint 02 - Definição dos primeiros requisitos da solução . . . . . . . . . 44

6.3 Sprint 03 - Pré-banca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 RESULTADOS E DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . . . 51

7.1 PiScrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.1.1 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.1.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1.3 Cerimônias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . 56

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

APÊNDICE A – CRONOGRAMA PREVISTO PARA PROJETO IN-

TEGRADO II - 2018.2 . . . . . . . . . . . . . . . . . . 61

ANEXO A – CRONOGRAMA DA DISCIPLINA PROJETO INTEGRADO

II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

ANEXO B – DIÁRIO DE AULA DA DISCIPLINA PROJETO INTE-

GRADO I . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

11

1 INTRODUÇÃO

Instituições de Ensino Superior (IES) aplicam esforços para trabalhar de maneira

a simular ambientes reais da sociedade e mercado de trabalho, preparando e formando o perfil

profissional do futuro egresso. Conforme Lei no 9.394, de 20 de dezembro de 1996, as IES

devem estar sempre atualizando as diretrizes curriculares de seus cursos com as tendências mais

relevantes e aplicando-as (BRASIL, 1996).

Como considerado por essa necessidade das IES estabelecida por lei, o presente

trabalho trata da disciplinas Projeto Integrado I e Projeto Integrado II, do curso de graduação em

Design Digital da Universidade Federal do Ceará, modalidade bacharelado, buscando introduzir

em ambiente pedagógico práticas de gerenciamento de projetos de software encontradas no

mercado. Sendo a gestão de projetos de software, uma disciplina da Engenharia de Software

(PRESSMAN, 2011), uma das subáreas da Ciência da Computação (CAPES, 2017; CNPQ,

2017).

A Engenharia de Software tem o objetivo de apoiar o desenvolvimento profissional

de software, incluindo técnicas de apoio a seus projetos desde sua especificação, projeto (de-

sign/planejamento) e evolução do software para obtenção de um produto final com aceitação

por parte do usuário final ou contratante (SOMMERVILLE, 2011). Uma de suas disciplinas é

a gestão de projetos de software, que são geralmente complexos de controlar e necessitam ser

gerenciados, estando sujeitos à mudanças e restrições de diversos tipos, sendo válido ressaltar

que o mau gerenciamento de projetos costumam resultar em falhas diversas, como no escopo,

custo ou prazos (SOMMERVILLE, 2011).

Existem diversos processos de desenvolvimento de software na literatura, cada um

com particularidades e melhor aplicabilidade. Dentre os mais conhecidos estão o modelo Cascata,

o modelo Iterativo e Incremental e o RUP (Rational Unified Process). Embora sejam abordagens

tradicionais, Sommerville (2011) afirma que o requisito de rapidez na entrega de produtos

requerido no cotidiano requer que novas abordagens sejam usadas para apoio em projetos de

software.

As novas abordagens surgiram com o Manifesto Ágil (BECK et al., 2001), uma

resposta aos problemas ocorridos nas abordagens tradicionais de desenvolvimento, sendo uma

filosofia para todos os métodos ágeis existentes. Ele propõe o uso de pequenos ciclos de tempo

para iterações, realizando incremento no produto ou serviço que está sendo produzido, de

forma que há um feedback rápido sobre o mesmo e espaço para respostas rápidas à mudanças

12

(GOMES, 2014). Uma das abordagens ágeis amplamente utilizada no gerenciamento de projetos

de software é o framework Scrum.

A expressão Scrum tem como origem o esporte rúgbi, a qual trata-se de um momento

em que os jogadores realizam uma formação específica. Sendo mais tarde usada de forma

análoga por Nonaka e Takeuchi (1986), em um estudo sobre a adoção de um novo processo de

desenvolvimento de produtos não linear, mas paralelo (iterativo e incremental), em empresas ja-

ponesas. A partir desse estudo, em que os autores relatam os benefícios e sucesso da aplicação do

novo processo, surgiu uma das inspirações para a criação do framework ágil para gerenciamento

de projetos: o Scrum, por Schwaber e Sutherland (2016).

Como campo de estudo deste trabalho, que trata da aplicação de metodologias de

gerenciamento de projetos em meio acadêmico, o curso de Design Digital da Universidade

Federal do Ceará apresenta necessidades de aplicação dessas metodologias, principalmente em

suas disciplinas iniciais de Projeto Integrado, onde elas também tem uma semelhança em sua

metodologia projetual e são desenvolvidos produtos de software. O curso está ligado a área

das Tecnologias da Informação e Comunicação, tendo como perfil de egresso “atua[ção] como

membro de equipes de desenvolvimento de software, sendo responsável pela concepção visual e

funcional das interfaces dos sistemas digitais” (UFC, 2015a).

Dentre os componentes curriculares do curso de Design Digital, existem quatro

disciplinas de Projeto Integrado, nas quais, atividades e conhecimentos das disciplinas feitas em

paralelo (ou anteriormente) são postas em prática para a elaboração e execução de um projeto

(UFC, 2015c). Para gerenciar os variados projetos das disciplinas Projeto Integrado, sentiu-se

a necessidade de aplicação de métodos de gerenciamento de projeto por parte de discentes e

docentes. Sobre estas disciplinas, Monteiro e Sampaio (2017) também sentiram a dificuldade

no estabelecimento e manutenção de sincronia de conteúdos, tal como a organização de um

cronograma em comum entre as disciplinas envolvidas em uma instância da disciplina Projeto

Integrado.

Amplamente utilizado em projetos de software (FUNDAÇÃO DOM CABRAL,

2017), o Scrum é um framework no qual problemas complexos podem ser tratados de forma

adaptativa e produtiva, de modo a gerar valor para um produto entregável. Seu processo de

controle é baseado no empirismo, tendo em seus pilares a transparência, inspeção e adaptação.

O Scrum tem como seus componentes papéis, cerimônias e artefatos, de modo que, seus pilares

são suportados por meio desses componentes (SCHWABER; SUTHERLAND, 2016). Apesar

13

de sua ampla utilização no desenvolvimento de software, o Scrum pode também ser aplicado

em diferentes tipos de projetos que podem ser adaptados ao framework, por exemplo, no campo

educacional (ROCHA; SABINO; ACIPRESTE, 2015; PERSSON et al., 2011), no qual trata este

trabalho, em disciplinas de um curso de graduação onde também são desenvolvidos produtos de

software.

Este trabalho tem como objetivo geral adaptar o framework Scrum para as disciplinas

do curso de Design Digital Projeto Integrado I e Projeto Integrado II. Já os objetivos específicos

consistem em: realizar observações para familiarizar-se com sua estrutura; realizar uma primeira

adaptação e avaliá-la; e também propor um guia para uso posterior nessas disciplinas.

Além dos docentes e discentes envolvidos nas disciplinas, o trabalho dirige-se a

profissionais da educação que tenham dificuldades na aplicação de técnicas de gerenciamento de

projetos, da Engenharia de Software, em suas atividades de orientação de projetos em equipe.

O restante deste trabalho está organizado da seguinte forma. O capítulo 2 apresenta

alguns conceitos utilizados e o capítulo 3 discute trabalhos relacionados. O capítulo 4 detalha

os procedimentos metodológicos. O capítulo 5 apresenta uma primeira proposta e o capítulo 6

sua avaliação por meio de uma aplicação. Por fim, o capítulo 7 apresenta um modelo final e o

capítulo 8 conclui o trabalho.

14

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados os principais conceitos utilizados neste trabalho, ele

está organizado da seguinte forma: na seção 2.1 discorre-se sobre gerenciamento de projetos,

na seção 2.2 aborda-se o framework Scrum, a seção 2.3 mostra como funcionam a disciplinas

Projeto Integrado campo de estudo deste trabalho e por fim, a seção 2.4 aborda rapidamente

sobre o framework eduScrum.

2.1 Gerenciamento de projetos

Projetos são ações aplicadas para a criação de um produto, serviço ou um resultado

exclusivo, por sua natureza são temporários, chegando em seu término ao atingir metas ou

encerramento por forças maiores. Cada projeto é composto de esforços e resultados singulares

e distintos, que por sua vez, os tornam complexos e difíceis de conduzir. O gerenciamento de

projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades de

projetos para que metas sejam alcançadas (PROJECT MANAGEMENT INSTITUTE, 2013).

Devido à natureza complexa do gerenciamento dos projetos, foram elaborados

diversos guias, modelos e processos para fins de apoio dessas atividades de gerência. Um

exemplo é o Project Management Body of Knowledge (PMBoK) do Project Management Institute

(2013), que abrange boas práticas que podem ser aplicadas em todas as áreas do gerenciamento

de projetos (risco, custo, comunicação, recursos humanos, dentre outras). No entanto, o PMBoK

identifica-se como um guia de boas práticas, embora flexível quanto ao seu uso, é extenso e de

grande documentação.

Entretanto, quando se discute sobre gerenciamento de projetos no desenvolvimento

de software, área de atuação do egresso em Design Digital, as abordagens de gerenciamento ágil

são bastante discutidas (CRUZ, 2013).

Abordagens ágeis nasceram de inspirações no ciclo Plan-Check-Study-Act (PDSA),

que vem da proposta de aplicar método científico para adquirir conhecimento sobre o processo de

produção, visando sua melhoria contínua. Dessa ideia de melhoria contínua, surge a abordagem

de desenvolvimento iterativo e incremental. A Toyota, uma empresa japonesa, utilizou dessa

proposta para a criação do conhecido Sistema Toyota de Produção, também chamado de Lean

Manufacturing (RIGBY; SUTHERLAND; TAKEUCHI, 2016), que veio a inspirar mais empresas

japonesas posteriormente.

15

Em projetos de software percebeu-se uma grande necessidade de respostas rápidas a

mudanças, por conta do uso intensivo de aplicações de software por corporações que viriam a usá-

las em meio a questões competitivas e de sobrevivência no mercado. Dá-se maior importância

para entregas rápidas e com possibilidades de mudanças, do que à construção demorada de

aplicações completas que se tornariam inúteis devido às inconstâncias do mundo dos negócios e

requisitos (SOMMERVILLE, 2011).

Diante dessa necessidade surgiu o Manifesto Ágil por Beck et al. (2001), que vai ao

contrário de abordagens tradicionais, burocráticas e demoradas de desenvolvimento de software.

Tem como principais valores:

1) Indivíduos e interações mais que processos e ferramentas;2) Software em funcionamento mais que documentação abrangente;3) Colaboração com o cliente mais que negociação de contratos;4) Responder a mudanças mais que seguir um plano.

[...] mesmo havendo valor nos itens à direita, valorizamos mais os itens àesquerda (BECK et al., 2001).

Partindo dos valores do Manifesto Ágil, novos modos de gerenciar o desenvolvimento

de software foram propostos: os métodos ágeis, que vem mostrando-se bem-sucedidos para

desenvolvimento de produtos de software de pequena ou média escala, seja para venda de

prateleira ou para um cliente. Como todo processo profissional de construção do software, o

desenvolvimento ágil deve ser gerenciado para uso eficiente de tempo e recursos, demandando

abordagens diferentes e de modo iterativo e incremental conforme os valores do Manifesto Ágil

para respostas à mudanças e interações (SOMMERVILLE, 2011).

Uma das abordagens ágeis mais utilizadas atualmente no desenvolvimento e ge-

renciamento de projetos de software é o framework Scrum (FUNDAÇÃO DOM CABRAL,

2017). A expressão Scrum parte da inspiração do esporte rúgbi, onde os jogadores realizam

uma formação para recuperar a bola de um aglomerado. Ela passou a ser usada por Nonaka e

Takeuchi (1986) em seu estudo sobre a adoção de um novo processo de desenvolvimento de

produtos não linear, mas em paralelo (iterativo e incremental) em empresas japonesas e relatos

de benefícios e sucessos da aplicação desse novo tipo de desenvolvimento.

Apesar da utilização do Scrum em projetos de software, existem aplicações no

desenvolvimento em outros tipos de produtos e ambientes (SUTHERLAND, 2016). Para

o presente trabalho, será realizada uma adaptação e aplicação do framework em ambiente

pedagógico de sala de aula, em disciplinas de curso de graduação onde são realizados muitos

16

projetos de estreita relação com o desenvolvimento de software. Visando facilitar a gerência

desses projetos e ainda promover o uso de um recurso relevante para o mercado. Na seção

seguinte aborda-se sobre o framework Scrum, de acordo com seus criadores, Schwaber e

Sutherland (2016).

2.2 Framework Scrum

O Scrum é um framework no qual problemas complexos e adaptativos podem ser

tratados de forma produtiva e criativa gerando alto valor para um produto entregável. Fundamen-

tado em teorias empíricas de controle de processo, de modo que o conhecimento é gerado de

experiências e tomadas de decisão em algo conhecido (SCHWABER; SUTHERLAND, 2016).

Um conhecimento gerado no Scrum é um conhecimento aplicado e não apenas tácito. Por

processo empírico, entende-se um processo executado e ajustado com base em experiências

práticas.

O Scrum não é uma metodologia (como tratado algumas vezes na literatura), mas

sim um framework, abordagem utilizada neste trabalho. Por metodologia, entende-se algo a ser

seguido da forma que foi definido. Já por framework, uma estrutura de conceitos e técnicas que

podem ser adaptadas, podendo-se empregar técnicas externas. No Scrum, permite-se utilizar

técnicas e métodos de gerenciamento de projetos externos no desenvolvimento de produtos para

aperfeiçoá-los, seu processo é iterativo e incremental (SCHWABER; SUTHERLAND, 2016).

Por se tratar de algo com base em processos empíricos, o Scrum funciona sob três

pilares (SCHWABER; SUTHERLAND, 2016), são eles:

a) Transparência – características do processo devem estar disponíveis aos respon-

sáveis pelos resultados;

b) Inspeção – na aplicação do Scrum, seus usuários devem frequentemente verificar

os artefatos e progressos a fim de detectar variações;

c) Adaptação – o processo e/ou produto deve ser ajustado o mais breve possível ao

notar-se divergências e/ou que o produto não será aceito.

Para que transparência, inspeção e adaptação aconteçam, o framework Scrum define

papéis, artefatos e cerimônias (SCHWABER; SUTHERLAND, 2016) detalhadas nas subseções

a seguir.

17

2.2.1 Papéis

O time Scrum é estabelecido pelos papéis do Product Owner, Scrum Master e

Time de Desenvolvimento. O time deve ser auto organizável e multifuncional, de modo que o

ele define a melhor maneira para trabalhar e possui o conhecimento necessário para completar

seu trabalho (SCHWABER; SUTHERLAND, 2016). Segundo Schwaber (2009), caso algum

membro do time Scrum não detenha as habilidades necessárias para realizar seu trabalho, o

mesmo deve capacitar-se para executá-lo.

O Product Owner é o responsável por potencializar o valor do produto que está

sendo desenvolvido e o trabalho do Time de Desenvolvimento. O Product Owner é também res-

ponsável por gerenciar clientes e partes interessadas de um produto que está sendo desenvolvido,

representando todos eles e sendo o responsável por gerenciar o artefato Product Backlog (ver

subseção 2.2.2), definindo seus itens, priorizando-os e tornando o artefato visível para o time

Scrum de maneira clara e transparente. Ele pode também delegar a realização de suas atividades

de gerenciamento do artefato para o Time de Desenvolvimento, no entanto, continua sendo o

principal responsável (SCHWABER; SUTHERLAND, 2016).

O Scrum Master é o responsável por garantir o entendimento do Scrum e sua

aplicação, de modo que o time siga à teoria,as práticas e as regras do Scrum (SCHWABER;

SUTHERLAND, 2016). Ele apoia o Product Owner e Time de Desenvolvimento a serem mais

eficientes na realização de seu trabalho, fazendo com que haja boa comunicação e ocorrência das

cerimônias do Scrum, além de prevenir e remover impedimentos. Deve ser presente, observador,

proativo e capaz de lidar bem com pessoas (SABBAGH, 2014).

O Time de Desenvolvimento é composto por um conjunto de quatro a oito profissi-

onais que possuem habilidades para trabalhar em versões do produto potencialmente utilizável

de modo iterativo e incremental em eventos chamados Sprints (ver subseção 2.2.3). Eles pos-

suem total autonomia sobre como transformar o Product Backlog nesse produto potencialmente

utilizável (SCHWABER; SUTHERLAND, 2016).

2.2.2 Artefatos

Para fins de transparência, o Scrum aborda o uso de artefatos: Product Backlog e

Sprint Backlog. Decisões sobre o produto que está sendo desenvolvido são tomadas com base

no estado desses artefatos, que precisam ter uma base sólida para ocorrências de inspeções

18

e adaptações. Em sequência, são definidos os artefatos presentes no Scrum (SCHWABER;

SUTHERLAND, 2016).

O Product Backlog contém todos os requisitos do produto. Este artefato está em

constante evolução, e seus itens são ordenados por prioridade de desenvolvimento, possuindo

atributos de descrição, ordem, valor e estimativa. Sendo o Time de Desenvolvimento responsável

pela configuração do último atributo, com auxílio do Product Owner para melhor entendimento

e refinamento dos itens.

O Sprint Backlog é composto de itens de Product Backlog que foram selecionados

para uma Sprint. Deve ser detalhado suficientemente bem para que o progresso seja observado

em reuniões diárias e, para isso, o Sprint Backlog é alterado ao se entender cada vez mais o

trabalho necessário para atingir a meta da Sprint.

2.2.3 Cerimônias

De acordo com Schwaber e Sutherland (2016), as cerimônias do Scrum são eventos

pré-definidos que devem acontecer de forma rotineira, evitando-se o acontecimento de reuniões

extras que porventura causariam ineficiência no modo de gerenciar o desenvolvimento do produto.

Essas cerimônias possuem tempo de duração máximo estabelecido, que varia em diferentes

aplicações do framework. As cerimônias são descritas nos parágrafos a seguir.

As Sprints, “coração do Scrum”, são eventos com duração máxima de um mês; ela

é a cerimônia que abriga as outras cerimônias do Scrum. Tem, como objetivo, um incremento do

produto potencialmente utilizável (ou entregável) trabalhado de acordo com o que foi definido

no artefato Sprint Backlog, o que permite adaptação e inspeção do progresso do trabalho, que

evita e limita possíveis riscos e prejuízos ao tempo de duração da Sprint.

As Sprints são precedidas por uma reunião de planejamento, e finalizadas com uma

revisão seguida de retrospectiva (SCHWABER; SUTHERLAND, 2016).

A Reunião de planejamento da Sprint é o evento que ocorre ao início de cada

Sprint com a garantia do Scrum Master. Foca-se na definição dos objetivos da Sprint em conjunto

com todo o time Scrum, debatendo-se e estabelecendo-se qual o trabalho será necessário para

completar a Sprint de acordo com a priorização dos itens de Product Backlog, que foram definidos

pelo Product Owner e Equipe de Desenvolvimento, chamados de Sprint Backlog (subseção

2.2.2), estes itens priorizados serão o único trabalho da Equipe de Desenvolvimento durante

a Sprint para atingir o objetivo da mesma. A reunião tem, como entradas: o Product Backlog

19

atualizado; o incremento do produto potencialmente utilizável da Sprint anterior, caso exista; a

capacidade estimada da Equipe de Desenvolvimento; e informações do seu desempenho passado.

A Revisão da Sprint é uma reunião realizada informalmente no fim de uma Sprint

para inspeção e apresentação do produto potencialmente utilizável, o que foi feito de acordo

com a Sprint Backlog. A reunião é realizada em conjunto com o time Scrum e possíveis partes

interessadas, visando feedback para otimização da próxima Sprint e atualizações no Product

Backlog.

A Retrospectiva da Sprint ocorre após a Revisão da Sprint e trata de uma auto

avaliação do time Scrum e de estabelecer planos de melhorias para a próxima Sprint. A auto

avaliação aborda uso das ferramentas, processos e relacionamentos de modo a torná-los mais

efetivos e prazerosos. Implantar essas melhorias é uma forma do time Scrum realizar inspeção e

adaptação de si mesmos.

Além da Sprint, seu planejamento, revisão e retrospectiva, há a Reunião Diária.

Esta cerimônia é um evento com duração de até quinze minutos que reúne diariamente a Equipe

de Desenvolvimento para inspeção do que foi realizado no dia de trabalho, o que será realizado

no próximo dia e impedimentos observando o que atrapalhe o desempenho da Sprint, realizando

assim uma sincronização de atividades entre os membros do time. A Equipe de Desenvolvimento

é a única responsável por conduzir a reunião, no entanto, o Scrum Master é o responsável pelo

acontecimento da mesma. São realizadas adaptações no trabalho de acordo com necessidades

observadas nessa reunião.

A Figura 1 ilustra o ciclo de vida do Scrum de acordo com os conceitos estabelecidos

por Schwaber e Sutherland (2016).

Figura 1 – Ciclo de vida do Scrum

Fonte: adaptado de sitecampus.com.br

20

2.3 Disciplina(s) Projeto Integrado

No curso de Design Digital da Universidade Federal do Ceará, existem quatro

disciplinas denominadas Projeto Integrado (I, II, III e IV) ofertadas do terceiro ao sexto semestre

do curso. Em cada uma delas, tem-se a elaboração de um projeto prático e interdisciplinar, em

que seu tema deve seguir seu identificador: I - ênfase no usuário; II - ênfase no produto; III -

ênfase nos processos; IV - ênfase em negócios e inovação. Todas possuem carga horária de 64

horas em 4 horas de aula por semana, totalizando-se 16 semanas de aula. (UFC, 2015c)

As disciplinas Projeto Integrado não contém conteúdo próprio, possuindo como

co-requisito algumas outras ofertadas no mesmo semestre. Tendo como critério de avaliação a

criação de um projeto que utilize o conhecimento destas disciplinas em co-requisito com caráter

interdisciplinar. Para este trabalho, são consideradas as disciplinas Projeto Integrado I e Projeto

Integrado II, doravante denominadas Projeto I e Projeto II, que respectivamente, são o campo de

estudo.

Em Projeto I, ofertada no terceiro semestre do curso, tem-se como co-requisito as

disciplinas: Interação Humano-Computador e Semiótica. No mesmo semestre também são

ofertadas Modelagem Tridimensional e Sociedade, Culturas e Tecnologias (UFC, 2015b) que

não são co-requisitos de Projeto I, mas em prática tem seus conhecimentos utilizados.

Do mesmo modo, Projeto II, que é ofertada no quarto semestre do curso, tem como

co-requisitos são: Linguagens de Marcação e Scripts e Direção de Arte. No mesmo semestre

também são ofertadas Avaliação da Interação Humano-Computador e Comunicação Visual I

(UFC, 2015d).

Ao início de período letivo de oferta de cada uma dessas disciplinas, professores

e alunos definem um grande-tema para os projetos a serem realizados, por exemplo: projetos

sociais. Também é feita a organização de equipes para trabalho em diferentes projetos e se

conversa sobre um cronograma pré-definido pelo professor-orientador, para finalização de

diferentes entregáveis de cada projeto como um todo. Os entregáveis da disciplina são1:

a) Briefing - descrição em documento da solução à ser desenvolvida, contém as

diretrizes que o cliente estabelece para o produto;

b) Proposta de Desenvolvimento Projetual (PDP) - a partir do Briefing, o PDP

contém o estudo de como se chegará a solução, como por exemplo, as cores à

serem utilizadas;1 Fonte: alunos e professora da disciplina Projeto Integrado II, 2017.2, confirmado em observações em 2018.1

21

c) Plano Executivo - um detalhamento do PDP, contém a documentação completa

do projeto. Deve conter tudo o que se precisaria para se refazer o projeto;

d) Artigo - um artigo científico em formato acadêmico;

e) Protótipo de um produto (Projeto I), website implementado (Projeto II);

f) Material de divulgação - trata-se de caixa física para acomodar entregáveis

produzidos na disciplina;

g) Acervo - corresponde ao conjunto de todos os arquivos relacionados à pesquisas

de fundamentação e aos demais entregáveis dos projetos.

Todos esses entregáveis são criados em equipe, de modo iterativo e incremental e de

entrega obrigatória, com cada parte sendo feita de acordo com o conteúdo ministrado nas demais

disciplinas co-requisito. Os entregáveis são todos relacionados entre si, alguns desenvolvidos

simultaneamente por diferentes membros das equipes, o que torna clara a necessidade de se

dispor técnicas que possibilitem o gerenciamento do projeto de forma estruturada.

Um dos problemas notados em uma instância de Projeto Integrado é a ocorrência

de dificuldades de sincronização de conteúdos entre todas as disciplinas (MONTEIRO; SAM-

PAIO, 2017), causando casos redundantes nas entregas em comum entre Projeto Integrado e as

disciplinas em paralelo. Nota-se, portanto, a necessidade de mecanismos e técnicas para anular

ocorrências como essas. Além de geralmente haver uma numerosa quantidade de alunos/equipes

nessas disciplinas.

2.4 Framework eduScrum

O framework eduScrum é uma adaptação do Scrum criada por Delhij, Solingen e

Wijnands (2016) e posteriormente revisada por Sutherland, um dos criadores do Scrum. Ele

tem como origem experiências em escolas holandesas de ensino fundamental e médio. Embora

os dois frameworks possuam estrutura muito similar a principal diferença é o foco no que é

entregue: O eduScrum tem foco totalmente educacional e voltado ao aprendizado, diferente do

Scrum, que tem seu foco voltado para desenvolvimento de produtos.

Essencialmente, o eduScrum difere do Scrum nas cerimônias, que ocorrem todas em

tempo de sala de aula. Em relação aos artefatos, estão relacionados a objetivos de aprendizagem,

e são definidos previamente pelo professor.

A proposta deste trabalho, denominada PiScrum, consiste na busca por conciliar os

dois focos: aprendizado e entrega de produto para um cliente. Por ter sua estrutura voltada a edu-

22

cação, utiliza elementos do eduScrum. Também se fundamenta em elementos do Scrum porque

trata da elaboração de produtos potencialmente utilizáveis (websites responsivos, protótipos de

alto nível, aplicativos móveis ...), no qual denominamos entregáveis a clientes potencialmente

reais.

23

3 TRABALHOS RELACIONADOS

Neste capítulo são apresentados os trabalhos relacionados que foram utilizados como

base e motivação para o presente trabalho.

3.1 Metodologia do Design para Web: Uma Proposta de Unificação das Metodologias

Projeto E e Scrum

Dantas e Santos (2016) discutem metodologias usadas em projetos de design voltados

para web no âmbito acadêmico do ensino superior e comparam-nas com as mais usadas no

mercado de trabalho, já que, segundo as autoras, o ambiente acadêmico está sempre à procura

de tendências que são usadas em demandas da sociedade para aplicação. Por meio de uma

ferramenta de pesquisa questionário, aplicado com acadêmicos e profissionais de design, foi

obtido que a metodologia de projetos de design Projeto E1 e Scrum são as mais utilizadas nos

dois ambientes em projetos de design voltados para a web.

Por final, comparam as características das duas e propõem uma unificação chamada

Projeto E - Scrum, dando ênfase ao que cada uma apresenta de melhor. Projeto E, é composta de

seis fases não sequenciais e não obrigatórias, são elas Estratégia, Escopo, Estrutura, Esqueleto,

Estética e Execução. A unificação se dá por categorização dessas fases em Sprints do Scrum e

dentro das Sprints o acontecimento de cerimônias e criação/refinamento de artefatos estabelecidos

no Scrum.

Neste trabalho, em vez da metodologia Projeto E, se propõe a identificar e analisar

a disciplinas Projeto I e Projeto II, seu campo de estudo, e adequá-las ao Scrum de forma

semelhante à unificação proposta em Dantas e Santos (2016). Conhecendo-se previamente como

funcionam essas disciplinas e após isso, adaptando-se papéis, cerimônias e artefatos de acordo

com o Scrum. Ressalta-se que as disciplinas Projeto I e II não possuem metodologia projetual

formalizada nem foco em Design para Web como no trabalho relacionado. Os projetos são

realizados de acordo com conhecimentos obtidos nas disciplinas co-requisito.1 Disponível em: http://projetoe.com

24

3.2 Metodologia Scrum como mobilizadora da prática pedagógica: um olhar sobre a

Engenharia de Software

Rocha, Sabino e Acipreste (2015), por síntese, reconhecem que propostas pedagógi-

cas devem estar inseridas em ambiente colaboração, compartilhamento, autonomia e experimen-

tação. De modo que o professor, no papel de orientador, possa prover aos seus alunos cenários e

meios para experimentar soluções de maneira que a participação seja efetiva e com articulação

de ideias. Tais providos estão presentes na aprendizagem cooperativa.

Partindo da aprendizagem cooperativa, o uso de metodologias que visam o processo

de ensino aprendizagem centrada no aluno, envolvendo dinâmicas, ambientes e contextos que

proporcionem interação e criatividade, a metodologia de gerenciamento de projetos Scrum

apresenta-se como alternativa para práticas pedagógicas rica em recursos e modelos para geren-

ciamento de projetos. Rocha, Sabino e Acipreste (2015) afirmam que, sendo objeto de estudo

na educação, a aplicação do Scrum indica uma aprendizagem significativa do aluno para outras

situações de sua vida.

Por fim, Rocha, Sabino e Acipreste (2015) investigam, com base na discussão de

aprendizagem apresentada e da metodologia de projetos Scrum como ferramenta para aprendi-

zado, a aplicação da mesma em uma disciplina de Engenharia de Software em uma turma de

ensino técnico profissionalizante em Informática. Tendo essa sido escolhida devido a sua ementa

conter estudos sobre processos de desenvolvimento de software, possibilitando a aplicação

do Scrum. Por observação e investigação na turma selecionada, concluiu-se que a aplicação

do Scrum na disciplina mostra-se potencialmente adequada para incentivo da aprendizagem,

promovendo o protagonismo do estudante na sua própria aprendizagem e no coletivo.

A semelhança com o presente trabalho vem ser a real aplicação do Scrum na sala de

aula. Tomando como referência as horas/aula de disciplina e realização dos eventos do Scrum, no

trabalho de Rocha, Sabino e Acipreste (2015) o campo de estudo tem uma disciplina de caráter

intensivo com 60 horas/aula sendo 20 horas/semana, o do presente trabalho aborda uma de 64

horas/aula sendo 4 horas/semana.

Tomando por base a referência de Sprints a cada 3 dias do trabalho relacionado, e

uma regra de três simples, pode-se configurar Sprints na aplicação do presente trabalho a cada 3

semanas aproximadamente. A definição de papéis é semelhante no trabalho relacionado, pois o

Product Owner mostrado é o professor, mas se diferencia com o presente trabalho que configura

organizações encontradas em pesquisa de campo como subsídio para definição do foco dos

25

projeto trabalhados pelas equipes ao invés de ter apenas o desejo do professor (como cliente

fictício) refletido no que é desenvolvido, não tornando uma abordagem do trabalho relacionado

suficiente.

O Quadro 1 apresenta as similaridades e as diferenças dos trabalhos citados neste

capítulo com o presente trabalho, com relação às suas principais características.

Quadro 1 – Comparação entre os trabalhos relacionados e o presente trabalho

TrabalhosCaracterísticas Adaptação do Scrum

no âmbito educacional?Utiliza metodologiaprojetual?

Adaptação realizada éavaliada?

Dantas e Santos (2016) não. sim, Projeto E. não, apenas em trabalhosfuturos.

Rocha, Sabino e Aci-preste (2015)

sim, no ensino profissio-nalizante.

não. sim, os autores afirmamsucesso.

Felipe (2018) sim, no ensino superior. sim, embora não forma-lizada.

sim, em execução.

Fonte: elaborado pelo autor.

26

4 PROCEDIMENTOS METODOLÓGICOS

Neste capítulo são descritos os passos necessários para a realização deste trabalho.

A metodologia seguiu princípios da pesquisa-ação que, associando pesquisa com ação social,

visa gerar conhecimentos a partir de ações de caráter social. Thiollent (2004) relaciona alguns

possíveis objetivos de conhecimento potencialmente alcançáveis pela pesquisa-ação, dentre os

quais destacam-se para este trabalho:

a) A produção de guias ou de regras práticas para resolver os problemas e planejar

as correspondentes ações;

b) Os ensinamentos positivos ou negativos quanto à conduta de ação e suas condi-

ções de êxito.

Na concepção da pesquisa-ação, o estudo da relação entre saber formal e saber

informal visa estabelecer comunicação entre dois universos culturais: o dos interessados e dos

especialistas (THIOLLENT, 2004). Nesta pesquisa, uma professora de Projeto Integrado repre-

senta o grupo de interessados e o pesquisador corresponde ao especialista que faz a articulação

entre a prática observada e a teoria relacionada à gerência de projetos.

A primeira coluna do Quadro 2 relaciona as fases ou temas gerais da pesquisa-ação

definidas por Thiollent (2004) como flexíveis e reordenáveis, e a segunda coluna uma descrição

já considerando o contexto de aplicação neste trabalho. A terceira coluna do referido Quadro

contém uma descrição da fase já considerando sua aplicação ao realizável neste estudo.

4.1 Descrever atividades da disciplina em consonância ao Scrum

Este passo tem objetivo de se conhecer a estrutura das disciplinas Projeto I e II e

familiarizar-se com as mesmas, descobrindo problemas e propondo-se a organização de papéis,

cerimônias e artefatos em consonância ao Scrum.

Ele foi realizado por meio de observação não participante (MARCONI; LAKATOS,

2010) na disciplina Projeto II (UFC, 2015d), bastante semelhante em estrutura com a disciplina

Projeto I que foi campo de aplicação e avaliação deste trabalho. A observação ocorreu no período

de agosto a outubro de 2017.

27

Quadro 2 – Fases da pesquisa-ação

FASES DAPESQUISA-AÇÃO

DESCRIÇÃO REALIZADO

Fase exploratória. For-mulação do tema.

Definir o campo da pesquisa e oproblema a ser solucionado.

Foi definida a aplicação de metodologias de ge-rência de projetos para melhorar o desempenhode equipes em Projeto Integrado.

Campo de observação. Delimitação do campo de estudoe ação.

Foi delimitado inicialmente Projeto I, depois am-pliado também para Projeto II.

Colocação dos proble-mas. O lugar da teoria.

Delinear problemas sob umaperspectiva teórica.

Descrito na seção 4.1 Descrever atividades dadisciplina em consonância ao Scrum.

Seminários. Eventos periódicos de planeja-mento e avaliação da ação.

Reuniões semanais entre pesquisador e profes-sora participante.

Hipóteses. Hipótese de solução. Descrito nas seções: 4.2 Fazer uma primeiraadaptação e 4.3 Incluir Scrum no planejamentoda disciplina.

Coleta de dados. Apren-dizagem. Plano de ação.

Coleta de Dados que retroali-menta o planejamento da ação.As ações são necessariamenteobservadas, gerando novas infor-mações para orientar as ações.

Descrito na seção: 4.4 Aplicar o Scrum na disci-plina Projeto Integrado.

Saber formal e saber in-formal.

Articulação do saber formal (pes-quisador) e saber informal (par-ticipante)

Descrito na seção: 4.5 Modelagem final doScrum para a disciplina Projeto Integrado I.

Divulgação externa. - Publicação em monografia.Fonte: elaborado pelo autor.

4.2 Fazer uma primeira adaptação

Este passo visa realizar uma primeira adaptação dos papéis, cerimônias e artefatos

de acordo com o Scrum e cronograma do semestre da disciplina Projeto I do semestre seguinte

(2018.1). Para isso, foram realizadas reuniões semanais com a professora participante (repre-

sentante do grupo de interessados) deste trabalho, na ocasião lecionando a disciplina Projeto II.

Foram utilizados os documentos: planilha com cronograma de acompanhamento (Anexo A),

lista dos entregáveis (ver subseção 2.3) e suas respectivas descrições.

4.3 Incluir Scrum no planejamento da disciplina

Neste passo é realizada uma análise de ferramentas que possam auxiliar nas ativi-

dades do gerenciamento dos projetos usando o Scrum na disciplina. Visando melhor acom-

panhamento por parte do professor-orientador e times Scrum, além de apoiar os pilares do

Scrum.

A seleção das ferramentas foi realizada logo após o término do semestre 2017.2,

estando disponível para uso pela turma de Projeto I no semestre 2018.1. O procedimento de

28

seleção consistiu de ampla pesquisa por ferramentas gratuitas de gerência de projetos e tabulação

de suas características de forma a identificar qual a mais adequada à disciplina, conforme técnica

para comparação de produtos descrita em Wazlawick (2014).

4.4 Planejar e Aplicar o Scrum na disciplina Projeto Integrado I

O detalhamento do planejamento da aplicação foi realizado em conjunto com o

planejamento dos professores da disciplina Projeto I.

A aplicação da adaptação Scrum na disciplina foi realizada durante o semestre letivo

de 2018.1, e foram realizadas observações participantes (MARCONI; LAKATOS, 2010) durante

as aulas do semestre, acompanhando as atividades dos docentes e estudantes da disciplina.

Observações foram registradas em diário de campo, de modo a prover subsídios para a análise

da aplicação.

4.5 Adaptação proposta do Scrum para as disciplinas Projeto Integrado I e II

Próximo ao final do semestre, foi realizada a documentação final da proposta de

modelo para uso do Scrum nas disciplinas Projeto I e II. A adaptação, chamada PiScrum, foi

construída de forma iterativa por meio das reuniões semanais com a professora representante ao

longo do semestre.

A Figura 2 exibe um fluxo dos passos metodológicos divididos em duas maiores

etapas: Proposta e Aplicação.

Figura 2 – Fluxograma dos passos metodológicos


29

5 PRIMEIRA PROPOSTA PARA USO DO SCRUM EM PROJETO I E II

Este capítulo trata sobre uma primeira proposta para uso do Scrum nas disciplinas

iniciais de Projeto Integrado. Para construí-la, foi realizada uma observação não participante

(MARCONI; LAKATOS, 2010) na disciplina Projeto II ofertada no semestre letivo de 2017.2,

bastante semelhante com a disciplina Projeto I. A principal diferença entre elas, relevante para

este trabalho, está no entregável Protótipo que em Projeto II passa a ser uma implementação

front-end de um website e sua avaliação da Interação Humano-Computador, além da ênfase que

muda do usuário para o produto (UFC, 2015b; UFC, 2015d).

Todos os entregáveis foram construídos no decorrer de Projeto II, com suporte das

disciplinas lecionadas em paralelo para a mesma turma da disciplina: Avaliação da Interação

Humano-Computador, Linguagem de Marcação e Scripts, Comunicação Visual I e Direção de

Arte. Em sequência, discorre-se uma visão preliminar a partir da observação e também a primeira

adaptação do Scrum realizada, que será chamada PiScrum.

O objetivo inicial deste trabalho era a aplicação do framework Scrum em sua estrutura

original nas disciplinas iniciais de Projeto Integrado, porém, conforme observações, foi seguido

um caminho diferente: foi optado elaborar uma nova maneira de aplicá-lo. Princípios do guia

do Scrum (SCHWABER; SUTHERLAND, 2016) e do guia eduScrum (DELHIJ; SOLINGEN;

WIJNANDS, 2016) foram utilizados, tornando uma abordagem nova e híbrida entre os dois

guias.

As disciplinas iniciais de Projeto Integrado são as primeiras do componente curricular

de Design Digital nas quais os alunos experienciam a criação mais formalizada de um projeto

em equipe. Principalmente em Projeto I, que geralmente possui numerosa quantidade de alunos.

No semestre de aplicação da pesquisa (2018.1) foram cinquenta e um alunos matriculados.

Devido a essa numerosa quantidade, a coordenação do curso alocou dois professores para melhor

acompanhamento. Na subseção seguinte, é abordado como a adaptação do Scrum foi realizada e

os motivos que levaram a cada escolha.

A adaptação proposta foi planejada no período compreendido entre as observações

de Projeto II e o mês de janeiro de 2018, para ser avaliada e refinada em uma aplicação em

Projeto I.

30

5.1 Análise entre Projeto I e Projeto II - PiScrum

Na primeira aula em Projeto II, a professora da disciplina sugeriu à turma que os

projetos seguissem um metatema: projetos sociais para a comunidade. Foi discutido o que

poderia ser feito para levantar informações para pesquisa de campo como, por exemplo, procurar

instituições, ONGs e demais locais que necessitam de um produto/solução tecnológica em acordo

com o contexto da disciplina: um front-end de website implementado. Quatro equipes foram

formadas de um total de vinte e um alunos e em aulas posteriores, para cada equipe, informações

foram trazidas das organizações visitadas e possíveis soluções foram abordadas. Nas aulas

consecutivas mais observações foram feitas e analisadas como resultado preliminar, as subseções

seguintes abordam uma discussão sobre esses resultados.

5.1.1 Papéis

5.1.1.1 Product Owner

Nos resultados preliminares, havia-se notado a potencial aplicação do papel do

Product Owner em algum integrante de cada equipe, sendo ele o responsável por representar

desejos dos potenciais clientes de pesquisa de campo e demais partes interessadas (como

o professor-orientador da disciplina) de um apanhado de entregáveis da disciplina a serem

desenvolvidos.

No entanto, em 2018.1 uma mudança em Projeto I mudou essa visão – foram

alocados dois professores-orientadores para a disciplina – sendo preferido torná-los os Product

Owners das equipes na disciplina. O formato educacional do guia eduScrum permite que mais

de uma pessoa possua este papel: “[...] No caso de projetos integradores, as equipes poderão ter

até ter vários Product Owners, um por tema.” (DELHIJ; SOLINGEN; WIJNANDS, 2016, p. 9).

Ambos os guias, Scrum e eduScrum, descrevem o papel como responsável por potencializar o

produto que está sendo desenvolvido por meio do trabalho do Time de Desenvolvimento, além

de representar partes interessadas e gerenciar o artefato Product Backlog.

Em Projeto I, por possuir ênfase no usuário e a disciplina Interação Humano-

Computador como co-requisito, são também realizadas pesquisas de campo como meio de

prover dados e elementos de estudo para elaboração do projeto com foco no usuário. Nestas

pesquisas de campo, equipes podem encontrar clientes e propor uma solução de uma aplicação

/ sistema de informação, ou fundamentação para uma ideia do projeto por meio de protótipos,

31

sejam eles de baixa, média ou alta fidelidade. No entanto, a pesquisa de campo e definição de

cliente foram consideradas uma forma de descrever como serão feitas atividades da disciplina.

Foi desconsiderado tornar este cliente alguém representado por algum Product

Owner ou o próprio, seja(m) ele(s) professor(es) ou integrante de equipe, uma vez que o produto

(protótipo) dificilmente volta para o cliente de alguma forma para obtenção de feedbacks. A

dinâmica e carga horária da(s) disciplina(s) inviabiliza(m) retornos à pesquisas de campo. Esse é

dos problemas identificados na disciplina durante a pesquisa, embora o preferível é que se tenha

a presença frequente do cliente de campo durante toda a extensão da disciplina para que no final

ele receba um produto potencialmente utilizável.

5.1.1.2 Scrum Master

Em resultados preliminares vindos da observação em Projeto II, a professora da

disciplina foi vista como facilitadora e orientadora das equipes nos projetos e seus entregáveis,

usando de maneiras próprias na tentativa de gerenciar os projetos das quatro equipes, relembrando

cronograma e demais assuntos relacionados à entregas com certa frequência, além de realizar

orientação. Notou-se anteriormente a potencial aplicabilidade do papel de Scrum Master ao

professor para Projeto I no semestre seguinte.

Entretanto, o professor enquanto Scrum Master não estaria de fato imerso no acom-

panhamento dos projetos de todas as equipes como se deseja. Nem estaria presencialmente

em todos as suas cerimônias para reforçar que as mesmas sigam às teorias, regras e práticas

aderentes do Scrum, houve também a diferença de vinte e quatro para cinquenta e um alunos

entre Projeto I e II. A melhor opção foi tornar um integrante de cada equipe o Scrum Master.

Ainda assim, deduziu-se que atribuir carga de responsabilidades e conceitos do

Scrum (como cultura) de uma só vez em alunos inexperientes seria difícil. O eduScrum descreve

que responsabilidades do Scrum Master são inicialmente acumuladas com as do Product Owner

(professor) e repassadas pouco a pouco para o Scrum Master definido: um integrante de equipe

(DELHIJ; SOLINGEN; WIJNANDS, 2016). Foi optado por seguir essa abordagem.

Sendo assim, proposto que as equipes seriam orientadas pelo professor (Product

Owner), aos poucos, em sala de aula para que algum integrante fixo de cada equipe (Scrum

Master) relembre acontecimentos das cerimônias, práticas e cuidado com atualizações dos

artefatos. Não segue-se nenhum processo específico para a seleção deste papel, os alunos com

maior perfil de liderança poderiam ao poucos assumí-lo.

32

5.1.1.3 Time de Desenvolvimento

Os integrantes de cada equipe podem ser vistos como a composição do Time de

Desenvolvimento, a justificativa é que, conforme há avanço do período letivo, as habilidades

são obtidas por eles através das disciplinas co-requisito para o desenvolvimento dos entregáveis

necessários para Projeto Integrado. Válido observar que acontece acúmulo de papéis para os

alunos que foram aos poucos designados como Scrum Masters também.

5.1.2 Artefatos

Os entregáveis, tanto de Projeto I como de Projeto II e disciplinas em paralelo são

desenvolvidos ao longo do semestre letivo corrente, cada parte em determinado período, de modo

iterativo e incremental. Eles foram fragmentados em itens, visando seu desenvolvimento no

período correto, gerando um Product Backlog. Os entregáveis de Projeto I e II apenas diferem

no Protótipo, que em Projeto II passa a ser a implementação de um website. O Quadro 3 lista os

entregáveis.

Quadro 3 – Comparativo de entregáveisProjeto II - ênfase no usuário Projeto II - ênfase no produtoBriefing BriefingProposta de Desenvolvimento Projetual (PDP) Proposta de Desenvolvimento Projetual (PDP)Plano Executivo Plano ExecutivoArtigo ArtigoProtótipo da solução digital Implementação front-end de um websiteMaterial de divulgação Material de divulgaçãoAcervo Acervo


De forma para que houvesse uma paralelização com as disciplinas co-requisito,

os itens do Product Backlog foram priorizados e divididos em seis Sprints de três semanas

(ver subseção 5.1.3), no decorrer do semestre letivo, gerando o Sprint Backlog de cada Sprint.

Para isso, uma professora alocada em Projeto I de 2018.1, na tentativa de acontecimento dessa

paralelização, elaborou antecipadamente um cronograma utilizando materiais dos professores

das outras, com intuito de minimizar redundâncias de entregas, tentando fazer com que o

desenvolvimento dos itens do Product Backlog aconteçam em comum entre todas as disciplinas

envolvidas. O Quadro 4 lista todos os itens do Product Backlog criados pela professora (uma dos

Product Owners) e os que foram priorizados pela mesma para compor o Sprint Backlog de cada

Sprint.

33

Quadro 4 – Sprints e itens de backlog priorizados

S1. Definição doproblema social aser abordado

#1 Configuração de ferramentas online#2 Planejamento do período S1 (Sprint)#3 Definição de tema/sub-tema/problema social a ser resolvido (+Texto 1)#4 Briefing v1#5 Pesquisa Teórica - 1◦ conceito#6 Pesquisa Produtos Similares (ling. Categoria) (+Texto 2)#7 Pesquisa Iconográfica (fase 1)#8 Pesquisa de Campo (fase 1 - disciplina IHC)#9 Apresentação oral do Briefing v1#10 Retrospectiva (S1)

S2. Definição dosprimeiros requisitosda solução

#11 Planejamento do Período S2 (Sprint)#12 Pesquisa Iconográfica (fase 2)#13 Briefing v2#14 Pesquisa Teórica - 2◦ conceito#15 Pesquisa Teórica - 3◦ conceito#16 Pesquisa de Campo (fase 2)#17 Pesquisa exploratória (experimentação de soluções)#18 Conceito de Criação (entrega no PDP)#19 Estratégia de Design (entrega no PDP)#20 PDP v1#21 Artigo v1#22 Apresentação oral de telas/protótipos iniciais#23 Retrospectiva (S2)

S3. Pré-banca

#24 Planejamento da Sprint S3#25 Pesquisa de campo (fase 3)#26 PDP v2#27 Artigo v2#28 Briefing v3#29 Conjunto de Peças (desenvolvimento/prototipação) (fase 1)#30 Primeira verificação do Registro de Pesquisa e demais arquivos#31 Apresentação para Pré-banca#32 Retrospectiva (S3) (+Texto 3)

S4. Plano Executivoe Avaliação de IHC

#33 Planejamento da Sprint S4#34 Artigo v3#35 Conjunto de Peças (desenvolvimento/prototipação) (fase 2)#36 Plano de Divulgação (entrega no PE)#37 Plano Executivo-PE v1#38 Avaliação de IHC (fase 1)#39 Apresentação Plano Executivo - v1 e Avaliação de IHC#40 Retrospectiva (S4)

S5. Banca

#41 Planejamento da Sprint S5#42 Plano Executivo-PE v2 (banca)#43 Artigo v4 (banca)#44 Conjunto de Peças (desenvolvimento/prototipação) (fase 3)#45 Avaliação de IHC (fase 2)#46 2a verificação do Registro de Pesquisa e demais arquivos#47 Fazer Cartaz#48 Fazer Banner#49 Fazer a Embalagem#50 Fazer a Apresentação Digital#51 Apresentar para a Banca#52 Retrospectiva (S5) (+Texto 4)

S6. Entregas finais#53 Planejamento da Sprint S6#54 Plano Executivo-PE v3 (após banca)#55 Artigo v5 (após banca)


34

Apesar da priorização dos itens ter sido realizada pela professora (Product Owner),

as estimativas seriam realizadas pelos membros das equipes (Time de Desenvolvimento) por

meio da técnica Planning Poker conforme recomendado por Sutherland (2016). Foi optado

por utilizar uma prática recomendada pelo Scrum para melhorar ainda mais acompanhamento

e transparência dos projetos: o Burndown Chart1. Na ferramenta selecionada (ver subseção

5.2), foi descoberto mais tarde a existência de um gráfico de burndown integrado, no qual foi

selecionado uso para experimentação.

5.1.3 Cerimônias

Por referência do trabalho relacionado de Rocha, Sabino e Acipreste (2015) e

do período de observação de Projeto II juntamente com a análise de seu cronograma, que

permitiu a visualização de acontecimentos importantes a cada três semanas (ver Anexo A), foram

estabelecidas Sprints de três semanas para a primeira adaptação, aproximadamente.

Devido Projeto I ter grande quantidade de alunos matriculados e dois professores-

orientadores, sua dinâmica foi vista como complexa e os horários de aula insuficientes para as

orientações e feedbacks desejados pelos professores (Product Owners) com todas as equipes e de

explicações sobre gerenciamento dos projetos. Uma das formas de contornar essa situação foi

solicitar às equipes que, depois de formadas, informassem dois horários para reuniões extraclasse

de maneira que fosse dedicado, no mínimo, seis horas semanais.

A Reunião de Planejamento da Sprint foi determinada para acontecer em dias

extraclasse logo após o término de uma Sprint, Nela não se tem a presença do Product Owner

(professor) como recomendado pelos guias Scrum e eduScrum (SCHWABER; SUTHERLAND,

2016; DELHIJ; SOLINGEN; WIJNANDS, 2016). Propõe-se a orientação de pontos a serem

discutidos nessas reuniões. São eles:

a) Planejamento do trabalho necessário para desenvolver os itens do Sprint Bac-

klog (que já estariam identificados previamente pelo Product Owner em uma

ferramenta de apoio e discutidos em sala de aula);

b) Dados da Sprint anterior para discussão;

c) Estimativas dos itens de backlog usando a técnica Planning Poker (atividade

orientada pelo Product Owner enquanto também Scrum Master);1 Burndown é uma técnica para as estimativas que tenta prever progresso no andamento do projeto por meio de

visualização gráfica.

35

d) Trazer os itens da Sprint Backlog que não foram cumpridos de uma Sprint anterior

para a atual.

A Revisão da Sprint foi demarcada para acontecer ao fim do ciclo de três semanas

das Sprints na sala de aula. Apresentações e seminários no fim desse período são um meio de

mostrar o trabalho que as equipes realizaram de acordo com a Sprint Backlog corrente. Na

forma de apresentação, tem-se presença das partes interessadas (Product Owners) no que foi

desenvolvido juntamente com feedbacks que orientam e melhoram o direcionamento do projeto.

É importante que haja orientação de que esses feedbacks sejam registrados para que serem

trabalhados em seguida, promovendo uma atualizações e refinamentos no Product Backlog.

A Retrospectiva da Sprint que ocorre após a Revisão da Sprint, foi definida para

acontecer também no horário extraclasse dedicado. Sendo orientado que realizem uma espécie

de inspecionamento em equipe, abordando o uso de ferramentas, o processo interno e os

relacionamentos dos integrantes, de forma com que o trabalho em equipe seja mais agradável

e menos complexo. Orienta-se aqui, que o integrante da equipe com o papel cedido de Scrum

Master conduza a Retrospectiva. É aconselhável o uso de atas para registro dessa reunião.

Em busca de aplicar a Reunião Diária, solicita-se as equipes que também aconteça

ao início dos dias de trabalho extraclasse ao longo das semanas do semestre e que não passe de

quinze minutos, por consequência, dias de aula da disciplina não foram considerados dias de

trabalho para acontecimento dessa cerimônia. Tópicos de discussão para orientar essa reunião

foram:

a) O que você fez no dia de trabalho anterior?

b) Tem algo que está atrapalhando seu trabalho?

c) O que você fará no próximo dia de trabalho?

Dessa forma, como no guia do Scrum e guia eduScrum (SCHWABER; SUTHER-

LAND, 2016; DELHIJ; SOLINGEN; WIJNANDS, 2016), o acontecimento da Reunião Diária é

uma forma de realizar adaptações e inspeções no processo de cada equipe.

Dado o mapeamento realizado para a aplicação em em Projeto I de 2018.1, em

seguida discorre-se sobre o passo de seleção das ferramentas para auxílio da aplicação do

PiScrum.

36

5.2 Configuração de ferramentas

Em resultados preliminares vindos da observação em Projeto II, foi visto que os alu-

nos e a professora da disciplina usaram a ferramenta Trello para acompanhamento de atividades.

Foi uma ferramenta de uso recomendado pelos alunos para uso na disciplina, por possivelmente

terem-na usado em algum momento anterior.

A Figura 3 exibe o uso da ferramenta Trello por uma equipe de Projeto II, usando

as raias (colunas) estabelecidas por ela mesma para definir o status de cada tarefa: To-do list,

Doing, Doing - Importante, Review e Done. Cada tarefa no Trello era como um checklist com

cada etapa do desenvolvimento dos entregáveis. Toda a movimentação e anexação de objetos de

trabalho e acompanhamento da professora foi realizada por meio da ferramenta.

Figura 3 – Uso do Trello por uma equipe

Fonte: elaborada pelo autor.

Para Projeto I e II com a aplicação do PiScrum, foi constatado que o Trello não

era suficiente. Partiu-se então para uma análise de variadas ferramentas (incluindo o próprio

Trello para comparação). Dentre as outras soluções que foram analisadas, estão: Zube.io, Taiga,

MeuScrum, MyScrumHalf e MeisterTask. Todas são aplicações web (executáveis em navegador

de internet), um modo encontrado para não se prender informações importantes disponíveis

apenas no ambiente de sala de aula (que seria com painéis em parede).

As duas primeiras ferramentas, Trello e Zube.io, já são utilizadas na instituição que

oferta o curso. A segunda, em especial, é utilizada em seu Núcleo de Práticas em Informática2.

As outras ferramentas foram escolhidas por serem identificadas exaustivamente em mídias2 Programa de extensão da Universidade onde existe um ambiente propício para alunos concludentes realizarem

atividades de estágio supervisionado requeridas em alguns cursos.

37

especializadas no gerenciamento ágil de projetos, conforme o que se pretendia aplicar com o

PiScrum.

Por possuírem processo empírico, o Scrum e eduScrum (em primeira adaptação

para o PiScrum) sustenta-se em pilares de transparência, inspeção e adaptação (SCHWABER;

SUTHERLAND, 2016), assim esperava-se que a(s) ferramenta(s) selecionada(s) deveria(m)

suportar os pilares por meio do gerenciamento de seus papéis, cerimônias e artefatos preestabele-

cidos no PiScrum. O Quadro 5 abaixo apresenta as características para cada ferramenta.

Para o gerenciamento dos papéis foi considerado criar, alterar e excluir papéis de

Product Owner, Scrum Master, Equipe de Desenvolvimento e Stakeholders. Para gerenciamento

de cerimônias apenas a demarcação de datas das Sprints foi considerada. Quanto aos artefatos,

foi observado a possibilidade de controlar itens do Product Backlog e separá-los em Sprints,

além de registro de estimativas para cada item e um gráfico de Burndown que foi optado para

que seja possível visualizar o andamento para cada projeto.

Quadro 5 – Atende ao Scrum?Ferramenta Gerenciamento de papéis Demarcação de Sprints Gerenciamento de artefatos

Trello não não não, apenas cardsMeisterTask não não apenas quadro de tarefas

Zube.io não sim, com datas simMeuScrum sim sim, com datas sim

MyScrumHalf sim sim, com datas simTaiga sim sim, com datas sim


Como critérios de seleção, além da conformidade com o Scrum como detalhado, as

ferramentas deveriam atender aos seguintes requisitos para a disciplinas de Projeto Integrado do

estudo deste trabalho:

a) Criação de muitas equipes independentes, pois haveria grande possibilidade de

muitos discentes matriculados no semestre 2018.1 e consequentemente muitas

equipes;

b) Entre 5 a 15 pessoas por equipe para possibilitar um acompanhamento por todos

os docentes das disciplinas envolvidas e demais partes interessadas;

c) Personalização;

d) Disponibilidade - estar acessível e pronto para uso a qualquer momento.

Conforme Quadro 5, as ferramentas Trello, Zube.io e MeisterTask foram desconside-

radas. Sendo depois analisadas para requisitos das disciplinas as ferramentas Taiga, MeuScrum e

MyScrumHalf em Quadro 6.

38

Quadro 6 – Atende as demandas da disciplina?Ferramenta Criação de muitos

timesMuitos membrospor time

Personalização Disponibilidade

MeuScrum sim sim não dependente do ser-viço

MyScrumHalf apenas paga apenas paga não dependente do ser-viço

Taiga sim, em nuvem pri-vada / do serviçocom projetos públi-cos / versão paga

sim, em nuvem pri-vada / do serviçocom projetos públi-cos / versão paga

sim, ferramentaopen-sourcealém de forne-cer nativamentepersonalização

em nuvem privada/ dependente do ser-viço


A ferramenta MeuScrum é totalmente gratuita para uso ilimitado, porém se teve

muita dificuldade de compreendê-la, em especial quando comparada ao uso das demais. Adicio-

nalmente, apesar de rica em funcionalidades, não permite personalizações. Sua disponibilidade é

dependente do serviço fornecido pelo website da ferramenta em acordo com seus termos de uso.

Seria um risco adotá-la, pois a qualquer momento poderia ficar offline e haveria grandes chances

de prejuízo à pesquisa.

Já a MyScrumHalf fornecia uso gratuito apenas para período de testes de um mês e

com restrições. Inviabilizando seu uso para o tempo compreendido de um semestre letivo.

Por último analisou-se a ferramenta Taiga inicialmente em seu website, a criação

ilimitada de projetos e membros por projeto era permitida somente se fossem públicos. A

personalização um pouco mais limitada e disponibilidade dependente do serviço fornecido pelo

website. No entanto, percebeu-se durante a análise, que a ferramenta é de código-fonte aberto,

com documentação acessível para que qualquer interessado possa instalá-la e usufruir sem

restrições em seu próprio servidor/nuvem.

Por fim, optou-se em utilizar a ferramenta Taiga instalada e configurada em uma

nuvem própria. Pelas análises, ela mostrou ser a melhor por atender aos requisitos da disciplinas

Projeto Integrado com o PiScrum dessa maneira. Além de ser gratuita para uso particular, foi

premiada como melhor ferramenta ágil3 e uma das onze melhores ferramentas em gerenciamento

de projetos4, o que fortaleceu a escolha.

Por fim, a ferramenta foi implantada em um serviço de hospedagem de máquinas

virtuais da Amazon Web Services - Elastic Compute Cloud5, por fornecer robustos serviços de

computação em nuvem, em uma máquina com Ubuntu Server 16.04 LTS, dedicada e de uso3 Best Agile Tools, Agile Awards 2015 - https://taiga.io4 Project Management Tools 2016 - https://opensource.com/5 https://aws.amazon.com/ec2

39

gratuito, visando a disponibilidade da ferramenta. Sendo proposto o uso para a turma de Projeto

I e acessível por navegador de internet em link fornecido aos envolvidos.

Para personalizar a ferramenta à linguagem da disciplina e do Scrum/PiScrum, foram

realizadas modificações em seus arquivos-fonte de tradução de idioma. Por exemplo, modificou-

se “História(s) de Usuário” (comumente utilizado para elaborar um requisito na Engenharia de

Software) para “Item(ns) de Backlog”.

40

6 APLICAÇÃO

Neste capítulo é descrito como foi procedida a tentativa de aplicação da primeira

adaptação do Scrum (PiScrum, descrita no capítulo anterior) em Projeto I no semestre letivo em

2018.1. Uma observação participante (MARCONI; LAKATOS, 2010) para coleta de dados e

exercer auxílio aos professores alocados e alunos da disciplina.

Os acompanhamentos foram realizados do período compreendido entre 22 de feve-

reiro a 25 de abril de 2018, a disciplina teve horário determinado em quartas de 13:30 as 15:30 e

quintas de 15:30 as 17:30, o pesquisador comparecia marjoritariamente nas quintas. Embora

a disciplina fosse compreendida até 26 de junho de 2018, o tempo restante foi reservado para

reunir e analisar dados e a escrita deste trabalho.

Os dois professores dividiram tarefas entre si, mas não limitaram-se a elas: um

teria maior foco em ensino e orientações na construção dos entregáveis das equipes por sua

sólida formação e experiência em Design e outro em orientações de gerência dos projetos das

equipes. Para diferenciá-los em texto, o primeiro será chamado de professor P1 e a segunda de

professora P2.

A professora P2 em momento anterior ao início de aulas, além de preparar material

didático, também realizou um auto-estudo orientado pelo pesquisador sobre o funcionamento do

Scrum para fins de capacitação, e juntamente, reuniões com o autor deste trabalho para aplicação

da adaptação realizada em conjunto pelos dois, além de elaboração de cronograma e configuração

das ferramentas do Google Drive e Taiga para uso na disciplina.

Este capítulo está organizado em seções separadas por Sprints, contido nelas, os seus

dias de aula observados para cada uma conforme planejado na adaptação para 2018.1. Nos dias

de aula são descritas observação de fato, algum comentário do ponto de vista teórico seguido de

comentários do autor e por fim, recomendações possíveis para o modelo refinado buscadas na

literatura relacionada.

6.1 Sprint 01 - Definição do Problema Social a ser resolvido

Aula 01, 22 de fevereiro: primeira semana

No primeiro dia de aula, o metatema sugerido pelos dois professores para trabalho

do problema social a ser resolvido da disciplina seria pautado na Agenda 2030 da Organização

41

das Nações Unidas (ONU)1. A agenda estabelece um plano de ação com dezessete objetivos

maiores para ações mundiais, de forma a tornar o mundo melhor. Exemplos de objetivos são: (1)

Erradicação da pobreza; (5) Igualdade de gênero e (9) Indústria, inovação e infraestrutura.

Dentre os cinquenta e um alunos matriculados, os professores pediram a formação

de nove equipes. Cada equipe seria formada por no máximo seis alunos e poderia focar em um

objetivo da Agenda 2030. A primeira aula foi seguida da contextualização de pautas sociais

para exemplificação, e estabelecido o uso do Google Drive2 para trabalho nos entregáveis e

de gerenciamento de projetos uma apresentação muito rápida da ferramenta Taiga, formas de

avaliação e os entregáveis propriamente ditos. Também houve menção de que o Scrum seria

utilizado como estrutura para o gerenciamento dos projetos com a ferramenta Taiga.

Para facilitar o entendimento inicial, foi dito que os projetos seriam trabalhados em

ciclos de três semanas, conforme cronograma previamente definido, e que ao final de cada ciclo

foi estabelecido acontecer uma apresentação do produto feito dentro do ciclo de três semanas

para a turma, que no caso, observa-se serem as Sprints e as reuniões de Revisão da própria no

PiScrum. Além disso, não foram observadas mais explicações por ser a primeira aula introdutória

a disciplina.

Aula 03, 01 de março: segunda semana

Na segunda aula da primeira semana, a ferramenta Taiga havia sido introduzida na

disciplina pela professora P2, e pedido para que todos os alunos realizassem cadastro pessoal na

ferramenta Taiga para conhecerem sua estrutura e usabilidade. A professora P2 explicou por

meio da apresentação da ferramenta as atividades do Scrum a serem realizadas.

O cronograma da disciplina, em forma de planilha eletrônica foi novamente apresen-

tado, dessa vez com mais riqueza de detalhes, particularmente em sua fração que corresponde

ao primeiro ciclo de três semanas (Sprint). Termos do PiScrum foram introduzidos em uma

linguagem menos técnica, por exemplo, o Product Backlog foi descrito como um ”checklist” ou

lista de tarefas. Em sequência, os professores explicaram a forma de construção primeira versão

do entregável da Sprint: o Briefing.

Textos de apoio na forma de descrição dos itens de Backlog foram deixados como

orientações para as equipes que até então nada sabiam sobre os entregáveis nem sobre o PiScrum.

Na Figura 4 é mostrado o exemplo de descrição da Reunião de Retrospectiva.1 https://nacoesunidas.org/pos2015/2 Serviço de compartilhamento de arquivos e suite office do Google. Disponível em drive.google.com

42

Figura 4 – Descrição da Reunião de Retrospectiva da Sprint


Vê-se aqui que cerimônias do Scrum (reuniões de Planejamento, Revisão, Retrospec-

tiva e Diária) foram adicionadas na ferramenta como itens de Backlog para recordar as equipes a

sua realização (ver Quadro 4 e Figura 5). Sendo optado por também utilizar uma definição de

pronto para cada item da Sprint como recurso pedagógico para as equipes melhor se situarem.

Figura 5 – Sprint 01 visívelna ferramenta paracada equipe


43

Na ferramenta Taiga, as equipes poderiam utilizar um quadro de tarefas para melhor

se organizarem, ele é exibido na Figura 6: à esquerda os itens de Backlog da Sprint e à direita,

colunas com o estado de cada item de backlog com tarefas que dividem a construção de um item

de backlog: a fazer, fazendo, revisão, feito e arquivado.

Figura 6 – Quadro de tarefas da Sprint 01 da Equipe 04


Na aula abordada os dois professores atuaram como Product Owners do PiScrum,

requisitando e orientando passos iniciais para a construção do Briefing (produto potencialmente

entregável da primeira Sprint agora iniciada). Em adição, orientações da professora P2 como

Scrum Master de realizações das cerimônias do PiScrum durante a Sprint e entendimento delas

por meio de textos auxiliares na ferramenta.

O PiScrum não foi explicado diretamente pela professora P2, e o pouco explicado foi

muito rápido, sendo esperado por ela que por meio do uso constante da ferramenta Taiga e seus

textos de apoio nos itens de Backlog fornecidos por ela, as equipes entendessem, aos poucos, o

funcionamento do PiScrum por meio da lógica da aplicação.

Aqui, caberiam melhores explicações gerais sobre o Scrum, como por exemplo, em

Oliveira et al. (2013), onde os autores realizam aulas de nivelamento com carga horária de 16

horas sobre gerenciamento de projetos com Scrum e PMBoK em uma disciplina de projeto

integrado. Evidente que 16 horas para referência é muito para os Projetos Integrados de Design

Digital, sendo necessário um planejamento prévio de carga horária dedicada.

Aula 05, 08 de março: terceira semana

44

Nesta aula, os professores sentaram-se individualmente e em revezamento com as

equipes para orientações sem tempo fixo. Foram discutidos assuntos que elas desejam focar em

seus projetos baseados no metatema da Agenda 2030, por exemplo: proximidade na relação

professor-aluno na escola pública, empoderamento feminino nas profissões, dentre outras. Nas

orientações, o cronograma foi relembrado, com discussão de ideias pelas equipes os professores

as guiavam na elaboração do Briefing em acordo. Também as fizeram conscientes de qual tipo

de pesquisa utilizar.

Não foram observadas orientações de gerenciamento dos projetos com o PiScrum

nesta aula, incluindo reforço da importância das Reuniões Diárias, que a essa altura deveriam

estar acontecendo nos horários extra-classe. Esperava-se que essas orientações fossem dadas

pela Scrum Master atual (professora P2).

Schön (2000) afirma que em fases iniciais de projetos, o aluno não entende o seu

processo, sendo algo muito obscuro para ele. Partindo disso, o professor de uma disciplina de

projeto (integrado) pode ver que “ele não pode explicar tais coisas com qualquer esperança

de ser entendido, pelo menos no princípio, porque elas somente podem ser compreendidas na

experiência do processo real de projeto” (SCHÖN, 2000, p. 72–73).

A professora, no papel de Scrum Master, precisaria adotar mais maneiras de garantir

o entendimento do PiScrum para não confiar apenas com o uso da ferramenta pelas equipes

inexperientes tanto na metodologia projetual quanto no gerenciamento de projetos até o momento,

faltando melhores observações da sua atenção nessa parte. Sendo algo compreensível até certo

ponto, devido ao tempo insuficiente até mesmo para as atividades da disciplina e sua metodologia

projetual.

A aula seguinte, em 14 de março de 2018, foi planejada para acontecimentos das

primeiras apresentações de Briefing preliminar.

6.2 Sprint 02 - Definição dos primeiros requisitos da solução

Aula 07, 15 de março - primeira semana

Nesta aula aconteceram ainda as apresentações restantes dos Briefings da semana

passada aos professores e a turma, após a apresentação de cada equipe houveram os feedbacks

dos professores sobre a proposta do projeto social apresentado por cada equipe. A maneira como

as equipes vinham idealizando e realizando o projeto, seja a forma certa ou errada e seu modelo

45

de negócio foram discutidas e sugestões foram propostas pelos professores e até mesmo por

alguns alunos da turma. Esperou-se que após a apresentação que as equipes reflitam e sigam as

orientações dos professores.

A professora P2 forneceu formulário em papel para registro de problemas, sugestões

de melhorias ou dúvidas vindas das apresentações. O formulário refletia a estrutura da ferramenta

Taiga em seu módulo Problemas (Figura 7). Problemas poderiam ser categorizados por tipo,

gravidade e prioridade. Ainda foi pedido que, após a coleta, os problemas fossem cadastrados na

ferramenta e trabalhados pela equipe após as mesmas refletirem a sua importância.

Figura 7 – Módulo Problemas da ferramenta Taiga


Ainda que maioria das equipes tenham apresentado o Briefing em sua primeira

versão na aula anterior, o tempo limitado não permitiu que todas conseguissem apresentar. Após

finalizadas as apresentações, a professora P2 requisitou aos alunos que movessem os itens não

trabalhados na Sprint 01 para a Sprint 02 (que acabara de iniciar) na ferramenta Taiga, também

que iniciassem o trabalho nesses itens o mais breve por conta do acontecimento de um atrasos e

evitar mais acúmulo de tarefas.

Como Product Owners, os dois professores estiveram presentes na construção e

apresentação oral do entregável Briefing em sua primeira versão, fornecendo feedbacks e po-

tencializando o seu valor como um produto potencialmente entregável. Como Scrum Master

inicial das equipes, a professora P2 relembrou na sala que o artefato Product Backlog, deveria

ser atualizado e refinado com as sugestões obtidas na apresentação. Dessa forma, a apresentação

oral do Briefing é de fato como uma Revisão da Sprint na ótica do PiScrum.

No entanto, a professora P2 apenas pediu a atualização e refinamento do Product

46

Backlog na ferramenta, e demais orientações foram deixadas disponíveis em texto de apoio da

ferramenta. Ela esperou que as equipes tivessem autonomia para as ações do PiScrum a tal altura,

como, por exemplo, com algum aluno de cada equipe lendo os textos de apoio sobre Reuniões

de Retrospectivas ou de Planejamento, e começando a conduzí-las. Iniciando assim, o repasse de

responsabilidades de Scrum Master previsto no PiScrum: inicialmente do professor, passando

para um aluno designado pela equipe.

Aqui, a nova Sprint iniciou ainda com apresentações (Reunião de Revisão) da Sprint

anterior. Ficaria melhor organizado se o ciclo de uma Sprint fosse terminado somente após

todas as apresentações terem sido concluídas. Além disso, é melhor acomodar dois dias de aula

seguidos para as apresentações. A apresentação em mais de uma semana causa dois problemas:

a) Equipes que apresentaram primeiro tem bastante tempo ocioso até o efetivo

início da próxima Sprint;

b) Iniciar a nova Sprint para equipes que apresentaram primeiro necessita maior

coordenação por parte do professor como Scrum Master.

A aula seguinte (21 de março de 2018), teve uma pauta em estimativas, o pesquisador

não compareceu, mas planejou com a professora P2 a realização da aula sobre estimativas.

Aula 08, 21 de março

Na aula do dia 21 de março de 2018, conforme relato ao pesquisador e análise do

cronograma, plano de aula e material didático, a professora P2 reservou um momento para falar

sobre como realizar estimativas para os itens de backlog da Sprint corrente. Ela pediu a todos

que instalassem o aplicativo Scrum Poker3 para auxílio nas atividades de estimativas.

A técnica utilizada para estimativas escolhida é conhecida como Planning Poker.

Nela, tem-se em disposição um deck de cartas com alguma sequência numérica conhecida,

como a sequência Fibonnaci, que acabou sendo a escolhida. A estimativa pedida funciona de

maneira bem simples: pediu-se que um item de backlog que poderia ter mais difícil construção

fosse estimado pela equipe com algum peso referencial, por exemplo, o item "PDP v1"com o

número 21. Partindo desse item como base, os outros poderiam ser estimados numericamente em

consenso por equipe. Como quase unanimidade da turma possuia celular Smartphone, pediu-se

a instalação do aplicativo para facilitar o processo de estimativas.3 Disponível em: https://play.google.com/store/apps/details?id=artarmin.android.scrum.poker

47

A Figura 8 exibe o funcionamento do aplicativo. O usuário pode escolher dentre

o deck de cartas alguma configuração de sequência numérica no aplicativo e escolhendo-se a

Fibonacci, abre-se o deck de cartas. Válido ressaltar que as 3 últimas cartas são sobre:

a) Símbolo do infinito - significa que a tarefa é extremamente importante;

b) Interrogação - o item de backlog a ser estimado não foi bem entendido;

c) Café - uma pausa na atividade para relaxar.

Figura 8 – Aplicativo Scrum Poker


A professora P2 pediu ainda que, ao início de toda Sprint (ciclo de 3 semanas), essa

atividade fosse repetida e que fossem cadastrados os pontos estimados na ferramenta Taiga,

apontando ainda, o caminho onde deveria ser cadastrado, e sua influência no gráfico de burndown

como tentativa de prever andamento do projeto com relação a atrasos ou ritmo normal. Esse

processo de estimativas deveria ainda ser realizado nas Reuniões de Planejamento da Sprint em

horário extra-classe estabelecido.

Apenas duas equipes conseguiram realizar o processo de estimativas, ainda assim de

maneira incompleta e insegura, não sabendo utilizá-las para efeito de planejamento, resultando

em um processo que não foi muito proveitoso. A professora P2 ainda com responsabilidades de

Scrum Master não conseguiu realizar acompanhamentos na ferramenta.

O processo de estimar, segundo Sutherland (2016), necessita de tempo para amadu-

48

recimento, de modo que o estimado se aproxime do real. As estimativas vão se tornando cada

vez mais proximas ao real (ou mesmo reais) conforme o projeto progride.

O processo de estimativas foi bem planejado, embora citado apenas na Sprint 02.

O que não foi um problema, já que a Sprint 01 foi considerada “uma Sprint de adaptação”

pela professora P2. O processo de estimativas deve ser reconsiderado para não ser obrigatório

em posterior refinamento do PiScrum. Quanto a maioria das equipes não haverem realizado

estimativas, não sabe-se os motivos.

Aula 09, 22 de março: segunda semana

Nesta aula ainda houve a apresentação restante do Briefing de uma equipe que atrasou

as datas estabelecidas, a apresentação ocorreu de maneira parecida com as anteriores. Depois da

apresentação o professor P1 solicitou a elaboração do próximo entregável – os Protótipos de tela

iniciais que deveriam concretizar os projetos de informação, interface e navegação.

Tratando-se da interdisciplinaridade entre disciplinas paralelas a Projeto I, especifi-

camente com a disciplina Interação Humano-Computador (IHC), havia o item de backlog #8

Pesquisa de Campo (fase 1 - disciplina IHC) previsto para a Sprint 01. Nele, as equipes preci-

sariam apenas registrar primeiras ideias relacionadas ao projeto a partir das aulas de IHC, mas

não registraram. Em Projeto I foi considerado como não realizado, pois não se teve informação

se foi feito na disciplina IHC ou de outra maneira não percebida pelos alunos. O item foi movido

para a Sprint 02, mas a construção referente teve início logo no item de backlog #16 Pesquisa de

Campo (fase 02), que trata de um planejamento propriamente dito, não mais registro de ideias.

Sugere-se a criação de um projeto acadêmico que possa contar com algum aluno

regular como participante para auxiliar na interlocução entre Projeto Integrado e disciplinas do

mesmo semestre. Já que notou-se a dificuldade de sincronismo das atividades de Projeto I com

IHC mesmo que a professora P2 tivesse conhecimento prévio das atividades planejadas para

IHC.

Existiu um grande atraso da construção dos itens de backlog selecionados pela

professora P2 para a Sprint 01, sendo eles movidos para serem trabalhados na Sprint 02. Não foi

conseguido identificar o real motivo dos atrasos iniciais. Talvez por orientação insuficiente em

como chegar a clientes de campo em potencial, talvez por erro no dimensionamento do tempo

necessário para os alunos encontrarem clientes e problemas destes a serem resolvidos, ou mesmo

por pouco sincronismo com as demais disciplinas do semestre – que poderiam ter contribuído

mais, como foi exemplificado com IHC.

49

Mais observações

No dia 07 de março, o pesquisador conferiu se o uso da ferramenta Taiga pelas

equipes estava indo bem, sendo constatado que não. Apenas duas equipes estavam realizando

estimativas, e ainda assim, de maneira incerta, não refletindo mudanças de estado no gráfico de

burndown. Logo entrou em contato com a professora P2, que ainda estava com responsabilidades

de Scrum Master. Ela explicita: "Eu precisaria estar mais no Taiga. Não estou conseguindo

fazer o papel de Scrum Master.".

A observação não foi realizada na semana seguinte, sendo um feriado nacional, logo

não houve aula. A Sprint 02 estava previsa para ser concluída na quarta, 04 de abril (aula 11),

com a apresentação dos protótipos iniciais.

6.3 Sprint 03 - Pré-banca

Neste período o autor realizou observação apenas na segunda e terceira semana da

Sprint corrente.

Aula 14, 12 de abril: segunda semana

No início da aula a professora P2 relembrou o cronograma, atrasos e passos que

foram reajustados diferente do planejado para a disciplina foram exibidos por ela. A divisão dos

entregáveis foi exibida em um mapa elaborado por conhecimentos da professora P2 decorrente

a sua ministração e observação anterior em Projeto I. O professor P1 explicou o mapa para os

alunos entenderem e descobrirem sua composição e formato.

Ao exibir e explicar a composição do mapa dos entregáveis detalhadamente, es-

sencialmente na Proposta de Desenvolvimento Projetual (PDP) em seu projeto de informação,

navegação, interface e interação, como nos protótipos. Os dois professores atuam como Product

Owners manifestando seu desejo sobre como o mesmo deve refletir em estrutura no entregável.

Observando-se o cronograma planejado, nota-se aqui que aconteceram atrasos no-

vamente: o PDP versão 1 que estava previsto para a Sprint 02 acabou sendo tocado apenas na

Sprint 03. Não sabe-se como foi o trabalho dentro das equipes com os itens de backlog ainda da

Sprint 01 sendo trabalhados na Sprint 02.

Aula 17, 25 de abril: terceira semana

50

Nesta aula aconteceu a pré-banca em horário extra combinado com a turma. A

Pré-banca consiste de apresentações mais rigorosas que reúnem os professores das disciplinas em

paralelo (incluindo os professores de Projeto I) para obtenção de feedbacks para os projetos de

maneira a aumentarem sua qualidade. Cada professor da disciplina em paralelo é visto com um

especialista em sua área. Para isso, eles recebem com antecedência os entregáveis dos projetos

até o momento.

Os feedbacks foram seguidos para cada equipe, por exemplo, a professora de Intera-

ção Humano-Computador emitiu pareceres quanto aos métodos de pesquisa de campo mostradas

na disciplina utilizado em cada projeto, o professor de Semiótica falou sobre a pesquisa icono-

gráfica e identidade visual dos projetos em modo geral, o de Sociedade, Culturas e Tecnologias

falou emitiu parecer sobre a profundidade da pesquisa enquanto acadêmica, o modelo de negócio

da solução de Design apresentada por meio dos entregáveis.

A Pré-banca pode ser vista como uma Revisão da Sprint maior, que reúne mais

partes interessadas agora melhor identificadas (professores das outras disciplinas). Poderia ser

interessante o acontecimento de Revisões de Sprint da mesma maneira que a Pré-banca, mas

torna complicado conciliação de todo mundo.

Não foi observado nessa aula extra de apresentações nenhuma atividade de gerência

de projetos, apenas ocorreram apresentações. Por experiência, espera-se que as equipes trabalhem

nas sugestões da Pré-banca. Não sabe-se quantos e quais itens de backlog foram trabalhados

nesse ciclo de 3 semanas. Nessa presente data o autor encerrou suas observações participantes

em sala de aula, mas permaneceu disponível para os professores e as equipes esclarecerem

dúvidas.

Demais Sprints

O atraso de itens de backlog a serem realizados na Sprint 01 causaram um efeito-

dominó em todas as outras disciplinas, além da incerteza do início de finais das Sprints que não

finalizavam na data estabelecida. Pela análise do cronograma e plano de aula, pode-se observar

que apenas duas aulas (4 horas) tiveram um momento para explicação de gerenciamento de

projetos, não tornando a primeira aplicação do PiScrum efetiva. Com as lições aprendidas e

recomendações vistas em cada dia de aula observado a adaptação será refinada para uso posterior

em Projeto I e II. Cabe aos professores futuramente alocados na disciplina compreenderem o

PiScrum, que é o resultado deste trabalho e descrito no capítulo seguinte.

51

7 RESULTADOS E DISCUSSÃO

O PiScrum é o resultado deste trabalho, com ele visa-se o melhor gerenciamento das

disciplinas iniciais de Projeto Integrado do curso de Design Digital. Fruto de uma pesquisa com

adaptações baseadas nos frameworks Scrum (SCHWABER; SUTHERLAND, 2016) e eduScrum

(DELHIJ; SOLINGEN; WIJNANDS, 2016), além de recomendações de autores de disciplinas

semelhantes buscadas na literatura para solucionar problemas observados em sua construção.

Sua descrição é semelhante a dos dois guias, sendo adaptada à características da disciplina.

7.1 PiScrum

O PiScrum é uma estrutura na qual podemos adaptar facilmente a metodologia

projetual utilizada na construção dos projetos realizados em Projeto Integrado I e II. Embora

seja bastante simples, é difícil de se dominar. O PiScrum tem em sua composição cerimônias,

artefatos e papéis. Eles são descritos nas subseções à seguir.

Nas disciplinas de Projeto Integrado de Design Digital são trabalhados projetos em

equipes, estas que podem variar em quantidade de membros de acordo com o número de alunos

matriculados. A descrição de cada componente do PiScrum é individual de cada equipe, exceto

para o papel de Product Owner que é único para todas as equipes.

O PiScrum possui um processo empírico e tem os mesmos pilares dos guias que são

sua base, são eles:

a) Transparência - características do processo devem estar disponíveis para todos os

envolvidos. Por exemplo: adoção de uma linguagem em comum e possuir uma

definição de concluído;

b) Inspeção - no PiScrum, seus participantes devem frequentemente checar seus

artefatos e progresso para detectarem variações;

c) Adaptação - ajustes no processo do PiScrum ou nos entregáveis devem ser

realizados o mais rapidamente ao serem notadas divergências ou que o entregável

não está legal (segundo o Product Owner ou a definição de concluído).

7.1.1 Papéis

O time PiScrum é formado pelos papéis do Product Owner, Scrum Master e Equipe

de Desenvolvimento. O time deve ser auto-organizavel e comprometido com a estrutura fornecida

52

neste guia.

O Product Owner é o papel representado pelo professor. Teremos mais de um profes-

sor com este papel, se houver mais de um professor alocado na disciplina de Projeto Integrado.

Eles potencializam o trabalho que está sendo desenvolvido pela Equipe de Desenvolvimento,

sendo responsável por especificar os entregáveis da disciplina, sua ordem de entrega ou prio-

rização, além de fornecer feedbacks e orientações nos projetos. Além dos entregáveis, ele(s)

avalia(m) também o resultado educacional gerado.

Algum professor assume inicialmente o papel do Scrum Master e vai explicar como

aplicar o PiScrum nos projetos da disciplina. Ao prosseguir da disciplina, o professor repassa o

papel de Scrum Master a algum aluno de cada equipe. Com o tempo, o aluno designado pela

equipe, passa a ser o responsável por garantir a ocorrência de cerimônias, regras e práticas do

PiScrum e também de manter os artefatos atualizados.

A Equipe de Desenvolvimento é cada equipe formada. Recomenda-se, por experiên-

cias anteriores, que seu tamanho varie de quatro a cinco alunos1.

O professor pedirá que todas as equipes estabeleçam pelo menos um horário fixo

extra-classe para que trabalhem em seus projetos, evitando assim que o trabalho seja feito em

momentos esporádicos ou próximo a data de entrega, o que geralmente é comprovado ineficiente.

A equipe é considerada formada apenas quando seus horários estiverem estabelecidos.

No PiScrum, as equipes não são compostas por especialistas. É suposto que seus

membros adquiram, ao longo de Projeto Integrado, habilidades e conhecimentos para trabalhar

nos entregáveis da disciplina. Para isso, o aluno de Projeto Integrado deve estar matriculado nas

disciplinas em paralelo ou já ter cursado estas disciplinas anteriormente. Adicionalmente, para

conseguir o sincronismo desejável entre as disciplinas do semestre, é recomendado que cada

equipe tenha pelo menos um participante matriculado em cada uma das disciplinas paralelas.

Válido ressaltar que, nos Projetos Integrados iniciais existe o trabalho com clientes

de campo reais, tornando-se necessária a representação do desejo do cliente por algum membro

da Equipe de Desenvolvimento. Embora essa representação se assemelhe com a descrição de um

Product Owner, não adotamos essa terminologia porque quem decide sobre os entregáveis, em

última instância, é o professor.1 O Scrum recomenda de quatro a oito pessoas, já o eduScrum recomenda no máximo quatro alunos e complementa

que menos do que três e mais do cinco pode comprometer a coordenação das equipes.

53

7.1.2 Artefatos

Temos aqui dois artefatos relacionados entre si: o Product Backlog e o Sprint Backlog.

Decisões sobre o gerenciamento do projeto são tomadas com base no estado desses artefatos,

que precisam estar sempre atualizados para possíveis ocorrências de inspeções e adaptações.

O Product Backlog é uma lista que contém todos os entregáveis, desmembrados

para trabalho incremental. Este artefato está em constante evolução, eles são priorizados

previamente pelo professor (Product Owner) para trabalho pelas Equipes de Desenvolvimento

posteriormente, ou seja, ele estabelece a sua ordem de entrega. Cada item da lista deve conter

atributos de descrição, ordem, valor e estimativa2. Sendo o último atributo definido pela Equipe

de Desenvolvimento com auxílio do Product Owner, recomenda-se a técnica Planning Poker

para sua realização.

O Sprint Backlog contém os itens do Product Backlog que serão trabalhados em

uma Sprint. Deve ser detalhado suficientemente bem para que seu progresso de conclusão seja

observado em Reuniões Diárias da equipe, devendo ser alterado ao se entender cada vez mais o

trabalho necessário para se atingir a meta da Sprint.

7.1.3 Cerimônias

As cerimônias no PiScrum são eventos definidos que devem acontecer rotineiramente,

evitando o acontecimento de reuniões extras que possam tornar ineficiente o processo do PiScrum.

As Sprints são ciclos de tempo que abrigam as outras cerimônias do PiScrum e

começam partindo da segunda semana de aulas, a primeira semana é reservada para apresentação

da disciplina, formação das equipes e discussão sobre o meta tema do semestre.

Nas Sprints, tem-se como objetivo o desenvolvimento de um ou mais itens potenci-

almente entregáveis trabalhados de acordo com o Sprint Backlog. Para as disciplinas iniciais

de Projeto Integrado, recomendam-se Sprints de três semanas. Dentro deste ciclo de tempo

estão previstas acontecerem: Reunião de Planejamento, de Revisão, de Retrospectiva e Reunião

Diária.

A Reunião de Planejamento da Sprint deve acontecer no início da Sprint, recomenda-

se sua condução em sala de aula e com o time PiScrum presente, com o Scrum Master a

conduzindo. Conforme recomendação do guia eduScrum, divimos essa Reunião em três momen-2 Embora seja recomendado que hajam estimativas para constantemente checar o andamento do projeto e

capacidade de trabalho das equipes, ela não é obrigatória para o PiScrum

54

tos:

a) (Re)Formação das equipes - a escolha de membros das equipes se dá conforme

descrição da Equipe de Desenvolvimento na subseção 7.1.1. Embora indesejado,

caso algum aluno deseje trocar de equipe, só será possível na próxima Reunião

de Planejamento;

b) Discussão de metas de aprendizado - são discutidos os objetivos de aprendizagem

que dão a equipe de estudantes a flexibilidade necessária no que diz respeito aos

entregáveis. O Product Owner diz o que ele espera da equipe no final da Sprint;

c) Planejamento do trabalho - os objetivos da Sprint são discutidos com o time

PiScrum e o trabalho necessário para completá-la de acordo com o Sprint Backlog.

Pode-se usar para fins de apoio nessa reunião o Product Backlog atualizado,

dados do entregável anterior (caso exista), capacidade estimada da Equipe de

Desenvolvimento e informações de desempenho passado.

A Revisão da Sprint é realizada na última semana da Sprint na forma de apresentações

dos projetos e respectivos entregáveis para a turma, de modo que estão presentes: o Product

Owner, os demais alunos da disciplina e possíveis partes interessadas em seus entregáveis

(clientes de campo, professores das disciplinas em paralelo, especialistas). Nessa cerimônia,

visa-se feedback de todos esses participantes, almejando otimização para a Sprint seguinte e

atualizações no Product Backlog, gerando assim de entregáveis de maior qualidade e também

maior aprendizado educacional, além de ser uma forma de inspeção.

A Retrospectiva da Sprint ocorre após a Revisão da Sprint, em horário extraclasse.

Trata-se de uma cerimônia em que ocorre um processo de autoavaliação do time PiScrum e

de estabelecer planos de melhorias para a próxima Sprint. A autoavaliação tem o propósito

de discutir o uso de ferramentas, do processo interno e relacionamento de maneira a suprimir

aborrecimentos e conflitos.

E por fim, a Reunião Diária. É uma cerimônia com até quinze minutos de duração

que une a Equipe de Desenvolvimento para inspeções do que foi realizado em um dia de trabalho.

No PiScrum, um dia de trabalho corresponde aos dias de aula e os extra-classe solicitados pelo

Scrum Master.

55

A Figura 9 ilustra o ciclo de vida do PiScrum conforme mostra o guia discutido

anteriormente.

Figura 9 – Ciclo de vida do PiScrum

Fonte: elaborado pelo autor com base em Scrum.org

56

8 CONSIDERAÇÕES FINAIS

Após a realização deste trabalho, foi possível verificar que existem grandes dificulda-

des na condução das disciplinas iniciais de Projeto Integrado do curso de Design Digital. Tanto

por parte do professor, como por parte dos alunos que a cursam. No decorrer do trabalho foram

realizadas observações para criar um framework ágil adaptado para gerenciar os projetos da dis-

ciplina, com fundamentação em dois guias: do Scrum e eduScrum. Que focam, respectivamente,

no desenvolvimento de produtos e resultados educacionais.

A problemática teve vivência no período correspondente ao segundo semestre letivo

de 2017 e o primeiro de 2018, onde foram realizadas observações e integração em seu ambiente

por meio da metodologia pesquisa-ação, na qual o pesquisador adentrou ao ambiente das

disciplinas para conhecer a fundo sua realidade, e propor, juntamente com uma professora,

que representou o grupo de interessados (caracterizado pelos alunos das disciplinas, demais

professores envolvidos, ...), uma adaptação, resultando no framework PiScrum apresentado em

síntese no capítulo anterior.

Na primeira adaptação não foram obtidos bons resultados, esperava-se com confiança

que por meio do uso de uma ferramenta selecionada, todos os participantes compreendessem

implicitamente a estrutura do PiScrum em sua primeira versão. No final, em mais encontros

posteriores com a professora representante do grupo de interessados, a adaptação foi refeita

em um guia e tornou-se o resultado deste trabalho (Capítulo 7). Refletindo com a professora

representante as falhas cometidas e buscando na literatura fundamentações e recomendações que

poderiam ser seguidas fortemente.

Muitas alterações simples no PiScrum foram realizadas para aplicações seguintes:

adição de cerimônias em sala de aula, aulas de nivelamento dedicadas sobre o framework, forma

de reorganização das equipes, maior quantidade de explicações sobre a constituição de equipes

feitas por não especialistas. O semestre 2018.2 já está com cronograma pré-preparado para sua

aplicação em Projeto II (Apêndice A).

Este trabalho teve como fruto uma submissão pré-aceita para o periódico #Tear:

Revista de Educação, Ciência e Tecnologia1. No qual, focamos em uma categorização literária

das disciplinas de Projeto Integrado em seu nível de dificuldade, tipologia de integração curricular,

também no percurso de seleção de ferramentas para auxiliar na aplicação do PiScrum.

Por final, se tem a contribuição para o curso de Design Digital e os futuros professores1 https://periodicos.ifrs.edu.br/index.php/tear

57

alocados para as disciplinas Projeto I e II, que por meio deste trabalho possam fazer ações

necessárias para facilitar a sua continuação e evolução. Para trabalhos futuros, sugere-se a

avaliação de próximas aplicações com mais sugestões de melhorias, já que se trata de um trabalho

que necessita de um longo tempo para amadurecer, ou até mesmo o foco nas metodologias

projetuais que não existem formalizadas nas disciplinas.

58

REFERÊNCIAS

BECK, K. et al. Manifesto para Desenvolvimento Ágil de Software. 2001. Disponível em:<http://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 31 out. 2017.

BRASIL. Lei no 9.394, de 20 de dezembro de 1996: estabelece as diretrizes e bases da educaçãonacional. Brasília, 1996. Disponível em: <http://www.planalto.gov.br/ccivil_03/leis/L9394.htm>.Acesso em: 16 set. 2017.

CAPES. Áreas do conhecimento. Brasília, 2017. Disponível em: <http://www.capes.gov.br/images/documentos/documentos_diversos_2017/TabelaAreasConhecimento_072012_atualizada_2017_v2.pdf>. Acesso em: 16 set. 2017.

CNPQ. Tabela de áreas do conhecimento. Brasília, 2017. Disponível em:<http://lattes.cnpq.br/documents/11871/24930/TabeladeAreasdoConhecimento.pdf/d192ff6b-3e0a-4074-a74d-c280521bd5f7>. Acesso em: 16 set. 2017.

CRUZ, F. Scrum e PMBOK unidos no Gerenciamento de Projetos. Rio de Janeiro: Brasport,2013.

DANTAS, L. G. R.; SANTOS, A. M. C. d. Metodologia do design para web: uma propostade unificaçao das metodologias Projeto E e Scrum. In: CONGRESSO BRASILEIRO DEPESQUISA E DESENVOLVIMENTO EM DESIGN, 12. Anais... São Paulo: Blusher DesignProceedings, 2016. p. 1500–1512. DOI: http://dx.doi.org/10.5151/despro-ped2016-0127.

DELHIJ, A.; SOLINGEN, R. van; WIJNANDS, W. O guia eduScrum: as regras do jogo. 2016.Disponível em: <http://eduscrum.nl/en/file/CKFiles/O_guia_eduScrum.pdf>. Acesso em: 31out. 2017.

FUNDAÇÃO DOM CABRAL. Conheça os 6 principais métodos de ges-tão de projetos. 2017. Disponível em: <http://blogespecializacao.fdc.org.br/conheca-os-6-principais-metodos-de-gestao-de-projetos/>. Acesso em: 20 nov. 2017.

GOMES, A. F. Agile: desenvolvimento de software com entregas frequentes e foco no valor denegócio. São Paulo: Editora Casa do Código, 2014.

MARCONI, M. d. A.; LAKATOS, E. M. Fundamentos de metodologia científica. 5. ed. SãoPaulo: Atlas, 2010.

MONTEIRO, I. T.; SAMPAIO, A. L. Trabalhando a diversidade e a inclusão social nadisciplina de Projeto Integrado. In: WORKSHOP SOBRE ENSINO DE INTERAÇÃOHUMANO-COMPUTADOR (IHC ’17 - WEIHC), 14. Anais... Joinville: Sociedade Brasileirade Computação, 2017.

NONAKA, I.; TAKEUCHI, H. The New New Product Development Game. Havard BussinessReview, v. 64, n. 1, p. 137–146, 1986.

OLIVEIRA, E. C. et al. Projeto integrador de engenharia: experiência de uma disciplina embusca por uma didática em ambiente desafiador. In: CONGRESSO DE EDUCAÇÃO EMENGENHARIA, 41. Anais... Gramado: COBENGE, 2013.

http://agilemanifesto.org/iso/ptbr/manifesto.html

http://www.planalto.gov.br/ccivil_03/leis/L9394.htm

http://www.capes.gov.br/images/documentos/documentos_diversos_2017/TabelaAreasConhecimento_072012_atualizada_2017_v2.pdf



http://lattes.cnpq.br/documents/11871/24930/TabeladeAreasdoConhecimento.pdf/d192ff6b-3e0a-4074-a74d-c280521bd5f7

http://lattes.cnpq.br/documents/11871/24930/TabeladeAreasdoConhecimento.pdf/d192ff6b-3e0a-4074-a74d-c280521bd5f7

http://eduscrum.nl/en/file/CKFiles/O_guia_eduScrum.pdf

http://blogespecializacao.fdc.org.br/conheca-os-6-principais-metodos-de-gestao-de-projetos/

http://blogespecializacao.fdc.org.br/conheca-os-6-principais-metodos-de-gestao-de-projetos/

59

PERSSON, M. et al. On the Use of Scrum in Project Driven Higher Education. In:INTERNATION CONFERENCE ON FRONTIERS IN EDUCATION: COMPUTER SCIENCEAND COMPUTER ENGINEERING (WORLDCOMP’11 - FECS’11), 11. Anais... Las Vegas:WorldComp, 2011. p. 1–6.

PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. Porto Alegre:Mc Graw Hill, 2011.

PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento deprojetos (Guia PMBOK). 5. ed. Pennsylvania: Project Management Institute, Inc., 2013.

RIGBY, D. K.; SUTHERLAND, J.; TAKEUCHI, H. The Secret History About Agile Innova-tion. 2016. Disponível em: <https://hbr.org/2016/04/the-secret-history-of-agile-innovation>.Acesso em: 15 jan. 2018.

ROCHA, F. G.; SABINO, R. F.; ACIPRESTE, R. H. L. A metodologia Scrum comomobilizadora da prática pedagógica: um olhar sobre a Engenharia de Software. In: FÓRUM DEEDUCAÇÃO EM ENGENHARIA DE SOFTWARE (CBSOFT ’15), 8. Anais... Belo Horizonte:Sociedade Brasileira de Computação, 2015. p. 12–23.

SABBAGH, R. Scrum: gestão ágil para projetos de sucesso. São Paulo: Editora Casa doCódigo, 2014.

SCHÖN, D. A. Educando o profissional reflexivo: um novo design para o ensino e aaprendizagem. 1. ed. Porto Alegre: Artmed, 2000.

SCHWABER, K. Guia do Scrum. 2009. Disponível em: <https://www.trainning.com.br/download/GUIA_DO_SCRUM.pdf>. Acesso em: 16 set. 2017.

SCHWABER, K.; SUTHERLAND, J. Scrum Guide. 2016. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Portuguese-Brazilian.pdf>.Acesso em: 31 out. 2017.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. São Paulo:Texto Editores, 2016.

THIOLLENT, M. Metodologia da pesquisa-ação. 13. ed. São Paulo: Cortez, 2004.

UFC. Design Digital. Quixadá, 2015a. Disponível em: <http://dd.quixada.ufc.br/>. Acesso em:16 set. 2017.

UFC. Projeto Integrado I - QXD0160. Quixadá, 2015b. Disponível em: <http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Integrado-I-QXD0160-DD.pdf>.Acesso em: 31 out. 2017.

UFC. Projeto Pedagógico de Curso - Design Digital. Quixadá, 2015c. Disponívelem: <http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Pedag%C3%B3gico-do-Curso-de-Design-Digital.pdf>. Acesso em: 31 out. 2017.

UFC. Projeto Integrado II - QXD0165. Quixadá, 2015d. Disponível em: <http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Integrado-II-QXD0165-DD.doc.pdf>. Acesso em:31 out. 2017.

https://hbr.org/2016/04/the-secret-history-of-agile-innovation

https://www.trainning.com.br/download/GUIA_DO_SCRUM.pdf

https://www.trainning.com.br/download/GUIA_DO_SCRUM.pdf

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Portuguese-Brazilian.pdf

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Portuguese-Brazilian.pdf

http://dd.quixada.ufc.br/

http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Integrado-I-QXD0160-DD.pdf

http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Integrado-I-QXD0160-DD.pdf

http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Pedag%C3%B3gico-do-Curso-de-Design-Digital.pdf

http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Pedag%C3%B3gico-do-Curso-de-Design-Digital.pdf

http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Integrado-II-QXD0165-DD.doc.pdf

http://dd.quixada.ufc.br/wp-content/uploads/2017/02/Projeto-Integrado-II-QXD0165-DD.doc.pdf

60

WAZLAWICK, R. S. Metodologia de pesquisa para ciência da computação. 2. ed. Rio deJaneiro: Elsevier Editora Ltda., 2014.

61

APÊNDICE A – CRONOGRAMA PREVISTO PARA PROJETO INTEGRADO II -

2018.2

Cronograma elaborado para a disciplina Projeto Integrado II ofertada em 2018.2 de

modo a adequar melhor o PiScrum.

Un

iver

sid

ade

Fed

eral

do

Cea

rá, C

amp

us

Qu

ixad

á, P

roje

to In

tegr

ado

2, 2

01

8.2

Av.

IHC

Dir

. Art

eP

roj.

Int

2Li

ng.

Mar

c.C

om

. Vis

ual

Cro

no

gram

a d

e a

ula

s

sA

ula

Dat

aA

tivi

dad

es

em

sal

a d

e a

ula

Re

gist

ro d

a p

esq

uis

a

Bri

efi

ng

Co

nce

ito

de

Cri

ação

e

Estr

até

gia

de

De

sign

PD

PA

rtig

oP

lan

o

Exe

cuti

voC

on

j. d

e P

eça

s

(De

sen

volv

.)

Car

taz,

Ban

ne

r e

Ap

rese

n-

taçã

o D

igit

al

Emb

alag

em

pq

. pro

d

sim

ilare

s (L

.

cate

gori

a)p

q. t

eó

rica

pq

. ico

no

- gr

áfic

ap

q. d

e

cam

po

exp

eri

me

n-

taçõ

es

apresen- tação

11

9-a

go 5

ª A

pre

sen

taçã

o d

a d

isci

plin

a. D

efin

ição

de

tem

as/e

qu

ipe

s. C

on

figu

raçã

o d

e fe

rram

en

tas

on

line

.

---

---

---

---

---

---

---

---

---

---

---

---

---

21

0-a

go 6

ª N

ivel

amen

to e

m S

cru

m--

---

---

---

---

---

---

---

---

---

---

---

---

-

S1. Definição do Problema Social a ser resolvido

23

16

-ago

5ª

Pla

nej

amen

to d

a Sp

rin

t. S

cru

m M

aste

r.in

ício

v1

(p

esq

uis

a)in

ício

v1

(s

eleç

ão)

iníc

io v

1

(pes

qu

isa)

iníc

io v

1

(pla

nej

.)--

-in

ício

v1

(c

om

ple

to)

---

---

---

---

---

---

---

41

7-a

go 6

ª D

efin

ição

de

pro

ble

ma

(op

ort

un

idad

e). O

bje

tivo

s.

Dir

etri

zes

par

a B

rie

fin

g.o

oo

o--

-o

---

---

---

---

---

---

---

35

23

-ago

5ª

Dir

etri

zes

par

a p

esq

uis

as p

rod

. sim

ilare

s (l

ing.

ca

tego

ria)

e ic

on

ogr

áfic

a.

oo

oo

---

o--

---

---

---

---

---

---

-

62

4-a

go 6

ª D

iret

rize

s p

ara

a p

esq

uis

a te

óri

ca. T

ema

e co

nce

ito

s ch

ave

do

tra

bal

ho

. o

oo

o--

-o

---

---

---

---

---

---

---

47

30

-ago

5ª

Ap

rese

nta

ção

ora

l do

bri

efin

g p

relim

inar

. v1

-on

line

v1-o

nlin

ev1

-on

line

v1-i

mp

res.

---

v1-i

mp

res.

---

83

1-a

go 6

ª A

pre

sen

taçã

o o

ral d

o b

rief

ing

pre

limin

ar.

v1-o

nlin

ev1

-on

line

v1-o

nlin

ev1

-im

pre

s.--

-v1

-im

pre

s.--

---

---

---

---

---

---

-

S2. Definição dos primeiros requisitos da solução

59

6-s

et 5

ª P

lan

ejam

ento

da

Spri

nt.

Dir

etri

zes

par

a ar

tigo

.in

ício

v2

(r

evis

ão)

iníc

io v

2

(esc

rita

)in

ício

v2

(r

evis

ão)

iníc

io v

2

(ap

licaç

ão)

iníc

io v

1

(pro

t.in

icia

is)

iníc

io v

2

(rev

isão

)in

ício

v1

(c

on

teú

do

)in

ício

v1

(c

on

teú

do

)in

ício

v1

(1

o c

om

ple

to)

---

---

---

---

7-s

et 6

ª Fe

riad

oo

oo

oo

oo

oo

---

---

---

---

61

01

3-s

et 5

ª D

iret

rize

s p

ara

pe

squ

isa

de

cam

po

. o

oo

oo

oo

oo

---

---

---

---

11

14

-set

6ª

Dir

etri

zes

par

a e

xpe

rim

en

taçã

o d

e so

luçõ

es

(pes

q.

exp

lora

tóri

a): t

ela

s/p

rotó

tip

os

inic

iais

.fi

mfi

mfi

mo

ofi

mo

oo

---

---

---

---

71

22

0-s

et 5

ª A

pre

sen

taçã

o O

ral d

e te

las/

pro

tóti

po

s in

icia

isv2

-on

line

v2-o

nlin

ev2

-on

line

v2-o

nlin

ev1

ap

rese

nt.

p

rotó

tip

os

v2-o

nlin

ev1

-on

line

v1-o

nlin

ev1

-on

line

---

---

---

---

13

21

-set

6ª

Ap

rese

nta

ção

Ora

l de

tela

s/p

rotó

tip

os

inic

iais

---

---

---

---

---

---

---

---

---

---

---

---

---

S3. Pré-banca

81

42

7-s

et 5

ª P

lan

ejam

ento

da

Spri

nt.

D

iret

rize

s p

ara

Estr

até

gia

de

De

sign

.--

-in

ício

v3

(a

pro

fun

da

men

to)

---

iníc

io v

3(p

erso

nas

)(c

on

tin

uar

do

cum

enta

ção

de

vers

ões

)

---

(no

PD

P)

iníc

io v

2

(dia

graç

ão)

iníc

io v

2

(rev

isão

)--

-in

ício

v1

(p

rotó

tip

os)

---

---

15

28

-set

6ª

PD

P: d

iret

rize

s p

ara

Co

nce

ito

de

Cri

ação

.--

-o

---

o--

-o

oo

---

---

---

---

91

64

-ou

t 5

ª P

DP

: Pro

jeto

s d

e in

form

ação

, nav

egaç

ão, i

nte

rfac

e,

inte

raçã

o. I

mp

ress

ão.

---

o--

-o

o--

-(n

o P

DP

)v2

on

line

ban

cav2

imp

res.

p

ré-b

anca

---

---

---

---

17

5-o

ut

6ª

Dir

etri

zes

par

a o

Pla

no

Exe

cuti

vo (

PE)

.(c

om

par

ativ

o c

om

PD

P)

---

o--

-fi

mo

---

oo

o--

---

---

---

-

10

18

11

-ou

t 5

ª P

ré-b

anca

(m

anh

ã e

tard

e)--

-v3

-on

line

---

v2-o

nlin

eo

---

(no

PD

P)

pré

-ban

cap

ré-b

anca

---

v1 t

elas

pré

-b

anca

---

---

19

12

-ou

t 6

ª fe

riad

o--

---

---

---

---

---

---

---

---

---

---

---

---

-

S4. Plan. Exec. e Avaliação de IHC

11

20

18

-ou

t 5

ª P

lan

ejam

ento

da

Spri

nt

---

iníc

io v

4

(rev

isão

)--

---

-o

---

---

---

iníc

io v

3(f

inal

izar

)in

ício

v1

(c

om

ple

to)

v2 d

evin

ício

v1

(c

om

ple

to)

---

21

19

-ou

t 6

ª D

iret

rize

s p

ara

Pla

no

de

Div

ulg

ação

e P

roto

tip

ação

.--

-o

---

---

o--

---

---

-o

oo

o--

-

12

22

25

-ou

t 5

ª En

con

tro

s U

niv

ersi

tári

os/

Co

ngr

esso

IHC

---

o--

---

-o

---

---

---

oo

oo

---

23

26

-ou

t 6

ª En

con

tro

s U

niv

ersi

tári

os/

Co

ngr

esso

IHC

---

o--

---

-o

---

---

---

oo

oo

---

13

24

1-n

ov

5ª

Ap

rese

nta

ção

de

pro

tóti

po

s/im

ple

men

taçã

o--

-v4

-on

line

---

---

fin

al--

---

---

-v3

-on

line

v1-o

nlin

ev2

-on

line

v1-i

mp

ress

---

25

2-n

ov

6ª

Ap

rese

nta

ção

de

pro

tóti

po

s/im

ple

men

taçã

o--

---

---

---

---

---

---

---

---

---

---

---

---

-

S5. Banca

14

26

8-n

ov

5ª

Pla

nej

amen

to d

a Sp

rin

t--

---

---

---

---

---

---

---

-v3

imp

ress

b

anca

v2 im

pre

ss

ban

cav3

(a

v. IH

C)

iníc

io v

2

(rev

isão

)in

ício

27

9-n

ov

6ª

Fin

aliz

ação

do

s tr

abal

ho

s--

---

---

---

---

---

---

---

---

---

-o

oo

15

28

15

-no

v 5

ª Fi

nal

izaç

ão d

os

trab

alh

os

---

---

---

---

---

---

---

---

---

---

oca

rtaz

e

ban

ner

o

29

16

-no

v 6

ª Fi

nal

izaç

ão d

os

trab

alh

os

---

---

---

---

---

---

---

---

---

---

fim

oo

16

30

22

-no

v 5

ª B

anca

....

....

....

..

ava

liaçã

o (

fin

al)

do

co

nte

úd

o e

org

aniz

ação

do

s ar

qu

ivo

s (o

nlin

e e

no

CD

/pen

dri

ve)

....

....

....

....

....

....

....

..ban

ca1

imp

ress

o

FIN

AL

entr

ega

fin

alví

deo

p

rom

oci

on

alen

treg

a em

bal

agem

31

23

-no

v 6

ª B

anca

---

---

---

---

---

---

---

---

---

---

---

---

---

17

32

29

-no

v 5

ª en

treg

a d

e re

sult

ado

s--

---

---

---

---

---

---

---

-v4

fin

al--

-ar

tigo

at

ual

izad

o--

---

-

30

-no

v 6

ª

6-d

ez 5

ª ce

nté

sim

o d

ia le

tivo

---

---

---

---

---

---

---

---

---

---

---

---

---

27

/ju

n a

03

/ju

l. P

erío

do

de

aval

iaçõ

es f

inai

s.

63

ANEXO A – CRONOGRAMA DA DISCIPLINA PROJETO INTEGRADO II

Cronograma criado pela professora com o papel de representante de acordo com a

metodologia pesquisa-ação deste trabalho. Ele está dividido em duas partes, e nas duas páginas

seguintes para melhor visualização.

66

ANEXO B – DIÁRIO DE AULA DA DISCIPLINA PROJETO INTEGRADO I

Plano de aula gerado por sistema acadêmico e fornecido pela professora representante

para análise.

Universidade Federal do CearáDesign DigitalSistema de Presença e Planos de Aula

Diário de Aula

Código: QXD0160 Turma: 03 Disciplina: Projeto Integrado I

Período: 2018.1 Créditos: 4.0 Créditos Práticos: 0.0

Professor(a): xxxxxxxxxxxxx

Horários: QUARTA 13h30-15h30; QUINTA 13h30-15h30;

Aula Data Diário1 22/02/2018 Apresentação da disciplina. Definição de temas/equipes. Configuração de

ferramentas online.2 28/02/2018 Definição de problema (oportunidade). Objetivos.3 01/03/2018 Diretrizes para o briefing.4 07/03/2018 Diretrizes para o briefing.(cont.)5 08/03/2018 Orientação das equipes.6 14/03/2018 Apresentação oral do briefing preliminar.7 15/03/2018 Apresentação oral do briefing preliminar.8 21/03/2018 Apresentação de Briefing (cont.). Acompanhamento dos trabalhos.9 22/03/2018 Diretrizes para pesquisa de campo. Diretrizes para experimentação de

soluções (pesq.exploratória)10 21/03/2018 Acompanhamento dos projetos. Orientações para gerência de projetos.

(horário extra, 15:30-17:30)11 04/04/2018 Diretrizes para Conceito de Criação. Estratégia de Design.12 05/04/2018 Debate da relação da metodologia estrela (IHC) com o projeto integrado, em

especial no momento inicial de delimitação do problema social a ser resolvido.Revisão de: todos os itens da pesquisa referencial; formato e conteúdo doartigo; proposta do briefing.

13 11/04/2018 Diretrizes para modelagem/prototipagem.14 12/04/2018 PDP. Projetos de informação, navegação, interface, interação.15 18/04/2018 PDP. Como imprimir PDP.16 19/04/2018 Orientações: 1) PDP e 2) para apresentação para pré-banca.17 25/04/2018 Apresentação de projetos - Pré-Banca18 26/04/2018 Orientação equipes (PDP).19 02/05/2018 Orientação equipes (PDP).20 03/05/2018 Diretrizes para o Plano Executivo (PE), que incluir plano de divulgação em

seu último item.212223242526272829303132

ADAPTAÇÃO DO FRAMEWORK SCRUM EM DISCIPLINAS … · This study had the purpose of making a Scrum...

Documents

Transcript of ADAPTAÇÃO DO FRAMEWORK SCRUM EM DISCIPLINAS … · This study had the purpose of making a Scrum...