Scrum // Dicionário do Programador

Oi CDF pode entrar fica à vontade esse aqui é o dicionário do programador do código fonte TV onde a cada vídeo explicamos um novo termo uma tecnologia ou até uma simples palavrinha utilizada por nós nesse Incrível Mundo da [Música] programação scrum contextualizando scrum está ligadinho à área de gerenciamento de projetos e de equipes ágeis ele é uma abordagem ágil muito utilizada por equipes de Tecnologia e vem sendo adotada já há muitos anos em outras áreas inclusive com muito sucesso Isso mesmo o nome scrum só de curiosidade surgiu por conta de um movimento feito por jogadores

de rugby é esse esporte mesmo que você tá pensando é aquele bem tranquilo Pacífico onde um jogador pode ser substituído e voltar posteriormente somente se o sangue dEle esver sido estancado Cruze gente para quem nunca viu isso aí é um scrum no rugby apesar da truculência o scrum mostra coletivismo e a integração de todos para uma jogada ser feita perfeitamente e esse meus amigos é o espírito do nosso scrum por aqui também o site oficial O scrum.org define o método scrum como um Framework em que as pessoas podem tratar de problemas complexos e adaptativos ao

entregarem de modo produtivo e criativo produtos de altíssimo valor se você está por dentro das teorias de gestão de projetos pode se dizer que o scrum é uma metodologia ágil que usa sequências de trabalho incrementais e interativas em outras palavras o scrum é um processo que ajuda as pessoas a solucionar problemas e concluir projetos com o máximo de produtividade possível e garantindo que os projetos em que trabalham tenham o maior valor possível no início o scrum era uma forma das equipes de software administrarem seus novos lançamentos mas logo se tornou um modo de trabalho que

todo tipo de equipe considera útil com o scrum sua equipe vai sempre ter conhecimento do Progresso do projeto em tempo real ao classificar as tarefas em estágios como a fazer fazendo e feito ou para quem gosta dos termos em inglês o To Do or sometimes Ready tasks whip for work in Progress and D É isso mesmo e ainda temos outras duas classificações que são importantíssimas para o scrum que são o backlog e o reveal que falaremos aí mais à frente seguindo essa linha então podemos dizer que um dos princípios fundamentais do scrum é a visibilidade

Ou seja todos na equipe devem estar cientes do que outros estão desenvolvendo Quais são as suas tarefas isso é importante para acompanhar o progresso do projeto e mostra para onde a equipe está caminhando por isso que D visibilidade a tudo é tão importante nesse processo mas o scon está muito longe de ser somente uma forma de organizar melhor as tarefas em etapas nada disso como dissemos que ele é um Framework de gestão Existem algumas regras papéis e rotinas a serem seguidas justamente para que o projeto tenha um controle e rastreabilidade uma excelente analogia que já

ouvimos por aí e e que mostra muito bem tudo isso é que a metodologia ágil pode ser considerada uma dieta para quem quer manter a saúde e o scrum Nesse contexto é a receita para que a dieta funcione Então vamos lá pessoal a ideia aqui é mostrar para vocês o quanto scrum pode ajudar realmente a sermos mais produtivos inclusive o título desse livro aqui que temos aqui em casa é o do Jeff sunderland um dos criadores do scrum é a arte de fazer o dobro do trabalho na metade do tempo dizem por aí que o

scrum é igual a pok você aprende todas as regras em 10 minutinhos Mas para ficar bom nele é preciso praticar por um bom tempo então para começarmos a desvendar o scrum propriamente dito Temos que conhecer porque ele surgiu e porque o modelo que existia anteriormente não estava mais atendendo o desenvolvimento dos projetos de softwares voltando rapidinho na história tínhamos um modelo de gestão chamado PDCA criado lá atrás na década de 20 ele tinha seu conceito talhado na melhoria contínua dos processos cada letra do PDCA representa uma ação dentro de um processo que significa em inglês

plan de planejamento do de fazer check de validação do que foi executado e finalmente act para criar os ajustes e correções necessárias e a partir daí reiniciar o processo esse ciclo do PDCA reinou durante décadas e ainda é muito utilizado e pode ser associado ao modelo de desenvolvimento Waterfall ou Cascata em português mas que já há alguns anos se mostrou um modelo em saturação o scrum na nossa visão pode ser considerado um aprimoramento desses modelos ainda mais voltados para a melhoria contínua e para o desenvolvimento de projetos de softwares nós mesmo na época da faculdade

não estudamos quase nada de ajio E aprendemos a fazer o trabalho de análise de sistemas de uma forma muito engessada baseado no modelo do PDCA Pois é e apesar de dele ser um ciclo ele era muito amplo onde a etapa do plan ou planejamento só era concluído quando todos os requisitos eram levantados e definidos era lindo isso no papel mas os requisitos em 99.9% das vezes mudavam durante o Du e o cheque e o ciclo acabava furado de alguma forma Pois é e depois de muitos projetos de softwares baterem a cabeça por conta disso O

scrone foi pensado justamente para que esse processo fosse mais curto e para que cada fim de um ciclo um entregável já esteja pronto isso Acabou mudando a visão do como os projetos eram geridos pois agora é possível conseguir um pequeno pedaço de de produto pronto e de forma constante O que é ótimo pois a cada passo dado em falso é possível voltar sem levar aquele tombo Essa é a essência do scrum porém como ela é um Framework algumas regras não muitas que devemos seguir para que tenhamos sempre o entregável que faça parte de um todo

por isso mesmo temos alguns termos que o método scr utiliza e que vamos analisar agora mesmo o dicionário do programador é uma parceria com a hostgator uma das maiores e melhores empresas de host do mundo então faça como nós mantenha seu site sempre no ar pelo melhor custo benefício acessa aí hostgator.com.br ou melhor ainda acesse o nosso link especial aqui na descrição e tenha 50% de desconto pessoal temos que ter em mente que no scr existem três somente três elementos papéis artefatos e eventos os papéis são essencialmente as pessoas a equipe E os responsáveis pela

gestão desenvolvimento do projeto e são três tipos de papéis que se pode assumir no scrum Pois é temos o product owner que é o dono do produto ou seja o responsável por ter a visão do produto como um todo ele também é o gestor dos backlogs do produto e também prioriza as necessidades e compreende as expectativas ele é o representante do cliente no projeto o scrum Master esse papel é Ultra importante podemos dizer que ele é o líder que facilita o trabalho do te scrum e e também dos demais envolvidos ele é o responsável por

não deixar impeditivos para que a sua equipe faça o trabalho e é ele também que garante que os eventos scrum sejam seguidos ou seja o scrum Master é o responsável por manter o ciclo do scrum fluindo e finalmente temos o time de desenvolvimento Esse é formado por todas as pessoas da equipe envolvidas no projeto no scrum se diz que uma equipe deve ser auto-organizada e responsável por realizar o trabalho que irá gerar a entrega da Sprint que iremos explicar aqui daqui a pouquinho a equipe é responsável por colocar a mão na massa e criar as

versões usáveis do produto o ideal é que ela tenha entre três e nove pessoas ou seja que seja uma equipe bem enxuta Lembrando que o product honer e o scrum Master não fazem parte do time de desenvolvimento falamos dos papéis agora o próximo passo é mostrar para vocês algum dos artefatos do scrum Ou seja a documentação e os elementos gráficos utilizados na metodologia fica tranquil aquilo que são poucos e fáceis de entender são eles o backlog o product backlog o Sprint backlog as histórias e o burndown o backlog é a lista de requisitos da aplicação

que será necessária para o seu entendimento e desenvolvimento o responsável por ela é o product Honor o backlog é dividido em duas partes sendo elas o product backlog e o Sprint backlog então o product backlog já é a lista de requisitos da aplicação em si nela estão contidas todas as informações pertinent ao projeto e tudo precisa ser desenvolvido para que a aplicação seja entregue E aí agora vem o Sprint backlog que é o conjunto de informações necessárias para a finalização de um Sprint ele é criado a partir de do Product backlog dentro da Sprint backlog

é que são criadas as tarefas que precisarão ser entregues no final de um Sprint temos as histórias que são um descritivo Claro e objetivo porém resumido da funcionalidade que será desenvolvida muitas vezes uma história cabe ó em um postinho por conta justamente da objetividade E aí temos que abrir um parêntese aqui para explicar como o Jeff o criador do scrum define o que é uma história no scrum nós nos acostumamos a nos organizar criando tarefas até aqui nesse vídeo mesmo acabamos dizendo coisas sobre tarefas mas é muito importante frisar que no scrum não há tarefas

e sim histórias exatamente quando listamos coisas a fazer é muito tentador criar tarefas não é verdade se você vai organizar uma festa por exemplo é comum elencar aí coisas como música comida bebida decoração e etc O problema é que delegar qualquer um desses elementos a uma equipe que não esteja realmente envolvida nos resultados da decisão Ou seja que não sejam afetadas pela consequência da Escolha como comprar mais coxinhas ou croquetes por exemplo é muito possível que não se obtenha os resultados que deseja queremos dizer é que se você recebe uma tarefa e não entende completamente

o porquê daquilo ou o porqu é necessário isso acaba ficando nebuloso nós humanos pensamos sempre em formas de narrativa de histórias e é assim que entendemos o mundo e é por isso que no momento que estiver elaborando uma tarefa o primeiro elemento que se deve levar em consideração são os personagens ou os papéis envolvidos nela ou seja para quem esse trabalho está sendo feito e em seguida é preciso perguntar o que queremos fazer e por fim o motivo daquilo está sendo feito sem pensarmos bem essa é a parte mais importante a a motivação é a

que dá cor a tudo então só para exemplificar um pouco vamos imaginar um comércio eletrônico de livros onde temos histórias como como cliente quero ser capaz de pesquisar livros por gênero para que eu possa encontrar o tipo de obra que eu gosto ou então que é outra como gerente de produto quero poder rastrear as compras do meu cliente para recomendar livros específicos com base no que ele já comprou viram é dessa forma que podemos determinar o tamanho de nossas histórias para que seja adequado ao time de de desenvolvimento e finalmente temos o Burn Down que

é um gráfico que mostra a linha de esforço frente aos trabalhos que precisam ser e que também já foram realizados os eixos que formam esse gráfico analisam a quantidade de trabalho a ser completado no eixo Y e as datas ou dias de execução no eixo X o burndown assim como o backlog também é dividido em duas partes um gráfico para o produto e o outro para o Sprint é com o gráfico do Burn Down que se consegue estimar o progresso do time e prazo de entrega utilizando dados reais do próprio projeto e não através de

cálculos empíricos falamos dos papéis dos artefatos Agora falta falar finalmente sobre os eventos que acontecem no scrum o primeiro que temos a citar é o Sprint justamente por ser o coração do scrum o Sprint é um ciclo de desenvolvimento que deve ter um tempo pré-determinado geralmente com máximo de sei lá umas quatro semanas onde o time completa alguns conjuntos de histórias ou seja os Sprint backlog E é exatamente aí que entra o Sprint planning que é uma reunião de colaboração do time scrum para definição dos itens que entrarão no Sprint backlog e que deverão ser

entregues no final da Sprint além desse backlog a equipe define também qual será a meta a ser atingida com essa Sprint geralmente esse planejamento também tem um tempo definido de até 8 horas essas limitações que o scr impõe são importantes para saber que se algo está levando muito tempo para planejar então é preciso dividir ainda mais o próximo evento Talvez seja o mais emblemático do scrum que são as reuniões diárias chamadas de Daily scrum essas reuniões Como o próprio nome diz devem ser executadas diariamente pelo time de desenvolvimento e pelo scrum Master É nesse evento

que se faz o sincronismo das tarefas E o planejamento para as próximas 24 horas algumas questões devem ser levantadas como o que foi feito no dia anterior o que será feito no dia atual e se há ou ou houve algum impeditivo que dificultou a conclusão de algo se algo estiver impedindo o scrm deve intervir imediatamente para tentar sanar o problema essas reuniões o tempo é importantíssimo o ideal é que elas não durem mais do que 15 minutos por isso mesmo aquela imagem de fazer reuniões em pé são famosas e por incrível que pareça elas funcionam

primeiro porque força todos a saírem dos seus computadores e também porque cada um tem um espaço limitado de tempo para falar e se planejar isso deixa tudo muito mais dinico depois da Daily scrum temos mais dois eventos que são o Sprint review e o Sprint retrospective o Sprint review é sempre realizado no último dia da Sprint é lá que se demonstra ao product honer também aos demais stakholders o incremento que foi criado ao produto o Sprint review é focado no aceite ou não do trabalho realizado sempre depois da revisão do Sprint é feita uma revisão

no backlog do produto e ali se define o provável backlog para a próxima Sprint acho que já deu PR perceber que o scrone não perde muito tempo com as coisas e tudo acontece bem rápido isso é excelente Pois cada problema que ocorre a correção é sempre muito rápida existe uma máxima no scrum que se diz ao fracassar fracasse rápido para que a correção do problema possa vir o quanto antes e finalmente meus amigos temos o Sprint retrospective que é uma reunião realizada justamente após o Sprint reveal ou que tem o objetivo em rever o processo

de trabalho e de qualidade da última Sprint ela é realizada pelo próprio time e deve ter no máximo 3 horas de duração Então pessoal para resumir tudo que a gente falou aqui nesse vídeo o ciclo do scrum começa com a visão do produto logo depois são criados os user histories que na verdade são as as tarefas do scram né que são as histórias e a partir daí vai se gerando o product backlog que são essas user histories o próximo passo já é o planejamento da Sprint e isso aí não deve durar mais do que o

8 horas e todo o time scun colabora com esse planejamento depois disso é gerado o Sprint backlog que são as histórias que serão concluídas durante o processo da Sprint a Sprint não deve durar mais do que 4 Semanas e esse ciclo é movido pela Daily scrum que são aquelas reuniões de até 15 minutos feitas diariamente depois de concluída essa Sprint você terá um entregável ou seja uma nova funcionalidade do sistema pronta e a partir daí é que se inicia o Sprint review que é a revisão da Sprint ela pode durar até umas 4 horas e

pode também fazer parte dela algum stakeholder ou seja algum interessado no produto que seja de fora do team scrum uma vez finalizado essa revisão a gente passa agora pro Sprint retrospective Ou seja é uma retrospectiva do que aconteceu e isso vai ajudar bastante na hora de você começar um novo ciclo Então pessoal aprendendo esse dialeto scrum das coisas é possível realmente ganhar mais produtividade principalmente antevendo os possíveis problemas e quando eles ocorrem e ocorrem e seja muito rápido para corrigi-los essa CDF é a essência disso tudo que falamos até agora por isso mesmo que falamos

aqui no canal como nós programadores precisamos também Nos preparar para sermos técnicos mas também temos que ter habilidades pro trabalho trabalha em equipe e de gestão do nosso trabalho nesse ciclo de desenvolvimento ágil E aí você gostou assiste então outras episódios aqui na nossa playlist ou também aqui na descrição desse vídeo aproveita que o vídeo tá terminando clica aí no curtir e comenta o que você achou compartilhe esse episódio com seus amigos programadores e não deixe de se inscrever aqui no canal e ver um CDF você também aproveita e acompanha a gente também lá no

Instagram no @codojfw65 e até um próximo vídeo tchau tchau tchau [Música]