[MÚSICA] Olá bem vindo ao curso Princípio de Desenvolvimento Ágil de Software. Eu sou Clóvis Fernandes e hoje iremos apresentar algumas dicas para desenvolver com mais facilidade a User Story, ao final da vídeo aula você terá aprendido algumas maneiras de criar User Story que serão depois utilizadas mais a frente principalmente quando eu estiver mostrando uma receita mais organizada, né ta certo, de como criar User Story mas essas dicas servem para essa época também. Bom, o que que nós queremos no final? User Story. Porque as User Stories elas vão nortear todo o desenvolvimento do software. Elas vão guiar o que que o time de desenvolvimento vai fazer, para isso eu preciso ter boas User Stories, e como é que eu obtenho isso? Principalmente através do time junto com o Product Owner. O PO ele é muito importante nessa hora, está certo? Então normalmente se faz uma reunião que se define as User Stories para uma dada aplicação. Mas define como? Cima da visão da aplicação. Porque é isso que nós vamos fazer, nós. Com base na visão da aplicação, nós vamos aplicar essas dicas, está certo, e conseguimos então produzir User Stories de qualidade. Nós devemos apresentar quatro dicas, está certo, que vão ajudar você desenvolver melhor o User Story qualquer situação na verdade. Mais para frente nós iremos como eu falei apresentar uma receita que organiza melhor mas as dicas são sempre úteis. Qualquer outro momento que eu precisar discutir conversar, o Product Owner o time discutir sobre as User Stories, essas dicas devem ser sempre seguidas. A primeira dica O foco ''O quê fazer", não "como fazer". Isso é óbvio né? Mais ou menos óbvio. Por que? O Product Owner ele que deve realmente ficar com a responsabilidade de definir as User Stories e ele não tem muito conhecimento sobre desenvolvimento, geralmente não tem, está certo. Então ele não sabe como fazer. Por isso que o foco tem que ser sempre no "o quê fazer" mesmo o time de desenvolvimento participando é que ele vai ajudar o Product Owner a produzir essas User Stories, mas o foco é sempre no "O quê fazer". Temos sempre que lembrar e o dono do produto tem que estar bastante envolvido nesse hora, está certo, ou seja, ele é fundamental, ele é crítico. Está certo, participar nesse hora de definir as User Stories. E por que que é crítico? Porque ele que conhece o valor do negócio, ele que vai valorizar o que nesse negócio tem que ser colocado ou não. E para isso ele tem que a User Stories tem que estar escrito na linguagem do usuário na linguagem do domínio do negócio. Porque ele vai levar e discutir essas User Stories com pessoas leigas está certo. Vai discutir também o time de desenvolvimento também discutir com usuários, clientes stakeholders, e vão realmente corroborar as decisões que ele toma com relação ao negócio. Uma coisa que é importante é manter as User Stories curtas elas vão ter os tamanhos que elas devam ter, curtas no sentido de informações se adiciona ao cartão da User Stories. Então por que que elas devem ser curtas? Porque elas são lembrete para conversação, está certo? O final o objetivo final, é que o time desenvolva o código correspondente e faça a implementação dessa User Story mas tendo sempre conversas com o product owner. Está certo? Então essa conversação deve existir, e também o product owner vai ter conversas com outras pessoas fora do time, como usuários steakholders, clientes, então é sempre importante isso. Nós já falamos mas não custa enfatizar que nós estaremos usando uma estrutura no nosso XP na nossa metodologia, e se baseia você definir o Who, ou o tipo do usuário, está certo aquele que vai interagir com o seu sistema, com o seu sistema, está certo? Com esse sistema que vai ser desenvolvido, o What ou seja, qual é o objetivo desse tipo de usuário na interação com o sistema, né está certo? E o Why, ou seja qual o motivo dele estar fazendo isso? Isso ajuda na conversação mais para frente. Está certo, isso ajuda o time de desenvolvimento a saber o que fazer, principalmente quando ele vai desenvolver o testes de aceitação, temos que lembrar que o Why, ele é opcional está certo? Na hora que eu estou produzindo os User Stories, se eu não conseguir produzir nem Why satisfatório, ou mais ou menos meia boca, não tem problema. É que mais para frente principalmente antes do desenvolvimento, se eu tiver com uma User Story completa, ajuda o desenvolvimento sair melhor. Eu preciso, tendo o Why isso facilita criar os testes de aceitação, tendo o motivo e o teste de aceitação isso ajuda a definir o tamanho da User Story ou seja o esforço que isso vai levar semanas por exemplo, ou dias ou semanas para desenvolver a dada User Story está certo? Então isso é importante que antes do desenvolvimento todas essas informações estejam prontas, principalmente o Why. Com isso a gente mostrou para vocês essas quatro dicas, elas vão ser importantes para vocês definirem, nós vamos exemplificar mais a frente, mas vai ser importante para vocês definirem boas User Stories, o que são User Stories? são User Stories que realmente ajudam o desenvolvedor a desenvolver o código correspondente sem grandes problemas, está certo? Ele olha e consegue desenvolver com mais facilidade, obrigado. [MÚSICA] [MÚSICA]