Devo criar um aplicativo com todos os recursos ou um pacote básico e depois adicionar recursos lentamente?

Eu trabalho em uma fábrica que encarregou a TI de criar um programa de programação de chão de fábrica (que é muito necessário). Com base na experiência de outras pessoas, seria melhor dedicar menos tempo e criar uma estrutura básica que seja utilizável e, depois disso, adicionar recursos ou começar criando uma solução totalmente implementada desde o início. Sou desenvolvedor há apenas um ano e não tenho muita experiência com a criação inicial de aplicativos desse tamanho. Eu tenho me inclinado para a ideia de que um aplicativo barebones é o caminho a percorrer primeiro devido à extrema necessidade de algum tipo de programação digital, mas estou preocupado que a adição de recursos aleatórios após o fato possa ficar um pouco confusa. Se você estivesse na mesma situação, para qual caminho você se inclinaria?

Definitivamente, a experiência leva à criação de algo pequeno e simples e à entrega aos usuários o mais cedo possível. Adicione recursos e recursos conforme solicitado pelos usuários.

As chances são muito boas (quase certas) de que o que elas querem / pedem não se parece muito com o que você teria construído por conta própria (se é que havia).

Na medida em que as coisas ficam confusas quando você adiciona ao seu aplicativo original: bem, é por isso que o Agile (e as metodologias mais semelhantes) coloca uma forte ênfase nos testes e refatoração. Refatorar significa limpar o código à medida que você faz alterações, e um sólido conjunto de testes (que você executa sempre que faz alterações) garante que se / quando você introduzir erros, souber sobre eles (quase) imediatamente, para que quando você libere algo para seus usuários, você tem uma garantia razoável de que realmente funciona.

Você tem alguma idéia se eles são sérios sobre o aplicativo? Talvez você não queira criar estruturas, etc. etc.

No entanto, você precisa encontrar um equilíbrio. O desenvolvimento ágil sugere que você se concentre no que é exigido pelo aplicativo nesse estágio, mas isso não significa que você deve se limitar negligenciando o design básico. Há coisas que podem ser vistas com facilidade (e a experiência sim desempenha um papel aqui) e outras que você não pode imaginar nesta fase (tenho certeza de que as pessoas que solicitaram o aplicativo também não podem imaginá-las).

Não conheço os detalhes do aplicativo de agendamento, mas posso imaginar que o "tipo de compromisso" é algo que você encontrará em breve. Talvez as pessoas não peçam isso agora, não é razoável esperar essa funcionalidade.

Eu abordaria esse caso da seguinte maneira: criaria a infraestrutura (a estrutura mencionada) criando uma tabela no banco de dados para armazenar tipos de compromisso, mas não me preocuparia em criar a interface para adicionar ou selecionar os tipos. Eu codificaria um tipo básico e seguia em frente com os recursos reais. Afinal, ninguém pediu para incluir diferentes tipos de compromissos.

Então, no futuro, se as pessoas voltarem para você solicitando esse recurso, você terá a estrutura e apenas criará o meio / front-end.

Freqüentemente, você não possui informações suficientes para criar um programa inicialmente completo. Testes e feedback do cliente quase sempre revelam partes do seu projeto inicial que não eram tão boas quanto eram em teoria.

Dito isto, se o problema for bem compreendido e você puder escrever um programa completo inicialmente, isso será melhor porque, caso contrário, você estará constantemente refatorando o código e o resultado raramente será tão limpo quanto um design sólido que foi seguido desde o início.

No mínimo, acho importante pensar bastante sobre o tipo de recurso que seu programa pode precisar. Dessa forma, você pode projetá-lo para que esses recursos possam ser facilmente adicionados à estrutura existente.

Por experiência pessoal: construa seu MVP (Produto mínimo viável) e adicione recursos a ele com base nos comentários recebidos. É fácil obter toneladas de recursos e não ser usado por ninguém.

Também é importante a experiência do usuário que você usa para resolver o problema. Valide o fluxo de trabalho que você cria com seus usuários reais e depois adicione outros recursos. Dessa forma, você pode se concentrar no valor principal que está criando.