História do usuário
As histórias de usuários são uma maneira eficaz de estabelecer requisitos para software em desenvolvimento. Essas histórias contêm breves conselhos em nome do usuário do software.
Como na metodologia Scrum a definição de metas geralmente é prerrogativa do cliente ou proprietário do software, elas são consideradas a principal forma de influenciar o processo de desenvolvimento. Cada User Story tem uma limitação na quantidade de texto e na complexidade da apresentação. A história costuma ser escrita em uma folha pequena, o que por si só limita o volume.
Graças às histórias de usuários, você pode documentar os desejos do cliente e responder rapidamente às demandas do mercado.
A User Story deve ser considerada uma medida simplista de requisitos porque não inclui um procedimento de teste de aceitação. A compilação da história do usuário deve obedecer ao procedimento de admissão. Isso garantirá que a história do usuário atinja seu objetivo.
A estrutura da história é assim: “Como um usuário <tipo de usuário>, quero executar <ação> para obter <resultado>” (como proprietário do produto, quero ...). Tal estrutura não é apenas simples, mas também compreensível para todos.
Benefícios de usar Histórias de Usuário:
- As histórias são pequenas e fáceis de criar.
- Ajude todas as partes interessadas a discutir o trabalho no projeto e seu suporte.
- Não requer manutenção constante.
- Relevante apenas quando usado.
- Melhorar a interação com o cliente.
- Graças a eles, você pode dividir o projeto em pequenas etapas.
- Facilitar o trabalho em projetos com requisitos mal compreendidos.
- Simplifique a avaliação de tarefas.
Desvantagens das histórias de usuário:
- Sem acordo prévio, os procedimentos podem dificultar o uso como base para um acordo.
- A sua utilização exige um contacto próximo com o cliente ao longo de todo o projeto, o que por vezes dificulta o fluxo de trabalho.
- Eles têm desvantagens ao escalar em grandes projetos.
- Diretamente relacionado ao nível profissional dos desenvolvedores.
- Usado para iniciar uma discussão, mas não pode terminar uma discussão e não é usado para documentação do sistema.
Lista de pendências
O backlog do produto são as tarefas atuais na forma de uma lista, compiladas em ordem de prioridade. A lista é formada com base no roteiro (roteiro) do projeto e nos pontos nele estabelecidos. As tarefas mais importantes geralmente estão no topo da lista. Isso é necessário para entender qual trabalho deve ser feito primeiro.
A equipe de desenvolvimento escolhe a velocidade de conclusão das tarefas pendentes, independentemente dos desejos do cliente, mas com base em suas qualificações e experiência em sprints anteriores. É extremamente indesejável "ajustar" os programadores. A própria equipe escolhe tarefas do backlog de acordo com suas próprias considerações e capacidades. A execução ocorre sem interrupção (Kanban) ou várias iterações (Scrum).
Duas condições importantes de backlog
O núcleo de um product backlog consiste em um roteiro, propostas e condições de execução. Os épicos contêm condições e história de usuário. Vamos dar uma olhada em um exemplo típico de roadmap.
A criação do site “Teams in Space” é a primeira proposta do roteiro. Ele precisa ser dividido em épicos (na figura eles são mostrados nas cores verde, azul e turquesa) e uma User Story para cada épico.
O cliente de software forma uma lista de várias histórias de usuário. Se necessário, ele pode alterar a ordem de execução das histórias, para que os desenvolvedores lidem primeiro com um dos épicos mais importantes (à esquerda) ou verifiquem como funciona a reserva de ingressos com desconto. Para fazer isso, você precisa implementar histórias de épicos (à direita). Ambas as opções podem ser vistas abaixo.
Com base em quais fatores o cliente deve priorizar?
- Relevância para os usuários.
- A presença de feedback.
- Complexidade do desenvolvimento.
- A relação entre as tarefas (para completar "B", primeiro você precisa fazer "A").
As prioridades no trabalho são determinadas pelo cliente, mas outras partes podem expressar sua opinião sobre isso. O sucesso do backlog depende, entre outras coisas, da opinião de clientes e programadores. Juntos, eles podem alcançar melhores resultados e garantir a entrega pontual do produto acabado.
Como manter um backlog
Se o backlog já tiver sido criado, depois disso, você precisará alterá-lo periodicamente durante o trabalho posterior. O cliente de software deve certificar-se de que o backlog seja devidamente compilado antes de cada novo planejamento de iteração. Isso ajudará a esclarecer prioridades ou mudar algo após a análise da última iteração. Ajustar o backlog no Agile às vezes é chamado de “preparação” ou “refinamento” ou “manutenção do backlog”.
Se o backlog já for relativamente grande, o cliente precisa agrupar tarefas por execução de curto e longo prazo. Atribuições de curto prazo devem ser examinadas antes de receberem esse status. Você terá que compor uma história de usuário, descobrir todas as nuances dentro da equipe.
Quanto às tarefas de longo prazo, é altamente desejável que os desenvolvedores façam sua avaliação. Isso facilitará a priorização. Talvez algo mude, mas a equipe melhorará sua compreensão das tarefas e fará o trabalho mais rapidamente.
O backlog é um componente importante entre o cliente e a equipe de programação. O cliente sempre pode mudar as prioridades com base no feedback do cliente, previsões ou novos requisitos.
Recomenda-se evitar fazer alterações diretamente durante a operação. Isso tem um efeito negativo no fluxo de trabalho e no estado emocional dos programadores.
Corrida
Um sprint é um curto período durante o qual uma quantidade de trabalho previamente acordada deve ser concluída. Sprints são baseados em metodologias Scrum e Agile. Escolher os sprints certos ajuda uma equipe ágil a desenvolver software de qualidade.
“Usando o Scrum, você pode desenvolver um produto em várias iterações com uma duração clara - sprints. Isso ajuda a dividir grandes projetos em tarefas menores”, diz Megan Cook, líder de Jira na Atlassian.
Como o Scrum planeja e executa sprints?
Segundo os autores da metodologia Scrum, para planejar o futuro sprint, todos precisam se reunir em uma reunião separada. Neste evento, os membros da equipe devem encontrar respostas para duas perguntas principais: o que precisa ser feito neste sprint e qual a melhor forma de fazê-lo?
O cliente de software, Scrum master e programadores estão envolvidos na determinação da lista de tarefas de trabalho. O cliente explica o objetivo do sprint e as tarefas do backlog.
Em seguida, a equipe desenvolve um plano segundo o qual as tarefas do sprint serão concluídas. Esse plano, junto com os itens de trabalho selecionados, é chamado de backlog da sprint. Após a reunião de planejamento, a equipe começa a trabalhar. Os desenvolvedores selecionam tarefas do backlog, conforme o trabalho é concluído, o status de cada tarefa muda de “Em andamento” para “Concluído”.
Durante o sprint, a equipe realiza reuniões Scrum diárias (stand-ups) para discutir os problemas atuais e o progresso. Tais reuniões são necessárias para identificar dificuldades que podem afetar a conclusão do sprint.
Se o sprint for concluído, a equipe mostra os resultados de seu trabalho na revisão dos resultados (demo). Cada participante do projeto pode se familiarizar com os resultados. A familiarização deve ser feita antes que o código final seja mesclado no ambiente de produção.
A retrospectiva completa o ciclo de sprints. Nela, a equipe identifica as áreas que precisam ser melhoradas em um sprint futuro.
O que prestar atenção e o que não fazer
A maioria das equipes jovens acha difícil introduzir sprints em seu fluxo de trabalho pela primeira vez. Para evitar problemas, recomendamos que você revise a lista de ações que precisam de atenção prioritária.
O que nós temos que fazer:
- Verifique se a equipe entende o propósito do sprint e como ele será bem-sucedido. Isso é necessário para que todos caminhem juntos para um resultado de sucesso.
- Você deve ter um backlog claro e compreensível. Se o backlog não foi mantido corretamente, isso pode se tornar um problema que pode prejudicar o fluxo de trabalho.
- Certifique-se de que sua estimativa do ritmo de trabalho esteja correta, levando em consideração as férias de verão e outros fatores.
- Participar ativamente do planejamento do sprint. Incentive os membros da equipe a expandir o plano para histórias, bugs e atribuições.
- Recuse tarefas durante as quais os desenvolvedores não poderão resolver problemas de dependência.
- Após a aprovação do plano, designe um funcionário que será responsável por inserir os dados no programa de gerenciamento de projetos (cartões Jira, etc.).
O que evitar:
- Não abuse de um grande número de histórias, avalie com sobriedade o ritmo de trabalho e não atribua tarefas que serão difíceis de concluir em um sprint.
- Esteja atento à qualidade do seu trabalho. Verifique se você tem tempo suficiente para controle de qualidade e correção de bugs no código.
- Certifique-se de que todos os membros da equipe entendam claramente o conteúdo do sprint. Não persiga a velocidade. Toda a equipe deve se mover junto.
- Não sobrecarregue os desenvolvedores com trabalho extra. Outro sprint em breve.
- Se a equipe expressar preocupação com a carga de trabalho ou com o prazo, você deve levar em consideração a opinião deles. Lide com os problemas e corrija-os se necessário.
placa de scrum
O Scrum Board é uma ferramenta que mostra como é feito o trabalho do Time Scrum. Você pode exibir informações em tal quadro em papel, na parede ou em formato eletrônico (JIRA, Trello).
Um quadro Scrum tem pelo menos três colunas: To Do, In Progress e Done. Aqui está uma placa de exemplo:
O quadro Scrum contém todas as informações do backlog, previamente aprovado para planejamento. Como regra, os cartões de tarefas de negócios são fixados no quadro por prioridade de cima para baixo. Você pode dividi-los em tipos específicos de trabalho (trabalho em código, design e outros).
Depois que parte do trabalho é concluída, o cartão é movido pelo tabuleiro para a próxima coluna. Para mostrar a visibilidade do andamento do trabalho da equipe, o “trabalho restante” por dia no Burndown Chart ajuda.
Você também pode usar um quadro de flipchart. Nela, os nomes das obras são escritos em adesivos de papel e fixados no quadro. Assim que o trabalho é concluído, os adesivos são movidos para outra coluna.
gráfico de burndown
O gráfico burndown mostra a quantidade de trabalho realizado e a quantidade de trabalho restante. É atualizado todos os dias e está disponível para todos os interessados. O gráfico é necessário para mostrar o progresso no trabalho no sprint.
Existem dois tipos de gráficos:
- Burndown chart mostrando o progresso do trabalho em um sprint.
- Burndown chart mostrando o andamento do trabalho até o lançamento do produto (os dados são resumidos de vários sprints).
Exemplo de gráfico:
Este exemplo usa psicologia: o gráfico não mostra o número de tarefas concluídas, mas o número de tarefas restantes (não concluídas).
Ou seja, se a equipe realizou 90 tarefas em 100, pode haver uma falsa sensação de que tudo está pronto. Afinal, o progresso de 90 para 100 tarefas não muda nada.
Se você exibir o número de tarefas restantes, não poderá deixar de notar como cada vez elas se tornam cada vez menos. Isso inconscientemente estimula os participantes do projeto a atingir a meta mais rapidamente - não deve haver tarefas inacabadas no quadro.