ADAPTAÇÃO DO FRAMEWORK SCRUM EM DISCIPLINAS … · This study had the purpose of making a Scrum...
-
Upload
nguyenkiet -
Category
Documents
-
view
215 -
download
0
Transcript of 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
DANILO ALMEIDA FELIPE
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
DANILO ALMEIDA FELIPE
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
Fonte: elaborado pelo autor.
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
Fonte: elaborado pelo autor.
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)
Fonte: elaborado pelo autor.
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
Fonte: elaborado pelo autor.
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
Fonte: elaborado pelo autor.
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
Fonte: elaborada pelo autor.
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
Fonte: elaborada pelo autor.
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
Fonte: elaborada pelo autor.
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
Fonte: elaborada pelo autor.
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
Fonte: elaborada pelo autor.
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.
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.
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