[Música] lomba olá sou professor marcelo fantinato até disciplina de engenharia de software do curso de engenharia da computação da univesp vamos agora para a aula quatro na aula anterior eu apresentei os conceitos básicos sobre método vagens e agora vou apresentar para vocês uma visão geral de um dos métodos ágeis o primeiro método ágil que ficou mais conhecido e usado maior escala que foi a programação extremos ip vou falar muito brevemente sobre um dos que está sendo mais usado atualmente o scream e finalizou com um breve resumo sobre quando e quando em quando usar e quando
não usar é baseado na bibliografia básica que a gente está seguindo nessa disciplina bom então começando esse diagrama ele basicamente resume o que é a afp o extreme programming ou programação extrema eu havia comentado que se espelha um pouquinho mais técnico do queijo de gestão isso porque ele dá um pouco mais de informação sobre como executar as atividades do ponto de vista técnico por exemplo como levantar os requisitos do usuário é eu tomei uma decisão basicamente também levando em consideração como que o próprio somerville organiza informações no livro dele mas a gente ainda não viu
como requisito o efeito de uma forma tradicional em engenharia de software e aqui a gente vai ver como é tem métodos ágeis nec é baseado na história na na idéia de histórias do usuário e ea gente não viu por exemplo como é feito caso de uso que engenharia de software tradicional então seria bom se a gente já tivesse dito tradicional para comparar agora com a idéia de métodos usados por outro lado eu optei para se perseguir a idéia do a-ha a estrutura do livro do flamengo viu também porque ele está falando de processo de forma
geral então acaba sendo um bom momento de falar de métodos usados também de uma forma geral mas enfim vocês podem entender né que a idéia de casos de uso por exemplo uma idéia um pouco mais ampla de você especificar os requisitos de uma forma um pouco mais detalhada e vocês vão perceber que aqui que a história de usuário é uma forma um pouco mais simplificada sim com certeza e representar os requisitos do usuário e de novo existem os prós e contras para cada uma das formas mas enfim a idéia é isso aqui representa um ciclo
para você terminar um ciclo de uma duas três semanas é entregando uma versão do software funcionando um incremento do foco então quando você vai desenvolver aquele pedaço de software seleciona qual pedaço do software você vai fazer naquela entrega chamado de menino há outra palavra que às vezes a gente costuma não traduzir para o português então o ciclo isso aqui é um ciclo de uma menina que a gente vai entregar então selecionar quais histórias do usuário que eu quero a implementar nesta iv nesse incremento aí eu selecionei essas histórias vão implementar devido a essas histórias impressas
divididos pelos pros programadores desenvolvedores eu planejo fnf eu desenvolvo íntegro texto e aí eu libero e software avalio junto com o cliente finalizei começa o ciclo novamente então percebo que a idéia é você dentro de uma a de um ciclo de uma seleção que vai implementar naquele momento você divide os desenvolvedores envolve integra a festa dentro do desenvolvedor do desenvolver é que você vai basicamente projetar definir e testar libera e avalia bom algumas práticas de xp que vocês vão perceber muito muitas delas estão alinhados os princípios gerais que a gente viu na vídeo-aula passada então
a idéia do planejamento implementar os requisitos são feitos em cartões de história a questão da história específica de xp a e essas histórias serão incluídas no livro como a gente viu no slide anteriores ea gente vai ver qual é o tempo disponível qual a prioridade de cada uma dessas histórias baseado nisso essas histórias serão divididas em tarefas a gente vai ver quadro ao ver alguns eventos planejamento de forma incremental baseado em histórias histórias de vídeo do evento tarefas ea gente vai pensar sempre em pequenos bebidas então é a gente pensa em conjunto mínimo de funcionalidades
mas que estas funcionalidades sejam úteis e inagi engenharia de software tradicional é muito comum a gente pensar primeiro na na arquitetura básica vamos começar pelo básico pela camada de banco de dados e comunicação do banco de dados demora semanas às vezes meses para você ter uma parte superior que tem uma interface com o usuário que o usuário começa o cliente começa a ver o sistema podendo funcionar não significa que você não tem nada você pode ter muita coisa já implementado mas não talvez ainda nada de interface com o usuário aqui a idéia é você desenvolve
uma forma que rapidamente o usuário já consiga fazer alguma coisa útil para ele então você inverte a ordem das coisas ou seja o valor do negócio logo no início um ok e através de pequenas entregas pequenas do livro você tem que ter um projeto simples então pensa naquela necessidade naquele momento também tem que ter o desenvolvimento teste forte a idéia é você se preparar para o teste antes mesmo de implementar e vesti uma estratégia específica para isso na verdade um dos métodos ágeis rebatizado completamente nifo mas uma das práticas ip é também baseado nisso e
também o princípio da restauração sempre que tiver um tempinho o programador o desenvolvedor dá uma olhada no código dele para ver se ele consegue simplificar algo que é sempre a idéia de deixar mais fácil para manutenção no futuro programação em paris os desenvolvedores em que trabalham em paris sentarem juntos um ajudando o outro programar ok prestando apoio para o trabalho na propriedade coletiva como as pessoas os programadores e desenvolvedores trabalham em paris então não existe um código que é bom que com uma pessoa só é dono deles sempre é todo mundo é dono de tudo
porque os padres vão vão trocando então é existe a ideia da propriedade coletiva justamente por conta disso a integração contínuo então uma tarefa é concluída já integra como o sistema como um todo e os testes de unidade já devem ser executados de forma automatizada a ritmo sustentável é não se espera hora extra pelo menos não uma quantidade muito grande o grupo tem que trabalhar de uma forma sustentável e aquela ideia do cliente trabalhando no local junto com os desenvolvedores e acompanhando na verdade ele é responsável pela priorização dos requisitos que vão ser implementados não é
ele que vai de ver o que é útil o que vai servir realmente o negócio desde o início então aqui um evento de uma história pensando num sistema que vai fazer a prescrição de medicamentos eu não vou ler todo o exemplo aqui tá lá na bibliografia de vocês a idéia não é ler mas só para vocês perceberem história diferentemente de um requisito da engenharia de software tradicional que ele trata sempre impessoal é aqui a história de um evento como se fosse uma pessoa então vejam quente é uma médica que deverão prescrever medicamentos para um paciente
de uma clínica o prontuário do paciente já está sendo exibido em seu computador assim ela no caso a quente clickon campo medicação ela pode selecionar o médico atual então é já um cenário de uso do sistema se ela selecionar tal coisa o sistema faça tal coisa se ela fizer outra coisa então o sistema digital coisa já está o dizendo como a kate vai usar o sistema no caso específico de engenharia de software adicional a gente sempre faz já pensando como vai ser o sistema sempre assim seu médico um médico pode fazer tal coisa se ele
quiser tal coisa então o sistema façam coisas a gente já pensa sempre na forma é genérica então a gente já tem que pensar em todos os casos todas as possibilidades aqui a gente está pensando num caso específico e é esse caso específico que vai implementar a primeira vez o rock se tem outras situações e tem as exceções que a gente pode deixar para pensar nisso depois em outros incrementos em outras operações bom essa história aqui se ela foi em algum momento escolhido para ser implementada numa interação no incremento essa história é dividida em tarefas que
são os cartões de tarefa então a tarefa um vai se alterar a dose do medicamento a tarefa 2 efe a seleção do formulário ea tarefa três vezes e verificação de dose que são tarefas que podem ser extraídos a partir dessa história aqui essas tarefas vão ser distribuídas entre os desenvolvedores e os desenvolvedores então vão ficar responsáveis por essas tarefas notem que não vai ser trabalhado implementado por tudo o que é possível através de dentro de uma funcionalidade dessa sol que é mais importante nesse primeiro momento outras histórias podem surgir é nesse contexto mas podem entrar
em outras interações bom ainda algumas outras características adicionais dentro desse sistema o cliente é que prioriza as histórias para implementação para implementação escolhendo as que podem ser imediatamente usadas por ele dentro de duas semanas então geralmente um ciclo duradouro semana então é o próprio cliente que vai ajudar a fazer essa priorização que ele está trabalhando junto com o próprio a desenvolvedor os requisitos buda e fato então histórias não implementadas mudam ou podem ser descartados novos cartões podem ser desenvolvidos a nova versão só é aceita se todos os testes forem executados e esses testes passarem senão
ela não vai ser feita e aí o ciclo vai demorar um pouco mais do que era previsto mas isso não é esperado que aconteça na prática nem todos os princípios são sempre adotado uma coisa é o que seria o ideal é essa esses princípios aqui olha esses princípios de xt é o ideal mas aquilo mesmo eu falei pro engenharia de software adicional não é que ela no livro que tem que ser feito tudo o método usado da mesma coisa não é porque está aqui como princípio que tem que ser feito tudo senão você não pode
dizer que o sp você não pode dizer que a meta do ágio você pode perceber que para sua empresa determinada princípio está mais falando mal do que causando bem ok então não necessariamente teste p também é uma questão bastante importantes muito valorizada a ideia no teste forte você já pensa já projeta o teste que vai ser executado inclusive pensando no teste de unidade você já implementa o teste que vai ser executado automaticamente para testar aquele método que está sendo implementado a idéia é você e criando peças incrementais a partir dos cenários que estão sendo derivados
a partir das histórias que vão ser desenvolvidas a idéia é você envolveu vários clientes no desenvolvimento desses testes que também a ideia é ter essa idéia que de abordagem de testes automatizados a programação em paris então é pra você desenvolver uma propriedade responsabilidade coletiva embora essa idéia ela não seja nova né mas é uma ideia de uma programação sem ego isso leva a uma revisão informal claro se você tem duas pessoas programando uma programa ea outra ajudando essa outra já está informalmente fazendo uma revisão de forma que esta revisão não precisa ser feita na frente
de forma formal você acaba já adiantando uma reestruturação o programador que está sentado do lado ele já vai ajudando o já vai dando sugestões para você fazer o código não só corrigir o que está errado mas já fazer o código de uma forma mais simples é e da programação em paris este princípio ele tem um ganho maior quando a gente está falando de programadores menos experientes não é porque você inclusive pode pensar poxa mas se você pegar de dois programadores de cada um fazer o seu próprio código pode chegar até produtividade em dobro quando você
põe 21 só programando você diminui a produtividade pela metade da metade do código mas na verdade um ajudando o outro você tem você acaba melhorando a qualidade a rapidez então uma coisa anula a outra na verdade complementa né nem seria o melhor termo mas acaba melhorando do que cada um fazendo o seu e isso quando eles são não tão experiente se você colocar dois programadores muito experientes para trabalhar junto provavelmente o alguns estudos dizem que a produtividade acaba caindo como sempre são indicações mas a gente não pode ver uma coisa absoluta só para fechar muito
rapidamente sobre o processo apenas para ver que o scream ele é mais relacionada ao planejamento geral do ciclo então aquela idéia que aqui nós chamamos de deixa eu voltar aqui a idéia que está sendo chamada de um ciclo que em algum momento foi falado aqui de de duas semanas mais ou menos aqui no pan então isso vai ser planejado e desenvolvido e revisado comece novamente então você tem vários sprints obviamente princípios e idéias boas práticas na mesma idéia na mesma linha existem as práticas de shit mas eu não vou entrar nessa nesse detalhe aqui tem
muita bibliografia muita muito a informação a respeito disso é atualmente provavelmente o método mais usado nas organizações pelo menos nas organizações brasileiras certamente você encontra muita informação relacionada ao spam então já adiantei bastante sobre isso com vocês mas quando aplicado com certeza métodos ágeis em geral em geral não é verdade absoluta não sou eu que estou dizendo não sou especialista mas ter em método vagens mas fazendo uma análise simples básica a gente pode ver que em geral quando nós temos nós estamos desenvolvendo produtos novos do zero em geral pequeno e médio porte quando e visse
o compromisso claro do cliente que ele vai se envolver no processo e que não há muitas regras e regulamentos internos por exemplo no início um regulamento muito sólido claro a ser seguido como por exemplo do caso que eu usei um banco que tem um monte de regras do banco central que precisam ser seguidas e também equipes pequenas e integradas então esse é o cenário ideal em que um método ágil ele pode ser usado por outro lado quando não apitar dino em geral a sistemas são muito grandes sistemas são críticos se as equipes também são muito
grandes em relação à distribuidoras se você não está fazendo um sistema do node do vero mas se você está dando manutenção ou se você está fazendo uma extensão de um sistema que só existe se o cliente prefere não se envolver diretamente ele quer passar a especificação e pegar o sistema pronto do outro lado ou então se ele depende de regulamentação externa que não muda ou seja o instável são bastante estável então sistemas de grande porte não é razoável pensar em focar apenas no código do sistema lembra daquela figura em que a gente eu tenho muito
grande na implementação e teste não é razoável pensar nisso quando a gente está pensando e falando de temas de grande porte é mais necessário fazer projeto adiantado e documentação do sistema como um todo pensado antes arquitetura do sistema e não duvido para descrever os aspectos críticos do sistema como por exemplo pensar na arquitetura no projeto no esquema do banco de dados como um todo é dividir o trabalho entre a equipe mas não posso deixar de dizer que a 100 relatos de uso de métodos ágeis para sistemas grandes sistemas críticos equipes grandes distribuídos existem artigos o
artigo científico do artigo de de revistas de praticantes que não são científicos que sabem relatos de que funcionou existem relatos que dizem arma não funcionou ok então de novo não tem verdade absoluta mas em geral mesmo que funcionaram dizem funcionou mas em geral tal e qual aí a pessoa vai ter organizações que vai achar que vale a pena gastar muito e não vai falhar a pena enfim cada caso é um caso talvez nos dê mais valia a pena então uma análise mais importante uma mais criteriosa ela pode fazer sentido em cada caso então com isso
a gente termina é essa parte introdutória do processo de desenvolvimento de software e aí a partir da próxima das próximas vídeo aulas a gente começa a pegar cada etapa especificamente começando então com especificação de requisitos obrigado [Música] [Música] ae [Música] [Música] eu não me abalar
