Parte II - Acelerando o Aprendizado

Visão Geral

Uma estratégia eficaz de aprendizagem deve integrar conceitos teóricos com sua aplicação prática, seguindo o princípio de “aprender fazendo”. Sem prática, não há aprendizado significativo. Portanto, o processo de ensino-aprendizagem deve incluir duas etapas fundamentais: sessões de assimilação de conceitos teóricos e sessões de prática.

Embora o uso de casos acadêmicos possa ser útil, ele pode fornecer uma perspectiva limitada e estreita sobre o problema. Por isso, é fundamental preparar os alunos para a realidade do mercado de trabalho, especialmente em setores como desenvolvimento de software, que estão passando por mudanças significativas com a adoção da cultura DevOps. A integração da teoria com a prática permite que os alunos desenvolvam habilidades práticas e estejam prontos para enfrentar desafios reais em suas carreiras.

Esse capítulo é dedicado aos participantes do processo do processo de onboarding com o objetivo de aprender sobre Métodos de Desenvolvimento de Software, mais especificamente aprender os conceitos e práticas relacionados aos métodos ágeis. É a concretização do planejamento realizado na etapa anterior.

Roadmap do Metodologia

A imagem abaixo reapresenta todos os elementos da metodologia utilizada para o desenvolvimento de um ciclo de formação a partir do projeto de software. A metodologia combina fundamentos de processo de onboarding, aprendizagem por experiência e práticas de comunidades de software livre para proporcionar uma experiência de aprendizagem completa e efetiva. A imagem ilustra a cronologia do ciclo de formação e destaca os principais pontos de cada fase.

Estratégia do Coelho de Maratona

Corredores chamados de “coelhos” ou “liebres” (em espanhol) são atletas experientes que são contratados para ajudar a impor um ritmo consistente para os corredores de elite em uma maratona ou outra corrida de longa distância. Os coelhos geralmente são contratados para correr a primeira metade ou dois terços da corrida em um ritmo mais rápido do que o ritmo do recorde mundial ou do tempo desejado pelo corredor de elite. O objetivo é ajudar o corredor a manter um ritmo constante e não “quebrar” ao longo da corrida, permitindo que ele ou ela termine com um tempo mais rápido.

Um dos princípios fundamentais do desenvolvimento ágil de software é a transmissão contínua de conhecimento entre membros de uma mesma equipe. Uma estratégia eficaz para otimizar recursos no início de um projeto é alocar tarefas de estudo para diferentes membros da equipe. Esses membros são conhecidos como “coelhos” e são responsáveis por aprender sozinhos os conceitos, mapear as fontes de informação mais relevantes para o contexto do projeto e documentar o processo de aprendizagem como um tutorial. Em seguida, compartilham esse material com o restante da equipe, que acompanha o ritmo de aprendizagem dos “coelhos”. Essa abordagem é uma maneira eficiente de compartilhar conhecimento e garantir que todos os membros da equipe estejam alinhados com as metas e objetivos do projeto desde o início.

Fase Explorar - Boas Vindas e Orientações gerais

A primeira etapa da metodologia envolve introdução às informações gerais necessárias para iniciar o projeto, formação das equipes, definição de papéis, escolha de ferramentas e práticas para acolher os participantes. A duração dessa etapa pode variar dependendo da frequência dos encontros. Por exemplo, se houver dois encontros semanais, a primeira etapa pode durar até duas semanas. Já se houver apenas um encontro semanal, a primeira etapa pode durar até um mês.

Nesta etapa, as equipes começam o projeto com base nas informações gerais fornecidas. No entanto, a falta de detalhamento das entregas por sprint gera a sensação de dificuldade dos alunos na execução das tarefas. É importante ressaltar que a dificuldade nesta fase é fundamental para a aprendizagem por experiência e para o desenvolvimento de habilidades não técnicas, tais como iniciativa, autodidatismo, tomada de decisão e gestão de erros. Portanto, é importante que haja um equilíbrio entre o detalhamento das tarefas e a oportunidade de enfrentar desafios e desenvolver habilidades valiosas.

Objetivo

Acolher novos colaboradores, e apresentar informações sobre a cultura e os processos, além de conhecer os colegas de trabalho.

Propomos sessões práticas focadas no desenvolvimento de projetos Open Source, onde os alunos têm a oportunidade de desenvolver o código-fonte, planejar e automatizar o pipeline de implantação, adotando práticas, ferramentas e orientação da comunidade OSS, conforme descrito na Tabela abaixo.

É interessante destacar que essa abordagem de deixar os alunos lutarem e procurarem informações por conta própria faz parte do modelo de aprendizagem experiencial de David Kolb, que valoriza a autodescoberta e a aprendizagem autônoma como elementos-chave para o processo de aprendizagem. O curso não fornece um plano detalhado para a entrega final do projeto, o que se assemelha aos projetos de software reais. Essa decisão central é deixada para as equipes, o que lhes permite exercitar suas habilidades de gestão e decisão, além de incentivar a colaboração com outras equipes, mentores e professores. Isso inclui a definição de processos, conjunto de ferramentas, pipeline de entrega, automação, ambiente de execução, monitoramento, atribuição de tarefas, entregas, treinamento da equipe, entre outros aspectos. Aprender com base na experiência é mais importante e benéfico do que uma abordagem puramente teórica, pois evidencia como os conceitos técnicos e não técnicos estão interconectados e ambos impactam a entrega final. Vários alunos relataram a dificuldade inicial em tomar decisões e a insegurança de não ter uma lista de tarefas pré-definida. No entanto, eles reconheceram a importância da tomada de decisão para compreender os elementos que impactam a entrega contínua.

Além disso, ao apresentar os entregáveis esperados em macro atividades, permite-se que os alunos tenham liberdade para definir seus próprios caminhos e desenvolver suas habilidades não técnicas, o que pode ser extremamente valioso para sua formação como desenvolvedores. Nessa etapa são desenvolvidas várias habilidades não técnicas, como comunicação efetiva, auto aprendizagem, gestão de horas, gestão des conflitos, agir mesmo com pouca informação. Esse setup é bastante próximo de início de projetos no mercado.

Formação das Equipes

Cada aluno desempenha um papel único em uma equipe DevOps, que se assemelha a uma equipe de produto, com a responsabilidade coletiva de “Você construiu, você executa”.

As funções, suas responsabilidades e entregas são as seguintes:

• Scrum Master/Tech Leader: Responsável pela execução de conceitos e práticas de gerenciamento de projetos. Entregáveis esperados incluem documentação de processo, métricas de produtividade e análise e avaliação contínuas da maturidade das práticas ágeis da equipe.
• Estrategista de Produto: Responsável pela execução de conceitos e práticas de gestão de produto. Essa função deve descrever as personas do usuário, como o produto se encaixa no mercado atual e como atingirá as metas de negócios. Entregáveis esperados incluem planos de produtos, roteiro, plano de negócios, testes de usabilidade e identidade visual do produto.
• Arquiteto de Software: Responsável pela execução de conceitos e práticas de gerenciamento de produtos e categorias de processo de construção. Essa função lida com o aplicativo e seu fluxo de dados definindo estruturas, ferramentas e tecnologias. Entregáveis esperados incluem definição e documentação de arquitetura, seleção de linguagem de programação, uso de serviços externos (Open Source), reutilização de funcionalidades e integração de serviços e definição de critérios de qualidade.
• Engenheiro de Release/DevOps: Responsável pela execução de conceitos e práticas das categorias de integração contínua, automação de implantação e monitoramento e registro. Essa função define os estágios do pipeline de implantação, as ferramentas de automação, configura esse pipeline nos ambientes de preparação e produção. Entregáveis esperados incluem documentação, implementação de estágios de pipeline, automação de implantação contínua e testes automatizados. Monitorar o ambiente de produção é opcional.
• Equipe de Desenvolvimento: Implementa o backlog do produto em funcionalidade potencialmente entregável seguindo tecnologias estabelecidas e critérios de qualidade. Entregáveis esperados incluem o código-fonte do projeto, testes de unidade, comunicação via problemas e execução de práticas de software de código aberto.
• Professor: Auxilia no gerenciamento de riscos, apresenta conceitos teóricos relacionados ao DevOps e facilita a comunicação com outras partes interessadas.
• Instrutor: Auxilia a equipe com treinamento e feedback sobre ferramentas, tecnologias e melhores práticas no desenvolvimento de produtos de software de código aberto. Eles ajudam na cultura de colaboração e compartilham suas lições aprendidas.

É dada aos alunos total autonomia para auto-organização, para que pudessem experimentar trabalhar em um ambiente similar a empresas. Os alunos recebem total autonomia para decidir como querem organizar suas equipes. A maioria dos alunos se destaca com a autonomia total e elogiou o aspecto de autoaprendizagem do curso. Como um aluno explicou: “A diferença crucial neste curso que o destaca de todas as outras ofertas de cursos na universidade é a imensa mudança em direção à autoaprendizagem e independência de uma equipe de ensino/apoio. A quantidade de trabalho necessária rapidamente aumentou de um sprint para o próximo - o que significou que eu precisava explorar novas abordagens para aprender e, mais importante, colaborar com os outros”.

Tópicos/Temas de projetos

Os temas do projeto são apresentados no primeiro dia e sugeridos por praticantes, ex-alunos e potenciais clientes, dando às equipes autonomia para escolher o escopo do projeto, a stack tecnologica, a arquitetura de software e as ferramentas de automação.

Com o objetivo de simular a experiência de múltiplas equipes da indústria, o projeto deste ano envolveu a concepção e implementação de um software de agendamento de cursos universitários para o departamento de Engenharia de Software e Ciência da Computação da nossa universidade, utilizando práticas Scrum. Apesar de parecer um projeto simples, considerou-se que ambos os departamentos não possuíam atualmente um programa de agendamento de cursos.

As restrições do projeto são importantes para limitar o escopo do projeto, estabelecer os critérios e checklist de avaliação, orientar o planejamento, execução e priorização das tarefas. Elas também ajudam os instrutores a avaliar continuamente os riscos do projeto e dar feedback constante às equipes, de acordo com os limites definidos pelas restrições. A comunidade OSS tem uma série de padrões recomendados com foco na construção de comunidades acolhedoras. Essas práticas visam manter normas, qualidade de código, padrões técnicos, comunicação, disseminação de conhecimento, conscientização da equipe, compartilhamento de propriedade e dar boas-vindas continuamente aos novos membros. Não abordamos neste trabalho os critérios detalhados de avaliação dos alunos. Baseados fortemente nas comunidades e padrões OSS, definimos um conjunto de restrições de projeto para orientar a tomada de decisão dos alunos:

• Ambientes: cada equipe deve ter ambientes de teste e produção disponíveis;
• Padrões OSS: os padrões da comunidade OSS devem ser adotados. Padronização e problemas de modelo, modelo de branch de controle de origem, documentação do projeto, pipeline de implantação, comunicação de problemas e feedback em Pull Requests são exemplos de padrão OSS;
• Ciclos de entrega: existem dois lançamentos oficiais significativos no curso, nos quais as equipes apresentam suas soluções a um conselho de avaliação.

Práticas de aprendizagem

Especificar, projetar, trabalhar, tudo em par

É incentivado o uso de pareamento para a realização das tarefas e uma comunicação clara através das issues. O objetivo do pareamento é nivelar o conhecimento entre os membros da equipe. Embora tenhamos utilizado a técnica do coelho para acelerar o aprendizado na fase inicial, agora é importante compartilhar esse conhecimento e nivelá-lo com outros membros do squad.

O pair programming, ou programação pareada, é uma prática na qual duas pessoas trabalham juntas em um mesmo computador para escrever código. Essa abordagem altamente colaborativa requer muita comunicação e, enquanto os desenvolvedores trabalham em conjunto em uma tarefa, eles não apenas escrevem código, mas também planejam e discutem o trabalho a ser feito. Durante esse processo, ideias são esclarecidas, diferentes abordagens são avaliadas e soluções mais efetivas podem ser alcançadas. Um ótimo artigo sobre programação pareada está aqui.

Comunicação

Um elemento central das metodologias ágeis é uma comunicação efeitva. Essa mesma comunicação efetiva é adotada por comunidades de software livre. Para isso, as práticas e cultura de comunicação efetiva deve ser estimulado e respeitado desde o primeiro encontro.

Uma comunicação efetiva começa por estabelecer os canais de comuncação e o tipo de comunicação se dar por cada canal. Por exemplo, se há um canal específico de dar informes, ele não deve ser usado para tirar dúvidas ou compartilhar informações relacionados ao projeto. Aqui vão os principais tipos de comunicação adotados por comunicades de software livre e empresas:

• Issues: qualquer tarefa relacionada ao projeto deve ser documentada como uma issue. Se alguma decisão sobre uma issue é tomada (por exemplo em um pareamento, reunião), essa decisão deve ser posteriormente documentada na issue. A escrita das issues devem ser padronizadas para facilitar a compreensão de newcomers e acompanhamento do projeto. Por isso para cada tipo de issue (tarefa, User Story, Epico, etc) é necessário um template adequado. A issue é o principal canal de comunicação assincrona da equipe de desenvolvimento.
• Canal de comunicação por squad: cada squad/time deve escolher seu próprio canal de comunicação, seja o slack, servidor discord, grupo telegram/whatsapp. Normalmente esses canais servem para comunicações rápidas, coloquiais.
• Canal de comunicação geral: gerido pelo professor/gestor, esse canal reune participantes, instrutores, mentores e clientes. Aqui são trocadas mensagens sobre andamento do projeto, informes gerais, alinhamento de datas/artefatos de entrega.
• Canal de dúvidas: canal gerido pelos instrutores e squads para tirar dúvidas técnicas, pedido de análise dos artefatos, agendamento de treinamento sob demanada.
• Repositório: Toda a documentação técnica para comunicar artefatos de projeto devem ser compoartilhado em um repositório aberto, seguindo os templates, boas práticas e organização de comunidades de software livre.

Checklist

Segue um checklist para ajudar na organização do evento de recepção:

• Definir dos dias/horários/local dos encontros semanais
• Apresentar a visão geral do processo de onboarding
• Apresentar as listas de Entregáveis para a Release I e Release II
• Definir as datas da Release I e Release II
• Definir as equipes/squads
• Definir os canais de comunicação (Comunicação rápida/informes, dúvidas, decisões, tarefas)
• Definir dias/horários/locais de disponibilidades dos instrutores
• Definir dias/horários/locais dos treinamentos
• Compartilhar os repositórios de projetos passados
• Garantir que todos os participantes tem todos acessos necessários (repositório, lista de e-mails, Discord, etc)
• Garantir que todos os participantes tenham os contatos dos instrutores

Segue um checklist para ajudar na organização da primeira etapa do onboarding para o professor.

• Apresentar o ciclo de vida de projetos de software
• Apresentar práticas de gestão de equipes ágeis - Scrum
• Apresentar práticas de documentação ágil - issues, templates de issues, comunicação de issues
• Apresentar o conceito de timebox e exercitar em atividades síncronas
• Organizar um evento para que os clientes possam apresentar os problemas a serem resolvidos com software

Segue um checklist para ajudar na organização da primeira etapa do onboarding para os monitores/coaches.

• Compartilhar o contato
• Organizar as datas/horários/locais dos treinamentos
• Treinamentos sugeridos: revisão de comandos git, revisão de OO, práticas ágeis

Segue um checklist para as equipes.

• Monte a equipe e compartilhem os contatos
• Façam o mapa de horários livre, e definam os horários que cada um vai dedicar pro projeto semanalmente
• Mapeem os riscos pessoais (computador quebrando, dificuldade de conectividade, dificuldade de locomoção para as reuniões, entre outros)
• Façam o quadro de conhecimento (a partir do quadro de conhecimento, levantem os treinamentos iniciais necessários para nivelar a equipe)

• Definam o dia/horário da semana para os rituais ágeis: reunião (2 horas), retrospectiva e review (1 hora), stand up (5 min/dia)

• Métricas de sucesso:

  • Os participantes têm seu ambiente de trabalho configurado corretamente (programação em pares com o mentor, se necessário);
  • Os participantes concluíram os exercícios de git;
  • Os canais de comunicação (grupo de telegrama, questões) são usados corretamente;
  • Os interesses, habilidades, motivações e ambições dos participantes são mapeados.

• Dicas:

  • Empregue a estratégia “Recomendar tarefas repetitivas” - usamos essa estratégia para ajudar irmãos mais novos a dominar as habilidades do git e ganhar confiança antes de passar para tarefas mais complexas. Temos tarefas semanais, pedindo a eles para:
  • Atualizar o Readme de sua página pessoal do GitHub;
  • Abrir um pull request em https://github.com/twilio-labs/open-pixel-art;
  • Abrir/comentar uma no repositório do projeto.
  • Estabeleça, desde o início do programa, um cronograma de oficinas fixo (dia útil, hora) com uma duração definida. Ser capaz de organizar o tempo com antecedência é crucial para manter os participantes engajados.
  • Use o máximo possível de ferramentas de código aberto. Isso apresenta os participantes ao ecossistema FOSS e a diferentes comunidades.
  • Quando as mulheres são mentoradas por outras mulheres, elas relatam sentimentos de inspiração, solidariedade, irmandade e um ambiente amigável. Portanto, deve-se levar em consideração a interseccionalidade de gênero, raça, etnia e deficiências, tanto dos participantes quanto dos mentores, para fazer a correspondência.
  • Os mentores devem encorajar os participantes a compartilhar suas conquistas com outros participantes. Isso promove uma comunidade acolhedora, com feedback construtivo, colaboração e dificuldades antecipadas que os participantes possam estar enfrentando.

• Treinamento sugerido:

  • História do código aberto livre, filosofia, as quatro liberdades essenciais, além do software (cultura);
  • Fundamentos do git;
  • Configuração do ambiente local (instalação do Linux, instalação do git, IDE, dependências);
  • Fluxo de trabalho de contribuição de OSS (da comunicação da questão ao pull request).
  • Comunicação
  • Trabalho remoto

Fase Definir/Prototipar

O objetivo desta etapa é fornecer autonomia para as equipes desenvolverem o projeto, enquanto recebem feedback contínuo. Durante as sessões teóricas, serão apresentados os conceitos teóricos e estudos de caso para que os participantes possam relacioná-los com as práticas executadas.

Nesta etapa, as equipes começam a criar os primeiros artefatos do projeto e a tomar as principais decisões, como a escolha da tecnologia, ferramentas, escopo e arquitetura. Os mentores e professores auxiliam na gestão de riscos, intervindo somente em propostas inviáveis. É crucial respeitar a autonomia das equipes e suas decisões, mesmo que estas contrariem as orientações dadas. As equipes não devem ser punidas por decisões equivocadas, pois o mais importante é compreender os conceitos e desenvolver um senso crítico para entender as razões dos erros.

O foco dessa etapa é medir e otimizar a produtividade dos squads. Algumas métricas de produtividade de equipe são o burndown, velocity, quantidade de issues fechadas por membro. Existem muitos outros fatores que podem afetar a produtividade da equipe de software, como a qualidade do código, a eficiência da comunicação e colaboração entre os membros da equipe, a utilização de boas práticas de desenvolvimento de software, a adoção de tecnologias e ferramentas modernas, entre outros.

Compreender o trabalho invisível e o impacto que ele tem na produtividade da equipe é crucial para o sucesso de um projeto de software. Quando esse trabalho é ignorado ou subestimado, pode haver uma lacuna significativa entre as expectativas das partes interessadas e a realidade do trabalho da equipe de desenvolvimento.

Isso pode levar a problemas de comunicação e compreensão, resultando em frustração, mal-entendidos e atrasos no projeto. Além disso, a falta de reconhecimento e valorização do trabalho invisível pode levar à rotatividade de colaboradores, pois a equipe pode sentir-se desmotivada e subestimada.

Cabe à liderança da equipe e dos facilitadores reconhecer e valorizar o trabalho invisível realizado pela equipe de software, comunicar de forma clara e transparente com as partes interessadas do negócio e garantir que haja um entendimento mútuo das expectativas e dos objetivos do projeto. Isso pode ser alcançado através de uma comunicação frequente e efetiva entre a equipe de desenvolvimento de software e as partes interessadas, bem como pelo estabelecimento de um ambiente de trabalho colaborativo e inclusivo.

Ao reconhecer e valorizar o trabalho invisível e promover uma cultura de comunicação aberta e transparente, a liderança pode ajudar a minimizar a lacuna entre as expectativas das partes interessadas e a realidade do trabalho da equipe de software, promovendo um ambiente de trabalho mais saudável e produtivo e impulsionando o crescimento.

Alguns exemplos podem incluir:

• Acompanhamento e avaliação de métricas de qualidade e desempenho do software;
• Análise de dados e feedback dos usuários para orientar a tomada de decisões de desenvolvimento;
• Realização de testes de integração e testes automatizados;
• Gerenciamento de configuração de software e controle de versão;
• Participação em treinamentos e desenvolvimento profissional;
• Colaboração com outras equipes ou departamentos da empresa, como equipes de operações, marketing e vendas, para garantir a integração efetiva do software no ambiente de negócios.

Definindo o significado de Pronto

Entregas

Embora o objetivo principal do curso seja desenvolver um projeto para avaliar o aprendizado, também foram definidos outros entregáveis durante o período. A lista de entregáveis inclui:

• Documento de especificação de requisitos (Roadmap, StoryMap)
• Planejamento, demonstração e retrospectiva para cada sprint
• Revisão por pares para cada sprint
• Logbook para cada sprint
• Documentação do projeto de acordo com padrões de Software Livre e relatório final (Release notes)
• Apresentação Release 1
• Código fonte evidenciando a viabilidade da arquitetura

O logbook, ou diário de bordo, é uma ferramenta utilizada para cada aluno registrar as atividades realizadas pelos durante cada sprint, bem como o número de horas dedicadas a cada uma delas. Essa prática permite uma melhor gestão do tempo e das atividades, além de facilitar o monitoramento do progresso individual de cada estudante.

Na última semana, cada equipe é solicitada a apresentar uma demonstração ao vivo da solução para o cliente e realizar uma apresentação final. Além disso, cada equipe escreve um relatório final contendo todas as decisões de projeto, suposições e resultados obtidos.

Checklist

Nesta fase do projeto, espera-se que as práticas ágeis estejam sendo executadas de forma mais madura e a equipe tenha uma métrica estável de produtividade da equipe. Para ajudar a garantir a produtividade da equipe, segue um checklist com algumas práticas ágeis a serem consideradas:

• Os rituais de planejamento, review, retrospectiva estão acontecendo sempre no mesmo dia/horário?
• Os rituais são time-box (começam sem atraso e terminam no horário limite estipulado)?
• A técnica de planning poker está sendo feita para pontuar as issues?
• As issues (US, features, Épicos) são documentadas de forma padronizadas (seguind templates)?
• Tem pelo menos 1 issue por membro/dupla por sprint?
• Os stand-ups estão acontecendo todos os dias?
• Todos os membros se sentem a vontade para falar nos rituais?

Segue um checklist de alguns artefatos desenvolvidos nessa etapa do projeto:

• Checklist dos padrões de comunidade de OSS devem ter sido cumpridos https://opensource.guide

• Métricas de Sucesso:

  • O participante consegue subir o ambiente do projeto em um ambiente local;
  • O participante consegue modificar o projeto;
  • O participante participa ativamente das discussões das sessões teóricas;
  • Os participantes trabalham em pares para resolver problemas propostos;
  • O participante se sente confortável compartilhando com o mentor/coach suas dificuldades;
  • O participante se sente confortável compartilhando suas realizações nas sessões teóricas;
  • O participante compreende a importância da documentação técnica no ecossistema de código aberto;
  • O participante estabelece objetivos claros e expectativas sobre o programa e percebe suas melhorias.

• Dicas:

  • Utilize a programação em pares entre os participantes e superpareamento com mentores técnicos, se necessário;
  • Divida as tarefas em pedaços menores - tarefas desafiadoras podem criar medos sociais nos novatos;
  • Como os participantes podem ter diferentes habilidades técnicas, o mentor/coach deve monitorar o progresso dos participantes e garantir que eles se sintam desafiados e motivados;
  • Os mentores devem se comunicar com a organização sobre as dificuldades enfrentadas pelos participantes para que possamo professor possa ajustar as tarefas/entregas para atender às expectativas dos participantes;

Fase Desenvolver/Testar

A terceira fase consiste em consolidar os conceitos aprendidos, manter a produtividade da equipe e focar na qualidade de código.

A medição da produtividade das equipes de software é uma tarefa complexa e desafiadora. Em primeiro lugar, a própria noção de produtividade pode ser subjetiva e variar de pessoa para pessoa. Mesmo quando se estabelecem parâmetros de referência e métricas, a percepção da produtividade por um engenheiro de software pode ser diferente daquela de um executivo ou membro do conselho.

No desenvolvimento de software, a produtividade não se resume apenas ao volume de código escrito ou à ausência de erros. Existem muitos outros fatores que podem influenciar a produtividade da equipe, como a qualidade do código, a eficiência do processo de desenvolvimento, a colaboração entre membros da equipe, o uso de ferramentas e tecnologias apropriadas, entre outros.

Portanto, para medir adequadamente a produtividade de uma equipe de software, é essencial ter uma compreensão abrangente e holística do processo de desenvolvimento, bem como das necessidades e objetivos da empresa. Além disso, é importante ter uma abordagem flexível e adaptável, que possa se ajustar às mudanças nas prioridades e demandas do projeto. Somente assim será possível obter uma visão precisa e útil da produtividade da equipe.

É verdade que métricas como Deployment Frequency, Cycle Time, Pull Request Throughput, Code Activity e Lead Time podem ser úteis para medir a produtividade das equipes de software. No entanto, é importante lembrar que essas métricas não são a única forma de medir a produtividade e podem não ser suficientes por si só.

A maturidade no desenvolvimento de software é um conceito que se refere à capacidade da equipe de software de entregar um produto de alta qualidade, confiável e seguro de maneira consistente e previsível. Isso implica ter processos de desenvolvimento de software bem definidos, testes automatizados e uma cultura de qualidade e melhoria contínua.

Por outro lado, a produtividade no desenvolvimento de software se concentra no ritmo e eficiência do trabalho da equipe, medindo a capacidade de produzir resultados de maneira rápida e eficaz. Isso inclui métricas como a quantidade de trabalho concluído em um determinado período de tempo, a rapidez com que as alterações de código são implementadas e a frequência com que o software é distribuído para o usuário final.

Equipes de alto desempenho em desenvolvimento de software devem reconhecer a importância de investir tempo em apoiar outras atividades que são vitais para o sucesso do projeto, mesmo que não envolvam diretamente alterações de código ou mudanças visíveis aos usuários. Essas atividades podem incluir a melhoria contínua dos processos de desenvolvimento,

Sessões Teóricas

Durante o curso, os alunos participaram de aulas teóricas, palestras e painéis de discussão sobre tópicos como: habilidades críticas de engenharia de software, regras não ditas para iniciar sua carreira, coordenação e comunicação, gestão do conhecimento, cultura e confiança. Nos painéis, eles tem a oportunidade de compartilhar suas experiências de trabalho no projeto e aprender com os painelistas da indústria.

Além disso, os alunos são desafiados a escrever reflexões em postagens de blog, conectando os tópicos com suas experiências e projetos. Por exemplo, eles poderiam escrever sobre como a coordenação e a comunicação foram importantes para o sucesso do projeto de programação de cursos. Essas atividades ajudaram os alunos a refletir sobre suas habilidades e conhecimentos e a aplicá-los no contexto do projeto.

Entregas

Embora o objetivo principal do curso seja desenvolver um projeto para avaliar o aprendizado, também foram definidos outros entregáveis durante o período. A lista de entregáveis inclui:

Checklist

Segue um checklist para ajudar na organização do evento de recepção:

Segue um checklist para ajudar na organização da primeira etapa do onboarding para o professor/mentor.

Segue um checklist para ajudar na organização da primeira etapa do onboarding para os instrutores.

• Métricas de Sucesso:
  • O participante contribui para o projeto;
  • Os participantes se sentem confiantes em suas habilidades para contribuir para outras comunidades de software livre;
  • Os participantes se sentem motivados a contribuir para projetos de software livre;
  • O participante entende os benefícios de contribuir para o projeto de software livre (autoaperfeiçoamento, construção de portfólio, mentoria, projetos interessantes).
• Dicas:
  • Aconselhe os participantes a escolherem issues que estejam de acordo com suas habilidades e objetivos de carreira;
  • Apresente o fluxo de trabalho de contribuição da comunidade de software livre;
  • Certifique-se de que todos os participantes tenham o ambiente local funcionando corretamente (caso contrário, faça pair programming com eles para resolver os problemas ou tenha uma codificação ao vivo específica para configurar o ambiente);
  • Dê feedback constante aos participantes durante o workshop e especialmente em questões / pull requests;
  • Mapeie questões para diferentes conjuntos de habilidades (documentação, comunicação, implementação, correção de bugs);
  • Verifique com mais frequência para ver se o participante está bloqueado;
  • Configure sessões em pares para os participantes trabalharem em contribuições;

Releases/Fechamento

O release de software é o processo de lançamento de uma nova versão de um software para o público. É uma etapa importante do ciclo de vida do desenvolvimento de software, que permite que os usuários experimentem e aproveitem as novas funcionalidades e correções de bugs. Os releases podem ser classificados em várias categorias, como major releases (que incluem grandes mudanças e novas funcionalidades), minor releases (que incluem pequenas correções e melhorias), ou patches (que corrigem bugs críticos). O processo de release é geralmente gerenciado pelo time de desenvolvimento de software e inclui testes extensivos antes de ser lançado para o público. Para os alunos universitários, é importante compreender o conceito de release de software para entender como os softwares são desenvolvidos e lançados, e para ter uma ideia do que esperar quando usam um software.

Os artefatos esperados em uma release de software incluem:

• Código-fonte: a última versão do código-fonte, já testado e aprovado para lançamento.
• Documentação técnica: especificações técnicas, diagramas e outros documentos técnicos que descrevem como o software funciona.
• Testes: relatórios de testes que mostram que o software passou em todos os testes e está pronto para o lançamento.
• Pacotes de instalação: arquivos necessários para instalar o software em diferentes plataformas.
• Notas de Release: descrição detalhada das novas funcionalidades, correções de bugs e outros aprimoramentos incluídos na nova versão.
• Estes artefatos são importantes para garantir que a nova versão do software seja facilmente compreendida e utilizada pelos usuários, e para documentar as mudanças feitas no software durante o processo de desenvolvimento.

Release 1/Release 2

O objetivo principal das apresentações da R1/R2 é evidenciar o aprendizado da equipe, tanto individual quanto coletivamente, demonstrando que eles foram capazes de compreender os conceitos apresentados em sala de aula e aplicá-los no projeto desenvolvido.

É importante lembrar que os avaliadores já leram todo o conteúdo disponível no repositório do projeto e que parte do público presente não irá avaliar o projeto, mas estará interessado no produto de software proposto. Portanto, é crucial que a apresentação se concentre nos elementos da proposta que não estão disponíveis no Github.

Para isso, é fundamental responder às seguintes perguntas:

• Qual é a proposta do produto de software?
• Como funciona a aplicação proposta? Quais são as principais funcionalidades?
• Quais foram as lições aprendidas durante o projeto? Isso inclui tanto aspectos positivos quanto negativos.
• Qual foi o impacto das práticas ágeis na forma como o projeto foi desenvolvido? Seja específico, mencionando como a retrospectiva ajudou na gestão de riscos e aumento da produtividade, por exemplo.
• Como a equipe interpreta as métricas do projeto, como burndown, velocity e issues abertas/fechadas?
• Qual é a complexidade técnica da solução proposta?
• Certifique-se de que a apresentação seja clara e objetiva, destacando as informações mais relevantes para o público presente. Use exemplos e ilustrações sempre que possível para tornar a apresentação mais interessante e fácil de entender. Boa sorte!

Dicas

• Como fazer boas apresentações Dicas de slides - https://www.ime.usp.br/~kon/ResearchStudents/dicasSlides.html