Scrum Agile: como usar o Scrum FW como proprietário de produtos?

1. Introdução e agenda: Olá, bem-vindo ao curso. Neste curso, você aprenderá como desempenhar o papel de proprietário do produto no framework Scrum. Meu nome é Melissa, e eu vou te guiar neste curso. Tenho mais de 17 anos de experiência, onde desempenhei muitos papéis como Scrum, Master, gerente de projetos, proprietário de produto e arquiteto. Este curso foi desenvolvido para os novos aspirantes a proprietários de produtos que desejam construir uma forte compreensão do papel do proprietário do produto nesta estrutura básica. Então, sem mais delongas, vamos começar. 2. Por que é necessário papel do proprietário do produto?: Se você está apenas começando com os papéis de proprietário do produto ou está aspirando pela regra de proprietário do produto. Tenho quase certeza de que você terá essa pergunta. Por que o papel do proprietário do produto está em demanda? Eu vou te guiar por isso. A primeira é que o ambiente de negócios desafiador precisa de maior eficiência e produtividade. Não podemos negar isso, certo? Todas as organizações agora estão buscando maior eficiência e produtividade da mesma equipe, certo? Então, como fazer isso? O primeiro passo para essa equipe mais fácil, menor e auto-organizada. E essa é a necessidade da hora. Precisamos de uma equipe menor o suficiente e auto-organizada para entregar o produto a tempo, bem como gerenciar a agilidade do ambiente de negócios, certo? É disso que precisamos. Então, a próxima pergunta e uma pergunta-chave vem como fazer isso? E aí vem a estrutura do Scrum. O Scrum fornece uma estrutura comprovada para adotar a agilidade do ambiente de negócios, bem como entregou o produto com uma equipe pequena e auto-organizada. E o proprietário do produto é a única função a impulsionar o desenvolvimento e a entrega do produto de acordo com a necessidade do cliente junto com a equipe. Eu só quero repetir a frase, o proprietário do produto é o único papel para impulsionar o desenvolvimento e a entrega do produto , eu identifico a necessidade do cliente. Então, agora você pode entender o quão crítico é o papel de um proprietário de produto para o sucesso de uma organização neste ambiente de negócios desafiador e azídico, certo? Então, isso é tudo para esta palestra. Na próxima palestra, veremos como está o mercado de trabalho para os proprietários do produto. 3. Como é o mercado de trabalho para o proprietário do produto?: Sem rodeios, irei diretamente para o aspecto salarial porque sei que quando planejamos mudar para uma função específica, salário também é um dos fatores mais importantes que consideramos, certo? Então, vamos pular nisso. Assim, quanto ao site Glassdoor, você pode ver essas estatísticas de que, na Índia o salário médio de um proprietário de produto é de cerca de 20 lakhs. E pode variar até 30 lakhs. Na Índia. É um salário muito bom para viver uma vida confortável, certo? Então eu tirei outra estatística para os Estados Unidos. E aqui o salário médio é cerca de 94 mil dólares americanos. E, novamente, é uma boa salada para viver uma vida confortável, certo? Então, isso é sobre uma parte sólida. Então. Agora vamos dar uma olhada nas oportunidades de emprego. Nesta captura de tela, você pode ver que só nos Estados Unidos, existem 50 mil empregos para o papel dos proprietários do produto. Na Índia, são cerca de 4 mil. Isso é apenas do site do cluster. Se você olhar para o LinkedIn ou Indeed ou qualquer outro site de emprego, acho que você será capaz de encontrar mais e mais oportunidades de emprego corretamente. Agora, você está bem claro que papel de proprietário do produto y dot é necessário. O que há para a organização nessa função e o que há para você na loja. Certo? Porque não entendemos a parte do porquê de nada. Eu acredito que você não poderia continuar com isso. Você não pode dar todo o esforço para isso, certo. Portanto, minha intenção era deixar claro que esse papel tem algo muito interessante e empolgante para você e para a organização. E esse é um bom papel a ser seguido. Então, vamos ter isso em mente e passar para a próxima aula para ver quem é realmente um próton. 4. Quem é um proprietário de produtos?: Oi. Nesta palestra, vamos discutir um barco que é proprietário de um produto. Antes de entrarmos em detalhes sobre a função de proprietário do produto, vamos entender quem é o proprietário do produto. Conforme descrito no Guia Scrum, proprietário do produto Chrome é responsável por maximizar o valor do produto resultante do trabalho da equipe de desenvolvimento. E como isso é feito pode variar muito entre organizações, equipes Scrum e indivíduos. Ok, vamos entrar em detalhes sobre isso. Então, quando pensamos no proprietário do produto ou em qualquer pensador da organização, proprietário do produto, eles só pensam em duas coisas. Uma pessoa ou uma função que pode maximizar o valor do trabalho da equipe de desenvolvimento. Ok, então essas são as principais coisas você deve entender quando pensa em um meio de proprietário de produto como seu papel, você só pode pensar em maximizar o valor do trabalho realizado pela equipe de desenvolvimento. Em seguida, a próxima parte diz que a forma como isso é feito pode variar muito entre organizações, equipes e indivíduos. Isso está muito correto. última vez, quando mudei minha equipe como proprietário de produto de um termo para outro. Descobri que muitas coisas eu preciso ajustar dentro mim mesmo para garantir que eu tire o melhor proveito da equipe scrum. Ok, então acontece, e é por isso que essa regra é complicada. Ok? O que você quer dizer com papel é complicado? Então, temos uma má notícia. A má notícia é que você precisa sujar as mãos para se tornar proprietário de um produto. O que quero dizer com isso? Quero dizer, você não pode simplesmente trabalhar em um silo, ok? Você não pode dizer à equipe que, ok, essas são as dez coisas que precisamos fazer e voltar depois do sprint e perguntar se isso não está feito ou não. Esse não é absolutamente o papel. A função realmente exige trabalhar com a equipe para garantir que eles entendam o produto corretamente e entendam um backlog corretamente e o construam? Correto. E esse é o seu papel para garantir que eles estejam no caminho certo. OK. Então você tem que trabalhar com a equipe e temos uma boa notícia também. Se você fizer isso bem, terá um produto para vender e um cliente para pagar. O que mais qualquer organização precisa mais do que isso, que você tem um produto, o que estamos construindo pode ser vendido e um cliente está interessado em comprá-lo, e como isso pode ser feito. Isso pode ser feito quando alguém escuta o cliente muito bem e transfere esses requisitos formato compreensível para a equipe de desenvolvimento. E esse é exatamente o papel do principal proprietário do produto. Ok, então este é apenas um breve resumo sobre a propriedade do produto. Então, na próxima seção discutiremos sobre o Scrum. A função de proprietário do produto é trabalhar junto com a equipe dentro da estrutura do Scrum. Então, se você não entende bem o Scrum, o papel pode se tornar um pouco mais complicado. Então, vamos entender a estrutura do Scrum do ponto de vista do proprietário do produto em detalhes da próxima palestra. Obrigada. 5. O que é Scrum?: Oi, Nesta palestra, vamos discutir sobre o que é Scrum. Antes de começarmos com a função de proprietário do produto, é essencial entender o que é Scrum. O Scrum é uma estrutura leve com três funções, três artefatos e cinco eventos, que é usada para desenvolver e manter um produto complexo. Como proprietário do produto, sua função é manter e desenvolver esse produto complexo. E como você faz isso é utilizar essas três funções, esses três artefatos sob cinco eventos. Então, vamos discutir em detalhes sobre esses papéis, artefatos e eventos na próxima palestra. O Scrum pode ser explicado de uma forma muito detalhada. Mas, a partir desta perspectiva do curso, quando estamos discutindo sobre o papel do proprietário do produto, quero realmente fazer com que você se concentre em como você deve olhar para as coisas também? Isso significa que quando você olha para o Scrum, você apenas olha para nós. São três funções, três artefatos e cinco eventos que eu preciso para utilizar desenvolver e manter um produto complexo. Ok, então com esse pensamento, vamos passar para a próxima palestra em que estamos discutindo sobre as regras. 6. Quais são diferentes papéis no Scrum?: Oi. Nesta palestra discutiremos sobre os papéis no Scrum. Existem basicamente três funções no Scrum. O scrum master, o proprietário do produto sob a equipe de entrega. Ok, vamos entender o que esse papel significa. Sm ou a forma salina do scrum master é aquele treinador para fazer o Scrum funcionar. Isso significa que todos os rituais da equipe scrum, como stand-ups, planejamento de sprint, revisão de sprint, todas essas coisas precisam ser tratadas pelo Scrum master. Qualquer problema relacionado à equipe a partir do funcionamento ou do potencial de trabalho deve ser resolvido pelo Scrum master, PO ou pelo proprietário do produto, que maximiza o valor do que maximiza o valor do produto ao entrega incremental. Ok, isso é outra coisa que estamos começando a saber é a entrega incremental. O que é entrega incremental? Isso significa que quando você entrega o produto, não pense que precisa entregar o produto no final apenas a partir do primeiro incremento ou do primeiro sprint em si, você deve entregar alguma peça do produto que é variável de temperatura. De qualquer forma, vamos discutir isso em detalhes nas próximas palestras. Eu só quero dar uma dica de que o que você quer dizer com entrega incremental? E então a equipe de entrega ou a equipe de desenvolvimento que é uma parte muito importante desse Whole Scrum Framework. E eles são responsáveis por fazer toda a bifurcação de desenvolvimento e criar um produto lançável. Ok, então qual é o seu papel aqui? Às vezes, ficamos confusos de que a equipe de entrega trabalha apenas em tudo e está liberando o produto. Então, qual é o papel do proprietário do produto? Mas o papel crítico do proprietário do produto é garantir que o produto seja lançado e possa ser usado pelo cliente. Quando pensamos em partes realmente visíveis, pensamos em qualidade. Assim, os produtos atenderiam algumas metas de qualidade para que pudessem ser entregues. E o produto deve atender aos requisitos do cliente, então somente você pode entregar o produto. Portanto, o trabalho de imagem do produto é certo, mas como eles funcionarão e em que direção trabalharão, esse é todo o papel do proprietário do produto. Ok, então eu acho que você tem uma visão geral das funções no Scrum e quem é responsável e responsável por quais atividades. Na próxima palestra, vamos discutir sobre os diferentes eventos no Scrum. 7. Quais são os diferentes eventos do Scrum?: Olá, bem-vindo a esta palestra. Nesta palestra, vamos discutir eventos de um boda no Scrum. É importante conhecer o propósito dos eventos Scrum a partir da perspectiva do proprietário do produto, porque esses são seus pontos de contato com a equipe. Isso significa que esses são os pontos, esses são os eventos em que você interage com a equipe. Então, vamos entender qual é a razão por trás desses eventos ou por que os eventos são necessários? Então, nesta foto, como você pode ver, quando falamos sobre eventos de sprint, podemos pensar sobre o planejamento do sprint, o Scrum Diário, depois a revisão do sprint, o sprint retro e se imprime. Então, vamos discutir sobre o que isso significa ou para que esses eventos realmente significam? Então, a primeira coisa é o planejamento do sprint, que é um evento de oito horas. Ele deve ser concluído dentro oito horas e deve responder o que, por que e como, o que e por que parte é o papel do proprietário do produto? Porque você precisa responder quais pendências serão tomadas pela equipe. Por que as pendências devem ser tomadas? E a parte como será respondida pela equipe, especialista no assunto, pelos arquitetos e por qualquer outra pessoa que possa contribuir para isso, certo? E então o Daily Scrum, The Daily Scrum tem que ser cronometrado em 15 minutos. Ele inspeciona o progresso em direção à meta do sprint e adota nosso plano. Isso significa um plano de equipe para as próximas 24 horas. Ok, então isso é completamente uma árvore Maven e isso foi guiado pelo Scrum Master. OK. Em seguida, a revisão do sprint, que deve ser dentro de quatro horas e inspeciona o Incremento do Produto e adota um backlog do produto para maximizar o valor do sprint futuro. Então, sempre que você ouve esse termo valor, você sabe que tem um papel crítico a desempenhar. Portanto, como proprietário de um produto, você também tem um papel muito bom a desempenhar na revisão do sprint. Vamos discutir isso em detalhes. OK. Apenas uma visão geral do que são esses eventos? Esta é a impressão retrô, que deve ser cronometrada dentro de três horas, e espera que o sprint e o plano para as melhorias sejam feitos para o próximo sprint. E depois basta imprimir como um todo, o que é menos de 30 dias corridos. E isso serve como um contêiner para outros eventos e atividades do scrum. Ok, então em um sprint, não é só que você precisa fazer isso direito em um sentido prático. No dia a dia, você tem muitas outras tarefas a serem feitas, certo? Então isso virá sob esse sprint. Os sprints são feitos consecutivamente sem lacunas. Isso significa que a equipe imprime um, depois dois, depois três, depois quatro, sprint. A equipe não pode dizer que estou fazendo essa impressão, então estou gastando três. Isso é uma coisa fundamental básica do Scrum. Então, espero que você tenha uma visão geral sobre quais são os diferentes eventos, escritório Chrome, vou discutir isso nesses eventos impressos, o que exatamente você precisa fazer. Portanto, fique atento para a próxima palestra em que discutiremos um artefato em pó, que o ajudará a acompanhar o progresso da equipe. 8. Quais são os diferentes Scrum Artefact?: Oi, Nesta palestra, vamos discutir sobre artefatos. um sprint é basicamente focado no backlog do produto, no backlog do sprint e no incremento. Portanto, o primeiro artefato é uma lista de pendências de produtos. Esta é uma lista ordenada do trabalho a ser feito para criar, manter e sustentar o produto. Portanto, esse backlog de produtos é uma coisa fundamental para o proprietário do produto, certo? Porque você possui essa lista de pendências de produtos e y para acompanhar o progresso dessa lista de pendências de produtos porque você pode dizer claramente que porcentagem do seu recurso ou do produto está pronta. Porque se o backlog do seu produto contiver 20 pendências e você tiver concluído dez pendências. Isso significa que você pode dizer claramente que 50 por cento da minha entrega está concluída, ou 50 por cento do produto está pronto para ser entregue, certo? Então, esse é um artefato muito crítico. O próximo é o backlog do sprint. O backlog do sprint, esta é uma visão geral do trabalho de desenvolvimento para realizar o objetivo do sprint. Ok, então o que queremos dizer com meta da Sprint? Porque para cada sprint, sabemos que no final do sprint temos que fornecer alguma funcionalidade. Essa funcionalidade em si é o objetivo do sprint para fazer isso ou para implementar, testar e entregar essa funcionalidade, equipe scrum tem que trabalhar em algumas das tarefas. Ele não estará diretamente relacionado ao backlog do seu produto. Pode haver muitas outras tarefas, o que as equipes precisam, digamos que o teste de unidade elas precisam fazer, elas precisam obter o ambiente para o teste do sistema. Todas essas coisas também estão sob o backlog do sprint, que não está diretamente relacionado ao backlog do produto, mas é essencial garantir que o backlog do produto seja entregue. Essa lista de pendências também precisa ser concluída. Qual backlog de sprint? Que tipo de artefato ele fornece se você puder prever quanto a equipe pode entregar em um sprint. Assim, isso pode fornecer a previsibilidade do cronograma de entrega. Certo? Depois vem o incremento. O que é um incremento? O incremento é um software funcional que é adicionado ao incremento criado anteriormente. Incremento tem tudo a ver com o software que você está trabalhando. Se todo o seu produto for sobre a implementação de 20 casos de uso. Portanto, cada incremento pode, então alguns dos casos de uso estão sendo demonstrados. Então isso significa que você pode visualizar claramente que, ok, meu produto está concluído até este caso de uso. Ok? Então isso é um incremento. E o incremento está diretamente relacionado ao produto da tabela de demonstração. No nível da organização, na verdade, rastreamos muitos outros artefatos que são muito mais métricas disponíveis, que precisam ser rastreados como parte de um projeto ou como parte de uma entrega. OK. Mas minha sugestão é que, quando você tiver uma opinião sobre quais métricas e quais coisas devem ser rastreadas, direi que tente limitá-lo apenas a esses três artefatos, backlog de produtos, sprint backlog e o incremento. Esses são os artefatos suficientes. Se você acompanhar isso, você será capaz de entregar o software e também poderá prever sua entrega e porcentagem de conclusão. Isso é o que importa no final do dia. Ok, então eu espero que você tenha entendido o conceito. Fique ligado na próxima palestra em que discutiremos sobre a definição de critérios de conclusão e aceitação. Isso é bastante crítico quando se trata do papel do proprietário do produto. Então fique atento para isso. Obrigada. 9. Diferença entre DoD e Critérios de Aceitação: Olá, bem-vindo a esta palestra. Nesta palestra, discutiremos sobre a definição de critérios de conclusão e aceitação. Esses são os dois termos que são usados na maioria das vezes de forma intercambiável. Eu também fiz isso quando comecei minha carreira como banco. Mas isso é, na verdade duas coisas diferentes e você deve entender claramente o que isso significa. Ok, então vamos começar com a definição de pronto. Esse é um entendimento compartilhado das expectativas que o incremento deve corresponder para que possa ser lançado em produção sempre que falarmos sobre o lançamento de um produto para a implantação. ou um teste, nesse momento precisamos ter certeza de que nosso produto salta para a qualidade, certo? Então, como fazemos isso? Isso é através da definição de feito. Portanto, a definição de concluído nada mais é do que uma lista de verificação de qualidade, que é uma lista de texto estática de acordo a organização Stan em relação à qualidade, se você tiver uma qualidade estrita, isso significa que você tem muito item da lista de verificação a ser verificado. Mas se a organização estiver mais voltada para a entrega de novos recursos o mais rápido possível, os critérios de qualidade serão pouco tolerantes, mas, de qualquer forma, a qualidade estará morta. Portanto, a definição de feito está diretamente ligada aos critérios de qualidade. Portanto, você precisa garantir que todas as suas pendências atendam aos critérios de qualidade. Está bem? De qualquer forma, isso é feito pela equipe, mas você precisa orientar a equipe de que a definição ampla de feito é importante e o que é abordado como parte da definição de feito. Ok, então em não célula, Definição de Concluído significa uma lista de verificação de qualidade. Como todos os casos de teste foram passados adiante, um documento específico foi atualizado, alguns critérios de segurança foram atendidos, seu código foi revisado e a lista continua. Depende da sua organização. Ok, então isso é tudo sobre a definição de pronto. Então, agora, o que é um critério de aceitação? Os critérios de aceitação fornecem os requisitos. Isso significa que os documentos solicitados de teste, etc., para garantir que o backlog seja implementado corretamente. E aqui, sua função é bastante crítica porque quando você define um backlog e você o possui, isso significa que quando você diz que, sim, esse backlog é feito como um proprietário de produto, então todos têm que concordar que Sim, está feito. E o mais importante, os clientes devem dizer que sim, eu estou bem com essa entrega, ok? Então, o que você precisa fazer para garantir que o backlog do seu produto seja concluído, rótulo de critérios. Você precisa se certificar de que o teste necessário , a demonstração necessária ou o documento necessário, que deve ser atualizado como parte disso, deve ser feito. Por exemplo, digamos que temos uma lista de pendências em que dizemos que, usando seu telefone celular, eu deveria ser capaz de fazer uma ligação. OK. Essa é a minha carteira de pendências. Então, nesse caso, que tipo de critério de aceitação você deve colocar? Os usuários dizem que quando eu ligo meu celular, eu deveria ser capaz de fazer uma chamada. Depois de desconectar uma chamada, devo conseguir fazer outra chamada. chave que pode ser usada para fazer uma chamada deve ser documentada no manual do usuário. Escrever todas essas coisas tem que vir como parte de seus critérios de aceitação. Então, agora você entende a diferença entre a definição de critérios de conclusão e aceitação. definição de concluído é mais influenciada pelo requisito de qualidade da organização. E os critérios de aceitação são muito específicos para o backlog do produto, usando o qual, como proprietário do produto, você deve ser capaz de carimbar o backlog do produto como feito e realmente visível para o cliente. Ok, espero que o conceito esteja claro. Portanto, fique atento para a próxima palestra que estamos discutindo sobre escalonamento. 10. Qual é o significado de Scaling in Scrum?: Olá, bem-vindo a esta palestra. Nesta palestra, estamos discutindo sobre dimensionamento. Então, o que queremos dizer com escala? Agora não, discutimos sobre uma equipe, um proprietário de produto, scrum master, equipe de entrega. Mas hoje em dia não é uma única equipe capaz de gerenciar todo o produto porque o produto é realmente grande, existem vários recursos. Portanto, é necessário que várias equipes trabalhem no produto. E é assim que a escala entra em cena. Isso significa que temos um produto aqui Portanto, as equipes estão trabalhando nesse produto. Isso significa que é um único backlog de produto. Mas há quatro proprietários de produtos que trabalharão para garantir que a visão do produto seja concretizada, certo? Portanto, nesse tipo de ambiente, temos o conceito de proprietário chefe de produto e gerente de produto. Porque todo o produto pertence a um proprietário chefe do produto ou a um gerente de produto. E cada equipe trabalha em alguns recursos específicos, certo? E essa é uma configuração típica quase em organizações mais antigas hoje em dia, certo? Portanto, temos um único produto e várias equipes trabalham no produto. Cada equipe possui recursos específicos, certo? Então, nesse tipo de ambiente, quando pensamos em um proprietário de produto, você tem uma função adicional para garantir que sua equipe esteja sincronizada com outra equipe quando você trabalha, certo? Por quê? Porque talvez sua equipe esteja desenvolvendo o recurso um, que também depende do recurso. Porque o recurso um e recurso dois fazem um caso de uso. O único recurso um não faz um caso de uso. Isso significa que agora você tem uma dependência entre essas duas equipes. E quem é o proprietário para resolver essas dependências é o proprietário do produto. Ok, então essa é mais uma responsabilidade adicional quando se trata de escalonamento. E esse é um cenário normal em toda a nossa organização hoje em dia. Portanto, como proprietário do produto, você também precisa gerenciar as dependências entre equipes. Um outro termo que quero apresentar aqui é o principal proprietário do produto e um gerente de produto em sua organização que pode ter um nome diferente, mas tente mapear essa estrutura. Espero que o conceito de escala seja claro. Se você tiver alguma dúvida, você sempre pode entrar em contato comigo sobre a seção Q e a, e eu entrarei em contato com você. Ok, então vamos ficar atentos para a próxima palestra, que é a nossa última palestra desta série scrum. E depois disso, vamos pular para as raízes do proprietário do produto. 11. Diferentes terminologias usadas no Scrum: Oi, Nesta palestra, vou mostrar um truque simples sobre a terminologia. O que queremos dizer? Normalmente, essa terminologia do scrum tem sido mal utilizada em muitos lugares e em muitas organizações. Portanto, no proprietário de um produto, você deve se certificar de que essas coisas sejam interpretadas corretamente para que o trabalho aconteça de acordo com o processo e conforme planejado. Este é o link para o site com.org, onde você pode ver a velocidade sempre que tiver alguma dúvida sobre um termo específico no Scrum. Ok? Isso tem sido muito útil para mim porque em algum momento eu estava um pouco confuso. Cada meta de sprint, o que você quer dizer com Sprint? Bom. Mas aqui, este documento o define muito corretamente. O objetivo do Sprint é uma espécie de expressão do propósito do sprint off em um problema de negócios que é abordado, certo? Então, dessa forma, o que aconteceu quando em uma reunião em pé quando eu estava discutindo sobre o que precisamos fazer, eu não fui capaz de fazer a equipe focar que, ok, isso é o que eu quero até o final do sprint. Mas quando eu aprendi exatamente o que era considerado um objetivo de sprint, eu costumava reiterar o objetivo do sprint em cada standup e isso fazia com que a equipe se concentrasse melhor nas coisas. Sempre que você tiver alguma confusão, consulte este documento para saber exatamente o que significa e como utilizá-lo no dia-a-dia para que, como proprietário do produto, você faça o seu papel da melhor maneira possível. Espero que isso seja útil. Por favor, me avise se você tiver alguma dúvida. Obrigada. 12. Como é uma história de usuário?: Olá, bem-vindo a esta palestra. Aqui, vamos discutir sobre como é a aparência de uma história de usuário. Até agora, discutimos por que uma história de usuário é necessária. O que é uma história de usuário e como ele usa esses requisitos diferentes. Mas vamos dar uma olhada em como exatamente a história do usuário se parece. Então, sempre que você pensa em uma história de usuário, apenas uma imagem vem à sua mente, certo? Isso é uma nota adesiva. Normalmente escrevemos histórias de usuários em uma nota adesiva. Mas por quê? Eu responderei a essa pergunta, mas por favor, espere. Essa palestra não é sobre isso. Trata-se de ver a estrutura de uma história de usuário. Esse é um exemplo de uma história de usuário. Como usuário, quero fixar um tópico de mensagem específico para que eu possa verificar e responder rapidamente às mensagens. Você sabe, no WhatsApp, esse é um recurso em que você pode realmente fixar uma mensagem no topo. Assim, sempre que houver uma mensagem vinda desse remetente, você poderá vê-la imediatamente no topo da lista e reproduzi-la. Isso é tudo sobre um recurso no WhatsApp. Mas é assim que usamos a história. Você vê um padrão aqui? Como estamos escrevendo a história do usuário? Espero que você tenha adivinhado. A maneira mais específica de escrever uma história de usuário é a função do usuário. Quero fazer alguma atividade para obter esse valor aqui mesmo. Além disso, o mesmo formato foi seguido. Como usuário. A função de usuário é o próprio usuário aqui, o usuário final I V1 para o que eu quero fazer. Quero fixar um tópico de mensagem específico que valor eu vou tirar dele ou para que exatamente eu vou usar esse recurso para que eu possa verificar e responder rapidamente às mensagens, certo? Você vê que é uma maneira muito simples e precisa falar sobre a perspectiva do usuário, qual atividade você quer fazer e quais benefícios você deseja receber, certo? Portanto, essa é uma maneira muito simples e precisa capturar todas essas informações. Ok, então essa é a maneira que você deve escrever suas histórias de usuário. Mas a grande questão é, se essa história de usuário é dada a um desenvolvedor, pode começar a implementar, a resposta óbvia é não. Então, por que essa história de usuário é necessária? Ok, então sabemos por que uma história de usuário é necessária porque fala sobre o ponto de vista do usuário durante a implementação, não queremos esquecer o ponto de vista do usuário. Ok, mas ainda assim permanece a questão que um desenvolvedor pode implementar isso? A resposta é não. Nesse estágio, o desenvolvedor não pode implementar essa história de usuário, mas a equipe de desenvolvimento não escolherá a história do usuário neste formulário. Que você vai se transformar totalmente com diferentes processos e atividades diferentes. Então, como ele usa o histórico depois de ser processado? Havia uma história parecida com esta. Portanto, temos uma linha aqui, que nada mais é do que dias rápidos de uma história de usuário. Então, temos critérios de aceitação. que significa que, com base no que eu decidirei , essa história de usuário está pronta ou não. Em seguida, haverá muitos detalhes sendo adicionados para também usar uma história como descrição técnica, diagramas necessários, diagramas necessários, quais tarefas diferentes a equipe de desenvolvimento fazer para alcançar essa história de usuário? Quais são os diferentes casos de teste para essas histórias de usuários? Quais são as suposições? Quais são as dependências que também são atributos como prioridade, esforço, equipe e status. Todas essas coisas que vamos usar à medida que progredimos no curso, você saberá onde isso é adicionado, como é usado. Então, na verdade, você só precisa se transformar daqui até aqui antes de ser escolhido pela equipe de desenvolvimento para implementação. Então, quais são esses campos de onde o obtemos? Todas essas coisas que discutiremos em detalhes nas próximas palestras. Por favor, não se preocupe com isso. O que eu queria transmitir é que quando um usuário estuda identificá-lo é tão simples quanto isso. E o formato popular que é seguido para escrever uma história de usuário é esse. E, claro, isso é amplamente usado. Portanto, sugiro que você use esse formato para escrever histórias de usuários. E então vamos fazer alguns processos, atividades para garantir que essa história de usuário seja definida e registrada para ser escolhida pela equipe de desenvolvimento e iniciar a implementação. Espero que você tenha uma ideia clara sobre como escrever uma história de usuário no estágio inicial e qual deve ser o estágio final da história do usuário, certo? Se você tiver alguma dúvida, coloque-a na seção de perguntas e respostas e teremos uma discussão para esclarecer dúvidas. Obrigado pelo seu tempo. Fique ligado na próxima palestra que discutiremos sobre o conceito de persona. Obrigada. 13. Papel do proprietário do produto: Como parte desta palestra, discutiremos apenas sobre a função de proprietário do produto. Isso significa quais são as atividades de alto nível ou o grupo de atividades que o proprietário do produto precisa fazer na organização. Portanto, a primeira coisa importante que o proprietário do produto faz é reunir os requisitos sustentados pelos pontos do cliente e de outras partes interessadas, certo? Portanto, essa é uma atividade chave que o próton precisa fazer para garantir que ele construa um produto na direção certa. E um segundo grupo de atividades é o backlog, a identificação, a priorização e o refinamento do produto . Esse é o cerne da regra doutrinária. função de proprietário do produto significa diluir o backlog do produto, identificar prioridades, refinar e facilitar a implementação da equipe de desenvolvimento. O próximo passo é que a preparação do roteiro significa, após seis meses do produto significa, após seis meses, como o produto será, quais recursos farão parte do produto após um ano, como o produto é e quais recursos fazer parte deste produto. Então é disso que se trata o roteiro do produto. Este roteiro de produto é atualizado frequentemente com as tendências do mercado e as necessidades do cliente. Em seguida, um planejamento de lançamento do produto e acompanhamento geral. Isso significa quando o produto será lançado e como os critérios de qualidade serão atendidos quando a entrega acontecerá. Todos esses aspectos também do produto não são necessários para cuidar. A última parte é derivar a visão do produto. Essa também é uma parte fundamental da função de proprietário do produto. Agora, se você olhar para essas várias atividades, essa não é uma atividade única. Se eu falar sobre isso, isso realmente não poderia ser realizado apenas organizando uma reunião, depois uma técnica multivariada e várias reuniões que precisam ser convocadas pelo proprietário do produto e o proprietário do produto precisa conversar com muitas partes interessadas para obter essa parte do escopo do produto, certo? Da mesma forma, isso também é um grupo de atividades, e esses são todos o grupo de atividades. Na maior parte da organização, o papel do proprietário do produto inclui 0,1 e 0,4, certo? Portanto, essas são coisas mínimas ruins que o proprietário do produto deve fazer. O 0.3.5 depende da organização, estrutura e cultura. Então, se em sua organização há mais hierarquia entre proprietário do produto e o líder de negócios, essa tarefa também pode ser distribuída entre essas funções, certo? Espero que você esteja entendendo meu ponto. Mas se você está em uma organização onde outro proprietário de produto, você está se reportando diretamente ao proprietário da empresa, então eu acho que você precisa cuidar de tudo isso. Isso significa uma espécie de entrega de ponta a ponta do produto, certo? Então, essa é exatamente a designação fala sobre o proprietário do produto. Você possui o produto desde a coleta de requisitos até a entrega. Bom. Espero que você tenha uma imagem muito clara sobre o tipo de atividades que o proprietário do produto precisa fazer. Mas é claro, em um nível muito alto, porque não é possível cobrir todas essas coisas neste curso. Porque é preciso muito mais tempo para descrever as técnicas e as atividades que um próton precisa fazer para desempenhar o papel de maneira perfeita, certo? Espero que esta palestra seja informativa para você e que você tenha boas informações sobre o papel das honras do produto. Obrigada. 14. Conclusão e boa sorte: Então, com isso, chegamos ao fim deste curso. Obrigado pelo seu tempo e atenção. Espero que este minicurso e um projeto para por que você fez boa informação para improvisar sobre o papel do produto neles? Desejo-lhe boa sorte para seus empreendimentos futuros.