Processo de Desenvolvimento Ágil

Cuiabá - MT
Julho/2024

1
Sumário
1. Introdução...........................................................................................................................3
1.1. Convenções, termos e abreviações............................................................................ 3
1.2. Relacionamento entre produto, tema, épico e histórias.............................................. 5
1.3. Processo de desenvolvimento e manutenção.............................................................5
1.4. Conect@/Agile Development...................................................................................... 7
1.5. Funções de usuário.....................................................................................................9
2. Exemplos práticos de desenvolvimento ágil................................................................ 10
2.1. Entrega baseada na versão...................................................................................... 10
2.2. Entrega baseada em projeto..................................................................................... 11
2.3. Entrega baseada em versão x baseada em projeto..................................................13
2.4. Desenvolvimento de projeto autônomo.....................................................................13
3. Agile Development > Quadro ágil...................................................................................15
4. Agile Development > Defeitos e Melhorias....................................................................19
4.1. Relatando defeitos encontrados................................................................................19
4.2. Solicitando melhorias................................................................................................ 19
4.3. Backlog unificado...................................................................................................... 20
5. Configuração do Sistema................................................................................................ 22
5.1. Instalação do módulo Agile Development 2.0........................................................... 22
Referências...........................................................................................................................24

2
1. Introdução
A metodologia ágil utiliza uma abordagem de gerenciamento iterativo no gerenciamento de
projetos e no desenvolvimento de software de forma que ajuda os times a entregar valor
aos seus clientes mais rapidamente e com menos “dores de cabeça”, se comparado com a
abordagem tradicional (cascata).

O Scrum é uma das metodologias populares de Agile Development, que inclui uma
programação de sprint fixa e testes de requisitos regulares. Essas atividades são realizadas
por funções comuns, como product owner, scrum master e membros do grupo.

1.1. Convenções, termos e abreviações

Backlog

Lista de trabalhos que devem ser implementados, como parte da obtenção de resultados
específicos. O backlog contém trabalho relacionado a novos recursos, aprimoramentos de
recursos existentes e outras atividades de desenvolvimento do produto. O backlog é
considerado a única fonte de trabalho para um produto ou equipe. Qualquer coisa que não
esteja incluída no backlog não será priorizada para desenvolvimento.

Backlog de Sprint

Escopo de trabalho para um sprint. Os product owners e suas equipes de desenvolvimento

usam a atividade de planejamento de sprint para revisar seu backlog e decidir sobre as
histórias a serem selecionadas para um sprint.

Backlog pessoal

Os responsáveis pelo produto definem um pipeline de trabalho personalizado chamado

backlog pessoal, aplicando critérios de filtro relevantes. Os responsáveis pelo produto
podem definir quantos backlogs personalizados forem necessários. Os critérios usados para
criar o backlog personalizado são flexíveis e podem ser modificados a qualquer momento.

3
Depois de criar histórias e tarefas de scrum para seus produtos, você pode criar um backlog
personalizado contendo as histórias de um ou mais desses produtos.

Épico

Definição de alto nível de um requisito que agrega valor ao negócio, como um novo recurso
ou uma melhoria significativa. Os épicos são divididos em histórias do Agile e podem ser
trabalhados por uma ou várias equipes.

Grupo de atribuição ou equipe Agile

Grupo multifuncional de profissionais envolvidos no trabalho e na conclusão do

desenvolvimento de um produto Agile. Em um grupo de atribuição, um dos integrantes é
designado como Scrum Master, que é responsável por assegurar que todas as atividades
de Scrum sejam realizadas corretamente para uma versão.

História

Trabalhos curtos e gerenciáveis relacionados a um épico. As histórias capturam quem, o

quê e o motivo de um requisito de maneira simples e concisa, utilizando formato: Como um
<papel> <eu quero|eu preciso de|devo|gostaria de> <ação> para <benefício|objetivo>.
Usando a descrição e os critérios mencionados nas histórias, as equipes podem estimar
com precisão o esforço necessário para implementar o trabalho nele. Exemplos:

● Como cliente eu quero consultar os apartamentos pela web para facilitar a reserva.
● Como um cliente eu quero consultar os pagamentos realizados no portal da
operadora para que possa controlar minhas contas.
● Como cliente eu quero imprimir a segunda via do boleto de pagamento pelo portal
da operadora para que não tenha que ir à operadora.
● Como cliente eu quero imprimir o relatório e comprovante de pagamentos pelo portal
da operadora para que eu possa controlar as minhas contas.

Produto

Entidade para organizar temas, épicos e histórias de funcionalidade semelhante em um

único contexto. Um produto representa um item ou recurso que deve ser desenvolvido e
lançado no mercado.

Sprint

Períodos curtos, de até um mês, e fixos em que os membros da equipe escolhem e

concluem um determinado número de histórias. Esses ciclos curtos e com intervalo de
tempo fornecem às equipes a flexibilidade para se adaptar às mudanças de prioridades. A
cadência de recorrência de um sprint é decidida pelas equipes de desenvolvimento e pelos
responsáveis pelo produto. Por exemplo, um sprint de 10 dias ou um sprint de 1 semana.

Tarefa de scrum

Tarefas distintas que são necessárias para concluir uma história. Uma tarefa pode levar de
4 a 12 horas para ser concluída. Exemplos:

4
Tema

Área de foco com um valor de negócio associado. Um tema está relacionado a um ou mais
objetivos da organização. Os temas ajudam a priorizar seu trabalho em alto nível e podem
ser associados a vários épicos.

Versão

Uma versão tem uma data de início e término durante a qual várias iterações (sprints) de
desenvolvimento são concluídas. As versões são criadas por um product owner e contêm
histórias de usuários, às vezes de vários produtos, e também podem envolver várias
equipes. As histórias associadas a uma versão formam seu backlog de versão. Certifique-se
de criar um produto antes de criar temas, épicos ou histórias. Você não pode publicar esses
registros sem anexá-los a um produto.

1.2. Relacionamento entre produto, tema, épico e histórias

A imagem abaixo mostra como o produto, temas, épicos e histórias se relacionam:

1.3. Processo de desenvolvimento e manutenção

O processo de desenvolvimento e manutenção é baseado no Scrum, ilustrado a seguir,
consistindo nas atividades a seguir. Observação: O sprint deve ser de uma a quatro

5
semanas (mês), de forma fixa para cada grupo de atribuição (time), favorecendo uma
cadência regular.

Planejamento de sprint

Os membros do grupo de atribuição se reúnem para decidir sobre as histórias que podem
se comprometer a entregar no sprint. Normalmente, eles se comprometem com as histórias
com melhor classificação primeiro. O grupo decide quais tarefas de scrum são necessárias
para cada história. O product owner deve estar presente para responder a quaisquer
perguntas.

Reunião diária

Os membros do grupo de atribuição se reúnem para discutir o andamento do trabalho do

dia anterior, o trabalho planejado para o dia atual e quaisquer impedimentos. A atualização
diária mantém os membros do grupo focados em concluir as histórias do sprint atual e
informa o scrum master de quaisquer impedimentos externos. Os impedimentos internos
devem ser resolvidos pelos membros do grupo de atribuição. No final do sprint todas as
histórias que atendam ao objetivo do sprint devem estar concluídas, produzindo um
incremento. Todas as histórias incompletas deverão ser movidas de volta para o backlog ou
para um sprint futuro.

Revisão de sprint

As reuniões de revisão de sprint são realizadas no final de cada sprint. Nessas reuniões, o
grupo de atribuição revisa o trabalho concluído e demonstra os recursos recém-
desenvolvidos ao responsável pelo produto (stakeholders), obtendo feedback. Esta reunião

6
também pode gerar novas histórias que serão inseridas no backlog, para refinamento
posterior.

Retrospectiva de sprint

Uma reunião de retrospectiva é realizada no final de cada sprint, após a revisão de sprint,
para facilitar a discussão entre os membros do grupo sobre o que deu certo e o que não
deu certo. O objetivo de uma retrospectiva de sprint é discutir maneiras de melhorar a
execução de sprints futuros.

1.4. Conect@/Agile Development

O fluxo apresentado aqui representa a prática adotada para gerenciar os esforços de
desenvolvimento do Agile usando a funcionalidade disponível na aplicação Agile
Development 2.0 do Conect@.

Definir produtos

Um produto pode ser um conjunto de recursos ou funcionalidades oferecidos aos usuários.

Cada produto pode ter um proprietário que mantém o pipeline de trabalho, como épicos e
histórias, para o produto. Esses itens de trabalho podem ser associados a um tema, que
está relacionado a um objetivo de negócios.

Criar épicos e histórias

Os épicos contêm requisitos de alto nível para seus produtos, que você pode usar para
dividir em histórias gerenciáveis. Ao criar épicos e histórias em Agile Development 2.0, você
pode associá-los a um produto e/ou projeto.

Criar versões

Pode-se adotar um intervalo de tempo fixo para disponibilizar os produtos ao mercado,

gerando uma nova versão. Uma versão tem uma data de início e término, durante as quais
várias iterações (sprints) de desenvolvimento são concluídas, que podem possuir produtos,
épicos e histórias associados a ela. Por exemplo, você pode ter programações trimestrais
ou semestrais para lançar novos aplicativos ou aprimoramentos em aplicativos existentes.

Criar backlog personalizado

Um backlog personalizado pode ser criado definindo critérios de filtro. Por exemplo, um
backlog personalizado pode ser uma combinação de histórias, defeitos e incidentes,
enquanto o outro backlog personalizado pode ser uma combinação de histórias e

7
incidentes. Dessa forma, você pode criar quantos backlogs personalizados forem
necessários.

Criar grupos de atribuição

Crie um grupo de atribuição e adicione membros a ele. Para cada membro do grupo, defina
o número de pontos da história que eles podem concluir em um sprint. No nível do grupo, a
soma dos pontos da história de todos os membros do grupo determina a capacidade do
grupo.

Criar sprints

Um sprint é o intervalo de tempo no qual a equipe de desenvolvimento entrega uma ou mais

histórias. Um sprint pode ter qualquer tamanho, mas normalmente leva entre uma e quatro
semanas para ser concluído. O grupo scrum cria o número de sprints necessários para o
grupo e esses sprints são usados pelos membros do grupo para concluir o trabalho
necessário para uma versão futura. No entanto, todos os sprints de uma versão devem
estar dentro das datas de início e término da versão.

Planejar atividades de sprint

Antes do início de um sprint, o grupo e o product owner, com o apoio do scrum master,
decidem quais histórias do backlog podem confirmar para concluir em um sprint. As
histórias de um sprint devem ser selecionadas com base na prioridade. O scrum master
deve assegurar que o esforço (total de pontos da história) necessário para concluir as
histórias corresponda à capacidade do grupo.

Ao planejar seus sprints, você pode usar os relatórios de velocidade como orientação para
estimar a quantidade de trabalho que o grupo pode concluir no próximo sprint. O Painel da
Equipe do Agile 2.0 fornece relatório de histórico de velocidade e relatório de velocidade
por tipo.

● Histórico de velocidade: obtenha informações sobre a velocidade geral da equipe

nos últimos 10 sprints. Analise se a equipe está alcançando uma velocidade estável
e previsível e está cumprindo os compromissos.
● Velocidade por tipo: analise como a velocidade da sua equipe muda ao longo do
tempo e compare a carga de trabalho estratégica da equipe com a operacional ou
outros tipos de carga de trabalho.

Acompanhar o andamento do sprint

O scrum master acompanha os esforços da equipe de sprint, fornece relatórios de

andamento e facilita a remoção de todos os bloqueadores que a equipe encontra. Os
membros da equipe atualizam os registros da história e realizam reuniões diárias para
discutir seu progresso e comunicar as preocupações ao scrum master e aos proprietários
do produto.

Espera-se que a equipe conclua todas as histórias confirmadas para um sprint. O scrum
master assegura que as histórias sejam totalmente testadas e estejam prontas para
lançamento, de acordo com os critérios de aceitação.

8
O ideal é que as histórias confirmadas e o escopo de um sprint específico não sejam
alterados enquanto o sprint estiver em andamento. Existe flexibilidade para atualizar o
backlog do sprint conforme necessário para se adaptar às mudanças de prioridades. No
entanto, as histórias devem ser adicionadas ou removidas de um sprint somente após uma
discussão entre o grupo, o scrum master e o product owner.

Você pode usar o Painel de Sprint do Agile 2.0 com relatórios como gráficos de burnup e
burndown para rastrear o andamento da equipe em um sprint.

Acompanhar o andamento da versão

O product owner rastreia o andamento da versão e verifica se a equipe está concluindo

histórias no ritmo necessário para atingir o objetivo da versão.

Você pode usar o Painel de Liberação do Agile 2.0 com relatórios como burnup, burndown
e gráficos de tempo de ciclo para rastrear o andamento da equipe de uma versão.

Melhorias e defeitos

Durante o ciclo de vida adotado, defeitos e oportunidades de melhoria do produto podem

ser encontrados. As melhorias e defeitos podem ser filtradas no Quadro Ágil, compondo o
backlog do produto, para posterior refinamento e tratamento dos mesmos, podendo ser
criadas histórias relacionadas e para que sejam incluídas em sprints posteriores.

1.5. Funções de usuário

Cada usuário possui uma função específica, utilizada para os diferentes propósitos:

Função Propósito

scrum_user Usuário básico, com acesso somente de leitura para

histórias, épicos e defeitos

scrum_admin Acesso administrativo completo na plataforma Agile

Development

scrum_master Criar e modificar produtos, temas e versões

scrum_release_planner Criar e gerenciar produtos, temas e versões

scrum_product_owner Criar e modificar produtos, temas e sprints

scrum_sprint_planner Criar e modificar sprints e histórias

scrum_team_member Acesso para criação e alteração de histórias, épicos e

defeitos

Para alterar a permissão de algum usuário específico, o administrador do Conect@ deverá

acessar a lista de usuários, usando o menu Administração de usuários > Usuários.

Ficou definido que os grupos de atribuição (times) possuirão as seguintes funções:

scrum_master. scrum_product_owner e scrum_team_member.

9
2. Exemplos práticos de desenvolvimento ágil
Conheça os diferentes métodos que as organizações podem usar para planejar o backlog e
entregar histórias.

Alguns métodos de entrega comuns são:

● Entrega baseada na versão

● Entrega baseada em projeto
● Desenvolvimento de projeto autônomo

Pode-se manter um backlog unificado que pode ser usado para tipos de entrega baseados
em projeto ou versão. Todo o backlog pode ser mantido em um só lugar e ser associado às
histórias de um produto, projeto ou ambos. Também pode-se selecionar histórias do backlog
e executá-las como um projeto, como um desenvolvimento de projeto autônomo.

O exemplo a seguir mostra como o desenvolvimento ágil pode ser aplicado para utilizar um
backlog unificado para entregas baseadas em projeto e em versão.

2.1. Entrega baseada na versão

Esta seção apresenta um exemplo de desenvolvimento baseado em versão. As atividades
usuais envolvidas em um desenvolvimento ágil baseado em versão são:

● Manter o backlog do produto: os product owners mantêm o backlog do produto. Eles

refinam continuamente seus backlogs adicionando histórias, priorizando e
estimando-os. Em Agile Development 2.0, navegue até Agile Development >
Histórias para obter a lista de todas as histórias. Você pode filtrar a lista para um
produto específico.

10
 ● Planejamento de versão: as organizações têm ciclos de versão definidos, como
versão trimestral, versão semestral e versão anual. Os product owners selecionam
as histórias priorizadas do backlog do produto que devem ser concluídas em uma
determinada versão para formar o backlog da versão.
● Atribuição de histórias: em Agile Development 2.0, navegue até Agile Development
> Histórias. Selecione as histórias que você deseja atribuir a uma versão e
selecione Atribuir a versão/grupo. Especifique uma equipe à qual você deseja
associar essas histórias.
● Planejamento de sprint: as equipes de scrum definem sua programação de sprint,
como sprint de duas semanas ou sprint de três semanas. Eles trabalham com o
product owner e selecionam histórias do backlog de versão que devem ser
concluídas em cada sprint para criar o backlog de sprint. Os membros do grupo,
junto com o proprietário do produto e o scrum master, decidem as histórias de cada
sprint usando o Planejamento de sprint. Em Agile Development 2.0, navegue até
Agile Development > Quadro ágil > Planejamento de sprint.

A ilustração a seguir fornece uma visão geral de alto nível do fluxo de trabalho em um
ambiente baseado em versão.

2.2. Entrega baseada em projeto

Veremos, nesta seção, um exemplo de desenvolvimento baseado em projeto. As atividades
usuais envolvidas em um projeto baseado em desenvolvimento ágil são:

● Backlog do produto: os product owners mantêm o backlog do produto. Eles refinam

continuamente seus backlogs adicionando histórias, priorizando e estimando-os. Em
Agile Development 2.0, navegue até Agile Development > Histórias para obter a
lista de todas as histórias.

11
 ● Backlog do projeto: os product owners selecionam as histórias priorizadas e as
atribuem a um ou mais projetos, criando assim o backlog do projeto. Os product
owners podem criar um ou mais projetos e capturar detalhes adicionais, como
recursos necessários, custo, risco e alinhamento estratégico. Todos esses projetos
passam pelo processo de priorização de portfólio e os projetos selecionados são
executados pelas equipes de projeto.

Atribuindo histórias a projeto

Em Agile Development 2.0, navegue até Agile Development > Histórias e selecione
Atribuir ao projeto para atribuir histórias a um projeto novo ou existente.

Você também pode abrir um projeto existente e associar histórias do backlog ao projeto.
Essas histórias são executadas como parte da execução do projeto.

Atribuição de histórias a grupos e planejamento de sprint

● Atribuição de histórias: atribua as histórias do projeto a um grupo de atribuição para

que a equipe possa selecioná-las nos próximos sprints. Em Agile Development 2.0,
selecione as histórias que você deseja atribuir a uma versão, selecione Atribuir a
versão/grupo e especifique um grupo de atribuição.
● Planejamento de sprint: as equipes de scrum definem sua programação de sprint,
como sprint de duas semanas ou sprint de três semanas. Eles trabalham com o
product owner e selecionam histórias do backlog de versão que devem ser
concluídas em cada sprint para criar o backlog de sprint. Os membros do grupo,
junto com o product owner e o scrum master, decidem as histórias de cada sprint
usando o Planejamento de sprint. Em Agile Development 2.0, navegue até Agile
Development > Quadro ágil > Planejamento de sprint.

A ilustração a seguir fornece uma visão geral de alto nível do fluxo de trabalho em um
ambiente baseado em projeto.

12
2.3. Entrega baseada em versão x baseada em projeto
A ilustração abaixo compara as duas abordagens, de forma mais detalhada, incluindo os
temas, épicos, defeitos, melhorias e tarefas no relacionamento:

Nesta ilustração, podemos perceber que o módulo de desenvolvimento ágil é flexível o

suficiente para conseguir abordar as mais variadas necessidades de configuração de
relacionamentos entre os elementos que fazem parte de um projeto e/ou produto.

Cada time pode adotar o formato mais adequado e conveniente, dependendo das
características do produto que está sendo desenvolvido ou mantido.

2.4. Desenvolvimento de projeto autônomo

A seguir temos um exemplo de desenvolvimento de projeto autônomo. Nesse caso, uma
solicitação (demanda) de um novo produto, recurso ou sistema é gerada. Os gerentes de
demanda capturam os requisitos em termos de histórias. Eles também capturam outros
detalhes da demanda, como recursos necessários, custo, riscos e direção estratégica.
Essas demandas são convertidas em projetos após a aprovação. Os gerentes de projeto
podem escolher o modo ágil puro ou híbrido de execução de projeto. No modo híbrido, as
fases iniciais, como planejamento e análise, são realizadas como tarefas em cascata e, em
seguida, a execução é feita como fase ágil. A fase ágil é atribuída a um grupo ágil. O grupo
ágil conclui o trabalho através da execução de sprints.

A ilustração a seguir fornece uma visão geral de alto nível do fluxo de trabalho para
executar um desenvolvimento de projeto autônomo.

13
Uso do Agile Development 2.0 para desenvolvimento de projetos híbridos autônomos

Etapas para executar um projeto híbrido autônomo:

1. Criar demanda: capturar requisitos no estado de demanda em termos de histórias de

usuários. Usar a lista relacionada Histórias no formulário de demanda para criar
histórias.
2. Conversão de demanda para projeto: quando a demanda é convertida em um
projeto, as histórias de demanda são movidas para o projeto para que a equipe do
projeto (grupo de atribuição) possa executá-las. Durante a conversão, uma fase ágil
também é criada e as histórias são atribuídas à fase ágil.
3. Planejamento de sprint: os membros do grupo Agile, junto com o gerente de projeto
e o scrum master executam o planejamento de sprint. Navegar até Agile
Development > Quadro ágil > Planejamento de sprint para planejar sprints.

14
3. Agile Development > Quadro ágil
O quadro ágil é uma página principal na qual você pode executar ações importantes do
processo de scrum, como gerenciar seu backlog, planejar seus sprints e acompanhar o
andamento do sprint.

O quadro ágil está organizado nas seguintes guias para ajudá-lo a gerenciar essas
atividades. Você precisaria de uma ou mais das seguintes funções de usuário
scrum_admin, scrum_master, scrum_product_owner ou scrum_sprint_planner.

Backlog

A guia Backlog ajuda a gerenciar seus backlogs personalizados. Na guia Backlog, você
pode:

● Criar histórias, épicos e temas.

● Exibir todas as histórias ativas que estão atribuídas a uma equipe, mas que não
estão atribuídas a nenhum sprint.
● Exibir cartões indicando o número total de histórias, histórias que não têm pontos de
história e histórias que não têm critérios de aceitação em seu backlog.
○ Clicar em qualquer um desses cartões fornece uma lista de histórias dessa
categoria.
● Reordenar as histórias no backlog entre as páginas.
● Filtrar as histórias por épico usando a seção Registros por épico.
○ Nesta seção, somente os épicos, que pertençam às histórias do backlog
selecionado são listados.
○ Os épicos das histórias do seu backlog estão listados nesta seção.

15
 ○ A conclusão do épico é indicada por uma barra de progresso e uma
porcentagem.
○ Você pode mostrar ou ocultar esta seção selecionando o ícone de
configuração ( ).
● Personalizar colunas usando o ícone para atualizar lista personalizada ( ).
● Usar a opção de pesquisa para filtrar histórias usando uma palavra-chave.

Planejamento de sprint

A guia Planejamento de sprint do quadro ágil mostra o backlog da equipe e os sprints como
seções, que contêm a lista de histórias. Você pode criar, editar e planejar sprints usando as
opções disponíveis nesta guia.

Na guia Planejamento de sprint, você pode:

● Criar, organizar, monitorar, iniciar e concluir sprints.

● Exibir os sprints atuais e futuros em ordem cronológica.
● Exibir datas de início e término planejadas, pontos da história, porcentagem de
velocidade do grupo e o número de pontos da história (total, concluído e pendente)
para o sprint atual.
● Avaliar as histórias no backlog e arrastá-las para os sprints.
● Adicionar histórias ao backlog e configurar sua ordem de implementação.
● Mover histórias inacabadas do sprint concluído para o backlog ou para um sprint
futuro.

16
Controle de Sprint

Na guia Controle de sprint, você pode acompanhar o andamento do seu sprint atual em um
quadro de história, quadro de tarefas ou exibição de lista.

a) Quadro de histórias
● Rastrear todas as histórias do sprint atual entre as raias.
● Mover uma história de uma raia para outra, o que atualiza o estado da história.
● Filtrar histórias por critérios de pesquisa.

b) Quadro de tarefas

O quadro de tarefas permite que você rastreie todas as tarefas de scrum para histórias do
sprint atual entre as raias. Você pode:

● Mover tarefas de scrum de uma raia para outra, o que atualiza o estado das
histórias.
● Filtrar tarefas de scrum por critérios de pesquisa.

17
 c) Lista de andamento

A exibição de lista exibe tarefas de scrum e testes para as histórias do sprint atual. Na
exibição de lista, você pode:

● Adicionar tarefas de scrum e testes sem sair do contexto do registro.

● Exibir o estado, a descrição resumida e o a pessoa atribuída da tarefa de scrum.
● Exibir a descrição resumida e o resultado de um teste.
● Avaliar as tarefas de scrum e os testes que ainda estão pendentes antes que o
sprint atual seja encerrado.

18
4. Agile Development > Defeitos e Melhorias
O módulo Agile Development 2.0 fornece os recursos para relatar defeitos e solicitar
melhorias nos produtos desenvolvidos e mantidos.

4.1. Relatando defeitos encontrados

Problemas relatados relatados para o seu produto podem ser cadastrados como defeitos.
Você pode associar histórias para esses defeitos para que suas equipes possam começar a
trabalhar na resolução deles.

Os defeitos podem ser usados para rastrear a resolução de problemas que são observados
durante o desenvolvimento de um novo recurso ou como um feedback para recursos
existentes. Os product owners revisam esses defeitos e decidem sobre a criação de
histórias para eles, que são atribuídas aos grupos de atribuição relevantes.

Função do usuário para criar defeitos

Os usuários que precisem relatar os defeitos devem ter uma das seguintes funções:

● feature_user
● scrum_story_creator
● scrum_admin

No entanto, se um usuário tiver apenas a função feature_user, ele só poderá exibir os

defeitos do módulo Defeitos da aplicação Agile Development. Eles não podem exibir as
histórias associadas aos defeitos na lista relacionada Histórias do registro do defeito.

4.2. Solicitando melhorias

Solicitações de melhoria para diferentes áreas do seu produto também são suportados pelo
módulo Agile Development. Você pode associar histórias para essas solicitações para que
suas equipes possam começar a trabalhar no desenvolvimento delas.

As solicitações de melhoria podem ser usadas para registrar melhorias de recurso para um
produto. Essas solicitações podem surgir de requisitos internos ou de feedback do cliente.
Os product owners revisam essas solicitações registradas e decidem sobre a criação de
histórias para elas com base na prioridade. Essas histórias são atribuídas aos grupos de
atribuição relevantes para desenvolvimento.

Função do usuário para criar solicitações de melhoria

Criar ou editar solicitações de melhoria requer uma das seguintes funções:

● feature_user
● scrum_story_creator
● scrum_admin
● rm_enhancement_admin

19
No entanto, um usuário sem funções de scrum só pode acessar essas solicitações do
módulo Solicitações de melhoria da aplicação Agile Development mas não as histórias
que são criadas para esta solicitação.

Nota: O administrador deve conceder a função feature_user a todos os usuários que devem
criar uma solicitação de melhoria na aplicação Agile Development.

Depois que uma solicitação de melhoria é criada, os usuários com a função

scrum_story_creator ou scrum_admin podem:

● Revisar a solicitação de melhoria e criar uma história para ela

● Gerenciar histórias na lista relacionada Histórias no formulário Melhoria.

4.3. Backlog unificado

O backlog unificado ajuda a manter um backlog centralizado para registros de diferentes
tipos de tarefa, como defeitos, problemas ou melhorias. Priorize diferentes tipos de tarefa
em um único local e crie histórias automaticamente para esses registros, economizando
tempo. O fluxo de trabalho descrito aqui representa a prática comum de criar e gerenciar
registros.

Configurar um quadro de triagem

Defina os critérios de filtro e crie seus quadros de triagem. Os quadros de triagem ajudam a
exibir registros de um tipo de tarefa específico, dando melhor visibilidade. Por exemplo,
você pode criar um quadro de triagem para defeitos e outro para incidentes. O quadro de
triagem é atualizado automaticamente com qualquer novo registro que corresponda aos
critérios de filtro definidos.

Registros de triagem

Na guia Backlog do quadro ágil, você pode:

● Exibir o número total de registros nos quadros de triagem de todos os tipos de tarefa
● Abrir o quadro de triagem de um tipo de tarefa específico
● Editar a definição de filtro de um quadro de triagem existente

20
Você pode fazer a triagem dos registros e adicioná-los ao backlog do produto ou da equipe.
Itens adicionados ao backlog do quadro de triagem também terão histórias criadas para eles
automaticamente.

Atribuir registros

Depois que um registro for adicionado ao backlog de um quadro de triagem, trate-o como se
fosse uma história normal. Você pode atribuí-lo às equipes de produto relevantes e
programá-lo para os próximos sprints.

Trabalhando com os registros atribuídos em uma exibição de quadro

Os registros de um quadro de triagem são representados por histórias no quadro ágil. Você
pode rastrear o status dessas histórias na exibição do quadro de histórias da guia Controle
de sprint.

Quando você move essas histórias para raias diferentes no quadro de histórias para
atualizar seu estado, o estado da história associada é atualizado, mas o estado do registro
original triado permanece o mesmo. Para mudar o estado do registro original, abra a história
e alterne para a guia de registro original.

21
5. Configuração do Sistema
Esta seção apresenta as configurações necessárias para utilização do módulo Agile
Development da plataforma Conect@.

5.1. Instalação do módulo Agile Development 2.0

Para instalar o módulo Agile Development 2.0, é necessário possuir o perfil de
administrador da plataforma Conect@. Acione o comando de menu Definição do Sistema
> Plug-ins. Digite “agile” na caixa de pesquisa:

Abra o item Agile Development:

Instale os produtos do pacote (os três itens listados abaixo):

22
Obs.: Existem alguns problemas de tradução de alguns termos do inglês (original) para o
português brasileiro. Então, será necessário acessar os subitens do menu Localização do
Sistema e seus itens de menu para efetuar as correções nos textos traduzidos de forma
equivocada:

● Nome/Campos Traduzidos
● Mensagens
● Rótulos de campos
● Escolhas
● Texto traduzido

23
Referências
ROHIT. Agile Development 2.0 Publicado em 02/12/2022.

ServiceNow. Agile Development. Versão Washington.

WAGNER, Pauline. Como escrever um bom backlog. Publicado em 23/03/2023.

24