[MÚSICA] [MÚSICA] Olá. Bemvindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou Clovis Fernandes. Nesta aula estaremos estendendo a estrutura de User Stories por meio de uma técnica chamada 3 Cs, Cartão, Conversação e Confirmação. Ao final desta aula você saberá então, como é que fica a nova estrutura das User Stories. Essa técnica de 3Cs ajuda a entender melhor como se estrutura e se usa as User Stories. Então, ela é formada pelas três partes, como nós estamos vendo aí: Cartão, Conversação e Confirmação. O Cartão é a estrutura normal, é a parte da frente do Cartão a estrutura normal que a gente já tinha definido que vai numa User Story. Esse formato que nós estamos usando que ajuda a entender também uma User Story, que é o Who, o papel o What, que vai definir qual é o objetivo e o Why, que vai dizer o contexto, qual o benefício que eu tenho de fazer essa User Story, e lembrando que ela é opcional. Na Conversação a gente não deve nunca esquecer que a User Story, ela é uma promessa de conversa desde o início dela e para o futuro do desenvolvimento do software. Então o PO vai conversar com o time, vai definir essa User Story num dado momento e a cada momento que o time precisar de alguma informação adicional vai entrar contato com o PO o dono do produto para esclarecer melhor como é que é essa User Story. Já a Confirmação você vejam que a User Story ela é escrita na frente do Cartão e a Confirmação, onde eu vou colocar esse conjunto de Testes de Aceitação que eu estou aqui simbolizando como AT vai ficar no verso. Então, para cada User Story nós vamos ter ou mais Testes de Aceitação. Testes de Aceitação não fazem sentido sem User Story. A User story pode até num dado momento eu não ter ainda os Testes de Aceitação. Posso, por exemplo, não fazer isso no começo. Eu posso fazer isso só na hora que eu vou tratar, implementar, codificar uma dada User Story. Então, vamos mostrar cada uma dessas partes, começando pelo Cartão. O Cartão ele representa requisito, ele representa uma User Story, como a User Story representa requisito, então o Cartão também representa requisito. Então, use Cartão realmente cartão. Você pode estar usando, por exemplo, post-it para colar no mural. Você pode estar usando também cartão virtual, usando softwares, aplicativos que ajudam a descrever User Stories. Então, você pode estar usando o Trello o KanbanFlow e outras ferramentas que trabalham nesse sentido. Como eu já havia dito, uma User Story ela vai ter o texto suficiente, ela não precisa ser muito detalhada, basta ter a informação que seja suficiente e para isso a gente sabe que o tamanho do cartão ajuda muito a você não ficar pondo muita coisa. A segunda parte, que é a conversação, ela começa antes das User Stories estarem definidas. Normalmente ela ocorre no que a gente chama, nós chamamos aqui no nosso Scrum e XP na nossa metodologia que a gente está querendo mostrar para vocês é o Sprint Zero. Ele antecede o desenvolvimento, corresponde aquela frase que eu chamei nos cursos anteriores, EDUF- Enough Design Up-Front. Quer dizer, nós vamos fazer projeto anterior suficiente e é isso que a gente faz nesse Sprint Zero. Nesse Sprint Zero nós vamos, o PO e o time de desenvolvimento vai fazer entrevistas, vai tentar entender o desenvolvimento que deve fazer vão representar essas funcionalidades que se deseja por nesse software na forma de User Story. Para cada User Story o Product Owner, o dono do produto ele quer garantir que o que ele deseja seja feito para aquela característica que está sendo representada para User Story. Para isso, o que é que ele faz? Ele cria então, conjunto de Testes de Aceitação e associa isso a cada User Story e coloca no verso, então, na frente a gente tem a User Story escrita, no verso nós vamos ter os Testes de Aceitação. Como eu disse, o Teste de Aceitação vai dar uma garantia ao time desenvolvedor que eles estão fazendo o caminho certo ao desenvolver aquela User Story. O Product Owner vai depois validar se o que eles fizeram está de acordo com esses Testes de Aceitação. Por isso que é importante ter o Teste de Aceitação. Tendo já definido uma User Story com três partes: o Papel, o Who, o What e o Why, mais os Testes de Aceitação para cada User Story, tanto o Product Owner quanto o time estão entendendo mais o que deve ser feito. Com isso, eles podem definir estimativas de tamanho, de esforço que correspondem. Essa User Story vai levar quantos dias, por exemplo? Quantos dias estimamos que vamos desenvolver essa User Story? Essa é uma situação pouco difícil de ser feita mas já tem mais informação. E normalmente eles fazem isso usando uma reunião que a gente chama de Planning Poker ou Scrum Poker ou Planning Game que o time de desenvolvimento junto com a presença do Product Owner, vão atribuindo a cada User Story esse tamanho, esse size, esse tamanho do esforço necessário para codificar. Por sua vez, o dono do produto, ele não é dono do produto à toa. Ele é que vai decidir qual User Story tem mais valor de negócio ou não. Ele que vai fazer isso. Então, para cada User Story que se define nesse Sprint Zero o Product Owner vai definindo uma estimativa de valor de negócio, que pode variar ao longo do tempo. Mas ele especifica num dado momento, pode mudar depois qual é esse valor. Porquê? Depois, a ideia é que possa priorizar, para que as User Stories que tenham mais valor de negócio é que sejam feitas para os primeiros [INAUDÍVEL]. Ela viu o projeto terminar, o principal estaria tudo feito. Isso quer dizer o valor de negócio que a gente está chamando BV aí, que é Business Value. Vocês têm que me desculpar o uso de muitos termos inglês é porque eu acho importante, que vocês vão ler muito material sobre isso apenas inglês. A gente vai fazendo vocês se acostumarem a termos inglês. Para cada User Story, conjunto de Testes de Aceitação e esse conjunto é que vai mostrar para a equipe desenvolvedora se eles estão no caminho certo. Então vai ser uma rota, como se fosse roteiro que vai mostrar para eles onde, como chegar no software codificado e se vai satisfazer o Product Owner. Por sua vez, o Product Owner numa reunião que a gente chama de Sprint Review, que é no final, quando você começou a codificar algumas, no final da interação ou do Sprint, que você começa a desenvolver algumas User Stories. No final o grupo vai mostrar, isso que a gente está chamando de Demo, vai mostrar para o PO que eles conseguiram completar o trabalho de acordo com os Testes de Aceitação que ele definiu. Mas cabe ao Product Owner aceitar ou rejeitar. Ele pode aceitar, beleza, o software está ok, o trabalho foi feito. Você pode classificar isso como bem feito. Ele pode rejeitar. Como ele é o [INAUDÍVEL] negócio, pode ser que aquilo que foi construído naquele Sprint não tem mais valor, ele não esteja mais interessado. Agora ele também pode rejeitar parcialmente, uma coisa ou outra que ele viu feito, achou que não ficou muito bem. Não tem problema, na verdade, não se perde o trabalho e se cria uma nova User Story para fazer o acerto dessa mudança que ele fez. Lembrem-se, nós estamos trabalhando com uma metodologia ágil. É para que mudanças que ocorram possam ser acomodadas e isso pode ocorrer. [SEM ÁUDIO] Até agora a estrutura da User Story é composta de definição da própria User Story naquele formato do "As a" "I want", o objetivo. "So that", benefício. Tem essa subestrutura. Agora a gente já acrescentou o tamanho da User Story. Ou seja, ela vai ser difícil, fácil de implementar e também o Business Value, o BV. Ou seja, ela vai estar melhor priorizada ou não. E obviamente o Teste de Aceitação, que seria conjunto de Testes de Aceitação para cada User Story. Com isso espero que você tenha entendido melhor como é que ficou a estrutura de User Story, que é fundamental no nosso desenvolvimento ágil de Scrum e XP que nós estamos mostrando aqui. Até à próxima aula. [MÚSICA] [MÚSICA] [MÚSICA]
