2 North Sea Herring 2.1 The Fishery
Run 1 Standard HCR: The first set of simulations applied the basic harvest rule agreed by Norway and EU from 2004:
5.1.1.1 Product Owner
Nos resultados preliminares, havia-se notado a potencial aplicação do papel do Product Ownerem 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 Ownersdas 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,
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 Ownerou 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.
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áveis
Projeto II - ênfase no usuário Projeto II - ênfase no produto
Briefing Briefing
Proposta de Desenvolvimento Projetual (PDP) Proposta de Desenvolvimento Projetual (PDP)
Plano Executivo Plano Executivo
Artigo Artigo
Protótipo da solução digital Implementação front-end de um website Material de divulgação Material de divulgação
Acervo 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.
Quadro 4 – Sprints e itens de backlog priorizados
S1. Definição do problema social a ser 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 dos primeiros requisitos da 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 Executivo e 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.
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
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 Masterconduza 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.
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ídias
2 Programa de extensão da Universidade onde existe um ambiente propício para alunos concludentes realizarem
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 cards
MeisterTask não não apenas quadro de tarefas
Zube.io não sim, com datas sim
MeuScrum sim sim, com datas sim
MyScrumHalf sim sim, com datas sim
Taiga 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.
Quadro 6 – Atende as demandas da disciplina? Ferramenta Criação de muitos
times
Muitos membros por 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ço com projetos públi- cos / versão paga
sim, em nuvem pri- vada / do serviço com projetos públi- cos / versão paga
sim, ferramenta open-source além de forne- cer nativamente personalizaçã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 ágil3e 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 uso
3 Best Agile Tools, Agile Awards 2015 - https://taiga.io 4 Project Management Tools 2016 - https://opensource.com/ 5 https://aws.amazon.com/ec2
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”.
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
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)