No Ciclo de Vida de Desenvolvimento de Software (SDLC) temos 8 grandes etapas que ajudam a estruturar e visualizar melhor o processo, são elas: Planejamento, Análise de Requisitos, Design de Sistema, Desenvolvimento, Teste, Implantação, Manutenção e Revisão/Retrospectiva.
Em tentativas anteriores de fazer um projeto passei por dificuldades por ter considerado desnecessárias etapas da engenharia de software como planejamento, análise de requisitos e design de sistema. Por serem projetos pequenos e desenvolvidos por uma pessoa só, pensei que pelo tamanho do escopo eu daria conta de pensar em todas essas coisas à medida em que ia desenvolvendo. A verdade é que não dá.
Começar diretamente na fase de desenvolvimento, seja para testar logo algo que você passou os últimos dois meses estudando ou tentando ir direto ao ponto para terminar mais rápido acaba sendo um tiro no próprio pé. Sem um planejamento anterior, você não tem uma noção da sua arquitetura, não tem uma definição clara dos requisitos, não tem um protótipo da sua interface, não sabe se o que você está tentando utilizar faz sentido ou é apenas um capricho seu.
À medida que você implementa novas funcionalidades percebe que precisa revisitar o que você já fez pois o código existente não acomoda bem as novas funcionalidades. A UI passa a não ser coesa. Chega a um ponto em que você acaba desistindo, ver sua ideia funcionando se torna mais distante pelas refatorações que agora seriam necessárias.
Por se tratar de um modelo conceitual, posso e devo adaptar as etapas ao meu projeto. Por exemplo, em projetos ágeis (como o que estou fazendo), essas etapas existem, mas acontecem de forma diferente, são iterativas e menos formais, a documentação pode ser simplificada também. Com MVPs e protótipos, é aceitável afrouxar os testes (com responsabilidade), pois o foco é aprender rápido e validar hipóteses e não garantir “perfeição” técnica. Outro ponto é que, geralmente, nessas etapas, os requisitos ainda são instáveis, podem sofrer muitas alterações, portanto, testar com profundidade algo que tem grandes chances de mudar ou ser descartado não é eficiente.
No projeto do app de finanças, atualmente, estou perto de iniciar o desenvolvimento. Passei um tempo nas etapas iniciais, na fase de Planejamento, escrevi um PRD (Product Requirement Document), que é um documento que os Gerentes de Produtos descrevem os objetivos, problemas que o produto resolve, funcionalidades principais, regras e restrições e, por último, métricas esperadas (esse último eu não coloquei, por não ser um produto que vai para o mercado, não acompanharei nenhuma métrica).
Queria simular um ambiente de trabalho, então, por ser uma ferramenta bastante utilizada, configurei uma conta da Atlassian no nível gratuito e estou utilizando o Confluence para a documentação. Como eu já havia decidido utilizar os recursos do AWS, comecei a desenhar uma arquitetura, fazendo uma prova de conceito PoC se ela funcionaria da maneira em que eu imaginei. Utilizei também o AWS Pricing Calculator que me permite simular o custo mensal de ter minha solução funcionando.
Passando para a fase de Análise de Requisitos, criei histórias de usuário no Jira com base no meu PRD e foi aqui em que eu entendi seu valor. Ele tem sido meu norte nesse processo, sendo revisitado à medida em que vou avançando ou vendo necessidade de refinar algo.
Em paralelo, fui desenvolvendo um protótipo da interface no Figma para completar o entendimento das histórias. Aproveitando para tentar aplicar outro conceito na hora de desenhar a interface e os componentes, que é o Atomic Design, ele ajuda a estruturar a interface e na interação dos componentes, percebi que essa me faz visualizar já como seria a implementação e separação dos componentes no React, acredito que vai me trazer maior clareza e agilidade na hora de codificar.
Estou aprendendo muito nessa jornada, seguir o SDLC mesmo que de forma adaptada está me dando clareza e foco. Agora que eu tenho quase tudo no lugar, pretendo mover para a fase de desenvolvimento, então logo já devo disponibilizar o repositório público do projeto.