TADS - Engenharia de Software - Módulo I - Aula 03

Olá seja bem-vindo à nossa terceira aula do primeiro módulo nossa aula agora de engenharia de software voltada a métodos ágeis e desenvolvimento vou falar um pouquinho sobre como surgiram esses métodos ágeis eh mas especificamente eu vou falar de um método agem que é o chamado scrum a gente vai ver depois mas o scrum Não é só para desenvolver software eh pode ser para qualquer coisa né você pode utilizar o scrum por Exemplo para trabalhar na sua empresa por exemplo onde se você trabalha na sua empresa Você pode organizar os processo o desenvolvimento dos processos de

produtos o que você quiser utilizando o scrum e ele se deu muito bem na área de engenheria de software para projetos pequenos para software com eh que são construídos por de duas até até 12 pessoas você consegue utilizar o Square Tá bom então Preste atenção no que vai ser dado Por que que surgiu Então essa Nova metodologia a gente viu na aula passada as metodologias tradicionais de software que as primeiras metodologias tentavam colocar em ordem um mundo um pouco caótico que é essa construção de software através de Passos através de uma metodologia que você vai

seguir passo a passo entretanto projetos pequenos projetos que de demanda de software eh onde é focado mais do cliente esses projetos não eram bem atendidos nessas novas nessas Metodologias mais tradicionais como a gente viu o Cascata o espiral e o processo Unificado assim como tá dizendo aqui nesse slide né Existe uma grande demanda de novas aplicações e aqueles processos de desenvolvimento mais robustos eh começaram a ficar complicados e acabaram não sendo usados e voltaram a usar aquele método de codificação e e reorganização você codifica e refaz de novo codifica e refaz software complexo sistemas Distribuídos

heterogêneos começaram as ter mais quantidades deles seram produzidos E era necessário agora uma nova metodologia que pudesse ser feita em menos pessoas em menos quantidade de gente requisitos Mutantes lembra lá no modelo Cascata quando ele era sequencial se eu tivesse um requisito que tivesse mudado durante o processo de desenvolvimento eu teria que voltar de novo no início lá do nosso processo de desenvolvimento isso não se adequava bem Às novas necessidades é importante anizar que não há gente para para desenvolver tanto software com qualidade Então tem que pensar em alguma coisa um pouco menor e foi

aí que vários pesquisadores se reuniram tomaram uma decisão importante pro desenvolvimento de software com as metodologias de software tradicionais que a gente viu elas tinham alguns problemas por exemplo elas supunham que você conseguiria prever o futuro quando você de novo Pensando no cascato você tem que definir os requisitos lá no começo do processo de movimento você definiu e não pode mexer mais porque ele é sequencial e linear então só no final que você vai entregar outro problema pouca interação com o cliente o cliente só viu o software no final ou só viu ou no começo

quando você começava a elicitar os requisitos a descobrir os requisitos ênfase em burocracias é muita documentação se vocês procurarem saber Um pouco mais sobre o processo Unificado que eu expliquei na aula passada levemente vocês vão ver a quantidade de documentação essa quantidade de documentação é importante para que você entenda o software mas softwares talvez menores não precisa de tanta burocracia eh a avaliação de produtividade desses modelos antigos é baseada em burocracia e não em código eh grande quantidade de erros e falta de flexibilidade são outros problemas Também relatados eh modelos tradicionais desenvolvimento de software Então

a partir daí tiveram algumas ideias então começaram a surgir novas tecnologias como padrões de projeto que é uma reutilização de ideias padrões de projeto eh se vocês procurarem saber o que que é são soluções para para problemas recorrentes ou seja são soluções que já foram aplicadas testadas e que você pode utilizar de novo a orientação objeto Também permitiu que que isso seja possível eh através de componentes por exemplo então quando surgi a orientação objetos na década de 80 e começou aprimorar na década de 90 começaram a criar essas novas tecnologias midare que aumenta abstração mides

que facilitam você conectar com banco de dados facilita você não precisa saber detalhes da implementação você usa o midware e começaram a surgir novas metodologias de desenvolvimento de software que são Chamados métodos ágeis e e a gente vai ver e o principal método ágil que é o scrum principal utilizado hoje em dia então tiveram vários pesquisadores vários desenvolvedores de software que não estavam contentes com os modelos da época Então o que eles fizeram Eles resolveram fazer uma reunião num hotel lá em Utá nos Estados Unidos e fizeram um Manifesto é conhecido como Manifesto ágil você

pode entrar nesse endereço ó aiom manifesto.org que você vai ver Exatamente a reunião tem uma foto lá dos a gente vai ver no próximo slide uma foto dessa reunião desses 17 desenvolvedores de software e eles colocaram algumas regras que a partir dessas regras partir desses princípios os novos processos de desenvolvimento novos modelos de desenvolvimento de software tinham que seguir se quisesse ser o modelo ágil Essa é a página do Manifesto ágil onde eles colocam algumas das dos princípios Do Manifesto tá bom Até hoje você pode acessar esse Manifesto tá nesse endereço que tá colocado na

no slide e aparece o nome dos 17 desenvolvedores de software pesquisadores Tá bom se você pesquisar um pouco sobre e métodos ágeis você vai descobrir que várias dessas pessoas que estão aí desses 17 foram os que contribuíram para desenvolver esses novos métodos o Kent beack por exemplo esse primeiro da lista ele que encabeçava esse Manifesto ágil ele fez Tem um livro sobre XP XP chama programação extrema Tá bom quem tiver mais interesse Procure um pouco sobre isso na internet o penúltimo nome da lista o Jeff sutherland é um cara que desenvolveu o scrum que a

gente vai ver daqui a pouco as principais ideias do Manifesto de desenvolvimento ágil de software era que indivíduos e interações são mais importantes que processo em ferramentas ou seja priorizar eh o face to face o cara a cara a conversa com o Cliente software funcionando é mais importante do que documentação completa e detalhada então começaram a pensar novas maneiras de você documentar o software não ter aquela documentação mais pesada como os processos tradicionais dos processos mais antigos colaboração com o cliente é mais importante do que negociação de contratos se você conseguir ter o cliente participando

do seu processo de desenvolvimento em todo o processo é uma Das partes mais importantes do Manifesto ágil a adaptação a mudança é mais importante do que seguir o plano Inicial eh aquela parte dos requisitos mutáveis de repente tô desenvolvendo o software apareceu um requisito novo ou então Quero mudar um requisito então não tenho que voltar desde o início eu tenho que abraçar essa mudança e fazer com que essa mudança seja parte do processo de desenvolvimento do software alguns princípios do Manifesto Ágil tem como objetivo inicial n só lendo aqui satisfazer o cliente entregando rapidamente com

frequência sistemas com algum valor é aquela parte de ser interativo ou seja toda vez você entregar alguma cois participar de interações e também participar de incremento do software então entregar versões funcionais em prazos curtos a gente vai ver que dependendo do tamanho do software o modelo scrum por exemplo pode ser de uma semana de um mês de duas Semanas você define o prazo para que você entregue uma nova versão estar preparados para requisitos Mutantes ou seja estar preparados para mudanças que podem ocorrer tanto pelo cliente como pelo pelo próprio ambiente que tá sendo desenvolvido pessoal

de negócio e desenvolvedores juntos a gente vai ver por exemplo no scram eh existe uma pessoa do do desenvolvimento que é o po a gente vai falar disso daqui a pouco Que ele é o dono do produto é um desenvolvedor que representa o cliente ou seja ele vai tá muito próximo do cliente é diferente de você encontrar o cliente somente em etapas definidas do seu processo como era lá no no Cascata como era no modelo espiral ou então Eh num processo Unificado troca de de informações através de conversas diretas Então você vai ver alguns modelos

de desenvolvimento de software eles falam por exemplo que é preferir você eh falar Com o cliente pessoalmente ou então uma ligação ou então uma mensagem então eles vão dando prioridade para que o o cara a cara com o cliente seja mais mais mais importante por isso é importante sempre manter o contato com o cliente algumas alguns dos principais métodos ágeis que foram Existem muitos né mas os principais aí que talvez estejam na literatura que você pode procurar um pouco mais eh O primeiro é da família Crystal tá o da família Crystal foi Criado eh pel

um pesquisad eh onde ele tem eh vários tipos para tanto para software pequeno paraa quantidade de desenvolvedores eh software médio e software grande Tá bom se você procura quiser procurar um pouco sobre isso Procura lá Crystal eh no Google que você vai encontrar mais informações a gente não vai ver sobre isso no Brasil usa-se muito pouco o método Crystal talvez eu não não conheça quem usa aqui no Brasil programação extrema XP foi os um dos Primeiros a ser utilizados foi idealizado para aquele cara lá que eu falei para você o KB ele tem um livro

sobre isso e também tem várias páginas na internet sobre programação extrema eh hoje então tem se usado menos o programação extrema Mas ele foi muito importante para por aplicar fori o primeiro método de desenvolvimento de software aplicar aqueles princípios do Manifesto ágil e tem o modelo scrum que ele serve para você desenvolver qualquer Coisa até para você organizar trabalho eh até para você por exemplo um professor que é orientar os alunos ele pode ar o scram até nessa orientação de alunos nesse processo de orientação Tá bom então É bem interessante o scram utiliza outras técnicas

como o kamban que veio já de é uma outra tecnologia de de de gerenciamento de pessoas gerenciamento de tarefas a gente vai ver na verdade somente o scram nessa aula tá bom a metodologia scram ou também se Pode L scom eh na verdade é uma uma estratégia de jogo do rugby né el o o idealizador da metodologia devia ser fã de rugby e deu esse nome aí para esam na verdade eh várias o que que é essa esse esse esse essa estratégia de jogo do rugby eh onde vários jogadores colocam uma bola quase perdida novamente

em jogo através do trabalho e equipe e é meio que essa ideia mesmo de você saber participar a equipe a equipe ser forte no Desenvolvimento de software em outras metodologias mais tradicionais a equipe não importa muito né nessa não Essa é importante e os valores são importantes para a equipe a equipe tem que est feliz a equipe tem que est Coesa para que dê certo mas tem que ser equipe pequena né por isso a gente vai ver depois no final da aula é quando que o scrum pode ser utilizado ou não eh quem desenvolveu o

o método scrum é o Jeff sutherland é aquele cara lá que eu falei para vocês Que fazia parte do Manifesto ágil mas ele começou a desenvolver essa ideia né de do do scram desde 1990 tá bom com a sua equipe de desenvolvimento de software a equipe scram né que a primeira coisa que você vai montar é uma equipe scram a equipe scram ela tem somente três papéis Ela é bem tranquila é claro que alguns papéis podem ser alternados eu vou explicar isso com mais detalhe depois e a esip SC Pelo menos tem o scam Master

que é o cara que ajuda A entender e seguir as regras do scram ele vai ver e como é que tá funcionando o scram se tá todo mundo seguindo as regras se tá todo mundo assumindo o papel se tá funcionando a gente vai ver que por exemplo tem uma reunião e eh diária se essa reunião tá sendo executada e no final tem uma revisão Tá bom então a gente vai ver tudo sobre isso é sobre os Cram Master ele que é o responsável o product honer conhecido como po é o O que representa o Stakeholder

ah lembra a palavrinha stakeholder stakeholder é qualquer pessoa que esteja envolvida no desenvolvimento de software pode ser desde o desenvolvedores em si mas também pode ser o cliente tá bom e vários tipos de cliente talvez o cliente que que pediu o software que requisitou o software ou o cliente que vai utilizar o software Tá bom então essa palavra stakeholder é bastante utilizada em engenharia de software então se você Tiver lembra aquela ideia que eu falei aquele princípio de sempre manter o o o cliente junto no processo de desenvolvimento o scram faz isso através do po

e por último eh outro papel que tem é a equipe desenvolvimento geralmente nesse papel de equipe desenvolvimento eh tem mais de uma pessoa então com três pessoas você começa a desenvolver software Então você consegue ter uma equipe pequena e consegue desenvolver software é claro Que geralmente é utilizado para mais pessoas cinco a seis pessoas Talvez seja o tamanho ideal para você utilizar o scrum o fluxo de processo do scram é mais ou menos assim você pega algumas das funcionalidades e que você vai contol do software e coloca ela de maneira que ela possa ser implementada

em semanas ou então em dias Então você a equipe que vai definir isso essas funcionalidades elas são chamadas de backlog do produto se você dar uma Olhada nessa figura você vai ver lá backlog do Sprint a palavra Sprint em inglês significaria corrida então o Sprint é o quanto tempo que você demora para implementar essas funcionalidades que estão no backlog esse Sprint pode ser de uma semana 30 dias duas semanas dependendo do tamanho do software dependendo da complexidade de cada funcionalidade Então vamos lá a equipe escolhe qual vai ser o backlog e quais dessas funcionalidades do

backlog vão Entrar nesse Sprint então esses print vai vão durar por exemplo 30 dias então eu escolho os itens que vão pertencer ao backlog e coloco isso no Sprint aí a minha equipe sabe que nesses 30 dias a gente só vai se preocupar com esses itens do backlog ou seja com esses itens com essas funcionalidades que foram escolhidas e já foram pensadas e sabidas que se dá tempo de implementar elos em 30 dias após esses 30 dias eu vou gerar uma nova funcionalidade que é o que tá Mostrando aí n nessa figura Lembrando que cada

um desses 30 dias a cada dia a cada final de dia eu tenho uma reunião scrum essa reunião scram é uma reunião chamada de standup meeting que é uma reunião em Pé Na verdade é uma reunião que todo mundo vai falar Eh o que aconteceu o que realizou naqu desde o último scrum da última reunião está tendo alguma dificuldade ou será o que vai fazer antes da próxima reunião Tá bom então são reuniões que facilitam o Entendimento lembra que a métodos ages uma das ideias é a comunicação também se comunicar bastante então todo dia a

equipe de desenvolvimento junto com escura Master e o poo se reúnem e tem 15 minutos de reunião de pé para que de pé para que seja rápida mesmo para que seja uma reunião mais efetiva tá então todo dia tem essa reunião de pé Então nesse exemplo que a gente tá mostrando aqui na figura em 30 dias você produz uma nova funcionalidade agora vou mostrar para Vocês um exemplo de como seria e você aplicar a metodologia scrum e no desenvolvimento de um software Tá bom então principalmente a gente vai prestar atenção e nos papéis e como

que Eu dividi a equipe dentro desses papéis que a gente aprendeu agora a pouco é um sistema de restaurante que será construído Tá bom então eu meio que inventei as funcionalidades mas a ideia é só para que a gente aprenda como é que isso é feito tá bom também vou inserir Umas palavras diferentes que a gente vai começar a a prestar atenção nelas que são bastante utilizados dentro da área de engenharia de software a gente vai ver isso nos próximo slide Lembrando que a equipe scram só também só tem somente três papéis scram Master product

honer E a equipe desenvolvimento Tá então vamos dar um exemplo da formação da equipe scram para desenvolver o sistema de restaurante e o scram Master seria Maria por exemplo que tem experiência em Gestão de projeto de software e é responsável por garantir a equipe siga suas práticas scr já falei sobre isso no slide passado Pedro que trabalha para o restaurante tem uma compreensão Clara das necessidades do sistema Olha é o dono do produto é legal que você ten um dos clientes um dos que vão utilizar o sistema que faça parte da sua equipe de desenvolvimento

e a equipe desenvolvimento a Ana seria a designer de Ui ux ui seria user interface interface com usuário é responsáveis pelos botões pelas cores e ux eh user Experience eh são responsáveis pelas experiências do usuário como facilidade de visualização eh qualidade e cores combinação de cores paleta de cores seria então a Ana responsável por isso o João seria um desenvolvedor frontend front end é o que vai desenvolver a fá do sistema Tá bom então a Ana vai projetar e o João vai desenvolver o Lucas seria o Desenvolvedor backend desenvolvedor backend é o que vai fazer

a parte de conexão com o banco de dados fazer as regras de negócio implementar os algoritmos Tá bom então desenvolvedor backend é o que faz isso e Fernanda seria a especialista em testes é o que vai fazer funcionar ver se tá funcionando tudo corretamente aplicando testes para verificar isso seguindo o exemplo agora tem a criação do backlog do produto lembra o que que é o backlog Do produto seriam as atividades que serão implementadas as necessidades do cliente que serão implementadas dentro do Sprint se você não lembra volta um pouquinho o vídeo volta l no slide

onde eu mostro e a figura do scram o processo scram e verifique lá o que que é backlog cada caixinha daquela que tem naquela figura representa uma atividade que será implementada no nosso exemplo agora Pedro que é o po trabalha com os steakholders do restaurante para Identificar os recursos necessários para o sistema ele cria o backlog do produto que inclui itens como como gerente quero gerenciar o meu restaurante para que os clientes possam ver os itens atualizados como garçom quero Anotar os pedidos dos clientes para que os chefes possam prepará-los como gerente Quero visualizar e

gerenciar os o inventário para que possamos manter um estoque adequado em no processo scram quando você anota os requisitos quando Você descreve os requisitos sempre você vai colocar desse jeito que tá aí nesse exemplo como Aí você coloca o papel que você tá assumindo lá de usuário do sistema o que que você quer e com isso tá bom então você sempre você coloca o seu papel que você quer e o que você quer e para aquilo né então Pedro que era o pi ele foi lá no restaurante e ele que era o maior conhecedor ele

trabalha no restaurante e ele conseguiu fazer esses Requisitos esses requisitos são fáceis são diretos para que vocês entenda e para que toda a equipe de desenolvimento entenda Então nesse caso aqui o backlog seriam essas três atividades essas três funcionalidades que serão implementadas no Sprint aí antes de começar o splint é feita uma reunião para decidir daquelas funcionalidades que o Pedro que era o po encontrou junto com os clientes junto com os os usuários do sistema do do Futuro sistema então Eh quais daquelas Funcionalidades que vai ser efetivamente implementada nesse Sprint e gerar uma nova versão

E também o tamanho do Sprint em tempo né no caso esse exemplo na reunião de planejamento de Sprint a equipe eh decide que a implementação da funcionalidade de gerenciamento de menu e anotação de pedidos pode ser alcançadas no Sprint de duas semanas então na própria reunião junto com o desenvolvedor junto com o scram master eles conseguiram entender que aqueles Dois requisitos aquelas duas funcionalidades que tá lá no backlog conseguem ser implementadas em duas semanas e você consegue gerar uma nova versão do software já eh depois dessas duas semanas agora eu dou um exemplo como seria

a execução do Sprint nessas duas semanas né então a equipe começa a trabalhar nas tarefas designadas então a Ana que a gente falou lá no começo quando a gente definiu o papel dela que ela era designer de ui e ux cria os Designers de interface para o gerenciamento do menu e anotação dos pedidos o João que também é da equipe de desenvolvimento que é um desenvolvedor frontend começa a implementar os designers da Ana ele pega os designers que a Ana fez e começa a fazer a interface o Lucas que é um desenvolvedor backend trabalha em

paralelo com João desenvolvendo as apis que apis são bibliotecas são códigos Fontes que vão ser utilizados por todo o sistema Necessários para suportar as novas funcionalidades Fernanda que é especialista em teste como foi definido lá logo no começo trabalha com conjunto em conjunto com João e com Lucas testando as funcionalidades conforme elas são desenvolvidas E durante as reuniões diárias de scram lembra que na na em scram todo dia tem uma reunião no final do do trabalho de 15 minutos a equipe discute o progresso levanta as questões e ajusta seu plano conforme o Necessário continuando o

exemplo depois dessas duas semanas que levou o Sprint acabou o Sprint agora vou ter uma nova versão do software uma nova versão do meu produto então a equipe organiza uma outra reunião de demonstração pro po então o po que é representa o o cliente o dono do produto ele vai verificar se aquelas funcionalidades que ele pediu lá logo no começo foram realmente implementadas eles demonstram uma nova funcionalidade de gerenciamento de menu E anotação de pedidos e recebem um feedback que é valioso nesse caso pois ele representa o cliente antes de começar o novo Sprint escolher

novas funcionalidades que vão ser implementadas novas funcionalidades que estão lá no backlog que vão ser levados para aquele novo Sprint a reunião existe uma reunião de retrospectiva do Sprint que na verdade é para ver quais foram as principais dificuldades encontradas ali no exemplo eu coloquei um exemplo eh Aqui que eles identificam que a comunicação entre os desenvolvedores frontend e backend frontend que desenvolve interface backend que desenvolve os algoritmos e e tudo mais precisa ser melhorada Pois houve algumas confusões sobre as apis eh como as apis deveriam funcionar eles concordam Inter ter reuniões de alinhamento mais

regulares no próximo Sprint Ou seja eu tentei resolver então um problema que foi Recor ente durante o Sprint passado Para que eu não repita esse problema no próximo Sprint agora para a pensar no próximo Sprint que vai ser feito eh com base nos feedbacks dos stakeholders das pessoas que estão envolvidas em todo o processo de desenvolvimento e nas lições aprendidas naquela reunião de retrospectiva que foi feita Pedro que é o po que é o o proprietário e do produto né que a gente chama atualiza e repriorização algumas funcionalidades que estão lá no Backlog E agora

repriorização o que que a gente vai implementar nesse novo Sprint vai durar duas semanas também pode ser que dure mais dependendo da complexidade do que será implementado a equipe então começa a planejar já o próximo eh Sprint o o o processo scram ele pode utilizar uma tecnologia chamada canan canan foi inventada eh no Japão e era para ajudar a facilitar a visualização de tarefas tarefas essas que podem ser a fazer em Progresso e Feito tá bom eh no nosso caso utilizando o cante gente pode usar também uma ferramenta chamada trelo o trelo ele organiza as

tarefas também no formato do canan que é mais ou menos parecido com que a gente tá vendo aqui eh nessa tela é por exemplo o que que a gente podia fazer então o cban é um quadro que vai ser visualizado por todo mundo que faz parte do processo de desenvolvimento aí eu vou conseguir saber os o status como é que tá cada tarefa que tá sendo Executado então eu sei por exemplo olhando aqui nesse quadro cban que visualizar inventário e pagamento online ainda não foi feito nada ele está a fazer o que está sendo feito

no momento em Progresso é o gerenciar o menu anotar pedidos interface do usuário e implementação backend e o que já foi feito é o design do gerenciamento de menu design de anotações de pedido e por aí vai então é legal de você utilizar o canan até para você se organizar em Várias coisas dá para você usar o canan por exemplo na disciplina você saber o que que tá faltando Quais são as aulas que estão faltando para que você assista Quais foram que você tão que você tá assistindo agora que você tá estudando agora e quais

já foram assistidas é bem legal e você pode praticar um pouco a quem se destina os métodos ágeis por exemplo o sccr que a gente acabou de ver geralmente grupos de 2 a 10 pessoas programadores desenvolvedores eh não Muito mais do que isso a gente viu nesse exemplo que tem que ser bem coeso o grupo a gente tem reunião diariamente então se for muita gente vai ser difícil de funcionar o scran também funciona e muito bem se for online mas ele é preferível que seja executado em loco projetos de 1 a 36 meses um projetos

não muito longos de tempo para que seja construído e uma Estimativa de 1000 a 250.000 linhas de código para que também não sejam projetos muito complexo Que o d conta a partir disso se for alguma coisa muito complexa é melhor que você utilize o método tradicional só pra gente discutir um pouquinho agora que a gente viu o scram viu um exemplo de como aplicar um processo de desenvolvimento ágil e algumas características comuns de todos os métodos ágeis né é o foco desses métodos é entrega frequente de subversões de software funcionando para o cliente a gente

viu que quando a gente escolhe no backlog as funcionalidades Faz um Sprint de pouco tempo no máximo um mês então uma vez por mês eu entrega uma versão nova do software para o cliente e colocar o foco também nos seres humanos que desenvolvem um software né tem essa reunião di área ter essa coesão na equipe é importante para qualquer método ágil tanto no XP que a gente não tá vendo nessa aula mas vocês podem procurar mais para saber um pouco mais quanto no scrum quanto no Crystal e outros métodos por aí retira o foco de

Processos rígidos e burocráticos né se você for pegar eh o processo Unificado o o o up que a gente fala eh você vai ver o tanto de documentação o tanto de burocracia que tem para cada etapa tudo sempre é bastante documentado no nosso caso não vai ter isso documentações e contratos detalhados também é retirar do foco ferramentas que são usadas pelo seres humanos eh então A ideia é que você interaja mais com o ser humano tá bom sem sem o uso de ferramentas por Isso ele sempre prega eh o contato a reunião diária com o

ser humano Tá bom agora que a gente já viu bastante coisa não tem nada a ver essa aula bom agora que a gente já viu bastante eh métodos desenvolvimento entendeu um pouquinho desse universo que é o princípio da engenharia de software tentar colocar a ordem eh um passo a passo para que você construa software que seja verificável a qualidade como é que eu escolho Qual que é o o o melhor modelo de processo bom Primeira coisa a natureza do projeto e da aplicação se for um processo por exemplo um projeto que seja bastante complicado eh

talvez e e utilize muita gente seja muitas linhas de código Talvez seja melhor você utilizar o processo Unificado que a gente viu na outra aula Se for por exemplo um projeto que eu já tenho os requisitos bem definidos não eu sei que não vão mudar são requisitos estáveis eu posso usar o modelo Cascata por exemplo que ele é bem Ele é bem fácil de usar bem fácil de você compreender Quais são as os métodos e as ferramentas que vão utilizar são coisas muito complexas são métodos que precisam de treinamento o tempo todo podem ser que

eh sejam mudados durante o proc desenvolvimento então é melhor utilizar o método de desenvolvimento ágil que ele é adaptável à mudanças controles e produtos que precisam ser entregues eu posso entregar o produto com bastante tempo eu vou ter bastante Tempo para pensar para projetar então eu posso utilizar um eh de novo Cascata Ah tenho pouco tempo eu preciso então da análise de riscos vamos supor que eu tô fazendo um sistema sei lá para controle de tráfego em aviação eu preciso de ter uma análise de riscos eu preciso saber exatamente o que tá acontecendo Eu não

posso entregar um software de qualquer tipo ou então se for um software pequeno um software que que eu consigo entregar ele e consigo incrementá-los poucos eu Vou utilizar um método ágil Então depende de muitas características também depende da equipe da quantidade de de desenvolvedores que eu tenho na minha equipe se você for trabalhar numa empresa uma software House numa empresa que desenvolve software eles vão contratar o tempo todo desenvolvedores projetistas que fazem parte dessas equipes isso é Dependendo para projeto então um desenvolvedor é contratado por projeto tá bom devido eh essas Características dos processos de

desenvolvimento de software estamos terminando eh essa última aula do módulo um eh Lembrando que nós vamos ter uma atividade avaliativa nesse módulo tá bom que vai ser do dia 16 ao dia 17 de novembro Fique atento tá vai ficar aberto por dois dias eh essa atividade avaliativa são 10 questões objetivas E é só você ler o material que eu passei e também que você faça parte preste atenção na Nas aulas né Anote o que você tiver dúvida Lembrando que V vamos ter eh pelo menos três aulas síncronas antes da prova antes dessa atividade avaliativa então

tire suas dúvidas se você tiver Leia na Postila a unidade dois processo de software é pouquinha coisa agora são da página 23 da página 26 se você quer se aprofundar na apostila não tem muita coisa sobre o scram só tem sobre desenvolvimento ágil de software se você quiser se aprofundar um pouco Mais tem uma apostila bem densa e com bastante conteúdo sobre Scan que eu tô deixando aqui no ambiente também tá bom procura no ambiente que você vai encontrar essa apostila que você pode se aprofundar mais sobre o screen não vai cair na prova mas

é mais para você ter um conhecimento um pouco melhor sobre essa esse processo scen Olá seja bem-vindo à nossa terceira aula do primeiro módulo nossa aula agora de engenharia de software voltada a métodos Ágeis e desenvolvimento vou falar um pouquinho sobre como surgiram esses métodos ágeis mas especificamente eu vou falar de um método agem que é o chamado scrum a gente vai ver depois mas o scrum Não é só para desenvolver software pode ser para qualquer coisa né você pode utilizar o scrum por exemplo para trabalhar na sua empresa por exemplo onde se você trabalha

na sua empresa Você pode organizar os processos o desenvolvimento dos processos de Produtos o que você quiser utilizando o scrum e ele se deu muito bem na área de engenharia de software para projetos pequenos para software com que são construídos por de duas até 12 pessoas você consegue utilizar o scram Tá bom então Preste atenção no que vai ser dado Por que que surgiu Então essa nova metodologia a gente viu na aula as metodologias tradicionais de software que as primeiras metodologias tentão vam colocar em ordem um mundo um pouco Caótico que é essa construção de

software eh através de Passos através de uma metodologia que você vai seguir passo a passo entretanto projetos pequenos projetos que de demanda de software eh onde é focado mais no cliente esses projetos não eram bem atendidos nessas novas nessas metodologias mais tradicionais como a gente viu o cascata oir e o processo Unificado e assim e como tá dizendo aqui nesse slide né Existe uma Grande demanda de novas aplicações e aqueles projetos aqueles processos de desenvolvimento mais robustos e começaram a ficar complicados e acabaram não sendo usados e voltaram a usar aquele método de codificação e

e reorganização você codifica e refaz de novo codifica e refaz e software os sistemas distribuídos heterogêneos começaram as ter mais quantidades deles S produzidos E era necessário agora uma nova Metodologia que pudesse ser feita em menos pessoas em menos quantidade de gente requisitos Mutantes lembra lá no modelo Cascata quando ele era sequencial se eu tivesse um requisito que tivesse mudado durante o processo de desenvolvimento eu teria que voltar de novo no início lá do nosso processo desenvolvimento isso não se adequava bem às novas necessidades e é importante enzar que não H gente para para desenvolver

tanto software com Qualidade Então tem que pensar em alguma coisa um pouco menor e foi aí que vários pesquisadores se reuniram e fizeram um um tomaram uma decisão importante para desenvolvimento de software com as metodologias de software tradicionais que a gente viu elas tinham alguns problemas por exemplo elas supunham que você conseguiria prever o futuro quando você de novo pensando no cascata você tem que definir os requisitos lá no começo do processo de movimento você Definiu e não pode mexer mais porque ele é sequencial e linear então só no final que você vai entregar outro

problema pouca interação com o cliente o cliente só viu o software no final ou só viu ou no começo quando você começava a a elicitar os requisitos a descobrir os requisitos ênfase em burocracias é muita documentação se vocês procurarem saber um pouco mais sobre o processo Unificado que eu expliquei na aula passada breve mente vocês vão ver a quantidade de Documentação essa quantidade de documentação é importante para que você entenda o software mas softwares talvez menores não precisa de tanta burocracia eh a avaliação de produtividade desses modelos antigos é baseada em burocracia e não em

código eh grande quantidade de erros e falta de flexibilidade são outros problemas também relatados eh modelos tradicionais desenvolvimento de software Então a partir daí tiveram Algumas ideias então começaram a surgir novas tecnologias como padrões de projeto que é uma reutilização de ideias padrões de projeto eh se vocês procurarem saber o que que é são soluções para para problemas recorrentes ou seja são soluções que já foram aplicadas testadas e que você pode utilizar de novo a orientação objeto também permitiu que que isso seja possível eh através de componentes por exemplo então quando surgi a orientação Objetos

na década de 80 e começou aprimorar na década de 90 começaram a criar essas novas tecnologias midware que aumenta a abstração mides que facilitam você conectar com banco de dados facilita você não precisa saber detalhes da implementação você usa um midware e começaram a surgir novas metodologias de desenvolvimento de software que são chamados métodos ágeis e e a gente vai ver o principal método ágil que é o scr principal utilizado Hoje em dia então tiveram vários pesquisadores vários desenvolvedores de software que não estavam contentes com os modelos da época Então o que eles fizeram Eles

resolveram fazer uma reunião num hotel lá em Utá nos Estados Unidos e fizeram um Manifesto é conhecido como Manifesto ágil você pode entrar nesse endereço ó agom manifesto.org que você vai ver exatamente a reunião tem uma foto lá dos a gente vai ver no próximo slide uma Foto dessa reunião desses 17 desenvolvedores de software e eles colocaram algumas regras que a partir dessas regras partir desses princípios os novos processos de desenvolvimento novos modelos de desenvolvimento de software tinham que seguir se quisesse seru modelo ágil Essa é a página do Manifesto ágil onde eles colocam eh

algumas das dos princípios do Manifesto tá bom Até hoje você pode acessar esse Manifesto tá nesse endereço que tá Colocado na no slide e aparece o nome dos 17 desenvolvedores de software pesquisadores tá bom se você pesquisar um pouco sobre e métodos ágeis você vai descobrir que várias dessas pessoas que estão aí desses 17 foram os que contribuíram para desenvolver esses novos métodos o Kent beack por exemplo esse primeiro da lista ele que encabeçava esse Manifesto ágil ele fez tem um livro sobre XP XP chama programação extrema Tá bom quem tiver Mais interesse Procure um

pouco sobre isso na internet o penúltimo nome da lista o Jeff sutherland é um cara que desenvolveu o scrum que a gente a vai ver daqui a pouco as principais ideias do Manifesto de desenvolvimento ágil de software era que indivíduos e interações são mais importantes que processo em ferramentas ou seja priorizar eh o face to face o cara a cara e a conversa com o cliente software funcionando é mais importante Do que documentação completa e detalhada então começaram a pensar novas maneiras de você documentar o software não tem clar documentação mais pesada como os processos

tradicionais os processos mais antigos colaboração com o cliente é mais importante do que negociação de contratos se você conseguir ter o cliente participando do seu processo de desenvolvimento em todo o processo é uma das partes mais importantes do Manifesto ágil a adaptação à mudança é mais Importante do que seguir o plano Inicial eh aquela parte dos requisitos mutáveis de repente tô desenvolvendo o software apareceu um requisito novo ou então Quero mudar um requisito então não tem que voltar desde o início eu tenho que abraçar essa mudança e fazer com que essa mudança seja parte do

processo de desenvolvimento do software alguns princípios do Manifesto ágil eh como tem como objetivo inicial n só lendo aqui satisfazer o cliente entregando Rapidamente com frequência sistemas com algum valor é aquela parte de ser interativo ou seja toda vez eh você entregar alguma coisa participar de interações e também participar de eh incremento do software então entregar versões funcionais em prazos curtos a gente vai ver que dependendo do tamanho do software o modelo scrum por exemplo pode ser de uma semana de um mês de duas semanas você define o prazo para que você entregue Uma nova

versão estar preparados para requisitos Mutantes ou seja estar preparados para mudanças que podem ocorrer tanto pelo cliente como pelo pelo próprio ambiente que tá sendo desenvolvido pessoal de negócio e desenvolvedores juntos a gente vai ver por exemplo no scram eh existe uma pessoa do do desenvolvimento que é o po a gente vai falar disso daqui a pouco que ele é o dono do produto é um desenvolvedor que representa o cliente Ou seja ele vai tá muito próximo do cliente é diferente de você encontrar o cliente somente em etapas definidas do seu processo como era lá

no no Cascata como era no modelo espiral ou então Eh num processo Unificado troca de de de informações atrav eh através de conversas diretas Então você vai ver alguns modelos desenvolvimento de software eles falam por exemplo que é preferí você eh falar com o cliente pessoalmente ou então uma ligação ou Então uma mensagem então eles vão dando prioridade para que o o cara a cara com o cliente seja mais mais mais importante por isso é importante sempre manter o contato com o cliente algumas alguns dos principais métodos ágeis que foram Existem muitos né mas os

principais aí que talvez estejam na literatura que você pode procurar um pouco mais eh O primeiro é da família Crystal tá da família Crystal foi criado eh P um pesquisador eh onde Ele tem e vários tipos para tanto para software pequeno pra quantidade de desenvolvedores eh software médio e software grande Tá bom se você procura quiser procurar um pouco sobre isso Procura lá Crystal eh no Google que você vai encontrar mais informações a gente não vai ver sobre isso no Brasil usa-se muito pouco o método Crystal talvez eu não conheça quem usa aqui no Brasil

programação extrema XP foi os um dos primeiros a ser utilizados foi Idealizado para aquele cara lá que eu falei para você o KB ele tem um livro sobre isso e também tem várias páginas na internet sobre programação extrema eh hoje ão tem se usado menos o programação extrema Mas ele foi muito importante para por apli for o primeiro método de desenvolvimento de software aplicar aquelas princípios do Manifesto ágil e tem o modelo scrum que ele serve para você desenvolver qualquer coisa até para você organizar trabalho eh até para você Por exemplo um professor que é

é orientar os alunos ele pode usar o scrum até nessa orientação de alunos nesse processo de orientação Tá bom então É bem interessante o scram utiliza outras técnicas como o canan que veio já de é uma outra tecnologia de de de gerenciamento de pessoas gerenciamento de tarefas e a gente vai ver na verdade somente o scrum nessa aula tá bom a metodologia scrum ou também você pode verem screw Eh na verdade é uma é é um é uma estratégia de jogo do rugby né ele Dev o idealizador da metodologia devia ser fã de rugby e

deu esse nome aí parae na verdade eh várias o que que é essa esse esse esse essa estratégia de jogo do rugby eh onde vários jogadores colocam uma bola quase perdida novamente em jogo através do trabalho em equipe e é meio que essa a ideia mesmo de você saber participar a equipe a equipe ser forte no desenvolvimento de software em outras Metodologias mais tradicionais a equipe não importa muito né nessa não nessa é importante e os valores são importantes para a equipe a equipe tem que estar feliz a equipe tem que estar Coesa para que

dê certo mas tem que ser equipe pequena né por isso a gente vai ver depois no final da aula é quando que o scrum pode ser utilizado ou não E quem desenvolveu o o método scrum é o Jeff sutherland é aquele cara lá que eu falei para vocês que fazia parte do Manifesto Ágil mas ele começou a desenvolver essa ideia né de do do scram desde 1990 tá bom com a sua equipe de desenvolvimento de software a equipe scram né que a primeira coisa que você vai montar é uma equipe scram a equipe scram ela

tem somente três papéis Ela é bem tranquila é claro que alguns papéis podem ser eh alternados eu vou explicar isso com mais detalhe depois eh a SKP Pelo menos tem o Square Master que é o cara que ajuda a Entender as e seguir as regras do Square ele vai ver eh como é que tá funcionando o scram se tá todo mundo seguindo as regras se tá todo mundo assumindo o papel se tá tá funcionando a gente vai ver que por exemplo tem uma reunião eh eh diária se essa reunião tá sendo executada eh no final

tem uma revisão Tá bom então a gente vai ver tudo sobre isso é sobre o scram Master ele que é o responsável o product Honor conhecido como po é o O que representa o Stakeholder ah lembra essa a palavrinha stakeholder stakeholder é qualquer pessoa que esteja envolvida no desenvolvimento de software eh pode ser desde o dos desenvolvedores em si mas também pode ser o cliente tá bom e vários tipos de cliente Talvez o cliente que que pediu o software que requisitou o software ou o cliente que vai utilizar o software Tá bom então essa palavra

stakeholder é bastante utilizada em engenharia de software Ah então se você tiver lembra aquela ideia que eu falei aquele princípio de sempre manter o o o cliente junto no processo de desenvolvimento o scream faz isso através do po e por último é o outro papel que tem é a equipe de desenvolvimento geralmente nesse papel papel de equipe de desenvolvimento é tem mais de uma pessoa então com três pessoas você começa a desenvolver software Então você consegue ter uma equipe pequena e consegue desenvolver Software é claro que geralmente é utilizado para mais pessoas cinco a seis

pessoas Talvez seja o tamanho ideal eh para você utilizar o scram o fluxo de processo do scram é mais ou menos assim você pega e algumas das funcionalidades eh que você vai control do software e coloca ela eh de maneira que ela possa ser e implementada em semanas ou então em dias então você a equipe que vai definir isso essa essas funcionalidades elas são Chamadas de backlog do produto se você der uma olhada nessa figura você vai ver lá backlog do Sprint a palavra Sprint em inglês significaria corrida então o Sprint é o quanto tempo

que você demora para implementar essas funcionalidades que estão no backlog essas funcional ess print pode ser de uma semana 30 dias eh duas semanas dependendo do tamanho do software dependendo da complexidade e de cada funcionalidade Então vamos lá a equipe escolhe qual vai ser o backlog e Quais dessas funcionalidades do backlog vão entrar nesse Sprint Então esse Sprint vai vão durar por exemplo 30 dias então eu escolho os itens que vão pertencer ao ao backlog e coloco isso no Sprint aí a minha equipe sabe que nesses 30 dias a gente só vai se preocupar com

esses itens do backlog ou seja com esses itens com essas funcionalidades que foram escolhidas e já foram pensadas e sabidas que se dá tempo de implementar elas em 30 dias após esses 30 dias eu Vou gerar uma nova funcionalidade que é o que tá mostrando aí nessa figura E lembrando que cada um desses 30 dias a cada dia a cada final de dia eu tenho uma reunião scrum essa reunião scrum é uma reunião chamada de standup meeting que é uma reunião em Pé Na verdade é uma reunião que todo mundo vai falar e o que

aconteceu o que realizou na desde o último SC da última reunião e se tá tendo alguma dificuldade ou será o que vai fazer eh antes do próx da próxima Reunião Tá bom então são reuniões que facilitam o entendimento lembra que a a esses métodos AD uma das ideias é a comunicação também se comunicar bastante então todo dia a equipe de desenvolvimento junto com es e o poo se reúnem e tem 15 minutos de reunião de pé Por que de pé para que seja rápida mesmo para que seja uma uma uma reunião mais efetiva tá então

todo dia tem essa reunião de pé Então nesse exemplo que a gente tá mostrando aqui na figura eh em 30 dias você produz uma nova funcionalidade agora eu vou mostrar para vocês um exemplo de como seria eh você aplicar a metodologia scram e no desenvolvimento de um software Tá bom então principalmente a gente vai prestar atenção eh nos papéis e como que Eu dividi a equipe dentro desses papéis que a gente aprendeu agora a pouco é um sistema de restaurante que será construído Tá bom então Eh eu meio que inventei as funcionalidades mas a ideia

É só para que a gente aprenda como é que isso é feito tá bom também vou inserir umas palavras diferentes que a gente vai começar a prestar atenção nelas que são bastante utilizados dentro da área de engenharia de software a gente vai ver isso nos próximos slides Lembrando que a equipe scram só também só tem somente três papéis scram Master product owner E a equipe de desenvolvimento Tá então vamos eh dar um exemplo da formação da equipe scram para desenvolver o sistema De restaurante eh o scram Master seria Maria por exemplo que tem experiência em

gestão de projetos de software e é responsável por garantir a equipe siga suas práticas de scrum já falei sobre isso no slide passado Pedro que trabalha para o restaurante tem uma compreensão Clara das necessidades do sistema Olha é o dono do produto é legal que você ten um dos clientes eh um dos que vão utilizar o sistema que faça parte da sua equipe de desenvolvimento e a a equipe De desenvolvimento a Ana seria a designer de ui e ux ui seria user interface interface com usuário é responsáveis pelos botões pelas cores e ux eh user

Experience é são responsáveis pelas experiências do usuário como facilidade de visualização e qualidade cores combinação de cores paleta de cores seria então a Ana responsável por isso o João seria um desenvolvedor frontend front end é o que vai desenvolver a interface do sistema Tá bom então a Ana vai projetar e o João vai desenvolver o Lucas seria o desenvolvedor backend desenvolvedor backend é o que vai fazer a parte de de conexão com o banco de dados fazer as regras de negócio implementar os algoritmos Tá bom então desenvolvedor backend é o que faz isso e Fernanda

seria especialista em testes é o que vai fazer o funcionar V se tá funcionando tudo corretamente aplicando testes para verificar Isso seguindo o exemplo agora eu tenho a criação do backlog do produto lembra o que que é o backlog do produto seriam a as atividades que serão implementadas as necessidades do cliente que serão implementadas dentro do print se você não lembra volta um pouquinho o vídeo volta L ali no slide onde eu mostro e a figura do scram o processo scram e verifique lá o que que é backlog cada caixinha daquela que tem naquela figura

representa uma atividade que será Implementada eh no nosso exemplo agora Pedro que é o po trabalha com os stakholders do restaurante para identificar os recursos necessários para o sistema ele cria o backlog do produto que inclui item como como gerente quero gerenciar o meu restaurante para que os clientes possam ver os itens atualizados como garçom quero Anotar os pedidos dos clientes para que os chefes possam preparar prepará-los como gerente Quero visualizar e gerenciar os o inventário Para que possamos manter um estoque adequado e no processo scram quando você anota os requisitos quando você descreve os

requisitos sempre você vai colocar desse jeito que tá aí nesse exemplo como Aí você coloca o papel que você tá assumindo lá de de usuário do sistema o que que você quer e com isso tá bom então você sempre você coloca o seu papel que você quer e o que você quer Eh para para aquilo né então o Pedro que era o pi ele foi lá no restaurante e ele Que era o maior conhecedor ele já trabalha trabalha no restaurante e ele conseguiu fazer esses requisitos esses requisitos são fáceis são diretos para que vocês entenda

e para que toda a equipe de movimento entenda então nesse caso aqui o backlog seriam essas três atividades essas três funcionalidades que serão implementadas no Sprint aí antes de começar o splint é feita uma reunião para decidir daquelas funcionalidades que o Pedro que era o po Eh encontrou junto com os clientes junto com os os usuários do sistema do do Futuro sistema então Eh quais daquelas funcionalidades que vai ser efetivamente implementada nesse Sprint e gerar uma nova versão E também o tamanho do Sprint em tempo né no caso eh nesse exemplo na reunião de planejamento

do Sprint a equipe eh decide que a implementação da funcionalidade de gerenciamento de menu e anotação de pedidos pode ser alcançadas no Sprint de duas semanas Então na própria reunião junto com o desenvolvedor junto com o scram master eles conseguiram entender que aqueles dois requisitos aquelas duas funcionalidades que tá lá no backlog conseguem ser implementadas em duas semanas e você consegue gerar uma nova versão do software eh depois dessas duas semanas agora eu dou um exemplo como seria a execução do Sprint nessas duas semanas né então a equipe começa a trabalhar nas tarefas designadas então

a Ana que a gente falou lá no começo quando a gente definiu o papel dela que ela era designer de ui e o ex cria os designers de interface para o gerenciamento do menu e anotação dos pedidos o João que também é da equipe de desenvolvimento que é um desenvolvedor frontend começa a implementar os designers da Ana ele pega os designers que a Ana fez e começa a fazer e a interface o Lucas que é um desenvolvedor backend trabalha em paralelo com o João Desenvolvendo as apis que api são bibliotecas são códigos Fontes que vão

ser utilizados por todo o sistema necessários para suportar as novas funcionalidades Fernanda que é especialista em teste como foi definido lá logo no começo trabalha com conjunto em conjunto com João e com Lucas testando as funcionalidades conforme elas são desenvolvidas e durante as reuniões diárias de scram lembra que na na em scram todo dia tem uma reunião no Final do do trabalho de 15 minutos a equipe discute o progresso levanta as questões e ajuda seu plano conforme o necessário continuando o exemplo depois dessas duas semanas que levou o Sprint acabou o Sprint agora vou ter

uma nova versão do software uma nova versão do meu produto então a equipe organiza uma outra reunião de demonstração pro po então o po que é representa o cliente o dono do produto ele vai verificar se aquelas funcionalidades que ele pediu lá Logo no começo foram realmente implementadas eles demonstram a nova funcionalidade de gerenciamento de menu e anotação de pedidos e recebem o feedback que é valioso nesse caso pois ele representa o cliente antes de começar o novo Sprint escolher novas funcionalidades que vão ser implementadas novas funcionalidades que estão lá no backlog que vão ser

levadas para aquele novo Sprint a reunião existe uma reunião de retrospectiva do Sprint Que na verdade é para ver quais foram as principais dificuldades encontradas ali no exemplo eu coloquei um exemplo eh aqui que eles identificam que a comunicação entre os desenvolvedores frontend e backend frontend que desenvolve interface backend que desenvolve os algoritmos e e e tudo mais precisa ser melhorada Pois houve algumas confusões sobre as apis eh como as apis deveriam funcionar eles concordam em ter reuniões de alinhamento mais regulares No próximo Sprint Ou seja eu tentei resolver então um problema que foi recorrente

durante o Sprint passado para que eu não repita esse problema no próximo Sprint agora para a pensar no próximo Sprint que vai ser feito eh com base nos feedbacks dos stakeholders das pessoas que estão envolvidas em todo o processo de desenvolvimento e nas lições aprendidas naquela reunião de retrospectiva que foi feita Pedro que é o po que é o o proprietário e do produto Né que a gente chama atualiza e repriorização lá no backlog E agora repriorização o que que a gente vai implementar nesse novo Sprint vai durar duas semanas também pode ser que dure

mais dependendo da complexidade do que será implementado a equipe então começa a planejar já o próximo eh Sprint o o o processo scram ele pode utilizar uma tecnologia chamada canan canan foi inventada eh no Japão e era Para ajudar a facilitar a visualização de tarefas tarefas essas que podem ser a fazer em Progresso e feito tá bom e no nosso caso utilizando o cante a gente pode usar também uma ferramenta chamada trelo o trelo ele organiza as tarefas também no formato do canan que é mais ou menos parecido com o que a gente tá vendo

aqui e nessa tela é por exemplo o que que a gente podia fazer então o canan é um quadro que vai ser visualizado por todo mundo que faz parte Do processo de desenvolvimento aí eu vou conseguir saber os o status como é que tá cada tarefa que tá sendo executada então eu sei por exemplo olhando aqui nesse quadro cban que visualizar inventário e pagamento online ainda não foi feito nada ele está a fazer o que está sendo feito no momento em Progresso é o gerenciar o menu anotar pedidos interface do usuário e implementação backend e

o que já foi feito é o design do gerenciamento do menu design de Anotações de pedido e por aí vai então é legal de você utilizar o cban até para você se organizar em várias coisas dá para você usar o cban por exemplo na disciplina você saber o que que tá faltando Quais são as aulas que estão faltando para que você assista Quais foram que você tão que você tá assistindo agora que você tá estudando agora e quais já foram assistidas é bem legal e você pode praticar um pouco a quem se destina os métodos

ágeis por Exemplo o que a gente acabou de ver geralmente grupos de dois a 10 pessoas programadores desenvolvedores eh não muito mais do que isso a gente viu nesse exemplo que tem que ser bem coeso o grupo a gente tem reunião eh diariamente então então se for muita gente vai ser difícil de funcionar o scran também funciona eh muito bem se for online mas ele é preferível que seja eh executado em loco projetos de 1 a 36 meses projetos Não muito longos de tempo para que seja construído e uma Estimativa de 1000 a 250.000 linhas

de código para que também não sejam projetos muito complexo que o SC dá conta a partir disso se for alguma coisa muito complexa é melhor que você utilize o método tradicional só pra gente discutir um pouquinho agora que a gente viu o scram viu um exemplo de como aplicar um processo desenvolvimento ágil eh algumas características comuns de todos os Métodos ágeis né é o foco desses métodos é entrega frequente de subversões de software funcionando para o cliente a gente viu que quando a gente escolhe no backlog as funcionalidades faz um Sprint de pouco tempo no

máximo um mês então uma vez por mês eu entrego uma versão nova do software para o cliente e colocar o foco também nos seres humanos que desenvolvem o software né ter essa reunião diária ter essa coesão na equipe é importante para qualquer método ágil Tanto no XP que a gente não tá vendo nessa aula mas vocês podem procurar mais para saber um pouco mais quanto no scram quanto no Crystal e outros métodos por aí retira o foco de processos rígidos e burocráticos né se você for pegar e o processo Unificado o o o Up que

a gente faz fala eh você vai ver o tanto de documentação o tanto de burocracia que tem para cada etapa tudo sempre é bastante documentado no nosso caso não vai ter isso documentação e contratos Detalhados também é retirar do foco ferramentas que são usadas pelos seres humanos eh então A ideia é que você interaja mais com o ser humano tá bom sem sem o uso de ferramentas por isso ele sempre prega eh o contato a reunião diária com o ser humano Tá bom agora que a gente já viu bastante coisa não tem nada a ver

essa aula bom agora que a gente já viu bastante métodos movimento entendeu um pouquinho desse universo que é o princípio da Engenharia de software tentar colocar a ordem é um passo a passo para que você construa software que seja verificável a qualidade como é que eu escolho Qual que é o o melhor modelo de processo bom primeira coisa a natureza do projeto e da aplicação se for um processo por exemplo um projeto que seja bastante complicado tal tal vez eh e utilize muita gente seja muitas linhas de código Talvez seja melhor você utilizar o processo

Unificado que a gente viu na Outra aula eh se for por exemplo um projeto que eu já tenho os requisitos bem definidos não eu sei que não vão mudar são requisitos estáveis eu posso usar o modelo Cascata por exemplo que ele é bem ele é bem fácil de usar bem fácil de você compreender Quais são as os métodos e as ferramentas que vão utilizar são coisas muito complexas são métodos que precisam de treinamento o tempo todo pode ser que eh sejam mudados durante o PR desenvolvimento então é Melhor utilizar o método de desenvolvimento ágil que

ele é adaptável a mudanças cont controles e produtos que precisam ser entregues eu posso entregar o o o o produto eh com bastante tempo eu vou ter bastante tempo para pensar para projetar então eu posso utilizar um eh de novo o Cascata Ah tenho pouco tempo eu preciso então da análise de riscos vamos supor que eu tô fazendo um sistema sei lá para controle de tráfego em aviação eu preciso de ter uma análise de Riscos eu preciso saber exatamente o que tá acontecendo Eu não posso entregar um software qualquer tipo ou então Eh se for

um software pequeno um software que que eu consigo entregar ele e consigo incrementá-los poucos eu vou utilizar um método ágil Então depende de muitas características também depende da equipe da quantidade de de desenvolvedores que eu tenho na minha equipe se você for trabalhar numa empresa uma software House numa empresa que desenvolve Software eles vão contratar a o tempo todo desenvolvedores projetistas que fazem parte dessas equipes isso é Dependendo para projeto então um desenvolvedor é contratado por projeto tá bom devido eh essas características dos processos de desenvolvimento de softw estamos terminando e essa última aula do

módulo um eh Lembrando que nós vamos ter uma atividade avaliativa nesse módulo tá bom que vai ser do dia 16 ao dia 17 de novembro fique até tá vai Ficar aberto por dois dias essa atividade avaliativa são 10 questões objetivas E é só você eh ler o material que eu passei e também que você eh faça parte preste atenção nas aulas né Anote o que você tiver dúvida Lembrando que vamos ter pelo menos três aulas síncronas antes da prova antes dessa atividade avaliativa então tire suas dúvidas se você tiver Leia natil eh a unidade dois

processo de software é pouquinha coisa agora são da página 23 Da página 26 se você quer se aprofundar na apostila não tem muita coisa sobre scram só tem sobre e desenvolvimento ágil de software se você quiser se aprofundar um pouco mais tem uma apostila bem bem densa e com bastante conteúdo sobre scam que eu tô deixando aqui no ambiente também tá bom procura no ambiente que você vai encontrar essa apostila que você pode se aprofundar mais sobre o scream não vai cair na prova mas é mais para você ter um Conhecimento um pouco melhor sobre

essa esse processo