I_PITADSistemasII (1)

Prévia do material em texto

Conteudista: Prof. Me. Artur Marques
Revisão Textual: Esp. Danilo Coutinho de Almeida Cavalcante
DESAF IO
ATIVIDADE
Material Teórico
Material Complementar
Situação-Problema 1
Situação-Problema 2
Situação-Problema 3
Problema em Foco
Projeto Integrador Transdisciplinar em Análise e
Desenvolvimento de Sistemas II
R EF ER ÊN CIAS
Atividade de Entrega
Referências
Olá, estudante!
Vamos iniciar a disciplina abordando os conceitos necessários para que você possa realizar a
atividade através das situações-problema mais à frente.
Introdução
A ideia neste espaço é aproveitar para discutir o material e relembrar o conteúdo que você precisará
de forma geral, para realizar os desafios. 
Não estamos interessados apenas em resolver problemas, queremos te mostrar a abordagem ideal,
além de discutir metodologias. Além disso, essa disciplina te auxiliará no seu desenvolvimento, afinal
1 / 8
Material Teórico
 Atenção, estudante! Aqui, reforçamos o acesso ao conteúdo
online para que você assista à videoaula. Será muito importante
para o entendimento do conteúdo.
temos pouco tempo para fazer muita coisa, no que tange a alternativas e a novas experimentações
que focam em facilitar sua vida para que você foque em itens importantes na produção de um
planejamento ágil para análise e desenvolvimento de sistemas. Portanto, focaremos em:
desenvolvimento de requisitos ágeis, conversão de requisitos ágeis em itens de projeto e atividades,
artefatos ágeis, criar o backlog de produto, sprints, jogo do planejamento, entre outras coisas.
Queremos que a partir da experiência nessa disciplina você possa aprenda a gerar valor para os seus
usuários e para sua vida pessoal e profissional.
Um conselho importante é que, independentemente de essa disciplina desenvolver um projeto
individual ou coletivo, o importante é que você desenvolva seu networking durante a execução do
projeto. 
Converse com seus colegas ou faça novos colegas; troque experiências, faça sugestões e se permita
receber sugestões. 
O objetivo deste espaço é discutir e relembrar o conteúdo necessário para realizar os desafios,
abordando metodologias e ferramentas que possam ajudar a tornar o processo mais ágil e eficiente. 
Vamos então iniciar nossa recordação antes dos desafios?!
Desenvolvimento de Requisitos Ágeis
Os requisitos ágeis são desenvolvidos por meio de um processo colaborativo e iterativo que envolve
várias técnicas para capturar, priorizar e validar as necessidades do usuário e os recursos do produto. 
Vejamos essas técnicas, então: 
Histórias de usuário: uma história de usuário é uma declaração breve e simples que
descreve a necessidade ou o recurso de um usuário a partir de sua perspectiva. A
história é normalmente escrita em uma linguagem amigável, fácil de entender e com
critérios de aceitação específicos. As histórias de usuários são um bloco de construção
fundamental dos requisitos ágeis e ajudam a garantir que a equipe esteja focada na
entrega de valor aos usuários finais. Exemplo de um padrão aceito para história do
usuário: “Como viajante frequente, quero poder ver o status do voo da minha próxima
viagem para que eu possa planejar meu dia”;
Critérios de aceitação: os critérios de aceitação são um conjunto de condições que um
produto ou recurso deve atender para ser considerado completo e aceitável. Os
critérios de aceitação ajudam a garantir que a equipe entenda o que é esperado e quais
são as necessidades do usuário. Aqui vai um exemplo seguindo a história do usuário do
exemplo anterior para dar continuidade: “O status do voo deve incluir atualizações em
tempo real sobre os horários de partida e chegada, quaisquer alterações no portão de
embarque e quaisquer atrasos ou cancelamentos”;
Prototipagem: envolve a criação de um modelo simples e de baixa fidelidade do
produto ou recurso para testar e validar com os usuários. A criação de protótipos pode
ajudar a identificar problemas de design logo no início e ajudar a garantir que a equipe
esteja criando o produto certo. Vejamos um exemplo utilizando a história do usuário
usada acima: a equipe cria um protótipo do recurso de status de voo com uma interface
simples e que permite aos usuários visualizar atualizações em tempo real de seus
próximos voos. Depois a equipe testa o protótipo com um pequeno grupo de usuários e
coleta feedback para refinar o design;
Modelagem Ágil: a modelagem ágil envolve a criação de diagramas ou modelos para
ajudar a comunicar requisitos e decisões de projeto. A modelagem ágil pode ajudar a
garantir que a equipe esteja alinhada com a visão e o design do produto. Utilizando a
mesma história do usuário, aqui vai mais um exemplo: a equipe cria um diagrama de
caso de uso de alto nível para ilustrar como o recurso de status de voo interagirá com
outras partes do produto. O diagrama inclui o usuário, o recurso de status de voo e os
outros componentes do produto;
Refinamento de backlog: envolve revisar e priorizar regularmente o backlog do produto
para garantir que ele esteja atualizado e que a equipe esteja focada em fornecer os
recursos mais valiosos primeiro. Vejamos como isso fica com a nossa história do usuário
original: a equipe realiza uma sessão de refinamento de lista de pendências e analisa a
história do usuário do recurso de status de voo. Eles refinam os critérios de aceitação e
adicionam detalhes adicionais para garantir que a história seja clara e acionável.
Figura 1 – Modelo de refinamento de backlog por Roman
Pichler, 2011
Fonte: Reprodução
#ParaTodosVerem: figura em tons de cores demonstrando um modelo de
refinamento de backlog. A figura deve ser lida da esquerda para a direita. A primeira
área, em tons de azul, é chamada Área das Histórias, nela há uma parte superior
onde cartões brancos escritos em letra preta descrevem histórias dos usuários
preparadas para desenvolver. Mais abaixo, na mesma coluna, há os outros cartões
descrevendo Temas e Épicos ainda a serem fracionados e aprofundados. Na coluna
seguinte, em tons de verde, há uma caixa branca nomeada como Caixa de
Restrições, a qual divide-se em duas colunas. Na primeira coluna, na cor verde-
claro, há os dizeres “Qualidades Operacionais” e, logo abaixo, os cartões
performance, robustez e interoperabilidade, que são as características essenciais da
produção das tarefas. Logo ao lado direito, pertencente ao mesmo título, está a
segunda coluna, em verde um pouco mais escuro, e com os dizeres “Design do
Produto e da Interface do usuário”, com wireframes (desenho de protótipo de baixa
fidelidade) das telas que comporão a interface do usuário do sistema que será
construído. Por fim, mais à direita, na última caixa, de cor laranja, há a Área de
Modelagem, e, abaixo dela, os modelos que são produzidos com UML – linguagem
de modelagem unificada – com os artefatos necessários para o desenvolvimento. O
primeiro deles é um diagrama geral de caso de uso e o outro, logo abaixo,
representa um diagrama de atividades. Fim da descrição.
Roman Pichler, um especialista em gestão de produtos ágeis, aplicou esse conceito de
“Refinamento” ao backlog (repositório de requisitos dentro do framework Scrum), criando uma
espécie de modelo, que é apresentado na figura logo acima. São apresentadas 3 áreas: a primeira,
em tons de azul, é onde estão as histórias dos usuários (Story Area); a segunda, em tons de verde, é a
área das restrições e de design da interface do usuário (Constraint Area); por fim, em tons de laranja,
está a área onde modelamos a solução para que seja produzido o código (Model Area).
Conversão de Requisitos Ágeis em Itens de Projeto e
Atividades
Depois que as histórias de usuários forem priorizadas e selecionadas para implementação em um
sprint específico, a próxima etapa é dividi-las em tarefas ou atividades menores e mais gerenciáveis
que podem ser concluídas pela equipe de desenvolvimento. Esse processo é chamado de
tasking ou “tarefação”.
A tarefa envolve a identificação das etapas e das atividades específicas necessáriaspara implementar
uma história de usuário. Isso pode envolver dividir a história em recursos ou funções individuais e,
em seguida, identificar as atividades específicas de codificação, teste e implantação necessárias para
implementar cada uma.
Uma maneira de abordar a tarefa é reunir a equipe de desenvolvimento e fazer com que eles
colaborem na divisão das histórias de usuários em tarefas individuais. Isso pode ser feito usando um
quadro branco ou notas adesivas (post-it), com cada tarefa sendo escrita em uma nota separada e,
em seguida, organizada em grupos lógicos, grupos de afinidade ou fluxos de trabalho.
Outra técnica que pode ser usada é chamada de “três amigos”. Essa técnica envolve reunir um
representante da equipe de desenvolvimento, da equipe de testes e do proprietário do produto para
discutir e definir colaborativamente as tarefas necessárias para implementar uma história de usuário.
Uma vez que as tarefas tenham sido identificadas, elas podem ser inseridas na lista de pendências da
sprint, juntamente com estimativas de quanto tempo cada tarefa levará para ser concluída. Isso dará à
equipe uma compreensão clara do que precisa ser feito para implementar cada história de usuário e
ajudará a garantir que todos estejam trabalhando para os mesmos objetivos e cronogramas.
Além das tarefas, os itens do projeto também podem ser identificados durante o processo de
detalhamento de histórias de usuários.
Vejamos um exemplo:
Essas tarefas podem ser adicionadas à lista de pendências da sprint e atribuídas aos membros da
equipe para conclusão durante a sprint. 
Podemos inclusive quebrar em subtarefas para aumentar a granularidade. Veja, por exemplo:
História do usuário: como cliente, quero poder ver meu histórico de pedidos no site:
Tarefa 1: analisar os requisitos e projetar o esquema de banco de dados para armazenar
o histórico de pedidos;
Tarefa 2: desenvolver o código do banco de dados para recuperar dados do histórico de
pedidos;
Tarefa 3: criar a interface do usuário para exibir os dados do histórico de pedidos no site;
Tarefa 4: integrar a interface do usuário com o código do banco de dados de back-end;
Tarefa 5: escrever casos de teste automatizados para o recurso de histórico de pedidos;
Tarefa 6: executar testes manuais para garantir que o recurso funcione conforme o
esperado.
História do usuário: como usuário do site, quero poder criar uma conta para que eu
possa salvar minhas preferências e visualizar meu histórico de pedidos.
Tarefa 1: projetar fluxo de criação de conta de usuário.
• Subtarefa 1.1: criar wireframes do fluxo de criação de conta de usuário;
Artefatos Ágeis
Artefatos ágeis são documentos físicos ou digitais que capturam informações essenciais sobre o
produto que está sendo desenvolvido e o andamento do projeto. Eles são parte integrante da
metodologia ágil, que enfatiza uma abordagem colaborativa e entrega frequente de software de
trabalho. Os artefatos ágeis ajudam a facilitar a comunicação e fornecem transparência entre a
equipe de desenvolvimento, as partes interessadas e o cliente.
Existem vários tipos de artefatos ágeis utilizados na construção de sistemas de informação:
• Subtarefa 1.2: obter feedback das partes interessadas sobre wireframes;
• Subtarefa 1.3: revisar wireframes com base no feedback das partes interessadas.
Product Backlog: a lista de pendências do produto é uma lista priorizada de recursos,
funcionalidades e histórias de usuários que precisam ser desenvolvidos para criar o
produto. Ele é continuamente atualizado durante o projeto e serve como uma única
fonte de requisitos para a equipe de desenvolvimento;
Sprint Backlog: a lista de pendências de sprint é um subconjunto da lista de pendências
do produto que contém os itens que a equipe se compromete a concluir durante uma
sprint específica. Inclui tarefas, histórias de usuários e bugs;
Gráfico de burndown: um gráfico de burndown é uma representação visual do progresso
da equipe durante um sprint. Ele mostra o trabalho restante versus o trabalho planejado
para cada dia do sprint;
História de usuário: uma história de usuário é uma descrição simples e concisa de um
recurso ou funcionalidade da perspectiva do usuário. Ele fornece uma compreensão
clara do que o usuário quer e por quê;
Critérios de aceitação: os critérios de aceitação são um conjunto de condições ou
requisitos que a história do usuário deve satisfazer antes de ser considerada completa.
Clique no botão para conferir o conteúdo.
Eles garantem que as necessidades do usuário sejam atendidas e que o recurso
funcione conforme o esperado;
Plano de lançamento: um plano de alto nível que descreve o escopo de uma versão,
incluindo os recursos ou histórias de usuários que serão incluídos e o cronograma de
entrega;
Meta da Sprint: uma breve declaração que define o objetivo ou o resultado de uma
sprint;
Quadro de tarefas: uma representação visual da lista de pendências da sprint que ajuda
a equipe a gerenciar e acompanhar seu progresso. Veja bem, podemos utilizar um
quadro Kanban, porém não há uma linha declarando isso na última versão do SCRUM;
Notas retrospectivas: um registro da reunião retrospectiva (Sprint Retrospective) da
equipe que captura os insights e ideias da equipe para melhorar seu processo;
Incremento do produto: um software funcional, testado e potencialmente liberável que
foi desenvolvido durante uma sprint.
Leitura
O Guia do Scrum 
Acesse a última versão do SCRUM, lançada por Jeff Sutherland e Ken
Schwaber em 2020.
ACESSE
Figura 2 – Ciclo de vida SCRUM – Uma visão geral do
framework SCRUM, que reúne grande parte dos artefatos
ágeis utilizados na produção de software de qualidade
Fonte: Reprodução
#ParaTodosVerem: figura esquemática do ciclo de desenvolvimento de
software ágil chamado SCRUM. A imagem é feita sobre um fundo branco utilizando a
cor cinza para desenvolver as setas de progressão de atividades e, em tons de
verde, os artefatos entregues. Deve ser lida da esquerda para a direita e se inicia no
canto inferior esquerdo, com o título: “Visão do Produto + Equipe”. Uma seta de
progressão nos leva para o backlog do produto, que é composto pelas histórias do
usuário na forma de cartões. Na sequência, outra pilha de documentos, em verde,
nos remete ao backlog da sprint, em que os cartões de história já estão intercalados
e classificados por prioridade, complexidade e agregação de valor para que o time
de desenvolvimento possa então entrar na fase de 15 dias. Nessa fase, o ritual segue
com as reuniões diárias de posicionamento pelo time de desenvolvimento com
duração de 15 minutos. Isso é demonstrado na próxima etapa, em que há um círculo
pequeno sobre um círculo grande que possui as cerimônias de artefatos do SCRUM,
logo após o backlog da sprint entrar, são elas: reunião de planejamento da sprint, na
sequência o desenvolvimento do incremento do produto resultante dos trabalhos
após o planejamento, na sequência a revisão da sprint, a retrospectiva da sprint,
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-PortugueseBR-3.0.pdf
portanto o produto dessa sprint já está pronto e, por fim, devemos atualizar o
backlog do produto e, nessa situação, entendemos que o backlog diminui a cada
sprint de 15 dias rodada, todavia, podem ocorrer acréscimos de cartões se for
permitido pelo dono do produto em concordância com a equipe de
desenvolvimento associada ao tempo que resta. Lembre-se de que não é permitido
alterar a quantidade de sprints de um projeto uma vez decidido no planejamento
quantas serão. Isso determina o que pode ser entregue pela medida da capacidade
da equipe em fazer, conforme a extremidade mais à direita demonstra com a saída
dos círculos de 15 dias da sprint e das reuniões diárias.. Fim da descrição.
Os artefatos ágeis são aplicados em situações em que os requisitos não são claros, são complexos ou
estão sujeitos a alterações. Eles são especialmente úteis em projetos com alto nível de incerteza e
risco. Os artefatos ágeis promovema colaboração e a transparência, facilitando a adaptação às
mudanças e a entrega de valor ao cliente rapidamente.
Claro que não existem apenas esses artefatos ágeis, mas, para a parte inicial em que você precisa
capturar requisitos, definir o planejamento mínimo e depois se preparar para um controle visual, é
importante também um quadro Kanban associado a um monitoramento da evolução das entregas
em frente ao backlog do produto, que pode ser, como visto logo acima, um gráfico de burndown ou
burnup, entre outros.
Vejamos duas definições de conceitos importantíssimos em método ágil: a definição de preparado e
a definição de pronto.
Bem, para começar, os termos em inglês são: Definition of Ready (DoR) e Definition of Done (DoD). Em
tradução livre para o português, temos: Definição de preparado (DoR) e Definição de Pronto (DoD).
As abreviações são esses dois acrônimos: (DoR) e (DoD). Esses são dois conceitos importantes no
desenvolvimento ágil, que ajudam as equipes a estabelecer critérios claros para quando uma
história ou tarefa de usuário está pronta para ser trabalhada e quando é considerada completa.
Definição de Preparado (DoR)
É um conjunto de critérios que uma história de usuário deve atender antes que uma equipe possa
começar a trabalhar nela. Ela garante que a história do usuário seja bem compreendida, definida
corretamente e contenha todas as informações necessárias para que a equipe comece a trabalhar
nela. Essa definição pode variar de equipe para equipe, mas normalmente inclui itens como critérios
de aceitação claros, priorização adequada e dependências identificadas. Vejamos um exemplo de
critérios que o time de desenvolvimento utilizará para aceitar o que vem do dono do produto e dos
usuários:
Definição de Pronto/Feito/Realizado (DoD)
Descreve os critérios específicos que devem ser atendidos para que uma história de usuário ou
tarefa seja considerada completa/encerrada. Ela garante que a equipe cumpriu todos os requisitos e
entregou uma solução de trabalho que atende às expectativas das partes interessadas, chamadas,
em inglês, de stakeholders. Uma definição de pronto, normalmente inclui itens como revisão de
código, teste, documentação e aceitação pelo proprietário do produto. Vejamos um exemplo de
critérios para que as partes interessadas aceitem o que o time de projeto desenvolveu:
A história do usuário deve ser escrita em uma linguagem clara, concisa e de fácil
compreensão;
Os critérios de aceitação devem ser claramente definidos e acordados pela equipe e
pelo proprietário do produto;
As dependências para a história do usuário devem ser identificadas;
A prioridade para a história do usuário deve ser definida e acordada pela equipe e pelo
proprietário do produto;
O código deve ser revisado por pelo menos um outro membro da equipe;
O código deve passar por testes automatizados;
O código deve ser mesclado na ramificação principal;
Tanto o DoR quanto o DoD ajudam a evitar mal-entendidos, atrasos e retrabalho. Ao usar essas
definições, é possível garantir que a qualidade do produto atenda às expectativas das partes
interessadas a partir do que é esperado dela.
Clique no botão para conferir o conteúdo.
ACESSE
Outra coisa importante a descrever é exatamente o uso dos gráficos para visualizar a situação dos
projetos de software ágeis. Os gráficos de burndown e burnup como artefatos ágeis, em um projeto de
O teste de aceitação do usuário deve ser concluído e aprovado pelo proprietário do
produto;
A documentação deve ser atualizada para refletir as alterações feitas.
Leitura 
Somente Empresas Ágeis Sobrevivem ao Ambiente de Negócios em
Constante Mudança                         
Aproveitando a oportunidade, recomendo fortemente que você leia o texto
a seguir. Trata-se de um artigo muito esclarecedor sobre agilidade e o
futuro das empresas.
https://www.infoq.com/br/articles/agile-survive-change/?itm_source=infoq&itm_campaign=footer_links&itm_medium=footer_links_category_page
software, servem para isso. A saber: 
Gráficos de burndown e burnup são usados para acompanhar o progresso do projeto e o
desempenho da equipe.
Figura 3 – Gráfico para visualização de progresso de sprints:
Burndown
Fonte: Reprodução
Exemplo de gráfico de burndown. “Estava previsto que no dia 1,
teríamos restantes 108 horas de trabalho; no entanto, foram
trabalhadas apenas 8 horas no projeto e não 12, por este motivo
Um gráfico de burndown acompanha o progresso do trabalho da equipe e o trabalho
restante a ser feito ao longo do tempo. Ele mostra o trabalho restante no eixo vertical e
o tempo no eixo horizontal. A linha de progresso ideal é uma linha reta do canto
superior esquerdo para o canto inferior direito, representando a quantidade de trabalho
que precisa ser feito e o tempo alocado para concluí-lo. A linha de progresso real
controla a quantidade de trabalho concluído pela equipe durante cada sprint e o
trabalho restante que ainda precisa ser feito. Aqui está um exemplo de um gráfico de
burndown:
teremos que compensar nos dias seguintes os dias não
trabalhados” (RIEPER, 2016, p. 2)
#ParaTodosVerem: representação do gráfico de burndown em fundo branco com
dois eixos, o vertical, na cor preta, representa a quantidade de horas acumuladas
nas histórias de usuários totais, no gráfico em questão elas estão representadas de
20 em 20 horas. No eixo horizontal, também na cor preta, há a descrição do tempo;
nesse exemplo contado em dias, da esquerda para a direita. Na primeira coluna, há
o total de horas depois do dia 1 até o dia 10. Há uma linha diagonal descendente
contendo o número 112 como o acumulado de horas planejadas que serão gastas
com o projeto; essa linha se inclina até atingir o 0 de trabalho a ser feito na origem
do eixo horizontal. A linha diagonal está na cor verde e os números variam em uma
sequência numérica regressiva, iniciando em 112 indo até zero em 10 dias. Há uma
outra linha em verde claro partindo da mesma forma que a linha vermelha em uma
diagonal descendente e mostrando a quantidade de horas realizadas na produção
dessas histórias em código, de forma que essa quantidade pode ser maior ou menor
que a planejada. Nesse exemplo, espera-se que se produzam 12 horas no dia 1, mas
a linha azul só indica a produção de 8 horas, portanto foram produzidas 4 horas a
menos do que o esperado. Esperava-se baixar de 120 horas para 112, mas foi
baixado apenas para 108. O gráfico burndown é criado no início de uma sprint e é
atualizado diariamente pela equipe Scrum. A cada dia, a equipe registra o trabalho
concluído e o trabalho restante, e o gráfico é atualizado com as novas informações.
Isso permite que a equipe veja o progresso em tempo real e faça ajustes conforme
necessário. Fim da descrição.
O gráfico de burnup é uma representação gráfica da quantidade de trabalho concluído
pela equipe ao longo do tempo. Ele mostra a quantidade de trabalho que foi concluída
no eixo vertical e o tempo no eixo horizontal. O gráfico é dividido em duas partes, o
trabalho concluído e o trabalho restante. Aqui está um exemplo de um gráfico de
burnup:
Figura 4 – Gráfico para visualização de progresso de sprints:
Burnup
Fonte: Reprodução
#ParaTodosVerem: desenho em tons de verde e preto, demonstrando um gráfico
de burnup. Ele mostra o progresso de um projeto Scrum ao longo do tempo,
exibindo a quantidade de trabalho completo em um eixo vertical, que está situado
na extrema direita do gráfico, numerado de 0% até 100%, e, em um eixo horizontal, o
tempo decorrido em dias. A linha diagonal no gráfico representa a quantidade de
trabalho completo ao longo do tempo. A linha na extrema esquerda começa em
zero, no início do projeto, e aumenta à medida que a equipe conclui as tarefas
planejadas. O objetivo é mostrar o progresso da equipe em direção ao objetivo final
do projeto, que é representado por uma linha reta diagonal na cor preta no gráfico.
Fim da descrição.
Se a linha do gráfico burnup estiver acima da linha reta, significa que a equipe está trabalhando maisdo que o planejado para concluir o projeto. Se a linha estiver abaixo da linha reta, significa que a
equipe está trabalhando menos do que o planejado.
O gráfico de burnup fornece uma visão mais abrangente do progresso da equipe, mostrando a
quantidade de trabalho concluído, o trabalho restante e o progresso geral em direção ao objetivo do
projeto.
O gráfico de burndown ajuda as equipes a monitorar seu progresso e identificar quaisquer desvios da
linha de progresso ideal. 
Criar o Backlog de Produto
No desenvolvimento ágil, um Product Backlog, ou em português, uma lista de pendências de
produto, é como o próprio nome diz: uma lista priorizada de recursos ou requisitos para um produto
que está em desenvolvimento. 
É um documento dinâmico que está em constante evolução (documentos novos entram e
documentos não necessários, ou que não serão mais desenvolvidos saem). Ou seja, à medida que
novas informações são aprendidas ou à medida que as prioridades mudam.
O processo de criação de uma lista de pendências do produto normalmente envolve a colaboração
entre o proprietário do produto (product owner), a equipe de desenvolvimento e quaisquer outras
partes interessadas relevantes. O proprietário do produto é responsável por definir e priorizar os
itens na lista de pendências com base em seu valor para o usuário final.
Para criar uma lista de pendências do produto, as seguintes etapas serão executadas:
Identificar as personas do usuário: quem são os usuários-alvo do produto?
Fazer um brainstorming sobre os recursos: quais são os recursos ou funcionalidades
potenciais que o produto deve ter para atender às necessidades dos usuários?
Priorizar os recursos: quais recursos são mais importantes ou valiosos para os usuários e
para a empresa?
Aqui está um exemplo simples de uma lista de pendências de produtos para um site de comércio
eletrônico bem geral:
Você já percebeu que a lista de pendências de produtos (backlog) consiste em uma lista de histórias
dos usuários; mas nem todas as histórias, porque novas podem aparecer e antigas simplesmente
podem deixar de ser necessárias. 
Portanto, o backlog pode incluir muito mais recursos e funcionalidades. A chave é priorizar os itens
na lista de pendências com base em seu valor para os usuários e os negócios, e refinar e atualizar
continuamente a lista de pendências à medida que o projeto progride.
Refinar e atualizar o backlog: à medida que o projeto progride, o backlog deve ser
continuamente refinado e atualizado com base em novas informações e mudanças de
prioridades.
Como cliente, quero poder criar uma conta para salvar minhas informações de frete e
faturamento;
Como cliente, quero ser capaz de pesquisar produtos por palavra-chave ou categoria
para que eu possa encontrar o que estou procurando rapidamente;
Como cliente, quero poder adicionar itens ao meu carrinho e visualizar meu carrinho
para que eu possa acompanhar o que estou comprando;
Como cliente, quero poder finalizar a compra e pagar meu pedido usando um método
de pagamento seguro;
Como cliente, quero receber um e-mail de confirmação com os detalhes do meu
pedido assim que ele for feito;
Como administrador do site, quero ser capaz de gerenciar pedidos de clientes e
acompanhar os níveis de estoque.
Aqui um outro exemplo de backlog de produto:
Figura 5 – Abstração de um Backlog de Produto
Fonte: Reprodução
#ParaTodosVerem: esquema retratando um exemplo macro de um backlog de
produto no SCRUM, o esquema utiliza a cor verde para ajudar na descrição. No
canto esquerdo do esquema há uma pilha de blocos em tom verde médio
contendo todas as histórias de usuários levantadas pelo Product Owner, lembrando
que supostamente estão todas as histórias nessa pilha, mas sabemos que com o
desenrolar das sprints do projeto haverá novas histórias ou o refinamento de outras
que poderão ser descobertas como épicos ou temas. No centro da imagem há uma
caixa de texto cujo contorno é verde, em seu interior está escrito: itens do
backlog do produto, e se refere a pilha anterior que definimos. Dessa caixa sai uma
linha que deriva em 4 novas linhas posicionadas mais à direita da imagem com os
dizeres: funcionalidades, defeitos, trabalhos técnico e aquisição de conhecimento.
Que são os itens que são retirados dessa pilha de backlog de forma a poderem ser
trabalhada no decursos da execução das sprints. Fim da descrição.
Sprints
Você deve se recordar que uma sprint é um período de uma a quatro semanas durante o qual uma
quantidade específica de trabalho é concluída pela equipe de desenvolvimento.
Preponderantemente no Brasil utilizamos uma sprint durando, em média, duas semanas. 
A ideia de uma sprint é entregar um incremento de produto potencialmente liberável no final de
cada iteração (outro nome para sprint). 
As sprints são parte fundamental do framework Scrum, que é uma das metodologias ágeis mais
populares atualmente em uso no mundo.
Cada sprint começa com uma reunião de planejamento de sprint, na qual a equipe de
desenvolvimento seleciona itens da lista de pendências do produto a serem concluídos durante a
sua execução. 
Ao longo da sprint, a equipe de desenvolvimento trabalha em conjunto para concluir as tarefas com
as quais se comprometeu na reunião de planejamento da sprint (sprint planning). Durante a sprint são
realizados check-ins diários para monitorar o progresso e identificar quaisquer obstáculos ou desafios
que surjam.
No final de cada sprint, a equipe de desenvolvimento conduz uma reunião de revisão da sprint (sprint
review), durante a qual apresenta o trabalho concluído às partes interessadas, coleta feedback e
planeja a próxima sprint (lembrando que não se planejam todas as sprints, no máximo duas; o comum
é uma, ou seja, a próxima, afinal tentar adivinhar todas as sprint é frontalmente contrário aos
princípios ágeis). 
A reunião de revisão da sprint oferece uma oportunidade de demonstrar o progresso feito durante a
sprint e coletar feedback importante, que pode ser usado para refinar a lista de pendências do
produto e ajustar o processo de desenvolvimento conforme necessário.
Para criar uma sprint, a equipe deve seguir as seguintes etapas:
Identificar o objetivo da sprint e definir as entregas;
Selecionar os itens da lista de pendências do produto que serão incluídos na sprint;
Apesar de já ter visto isso em disciplinas anteriores, aqui está um exemplo de como transformar uma
história de usuário em tarefas e atividades para uma sprint:
Tarefas associadas àquela declaração:
Dividir os itens selecionados em tarefas e atividades específicas que podem ser
concluídas durante a sprint;
Estimar o tempo necessário para cada tarefa ou atividade;
Criar um sprint backlog, que é uma lista das tarefas e atividades a serem concluídas
durante a sprint;
Definir um período para a sprint, normalmente entre 1 e 4 semanas;
Conduzir uma reunião de planejamento da sprint para revisar o backlog da sprint e
atribuir tarefas aos membros da equipe.
História de usuário: “Como cliente, quero ser capaz de pesquisar produtos no site, para
que eu possa encontrar o que eu preciso de forma rápida e fácil”.
Criar uma barra de pesquisa no site;
Implementar um algoritmo de pesquisa que permita aos usuários encontrar produtos
por palavra-chave, categoria ou faixa de preço;
Integrar a função de busca com a base de dados do site;
Projetar e implementar uma página de resultados de pesquisa que exiba produtos
relevantes e permita que os usuários classifiquem e filtrem seus resultados;
As sprints não são exclusividade do Scrum, elas são utilizadas em outras metodologias ágeis como
Kanban, Lean e XP. Portanto, seu nome pode variar, mas o propósito é o mesmo.
Vamos aproveitar também para recordar o que é um sprint backlog:
Sprint backlog é um subconjunto do product backlog que contém o conjunto de itens retirados do
product backlog que a equipe de desenvolvimento se comprometeu a entregar durante a
sprint atual. 
É um documento vivo que é atualizado ao longoda execução da sprint à medida que o progresso é
feito e as prioridades mudam. Ele ajuda a equipe de desenvolvimento a se concentrar no trabalho
que precisa ser feito durante a sprint, portanto dá direcionamento ao time.
O sprint backlog é criado durante a reunião de planejamento da sprint, na qual a equipe seleciona os
itens de alta prioridade do product backlog nos quais irão trabalhar durante a próxima sprint. Em
seguida, a equipe decompõe cada item selecionado em tarefas menores e mais gerenciáveis, estima
o esforço necessário para cada tarefa e as atribui aos membros da equipe.
À medida que o trabalho progride durante a sprint, a equipe atualiza o sprint backlog para refletir
quaisquer alterações no andamento ou nas prioridades. Isso permite que a equipe acompanhe seu
progresso para completar as metas da sprint e ajuste seus planos, se necessário.
Exemplo simples para ilustrar o conceito de um sprint backlog:
Suponhamos que o dono do produto tenha priorizado três itens para a próxima sprint:
Testar a função de pesquisa para garantir que ela esteja funcionando corretamente e
atenda aos critérios de aceitação.
Implementar um recurso de login para o aplicativo;
Permitir que os usuários redefinam suas senhas;
Durante a reunião de planejamento da sprint, a equipe de desenvolvimento divide cada item em
tarefas menores, estima o esforço necessário para cada tarefa e as atribui aos membros da equipe.
Como exemplo, o backlog dessa sprint tem o seguinte aspecto:
Ao longo da sprint, a equipe atualiza o sprint backlog para refletir seu progresso e quaisquer
mudanças nas prioridades.
Ao final da sprint, todo o trabalho do sprint backlog foi entregue e as metas foram atingidas.
Jogo do Planejamento
Melhorar o desempenho do recurso de pesquisa.
Implementar um recurso de login para o aplicativo: 
• Criar o formulário de login (2 horas, atribuído a Pedro);
• Implementar a funcionalidade de login (8 horas, atribuído a Katia);
Permitir que os usuários redefinam suas senhas: 
• Projetar o fluxo de redefinição de senha (3 horas, atribuído a Bruna);
• Implementar a funcionalidade de redefinição de senha (5 horas, atribuído a Antônia);
Melhorar o desempenho do recurso de pesquisa:
• Identificar gargalos de desempenho (4 horas, atribuído a Astolfo);
• Otimizar algoritmos de pesquisa (6 horas, atribuído a Jorge).
O Planning Poker, ou Poker de Planejamento em português, é uma técnica de estimativa colaborativa
usada por equipes ágeis para estimar o esforço necessário para completar uma história de usuário
ou uma tarefa. 
É uma maneira divertida e interativa de fazer com que os membros da equipe cheguem a um
consenso sobre o nível de esforço necessário para uma tarefa específica.
Vejamos como funciona:
Preparação: antes do início da sessão, a equipe já deve ter uma lista de histórias de
usuários ou tarefas que precisam estimar. O dono do produto ou scrum master deve
apresentar a lista de histórias de usuários ou tarefas para a equipe de uma forma que
todos possam entender;
Estimativa: a equipe se reúne para estimar cada história ou tarefa do usuário. O scrum
master seleciona uma história ou tarefa de usuário e a lê em voz alta para a equipe. Em
seguida, cada membro da equipe seleciona um cartão com um número que representa
o esforço necessário para concluir a tarefa. Os números nas cartas geralmente seguem
a sequência de Fibonacci (1, 2, 3, 5, 8, 13, 20, 40 etc.). Os números representam os pontos
de história, que são uma medida do nível de esforço necessário para concluir a tarefa.
Site
Neste momento talvez você esteja curioso sobre como é esse “baralho
ágil” certo? Bem aqui está um lugar para você baixar e imprimir para
treinar. Lembrando que cartas com o número zero (0) e meio (1/2) também
podem compor o “baralho” quando temos histórias muito simples.
Clique no botão para conferir o conteúdo.
ACESSE
As regras de planejamento do poker são simples e diretas:
Discussão: uma vez que cada membro da equipe selecionou um cartão, todos revelam
seus cartões ao mesmo tempo. Se houver um consenso sobre a estimativa, o scrum
master passa para a próxima história ou tarefa do usuário. Se houver uma diferença
significativa nas estimativas, os membros da equipe que selecionaram as cartas mais
altas e mais baixas explicam seu raciocínio. A equipe então discute as estimativas e
chega a um consenso sobre a estimativa;
Reestimativa: se as estimativas ainda não estiverem de acordo, os membros da equipe
que selecionaram as cartas mais altas e mais baixas têm outra chance de reestimar. A
equipe continua discutindo e reestimando até que haja um consenso sobre a estimativa;
Repetir: a equipe continua a estimar cada história de usuário ou tarefa até que toda a
lista seja concluída.
Todos da equipe participam do processo de estimativa;
Cada membro da equipe seleciona uma carta com um número que representa o nível
de esforço necessário para concluir a tarefa;
Ninguém revela sua estimativa até que todos tenham selecionado uma carta;
Se houver uma diferença significativa nas estimativas, os membros da equipe que
selecionaram as cartas mais altas e mais baixas explicam seu raciocínio;
https://bit.ly/3MZFZY7
O planejamento é uma ferramenta útil para equipes ágeis porque incentiva a colaboração e a
discussão, garantindo que todos tenham voz no processo de estimativa. Ao estimar em conjunto, a
equipe pode criar uma compreensão compartilhada do nível de esforço necessário para cada tarefa,
o que ajuda no planejamento e na priorização.
Talvez a essa altura do texto você queira um exemplo. Bem, aqui vai um bem simples:
A equipe continua a estimar cada história de usuário ou tarefa da mesma maneira até que tenham
concluído toda a lista.
Por outro lado, talvez você pense: “mas todo mundo usa estimativa por pontos de função e não o
poker de planejamento, certo?!”
A equipe discute as estimativas até que um consenso seja alcançado.
Imagine que uma equipe de desenvolvimento está trabalhando em um novo recurso
para um site. O recurso deve permitir que os usuários carreguem e compartilhem fotos.
O proprietário do produto criou uma história de usuário que descreve o recurso em
detalhes. A equipe se reúne para uma sessão de poker de planejamento para estimar o
nível de esforço necessário para completar a história do usuário;
O scrum master lê a história do usuário em voz alta para a equipe. Cada membro da
equipe seleciona um cartão com um número que representa o nível de esforço
necessário para concluir a tarefa. Um membro da equipe seleciona um 3, outro
seleciona um 5, outro seleciona um 8 e assim por diante;
O scrum master pede aos membros da equipe que selecionaram os 3 que expliquem
seu raciocínio. Os membros da equipe explicam que eles acham que o recurso é
relativamente simples de implementar, mas pode haver alguns desafios técnicos que
precisam ser resolvidos. A equipe então discute as estimativas e chega a um consenso
de que um nível de esforço de 5 pontos de história é mais apropriado.
Errado, o volume de equipes e empresas que estão preferindo a forma ágil de estimar tem
aumentado a cada dia de forma a tornar essa uma prática comum entre times de desenvolvimento.
De fato, as equipes ágeis preferem ouvir opiniões subjetivas de seus membros sobre a
complexidade da história do usuário em vez de confiar apenas em cálculos de ponto de função por
vários motivos. Aqui vão eles:
Portanto, embora os cálculos de ponto de função possam ser úteis em determinadas situações, as
equipes ágeis preferem confiar em opiniões subjetivas de seus membros sobre a complexidade da
Os cálculos de ponto de função podem ser demorados e podem exigir conhecimento e
ferramentas especializadas, que podem não estar disponíveis para todos os membros
da equipe. Por outro lado, estimar a complexidade de uma história de usuário com base
em opiniões subjetivas é um processo simples e direto que pode ser feito por qualquer
pessoa da equipe, baseado em sua experiência;
Os cálculosde ponto de função são baseados em dados históricos e suposições, que
podem não refletir com precisão o projeto atual ou as capacidades da equipe. Por outro
lado, opiniões subjetivas sobre a complexidade da história do usuário são baseadas no
conhecimento, na experiência e na compreensão coletiva da equipe sobre o projeto, o
que as torna mais relevantes e precisas;
Opiniões subjetivas sobre a complexidade da história do usuário promovem a
colaboração e a comunicação entre os membros da equipe, pois incentivam discussões
sobre a história e seus requisitos. Isso pode levar a uma melhor compreensão da história
e de seu impacto no projeto e, em última análise, resultar em uma estimativa mais
precisa;
Você deve se lembrar do manifesto ágil, que descreve que as equipes ágeis valorizam
indivíduos e interações em vez de processos e ferramentas. As opiniões subjetivas sobre
a complexidade da história do usuário se alinham a esse princípio. Ao incentivar os
membros da equipe a compartilhar suas opiniões e perspectivas, a equipe pode se
beneficiar do conhecimento e da experiência diversificados de seus membros e tomar
decisões mais bem informadas sobre o projeto.
história do usuário porque são mais simples, relevantes, incentivam a colaboração e a comunicação,
além de estarem alinhadas aos princípios ágeis. Isso é o que importa!
Indicações para saber mais sobre os assuntos abordados nesta disciplina:
 VÍDEOS 
Minicurso de Requisitos Ágeis – Parte 1
Você aprenderá os principais conceitos e práticas de requisitos ágeis.
Clique no botão para conferir o vídeo indicado.
ASSISTA
Minicurso de Requisitos Ágeis – Parte 2
Boas práticas para escrever requisitos ágeis.
Clique no botão para conferir o vídeo indicado.
ASSISTA
Minicurso de Requisitos Ágeis – Parte 3
Como escrever histórias de usuário.
Clique no botão para conferir o vídeo indicado.
2 / 8
Material Complementar
https://youtu.be/PZL4xa6diWo
https://youtu.be/MD8T4KsnPZA
ASSISTA
Minicurso de Requisitos Ágeis – Parte 4
Como escrever histórias de usuário.
Clique no botão para conferir o vídeo indicado.
ASSISTA
https://youtu.be/UCvWConFVeA
https://youtu.be/2tw5C--LXyw
Caro(a), estudante.
Agora, vamos compreender o cenário que será abordado na primeira situação-problema da
disciplina.
Atente-se à situação profissional que você precisará entender para poder realizar a atividade.
Desenvolvimento de Artefatos de Planejamento de Sistemas
de Informação Ágeis
E-commerce de Produtos Personalizados
A empresa X deseja desenvolver um e-commerce para venda de produtos personalizados, porém
enfrenta um obstáculo de tempo limitado. Devido à concorrência, a empresa não pode demorar mais
do que 4 meses para lançar o e-commerce; pelo método de desenvolvimento tradicional, no entanto,
esse processo levaria 12 meses e a instituição não sabe por onde começar. Você foi contratado para
resolver esse problema, portanto a solução proposta deve ser capaz de desenvolver o e-commerce
de produtos personalizados dentro do prazo de 4 meses. Qualquer solução que ultrapasse esse
prazo não será viável e a empresa pode perder mercado para a concorrência.
3 / 8
Situação-Problema 1
O que se espera de você como entrega ágil:
Escrita dos cartões de história do usuário para o e-commerce (ao menos 10);
Criação do backlog do produto (lista de itens priorizados com ao menos as 10 histórias
classificadas por ordem de valor agregado ao cliente do projeto);
Quebra do backlog em sprints para serem desenvolvidas, já com a conversão em
tarefas;
Criar o quadro Kanban com as tarefas.
Vamos compreender o cenário que será abordado na segunda situação-problema da disciplina.
Atente-se à situação profissional que você precisará entender para poder realizar a atividade.
A empresa Y precisa desenvolver um aplicativo para entrega de comida, mas enfrenta um obstáculo
de falta de experiência em desenvolvimento ágil. A equipe de desenvolvimento atual da empresa
não está familiarizada com os métodos ágeis e, portanto, não sabe por onde começar o projeto. A
solução foi contratar você, cuja proposta é capaz de desenvolver o aplicativo de entrega de comida
com a ajuda de métodos ágeis de desenvolvimento. Portanto, qualquer solução proposta que não
inclua o uso de metodologias ágeis não será considerada viável para a empresa.
Como consultor de agilidade, espera-se uma entrega mínima contendo os seguintes artefatos de
planejamento de sistemas ágeis:
4 / 8
Situação-Problema 2
O product backlog, ou seja, a lista de todas as funcionalidades do aplicativo que precisam
ser desenvolvidas, priorizadas de acordo com valor de negócio que cada uma delas
trará. No nosso caso, um backlog com 20 itens será suficiente;
A lista de tarefas específicas para cada sprint (sprint backlog), definidas durante o
planejamento da sprint a partir do product backlog. Espera-se ao menos a definição de 2
sprints completas e planejadas, já quebradas em tarefas.
Por fim, vamos compreender o último cenário, abordado na terceira situação-problema da disciplina.
Atente-se à situação profissional que você precisará entender para poder realizar a atividade.
A empresa Z precisa desenvolver uma plataforma de gerenciamento de projetos, mas enfrenta o
obstáculo de não saber como começar e de não ter experiência em metodologias ágeis para o
desenvolvimento. Além disso, a empresa não poderá contratar novos funcionários e precisará
trabalhar com o material humano existente. Você, como funcionário sênior, foi chamado para lidar
com esse desafio. Espera-se como solução a capacidade de desenvolver a plataforma de
gerenciamento de projetos em 6 meses, sem a contratação de novos funcionários. Qualquer solução
proposta que não leve em conta essas restrições não será considerada inviável para a empresa.
Para atender a essa restrição será importante trabalhar na capacitação do time existente, oferecendo
treinamentos e orientações sobre a metodologia Scrum. Uma técnica que pode ser utilizada é a
divisão da equipe em pequenos grupos, chamados de squads, de modo que cada grupo tenha um
objetivo específico a ser alcançado.
Os seguintes artefatos de planejamento são mandatórios nessa solução:
5 / 8
Situação-Problema 3
Escrita dos cartões de história do usuário para a plataforma de gerenciamento de
projetos (ao menos 5);
Criação do backlog do produto (lista de itens priorizados com ao menos as 5 histórias
classificadas por ordem de valor agregado ao cliente do projeto);
Quebra do backlog dessas 5 histórias em sprints para serem desenvolvidas (já
convertidas em tarefas);
Sua equipe tem 6 pessoas, quebre em 3 squads de 2 pessoas cada e agrupe as tarefas
por categoria para esses squads. Por exemplo: design e UX, back-end, front-end…;
Criar o quadro Kanban com as tarefas distribuídas por squads.
Orientações para o desenvolvimento de seu projeto.
Situação 1
Crie o backlog de produto, divida as tarefas em sprints, estime o tempo para cada atividade e
desenvolva um jogo de planejamento.
6 / 8
Problema em Foco
Importante!
Utilizaremos a situação 1 como exemplo mais detalhado do que se espera
em nível de artefatos para serem produzidos, para os outros vou descrever
orientações de forma mais sumarizada. Afinal, o desafio é para que você se
desenvolva.
Um backlog de produto é uma lista das histórias de usuário declaradas, priorizadas e com seu tempo
definido, a partir daí, os outros artefatos são desenvolvidos. Abaixo dou dois exemplos:
Exemplo de backlog para e-commerce de produtos personalizados:
História de usuário: como usuário, eu quero ser capaz de visualizar todos os produtos
personalizados disponíveis na loja, para que eu possa escolher o produto que melhor
atenda às minhas necessidades.
• Critérios de aceitação:
• A página inicial do e-commerce deve exibir todos os produtos disponíveis para venda;
• Deve haver uma opção de pesquisa para os usuários filtrarem os produtos por tipo,
preço, categoria etc.;
• Os produtos devem ser exibidos com uma descriçãobreve, imagem, preço e botão de
“Comprar”;
• Tempo estimado: 2 dias.
1
História de usuário: como usuário, eu quero ser capaz de personalizar o produto que
escolhi, para que ele atenda às minhas necessidades específicas.
• Critérios de aceitação:
• O usuário deve ser direcionado para uma página de personalização
após clicar em Comprar";
• Deve haver opções de personalização disponíveis, como escolha
de cor, tamanho, texto a ser inserido etc;
• Os usuários devem ser capazes de visualizar uma prévia do
produto personalizado antes de adicioná-lo ao carrinho de compras.
2
Lembrando que um backlog de produto é composto de muitas histórias postas dessa forma, afinal é
um sistema inteiro, certo?! No caso desse desafio, acredito que ao menos 20 histórias como as do
exemplo que dei, serão suficientes para que você ganhe experiência.
Com base nas histórias de usuário criadas, podemos elaborar sprints de 2 semanas para o
desenvolvimento do e-commerce de produtos personalizados. Segue abaixo uma sugestão:
Sprint 1 (duração de 2 semanas):
Histórias de usuário:
Atividades:
• Tempo estimado: 4 dias.
Como usuário, eu quero ser capaz de selecionar produtos personalizados para que eu
possa escolher o que quero comprar;
Como usuário, eu quero ser capaz de personalizar meus produtos para que eu possa ter
um produto único e exclusivo;
Como usuário, eu quero ser capaz de adicionar produtos personalizados ao meu
carrinho de compras para que eu possa finalizar a compra.
Definir as opções de produtos personalizados disponíveis para compra;
Desenvolver a funcionalidade de personalização de produtos;
Integrar a funcionalidade de carrinho de compras ao sistema;
Sprint 2 (duração de 2 semanas): 
Histórias de usuário:
Atividades:
Lembrando que essas são sugestões e que a quebra de um product backlog em sprints é muito maior
que essas duas sprints que ofereci.
Você deve ir além disso. Espero ao menos o dobro de sprints, diferentes das que ofereci como
exemplo.
Desenvolver o layout das páginas de seleção de produtos, personalização e carrinho de
compras.
Como usuário, eu quero ser capaz de finalizar a compra de forma segura para que eu
possa receber meus produtos com tranquilidade;
Como usuário, eu quero ser capaz de acompanhar o status do meu pedido para que eu
possa saber quando ele será entregue;
Como usuário, eu quero ser capaz de avaliar meus produtos e a experiência de compra,
para que eu possa fornecer um feedback para a empresa.
Desenvolver a funcionalidade de checkout seguro;
Desenvolver a funcionalidade de rastreamento de pedidos;
Desenvolver a funcionalidade de avaliação de produtos e experiência de compra;
Realizar testes de integração e usabilidade do sistema.
Feito isso, você deverá criar o quadro Kanban, mas, antes disso, deverá quebrar as histórias do
usuário em atividades para colocar no quadro. Afinal, uma história de usuário não é uma lista de
coisas a serem feitas, apenas o desejo manifestado pelo usuário do que ele deseja.
Você pode fazer isso conforme o seguinte exemplo de decomposição de história de usuário:
Como usuário, eu quero ser capaz de navegar pelo site, para encontrar os produtos que desejo.
Tarefas:
Aí espero que você crie um quadro Kanban como no exemplo abaixo:
Quadro 1
Sprint Backlog A fazer Fazendo Feito
Seleção
Produtos.
Estudar
possibilidades
de produtos
personalizados
Analisando
possíveis
produtos.
Desenvolvida
lista de
produtos.
Definir a estrutura de navegação do site;
Criar a página inicial com as principais categorias de produtos;
Criar as páginas de categorias e subcategorias de produtos;
Implementar a barra de busca;
Criar a página de resultados de busca.
Sprint Backlog A fazer Fazendo Feito
a serem
disponibilizados.
Personalização.
Estudar
possibilidades
de
personalização
de cada
produto.
Analisando
possíveis
personalizações.
Definida
personalização
para cada
produto.
Carrinho de
Compras.
Analisar opções
de integração
do carrinho de
compras com a
loja.
Integrando
carrinho de
compras ao
sistema.
Carrinho de
compras
integrado ao
sistema.
Layout.
Analisar opções
de design para
as páginas de
seleção de
produtos,
personalização
e carrinho de
compras.
Desenvolvendo
layout das
páginas.
Páginas de
seleção de
produtos,
personalização
e carrinho de
compras
finalizadas.
Aqui eu já coloquei no exemplo o que é possível preencher em todas as colunas, assim fica mais
fácil para você poder colocar na coluna certa o andamento e o tipo de status esperado.
Muita gente acredita que só cartões gráficos podem ser utilizados, mas isso não é verdade. Podemos
utilizar texto, como eu fiz.
Então, agora você poderá criar o quadro Kanban baseado nesse exemplo; é mais tranquilo.
Situação 2
Converta os requisitos ágeis em itens de projeto e atividades, crie o backlog de produto, utilize sprints
semanais e desenvolva um jogo de planejamento.
Aqui a única diferença é que te convidamos a realizar o jogo do planejamento ou Planning Poker.
Lembra-se de como é? Aqui vai um reforço.
Participantes: equipe de desenvolvimento e product owner.
Passo a passo:
Apresentação da história: o product owner apresenta a história para a equipe, explicando
a importância dessa funcionalidade para o negócio;
1
Discussão das tarefas: a equipe discute cada uma das tarefas necessárias para
implementar a funcionalidade de adicionar produtos ao carrinho de compras. Durante
essa discussão, a equipe pode adicionar novas tarefas ou remover tarefas
desnecessárias;
2
Priorização das tarefas: o product owner prioriza as tarefas em ordem de importância
para o negócio, levando em consideração os critérios estabelecidos previamente;
3
Estimativa de tempo: a equipe estima o tempo necessário para cada uma das tarefas,
levando em consideração a complexidade e os recursos necessários;
4
Definição das tarefas da sprint: com base nas prioridades estabelecidas e nas estimativas
de tempo, a equipe define as tarefas que serão executadas na primeira sprint;
5
É claro que você vai simular o jogo, para tanto imprima as cartas do jogo de poker de planejamento
baseado na série de Fibonacci, como mostrado no material didático.
Situação 3
Crie o backlog de produto, defina as sprints, utilize artefatos ágeis e desenvolva um jogo de
planejamento.
Da mesma forma que foi feito no desafio 2, realize as atividades na ordem correta para um resultado
melhor.
Lembre-se que os desafios são diferentes, porque os negócios explorados são diferentes apesar de
terem artefatos semelhantes. A ideia aqui é que você conheça negócios diferentes para aumentar
seu repertório de modelagem, utilizando a pesquisa, solução de problemas e muita criatividade,
coisa que são absolutamente mandatórias a um analista e desenvolvedor de sistemas de informação.
Planejamento da sprint: a equipe se reúne para definir as datas de início e de fim da
sprint, bem como as metas e os objetivos que serão alcançados ao final da sprint.
6
Divisão de responsabilidades: cada membro da equipe é responsável por uma ou mais
tarefas da sprint e se compromete a entregá-las dentro do prazo estabelecido.
7
Revisão e ajustes: ao final da sprint, a equipe se reúne para revisar o trabalho realizado e
fazer ajustes para a próxima sprint, se necessário.
8
Muito bem, estudante.
Agora que você já leu todas as situações-problema, você pode
fazer o download deste arquivo para realizar a atividade de
entrega.
Caso prefira, o arquivo também se encontra no Ambiente Virtual
de Aprendizagem.
7 / 8
Atividade de Entrega
https://bb.cruzeirodosulvirtual.com.br/bbcswebdav/xid-135968949_1
RIEPER, M. Gráfico Burndown Scrum Excel. Guia do Excel, 19/06/2016. Disponível em:
<https://www.guiadoexcel.com.br/grafico-burndown-scrum-excel/>. Acesso em: 28/04/2023.
8 / 8
Referências
 Muito bem, estudante! Você concluiu o material de estudos! Agora,
volte ao Ambiente Virtual de Aprendizagem para realizar a Atividade.