[MÚSICA] Olá! Bemvindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou Clovis Fernandes e hoje iremos falar sobre o que é uma User Story. Iremos mostrar inicialmente uma estrutura inicial que descreve o que é uma user story. Da outra vez nós mostramos que tinha cliente que desejava fazer software. Agora, já que a gente está usando a metodologia Scrum e XP, esse cliente, e XP chamado de cliente ou customer, no nosso caso do Scrum, que é o que nós vamos adotar, ele é chamado de product owner, o dono do produto. Ele que vai acompanhar a equipe de desenvolvimento do começo ao fim do desenvolvimento da aplicação. Ele que vai interagir todos os momentos esclarecendo o quê que deve ser feito para aquele software. Se ele não sabe ele vai procurar as pessoas da empresa, ou de outros lugares para no final definir. É muito importante esse papel porque é ele que vai definir a cara do software. Ele vai acompanhar e vai aceitar tudo o que o time de desenvolvimento tiver feito de acordo com o que ele prescreveu. Para o desenvolvimento desse software desejado pelo product owner, que a gente carinhosamente simplifica pra PO, as duas letra P e O, PO inglês, ele precisa, então, saber e definir os requisitos. Algum momento nós iremos mostrar como que se obtém esses requisitos. Nesse momento agora, nós vamos nos fixar apenas e você pode descrever os requisitos usando funcionalidades, descreve essas funcionalidades e algumas vezes seguindo alguns padrões internacionais de como descrever, são coisas longas. Princípio, antes de você desenvolver o software você vai definir essas funcionalidades. Você pode também usar casos de uso, que também é uma descrição bastante detalhada, antes de poder começar a se desenvolver o software. Ou a gente pode usar as user stories. No modelo ágil tem grupos que estão usando funcionalidades inicialmente e, dessas funcionalidades, obtêm as user stories. Outros estão usando casos de uso. É meio estranho, eles detalham aqueles casos de uso, e, no final, extraem as user stories. Outros definem as user stories e dessas user stories extraem casos de uso. Nós não iremos fazer nada disso aqui. Nós iremos trabalhar com user stories puras. Não iremos trabalhar de nenhuma maneira fazendo uso, ou de funcionalidades, descrever funcionalidades, embora se você quiser fazer isso você também pode fazer, e nem usando casos de uso, vai ser user stories. Então, o que vem a ser uma user story? Ela descreve uma funcionalidade que o product owner, o PO, gostaria que ela fizesse parte do produto. A ideia aqui é que essas user stories, ao contrário dos casos de uso, descrevem muito no sentido de trabalhar com informações de desenvolvimento, as user stories, a perspectiva é do product owner, do PO. Ou seja, você vai descrever as stories na linguagem do cliente. Você vai escrever junto com o PO, de preferência, se o PO conseguir escrever as user stories, melhor. Porque ele vai descrever as user stories que dão mais valor de negócio ao produto. E vai ajudar, inclusive, a definir como que os releases dessas user stories vão sendo depois implementados. Essa estrutura inicial, iremos estruturar uma user story usando esses três Ws, inglês aqui. Who: eu quero determinar quais são os papéis dos usuários desse software. Suponha que você tem site que existam três tipos de usuários, por exemplo, você vai ter visitante, que é visitante comum, ele entra no site e não tem direito a muita coisa, vê o que você permitir que ele veja. Você pode ter, então, cliente padrão. Esse cliente padrão, ele é mais do que visitante, ele vê as mesmas coisas que o visitante vê também, mas ele vê alguma coisa que o outro não vai ver. E você também pode ter cliente premium. Aí as principais coisas do site só são apresentadas para o cliente premium. Então, esses são os três tipos de usuários para determinado site, por exemplo. Você pode ter, sabendo qual é o cliente, então imagine que você tenha uma empresa com o uso de software que você está desenvolvendo, gerente comercial, E ele tem como objetivo, aí é o What, o What vai mostrar o objetivo do que esse tipo de usuário quer ver. Suponha que esse gerente comercial, ele queira ver uma lista com os nomes dos clientes que fizeram compras mas, ordenado pelo volume de vendas. Aí vem a parte do Why, que é o contexto. Por que ele precisa ver isso? Ele está querendo ver isso por que ele quer conhecer melhor os seus clientes que fazem compras mais altas, oferecer oportunidades novas para eles e também desenvolver algumas estratégias ou táticas de marketing para fazer com que os clientes que compram menos passem a comprar mais. A estruturação de user story inicial vai se basear nesses três Ws. Então, vocês vejam que para identificar o tipo do usuário você vai pôr: "As a <o tipo do usuário>", como <usuário>. Então seria: Como <gerente comercial>. O what vai mostrar o objetivo que esse gerente comercial, que esse tipo de usuário, necessita. Então você vai pôr: I need, I want, I can alcançar determinado objetivo. e por fim o why, que eu falei, ele é o contexto. E ele também, vocês vejam que ele está marcado numa cor diferente, tem até colchete antes e depois, ele é opcional. No nosso Scrum com XP ele é opcional. Você não pode ficar parado, paralisado, porque você não consegue definir o motivo num dado momento. Qual é o motivo? Nem sempre você consegue visualizar isso, mas não tem problema porque, como a gente disse que a user story é uma conversa entre o PO e o time de desenvolvimento, algum momento esse feedback todo acaba descobrindo o que é essa parte do why. Então, vamos ver exemplo. Eu estou formalizando aquilo que eu tinha dito sobre o exemplo do gerente comercial. Qual é o tipo do usuário? É gerente comercial, então: As a gerente comercial, I want, want né, o que quero, I want o relatório de vendas ordenado por volume de vendas. E o why: So that conhecer meus melhores clientes. Então, veja que eu tenho essas três coisas aqui. O gerente comercial, o objetivo é o relatório de vendas ordenado pelo volume de vendas, e o motivo, o contexto, o porquê, é conhecer os meus melhores clientes. Eu não preciso usar as palavras inglês. Então: Como gerente comercial, eu quero o relatório de vendas ordenado pelo volume de vendas, de modo a conhecer os meus melhores clientes. É isso que importa, essa estrutura é que importa. Vamos mostrar agora outro exemplo que o tipo do usuário é comprador online de livros. Então: Como comprador online de livros, eu quero utilizar meu cartão de crédito no pagamento dos livros escolhidos, de modo a ter praticidade e segurança no pagamento. Veja que o de modo a ter praticidade e segurança no pagamento, pode ser que eu não soubesse disso no início, não tem problema. Ele é opcional. Ele não precisa aparecer todas as user stories que eu estiver definindo junto com o product owner. Por quê disso? Porque é o que eu falei. Uma user story é uma promessa de conversação, de conversa, de diálogo, entre o time de desenvolvimento e o product owner. Ou seja, se você tem alguma coisa que não está clara, quando o time não consegue entender direito aquela user story pra chegar no desenvolvimento, nós iremos mostrar como se faz isso, você vai conversar com o product owner. O PO. Por que você tem essa facilidade? Porque o PO, durante todo o projeto, ele está junto com a equipe. Na verdade, ele fica normalmente numa sala do lado da sala de desenvolvimento. Ele é facilmente alcançado. Ele, normalmente, entra dentro da sala de desenvolvimento e vê como as coisas estão correndo, e responde novas indagações que os desenvolvedores precisam pra entender o que estão fazendo. Com isso nós mostramos essa estrutura inicial, baseada no Who, What e Why, desses três Ws. Posteriormente, nós iremos ligar alguns novos elementos a essa estrutura. Sempre com o objetivo de oferecer mais subsídios ao product owner, para ele entender melhor o que ele está desenvolvendo, inclusive para priorizar as user stories que vão ser implementadas primeiro. E o time de desenvolvimento que, com mais informação, vai ajudar, inclusive, a estimar melhor os tempos, por exemplo, quanto tempo vai levar determinadas user stories para serem desenvolvidas. Obrigado. [MÚSICA]
