Backlog do Produto de Software

Clique Aqui para baixar o documento.

O Backlog do Produto é uma lista priorizada de todas as funcionalidades, melhorias e correções necessárias para o desenvolvimento de um produto. Essa lista é dinâmica e pode ser constantemente atualizada conforme novas informações se tornam disponíveis, garantindo que a equipe de desenvolvimento esteja sempre focada nas tarefas mais valiosas para os usuários e stakeholders.

Tabela de Backlog

A Tabela de Backlog apresentada a seguir lista os épicos e histórias de usuário priorizados, com as respectivas estimativas de esforço (Story Points) e prioridade de implementação. A priorização foi realizada utilizando a técnica Planning Poker, onde a equipe de desenvolvimento atribui valores de prioridade baseados em consenso, considerando a importância e a complexidade de cada item. Esta abordagem permite que a equipe se concentre nas tarefas mais relevantes para atender às necessidades dos usuários e stakeholders. A Tabela 1 abaixo resume os principais itens do backlog do produto, enquanto a Tabela 2 apresenta uma legenda para facilitar o entendimento.

Tabela 1: Tabela de Backlog.

Épico	História de Usuário	Story Points	Prioridade
Realidade Aumentada (E01)	Eu como cliente, desejo de ter uma assistência de mira para auxiliar o alinhamento da carga no alvo.	8	Alta
Realidade Aumentada (E01)	Eu como cliente, desejo saber a temperatura das baterias em tempo real para monitorar riscos de pane elétrica.	5	Média
Realidade Aumentada (E01)	Eu como cliente, desejo uma sobreposição de tela no canto superior esquerdo do FPV mostrando a variável de tensão da bateria recebida pela telemetria para questões de segurança e monitoramento.	5	Média
Realidade Aumentada (E01)	Eu como cliente, desejo implementar uma solução que identifique automaticamente focos de incêndio em tempo real, para melhorar a resposta e a prevenção de incêndios.	13	Baixa
Relatório de Voo (E02)	Eu como cliente, desejo ter relatórios pós-voo para identificar peças com defeitos e outras informações de valor.	3	Alta

Por padrão, por envolver embarcados, os requisitos de qualidade (não funcionais) do software embarcado deve envolver as limitações de hardware. Por outro lado, o Relatório de Voo, devido a sua natureza desktop, não tem muitas dificuldades de restrição, sendo seus requisitos de qualidade uma resposta rápida e um visual atrativo para o cliente

Legenda

Tabela 2: Legenda da tabela de Backlog.

Legenda	Descrição
Épico	Um Épico é uma grande funcionalidade ou requisito que geralmente precisa ser quebrado em várias User Stories para ser desenvolvido. Os Épicos são frequentemente usados para descrever objetivos amplos e de alto nível que serão refinados ao longo do tempo.
História de Usuário	Uma História de Usuário é uma descrição simples e concisa de uma funcionalidade que representa uma necessidade ou desejo de um usuário. Ela é geralmente escrita da perspectiva do usuário final e serve para guiar o desenvolvimento e fornecer valor imediato ao produto.
Story Points	Estimativa do esforço necessário para completar a tarefa, baseado na sequência de Fibonacci: 1, 2, 3, 5, 8, 13... Quanto maior o número, maior o esforço estimado.
Alta	Prioridade máxima. Imediatamente desenvolvível, valor alto para o produto.
Média	Prioridade intermediária. Requer detalhamento adicional antes do desenvolvimento.
Baixa	Prioridade baixa. Não é urgente e pode ser abordada em fases posteriores.

Story Map

O Story Map é uma ferramenta visual que organiza e prioriza as histórias de usuários, alinhando-as à jornada do usuário e ao valor entregue por cada funcionalidade. Ele facilita a comunicação entre a equipe e os stakeholders, ajudando a identificar lacunas no desenvolvimento, conforme ilustrado na Figura 1 a seguir. Caso haja duvídas sobre a interpretação desse subartefato, a Tabela 3 representa uma legenda para auxiliar no entendimento do Story Map.

Figura 1: Story Map.

Story Map representando o planejamento do sistema.

Legenda

Tabela 3: Legenda do Story Map.

Elemento	Descrição	Cor
Topo do Story Map (Atividades)	As atividades são agrupamentos de tarefas, representando um resumo de um conjunto de ações, facilitando a discussão sem a necessidade de detalhes.	Azul e Verde
Corpo do Story Map (Tarefas, Detalhes, Alternativas)	Tarefas (Tasks): Ações específicas que o usuário realiza ao interagir com o produto. Detalhes (Details): Informações complementares sobre as tarefas. Alternativas (Alternatives): Opções alternativas para executar as tarefas.	Amarelo
Linhas Horizontais (MVP e Releases)	- MVP (v1) - Primeira Prioridade: Funcionalidades essenciais para o lançamento inicial do produto. - Releases (v2 em diante) - Próximas Prioridades: Versões seguintes com melhorias e novas funcionalidades.	Linha Horizontal (sem cor definida)
Linhas Verticais (Fronteira entre Sistemas)	Representa a divisão entre diferentes sistemas dentro do Story Map.	Linha Vertical (pontilhada)

Roadmap

O Roadmap é um plano estratégico que descreve os objetivos do produto e as principais entregas ao longo do tempo. Ele define as etapas que a equipe seguirá para alcançar as metas do produto, servindo como um guia para o planejamento de releases e sprints. O roadmap proporciona uma visão clara para todos os envolvidos no projeto, alinhando a direção e as expectativas do desenvolvimento, conforme ilustrado na Figura 2.

Observação: O backlog do produto serve como base para o planejamento das sprints e para as entregas esperadas em cada release.

Figura 2: Roadmap.

Roadmap detalhando o planejamento e execução do projeto.

Kanban

Para gerenciar o progresso e o fluxo de trabalho, utilizamos sistemas Kanban. O Kanban é uma ferramenta visual que nos permite organizar e monitorar as tarefas de maneira eficiente, ajudando a visualizar o status de cada tarefa e otimizar o fluxo de trabalho. A seguir, estão os links para nossos quadros Kanban, juntamente com um exemplo ilustrado pela Figura 3, que representa o issue board do relatório de voo.

Figura 3: Kanban do Relatório de Voo.

Kanban ilustrando o fluxo de tarefas do Relatório de Voo.

Labels

As labels que estamos utilizando para classificar as tarefas no Kanban (Tabela 4) são definidas para facilitar a identificação do status de cada tarefa e auxiliar no gerenciamento eficiente do progresso. Cada label está associada a uma cor específica, o que permite uma visualização rápida e clara do estado de cada atividade. A seguir, confira as labels selecionadas para o desenvolvimento de software:

Tabela 4: Labels utilizadas no Kanban.

Label	Cor	Descrição
Backlog	Roxo	Itens ou tarefas que ainda não foram priorizadas para desenvolvimento, mas estão registradas para futuras considerações.
Blocked	Vermelho	Tarefas que estão impedidas de avançar por algum motivo, como dependências não resolvidas ou bloqueios técnicos.
Doing	Azul	Tarefas que estão em andamento, ou seja, já iniciadas e sendo trabalhadas.
Done	Verde	Tarefas que foram concluídas e estão totalmente finalizadas, sem necessidade de mais alterações.
In Review	Laranja	Tarefas que estão aguardando uma revisão ou validação por uma pessoa responsável antes de serem consideradas concluídas.
To Do	Amarelo	Tarefas que estão planejadas para serem iniciadas, mas ainda não foram trabalhadas. Geralmente são tarefas que estão na fila de execução.

Essas labels ajudam a fornecer uma visualização clara do estado atual de cada tarefa, permitindo que toda a equipe saiba exatamente o que está acontecendo com o trabalho. As cores também ajudam a identificar rapidamente o status das atividades e facilita a tomada de decisão sobre o que precisa ser feito a seguir.

Histórico de Ferramentas

O desenvolvimento do sistema de relatório de voo para o SiDrone eVTOL envolveu a análise de diversas tecnologias, considerando vantagens e desvantagens, além de desafios encontrados durante a utilização de cada uma. Após a elaboração do Protótipo de Alta Fidelidade, foi decidido iniciar o desenvolvimento utilizando Python e Tkinter.

Essa seção registra as decisões tomadas pelos desenvolvedores, funcionando como uma referência para o futuro, de forma a evitar retrabalho na busca por novas ferramentas de desenvolvimento.

Front-end

TKinter

O Tkinter é a biblioteca padrão de interfaces gráficas (GUIs) para Python. Ele fornece ferramentas para criar aplicações com janelas, botões, campos de texto, menus e outros componentes gráficos. Essa ferramenta logo foi descartada por não apresentar os recursos necessários para reproduzir o Protótipo de Alta Fidelidade.
PyQt

O PyQt é um conjunto de bindings em Python para a biblioteca Qt, amplamente utilizada no desenvolvimento de interfaces gráficas de usuário (GUIs).

Motivos para a escolha do PyQt
- Integração com Python: Compatibilidade com a linguagem escolhida para o projeto.
- Portabilidade: Possibilidade de executar o aplicativo em Windows, macOS e Linux com mínimas alterações no código.
- Extensibilidade: Suporte a recursos como gráficos 2D e 3D, threads e widgets personalizáveis.
- Facilidade de uso: Boa documentação e comunidade ativa.
Limitações do PyQt

O PyQt apresentou dificuldades na implementação de recursos visuais mais modernos, como degradês, sombreamentos e transparência, essenciais para a interface planejada. Isso levou à exploração do Kivy como forma de complementar o projeto com recursos faltantes no PyQt.
Kivy

O Kivy é um framework de código aberto voltado para aplicações com interfaces gráficas interativas e multitouch.

Vantagens do Kivy
- Suporte multitouch: Ideal para telas sensíveis ao toque.
- Linguagem declarativa (KV): Permite a separação clara entre o design e a lógica do aplicativo.
- Uso do OpenGL ES 2: Garante desempenho gráfico mesmo em dispositivos com hardware limitado.
Limitações e decisão final

Embora o Kivy apresentasse recursos complementares ao PyQt, o uso simultâneo de ambos aumentava a complexidade do projeto. Por isso, foi decidido explorar o Electron como alternativa.
Electron

O Electron é um framework de código aberto que permite criar aplicativos de desktop multiplataforma utilizando tecnologias web (HTML, CSS e JavaScript).

Motivos para a escolha do Electron
- Multiplataforma: Compatibilidade com Windows, macOS e Linux.
- Tecnologias web: Utiliza ferramentas conhecidas (HTML, CSS e JavaScript).
- Integração com Node.js: Permite funcionalidades avançadas através de módulos do Node.js.
- Ampla biblioteca de pacotes: Disponível via npm.
- Atualizações automáticas: Facilita a distribuição de novas versões para os usuários.
Desvantagens
- Tamanho do aplicativo: Os aplicativos criados com Electron geralmente são maiores.
- Consumo de recursos: Maior uso de CPU e RAM em comparação com soluções nativas.
Apesar das desvantagens, os benefícios do Electron superaram os desafios, sendo a opção escolhida para o desenvolvimento final.

Back-end

Python

A linguagem Python foi escolhida por diversos motivos:
- Curva de aprendizado baixa: Simplicidade da linguagem para desenvolvedores iniciantes e experientes.
- Extensão de bibliotecas: Disponibilidade de recursos para lidar com interfaces gráficas, manipulação de dados e outras funcionalidades necessárias ao projeto.
- Versatilidade: Adequada para aplicações diversas, incluindo interfaces gráficas, análise de dados e automação.
Node.js e Nodemon

Com a adoção do Electron, foi necessário reestruturar o projeto para integrar o Node.js e o Nodemon.

Node.js
- Plataforma de execução de JavaScript no lado do servidor.
- Ideal para aplicações escaláveis e eficientes.
Nodemon
- Ferramenta para desenvolvimento em Node.js que monitora alterações nos arquivos e reinicia automaticamente o servidor.
- Reduz o tempo de desenvolvimento ao eliminar reinicializações manuais do servidor.
- Suporte a arquivos adicionais como .html, .css e outros.

Conclusão

A análise das tecnologias levou à escolha do Electron, combinado com Node.js e Nodemon, para criar um ambiente robusto e flexível, compatível com o hardware presente no drone. A transição de ferramentas foi baseada na busca por soluções eficientes e alinhadas aos objetivos do projeto. Um desafio enfrentado é a substituição de partes do código Python por códigos JavaScript.

Referências

PEREIRA, P.; TORREÃO, P.; MARÇAL, A. S. Entendendo Scrum para gerenciar projetos de forma ágil. Mundo PM, v. 1, p. 3-11, 2007.
Acesso em: 10 nov. 2024.

LUCIDCHART. O que é backlog do produto Scrum e como fazer um.
Acesso em: 10 nov. 2024.

MÉTODO ÁGIL. Planning Poker: A melhor maneira de estimar qualquer atividade.
Acesso em: 10 nov. 2024.

SCRUM POKER ONLINE. Ferramenta para Planning Poker.
Acesso em: 10 nov. 2024.

MIRO. User Story Map Template.
Acesso em: 10 nov. 2024.

USER STORY MAPPING TUTORIAL. User Story Mapping Tutorial
Acesso em: 10 nov. 2024.

LUCIDCHART. Product roadmap
Acesso em: 10 nov. 2024.

Tabela de Versionamento

Versão	Data	Descrição	Autor(es)
1.0	03/11/2024	Criação inicial e estrutura do artefato	Gustavo e Gabriel Ferreira
1.1	13/11/2024	Atualização do artefato de backlog com Story Map, Roadmap e Kanban	Gustavo
1.2	21/11/2024	Revisão, correção geral e evolução do artefato	Gustavo
1.3	21/11/2024	Revisão geral e correção de problemas de visualização	Ana Hoffmann
2.0	27/11/2024	Revisão e Atualizações	Gustavo
2.1	12/01/2025	Revisão, atualizações e adição do histórico de ferramentas	Ana Hoffmann
2.2	13/01/2025	Revisão	Gustavo