Backlog
| Nome | Data | Descrição | Versão |
|---|---|---|---|
| Adrianne Alves | 29/10/2018 | Criação do Documento e adição de introdução, propósito, escopo, objetivos e metodologia | 0.0.1 |
| Mariana Mendes | 06/11/2018 | Adição do link do backlog do produto | 0.0.2 |
| Maria Luiza | 20/11/2018 | Adição das imagens | 0.0.3 |
| Adrianne Alves | 22/11/2018 | Atualização do documento | 0.0.4 |
| João Pedro Sconetto | 22/11/2018 | Correções para entrega do Backlog | 1.0.0 |
- 1 Introdução
- 2 Objetivos
- 3 Metodologia
- 4 Product Backlog
- 5 Referências
A partir de uma baseline de requisitos bem fundamentada, é possível definir um backlog bem estruturado a partir do qual o desenvolvimento pode obter maior sucesso. É importante lembrar, entretanto que o backlog do produto é um artefato SCRUM constantemente refatorado, devido à volatilidade dos requisitos dos stakeholders, dessa maneira, as diversas modificações podem ser vistas pelo histórico do drive (Google Drive).
O presente documento tem como propósito apresentar o product backlog do software a ser desenvolvido, o Ticketflix, trazendo as histórias de usuários e os seus critérios de aceitação. Espera-se a partir desse backlog conseguir planejar as sprints (conforme a metodologia estabelecida) a serem executadas até o prazo final da melhor forma possível.
O escopo do product backlog considera as histórias selecionadas a partir dos requisitos elicitados, a serem desenvolvidos até o fim do prazo de entrega do projeto. Assim, optou-se por dividir em módulos e apresentar os critérios de aceitação da histórias a serem entregues.
Objetiva-se, para a construção do backlog, utilizar a modelagem de requisitos relacionando as histórias de usuário que representam as características necessárias ao software a ser desenvolvido, proposto pelo time. Espera-se obter assim uma consolidação da baseline de requisitos, disponibilizando uma relação pronta para ser implementada.
Primeiramente, foi necessário recolher os requisitos obtidos a partir de todas as técnicas utilizadas, explicitadas no Moscow e previamente priorizadas, para orientar a criação do backlog do produto. A priorização do Moscow foi revista por todos os componentes da equipe e então foram divididas entre os membros as funcionalidades relatadas. Dessa forma, cada um ficou responsável por escrever a história correspondente e elaboras os critérios de aceitação. A divisão dessa atividade está explicitada na ata da reunião correspondente.
Devido ao curto tempo de desenvolvimento da aplicação pela equipe, foi preciso reduzir o escopo da aplicação de maneira a compor as partes principais que poderiam ser entregues até a data final estabelecida para o projeto. Dessa forma, o backlog original foi dividido em dois: O implementado e o constante para iterações futuras. As imagens podem ser visualizadas abaixo.
O Product Backlog pode ser acessado através desse link: https://docs.google.com/spreadsheets/d/1tk3AKKslzvp-USAvyrjODCVK4mIj8pOG7cYVpn8alOA/edit?usp=sharing
- Desenvolvimento ágil. Product Backlog.