Engenharia de Software - Aula 03 - Métodos ágeis, desenvolvimento ágil e dirigido a planos

[Música] Olá eu sou o professor Marcelo Fantinato Esta é a disciplina de engenharia de software do curso de engenharia da computação da Univesp vamos agora nessa videoaula falar um pouco sobre os métodos ágeis dentro da engenharia de software Ah para falar falar um pouco sobre os métodos ágeis primeiramente Ainda vamos falar um pouco do histórico que é pra gente conseguir entender a motivação pelo pela qual os métodos ágeis foram criados ess esse histórico né ele começa lá nacada de 60 nacada de 70 com o que ficou conhecido como a crise do software vocês provavelmente não

ouviram falar mas existiu a crise do software né basicamente Ah quando o software começou a ser desenvolvido né aqueles computadores muito antigos muito grandes com baixo poder de processamento e aqueles softwares também muito limitados né aquele software puramente técnicos ainda não era sistemas de informação mas enfim começou-se a desenvolver software eh as pessoas não eram Engenheiros de software não eram pessoas especializados no desenvolvimento de software e Ah já começou a ter problema com o desenvolvimento software lá naquela época problemas com orçamento que não eram cumpridos já existiam empresas desse dependendo de software naquele momento empresas

que desenvolviam software já não cumpriam o orçamento já não cumpriam prazo já não cumpriam qualidade já não cumpriam os requisitos E já tinham problema com a manutenibilidade ou seja depois que o software estava pronto se você tivesse que fazer alguma alteração já tinha dificuldade de fazer alteração entre outros problemas que nós conhecemos hoje e isso então ficou conhecido como a crise de software foi quando nós eh foi foi criado a ideia da engenharia de software ainda nesse período aqui final desse período aqui um grupo de pessoas de de de praticantes do desenvolvimento de software se

reuniu e pensou nós precisamos botar ordem na casa e aí pensaram se existem outras áreas tecnológicas que fazem se trabalho de forma sistemática e que isso é chamado de engenharia nós precisamos fazer isso também na na na área de desenvolvimento de software por isso foi cunhado e passou-se a usar o nome o termo engenharia de software que hoje nós costumamos chamar da engenharia de software tradicional mas na época era simplesmente engenharia de software então a ideia era olha vamos fazer um planejamento cuidadoso se se faz isso em outras engenharias por não em software vamos cuidar

cuidar de qualidade a gente precisa pensar de uma forma formal sistemática com qualidade vamos pensar em métodos não vamos fazer a coisa assim sem mais nem menos senta no computador e programa A gente precisa pensar ter métodos de análise e design ferramentas que apoiem né no caso ferramentas computacionais que apoiem foi aí que surgiu o termo ferramentas cas que são usadas até hoje que são que é a Eng Aria de software apoiada por computador a o próprio computador ajudando a desenvolver software software que ajude a desenvolver software e também ter um processo de desenvolvimento de

software rigoroso e controlado então percebam que você ter um modelo um processo de desenvolvimento de software rigoroso e controlado foi para resolver um problema não foi para criar um problema foi para resolver um problema que na época não se fazia software com qualidade na época software gastava muito para desenvolver software gastava muito não fazia no tempo adequado não satisfazia o cliente e Ah enfim você tinha uma série de problemas então foi a forma que se pensou para poder colocar ordem na casa e teve um sucesso relativo naquela época isso funcionou por um determinado tempo Ok

eh eh então isso funcionou principalmente porque houve uma série de de sistemas que eram de grande porte eram sistemas críticos por exemplo sistemas aeroespaciais pro governo então sistemas militares né Pensando principalmente por exemplo Governo dos Estados Unidos eh Nasa por exemplo ah sistemas que eram para durar por bastante tempo então valia a pena você gastar tempo se planejar bem fazer uma coisa com bastante qualidade ah sistemas que por por isso você precisava que ele pudesse ser fácil de manter porque ele ia durar por bastante tempo Então imagina um sistema bancário que você não pode ficar

mudando a todo momento ele é para ficar lá por muito tempo funcionando ah grandes empresas desenvolvendo esses sistemas até mesmo diferentes empresas desenvolvendo o mesmo sistema grandes equipes trabalhando inclusive eh equipes que não estão localizadas no mesmo local em cidades diferentes até mesmo em países diferentes inclusive sistemas que ficaram em desenvolvimento por até 10 anos justamente porque por conta de todo esse cenário aqui tá Então essa engenharia de software tradicional ela funcionou ela servia ela foi criada pensando nesse contexto e ela funcionou O que aconteceu é que por volta do ano 2000 2010 um pouco

antes do ano 2000 o que aconteceu mudou o cenário globalização internet mais pra frente celular smartphone o tipo de software que surgiu foi um software diferente um software mais eh com com um ciclo de vida muito mais curto um software que você desenvolve rápido coloca no celular ok tô falando mais recente ainda né mas um software que você disponibilizava na internet e que logo você precisava jogar fora e construir um outro Ah enfim são softwares Ah mais efêmeros que você tem tem um ciclo de vida muito rápido o o o mercado muda muito rápido o

mercado é muito dinâmico Ah você precisa rapidamente alterá-lo ou até mesmo substituí-lo então os software são menores as empresas que desenvol desenvolvem são menores com isso mudou a o cenário isso não significa que o cenário anterior não não existe mais isso não significa que você não tem mais esse cenário aqui você tem você ainda tem Empresas Grandes Você ainda tem sistemas críticos e isso aqui tudo tem você tem um novo cenário tá Ah então nesse novo cenário novas oportunidades surgem todo dia novos mercados Novos Produtos novos concorrentes eh e por isso ess esses software esses

sistemas precisam ser desenvolvidos rapidamente e com muita agilidade eh E com isso o tempo às vezes é mais importante do que qualidade você ter um sistema feito muito rapidamente às vezes às vezes nem sempre é mais importante do que esse sistema ser ter qualidade esses requisitos em geral são muito instáveis mudam muito mais rapidamente do que se mudava antes eh os requisitos iniciais eles mudam é difícil você saber exatamente quais eram os requisitos no início é difícil saber como que o sist tem que interagir com outros sistemas Como que o usuário vai realmente querer operar

o sistema Ah enfim é é é um outro cenário e que para isso a agilidade é um ponto muito importante você tem empresas menores de médio e pequeno porte embora você ainda tenha as empresas grandes elas não morreram obviamente que não tá então o que nós chamamos de processos pesados que é a engenharia de software tradicional causa um overhead muito grande então se você tentar aplicar esses sistemas Eh esses processos tradicionais os chamados processos pesados nesse tipo de ambiente Você vai gastar muito tempo planejando e pouco tempo desenvolvendo isso não é aceitável isso não é

razoável tá E esse é o argumento Essa é a motivação que as pessoas os desenvolv edores ali Por volta do ano 2000 pararam falaram isso não tá funcionando para esse contexto Isso não funciona Ok então ainda ali no final da década de 90 os desenvolvedores propuseram os processos mais leves em contra eh para para contrabalancear o que foi chamado dos processos pesados e eles ficaram então chamados de métodos ágeis então Eh basicamente o o o o o divisor de água foi em 2001 com o chamado Manifesto ágil Manifesto ágil que é o que está reproduzido

em traduzido pro português aqui Então esse foi o Manifesto ágil Assinado por um conjunto de desenvolvedores dizia eh Estamos descobrindo maneiras melhores de desenvolver software fazendo nós mesmos e ajudando outros a fazerem mesmo através deste trabalho passamos a valorizar individos e interações mais do que processos e ferramentas mas é valorizar E não é tratar apenas isso e parar de tratar isso então um erro que é muito comum você perceber quando você fala com defensores atuais de métodos ágeis é esquece process esquece ferramenta porque o só tem que tratar indivíduo e interação mesmo Vale pros quatro

aqui tá na verdade isso não é verdade a ideia é você valorizar mais uma coisa do que a outra porque você não quer ter um overhead em cima disso aqui OK mas ninguém disse que você tem que esquecer aquele lado direito e se preocupar com o lado esquerdo inclusive olha ou seja mesmo havendo valor nos itens à direita ou seja eles entendem haver valor aqui mas valorizamos mais os itens à esquerda mas enfim Quais são os itens né então mais indivíduos e interações do que processos e ferramentas mais software em funcionamento do que documentação abrangente

mas documentação ainda é necessário claro que o software em funcionamento é melhor mais colaboração com o cliente do que negociação de contrato então eles preferem conversar Face a Face com o cliente do que ficar escrevendo o contrato ah embora o contrato para empresas grandes sistemas grandes é muito importante qual que ninguém vai dizer que não responder a mudanças mais do que seguir um plano então não adianta ter um plano e se apegar a ele se você não conseguir responder as mudanças enfim eu acho que vocês são maduros suficiente para ler esse manifesto e entender exatamente

o que eles querem dizer com isso e é importante que vocês consigam entender e não se apegar apenas a parte que parece ser mais interessante do tipo ah muito mais legal a gente fazer só isso e esquecer da parte chata porque convenhamos é uma parte chata burocrática mas em geral ela é necessária bom exemplos vocês já devem ter ouvido falar desses exemplos né O que a gente tá mais em voga atualmente é o scrum mas ele é mais voltado paraa gestão do projeto menos técnico mas também tem uma parte técnica mas é mais a gestão

do Projeto um pouco mais técnico talvez é o XP o extreme programming ou a programação extrema também um pouco técnico eles misturam muito parte técnica e a parte de gestão mas uma parte também um também um pouco conhe bastante conhecido é o tdd que é o test driven development desenvolvimento orientado a teste esses três eu tenho quase certeza que eu posso afirmar que são os mais conhecidos os mais usados atualmente mas outros foram eh surgiram ah pelo menos no Brasil eu acho que eles não são tão usados pelo menos na percepção que eu tenho e

nas leituras que eu faço e com as pessoas que eu converso ah na próxima aula eu vou falar um pouco sobre o XP e um pouco menos sobre o scrum e no material que eu vou deixar de leitura para vocês eh é falado sobre os dois bom e ainda um pouco sobre os princípios gerais de métodos ágeis que em teoria todos esses deveriam seguir nós temos principalmente o que todos eles deveriam seguir o envolvimento com o cliente uma entrega incremental pessoas e não processos aceitar mudança e manter a simplicidade é muito baseado em você tratar

essa parte da esquerda aqui e não a da direita principalmente tá Então olha só envolvimento do cliente os clientes devem estar intimamente envolvidos eh no processo de desenvolvimento ou seja o cliente tem que estar sempre ali ou quase sempre ligado com a equipe de desenvolvimento não mais aquela ideia de que o cliente chega disse o que quer vai embora chega no final você vai lá e fala cliente toma é isso e o cliente fala ah não era bem isso claro que eu exagerei né dificilmente isso acontece eh e aí eles exageram pro outro lado dizendo

quem quem quem trabalha defende muito métodos argens e exagera pro outro lado qu é que o cliente fica 8 horas por dia trabalhando junto com vocês então nenhum dos dois exageros funciona e é claro que a gente precisa sempre de um meio-termo razoável claro que o métodos ágeis vai pedir um pouco mais de envolvimento do cliente do que a engenharia tradicional pede consegue eh até porque senão a gente vai dizer que são as mesm que Ambos são a mesma coisa e claro que não são a mesma coisa mas enfim aqui então a gente quer um

envolvimento maior com o cliente ah entrega incremental o software é desenvolvido em incrementos com o cliente especificando os requisitos para serem incluídos em cada um o rop que eu mostrei para vocês já prega isso também o hop Já é masiado em outros modelos que já pregavam isso também mas os métodos ágeis tentam levar isso levar isso ao extremo então a diferença é basicamente isso métodos ágeis tentam eh fazer incrementos ainda mais rápido rapidamente Se o se o rup pensa em incrementos a cada 2 3 meses os métodos ágeis pensam em incrementos a cada uma duas

semanas então basicamente Essa é a diferença agora a ideia de incrementos já existia antes Ok então percebam que os métodos ágeis Na verdade o que eles estão tentando fazer é levar ao extremo ideias que já existiam antes não são ideias basicamente novas então pessoas e não processos habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritivos bom desenvolver eh habilidades ninguém vai dizer que a gente na engenharia de software tradicional não quer desenvolver e reconhecer habilidades da equipe talvez eh a enfim não

dá para dizer que não agora aqui tudo bem membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritivos você tá dando uma liberdade maior para eles trabalharem e na engenharia de software tradicional sim é fato busca-se que se trabalhe de uma forma mais mas existe uma série de argumentos para isso no sentido de que empresas maiores processos maiores sistemas mais críticos eh pensando em nesse tipo de cenário você tem que ter um controle maior existem prós eas livros artigos que estudam as duas coisas pessoas especialistas não tem não temos tempo de discutir

e nem é objetivo aqui a gente trabalhar esses dois lados ok aceitar mudanças deve-se ter em mente que os requisitos dos sistemas vão mudar por isso projete o sistema de maneira a acomodar essas mudanças realmente na engenharia de software tradicional Mudanças são um problema embora tente-se trabalhar com elas lá também de novo aqui tem o objetivo é trabalhar de uma forma ainda melhor com essas mudanças e manter a simplicidade focalize a simplicidade tente ser o mais simples possível tanto do software a ser desenvolvido quanto do processo de desenvolvimento A ideia é não complicar se você

pode simplificar bom mas há as críticas H as limitações é claro existem uma série inúmeros casos de sucesso com métodos ágeis eh embora também existam as críticas e as limitações Como eu disse sempre tem os dois lados algumas dificuldades algumas limitações o cliente por definição deve estar disposto e capaz de passar o tempo com a equipe de desenvolvimento e existem clientes que querem trabalhar no método tradicional ele quer chegar e dizer o que eu quero isso isso isso isso isso isso e isso por favor desenvolva eu tô pagando Ok faça e ele Ah mas você

tem que ter algum representante seu aqui não é impossível enfim ele pode não entrar em acordo com esse método de desenvolvimento é um fato Existem relatos Ok Talvez seja a minoria mas Existem relatos o cliente deve ser capaz de representar todas as partes interessadas ok que vá um dois representantes do cliente trabalhar com a equipe de desenvolvimento mas ele vai ser capaz de representar a organização como um todo que vai usar aquele software membros da equipe podem não ter a personalidade adequada uma pessoa que pensa de uma forma mais tradicional e trabalha no desenvolvimento de

software ela pode ter uma dificuldade em se adequar a essa nova forma essa esse novo paradigma de desenvolvimento de software isso pode ser um problema ela pode não se adequar enfim existem formas de lidar com isso e de pensar a respeito disso só estou apontando aqui uma dificuldade uma limitação uma crítica relatada E como sempre formas de lidar com isso existem formas de de pensar a respeito disso a organização Pode não ter a cultura adequada a organização como um todo pode ser muito tradicional a gerência alta gerência a diretoria pode olhar para aquilo e falar

assim não aqui isso não vai funcionar isso por enquanto aqui não vamos ter que a as pessoas que são entusiastas dessa ideia vai ter que ir comendo pelas bordas vão ter que ir comendo pelas bordas ah priorizar mudanças pode ser extremamente difícil principalmente se há muitas partes envolvidas ah manter simplicidade que é um dos objetivos um dos princípios pode ser complicado às vezes é mais fácil deixar complicado do que simplificar eh e uma coisa interessante você pode ter dificuldade em negociações contratuais porque às vezes por exemplo se você for desenvolver um software para um para

um governo você tem que deixar tudo Claro a especificação de uma forma muito completa eh através de um contrato e isso não é previsto num método ágil ah e também depende da maturidade dos desenvolvedores em geral desenvolvedores Júnior tem mais dificuldade em lidar com essa liberdade com essa flexibilidade Ah bom enfim comparando os dois um método tradicional que também é chamado baseado em plano porque você tem que planejar muito especificar muito você tão Então você tem então é essa etapa eh intermediário de especificação que você não tem no método ágil você basicamente levanta os requisitos

de uma forma fácil e já vai projetar e implementar aqui no método tradicional Você tem os requisitos passa por uma atividade considerada pesada de especificação de requisitos para depois você planejar e implementar então vocês lembram do modelo em Cascata que você faz o requisito projeta implementa integra e opera é como se pensando em métodos ágeis você pegasse tudo isso aqui e jogasse para dentro da implementação e teste e a implementação e teste incorporasse tudo isso Você acaba de uma certa forma não tendo muito mais aquele papel formal de analista de requisitos de projetista de banco

de dados de proje de arquiteto de software de projetista de de de interf fácil porque basicamente você vai ter desenvolvedor implementador você vai ter a equipe de implementadores de desenvolvedores basicamente fazendo isso tudo de uma forma integrada e única a ideia ela é muito eh parecida com isso num nível mais abstrato bom isso é uma visão bastante Ampla bastante geral eh tentando mostrar a motivação mostrar a evolução porque as pessoas chegaram a impr propor os métodos ágeis basicamente de uma forma muito simplificada quando ela poderia ser usada quando ela poderia não ser usada Há controvérsias

há quem defende muito há quem fica com quem fique com o pé atrás quem defende que em determinados cenários é o melhor é a melhor solução quem defende que em outros cenários não é apropriado quem defende que sempre é apropriado é só você aplicar da forma melhor em cada caso enfim não foi meu objetivo aqui nem criticar demasiadamente nem defender eh em todos os casos mas apenas apresentar para aqueles que ainda não tinham tido um contato com a ideia de métodos ens E aí fica a critério de vocês e ler procurar entender e formar a

opinião própria de cada um de vocês [Música] obrigado [Música] [Música] [Música] k [Música] Y