1. Introdução

Nesse Repositório você encontra material complementar para a disciplina MDS. Se você está estudando Métodos de Desenvolvimento de Software, este repositório pode ser uma ferramenta valiosa para ajudá-lo a aprimorar seus conhecimentos e aprofundar seu aprendizado.

O repositório contém diversos materiais complementares, incluindo artigos, livros, vídeos e apresentações. Esses materiais podem ajudá-lo a entender melhor os conceitos e práticas relacionados a MDS, bem como fornecer exemplos de como aplicá-los na prática.

O objetivo deste repositório é fornecer um ambiente de aprendizado aberto e colaborativo, onde os alunos possam se ajudar mutuamente e compartilhar suas experiências de aprendizado. Portanto, sinta-se à vontade para explorar o repositório, fazer perguntas e compartilhar seus próprios materiais e ideias.

Lembre-se de que a disciplina MDS é uma área em constante evolução, e novas técnicas e ferramentas estão surgindo o tempo todo. Portanto, manter-se atualizado com as últimas tendências e práticas é fundamental para se tornar um desenvolvedor de software bem-sucedido e competente.

Esperamos que este repositório ajude você a alcançar seus objetivos de aprendizado em MDS e a se tornar um profissional de software excepcional. Boa sorte em seus estudos!

Esta seção tem como objetivo apresentar os planos de ensino da disciplina MDS, bem como fornecer algumas diretrizes úteis para a sua compreensão. Fique à vontade para fazer contribuições e melhorias contínuas no conteúdo apresentado.

O que você vai encontrar

  • Plano de ensino
  • Principais ponteiros necessários para a disciplina
  • Guias para as primeiras semanas e para a entrega de releases

Para mais informação sobre o a disciplina, acesse nosso ebook Como Acelerar o Aprendizado e Disseminar a Cultura de Inovação Ágil.

Plano de Ensino

O plano de Ensino está disponibilizado aqui

Organização da Disciplina

Projetos/Grupos

O tema do semestre é Visualização de dados. Todos os projetos possuem um contexto específico, com o objetivo comum à todos os projetos de criar indicadores a partir dos dados e apresentar para o usuário.

São três projetos e cada projeto é composto por até 3 squads. Cada squad tem um tech lead, product Owner/Manager, DevOps, Arquiteto, e desenvolvedores.

Indicadores SIGAA

Indicadores Alunos UnB

Indicadores Brasil.io

Projeto Brasilio

Critérios de Avaliação

  • Três categorias de avaliação: "iniciante", "saudável", "maduro" e três aspectos de avaliação: "Código", "Equipe" e "Projeto"

Etapa Iniciante

  • peso: 20%
  • Código
    • repositório configurado
    • licença de software
    • ambiente de desenvolvimento configurado
  • Equipe
    • atribuições de papéis
    • standup e mobs iniciais rolando
    • ambiente de trabalho informativo criado (Github)
    • definida política de horas extras
    • planilha para controle de horas trabalhadas
    • execução dos rituais do scrum
  • Projeto
    • meio de comunicação definido
    • Documentos do projeto revisados

Etapa Saudável

  • peso: 30%
  • Código
    • commits frequentes
    • início testes
    • início pipeline de CI/CD (testes + entregável) -Equipe
    • bom rodízio de pares
    • consistência em mobs
    • Planejamento maduro
    • Velocity estável
    • Métricas de produtividade equilibada
    • Comunicação efetiva
  • Projeto
    • boa comunicação
    • ter feito a primeira entrega
    • Ambiente de homologação

Etapa Maduro

  • peso: 50%
  • Código
    • tracking
    • testes automatizados
    • cobertura de testes
    • pipeline de CI/CD (testes + entregável)
    • artefatos para continuidade do projeto
  • Equipe
    • TDD
    • auto organização ("coach invisível")
  • Projeto
    • demais entregas (funcionalidades implementadas + manutenibilidade - como outra equipe pode continuar o projeto)

Obs.: Por manutenibilidade entende-se documentação sobre como ter um ambiente de desenvolvimento completo com os testes passando, ponteiros para pontos interessantes no código para novos contribuidores, e funcionalidades mais simples para estes implementarem enquanto conhecem o sistema.

Aulas

DataDia da SemanaAula
18/01/2022Terça-feiraSprint 0 - Aula 01 Planejamento sprint 0 Apresentação da disciplina Definição da dinâmica do curso Iniciar os treinamentos (git, ágil, documentos)
20/01/2022Quinta-feiraSprint 0 - Aula 2 Ciclo de projeto Apresentação dos Projetos Aula: Revisão de Git https://education.github.com/git-cheat-sheet-education.pdf
25/01/2022Terça-feiraSprint 01 - Aula 01 Planejamento Sprint 1 Definição dos projetos Iniciar a definição de escopo do projeto (Roadmap, documento de visão, EAP, TAP) - Estudar documento de arquitetura
27/01/2022Quinta-feiraSprint 01 - Aula 02 Modelos de processo Métodos ágeis Planejamento ágil Material assincrono: https://youtu.be/OzTGRO7UGyY Material assincrono: https://youtu.be/WiRwKm9M5w8
01/02/2022Terça-feiraSprint 02 - Aula 01 Planejamento Sprint 02 Scrum/Kanban/spotify Papéis, artefatos, rituais Documentos: planning sprint/review sprint/issues Revisar escopo projeto, iniciar documento de Arquitetura, escolha tecnológica. Treinamento papéis, Aula assincrona: https://youtu.be/NoGhC1LaaAE https://youtu.be/Q3MxVo9zdvU
03/02/2022Quinta-feiraSprint 02 - Aula 02 Requisitos ágeis (Épicos, features, História de usuário, task, bugs) Artefatos: EAP, Documento de Visão, Backlog de produto, Backlog da sprint, documento de requisitos funcionais/não funcionais Treinamento: uso do zenhub Slide da aula: https://docs.google.com/presentation/d/1P2-Odi4s-IZ2-OGN9Xqcb5ngqczZDBszqi4w8swawhE/edit?usp=sharing Material complementar (Design com olhar disruptivo): https://youtu.be/vlbB0xYRulQ
08/02/2022Terça-feiraSprint 03 aula 01 Show me the code Grupos apresentarem documentação
10/02/2022Quinta-feiraSprint 03 - Aula 02 Arquitetura de software Components, Camadas, diagramas UMLs Documentos: documento de arquitetura, pipeline Material assíncrono: https://youtu.be/oCjZNteAvg0 https://youtu.be/RCnmxKZjIQM Material de estudo: https://martinfowler.com/architecture/
15/02/2022Terça-feiraSprint 04 - Aula 01 Controle de versão e desenvolvimento colaborativo Gitflow https://about.gitlab.com/images/press/git-cheat-sheet.pdf https://docs.gitlab.com/ee/topics/gitlab_flow.html
17/02/2022Quinta-feiraSprint 04 - Aula 02 Política de Branches - aprendendo o fluxo de colaboração - Pull request, merge request, revisão, papel mantenedor. https://github.com/fga-eps-mds/Qualifying-Software-Engineers-Undergraduates-in-DevOps/issues/24
22/02/2022Terça-feiraSprint 05 - Aula 01 Papéis ágeis - Scrum master Produtividade, métricas ágeis (retrospectiva, burndown, velocity, quadro de conhecimento, health check), maturidade das práticas (comunicação nas issues/PRs, rituais time box, pareamento)
24/02/2022Quinta-feiraSprint 05 - aula 02 Controle de Versão e Integração Contínua Isolamento de ambiente Aula Assíncrona: https://www.youtube.com/watch?v=-Vui7mdYkgk&t=1920s https://www.youtube.com/watch?v=FBrUzyKviJw
01/03/2022Terça-feiraInício Sprint 06 Feriado
03/03/2022Quinta-feiraSprint 06 - aula 02 Entrega Release O que é release - Release Train Release notes - https://github.com/RocketChat/Rocket.Chat/releases/tag/4.5.0 Material de Apoio - https://www.thoughtworks.com/en-br/radar/techniques/release-train https://www.scaledagileframework.com/agile-release-train/
08/03/2022Terça-feiraRelease 01 Vídeo por projeto (Máx 4 minutos) Vídeo por squad (Max 4 minutos)
10/03/2022Quinta-feiraSprint 06 - aula 02 Soft Skills - agilista - agile brazil Slides - https://drive.google.com/file/d/1L01HuKcFPueg6wPwlPdCHgPWN8MQe7nk/view?usp=sharing
15/03/2022Terça-feiraSprint 07 - aula 01 Síncrona - 10 min Início Sprint
17/03/2022Quinta-feiraSprint 07 - aula 02 Extreme Programming (XP) O que é? Práticas (programação pareada, testes automatizados, testes unitários, integração) Slides: https://www.slideshare.net/hotpop/introduo-programao-extrema-extreme-programming-xp
22/03/2022Terça-feiraSprint 08 -Aula 01 Início Sprint
24/03/2022Quinta-feiraSprint 08 - Aula 02 Testes Testes unitários Testes integração Teste aceitação Testes automatizados práticas de testes - TDD + pair programming Git colaborativo práticas de Gerência de Configuração
29/03/2022Terça-feiraSprint 09 - Aula 01 Síncrona - Avisos Planning - trabalho dos grupos
31/03/2022Quinta-feiraSprint 09 - Aula 02 Qualidade de software Qualidade estática de software Clean Code/SOLID Code climate, LINT
05/04/2022Terça-feiraSprint 10 - Aula 01 Síncrona - Avisos Início Sprint
07/04/2022Quinta-feiraSprint 10 - Aula 02 Pipeline de Integração Stages Build automatizada Testes automatizados qualidade de software deploy
12/04/2022Terça-feiraSprint 11 - Aula 01 Síncrona - Avisos Início Sprint
14/04/2022Quinta-feiraSprint 11 - aula 02 Aula: Licenças de software livre Copyright, patentes e aspectos legais Outros modelos de processo Cascata / RUP
19/04/2022Terça-feiraSprint 12 - aula 01 Início Sprint
21/04/2022Quinta-feiraFeriado
26/04/2022Terça-feiraRelease 02 - MVP - Poc
28/04/2022Quinta-feiraRetrospectiva Disciplina
03/05/2022Terça-feira
05/05/2022Quinta-feiraEntrega notas final - revisão

Plano de Ensino

O plano de Ensino está disponibilizado aqui

Organização da Disciplina

Projetos/Grupos

O tema do semestre é Visualização de dados. Para isso, precisamos de DADOS!! As equipes, ou squads, são compostas por até 8 integrantes, serão responsável pela Extração de Dados (Webscraping), pelo armazenamentos dos dados (bancos de dados) e pela apresentação/processamento dos dados.

Quais são as fontes dos dados? Vocês escolhem.. pode ser requisição de uma API, pode ser via webscraping, pode ser fazendo a copia de um banco de dados. Alguns contextos interessantes: Brasil.io, o proprio Siga da unb, dados de saúde, etc.

Cada grupo deve definir o seu próprio escopo.

Apresentações

  • Release 1 (major) - 10 de dezembro de 2022
  • Release 2 (major) - 26 de janeiro de 2022

Release I

  • A Release 1 A ordem de apresentacao é sorteada, mas os grupos sao podem trocar entre si a ordem.

  • Peso da R1 - 40% da nota de projeto

  • Tempo de apresentação: 15 minutos

  • Artefatos avaliados: (I) Documento de Visão do Projeto, (II) Planejamento/Comunicação Interna e Externa (agenda de trabalho + ferramentas), Documento de Arquitetura do Projeto, (III) Especificação das historias de usuários (critérios de aceitação), (IV) Configuração do repositório de acordo com os padrões de comunidade de software livre (Github), (V) Wiki atualizada (VI) Protótipo de alta fidelidade

  • Praticas avaliadas: pareamento, produtividade, participação nos rituais, desempenho

  • Detalhamento da avaliação: Código-Fonte/entregas (30%), (II) Coerência entre a documentação e implementação (10%), (III) Documentação: Doc. visão (15%), doc arq (15%), Requisitos Especificados (10%), Protótipo (10%), (IV) critério extra(10%)

Release II

  • A Release 2 A ordem de apresentacao é sorteada, mas os grupos sao podem trocar entre si a ordem.

  • Peso da R2 - 60% da nota de projeto

  • Tempo de apresentacao: 15 minutos

  • Detalhe da avaliacao: (I) Codigo-fonte entregue (60%): features, implantacao, qualidade, cobertura de testes, testes de aceitacao, (II) documentação/evidências da execução metodologia de desenvolvimento contínua (30%), (III) Tracking (10%)

Critérios de Avaliação

Os critérios de avaliação estão detalhados no plano e ensino aqui.

As notas são dadas em cada critério a partir do nível de maturidade individual na disciplina, de acordo com as três categorias abaixo:

  • Três categorias de avaliação: "iniciante", "saudável", "maduro" e três aspectos de avaliação: "Código", "Equipe" e "Projeto"

Etapa Iniciante

  • peso: 20%
  • Código
    • repositório configurado
    • licença de software
    • ambiente de desenvolvimento configurado
  • Equipe
    • atribuições de papéis
    • standup e mobs iniciais rolando
    • ambiente de trabalho informativo criado (Github)
    • definida política de horas extras
    • planilha para controle de horas trabalhadas
    • execução dos rituais do scrum
  • Projeto
    • meio de comunicação definido
    • Documentos do projeto revisados

Etapa Saudável

  • peso: 30%
  • Código
    • commits frequentes
    • início testes
    • início pipeline de CI/CD (testes + entregável) -Equipe
    • bom rodízio de pares
    • consistência em mobs
    • Planejamento maduro
    • Velocity estável
    • Métricas de produtividade equilibada
    • Comunicação efetiva
  • Projeto
    • boa comunicação
    • ter feito a primeira entrega
    • Ambiente de homologação

Etapa Maduro

  • peso: 50%
  • Código
    • tracking
    • testes automatizados
    • cobertura de testes
    • pipeline de CI/CD (testes + entregável)
    • artefatos para continuidade do projeto
  • Equipe
    • auto organização ("coach invisível")
  • Projeto
    • demais entregas (funcionalidades implementadas + manutenibilidade - como outra equipe pode continuar o projeto)

Obs.: Por manutenibilidade entende-se documentação sobre como ter um ambiente de desenvolvimento completo com os testes passando, ponteiros para pontos interessantes no código para novos contribuidores, e funcionalidades mais simples para estes implementarem enquanto conhecem o sistema.

Aulas

DataDia da SemanaAula
Terça-feiraSprint 0 - Aula 01 Planejamento sprint 0 Apresentação da disciplina Definição da dinâmica do curso Iniciar os treinamentos (git, ágil, documentos)
Quinta-feiraSprint 0 - Aula 2 Ciclo de projeto Apresentação dos Projetos Aula: Revisão de Git https://education.github.com/git-cheat-sheet-education.pdf
Terça-feiraSprint 01 - Aula 01 Planejamento Sprint 1 Definição dos projetos Iniciar a definição de escopo do projeto (Roadmap, documento de visão, EAP, TAP) - Estudar documento de arquitetura
Quinta-feiraSprint 01 - Aula 02 Modelos de processo Métodos ágeis Planejamento ágil Material assincrono: https://youtu.be/OzTGRO7UGyY Material assincrono: https://youtu.be/WiRwKm9M5w8
Terça-feiraSprint 02 - Aula 01 Planejamento Sprint 02 Scrum/Kanban/spotify Papéis, artefatos, rituais Documentos: planning sprint/review sprint/issues Revisar escopo projeto, iniciar documento de Arquitetura, escolha tecnológica. Treinamento papéis, Aula assincrona: https://youtu.be/NoGhC1LaaAE https://youtu.be/Q3MxVo9zdvU
Quinta-feiraSprint 02 - Aula 02 Requisitos ágeis (Épicos, features, História de usuário, task, bugs) Artefatos: EAP, Documento de Visão, Backlog de produto, Backlog da sprint, documento de requisitos funcionais/não funcionais Treinamento: uso do zenhub Slide da aula: https://docs.google.com/presentation/d/1P2-Odi4s-IZ2-OGN9Xqcb5ngqczZDBszqi4w8swawhE/edit?usp=sharing Material complementar (Design com olhar disruptivo): https://youtu.be/vlbB0xYRulQ
Terça-feiraSprint 03 aula 01 Show me the code Grupos apresentarem documentação
Quinta-feiraSprint 03 - Aula 02 Arquitetura de software Components, Camadas, diagramas UMLs Documentos: documento de arquitetura, pipeline Material assíncrono: https://youtu.be/oCjZNteAvg0 https://youtu.be/RCnmxKZjIQM Material de estudo: https://martinfowler.com/architecture/
Terça-feiraSprint 04 - Aula 01 Controle de versão e desenvolvimento colaborativo Gitflow https://about.gitlab.com/images/press/git-cheat-sheet.pdf https://docs.gitlab.com/ee/topics/gitlab_flow.html
Quinta-feiraSprint 04 - Aula 02 Política de Branches - aprendendo o fluxo de colaboração - Pull request, merge request, revisão, papel mantenedor. https://github.com/fga-eps-mds/Qualifying-Software-Engineers-Undergraduates-in-DevOps/issues/24
Terça-feiraSprint 05 - Aula 01 Papéis ágeis - Scrum master Produtividade, métricas ágeis (retrospectiva, burndown, velocity, quadro de conhecimento, health check), maturidade das práticas (comunicação nas issues/PRs, rituais time box, pareamento)
Quinta-feiraSprint 05 - aula 02 Controle de Versão e Integração Contínua Isolamento de ambiente Aula Assíncrona: https://www.youtube.com/watch?v=-Vui7mdYkgk&t=1920s https://www.youtube.com/watch?v=FBrUzyKviJw
Terça-feiraInício Sprint 06 Feriado
Quinta-feiraSprint 06 - aula 02 Entrega Release O que é release - Release Train Release notes - https://github.com/RocketChat/Rocket.Chat/releases/tag/4.5.0 Material de Apoio - https://www.thoughtworks.com/en-br/radar/techniques/release-train https://www.scaledagileframework.com/agile-release-train/
Terça-feiraRelease 01 Vídeo por projeto (Máx 4 minutos) Vídeo por squad (Max 4 minutos)
Quinta-feiraSprint 06 - aula 02 Soft Skills - agilista - agile brazil Slides - https://drive.google.com/file/d/1L01HuKcFPueg6wPwlPdCHgPWN8MQe7nk/view?usp=sharing
Terça-feiraSprint 07 - aula 01 Síncrona - 10 min Início Sprint
Quinta-feiraSprint 07 - aula 02 Extreme Programming (XP) O que é? Práticas (programação pareada, testes automatizados, testes unitários, integração) Slides: https://www.slideshare.net/hotpop/introduo-programao-extrema-extreme-programming-xp
Terça-feiraSprint 08 -Aula 01 Início Sprint
Quinta-feiraSprint 08 - Aula 02 Testes Testes unitários Testes integração Teste aceitação Testes automatizados práticas de testes - TDD + pair programming Slides: https://www.slideshare.net/hotpop/introduo-qualidade-e-testes-geis-de-software Git colaborativo práticas de Gerência de Configuração https://www.slideshare.net/hotpop/gerncia-de-configurao-gil Material complementar: Pytest - https://medium.com/assertqualityassurance/tutorial-de-pytest-para-iniciantes-cbdd81c6d761 https://github.com/pluralsight/intro-to-pytest
Terça-feiraSprint 09 - Aula 01 Síncrona - Avisos Planning - trabalho dos grupos
Quinta-feiraSprint 09 - Aula 02 Qualidade de software Qualidade estática de software Clean Code/SOLID Code climate, LINT Slides: Revisão de Codigo/Code Review: https://github.com/thamara/thamara/blob/7111f8907f2f2737902be4e60d7dc7f56e5d1bcc/presentations/2020-11-19%20Shes%20Tech%20-%20Code%20Review/Revisão%20de%20Código.pdf Dicas: https://github.com/MunGell/awesome-for-beginners
Terça-feiraSprint 10 - Aula 01 Síncrona - Avisos Início Sprint
Quinta-feiraSprint 10 - Aula 02 Pipeline de Integração Stages Build automatizada Testes automatizados qualidade de software deploy
Terça-feiraSprint 11 - Aula 01 Síncrona - Avisos Início Sprint
Quinta-feiraSprint 11 - aula 02 Aula: Licenças de software livre Copyright, patentes e aspectos legais Outros modelos de processo Cascata / RUP
Terça-feiraSprint 12 - aula 01 Início Sprint
Quinta-feiraFeriado
Terça-feiraRelease 02 - MVP - Poc
Quinta-feiraRetrospectiva Disciplina
Terça-feira
Quinta-feiraEntrega notas final - revisão

Metodos de Desenvolvimento de Software - Plano de ensino

DISCIPLINA: Métodos de Desenvolvimento de Software

CARGA HORÁRIA: 60 horas

PROFESSOR: Carla Rocha

CREDITOS: 04

SEMESTRE/ANO: 01/2023

Objetivos da Disciplina

Métodos de desenvolvimento de software podem ser entendidos como conjuntos estruturados de boas práticas, podendo ser repetıveis durante o processo de produção do software.

Os principais objetivos da disciplina são:

  • Capacitar o aluno a compreender os diferentes métodos, ferramentas, procedimentos e complexidade do desenvolvimento de software.

  • Capacitar o aluno a aplicar / adaptar processos de desenvolvimento de software a resolução de problemas de software.

  • Capacitar os estudantes para construírem sistemas complexos, apresentar as habilidades técnicas e não técnicas necessárias para a construção de software no contexto atual da Indústria.

Ementa do Programa

Modelos de ciclo de vida e de processos; Processo Unificado. Métodos Ágeis de desenvolvimento de software. Outras abordagens de desenvolvimento de software. Ferramentas.

Metodologia de Ensino

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.

A disciplina usa aprendizagem por experiência, aprendizagem orientada a projetos, processo de Onboarding, e práticas de comunidades Open source para que o aluno seja ativo no seu processo de aprendizagem. A imagem abaixo mostra o ciclo da disciplina:

image

Formação das equipes

A turma deve se dividir em equipes ágeis, de até 6 membros por time. Serão apresentados temas de projeto e, cada grupo escolhe 3 temas na ordem de preferência. A professora negocia e aloca os temas para o grupo, dentro das preferências.

  • A planilha para definição dos grupos e temas aqui

Canais de Comunicação

A disciplina será realizada de forma presencial na sala Mocap. Serão disponibilizado tanto material assincrono quanto aulas sincronas.

Dúvidas, conversas rápidas, avisos

Aulas assíncronas

  • Vídeos disponibilizadas no youtube - [canal youtube] (https://www.youtube.com/channel/UC_VXpS5GIL8NdJNkwNeAorw/videos?view_as=subscriber)
  • Leituras sugeridas na sprint - disponibilizados no planejamento das aulas

Planejamento das aulas

  • O planejamento das aulas semanais, discriminando se são assíncronas ou síncronas, e qual canal vai ser atualizado no início da semana no link

Descrição do Programa

Processos de Desenvolvimento de Software

  • Modelos de Processo de Desenvolvimento de Software (ciclo de vida)
  • Atividades de Processo

Fundamentos do Extreme Programming

  • O manifesto Ágil
  • Os Quatro valores e as Quatro variáveis
  • Praticas ageis
  • O jogo do planejamento
  • Releases Pequenas
  • A metáfora
  • Histórias do Usuário
  • Desenho simples
  • Testes (unitário, aceitação)
  • Refatoração
  • Programação em Pares
  • Desenvolvimento Coletivo

Fundamentos do Processo Unificado de Desenvolvimento de Software

  • Conceitos
  • Fases: Iniciação, Elaboração, Construção e Transição
  • Disciplinas( Modelagem de Negócio, Requisitos, Análise e Desenho, Implementação, Teste, Gerenciamento de Projeto, Gerência de Configuração e Mudanças, Implantação e Ambiente)

Avaliações e Critérios de Avaliação

A avaliação será feita por meio da avaliação individual do desempenho do aluno no ciclo de projeto:

O objetivo do Projeto simula uma situação real de desenvolvimento. Os alunos de MDS irão se concentrar na execução metodologia de desenvolvimento através da especificação de requisitos, codificação e testes. Haverá duas avaliações formais das releases a serem desenvolvidas.

A nota final do aluno é calculado da seguinte forma:

Nota Final = (Critério de Avaliação Coletiva) * 0,20 + (Critério de Avaliação Individual) * 0,40 + (Release 1) * 0,2 + (Release 2) * 0,2

Os critérios estão detalhados nesse documento

Para o aluno satisfazer os seguintes requisitos para obter a aprovação na disciplina:

  • Aprovação se MF >= 5,0 e se Percentual de faltas (PF) for PF <= 25%. Onde PF é dado pelo número de aulas com faltas registradas dividido pelo número de aulas ministradas.
  • Reprovação se MF < 5,0ou se PF > 25%. Nessa situação o aluno será considerado reprovado por nota ou por falta.

Os criterios avaliados individualmente no projeto esta destacado na tabela abaixo

Evento da Avaliacao Individual no projeto
Codigo/ Entrega
Documentação
Coerência - Documentos e Código
Critério Extra
Histórias e Planejamento da Release
Testes Automatizados e Cobertura de Código > 90%
Tracking
Wiki Atualizada
Software Implantado e Disponível para Uso
PA - pareamento
PA - reuniao de planejamento da sprint
PA - planning poker
PA - sprint time box
PA - participacao nas daylies
PA - review com o cliente
PA - retrospectiva na sprint
PA - user stories
PA - risco sustentavel de trabalho
PA - codigo escrito com padroes
PA - plano de comunicacao
PA - comunicacao tecnica nas issues
PA - pull requests educativos
PA - praticas de comunidades de software livre

Avisos

  • Também são considerados critérios de avaliação da participação: assiduidade; pontualidade; interesse; participação em sala.
  • Os documentos referentes à disciplina, estarão disponíveis em: https://github.com/fga-eps-mds/Qualifying-Software-Engineers-Undergraduates-in-DevOps
  • Os projetos sao avaliados continuamente
  • A cobertura de código deverá ser 90%, excetuando a camada de apresentação
  • O tamanho dos times deve respeitar o limite máximo de 6 membros.
  • As atividades do projeto deverão ser organizadas por meio de issues e milestones.
  • O código-fonte e demais artefatos elaborados deverão ser revisados utilizando pull/merge requests e issues.

Datas das Releases 1 e 2

  • Release 1 (major) - 9 de maio de 2023

  • Release 2 (major) - 12 de Julho de 2023

Bibliografia Basica

  • (OPENACCESS) Rocha, Carla. Como Acelerar o Aprendizado e Disseminar a Cultura de Inovação Ágil - https://rochacarla.github.io/Onboarding/
  • Beck, K., Programacao Extrema (XP) Explicada, 1st ed. Bookman, 2004
  • Ken Schwaber e Jeff Sutherland - O Guia Definitivo para o Scrum: As Regras do Jogo - Disponível em português em https://scrumguides.org
  • Sommerville, I., Engenharia de software. 8th ed., Pearson Addison Wesley, 2007.
  • Engenharia de Software Moderna
  • Alves, Isaque, Rocha,Carla. Qualifying Software Engineers Undergraduates in DevOps - Challenges of introducing technical and non-technical concepts in a project-oriented course - http://arxiv.org/abs/2102.06662
  • Jacobson, I., Booch G., Rumbauch J., The Unified Software Development Process, 1st ed., Addison-Wesley, 1999.
  • [EBRARY] Lano, K.,UML 2 Semantics and Applications, 1st ed., Wiley, 2009.
  • OPENACCESS Scrum e XP direto da sTrincheiras

Bibliografia Complementar :

  • Pfleeger, S. L., Engenharia de software: teoria e prática. 2nd ed., Prentice Hall, 2004.
  • Pressman, R. S., Engenharia de software. 6th ed., McGraw-Hill, 2006.
  • Ambler, S., Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, 1st ed., Wiley, 2002
  • Jacobson, I., Booch G., Rumbauch J., UML: Guia do Usuário, 2nd ed., Elsevier, 2005.
  • [OPEN ACCESS] Scrum e XP direto das Trincheiras. (http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches)

Metodos de Desenvolvimento de Software - Plano de ensino

DISCIPLINA: Métodos de Desenvolvimento de Software

CARGA HORÁRIA: 60 horas

PROFESSOR: Carla Rocha

CREDITOS: 04

SEMESTRE/ANO: 02/2023

Objetivos da Disciplina

Métodos de desenvolvimento de software podem ser entendidos como conjuntos estruturados de boas práticas, podendo ser repetıveis durante o processo de produção do software.

Os principais objetivos da disciplina são:

  • Capacitar o aluno a compreender os diferentes métodos, ferramentas, procedimentos e complexidade do desenvolvimento de software.

  • Capacitar o aluno a aplicar / adaptar processos de desenvolvimento de software a resolução de problemas de software.

  • Capacitar os estudantes para construírem sistemas complexos, apresentar as habilidades técnicas e não técnicas necessárias para a construção de software no contexto atual da Indústria.

Ementa do Programa

Modelos de ciclo de vida e de processos; Processo Unificado. Métodos Ágeis de desenvolvimento de software. Outras abordagens de desenvolvimento de software. Ferramentas.

Metodologia de Ensino

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.

A disciplina usa aprendizagem por experiência, aprendizagem orientada a projetos, processo de Onboarding, e práticas de comunidades Open source para que o aluno seja ativo no seu processo de aprendizagem. A imagem abaixo mostra o ciclo da disciplina:

image

Formação das equipes

A turma deve se dividir em equipes ágeis, de 5 membros por time. Serão apresentados temas de projeto e, cada grupo escolhe 3 temas na ordem de preferência. A professora negocia e aloca os temas para o grupo, dentro das preferências.

  • A planilha para definição dos grupos e temas aqui

Canais de Comunicação

A disciplina será realizada de forma presencial na sala I6. Serão disponibilizado tanto material assincrono quanto aulas sincronas.

Dúvidas, conversas rápidas, avisos

Aulas assíncronas

  • Vídeos disponibilizadas no youtube - canal youtube
  • Leituras sugeridas na sprint - disponibilizados no planejamento das aulas

Planejamento das aulas

  • O planejamento das aulas semanais, discriminando se são assíncronas ou síncronas, e qual canal vai ser atualizado no início da semana no link

Descrição do Programa

Processos de Desenvolvimento de Software

  • Modelos de Processo de Desenvolvimento de Software (ciclo de vida)
  • Atividades de Processo

Fundamentos do Extreme Programming

  • O manifesto Ágil
  • Os Quatro valores e as Quatro variáveis
  • Praticas ageis
  • O jogo do planejamento
  • Releases Pequenas
  • A metáfora
  • Histórias do Usuário
  • Desenho simples
  • Testes (unitário, aceitação)
  • Refatoração
  • Programação em Pares
  • Desenvolvimento Coletivo

Fundamentos do Processo Unificado de Desenvolvimento de Software

  • Conceitos
  • Fases: Iniciação, Elaboração, Construção e Transição
  • Disciplinas( Modelagem de Negócio, Requisitos, Análise e Desenho, Implementação, Teste, Gerenciamento de Projeto, Gerência de Configuração e Mudanças, Implantação e Ambiente)

Avaliações e Critérios de Avaliação

A avaliação será feita por meio da avaliação individual do desempenho do aluno no ciclo de projeto:

O objetivo do Projeto simula uma situação real de desenvolvimento. Os alunos de MDS irão se concentrar na execução metodologia de desenvolvimento através da especificação de requisitos, codificação e testes. Haverá duas avaliações formais das releases a serem desenvolvidas.

A nota final do aluno é calculado da seguinte forma:

Nota Final = (Critério de Avaliação Coletiva) * 0,20 + (Critério de Avaliação Individual) * 0,40 + (Release 1) * 0,2 + (Release 2) * 0,2

Os critérios estão detalhados nesse documento

Para o aluno satisfazer os seguintes requisitos para obter a aprovação na disciplina:

  • Aprovação se MF >= 5,0 e se Percentual de faltas (PF) for PF <= 25%. Onde PF é dado pelo número de aulas com faltas registradas dividido pelo número de aulas ministradas.
  • Reprovação se MF < 5,0ou se PF > 25%. Nessa situação o aluno será considerado reprovado por nota ou por falta.

Os criterios avaliados individualmente no projeto esta destacado na tabela abaixo

Evento da Avaliacao Individual no projeto
Codigo/ Entrega
Documentação
Coerência - Documentos e Código
Critério Extra
Histórias e Planejamento da Release
Testes Automatizados e Cobertura de Código > 90%
Tracking
Wiki Atualizada
Software Implantado e Disponível para Uso
PA - pareamento
PA - reuniao de planejamento da sprint
PA - planning poker
PA - sprint time box
PA - participacao nas daylies
PA - review com o cliente
PA - retrospectiva na sprint
PA - user stories
PA - risco sustentavel de trabalho
PA - codigo escrito com padroes
PA - plano de comunicacao
PA - comunicacao tecnica nas issues
PA - pull requests educativos
PA - praticas de comunidades de software livre

Avisos

  • Também são considerados critérios de avaliação da participação: assiduidade; pontualidade; interesse; participação em sala.
  • Os documentos referentes à disciplina, estarão disponíveis em: https://github.com/fga-eps-mds/Qualifying-Software-Engineers-Undergraduates-in-DevOps
  • Os projetos sao avaliados continuamente
  • A cobertura de código deverá ser 90%, excetuando a camada de apresentação
  • O tamanho dos times deve respeitar o limite máximo de 6 membros.
  • As atividades do projeto deverão ser organizadas por meio de issues e milestones.
  • O código-fonte e demais artefatos elaborados deverão ser revisados utilizando pull/merge requests e issues.

Datas das Releases 1 e 2

  • Release 1 (major) - 9 de maio de 2023

  • Release 2 (major) - 12 de Julho de 2023

Bibliografia Basica

  • (OPENACCESS) Rocha, Carla. Como Acelerar o Aprendizado e Disseminar a Cultura de Inovação Ágil - https://rochacarla.github.io/Onboarding/
  • Beck, K., Programacao Extrema (XP) Explicada, 1st ed. Bookman, 2004
  • Ken Schwaber e Jeff Sutherland - O Guia Definitivo para o Scrum: As Regras do Jogo - Disponível em português em https://scrumguides.org
  • Sommerville, I., Engenharia de software. 8th ed., Pearson Addison Wesley, 2007.
  • Engenharia de Software Moderna
  • Alves, Isaque, Rocha,Carla. Qualifying Software Engineers Undergraduates in DevOps - Challenges of introducing technical and non-technical concepts in a project-oriented course - http://arxiv.org/abs/2102.06662
  • Jacobson, I., Booch G., Rumbauch J., The Unified Software Development Process, 1st ed., Addison-Wesley, 1999.
  • [EBRARY] Lano, K.,UML 2 Semantics and Applications, 1st ed., Wiley, 2009.
  • OPENACCESS Scrum e XP direto da sTrincheiras

Bibliografia Complementar :

  • Pfleeger, S. L., Engenharia de software: teoria e prática. 2nd ed., Prentice Hall, 2004.
  • Pressman, R. S., Engenharia de software. 6th ed., McGraw-Hill, 2006.
  • Ambler, S., Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, 1st ed., Wiley, 2002
  • Jacobson, I., Booch G., Rumbauch J., UML: Guia do Usuário, 2nd ed., Elsevier, 2005.
  • [OPEN ACCESS] Scrum e XP direto das Trincheiras. (http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches)

Release de Software

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 do usuário: manual de usuário, guias de início rápido e ajuda on-line para os novos recursos e funcionalidades.
  • 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 lançamento: descrição detalhada das novas funcionalidades, correções de bugs e outros aprimoramentos incluídos na nova versão.
  • Comunicação de lançamento: anúncio oficial da nova versão para os usuários e a mídia, incluindo e-mails, boletins informativos e atualizações nas redes sociais.

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.

R1/R2

O principal objetivo das apresentações da R1/R2 na disciplina MDS é evidenciar o aprendizado. Evidenciar que tanto de forma individual quanto coletiva, são capazes de compreender os conceitos apresentados em sala de aula, e como eles foram aplicados no projeto desenvolvido.

Considere que todas as pessoas que forem assistir a apresentação que forem avaliar já leu todo o conteudo disponível no repositório do projeto. E que parte dos ouvintes da apresentação não vão avaliar o projeto e estão interessados no produto de software que estão propondo. Logo, foque nos elementos da proposta, e apresente o que não está disponível no github.

O que queremos enteder eh:

  • qual a proposta do produto de software?

  • Mostrar a jornada do usuario na sua aplicacao ? (aplicacao funcionando.. soh as principais funcionalidades)

  • Quais foram as lições aprendidas durante o projeto ? (aqui estão livres para falar tanto dos aspectos positivos quanto negativos)

  • Quais foram os impactos das práticas ágeis na forma como vocês desenvolveram o projeto. ser especificos. Ex: como a retrospectiva ajudou na gestao de riscos e aumento da produtividade, etc

  • Como vocês interpretam as métricas do projeto de vcs (burndown, velocity, issues abertas/fechadas)

  • Qual a complexidade técnica da solucao proposta?

Dicas

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

Guia das primeiras semanas

As primeiras semanas da disciplinas são as mais confusas, complexas e umas das mais importante. Vocês não sabem exatamente o que tem que ser feito, como tem que ser feito, e o que é esperado. Acreditem que faz parte da experiência. Esse documento tenta trazer um guiar para fazer bem as primeiras semanas.

  • Dinâmicas para conhecer todos os membros do time
  • Mapeamento das habilidades e dificuldades de cada pessoa do time
  • Estudos em pares nos seguintes temas: Scrum, papéis/habilidades ágeis (Scrum master, Product Owner, Arquiteto/DevOps), documentos de projeto de software (Documento de Visão, Documento de arquitetura, TAP), documentos ageis (issue, pull request, documento de sprint)
  • Treinamentos - configuração de ambiente (intalação de git, etc), uso de principais comandos git, treinamento práticas ágeis. Podem pedir para algum monitor dar o treinamento, ou alguém do time prepara o treinamento.

Conhecendo o time

No mercado de trabalho, nós não escolhemos com quem vamos trabalhar. Então se não estiver no time que gostaria, é uma ótima experiência para testar seu profissionalismo no ambiente de trabalho.

Antes de começar o trabalho mão na massa, é importante que as pessoas do time sintam a vontade de se expressar, e que verbalizem as expectativas, limitações e frustrações. Então, na primeira semana na disciplina, dediquem tempo para conhecer as pessoas do seu time, ver o perfil de cada um (gosta de programar, fazer interface, sonha em mexer com dados, ja sabe programar em python etc), mapear as expectativas individuais na carreira de engenharia de software, compartilhar os medos/inseguranças em relação à disciplina\faculdade, e dificuldades individuais. Essas conversas iniciais são muito importantes! Todas as pessoas devem falar, sentir parte do grupo, e devem agregar Todas as pessoas no time e criar uma expectativa coletiva.

Pra que essas conversas iniciais são importantes? Primeiro estamos trabalhando com pessoas, com usas histórias, seus sonhos e suas restrições. Conhecer as pessoas nos faz entender que cada uma vai dedicar o máximo possivel, dentro das suas limitações, para o sucesso do grupo. Vão perceber que o sumiço de um membro pode estar relacionado a questões muito mais complexas (muito raramente é por ser migué), e saber da historia de cada um nos faz compreender que as dedicações não são uniformes e ajudar os colegas de time em momentos de dificuldade.

Estudo em Pares

Uma das grandes práticas ágeis que vamos trabalhar no semestre é o pareamento. Nessa prática, todas as tarefas a serem realizadas no projeto são feita por dois integrantes. Trabalhar em dupla pode parecer contra produtivo em um primeiro momento (se cada pessoa ficasse com uma tarefa parece que teria mais tarefas entregues), mas estudos mostram que trabalhar em dupla, além de ter revisão do que é feito, é uma forma de trocar conhecimento, aumenta a qualidade da tarefa entregue, e é mais produtivo.

Por isso, todas as tarefas devem ser realizadas por duplas no time/squad.

Encontros

Desde a primeira semana, o time deve fazer reuniões de planejamento, com o objetivo de levantar as atividades a serem realizadas na semana e quem é o responsável para realizar as tarefas.

Nas primeiras semanas, as tarefas são exclusivamente de estudos, e treinamentos. Estudos e treinamento incluem: Scrum, papéis/habilidades ágeis (Scrum master, Product Owner, Arquiteto/DevOps), documentos de projeto de software (Documento de Visão, Documento de arquitetura, TAP), documentos ageis (issue, pull request, documento de sprint).

Além das reuniões de planejamento, precisam marcar reuniões para discutir o escopo do software que vocês gostariam de desenvolver - funcionalidades (login, x, etc), e as tecnologias que vcs gostariam de usar (python, etc).

Ao final da semana, deve ter uma reunião para que cada membro do time entregue o que foi desenvolvido na semana. Chamamos essa reunião de Review. O objetivo é que todos saibam o que foi finalizado, o que está pendente, e o que não foi finalizado. Com essa reunião, terão as informações necessárias para fazer o planejamento de um novo ciclo semanal.

  • Reunião Semanal de planejamento
  • Reunião semanal de revisão/entrega (review)
  • Reuniões focadas técnicos sobre o projeto (com temas definidos).

Treinamentos

O início do semestre deve ser dedicado à estudos e treinamentos. O que isso quer dizer? normalmente uma dupla/pessoa estuda um conceito/tecnologia/prática e confecciona o material para capacitar o restante do time.

O material dos treinamentos podem ser links para tutoriais com boa qualidade, apresentação utilizada no treinamento. Deve-se garantir que ao final do treinamento, todos os membros da equipe tenham conhecimento necessário para que consiga aplicar no contexto do projeto.

Todos os treinamentos devem ser planejados e registrados nas issues.

Treinamentos a serem realizados:

  • Métodos ágeis - o que são métodos ágeis, o que é Scrum e as práticas do Scrum
  • Configuração de ambiente - instalar bibliotecas/ferramentas necessárias para o projeto. Instalando linux, git, pip, etc.
  • Git - o que é, quais são os principais comandos (clone, push, pull, commit, add, remove)
  • Github - práticas das issue (Criar issue, comentar issues etc), documentação (markdown, estrutura pastas etc), pull request, branches
  • Gitpage - reaproveitar tema/estrutura de outro time, etc.

Registro de Horas Trabalhadas

Vocês devem controlar em um primeiro momento o tempo de dedicação em horas de cada membro do time. Para isso, toda vez que um participante trabalha para o projeto, monitora o tempo dedicado e registra em um local que o time definiu (planilha de horas compartilhada, algum software etc)

Exemplo de Planilha - https://www.coalize.com.br/planilha-horas-trabalhadas

Documentação

Todo o trabalho realizado deve ser registrado no repositório github do projeto.

A documentação das tarefas deve ser feito por meio de issues no github. Cada participante deve ter, pelo menos, 1 issue alocada (assign).

Deve ter também documentação do planejamento e revisão da sprint.

Ponteiros

Ler os post mortem dos outros grupos dos semestres anteriores. O documento post mortem é um documento com o objetivo de deixar as lições aprendidas, o que fizeram errado, o que foi importante pra eles, o que eles dariam de conselhos para vocês. Aproveitem esse material para entender mais a disciplina, o que é esperado de você, como gerir bem seu tempo e se organizar pra disciplina.

Semestre anterior

Outros semestres

Tutoriais

Web Developer Roadmap Spellbook of Modern WebDev System Design Primer

Ferramentas

Referências

Engenharia de Software

Engenharia de Software Moderna

Code Complete [Steve McConnell]

Clean Code: A Handbook of Agile Software Craftsmanship [Uncle Bob]

The Pragmatic Programmer: From Journeyman to Master [Andy Hunt, Dave Thomas]

Arquitetura de Software

Clean Architecture [Uncle Bob]

Building Evolutionary Architectures: Support Constant Change [Neal Ford, Rebecca Parsons, Patrick Kua]

Microsserviços

Building Microservices: Designing Fine-Grained Systems [Sam Newman]

Design

The Modern Web Design Process [Jeff Cardello, John M. Williams]

Métodos Ágeis

Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds [Henrik Kniberg, Anders Ivarsson]

Software Engineering: A Practitioner's Approach

Kanban em 10 passos [Jesper Boeg]

Extreme Programming Explained: Embrace Change [ Kent Beck, Cynthia Andres]

DevOps

The DevOps Handbook [Gene Kim, Jez Humble, Patrick Debois, John Willis]

Site Reliability Engineering: How Google Runs Production Systems [Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Murphy]

Accelerate: The Science of Lean Software and DevOps [Nicole Forsgren, Jez Humble, Gene Kim]

Projetos 2023/1

A seguir está a lista de projetos, que estarão sendo trabalhando na disciplina ao longo do 1º Semestre de 2023.

HUB FGA Inovação

  • Portal de Inovação na universidade de brasilia - campus gama
  • Minerar as disciplinas de inovação na universidade de brasilia
  • Apresentar resumo dos laboratórios de pesquisa da FGA
  • Categorizar laboratórios, professores, temas

https://hubusp.inovacao.usp.br https://github.com/hub-usp-inovacao

Robô de monitoramento dos videos assistidos no moodle

Descrição: Desenvolver um bot que percorre todos os usuários de uma turma do moodle, fazendo o acompanhamento do aluno, salvando os dados diariamente em uma planilha excel (google drive api), para controle. Por exemplo, o aluno/usuário X já acessou 50% do material do curso, respondeu 15% dos questionarios propostos, fez 10 logins, e passou 56 min na plataforma.

  • Necessidades: ter acesso professor à sala. Pode ser feito como plugin no moodle, ou somente um executavel (rodar no terminal).

  • Funcionalidades: webscraping da pagina da aula no moodle

Canvas Inteligente

Um "canvas" pode se referir a uma representação visual do produto, geralmente apresentada de forma simplificada e intuitiva. Nesse caso, o canvas pode ser usado para mostrar as principais características e benefícios do produto, de forma a facilitar a compreensão do cliente.

O objetivo desse projeto é que além de um canvas visual, seja feito um checklist do canvas para que possa ser gerado automaticamente um índice de maturidade daquele produto.

Esse projeto tem clientes que vão auxiliar na definição do escopo

Biblioteca em python para gerar relatorio de repositórios git

Descrição: uma ferramenta offline, que, por linha de comando, a partir do git log de um repositório, gere relatório (txt) com estatiticas de um usuario especifico ou da equipe inteira.

o relatorio deve ser por repositório (completo) e por usuário

por exemplo - qte de issues fechadas na semana, qte de commits por semana

usuario - qte de commits por semana, qte de issues alocadas por semamna

Mineração de projetos open source

Descrição: automação de mineração d projetos open source.. tipo de licença, qte de contribuidore, linguagens/frameworks

fazer por webscrapping

Tema livre

Se o time tiver alguma proposta de tema, que seja com o objetivo de resolver algum problema social, deve-se fazer uma descricao e as principais funcionalidades da plataforma para ser avaliado a viabilidade

Dados abertos

Descrição: Escolher orgão federal de dados abertos e apresentar a evolução temporal dos dados.

Dicas

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

Posts

Essa seção é destinada aos blog post feitos pelos alunos

Como publicar um post

  • Faça um fork do repositório
  • Crie um arquivo markdown na pasta post
  • Insira seu conteudo no arquivo
  • adicione o seu blopost ao summary (SUMMARY.MD) do projeto (na pasta ./src)
  • Execute a pagina (comando mdbook serve)
  • Teste localmente
  • Abra um pull request

Aprendizados para "aprender a aprender e aprender a fazer"

Jornada do Squad 2- BOTO

					By Mylena Angélica- matrícula 211029497

Aprendizados para “aprender a aprender e aprender a fazer” consiste em uma metodologia chamada de “Experience Learning” e tem muita relação com o aprendizado de software.

Quer saber o porquê?

O aprendizado é coisa séria, aprender sobre software, para um engenheiro que tem como principal ferramenta o próprio software, então, é mais que sério.

Para que você entenda um pouco mais sobre essa metodologia, vou contextualizar.

A metodologia tem como foco a aprendizagem como experiência. Veja só que bacana! Ela proporciona um ambiente no qual o aluno consegue controlar seu autodesenvolvimento para ir mais no nosso contexto, é centrada no usuário, ou seja, nós futuros engenheiros.

Bem e o que isso tem a ver com a disciplina Métodos de Desenvolvimento de Software- MDS.

duvida

Continue a ler o post e no final, responda a seguinte pergunta:

A metodologia Experience Learning tem a ver com o que vamos conhecer ao longo deste post?

Contextualizando

A disciplina de Métodos de Desenvolvimento de Software, do curso Engenharia de Software, da Universidade de Brasília, ministrado pela Professora Doutora Carla Rocha, vai além do conhecimento teórico e ensina aos alunos a lidar com situações que serão importantes para sua vida profissional. Ela é considerada, pela comunidade acadêmica, essencial na grade horária do curso, pois apresenta conteúdos, dicas, metodologias, dentre outras, para quem quer se desenvolver na área de software.

Sabe por quê?

O que você adquirir durante a disciplina, com certeza irá levar para o resto da sua “vida” de desenvolvedor (a). Lembre-se que o seu futuro depende do seu conhecimento, assim compartilho 4 tópicos fundamentais na jornada do estudante que vai se aventurar no mundo dos códigos.

Não deixe de ler, ficar de fora do conhecimento é estar a beira de um precipício.

Vamos comigo?

Metodologias ágeis

Para quem não sabe, as metodologias ágeis são as principais formas de planejamento e de desenvolvimento de software. Vou listar os principais métodos ágeis que podem ser implementados em seus trabalhos. São eles: Scrum, Kanbam, XP e muitas outros.

Mas, durante a disciplina, você irá observar que eles serão um ponto forte para o desenvolvimento do seu trabalho. Você poderá escolher os que achar melhor ou até mesmo utilizar uma mistura dos métodos. Tudo vai depender dos projetos e de suas necessidades. Mas vamos voltar ao nosso papo inicial.

A equipe Squad 2- BOTO, grupo que faço parte, com orgulho, pois somos interessados demais em metodologias ágeis, utilizou uma mistura de técnicas de Scrum e XP. E deu super certo! A experiência, já adianto, foi fantástica! Está curioso?

Vou compartilhar com você como descobrimos esse mundo magnífico.

Além dos conteúdos que obtivemos por meio de pesquisas, da curiosidade, realização de testes e pela experiência que fomos adquirindo na jornada , também, somamos os comentários de outros colegas, e as valiosas dicas da professora. A interação dela com o grupo foi essencial, pois tivemos a oportunidade de conhecer a fluxos de trabalho mais ágil, flexíveis e que se adaptam aos desejos e necessidades de todo desenvolvedor.

Então, vai a dica de ouro bau-ouro

Aproveite bem as aulas, estude, teste, crie, pesquise e busque desenvolver seu trabalho sem medo de errar, ao errar se liga em ter a rapidez para mudar. Desmitificando aí a cultura do erro! Mas seja rápido e ágil para mudar a direção do seu projeto, caso identifique falhas que possam comprometer o resultado. Trabalhe em tão com o MVP, dá muito certo esse caminho. Assim, você terá a oportunidade de aprofundar os seus conhecimentos e desenvolver habilidades que irão fazer você se destacar no mercado de trabalho.

Lembre-se que: ágil é um novo estilo de trabalho que está ganhando o mercado, não fique de fora dessa!!

Show me the code

Mas o que é isso?

Uma grande inovação na área de software.

O Show me The Code, foi uma metodologia implementada pela professora da disciplina. Ela apresenta para nós essa ferramenta como forma de avaliar os avanços dos grupos ao longo do semestre.

Bem na pegada de Shark Tank. Que funciona assim: os alunos são desafiados a mostrar o que foi desenvolvido, dentro de um limite de tempo, quer seja os desafios, quer seja a organização e a estrutura do trabalho.

Muita adrenalina! Mas superar o desafio, sem dúvida, é recompensador.

Veja aqui o que te falei no post acima!

Esse é um novo estilo de trabalho que está ganhando o mercado.

Assim, aconselho você a agarrar a oportunidade de desenvolver as tão faladas Soft skills.

Se não sabe o conceito, sugiro que faça uma pesquisa, pois cabe também, a um bom desenvolvedor pesquisar os temas que não conhece. Lembre-se que estamos na era do conhecimento! Não fique parado!

Mas espera aí:

Tem mais dicas que quero compartilhar!

Você deve estar pensando, nossa quantas descobertas! Com o conhecimento adquirido durante o curso, eu aprendi a aprender e aprendi a fazer. Muito legal, né? Continuando nossa conversa, neste post, eu ainda vou te contar as competências, habilidades e atitudes requeridas do profissional do século, vamos lá?

A criatividade, a comunicação eficaz, a persuasão , a influência, a gestão do tempo e a capacidade de trabalhar sob pressão , pois uma coisa que está em alta, também, é a inteligência emocional.

presentation

Então vale a pena se preparar e utilizar essa oportunidade para colocar em prática as soft skills e perceber de onde partir e onde você quer chegar.

O autoconhecimento também, é fundamental. Anota aí!

Github

Talvez, você já saiba, mas faço questão de frisar sobre a importância desse software para a vida de um desenvolvedor.

Com a docente, aprendi a utilizar o máximo dessa ferramenta. Tirar o maior proveito possível, pois ele é um recurso é extraordinário.

E se for agregado ao Zenhub, então, tudo pode ser feito. Você pode documentar no próprio Git, facilitando a organização e o fluxo de trabalho.

Teste aí e veja se eu “não tenho razão”!

enter image description here

Olha só, além disso, aprendi a utilizar issues, pull request, milestone, gitpages….

Aconselho que você faça o mesmo, não perca um dia só de aula.

Está com dúvidas nesses nomes?

Não se preocupe, a professora irá apresentar todos eles! Mas caso meu nobre Jedi, seja curioso, visite os repositórios de semestres anteriores e eu te garanto que você irá achar ótimas fontes de conhecimento.

enter image description here

Com isso, você se tornará um desenvolvedor de verdade. Aqui não é só teoria, é muita prática.

Então, vale a pena desenvolver hard skills e colocar no currículo a sua experiência com essa ferramenta tão fundamental.

Quer mais dicas?

Software livre

Pode apostar que vai se tornar o seu novo amor. Softwares livres são os programas que podem ser copiados, aprimorados, estudados, por qualquer pessoa que tenha interesse, além de serem totalmente gratuitos.

Alguns exemplos de softwares livres são: o Linux, o LibreOffice, o Firefox e muitos outros que você irá conhecer durante sua trajetória em MDS.

A nossa docente, explica, com uma linguagem espetacular sobre os software livres, além disso, demonstra a sua importância, suas vantagens e ainda, conta bem contado, o motivo de utilizar e o porquê é tão fundamental para a comunidade de software.

Vale lembrar que: As ferramentas utilizadas durante a disciplina são open source ou são gratuitas para projetos de software livre.

Olha só, não quero ser repetitiva, mas já sendo, vale a pena pesquisar, utilizar e desenvolver softwares desse tipo. Topa o desafio?

Além disso, é algo tão bacana! Criar, compartilhar, renovar, disponibilizar, participar de comunidades de desenvolvedores, ajudar e também, ser ajudado. Eita, mundo novo! Deu para perceber que construir um projeto open source é algo tão moderno, tão atual e tão gratificante que faz de qualquer engenheiro um “deus”.

Sem exagerar, viu, mas é isso mesmo.

enter image description here

Aproveite então cada palavra, cada ensinamento, cada experiência com a professora e seus colegas, e já vá utilizando os conhecimentos adquiridos,. Planeje e desenvolva o seu primeiro software livre, e compartilhe, já que os projetos desenvolvidos são dessa categoria.

E eu te garanto, depois da disciplina você irá ficar apaixonado por essa modalidade e irá querer contribuir com as comunidades.

E colaborar também é uma coisa importante na vida de um profissional, juntos somos fortes! O que seria de nós sem o Stack Overflow 🤣🤣

Chegou a tão esperada hora de responder ao questionamento que postei lá no início do post.

Vamos lá?

Foi perguntado a você: A metodologia Experience Learning tem a ver com o que vamos conhecer ao longo deste post?

Se você respondeu que sim, parabéns! Você entendeu muito bem o que significa “aprender a aprender e aprender a fazer” e é exatamente a metodologia que a professora utiliza. Você deve ter percebido que ela é centrada no usuário e por isso, torna o processo de aprendizagem mais fluido e interessante. É bom aprender assim, não é mesmo?

Gostaria de falar muito mais, sobre os descobrimentos e conhecimentos que foram oportunizados pela disciplina de MDS, mas como tempo é dinheiro 💸💸abordei apenas alguns alguns dos tópicos que mais me marcaram.

Então, espero que, você, possa aproveitar meu post. E não se esqueçam de curtir bastante esse caminho que se abre para você. Bom curso e nos encontramos por aí, seja na Universidade, seja nas comunidades, compartilhando experiências, criando novos sistemas e ajudando o mundo a se tornar melhor.

tchau