Gerência e Qualidade de Software - Aula 13 - Scrum

[Música] o [Música] olá eu sou fábio siqueira nessa aula vou falar sobre os campos que é um dos métodos ágeis mais usados atualmente senão um método ágil mais usado é hoje pelas empresas brasileiras de desenvolvimento de software e apesar de ser um método muito usado a começou a ser usado com freqüência faz 15 10 anos a ele o método relativamente antigo ele foi proposto pelo quente obra helgerson atlântico em 1993 ou seja ele é relativamente antigo ainda assim demorou bastante tempo pra ele ficar popular que atinge a popular de popularidade que ele tem hoje e

é interessante dele é que ele não é um processo de desenvolvimento de software na verdade ele é um framework gerencial ele não é um processo não é um método não é uma técnica é um framework e os autores definem como um framework para desenvolver e entregar e manter produtos complexos no final das contas o que ele trata da gestão também trata da gerência de projetos e também de algumas questões de organização então ele não é específico para desenvolvimento de software ele pode ser aplicado para vários outros domínios tem até um livro do santana que ele

fala sobre a aplicação do ies campo por exemplo há dentro da sua casa então você pode organizar as atividades às tarefas domésticas usando scan a tem gente também que o escreve pra as atividades dentro de uma escola primária então não é para desenvolvimento de software não é só para desenvolvimento de software pode ser feito para outros produtos e outros serviços mas ele é pesadamente usado pra desenvolvimento de software e vocês vão ver que a abordagem do scream é fortemente interativa incremental então você tem muita interação as atrações são relativamente curtas então você pode ter ações

de ter interações de uma duas ou até um mês mas é tudo muito curto a pra você gerar um incremento do produto e entregar isso daí é deixar disponível para o uso e os pilares dos campos canta em três pilares fundamentais primeiro é a transparência então a ideia é que tudo deve ser transparente os resultados têm que ser transparentes e os critérios pra você dizer que algo está pronto ou não o critério de fazê lo em relação a alguma atividade tem que ser bem transparente bem visível pra todo mundo o outro pilar a inspeção então

como é um produto complexo ele precisa ser inspecionado frequentemente mas essa freqüência de expressão não deve atrapalhar a atrapalhar o processo o processo ele deve fluir então você inspeciona com freqüência para ver se os artefatos estão seguindo o que estava sendo esperado por ele e também para ver se o progresso dele é apropriado e o outro pilar do scream adaptação ou seja a bom como é um produto complexo o processo ele vai se adaptando pra ser o melhor possível para desenvolver aquele produto então vamos ver como funciona o scan e se daqui é uma visão

geral da dos eventos e dos artefatos do escândalo então os artefatos descansam beck logo do produto backlog da sprint e você tem um produto entregava os eventos estão planejamento de sprint o trabalho desenvolvimento a revisão da sprint a retrospectiva da sprint todos esses daqui são parte do que a gente chama de sprint então esse pente é basicamente uma interação tão o que vai ser feito em uma interação do desenvolvimento vamos ver em cada em detalhe cada um deles começando pelo beque longo do produto então que é o beque logo do produto é na verdade uma

lista de itens de tudo o que se espera que seja feito para aquele produto que se sabe o que é necessário para aquele produto no final das contas ele é a fonte dos requisitos pensando em desenvolvimento de software é dali que os requisitos vem e ele é uma lista ordenada então você tem vários itens eles são ordenados e em geral eles têm uma descrição tão o que aquele item uma estimativa que a equipe dizer o que o time de desenvolvimento acha que é da complexidade do tempo necessário para ser feito e tem um valor e

às vezes aparece também há uma descrição dos testes de aceitação como que eu aceito aquele item como eu digo que aquele item foi está correto e esse blog do produto ele não é fixo ele vai ser alterado durante o desenvolvimento vai ser continuamente refinado então há o pessoal vai o produtor que é o responsável por esse técnico produto produto toner é basicamente é o representante do dos stakeholders então ele é quem vai cuidar do do backlog produto e ele vai refinar e vai colocar novos itens vai retirar a itens vai quebrar a itens estão ele

vai mexer nesse nesse beco do deco logo do produto conforme a necessidade então partir desse blog tem uma reunião chamada de planejamento sprint então essa reunião é feita no começo de cada sprint e ela trata de 22 pontos duas questões primeiro é o que tem que ser entregue então o que pode ser entregue naquele sprint então pra isso o produtor e ele vai conversar com o time e desenvolvimento ele vai debater ou seja não é algo que ele obriga que seja feita uma discussão contínua e desenvolvimento produtor tem o poder sobre quais são os itens

importantes ele sabe quais são os itens importantes mas ele debate contínuo desenvolvimento um outros itens e mostra também qual é o objetivo esperado para aquela aquele sprint então o que está se esperando qualquer a meta daquela spend que a gente quer alcançar com aquela sprint e consegui pra saber o que pode ser entregue se considera a capacidade do time escravo ou seja o que o time consegue entregar em um sprint outra questão é tratada é como o trabalho vai ser realizado a decisão do trabalho como ele vai ser feito é um problema específico do time

de desenvolvimento ele decide como vai fazer o trabalho dele mas ele vai a perguntarem tradicionalmente pergunta tirar dúvidas sobre como vai ser feita aquela atividade em geral você vai pegar um item e vai ter que entender um pouco melhor ele consegui fazer o trabalho e nisso daí o resultado desse da definição do trabalho é feito tal do backlog da sprint que é basicamente um conjunto de itens do que vai ter que ser feito naquela sprint em um blog do produto ele tem todos os itens que se espera do produto ou da sprint é o que

se espera daquela existente então você vai pegar o times cano ele pega o item do petróleo do produto que o produtor achou apropriado para aquela sprint e refina detalhe ele a ponto de que consiga desenvolver o que precisa ser desenvolvido então eo beque do da sprint a responsabilidade total do time de desenvolvimento ele vai pegar esse item é os itens e quebrar organizar da forma que eles acharem mais apropriado para conseguir entregar o incremento a mais adequado e aí sim vem o trabalho de desenvolvimento então o escândalo falar nada sobre como tem que ser feito

esse trabalho ele só fala que tem que ser feito então o time desenvolvimento ele vai pegar cada um dos itens cada uma das tarefas que estão ano da cloud print e vai desenvolver não vai fazer todas as todo o desenvolvimento necessário dependendo do produto por causa do envolvimento de software para desenvolver o software vai testar vai implantar dependendo do caso integrar com os elementos e isso é feito com pelo time desenvolvimento e o que o scan fala sobre o trabalho desenvolvimento é que tem uma reunião diária diariamente se faz uma reunião a reunião tem que

ser rápida se fala é a reunião também se chama reunião de 15 minutos a reunião curta um salem durar 15 minutos pode ser até ser menos mas é uma reunião curta que os desenvolvedores fazem até de pé em geral é um também se chama de reunião de pé todo mundo se junta o time desenvolvimento se junta ea idéia é ver o que está acontecendo há com cada um desenvolvedor espera que ele consiga atingir a meta que foi definida pela sprint então tradicionalmente tem três perguntas que o cada desenvolvedor responder o que ele fez no dia

anterior pra atingir o objetivo da sprint ele vai responder também o que ele vai fazer naquele dia e ele responde também se tem algum obstáculo então alguma coisa que ele fez que está atrapalhando o trabalho dele então a idéia da reunião diária é ajudar o planejamento para as próximas 24 horas até a próxima reunião diária se tiver algum impedimento é um problema já toda a equipe está lá sabe algum membro do time consegue ajudar contribuir para resolver o problema que tiver e as outras pessoas têm a informação do que está sendo feito de forma transparente

então feito o trabalho de desenvolvimento você tem um produto empregável estão na aula de garantia da qualidade eu já comentei sobre a definição de pronto dois campos a definição de pronto aparece aqui é como eu sei que um produto uma parte do meu produto tá pronto então a desenvolver o software cheguei no resultado ali implementem o que tinha equipamento implementar como que eu sei que ele está pronto então o time desenvolvimento tem que definir em conjunto o que é o pronto significa a só tem implementado ou psa tts unidade e quanto de teste unidade ou

até que seja implantado isso em algum lugar então tudo isso é definido pelo time de desenvolvimento e quando define que está pronto a ele é entregue é junto é juntado com o incremento e no final do expediente você tem um resultado depois que o trabalho desenvolvimento foi feito terminou e é tá no fim em sprint existem duas reuniões que são feitas tem a tal da revisão da sprint e t retrospectiva da sprint a revisão da sprint é basicamente pra você a preparar o time de desenvolvimento o melhor do time escalando apresentar como foi o resultado

que teve naquela spent então que se obteve a isso é apresentado para todos os stakeholders há também se fala quais foram os problemas que aconteceram durante a sprint e como eles foram resolvidos a outra informação que fala é o que outra informação que discutia como o produto pra pode evoluir nas próximas sprints então como o que seria interessante colocar as próximas sprints a se for necessário repensar release o que vai ter na próxima release pensar em orçamento questões de mercado que apareceram desde o último sprint tal momento pra você discutir por times chrome os stakeholders

discutirem um produto a reunião seguinte é a retrospectiva que é basicamente por tim scan discutir o processo dele para melhorar o processo então é a questão da adaptação se está adaptando o processo continuamente ao final de cada sprint melhor um pouco o processo ou procura-se formas para melhorar o processo então nesse momento o time discutir em geral se apresenta o que deu certo eo que deu errado então pontos fortes e pontos fracos tratando de do processo que aconteceu então uma ferramenta funcionou muito bem a faltou comunicação com tal pessoa que seria importante tal atividade não

está sendo executada com adequadamente tudo isso se levanta e se definir um plano próximo sprint como isso pode ser aproveitado como isso pode ser que o esporte podem ser melhorados os pontos fracos podem ser corrigidos se você tem um plano para a próxima experiente então isso é o escambo isso é o funcionamento do freio bookscan todos esses artefatos e essas cerimônias os papéis importantes dos campos são parte do time espanhol que é composto pelo próprio ituano que eu já comentei torna é o responsável pelo blog do produto ele que sabe o que é importante para

o produto ele define isso daí junto com times campo com time de desenvolvimento então ele é responsável pelo blog e às vezes o produto é chamado de don no produto ou até mesmo de pi o pessoal da sigla há o time desenvolvimento é o time que vai fazer o desenvolvimento não existem papéis dentro do time no time e desenvolvimento ele é um time é um time muito funcional e auto organizava ou seja não existe uma hierarquia ele o time mesmo definirá é dele a forma dele se organizar e não têm o menor que entre os

elementos então você não tem um alguém que é o chefe a não tem isso o time ele é todos são iguais todos conseguem fazer um pouco de tudo então eles são multifuncionais e claro cada um tem um pouco pois é um pouco de especialidade mas todo mundo consegue trabalhar consegue trabalhar em conjunto a o scan define que os times de desenvolvimento ele tem que ter de três a nove pessoas mais que isso a você tem um problema muito sério de comunicação que é um problema sério para métodos ágeis então time tem que ser pequeno para

que as pessoas consigam trabalhar em conjunto e conversar de quadra mente para compra a comunicação flui e não existe subtilis então o time é aquilo não tem hierarquia não tem subtil e o time é quem vai fazer o trabalho de desenvolvimento é quem vai entregar o produto um outro papel muito importante no scream é o scan basta o iskra master ele não é um gerente de projetos longe disso ele é simplesmente alguém que vai ajudar o próprio toner e o time de desenvolvimento aplicar o escândalo forma mais adequada possível então ele vai treinar vai auxiliar

os os membros do time em campo para fazer da melhor forma possível escândalo então ele não acompanha o projeto não é um gerente ele soja o treinamento e às vezes ajuda também a disseminar o o escândalo organização então ajuda a alta direção da empresa entender o que queres campo como ele funciona e por que o time está fazendo um trabalho que ele está fazendo então 3 ante a notar que não escuta não existe um papel formal do gerente de projetos são só esses três papéis o próprio tony o time desenvolvimento que não têm papel interno

e você tem também o esquema mostra como funciona a estimativa no escândalo então o escândalo ele tem quando você tem um item de blogs é estimado mas como se estima qualquer qual que é a técnica que se usa e quais são as métricas que trabalham no caso do escândalo ele não falou detalhes e pegar o dinheiro do crime ele não fala como você tem que fazer isso cada time desenvolvimento encontrar a forma adequada depende na verdade do contexto mas tradicionalmente para desenvolvimento de software o que a gente usa é histórias como forma como item tão

o escândalo fala como tem que ser esse item também esse item pode ser qualquer coisa então para desenvolvimento de software gente poderia ter por exemplo caso de uso como item do backlog mas tradicionalmente que se usa é história e aí como eu estimo história como eu há como eu digo qual é o tamanho dela a no backlog do produto se usa tradicionalmente tamanho de camisa que se fala então você faz o tamanho p m g nada impede que você tenha esta grande ou extra pequeno mas é algo bem bem vago bem é bom é também

de caminho é bem diferente e no backlog da sprint aí sim você vai ter um detalhamento um pouco maior então nas histórias que se trabalha com pontos de história seus 11 alguns números para representar qual é o tamanho daquela história e no caso das tarefas se trabalha com com horas mesmo então a idéia é que você vai pegar uma história que está no blog do produto e passar o backlog de repente a esse estigma qual é o tamanho dessa história usando pontos de história e nem o time de desenvolvimento quebra essas histórias em tarefas estima

as tarefas em horas então como se estima qual que a forma de estimular como eu defino quantas horas a tarefa dele é demora ou na verdade principal é como que eu defino quantos pontos de história uma história tem então pra pontos de história é muito normal usar o plano em pouca que é uma técnica muito parecida com na verdade uma variação de uma técnica chamada delphi uma técnica antiga então a idéia dela é que você vai ter um consenso entre o time desenvolvimento então cada um dos desenvolvedores vai ter vai passar desenvolvedores na verdade são

especialistas na então eles como especialistas e cada um deles vai ter uma estimativa e a técnica ela vai tentar obter um consenso sobre isso essa ideia geral e o interessante é que ela trabalha com o tamanho relativo então a idéia que você não vai ter exatamente o valor é um ponto de história na verdade não significa muita coisa ele significa um tamanho relativo frente uma outra história então ele não significa horas christine significa um tamanho relativo àquela história e a idéia por trás disso é que o ser humano não é muito bom em precisão estimar

com precisão mas ele é bom em acurácia tão a proximidade com o valor real então ele consegue é muito mais fácil você estima por proximidade falar isso está mais próximo disso do que dá um valor real para aquilo são pontos de história trabalha com essa idéia a escala que se usa tradicionalmente no plano em pouca é uma seqüência de fibonacci modificada então é exatamente a seqüência de fibonacci mas é uma sequência baseada na idéia da seqüência de fibonacci que você tem um valor como a soma dos valores anteriores então você tem uma distância ainda está

é uma instância relativa boa entre os valores são tradicionalmente usa essa essa seqüência 1 2 3 5 8 13 que tudo fique bonatti e aí se modifica 2045 então sem um valor grande tem também alguns algum alguns usuários essa técnica que usa outros valores por exemplo o infinito para falar isso aqui é muito grande não conseguiu intimar mas como funciona a pleno em pouca qualquer qualquer o funcionamento dele então a idéia do plano em pouco aqui a primeira coisa o produtor explica aquele item então a gente vai se chamar uma história então produtor explica a

história ele diz como aquela história funciona é qualquer idéia dele e tira dúvida então todos os jogadores perguntam sobre aquela história qualquer dúvida que eles tenham e aí cada desenvolvedor pega uma carta que na verdade são cartas na idéia que você vai ter uma carta cada desenvolvedor tem um deck de cartas de um baralho com cada um daqueles valores e cada desenvolvedor vai lá escolhe uma carta fala puxa eu acho que a estimativa que essa história aqui é tem vale tantos pontos então vale será quatro pontos um outro desenvolvedor acha que a história vale é

41 55 pontos o outro acho que vale 8 outro acho que vale 3 então cada um tinha uma carta falou é esse valor que eu acho que cada um escolhe a carta e todos mostram a carta ao mesmo tempo então se tiver um consenso todo mundo escolheu a mesma carta então todo mundo escolheu cinco tá bom entrou sim consciência encontrou se um consenso sabe qual que é o quanto vale aquela história agora caso não tem um consenso o que se faz é de alguma forma a gente se discutir então o tradicional é pedir pra quem

te vê alguém que teve uma estimativa a menor estimativa apresentar porque ele acha que aquela estimativa é daquele é aquela valor e pede para alguém que teve uma a uma das estimativas maior estimativa mais alta também para explicar porque ele acha que a estimativa está em alta ea partir dessa discussão se discutir com o próprio tony tinha alguma dúvida necessária e os desenvolvedores dos outros do time e desenvolvimento também participam e se faz de novo você tira o cada parte e cada membro do time desenvolvimento tirar a carta e isso é feito até se obter

um consenso ou até um conjunto de deter ações ter sido feito que percebe que não vai ter um consenso e aí se encontra alguma alguma solução para isso pega média mediana ou alguém decide como vai ser o valor uma outra um outro fato interessante que aparece com freqüência no scream é um gráfico que é chamado de banda um chat que ele mostra o progresso do time desenvolvimento o objetivo então em geral que se faz é se só umas horas se mostra as horas das tarefas e mostra-se o progresso daquela é do time desenvolvimento pra em

relação aos dias poxa estamos no dia 5 e já faltam ainda 120 horas então que se mostram que quanto falta idealmente no final da sprint sequer que tenha terminado todas todas as tarefas bom como conclusão a o scan é um método ágil é um framework gerencial que não fala como o desenvolvimento tem que ser feito ele só fala quais são alguns eventos e quais são os artefatos e quais são os papéis necessários pra você ter um bom funcionamento do time e para desenvolver o time desenvolvimento precisa decidir quais são as técnicas que ele vai usar

e pra isso xp 8 no programa pode ser uma boa forma então você pode juntar o escândalo com o xp é um programa para desenvolver o software que o xp já trata de questões técnicas e um detalhe interessante dos campo é que o scan de acordo com os autores do scream é só existe em sua totalidade então não existe meio scan não existe schramm sem alguma prática ou s é um evento escanteio algum algum papel até fazendo descansa em prol do toner estou fazendo os cães sem a retrospectiva não existe isso o scan é tudo

ou nada então os autores falam que você precisa ter tudo e precisa ser feito daquele jeito pra você falar que tem scan então é isso sobre scan nos vemos as próximas aulas [Música] o [Música] [Música]