O documento apresenta os conceitos e técnicas de levantamento de requisitos ágeis para desenvolvimento de software, incluindo a criação de uma visão de produto, identificação de partes interessadas, elicitação de requisitos e criação de histórias de usuário. As equipes deverão aplicar essas técnicas para definir a visão e requisitos de um sistema de biblioteca universitária.
Como especificar requisitos em metodologias ágeis?Priscilla Aguiar
Apesar deste artigo ter sido produzido descrevendo técnicas de metodologias ágeis, há tópicos que agregam valor e esclarecem dúvidas na descrição de requisitos independente do processo (ágil ou cascata).
Material de apoio do Workshop de Desenvolvimento Ágil oferecido para estudantes universitário participantes do Ideias Já!, primeira competição universitária de ideias realizado pela Startup House em novembro de 2012.
Como especificar requisitos em metodologias ágeis?Priscilla Aguiar
Apesar deste artigo ter sido produzido descrevendo técnicas de metodologias ágeis, há tópicos que agregam valor e esclarecem dúvidas na descrição de requisitos independente do processo (ágil ou cascata).
Material de apoio do Workshop de Desenvolvimento Ágil oferecido para estudantes universitário participantes do Ideias Já!, primeira competição universitária de ideias realizado pela Startup House em novembro de 2012.
Esta palestra mostra como é o processo de desenvolvimento no UOL, saindo do método tradicional RUP para o Scrum, um método ágil de desenvolvimento que se popularizou nos últimos anos. Palestra ministrada na Maratona Mineira de Programação em maio/2013, em Itajubá/MG
O Time recebe as USs para desenvolver, mas será que sabem por que existem? O que pode conter? E que a melhor forma de uma US é a que o Time definir junto ao papel de PO/ PM! Este papel não precisa trabalhar de maneira solitária e entregando USs ao Time, deve parear com pessoas técnicas, assim as pessoas desenvolvem a visão técnica x negócio, apoiando ter um Time full stack. Além disso o papel PO/ PM pode focar mais nas descobertas do produto e o time pode apoiar na escrita de histórias do usuário. Junto a qualidade deve estar em todo processo de desenvolvimento e é responsabilidade de todo Time, o QA review pode auxiliar promovendo o alinhamento e a análise do que tem de ser desenvolvido. USs e QA review promovem a conversa para que visões diferentes sejam complementares para entrega de um produto com valor e qualidade, com foco na pessoa usuária. Este workshop tem o objetivo de promover time autônomos.
Dúvidas, sugestões e feedback:
Mayra Souza
mayra.souza@zapcorp.com.br
https://br.linkedin.com/in/mayrarodriguesdesouza
@paola_mayra
Eluza Pinheiro
eluzapinheiro@gmail.com
https://www.linkedin.com/in/eluzapinheiro/
@usinadeux
Referências:
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
http://www.knowledge21.com.br/sobreagilidade/user-stories/o-que-e-user-story/
https://www.agilealliance.org/glossary/invest/
https://www.slideshare.net/tdc-globalcode/tdc2016poa-trilha-analise-de-negocios-como-fatiar-seu-produto-em-estrias-que-faam-sentido
https://www.slideshare.net/augustoruckert/historias-de-usuarios-declarao-de-valor
Proposta para especificação de histórias de usuários alinhadas a IEEE 830André Agostinho
Uma proposta para especificação de user stories utilizando a engenharia centrada a uso e criando especificações de requisitos alinhadas a prática a IEEE 830. A proposta considera ainda o uso da metodologia ágil Scrum e da técnica BDD para testar e validar user stories, além de fornecer living documentation para e equipe de desenvolvimento e do cliente.
Esta palestra mostra como é o processo de desenvolvimento no UOL, saindo do método tradicional RUP para o Scrum, um método ágil de desenvolvimento que se popularizou nos últimos anos. Palestra ministrada na Maratona Mineira de Programação em maio/2013, em Itajubá/MG
O Time recebe as USs para desenvolver, mas será que sabem por que existem? O que pode conter? E que a melhor forma de uma US é a que o Time definir junto ao papel de PO/ PM! Este papel não precisa trabalhar de maneira solitária e entregando USs ao Time, deve parear com pessoas técnicas, assim as pessoas desenvolvem a visão técnica x negócio, apoiando ter um Time full stack. Além disso o papel PO/ PM pode focar mais nas descobertas do produto e o time pode apoiar na escrita de histórias do usuário. Junto a qualidade deve estar em todo processo de desenvolvimento e é responsabilidade de todo Time, o QA review pode auxiliar promovendo o alinhamento e a análise do que tem de ser desenvolvido. USs e QA review promovem a conversa para que visões diferentes sejam complementares para entrega de um produto com valor e qualidade, com foco na pessoa usuária. Este workshop tem o objetivo de promover time autônomos.
Dúvidas, sugestões e feedback:
Mayra Souza
mayra.souza@zapcorp.com.br
https://br.linkedin.com/in/mayrarodriguesdesouza
@paola_mayra
Eluza Pinheiro
eluzapinheiro@gmail.com
https://www.linkedin.com/in/eluzapinheiro/
@usinadeux
Referências:
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
http://www.knowledge21.com.br/sobreagilidade/user-stories/o-que-e-user-story/
https://www.agilealliance.org/glossary/invest/
https://www.slideshare.net/tdc-globalcode/tdc2016poa-trilha-analise-de-negocios-como-fatiar-seu-produto-em-estrias-que-faam-sentido
https://www.slideshare.net/augustoruckert/historias-de-usuarios-declarao-de-valor
Proposta para especificação de histórias de usuários alinhadas a IEEE 830André Agostinho
Uma proposta para especificação de user stories utilizando a engenharia centrada a uso e criando especificações de requisitos alinhadas a prática a IEEE 830. A proposta considera ainda o uso da metodologia ágil Scrum e da técnica BDD para testar e validar user stories, além de fornecer living documentation para e equipe de desenvolvimento e do cliente.
3. Levantamento de Requisitos Ágil
Listagem ou
recolha de
informaçãoes
Condição necessária
e indispensável;
Exigência; Requerido
Que se comporta ou
trabalha de maneira
eficaz e rápida; Que acha
uma solução rápida; que
se consegue desenrolar
com facilidade
6. Visão do Produto
• Define o objetivo
macro do produto a
ser desenvolvido
• Define o escopo
• Ajuda a guiar as
mudanças que vão
aparecendo
– Evita distorções em
relação ao que foi
acordado inicialmente
• De maneira sucinta
– Qual o problema?
– O que pretende-se
fazer?
– Quem será
beneficiado?
• Quais papéis
podemos distinguir?
8. Visão do Produto
• Nas duas técnicas temos que definir:
– Nome do produto
– Pontos chaves do produto (necessidades)
– Principais funcionalidades
– Principais requisitos operacionais
– Slogan (boa razão para comprar)
• Pode conter
– Imagens (logo)
9. Trabalho 1
• 4 Equipes
I. Criar um Product Box do sistema de
Biblioteca da Faculdade Evolução
II. TimeBox
I. Preparação: 30min
II. Apresentação: 15min
III. Escolha de qual iremos usar: 15min
10. Estorias de Usuário
• Descreve um requisito que é valioso
para um usuário ou comprador de
um sistema de software;
• 3 aspectos (3C):
– Cartão: Uma descricão escrita da̧
estória para servir como lembrete da
funcionalidade;
– Conversa: Para confirmar os detalhes
escritos na descricão;̧
– Confirmação: Testes que podem ser
usados para determinar quando uma
estória está completa;
11. Estorias de Usuário
• Estrutura
Como um <PAPEL>
eu posso/gostaria/devo <FUNCÃO>̧
para <VALOR DE NEGÓCIO>
• Exemplo
Como um comprador de livros
Eu gostaria de encontrar um livro que sei o titulo
para poder comprá-lo
13. Requisitos
• O que devemos fazer ?
1. Criar a visão do produto (product box)
2. Identificar as partes interessadas
3. Elicitar/levantar os requisitos
a) Entrevistas, brainstorms
b) Nível macro
4. Criar as User Stories
5. Criar o product backlog e priorizar
14. Trabalho 2
• Já temos a Visão do Produto!
• Precisamos descobrir os requisitos
– 4 Equipes
• Listar os requisitos levantados
• Criar pelo menos 3 User Stories
• TimeBox
– Preparação: 30min
– Apresentação: 15min