Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, graças às boas práticas e princípios orientados a objetos, TDD e conceitos avançados de Java aplicados à Web e banco de dados exercitados nos cursos anteriores; mas você talvez não se sinta ainda confortável em planejar e gerenciar o desenvolvimento das aplicações com base em modernas práticas de modelagem ágil. O objetivo deste curso é expor você às principais técnicas e princípios de desenvolvimento ágil, em especial aos que se popularizaram pela sua utilização no framework Scrum e na metodologia XP (Extreme Programming). Apresentamos o Scrum&XP, uma combinação apropriada do framework Scrum com a metodologia XP – Extreme Programming, sem no entanto afirmar que você estará aprendendo tudo sobre Scrum ou sobre XP. Os conceitos apresentados neste curso incluem o seguinte: * Manifesto ágil e princípios de desenvolvimento ágil * Requisitos de software na forma de user stories e backlog de produto * Eventos e reuniões do Scrum&XP: Sprint, Sprint Planning, Planning Poker, Daily Scrum, Sprint Review e Sprint Retrospective, TDD e Programação em Pares * Papéis do Scrum: Product Owner, Time de Desenvolvedores e Scrum Master * Tarefas, Sprint Backlog, Quadro de Tarefas e Diagrama Burndown Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar de modo ágil um sistema que incorpora um componente de gamificação constante do Trabalho de Conclusão do Programa de Cursos Integrados, com base nas boas práticas ágeis exercitadas neste curso com o Scrum&XP apresentado. Obs.: Embora o Programa de Cursos Integrados (descrito abaixo) seja sobre a linguagem Java no contexto de desenvolvimento ágil, neste curso em especial você poderá empregar a linguagem que desejar, embora incentivemos que os alunos dos cursos anteriores do programa faça uso do Java, pois será uma oportunidade muito enriquecedora de praticar TDD com Java da maneira que se faz na indústria de software. -- --- ---- coursera.org: ITA Programa de Cursos Integrados: Programação Java e Modelagem Ágil Curso 1: Orientação a Objetos com Java Curso 2: TDD – Desenvolvimento de Software Guiado por Testes Curso 3: Desenvolvimento Ágil com Java Avançado Curso 4: Princípios de Desenvolvimento Ágil de Software Curso 5: Desenvolvimento Ágil com Padrões de Projeto Curso 6: Técnicas Avançadas para Projeto de Software Curso 7: Arquitetura de Software em Projetos Ágeis Projeto Final: Aplicativo para Web com Componente Gamificado
User Story: O Que É?
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Princípios de Desenvolvimento Ágil de Software
131 classificações
Instituto Tecnológico de Aeronáutica
131 classificações
Na lição
Semana 1
Olá, bem-vindo ao Curso 4 – Princípios de Desenvolvimento Ágil de Software! Estamos contentes que você esteja aqui para ter os primeiros contatos com modelagem ágil de software. Neste módulo introdutório, você será apresentado ao Scrum&XP, uma combinação apropriada do Scrum com o XP. Ao final deste módulo você também terá aprendido sobre Manifesto Ágil, user stories e visão da aplicação.
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[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]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
