Métodos Ágeis

Olá nessa gravação eu vou discutir sobre métodos ágeis assim nós vamos começar por uma introdução do que vem a ser os métodos ágeis incluindo inclusive alguns princípios e algumas características que são comuns a todos os métodos ágeis que fazem tanto sucesso hoje em dia no mercado na sequência eu vou falar um pouco sobre o surgimento dos métodos ágeis a partir do manifesto e os Princípios ágeis que foram publicados em fevereiro de 2001 numa Estação de Esqui e Utá quando 17 pensadores da área de desenvolvimento de software se reuniram para dar uma resposta ao mundo sobre

os atrasos estouros de orçamento e qualidade dos produtos de software sendo desenvolvidos até então na sequência eu vou falar um pouco sobre modelagem ágil que embora não seja um método ágil é uma prática que vem Sendo muito utilizada dentro dos métodos ágeis partindo do princípio que nós modelamos para compreender determinado design e não para documentar tendo discutido esses fundamentos eu vou partir para a discussão daquele que talvez seja o método ágil mais famoso no mundo que é o extreme programming ou XP vamos falar um pouco dos seus valores das suas práticas e na sequência vamos

falar de um outro método ágil usado para o planejamento Acompanhamento e execução de projetos de desenvolvimento de software que muitas vezes é usado em conjunto com XP e é conhecido como scom também muito difundido aqui no Brasil na sequência eu vou dar uma pincelada em diversos outros métodos ágeis que estão presentes na literatura que estão presentes no mercado para que tenhamos assim uma visão mais ampla reconhec as características e as práticas que Realmente são compartilhadas por todos esses outros métodos e final eu vou indicar algumas referências que foram usadas para criação dessa gravação Vamos iniciar

então com a pergunta clássica O que são métodos ágeis por in que pareça é uma pergunta cuja resposta não éi de tendo em vista que se você fizer essa pergunta para 10 pessoas que trabalham no dia a dia com métodos ágeis cada uma vai te dar uma resposta Diferente portanto não há uma definição precisa pois as práticas específicas variam muito embora nós tenhamos algumas características que são compartilhadas por todos os meus métodos ágeis assim a maioria dos métodos ágeis possuem possu conceitos similares dentre eles destacar o desenvolvimento iterativo a criação do seu trabalho sendo norteado

por uma lista de tarefas outra característica muito comum É o desenvolvimento Baby Steps de forma que uma pequena funcionalidade é desenvolvida por mês e não esquecendo que nós não vamos sobrecarregar nossa equipe então a maioria dos métodos ágeis trabalham com conceito de ritmo sustentável o XP inclusive terminantemente proíbe o uso de horas extras semanas de 40 horas de trabalho não mais nós vamos perceber também que a maioria dos métodos ágeis trabalham com Conceito de equipes multifuncionais e auto-organizáveis é o que o Ken schwab nos seus livros de scom fala de não trabalhamos com o conceito

de comandar e controlar que é muito visto às vezes na área de gestão de projeto tradicional dentro de métodos ágeis A gestão é feita de é feita muitas vezes pelo próprio time indicando alocando para si próprio as tarefas necessárias as estimativas de esforço para determinadas tarefas ou em outras palavras se auto organizando para Atender determinado objetivo dentro de uma iteração que no scrum é chamado de Sprint todos os métodos ágeis parte do pressuposto que nós temos que confiar no nosso time de desenvolvimento Temos que confiar dos nossos gerentes Temos que confiar nos nossos clientes há

uma interação constante entre todos os stakeholders envolvidos dentro de um projeto de desenvolvimento de software portanto a confiança no na minha equipe é muito Importante outra característica também chave que é compartilhado por praticamente todos os métodos ágeis são as entregas prontas para produção no final de uma iteração ou no final de um Sprint nós não vamos entregar documento ação apenas para o nosso cliente nós vamos estregar código funcionando pois nós vamos ver daqui paraa frente a medida a principal medida de Progresso em métodos ágeis é código funcionando e não documentação Extensa a maioria dos métodos

ágeis também trabalho com os conceitos de testes e builds automatizados incluindo os sistemas de integração contínua onde toda sua aplicação Toda vez que você faz um comit no seu sistema de controle de versão automático integrado com servidor de integração contínua que já automaticamente roda todos os testes unitários os testes de aceitação os testes de integração para verificar se realmente Aquele comite feito já está pronto para produção então basicamente A ideia é tentar automatizar o máximo eliminando a interversão humana no que tange o desenvolvimento e a depuração dos seus códigos como também eliminar a intervenção humana

no momento que nós vamos ter que colocar o nosso software migrar ele do ambiente de desenvolvimento para o ambiente de produção de forma automatizada também nós vamos perceber Que o conceito de aceitação de mudanças é muito enraizado dentro dos métodos US ágeis Pois todos eles partem do pressuposto que requisitos mudam o tempo todo e com base nisso nós devemos inspecionar empiricamente o desenvolvimento do nosso projeto e com base nesses feedbacks contínuos no dia a dia alterar nosso processo ou até mesmo alterar os requisitos para que possamos dessa forma satisfazer os nossos clientes com produto de

Qualidade então conforme dito vocês devem ter percebido que o conceito de inspeção e adaptação é contínua dentro dos métodos ágeis em vez de termos apenas um setor de garantia de qualidade no final de um ciclo de vida numa fase de um projeto que vai testar tudo aquilo que tá sendo produzido nós vamos pulverizar as inspeções as adaptações os testes por todo o ciclo de vida do projeto essa é uma característica comum de praticamente todos os métodos Ágeis outra característica eu gostaria destacar É que tantos os meus planos como os minhas listas de tarefas como os

meus requisitos como o meu próprio projeto como o meu próprio produto meu próprio software sendo criado em cada interação ele vai sendo refinado evoluído ao longo do projeto nós não temos uma análise de requisitas Up front hoje nós tentamos detalhar ao máximos requisitos e depois iremos implementar dentro dos métodos á trabalhamos Conceito de planejamento evolutivo de forma que nós atacamos e detalhamos os requisitos dentro do seu momento oportuno para a realização outra característica chave de qualquer método ágil é reconhecimento de que pramos eliminar o abismo existente entre clientes que entendem de negócio e desenvolvedores que

entendem de tecnologia esse Abismo entre clientes desenvolvedores é um dos grandes desafios jar de software e os métodos Ágeis reconhecendo isso trabalham muito com conceito que nós tem nós temos que trabalhar com acompanhamento frequente de nosso cliente o cliente faz parte da nossa equipe precisamos respeitá-los e precisamos que ele esteja presente a maior parte do tempo possível auxiliando nas ambiguidades e removendo esse Abismo entre time desenvolvimento e cliente e lembrando também que nós vamos focar naquilo que vai tornar mais valor para o meu cliente então nós vamos focar nas Funcionalidades do software que mais agregam

valor para o cliente Essa é uma das grandes características que nós temos dentro dos métodos ágeis inclusive para estreitar esse rela entre time de desenvolvimento e cliente assim todos os métodos ágeis reconhecem então que precisamos de uma forma de atender a natureza mutável e dinâmica do processo de construção de software agora que foram apresentadas todas as Características que são comuns que são compartilhadas por todos os métodos ágeis presentes no mercado Chegou a hora de voltarmos um pouco no tempo até Fevereiro de 2001 que foi quando surgiu o famoso Manifesto ágil que foi a resposta dada

por 16 pensadores pesquisadores e pessoas muito experientes na área de desenvolvimento de software que se reuniram numa Estação de Esqui em Utá nos Estados Unidos para Tentar dar ao mundo uma resposta que pudesse dentre outras coisas estabelecer o porquê da maioria dos projetos de desenvolvimento de software não serem finalizados dentro do prazo planejado com o orçamento estabelecido e com critérios de qualidade aceitáveis assim essas 17 pessoas que aqui estão listadas se reuniram inclusive eram pessoas que trabalhavam muitas vezes em empresas até mentee concorrentes mas Reuniram para poder dentre outras coisas publicar uma solução ou um

conjunto de diretrizes que pudesse nortear o deseno software daquele momento para o futuro assim o resultado desse encontro é muito conhecido ficou muito conhecido como o Manifesto ágil que indica claramente alguns valores e alguns princípios que deveriam ser seguidos para que possamos dessa forma Desenvolver software com mais qualidade dentro dos prazos e sem estouro de orçamento O Manifesto ágil pode ser resumido os seus valores basicamente por essa pequena tabela onde nós mostramos que indivíduos e interação entre esses indivíduos entre os membros da equipe de desenvolvimento entre os clientes e a interação entre todas essas pessoas

envolvidas Entre todos os stakeholders é mais importante do que processos e ferramentas o que eu gostaria de deixar Bem claro aqui que o lado esquerdo do método ágil é mais importante do que o lado direito mas em nenhum momento estamos falando que nós não que o que tá do lado direito aqui no Manifesto ágil nessa tabela seja importante apenas que o lado esquerdo é mais importante então indivíduos e interação entre eles é mais importante do que processos e ferramentas da mesma forma é muito mais importante software funcionando do que documentação abrangente colaboração com Cliente do

que negociação contratual e seguir a risca os nossos planos é muito mais important responder mudanas do que seguir um Plano Especial ainda dentro do Manifesto ágil foram publicados 12 princípios que nós deveríamos seguir para um desenvolvimento de software com maior qualidade a primeiro o primeiro princípio publicado pelo Manifesto ágil é que a principal prioridade é a satisfação do Nosso cliente através da entrega adiantada e contínua de software de valor o segundo princípio ataca o conceito de que devemos aceitar as mudanças de requisitos mesmo no fim do desenvolvimento devemos lembrar sempre que os processos agem se

ade com as mudanças para que o cliente dessa forma consiga Ger vantagens competitivas devemos sempre dentro dos princípios ágeis e de acordo com o terceiro princípio do Manifesto entregar Software funcionando com frequência dando sempre prioridade preferência a iterações curtas quanto mais cur a minha interação a minha iteração a iteração do meu processo mais estreitamento menos Abismo entre clientes desenvolvedores é presenciado e Teoricamente mais qualidade nos artefatos sendo produzidos o quarto princípio ágil publicado através do Manifesto ágil Mostra pra gente que as pessoas relacionadas a negócios os seus nossos executivos e desenvolvedores eles devem trabalhar em

conjunto diariamente durante todo o curso de do projeto a participação do nosso cliente com o nosso time de desenvolvimento é muito importante de acordo com o quarto princípio ágil o quinto princípio ágil se diz fala sobre a motivação dos indivíduos reconhecendo que é muito Importante fornecer para o nosso time para os nossos clientes para os stakeholders um ambiente e suporte necessários e confiar de que o trabalho vai ser feito confiança na equipe é um dos princípios também que nós vimos que é uma das características que é compartilhado por basicamente todos os métodos ágeis o sexto

princípio Deixa claro para todos nós que o método mais eficiente para a transmissão de Informações entre os stakeholders envolvidos no projeto é comunicação face a face face to face já o s princípio ág mostra e a medida de progressa dentro de métodos ágeis é software funcionando e não documentação abrangente no oitavo princípio ágil nós podemos destacar o que nós chamamos de ambiente sustentável todos os envolvidos todos os take rados envolvidos devem ser capazes De manter um ritmo constante indefinidamente o XP conforme nós vamos ver inclusive permite horas extras por time de desenvolvimento de nada adianta

você sobrecarregar um time um do TR três iterações para que na semana seguinte você tenha que dar folga para eles ou até mesmo para que eles possam procurar seu terapeuta para resolver todos os seus problemas times que produzem mais trabalham dentro do que nós chamamos de ritmo Sustentável o nono princípio ágil nos remete à atenção à nossa excelência técnica e bom design já é demonstrado através de diversas publicações que o uso de por exemplo de técnicas como testes automatizados de refactoring além de melhorar o design de nossos aplicativos tornando a manutenção e expansão mais fácil

e menos tediosa aumenta a produtividade do nosso time de desenvolvimento o 10mo princípio ágil é muito simples ele é chamado de Simplicidade que basicamente é a arte de maximizar a quantidade de trabalho que que não precisa ser feito é muito baseado em um princípio usado no XP chamado y agne y aagn you Ain't gonna needed Ou seja você não irá precisar dentre outras palavras se eu não vou precisar eu não vou documentar eu não vou gastar esforço Eu apenas vou gastar esforço vou trabalhar bastante dentro daquilo que realmente vai trazer retorno de investimento para o

meu cliente e não Naquilo que em funcionalidades especulativas que ainda nem estou certo se deveriam ser produzidas ou não o 11º princípio ágil fala que as melhores arquiteturas e os melhores designs surgem e emergem de times que são auto-organizáveis e os 12º trabalha muito com o conceito de reflexão pois em intervalos regulares o time de desenvolvimento reflete em como ficar mais efetivo de forma a ajustar e otimizar o seu comportamento Com base nesse feedback com base nessa reflexão de forma que as práticas desenvolvidas pelo time de desenvolvimento possam ser primadas com base na experiência adquirida

empiricamente no momento que esver acompanhando o desenvolvimento do projeto embora não seja um método ágil a prática de modelagem ágil cunhada por Scott humbler se tornou bastante difundida dentro da comunidade de métodos ágeis De acordo com Scott humbler a finalidade da modelagem É principalmente entender determinado design e não documentar se partimos desse pressuposto podemos dentre outras coisas utilizar A modelagem como rascunho para o entendimento das ideias acerca do Design sem a necessidade por exemplo de usar uma ferramenta cas para modelagem e de acordo com Scott que cunhou o termo de modelagem ágil dentro do seu

livro A Modeling A modelagem ágil é constituía de diversas práticas e valores dentre elas Podemos destacar a doação de um método ágil não significa evitar a modelagem os modelos para entendimento e comunicação possuem esse propósito e não a documentação uma outra recomendação uma outra prática é que nós não devemos modelar ou aplicar o todo a maioria do nosso projeto de software nós temos que usar a ferramenta mais simples Possível outra característica interessante é o reconhecimento que se nós usamos modelagem para entendimento acerca de um design é melhor que essa modelagem seja feita de forma colaborativa

então uma das práticas é não modelar sozinho modelar em equipe talvez usando um quadro onde vári pessoas com seus pincéis atômicos possam trabalhar em cima de uma modelagem em conjunto inclusive em Paralelo nada impede que nós possamos ao mesmo tempo estar modelando como rascino num quadro um diagrama de classe representando um modelo de domínio da nossa aplicação e ao mesmo tempo fazendo uma outra parte do quadro uma uma modelagem dinâmica por exemplo do diagrama de comunicação ou de sequência que vai mostrar a colaboração entre os objetos para realização de um deter cenário de caso de

uso ou por exemplo de uma história de Usuário a uml como nós já sabemos ela teve um crescimento exponencial nos últimos 15 anos e com base nisso muitos detalhes que muitas vezes não são necessários foram incorporados dentro da especificação mas nós devemos usar apenas a oml simples aquela que realmente vai agregar valor para noss do projeto e não apenas modelar porque talvez um gerente de projetos tenha pedido para que você modelasse Nós precisamos modelar aquilo que vai agregar valor e devemos reconhecer que os nossos modelos que nós estamos modelando eles vão ficar imprecisos e o

código gerado a partir de um modelo inicial vai ficar diferente lembrando também que nós os diagramas os modelos eles devem ser criados pelos desenvolvedores para si próprios de forma que ele consiga entender e também dessa forma consiga criar modelos Claros precisos para que possa inclusive ser comunicados com outras pessoas eu não vou entrar no mérito da discussão de que uma outra área muito importante dentro Daia de software vem ganhando muita atenção nos últimos anos que é a área de mod Dri Engineering que engenharia de engia por modelos ou dirigida por modelos onde nós temos que

os modelos não são rascunhos é bem diferente do conceito de Modelagem ágil dentro do de uma arquitetura tipo MDA os modelos são a força motriz para desenvolvimento de software transformações automatizadas entre modelos geram código executável a partir de o modelo Independente de plataforma através de transformações sucessivas mas esse é um outro assunto O que nós estamos focando aqui é que o temo de modelagem ágil e algumas das práticas Previstas por Scott humbler se tornaram amplamente difundidas dentro dos métodos ágeis nos últimos anos o XP é um método ágil desenvolvido por Kent Back e que é

usado em projetos onde os requisitos são vagos e estão em constante mudança é um método que é focado em pequenas e médias equipes e que prega o constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de Software o que nós vamos perceber é que as regras individuais do XP elas não são novidades no mundo de desenvolvimento de software entretanto foi dentro do XP que elas foram coletadas e foram alinhadas de uma nova maneira para funcionarem umas com as outras surgindo assim o método Extreme programming XP dessa forma existe lembrando sempre que existem algumas

variáveis que de controle em projetos e que Também estão sob controle do XP basicamente as principais variáveis de controle que nós temos em projeto são as variáveis de custo tempo qualidade e escopo de acordo com o pmbok no caso de XP há uma tensão muito específica na questão do escopo de forma que nós vamos priorizar as funcionalidades que vão realmente representar maior valor para o negócio ou em outras palavras Caso seja necessária a diminuição de escopo as funcionalidades menos valiosas serão Adiadas ou canceladas o XP se baseia em alguns valores bem simples que vão notar

todas as regras do método esses valores de acordo com KB são comunicação onde todos os envolvidos fazem parte do time e deve se comunicar diariamente Face a Face simplicidade onde nós devemos fazer somente o necessário nada mais do que isso de acordo com o princípio y agne e a gonna need it você não irá precisar então Teoricamente você não tem que Fazer maximizando a arte daquilo do trabalho que não é feito outro valor do XP é o valor do feedback o software entregue o quanto antes e de forma frequente sempre escutando com atenção e fazendo

qualquer alteração necessária um dos principais valores do XP é a coragem deve-se sempre dizer a verdade sobre o progresso e as estimativas para todos os envolvidos dentro de um processo XP e o último valor do XP que foi Descrito por Kent Beck é o respeito todos respeitam e se sentem respeitados enquanto membros do time sejam clientes sejam gerentes ou se desenvolvedores assim com base nesses valores diversas regras foram elaborados dentro do método ágil XP essas regras foram categorizadas e talvez seja uma forma mais fácil de enxergarmos como elas trabalham em conjunto nós temos algumas regras

por exemplo de planejamento todo Planejamento do XP é baseado em histórias de usuário que são escritas pelo cliente dentro do XP um cronograma de liberações deve ser criado nós vamos fazer el liberações pequenas e frequentes o projeto vai ser dividido em interações toda interação vai iniciar com planejamento e serão serão os desenvolvedores que vão estimar os esforços dos os esforços dos itens presentes nesse planejamento nós vamos ver que tá muito alinhado com scrum Essas regras de planejamento do XP nós temos também algumas regras de gestão para o método a XP por exemplo Espaço Aberto de

trabalho o ritmo sustentável semanas de 40 horas de trabalho horas extras são terminantemente proibidas no XP reuniões que acontecem todos os dias em pé rápidas de forma a acompanhar o que tá dando certo o que tá dando errado o que tá sendo feito por cada membro do time dia a Dia a velocidade do projeto é medida em projetos do tipo XP do tipo scrum nós trocamos as pessoas com frequência em partes do projetos Às vezes você tá desenvolvendo uma tela na interface gráfica usuário você pode depois est desenvolvendo um D uma camada de integração com

de dados uma regra de negócio um teste automatizado isso Lembrando que nós temos equipes multifuncionais e quando necessário nós vamos adaptar o XP isso é possível Dentro do XP também desde que você consiga medir essas alterações se elas melhorar o desempenho do processo como um todo ou não Da mesma forma nós temos algumas regras XP que tem a ver com o design de objetos né com eu tô usando a palavra design aqui por causa do problema de tradução né design quando eu tiver falando design tô falando de workflow de design onde você por exemplo Consegue

projetar melhor os objetos os métodos e a interação entre esses objetos para realização de uma determinada história de usuário ou de um cenário de caso de uso e para isso a gente pode usar princípios grp pode usar design patterns pode usar tdd pode usar refactory pode pode usar domain driven design existem diversas técnicas de design eu não quis traduzir design Como projeto para não confundir com a definição de projeto pboc que é um Empreendimento com início com fim que produz um resultado serviço ou produto no final o design que eu tô falando aqui é no

sentido de projeto de objetos e no caso de XP nós temos algumas regras para design também principalmente a questão da simplicidade nós vamos Sempre buscar designs que funcionam mas que seja os mais simples possível nós vamos usar uma metáfora do sistema então Teoricamente o produto final que vai ser produzido dentro XP é uma metáfora que é compar ol Ada entre desenvolvedores e entre gerentes delimitando assim a forma do seu produto o XP usa muito a técnica de cartões CRC classe e responsabilidade dos colaboradores nessas sessões de design não é à toa né porque o artigo

principal de C CRC é um artigo do Kent be autor do XP que foi publicado no Ups Se não me engano em 96 que é um uma conferência muito famosa dentro da área de engenharia de software dentro do XP também nós podemos criar o Que é chamado de spikes basicamente são protótipos que são funcionais caso você tenha uma determinada história do usuário que possa agregar muito risco pro seu projeto o XP recomenda a criação de protótipos funcionais para minimizar ess riscos e facilitar as estimativas esses protótipos funcionais são chamados de spikes no XP nenhuma funcionalidade

no XP é incluído de forma antecipada no sentido que nós só vamos atacar focado em Objetivos aquilo que tem que ser desenvolvido funcioná especulativas que nós acreditamos que possa agregar valor no futuro mas ainda não estão certas não são incluídas no projeto Logo no início a partir do momento que nós vamos ganhando maturidade com o desenvolvimento do software e que as ideias vão se tornando mais claras aí sim nós vamos incluir incluindo essas funcionalidades E mais uma vez a gente vai também sempre Refatorar quando possível a refatoração produz designs melhores isso é um dos objetivos

do XP Então refactor faz parte tem iní dentro do mtodo XP até porque o XP trabalha com o conceito de test driven development e uma das etapas do test D develop é justamente a refatoração nós temos também algumas regras no XP com que tange a codificação basicamente XP recomenda no início do projeto Nós criamos O nossos padrões de codificação para tornar os Por exemplo os ref mais fácil Se todos trabalham com mesmo padrões de codificação manutenção do nosso código fica muito mais mais fácil primeiro nós vamos criar o teste unitário antes do teste antes do

do código que vai passar no teste Lembrando que o XP trabalha com conceito de tdd testes automatizados o tempo todo e escrito antes do código para passar nesses testes todo o código de produção no XP é desenvolvido com programação em pares existe alguns Artigos que demonstram que quando nós trabalhamos em pares Apesar de o tempo cair eu tenho um artigo basicamente que mostra que o tempo de forma empírica de desenvolvimento quando você tem programação em pares cai n cai mais ou menos 88% a produtividade do seu time Entretanto a taxa de erros produzido quando você

tem uma equipe que trabalha com programação pares cai pela metade do que como se tivesse programando de forma individual ou em outras palavras XP Recomenda e na verdade XP trabalha o tempo todo com programação em pares de forma que apenas um par vai integrar esse código por vez e as integrações vão ser sendo feitas com frequências com frequência todo código sendo produzido tá sendo integrado quanto antes com os testes de aceitação e integração sendo executados automaticamente é por isso que o XP trabalha muito com conceito de integração contínua de forma a automatizar essas integrações de

forma Frequente assim nós vamos ter um você nós vamos ter que configurar no ambiente um servidor de integração contínua seja o woodson seja o Cruise control ou seja qualquer outra tecnologia para integração contínua nó nós vamos ter um servidor dedicado justamente para esse fim para que quando a gente consiga fazer o comite de uma de um requisito dentro do nosso repositório automaticamente o nosso servidor de integração contínua entre e Ação fazendo Todos os testes necessários para colocar o código em produção e nós também usamos o conceito de propriedade coletiva do código né quando nós trabalhamos

em equipe Ninguém é dono do código O código ele tá disponível para todos todos podem alterar o código dentro do repositório apenas com uma premissa os testes de unidade os testes de integração os testes de aceitação eles devem passar para todas as alterações feitas em cima do Código já que falamos de testes nós temos algumas regras para testes também presentes no XP então todo código XP tem que ter teste unitário todo código então tem que passar pelos testes unitários antes de ser liberado quando nós encontramos algum bug novos testes são criados para atender para resolver

esse problema e os testes são executados frequentemente e os resultados desses testes são Publicados aqui eu tenho uma figura clássica do XP que basicamente é o ciclo de vida é só para entender basicamente Então tudo é focado em histórias de usuário para fazer o planejamento da minha liberação dependendo do risco de uma história de usuário nada impeça que eu faço um Spike um protótipo funcional para tentar Minimizar esses riscos a partir do momento que eu faço o Planejamento dentro das minhas iterações nós vamos escrevendo o código e vamos escrevendo os nossos testes e inclusive no

final nós temos que passar todo o código pelos testes de aceitação se os nossos códigos passaram pelos testes de aceitação nós vamos ter a aprovação do cliente e assim uma liberação do nosso código como todo processo do XP é focado em histórias de usuário que além de determinar os requisitos prescreve os os cenários para Os testes de aceitação eu acho que vale a pena discutirmos um pouco das questões de histórias de usuário Então as histórias de usuários são as eh são formas que nós temos para capturar requisitos levantar requisitos dentro do método ágil conhecido como

XP para quem ainda não conhece que tá mais acostumado talvez com caso de uso um caso de uso possui vários cenários cenários de sucesso e cenários de insucesso fluxo principal fluxo Alternativo vocês podem imaginar uma história de usuário como seo uma Instância particular um cenário em particular de um caso de uso por exemplo se eu tenho um caso de uso do tipo processar venda eu vou ter vários cenários processar venda com dinheiro processar venda com cartão processar venda com pagamento em cheque ou alguns cenários inclusive que não vão dar certo por exemplo cartão inválido ou

Saldo insuficiente para no seu cartão de Débito cada um desses cenários em particular dentro do caso de uso Global processar venda é conhecido como história de usuário existe algumas diretrizes para nós trabalharmos com histórias de usuário a mais famosa delas é o acrônimo investe de forma que a gente tem que investir em boas histórias cada letra desse acrônimo possui um significado que nós vamos discutir em breve então no XP os requisitos são normalmente capturados Com histórias de usuário que nada mais é do que uma descrição dos objetivos do usuário para com o sistema Então as

histórias de usuário são parecidas com as descrições de funcionalidades e elas destacam o papel do usuário o objetivo que eles estão tentando atingir e o valor desse objetivo inclusive existe um template PR escrita de história de usuá de usuário como fornecido pro Mike con no livro talvez mais famoso de histórias de Usuário que é US user source explained ou user source applied falhou agora exatamente o número do livro que é um livro específico sobre histórias de usuário escritos pelo Mike Kong que é um livro o cara muito famoso também na área de planejamento e estimativas

ágeis então o template proposto é enquanto tipo de usuário Eu quero um determinado objetivo para atingir algum valor nós vamos usar esse template para escrever nossas histórias de usuário nas reuniões De planejamento de iterações ou planejamento de Sprint se você assim preferir e nós vamos ver que são os clientes auxiliados pelos gerentes que escrevem as histórias do usuário bem como suas seus testes de aceitação da mesma forma que nós temos casos de uso bem escritos e casos de usos mal escritos nós temos histórias de usuário que são boas e histórias de usuários que são ruins

então um autor chamado Bill wake aconselha o acrônimo Investe no momento que nós fomos trabalhar com histórias de usuário basicamente o Invest significa e de Independente de forma que nós temos que evitar dependências entre as histórias escrevendo histórias para estabelecer o alico do sistema e combinando histórias similares em uma única interação qu apropriado as histórias devem ser negociáveis pois lembrando sempre histórias usuário não são contratos e muitos dos detalhes sugerem Que não existe mais nada a explorar então basicamente uma história do usuário não tem muitos detalhes tem apenas aquele objetivo e o valor que você

quer atingir com aquele objetivo E caso seja necessário determinado outro momento nós vamos detalhar essas histórias para o melhor entendimento então nós temos que lembrar que quando a gente tá falando de história usuário a gente tá falando de negociação pois nós não estamos usando História usuário como contrato É apenas uma forma de entender melhor o que deve ser feito numa negociação com o seu cliente uma história do usuário também tem que ser de valor ela tem que ser valorosa pois ela deve exibir o valor da história para os clientes e para outros stakeholders a letra

e é que as histórias os usuários devem ser estimáveis então nós vamos apresentar detalhes suficientes para a estimativa do esforço de trabalho nada mais do que Isso então as histórias devem ser pequenas para ser estimadas mas também a gente não vai trabalhar com histórias muito muito pequenas Talvez o nível de granularidade seja justamente o objetivo do ator perante um cenário e as histórias dos usuários também devem ser de tamanho correto Por isso elas devem ser pequenas o suficiente para serem completadas dentro de uma iteração nós não recomendamos por exemplo histórias maiores e que sejam Necessários

por exemplo mais de que duas semanas para poder implementar uma determinada história e lembrando também que quanto mais próximo de se trabalhar em uma história mais específica ela deve ser nós vamos ver quando for falar um pouco de scrum que as histórias podem iniciar Em um nível mais alto de abstração chamado Epic depois elas são quebradas detalhadas dentro do momento oportuno e o t última letra do acrônimo Investe indica que a nossas histórias de usuário devem ser testáveis e que os critérios de aceitação devem estar presentes dentro de minha história e que os testes devem

ser automatizados sempre que possível então seguindo o template de história de usuário uma história de usuário ela tem o template de enquanto papel eu gostaria de fazer algo para obter algum benefício E além disso além de escrever Nós usamos também a as condições de aceitação ou em alguns casos nós podemos ver até um desenho de um layout de uma determinada tela para atender aquela história do usuário ou até mesmo uma narrativa no formato talvez de cenário de fluxos para entendermos aquela história Lembrando que histórias não são contratos são apenas formas de termos uma negociação mais

fácil com os nossos clientes por exemplo uma história chamado pesquisar catálogo poderia ser Algo do tipo enquanto usuário registrado eu quero poder pesquisar usar o catálogo online ATRS de itens para compras dentário pode ser estimativa valor de negócio qualquer métrica que eu queira usar para valorizar essa história é muito com comum usarmos esses cartõezinhos para podermos indexar e para criar essas histórias dentro de reuniões de planejamentos de requisitos no verso do cartão nós podemos ter várias coisas já vi já vi artigos Mostrando no verso cartão inclusive um layout de uma tela ou aqui por exemplo

já vi questões de tipo de forma de narrativa muito parecido para quem tá acostumado com caso de uso né de mostrar exatamente qual que é o fluxo dentro daquela história de usuário Mas o mais importante é que as histórias têm que ter testes de aceitação por qu esses testes de aceitação junto com o conceito que nós vamos aprender quando for mostrar o scrum que é chamado definição De pronto são usados em conjuntos para que o time desenvolvimento consiga realmente ter uma ideia se aquilo que foi pedido foi implementado de forma correta ou não dentro da

iteração por exemplo um teste de aceitação que nós poderemos ter é que osos devem estar disponíveis em até 5 segundos ou seja tenho um requisito não funcional aqui que dever atendo dentro do meeste de Aita SC mtodo ávido por kaber com auxílio de Jeff Shut que prescreve um Método para planejament execução monitoramento e aperfeiçoamento dos nossos projetos de desenvolvimento de software ele é um método que prescreve alguns papéis importantes para o desenvolvimento de software com qualidade que o Ken schwaber e Ken schuab distinguiu esses papéis entre os chamados porcos e galinhas basicamente A ideia é

que os porcos são aqueles papéis que realmente desempenham o trabalho no Dia a dia e que realmente estão muito envolvidos com o projeto as galinhas por outro lado São pessoas que podem ter algum interesse no projeto mas não estão envolvidos no dia a dia são os stakeholders que T uma parcela de desejo uma parcela uma fatia de funcionalidade que gostaria de que o projeto atendesse mas que não estão envolvidos diariamente dentro do desenvolvimento do projeto nós vamos ver um pouco mais para frente que Por exemplo o papel do screw master é justamente proteger dentro um

dos papéis é justamente proteger o time scrum de interferências internas das Galinhas que são pessoas que têm interesse Mas que não estão envolvidas dentro do processo conforme vocês podem ver pela figura um dos papéis importantes do scom e na verdade muito importante é o product owner também conhecido como po que é a pessoa responsável por gerenciar o product backlog e assegurar o valor do Trabalho desenvolvido pelo time dentro das responsabilidades do Product nós podemos destacar a descrição e definição das funcionalidades do software é o prod backlog é o o product owner que vai concentrar as

informações vindas dos stakeholders do sistema é o product owner a pessoa responsável pelo retorno de investimento do projeto do Hoy é ele o responsável por priorizar os itens presentes dentro do Product backlog conforme nós vamos discutir um pouco Mais para frente cabe ao product Town e ele tem essa autoridade de alterar as prioridades que estão fora do Sprint não atrapalhando assim o objetivo do nosso time e É ele que vai aceitar o eitar os resultados do trabalho nós temos também conforme vocês podem ver pela figura o papel que é o time de desenvolvimento né é

o time scrum o time scrum nada mais é do que um grupo de pessoas diretamente ligadas ao Trabalho a ser feito ou seja são porcos como características principais desses times scrum é que eles devem ser multifuncionais e auto-organizáveis Ken shaber fala no número mágico para o tamanho de um time scom ele é formado por até sete pessoas você tendo uma uma liberdade de aumentar mais duas ou menos duas pessoas ou em outras palavras um time scrum ideal varia entre CCO e nove pessoas cabe ao time definir em colaboração com os demais papéis do scom O

objetivo para cada Sprint E conforme nós vamos ver Sprint apenas o nome dado no scrum para o conceito já conhecido por todos nós que é o conceito de iteração então toda a interação no scom é conhecido como Sprint e cabe ao time definir qual que é o objetivo de cada Sprint especificando os resultados do Trabalho há um comprometimento do time em atingir o objetivo que foi definido para aquele Sprint de forma que no final Do Sprint ou no final da iteração cabe ao time demonstrar o resultado obtido dentro daquele Sprint para o product owner e

os demais stakeholders outro papel importante do scom é o scom Master que é o papel que desempenha um papel de liderança gerenciando os interesses do Product owner mediante a equipe dentre as funções do screw master nós podemos destacar a colaboração Intensa com product owner e com o time de Desenvolvimento cabe ao scrum melhorar o bem-estar e a produtividade da equipe de desenvolvimento promovendo a criatividade e o conhecimento uma das características chave dentro de métodos Aris é você promover a questão da criatividade do próprio time de desenvolvimento e cabe também ao esrum estimular uma comunicação e

cooperação entre todas as pessoas envolvidas Entre todos os membros da equipe além conforme já dito de proteger a equipe de Interferências externas principalmente das Galinhas que T interesse no projeto mas não estão envolvidas diretamente na sua realização cabe ao scrum também remover qualquer impedimento que possa surgir no dia a dia de desenvolvimento do scrum que esteja impedindo ou que estejam fazendo com que a produtividade do time de desenvolvimento caia cabe a screw Master eliminar todas as barreiras necessárias para que o time possa trabalhar tranquilo e focado no objetivo Do Sprint outra característica importante e é

uma função do scw master é garantir que os princípios e as regras do scom do scom estão sendo respeitados é ele que realmente faz a verificação se o scom está sendo utilizado se o processo scom tá sendo utilizado da forma adequada e também é papel do scom master convidar auxiliando product a as pessoas apropriadas para as diversas reuniões presentes dentro do scom que nós vamos discutir um pouco mais para Frente que são as reuniões diária reuniões de revisão de Sprint reuniões de retrospectiva do Sprint e reuniões de planejamento do Sprint assim um dos principais uma

das principais funções do skm conforme dito é remover as barreiras entre o time de desenvolvimento e o cliente auxiliando o product no no sentido de direcionar o product owner para as funcionalidades que deverão ser desenvolvidas e que vão Maximizar o retorno de investimento para atingir os objetivos com scr também Cabe ao product também Cabe ao screw Master promover as práticas de engenharia de S para que cada pedaço da funcionalidade que foi priorizado pelo seu cliente seja potencialmente plantável de acordo com o scom é impossível não é certo chegar no final de uma Sprint no final

de uma interação entregarmos apenas documentação para os nossos clientes para o product Own nós Temos que entregar código funcionando que na terminologia do scom é chamado de potencialmente funcionalidade potencialmente implantável tendo ilustrado os papéis cabe agora nós discutirmos um pouco dos artefatos presentes dentro do método ágil para planejamento e acompanhamento de projetos conhecido como scom conforme vocês podem ver pela figura nós temos alguns artefatos chave que são imprescindíveis para o bom funcionamento Funcionamento do scom dentre eles Podemos destacar a visão do produto o product backlog o plano de liberações print backlog o Sprint e o

release burndown e a lista de impedimentos vale a pena ressaltar que a visão do produto não está definido dentro do scrum entretanto em um dos livros do Ken schwab ele cita a visão do produto como uma artefato de entrada inicial para a primeira reunião de planejamento de Sprint para que assim na primeira Reunião eu possa ter uma ideia pelo menos do que que deve ser feito pelo menos o estudo de de viabilidade já foi feito para que eu consiga realmente dessa forma startar o método scom que dentro de um projeto em particular além da visão

do produto em algumas literaturas também nós encontramos que a a entrada pro scom principa fato de entrada pro scom para startar o scrum e alguns autores não falam que é a visão do Produto alguns autores usam o conceito de business plan que na verdade o business Case que é o caso de negócio mas que conforme vocês podem já tá percebendo são documentos iniciais apenas para que possamos entre outras em outras palavras iniciar o processo de scrum pois nós vamos ver daqui a pouco que na primeira reunião do scom que vai iniciar o meu projeto é

produzido um artefato chamado product backlog e esse product backlog Nada mais é do que um detalhamento por exemplo do que está presente dentro da Visão do seu produto então todos esses artefatos nós vamos discutir um pouco com mais detalhes um pouco pra frente aqui apenas uma apresentação inicial para terem uma ideia que do quão simples é o método no sentido de artefatos que deve ser produzidos e que deve ser monitorados controlados e cuidados no decorrer do ciclo de vida do projeto além de Artefatos existe alguns conceitos que são muito importantes dentro do scrum e eu

vou discutir um pouco desses conceitos com vocês para ficar um pouco mais claro como que isso deve ser feito o scrum trabalha com o conceito de Box o time Box é um conceito muito importante para o acompanhamento quando nós definimos um objetivo em um período de tempo nós estamos forçando a equipe a se concentrar naquilo que é mais importante sem gastar tempo com coisas Desnecessários para objetivo assim o time Box é um pilar muito importante do scom que agrega valor de negócio num curto período de tempo tendo em vista que todas as atividades previstas dentro

do método ágil scum são cronometradas possuem uma fatia de tempo bem estabelecidas conhecido como Time Box nós vamos ver por exemplo se as reuniões diárias devem ter no máximo 15 minutos enquanto que uma reunião de planejamento de Sprint é dividida em duas sub Reuniões diremos assim de 4 horas cada tudo no scrum é cronometrado outro conceito muito importante dentro do scrum é o conceito de impedimentos que nada mais é do que qualquer tipo de problema que uma pessoa da equipe possa estar enfrentando impedimento impedindo que ele consiga atingir Air o objetivo que foi prescrito para

aquele Sprint particular esses impedimentos devem ser reportados diretamente ao scw Master que é o o Responsável que é o papel responsável por remover Essas barreiras podendo inclusive obter auxílio do Product owner para para isso outro conceito muito importante dentro do scr é a definição de pronto nós vamos ver que o product backlog é o principal artefato do Product é onde nós nossas listas de funcionalidades que deverão ser implementadas no nosso sistema os itens mais importantes desse prod backlog são as principais Funcionalidades do sistema e eles podem ser descritos na forma de casos de uso de

cenários de histórias de usuário características de sistema ou outras técnicas de levantamento de requisitos Mas como que o time sabe que Um item que está presente no prod backlog está pronto o detalhe aqui é que o time juntamente com screw Master e em concordância com o product owner deve ter a sentença daquilo que o projeto define como Pronto é muito importante ter em mente que o scon não considera funcionalidades 50% realizadas como é normal nas abordagens tradicional de gestão de projetos principalmente se você usa diagrama G grand grand shart Um item no scrum só está

pronto quando é potencialmente plantável de acordo com a definição de pronto e por isso nós devemos lembrar que o scrum é direcionado por objetivos e não por tarefas como é muitas vezes visto em Gestão de projetos tradicionais isso é muito importante Pois é muito comum que os desenvolvedores acharem que ao terminar uma codificação a funcionalidade está pronta no scrum a funcionalidade do prod backlock só está pronta quando estiver potencialmente implantável ou em outras palavras quando tiver o potencial de entrar em produção assim que o product decidir e ele vai decidir Com base no critério que

nós definimos de Pronto para ficar um pouco mais mais palpável diremos assim algumas definições de pronto poderia ser ah a história de usuário ou o cenário de caso de uso que vai ser implementado dentro do Sprint tem que est analisado projetado implementado e refatorado uma segunda definição de ponto de pronto que seria compartilhado por todos do equipe inclusive product Town né scr time de desenvolvimento poderia ter sido feito os testes unitários de aceitação e Gerada documentação de usuário uma outra definição de pronto poderia ser você ter builds integrados com a camada de apresentação negócio persistências

e recursos ao final da sua iteração o importante é saber que a definição de pronto ela tem que estar disponível para todos visível para todos para facilitar o entendimento do que deve ser realmente feito dentro daquele Sprint lembrando mais uma vez que o foco em objetivos é um dos pilares Importantes do scrum um time que realmente segue a metodologia scrum o método scrum planeja baseado em objetivos executa tarefas baseadas em objetivos e reporta o andamento do projeto baseado em objetivos e não em porcentagens agora que já entendemos um pouco dos papéis dos artefatos principais e

de alguns conceitos que são muito importantes dentro do scrum nós estamos prontos para entender um pouco mais do ciclo de vida de um projeto que É planejado executado monitorado e aperfeiçoado utilizando método ágil scom então conforme vocês podem ver aqui o scrum é um método ágil que é iterativo e incremental no sentido que você tem uma forma de uma espiral então para iniciar o projeto nós temos um Business Case ou um documento visão que serve como entrada paraa primeira reunião dentro do método que é reunião chamado Sprint planning ou reunião de planejamento de Sprint basicamente

O objetivo dessa Reunião é detalhar os requisitos priorizá-los e estimar o esforço necessário para a realização dos mos dentro do seu Sprint essa reunião nós vamos ver que ela demora um dia inteiro ela é dividida em duas partes de 4 horas cada e no segundo dia é que realmente começa o Sprint no sentido que é a partir do segundo dia que realmente códigos e testes automatizados são inscritos pelo time de desenvolvimento então no Decorrer do Sprint várias coisas acontecem a cada dia do Sprint é feita uma reunião diária de 15 minutos que nós vamos discutir

daqui a pouco que tem alguns objetivos básicos de funcionar como um ponto de inspeção diário dentro do scrum é dentro do Sprint do dia a dia que o desenvolvimento todo éfeito e o que é muito importante notar é que enquanto o time de desenvolvimento e scr m estão trabalhando no dia a dia com Sprint o Product aer está fazendo grooming o detalhamento do Product backlog para a próxima reunião de Sprint paraa próxima reunião de planejamento de Sprint que vai acontecer no próximo Sprint no final do Sprint é feito uma reunião de revisão do Sprint é

onde é apresentada as funcionalidades desenvolvidas para o product owner caso elas sejam aceitas nós temos um incremento de produto que pode ser que de acordo com o kab é chamado de potencialmente implantável Ou Seja é um software que foi entregue pro cliente que caso o cliente queira já pode colocar em produção e para finalizar o ciclo de um Sprint nós temos a reunião de retrospectiva do Sprint que é o ponto do scr onde você pode aperfeiçoar o próprio processo verificando o que que deu certo o que que deu errado dentro daquele Sprint Para poder melhorar

para a próxima reunião de planejamento do Sprint que começa no próximo dia útil e Assim o ciclo se repete aí voltamos novamente para a reunião de planejamento do Sprint onde os itens são priorizados e estimados volta novamente para o desenvolvimento dessas funcionalidades dentro do Sprint no final faz a revisão e finalmente a retrospectiva do Sprint aperfeiçoando cada vez mais assim o ciclo de vida eu vou falar um pouco mais detalhes nos slides que se seguem basicamente de cada uma dessas etapas prescritos dentro dessa figura desse Ciclo de vida interativa incremental Lembrando que o scon também

dá preferência para sprints curtos quanto menor melhor para você ter uma aproximação cada vez maior do seu cliente é típico você ter Sprint de no máximo um mês calendário talvez 20 20 e Poucos dias úteis mas é muito comum também equipes trabalharem com uma ou duas semanas no tamanho do seu Sprint então falando um pouco sobre a iniciação do Projeto que é é a entrada que nós temos para a primeira reunião que é reunião de planejamento do Sprint que tem como objetivo a criação do Product backlog então conforme discutido em vez de nós chegarmos nessa

reunião sem nada Teoricamente Nós já vamos para essa reunião paraa primeira reunião de planejamento do Sprint pelo menos com Business Case ou com o documento visão que vai demonstrar as principais funcionalidades os principais Stakeholders e o estudo de viabilidade para ver se deveremos investigar continuar a investigação ou não no projeto em questão então paraa criação do Product backlog que é a reunião de planejamento do Sprint nós temos todas as pessoas envolvidas né Nós temos o product T CL Master o team inclusive as galinhas os outros steakholders pois nós temos que identificar requisitos que vão ser

de interesse para todos aqueles envolvidos e o objetivo no final é Termos um product backlog priorizado estimado e detalhado de forma suficiente para que o time consiga quebrar esse PR backlog dentro de uma lista de tarefas que vão ser desempenhados no decorrer do Sprint assim dentro da reunião do planejamento do Sprint se pensarmos um pouco mais detalhado nós precisamos de todas essas pessoas envolvidas presentes pois nós vamos desenvolver o prod backlog Mas o mais importante que às vezes algumas Pessoas demor para entender é que no final da reunião do planejamento do Sprint o prod backlog

vai estar inteiramente estimado inclusive aquelas histórias de usuário aqueles requisitos que não entrarão no Sprint no Sprint corrente nós vamos ter todas as histórias estimadas os níveis de gradualidade vão mudar conforme eu vou mostrar para vocês daqui a pouco mas isso é importante porque com base nisso e com base com um outro conceito que eu Vou apresentar para vocês chama velocidade do time nós vamos conseguir produzir o chamado plano de liberação que vai ser basicamente um artefato de muito interesse do Product aer para ele ter uma certa previsibilidade de quando será entregue determinadas funcionalidades mesmo

que o Sprint dure uma semana o plano de liberação vai poder falar por exemplo que o seu projeto vai demorar talvez 20 ou no máximo talvez 30 sprints Isso vai ser Possível de ser respondido através do plano de liberação mas eu vou discutir isso um pouco mais paraa frente com vocês como prod backlog apesar de não ser único é o principal artefato produzido dentro da reunião de planejamento de Sprint vale a pena entender um pouco mais sobre esse artefato normalmente o prod backlog é uma lista de características de requisitos de funcionalidades que devem ser atendidas

Pelo sistema sendo desenvolvido normalmente é uma boa prática Nós escrevemos dos requisitos no scom com histórias de usuário que é a técnica de escrita de requisitos utilizado pelo método Extreme programming pelo XP mas nada impede isso aqui é muito importante nada impede que os requisitos presentes no prod backlog sejam escritos de outra forma nada impede que você tenha dentro do Pr backlog por exemplo alguma tarefa por exemplo de configuração do ambiente De desenvolvimento aquisição de determinada licença de software que seja descrito na forma de casos de uso e cenários de casos de uso ou até

mesmo que seja descritas as funcionalidades previstas através de características de sistemas tudo isso está de acordo com o scom embora o scom recomende eh acredita-se que tem um funcionamento melhor quando os requisitos são escritos através da técnica de história de usuário prescrit pelo KB No método XP Lembrando que os requisitos presentes no PR backlog as histórias presentes no prod backlog serão priorizados por valor e serão estimados pela equipe aqui é algo interessante que quem prioriza os itens do Product backlog é o product owner Mas quem estima o esforço necessário não é o product owner é

o time de desenvolvimento a responsabilidade do prod backlog é do prod a ele que o responsável pel retorno de investimento Do projeto então ele é responsável pela priorização e dos itens do prod backlog assim o prod backlog tem que ser trabalhado de forma intensa pelo product mas mais uma vez Muitas das coisas do SC trabalham no sentido de colaboração nada impede de que haja uma colaboração intensa Entre todos os envolvidos no time de desenvolvimento scrum para produzir um produto backlog adequado dentro da reunião de planejamento de Sprint então de maneira mais formal a Reunião de

planejamento de Sprint é onde todas as pessoas estão envolvidas com o objetivo de criar o prod backlog o plano de liberação e o Sprint backlog que eu vou destacar daqui a pouco então detalhando um pouco mais essa reunião de planejamento do Sprint nós devemos lembrar então que o todo Sprint no scrum inicia com planejamento e esse planejamento é feito em duas partes na primeira parte o objetivo principal é a criação do Product backlog Priorizado na segunda parte nós definimos O que é chamado de Sprint backlog que é um artefato muito útil para o time de

desenvolvimento no planejamento dentro dessa reunião de planejamento todos os desenvolvidos planejam quais serão os objetivos a serem finalizados dentro daquele Sprint se o seu Sprint seja caso seu Sprint seja de 30 dias por exemplo é dentro desse planejamento que vai ser planejado quais serão os Objetivos a serem finalizados nos próximos 28 dias pois se o Sprint é de 20 dias o primeiro dia paraa reunião de planejamento de Sprint último dia pras reuniões de revisão do Sprint e retrospectiva do Sprint para tornar um pouco mais claro isso eu trouxe aqui uma outra figura que talvez dê

fique mais claro justamente Como que é o funcionamento da reunião de de planejamento do Sprint E como que ela é Subdividida então dentro da primeira parte da reunião de planejamento do Sprint o screw Master e o product owner define verifica e detalha esse artefato conhecido como product backlog Lembrando que esse prod backlog pode ser representado em um documento comum ou uma planilha onde constam todas as funcionalidades do sistema já na segunda parte da reunião o screw Master o te o product sendo que product é opcional Nesse caso eles se reúnem para o Planejamento do Sprint

baseado no produ backlog que foi criado ou que foi atualizado sendo que o product Town screw Master apenas define a ordem das coisas não os prazos tendo em vista que os prazos estimativas são feitos pelo time de desenvolvimento uma outra forma de enxergar essa reunião é que na primeira parte da reunião a conversa deve focar no retorno de investimento do projeto nessa parte o trabalho de ordenar o product backlog é Uma importante tarefa pois o product Own decidirá aquilo que agregará mais valor ao software para ser entregue no final do Sprint eu trouxe aqui uma

figura que Talvez possa ilustrar isso melhor conforme pode ser visto o product backlog nada mais é do que uma lista de funcionalidades no meu caso aqui Teoricamente eu tô escrevendo no formato de casos de uso mas depois eu vou migrar paraa história de usuário para inclusive Ilustrar um pouco a diferença entre essas duas técnicas então na primeira parte nós poderíamos ter esse product backlog Inicial que poderia ter visto por exemplo de um documento visão Lembrando que um product backlog na primeira a prioridade é de cima para baixo ou seja os itens na parte superior desse

artefato possuem maior valor de negócio e vão ser detalhados dentro da reunião na segunda parte da reunião nós vamos selecionar quais itens Potencialmente implantáveis serão implementados dentro do Sprint o time vai fazer uma Estimativa de esforço para esses itens e verificar Quais são aqueles itens que serão passíveis de ser transformados em produto potencialmente plantável dentro do Sprint então caberá ao time fazer estimativa desses itens usando por exemplo uma técnica de estimativa relativa como plan poker que é muito usado dentro do scom que é uma técnica que vem também do met XP e cabe Na segunda

parte então da reunião o time de desenvolvimento quebrar cada um dos itens selecionados priorizados aqui no product backlog pelo product aer em tarefas menores que podem ser cumpridas talvez de no máximo 8 horas de trabalho os itens que aparecem no prod back são qualquer tipo de funcionalidade ou tarefa que possua um valor para product owner conforme eu já mencionei E lembrando que a funcionalidade Potencialmente implantável significa que quando Um item do prod backlog for finalizado ele estará completamente funcional e resolvendo algum problema de negócio dos nossos stakeholders assim na segunda parte da reunião de planejamento

do Sprint nós precisamos Então estimar os itens do prod backlog quem faz dessas estimativas são os membros do time de desenvolvimento scrum lembrando que quando nós se o time Que vai desenvolver nós temos que ter técnicas para poder fazer estimativas em GR em grupo nós temos um problema com estimativas e grupo é porque às vezes o impacto que a opinião de uma pessoa tem sobre a outra às vezes você tá fazendo uma estimativa você fala que aquilo às vezes uma pessoa muito respeitada dentro do próprio grupo ele dá uma estimativa X para determinada funcionalidade aí

todos AC acanham ele acreditando que ele está correto na sua estimativa para evitar Esse problema existe uma técnica que chamada plan poker que permite que a estimativa seja feita de forma conjunto sem influência de um sobre o outro basicamente A ideia é que cada membro do time de desenvolvimento vai receber um conjunto de cartas com alguns números normalmente é muito usados os números da sequência de fibona 1 2 3 5 8 13 e assim sucessivamente embora outros números sej possíveis e na literatura nós temos até exemplos de pessoas que usam coisas do Tipo x XL

ou ou seja usando tamanhos de camisa de roupa para poder fazer essas estimativas de esforço para determinadas funcionalidades então na técnica de plan poker é uma escala bastante usada a escala de Fibonacci principalmente porque ela não deixa muitas dúvidas na escolha de um número que represente o esforço em particular eu não recomendo por exemplo o uso de números 13 e 21 pois quanto maior foi esse número mais difícil o Planejamento dos nossos sprints e trabalhar com objetivos menores permite uma gão melhor de e uma estimativa mais precisa mas nós vamos ver Que itens que não

vão ser trabalhados na no Sprint corrente ou seja que já estão previstos mas que irão ser trabalhados apenas no futuro um pouco mais distante para isso nós usamos algumas cartas maiores que são conhecidas como temas e epics então nós estimamos esses temas apps com cartas com números por exemplo 20 30 50 100 e assim sucessivamente então a ideia dentro do plo poker Então eu tenho o scrum junto com o meu time de desenvolvimento e cabe a eles fazer estimativa o product Own não pode estar presente justamente para não influenciar o time de desenvolvimento A ideia

é foi foi priorizado uma funcionalidade a do backlog o time vai estimar E para isso cada membro da Vai Ter suas próprias cartas e o scrum Master vai apresentar Qual que é o item que tem que ser estimado todos vão refletir e ao mesmo tempo vão mostrar as suas cartas de acordo com o esforço que eles acreditam que seja necessário para realizar aquela funcionalidade tornar ela no produto potencialmente implantável então cada um vai colocar a sua opinião acerca do que que é necessário para transformar Aquilo num produto potencialmente plantável A ideia é a pessoa que

mostrar a a carta com maior número que acredita que aquela Funcionalidade Vai demandar um esforço maior e explica por ele acredita isso a pessoa que apresentar a carta com menor número indicando menor esforço também explica so os motivos pelo qual ele estimou daquela forma e todos escutam essas argumentações e fazem várias rodadas de plan por em cima da mesma história até que Teoricamente você con consiga convergir essas estimativas para um valor muito parecido no meu caso aqui do exemplo a pessoa que colocou a carta Três e a pessoa que colocou a carta oito explicariam seus

motivos todos refletiriam e mostrariam pensariam e jogariam novamente todas as cartas mostrando ao mesmo tempo até que estabilizasse essa estimativa então utilizando a técnica de plan poker nós poderemos ter por exemplo uma determinada história do usuário suponhando Um item do Pr backlog chamado pesquisar catálogo que foi estimado pelo time de desenvolvimento por exemplo aqui Nós temos o esforço dado de tamanho 3 e a história é bem simplesinha que enquanto usuário registrado eu gostaria de pesquisar o catálogo online atrás através atrás de itens para aquisição o time estimou com TRS E conforme vocês podem ver eu

t na segunda parte da reunião do Sprint nessa segunda parte o objetivo é estimar o esforço necessário para que aquela para aquele item do Pr backlog possa formar em produto potencialmente implantável é muito Importante vocês perceberem que a medida que eu for descendo para do backlog a granularidade vai aumentando então Teoricamente a granularidade ideal para um item do prod backlog É no sentido de uma história de usuário na medida que eu vou descendo no PR backlog eu vou tendo a granularidade aumentada por exemplo o item 4ro aqui efetuar pagamento tá muito parecido como um objetivo

do usuário no formato de caso de uso enquanto que essas histórias aqui para cima estão no Formato mato de história de usuário para quem ainda não sabe um pouco a diferença uma forma talvez inicial de começar a entender a diferença é que um caso de uso pode ter n cenários cenários de sucesso e n cenários de insucesso uma história de usuário seria uma Instância particular de um cenário ou ou de successo ou de de insucesso então outra coisa importante vocês podem perceber então que por exemplo a equipe pode ter determinado que ela acredita que nesse

Sprint que tá sendo que vai começar no dia seguinte o desenvolvimento a equipe tá achando por exemplo que vai conseguir fazer essas três primeiras histórias cujo esforço é 8 3 e 1 as outras histórias talvez não sejam passíveis de ser implementados dentro do desse Sprint então vai ficar pro Sprint 2 3 4 5 etc a grande sacada do SC é que essas histórias que não serão implementadas logo nessa iteração logo nesse Sprint elas devem ser priorizadas Com cartas maiores por quê Porque nós estamos usando estimativa relativa ou em outras palavras eu não preciso detalhar esses

itens aqui no prod backlog eu só vou detalhar os itens que eu vou trabalhar dentro daquele print colocando numa granularidade de história de usuário os itens lá para baixo eu vou detalhar no momento oportuno Quando essas necessidades realmente foram priorizadas pelo product owner outra questão interessante da estimativa Relativa é que se se o meu time tá dizendo que a História dois tem esforço três e a história 3 se a esforço um é que Teoricamente o time tá achando que o esforço necessário para realizar História dois é três vezes maior que o esforço necessário para realizar

história um o esforço necessário para realizar a história um Talvez seja duas vezes e meia maior do que forço necessário para resol resolver a história do e assim sucessivamente eu tô Fazendo estimativa relativa eu feiz uma estimativa x eu faço a estimativa da outra história com base relativo a essa base que eu iniciei para essa estimativa anterior uma grande sacada do scrum e aqui eu trouxe uma figura do livro famoso do Mike k que é sobre planejamento e estimativas ágeis é dentro desse livro Mike con apresença aenta essa figura que é bastante interessante basicamente o

que a figura quer dizer é que a partir do momento que Você começa a investir muito esforço para fazer alguma estimativa existe um momento que a acurácia dessa estimativa você vai ganhando um valor máximo ou seja quanto mais você vai detalhando Mel vai ficando sua estimativa só que tem o máximo essa função ou em outras palavras vai chegar em um momento que não adianta você ficar gastando muito tempo estimando detalhando as tarefas e estimando porque nesse momento a sua curaça vai começar a cair e a questão é Simples é só lembrarmos que requisitos mudam o

tempo todo no desenvolvimento de software então não compensa no início por exemplo de um projeto eu queria detalhar todos os itens do Pr backlog estimar todos aqueles itens sendo que assim na verdade vou est perdendo tempo vou est perdendo a coraç porque Muitos daqueles itens irão ser modificados no decorrer no curso do projeto dentro do scrum nós usamos algumas métricas e principalmente um Conceito chamado conceito de velocidade que vai nos garantir a obtenção dos prazos a partir de uma lista de funcionalidades uma das características interessantes do scom é que essas métricas elas são otimizadas com

equipes consistentes e que possuem baixa rotatividade a analogia com o futebol é muito comum né quando nós temos no futebol uma equipe que trabalha junto há muito tempo possui um conjunto melhor você acaba tendo o ritmo de jogo melhor E Teoricamente acaba conhecendo melhor acaba jogando melhor pois inclusive você começa já a saber aonde o seu companheiro de time vai estar localizado em determinado momento porque Vocês jogam muito tempo junto o objetivo aqui é o mesmo né quanto menos eu tiver rotatividade da dos membros da minha equipe talvez maior produtividade eu vou ter o que

não quer dizer que eu não possa ter rotatividade entre partes diferentes do me do meu Sistema Lembrando que a minha equipe é multifuncional e cada pessoa por exemplo pode pegar uma determinada tarefa dentro de todos seu ciclo de desenvolvimento do seu projeto uma pessoa pode pegar uma tarefa de banco de dados depois pegar uma tarefa de interface gráfica usuário aquilo que ela sentir mais confortável então é apenas lembrando então algumas métricas que nós temos dentro do scom são os conceitos de pontos velocidade e de prazo apenas Lembrando que uma ela pode ser objetiva ela pode

ser obtida através de uma medida de esforço e de velocidade para vencer esse determinado esforço ou em outras palavras eh nós dizemos que a velocidade é justamente a performance esperado dentro do Sprint e ela é obtida dividindo o esforço pelo tempo necessário é só lembrar da cinemática que distância é igual velocidade vezes o tempo a distância seria seu esforço dessa forma o tempo seria distância pela Velocidade ou a velocidade seria a distância dividido pelo tempo nós recomendamos que os o esforço não seja atrelado a uma unidade de tempo isso é chamado de esforço relativo Então

nós vamos ver que é muito comum pessoas tentarem fazer estimativas em horas e o que nós estamos falando até agora é usando apenas cartas de Fibonacci 1 2 3 5 e 8 nós estamos usando estimativas relativas para esforço relativo e não estimativas em horas mas eu vou discutir Isso com vocês um pouco mais para frente de forma melhor uma conceito interessante Então tendo a velocidade significando a performance esperada dentro do Sprint nós temos que lembrar que nessa performance já estão embutidas as restrições do ambiente os riscos e a produtividade da própria equipe assim para projetos

de software nós utilizamos pontos para medir o esforço do prod backlog e esses pontos Não existe relação com horas ess esses pontos são estimativas relativas de esforço e que representam o tamanho funcional e a complexidade técnica de Um item presente dentro do Product backlog então para descobrirmos qual que é a velocidade da nossa equipe para ir assim obter o prazo nós precisamos saber quantos pontos nós conseguimos vencer dentro de um período de tempo dentro de um Sprint Então os pontos que a equipe vai Fazendo dentro dentro do Sprint nada mais é do que a quantidade

de pontos que a equipe consegue entregar dentro do time box de aproximadamente 30 dias caso essa seja o tamanho da sua Sprint e lembrando também que nos primeiros sprints a incerteza com relação à produtividade da equipe é muito grande então para o primeiro Sprint nós simplesmente perguntamos ao time de desenvolvimento o que ele acredita conseguir entregar até o final Do Sprint para tornar mais claro pouco a discussão dessas métricas eu trouxe para vocês aqui uma figura de um prod backlog estimado apenas subconjunto prod backlog né só tô aqui as minhas estimativas só para vocês tentarem

entender um pouco mais Então suponhamos que a velocidade estimada pro meu time de desenvolvimento seja de oito pontos de história por Sprint Lembrando que na reunião de planejamento de Sprint todo o prod Backlog é estimado não só apenas aquilo que é possível de caber dentro do Sprint Então desse cenário se realmente a velocidade do meu time no desenvolvimento foi de oito pontos de história eu vou precisar do primeiro Sprint essas histórias do segundo Sprint essas no terceiro Sprint vou ter essas histórias no quarto Sprint essas histórias e no quinto Sprint essa última História então se

você olhar com calma aqui se nós pegarmos oito pontos por Sprint nós já temos uma previsão inicial do nosso prod backlog de cinco sprints pois o total de pontos se você somar Aqui nós temos 37 pontos a nossa velocidade estimada é de oito então o nosso prazo vai ser 37 di por 8 que vai dar mais ou menos 4,6 que é o equivalente a cinco sprints com isso nós podemos fazer então o que é chamado de plano de liberação Então nada mais o plano de liberação nada mais é do que talvez um Horizonte Um pouco

mais amplo para que o seu product possa ter um melhor controle de quantos sprints por exemplo que o projeto vai determinar ele poderia por exemplo indicar o product t n que seriam necessários Talvez o primeiro e o segundo Sprint para eu atingir um Marco talvez importante dentro do meu projeto e onde eu tivesse minha primeira release repare que isso aqui não tá em contradição com cons de produto potencialmente plantável no final de Cada Sprint eu entrego software funcionando pro meu cliente entretanto Pode ser que o meu cliente precise o deseje que eu tenha o resultado

de um ou mais sprints formando uma liberação para que realmente possa colocar alguma coisa no mercado Caso seja esse o desejo do meu cliente então uma vez estimado todo prod backlog com estimativas relativas em Pontos de história tendo feito plano de liberação da segunda parte ainda do planejamento Do Sprint o time de desenvolvimento tem que fazer um outro trabalho que é criar um artefato chamado Sprint backlog o Sprint backlog é o artefato produzido na segunda parte da reunião de planejamento de Sprint e que basicamente é refletido através de um quadro que é montado dentro do

ambiente desenvolvimento a cada Sprint Lembrando que dentro desse quadro o que vai acontecer basicamente é que nós vamos o time desenvolvimento vai Pegar uma história de usuário presente no prod backlog que foi priorizada e estimada e vai quebrar essa história em tarefas menores mensuradas muitas vezes em horas então nós temos dois tipos de estimativas no scrum se você for pensar os itens do prod backlog são estimados em Pontos de história e os as tarefas que são resultado da quebra dos itens do backlog dentro do Sprint backlog são mensuradas em horas isso lembrando sempre que todo

método de gestão de Projetos é baseado em planejamento execução controle e avaliação no scw isso não é diferente nós estamos agora planejando nós vamos na sequência executar controlar e no final do Sprint nós vamos fazer avaliação do nosso processo do que deu certo e do que deu errado então mais uma vez dentro do Sprint Pack log que é a segunda parte da reunião o artefato que é produzido cada item do prod backlog selecionado para o Sprint é quebrado em Tarefas menores mensurados em horas nós sugerimos que cada quebra individual não ultrapasse 16 horas quanto menor

sua tarefa mais rápido mais gerenciável ela se torna e mais rápido você vai ter um feedback saber se você tá no caminho certo ou não se você cria uma tarefa por exemplo de 24 horas quando você tiver trabalhado atravez de 18 horas na tarefa Você pode ter descoberto algum problema e não conseguir realmente com aquela tarefa e ter pedido talvez 18 horas de Trabalho Talvez uma coisa que poderia ter sido resolvido se tivesse sido quebrado em tarefas menores até para facilitar o trabalho em equipe Então se você for pensar o Sprint backlog nada mais é

do que a quebra de cada item do prod backlog em tarefas é importante ter essa noção de que o time deve consultar o screw Master e o product caso ele tenha dúvida então nós estamos na segunda parte da reunião reunião de planejamento do Sprint no Momento que você for quebrar as tarefas algumas dúvidas podem surgir então o product owner e o scrum deve estar disponíveis justamente para sanar essas dúvidas no momento que serão detalhados os itens do prod backlog dentro de tarefas o detalhamento ideal vai esclarecer tudo aquilo que é necessário para tornar o item

em algo pronto isso vai ocorrendo no decorrer do Sprint então conforme vocês podem ver pela A figura a história de usuário Pesquisar catálogo foi foi subdividida nas tarefas criar uma página de busca criar uma classe de consulta criar os testes unitários e criar um método para fazer essa busca Mas uma vez é muito importante que a definição de pronta seja compartilhada por todos porque a definição de pronto é uma das formas que nós temos de nortear justamente essa quebra de tarefas para ter uma ideia então melhor de como pode funcionar isso eu trouxe Aqui um

exemplo de como que é um quadro de um Sprint backlog então na primeira coluna tem a história do usuário que foi selecionado para esse Sprint o time de desenvolvimento quebra essa história em tarefas pequenininhas que serão desempenhadas ao longo do Sprint então é importante que no planejamento do primeiro Sprint ou numa fase inicial de concepção a maioria dos itens do prod backlog seja com uma estimativa inicial de esforse em Pontos De história mas nós vamos perceber que são necessários de três a quatro sprints para que a prod idade da equipe seja melhor adaptada à realidade

então nós fechamos assim a discussão da primeira reunião do scrum que é a reunião de planejamento do Sprint então no dia seguinte a reunião de planejamento do Sprint o Sprint propriamente dito no sentido de tempo de desenvolvimento e teste e criação de Testes automatizados é iniciado então só lembrando que o trabalho com ciclo de vida iterativa incremental e os processos iterativos minimizam os riscos oferecendo uma rápida avaliação dos usuários a respeito daquilo que está sendo desenvolvido E mais uma vez Lembrando que a iteração é um período tempo fixo onde a equipe está trabalhando para que

ao final desse período algo de valor seja demonstrado aos Usuários dentro do scom cada iteração é chamada de Sprint e basicamente o Sprint é o período de tempo que é necessário paraa realização de determinada história de usuário no formato de produto potencialmente plantável quem shab sugere no máximo 30 dias pro tamanho de um Sprint mas nós vemos casos aí de empresas que trabalham com sprints de um dia ou seja em um dia eles fazem Planejamento fazem execução fazem revisão e fazem retrospectiva quanto menor for esse tempo Teoricamente mais rápido um feedback maior mais rápido você

vai ter e vai conseguir se adaptar às mudan de forma mais rápida mas nem todos consegu fazer sprints tão curtos assim pois fica difícil você conseguir encaixar todas as reuniões no Sprint muito curto para quem tá começando Talvez uma boa sugestão Trabalhar com Sprint no máximo duas ou três semanas para conseguir realmente enxergar qual que é esse tamanho esse time frame necessário para realmente desenvolver alguma coisa de valor então é importante apenas notar que uma vez definido o tamanho do Sprint um projeto scom vai ser composto por vá V sprints dentro desse mesmo tamanho Então

dentro do planejamento do Sprint desculpa dentro já do Sprint o que vai acontecer é que o time de desenvolvimento via Auto-organização autogestão vai selecionar as as tarefinhas presentes dentro do prod backlog para poder executar no meu caso aqui uma tarefinha que estava pendente que era criar o modelo de dados foi selecionado por um determinado desenvolvedor que agora está em Progresso nós temos uma coluna já que tarefa que já ficou pronta no meu caso aqui o meu D Genérico e assim o quadro Vai funcionando as pessoas vão Selecionando as tarefas e elas vão de alguma forma

movimentando implementando e transformando essas tarefas em realidade de acordo com a definição de pronto que é compartilhada por todos na medida que for desempenhando as atividades algum impedimento surja nós recomendamos o uso de uma coluna dentro do Sprint backlog que é uma lista de impedimento que como nós já discutimos cabe ao escumar verificar esses impedimentos e tentar resolver talvez Com aillio do Product owner para que o time seja focado exatamente dentro da sua tarefa que é justamente terminar o objetivo do Sprint entregando assim produtos de qualidade para o nosso cliente então conforme já dito o

scom possui um modelo de ciclo de vida interativo incremental a interação é chamado de Sprint é recomendado sprints no máximo 30 dias e um projeto scom é constituído de vários sprints que que possui o mesmo tamanho Então uma forma uma representação talvez mais visual para você eu posso mostrar aqui que o primeiro Sprint Caso seja trabalhando com Sprint de 30 dias no final do primeiro Sprint eu tenho uma um trecho do meu produto no segundo Sprint mais 30 dias o meu produto vai sendo incrementado ao longo de n iterações dentro do meu Sprint uma outra

figura que eu trouxe para vocês basicamente envolvendo aqui estão do Time Box lembrando então que o Meu meu Sprint aqui particularmente está sendo trabalhado com 30 dias mas isso vai depender da sua equipe de desenvolvimento e da cultura organizacional mas lembrando o primeiro dia é destinado a reunião de planejamento do Sprint sendo que na primeira parte focada no Hoy onde nós vamos priorizar os itens do prod backlog e vamos detalhar os níveis de granularidade a segunda parte nós vamos criar fazer as estimativas dos itens do Pr backlog pelo time desenvolvimento criar o plano de liberação

e quebrar essas histórias que vão ser trabalhadas dentro do Sprint em tarefas menores e o que é feito pelo time de desenvolvimento num artefato chamado Sprint backlog os n men2 dias do Sprint desenvolvimentos com testes de qualidade e código de qualidade com testes automatizados e no último dia a revisão do Sprint retrospectivo do Sprint também último dia é dividido em Duas partes na primeira parte do último dia do Sprint o time de desenvolvimento apresenta as funcionalidades para o product e na segunda parte da última reunião do último dia é feito uma retrospectiva que é um

ponto para tentar verificarmos o que deu certo e o que deu errado dentro do Sprint para aperfeiçoarmos o próprio scrum conforme nós vamos ver daqui a pouco o scrum Apesar Dee terminar o modelo de Ciclo de vida para planejamento e execução e retrospectiva da gestão do seu projeto ele não especifica Quais são as técnicas Quais são as práticas de desenvolvimento de software que são usados pelo time de desenvolvimento o time do desenvolvimento tem uma certa Liberdade com relação a essas técnicas Entretanto é muito recomendado e muito usado o scrum em conjunto com XP nós já

vimos aqui algumas técnicas que são usados no Scrum e que na verdade são oriundas do XP como por exemplo a escrita o tempo todo de testes unitários o Plan e assim sucessivamente aqui eu tô mostrando para vocês algumas das técnicas que são usadas no dia a dia para Pelos times de desenvolvimento scr e que são boas práticas de desenvolvimento software primeiro nós temos que ter um servidor de gestão de configuração temos trabalhar com conceito de integração contínua Independente se vai usar jain Cruise control se vai usar woodson ou diversos outros softwares para fazer integração contín

é uma boa prática de programação e tá integrando o nosso código de forma automatizada e com bastante frequência nós vamos ver que testes de aceitação os chamados testes de funcionalidade também são automatizados na medida do possível juntamente com os nossos testes unitários existe um artefato dentro do Sprint que é muito usado e é muito bacana um artefato que é muito usado pelo time de desenvolvimento do scrum Na verdade são dois artefatos cada um tem um objetivo específico para o time desenvolvimento nós temos esse artefato chamado Burn sharts o gráfico de Burn ou gráfico de queima

de horas ou de histórias de usuário basicamente é um artefato usado no dia a dia pelo time de desenvolvimento do scom para reportar o andamento do projeto de maneira mais Amigável e tornando transparente toda a evolução do time desenvolvimento dentro do scrum basicamente a ideia desse gráfico aqui é que nós temos no eixo X a duração do meu Sprint e no eixo Y eu tenho o esforço restante em horas Lembrando que isso aqui essa primeiro gráfico que tô mostrando chamado Sprint bual é um gráfico de interesse do time de desenvolvimento Lembrando que o time de

desenvolvimento quebrou os itens do Pró Backlog em tarefas muradas em horas então Teoricamente esse gráfico Y vai mostrar as horas restantes e ou em outras palavras vai ser o número de horas a serem vencidas que vão representar as funcionalidades somente implantáveis do meu prod backlog uma característica importante desse gráfico e que ele é muito facinho é que a medida que nós vamos passando os dias por exemplo na hora que termina o primeiro dia é verificado quantas horas que o meu Time realmente conseguiu trabalhar nas tarefas e é feito uma interceção desse gráfico com o eixo

Y e o eixo X mostrando ponto de interceção se essa interceção estiver abaixo dessa linha azul a velocidade da equipe está acima do planejado se a interceção estiver acima da linha azul quer dizer que a equipe não está vencendo os pontos na velocidade planejada e a tendência é que o prazo não seja cumprido existe uma variação desse Gráfico chamado release Burn A diferença é que o release Burn Down o eixo X em vez de ser dias o eixo X é baseado em sprints enquanto que o eixo Y em vez de ser horas é baseado em

Pontos de histórias do PR backlog aqui talvez fique claro que o objetivo desse gráfico é reportar o andamento do projeto não pro te de desenvolvimento e sim para o product All pois aqui você tem uma visão mais a longo prazo com questão dos sprints aqui tem por exemplo 525 pontos de história que deverão ser cumpridos ao longo de talvez 10 ou 15 sprints enquanto que o o Sprint Burn é focado nas horas dentro de um Sprint particular os níveis de granularidade são diferentes no final do Sprint ou seja na data final para término do Sprint

é o Marco para o fim do Sprint e não para as funcionalidades ser implementados o Sprint termina mesmo que os itens presentes dentro do prio backlog não Estejam prontos nós não vamos entregar documentação Mas nós vamos respeitar as datas um Sprint de tamanho fixo durante todo o projeto é um importante mecanismo para medir a real produtividade do time melhorando as estimativas a do Sprint a mensagem que fica é que é muito melhor perder funcionalidades do que datas isso é um conceito muito interessante dentro do scrum e dentro dos do Sprint nós temos Lembrar também que

nós temos as chamadas reuniões diárias ou também chamadas reuniões em pé ou reuniões de pé se você preferir dessa forma o objetivo é que nós temos tenhamos as pessoas envolvidas dentro dessa reunião diária de no máximo 15 minutos para responder algumas questões básicas sobre o andamento do nosso nosso projeto então é uma reunião que ocorre todos os dias onde encontra-se o scrum Master o time é até qualquer pessoa Interessada no projeto com time box no máximo 15 minutos e por lembre-se sempre não ultrapasse o time bo tudo no scr é cronometrado então uma reunião diária

que dure du a 3 horas está comprometendo a produtividade da equipe basicamente A ideia é que cada membro da equipe consiga responder nessa reunião diária três perguntinhas básicas o que ele fez desde a última reunião diária o que ele pretende fazer até Amanhã e se tem alguma cois que esteja impedindo o trabalho dessa pessoa nós aconselhamos que a reunião diária aconteça todo dia no mesmo horário pois ela promove aorganização o maior comprometimento das pessoas e compartilhamento das responsabilidades Se vocês forem pensar um pouco a reunião diária é um dos pontos possíveis que o scum fornece

de inspeção e adaptação de estar monitorando o tempo todo o progresso do seu Projeto tendo feito o Sprint monitorado acompanhado quebrado as tarefas desempenhado as tarefas tendo atualizado os gráficos de Burn chegou a hora do último dia do Sprint que é é no dia onde nós fazemos a revisão do Sprint dentro da reunião de revisão do Sprint é que a reunião onde realmente o show the money né O dinheiro vai aparecer Pois é a reunião onde você vai entregar produto software funcionando para o product H então a revisão do Sprint é um importante ponto de

inspeção dentro do scom também e ocorre no último dia do Sprint e representa o momento em que o time e o SC Master demonstram as Fides potencialmente implantáveis para o product a a funcionalidade potencialmente implantável é a única medida real a respeito do andamento do projeto e que pode reduzir a incerteza é inadmissível para a filosofia do scom que ao final do Sprint sua equipe só entregue documentos para o product A então só para nós termos uma uma ideia um pouco melhor se nós olharmos nessa figura aqui aipe havia comprometido a entregar 12 pontos de

história dentro do Sprint mas por algum motivo o product só aceitou as duas primeiras histórias ou seja só for entregues 11 pontos dentro daquele Sprint então de acordo com essa figura o item uma reserva possui um ou mais quartos para um período específico de tempo não foi implementado ela será Entregue no Sprint 2 caso a prioridade seja mantida na na próxima reunião de planejamento do Sprint mas é importante lembrar que nessa situação deve ser avaliada a causa do não comprimento uma possibilidade talvez é que a velocidade do time pode ser menor do que a prevista

o time tava achando que a velocidade era 12 de pontos de história pro Sprint na verdade consegue só 11 lembrando também que esse prod backlog ele vai ser atualizado Constantemente durante o projeto assim nós vamos ter que ficar replanejando o tempo todo os nossos prod backlog nós vamos ter várias reuniões de planejamento de Sprint ao longo do projeto com esse planejamento Pode ser que surja um novo Sprint talvez a gente tava achando que a velocidade era 20 na verdade a gente tá fazendo uma velocidade só de 10 o que vai acontecer é que às vezes

nós vamos ter que incluir o novo Sprint e nesse caso o product Owner deve decidir se ele deseja aumentar o custo talvez aumentando a equipe aumentar o prazo ou até mesmo abrir mão de determinadas funcionalidades lembrando sempre o scrum possui dois valores muito importantes transparência e a arte do possível Finalmente nós chegamos então através de mais um ponto de inspeção e adaptação que é justamente a reunião de revisão do Sprint nós chegamos na última reunião do do scrum Dentro de um Sprint que é a reunião de retrospectiva de Sprint que é uma reunião muito importante

dentro do scrum que vai justamente mostrar para todos os envolvidos como que funciona a questão de avaliar o que deu certo e o que deu errado dentro daquele Sprint o é um conjunto de práticas focadas em melhoria contínua do processo assim o SC como controle empírico não prega uma uma rigidez de processo ao invés promove constante Adaptação das práticas Mesmo durante o projeto o processo pode mudar de um Sprint para outroe buscando melhoria na produtividade ou qualidade do produto final assim na reunião de retrospectiva do Sprint nós vamos discutir sobre as lições aprendidas e ajustes

necessários no processo para que Assim possamos fazer um planejamento de um novo Sprint No próximo dia útil Lembrando que todos os sprints no scum possuem uma estrutura exatamente igual planejamento Cumprimento avaliação do resultado e ajuste do processo ou em outras palavras nós temos aqui mais um ponto de inspeção e adaptação dentro do scr assim algum duas perguntas básicas que nós temos normalmente no time box de 3 horas para essa última reunião as perguntas básicas que nós respondemos é o que que caminhou bem e o que que poderia melhorar dentro daquele Sprint conforme vocês podem ver

aqui pela figura algumas características Interessantes poderia ser resposta Ah nós gostamos do scom ele forneceu uma gestão com maior visibilidade ficou mais clara a ideia que que nós trabalhar eu gostei do Sprint backlog que é o nosso quadro de tarefas mas chegamos à conclusão que nós fizemos algumas reuniões de scrum di áreas muito longas Isso deve ser deve ser revisto Nós deveríamos ter mais tempo refatorando testes unitários não foram tão legais talvez poderia melhorar ou seja é um Tempo que nós temos no último dia do Sprint na segunda parte desse último dia do Sprint quando

nós já entregamos as funcionalidades pro nosso cliente para fazer uma reflexão daquilo que pode ser melhor melhorado ou não dentro do Sprint então nessa reunião o objetivo é transparência interna do time o scrum deve avaliar os pontos apresentados e prover os recursos necessários para que as mudanças ocorram Um dos problemas mais comuns é que a equipe não busca se Empenhar para que as mudanças no processo ocorra lembre-se a adaptação contínua é Um fundamento importante para controlar projetos críticos e esses pontos de melhorias devem ser valorizados a as lições aprendidas é Um fundamento em muitas metodologias

de gestão de projetos terminando a reunião nós temos que repetir todo o ciclo de vida então no próximo dia útil nós vamos ter novamente uma reunião de planejamento do Sprint onde nós vamos priorizar itens do prod backlog detalhar itens do prod backlog estimar replanejar para que assim o ciclo continue em execução e eu trouxe essa figura apenas para mostrar como que é muito compatíveis muitos complementares os dois métodos ágeis scu XP então o scrum é o método á para fazer o planejamento acompanhamento e retrospectiva dos nossos projetos e o XP fornece uma série de regras

de práticas e de valores de Como isso pode ser feito então alguns conceitos como retrospectivo do Sprint reunião diária Sprint backlog Sprint Burn Down shart são conceitos presentes dentro do scrum que são podem que não conflitam com conceito do XP como desenvolvimento dirigido por testes integração contínua ou plan poker que veio do XP na verdade é usado dentro do scrum times com times com os integrantes um próximos ao outro refactoring propriedade coletiva de código ritmo Sustentável ou seja as práticas regras princípios do XP se encaixam perfeitamente com as regras práticas princípios e reuniões presentes dentro

do scrum esta apresentação sobre métodos ágeis teve como f como foco os dois principais métodos ágeis usados no mundo que são o scom e o XP mas diversos outros métodos ágeis existem na literatura e também são muito usados no mercado mas lembrando apenas que todos Esses métodos ágeis eles compartilham muito das características em comum que foram apresentados no início desta gravação assim eu vou ilustrar alguns métodos ágeis aqui apenas para aqueles interessados que possam procurar E caso queiram se aprofundar dentro do conhecimento de agilidade dentro esses outros métodos ágeis nós podemos destacar o xpm que

também foi desenvolvido por KB que é um Uma versão para ser usado com XP para fazer gestão de projetos ágil nós temos o APM temos o fdd que é muito usado aqui no Brasil que é o feature driven development temos a família Crystal que que é um conjunto de processos de acordo com o tipo de projeto que você queira trabalhar nós temos o LM e assim sucessivamente nós temos n métodos os publicados em uso na prática Caso vocês queiram tenham interesse em continuar aprofundar além de scom e XP que foram Discutidos com mais detalhes aqui

eu recomendo dar uma verificada desses métodos Mas vocês vão perceber que muito das características que eu levantei nessa a estão presentes também dentro desse desses métodos ágeis e diversos outros que também não foram listados aqui bom chegamos assim então ao final dessa apresentação sobre métodos ágeis e esta apresentação foi criado atendendo a solicitação do meu orientador de doutorado Professor Celso irata do Instituto Tecnológico de Aeronáutica e professor fique à vontade caso você arte pertinente e repassar essa apresentação para qualquer outra pessoa qualquer outro aluno orientado seu que tem interesse ou que vai realizar alguma pesquisa

tanto em nível de graduação mestrado ou doutorado em métodos ágeis Então essa gravação que eu fiz fica disponível para o senhor bem como aquela gravação que eu fiz sobre o meta modelo spen caso o senhor entenda Que seja de valia fique à vontade a repassar para outros orientados ou até mesmo para seus alunos dentro do Instituto Obrigado pela atenção e pela paciência por me escutar por essas duas horas até a próxima