Agile e Scrum — de iniciante a especialista (inclui um projeto prático)

1. Visão de curso: Olá a todos e bem-vindos a este curso que é intitulado mastering corredor idade e Scrum de iniciante para especialista. Você tomou uma decisão muito inteligente na escolha de aprender h l e é migalha. Porque você sabe, HL é um conceito tão importante no mundo de hoje, independentemente de qualquer domínio industrial ou tecnologia em que você está trabalhando. E seus usos crescem rapidamente. Quase 71% das organizações usam um IG e esse número está crescendo a cada dia. Então é por isso que é muito importante saber sobre isso. E você está definitivamente no caminho certo para o papai. Esta é uma classe mestre para Agile e Scrum, e você aprenderá todos os pequenos detalhes sobre eles. Você pode usar este Aprendizado para melhorar sua suposição ou trabalhar em uma equipe Scrum ou obter certificado como um mestre scrum, qualquer que seja o seu objetivo final. Estou muito entusiasmado para embarcar nesta jornada de aprendizagem. E agradeço-vos por escolherem este curso. Vamos começar e ver o que tudo vamos abordar neste capítulo de introdução. Então aqui está a agenda para este capítulo. E como você pode ver, estamos apenas começando a conhecer as coisas que é muito importante para definir o impulso. Veremos principalmente o que este curso cobre e como você pode tirar o melhor proveito dele. Falaremos sobre mim, seu instrutor, o conteúdo do curso e as imensas opções de transportadora que se seguem quando você tiver conhecimento da AGI. Então, o que você pode esperar deste curso? Bem, este curso é um pacote completo. Nós vamos, claro, aprender tudo sobre Agile e Scrum e longe Este curso é projetado. Vamos começar a partir dos conceitos mais básicos e, em seguida, passar para o avançado. Então, se você é totalmente novo no RH, você vai se sentir totalmente confortável nesta jornada. Ou se você é alguém que tem experiência em um gel, eu ainda sugiro que você assista todos os capítulos em sequência porque pode haver algo novo para você ou você vai ter uma recapitulação. Vamos aprender sobre os conceitos básicos de HL e Scrum, os papéis de Scrum, cerimônias, como estimamos as coisas? Quais são os artefatos que relatam que criamos? E muito, muito mais. E vamos manter essas aprendizagens interativas. Portanto, há um pequeno questionário no final de cada capítulo para atualizar o que aprendemos. Outro ponto e muito útil, não é apenas suficiente para conhecer a teoria. Precisamos aplicar nosso aprendizado na prática também porque é aí que temos o conhecimento real das coisas. E é por isso que temos um capítulo inteiro dedicado à criação de um projeto no Scrum a partir do zero. Em seguida, falaremos também sobre certificações e entrevistas neste curso. Então, se o seu objetivo é obter certificado como um mestre scrum, você certamente irá se beneficiar do curso, porque temos um capítulo inteiro dedicado a certificações e dicas para limpar o exame. Da mesma forma, se o seu objetivo é se destacar em uma entrevista, temos um capítulo dedicado a dicas de entrevista e 30 mais perguntas de entrevista mais comuns. Em seguida, se você é um membro deste curso ou de qualquer um dos meus outros cursos, você obtém suporte de consulta vitalícia. Então use o Q e uma opção no site ou envie-me um e-mail e você receberá uma resposta rápida. E este é o pessoal do suporte vitalício. Então você pode me enviar algo mesmo um ano depois fazer este curso e esperar de volta uma resposta. E por último, este curso é projetado para todos os tipos de público em mente. Se você é um novo desmaiado da faculdade ou um participante de TI ou um pessoal experiente. O conteúdo deste curso abrange todos os níveis e, no final, você teria toda a experiência de Agile e Scrum. Então, antes de seguir em frente, eu só queria dar uma breve apresentação sobre mim. Tenho mais de dez anos de experiência em gestão de projetos e garantia de qualidade. Trabalhei e liderei vários projetos de produtos AGL na Índia e também há vários anos em nós. Meu endereço de e-mail está na tela, então, como eu mencionei anteriormente, também, se você tiver alguma dúvida, sinta-se livre para me enviar um e-mail e eu responderei proativamente dentro de 24 a 48 horas. Você também pode postar suas perguntas através do Q e uma opção no site. Agora, antes de seguir em frente, uma das coisas que eu queria mencionar era que em todos esses anos de minha experiência de trabalho, a coisa mais importante que descobri que precisamos na vida profissional é ter a arte de nos aprimorar para manter sobre aprender coisas novas. Portanto, mantenha o desejo de aprender, assumir qualquer novo tópico que lhe interessa e continuar construindo ser um aprendiz. Tudo bem, então estamos prontos para entrar. Vamos analisar o conteúdo do curso agora para que você saiba o que está reservado para você. Então pessoal, aqui está o conteúdo do curso e à medida que passamos por ele, vocês notarão que chamei cada capítulo como um sprint. Por sprint é o coração de Scrum e todo o trabalho acontece nele e saberemos sobre isso mais tarde. Então cada capítulo é um sprint para aprender algo novo. Dentro de 80 sprints, aprenderemos tudo sobre Agile e Scrum. Vamos começar com os conceitos centrais de hL e Scrum. Então vamos falar sobre os papéis Scrum, as pessoas que estão na equipe scrum, seguido de cerimônias Scrum, que são as reuniões. E depois os artefatos Scrum. Vamos então aprender sobre planejamento de sprint e estimativa, seguido por relatórios Scrum que criamos. E, em seguida, o capítulo oito é um exercício de prática completa onde vamos configurar um projeto a partir do zero em um scrum e ver sua implementação todo o caminho desde coleta de requisitos inicial até a liberação para o usuário final. Finalmente, temos o capítulo nove para aprender sobre as certificações, dicas de bits sobre como limpar o exame de mestrado scrum certificado. E, por último, papel de jornal dez. Eu vou lhe dar um monte de perguntas de entrevista para ajudá-lo a se preparar para uma entrevista e manter a resposta para essas perguntas o mais simples possível para que você não tenha que roubar coisas, seus conceitos ou som. Então pessoal, como vocês podem ver, é uma lista bastante exaustiva e seguiremos esse plano próximos dez capítulos para torná-lo um especialista em agile e scrum. Agora voltando para o último tópico deste capítulo, as oportunidades de transportadora em AGI, É muito importante ver o caminho pela frente e ser motivado. Lembre-se, o HIV começou em algum lugar há 20 anos. E no mundo de hoje, é a metodologia mais comumente usada. Se falamos de grandes empresas, Fortune 500s, ou até mesmo pequenas startups, todos estão usando AGI. Você pode pegar qualquer uma de suas ofertas de trabalho para gerenciamento de projetos ou desenvolvimento ou teste, e isso exigirá um conhecimento infantil. Alguns empregos exigem uma certificação também como CSM ou CSP Leo e eu sugeriria que você perseguir essas áreas. Ter uma certificação dá um reconhecimento ao seu conhecimento e é uma adição mais agradável ao currículo. Se você já estiver na função de gerenciamento de produtos, você pode pensar na função de proprietário do produto ou em outras funções de gerenciamento. Se você é muito apaixonado por h l, você pode ser um treinador ágil. As oportunidades e usos do HIV são homens intermináveis. Em pesquisas do LinkedIn dos dez primeiros trabalhos mais promissores é Scrum Master e Product Owner são uma das entradas. Então, muito impressionante caminho de transporte. E é por isso que eu disse no início que você fez uma ótima escolha ao escolher aprender AGI. Ok, então nós conversamos sobre o curso, é conteúdo e oportunidades em AGI. Vamos começar nossa jornada de aprendizagem e começar com o próximo capítulo para saber o que é ágil e scrum. Obrigado. 2. Por que agil? (Problemas com abordagem tradicional): Olá a todos e bem-vindos ao segundo capítulo do curso. Agora vamos começar nossa jornada para os conceitos iniciais de Agile e Scrum. Vamos primeiro ver qual era a abordagem tradicional, a maneira pré ágil de fazer as coisas. Porque isso nos ajudará a entender a razão pela qual uma criança nasceu e por que ela é tão bem-sucedida. Em seguida, veremos o Manifesto Ágil e os princípios que são a base da HL. Em seguida, discutiremos a metodologia EGL seguida por Scrum. Usamos os termos que cada ilha está amontoada, mas lembre-se que há uma diferença entre eles e veremos o que é isso. Em seguida, vamos dar uma olhada no ciclo de vida scrum. Então, até agora estávamos na parte do que é. Agora vamos passar para a parte como é feito. E, por último, vamos falar sobre MVP e abordagem incremental, que é um conceito importante. Então vamos começar. Então vamos entrar e começar com o mundo ágil de fazer as coisas, como somos pensados antes da idade do Eyal aparecer. Então, a metodologia mais comum que foi seguida antes de uma criança ser conhecida foi o modelo de cachoeira. E era assim que parecia. Então pessoal, este é o modelo de cachoeira e como vocês podem ver, há uma seqüência rigorosa de fases. Temos a fase de requisitos, a fase de projeto, verificação de implementação e, finalmente, a fase de manutenção. E as fases anteriores tiveram que ser concluídas antes que você possa começar com a próxima. Então agora parece bem direto, mas houve um grande problema aqui. E o problema da dívida aconteceu quando tivemos que voltar e mudar as coisas. Então vamos entender isso por um exemplo. Vamos considerar um cenário em que uma empresa quer desenvolver um novo produto, digamos um telefone celular, eles fazem a pesquisa de mercado. Eles saem com os requisitos do que eles precisam e eles decidem implementá-lo usando a abordagem cachoeira. Agora, três meses após o início, digamos que a verificação do corante vermelho e teste final de fase percebeu os requisitos mudaram. Os clientes não precisam mais do que ensinaram inicialmente. E então tudo o que eles planejaram e fizeram até agora se foi. E agora temos que começar tudo de novo desde o início, a primeira fase de exigência. Se pensarem bem, pessoal, esta é a realidade do mundo de hoje. Se você vê a mentalidade do cliente hoje, suas necessidades estão mudando tão rápido estudos mostraram que em projetos grandes e complexos, cerca de 70% dos requisitos iniciais serão alterados durante o projeto. O que estamos a fazer hoje seria obsoleto e substituído por algo novo dentro de três a seis meses. E assim cachoeira não poderia lidar com este mundo requisitos em mudança. Então isso é o que o slide também diz. Se você pensar sobre isso, até mesmo o cliente, Então nos dê os requisitos para seus projetos. Eles podem não conhecer todos os requisitos de antemão. Na verdade, é difícil para alguém adivinhar como os mercados e os usuários reagirão a um produto nos próximos três a seis meses porque, você sabe, as coisas estão mudando tão rápido. E para superar esse problema, as coisas tinham que ser curso correto no meio e isso aumenta o custo, tempo, esforço, etc Agora, outro problema com Bagdá na cachoeira, o usuário final ou cliente não estava envolvido em o processo e Dessau trabalhando software ou produto muito tarde no jogo e se qualquer mudança foi necessária, bem, vamos voltar novamente e você começar a implementar a partir da fase inicial. Novamente, o que significa mais custos de tempo, esforço, etc. Então pessoal, essa abordagem tradicional de cachoeira que vimos começar a desenvolver rachaduras. E, de fato, nos EUA, onde o Departamento de Defesa era o maior usuário de cachoeira, eles descobriram que 75% de seu projeto nunca foi concluído por causa de atrasos e custos crescentes devido a mudanças frequentes. Então, mais uma vez, para resumir o problema com a abordagem tradicional, número um, ninguém pode obter exigência em um único tiro porque as coisas estão mudando tão rápido. Número dois, o usuário final não estava envolvido no processo. Não havia mecanismo de feedback. E número três, o software de trabalho ou protótipo chegou muito tarde na foto. Então, no momento em que as mudanças poderiam ser fatoradas, já era muito tarde. Então, em suma, essa abordagem tradicional não era boa para requisitos em constante mudança. E assim, no final dos anos noventa, a indústria queria avançar em direção um modelo iterativo que estava aberto às mudanças em evolução. E levou em consideração os problemas reais. Primeiro, ninguém pode conhecer todos os requisitos. Segundo, fazer mudanças é um grande negócio. Não é gerenciável continuar mudando as coisas sempre que há um novo requisito. E o mais importante de tudo, precisávamos de algo que pudesse ser o número um, feito em pequenos incrementos. Número dois, a dívida pode ser iterativa. E número três, que envolveu feedback contínuo. Então, se alguma vez tivemos uma modificação, podemos encontrá-la cedo. E pessoal, este é o processo de pensamento exato que deu à luz a uma criança, desenvolvimento iterativo e incremental com feedback contínuo. E você vai ouvir essas três palavras, iterativo, incremental e contínuo feedback muito neste curso, porque as outras necessidades sobre as quais uma criança ou um Scrum é construído. Tudo bem, agora a indústria teve um pouco começou a adotar alguns modelos iterativos na década de noventa. Mas a coisa real veio em 2001, quando 17 desenvolvedores de software se conheceram em um resort nos EUA, EUA. E eles inventaram algo que é chamado de manifesto HL. Então vamos falar sobre o que é esse manifesto h l e como ele forma a visão de uma criança na próxima palestra. Obrigado. 3. O Manifesto Agile: Olá a todos. Vamos falar sobre o Manifesto Ágil agora. E é importante entender esse manifesto porque é a base e o princípio orientador por trás da implementação de HL em todo o mundo. Agora este manifesto tem quatro valores fundamentais e 12 princípios de apoio. Então vamos ver o que eles são. E você sabe, há um site dedicado a este manifesto, então vamos verificar isso. Então, pessoal, eles têm um site chamado HL Manifesto.org. E é assim que parece. E você pode ver os quatro valores principais listados aqui. E diz que as coisas à direita são o que temos feito. Mas, em vez disso, devemos valorizar mais do que as coisas à esquerda e devemos segui-las. Então, número um, devemos valorizar indivíduos e interações sobre processos e ferramentas. Os processos são importantes, mas não são flexíveis para mudanças nas necessidades dos clientes. Portanto, não devemos ficar cegamente aos processos. Em vez disso, devemos nos concentrar mais nos indivíduos e suas interações. Quando os indivíduos vão colaborar mais, eles vão chegar a uma idéia melhor e não apenas seguir o processo. Então este foi o ponto número um, mas lembre-se que não diz parar de seguir todo o processo e fazer o que quiser. Não, ele só diz que os indivíduos devem interagir mais, eles devem colaborar mais e eles não devem ir cegamente para o que o processo diz. Número dois, software de trabalho sobre documentação abrangente. Então, nos dias da cachoeira, havia muita documentação para cada um desses estágios e idade. Eu disse que vamos manter a documentação ao mínimo é agilizar tudo e focar mais em obter um software de trabalho. Então, mais uma vez, não entendo que cada corredor diz é parado de fazer todos os tipos de documentação. - Não. Em vez disso, ele quer que nos concentremos mais em colocá-los em software em vez de apenas obter documentos. E número três, colaboração com o cliente sobre negociação de contrato, significa que o cliente envolveu em toda a jornada. Pense no que eles querem, em vez de apenas tentar trabalhar como um contrato de uma vez escrito. E o último número para responder à mudança depois de seguir um plano. E este é o mais importante no meu ponto de vista, porque a maioria das pessoas pensa em agendas apenas à metodologia. Mas lembre-se sempre que uma criança é mais um processo de pensamento. Temos que ser HI em nosso pensamento só então podemos seguir uma metodologia de prisão com precisão. E o teste de HIV nos diz para não seguirmos o plano cegamente. Em vez disso, ser flexível, ser responsivo às mudanças para que possamos nos adaptar rapidamente às mudanças das condições do mercado. Então estes são os quatro núcleos, valores centrais. E como diz, há valor nos itens à direita. As coisas que fizemos na abordagem tradicional. Mas agora vamos valorizar mais as coisas à esquerda. Então, em poucas palavras, esta era a parte que de um gel. E aqui ele lista o nome das 17 pessoas que se reuniram para formar o Manifesto Ágil e inventaram esses quatro valores fundamentais. Agora, se você rolar mais para baixo, você verá um link para os 12 princípios. Então esta é a página que ele leva para, e você pode ler através deles. Há alguns pontos-chave aqui. Primeiro, temos que fornecer ao cliente uma entrega antecipada e contínua. Então, se eu lhe der um produto depois de 12 meses e digamos que não é bom. Haveria muito esforço, custo e tempo em tentar voltar atrás e corrigi-lo novamente. Portanto, não deixe que isso aconteça, entregue ao cliente continuamente em incrementos. E mais uma vez, existem 12 princípios diferentes. Eu não quero passar por todos eles. Você pode lê-las. Vamos tentar entender os conceitos-chave aqui. A primeira foi a entrega precoce e contínua. E então, se você cair, ele fala em trabalhar juntos. Assim, os empresários e os desenvolvedores devem trabalhar juntos. Lembre-se de indivíduos e interações que vimos no primeiro princípio central. Em segundo lugar, confiar nas pessoas, lembre-se novamente dos valores centrais não seguem o processo e contrato por confiar cegamente nas pessoas e tê-los chegar com o melhor produto ou software. Em seguida, são interações face a face. Então, novamente, Phi, desculpe, conversa cara a cara. Então, novamente indivíduos e interações. Então, se você rolar para baixo, temos software de trabalho. Então, como falamos nos valores centrais mais cedo, menos documentação, mais software de trabalho. Estamos vendo software aqui, mas você pode pensar em produtos também. Basicamente, significa que os critérios de medição são de trabalhar algo não apenas toneladas e toneladas de documentação. Então, novamente, você pode ler isso completamente linha por linha, mas a idéia de um GYE, incluindo esses princípios, vem desses quatro valores fundamentais, que são indivíduos e interações sobre processos e ferramentas, trabalhando sobre documentação abrangente, colaboração com o cliente, negociação sobre contrato e, por último, resposta, respondendo à mudança ao seguir um plano. Lembrem-se destes quatro valores fundamentais. Você pode guardá-lo em algum lugar. Pode anotar na sua mesa. Na verdade, nos nossos primeiros dias, quando começamos a implementar um GI há muito tempo em nosso projeto, costumávamos ter esses grandes cartazes na dívida da parede listados esses valores fundamentais. E você também pode fazer o mesmo. Você pode pendurá-los em um lugar onde, você sabe, você faz reuniões regulares que combinam tudo. E é importante porque nos ajuda a lembrar da importância da colaboração, desenvolvimento incremental, etc E se você conseguir esses conceitos, você terá a idéia completa de wattage Alice. Então, tudo bem pessoal, então isso era tudo sobre o Manifesto Ágil. Agora vamos para a próxima palestra e ver a definição formal de um gel. Então, vemo-nos na próxima palestra até lá. Obrigado. 4. Definição de Agile: Olá a todos. Então, nas palestras anteriores, falamos sobre a abordagem tradicional de fazer as coisas. Demos uma olhada no manifesto HL. Agora vamos realmente ver o que é este anjo. Assim, em sua tela você verá a definição oficial de AGI e ele diz, HI EL desenvolvimento de software refere-se a metodologias de desenvolvimento centradas em torno da idéia de entrega incremental e iterativa de pequenos pedaços de funcionalidade. Somos requisitos e soluções evoluídas por meio da colaboração entre equipes multifuncionais de auto-organização, permitindo feedback frequente dos clientes e correção de cursos conforme necessário. Então essa é a definição oficial de gel, mas muito Wurtz, certo? Então vamos deixar de fora a maior parte disso e vamos nos concentrar nos termos mais importantes. Então o primeiro é a entrega incremental e iterativa. Lembre-se que conversamos anteriormente sobre os métodos antigos e o problema com eles era que nós entregamos o produto muito tarde e, em seguida, tivemos que fazer mudanças que eram coisas caras e atrasadas. Portanto, o ILC de idade está fornecendo incremento. Você não tem que fazer tudo de uma só vez. Faça a primeira versão ou MVP do produto e, em seguida, melhorá-lo em incrementos e através entregas freqüentes ou iterativas de um pequeno pedaço de funcionalidade. Então, projetando pequenas peças pequenas, forneça os incrementos em suas pequenas peças pequenas e, em seguida, continue repetindo todo esse processo. O próximo conceito importante é a colaboração. Então, como vimos anteriormente, nenhum processo ou ferramenta individual pode adivinhar todos os requisitos de uma só vez. Precisamos de um grupo de pessoas para colaborar e encontrar soluções. E é por isso que as equipes de crianças são multifuncionais e auto-organizadas. Não há nenhum conceito de gerente de desenvolvimento ou gerente de teste dentro da equipe Scrum. Eles são todos externos à sua equipe. Os indivíduos da equipe que se sentam juntos, que trabalharam juntos, eles interagem uns com os outros, eles discutem uns com os outros, eles colaboram uns com os outros. E o design de produtos e serviços úteis para o cliente. E o último aspecto, feedback e correção do curso. Então lembre-se, mudanças certamente virão. Serão necessárias correções. Então, mantenha um feedback contínuo com o cliente. Nós não queremos, você sabe, entrar em contato com o cliente depois de três meses ou seis meses para reunir seus comentários. Queremos fazer é menor, pequenos incrementos. Queremos mostrar o produto ao cliente. Queremos reunir seus comentários e fazer correções conforme necessário. Então essas cinco coisas que você vê destacadas na tela, isso é o que h l é. Lembrem-se, não quero que se lembrem desta definição, palavra por palavra. E, na verdade, não vou pedir que memorize as coisas palavra por palavra em qualquer lugar do curso. Basta lembrar as palavras-chave que são destacadas em sua tela na definição. E se você for a qualquer entrevista ou organização e alguém perguntar o que é um gel? Você pode dizer sua própria versão, incluindo essas palavras-chave. Uma vez que a outra pessoa ouvir essas palavras-chave, saberá com certeza que você entende. Oi. Então essa é a abordagem que seguiremos ao longo deste curso. Vou me certificar de que você entenda as coisas chave e você não precisa memorizar nenhuma coisa. Então essa era a definição de um gel caras. E basicamente é um ciclo de planejamento das coisas, projetando-as, recebendo feedback, revisão do cliente e lançando a coisa e, em seguida, refazendo novamente e novamente em iterações. Então dat é tudo hl é o diagrama único. Tudo bem, então eu tenho certeza que você sabe, sabe o que HFile é, seu manifesto, seus conceitos centrais. Então vamos falar sobre a parte de implementação, e vamos falar sobre um Scrum na próxima palestra. Obrigado. 5. Definição de Scrum e a diferença de diferença do Agile: Olá a todos e bem-vindos de volta. Então vamos falar sobre nosso próximo tópico, que é um Scrum. Então, o que exatamente é esse scrum? Agora falamos sobre H L, e muitas vezes usamos Scrum e idade IL juntos no mesmo contexto. Mas lembre-se que eles são na verdade dois termos diferentes. Is Scrum é uma estrutura de gerenciamento de projetos ágil que as equipes usavam para desenvolver e entregar produtos complexos. Então, enquanto uma criança é um conjunto de valores e princípios, é Scrum é a maneira de implementá-lo. Lembra-te desta coisa. H L é um conjunto de valores e princípios e um Scrum é a maneira de implementá-lo. E lembre-se. Scrum é uma abordagem incremental e iterativa. Então vamos recapitular essas duas palavras. Incremental significa que estamos construindo e entregando o produto em seus pequenos pedaços. E iteração significa que estamos fazendo algo e, em seguida, refiná-lo ainda mais. Assim como falamos sobre software, fazemos um produto inicial e depois refinamos iterativamente. Fazemos ciclos de duração duas semanas ou quatro semanas. E em cada um desses ciclos, adicionamos incrementos de novos recursos e detalhes ao produto inicial. Estes ciclos são realmente chamados como um Sprints e vamos falar sobre eles em detalhes mais tarde. Mas por enquanto, lembre-se que o objetivo do Scrum é desenvolver produtos em cada pequeno ciclo de duas ou quatro semanas chamado como Sprints. E em cada sprint adicionamos novos recursos, adicionamos novos incrementos em cima dos existentes. Essa é a saída de cada sprint. Agora há termos adicionais, pessoas, processo, etc, que também definido é Scrum. E não se preocupe, aprenderemos sobre cada um deles em detalhes mais tarde. Mas, resumindo, isso é o que é o Chrome. É uma estrutura H L incremental e iterativa para fornecer e desenvolver produtos complexos. Isso é tudo que Scrum é. Agora, um último ponto antes de avançarmos é Scrum é usado mais comumente no desenvolvimento de software. E falamos de referência de dados principalmente neste curso. Mas lembre-se é Scrum é igualmente utilizável em outras indústrias, como fabricação ou outros negócios também. Portanto, se você está vindo desse pano de fundo, o discurso e o descontentamento é igualmente significativo para você. Então eu espero que você esteja claro sobre a definição de um scrum. Agora, seguindo em frente, vamos ver como HI AL e Scrum são diferentes. À medida que você passar por esta lista, você vai notar que não há uma grande diferença de significado. Essa distinção é mais do que e como sentido. Então o que o DEUS fala é migalha faz isso. Agora já sabemos sobre a primeira e principal diferença e sempre lembramos que uma criança é a metodologia para o desenvolvimento e um Scrum é a estrutura para implementá-la. Então hl é o valor central, h l é o princípio central de fazer coisas de desenvolvimento e um Scrum é a sua implementação. Em segundo lugar, HL é adequado para uma equipe pequena e especialista, enquanto o Scrum é adequado para mudanças rápidas de requisitos por causa de seu aspecto de controle de processo. Próximo ponto, a liderança desempenha um papel fundamental no HDL, mas quaisquer decisões Scrum são tomadas pela equipe. Então, como eu mencionei anteriormente, também, não há nenhum gerente, não há nenhum líder de equipe dentro da equipe Scrum. Há um proprietário do produto, há um Scrum Master, há uma equipe de desenvolvimento. Todos se sentam juntos, colaboram, discutiram a interação, e foi assim que resolveram os problemas. Em quarto lugar, na mesma linha, HI EL promove a colaboração e a interação entre as equipes. Vimos isso no valor central. Agora é migalha faz isso através de algo chamado reuniões diárias de stand up. Então é uma reunião diária de indivíduos trabalhando no Scrum e é um dinheiro HL7, vamos falar sobre isso no capítulo posterior, mas é assim que a colaboração acontece nesta migalha. Em seguida, HL fala de entrega e atualizações em uma base iterativa. Novamente, é migalha também faz isso por que sprints? Então essas impressões, como mencionei anteriormente, são o coração de todas as atividades em seu Scrum. Se você estiver trabalhando em qualquer Scrum ou se você vai trabalhar em qualquer Scrum daqui para frente, você vai ouvir coisas como, ok, vamos fazê-lo neste sprint, vamos fazê-lo no próximo sprint. Tomaremos dois sprints para fazer isso. Porque como eu disse, esses sprints são onde toda a ação, todo o trabalho acontece no Scrum. E último ponto, h l promove feedback contínuo. Vimos isso mais cedo. É migalha também faz dívida através de algo chamado de demonstração sprint. No final de cada sprint. A demo também é uma cerimônia scrum e falaremos sobre isso em detalhes mais tarde. Por enquanto, só sei que é feito depois cada sprint para mostrar o produto e reunir feedback, que a metodologia de feedback contínuo. Então pessoal, essa é a principal diferença entre cada ilha é Scrum. E novamente, você não precisa se lembrar de tudo isso, apenas lembre-se número um, HI, e Scrum são diferentes. Número dois, h L é uma metodologia. Ela é guiada por um conjunto de valores e princípios fundamentais que vimos. E Scrum é uma abordagem baseada em HL. É apenas uma implementação do HAL. Certo, então na próxima palestra, vamos falar mais sobre Scrum. Vejo-te na próxima palestra até lá. Obrigado. 6. Ciclo de vida de Scrum: Olá a todos. Então agora sabemos o que é Scrum é. Vamos ver como as coisas funcionam lá dentro. E o que você vê na tela são os estágios que juntos compõem o ciclo de vida do Scrum. Agora só vamos falar brevemente sobre eles aqui porque temos um capítulo dedicado sobre eles mais tarde. Então vamos dar uma olhada rápida neles. Mas antes de pegá-los, vamos pensar em como trabalhamos em nossa vida diária. E se você entender isso, você terá a idéia de Scrum também. Então queremos fazer muitas coisas na nossa vida, certo? Há uma grande lista de coisas que queremos fazer ou temos que fazer. Da lista grande, escolhemos cinco coisas que queremos fazer esta semana. Então, queremos ir para algum lugar. Queremos comprar algo para nós, queremos conhecer alguém, etc. Estamos escolhendo em cinco coisas, certo? E depois fazemos essas cinco coisas ao longo da semana. No final da semana, recapitulamos como fizemos, se poderíamos ter feito melhor, etc. E então nós novamente abrimos nossa grande lista de coisas e escolhemos as próximas cinco coisas que temos que fazer na próxima semana. É assim que trabalhamos como indivíduo, e é exatamente assim que um scrum também funciona. Então, temos uma grande lista de requisitos que chamamos como o backlog do produto. É só uma grande lista de coisas que precisam ser feitas. Fazemos uma reunião de planejamento e do pai grandes listas escolhemos como cinco ou dez requisitos dependendo da disponibilidade ou capacidade das equipes. E nós os chamamos de “backlog do sprint”. Agora trabalhamos sobre eles no próximo ciclo de duas ou quatro semanas que é chamado como um sprint. Enquanto estamos neste sprint, fazemos uma reunião diária todas as manhãs para discutir o progresso que é chamado como a reunião stand-up. E uma vez que este é sprint termina, nós número um demo, o que quer que tenhamos feito com as partes interessadas para obter o seu feedback. E número dois, nós retrospectamos como uma equipe o que era bom e o que poderia ter sido melhor no último sprint. E então repetimos tudo isso novamente na forma de um novo sprint está começando com uma nova reunião de planejamento sprint. Então papai disse, todo esse ciclo é o que Scrum é. Não há uma maneira mais simples de entender isso. Agora aqui está a mesma coisa na forma de um gráfico. Então nós temos o backlog do produto, que aprendemos é uma grande lista de requisitos que a equipe se reúne para uma reunião de planejamento e escolher uma lista menor dele chamado um sprint backlog. Eles vão fazer neste sprint. E mais uma vez, não se preocupe com os detalhes mais finos de como o fazemos. Veremos isso mais tarde em detalhes completos. Mas nesta palestra estamos apenas arranhando a superfície das coisas. Então nós escolhemos um pequeno subconjunto de requisitos para fazer isso é chamado de sprint backlog. Desenvolvemos e testamos essas coisas no sprint de duas ou quatro semanas. E então vamos para uma demonstração com as partes interessadas. Vamos fazer uma retrospectiva com toda a equipe. E também podemos liberar esse incremento para os usuários finais. Então muito simples descarga que você vê aqui é todo o scrum em um nível alto. Essas outras tarefas que você vê aqui, o proprietário do produto, a equipe, o mestre scrum. Estes são chamados como as regras Scrum e veremos sobre eles mais tarde. E então há diferentes reuniões ou cerimônias que fazemos no Scrum para obter tudo isso juntos e vamos dar uma olhada nos dados também mais tarde. Mas isso aqui na sua tela é uma imagem de alto nível. E mais uma vez, se você olhar para ele, novamente se resume a apenas três palavras. Iterar todo o processo que estamos fazendo de novo e de novo. Forneça incremento ao usuário final, receba feedback e incorpore esse conjunto. Então dat era caras é migalha em poucas palavras. Agora, antes de escolhermos os aspectos que vimos aqui com muito detalhe mais tarde, vamos ver um último tópico deste capítulo na próxima palestra. Obrigado. 7. MVP e abordagem incremental: Olá a todos. Então vamos falar um pouco sobre MVP e abordagem incremental nesta palestra. Agora continuamos vendo que h l é tudo sobre incrementos. Então, como funciona esse conceito de incremento? Vamos dar uma olhada e você sabe o que, vamos entender primeiro, por que uma imagem? E então voltaremos a esses slides. Então pessoal, o que você vê na imagem é o que MVP ou produto mínimo viável significa. Lembre-se não esta parte superior, a inferior, nós damos ao cliente um mínimo, algo que cumpra seus requisitos. Nós deixamos que eles usem. Pegamos seu feedback e, em seguida, melhoramos nos próximos incrementos. E continuamos repetindo todo esse ciclo, entregando novos incrementos no processo. Agora lembre-se que a parte superior da imagem é a abordagem tradicional, como a cachoeira, onde estamos dando algo ao cliente em incrementos, mas eles não podem usá-lo como eles não podem usar apenas duas peças de pneu. Eles não podem dar feedback sobre isso. E quando o produto final estiver pronto, haveria muitas coisas que eles gostariam de mudar. E então acabaríamos com o mesmo problema que falamos anteriormente com a abordagem tradicional. Então, tudo bem. Oi l. O que estamos fazendo é que estamos dando o skate estado cliente para que eles possam viajar. Então eles virão com o feedback que OK, Eu quero algo mais rápido e com um opções de sessão. Então vamos dar-lhes uma bicicleta. Então eles voltarão novamente com o feedback de que eu quero algo que não tome nenhum esforço que é um mais rápido, então vamos dar-lhes um motociclo ou um carro e assim por diante. Então, em cada incremento, estamos dando aos clientes algo que eles podem usar, algo que eles podem dar feedback sobre. Com base nisso, estamos melhorando o produto. Então isso é pessoal, o que MVP é o produto mínimo viável. Damos uma versão inicial do produto ao cliente que ele pode usar. A obter o feedback deles. Melhoramos nos próximos incrementos e iterações. Então é baseado na abordagem de construir, medir e aprender, que significa que estamos construindo algo. Estamos recebendo o feedback e estamos analisando-o, medindo-o. Estamos aprendendo com esse feedback e estamos fazendo coisas novas. E novamente, pessoal, se pensarem bem, esse conceito subjacente é novamente, iteração e incremento. Construímos o produto, medimos o feedback, aprendemos com ele e fazemos tudo de novo. Então esse é todo o conceito e é importante entender porque este é o quadro maior do hL e é migalha. Lembre-se que não podemos fazer as coisas em um único curto. Isso significaria cometer os mesmos erros que cometemos com a abordagem tradicional. Então nos reunimos como uma equipe colaborativa. Fazemos coisas em iteração. Nós projetamos o MVP inicial. Nós colocamos melhorias incrementais nele e isso é tudo sobre isso. Isso é tudo o que há para entender. Incrível. Então agora estamos no final deste capítulo e vamos aprender os conceitos centrais aqui. Aprendemos que idade eu l é, o que é Scrum é um alto nível de como eles operam e como todo o incremento MVP funciona. Vamos continuar esses aprendizados para o próximo capítulo e ver todos estes e mais conceito em detalhes. Então vai ser uma viagem de aprendizagem muito emocionante. Mas antes de terminar este capítulo, eu só queria deixá-los com dois pensamentos que são mais importantes para alguém que trabalha com HIV. Então o primeiro pensamento é que h L não é apenas um livro guia. O mais importante é uma mentalidade. Se somos pensamentos altamente número, Se somos Eileen idade, nosso trabalho, nossa colaboração com sua equipe, só então podemos implementar com sucesso um gel ou um Scrum. Então pense na HCI como uma mentalidade que é mais importante. Segundo, HIS ou um scrum não é uma vara mágica que resolverá todos os nossos problemas. Pode mostrar-nos quais são os problemas ou quais foram os problemas com a indústria. Mas cabe a nós levar a mentalidade ágil, trabalhar juntos como uma equipe para resolver esses problemas e entregar produtos excepcionais ao usuário final. Então, novamente, os dois conceitos, manter uma mentalidade infantil e segundo, usar IL-2 idade. Conheça seus problemas. Não é um bastão mágico que pode resolver todos os seus problemas. Então pessoal, com esse pensamento, vamos passar para o próximo capítulo e aprender sobre algo que é conhecido como os papéis do Scrum, as pessoas que compõem o Scrum. Vejo-te na próxima palestra até lá. Obrigado. 8. Introdução a papéis de Scrum e Stakeholders: Olá a todos e bem-vindos ao terceiro capítulo do curso. Agora começando este capítulo, vamos escolher um por um, os tópicos que discutimos no último capítulo. E nós vamos aprofundar eles para saber todos os detalhes. Então esse tópico que vamos abordar neste capítulo são as pessoas que compõem uma equipe Scrum, mais comumente conhecido como os papéis Scrum. E eu escolho esse tópico em particular primeiro, porque como vimos no último capítulo, o primeiro valor central de h l diz indivíduos e interações sobre processos e ferramentas. Portanto, os indivíduos são o componente mais importante de uma equipe Scrum. E então vamos primeiro saber sobre eles neste capítulo. E você sabe o que, nós vamos abordar este capítulo muito interativamente. Na verdade, vamos chamar as pessoas de papéis de Scrum como nossos amigos e vamos conhecê-los um por um e saber qual é o seu trabalho, quais são as suas responsabilidades, etc. Então vamos começar. E aqui está a agenda deste capítulo. Então vamos falar sobre os seguintes papéis. Eles detentores da participação, o proprietário do produto, a equipe de desenvolvimento, O Mestre Scrum. E finalmente, vamos discutir a dinâmica da equipe scrum. Então, qual é a ligação e a relação entre eles? Então vamos começar. Então caras, esses são os diferentes papéis do Scrum ou a maneira que chamamos isso neste curso, nossos amigos no Scrum está começando do canto inferior esquerdo. Temos os detentores de participação que são externos a uma equipe Scrum, mas eles têm os requisitos de negócios em que 13 funciona. Então temos o proprietário do produto que é como o capitão da equipe. Ele ou ela decide o que a equipe tem que fazer e ele define a prioridade das coisas. Então temos a equipe de desenvolvimento que faz o trabalho de codificação ou teste. E finalmente temos o mestre scrum que é como o guarda da equipe. E ele ou ela se certifica de que a equipe segue é migalha efetivamente e eles não são blogados em nada. Também caras, na extrema direita, temos o usuário final para o qual todo o trabalho está sendo feito. Então, embora não seja um papel Scrum, ainda é, é muito importante manter sempre o usuário final em mente, porque ele ou ela é aquele para quem todo o trabalho está sendo feito e cuidar sua exigência e feedback é Muito, muito importante. Então vamos começar e dar uma olhada em nossa primeira regra, nosso primeiro amigo, eu apostadores. Então, quem são os detentores da participação? Bem, uma parte interessada é em primeiro lugar alguém que é externo à equipe scrum. E em segundo lugar, quem tem um interesse ou exigência ou conhecimento do produto que está sendo criado. Então pense no titular da participação como a equipe de gerenciamento de produtos em sua empresa que está recebendo requisitos do usuário final e passando-o para a equipe scrum. Ou alguém em vendas, ou mesmo o CEO da empresa poderia ser um detentor de participações. Quando estamos trabalhando na página de termos e condições, o cara do departamento jurídico será um detentor de estaca porque ele ou ela fornecerá o texto a ser escrito. Quando um fluxo promocional está sendo projetado, o membro da equipe de marketing será uma das partes interessadas porque ele ou ela usará o sistema. E se a equipe Scrum está trabalhando em algo e eles recebem ajuda de uma pessoa em outra equipe porque ele ou ela tem mais conhecimento de dívida. Isso também é uma parte interessada. Então, todos esses são como diferentes partes interessadas e esses acionistas revelam seu design, produto ou software. E eles fornecem o feedback, vindo diretamente deles ou do usuário final. E isso nos ajuda a criar um produto melhor e valioso. Então caras, pais o significado de detentor de estaca. Só para recapitular rapidamente, ele ou ela é externo ao scrum. Ele ou ela tem um requisito de interesse ou conhecimento do produto. E, finalmente, ele ou ela ajuda a fornecer informações para criar um produto melhor para o usuário final. Tudo bem, então agora que sabemos quem é a parte interessada, vamos olhar para o outro papel Scrum ou amigos na próxima palestra. Obrigado. 9. Proprietário Proprietário de produtos — papéis e responsabilidades: Olá e bem-vindo de volta. Vamos falar sobre o nosso próximo amigo no Scrum. Então os caras na sua tela são Kevin, e Kevin é o proprietário do produto. Scrum papel que vamos falar nesta palestra é o proprietário do produto, ou PO Em suma. Agora, o proprietário do produto é um papel muito importante na equipe scrum porque ele ou ela é como o líder da equipe e a voz dos clientes precisam para sua equipe. Kevin aqui é responsável por garantir que essa equipe forneça produtos valiosos para os usuários finais ou partes interessadas. Kevin também tem que definir metas e visão criativa do produto. Então, a equipe scrum que ele está liderando, os desenvolvedores finais ou testadores, eles não sabem sobre o produto, o que se destina, qual é o requisito a ser cumprido? Eles só sabem sobre os aspectos técnicos. Então Kevin tem que definir esses requisitos de negócios para a equipe. Ele tem que traduzir esses requisitos de negócios para a forma como a dívida que a equipe entende e sabe o que tem que ser feito. Além disso, Kevin tem que gerenciar o atraso do produto. Então vimos no último capítulo que o Product Backlog é como uma grande lista de requisitos que tem que ser feito. A tarefa de gerenciar essa lista é com o proprietário do produto. Ele tem que criar requisitos no backlog conhecido conhecido como histórias de usuários, ele tem que escrever os requisitos de baixo nível ou critérios de aceitação neles. Ele tem que modificar os requisitos, removê-los, priorizá-los, etc E, de fato, esta é uma das responsabilidades mais importantes de um proprietário de produto. Os dados são para manter o backlog do produto. Próximo ponto. próxima responsabilidade é gerenciar a prioridade das coisas em termos de tempo, dinheiro é escopo, etc. Tão bem claro. Pronto, tarefa importante novamente. Em seguida, Kevin tem que supervisionar o desenvolvimento real do produto. Então ele tem a configuração de backlog, ele tem o orçamento limpo. Agora ele tem que se certificar de que o trabalho real de fazer o produto acontece é sem problemas. Então isso, isso significa trabalhar com a equipe de desenvolvimento, fazendo um planejamento de sprint para corrigir a agenda do sprint. Responda a qualquer dívida de consulta que a equipe tem apoiar seu trabalho, et cetera. Também significa trabalhar com as partes interessadas para planejar as próximas adições incrementais ao produto ou ao lançamento, etc. Quinta tarefa, Kevin tem que antecipar as necessidades dos clientes. Então, novamente, para reiterar, todo o trabalho que estamos fazendo na equipe é para o cliente, o usuário final, e o proprietário do produto tem que entender o que o cliente precisa. Muitos requisitos do usuário vêm dos acionistas, mas eles estarão em um nível alto, como melhor implementá-lo, como ler a mente do cliente, como prever quaisquer riscos que eles possam ter. Tudo o, tudo isso é o trabalho diário de um proprietário de produto e uma tarefa muito importante. Em seguida, Kevin, o proprietário do produto, tem que atuar como uma ligação entre as partes interessadas, a equipe scrum, ou até mesmo os usuários. Então ele é o principal comunicador da equipe. Ele se comunica com os caras externos. Ele se comunica com os caras externos. Ele é o comunicador da equipe. E finalmente, Kevin é responsável por cada iteração e incremento do produto. Então ele tem que se certificar de que há melhorias suficientes, fim do progresso sendo feito com cada iteração, a chamada final sobre a qualidade do desempenho do produto, etc. É com o proprietário do produto e ele tem que decidir se a equipe pode avançar ou precisa voltar e refazer as coisas. Então, pessoal, em sua tela, o que você vê são as principais funções e responsabilidades do proprietário do produto. Agora, antes de concluir mais um ponto, lembre-se muitas vezes que poderia haver um analista de negócios também em sua equipe que irá descarregar parte do trabalho do proprietário do produto. Assim, o analista de negócios e os papéis e responsabilidades do proprietário do produto se sobrepõem um pouco. Ele ou ela pode tomar parte do trabalho que o proprietário do produto faz. Tudo bem, como vimos, o proprietário do produto é um papel muito importante na equipe de Scrum. E o proprietário do produto é aquele que tem que fazer malabarismos entre muitas responsabilidades. Só para recapitular aqui é trabalhar com as partes interessadas de um lado, a equipe scrum do outro lado. Ele tem que conseguir os requisitos, traduzi-los. E ele é o único que tem que finalmente se certificar de que todo o processo scrum está adicionando valores incrementais para o benefício do usuário final. Então papel muito importante, muitas responsabilidades para o nosso amigo Kevin aqui. Ótima. Então, agora que sabemos sobre o proprietário do produto, vamos dar uma olhada em outro papel na próxima palestra. Obrigado. 10. Equipe de desenvolvimento — papéis e responsabilidades: Olá a todos e bem-vindos de volta. Vamos falar sobre nossos próximos amigos em Scrum. Diga olá ao Andrew e à Karen. Andrew é um desenvolvedor da equipe e Karen é a QA ou tester. E ambos são referidos como a Equipe de Desenvolvimento. Então, apenas uma nota rápida aqui, embora a equipe scrum contém papéis diferentes, como desenvolvedor ou um testador, ou designer ou desenvolvedor sênior ou testador sênior é migalha não chamá-los separados. Eles são todos conhecidos apenas como equipe de desenvolvimento porque eles estão desenvolvendo o produto de acordo com as necessidades do proprietário do produto. Então estas são as pessoas que são responsáveis pela entrega do produto final. E essa é sua responsabilidade de alto nível apenas para resumir as coisas em uma frase. Mas vamos considerar isso com mais detalhes. A primeira responsabilidade de Andrew e Karen é entender histórias de usuários que são escritas pelo proprietário do produto. Eles têm que implementar essas histórias. Então, obviamente, eles têm que saber sobre isso quando a equipe se reúne para o planejamento de sprint ou preparação de backlog. E vamos olhar para essas cerimônias em detalhes no capítulo posterior, a equipe de desenvolvimento tem que se certificar de que eles entendem completamente o que o usuário é. história diz, o que o proprietário do produto quer, quais são os requisitos exatos para que as coisas possam ser projetadas da mesma maneira. No dia seguinte também fornecer entradas na criação das histórias de usuários. E lembre-se que estes são apenas entradas a equipe de desenvolvimento geralmente não cria um usuário é historiado, Isso é o trabalho de toner produto. Mas eles podem continuar lascando com entradas ou sugestões, etc Se é uma história puramente tecnicamente, então querida entrada provavelmente será tomada como a chamada final. Mas a principal responsabilidade de criar histórias de usuários é com o proprietário do produto. A equipe de desenvolvimento só o apoia. terceira responsabilidade de nossos amigos Andrew e Karen é estimar as histórias de usuários. Então estimativa é um grande tópico em um scrum e nós temos um capítulo dedicado sobre isso mais tarde. Por enquanto, saiba que a equipe de desenvolvimento irá fornecer suas estimativas para a história do usuário para que o proprietário do produto saiba quanto trabalho pode ser entregue em um sprint. Em quarto lugar, a equipe de desenvolvimento vai se comprometer com histórias de usuários para ser feito em um sprint. E esse compromisso vem depois do planejamento de sprint. E é algo que a equipe de desenvolvimento tem que ser honesta também, e garantiu que esse compromisso seja cumprido. próximo ponto é o aspecto do trabalho. Então escrever código ou testar as histórias do usuário que foram tomadas e garantir que a entrega do produto de qualidade para o usuário final. Na verdade, esta é a maior parte do trabalho da equipe de desenvolvimento e é aqui que sua maioria tempo e esforço irá cada sprint. Então eles são os únicos que estariam traduzindo os requisitos em um trabalho eficaz. Certo, então temos a responsabilidade de identificar riscos. E sempre que dizemos risco, tem que incluir também mitigação. Então, se algo não pode ser feito, algo corre o risco de não ser concluído. A equipe de desenvolvimento tem que elevá-lo para o mestre scrum ou proprietário do produto para que eles possam ajudar a resolvê-lo. E a responsabilidade final é empurrar as mudanças na produção para que equipe melhore a qualidade do design depois que eles gritam é sprint ends ou sempre que o proprietário do produto quiser, a equipe tem que empurrar esses incrementos, essas mudanças no ambiente ao vivo para que o usuário final possa usá-lo e todo o seu trabalho duro possa ser colocado em uso. Tudo bem, pessoal. Estes foram alguns dos papéis e responsabilidades de Andrew e Karen, nossa equipe de desenvolvimento. E apenas para resumir mais uma vez em uma frase, a equipe de desenvolvimento são os únicos entregando o produto final de acordo com os requisitos fornecidos pelo proprietário do produto. Ok, vamos passar para o último papel agora, que é o Scrum Master. Então vamos ver isso na próxima palestra. Obrigado. 11. Scrum Master — papéis e responsabilidades: Olá a todos e bem-vindos de volta. Vamos falar sobre o papel de Scrum Master. Agora, quando pensamos em papéis Scrum, o primeiro termo que vem à nossa mente é de um Scrum Master. Mas sabe, guardei isso intencionalmente por último para sabermos quais são os outros papéis. E então podemos ver como o Scrum Master ajuda a facilitar o trabalho para todos eles. Então, pessoal, este aqui é o nosso amigo Bob, que é o Mestre Scrum da equipa. E eu vou te dizer o que Bob tem um papel muito interessante na equipe porque ele tem que apoiar a equipe. Ele tem que se certificar de que a equipe segue as melhores práticas. E você também tem que se certificar de que os membros da equipe não estão blogados em nada. Então o primeiro ponto que você vai notar sobre Bob é que ele é o líder servo da equipe scrum. E o que isso significa é que ele tem que seguir um estilo de liderança de apoio. Ele tem que apoiar a equipe, servindo os diferentes papéis na equipe. Ele está servindo o proprietário do produto em muitas coisas. Ele está servindo a equipe de desenvolvimento e ele também está servindo a organização adotando com sucesso uma criança. Então é por isso que, como eu disse, é Scrum Master é um líder servo. É um dos papéis mais importantes e amplos na equipe. O Mestre Scrum ajuda o Proprietário do Produto no planejamento do trabalho com a equipe para que as metas de entrega do Proprietário do Produto sejam atendidas. E ele também ajuda o proprietário do produto na gestão do backlog de requisitos. É eficaz e atualizado. Em seguida, o Scrum Master garante que todos na equipe entendam os objetivos e o escopo do trabalho que é necessário. Então, estas são as maneiras pelas quais o Scrum Master ajuda o proprietário do produto. Ele o ajuda com o atraso e ele ajuda a definir os objetivos e o escopo da dívida para com todos na equipe. Então, todos estão na mesma página e fazem o trabalho que o proprietário do produto quer. Em seguida, vamos falar sobre as maneiras pelas quais Bob, o Scrum Master, está ajudando a equipe de desenvolvimento. Então ele é responsável por garantir que a equipe não seja bloqueada. Eles não são distraídos por interrupções externas ou outras distrações e que eles são capazes de trabalhar nos compromissos sprint. E este é um trabalho muito importante caras porque você sabe que a equipe se comprometeu com um conjunto de trabalho para o sprint. E se eles estão sendo desviados ou distraídos do que isso, trabalho será dificultado com certeza. Então, é o trabalho de um Scrum Master garantir que isso não aconteça. A equipe é capaz de se concentrar em seus compromissos. Mesmo tempo é Scrum Master também garante que a equipe não está sobrecarregado. Assim, durante um planejamento de sprint, o scrum master verifica as estimativas e planejamento de capacidade para garantir que todos tenham trabalho suficiente, mas ninguém tem excesso de trabalho. Então estas são as maneiras pelas quais o Scrum Master serve a equipe de desenvolvimento. E, finalmente, o Scrum Master é o HAL Coach das organizações. Então Bob aqui tem que organizar as diferentes cerimônias de migalhas. Como eles se levantam, eles correm, planejam, retrospectivos, etc. E veremos essas cerimônias em detalhes mais tarde. Mas, por enquanto, o Mestre Scrum é o facilitador, o organizador de todas essas cerimônias. E, por último, ele tem de se certificar de que o scrum está a ser seguido eficazmente na organização. E ele tem que se certificar de que as melhores práticas são diploides. Então, estas são a contribuição do Scrum Master para a organização. Resumindo, tudo como eu disse, é Scrum Master é um papel com um conjunto muito amplo de responsabilidades. Quando falamos sobre trabalhar em um scrum ou H L e falamos sobre seus benefícios. Esses benefícios só acontecerão quando uma criança ou um Scrum estiver sendo seguido de forma eficaz, quando as pessoas forem capazes de trabalhar eficazmente sem distrações. Quando a visão do proprietário do produto são transferidos para a equipe eo trabalho de um mestre Scrum para garantir que tudo isso acontece. Então, como você pode entender a importância de Bob, o Scrum Master é muito na equipe. Tudo bem, agora que sabemos todos os papéis diferentes em uma equipe Scrum, vamos falar um pouco sobre eles se juntarem e trabalharem juntos. Isso é sobre a dinâmica da equipe na próxima palestra. Obrigado. 12. Dinâmica de equipe de Scrum: Olá a todos e bem-vindos de volta. Vamos entender o conceito de dinâmica da equipe Scrum. Então sabemos que uma equipe Scrum tem um proprietário de produto, uma equipe de desenvolvimento analista de negócios, Scrum Master. Então, como esses caras se unem para trabalhar juntos como uma única unidade? Qual é a sinergia que os une? A resposta a tudo isso é, novamente, o que vimos no capítulo anterior. O primeiro valor central da dívida é indivíduos e interações sobre processos e ferramentas. E isso é o que impulsiona a dinâmica da equipe. Então vimos anteriormente que é Scrum equipes estão auto-organizando e auto-gerenciando. Isso significa que as equipes Scrum não devem ser governadas por métodos antigos. Não há nenhum gerente de desenvolvimento ou gerente de teste dentro da equipe scrum para controlar recursos ou estimar coisas que a equipe efetivamente gerencia em si mesmo. A equipe estima para o seu trabalho. Eles dizem ao proprietário do produto quanto tempo levará, quem fará a tarefa, etc., e honram seus compromissos. Próximo ponto, o Mestre Scrum está lá para agir como um facilitador para organizar as coisas. E como vimos, essa é uma das responsabilidades de um Mestre Scrum. Mas você sabe o que a equipe não deve depender inteiramente de um mestre scrum. Vamos salvar o Scrum Master está de licença, um dia ainda é então a equipe deve se reunir e fazer o seu stand up diário. Porque o conceito, lembre-se caras é de auto-gestão, para interagir, para colaborar uns com os outros, não para o doador do produto ou um mestre Scrum não ser dependente deles. terceiro ponto é as equipes Scrum ter sucesso ou falhar como uma equipe inteira. Então, quando falamos sobre relatórios de idade da OIT no capítulo posterior, veremos que as equipes são avaliadas sobre quanto é storypoints que são entregues, quantas histórias eles fecharam, fecharam, etc. Então é a saída da equipe que a equipe reservou, não indivíduos, assim como temos nos esportes. Na verdade, a palavra é Scrum em si vem dos esportes de rugby. próximo ponto é que as equipes Scrum são multifuncionais. Eles não vão por títulos. Então, como vimos anteriormente também, há uma única equipe de desenvolvimento. Não há desenvolvedor, arquiteto, testador, designer, etc. Não há nenhuma categorização, se necessário, o desenvolvedor também deve fazer esse teste. O testador pode assumir o trabalho de BA, etc. Quinto, e daqui em diante estamos a falar de cultura. Então é uma coisa cultural. I equipes Scrum tipicamente R é menor em tamanho, que é cerca de nove a 12 pessoas é um número muito bom e toda esta equipe se senta juntos. Não há conceito de isolamento, não há conceito de cabines separadas. Essa equipe se senta juntos. Eles se sentam perto um do outro, então há uma ligação entre a equipe, um ambiente aberto para discussão. E último ponto é uma cultura de comunicação eficaz na equipe. Portanto, há um stand up diário pela manhã. Equipe sentar juntos, eles discutem sobre coisas que eles se comunicam com o outro é Scrum equipes têm um nome de equipe, nosso manifesto de equipe, etc. E tudo isso ajuda a criar uma ligação, uma sinergia entre sua equipe. Então pessoal, estes foram alguns dos pontos para alcançar a dinâmica da equipe porque lembre-se, HI, ou é Scrum é tudo sobre indivíduos e interações. Portanto, é muito importante que as equipes trabalhem juntas e entreguem produtos excepcionais ao cliente. Certo, isso nos leva ao final do capítulo, mas aprenderemos algumas coisas legais aqui. Conhecemos nossos amigos na Equipe Scrum. Aprendemos como funciona a dinâmica da equipe. Agora, no próximo capítulo, vamos falar sobre suas reuniões, suas interações no que é conhecido como cerimônias Scrum. Então, vemo-nos no próximo capítulo. Obrigado. 13. Backlog e introdução às Ceremonies de Backlog: Olá a todos, e bem-vindos ao quarto capítulo do curso. Então, até agora, aprendemos as definições de Agile e Scrum. E nós vimos as diferentes regras, todos os indivíduos que compõem a equipe scrum. Agora neste capítulo, vamos falar sobre as várias reuniões em que esses papéis participam, e isso é conhecido como as cerimônias Scrum. Agora, antes de avançarmos, apenas para recapitular mais uma vez, é Scrum é baseado nos conceitos de iteração e incrementos. Então, um Scrum é tudo sobre repetição de iterações chamadas sprints, em que projetamos incrementos para o usuário final. E para gerenciar esses sprints de forma eficaz. Para executar esses sprints de forma eficiente, há uma sequência de reuniões ou cerimônias que acontecem. Neste capítulo, vamos falar sobre essas cerimônias e na ordem em que elas acontecem. Então você obtém a seqüência lógica das coisas. E no final, vamos olhar para eles juntos e então entenderemos que todo o ciclo é migalha. Então, vamos começar. Então, pessoal, aqui estão o conteúdo deste capítulo e estes não são nada mais que diferentes são as cerimônias de migalhas. Agora, em um dos capítulo anterior, falamos um pouco sobre o ciclo de vida Scrum. E eu mencionei como é muito semelhante a como planejamos as coisas em nossa vida diária. Então, se você conseguir isso, você terá o propósito dessas cerimônias também. Então me ouça e assista o ponteiro do mouse em conformidade para ver como ele se relaciona com Scrum. Então pessoal, vamos pensar em como trabalhamos na nossa vida real. Como lidamos com as coisas na nossa vida real? Então escrevemos uma grande lista de coisas que queremos fazer em nossa vida. E então tomamos um pequeno subconjunto dele que decidimos realizar em digamos, na próxima semana ou duas semanas, etc. Pensaríamos diariamente, quanto conseguimos nesse objetivo, se alguma correção necessária, se algo está nos bloqueando, etc. E quando a semana termina, tomamos uma recapitulação de como as coisas quando fazemos a correção do curso, e então repetimos tudo de novo na próxima semana com uma nova lista. Soa familiar, certo? E deixe-me dizer a vocês o que fazemos no Scrum é totalmente semelhante a isso. Como você teria adivinhado. Pegamos um backlog ou uma grande lista de requisitos, escolhemos um pequeno subconjunto dele, trabalhamos nele no sprint. Uma vez que o sprint termina, demonstramos o trabalho para nossas partes interessadas para que possamos chegar lá feedback rápido. Depois fazemos uma retrospectiva das coisas para melhorar. E enviamos as alterações para o usuário final, se necessário. E então repetimos tudo isso de novo e de novo. Isso é tudo o que é. Esse é todo o ciclo de suas cerimônias do Come. Veja como é simples. Então vamos seguir em frente e verificar cada uma dessas cerimônias com mais detalhes. Então pessoal, vamos falar sobre a nossa cerimónia de migalhas mais rápida, a preparação de pendências. Mas antes disso, eu só queria mencionar que vamos falar sobre cada uma das cerimônias no mesmo formato que você vê na tela. Ou seja, quando estiver feito. Quem são os participantes, quanto duração o bife cerimônia, e, finalmente, qual é o seu propósito? Então, vamos começar. Então, o que é preparação de backlog? Agora, como o nome sugere, é uma preparação ou um refinamento do atraso. Então, para entender esta cerimônia, primeiro precisamos entender o que é esse atraso? Agora, quando estamos em desenvolvimento de produtos, temos que trabalhar em projetar novos requisitos, certo? Então, obviamente, precisamos capturar esses requisitos em algum lugar. E DAT É o que quer que seja o backlog. O backlog é uma lista de novos recursos ou alterações em recursos existentes, bugs, tudo o que a equipe tem que fazer. Então pense nisso como uma grande lista de requisitos que é criada pelo Proprietário do Produto em consulta com as partes interessadas, e esse é o trabalho que a equipe tem que fazer. Agora esta lista obviamente continha toneladas de recursos, certo? Então precisamos revisá-lo periodicamente. Precisamos adicionar detalhes a ele, precisamos priorizá-lo, etc. E isso é importante, isso é importante caras porque então só teremos itens que estão prontos para trabalhar nas próximas duas semanas sprint a lista priorizada de itens. E este tipo é exactamente o que a preparação de pendências ou a cerimónia de Refinamento de Backlog faz. Então vamos olhar para os outros slides. Primeiro, quando é que esta preparação é feita? Isso é feito antes do planejamento sprint. E isso faz sentido, certo? Porque precisamos dos itens prioritários prontos para discussão pelo planejamento de sprint. Além disso, não há regra dura e rápida. Quantos dias antes de um planejamento sprint você deve fazê-lo. Mas como dois a três dias antes do planejamento é bom, nós não queremos fazer isso muito cedo e então as coisas podem mudar. Então vamos ficar de dois a três dias antes do sprint começar. O próximo sprint é começa. Isso deve ser bom. Próximo ponto, quem vai participar da preparação pendente? Então, obviamente, precisamos do proprietário do produto porque ele ou ela é responsável pelo atraso. O que deve ser feito? Qual é a prioridade se a equipe tiver alguma dúvida, ele ou ela pode responder. Então definitivamente precisamos do proprietário do produto. Então temos o mestre do Scrum apoiando ele ou ela. Lembre-se, o Scrum Master ajuda o proprietário do produto trabalho indiferente. Então, ajudá-lo a preparar o backlog, ajudando-os a refinar o backlog é uma das tarefas do Scrum Master. Então o proprietário do produto estaria lá, o Scrum Master estaria lá. E, finalmente, precisamos da equipe de desenvolvimento, então não precisamos de todos os eventos da equipe de desenvolvimento. Algumas pessoas da equipe de desenvolvimento também farão o trabalho. Próximo. Quanto tempo essa reunião ri. Então, novamente, nenhuma regra dura e rápida, mas como uma hora é bom. Lembra que conversamos sobre cuidar de backlog três dias antes do planejamento de sprint, certo? E isso significa que essa equipe seria o fim da corrente é sprint. Então, obviamente, a equipe terá um monte de trabalho para terminar e nós não queremos mantê-los sentados por como cinco horas em uma reunião. Assim, uma hora de preparação é suficiente, se necessário. Podemos fazer outra sessão de uma hora depois, mas isso deve ser suficiente. Não queremos manter essa equipe aguentada por longas horas antes que o próximo no final da corrente seja sprint porque eles teriam trabalhado para completar. Então faríamos de dois a três dias antes do planejamento de sprint. E como uma hora, se necessário, faremos outra sessão de uma hora, mas não muito longa. E, por último, qual é o propósito da preparação de pendências? Então, primeiro, revisamos histórias de usuários que precisam ser feitas no próximo sprint. ponto mais importante, temos que preparar as coisas porque o próximo sprint vai chegar nos próximos dois ou três dias. Então precisamos estar prontos com o conteúdo que temos que fazer seu próximo, temos que resolver fatos desconhecidos e incertos para uma estimativa correta. Então lembre-se que esta é a primeira vez que a equipe de desenvolvimento está vendo as histórias dos usuários. Então eles podem ter algumas perguntas, obviamente, e nós temos que resolvê-las na reunião de preparação. Quem vai resolvê-los? O proprietário do produto irá dissolvê-los. E ao resolver é necessário para que a equipe possa estimar o trabalho corretamente. Terceiro ponto, identificar dependências e riscos de antemão. Então, estamos planejando levar as histórias de prioridade máxima do Tau no próximo sprint. Então, vamos identificar quaisquer riscos ou dependência neles apenas agora, para que não fiquemos presos mais tarde. Próximo ponto, atribua estimativas a histórias de usuários. Então isso é como discutir pontos da história e vamos ver estimativa em muito detalhes mais tarde em um capítulo posterior. Mas por enquanto, saiba que a história de cada usuário tem que ter um ponto de história para estimativa. E este é o ponto de história é dado idealmente em preparação backlog. Algumas equipes fazem isso em um planejamento de sprint, mas a preparação de backlog é o momento mais ideal para fazê-lo. Em quinto lugar, dividimos as histórias de usuários que são muito complexas ou são nossas incógnitas. Então, se há um monte de trabalho em um usuário é história e equipe sente que eles não seriam capazes de fazê-lo em um sprint, então podemos dividi-lo em várias histórias. Então essa é também uma das agendas de preparação de backlog. E por último o ponto chave para levar. preparação bem-sucedida leva a um planejamento de sprint eficaz. Então, quanto mais esforço nós colocamos em preparação de backlog, mais preparados nós fazemos as coisas durante a preparação de backlog, mais eficaz é o sprint que teremos. E isso fazia sentido, pessoal? Porque lembre-se, nossos requisitos são claros, nossos requisitos são descritivos sua estimada corretamente, então as coisas seriam muito fáceis no próximo sprint. Tudo bem, então isso foi tudo sobre preparação de backlog. Nós completamos a primeira cerimônia. Agora temos uma lista prioritária de requisitos. Sabemos em que coisas temos que trabalhar no próximo sprint. Então vamos dar uma olhada na próxima cerimônia. Eles correm o planejamento na próxima palestra. Obrigado. 14. Planejamento de sprint: Olá a todos e bem-vindos de volta. Vamos falar sobre a próxima cerimônia. Eles correm o planejamento. Então eles sprint planejamento é o mais importante é cerimônia migalhas, e envolve vários aspectos. Vamos falar sobre essas coisas aqui em um alto nível. E, em seguida, em um capítulo posterior, vamos realmente aprender um planejamento sprint com mais detalhes, incluindo técnicas de importância e estimativa. Então vamos começar. Agora, se recapitularmos a última palestra, fizemos a preparação do backlog e a equipe finalizou as histórias dos usuários em termos de ordem de prioridade. A equipe discutiu essas histórias de usuários e se eles tinham quaisquer consultas ou dependências ou riscos, eles foram levados para o proprietário do produto e espero que ele ou ela tenha resolvido isso. Então agora estamos prontos para ir para o próximo sprint e começar a trabalhar nesses requisitos, essas histórias de usuários. Mas antes disso, precisamos planejar como fazê-lo. E a atividade de dados é chamada como um planejamento de sprint. Quando isso é feito, obviamente no início do sprint, não podemos iniciar o sprint a menos que tenhamos concluído o planejamento sprint. Quem participa disso? O proprietário do produto, o Scrum Master, e toda a equipe. Então, na preparação de backlog toda a equipe não era necessária. Mas aqui toda a equipe de desenvolvimento deve participar porque todo mundo vai chegar lá em seguida. Os Sprints trabalham nesta cerimônia apenas no próximo quanto tempo deve durar. Então, novamente, nenhuma regra difícil e rápida, mas para um sprint de duas semanas para o nosso diz, ok, lembre-se se o planejamento Sprint está rodando muito tempo, isso significa que a equipe não está fazendo backlog grooming corretamente porque a maior parte de relacionada com as histórias do usuário deve acontecer apenas na preparação do backlog e no planejamento, devemos idealmente ser apenas estimar e tasking coisas. E, finalmente, vamos ver quais são os propósitos de um planejamento sprint. Então, a primeira coisa, revisamos o atraso e decidimos quais itens puxar para o sprint. Significando o que o usuário é, histórias, bugs, etc As equipes vão trabalhar neste sprint. Lembre-se que as histórias do usuário já estão prontas após preparação do backlog e elas já estão organizadas na ordem de prioridade. Nós só temos que decidir com base na capacidade da equipe, quantos eles podem levar no sprint, como as cinco melhores histórias ou 80 histórias ou histórias de tênis, etc. Em seguida, discutimos a capacidade da equipe. Então falamos sobre quanto é a disponibilidade da equipe? Alguém está de licença? Há um feriado? Alguém tem outro trabalho pessoal ou profissional, etc? Então, esta é uma parte da estimativa e vamos falar sobre capacidade em detalhes no capítulo posterior sobre é planejamento sprint. Em terceiro lugar, atribuímos tarefas para desenvolvedores tester. Então esta é uma grande atividade de um planejamento de sprint. Temos que atribuir o trabalho, essa tarefa para a pessoa da equipe para que todos saibam quem está trabalhando no quê. E lembre-se em Scrum, esta tarefa deve ser mútua. Todos devem dizer por conta própria o que querem trabalhar com base na habilidade, experiência passada, etc. Todos devem ter trabalho igual e suficiente na tarefa e ninguém deve ser sobrecarregado. Período de estimativa de próxima finalidade para cada tarefa. Então, para cada usuário é história, nós criamos tarefa como desenvolvimento, teste, UAT, etc. E a equipe fornece sua entrada como esta tarefa em particular levará quatro horas, isso levará cinco horas, etc. E esta é a estimativa de trabalho das equipes. Em seguida, executamos novamente, as horas disponíveis dessa equipe, essa capacidade total. E com base no dat, decidimos quantas histórias podemos tirar do backlog no próximo sprint. Então, novamente, mais sobre essa capacidade de estimativa, etc, no capítulo posterior. Por enquanto, só sei que é planejamento sprint é a cerimônia em que estimamos o prazo para cada tarefa. Próximo ponto discutimos dependências de risco conhecidas que podem interromper um sprint. Então falamos sobre o risco na preparação também, se eles não são abordados, se há algo mais que surgiu como se não houvesse pessoas suficientes disponíveis no sprint. Se houver alguma informação que surgiu nova e não é totalmente abordada, essas coisas devem ser levantadas durante o planejamento sprint para que saibamos de antemão. E então as coisas não nos atingiriam de repente no meio do sprint depois de já termos comprometido com todo o trabalho. E último ponto é Scrum Master facilita a reunião para garantir uma discussão eficaz e acordo. Este é um ponto muito interessante, pessoal, e vimos mais cedo também que o mestre scrum é o cara que lida com toda a cerimônia, que dirige todas as cerimônias. Então, quando estamos no planejamento de sprint, quando estamos decidindo o trabalho a ser feito, o proprietário do produto, obviamente vamos tentar empurrar para mais trabalho porque ele ou ela tem a pressão de um detentor da estaca para entregar as coisas rapidamente. Escreva a equipe, por outro lado, irá estimar conservadoramente e eles, e assim haveria uma diferença chegando. Pode ser levantada, pode haver dependências, incógnitas. Não haveria trabalho suficiente para todos. Pode haver excesso de trabalho para todos. Todas essas coisas podem acontecer. Então, há vários processos de pensamento que está acontecendo. E é trabalho de um Scrum Master para lidar com todos esses aspectos. O Mestre Scrum facilita a reunião para se certificar de que todos os pontos são discutidos. O Proprietário do Produto responde a todas as perguntas que nossa equipe teve. A equipe não tem quaisquer incógnitas, que a equipe estima as coisas corretamente se houver qualquer risco que eles são tratados de antemão. Vimos o nosso querido também fez o trabalho de um mestre scrum é obter a melhor saída possível e qualidade da equipe. E essas habilidades são usadas melhor durante a sessão de planejamento de sprint. Tudo bem, pessoal, isso foi tudo sobre um planejamento de sprint. Agora lembre-se que novamente temos um capítulo mais tarde para falar é planejamento sprint incluindo estimativa em muito detalhes. Por enquanto, vamos passar para a próxima cerimônia e ver quais dados estão na próxima palestra. Obrigado. 15. Estampa Daily: Olá a todos e bem-vindos à próxima cerimônia, discrição, o stand diário sprint. Então vamos recapitular o que fizemos até agora. Fizemos a preparação do backlog, priorizamos as histórias. Fizemos o planejamento do sprint. Pegamos as histórias de usuários, criamos tarefas para todos, para que todos saibam o que precisam trabalhar. E nós começamos a corrente é sprint. Então agora estamos no sprint atual. E enquanto este sprint estiver sendo executado todas as manhãs, a equipe fará uma reunião rápida de 15 minutos que é chamado stand-up para falar sobre o progresso e bloqueios de estrada. Então, vamos falar sobre esta cerimônia em detalhes primeiro, quando terminar. Então é feito todos os dias do sprint. É feito geralmente pela manhã antes de todos começarem seu trabalho. Então a equipe tem a agenda definida para o dia. Agora, algumas equipes fazem isso duas vezes por dia no início e no final do horário de trabalho. Isso está totalmente bem. Não há ferramenta dura e rápida. Depende do acordo interno da equipe. Mas geralmente uma reunião no início da manhã é ideal. Em seguida, Quem são os participantes? O proprietário do produto, o mestre Scrum, mas o mais importante, toda a equipe de desenvolvimento. Assim, a maioria das pessoas pensa em stand-up como um exercício de reportagem. Somos a equipa que dá o seu estatuto ao proprietário do produto, mas isso não é inteiramente verdade. A reunião é para os membros da equipe dizer que há status para o outro. Então, mesmo que o proprietário do produto ou o Scrum Master não esteja presente na reunião, a equipe ainda deve se reunir para stand-up e eles devem discutir as coisas. Porque lembre-se, eles estão dando seu status para o outro, não para o proprietário do produto ou um mestre scrum. Próximo ponto, qual é a duração do stand-up dele? Portanto, deve ser muito curto, não mais de 15 minutos. Lembre-se, nós só temos que discutir três pontos rápidos que estão escritos abaixo. Não é um estado de trabalho de hora a hora. E assim não deve haver conversas paralelas, nem detalhes profundos. Se houver alguma discussão adicional que está saindo do standup é status. Os indivíduos ou a equipe podem discutir sobre isso depois de todos terem falado, mas isso não deve seqüestrar a reunião stand-up. Queremos encerrar a reunião de stand-up em 15 minutos. E finalmente, qual é o propósito desta cerimônia? Então, antes de mais nada, responder a três perguntas. O que eu fiz ontem? O que vou fazer hoje? Eu tenho algum bloqueador? Então este é o formato dourado de stand-ups em todos os lugares em Scrum. E cada membro da equipe deve continuar respondendo a essas três perguntas. Em seguida, comunicamos o progresso e levantamos impedimentos. Assim, a idéia básica de stand up é compartilhar o progresso que está sendo feito pela equipe diariamente. Por isso, sabemos que estamos a avançar na direcção certa, no ritmo certo. E para levantar qualquer impedimento ou a equipe de dados bloqueador tem para que saibamos o que está segurando a equipe de volta e quem vai ajudar a resolver esse bloqueador, o mestre scrum, ou o proprietário do produto. Último ponto, oportunidade de colaboração pode surgir com base nos status. Então, vamos entrar. Desenvolvedor a diz que eu sou blog porque eu não posso obter o código-fonte na minha máquina local ou desenvolvedor ser relatórios no padrão que eu estou preso porque é uma coisa nova para mim e eu não tenho trabalhado nele recentemente. Portanto, há uma oportunidade de colaboração aqui. Algum outro desenvolvedor na equipe pode dizer que, ok, Eu sei coisa pai, Eu vou ajudá-lo a lembrar um scrum fala sobre colaboração em sua equipe e é stand-ups são uma ótima maneira de promover essa colaboração. Só um conselho. Não comece a falar os detalhes finos no stand em si. Só disse que não se preocupe, eu posso te ajudar nisso. E então os dois indivíduos podem se sincronizar com ele depois que todos terminarem com o stand-up. Portanto, levantar-se é uma ótima oportunidade para relatar o progresso, relatar quaisquer bloqueadores e identificar oportunidades de colaboração entre a equipe. Porque lembre-se que a conclusão do sprint é responsabilidade da equipe. Completar toda a riqueza com que se comprometeram é responsabilidade da equipe. A equipe de refrigerante está dando um status para o outro que está dizendo seu progresso. Eles estão dizendo ao bloqueador, eles estão ajudando uns aos outros. Tudo bem. Agora sabemos o que é a cerimônia de stand-up. Lembre-se de três perguntas. O que eu fiz ontem? O que vou fazer hoje? E eu tenho algum bloqueador? Muito bem, vamos continuar a nossa dinâmica de aprendizagem. E vamos falar sobre a próxima cerimônia na próxima palestra. Obrigado. 16. Revisão ou demonstração: Olá a todos e bem-vindos à quarta discussão cerimônia, que é a revisão sprint. Então, até agora fizemos a preparação do backlog e priorizamos nossos requisitos. Fizemos o planejamento sprint e estimamos e tarefas esses requisitos. Começamos o Sprint e em cada dia com dados mais rápidos stand-up para discutir o progresso. Agora estamos em um ponto onde eles sprint terminou e vamos fazer o nosso primeiro post é atividade impressa, que é chamado de Sprint Review, ou mais comumente a demonstração. Mas antes de começar com os detalhes, vamos pensar sobre por que precisamos da cerimônia. Nós já tomamos os requisitos, as partes interessadas sabem no que essa equipe trabalhou. Então, por que mostrar isso a todos agora? A resposta é o feedback antecipado. Lembre-se, HIS Scrum é o estresse no feedback inicial e contínuo. Portanto, queremos obter esse feedback e queremos melhorar o produto com base na dívida. E também queremos receber esse feedback no início. É por isso que estamos a fazer esta revisão imediatamente após o fim do sprint. Faz sentido, certo? Então vamos ver os detalhes agora. Primeiro, quando é que a revisão de sprint ou demonstração é feita? Então, obviamente, no final do sprint agora não queremos esperar dez dias após o final do sprint. Não queremos fazê-lo o mais rápido possível quando o sprint terminar. Então, idealmente, as equipes fazem isso naquele dia há sprint ends e, em seguida, eles vão o planejamento sprint para o próximo sprint de modo que, se houver qualquer saída vindo desta sessões de demonstração e em nu, melhorias que são necessárias, eles podem rapidamente levá-lo para cima no próximo sprint também. Então, novamente, quando é que a revisão do sprint é feita no final do sprint? Quem são os participantes? Por isso, é a lista completa, mas o mais importante, ele precisa da participação do projeto é Stakeholders e as equipes de gerenciamento de produtos. Porque lembre-se do último capítulo, as partes interessadas são aqueles para quem estamos fazendo todo o trabalho. Por isso, é importante demonstrar-lhes as coisas. Próximo. Qual é a duração desta reunião de revisão? Então 15 a 30 minutos é bom, talvez uma hora. Novamente, não há nenhuma regra dura e rápida, mas é uma demonstração rápida dos novos recursos desenvolvidos. Vamos mostrar-lhes apenas grandes fluxos. Não vamos mostrar-lhes cada cenário de detalhe. Então, 15 a 30 minutos ou no máximo, uma hora é um bom limite de tempo. E, finalmente, qual é o propósito de fazer esta revisão? Então o primeiro é mostrar o trabalho que é feito pela equipe no passado é sprint. Então, é a primeira vez que os detentores de participações vão ver o trabalho para o qual eles tinham dado os requisitos de texto ou textos. Então o proprietário do produto tinha ido buscar os requisitos das partes interessadas aqui, traduziu-o em critérios de aceitação factível. Quanto à equipe, aquela equipe trabalhou nisso, eles entregaram. Então agora é a primeira vez que o titular da estaca vai realmente ver essa coisa em ação. Segundo e mais importante feedback das partes interessadas. Então, como eu disse, cada corredor e Scrum é dependente de feedback precoce e frequente. Então eles sprint demo, vamos garantir que isso aconteça. Em seguida, comemorar realizações e trabalho em equipe. Então, toda a equipe colocou em um é sprints vale a pena de trabalho para criar esses recursos. Eles trabalharam duro para as duas ou três semanas, qualquer que fosse a duração do sprint na organização. E quando esse recurso é mostrado para as várias pessoas, os caras da gerência, eles detentores de estaca, isso traz uma sensação de realização para a equipe scrum. Isso os deixa motivados a ver a saída do trabalho árduo que está sendo rebaixado para todos. Último ponto, idealmente, apenas o trabalho totalmente demonstrável e testado deve ser mostrado. Então isso é como um aviso de isenção de responsabilidade. Não devemos mostrar coisas que estão parcialmente prontas ou que têm vários defeitos. Lembre-se, a saída de cada sprint é o que chamamos de produto potencialmente enviado. Portanto, só devemos apresentar coisas que estão totalmente prontas e testadas. E quem faz essa ligação? Quem faz a chamada sobre a qualidade do produto, sobre o desempenho do produto, o proprietário do produto. Ótima. Então, agora que concluímos o Sprint e mostramos nosso trabalho às partes interessadas, ainda há um conjunto de dinheiro que resta. Ainda não terminamos. Ainda temos mais duas cerimônias a sobrar. Então vamos falar sobre o próximo na próxima palestra. Obrigado. 17. Retrospectiva: Olá a todos e bem-vindos à próxima discussão cerimônia eles sprint retrospectiva ou também conhecido como o retro e curto. Então, o que é essa retrospectiva e por que estamos fazendo isso? Já pegamos uma impressão de jornal. Comprometemo-nos com todo o trabalho que tínhamos feito. Rebaixamos para o titular da participação do produto. Então, qual é a necessidade de fazer isso? Mais uma cerimônia agora, vamos ver. Então a resposta é que é migalha contém atividades repetitivas. Sabemos isso, certo? Fazemos a preparação, fazemos o planejamento, completamos o sprint, e começamos com outro sprint, certo? Mas entre tudo isso, precisamos descobrir que o que tudo correu bem e se houver alguma margem para melhoria, é muito importante fazer essa análise porque é assim que vamos melhorar as outras coisas. Será apenas a mesma reputação das coisas com os mesmos problemas acontecendo de novo e de novo. Então é por isso que a retrospectiva é muito, muito importante. Infelizmente, muitas equipes não fazem isso. Eles não se importam com isso. Mas é muito importante tirar esse tempo para fazer retro depois de cada sprint. Então, quando é feito, é obviamente feito após o sprint ter terminado. Novamente, não queremos esperar muito tempo depois que o sprint terminar porque queremos feedback sobre o último sprint e, à medida que os dias passam, as pessoas vão esquecer isso. Então a idéia é fazê-lo assim que o sprint terminar, talvez no mesmo dia ou no dia seguinte após a demonstração, etc. Para que o sprint seja fresco na memória das pessoas e eles possam dar feedback correto. Em seguida, quem tenta? Então o proprietário do produto, o mestre do scrum, a equipe de desenvolvimento, toda a equipe deve comparecer. Nós não queremos nenhuma pessoa externa. Nós não queremos os gerentes, nós não queremos os detentores da participação. Não, esta é a análise da equipa. Então a equipe deve fazer tudo. A equipe deve estar presente e eles devem honestamente fazê-lo dentro de si mesmos. Em seguida, qual é a duração? Então essa duração é de 30 a 60 minutos. Novamente, não há regra fixa. A ideia é discutir as coisas e garantir que todos tenham tempo suficiente para falar. Finalmente, o propósito de primeiro e mais importante, reunir feedback para tornar o processo e cultura melhor. Lembre-se, nós temos que fazer as mesmas coisas, iterar nas mesmas coisas uma e outra vez no Scrum. Então eles correm, vão continuar. Vamos fazer é imprimir de um a cem, duzentos , mas devemos aprender algo de cada sprint. Devemos saber como melhorar as coisas com cada Sprint. E papai é o objetivo de fazer retrospectiva para descobrir os problemas com o sprint, para descobrir quais eram as coisas boas e como podemos melhorar ainda mais. E é por isso que falamos sobre duas coisas. Primeiro, o que correu bem? E número dois, o que poderia ter sido melhor? Então, qualquer coisa do apenas concluído é imprimir entrar as coisas da equipe não era bom como passo e deve ser feito novamente. Ou se algo não foi bom e algo que podemos melhorar, não devemos fazer. Trazemos todas essas coisas? Todo mundo fala sobre isso. Esse é o propósito da revisão retrospectiva e honesta da dívida do sprint. Próximo ponto, lembre-se que a idéia é não destacar falhas ou torná-lo um exercício de jogo de culpa. Como eu disse no último capítulo em Scrum, as vitórias e o fracasso são responsabilidade de toda a equipe. Portanto, a retrospectiva deve ser feita honestamente. Deve ser usado para melhorar as coisas. E mais importante, não deve ser ensinado de um exercício de jogo de culpa. Nós estamos, estamos apenas apontando as coisas ruins de todos. É para a melhoria da impressão, é para o melhoramento de todos. Então vamos manter isso honesto. Não vamos culpar todo mundo. Por fim, a prática da retrospectiva regular é reforça o aspecto da melhoria contínua. Então temos que aprender com o passado, temos que melhorar as coisas. E esse é o propósito da retrospectiva. Tudo bem, então isso foi tudo sobre caras retrospectivos ou retrô, se agora temos apenas mais uma cerimônia sobrando. Então vamos falar sobre isso na próxima palestra. Obrigado. 18. Planejamento de lançamento: Olá a todos e bem-vindos de volta. Vamos falar sobre o último tópico de cerimônias Scrum conhecido como planejamento de lançamento. Então pessoal, planejamento de lançamento é uma cerimônia importante em um scrum, embora você vai ver a maioria dos cursos não falar sobre este. Eu incluí aqui porque é importante entender esses detalhes. Precisamos saber quando entregar o incremento do produto ao usuário final para que ele possa usá-lo. E todo o nosso trabalho duro vem a ser usado. Então, o planejamento de lançamento dos caras é tudo sobre decidir quais incrementos de planta queremos empurrar para o usuário final. E quando é que vamos fazer isso? Lembre-se que o propósito de cada sprint é projetar novos instrumentos e temos que descobrir quando liberar esses incrementos para o usuário final. Algumas organizações vão liberá-lo em produção após cada sprint. Algumas organizações farão isso depois das duas. Sprint não é uma regra fixa para ele. Ele é chamado como cadência de liberação, e depende totalmente da exigência de negócios ou do roteiro do produto, ou o custo ou o valor que está sendo adicionado ao produto. Estes são os múltiplos fatores nos quais nossos lançamentos seriam baseados. E vamos falar sobre todos esses aspectos durante esta cerimônia de planejamento de lançamento. Então, em primeiro lugar, quando isso é feito, idealmente devemos fazer o planejamento do lançamento em intervalos freqüentes. Então devemos fazer como depois de cada corrida. Porque lembre-se com base em quando e no que temos que liberar, talvez tenhamos que modificar nossa lista de pendências. Talvez tenhamos que repriorizar os requisitos, realinhar recursos, etc. Portanto, é melhor fazê-lo em intervalos freqüentes. Próximo ponto, quem vai à reunião de planejamento de lançamento? Portanto, devem ser as partes interessadas, o proprietário do produto, e toda a equipe scrum. Porque lembre-se que todos da equipe de desenvolvimento podem ter algum papel no lançamento. Os desenvolvedores irão implantar o código, os testadores iria verificar o código para que todos tenham algum trabalho. Por isso, é bom incluir toda a equipe scrum ou um pequeno subconjunto dele. Em seguida, qual é a duração? Novamente, nenhuma regra dura e rápida. 30 minutos a 60 minutos é uma duração suficiente. E, por último, quais são os propósitos desta cerimônia? Então, primeiro, como discutimos, o planejamento da versão ajuda a descobrir quais todos os recursos podemos oferecer ao cliente. E lembre-se, as coisas podem ser guiadas por uma lista de recursos como queremos fazer uma versão assim que todos esses recursos estiverem prontos. Ou pode ser impulsionado por uma data como queremos fazer um lançamento no próximo mês, segunda sexta-feira, assim por diante, qualquer que seja o critério discutimos sobre essas coisas na cerimônia de planejamento de lançamento. Em seguida, analisamos o roteiro do produto e tomamos a decisão. Por isso, é guiado pela exigência do produto, as entradas das partes interessadas, todos esses fatores juntos para decidir quando queremos liberar o produto. Em terceiro lugar, também discutimos o equilíbrio entre as necessidades do cliente e o escopo. Assim, o cliente pode querer algo novo a cada semana, mas há preocupações genuínas de coisas que não estão prontas nesse curto período de tempo ou, para esse assunto, poderia haver preocupações sobre o orçamento também. Então conversamos sobre todas essas coisas. Tentamos encontrar um equilíbrio entre o nosso custo e liberar frequentemente para o usuário. Próximo ponto que a frequência de lançamento vai variar ou cada organização, como eu disse, algumas equipes vão lançar cada sprint. Às vezes, algumas equipes podem liberar depois de um sprint. Não há regra dura e rápida. Depende da organização, depende de suas necessidades de negócios. Último ponto, o plano de liberação não é um plano estático e pode ser alterado com base na nova adição ao backlog. É por isso que é importante rever as coisas. Regularmente, discutir as coisas com as partes interessadas e fazer isso, esta cerimônia de planejamento de lançamento com freqüência. Certo pessoal, então com isso, chegamos ao fim de todas as cerimônias Scrum. Vamos recapitular as coisas rapidamente na sequência em que elas acontecem. Então, fazemos a preparação do backlog antes do sprint começar. Então, para começar o sprint, fazemos o planejamento de sprint para chutar o sprint. cada dia do sprint, impressão mais selvagem está em execução. Faremos isso diariamente em pé. Finalmente, quando o sprint terminar, faremos a demo e faremos a retrospectiva. Nós também devemos incluir o planejamento de lançamento em algum lugar aqui, como depois do sprint termina e em um intervalo freqüente. Então, pessoal, lembrem-se que todas essas cerimônias são fundamentais para o scrum. Eles são encaixotados no tempo e cada um deles serve um propósito importante, como vimos. Vimos a importância deles, vimos a frequência deles. E você pode recapitular este gráfico muito rapidamente para recapitular quando você precisar de quando a cerimônia acontece e qual é o propósito deles. Certo pessoal, então vimos as várias cerimônias de migalhas. Vamos passar para o próximo capítulo e discutir o próximo componente de Scrum, que é os Artefatos Scrum. Obrigado. 19. Epics e introdução aos artefatos: Olá a todos e bem-vindos ao quinto capítulo do curso. Até agora em nossa jornada, vimos o que é h i e o que é um Scrum. Nós vimos as diferentes pessoas em uma equipe Scrum conhecido como os papéis Scrum. E nós também vimos as diferentes reuniões ou é cerimônias migalhas que eles fazem para desenvolver um produto ou incremento. Em suma, temos que saber quem e como parte da história. Agora, neste capítulo, vamos aprender sobre algo chamado Artefatos Scrum e como ele ajuda a equipe em sua jornada de Scrum. Então vamos começar. Então estes são os tópicos que estaríamos abordando neste capítulo. Mas antes disso, um aviso muito importante para evitar qualquer confusão. Lembre-se que os artefatos Scrum são realmente apenas o backlog do produto, o backlog sprint e incrementos. Então, o número 456 na nossa lista. No entanto, para compreendê-los, também precisamos ser aparecem fora de épicos e usuário é história, e é por isso que estamos nos movendo em uma ordem lógica. Neste capítulo, vamos primeiro falar sobre Epics, em seguida, vamos falar sobre histórias de usuários. E como as histórias de usuários são a fonte de requisitos para toda a nossa equipe, veremos as melhores práticas para escrever boas histórias de usuários. Isso nos ajudará a saber como escrevê-los corretamente em nossa organização ou manter um cheque se alguém estiver escrevendo, então vamos passar para falar sobre nossos artefatos. O Product Backlog é sprint backlog e incremento para que as coisas estão claras para nós. E, finalmente, vamos aprender sobre algo chamado a definição de feito, que é um conceito muito interessante e documentação do acordo da equipe Scrum. Então é por isso que eu incluí este capítulo. Então vamos começar nossa jornada e vamos começar com o primeiro tópico. Então vamos primeiro falar sobre o que é o significado de Artefatos Scrum. Então, se falamos em termos gerais, a palavra artefato significa os documentos que criamos. E o objetivo desses documentos é nos fornecer informações-chave e garantir que todos na equipe tenham o mesmo entendimento das coisas. Agora, quando dizemos nos fornecer informações-chave, qual é a informação que esses artefatos podem fornecer? Então, para entender isso, vamos esquecer é migalha por um momento, e vamos pensar em trabalhar na criação ou modificação de um produto em geral. Então, quais são as diferentes informações de que precisaríamos se fizéssemos isso? Em primeiro lugar, precisaríamos saber qual é o requisito. Porque esses são os requisitos em que estaríamos trabalhando. Em seguida, precisamos saber como parte, como estaríamos nos aproximando dessa exigência, qual é a parte que estaríamos fazendo, etc. E, finalmente, precisamos saber o progresso, quanto é feito, quanto resta, et cetera. E pessoal, este é o mesmo conceito que se aplica a um scrum. Além disso, os artefatos nos ajudam a fornecer informações importantes, como o número um, o produto em desenvolvimento. Portanto, estes não são nada além do requisito que queremos e eles são armazenados nas formas de histórias épicas e de usuários. Quem as escreve? O proprietário do produto os escreve em consulta com as partes interessadas e com a ajuda de um Scrum Master. E onde o proprietário do produto guarda essas histórias de usuários? Ele ou ela os mantém no Product Backlog. Segundo, as próximas atividades. Então, já vimos que durante o planejamento de sprint, pegamos as histórias de usuários do backlog do produto. E com base na capacidade da equipe, finalizamos um backlog de sprint. Essa é a lista de histórias de usuários que a equipe estaria trabalhando no próximo sprint. E último ponto o trabalho concluído até agora. Portanto, isso se reflete no nosso produto backlog ou conclusão sprint backlog também. E lembre-se que há vários relatórios também mostram essa informação. E é por isso que você verá vários autores reportando diretamente como gráfico de burndown, etcetera também para ser um artefato. Mas aqui neste curso vamos ficar com a lista de artefatos originais e vamos tratar apenas o Product Backlog é sprint backlog e incrementos neste capítulo. Para outros métodos de relatório, como Burndown ou gráfico de velocidade, temos um capítulo dedicado mais tarde cobrindo inteiramente o diferente é relatórios de migalhas. E finalmente, último ponto, qual é a vantagem de ter artefatos? Assim, ele fornece informações-chave para todos e coloca todos na mesma página em termos de compreensão. Por exemplo, digamos que se não tivéssemos qualquer backlog do produto, como eles serão os detentores da participação são membros da equipe, saber o que tudo o que temos a fazer e quanto trabalho está restante. Todo mundo terá uma compreensão diferente do trabalho esperado e isso causará confusão na equipe. Então os artefatos ajudam a resolver esses tipos de problemas. Tudo bem, então como eu mencionei anteriormente, os artefatos chave no Scrum, nosso backlog produto, um sprint backlog e incrementos, e vamos passar por eles neste capítulo. Mas para entender claramente as coisas que precisamos primeiro saber sobre épicos e histórias de usuários. Então vamos começar com os primeiros épicos. Então os caras comprados são esses épicos? Se falamos em termos gerais, épicos são basicamente grande exigência. Assim, neste capítulo, muito do que estamos falando é apenas em referência à exigência. E a maior peça documentada desses requisitos é o épico. Como diz a definição na tela, um Epic é um grande requisito que pode ser dividido em pequeno pedaço de trabalho chamado histórias de usuários. Então essa é a definição de épico. Digamos, vamos considerar um exemplo. Digamos que queremos fazer um site de comércio eletrônico e queremos criar seu fluxo de checkout ou colocação de pedidos. Então esse é um requisito muito grande com muitas peças de trabalho, teremos que cuidar do Checkout por cartão de crédito, pelo PayPal, Apple Pay e muito, muito mais. Então o redesenho do checkout seria um épico. E para fazer os requisitos subsequentes de checkout de cartão de crédito, PayPal checkout, Apple Pay checkout, etc. Vamos criar histórias de usuários, que é o exemplo de épicos e histórias de usuários, e que é a relação entre eles. Veremos isso mais claramente quando fizermos o projeto prático mais tarde, não se preocupe. Mas por enquanto, basta ter em mente que grande exigência é épico e criamos um pequeno requisitos ou histórias de usuários a partir dele, tão simples quanto isso. Então, vamos ler para o primeiro, épicos podem ser considerados como o nível superior do trabalho de desenvolvimento de produtos. Portanto, o desenvolvimento de produtos significa requisitos. E esses requisitos vêm da Epic, que são divididos em histórias de usuários. Assim, os épicos são o nível superior ou superior dos requisitos no desenvolvimento de produtos. Em segundo lugar, os épicos podem estender várias equipes, vários projetos e um quadro Scrum. Então isso soa lógico no nosso exemplo, épico de redesenho do Checkout. Um é a equipe Scrum vai lidar check-out no site. Outra equipe lidará com o processamento de pedidos de back-end. 13 vai lidar lidar com o envio de e-mails quando o pedido é colocado, etc Assim épicos são grandes o suficiente, eles podem incluir várias equipes e há placas Scrum. Próximo ponto, épicos são muitas vezes entregues em vários sprints. Então, obviamente, porque os épicos são tão grandes que não podemos fazê-los em um único sprint. É múltiplo sprint fora do trabalho. Ele é dividido em várias histórias de usuários e para várias equipes Scrum. E último ponto, os épicos evoluíram ao longo dos sprints, obtendo mais informações. Então, à medida que trabalhamos em tópicos, já que estaremos trabalhando em nosso épico de redesenho de checkout, vamos aprender mais coisas. Teremos novos requisitos que não pensámos anteriormente. E assim teremos que criar novas histórias de usuários para lidar com esses requisitos. Então, à medida que progredimos, à medida que avançamos em nosso sprint, teremos novas histórias de usuários vinculadas a esses épicos. Tudo bem, pessoal, então era tudo sobre épicos, mas você não precisa se lembrar de todas essas coisas. Lembre-se apenas de dois aspectos principais. Número um e épico é uma grande peça de trabalho. E número dois, ele é dividido em menor usuário é histórias que geralmente envolviam várias equipes e um sprint. Papai disse que isso é tudo épico. Ótima. Então, agora que sabemos o que é um épico, vamos falar sobre seu manuseio na forma de pequenas peças chamadas histórias de usuários. Vamos falar sobre essas histórias de usuários na próxima palestra. Obrigado. 20. Stories do usuário: Olá a todos, e bem-vindos ao tópico de histórias de usuários. Agora esta vai ser uma palestra muito importante porque sempre que você está trabalhando no Scrum, você vai lidar a maior parte do tempo com histórias de usuários. Essas histórias de usuários serão a fonte de todos os requisitos e você irá referi-lo se você está citando algo ou testando algo ou discutindo com as partes interessadas. Então é por isso que vamos falar com grande detalhe sobre histórias de usuários nesta palestra e na próxima. Então, vamos começar. Ok, primeiro de todas as histórias de usuários de água. Nós já vimos na última palestra que os grandes pedaços de requisitos são chamados como épicos. E a partir desses épicos criamos um pequeno pequeno requisito chamado histórias de usuários. Pegamos essas histórias de usuários em um sprint e trabalhamos nisso. Então histórias de usuários são basicamente a menor unidade de exigência em Scrum que pode ser entregue em um sprint. Então, quando a equipe se reúne para o planejamento sprint, eles vão levar como cinco ou sete ou dez usuário é baseado em história em sua capacidade e eles vão embarcar para completar todas essas histórias de usuários dentro de um é sprint. Então é isso que um usuário é. história é a menor unidade de trabalho que a equipe pode entregar em um sprint. Vamos ver os marcadores primeiro, histórias de usuários são explicação geral dos requisitos expressos nos termos do usuário final. Então, o que está nos requisitos de histórias do usuário e como escrevemos esses requisitos? Muito importante. Nós sempre escrevemos DEM na perspectiva de um usuário final. Se falamos sobre o checkout com cartão de crédito em nossa história de usuário do site de e-commerce, vamos escrevê-lo como um usuário, eu quero fazer um pedido com um cartão de crédito e, em seguida, vamos dar os detalhes adicionais. Nós nunca vamos escrevê-lo como uma pessoa técnica ou uma pessoa de negócios sabe, nossa história de usuário é sempre escrita a partir da perspectiva de um usuário final. Próximo ponto, como escrevemos aspectos de requisitos detalhados na história do usuário? Escreveríamos como algo chamado critério de aceitação. Assim, os critérios de aceitação é um conjunto de requisitos predefinidos que explicarão o que é necessário ser feito. Assim, por exemplo, para o nosso cartão de crédito é história que vamos começar com, como um usuário, Eu quero fazer um pedido com um cartão de crédito. E então vamos mencionar os critérios de aceitação é como o número um, usuário tem a opção de inserir um cartão de crédito. Número para o usuário tem a opção de inserir um cartão de débito. Número três, o usuário tem a opção de ver sua lista de segurança e assim. Então essa é a estrutura de uma história de usuário. E não se preocupe, veremos um exemplo também mais tarde na palestra. Mas apenas para recapitular rapidamente, a estrutura é como um usuário, eu quero assim e assim, e então nós temos que os critérios de aceitação detalhe tem terceiro, que escrever o usuário é história, então nós já vimos isso. É o proprietário do produto. O Proprietário do Produto é responsável por escrever histórias de usuários. Ele ou ela pode ter a ajuda da equipe se for necessário. Ele ou ela pode ter a ajuda do Scrum Master dois facilitado, mas a responsabilidade final de criar histórias de usuários , modificá-los, atualizá-los, para priorizá-los, etc. Tudo está com o proprietário do produto. Como vimos na última palestra, é uma das suas principais responsabilidades. E último ponto, histórias de usuários são um componente de estimativa. Então vamos falar sobre estimativa em muito detalhes no capítulo posterior. Mas, por enquanto, lembre-se que para a história de cada usuário, estimamos usando algo chamado pontos de história. Portanto, essas histórias de usuários também servem como um meio de estimativa. Então vamos seguir em frente e vamos dar uma olhada em como estamos realmente história de usuário parece. Então caras aqui é como uma história de usuário se parece. E isso é um problema. Provavelmente uma história de usuário criada para imprimir algo a partir do painel de problemas como G2 ou algo assim. Mas não se preocupe, apenas ignore o contexto. Vamos nos concentrar no formato. Então, como você pode ver, a história do usuário começa com a palavra como um usuário. Então, como eu disse, nós sempre escrevemos as histórias do usuário da perspectiva do usuário final. Nunca mencionaremos isso do ponto de vista empresarial. Nunca o mencionaremos do ponto de vista técnico. Ele sempre será retornado do ponto de vista de um usuário final. E é por isso que a história do usuário sempre começa com a linha como um usuário. E então você pode ver que temos os requisitos detalhados, que são os critérios de aceitação. E os critérios de aceitação foram escritos muito bem em balas. Assim, os dados, é claro, tudo foi explicado em grande detalhe. Então agora você sabe que quando a equipe se reunir para a preparação de backlog ou o planejamento de sprint, eles vão passar por essa história. Eles lerão os critérios de aceitação se tiverem alguma dúvida que possam perguntar ao proprietário do produto, ele ou ela responderá e assim por diante. Mas temos de dar cada detalhe ao mais ínfimo nível possível neste critério de aceitação. Lembre-se, podemos adicionar quaisquer detalhes técnicos também como se houver alguma dívida de informação técnica ajudará a equipe de desenvolvimento. Podemos adicioná-lo na parte inferior após cada detalhe do usuário de negócios. E se nós, se necessário, podemos anexar uma bela maquete também. Assim, a maquete ajuda na clareza visual, especialmente se estamos fazendo uma mudança de design ou se estamos fazendo uma alteração intensiva da interface do usuário, então é sempre útil anexar uma maquete para a história do usuário. Então é assim que um usuário é. A história parece com o Guys. E agora que sabemos o que é um usuário, história é watts, seus formatos, o que é importante. Vamos seguir em frente e vamos aprender sobre as melhores práticas para criar uma história de usuário na próxima palestra. Obrigado. 21. Como escrever ótimas histórias de usuário: Olá, pessoal. Vamos falar sobre as melhores práticas para escrever uma ótima história de usuário. Como discuti anteriormente, escrever uma história de usuário é principalmente o trabalho do proprietário do produto. Portanto, se você vai trabalhar como proprietário de um produto, precisa saber disso, ou se estiver trabalhando como analista de negócios, desenvolvedor ou testador, ainda precisará saber disso para garantir que as histórias de usuário sejam escritas corretamente em sua organização Então, vamos ver. O primeiro ponto manter o usuário final em mente e escrever do ponto de vista dele. Muito importante é que o Crum tem tudo a ver com fornecer produtos de boa qualidade ao usuário final Vamos pensar como um usuário final quando estivermos criando os requisitos. Não queremos pensar como proprietários de produtos, desenvolvedores, testes ou não. O que o usuário final quer? Vamos anotar dessa forma. Em seguida, mantenha-o curto e simples. Não escreva muitos detalhes para criar confusão. Se estiver ficando muito longa ou muito longa, provavelmente significa que a história está ficando muito complicada e devemos dividi-la em duas histórias separadas Seja breve, mantenha as coisas simples. Em seguida, adicione critérios de aceitação claros. O critério de aceitação, como vimos , é o que compõe a história do usuário. Precisamos ter critérios de aceitação claros, e é por isso que, no próximo slide, veremos como redigir ótimos critérios de aceitação. Quarto ponto, crie em colaboração. Discuta com as partes interessadas, discuta com a equipe de desenvolvimento, especialmente se for uma história técnica, receba suas contribuições e crie sua história Lembre-se de que criar as histórias é tarefa do proprietário do produto, mas ele deve sempre fazer isso em colaboração com a equipe. Uma pessoa pode perder coisas. Uma pessoa não pode conhecer todos os requisitos. A colaboração é uma ótima alternativa. Próximo ponto, faça um brainstorming, refine ou divida. Quando estivermos preparando a lista de pendências ou planejando um sprint, discuta a história, fale sobre ela, faça qualquer pergunta que Faça com que o proprietário do produto responda às suas perguntas, fale sobre as incógnitas, fale sobre o risco Se necessário, modifique a história ou, se ela estiver ficando muito grande, divida a história em duas ou mais histórias adicionais. E por último ponto, adicione visualizações para maior clareza. Pessoalmente, sugiro que uma maquete ajuda a esclarecer as coisas com mais facilidade e é melhor do que 100 palavras Portanto, sempre tente incluir uma maquete nas histórias de usuário, especialmente se for uma alteração na interface do usuário ou no design Existem muitas ferramentas no mercado, como a visão que ajudam a criar excelentes modelos e compartilhá-las com a equipe Então, vamos utilizá-los. Tudo bem Agora que sabemos como uma boa história de usuário deve ser escrita. Vamos falar sobre como escrever bons critérios de aceitação nele. Práticas recomendadas para redigir bons critérios de aceitação. E a primeira, na verdade, é garantir que os critérios de aceitação estejam presentes, sem a intenção de sarcasmo Mas, pessoal, você verá muitas vezes que as equipes simplesmente criarão a história do usuário com apenas uma descrição, e não haverá critérios de aceitação. Isso não está correto. Uma história deve sempre conter critérios de aceitação, pois esse é o requisito detalhado. Se eu simplesmente criar uma história vazia, por exemplo, dizendo fazer um pedido com cartão de crédito , não há um entendimento comum sobre como isso deve funcionar. Todo mundo terá sua própria interpretação das coisas e, obviamente, isso criará confusões e problemas Sempre escreva critérios de aceitação nas histórias, certifique-se de que não criemos histórias de usuários sem colocar os critérios de aceitação nelas. Segundo, documente antes do desenvolvimento. Escreva primeiro as histórias de usuários e os critérios de aceitação e depois desenvolva as coisas como parte desses detalhes, não desenvolva primeiro as coisas e depois escreva como estão funcionando, conforme os critérios de aceitação sabem. Isso pode significar que estamos tomando o caminho errado como rota de avanço. Próximo ponto, torne-o alcançável, mensurável e testável. Ao escrever algo nos critérios de aceitação, certifique-se de que seja factível, certifique-se de que seja testável Não escreva coisas que seriam impraticáveis de fazer. Quarto ponto, discuta com a equipe, tenha consenso. Portanto, obtenha contribuições das partes interessadas, certifique-se de que todos concordem com a mesma coisa, obtenha contribuições da equipe, discuta com elas, anote, faça perguntas e responda Lembre-se de que a equipe de desenvolvimento é quem realmente faria essas histórias e os critérios de aceitação. Portanto, a colaboração e o consenso com eles são a chave. Próximo ponto, concentre-se no resultado final, não na parte como. Novamente, muito importante, devemos escrever critérios de aceitação como usuário final, e o aspecto técnico não deve ofuscar essa parte Se houver algum detalhe técnico necessário, podemos escrevê-lo separadamente como nota técnica ou nota para a equipe de desenvolvimento. Mas a maioria dos critérios de aceitação deve ser sobre o que é necessário, não sobre como devemos fazer isso. E, finalmente, lembre-se de incluir também os aspectos não funcionais, para que a usabilidade e o desempenho sejam aspectos igualmente importantes Quando falamos em finalizar a compra em nosso site de comércio eletrônico, se houver um fluxo de dez páginas para fazer um pedido ou se levar 5 minutos para adicionar um cartão de crédito , ninguém fará isso. Não fale apenas sobre os aspectos funcionais. Pense também nos aspectos não funcionais e na melhor forma de implementá-los. Tudo bem, pessoal. Tudo se resumia a histórias de usuários e critérios de aceitação. Lembre-se das histórias de usuários mais detalhadas e bem documentadas que teremos com critérios de aceitação claros. A melhor equipe estaria alinhada a um entendimento comum e haveria menos falhas Se você está escrevendo histórias de usuários em seu trabalho ou as está usando em seu trabalho. Sempre certifique-se de que eles sejam escritos forma clara e agradável, de acordo com os pontos que discutimos Ótimo. Agora que falamos sobre épicos e falamos sobre histórias de usuários Agora, vamos voltar e examinar o tópico atual deste capítulo, os artefatos Vamos começar com o primeiro na próxima palestra. Obrigada 22. Artifact 1 - Backlog de produtos: Olá a todos e bem-vindos ao primeiro artefato, o backlog do produto. Então, caras do capítulo anterior, temos uma idéia do que é o Product Backlog. Simplesmente, é uma lista de entregáveis de petróleo que tem que ser feito em um produto. Então, se queremos fazer alguns novos recursos ou modificar alguns existentes, ou queremos corrigir alguns bugs. Estas são as coisas que compõem a lista de pendências do produto. Próximo ponto, o Product Backlog é sempre tentado para ser mantido em uma ordem de prioridade. Assim, o proprietário do produto deve revisitar o backlog frequentemente porque ele é responsável pelo backlog do produto e ele ou ela deve mantê-lo de uma forma priorizada. Caso contrário, não saberíamos o que é urgente. Nós não saberíamos o que precisa ser feito primeiro e ele pode se perder na lista à medida que o atraso do produto se expande. Então vamos passar pela bala. A primeira coisa na tela como você vê é a definição do backlog do produto, que como discutimos, é o número um, uma lista de todos os resultados que têm que ser feitos. E número dois, deve estar na ordem de prioridade. Estas são as duas principais conclusões desta palestra. Como diz o primeiro marcador, pendências do produto inclui novos recursos, alterações, correções de bugs na França, mudanças, etc. Então, estas são algumas das coisas que teremos na lista de pendências do produto como discutimos. E, de fato, com base em nosso aprendizado passado, podemos refinar essa lista ainda mais e simplesmente disse que na lista de pendências do produto idealmente contido número um, histórias de usuários e número dois dólares. Em segundo lugar, o proprietário do produto organiza esses requisitos ou histórias do usuário de acordo com a prioridade. Então, muito importante, como discutimos, é necessário manter o atraso do produto em ordem de prioridade. E quem é a pessoa que se encarrega de adicionar coisas novas ao backlog do produto ou manter sua ordem de prioridade, o proprietário do produto. Então vimos em uma das palestras anteriores que criar o backlog e manter o backlog é uma das principais responsabilidades de trabalho do proprietário do produto. Próximo ponto, o Product Backlog pode continuar crescendo e atua como o lugar detentor para todas as mudanças futuras. Assim, em qualquer metodologia de desenvolvimento de produto, haveria sempre uma nova adição aos requisitos. E assim a lista de pendências do produto continuaria mudando para sempre com coisas novas adicionadas, removidas ou priorizadas novamente. E último ponto, cada sprint a equipe leva histórias do usuário do backlog do produto para ser feito no ciclo atual. Portanto, qualquer alteração que tem de ser feita no produto, ele é adicionado primeiro ao backlog do produto pelo proprietário do produto. É discutido com toda a equipe. É parasitado com toda a equipe, a estimativa sobre ele, e, em seguida, ele é tomado em uma dessas impressões para trabalhar em. Então pessoal, é isso, isso é tudo sobre o atraso do produto. Mais uma vez, em resumo, você pode pensar no backlog do produto como uma lista de desejos priorizada, lista tarefas atada porque podemos mudar de faixa e não queremos fazer tudo lá dentro. Então nós chamamos isso como uma lista de desejos priorizada que é tratada pelo proprietário do produto. E serve como um grande balde de exigência a partir do qual puxamos os pequenos requisitos e desenvolvemos em um sprint. Então, pessoal, este foi o nosso primeiro artefacto. Vamos ver o próximo na próxima palestra. Obrigado. 23. Artifact 2 - Backlog: Olá a todos. Vamos falar sobre o próximo artefato que eu corro backlog. Então, pessoal, neste ponto temos uma lista de pendências do produto que contém as histórias do usuário para cada novo requisito que a equipe tem que fazer. Agora a equipe vai preparar essas histórias na preparação pendente. E então eles vão se reunir para uma sessão de planejamento de sprint onde eles vão levar os primeiros cinco ou dez primeiros histórias de usuários para trabalhar no próximo sprint com base em sua capacidade. E este grupo de cinco ou dez usuários histórias que levaram é o nosso próximo artefato conhecido como o backlog de sprint. Então, como você pode ver, a definição também diz que um sprint backlog é um subconjunto de Product Backlog identificado pela equipe a ser concluída durante o sprint. Então, já vimos o backlog do produto. É uma grande lista de requisitos que a equipe leva um pequeno conjunto de requisitos de lá e compõe o backlog sprint. E quanto seria dados sprint backlog? Seria muito trabalho que a equipe poderia completar durante o próximo sprint, tão simples quanto isso. Então vamos seguir em frente e ler as balas. Então, primeiro em um planejamento sprint que a equipe seleciona histórias de usuários de acordo com a prioridade definida pelo proprietário do produto e a capacidade da equipe. Então, já vimos sobre isso quando a equipe se reunia para um planejamento sprint, vamos rever o Product Backlog, que está em uma ordem de prioridade. Lembre-se, e a equipe iria pegar os primeiros cinco ou dez andares com base em sua capacidade. Eles vão fazer isso cinco ou dez histórias no sprint atual e dados é o que o sprint backlog é. Próximo ponto para a história de cada usuário no backlog sprint, essa equipe identifica a tarefa necessária para concluí-la. Então este é o outro aspecto do planejamento de sprint que discutimos no último capítulo. Basta pegar as histórias e criar um storyboard é sprint backlog não é suficiente. Precisamos descobrir quem vai trabalhar nisso. Este processo é chamado como tarefa. Basicamente, significa atribuir tarefas a cada membro da equipe individual. Até agora, uma é história. Vamos atribuir tarefas de desenvolvimento a um cara, testes de tarefas a um cara, maquete projetando UAT, etc. E os membros individuais da equipe assumirão essa tarefa e trabalharão nela. Então, isso ajuda a esclarecer quem trabalhará no que, quanto trabalho cada cara tem. Os donos estão ocupados? Será que eles têm sob trabalho todas essas coisas? Próximo ponto, um sprint backlog deve, idealmente permanecer inalterado durante a duração de um sprint. Assim, uma vez que nos comprometemos a fazer como histórias de tênis no sprint, idealmente não devemos fazer alterações nessa lista. E lembre-se que estou usando a palavra idealmente porque digamos que se alguém tem capacidade disponível porque terminou o trabalho, ou vamos ser mais realistas. E digamos que se algo urgente surgiu, então certamente teremos que trazer coisas novas para o backlog sprint, certo? Mas fora isso, devemos sempre nos ater a terminar o que nós comprometemos durante o planejamento. Observe também que no caso de estarmos puxando algo novo, essa equipe precisa descobrir como acomodá-lo. Eles não podem fazer todo o trabalho já comprometido mais este novo trabalho, certo? Então eles podem precisar de re-priorizar coisa, eles podem precisar remover algo, eles podem precisar de receber ajuda de outra equipe, etc Então, idealmente, não devemos fazer alterações no backlog sprint uma vez que eles sprint tem começou, mas provavelmente acontece. E quando acontece, quando temos que tomar algo novo, temos que pensar em todos esses fatores. Podemos fazer o novo trabalho retomado também. E último ponto, pessoal, se qualquer item não for concluído, ele pode ser adicionado de volta ao Product Backlog e re-priorizado no início do próximo sprint. Então, até agora, falamos sobre o caminho feliz, principalmente onde levamos como dez histórias de usuários em um sprint. Nós completamos todos eles e então começamos com o próximo sprint. Mas agora é assim que acontece sempre, às vezes as coisas não se fecham e vão passar para o próximo sprint. Então, no final do sprint, verificamos o atraso do sprint. Vemos o que tudo não está feito e ser revirado. E podemos continuar trabalhando nele no próximo sprint ou podemos movê-lo para o Product Backlog e re-priorizá-lo abaixo de outras coisas. Então este é um exercício que fazemos no final de cada sprint. E antes que eles comecem no próximo sprint, temos que descobrir o que fazer se alguma das coisas no sprint backlog não se fechou. Então, pessoal, isto foi tudo sobre o nosso segundo artefacto. Eles correm backlog. Lembre-se que vamos mais uma vez ir para os aspectos completos do Planejamento Sprint incluindo estimativa e como fazemos tudo isso, tomando as histórias, pensar kappa coisa sentada, et cetera no capítulo quatro mais tarde agora temos Acabei de ver um alto nível de atraso do produto, nosso segundo artefato. Então vamos seguir em frente. Vamos verificar o próximo e último artefato na próxima palestra. Obrigado. 24. Artifact 3 - Incrementos: Olá a todos. Vamos falar sobre o último artefato, o incremento. Então, pessoal, nós usamos esta palavra muito no curso. Então vamos ver isso em detalhes completos. O que é um incremento e o que isso significa? Então, em termos simples, e incremento é uma adição ao produto. Em nossa discussão até agora, vimos que em Scrum essa equipe cria um produto e, em seguida, cada sprint eles adicionar novos recursos ou incrementos a ele. Cada um desses incrementos adiciona à versão anterior do produto, criando um produto melhor, melhorado e de qualidade. Então essa é a definição de incremento. o aprimoramento do produto da corrente é sprint mais todos os sprints anteriores. Vamos ver os outros detalhes. Primeiro, no final de um sprint, o Incremento do Produto deve estar em uma condição utilizável e deve atender à definição da equipe de feito. Então lembre-se de qualquer incremento que estamos fazendo no sprint, só podemos considerá-lo valioso se estiver em uma condição utilizável e se ele satisfizer os critérios de aprovação das equipes conhecidos como definição de feito. Vamos ver esta definição de feito em uma palestra posterior. Mas por enquanto, basta considerar que é uma lista de verificação de todos os critérios que o produto ponto deve atender, a fim de ser considerado como concluído. Em segundo lugar, o incremento deve estar em uma condição utilizável independentemente de os lados do POD também o liberarem ou não. Então isso parece muito semelhante ao primeiro, mas há uma dívida em dinheiro adicional está liberando o produto. Lembre-se de que um dos critérios do Scrum é que cada sprint deve resultar no que chamamos de um produto potencialmente expedivel. Então isso significa que o que fazemos em um sprint, deve ser bom o suficiente para ser liberado para o usuário final. Agora é outra questão se o proprietário do produto quer liberá-lo ou não. Ele pode querer liberá-lo depois de dois “sprints”. Ele pode querer liberá-lo depois de um mês inteiramente sua chamada. Mas, no entanto, cada incremento deve estar em uma condição utilizável e deve resultar em um produto potencialmente expedivel. Próximo ponto com cada Sprint, o Incremento do Produto aumenta em direção à visão final ou meta. Então, bem claro, temos um roteiro de produtos, nossa visão de como queremos que o produto final seja. E com cada sprint, com cada incremento, estamos adicionando pouco a pouco a esse roteiro, esse objetivo final. E último ponto, pessoal, o aspecto central do Scrum é entregar um incremento feito. Então, se alguém nos perguntou, o que fazemos em um sprint, a resposta é que em cada sprint criamos um incremento para o produto. Criamos um incremento agradável, melhorado e de alta qualidade do produto. E esse incremento atende ao roteiro produtivo. Esse incremento atende à definição da equipe de feito. Certo, pessoal, então papai nos leva ao fim de todos os três artefatos, o atraso do produto, o sprint backlog e o incremento. Vamos recapitular todos os três artefatos mais uma vez através desta imagem. Portanto, temos vários requisitos que podem surgir das partes interessadas na forma de novos recursos ou correções de defeitos ou adições técnicas, etc. O proprietário do produto assume esses requisitos e cria um backlog do produto, que é como uma grande lista de desejos de requisitos das coisas a fazer. Pegamos um pequeno subconjunto de requisitos deste backlog e criamos o sprint backlog, que é o trabalho que a equipe vai assumir no próximo sprint. E, finalmente, uma vez que o trabalho de sprint é concluído, temos um incremento para o produto, que é como novos aprimoramentos de edição através do nosso produto e ele deve ser potencialmente enviável. Então esse cara na sua tela é um resumo de todos os três artefatos que você pode rapidamente recapitular para sua memória. Certo, então vimos todos os três artefatos, mas há um termo que ouvimos muito no último slide e que é a definição de feito. Então vamos ver também quais dados estão na próxima palestra. Obrigado. 25. Definição de conclusão: Olá a todos e bem-vindos ao último tópico deste capítulo. Vamos falar sobre algo chamado como a definição de feito. Então imagine que estamos trabalhando em um sprint e pegamos uma história de usuário para projetar o checkout com cartão de crédito como falamos anteriormente. Então, há como sete critérios de aceitação na história do usuário. E no final do sprint, desenvolvedor aparece e diz que eu fiz todas essas sete mudanças. Está tudo bem. Podemos considerar que a história acabou. Agora, devemos apenas seguir a sua compreensão da W1 e encerrar a história deles? - Não. Certo. Deveríamos, antes, dispor de uma lista de critérios de avaliação para fazer esse julgamento. Porque lembre-se, cada um é 2D no sprint deve adicionar ao incremento e resultar em um produto potencialmente enviado. Então, se não temos um conjunto de regras, dívida certifica que a história do usuário fez. Podemos estar adicionando coisas incompletas ou de baixa qualidade ao produto. E é aqui que a definição de feito entra em cena. Como uma equipe Scrum, devemos criar uma lista de verificação. Devemos criar uma lista de criterias que essa equipe pode cruzar referências. E com base nisso, eles podem dizer que o usuário é histórias feitas ou não. E a lista de verificação do pai é conhecida como a definição de feito. É uma lista de critérios que essa equipe deve completar com sucesso antes declarar a história do usuário a ser feita e antes de considerar o produto suficiente para liberar. E quais são as coisas que são comumente presentes na definição de feito, podemos ter critérios como design técnico deve ser revisado, código deve ser testado unidade. Os testes funcionais devem ser completos sem defeitos críticos ou bloqueadores. teste de aceitação do usuário deve ser feito, etc. Então estes são apenas alguns dos critérios. Só estou dando alguns exemplos. Na realidade, a equipe discutiu juntos e eles criam uma lista exaustiva, e eles seguiram essa lista, cada sprint para garantir que eles estão adicionando um incremento valioso ao produto. Então vamos ler a bala primeiro. Des, definição de feito ajuda a verificar o incremento do produto está concluído e pronto para entrega. Então, quando alguém diz ou histórias de usuários feitas, nós cruzamos tudo na definição de feito está terminado ou não. caso afirmativo, o incremento da planta deve ser considerado concluído e pronto para ser liberado para o usuário final. Caso contrário, vamos corrigir as coisas que estão falhando e, em seguida, verificar novamente. Segunda definição de feito ajuda a minimizar o risco, entender o progresso e trabalho salgado, esforço ou custos. Portanto, se não confirmarmos que nosso produto atende à definição de feito, pode estar incompleto , pode ter defeitos , pode, pode não atender aos requisitos do usuário, etc. E isso aumentará o custo de risco, esforço, todos esses fatores. Então definição de del w1 ajuda a minimizar todas essas coisas. Próximo ponto, definição de feito varia entre empresas e equipe, mas deve ser acordado por inteiramente Scrum Team. Portanto, não há nenhuma lista fixa de itens que devem ser incluídos na definição de feito. É algo que toda a equipe scrum se reúnem e discute, incluindo o proprietário do produto e o Scrum Master. Eles discutem todos os pontos que discutem modo deve estar lá e, em seguida, eles concordam com isso. Isso se tornará o guia de equipes e eles irão avaliar todas as mudanças futuras em relação a esta definição de feito. E por último, como você pode ver, alguns dos itens dívida pode estar na definição de feito, como eu discuti anteriormente. Mas lembre-se, esta é uma lista básica que deve estar lá na minha opinião. É, claro que a equipe é chamada, eles devem ter uma discussão e eles devem vir acima com sua própria lista. Você pode imprimi-lo, você pode colá-lo na área da ATM para que todos saibam quais são os critérios do pai que a equipe seguirá antes de certificar tudo como concluído. Certo, pessoal, então era tudo sobre a definição de W1. E com isso, chegamos ao fim deste capítulo. Estou muito feliz em dizer que agora cobrimos as três categorias principais de Scrum, os papéis, cerimônias e artefatos. Claro que continuaremos a nossa jornada de aprendizagem. Mas neste ponto nós aprendemos um monte de coisas relacionadas ao seu scrum. Agora, no próximo capítulo vamos tomar um novo tópico é sprint planejamento e estimativa muito importante e aprender sobre isso. Então, vemo-nos no próximo capítulo até lá. Obrigado. 26. Planejamento de sprint de detalhes completos e importância: Olá a todos e bem-vindos ao sexto capítulo do curso. Nós vamos dedicar este capítulo a dois conceitos importantes é planejamento sprint e estimativa. Nós já falamos sobre é planejamento sprint no capítulo sobre cerimônias Scrum. Mas aqui estamos indo para expandir ainda mais sobre ele, porque como eu disse anteriormente, também, um planejamento sprint é a cerimônia mais importante de Scrum e muitas decisões importantes e todo o trabalho da equipe para as próximas duas semanas, sprint vai depender ele. Da mesma forma, assim como qualquer outro quadro de gestão de projetos, o conceito de estimativa também é muito importante, mas complicado em Scrum. É por isso que eu coloquei esses dois tópicos de planejamento de sprint e estimativa em um capítulo separado para que possamos cobrir todos os aspectos em todos os detalhes aqui. Então, vamos começar. Aqui está a agenda deste capítulo. Vamos começar com por que o planejamento sprint é importante e, em seguida, passar para a estimativa. Vamos falar sobre é pontos de história, que é o método de estimativa primária em AGI e poker de planejamento, que é comumente usado para esta estimativa. E, finalmente, vamos falar sobre capacidade e velocidade, que são dois aspectos a considerar quando estamos fazendo é planejamento de sprint e estimativa. Então, vamos começar. Então, a primeira coisa que vamos falar é por que o planejamento de sprint é tão importante? Como vimos no capítulo anterior, é reunião de planejamento sprint onde toda a equipe scrum, incluindo o proprietário do produto e o Mestre Scrum, se reúnem antes de começar um sprint e eles assumem o usuário é histórias da equipe de dados de backlog do produto vai trabalhar no próximo sprint. Então, obviamente, o planejamento de sprint é a cerimônia em que decidimos o objetivo de todo o sprint. Planejamos o evitado que a equipe completa estaria fazendo nos próximos dias e também o incremento do Produto que seria desenvolvido com base nisso. Então dat explica partes dele, parte de sua importância, a importância do Planejamento Sprint é dat. Também ajuda a identificar fatores como esforço e capacidade para toda a equipe. E isso também é muito importante para calcular e gravar. Veremos no próximo slide como ele é feito e quais são os principais conceitos por trás dele. Mas, por enquanto, lembre-se que o plano de trabalho e estimativa são dois resultados muito importantes do Planejamento Sprint e dados de planejamento sprint sábio é uma coisa muito importante. Então ponto número dois, em um planejamento de sprint, finalizamos o backlog de sprint. Ou seja, o que a equipe do devedor verbo estaria fazendo no próximo sprint? Então toda a equipe tem duas semanas ou quatro semanas de trabalho, qualquer que seja a duração de nossos sprints seria decidido inteiramente com base nesta reunião de planejamento. Próximo ponto, os critérios exatos de aceitação de requisitos são discutidos e acordados. Então, como vimos anteriormente, os requisitos são capturados na forma de histórias de usuários e temos critérios de aceitação dentro deles. E só para que façamos o produto certo como expectativas, é importante que toda a equipe entenda esses critérios de aceitação. Assim, na reunião de planejamento, discutimos esses critérios de aceitação e se qualquer membro da equipe tem qualquer consulta ou preocupação ou risco, ele é destacado e resolvido lá. Agora lembre-se, isso também pode ser algo que seria feito na preparação de backlog. Mas, no entanto, é planejamento sprint é o fórum em que os requisitos são novamente discutidos e acordados antes que possamos finalmente levá-los para o sprint. Em quarto lugar, cada membro da equipe estima ou aponta as histórias dos usuários. Então é planejamento de sprint é onde a estimativa também acontece. É por isso que esta reunião é novamente muito importante. Próximo ponto tarefa são alocados para membros individuais da equipe. Então, depois de finalizarmos quais histórias de usuários estaríamos trabalhando. A próxima pergunta que surge é quem vai fazer o quê? Então, atribuímos trabalho aos membros da equipe, criamos tarefas para eles para que todos saibam o que devem fazer. E último ponto, o desempenho da equipe é discutido via Burndown, velocidade chart, etc. Então vamos falar sobre esses relatórios no capítulo posterior. Mas por enquanto, pense como podemos ter certeza de que essa equipe está estimando as coisas corretamente? Como sabemos que estamos progredindo corretamente no sprint? Então, para isso, temos gráficos como queimados e velocidade, etc. Nós os encaminhamos durante o planejamento de sprint para ver o desempenho da equipe. E isso nos ajudará a não nos comprometer excessivamente com as coisas e garantiu que assumimos apenas essa dívida de trabalho que podemos entregar completamente. Então, pessoal, eu espero que vocês agora estejam claros sobre por que o planejamento de sprint é uma reunião importante. E quando você estiver trabalhando em uma organização, certifique-se de que você permanece atento e focado durante as reuniões de planejamento sprint, pergunte quaisquer consultas que você tem. E, por último, não supere mais do que o que você pode entregar. Muito bem, vamos avançar e discutir outra estimativa de tópico na próxima palestra. Obrigado. 27. Estimação no Scrum: Olá a todos e bem-vindos de volta. Vamos falar de estimativa agora. Então pessoal, a estimativa é um conceito geral. Não se limita apenas ao Scrum. Sempre que estamos trabalhando na criação de qualquer coisa, seja qualquer produto ou software, seríamos solicitados a fornecer uma estimativa. Estimativa de dados é algum valor ou número de quanto tempo ou esforço que levaria para fazer a coisa. Então é isso que a estimativa é. Agora este conceito de estimativa é muito importante e deixe-me sentar complicado também, porque sempre que você está trabalhando em um projeto, as pessoas podem não se lembrar de muitas coisas, mas eles sempre lembrarão da estimativa que você deu eles e eles vão responsabilizá-lo por isso. Portanto, é muito importante estimar as coisas corretamente. Agora, assim como qualquer outra estrutura de gerenciamento de projetos é, migalha também envolve estimativa. E quando faremos isso? Estimativa? Fazemo-lo durante o planeamento da corrida. O que estimamos? Estimamos histórias de usuários. Agora lembre-se em algumas empresas que também estimam bugs ou defeitos porque eles também levam tempo e esforço. Mas não é uma tendência geral. Depende da organização. A maioria das organizações ainda é apenas estimativa usuário é histórias. Próximo ponto, há uma diferença fundamental na forma como estimamos as coisas em HI Norris Scrum e a maneira como costumávamos fazê-lo em outro lugar. Então, se falamos sobre as abordagens tradicionais que usamos para estimar de baixo para cima, significa que o primeiro passo irá listar os requisitos. É o passo dois, pensamos em todas as tarefas a fazer é o passo três, estimamos cada uma das tarefas em horas ou dias. E então, finalmente, passo quatro, nós adicionamos todos eles para obter a estimativa geral. Então esta era a abordagem de baixo para cima que era usada tradicionalmente. Agora, em um gel, seguimos a abordagem de cima para baixo, que significa que estimamos em todo o conjunto de recursos com base nas informações disponíveis, corretas, atualmente. E quando algo novo aparece, podemos incorporar dívidas. Então, a idéia geral, lembre-se disso muito importante é estimar com qualquer informação disponível. E se as coisas mudarem, podemos considerar isso. E isso nos dá a vantagem de reagir rapidamente como por mudanças. Então é isso que lhe dá seu grande ponto de ser adaptável a mudanças constantes. Estimamos com qualquer informação disponível. E então, se as coisas mudarem, consideramos que terceiro, cada membro da equipe deve dar suas estimativas. Então, um planejamento Sprint é uma reunião que todos os membros da equipe comparecem como vimos e exceto o proprietário do produto e o mestre Scrum, todos eles devem dar sua estimativa. Proprietários de produtos não apontam histórias de usuários, eles só dão resposta de consulta é mestre de migalhas também não apontam para histórias de usuários. Eles só ajudam a executar o planejamento de sprint. No entanto, se o Scrum Master está fazendo um duplo papel como um desenvolvedor ou teste ou também então ele ou ela pode apontar se a equipe está bem com ele. Mas em circunstâncias normais, doadores de produtos e Scrum Masters não apontam histórias de usuários. Toda a equipe de desenvolvimento faz isso. Próximo ponto, se houver um conflito, o mestre PIO ou scrum deve pesar em explicar. Então, na maioria das vezes acontece que um membro da equipe vai estimar uma história como digamos cinco pontos e outro diria como OK, oito pontos e não entre em pânico ao ouvir os pontos da Palavra. Isso é o que vamos aprender neste capítulo. Pense neles como unidades agora. Então uma pessoa dá o ponto como 5B e outra pessoa dá o ponto é oito. Portanto, há um conflito. E em casos como este onde há um conflito, o Scrum Master pode ajudar a equipe a chegar a um acordo. O proprietário do produto também pode pesar se ele ou ela sente que 1% apontou mais alto porque eles perdem entendidos ou sobre requisitos de pensamento. Portanto, a idéia geral é discutir e, em seguida, chegar a um consenso se houver um conflito. E novamente, vamos abordar esses pontos em detalhes mais tarde. Mas como você pode ver, todo o exercício de estimativa é uma abordagem baseada em consenso em Scrum. quintas unidades de estimativa mais comuns são pontos de história, tempo, tamanhos de camisetas, unidades personalizadas, etc. Então, com o que as equipes apontam? Quais são as unidades? Os mais comuns são pontos de história como 135, et cetera, a série Fibonacci. E vamos aprender em um tempo o que isso significa e como decidir esses pontos. Agora, além desses pontos, que a equipe também pode estimar sobre o valor de tempo, ou eles podem até mesmo estimar em tamanhos de camisetas como pequeno, médio, grande, extra grande, etc Ponto final, os métodos de estimativa mais importantes são Planejando pôquer , tamanho da camiseta, votação de pontos, afinidade, agrupamento, etc. Então estes são apenas os nomes dos métodos que usamos para atribuir pontos a histórias de usuários. Agora planejar poker é o mais comum, então vamos falar sobre isso em detalhes mais tarde. T-shirt tamanho como vimos, é sobre o agrupamento de histórias em pequenas, médias, grandes, extra grandes, etc votação Dot dá a cada membro da equipe um número limitado de adesivos de ponto e eles podem votar em histórias de usuários individuais por colocando um adesivo ao lado dele. Então, mais o número de pontos em uma história de usuário maior é seu tamanho. Agora este método é usado para um pequeno número de histórias e quando queremos manter as coisas simples, não é tão comum. O método mais comum é planejar poker. E o último método 2, agrupamento de afinidade. O que ele faz é pedir aos membros da equipe para agrupar histórias semelhantes em categorias de dimensionamento. Portanto, este método também é usado para estimar facilmente se há um grande número de histórias de usuários se você quiser agrupar as coisas rapidamente. Mas como eu disse, o método mais comum para estimar é o planejamento de poker, e isso é o que vamos ver neste capítulo. Portanto, estes são os céus da unidade de estimativa mais comuns e estes são os métodos de estimativa mais comuns na indústria. E lembre-se, vamos falar sobre isso com muito detalhes em um capítulo posterior. Então vamos continuar nosso aprendizado e vamos falar sobre seus pontos de história na próxima palestra. Obrigado. 28. Pontos de história: Olá a todos e bem-vindos de volta. Vamos falar sobre pontos da história agora. Então, pessoal, o que é um ponto de história? Em termos simples, é uma unidade de medida que é usada por equipes Scrum para fornecer estimativa de preenchimento de requisitos. Então isso é o que é storypoints é apenas uma unidade de estimativa. E vamos aprender com um exemplo. Então vamos dizer que se eu chegar até você e dizer que eu quero criar um site de e-commerce. Quanto esforço será necessário para projetar a página de login? E você vai dizer algo assim, ok, é o nosso esforço médio, certo? E então eu vou te perguntar, ok, quanto esforço será preciso para projetar o fluxo de caixa? Você vai ver que, ok, é um esforço muito grande ou um grande esforço como o papai. Então é assim que conversamos, certo? E agora vamos substituir a mesma coisa por números. E vamos chamar esses números como sua história aponta. Então vamos estimar as coisas em algo como 13581321. Então esta é a série Fibonacci e vamos usar esses valores por enquanto. Então vamos pedir que você forneça estimativas apenas sobre esses números. Então, se eu perguntar isso, tudo bem. Se é uma mudança muito pequena, como apenas mudar alguns textos verbiage, você vai dizer que, ok, é um 1. Se é um pouco mais complexo do que é um três pontos, se eu quiser projetar a página de login, então você provavelmente vai dizer que são cinco pontos ou oito pontos. Se eu quiser projetar a página de checkout, você verá que é muito complexa. Provavelmente são 13 pontos ou 21 pontos. Assim como a dívida. Então, pessoal, pais, o que é um ponto de história é, você pode ter pensado que é muito complicado, mas na verdade é tão simples como isso, um número para indicar a estimativa de pensar, escrever. E aprenderemos mais sobre isso, como progredimos, o mais importante, como damos essa estimativa. Mas, por enquanto, lembre-se que um ponto de história não é nada além de uma unidade de medida que é usada para estimativa. Em segundo lugar, as equipes da idade ILL usam o formato de pontos da história versus tempo. Então, em HI Lori Scrum, a unidade primária de estimativa é uma história pontos. E a razão pela qual não usamos o tempo é porque a definição de tempo de todos é diferente. Se eu perguntar à pessoa quanto tempo levará para projetar o fluxo de checkout. Ele vai dizer que talvez 20 horas. Se eu perguntei à pessoa B a mesma pergunta, ele dirá que levará 30 horas. Então, pessoas diferentes têm unidade de tempo diferente, e isso é por causa da diferença em seu conhecimento ou experiência passada, etc. Mas se eu pedir à mesma pessoa para estimar um usuário histórias em relação a outro através de seus pontos de história. Como se exemplo, eu pedi a ambos para me dizer o quão complexo o fluxo de checkout é em termos de pontos da história, eles provavelmente vão chegar a valores semelhantes. E essa é a lógica da razão pela qual confiamos em seus pontos de história ao longo dos valores baseados no tempo. No entanto, lembre-se que os pontos são também, pontos são usados na história, nível História do usuário. Nós ainda usamos a nossa na tarefa atribuída a membros individuais da equipe para que possamos decidir seu tempo disponível. Mas essa não é a nossa unidade primária de medida em AJI. Se alguém vier até você e perguntar qual é a saída da equipe, você vai dizer que é x pontos, não através de horas. Então vocês Story Points são a principal unidade de estimativa em HIV ou scrum. Próximo ponto, estimamos sem compromisso de tempo e abraçamos a incerteza. Então, quando estamos estimando em unidades de tempo, temos que fazer um compromisso de tempo preciso. Mas é storypoints impedem isso porque não há menção de tempo. Também quando você está usando pontos de história, isso nos permite capturar incerteza, que todos sabemos que é uma realidade prática quando estamos lidando com requisitos. Então, quatro pontos da história. Usamos valores discretos como 1358 et cetera, que é uma série de Fibonacci, como eu disse. E isso aborda a incerteza porque você verá que, à medida que os números estão se tornando maiores, a diferença entre eles também está aumentando. Então isso ajudará a gerar um alarme se o ponto for enorme, como 13 ou 21, e isso significaria que os requisitos são muito complexos. Temos que dividi-los em histórias menores. Em quarto lugar, os valores relativos importam mais do que o valor bruta. Então, pontos da história do dia muito importantes podem não significar muito se você os olhar isolado com, mas se você considerá-los de uma maneira relativa, então isso forneceria grande clareza. Então, por exemplo, é dívida história é apontada três seria três vezes mais do que uma história apontou um, e seria metade como algo apontou cinco. Assim, assim, podemos compreendê-lo em termos relativos. Próximo ponto é storypoints considerar esforço mais complexidade, incerteza. Então este é um conceito muito importante e muitas vezes as pessoas são perguntadas isso em entrevistas. O que esse ponto de história indica? Então a resposta é que seus pontos de história indicam a complexidade de uma história junto com o esforço e quaisquer incertezas. Por exemplo, digamos que queremos alterar o tamanho da foto do perfil no Facebook. Nós queremos torná-los maiores agora eles estão vindo em quatro por 400 pixels e queremos torná-lo 700 por 700 pixels. Tão simples, só queremos fazer essa mudança. Então, se perguntarmos ao desenvolvedor, ele diria que é uma mudança muito simples 1 para mim. Mas se você considerar o mesmo do aspecto do testador, ele ou ela teria que verificar a mesma mudança em diferentes dispositivos de navegadores. Ele teria que se certificar de que ele não quebrou nada como mostrar a foto do perfil na página do grupo, etc. Então é por isso que a complexidade pode ser baixa, mas o esforço para o testador é alto. Portanto, temos que considerar todos esses fatores. E este é um exemplo muito, muito simples de esforço e complexidade. Veremos mais sobre isso mais tarde. E se temos algumas incógnitas também na exigência, traço também deve refletir no ponto. Portanto, provavelmente tomaremos um caminho seguro e apontaremos para um pouco mais alto se houver alguma incerteza. Então estes são todos os processos de pensamento que vão para apontar e vamos ver como dar ponto em breve. Mas por agora, lembre-se muito importante, é perguntado em entrevistas também, se alguém perguntar a você, o que este ponto de história indica em que base você dá esta história pontos, diga a ele que é esforço mais complexidade mais incerteza. E o último ponto é que os Pontos de História são um pouco confusos no começo, mas nós evoluímos como uma equipe. Quando vejo novas pessoas em sua equipe, elas são inicialmente esforço para apontar ou simplesmente repetem os pontos dados por outros. E isso é porque eles não sabem o que os outros vão dar. E então eles podem ser questionados sobre onde, por que seus pontos são diferentes. Então evitar todas essas dúvidas não cair nesta armadilha é storypoints é um pouco intrigante no início, concordou? Mas dentro de um ou dois sprints, você vai aprender a evoluir como uma equipe, como apontar as coisas como uma equipe, e então você seria bom. Tudo bem, para ajudar a tornar esta jornada ainda mais fácil para você para ajudá-lo a explicar todos os detalhes de sua história pontos. Vamos falar sobre como algumas dicas que podem nos ajudar a decidir sobre dar os pontos corretos da história. Então vamos ver isso na próxima palestra. Obrigado. 29. Como decidir pontos de história com exemplos comuns: Olá a todos e bem-vindos de volta. Vamos aprender sobre as dicas para decidir os melhores pontos da história. Mas antes de avançarmos, vamos recapitular as três informações mais importantes sobre os pontos da história que vimos anteriormente. Número um é Story Points são uma unidade de estimativa em um GI. Número dois é Story Pontos são dados como números, mais comumente série Fibonacci 13581321. E número três, os pontos da história incluem complexidade, esforço e qualquer incerteza. Tudo bem, então agora que sabemos o que é Story Points são, vamos supor que estamos sentados no planejamento sprint e o primeiro usuário é a história aparece para discussão. E você sabe que você tem que apontá-lo em breve com todos os outros na equipe. Então, qual é o processo de pensamento que está acontecendo em sua mente? Quais são as diferentes dicas e truques que você pode usar para se certificar de que você está apontando de forma eficaz e correta. Então vamos ler sobre eles. O primeiro, leia os critérios de aceitação e faça perguntas para maior clareza. Portanto, certifique-se de que você entende o requisito detalhado que está retornando os critérios de aceitação. Você sabe o que o Proprietário do Produto aceita, esperado para ser feito e não há dúvida se você tem alguma dúvida, pergunte ao Proprietário do Produto, pergunte ao desenvolvedor ou a um testador e se livrar de quaisquer incógnitas ou quaisquer dúvidas que você ter. Próximo final o aspecto mais importante a fazer da nossa parte. Pense bem no seu trabalho. Se você é um desenvolvedor, Pense no que tudo que você terá para codificar. Seja um código legado, seja uma API de front-end, back-end, seja uma área complexa, etc. Se você é um teste ou pensar sobre os cenários de alto nível, como vamos obter os dados de teste. Você tem que testar em vários navegadores? Você tem que testar em dispositivos diferentes, etc.? Então pense sobre tudo isso. Pense nessas coisas quando estiver lendo os critérios de aceitação e isso resolverá 99,9% de seus problemas. Isso lhe dará um grande detalhe sobre a complexidade e o esforço que está envolvido nessa história. E você seria capaz de apontar de acordo com isso. Em terceiro lugar, escutou outras respostas e comentários. Então, como eu disse antes, é planejamento sprint é uma reunião muito importante. Portanto, esteja atento lá, concentre-se. Eles estão ouvindo o que os outros estão vendo porque suas dúvidas ou algumas informações adicionais podem estar escondidas em dívida e isso vai mudar seus pensamentos sobre a história. Próximo ponto, aprenda com estimativas passadas. Então a estimativa é algo pessoal, dívida vem muito da experiência passada também. Portanto, você deve ter em mente o seu aprendizado do passado, seja trabalhando em algo semelhante ou sabendo sobre a funcionalidade e incluir isso em sua estimativa. Quinto, fazer estimativas informadas, mas não inflar por conveniência. Então, uma das coisas que acontece muito é que as pessoas tendem a apontar as coisas mais altas por uma questão de conveniência, elas apenas manterão tudo no balde mais alto, mas isso não está correto. Tente fazer a sua estimativa o máximo de conhecimento com base possível. Próximo ponto discutido, não apenas média quatro 0s. Portanto, este é um ponto muito importante. Digamos que a equipe está apontando uma história de usuário. E pessoa a dá pi, cinco pontos, e pessoa B dá 13 pontos. Portanto, há um conflito. Uma pessoa está dizendo que é 5 ou a pessoa está dizendo que é um ponteiro 13. Agora o que não devemos fazer é dizer isso, ok, você dá cinco. Ele deu 13. Então vamos nos contentar com um oito. Não, a dívida está errada. Precisamos discutir por que a pessoa acha que é um 5, e precisamos discutir por que a Pessoa B acha que é um 5V, precisamos ouvir os dois. E então precisamos chegar a um consenso e porquê. Porque talvez haja alguma informação adicional que esteja com eles. Talvez não tenhamos pensado em algo, talvez não tenhamos conseguido os detalhes completos. Portanto, sempre deve haver uma discussão em caso de conflito, cada lado deve dar seus argumentos e, em seguida, a equipe deve ler o ponto. Então isso é muito importante, como eu disse. E como sempre, o Scrum Master desempenharia um papel importante na facilitação disso. Sétimo, se for muito alto, é dividido. Então cada equipe aprende com sua experiência, o que é o máximo é ponto de história que eles podem fazer. Normalmente, se for 13 ou 21 para a maioria das equipes. Mas se é 13 ponteiro ou 21 ponteiro, isso significa que é muito grande. Os requisitos são para flutuar e dividir visualmente a história do usuário em componentes menores. E o último número oito, não se preocupe, vai melhorar com o tempo. Então, como eu disse, a estimativa é algo que vem muito da experiência. Não se preocupe se seus pontos são muito diferentes dos outros no início, basta dar-lhe um par de sprints e então você será bom. Lembre-se também que não há problema em ter pontos diferentes porque você pode ter algumas informações que outras pessoas não tinham. Talvez eles não pensassem em algo. Então aponte como parece OK para você e, em seguida, dar a sua lógica de apoio se houver um conflito. Tudo bem, pessoal, então esta é algumas das dicas práticas que ajudarão você a apontar melhor. Agora vamos considerar alguns exemplos comuns de cada ponto da história para que você ajude, para que você entenda o conceito ainda mais melhor. Então pessoal, como discutimos no passado, normalmente usamos a série Fibonacci para apontar. E como você pode ver na tela, temos as cartas quatro valores, 13581321, dívida que a equipe pode usar para apontar. Normalmente, 21 é um valor muito alto e isso significaria que a mudança é muito complexa ou tomada de esforço. E deve ser dividido em histórias menores. Ou se há um monte de incógnitas 2, então devemos resolver essas incógnitas primeiro e , em seguida, assumir a história talvez no próximo sprint. A memória. Em algumas empresas, eles também podem pensar em 13 S2 ponto alto e dividi-lo. Depende apenas da experiência passada da equipe, se eles tinham sido capazes de fazer 13 ponteiros no passado ou não. Se eles não estão confortáveis com 13 ponteiros, se eles não tinham sido capazes de completá-lo no passado, podemos dividi-lo em várias histórias de como 5.8.3 pontos como esse. Então vamos ver o que alguns dos cenários comuns que vamos caber em cada valor de ponto. E como sempre, vamos tomar o exemplo do site de e-commerce porque isso é algo que todos nós temos usado e podemos nos relacionar com. Então, os caras na sua tela à direita estão começando do ponto mais baixo, o ponto um. Então 1 é um trabalho muito, muito pequeno, extremamente baixo ou complexidade 0, como supor que no site queremos mudar o nome de algo. Queremos fazer algumas alterações em qualquer mensagem de texto. Queremos alterar o nome de login para entrar, ou queremos alterar a palavra do histórico de pedidos para o seu pedido. Assim como a dívida muito pequeno trabalho, muito baixa complexidade. Em seguida, temos três pontos. Então isso é algo um pouco mais de esforço e complexo do que um, porque lembre-se, como discutimos, é Story Points são relativos. Então justifique, se eu apenas lhe dizer que algo é 3, isso não significa nada. Ele só significará algo se você compará-lo com um ponteiro ou um ponteiro e então faria sentido classificar as coisas. Então, qual é o três? Três é um pouco mais de esforço e complexidade do que um, como se estivéssemos criando a opção Remover no carrinho de compras. Clique no produto, ele é removido do cartão, o preço é atualizado, coisas como dívida ou outro exemplo é o e-mail de senha esquecido. Então toda a mudança de senha esquecida seria muito grande. Mas aqui estamos falando apenas sobre o envio de e-mail. Nós dividimos a história em pequenos pedaços. Estamos apenas a falar do e-mail. Então, enviar o e-mail com um link para redefinir senha é provavelmente um três e dívida é apenas para dar um exemplo, mais uma coisa a considerar aqui é que algumas equipes também usaram dois pontos. Então eles usam na série Fibonacci, eles também inserem o valor do ponto dois. Então isso é algo mais uma vez que se baseia na relatividade. É algo que é um pouco mais complexo do que um, mas menos complexo do que três. A próxima coisa temos o ponteiro de fie-ponteiro. Então deixe-me dizer a vocês que 58 são os valores usados mais comuns e eles significam a complexidade média. Então fibra é algo como procurar um produto porque há um monte de combinações na pesquisa. Há integrações externas também para entregar o resultado da pesquisa, etc. Então é uma complexidade média e soviético dizendo que é a-fib. Ou digamos que se você deseja criar um formulário de contato vendedor que o usuário preenche e ele envia as informações para o vendedor como dívida. Então isso também é ponteiro fie porque estamos criando um formulário. Estamos integrando-o ao fornecedor terceirizado. Estamos enviando o e-mail para a equipe apropriada. Então, um monte de partes móveis. Vamos dizer que é um ponteiro de arquivo. Certo, o próximo é oito ponteiros. Então, novamente, mais complexo e esforço tomando, em seguida, 5p. Então, como projetar o fluxo para se registrar no site, Precisamos de um formulário, precisamos salvar os detalhes. Precisamos ter certeza de que o e-mail é único. Precisamos ter certeza de que a senha é forte. Precisamos enviar o e-mail para o usuário. Então, como você pode ver, é um pouco mais de trabalho e complexidade do que o que chamamos de 5p. Da mesma forma, se estamos adicionando o item ao carrinho, é um fluxo muito importante no e-commerce. Então, precisamos atender a Adicionar ao carrinho único item, vários itens. E, na verdade, as coisas mais complicadas como se o produto não está disponível ou se você não pode adicionar ou menos ou mais de dez quantidade, se você já tem o item no cartão através desse tipo de coisas. Então, há muitos cenários, muitos fluxos a considerar. E também temos que considerar a quantidade de preços, todos esses sistemas diferentes. Então é por isso que vou chamar-lhe um oito. Agora, na maioria das vezes, quando você está integrando algo a um sistema externo, o que significa algo fora da equipe, geralmente é um pouco maior esforço, complexo. É um pouco mais complexo, leva mais tempo. Então, sempre que você estiver esperando algo, sempre que houver uma dependência externa em sua equipe, certifique-se de que você inclua isso também na imagem e você aponte um pouco mais alto. Tudo bem. O próximo é o 13. Então, como eu disse, 13s são geralmente divididos em histórias de usuários menores se a equipe não está confortável porque é uma grande mudança como projetar todo o fluxo de checkout. E talvez seja mesmo aos 21 anos. Nota em 13 mais, talvez nós estamos integrando um novo método de pagamento como estamos integrando PayPal ou Apple pagar dívida seria em 13 porque você pode entender um monte de trabalho a fazer. Há muitas integrações, coordenações com a equipe externa. Há muitos testes de ponta a ponta envolvidos. Então é por isso que vou apontar como 13. Lembrem-se, rapazes, estes são apenas exemplos nas vossas empresas. Alguns deles podem ser apontados de forma diferente com base em sua experiência passada e quanto conhecimento você tem e você aprenderá quando começar a trabalhar. Estes exemplos que eu dei aqui são de uma perspectiva leiga e apenas consideram o caso mais comum. Mas se você estiver em algum lugar, se você for a uma entrevista e eles pedirem exemplos, você pode citá-los. Tudo bem caras, então eu espero que você está claro sobre seus pontos de história agora ainda é se você tem alguma dúvida ou qualquer cenário de sua empresa ou entrevistado em, você vai querer hesitar, não hesite em usar o Q e uma opção ou me enviar um e-mail. Então esta é a minha ID de e-mail, pessoal. E se você tiver alguma dúvida, como eu disse, se você tiver alguma dúvida ou qualquer cenário de sua empresa ou entrevista onde as coisas não estavam claras para você que você quer discutir, não hesite em usar a opção q ND ou você me deixar um e-mail em este endereço. Ok, agora que aprendemos sobre seus pontos de história, vamos falar sobre o método de apontar as coisas. E vai ser um tópico muito interessante. Então vamos ver isso na próxima palestra. Obrigado. 30. Planejando o pôquer: Olá a todos e bem-vindos ao tópico de planejamento de poker. Não se preocupem, não vou começar a ensinar pôquer de repente. Você ainda está no curso correto de HL. O que o poker de planejamento é, é uma estimativa antiga e técnica de planejamento que é baseada na participação da equipe e consenso. Então lembre-se, como falamos anteriormente, também planejar poker é um dos métodos para estimar as coisas, e há um monte de outros métodos também, mas o planejamento de poker é o mais comum. É o mais consensual e eu diria que é o método mais envolvente para a estimativa da equipe. E é por isso que é usado pela maioria das organizações. E a maneira como funciona é, e isso é o que está escrito no slide também, mas vamos falar sobre isso. Então, digamos que estamos no planejamento de sprint. O proprietário do produto abre o primeiro usuário é história do backlog do produto e ele ou ela fala sobre isso. Ele diz à equipe qual é o requisito, quais são os critérios de aceitação, etc Se houver alguma dúvida ou risco, et cetera aqui, ou o proprietário do produto aborda isso. E uma vez que tudo é feito, uma vez que a equipe é clara em todos os requisitos, eles não têm quaisquer dúvidas, eles não têm quaisquer incógnitas, eles não têm nenhum risco. O proprietário do produto ou um Scrum Master dará a cada membro da equipe um conjunto de cartas como este que vimos na palestra anterior. Então todo mundo seria dado cartões com o número 13581321 escrito nele. E eu me lembro de caras, o proprietário do produto e o Scrum Master, eles não apontam. Então, eles não levariam qualquer cartão sobre a equipe de desenvolvimento levaria. E na contagem de 1.2.3, toda a equipe revelará o cartão com base em sua estimativa da história do usuário. Então todo mundo levantaria um desses cartões refletindo os pontos da história que eles acham apropriado. Se todos obtiverem os mesmos pontos, bom o suficiente, isso se tornará o ponto da história. Caso contrário, se houver um conflito como, digamos, a pessoa 1, corra a carta por cinco pontos e a pessoa B levante a carta por 13 pontos, então ambos têm que explicar qual é a razão por trás da escolha desse número. E é por isso que eu disse no início também este é um exercício baseado no consenso. Nós não vamos dizer isso, ok, todo mundo exceto uma pessoa deu 13, todo mundo deu cinco. Então digamos que cinco é o ponto da história. Observe que está incorreto. Mesmo se uma pessoa deu 13 ou mesmo se uma pessoa deu um número diferente do outro, então essa pessoa tem que explicar a lógica por trás da escolha desse número. Porque lembrem-se, rapazes, ele pode saber alguma coisa ou pode ter pensado em alguma coisa, ou ele pode ter, de sua experiência passada, saber algo que outros membros da equipe não sabem. Portanto, é necessário ouvi-lo. E então temos uma discussão sobre isso, por que ele deu pontos altos, por que a outra pessoa acha que é um ponto baixo. E com base no que a pessoa diz, novamente, lemos ponto a coisa toda e essa coisa continua de novo até que haja um consenso. Se houver alguma informação nova que sai dela, o proprietário do produto tem que responder a isso. Se houver um risco ou desconhecido que sai dele, então o proprietário do produto deve dissolvê-lo. E só então a equipe iria em frente e tomar a história deste usuário e apontou. Então é assim que funciona. E neste ponto, todas as histórias de usuários que a equipe tem que levar no sprint. Então, pessoal, isso foi tudo sobre planejar pôquer. E como eu disse, é um método muito interativo, baseado em consenso para estimar coisas. E é o mais amplamente Um. Mais um ponto para adicionar aqui, a atividade de planejamento dat poker está dando uma história pontos. Também pode ser feito na preparação de backlog. Uma vez que a equipe passa por histórias de usuários na preparação backlog e todas as suas dúvidas são esclarecidas, então podemos apontá-lo. Eles só estão usando Pontos de História e planejando pôquer. No entanto, 1 de nota, mesmo que façamos isso na preparação de backlog, ainda é recomendado para rever os pontos da história e discutir as coisas uma vez rapidamente durante um planejamento sprint porque lembre-se que algo pode ter mudou, algumas novas informações teriam surgido e também toda a equipe não estava presente na preparação backlog como vimos, mas eles estão presentes no planejamento agora. Portanto, é uma prática recomendada para recapitular rapidamente, mesmo que já tenhamos apontado as coisas na preparação do backlog. Tudo bem, pessoal, então isso era tudo sobre planejar pôquer. O slide também diz as mesmas coisas que conversamos. Então, se você quiser, você pode pausar e ler o slide. Mas, de qualquer forma, já cobrimos tudo isso. Então vamos seguir em frente e vamos falar sobre o próximo tópico, capacidade da equipe na próxima palestra. Obrigado. 31. Capacidade de equipe: Olá a todos e bem-vindos a esta próxima palestra. Então neste vamos falar sobre a capacidade da equipe e como fazemos um planejamento de sprint baseado nessa capacidade. Então vamos primeiro entender o que é a capacidade. Agora, quando a equipe se reunir para o planejamento de sprint. E vamos supor que estamos discutindo coisas para um sprint de duas semanas. Portanto, duas semanas significam que há dez dias úteis e cada dia útil é de oito horas. Então cada pessoa deve contribuir com um t horas neste sprint. Mas isso pode não ser verdade. Alguém pode estar tirando uma licença ou alguém pode ter um treinamento, ou eles podem estar ocupados com outros compromissos. Isso pode acontecer, certo? Isto é uma coisa prática e é isso que a capacidade leva em contexto. Qual é a disponibilidade da equipe em horas para este sprint? E baseado nisso, faríamos o planejamento de sprint. Então vamos ver o slide agora. Primeira coisa, Capacidade é a disponibilidade da equipe em horas para o sprint. Então já vimos isso. Estamos estimando a palavra dívida pode ser feito neste sprint de acordo com as horas disponíveis da equipe. Próximo ponto, a capacidade é calculada pelo total de horas de trabalho em um sprint menos compromissos pessoais ou profissionais que são membros da equipe podem ter. Digamos que os membros da equipe podem ter reuniões de folhas em cerimônias de Scrum, etc. Então temos que descartar isso e então temos que calcular o total de horas de trabalho da equipe. E, de fato, vamos olhar para isso para um exemplo. Então pessoal, digamos que temos cinco membros na equipe, a, B, C, D, E, e há dez dias no sprint com um total de horas de trabalho de oito horas todos os dias. Então o total de horas que todo mundo na equipe tem é 80. Agora vamos considerar que um dia no sprint é um feriado, então todo mundo estaria fora, ninguém estaria trabalhando. Assim, todo mundo não teria oito horas disponíveis para este sprint. Então vamos dizer que a pessoa A está de licença por um dia, então ele não vai estar lá por mais oito horas. Descanse, ninguém está pegando folha, então estamos colocando 0. E então digamos que a pessoa D tem um treinamento por quatro horas em um dia. Então por quatro horas ele não vai trabalhar no sprint. E, por último, vamos deixar de lado algumas vezes para o diferente é cerimônias de migalhas porque lembre-se, estamos tendo um stand up diário, Estamos tendo preparação backlog. Podemos ter outras reuniões, etc. Então, vamos deixar de fora seis horas de tempo para todo o sprint para todos. Então a disponibilidade real da equipe é tanto, que é 400 horas menos todas essas coisas que estão aqui. Então o total de horas disponíveis foi 400, e então nós vamos ser ocupados por 82 horas, algum membro ou outro. Então a capacidade disponível será de 400 menos 80 a 318 horas. Então 318 horas é a quantidade de tempo que temos para este sprint. E qualquer coisa que queiramos fazer neste sprint, só devemos planejar a quantidade de trabalho que pode ser feito nessas 318 horas. É isso que é todo o conceito de capacidade. E na verdade, vamos ser mais realistas porque só estamos planejando ponta a ponta aqui. Então, idealmente, vamos ser mais realistas e vamos considerar apenas uma parte deste tempo. Portanto, há algo chamado como fator de foco. Isso é o que a equipe é capaz de permanecer focada. E assumimos que qualquer equipe tem um fator de foco de apenas 80%. Isso significa que a equipe vai estar focada apenas 80% do tempo. Então a capacidade real que vamos ter é de 80% deste 318, ou seja, 258254 horas. Então esta é a nossa capacidade. Esta é a capacidade da equipe e esta é a duração de tempo para a qual devemos estimar o trabalho neste sprint. Então, agora que sabemos que temos 254 horas de capacidade, vamos começar a partir da história de maior prioridade e então vamos começar a adicionar tarefas a ela. Então vamos voltar ao slide e dar uma olhada nisso. Então temos 254 horas de capacidade. Começaremos a partir da história de maior prioridade e adicionaremos tarefas a ela. Como vamos adicionar desenvolvimento front-end, testes de desenvolvimento back-end, etc, todas as diferentes tarefas que são necessárias para completar que sua história. E para cada uma dessas tarefas, adicionaremos nosso satélite estimado para uma história número um, que o desenvolvimento levará cinco horas. O desenvolvimento de back-end levará quatro horas, teste levará duas horas, etcetera, apenas por exemplo. Então temos um total de 11 horas de dívida seria assumido nesta história em particular. Agora a capacidade restante, lembre-se que tivemos uma capacidade total de 254 horas. Então a capacidade restante é 254 menos 11, ou seja, 243 horas. Então tivemos uma capacidade inicial de 250 ou quatro horas. A primeira história vai levar 11 horas de trabalho. Agora temos 43 horas de trabalho restantes, então você ainda tem capacidade. Vamos passar para a próxima história. Vamos estimar a tarefa em dívida, e digamos que levará dez horas. Então tivemos que 43 horas após a primeira história. A história vai criar dez horas. Então agora temos 233, nosso soviético ainda tem capacidade. Vamos passar para a próxima história e é assim que acontece. Continuamos escolhendo uma história até termos capacidade disponível. Uma vez que a capacidade é consumida, paramos de ter mais histórias e tudo o que fizemos até agora se torna nosso backlog sprint no qual a equipe vai trabalhar no próximo sprint. Então é isso pessoal, é assim que o planejamento baseado em capacidade é feito. E é considerado uma maneira muito eficiente de fazer um planejamento de sprint. Porque lembre-se, estamos sendo muito realistas no cálculo da disponibilidade de todos para trabalhar. Ninguém pode estar lá para trabalhar 100 horas. As pessoas podem tirar folhas, as pessoas podem não estar disponíveis. E estamos levando todos esses fatores em consideração. Estamos comparando sua tarefa com o JavaScript está disponível para descobrir quanto tempo há. E é por isso que a capacidade da equipe planejar a capacidade da equipe e usar essa capacidade da equipe para fazer um planejamento sprint é muito eficiente, muito útil. Tudo bem, então agora que vimos planejamento baseado em capacidade, vamos olhar para a outra variante, planejamento baseado em velocidade na próxima palestra. Obrigado. 32. Velocity de equipe: Olá a todos e bem-vindos a esta palestra sobre velocidade e velocidade baseada é planejamento sprint. Então vamos primeiro falar sobre o que é a velocidade. Velocidade é a quantidade de trabalho que é terminado por equipe em cada sprint pais o que é. Então, vamos realmente aprendê-lo por um exemplo. Então vamos dizer que em um sprint um, pegamos dez histórias de usuários e eles são totalmente história ponto foi 75. Ele, no final desta impressão que a equipe foi capaz de completar oito histórias de usuários. E o total de pontos da história que eles foram capazes de entregar foi de 60. Sprint para a equipe levou um t pontos história e eles foram capazes de entregar em 55 pontos história. Em um sprint três, a equipe levou 60 pontos de história e eles foram capazes de entregar apenas 40. Então nossa velocidade média é a média desses três números que a equipe conseguiu completar. Cerca de 50 ou 51 pontos, essa é a nossa velocidade e isso é o trabalho que a equipe deve planejar para assumir no sprint. Então vamos, quando nos reunirmos para o planejamento de sprint, vamos começar com as Histórias de Usuário em ordem de prioridade, e vamos continuar pegando eles, vamos continuar adicionando seus pontos. E uma vez que alcançamos 15 pontos da história, vamos notar que isso é o quanto somos capazes de fazer. Isto é o quanto temos sido capazes de fazer, em média, nos últimos três sprints. Vamos parar por aí. Não aceitaremos mais de 50 pontos de história. Vamos puxar todas as histórias para cima até que 15 pontos de história para o nosso sprint backlog. E é isso. É assim que o planejamento de sprint baseado em velocidade funciona tão simples quanto stat. Vamos agora ver o que o slide diz. Todos nós cobrimos muitas dessas coisas. Assim, a velocidade dos pontos de partida é a quantidade de trabalho concluído por equipe em cada sprint. Essa é a definição de velocidade que vimos. E é calculado adicionando os pontos de história de todas as histórias de usuários concluídas no sprint e tomando sua média, como vimos na folha do Excel. Terceiro ponto, idealmente usamos os últimos três dados para capturar a velocidade. E esse cara é muito importante. É feito para evitar flutuações temporárias. Então vamos dizer que essa equipe foi uma equipe concurso entregou menos em um sprint porque as histórias que eles tomaram eram mais complexas. Ou digamos que muitas pessoas estavam de licença em dados Sprint ou houve alguma interrupção, etc. Portanto, queremos descartar essas flutuações temporárias. E é por isso que vamos calcular a velocidade. Pegamos a média de pelo menos três últimos sprints e usamos isso para calcular nossa velocidade. Segundo último ponto, além de estimar as coisas corretamente e evitar o excesso de comprometimento, os dados de velocidade são muito úteis, especialmente para o planejamento do projeto. E isso porque dá ao proprietário do produto e ao titular da participação uma ideia clara de quantos sprints serão necessários para entregar a funcionalidade necessária. Então vamos dizer que temos n número de histórias de usuários restantes no backlog e a equipe é capaz de fazer 15 pontos de história em média. Essa é a nossa velocidade. Então isso nos dará uma idéia de quanto tempo levará para completar essas histórias na lista de pendências. E último ponto, devemos sempre considerar dados de velocidade em cada planejamento de sprint para que saibamos que o registro passado da equipe e não superá-lo para as coisas. Então, um dos problemas mais comuns que a equipe enfrenta na realidade é o problema do excesso de compromisso. E dando uma olhada no registro passado da equipe, os dados de velocidade ajudarão a resolver esse problema. Certo, pessoal, então conversamos sobre velocidade e capacidade, e também falamos sobre fazer um planejamento de sprint baseado neles. Eu queria mencionar mais uma vez neste ponto que é Scrum equipes sofrem de um problema muito comum de excesso de compromisso, onde nós puxar em um monte de histórias de usuários para o sprint. E então, no final do sprint, muitos deles permanecem abertos. Portanto, esta é uma realidade muito comum e prática. É chamado como sobre o compromisso e isso acontece muito. Então é por isso que é muito importante manter um olho na velocidade e também calcular a capacidade quando estamos fazendo um planejamento sprint porque se a equipe não está disponível, se a equipe está de licença, então nós não estaríamos não deve levar tanto trabalho como devemos idealmente completar. Então é isso que normalmente faço e recomendo. O que eu faço é usar a capacidade de planejar as coisas para o próximo sprint. E eu uso os dados de velocidade para ter uma idéia geral de como a equipe ainda é cada recorde. Portanto, ambos os pontos são igualmente importantes. Ambas as métricas são igualmente importantes e devemos considerar ambos quando estamos fazendo um planejamento sprint. Ok pessoal, então com isso, chegamos ao final deste capítulo muito importante e abordamos o tópico muito importante da estimativa aqui. Ótima aprendizagem. Deixe-me apenas repetir que se você tiver alguma dúvida ou dúvida sobre qualquer assunto neste curso, por favor, por favor, não hesite em usar o Q e uma opção ou envie-me um e-mail. Os conceitos de estimativa são particularmente confusos no início, embora à medida que você evolui, você seria bom. Mas se você tiver alguma dúvida, se você não estiver claro sobre nada, se você precisar de ajuda com qualquer tópico específico de sua organização, por favor, não hesite em me enviar um e-mail, minhas idéias de e-mail ali mesmo. E responderei sempre à sua mensagem dentro de 24 horas. Tudo bem, então vamos continuar o impulso de nosso aprendizado e vamos olhar para um novo tópico no próximo capítulo. Obrigado. 33. O Board e Introduction aos métricas de Scrum: Olá a todos e bem-vindos ao sétimo capítulo do curso. Então pessoal, este capítulo é sobre relatórios ou métricas usadas no Scrum. E se você pensar sobre isso, cada estrutura de gerenciamento de projetos no mundo precisa um mecanismo de relatórios para medir a eficácia e o progresso das coisas. E é Scrum não é exceção. Existem várias opções em seu Crump para medir o progresso e vamos aprender sobre eles neste capítulo. E você notará uma coisa única, e é que todos eles não são sobre desempenho individual. Pelo contrário, é sobre equipe de dardo. Então é isso que é Scrum é como vimos antes. Temos sucesso ou falhamos como uma equipe. Então vamos começar e dar uma olhada no conteúdo. Lembrem-se, pessoal, eu incluí alguns tópicos aqui que normalmente não vão encontrar em outros relatórios de discussão, mas eles são igualmente importantes para medir as coisas e é por isso que eu queria falar sobre eles. Então vamos começar com a placa Scrum e relatórios diários a partir dele. Em seguida, vamos aprender o Bund para baixo e queimar gráficos seguido por gráfico de velocidade e como podemos até mesmo usar o Product Backlog para observar as coisas. Então, vamos começar. Então o primeiro tópico que vamos olhar é o quadro Scrum. E, na verdade, a placa Scrum é a face de cada processo Scrum. Se você vai para qualquer lugar que está seguindo é migalha, você provavelmente vai notar este quadro físico e ele lista as diferentes histórias de usuários que essa equipe está fazendo e seu progresso. Ou pode haver uma versão virtual dele no Gita ou em qualquer outra ferramenta que estamos usando. Mas, no entanto, é placas Scrum e a colocação de histórias de usuários sobre eles. O primeiro meio para verificar o progresso das coisas. Então, como o slide também diz, é desintegrado é um instantâneo visual do backlog sprint. Ou seja, o usuário é histórias que estamos fazendo neste sprint. E é mantido em uma forma virtual ou física. Assim, algumas das equipes fazem o é desintegrado em um formato virtual, enquanto outras mantê-lo em uma versão física. Ambos são os mesmos no layout. Se eu mostrar a versão virtual primeiro, é assim que parece. Então este é um projeto para um site de comércio eletrônico, e como você pode ver, há vários usuários histórias como esta. Um aqui é para a página de login, este aqui é para a página de checkout, etc. E para cada uma dessas histórias criamos essa tarefa como desenvolvimento de front-end, testes, UAT, etc. E este é apenas um exemplo. As equipes podem criar tarefa em nível mais granular também se ele está indo para separar pessoas. E também como você pode ver, há quatro colunas para status são tarefas, em andamento, testes feitos, etc. E novamente, esta é apenas uma maneira de categorizar. As equipes podem personalizá-lo com base em suas discussões e acordos. E essa é uma das vantagens de ferramentas como esta. Então, de manhã, quando suas equipes cumprirem seu padrão antes disso, todos devem mover suas tarefas neste barco de acordo. Assim como o desenvolvimento está atualmente em andamento, então ele está sentado aqui, projeto de caso de teste está em andamento taxa está sentado aqui, et cetera, que você não é um começo, então ele ainda está sentado no balde de tarefas como dívida. E como o trabalho de alguém é concluído, eles vão movê-lo para aquele balde feito. Assim, como quando o desenvolvimento é concluído, eles vão movê-lo para Dan mentor projeto caso de teste está completo, eles vão movê-lo para feito. E uma vez que todas essas tarefas são movidas para dentada dívida significa que todo o trabalho está concluído e uma história pode ser fechada. Então este era o barco virtual. E, na verdade, vamos usar este mesmo tipo de aborrecido quando vamos fazer o nosso capítulo projeto de vida. Então esta foi apenas uma breve introdução de barcos culturais por enquanto. E, da mesma forma, temos outra placa física também. Então este é um dos exemplos de barco físico. E então temos outro aqui também. Então, ambos são semelhantes. E se você olhar com cuidado, é muito semelhante à dívida do conselho virtual também vimos. E ele tem o novamente, as colunas para diferentes status gostam de fazer em andamento, teste feito, etc. Então estamos criando essas colunas. Estamos separando-os por ameaças para marcar o status de cada tarefa. Estamos tendo uma nota adesiva para cada tarefa pode Nós vamos movê-los para diferentes baldes como eles são concluídos. Então todo o conceito é o mesmo, seja o Conselho virtual ou o barco físico. É apenas a diferença em sua configuração e como a equipe reage a ela, como sua equipe a usa. Desculpe. Então, voltando ao slide, algumas equipes gostam de fazer coisas em um quadro físico porque ele é sempre visível. Qualquer um pode passar por aqui e ver o progresso das coisas. Há uma sensação de realização quando você está movendo suas notas pegajosas, etc. E alguma equipe, eles preferiram fazer a placa virtual porque é mais em tempo real. Não há nenhum esforço necessário para criá-lo. Ele salva as notas pegajosas, papéis, etc. Então, novamente, dependendo da preferência das equipes, eles podem escolher qualquer versão. Mas o takeaway mais importante é que o conselho de equipe scrum é o relatório mais comum do trabalho que a equipe está fazendo em um sprint. E é por isso que eu incluí neste capítulo, é um dos grandes métodos de relatório para o trabalho da equipe. Apenas indo para o Conselho, qualquer um pode ver em que toda a equipe está trabalhando, qual membro da equipe está trabalhando em que tarefa? Qual é o total de pontos que nossa equipe tomou? Quantos deles estão fechados? Quantos deles estão abertos? Ou seja, há qualquer bloqueador, etc Então, tudo em toda a informação total do Sprint está contido nesta única placa. Normalmente, as equipes fazem seu stand up matinal também com este barco aberto ou se eles estão fazendo uma versão física, eles ficam perto do tabuleiro e fazem o stand-up. E promove a discussão entre a equipe sobre cada um dos itens. E o mais importante, um dos aspectos bons é que quando alguém conclui seu trabalho, quando alguém move suas tarefas para a coluna concluída, isso cria uma sensação de realização em toda a equipe. Tudo bem, pessoal, então isso foi sobre um tabuleiro Scrum. Vamos olhar para outro relatório em uma próxima palestra. Obrigado. 34. Burn: Olá a todos e bem-vindos de volta. Vamos falar sobre o gráfico de queimaduras agora. Então, antes de fazermos isso, vamos considerar um exemplo típico. Em nossa equipe, fazemos duas semanas de um sprint e começamos o sprint, digamos todas as segundas-feiras. Então de segunda a sexta-feira da semana atual e, em seguida, de segunda a sexta-feira da próxima semana, estaremos trabalhando neste sprint. E então na terceira segunda-feira que chegar, essa equipe começaremos com o próximo sprint. É o caudal de um sprint de duas semanas. Agora vamos dizer que nesta corrente é sprint tomamos oito histórias de usuários com um total de 45 pontos de história. Agora a equipe tem que trabalhar de tal forma que mantenhamos um bom progresso e continuamos fechando as histórias em intervalos frequentes. Caso contrário, o que aconteceria? Estaríamos sobrecarregados no final. E então poderia haver histórias de usuários, dívida não se fecha e rolar. Então, o gráfico que nos mostra essa informação em particular, que é o trabalho que resta a ser feito versus o tempo é chamado como o gráfico de burndown. E é assim que parece. Então, temos os Pontos de História do Usuário no eixo y vertical, e que dias ou tempo está no eixo x horizontal. E se você olhar para o gráfico, há duas linhas aqui. Este escultura é a linha ideal. Isso significa, o que significa a progressão gradual das coisas e conclusão como se você estiver trabalhando em uma taxa ideal constante. E a segunda linha é a linha de conclusão real. Portanto, não se preocupe com a forma como este gráfico é feito. Se você usar uma melodia como G, certo, seria criado automaticamente para você, não haveria nenhum trabalho manual necessário. Vamos tentar entender o que este gráfico transmite. Então começamos com 25 pontos da história. Essa é a nossa estimativa total. E a ideia é manter esta linha vermelha o mais próximo possível da cinza. Se o ReadLine real está indo acima do DRE, isso significa que estamos indo mais devagar do que o estimado. E se estiver abaixo, significa que estamos indo para mais rápido. Então ambos os casos não estão bem. Temos que permanecer o mais próximo possível da linha cinzenta. Estas caixas, caixas cinzentas que você vê são para o fim de semana, então não haveria progresso aqui. É por isso que esta linha cinzenta é plana aqui. Caso contrário, em tudo, outras vezes, vai cair gradualmente. Portanto, isso significa que estamos a fechar as coisas gradualmente. Então, toda a idéia é que o trabalho real também esta linha vermelha deve ser o mais próximo possível desta linha cinza. E a melhor maneira de fazer isso é fechar histórias em intervalos regulares, tão simples quanto isso. Isso é tudo o que é necessário para obter um gráfico de burndown ideal, estimar o que você pode levar tanto trabalho quanto você pode entregar e, em seguida, fechar as coisas no conjunto de dados de intervalo gradual. Agora, antes de voltarmos ao slide e lermos, outras coisas são observação rápida aqui. Você vai ver que aqui este gráfico disparou. Então, por que isso aconteceu? Isso aconteceu porque podemos ter tomado em um novo usuário é história no meio de um sprint, o que não é uma coisa ideal como discutimos, mas isso acontece porque pode ter havido algum novo requisito de negócios urgente que veio à tona. Então é por isso que o gráfico curto para cima naquele ponto. Tudo bem, vamos voltar para o slide agora e vamos continuar. Então, já vimos o que é um gráfico de queima e quais são seu eixo X e eixo Y. Terceiro gráfico de burndown nos ajuda a rastrear o progresso do escritório sprint porque podemos verificá-lo diariamente e ver se estamos fechando as histórias ou não e como eles sprint está indo. Então, se restam apenas dois dias no sprint e a linha real está a quilômetros de distância da linha cinza, então é um problema. Em seguida, mantém a equipe dentro do cronograma. Então, apenas olhando para o gráfico, equipe pode saber se eles estão no caminho certo ou não. E terceiro, a queimadura é muito simples de entender. Como eu disse, ele é criado automaticamente pelo Gita ou qualquer outra ferramenta que você está usando. Não há nenhum esforço manual necessário e você pode olhar para ele todos os dias e entender se a equipe está no caminho certo ou não. Último ponto, gráficos de burndown devem ser analisados regularmente, especialmente pelo proprietário do produto e o Scrum Master para se certificar de que as equipes estão no caminho certo e as equipes estão fazendo progresso. E até mesmo toda a equipe pode olhar para ele no stand-up. Em um dos meus projetos, tínhamos uma placa de Scrum fisicamente onde nos levantávamos todas as manhãs. E o Scrum Master costumava colocar uma impressão fora do gráfico de queimaduras todas as manhãs antes de eles se levantarem para que a equipe possa ver o que eles estão fazendo e eles podem ter certeza de que eles estão progredindo no caminho certo. E lembre-se também que este gráfico de queima é uma ferramenta muito boa para reuniões retrospectivas. Além disso, ele vai dizer à equipe como eles progridem. Havia algum bloqueio de estrada, por que eles não poderiam fechar as coisas em intervalos regulares, et cetera. Gráfico tão simples e vários utilitários. Tudo bem, vamos seguir em frente e vamos falar sobre outro relatório na próxima palestra. Obrigado. 35. Burn: Olá a todos e bem-vindos de volta. Agora que sabemos sobre o gráfico de burndown, vamos falar sobre algo que soa semelhante, mas é uma coisa completamente diferente. O gráfico de queimaduras. Então pessoal, o gráfico de queima mostra a quantidade de trabalho que a equipe já concluiu e a quantidade total de trabalho que é necessário no projeto. Portanto, é uma medida do trabalho total necessário versus o que está concluído. E é assim que o gráfico de queimaduras se parece. E aqui, mais uma vez, temos o esforço ou os pontos da história no eixo y vertical e o tempo no eixo x horizontal. Mas no gráfico você verá agora três linhas. Então, o amarelo é a linha ideal, o vermelho é o esforço total necessário para alcançar o objetivo de desenvolvimento do produto, significa o nosso esforço total necessário. E o azul é o trabalho concluído, quanto a equipe já realizou. E você pode ver que esta linha amarela ideal está subindo com o tempo. Isso significa que temos de avançar para o objectivo final com o tempo e de forma consistente. Então cada sprint devemos chegar um pouco mais perto dele. Se estamos abaixo da linha ideal, isso significa que estamos indo devagar e corremos o risco de conclusão. Então é isso que o gráfico de queimaduras é. Lembre-se, no gráfico de burndown, verificamos que estamos queimando coisas que é, estamos fechando é histórias onde, como no gráfico de queimadura, vemos que se estamos subindo, estamos subindo em direção ao nosso objetivo final. É assim que se entende. Vamos voltar aos slides e checar os outros detalhes. Então ponto número um, N2 que já cobrimos. Lembre-se no gráfico de burndown que temos o excelente trabalho no eixo y, mas aqui no gráfico de queima temos concluído e trabalho total. E é por isso que algumas pessoas consideram queimar gráficos mais positivos porque ele fala sobre o trabalho concluído versus o burndown, que fala sobre o trabalho pendente. Próximo ponto, quais são os benefícios da sobrecarga gráficos para que ele mostre o trabalho total e o trabalho concluído lado a lado. Então essa é uma comparação muito boa. Em seguida, ele mostra o quanto de trabalho resta e que estamos vendo ambas as coisas lado a lado. Podemos ver o progresso das coisas. E último ponto queimar até gráfico fornece mais detalhes da conclusão do projeto. Então, obviamente, temos linhas separadas de trabalho total e trabalho concluído como vimos. E assim saberemos que nosso projeto é como ele está progredindo e se ele está no caminho certo para a conclusão. Além disso, digamos que, se houver uma nova adição ao projeto, você pode ver essa colisão aqui. Então isso mostrará que algo novo foi adicionado e nosso escopo aumentou. Essa é uma vantagem muito boa de queimar gráfico para rastrear o status geral do projeto. Certo, pessoal, então esse foi o gráfico de queimadura e outro importante é o relatório de migalhas. Vamos aprender um novo relatório na próxima palestra. Obrigado. 36. Gráfico de velocidade: Olá a todos e bem-vindos de volta. Vamos falar sobre um dos relatórios mais simples, mas poderoso em Scrum dot é o gráfico de velocidade. Então, no último capítulo, falamos sobre velocidade, e isso significa quanto trabalho nós comprometemos em um sprint particular e quanto nós realmente comprometemos. Então essa é a velocidade. E quando traçamos essas coisas lado a lado, obtemos o que é chamado de gráfico de velocidade. Então este é o gráfico de velocidade, e como eu disse anteriormente, é um relatório muito simples. Tudo o que temos são dois gráficos de barras lado a lado. E no eixo y temos nossa unidade de esforço como todos os pontos da história. E no eixo x temos os sprints. E lembre-se, como conversamos anteriormente, também, é melhor olhar para os dados dos últimos três ou cinco são impressos para entender melhor as coisas. Então o que estamos fazendo é para cada sprint, estamos plotando os pontos de história comprometidos em cinza e o concluído é storypoints lado a lado em verde. Então, como você pode ver para uma ajuda de sprint, aquela equipe ficou aquém de completar tudo o que cometeu. O gráfico de compromisso está em torno de 35, enquanto o concluído é em torno de 30. Então isso significa que a equipe não completou todas as coisas que eles tinham acordado. Então, em um sprint oito, nós caímos nele em suma é impressão nove e é impressão dez nós temos uma conclusão de 100%. Sprint 11, Nós realmente fizemos mais. Então isso significa que a equipe levou em algo extra no meio de um sprint e eles foram capazes de completar dados também. Então este é um bom gráfico de velocidade de equipes caras porque como você pode ver na maioria dos casos, eles alcançaram o que foi estimado. E, de fato, em um dos casos, eles estão superando. Também. Outra coisa a notar é que aqui em um sprint 13, que a equipe levou um grande hit e há uma enorme lacuna entre o que o comprometido e entregue. E lembre-se porque isso aconteceu é tema para retrospectiva. Mas você sabe, pode ser devido a várias razões como várias pessoas tiveram que tirar folhas repentinas ou a equipe ficou atrasada devido a algum trabalho urgente que entrou ou algum outro bloqueador apareceu, etc. E aconteceu em um sprint. Tudo só descansa. Tudo é que os sprints são bons. E é por isso que, se você se lembra, dissemos anteriormente também que ao olhar para a velocidade, devemos olhar para a média de pelo menos passar três sprints. Então, olhando para este gráfico, qual é a informação que podemos obter? Podemos dizer que para esta equipe em particular, cerca de 45 a 55 pontos de história é um bom número. Dados é a equipe de dados idealmente deve tomar porque eles foram capazes de completar que muito trabalho sprints durante todo o dia. Então, esse é um bom número para eles quando eles se reuniram para Planejamento Sprint e quando eles decidem levar em suas histórias um por um, eles devem se contentar com algum lugar perto de 45 a 55 pontos. Então é isso. É um gráfico de velocidade, pessoal e como usá-lo. E lembre-se, como eu disse, é um gráfico muito simples, mas muito eficaz. Criá-lo é muito simples. Nós só temos que traçar o estimador é história e realmente completou a história lado a lado. E, de fato, se você estiver usando uma ferramenta como Gita ou qualquer outra ferramenta de gerenciamento de projetos atualmente, elas serão criadas automaticamente para você. Você não tem que fazer nenhum esforço. A única coisa é que quando você está visualizando ele garante que você está usando as últimas três ou cinco impressões IS de dados para fazer a análise. Muito bem, pessoal, vamos voltar para o escorrega e continuar. Então vamos falar sobre o último ponto, porque já vimos o resto uma vez. Assim, o gráfico de velocidade ajuda a saber qual é a capacidade da equipe, quanto eles podem entregar idealmente. E baseado nisso, podemos planejar nossos sprints. Nós já vimos isso no último capítulo. Na verdade, não apenas um sprint, ele nos dá uma idéia do projeto geral também. Então, por exemplo, a equipe faz aproximadamente 50 em um sprint e temos 150 pontos a mais para fazer antes de podermos liberar o produto. Assim, podemos obviamente ver que serão necessários três sprints para terminar todo o trabalho. Esse é o propósito de usar o gráfico de velocidade, esse é o propósito de saber quanto trabalho a equipe pode fazer. Mais uma vez, relatório muito simples, mas eficaz. Tudo bem, agora nós cobrimos o mais comum são os relatórios do Chrome, mas há mais uma análise que eu queria falar. Então vamos ver isso na próxima palestra. Obrigado. 37. Mantendo um olho no Backlog: Olá a todos e bem-vindos de volta. Então, pessoal, até agora nós vimos várias opções que nos ajudam a analisar como os sprints estão indo, qual é o progresso da equipe, etc Nós demos uma olhada no gráfico de burndown , o gráfico de queima, o gráfico de velocidade, etc. qual é o progresso da equipe, etc Nós demos uma olhada no gráfico de burndown, o gráfico de queima, o gráfico de velocidade, etc. alguns dos relatórios mais comumente usados no Scrum. Mas, ao mesmo tempo, o backlog do produto que temos mantido falando por tanto tempo agora, isso também é algo que eu queria falar e dados porque apenas olhando para este produto backlog pode nos dar muita visão sobre como as coisas são indo. Se você se lembra de nossos últimos capítulos, o Product Backlog é como nosso roteiro de produtos. Então é uma lista de desejos do que todas as coisas que queremos fazer. Temos um novo requisito, colocamos no Backlog. Se obtivermos um novo defeito que possa ser feito mais tarde, colocamo-lo no backlog. Então, em intervalos regulares, devemos analisar se nosso backlog não está se transformando em algo muito grande e incontrolável porque então nós nunca seríamos capazes de terminar as coisas, certo? Nós estaríamos fazendo cinco coisas neste sprint para um lançamento específico, mas haveria mais dez adicionados ao backlog e será um processo sem fim. Então essa é a idéia geral deste slide. Eu queria que você soubesse este conceito da minha experiência pessoal que relata como queimadura, queima velocidade. São métricas muito boas. Mas, ao mesmo tempo, simplesmente olhar para o backlog também pode revelar como as coisas estão acontecendo na equipe. Então vamos ver o que o slide diz. Primeiro, o backlog é muito grande e incontrolável? Então já conversamos sobre isso. Nunca devemos chegar ao ponto em que temos que dizer que, ok, fizemos três pontos de trabalho para liberar o produto. Desculpe, fizemos três sprints de trabalho para liberar o produto. Mas agora precisamos de impressões digitais de Maurice porque houve uma tonelada de coisas adicionadas ao backlog. Não queremos fazer isso. Nosso atraso nunca deve se tornar muito grande. Nosso atraso nunca deve se tornar incontrolável. próximo ponto é o backlog que está sendo revisado e priorizado com freqüência. Então esta é a resposta para todos os nossos problemas. O proprietário do produto deve revisar o backlog com freqüência. Ele deve priorizar e você deve limpá-lo com frequência. Então, dat é a solução. terceiro ponto é que todos jogam as coisas em atraso. Então, em algumas das equipes que eu falei, o que acontece é que pegou uma história de usuário e, em seguida, qualquer defeito ou qualquer requisito que aparece, eles simplesmente movê-lo para o backlog. Então eu vou aconselhar contra esta prática. Lembre-se que o resultado de cada sprint é um produto potencialmente enviado. Portanto, abordar o defeito também é importante se for um defeito de caso de borda e não esperamos que isso aconteça com freqüência, então provavelmente podemos adiá-lo para mais tarde. Mas simplesmente colocar tudo cegamente no backlog não é uma boa idéia de fazer as coisas. Próximo ponto, ser transparente sobre a dívida técnica. Então, a dívida técnica é um agente conceitual muito interessante. Você pode ler sobre isso. Isso significa simplesmente o custo de retrabalhos futuros que virão porque a equipe escolheu uma solução fácil e rápida agora em vez da melhor e demorando um. Então, um grande atraso é um sinal de alta dívida técnica porque estamos simplesmente adiando as coisas. E lembre-se, em algum momento vai consumir nosso esforço e custo, porque teremos que lidar com eles. Então essa é a dívida técnica. E a dívida é algo que deve ser mantido em mente, especialmente se você está em uma função de gestão. Em quinto lugar, RV fechando uma história de usuário e adicionando mais dois ao backlog. Então, se não estamos pensando claramente sobre os requisitos o que vai acontecer é que vamos fazer uma história de usuário, mas mais tarde vamos descobrir mais dois requisitos que nós perdemos. E teremos que adicionar esses requisitos à lista de pendências para fazer mais tarde. Então pense, pense nos requisitos claramente. Pense nisso como uma equipe, discutir sobre isso, tentou capturar o máximo de exigência possível em um único tiro. Isto é algo que pode não ser totalmente evitável, mas devemos fazer o nosso melhor ao máximo. E, finalmente, estamos adicionando muitos bugs para o trabalho feito para o backlog. Então, se cada Sprint, nossa contagem de bugs está aumentando, então isso significa que em algum lugar e nós não estamos fazendo coisas com qualidade. E, infelizmente, esta é uma ocorrência muito comum em é migalha porque as coisas se movem tão rápido. Então tente entender claramente os requisitos. Peça qualquer consulta que você tiver. A ideia não é criar algo com dez defeitos que levará muito tempo para que a equipe conserte. Isso é algo que deve ser observado, especialmente pelos líderes técnicos e gestores. Certo, pessoal, isso foi alguns sinais de alarme para olhar no backlog, como eu mencionei, temos relatórios como Burndown Velocity, etc. Mas se você ficar de olho nessas coisas simples no backlog, ele vai lhe dar muitas informações sobre como as coisas estão indo. Tudo bem, então com isso, chegamos ao fim do capítulo. E, de fato, agora cobrimos todos os tópicos relacionados ao Agile e Scrum que tínhamos planejado para o conteúdo do curso. Agora sabemos sobre HIV, sobre Scrum, os diferentes papéis, cerimônias, artefatos, estimativas, métricas, etc., tudo o que é necessário para ser um especialista em AGI e Scrum. Então, congrats corporativos pessoal, você é agora um campeão em idade Island é Scrum. Você está totalmente familiarizado com todas as coisas sobre esses tópicos. Você pode começar a usá-lo. Você pode usá-lo para impulsionar melhorias em suas organizações. Você pode mencionar isso em seu currículo ou qualquer coisa que você quiser. Então pessoal, este curso não termina aqui, embora tenhamos abordado todos os tópicos agora que aprendemos cada detalhe em teoria, vamos colocá-lo para uso em um projeto prático e ver como as coisas funcionam no mundo real. Porque lembre-se Andi, quando fizermos as coisas, aprenderemos sobre a implementação do mundo real. Então, eu vou vê-lo no próximo capítulo e vamos começar a trabalhar em um projeto de ponta a ponta para discutir tudo em detalhes. Obrigado. 38. Projeto prático - Implementação de Agile - Parte 1: Olá a todos e bem-vindos. Então pessoal, este é o projeto de aprendizagem prática deste curso. E neste capítulo vamos aplicar todo o aprendizado que temos feito até agora no curso para ver como as coisas funcionam no mundo real, sugiro que você preste muita atenção a este capítulo porque somente se você se concentrar nos aspectos práticos de coisa, você vai ficar a conhecer todos os detalhes. Então vamos começar a ação. Então, neste capítulo vai ser dividido em quatro partes onde vamos começar com como obtemos os requisitos e como fazemos escrevê-los como histórias de uso. Então vamos ver como o backlog do produto é criado. Como fazemos o planejamento de sprint e como finalizamos o backlog de sprint? Em seguida, vamos ver como o sprint acontece, como o trabalho acontece quando eles sprint está em execução. E finalmente, vamos ver como o trabalho é liberado e avançamos. E como você pode ver, não haveria slides neste capítulo, todos os aprendizados são práticos. Vamos usar esta ferramenta Xcel Energy EDA para entender as coisas. Agora neste projeto vamos simular a criação de um site de comércio eletrônico. E eu gosto de usar o e-commerce para explicações porque é um domínio muito dinâmico. E todos nós poderíamos nos relacionar com isso. Todos nós usamos Amazon, eBay, ou qualquer outro site de comércio eletrônico. Então, é um bom exemplo a considerar. E nós vamos criar um site de comércio eletrônico do zero, e ele vai ser chamado como uma criança Mega Mart.com, aquele projeto de verão configurando este site de comércio eletrônico. E vamos ver como fazer isso. Então, vamos começar. Então vamos começar com a primeira parte, obtendo os requisitos e convertendo-os em histórias de usuários. Então, como obtemos os requisitos? Agora, os requisitos podem vir de fontes diferentes. Hoje em dia, todas as empresas têm um grupo dedicado à gestão de produtos que são responsáveis por gerar ou coletar esses requisitos. E para os nossos propósitos, nós os chamamos de partes interessadas. Por isso, já vimos o que é os detentores de participações são. Eles têm o requisito comercial a ser cumprido, e assim cada equipe irá obter os requisitos deles. Agora, lembre-se que esses acionistas primeiro geram ou coletam requisitos de alto nível, que é como um documento de visão do produto. Assim, eles podem se reunir com o cliente final ou usuário para entender esses requisitos ou para o nosso propósito de criar um site de comércio eletrônico. Referir-se-ão às necessidades do mercado ou aos concorrentes para compreender quais as características que devem existir. E com base nisso, eles criarão um requisito ou visão de alto nível. E isso será seguido por uma sessão de brainstorming de requisitos onde, você sabe, as equipes de gerenciamento de produtos se reúnem e decidem quais todos os recursos ou Epics precisavam ser feitos a partir dos requisitos de alto nível. E, finalmente, isso deve ser finalizado. Temos os épicos, que serão divididos em histórias de usuários. E vamos escrever os critérios de aceitação para essas Histórias de Usuário que se tornarão nossos requisitos. Então esse é todo o fluxo geral. Requisitos de alto nível, depois Epics, histórias de usuários e critérios de aceitação neles. Então, com a finalidade de criar um site de comércio eletrônico, vamos imaginar Amazon ou eBay em nossa mente. E vamos pensar sobre o que todos os recursos ou épicos que não precisavam. Então, por exemplo, eles precisam do seguinte. Precisamos de uma conta épica com histórias de usuário para registro, login, senha esquecida, página da minha conta, registro de e-mail, mudança de senha, etc E então precisamos de um pixel pesquisador. No tal pixel teremos coisas como criar uma página de lista de caixa de pesquisa de todos os produtos, refinamentos de produtos, classificação de páginas de categoria, páginas de produtos, etc Em seguida, podemos ter uma página de checkout. Portanto, é uma área muito importante e crítica de qualquer site de comércio eletrônico. E teremos histórias de usuários para a página do carrinho de compras, a página de endereço de envio do checkout, pagamento com cartão de crédito, PayPal, confirmação do pedido do Apple Pay, e-mail, todas essas coisas. E por último vamos ter o épico para a arquitetura de processamento de pedidos. Então este vai ser o material técnico que precisamos para criar um banco de dados de usuários, um banco de dados de produtos, banco de dados ordenado, etc. E eu incluí este exemplo aqui para você saiba que para fazer os requisitos de negócios, também precisamos desse material técnico. Assim, poderia haver requisitos técnicos também requisitos técnicos puros como a criação de todos esses bancos de dados. Tudo bem, agora temos todos esses épicos e sabemos o que todas as histórias de usuários precisamos criar para eles. Vamos começar escrevendo essas histórias de usuários e seus critérios de aceitação. E para o papai, vamos usar essa ferramenta. Então esta é a ferramenta JIRA. Você deve ter ouvido falar sobre isso. É uma ferramenta muito agradável e poderosa e é usada por diferentes empresas. Dívida segue um GI e alguns dos, maioria dos grandes nomes no mercado de gestão de produtos e implementação de HL. E você pode experimentar você mesmo. Basta ir para o seu site que está em lesbian.com e clique neste botão tente agora aqui para criar uma conta gratuita não é nenhuma informação de pagamento necessária. Você não precisa dar nenhum cartão de crédito, é totalmente grátis. Assim, você pode criar uma conta você mesmo e você pode explorar todos esses recursos gratuitamente. Então, quando você cria uma conta no Gita, a primeira coisa que você precisa fazer é criar um projeto. E eu criei o meu com o nome da dívida do site de comércio eletrônico. Estamos criando um gel Mega Mart. Você também pode criar seu próprio projeto. Basta clicar neste botão Criar projeto aqui. E abrirá algo assim. Então você tem que clicar no botão selecione clássico aqui. E uma vez que você chegar a esta página, basta dar um nome para o projeto e certifique-se de manter o modelo como ele é migalha porque nós vamos estar desenvolvendo este projeto usando a metodologia scrum. E papai sente-se, uma vez que você tenha preenchido todos esses detalhes, você vai pousar aqui com seu projeto listado aqui. Ok, então agora que temos um projeto, vamos em frente e criar nossos primeiros épicos. Então, vamos clicar neste botão Criar aqui, e vamos criar nosso épico. Então, se eu voltar para a planilha do Excel, tivemos quatro épicos, conta, pesquisa, checkout e arquitetura. Então vamos criar esses épicos no g r2. Então eu vou selecionar a opção para épicos aqui. E usarei para criar o primeiro épico. Nome épico seria conta. E vamos dar o resumo como este é o épico para trabalhos de conta. Eu já fiz isso, então ele está mostrando auto preenchido com sugestões, mas, você sabe, você pode dar qualquer coisa em alguém e você pode manter o épico chamado como algo específico dívida aponta qual área é ou qual equipe é, esse tipo de coisas. Então, vamos clicar. Então vamos criar este primeiro Épico. E o que vamos fazer é clicar nisso, criar outro botão aqui. Porque temos que criar mais três épicos. Então eu vou clicar neste Criar. E como diz, nosso primeiro Épico foi criado. Ok, vamos criar o próximo para o checkout. Ou foi realmente revistado. Então vamos criar para pesquisa, e este é o épico para trabalhos de pesquisa. Então, vamos clicar em Criar. Em seguida, podemos adicionar o 14x Checkout. Então este é o épico para trabalhos de checkout. E, finalmente, podemos clicar em Criar o último para arquitetura. E pai set, nós criamos todos os nossos quatro épicos. Então, se você se lembrar de nossos aprendizados, e épico é um grande requisito a partir do qual nós limpamos as menores, pequenas histórias de usuários. Por isso, decidimos adotar os épicos para nossa conta de projeto checkout, pesquisa e arquitetura. Então criamos esses épicos. Agora, o próximo passo que temos que fazer é criar histórias de usuários dentro delas. Então deixe-me clicar nesta opção aqui, e deixe-me clicar nesta história. Então agora vamos criar nossa história mais rápida. E vamos criar esta história para auto-registro. Então eu vou nomeá-lo algo como fluxo de auto-registro de usuário. Tudo bem? E mais uma vez, não se preocupe com todas essas coisas auto-povoadas que está acontecendo porque eu fiz isso uma vez para praticar neste navegador. Mas no seu caso, você pode digitar. Você pode dar o nome que quiser. Mais uma vez, queremos que os nomes sejam específicos para que aponte para o que a história sabe. Qualquer um pode olhar para o resumo e descobrir o que é esta história. Então, vamos seguir com este resumo. E, em seguida, o próximo passo que vamos fazer muito importante é listar os critérios de aceitação bem aqui. Então, se vocês se lembram de caras, quando estávamos fazendo o capítulo sobre histórias de usuários e critérios de aceitação, mencionamos que sempre que estamos escrevendo critérios de aceitação, nós sempre começamos com as palavras como um usuário. E, na verdade, o formato geral é este como uma persona. Então, como usuário ou como especialista em marketing ou como equipe jurídica, seja quem for o cliente final para o qual estamos projetando essa cadeia. Então, como personagem, eu quero um gol. Então, qual é o objetivo final de criar este histórico de usuários como neste caso, o resultado final é que o usuário deve ser capaz de se registrar. Esse é o nosso objetivo. E então, finalmente, para que o benefício partes do que é o benefício de fazer esta cadeia. O benefício é que uma vez que o usuário é capaz de se registrar, ele será capaz de fazer as compras. Então este é o formato geral em que morremos, os critérios de aceitação. E eu vou escrever desta forma. Como usuário, eu quero me registrar no site para que eu possa começar a fazer compras. Esta é a nossa declaração geral, certo? E foi escrito neste formato. A persona é o usuário. O objetivo é se registrar no site e o benefício é que ele pode. Ele ou ela pode começar a fazer compras. Então esta é a nossa primeira linha, o resumo. Deixa-me só remover esta parte. E então o que precisamos fazer, precisamos escrever os critérios de aceitação detalhados. Assim, os critérios de aceitação, como vimos anteriormente, é a lista detalhada dos requisitos. E lembre-se sempre que estamos escrevendo os critérios de aceitação, temos que ser o mais detalhados possível. Não temos que deixar nada para supor. Temos que marcar tudo o mais claramente possível. Temos que cobrir cada detalhe o máximo possível, certo? Nós não temos que ir muito para a parte como, como ela será implementada, mas certamente precisamos colocar tudo o que é necessário, a parte y. Tudo bem, então vamos clicar neste. Nós vamos escrevê-lo de uma maneira agradável com balas. Então eu vou dizer que um usuário pousa no site e clica no botão de registro. Próximo ponto, registro. E não se preocupe com o conteúdo exato aqui. Quero dizer, esta é apenas uma maneira de escrever as coisas com base no aplicativo em que você está trabalhando ou de sua empresa projetar os critérios de aceitação pode variar, mas a idéia geral permanece a mesma. Queremos fornecer todos os detalhes, tanto quanto possível. E nós queremos ter certeza de que tudo é capturado aqui para que as pessoas são, não deixe nada para sua suposição porque você sabe, o que aconteceria é se amanhã um dos desenvolvedores recebe esta história e ele começa a trabalhar sobre ele, e se há algum ponto está faltando, então ele pode querer preencher as lacunas com com seu próprio entendimento das coisas. E então ele pode acabar projetando algo que o proprietário do produto não quer ou a empresa não quer. Então, queremos evitar situações como essa. E é por isso que vamos fornecer tudo aqui o máximo de detalhes possível. Agora, mais uma coisa, e eu estou dizendo isso enquanto eu estou digitando. Então, uma das coisas que eu particularmente enfatizo ao criar histórias de usuários é ter uma maquete. Então, como se você imaginar este caso particular, estamos tentando criar uma página de registro. Agora, podemos escrever todas as informações o máximo possível. Mas se colocarmos uma imagem aqui, mostra a página de registro com todos esses campos, então, você sabe, ajudaria a limpar as coisas mais facilmente. Lembre-se, uma imagem vale 1000 palavras. E se nós estamos fornecendo uma imagem aqui, então as pessoas seriam capazes de se relacionar mais com as coisas e eles entenderiam as coisas com detalhes completos. Então, escrevemos os critérios de aceitação e diz que o usuário pousa no site e clica no botão de registro. A página de registro deve conter esses campos. Então CVR claramente apontando o que todos os campos devem estar lá, certo? Se o endereço de e-mail já está em uso, estamos claramente dizendo qual é a mensagem de erro que queremos dar? Nós não estamos apenas saindo terminando escrevendo que mostram uma mensagem de erro. Não, estamos mesmo a dizer qual deve ser a mensagem de erro porque queremos que seja clara. Queremos que seja do jeito que queremos exatamente certo. E, em seguida, temos dado algumas regras para senha como eles devem estar entre 815 e conter número de letra é corretor espacial como este. E uma vez que o usuário fornece todos os detalhes e clica no botão enviar, eles devem ser levados para a página da minha conta. Então esta é a maneira de escrever os critérios de aceitação. Temos que ser o mais detalhados possível. E esta é a opção de navegação a partir da qual podemos anexar uma maquete. Ele mostrará que o design que é necessário e será de grande ajuda. E, finalmente, o que faremos se rolarmos para baixo, temos que anexar esta história de usuário para épico. Lembre-se épico é o nosso grande requisito e fazemos várias histórias de usuários para completar esse épico. Então, para esta história de usuário, temos que selecionar um Epic e esta história de usuário pertence aos épicos de conta. Então vamos criar a conta épica aqui. E eu vou clicar neste botão Criar. Então é isso, pessoal. Parabéns, criamos nosso primeiro usuário é história. E se vamos para este usuário é história, você vai ver que ele lista tudo, claro, balas claras e recuo. Então, cada um que vier aqui, ele verá as coisas claramente. Então é assim que funciona. Esse é o fluxo completo. E, de fato, vimos essa jornada desde o início. Vimos como os requisitos são criados, como eles são classificados em épicos e, em seguida, como esses épicos são convertidos em histórias de usuários. Então, se eu voltar para o nosso Excel, nós concluímos o processo one-off parte, que é obter os requisitos e converter para histórias de usuários. Agora o que vou fazer é criar histórias de usuários para todos esses requisitos que vimos. Vou introduzi-los no Gita para que possamos obter o que chamamos como um backlog de produtos, uma lista completa de nossos requisitos. Então deixe-me criar essas histórias e então eu vou vê-lo na próxima palestra para levar adiante nosso passo de ponta a ponta. Obrigado, pessoal. 39. Projeto prático - Implementação de Agile - Parte 2: Olá a todos e bem-vindos de volta. Então agora vamos olhar para esta parte, a parte dois, onde estaremos criando o backlog. Não estaríamos simulando as ações de aliciamento e planejamento de sprint. E nós estaríamos terminando com nosso backlog de sprint. Esse é o trabalho que temos de fazer em cada corrida. Então vamos voltar ao projeto. Então, se eu clicar no nome do projeto e entrar nele. À sua esquerda, você verá essas quatro primeiras opções, que é o que temos falado muito em nosso aprendizado até agora. Então nós temos o tabuleiro Scrum, que neste momento estaria vazio porque nós não configuramos totalmente as coisas e começamos nosso sprint. Voltaremos a isto mais tarde. Então temos o atraso. Então esse cara é o nosso atraso de produto. Falamos muito sobre isso. Nós continuamos dizendo que o backlog do produto de dados é uma lista completa de nossos requisitos. Então é aqui que está. E eu criei a história do usuário para todos os requisitos que tínhamos em nosso Excel. E assim você pode ver todas essas histórias estão sentadas no Backlog. Esta é a lista completa de requisitos que tivemos que fazer. E você pode ver todos esses requisitos estão ligados ao épico também. Então, como em sua empresa, se Conta é uma equipe, então sabemos que ok, são a contabilidade tem que cuidar de todas essas mudanças. Se pesquisas e outra equipe, em seguida, apenas olhando aqui, podemos dizer que ok, equipe de busca tem que cuidar de todas essas coisas ou estes pertencem à funcionalidade de pesquisa. Então esse é o benefício de ter épicos que sabemos de qual área ele está vindo e qual i funcionalidade específica, essas coisas ligadas à direita? Agora deixe-me fechar esta seção para que tenhamos mais espaço. E então pessoal, nós temos todas essas 23 histórias de uso que estão no seu backlog. Agora estamos prontos para começar com o próximo passo. Então é aqui que vamos fazer a nossa primeira cerimônia HI é, a preparação de backlog. Então vamos abrir esta primeira história de usuário que irá criá-la que nós escrevemos com os critérios de aceitação. Então, o doador do produto ou o Mestre Scrum vai abrir esta história do usuário e o proprietário do produto vai ler os critérios de descrição e aceitação, o que tudo o que ele quer ser feito na história. Ele mostrará se houver uma maquete, que mais uma vez, recomendo fortemente para mudanças desse tipo porque esclarecerá as coisas. O proprietário do produto irá explicar todos estes detalhes e irá mostrar-lhes maquete. Agora que a equipe vai tentar entender esses requisitos e se eles têm alguma dúvida, eles vão perguntar como, qual é o comprimento deste campo nome aqui? Qual é o comprimento deste campo Sobrenome, etc.? Porque lembre-se, queremos mencionar claramente cada detalhe. Assim, o proprietário do produto vai responder toda a dívida e ele também irá adicionar esses detalhes para a história. Então, vamos adicioná-lo aqui. Então, digamos que o primeiro nome deve ser de 30 caracteres. O sobrenome deve ter um DAT de 30 caracteres, certo? Porque lembre-se que a idéia é que queremos capturar todas essas coisas o mais detalhado possível. Não queremos que um desenvolvedor crie o primeiro nome com apenas dez campos porque esse foi o processo de pensamento. Não, queremos que seja exatamente como precisamos. Então vamos mencionar tudo aqui e é bom documentar tudo porque lembre-se, ninguém vai se lembrar de tudo isso mais tarde. Então é melhor documentá-lo agora para que ele serve como uma referência para mais tarde também. Então esta foi a resposta da pergunta para baixo vai continuar e as pessoas vão fazer pergunta, a equipe de desenvolvimento vai fazer pergunta. O proprietário do produto responderá todas essas coisas. E uma vez feito isso, uma vez que cada pergunta foi respondida, uma vez que todos os pontos são esclarecidos, chegamos à parte muito importante da estimativa. Certo, então vamos dizer que essa equipe está sentada assim e o proprietário do produto aqui abre a história nesta tela, ele lê os critérios de aceitação, responde a qualquer pergunta que essa equipe tem. Tudo isso acontece agora, todos os dados da equipe estão sentados aqui, a equipe de desenvolvimento, exceto o proprietário do produto e o Scrum Master. Toda esta equipa de desenvolvimento terá cartas como esta que vimos. Então estes são cartões simples com o número 13581321, a série Fibonacci. Então estas não são nada além de todas as opções de ponto de história. E entregamos a cada um dos membros dessa equipe de desenvolvimento um conjunto desses cartões para que eles possam apontar uma história. E o que vai acontecer é que na contagem de 123, todos eles vão levantar uma carta com o seu ponto de estimativa. Então, digamos que para esta história, todos levantam uma mentira e ignoram meus maus guias de habilidades de desenho. Não sou muito bom no Photoshop. Então todos na equipe levantem o cartão com cinco. Toda a gente diz isso, está bem, esta é a nossa história de utilizador. Os pontos da história são cinco, todos concordam com dívidas. E então estamos bem para a história e vamos prosseguir com o próximo. Então este é o caminho feliz onde todos concordaram em um ponto comum. Agora vamos dizer que há um conflito. Todos aqui apontaram cinco, mas esse cara aqui, ele apontou isso como um oito. Então, o que acontece agora? Lembre-se, não podemos dizer que, já que a maioria dos caras aponta para cinco, vamos com cinco. Não, temos que chegar a um consenso. O exercício de poker de planejamento é impulsionado por consenso. Todo mundo tem que ser ouvido, todo mundo tem uma voz. Então o mestre do scrum ou proprietário do produto vai perguntar a esse cara por que ele acha que é um oito. E então ele vai explicar seu processo de pensamento e pode ser como algo que outros não pensaram. E assim a equipe vai recompensar com base nesta nova informação e talvez todos agora votem como ajuda porque eles não poderiam pensar em algo mais cedo que o céu apontou. E nesse caso também haveria um consenso ou o proprietário do produto e a equipe vai limpar esses caras dúvidas que tinha apontado em 08. E com base nessa nova informação, ele aceitará como um 5. Então todo mundo está apontando como um cinco. Temos um consenso. E assim, neste caso, o ponto da história será finalizado como cinco. Então podemos voltar para a história e podemos adicionar um ponto de história como cinco. Então esta história é estimada como um cinco e é assim que os caras a estimativa vai acontecer. E, idealmente, devemos fazê-lo durante a preparação do atraso. Algumas equipes fazem isso durante o planejamento de sprint, mas isso não é o ideal. A preparação do backlog é o melhor, desculpe, dinheiro para isso. Agora, deixe-me voltar ao backlog e você vê que se eu atualizá-lo, ele vai começar a mostrar esses cinco pontos aqui. Então esses pontos são app, mas agora sabemos quais são os pontos da história para a história mais rápida. Agora deixe-me pausar este vídeo e atualizar os pontos da história para mais algumas histórias também. Ok pessoal, então eu namorei o ponto da história para os próximos 60 andares, e isso é coletivamente 42 pontos. E vamos supor que os dados são a velocidade da nossa equipe. Analisamos os dados para os últimos três rodadas e descobrimos que ocorre em algum lugar em torno de 40 a 45 pontos é a estimativa ideal para esta equipe. Então vamos parar aqui. Fizemos preparação suficiente para estarmos preparados para o próximo sprint. Agora, se a equipe quiser e se tiver tempo, eles podem preparar a próxima ou duas histórias para o futuro. Caso contrário, estamos. É bom começar com o próximo sprint. Temos material suficiente para começar com o próximo sprint quando chegar a hora. Então, agora que temos um backlog priorizado e estimado, vamos avançar para a cerimônia de planejamento de sprint. Agora chegará o dia em que teremos que começar com o próximo papel de jornal. Então, vamos clicar neste botão Criar Sprint. E este é um muito sprint. E então o que vamos fazer é puxar as histórias apontadas para ele então nós apenas temos que arrastá-lo e soltá-lo. Então vocês se lembram até agora que viram em nossa jornada o quanto JIRA está nos ajudando a fazer todas essas tarefas. E essa é a razão pela qual a JNI é uma das ferramentas mais populares nas indústrias hoje em dia e é usada por todas as empresas que querem, você sabe, dados usando um GI elites, uma das ferramentas mais úteis para a gestão de produtos, HI EL desenvolvimento de gestão, todas essas coisas. E é muito popular na indústria hoje. Então vamos arrastar essas primeiras sete histórias para o sprint porque este é o trabalho que vamos levar para o sprint. Por isso, aguente comigo enquanto faço isso. Ok, então nós mudamos todos esses 70 andares e, você sabe, dentro dos sete também, se nós quisermos, nós podemos mudar a ordem deles dependendo da prioridade. Portanto, este produto backlog é uma lista priorizada de requisitos. E dentro do Sprint também, devemos manter as histórias na lista da prioridade porque a equipe vai começar a trabalhar a partir da história mais rápida. E essa deve ser a nossa ordem prioritária. Se eles não têm tempo suficiente, dia surdo pode não ser capaz de completar este. Então vamos continuar pensando em ordem prioritária aqui. Então nós puxamos um 70 andares em um sprint. Agora que a equipe vai entrar em um planejamento de sprint, eles vão rever as histórias novamente um por um. Eles vão recapitular rapidamente e, em seguida, eles vão atribuir tarefas. Então vamos fazer isso. Esta é a nossa primeira história que criamos onde escrevemos os critérios de aceitação. E também este está no topo do nosso sprint backlog. Então vamos criar a subtarefa dentro dela. Então eu vou criar várias sub-tarefas como deixe-me criar uma para o desenvolvimento da interface do usuário, certo? E, em seguida, outro para desenvolvimento Java, projeto de caso de teste, execução de caso de teste e, finalmente, UAT e etc. Então, este é apenas um exemplo. Estou a criá-la com base nas minhas lógicas. Você pode criar tarefa de acordo com as normas em sua organização. Mas lembre-se, novamente, a idéia é mantê-los detalhados. Como se uma pessoa vai estar fazendo desenvolvimento de UI e outra pessoa vai estar fazendo desenvolvimento Java, então nós não queremos criar uma tarefa para o desenvolvimento. Queremos separá-lo para que todos saibam quem ele é encarregado, que trabalho e quem está fazendo o quê. Nós podemos acompanhar o seu progresso, etc Então esta é a maneira que vamos criar subtarefa. E se eu entrar nessa tarefa do Foster, vamos atribuí-la ao desenvolvedor. Seja qual for o membro da equipa de desenvolvimento, está a trabalhar nisto. E também adicionaremos a estimativa da média a esse cara. Então lembre-se, Sprint Planning, além de puxar as histórias também envolve mais duas tarefas. Primeiro é a tarefa, então temos que atribuir a tarefa a quem está fazendo isso. E a segunda é que temos que estimar suas horas para isso. Então isso nos ajudará a determinar a capacidade geral. Então, digamos que para esta tarefa, este tipo está a demorar cinco horas, certo? Então vamos puxar, colocar dados aqui. E essa é a sua estimativa, a estimativa de tempo para completar esta tarefa. E é isso pessoal, essa tarefa e nossas tarefas feitas. Agora, mais uma vez, deixe-me pausar o vídeo e fazer a mesma coisa para todas as histórias. Ok, então agora eu terminei a tarefa de todas essas histórias e estamos prontos para começar nosso sprint com essas 70 histórias. Lembrem-se que quando estamos pegando essas histórias, ficamos de olho em seus pontos e nossa velocidade. Então nossa velocidade para os últimos três sprints foi, digamos, uma média de 45. Então decidimos manter nossos pontos de história ainda 42. Então nós temos que, nós temos que estar cientes de nossa velocidade e não superá-lo, não exceder o que temos sido capazes de fazer nos últimos três sprints. E ao mesmo tempo, vimos que quando criamos tarefas, adicionamos horas dentro delas. Então, com base nisso, o nosso, seríamos capazes de compará-lo com a capacidade dessa equipe. E novamente, certifique-se de que não estamos nos comprometendo demais. Então estes são dois aspectos que temos que considerar durante um planejamento de sprint como vimos em teoria, velocidade e capacidade. E isso nos ajudaria a evitar o excesso de compromisso que, como ele, iria garantir que nós não estamos levando mais do que as 70 histórias que nós poderíamos idealmente ser capazes de completar. Ok, então terminamos tudo. Estamos fartos de puxar a história é tarefa, colocar em horas, etc. Então, vamos clicar no botão Iniciar é Sprint e vamos começar o nosso Sprint mais rápido. E vamos manter esse sprint de duas semanas. Há uma opção para selecionar quantas semanas quiser ou há uma opção Personalizada, mas vamos ficar com duas semanas. E vamos começar a partir dele hoje e então deixe-me clicar em começar. E como você pode ver, nosso sprint foi criado com sucesso. Gita criou tudo e colocou no nosso, no nosso tabuleiro Scrum. Então este é o nosso barco Scrum. E como você pode ver, ele lista todas as histórias que tínhamos tomado em índices imprimir todas as 70 histórias juntamente com toda a sua tarefa que é atribuída a qualquer membro da equipe estaria fazendo isso. Então este é cada barco de sprint, este é o nosso sprint backlog, o trabalho que vamos fazer neste sprint. E com base nisso, sabemos o que estaríamos trabalhando nas próximas duas semanas. Tudo bem caras. Então, se eu voltar para o nosso Excel, nós terminamos esta parte. Criamos com sucesso uma lista de pendências. Nós assimilamos com sucesso a cerimônia de preparação de backlog e um planejamento de sprint. Vimos como estimamos as coisas, como retiramos as cartas. Criamos tarefas para diferentes histórias. Colocamos o nosso neles, criamos nosso próprio backlog de sprint, e finalmente começamos o sprint. Então agora estamos em um sprint. Vamos passar para o próximo capítulo e vamos simular que ativistas Imprimir tanque Período. Vocês, rapazes. 40. Projeto prático - Implementação de Agile - Parte 3: Olá a todos e bem-vindos de volta. Então este é o nosso sprint backlog caras que nós criamos em nosso último capítulo. Então este é o nosso trabalho para as próximas duas semanas e todos se mudaram assim que o sprint começar, todos começarão a trabalhar na tarefa que lhes foi atribuída. E também agora que estamos no sprint, lembre-se que temos que fazer um stand up diário todas as manhãs. Então todas as manhãs a equipe vai se reunir para um stand up como este. Agora lembre-se que eles estão fazendo este stand-up com este barco físico. Temos um modo virtual. Então, se quisermos, podemos fazer da mesma maneira usando uma tela com o quadro virtual abertamente, como esses caras estão fazendo com um quadro físico. Mas a ideia é a mesma. Todos devem atualizar seu status de tarefa antes de se levantarem. Assim como o desenvolvimento da interface do usuário para a primeira história como começou. Então vamos movê-lo para o progresso. criação do caso de teste para a primeira história acabou de começar. Então vamos movê-lo para o progresso. Então esta é a equipe odontológica em massa, idealmente, deveria fazer antes que eles se levantem e se levantem, eles sempre ficarão em um círculo como este ao lado da placa física ou do modo virtual, o que quer que seja. E eles vão responder seu status em três perguntas. Primeiro, o que eu fiz ontem? O que vou fazer hoje? E qualquer bloqueador seduz os caras do formato padrão de ouro, essas três perguntas, vai ser uma reunião rápida de 15 minutos todos os dias e então todo mundo volta para o seu trabalho e isso continua acontecendo todos os dias. Então eles correm, estão correndo, todo mundo está fazendo o trabalho que lhes foi atribuído. Eles estão atualizando sua tarefa. Eles estão assistindo ao stand-up e assim por diante. Agora vamos considerar ponto para isso é realmente o desenvolvimento da interface do usuário está fechado, então vamos mover isso para feito. O design do caso de teste também é fechado enquanto movê-lo para concluído. Uma vez que o desenvolvimento tenha acontecido. Vamos tirar esse cara também. Assim, uma vez que o desenvolvimento aconteceu no teste começará, o teste também será concluído. Em seguida, uma vez concluído o teste, o UAT também será iniciado e concluído. Então agora tudo dentro disto são histórias concluídas. Então agora nós vamos, JIRA vai dizer que, ok, você completou toda a tarefa dentro dele. Você quer atualizar a história. Então deixe-me clicar na atualização. E como você pode ver, esta história vai passar de em progresso para o fim. Por isso, concluímos o nosso primeiro trabalho no Sprint. Completamos nosso primeiro material de entrega, nossa história mais rápida. E da mesma forma, a equipe também estaria trabalhando em paralelo em todas essas coisas. E eles estariam atualizando sua tarefa. Eles estariam entregando esse status no stand-up e eles estariam fechando as coisas. E lembre-se, a mesma coisa seria feita para os defeitos também, os defeitos também seriam atribuídos a membros individuais da equipe. Estariam a trabalhar nesses defeitos, movendo-os para diferentes colunas de estado de doença que estamos a ver e estariam a fechá-lo. Então é assim que eles correm. Vamos trabalhar, é assim que o sprint vai progredir. E outra coisa que você deve notar é que enquanto estamos neste sprint um, nós também temos que fazer a preparação backlog para Sprint dois. Então, dois ou três dias antes do sprint um terminar, vamos fazer a preparação do backlog para o próximo sprint. Então, toda a sequência de eventos que vimos até agora, vamos repetir, vamos rever o backlog do produto. Vamos priorizar essas histórias. Vamos rever as histórias. Então nós somos puxados para o sprint 1 terço próximo planejamento sprint vem e todas essas fontes disso, como eu disse, um Sprint é um scrum não é iteração de tarefa. Então, continuamos repetindo esses ciclos iterativos de novo e de novo, e continuamos entregando novos incrementos ao usuário. Agora lembre-se se você clicar nesta coisa e você verá uma opção aqui para relatórios. Então, se você clicar nesses relatórios, você verá que diferentes métricas ou relatórios sobre os quais falamos. Então você tem o gráfico de queimaduras. Você tem o gráfico de queimaduras. Eu apresento o relatório de velocidade de tudo o pão que vimos. E esses gráficos não vão preencher corretamente para mim porque lembre-se, eu apenas criei o sprint alguns minutos atrás e eu estou vindo para vê-lo hoje para que ele não vai preencher para mim. Como você pode ver, não é a linha ideal está lá, mas não há nenhuma linha de conclusão porque nós apenas começou o sprint alguns minutos atrás. Mas você pode tentar por conta própria. Você pode tentar criar um sprint claro primeiro, criar algum histórico, Epics, em seguida, cria algumas histórias com critérios de aceitação. Em seguida, crie um sprint a partir dele. E então você pode fechar algumas dessas histórias todos os dias e você pode ver esse gráfico se movendo de qualquer maneira, a idéia aqui era não mostrar esses relatórios. Nós já vimos isso. O que eu queria mostrar é que o JIRA está fornecendo a opção de visualizar esses relatórios e JIRA está criando esses relatórios automaticamente para você. Você não precisa fazer nenhum esforço manual para criar esses relatórios. E mais uma vez, esta é outra vantagem porque usamos JIRA tanto para projetos Agile e Scrum, certo pessoal, então este é o fluxo principal das coisas e nós cobrimos a maior parte das coisas e eu expliquei tudo de uma forma agradável e fácil e espero que você esteja claro em tudo. Então, se você vê o excel, nós cobrimos as três partes. Temos os requisitos iniciais. Criamos épicos para eles, criamos histórias de usuários, adicionamos critérios de aceitação. Então fizemos a preparação do backlog, nós priorizamos as histórias, revisamos, estimamos, nós os puxamos para a tarefa de sprint, eles, colocando nosso tipo eles, nós criamos uma Primavera, Sabíamos que seja qual for o atraso do sprint, o trabalho que temos que fazer nas próximas duas semanas. Depois fizemos o nosso trabalho no sprint, fizemos o stand diário. Nós movemos uma tarefa no quadro, fechamos as histórias, fechamos defeitos, vimos o gráfico de queimaduras, tudo isso era o fluxo primário das coisas. Isso foi um monte de coisas que vimos. A espero que você seja claro em tudo. Se não, você pode me fazer as perguntas se você tiver alguma. Então esta parte também está feita. Agora, vamos ver a última parte da última palestra. Obrigado, pessoal. 41. Projeto prático - Implementação de Agile - Parte 4: Olá a todos. Então, cobrimos muitos aspectos relacionados ao projeto de ponta a ponta nos capítulos passados. Agora, vamos ver se algumas últimas coisas nesta palestra. Vamos ver este calendário agradável que temos aqui. Então, como sabem, começamos nosso sprint de duas semanas aqui. Fizemos o planejamento da corrida. Temos o nosso trabalho para as próximas duas semanas e fizemos uma tarefa clara de quem vai fazer o que tudo estava claro no quadro, ninguém poderia mudá-lo. Li que o trabalho era visível para todos. Sabemos quem está fazendo o quê, se eles estão em andamento, se eles estão em blog, etc. Então as coisas são praticamente organizadas por conta própria. O trabalho está progredindo. Estamos a fazer as nossas provas diárias, et cetera, et cetera. E então, se você notar aqui, tudo está indo bem. E então bem aqui alguns dias antes do sprint terminar e temos que começar o próximo sprint. Estamos fazendo a preparação do backlog ou o refinamento do backlog. Agora podemos fazê-lo aqui, podemos fazê-lo aqui. Não há nenhuma regra difícil e rápida, mas queremos mantê-lo alguns dias antes de começar o próximo sprint. Porque lembre-se, se algo surgir nesta preparação pendente como um desconhecido ou risco, temos tempo suficiente para resolvê-lo antes do próximo sprint começar. E lembre-se que estes são os últimos dias da nossa corrida de corrida. Assim, as pessoas podem ter trabalho compilado append devolved para completá-lo antes do final deste spin. Não queremos ocupar o tempo de muitas pessoas nos últimos dois ou três dias. Então normalmente eu preferiria fazer o backlog grooming nesta quarta-feira ou quinta-feira máxima. Então vamos fazer isso aqui e então estaremos prontos para o próximo sprint. E então, como você vai ver nesta terça-feira, quando a corrente é sprint termina, estamos fazendo a revisão sprint ou demo. Estamos, estamos mostrando nosso trabalho a todas as partes interessadas. E também estamos fazendo a retrospectiva onde toda a equipe iria se reunir para analisar como este todo é impresso funciona, se eles têm alguma sugestão ou feedback, etc. E caras, se você notar, este é o beleza de todo o processo. Estamos fazendo essa demonstração e retrospectiva imediatamente no final do sprint. Então, uma vez que demonstramos o produto para as partes interessadas, estamos chegando lá feedback rápido e antecipado. E uma vez que estamos fazendo a retrospectiva, estamos recebendo as lições aprendidas desta corrente é sprint que podemos implementar no próximo sprint que vai começar no dia seguinte. Então essas duas cerimônias também estão feitas, e agora no dia seguinte vamos começar com um planejamento de sprint para o próximo sprint, sprint dois, nós já teremos o backlog do produto que finalizamos aqui nessa preparação. E semelhante ao que vimos, vamos pegar as histórias de acordo com nossa velocidade e capacidade. Vamos fazê-los, vamos colocar horas, etc., e este processo iterativo vai continuar. E uma última coisa, este calendário não menciona, mas em algum lugar teremos um lançamento também do produto dos incrementos que projetamos para que o usuário final possa usá-lo. E não há nenhuma regra fixa para definir a data de lançamento. Ele é finalizado na reunião de planejamento de lançamento, e isso pode ser feito como aqui ou aqui. Não há data fixa para oito. Depende do roteiro do produto, da demanda do cliente, custo, esforço, etc. Vimos todos esses tópicos e o capítulo de planejamento de lançamento. Então pessoal, esse era todo o aspecto prático de Agile e Scrum. Implementamos um projeto a partir do zero. Nós criamos as histórias de usuário é sprints, tarefa, et cetera. Nós fizemos as diferentes cerimônias ou Backlog Refinement, backlog grooming, Sprint Planning, retro demoed, levantar-se, todas essas coisas. Então, espero que você tenha entendido tudo claramente e agora esteja super confiante de tudo o que aprendemos. Então esta última parte também é completá-lo. Mas como você vê, nós cobrimos um monte de coisas neste capítulo. Então, se você tiver alguma dúvida, se você não estiver claro sobre nada, por favor, não hesite em usar o Q e uma opção ou você pode me deixar um e-mail aqui. Este é o meu endereço de e-mail e, como mencionei no passado, também, respondo proativamente a todos os e-mails dentro de 24 a 48 horas. Envie-me as perguntas que tiver e farei o meu melhor para respondê-las. Agora, antes de avançarmos para os próximos tópicos, mais uma pergunta do meu lado, pessoal, por favor deixem uma revisão do curso. Dificilmente levará dois minutos do seu tempo, mas sua classificação nos motivará ainda mais a criar um ótimo conteúdo como este para você. Tudo bem, então vamos seguir em frente. Nós completamos todos os nossos aprendizados em Scrum. Nós cobrimos as partes teóricas, nós cobrimos as partes práticas. Agora vamos dar uma olhada no aspecto de certificação no próximo capítulo. Obrigado. 42. Exames de certificação com dicas para Exams: Olá a todos e bem-vindos ao capítulo nove deste curso. Então, agora que vimos todos os aspectos do Scrum em teoria e prático, vamos falar sobre como usar esse conhecimento e obter uma certificação. Eu entendo que muitas pessoas que fazem este curso estariam interessadas em obter uma certificação também. Então vamos dar uma olhada nessa jornada. Vamos primeiro falar sobre quais outras certificações, como se inscrever e como fazer o exame. E então eu vou compartilhar algumas dicas que vão ajudá-lo a limpar isso. Portanto, existem duas certificações que são mais populares no Scrum. O primeiro é o mestre scrum certificado ou CSM. E o outro é 35 para Scrum produto doador ou CSP o. Se você é um iniciante em Scrum ou você está apenas olhando para obter uma certificação para o seu conhecimento de sua migalha, então eu vou sugerir que você vá para o CSM um. E se você já está na linha de negócios como um analista de negócios pode estar, você pode fazer o curso de proprietário do produto. Depende da sua linha de trabalho, seus planos futuros, etc. Mas sugiro que comece com o CSM. Então, nesta palestra vamos falar sobre o curso CSM. Você pode ler mais sobre CSP também, o processo não é muito diferente. Então vamos para o site deles, que está na tela e ver detalhes. Lembre-se se você estiver fazendo este curso mais tarde, as coisas que eu falo aqui podem mudar um pouco. E é por isso que estou apontando para você para o site também porque isso sempre permanecerá atualizado. Então esta é a página de certificação. E se você rolar para baixo, você pode ver as várias jornadas de aprendizagem aqui na pista mestre Scrum. Temos o certificado Scrum Master Advanced Certified é Scrum master certificado scrum profissionalmente Scrum Master, como também no produto não rastrear. Nós também temos alguns cursos e na pista desenvolvedor também temos alguns cursos. Eu não recomendei cursos em pista de desenvolvedor. Se você é um desenvolvedor e se você quer aprender é migalha para o seu próprio aprendizado pessoal ou profissional, em seguida, basta ir para o curso CSM que é o melhor se você é um produto, se você é intruso linha de negócios como um analista de negócios e você quer se tornar um proprietário do produto, você provavelmente pode fora para este curso certificado proprietário do produto Scrum. Mas para a maioria das pessoas, os tribunais de mestre de scrum certificados seriam os melhores. Então, vamos clicar neste link master scrum certificado e ele abrirá algo assim. Assim, nesta página você pode ver todos os detalhes e se você rolar para baixo, você pode ver os requisitos para dar o exame. Há um pré-requisito para dar esses exames e dados CSM que você precisa participar de um curso on-line ou presencial antes de fazer o exame. Isso é como um workshop e é obrigatório e não se preocupe, não há taxas extras para ele. Já faz parte das taxas de exame e irá ajudá-lo também porque será uma espécie de revisão para você o que você já aprendeu neste curso. Agora, uma vez que você terminar com este workshop, você pode fazer o exame e haveria como 50 perguntas e você tem que obter pelo menos 37, correto. E o limite de tempo é de 60 minutos. E confiem em mim, esta é uma regra muito relaxada. O exame CSM é muito, muito simples. E se você seguiu este curso completamente, se você vai revisar as coisas na oficina, você vai limpá-lo muito facilmente, apenas esteja preparado. É muito simples. Agora, se você rolar para baixo e se você clicar neste botão Finder Course, ele irá levá-lo para a página de detalhes do workshop com base no seu país. E você pode ver os locais, datas, treinadores, etc., com base em sua localização. Então eu recomendo que você pode fazer alguma pesquisa na linha quatro com base nos detalhes do curso, horários, treinadores, etc, o que mais lhe convier, você pode ler sobre o local também. Então, no meu caso, tudo se você vê sua exibição on-line apenas porque estamos no tempo COBIT, então as coisas estão fechadas. Mas uma vez que as coisas estão normais, IV e oficinas abrem para interação presencial. Eu vou sugerir que você vá para uma aula presencial só que é mais interativo e vai ajudá-lo mais melhor. Então você pode clicar no link Registrar para qualquer um dos cursos que mais lhe convier. E abrirá uma página como esta com os detalhes mais finos. E uma vez que você clicar nesta caixa, ele lhe dará os detalhes para fazer o pagamento. Então, apenas aqui e depois de fazer o pagamento, você receberá um e-mail de boas-vindas. Você pode fazer o workshop, você pode, uma vez que você completar o workshop, você receberá outro e-mail que irá conter os detalhes para dar o exame tão simples quanto isso. Lembre-se, o único pré-requisito é que você tem que participar deste workshop antes de poder fazer o exame. E eu acho que é uma coisa muito boa também, você tem dois, interagir com outro campo de software profissional. Você começa a revisar as coisas rapidamente e então você pode fazer o exame com base nesse conhecimento atual. E, na verdade, tudo isso e mais informações está apresentando sua página FAQ também. Então, se você for para a página inicial, role todo o caminho para baixo e clique nesta FAQ. Vai abrir algo assim. E agora você tem que clicar nesta caixa Questões de Certificação aqui. E você obterá os detalhes completos sobre um mestre scrum certificado e exame CSP. As perguntas mais frequentes, navegei em todo o site para obter as melhores informações. E eu achei esta página de perguntas frequentes muito agradável. Então, se você clicar nisso primeiro, como posso me tornar um mestre de scrum certificado? Vai levar-te a uma página como esta. E nas duas primeiras perguntas aqui você pode encontrar praticamente todas as informações que você gostaria de saber. Quero saber. Eu já falei sobre isso, mas ainda é se você quiser lê-lo, essas duas primeiras perguntas terão todas as informações. Além disso, você pode clicar sobre isso. O que posso, posso esperar da pergunta de teste CSM e ler os detalhes sobre o exame. Como eu disse, é um exame de 60 minutos com 50 perguntas de múltipla escolha e você tem que responder pelo menos 74% correto. E é um teste online. Você pode dá-lo de qualquer lugar que você quiser. Então é isso. Esses são todos os detalhes que você precisará saber sobre o exame CSM. E o mais importante, lembre-se, como eu disse, é um exame muito simples. Você será capaz de limpá-lo muito facilmente com os aprendizados deste curso e uma revisão que você receberá no workshop. Tudo bem, então agora que sabemos sobre o exame, vamos voltar e ver algumas viagens, dicas para quebrar este exame. Então o primeiro é ler o Guia Scrum antes de fazer o exame. Então, se você for ao site, vamos fazer isso de novo. Então eu fui para o site deles, que é um scrum Alliance.org, e eu clico sobre esses recursos e clique neste e-books. E disfarce. Aqui está o Guia Scrum. Então você pode clicar nele e você pode baixar o PDF. São apenas 19 páginas e você pode tirar uma impressão dela e manter uma cópia durante o exame. Este é o link de download para obtê-lo. Próximo ponto, fazer algum teste simulado antes do exame para que você possa descobrir um monte de teste simulado on-line, apenas Google para ele e passar por um par deles. Isso irá ajudá-lo a praticar. Ele irá dizer-lhe MOOC algumas perguntas comuns também que você pode preparar. Terceiro, quando você está aparecendo para o exame, um dos problemas comuns que todas as respostas podem parecer semelhantes. Portanto, certifique-se de ler todas as respostas cuidadosamente e, em seguida selecionar uma opção que questionários que você fez no curso. Estamos em linhas semelhantes para lhe dar uma ideia de como foi o exame. Então, isso irá ajudá-lo até certo ponto. Mas lembre-se, sempre certifique-se de que você está lendo todas as respostas cuidadosamente e dez, selecionando uma opção. Próximo ponto que você pode, você pode usar as regras de eliminação, então elimine a resposta errada primeiro. Isso ajudará você a descartar algumas opções e, em seguida, identificar a resposta correta. Quinto, ser paciente é manter o conhecimento dos fatos. Como eu disse, o exame é muito simples. Nós já aprendemos um monte de coisas para ele no curso, e você terá uma atualização no workshop também. Portanto, seja paciente, confiante e fique com o que aprendeu. 6, reveja as perguntas antes de onde você tem uma dúvida para que você possa manter as respostas onde você tiver uma dúvida e voltar para elas mais tarde. Isso ajudará você a economizar tempo. E, finalmente, antes de submeter o exame, certifique-se de ter respondido a todas as perguntas. Portanto, verifique rapidamente se todas as perguntas estão marcadas como respondidas antes de terminar as coisas. Então é isso, pessoal. Esses foram alguns dos truques para ajudar com o exame de certificação CSM. E deixe-me repetir pela última vez. Se você fizer este curso cuidadosamente, se você revisar as coisas na oficina e aparecer para o exame com confiança, é muito, muito simples e você será capaz de limpá-lo muito facilmente tudo de melhor. Tudo bem, então com isso, chegamos ao fim do capítulo. Vamos passar para a próxima e aprender sobre as perguntas da entrevista. Obrigado. 43. Dicas de entrevista: Olá a todos e bem-vindos ao último capítulo deste curso. Vamos falar sobre algumas dicas rápidas que ajudarão você a limpar qualquer entrevista, seja para um papel relacionado ao HIV ou, em geral, qualquer perfil. Eu incluí esta seção no curso porque acredito que o objetivo de nós em aprender algo novo é melhorar nosso perfil de operadora e em algum momento ou o outro traduzido em um emprego melhor. Então é aí que esta seção será útil para você. E na mesma linha, incluí cerca 13 perguntas de entrevista na seção de recursos capítulos. Você pode lê-los antes de qualquer entrevista e revisar rapidamente as coisas. Então, vamos começar. Então pessoal, digamos que nos candidatamos a um emprego e agora temos que ir para uma entrevista. Então, como podemos nos preparar para o dat? Vamos ver algumas regras de ouro. Em primeiro lugar, esteja bem preparado e preparado. Então vestir-se profissionalmente, se houver um código de vestimenta necessário seguido no LC, Você pode vestir-se em qualquer coisa que é profissional e, em seguida, ir para a entrevista totalmente preparado para não apenas aparecer por causa disso. Segundo, fazer uma pesquisa sobre a empresa, o perfil do trabalho, etc. É bom saber para onde você está indo. O entrevistador também pode perguntar se você sabe sobre a empresa, então faça sua lição de casa. Terceiro, comportar-se, preparar as questões comportamentais. Então a primeira pergunta que eles fazem em qualquer entrevista é sempre me fale sobre você ou me explique seu perfil. Então prepare uma boa resposta para isso. Algo que fala sobre quem você é, seus detalhes educacionais, sua experiência de trabalho, suas habilidades técnicas, quaisquer prêmios notáveis de projetos, reconhecimentos, etc. Nos meus dias iniciais, eu costumava ter uma resposta escrita para isso para que eu pudesse ser preparado. Você também pode fazer isso. Mas se você fizer isso, apenas certifique-se de que você não soar como se tivesse bagunçado a resposta, diga as coisas em seu tom regular. E, além disso, há outras questões comportamentais também como, qual é a sua expectativa? Você é um jogador de equipe? Todo esse tipo de coisas. Então você pode encontrar a lista completa na internet. A idéia é que se prepare para essas questões comportamentais também, e não apenas as técnicas. Em quarto lugar, esteja pronto para falar sobre cada processo em sua empresa. Então, quando eu estou fazendo entrevistas, eu peço às pessoas para explicar o processo ágil e completar a jornada em sua empresa. Então prepare algo nas mesmas linhas. Como você obtém os requisitos? Como você faz as cerimônias, como você estima os pontos da história dele, como você gerencia o conselho de HL, todas essas coisas. Próxima e muito importante resposta claramente, então respondido de forma direta e precisa, você pode usar exemplos para complementar sua resposta. É sempre útil acompanhar os exemplos. Você pode dar exemplos de qualquer coisa semelhante que você fez em n, em sua empresa atual ou em outro lugar. 6 você não lutar. Ser mente aberta, ouvir o entrevistador e manter as coisas educadas. Próximo ponto e novamente, muito importante. Se você não sabe a resposta, diga que honestamente, há ninguém no mundo que sabe tudo, Então, permaneça honesto e passe a pergunta. Não tente blefar o entrevistador. Você vai ser pego com certeza e não seria bom. Segundo último ponto em qualquer entrevista, o entrevistador perguntará no final se você tiver alguma dúvida. Então use essa oportunidade para perguntar qualquer coisa sobre o perfil de trabalho, a empresa , etc., que você queira saber que também mostrará seu interesse no trabalho. Você pode pedir ao entrevistador seu feedback geral sobre você se eles podem fornecer qualquer, mas não discutir sobre os aspectos salariais lá que virá em uma fase posterior. E finalmente o último ponto b, confiança. Portanto, esteja preparado, seja otimista, responda tudo com confiança e espero que o resultado seja bom. Então, pessoal, estas foram algumas dicas importantes para entrevistas. Agora você também encontrará uma lista de 13 perguntas de entrevista anexadas a este capítulo, que eu criei cuidadosamente para cobrir diferentes aspectos da AGI e Scrum. Certifique-se de passar por eles, revisá-los antes de qualquer entrevista. E papai, combinado com o aprendizado deste curso, as dicas aqui devem ajudá-lo a navegar através de qualquer entrevista. Desejo a todos os melhores caras com isso, chegamos ao final deste curso. É realmente emocionante pensar em tudo o que aprendemos nesta jornada. Começamos com as deficiências da abordagem tradicional e por que uma criança entrou em cena. Falamos sobre os principais conceitos e definições de Agile e Scrum. Vimos os papéis Scrum é cerimônias migalhas, é Artefatos Scrum, relatórios de planejamento e estimativa, certificação, entrevista, muitas coisas. E também fizemos um projeto com implementação prática para que você tenha uma compreensão prática de como as coisas funcionam no mundo real. Então, foi de fato uma grande jornada. E espero que este curso tenha ajudado em seu objetivo de aprender sobre Agile e Scrum. Mais uma vez, gostaria de reiterar dois pontos que referi também no início do capítulo. Primeiro, HL não é apenas uma metodologia mais importante, é uma mentalidade. Temos que ser um gigante em nossos pensamentos, nosso trabalho, nossa colaboração com sua equipe. Só então podemos implementar com sucesso um gel ou um Scrum. Então mantenha que sua mentalidade sempre largura você. Segundo, Oi Lori. Scrum não é uma vara mágica que irá resolver todos os seus problemas. Isso nos mostrará quais são os problemas ou quais foram os problemas com a indústria. E cabe a nós levar a mentalidade HL, trabalhar juntos como uma equipe e entregar produtos excepcionais. Então, o usuário final. Tudo bem, então estamos no final do curso, mas lembre-se ao se inscrever neste curso, você tem direito a facilidade de suporte de consulta vitalícia. Então, se você tiver alguma dúvida, feedback, se você quiser falar sobre algo em sua organização, como ele funcionou, e se você tiver alguma confusão, não hesite em me enviar um e-mail, meus IDs de e-mail na tela, e respondo prontamente aos alimentos em 24 a 48 horas. Agora, antes de terminar, uma última pergunta do meu site, por favor, poupe alguns momentos para rever este curso e dar-nos uma classificação. Seu feedback é muito importante para nós e nos ajuda a criar conteúdo excepcional para nossos alunos. Mais uma vez, pessoal, muito obrigado por escolherem este curso e desejo-lhes o melhor em sua jornada de aprendizagem. Obrigado.