Scrum e os requisitos

Prévia do material em texto

Apresentação
O processo de desenvolvimento ágil de software por vezes é confuso, por não haver a existência de requisitos, ou seja, o projeto vai sendo desbravado conforme anda, sem que demais reuniões de planejamento ocorram. No entanto, isso está extremamente errado. Um dos maiores desafios na condução de um time Scrum é conseguir entender o que exatamente precisa ser feito, mas também como deve ser feito. Daí a importância do domínio dos requisitos.
Nesta Unidade de Aprendizagem, você irá aprender como funciona o processo de coleta visual dos requisitos e também a identificar quais são as partes interessadas e quais são os objetivos dentro de um projeto Scrum. Por fim, você verá a forma de coletar requisitos para o backlog do produto.
Bons estudos.
Desafio
Histórias de usuários são normalmente utilizadas para coleta de requisitos em projetos ágeis. Elas se caracterizam por serem frases em linguagem simples que delineiam o resultado desejado. Os stakeholders são chamados a participar e indicam suas necessidades, que são convertidas no formato de histórias de usuários. O dono do produto avalia as histórias de usuário e prioriza a ordem de implementação. Cada história de usuário deve ser implementada em, no máximo, uma sprint.
A imagem a seguir possui audiodescrição. Para acessar o recurso, ​
Diante do que foi lhe apresentado, responda:
a) Você considera o que lhe foi passado uma história de usuário?
b) Seria possível dividi-la em duas ou mais histórias de usuários? Demonstre.
Escreva sua resposta no campo abaixo:
​Padrão de resposta esperado
a) Avaliando com cuidado a necessidade do usuário apresentada pelo dono do produto como história do usuário, percebe-se estar diante de um épico, pois sua implementação irá envolver várias etapas: criar uma opção para incluir os produtos na lista, listar o que está cadastrado, identificar há quanto tempo o produto está cadastrado, verificar se algum produto da lista já foi comprado e possibilitar que os clientes visualizem a lista de desejo de seus amigos.
b) Sendo um épico, é possível que se divida, facilitando o entendimento pela equipe e a execução durante uma sprint. A seguir, encontram-se sugestões de divisão:
Infográfico
Os requisitos que irão compor o backlog do produto são as necessidades ou os desejos dos stakeholders. O dono do produto avalia essa lista e decide o que deve ser priorizado. Para o Scrum, não importa a técnica usada para a definição e a priorização dos requisitos, mas é importante que os resultados gerem valor para os clientes e para a empresa.
Para atender às demandas do projeto, o dono do produto deve garantir um bom backlog. DEEP é um acrônimo para Detalhado, Estimado, Emergente e Priorizado, que são as características para um bom backlog. Ele pode funcionar com um checklist para o dono do produto. Por sua vez, o acrônimo FDP indica as atividades Fatiar, Detalhar e Priorizar, e o dono do produto pode praticar para organizar os requisitos. Veja, neste Infográfico, detalhes desses acrônimos.
A imagem a seguir possui audiodescrição. Para acessar o recurso, ​
​​​​​​​
Conteúdo do Livro
Na fase de coleta de requisitos, ocorre a investigação do que e de para quem serão desenvolvidas as funcionalidades do sistema. No Scrum, a coleta de requisitos não precisa ser realizada em um único encontro ou em uma única fase. Inicialmente, definem-se os requisitos principais e o dono do produto prioriza alguns desses requisitos para serem desenvolvidos em uma sprint. Isso termina definindo-se o backlog do produto.
No capítulo Scrum e os requisitos, da obra Processos de desenvolvimento de software, você verá como coletar os requisitos de forma visual utilizando técnicas como árvores e floresta. Identificar os stakeholders e seus objetivos e influência é um processo que requer habilidades e técnicas, pois permite que você planeje formas de atender às diferentes necessidades desses grupos; portanto, você verá técnicas que vão auxiliá-lo a identificar os objetivos dos stakeholders. A qualidade dos requisitos que irão compor o backlog vai definir a qualidade do seu produto; então, é interessante conhecer estratégias e técnicas que podem ser empregadas nesse processo.
Boa leitura.
Os elementos gráficos deste capítulo possuem audiodescrição. Para acessar o recurso, 
Dica do Professor
O backlog do produto é uma lista que contém todos os requisitos identificados nas histórias de usuários. O dono do produto irá acessar essa lista e priorizar os requisitos que serão inicialmente implementados.
Perceba que as histórias são um ponto-chave para a coleta de requisitos, e, para que as histórias traduzam com clareza e simplicidade os requisitos, é necessário investir algum tempo avaliando suas qualidades. É possível avaliar as qualidades das histórias por meio das características do INVEST, que você conhecerá nesta Dica do Professor.
Na prática
No início de seu projeto, é importante ter foco em identificar todos os grupos que tenham interesses, papéis ou até mesmo necessidades relacionados ao seu produto de software, além da suas influências. Após, deve-se fazer uma espécie de mapeamento identificando como será a comunicação com cada stakeholder para mantê-los interessados e engajados no projeto.
Esse engajamento dos stakeholders garantirá bom desempenho no decorrer do desenvolvimento do projeto. Veja, neste Na Prática, uma situação em que a forma de interação com os stakeholders foi estipulada conforme seu papel ou sua capacidade de influência.
A imagem a seguir possui audiodescrição. Para acessar o recurso, ​
​​​​​​​
​​​​​​​
image1.jpeg
image2.jpeg
image3.jpeg