Introdução aos Processos Ágeis

Olá sejam bem-vindos ao canal engenharia de software com ênfase ml Eu sou professor Janes getes e eu já atuo na área de modelagem de software H vários anos eu tenho quatos publicados sobre o assunto e eu já administrei diversas palestras e cursos técnicos utilizando a linguagem uml para modelagem de software na aula de hoje eu vou darid ao tema sobre processos de desenvolvimento de software dessa vez introduzindo os processos ágeis Então vamos iniciar a nossa aula bom eh no final dos anos 90 início dos anos 2000 um conjunto de profissionais da área de engenharia de

software e desenvolvimento de de software se reuniram e trocaram as suas as suas impressões as suas experiências com relação ao desenvolvimento de software e aos processos de desenvolvimento em vol na época e eles chegaram a algumas conclusões então eles fizeram um Manifesto nesse Manifesto eles diziam que estavam descobrindo melhores formas de desenvolver software produzindo software e ajudando outras outras pessoas a fazer software então eles chegaram aos seguintes valores indivíduos e interações estão acima de processo e ferramentas software funcionando está acima de documentação compreensível colaboração do cliente está acima de negociação de contrato responder às mudanças

está acima de seguir um plano é importante destacar Todavia que embora os valores da esquerda sejam mais considerados os valores da direita não são desprezados não são descartados Eles continuam tendo valor apenas a prioridade maior é a dos valores da esquerda bom ah juntamente com o Manifesto ágil se produziu os 12 princípios ágeis que na verdade nem sempre são fáceis de seguir mas eu vou falar sobre eles então o primeiro princípio satisfazer o cliente através da entrega rápida e contínua de software com valor agregado é prioritário Então se destaca que os métodos ágeis eles são

iterativos e incrementais mudanças nos requisitos são bem-vindos mesmo nas etapas finais do projeto processos ágeis usam a mudança como um diferencial competitivo para o cliente na verdade esse segundo princípio ele nem sempre é fácil de seguir mudanças nos requisitos Na minha opinião não são bem-vindas os processos ágeis Eles são muito mais flexíveis a mudanças que os processos clássicos isso é verdade mas às vezes H mudanças nos requisitos itos podem ser bastante difíceis de adaptar elas podem ser custosas em tempos de em termos de custo de desenvolvimento cronograma esse tipo de coisa então não é um

princípio muito fácil de seguir em alguns momentos em algumas situações é preciso uma certa negociação com o cliente e principalmente é necessário priorização de requisitos para determinar Quais são os requisitos essenciais do software para ter um mínimo produto viável a ser entregue ao cliente Em algumas situações terceiro princípio entregar software funcionando frequentemente com intervalos entre duas semanas a 2 meses sempre preferindo o prazo mais curto quarto princípio pessoas envolvidas com o negócio e os desenvolvedores devem trabalhar juntos diariamente durante o desenvolvimento do projeto Esse princípio também não é muito fácil de ser seguido eh para

algumas empresas eh destacar usuários Chaves partes interessadas importantes que T conhecimento sobre determinado departamento determinado processo às vezes é bastante inviável às vezes impossível porque tem um custo proibitivo uma vez que a empresa depende muito desse tipo de profissional então às vezes tem um envolvimento integral de partes interessadas no processo de desenvolvimento é bastante difícil quinto princípio construa projetos em torno de indivíduos motivados dê a eles o ambiente o suporte necessário e confie neles para fazer o trabalho sexto a conversa Face a Face é o método mais eficiente e eficaz de transmitir informações para e

entre uma equipe de desenvolvimento sétimo princípio software funcionando é a medida primária de progresso oito oitavo processos ágeis promovem desenvolvimento sustentado Então os financiadores os usuários os desenvolvedores eles precisam ser capazes de manter um ritmo constante indefinidamente nono princípio atenção contínua a excelência técnica e bom projeto melhora a agilidade isso é um isso é um princípio excelente mas é preciso muito profissionalismo para conseguir mantê-lo às vezes é preciso não ser capaz de não não não sacrificar Esse princípio em razão de cumprir o cronograma nem sempre isso é fácil por causa da pressão do cliente simplicidade

essencial então sempre tentar manter o código simples utilizando boas práticas de desenvolvimento e também não desenvolver o que não é necessário então eles pregam a arte de maximizar a quantidade de trabalho não feito a simplicidade também é um princípio muito bom B Mas não tão fácil de seguir quando os prazos são curtos às vezes no afã de seguir o cronograma no afã de atender o cliente rápidamente essa simplicidade pode ser sacrificada e isso vai ter um custo no futuro quando for necessário manter ou evoluir o software 11º princípio os melhores requisitos arquiteturas e projetos emergem

de equipes auto-organizadas 12º a intervalos regulares a equipe reflete como sobre se tornar mais efetiva e refinar e ajustar o seu comportamento de acordo então a equipe tenta sempre melhorar profissionalmente e o próprio processo de software pode ser melhorado isso é bom é um bom princípio esse 10º segunda bom eh continuando algumas características dos processos ágeis então ele deve produzir software funcionando rapidamente como falei ele são interativo incrementais Isso significa que ah os requisitos vão ser divididos em várias interações e a cada interação novas funcionalidades serão desenvolvidas ou funcionalidades desenvolvidas anteriormente serão melhoradas refinadas refatorado

evoluídas ã outra característica os processos ágeis preconizam uma forte participação das partes interessadas como eu falei isso nem sempre é possível de conseguir e uma outra característica é que embora tenham muito valor o gerenciamento planejamento e documentação possui uma prioridade uma que a do código funcionando mas é importante destacar não significa que gerenciamento planejamento e documentação sejam desprezadas apenas a prioridade maior é com relação ao código funcionando eh falar um pouco sobre os requisitos nos processos ágeis então os os Defensores dos processos ágeis defendem que os requisitos muitas vezes em geral eles são instáveis ou

seja eles mudam muito devido ao dinamismo das empresas às quais eles se destinam então muitas vezes pode acontecer de um requisito ser simplesmente descartado ao longo do desenvolvimento software ele passa a não ser mais útil não ser não ter mais validade em outros casos o requisito pode mudar muito e ainda outros requisitos podem surgir ao longo do desenvolvimento Então os os Defensores dos processos ágeis defendem que adotar um processo prescritivo ou orientado a planos acaba em algumas situações levando a entrega de um software que na verdade já se encontra desatualizado com requisitos já não não

valendo mais ou que tenham sofrido muitas mudanças e é necessário fazer muitas adaptações Ah agora Eu costumo falar que processo de desenvolvimento não é a mesma coisa que time de futebol não existe o processo Favorito processo do coração não existe o processo melhor que o outro existem processos mais adequados a determinadas situações então em situações que dependem vidas humanas o software ele pode causar grandes prejuízos em termos de segurança em termos de ambiente em termos econômicos um software que é muito complexo e que exige muito planejamento e documentação e que se vai levar muito tempo

desenvolvendo desenvolvendo às vezes é mais adequado adotar um processo prescritivo para esse tipo de situação já quando os requisitos apresentam características de que são muito instáveis que eles podem mudar ao longo do desenvolvimento então processo interativos incrementais ou processos ágeis podem ser mais adequados Ah vou falar um pouquinho sobre os problemas na adoção de processos ágeis isso foi baseado principalmente no summerville no livro de engenharia do software do Ian summerville Ah mas não totalmente bom então primeiro problema envolvimento constante do cliente das partes interessadas como eu falei anteriormente isso não é fácil em algumas empresas

isso é proibitivo é quase que impossível porque o custo é muito alto e as empresas dependem muito de certos profissionais existem profissionais que dominam muito um processo dominam muito um determinado tem muita experiência com determinado departamento como fazer as coisas acontecerem e a empresa simplesmente não pode prescindir desse tipo de pessoa por tempo integral elas precisam desse profissional Elas têm um custo muito alto para a empresa e são muito importantes para ela então muitas vezes esses profissionais eles são quase que insubstituíveis a empresa precisa deles e não pode dispensar eles para trabalhar 24 horas tempo

integral com a equipe de desenvolvimento simplesmente é inviável então Esse princípio às vezes não pode realmente ser cumprido um outro princípio um outro problema membros da equipe podem não possuir o perfil adequado para o tipo de movimento Que processos ágeis exigem processos ágeis prescrevem uma integração em equipe muito alta e alguns perfis alguns profissionais não têm o perfil para isso então simplesmente alguns profissionais podem não conseguir se adaptar a esse tipo de integração em equipe mudanças podem não ser bem-vindas esse é o terceiro problema os métodos ágeis eles preconizam que Mudanças são bem-vindas acontece que

na minha experiência mudanças não são bem-vindas na maioria das vezes mudanças sempre causam Impacto mudanças sempre causam problemas elas são elas são bem-vindas no sentido que elas vão ajudar a desenvolver um software que realmente atenda as necessidades do cliente e nesse ponto é correto elas devem ser eh aceitas mas eh bem-vindas muitas vezes elas não são Porque dependendo da mudança que essas esses requisitos sofrem o impacto no no custo do projeto pode ser muito alto então principalmente se essas mudanças afetam a arquitetura se a arquitetura for afetada Às vezes o projeto tem que ser quase

que começado de novo então o custo pode ser muito grande Qual é a alternativa para esse tipo de situação é priorização de requisitos Como já falei é bom utilizar técnicas de priorização como a Moscou para identificar Quais são os requisitos essenciais que sem eles o software não é válido pro cliente os requisitos desejáveis que seria muito bom que o software suportasse mas que em uma em último caso pode ser Deixados para uma segunda versão e os requisitos opcionais que são opcionais que acrescentam mas acrescentam pouco e se são serão desenvolvidos só sobrat tempo e mais

importante os requisitos que não serão desenvolvidos é importante identificar os requisitos que estão fora do escopo e já avisar o cliente que eles não serão desenvolvidos E então não não deixando ele ter falsas expectativas simplesmente dizer para ele esse requisito está fora do escopo desse projeto faz parte de um outro software não será desenvolvido nesse momento então em situações em que a mudanças muito radicais é necessário negociar com o cliente e explicar olha essas mudanças serão adaptadas mas isso vai causar um impacto muito forte no nosso projeto então requisitos outros requisitos terão que ser sacrificados

Aqui nós temos a lista dos requisitos que podem ser sacrificados deixados por uma segunda versão e nós podemos manter os requisitos essenciais por exemplo os requisitos que Ao serem desenvolvidos entregam um mínimo produto viável para o cliente é importante saber negociar nessas situações priorizar mudanças muitas vezes não é uma tarefa fácil é um outro problema bom as mudanças ocorrerão Isso é uma realidade Mas acontece queem sistemas grandes eu posso ter muitas partes interessadas E essas partes interessadas podem ter interesses diferentes então elas podem querer ser atendidas primeiro e isso pode gerar conflitos que não são

bem fáceis de resolver existem pessoas que não são suficientemente maduras para ceder ou para negociar isso não é tão fácil então priorizar as mudanças pode ser problemático eh algumas as partes interessadas podem não gostar de serem eh deixadas para um segundo plano em relação a outras por exemplo Então aqui tem um fator humano bastante difícil de resolver existem técnicas de negociação que podem ser aplicadas mas negociação com partes interessadas às vezes não são difíceis Principalmente quando a as pessoas têm egos bem alimentados o que às vezes é comum quinto problema manter a simplicidade do código

não é fácil para manter a simplicidade do código eu tenho que aplicar boas práticas de engenharia de software boas práticas de desenvolvimento seguir padrões de codificação tentar evitar ma cheiros trabalhar com inspeções e estar constantemente refatorando o código e isso eh É vantajoso a longo prazo principalmente com relação à manutenção quando os requisitos precisarem ser alterados agora o problema é o cronograma e a pressão do cliente às vezes quando o cronograma Está curto e o cliente pressiona muito essa simplicidade pode ser sacrificada em razão da entrega rápida de código organizações com processos rígidos e bem

definidos é um mais um problema ah algumas organizações existem há vários anos e passaram muito tempo eh se dedicando a definir processos prescritivos com passos bem definidos e treinando seus funcionários para isso então adotar um processo ágil nesse ambiente pode encontrar uma forte resistência dos funcionários mais antigos contratos de desenvolvimento Esse é o sétimo problema às vezes eles podem ser problemáticos antigamente ou com relação a outros tipos de processo o documento de especificação de requisitos estabelecia a base para o a criação de um contrato de desenvolvimento Ah agora num processo que é Interativo incremental em

que os requisitos vão sendo entre em ciclos e podem sofrer muitas mudanças ao longo do processo de desenvolvimento e outros requisitos podem surgir Esses contratos eles ficam um pouco mais difíceis de serem eh escritos então alguns contratos passam a estabelecer o tempo necessário para desenvolver o software só que nem sempre isso é fácil eh estimar o tempo de desenvolvimento é bastante complexo existem técnicas para isso mas é sempre uma estimação às vezes existe uma uma uma aliás uma estimativa desculpe às vezes existe uma complexidade maior nos requisitos que não foi prevista e às vezes requisitos

sofrem muitas mudanças então o tempo de desenvolvimento é extrapolado o cronograma é extrapolado então aí é necessário uma negociação com o cliente que nem sempre é fácil às vezes o cliente não está disposto a pagar a mais do que estava estabelecido porque Houve atraso no cronograma então de novo é importante a priorização dos requisitos e negociar quais requisitos deixarão de ser desenvolvidos continuidade da equipe e documentação bom os processos ágeis não é que eles sejam contra documentação Eles apenas não gostam de documentação burocrática documentação que eles consideram inútil eles eh acham que a documentação ela

só é importante Se ela ajudar a compreender o problema ou ajudar a solucionar o problema e muitos processos ágeis afirmam que a equipe deve ser capaz de compreender alguns aspectos do software sem precisar consultar documentação porém se acontece da equipe sofrer mudanças que parte dos membros da equipe saírem da saírem serem transferidos para outr para outros projetos ou simplesmente pedirem demissão então muito do conhecimento inerente conhecimento implícito que já havia sido produzido entre a equipe ele é perdido e quando novas pessoas forem contratadas forem inseridas na equipe elas precisam de documentação para que possam se

enterar do que já foi feito dos objetivos do só esse tipo de coisa então às vezes é necessário produzir documentação E então nós terminamos essa breve introdução aos processos de desenvolvimento ágil ágeis aliás eu agradeço a atenção de vocês eu espero que esse conteúdo tenha sido tenha sido útil ah se vocês gostaram desse conteúdo eu peço que vocês curtam esse vídeo que compartilhem com quem possa ter interesse nele e se não se inscreveram ainda eu peço que se inscrevam obrigado pela atenção