[MÚSICA] Olá! Bem-vindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou Clovis Fernandes, hoje iremos apresentar uma receita para desenvolver de maneira organizada as user stories da sua aplicação. Como é usual, por exemplo, se você vai fazer bolo que você não conhece, você então segue a sua receita desse bolo. Com o tempo, fazendo várias vezes esse mesmo bolo, você vai se acostumando e vai interiorizando o que fazer. No desenvolvimento das user stories nós vamos apresentar uma receita que vai ajudar você, de uma maneira organizada, a partir da visão da aplicação, junto com o product owner, construir conjunto de boas user stories, que vai facilitar o desenvolvimento. Basicamente, essa receita inclui, ou ocorre durante uma reunião, essa reunião é a reunião que você vai definir as user stories. E essa reunião é feita, muitas vezes, comandada pelo dono do produto, o PO, junto com o time de desenvolvimento, ele vai definir as user stories seguindo essa receita. Mais ou menos essa receita. E vai obter todas as informações da visão da aplicação. O passo da receita, se você construiu a visão da aplicação de acordo com o que nós mostramos na aula específica, você já obtém esse conjunto de tipos de usuários. Então você vai obter, por exemplo, no nosso exemplo aqui, sempre vai existir pelo menos tipo de usuário, nem que seja tipo de usuário que vai ser usuário qualquer. Mas na nossa aplicação, a gente pode ter até k tipos de usuários, e você vai pegar os cartões, criar cartões para cada deles. Então você vai criar cartões para cada deles. A ideia, se você não construiu do jeito que a gente te mostrou, é ir lendo a especificação, o documento da visão da aplicação e extraindo os tipos de usuários junto com os objetivos de interação de cada usuário. Então por exemplo, na nossa aplicação, que usamos lá na definição do documento de visão da aplicação, que é o Livros a Jato, aqui de uma maneira simplificada, nós temos cinco tipos de usuários: o UR1 que é o admin, o administrador, o UR2 que é o visitante, o UR3 que é o cliente, ele é tipo de usuário abstrato, ele realmente, quando se refere a cliente está dizendo que pode ser o cliente padrão ou o cliente premium, o UR4 que é o tipo padrão e o UR5 que é o tipo premium. Tomemos como exemplo o tipo de usuário admin, UR1 admin, administrador. Ele tem alguns objetivos aqui. Então, por exemplo, ele tem o faz login, ele tem o mantém o site, insere novos e-books e remove e-books. Certo? A gente também está usando uma nomenclatura do O1, O2, O3 pra identificar esses objetivos. O O é de objetivo. O passo dois é, ele vai, ele tem dois fluxos. Fluxo externo que é pra varrer os tipos de usuários. Então ele vai pegar do usuário até o usuário k, no nosso exemplo do Livros a Jato, o k é cinco, então vai ser de a cinco. Então eu pego por exemplo, aqui, o R1, inicialmente, aí vou pro fluxo interno. Ele vai começar a varrer os objetivos. Então ele vai pegar o objetivo que é fazer login. Aí eu vou definir, sabendo que é o admin, e é fazer login, eu vou definir a user story, eu vou fazer essa composição aqui, do who com o what, e depois eu tento definir a parte why. Por que eu tento? Por que eu estou tentando aqui? Porque eu já disse que se não sair não tem problema, ela é opcional nessa hora que a gente está definindo. Aí eu vou seguindo o fluxo aqui, eu vou seguindo o fluxo e pego novo objetivo, o O2, e assim vou até concluir. No nosso exemplo aqui são até quatro objetivos. Concluído pro R1 eu vou e pego o R2. E assim vou fluindo, vou seguindo até que os k tipos de usuários sejam tratados. No nosso exemplo, o k é igual à cinco. A toda combinação do tipo do usuário com o objetivo do usuário, a gente está mostrando aqui, eu estou formando uma user story diferente. Eu estou chamando aí de US1, é user story US2, US3, US4, correspondente à cada uma das combinações dos objetivos correspondentes a esse tipo de usuário. Vocês vejam aqui que eu estou trabalhando com o objetivo do tipo de usuário admin, administrador. Então construindo aqui a user story pra ele. Estou usando o modelo de usar três linhas, uma pra cada da minha estrutura, o who, o what, e o why. Então aqui, como admin, eu quero fazer login no website, de modo que eu possa mantê-lo. Essa é a razão. E não sou obrigado a usar aquele estrutura de três linhas, eu posso usar de uma linha só. Então ficou, como admin eu quero fazer login no website, de modo que eu possa mantê-lo. Eu posso também fazer, apresentar as outras user stories. Eu só vou falar aqui pro objetivo mantém site, como admin eu quero manter o site, no caso aqui eu não tenho uma razão, motivo, vai ficar sem. Algum momento pode aparecer. Insere novos e-books. Como admin eu quero inserir novos e-books, de modo que eu possa oferecer novidades, oferecer novidades. E o quarto aqui, como admin eu quero remover e-books, de modo que eu mantenha apenas e-books de interesse. Com isso nós mostramos uma receita simples. Na verdade ela não precisa ser tão organizada, ela pode ser pouquinho mais flexível. Eu posso pegar cartões na ordem que eu quiser. Eu não preciso ficar identificando, a partir daquela lista, uma certa ordem de tipos de usuários. Mas de qualquer maneira, organizadamente é melhor. Então se eu pego cada deles e vou trabalhando os seu objetivos fica muito melhor. Eu consigo então, se o sistema é pequeno você leva algumas horas, você faz toda, uma reunião relativamente curta e produz todas as user stories. Se for uma aplicação mais complicada vai levar dois dias, uma reunião mais longa porque vai ter muitos tipos de usuários, vai ter muitos tipos de objetivos pra cada tipo de usuário. Lembrete que fica aqui, e como é uma receita, quanto mais você usar e definir isso ela vai se interiorizando no grupo, no time de desenvolvimento, e com isso vocês têm mais facilidade de desenvolver user stories de qualidade e com mais rapidez. Obrigado. [MÚSICA]