Engenharia de Software - Métodos de desenvolvimento ágeis

E aí [Música] o Olá eu sou o professor Marcelo Fantinato Essa é a disciplina de engenharia de software e Nesta aula nós vamos falar sobre métodos de desenvolvimento ágeis em aula anterior nós falamos sobre a engenharia de software de uma forma geral e depois Mais especificamente sobre os modelos de processo de software em que nós vimos Quais as atividades que devem ser executadas para se desenvolver um software e Mais especificamente ainda é sobre como Essas atividades são organizadas em que ordem elas devem ser executadas seguindo alguns modelos desde o modelo original em Cascata passando pelo

modelo por modelos e iterativos incrementais e também baseados em rios Olá a todos esses que nós vimos em aula anterior eles compartilham as características de serem modelos conhecidos como engenharia de software tradicional ou então engenharia de software baseada em planos em que a especificação ela é bastante grande e você tem um trabalho bastante grande com a modelagem com especificação um documentação é para subsidiar o trabalho da implementação da codificação propriamente dita Mas é em paralelo também Existem os métodos de desenvolvimento conhecido como ages né O que esse nome ele já diz né para tentar dar

mais agilidade ao ciclo de desenvolvimento de software é entendendo que os métodos de engenharia tradicionais eles são lentos vou te incomo uma das críticas da engenharia de software é problema com o tempo que se demora demora sipar é entregar um software então foram propostos os métodos de desenvolvimento ágeis basicamente por volta dos anos 2000 muitos de vocês já devem ter ouvido falar outros até já devem usar é e essa aula então nós vamos falar um pouco né uma visão geral sobre os métodos de desenvolvimento ágeis é começando com histórico que basicamente eu já resumi aqui

mas sendo um pouquinho mais é específico Então por volta ali dos anos2000 é que a por volta dos anos 2000 é que e a engenharia de software ágil surgiu porque a o quê lá no início lá a 50 anos com houve a crise de sorte porque não existia método nenhum não existia processo nenhum e então a solução foi desenvolver métodos processos baseados em outras engenharias e aquilo resolveu o ajudou muito não dá para dizer que resolveu tudo mas ajudou muito mas aí da década de 70 até o final da década de 90 início do Novo

Milênio nos anos 2000 o que acontece mudou muita coisa do ponto de vista é de da indústria de software por exemplo os ambientes corporativos é passaram a ser menores de médio e pequeno porte então assim começou a surgir empresas menores e menores e mais recentemente ainda está de a costa enquanto antes grande as empresas desenvolver um software para grandes empresas passou se até Pequenas Empresas desenvolvendo software para pequenas empresas é isso foi uma diferença bastante grande a os processos baseados em planos né que é a engenharia de software tradicional causam muito ver Rede né você

acabava exemplo acaba executando uma série de atividades que causam over head você de você gasta tempo em atividades que não são de implementação propriamente dito eu ligasse também muito com planejamento análise comparativamente com a implementação e o teste e como resultado ali no final da década de 90 os desenvolvedores né que a gente pode dizer os programadores é Mais especificamente propuseram processos mais leves né entendendo que os processos em uso no momento eram processos mais pesados e esses ficarão chamadas então de métodos ágeis com o objetivo de produzir rapidamente softwares úteis por meio de implementos

é enquanto um cada incremento incluindo novas funcionalidades então a ideia de ter implementos ela não é nova nós vimos alguns modelos de processo na aula anterior que é baseado em ir oferecendo implementos mas ainda assim altamente baseado impo a especificação em cada incremento ainda teria que ter muita planejamento muito especificação a ideia aqui é que além de ser baseado em incrementos sem muita especificação bom então vejam né a diferença aí do modelo do processo de engenharia de software dirigida por planos e age é aqui na de cima nós temos a o dirigido por plano se

você tem a engenharia de requisitos que gera a especificação de requisitos para a partir dela se realizar o projeto EA implementação Essa é a visão tradicional da engenharia de software é tradicional no desenvolvimento ágil você vai dar engenharia de requisitos diretamente para o projeto e implementação sem aquela etapa aqui do meio em que você gera a especificação de requisitos você gera uma documentação bem detalhada e especificando os requisitos então a ideia você ganhar tempo desenvolvendo um software sem gastar tempo fazendo uma especificação bem detalhado dos requisitos tô tentando a ainda sim claro representar bem o

software desejado com através de outras outros métodos outras técnicas que são serão vistas aqui porque a especificação de requisitos é realizada é na na engenharia do Falcão tradicional porque ela que representa que o usuário quero o teu cliente quer e aí como que isso vai ser feito no desenvolvimento ágil existem outras formas de você representar e garantir que o software está sendo desenvolvido da forma como cliente quero bom é a então lembrando né no no no modelo de processo base dirigido por planos naquele bem tradicional né que é o Cascata nós temos atividade por atividade

feita em bloco A e podendo voltar eventualmente para fazer alguns ajustes então desde lá da definição dos requisitos passando depois pelo projeto implementação e agilidade integração e testes implementação eternidade integração entre sistemas em operação e manutenção nos métodos ágeis É como se você tirar as em todas essas três etapas aqui do início do meio e Trocasse por uma única grande atividade zona que seria o projeto e implementação projeto implementação e teste perto então aquelas três atividades você faz em uma só de uma forma mais Age de uma forma mais rápida e essa é a ideia

do método ágil a conta um pouquinho mais história isso foi formalizado lá em 2001 quando foi para o posto foi foi publicado o Manifesto ágil O Manifesto ágil ele diz o seguinte né é um documento que foi proposto por um conjunto de desenvolvedores em que eles é Estamos descobrindo maneiras melhores de desenvolver software fazendo os fazendo o nós mesmos e ajudando outros a fazerem o mesmo Então veja um grupo de desenvolvedores publicou esse documento dizendo Olha nós estamos descobrindo maneiras melhores de desenvolver software é a gente pode fazer ainda melhor do que já tem sido

feito e com isso a gente tá melhorando e a gente quer ajudar os outros também a melhorar atravesso neste trabalho nós estamos valorizando os indivíduos e interações mais do que processos e ferramentas então vejam a engenharia de software tradicional valoriza muito processos que devem ser seguidos e ferramentas a serem usadas e eles passaram a valorizar mais as pessoas e as interações entre as pessoas e é valorizar mais o software em funcionamento do que do que tem uma documentação abrangente então a engenharia de software tradicional valoriza muito você como documentar bem o que você está sendo

o que você está fazendo eles valorizam mais ter o software em funcionamento valorizam a colaboração com o cliente mas do que negociação de contratos Então em vez de ficar negociando muito contrato né é colaborar com o cliente trazer o cliente para dentro do ciclo de desenvolvimento e responder às mudanças mais do que seguir um plano então a engenharia de software tradicional ela disse você tem que planejar e seguir esse plano o grupo aqui que propôs essa esse Manifesto ágil disso a gente tem que conseguir responder às mudanças em vez de seguir cegamente um plano nós

temos que estar prontos para reagir às mudanças durante esse plano ou seja replanejar alterar o quando for necessário e essa parte em amarelo é o que eles estão valorizando mais do que a parte em branco agora veja mais e não descartando toda a parte em branco tá então isso é uma uma falha comum em pessoas que passam a querer usar os métodos ágeis que entender que estamos usando a valorizando indivíduos e interações e descartando os processos e ferramentas não Eles não estão descartando Ele só não estão dando tanta ênfase então eles só estão tentando rebalancear

a as coisas colocando mais peso em um e menos peso no outro mas não descartando certo e é ou seja mesmo havendo valor nos itens à direita valorizando mais os itens à esquerda que foi esse final comentário final do que eu fiz bom E aí eles é também apresentaram um conjunto de princípios para os métodos Ases porque os métodos Lages existem vários métodos a gente não existe você você não trabalha com a eu sigo um método ágil qual o método Lógico que você segue mas independentemente de qual método ágil esses métodos ágeis deveriam seguir esses

princípios esses cinco e princípios básicos aqui para que seja considerado um método ágil Então veja só envolvimento do cliente o cliente tem que estar envolvido durante o ciclo de desenvolvimento o cliente não pode ser o que tradicionalmente se fale fazia na engenharia de software tradicional cliente vai lá de Olha o Faustão que eu quero é esse passa tantos meses vou sei lá quanto tempo e o a empresa chama o que a gente fala toma o seu software certo e aí os cliente falar não era bem assim que eu queria Então para evitar esse tipo de

problema os métodos ágeis pedem que a o cliente se envolva esteja diretamente envolvido até mesmo muito desse dos métodos coloca o cliente trabalhando junto na equipe diariamente Essa é uma das formas de evitar a necessidade de escrever aquele documento de especificação de requisitos porque é a partir do documento de especificação de requisitos que você manda para o cliente para o cliente validar e de ver se tem problemas ou não se o cliente está junto com você você pode abrir mão desse documento Então veja você tá abrindo mão de uma coisa mas você tá tendo que

por outra para compensar que você tá abrindo mão de uma documentação detalhada Que costuma ser enviado para o cliente mas você tá tendo que ter o cliente junto com você Certo acolher as mudanças é um outro é princípio E aí e a qualquer método ágil ele tem que parte do princípio de que mudança faz parte você não pode ser avesso às mudanças dos requisitos estão pediu não é porque foi pedido daquela forma que não pode mudar pode mudar durante o desenvolvimento entrega incremental o software vai ser feito de forma incremental Pedacinho por pedacinho para que

o cliente é diga eu quero primeiro essa parte depois essa depois dessa até porque a ideia é que esses pedacinhos já possam ser usados pelo cliente aos poucos para os clientes não tem que esperar o software final completo Então olha faz essa parte e já eu já ir levando manter a simplicidade então a ideia um dos princípios também é manter a simplicidade é tentar sempre desenvolver o software evitando complexidade tanto do ponto de vista do software em si quanto da forma de desenvolvê-lo né tentar seguir e técnicas e métodos que fez ah e também tentar

desenvolver um software que seja simples e por fim o último princípio é tratar mais pessoas e não processos então reconhecer as habilidades das pessoas que desenvolvem aproveitar isso da melhor forma possível em vez de forçá-las a seguir um processo que foi para definido então eu comentei que é existem vários exemplos de métodos ágeis certo e alguns desses exemplos os dois mais famosos é o Extreme programming chamado de XP foi Provavelmente o primeiro a ser criado um outro muito famoso bastante usado no Brasil que o scream que mistura um pouco desenvolvimento em gestão de projetos tem

também um que a bastante conhecido que é o tdd test driven development e outros não tão conhecidos mas também existentes e esse último aí que eu a diário e unified process que aquele é uma tradição ágil para aquele que a gente viu na aula anterior que é o rup ele faz o processo rup é o IBM rup Neo o IBM Rational unified process e esse é o WhatsApp unified process e a bom o XP como por exemplo ele segue também um modelo também existe um modelo para o XP certo é como qualquer outro processo existe

um modelo a diferença que vai dar ênfase vocês não vão ver aqui nesse modelo grandes é não vão ver atividades em que pede grandes especificações Vai forçar vai focar no na especificado na no desenvolvimento dos incrementos a o Sprint também tem um [Música] e o scream Aliás o scrum também tem um modelo para seguir tá é esse aqui são modelos genéricos cada um deles tem uma figurinha cloridim específica para eles é tô passando aqui de uma forma ilustrativa Claro que tem entender cada um deles Vocês precisam ler o material associado é para poder entender o

que cada um como que cada um deles trabalha certo mas enfim para cada um desses métodos ages existe existem regras que devem ser seguidas o material base que tanto material de base contra o material de apoio é que tá disponível na plataforma a explica esses modelos aqui na tanto os mais comuns que esses te quanto o outros menos comuns bom os métodos ages eles tem 10 lá do ano 2000 principalmente já no final da a década do de desse século e agora agora na segunda década também ganharam muitos adeptos muitas empresas crescimento das empresas de

pequeno porte têm usado muito esses modelos mas eles não são a solução para todos os problemas né E também Existem algumas dificuldades algumas limitações por exemplo o cliente Ele deve estar disposto e ser capaz de passar o tempo com a equipe de desenvolvimento se isso não for uma possibilidade você já fura um dos princípios básicos E você já vai ter problema em executar e em seguida esse modelo é o cliente deve ser capaz de representar todas as partes interessadas esse cliente não basta o cliente estar lá o cliente tem que saber o que o software

precisa ter ou seja o cliente tem que saber se o Foster ele é relativamente complexo ligarem de várias áreas de uma empresa por exemplo esse cliente ele tem que conseguir em várias áreas da empresa os membros da equipe podem não ter a personalidade adequada é normalmente pessoas mais jovens possuem uma personalidade mais adequada para trabalhar com com esse tipo de método mas não necessariamente né Isso é uma questão de personalidade em geral as pessoas mais jovens possuem mais personalidade mas pessoas - homens também podem ter é embora seja um pouco mais difícil principalmente empresas que

já trabalham com a engenharia de software tradicional há muito tempo a organização Pode não ter a cultura adequada a até porque muitas organizações gastaram muito tempo definir os processos da engenharia de software tradicional e elas podem entender que mudar agora é desperdiçar o tempo que elas gastaram isso a realizar mudanças podem ser extremamente difícil manter a simplicidade também pode ser complicado é negociações contratuais pode ser difícil também e os desenvolvedores precisam ter uma grande maturidade tá bom e é esse material é esse conteúdo está na no material base no livro de engenharia de software The

Summer viu assim como em outros materiais de apoio que estão disponíveis na plataforma é isso obrigado a [Música] E aí [Música] [Música]