Sprint Backlog
É o conjunto de itens que uma equipe multifuncional de produtos seleciona de seu product backlog
para trabalhar durante o próximo sprint.
Normalmente, a equipe concorda com esses itens durante a sessão de planejamento do sprint. Na
verdade, o backlog do sprint representa a principal saída do planejamento desse.
Se a equipe não for capaz de completar, ou mesmo começar certos itens do sprint backlog até o final
do sprint, a equipe pode escolher adicionar esses trabalhos inacabados ao próximo sprint backlog,
caso eles ainda forem considerados de alta prioridade, ou para o backlog do produto.
De acordo com a estrutura do scrum, toda a equipe ágil, incluindo o scrum master, o product owner e o
time de desenvolvimento, compartilhará a propriedade do sprint backlog. Isso ocorre porque todos
os membros da equipe trarão conhecimentos e percepções exclusivas para o projeto no início de
cada sprint.
Sprint backlogs são geralmente planilhas embutidas, mas também podem ser desenvolvidas e
mantidas em ferramentas de software projetadas para gerenciamento ágil de projetos. Como essas
listas incluem apenas trabalhos que podem ser concluídos em um curto espaço de tempo, a que
chamamos de SPRINT, que dura de 2 a 4 semanas, os backlogs de sprint costumam ser muito simples.
Diagrama de Atividades
Usamos Diagramas de Atividades para ilustrar o fluxo de controle em um sistema e fazer referência
às etapas envolvidas na execução de um caso de uso. Modelamos atividades sequenciais e
concorrentes usando diagramas de atividades. Portanto, basicamente representamos os fluxos de
trabalho visualmente usando um diagrama de atividades. Um diagrama de atividades enfoca a
condição do fluxo e a sequência em que ele acontece. Descrevemos ou representamos o que causa
um determinado evento usando um diagrama de atividades.
Um diagrama de atividades é usado por desenvolvedores para entender o fluxo de programas em
alto nível. Também permite que eles descubram restrições e condições que causam eventos
específicos. Geralmente usamos o diagrama e a documentação textual para tornar a descrição do
nosso sistema o mais clara possível.
TDD E Testes
Testes de Aceitação do Usuário: Eles devem incluir todos os cenários descritos nas histórias de
usuário. Eles não devem ser muito detalhados (eles não precisam mencionar telas específicas ou
uma lista completa de ações para executar as etapas). Devem ler:
DADA essa condição 1 e condição 2….
QUANDO eu faço a etapa 1 e a etapa 2…
ENTÃO, resultado desejado 1, resultado desejado 2….
Eles definem um conjunto de cenários reais que um testador pode percorrer para garantir que o
recurso está completo.
Esses não são scripts de teste detalhados, pois o objetivo deles é transmitir um conjunto de testes
que todos os envolvidos podem percorrer para entender como o recurso funcionará.
Vamos conhecer um pouco de TDD –Desenvolvimento Orientado a Testes. É uma abordagem
evolutiva do desenvolvimento que requer disciplina e habilidades significativas e, claro, boas
ferramentas.
A primeira etapa é adicionar rapidamente um teste, ou seja, um código básico o suficiente para
falhar.
Em seguida, você executa seus testes, frequentemente, o conjunto de testes completo, ainda que,
por uma questão de velocidade, você possa decidir executar apenas um subconjunto, para garantir
que o novo teste de fato falhe.
Depois, você atualiza seu código funcional para que ele passe nos novos testes.
A quarta etapa é executar seus testes novamente. Se eles falharem, você precisará atualizar seu
código funcional e testar novamente.
Depois que os testes forem aprovados, a próxima etapa é começar de novo, aproveite para refatorar
qualquer duplicação de seu código conforme o necessário.
Wireframe, Mapa Conceitual e Mapa Navegacional
Wireframes: Uma imagem é necessária para cada tela envolvida. Eles podem ser desenhos simples
em um quadro branco, que são digitalizados e postos no documento em word, ou um conjunto de
caixas criadas em softwares para isso, e que depois podem gerar imagens para serem coladas no
word ou algum outro software de documentação.