Produto

A etapa de produto é onde novas demandas de produto são avaliadas, discutidas e tudo começa. Esta etapa consiste em atividades, reuniões, novas ideias, estudos e definições que são responsabilidade do Product Manager (PM) e Product Owners (POs) de cada produto. É aqui que ideias e sugestões são validadas e o processo de desenvolvimento é iniciado.

Ideias e Sugestões

Todo o ciclo de entrega do produto inicia com ideias e sugestões que são avaliadas e filtradas pelos responsáveis em reuniões periódicas de análise e priorização. As sugestões ficam em locais diferentes dependendo do seu caráter:

  • Nolt FWFLEX: Ferramenta dedica à ideias e sugestões que é aberta para clientes, parceiros e colaboradores das áreas de suporte, CS e implantação sugerirem melhorias e funcionalidades que são qualificadas periodicamente.

  • Backlog de Ideias: Mind onde são armazenadas e organizadas as ideias antes que elas sejam abertas no Redmine. Features que precisam ser feitas por necessidades do negócio normalmente são inseridas diretamente no backlog de ideias e quando é o momento ideal são transferidas para o Redmine.

  • Redmine: Ferramenta de gerenciamento e administração de projetos. Épicos e features são abertos no Redmine a partir do momento onde foi decidido que serão executados e estão priorizados no roadmap.

Priorização

A priorização ocorre de acordo com os objetivos da empresa e produto, discutida em conjunto entre os PM's e PO's baseando-se nas ferramentas listadas acima.

Conforme descrito no fluxo acima, são realizadas reuniões periodicamente para realização do alinhamento e priorização das atividades que serão executadas, incluindo o bugs. O alinhamento macro do roadmap é o que gera os objetivos e próximas atividades que serão executadas nas sprints de produto e desenvolvimento.

É responsabilidade dos PO's abrir os épicos trazendo iniciativas para o produto e organizar as features dentro dos mesmos no Redmine.

Sprint

A partir das iniciativas em aberto e as features devidamente organizadas, as stories das features entram na sprint de produto, conforme a prioridade definida. Os PO's escrevem as features, seguindo o template no Redmine. É definido O quê, porquê e a Definição de Conclusão necessária para os testes. As features são quebradas em stories e estas também são escritas pelos POs seguindo o template no Redmine. A story é descrita no formato de User story e Use cases.

No caso do FWM, nesta fase é realizado o desenho das telas e definido o fluxo de uso da funcionalidade, conforme descrito no procedimento de Desenho de Telas e Fluxo de Uso com Figma.

A sprint de produto termina e as stories passam para a próxima sprint de desenvolvimento.

A cadência é controlada sempre nas reuniões de prioridades do produto e na reunião de Refinning no início da Sprint, que define exatamente o que será executado. O objetivo da sprint de Produto é definir as stories e garantir que as próximas atividades da Sprint de desenvolvimento estejam definidas e com todos os detalhes necessários. Atividades paralelas, spikes e análise de bugs também são ponderados e executados na sprint de produto.


Tempo de duração da sprint: 2 semanas (10 dias úteis)

Tickets

  • Épicos: são consideradas iniciativas de entrega de valor do produto. Agrupam outros tickets como Atividades, Features e Bugs.

  • Features: novas funcionalidades, débitos técnicos e melhorias de funcionalidades existentes. Uma feature pode conter tickets como story, atividade, spike, test e doc.

  • Atividades: utilizados para execução de atividades que não entregam nada diretamente ao produto, como manutenção em servidores, repos, dns, CI/CD, aplicações, etc.

  • Spikes: utilizados para estudos de novas tecnologias.

  • Bugs: erro ou falha na execução de um programa, tela, campo ou outros, prejudicando ou inviabilizando o seu funcionamento.

  • Test: utilizados para testes de bugs e features. Devem ser abertos sempre dentro do ticket que será testado.

  • Doc: indicam a documentação de uma funcionalidade, seja de forma mínima ou completa. Normalmente aberto dentro de Features de novas funcionalidades ou melhorias que demandam alteração no produto.

  • Fix: abertos sempre que há necessidade de correção de problemas detectados em execução de Testes. São abertos dentro de tickets de teste pelo analista que detectou a necessidade de correção.

  • Story: tickets de story são os tickets onde os desenvolvedores e analistas de produto trabalham. Eles compões uma feature e são os tickets utilizados ao longo da sprint.