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
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.
Backlogna 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 Poker3para 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.
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 Masternão conseguiu realizar acompanhamentos na ferramenta.
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.
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 Ownersmanifestando 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.
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.
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
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
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
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.