Projeto Integrador Transdisciplinar em Análise e

Desenvolvimento de Sistemas II

Conteudista: Prof. Me. Artur Marques

Revisão Textual: Esp. Danilo Coutinho de Almeida Cavalcante

Material Teórico

Material Complementar

DESAFIO

Situação-Problema 1

Situação-Problema 2

Situação-Problema 3

Problema em Foco

ATIVIDADE
 Atividade de Entrega

R EFER ÊN CIAS

Referências
1/8

Material Teórico

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.

 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.

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
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árias para 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:

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.

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 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;

 • Subtarefa 1.2: obter feedback das partes interessadas sobre wireframes;

• Subtarefa 1.3: revisar wireframes com base no feedback das partes interessadas.

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:

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.
 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.

Clique no botão para conferir o conteúdo.

 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,
 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 promovem a 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:

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;

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:

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;

 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.

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.

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.

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
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.

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:

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
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 mais
do 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?
 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.

Aqui está um exemplo simples de uma lista de pendências de produtos para um site de comércio
eletrônico bem geral:

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.

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.
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;

 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.

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:

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”.

Tarefas associadas àquela declaração:

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;
 Testar a função de pesquisa para garantir que ela esteja funcionando corretamente e
atenda aos critérios de aceitação.

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 longo da 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:

Implementar um recurso de login para o aplicativo;

Permitir que os usuários redefinam suas senhas;

 Melhorar o desempenho do recurso de pesquisa.

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:

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).

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
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

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.

As regras de planejamento do poker são simples e diretas:

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;
 A equipe discute as estimativas até que um consenso seja alcançado.

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:

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.

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?!”
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:

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álculos de 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.

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
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!
2/8

Material Complementar

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.

 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
3/8

Situação-Problema 1

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.
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.

4/8

Situação-Problema 2

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:

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.
5/8

Situação-Problema 3

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:

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.

6/8

Problema em Foco

Orientações para o desenvolvimento de seu projeto.

Situação 1

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.

Crie o backlog de produto, divida as tarefas em sprints, estime o tempo para cada atividade e
desenvolva um jogo de planejamento.
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:

1 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ção breve, imagem, preço e botão de
“Comprar”;

• Tempo estimado: 2 dias.

História de usuário: como usuário, eu quero ser capaz de personalizar o produto que
2
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.
 • Tempo estimado: 4 dias.

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:

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.

Atividades:

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;

 Desenvolver o layout das páginas de seleção de produtos, personalização e carrinho de
compras.

Sprint 2 (duração de 2 semanas):

Histórias de usuário:

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.

Atividades:

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.

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.
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:

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.

Aí espero que você crie um quadro Kanban como no exemplo abaixo:

Quadro 1

Sprint Backlog A fazer Fazendo Feito

Seleção Estudar Analisando Desenvolvida

Produtos. possibilidades possíveis lista de
de produtos produtos. produtos.
personalizados
 Sprint Backlog A fazer Fazendo Feito

a serem
disponibilizados.

Estudar
possibilidades Definida
Analisando
de personalização
Personalização. possíveis
personalização para cada
personalizações.
de cada produto.
produto.

Analisar opções
Integrando Carrinho de
de integração
Carrinho de carrinho de compras
do carrinho de
Compras. compras ao integrado ao
compras com a
sistema. sistema.
loja.

Analisar opções
Páginas de
de design para
seleção de
as páginas de
Desenvolvendo produtos,
seleção de
Layout. layout das personalização
produtos,
páginas. e carrinho de
personalização
compras
e carrinho de
finalizadas.
compras.

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:

1 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;

2 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;

3 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;

4 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;

5 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;
 6 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.

7 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.

8 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.

É 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.
7/8

Atividade de Entrega

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.
8/8

Referências

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.

 Muito bem, estudante! Você concluiu o material de estudos! Agora,

volte ao Ambiente Virtual de Aprendizagem para realizar a Atividade.