Olá, akil. Tudo bem?

A UML caiu em desuso nos últimos anos, porém os fluxogramas continuam sendo usados e ajudam a entender o escopo e as regras de negócio de um projeto.

Após o levantamento de requisitos, é comum que sejam elaborados fluxogramas, lista de tarefas, divisão dessas tarefas dentro de sprints (caso o Scrum seja o método adotado). Claro que nem todos os requisitos levantados são necessários, por isso é importantíssimo o papel do Product Owner para priorizar o que é crucial, o "core" da aplicação.

Essas sprints são iterativas até que o projeto seja concluído, sendo submetido a um teste de aceitação, isto é, o cliente deve usar o projeto e sinalizar se aprova o resultado. Antes do teste de aceitação, também devem ocorrer outros contatos do cliente com o produto, para que o processo de desenvolvimento esteja de acordo com as necessidades dele.

As "versões" que são disponibilizadas a cada sprint são incrementais (idealmente). Vamos imaginar que eu tenho um aplicativo de finanças, cujas funcionalidades principais são: adicionar contas a receber, adicionar contas a pagar e visualizar saldo. Eu poderia dividir o desenvolvimento desse projeto (falando bem a grosso modo), em três etapas incrementais: Primeiro a funcionalidade de adicionar contas a receber, segundo a funcionalidade de adicionar contas a pagar e por último o saldo. Desta forma, a cada funcionalidade entregue, é possível testar o projeto e verificar se está ficando de acordo com os requisitos, mesmo que ele não esteja totalmente pronto.

O processo de desenvolvimento é bastante complexo e, em minha humilde experiência, quase todas as vezes, os requisitos e as "tasks" (tarefas atribuídas a cada sprint) mudam com o decorrer do projeto - não por desorganização, mas por amadurecimento dos requisitos e das regras de negócio. Muitas coisas só são identificadas durante o desenvolvimento, por isso, o processo é algo fluído, não é rígido como impunha o modelo cascata.

Eu espero ter te ajudado, qualquer dúvida pode perguntar. Vale ressaltar que essa é a minha visão enquanto desenvolvedora, e um Product Owner ou um Scrum Master devem ter bem mais detalhes a acrescentar.

Abraço!