Haruskah saya membangun aplikasi berfitur lengkap atau yang telanjang dan kemudian perlahan menambahkan fitur?

Saya bekerja di pabrik yang menugaskan TI untuk membuat program penjadwalan lantai toko (yang sangat dibutuhkan). Berdasarkan pengalaman orang lain, akan lebih baik untuk mengambil lebih sedikit waktu dan membangun kerangka dasar yang dapat digunakan dan kemudian membangunnya dengan menambahkan fitur atau memulai dengan menciptakan solusi yang sepenuhnya diimplementasikan di luar gerbang. Saya hanya menjadi pengembang selama sekitar satu tahun dan tidak memiliki banyak pengalaman dengan pembuatan awal aplikasi sebesar ini. Saya telah condong ke arah gagasan bahwa aplikasi barebones adalah cara untuk pergi pertama karena kebutuhan ekstrim untuk beberapa jenis jadwal digital tetapi saya khawatir bahwa menambahkan fitur acak setelah fakta bisa menjadi sedikit berantakan. Jika Anda berada dalam situasi yang sama jalan apa yang akan Anda tuju?

Pengalaman jelas mengarah pada membangun sesuatu yang kecil dan sederhana, dan memberikannya kepada pengguna sedini mungkin. Tambahkan fitur dan kemampuan sebagaimana diminta oleh pengguna.

Peluangnya sangat bagus (berbatasan dengan tertentu) bahwa apa yang mereka inginkan / minta tidak akan sangat mirip dengan apa yang Anda bangun sendiri (jika ada).

Sejauh hal menjadi berantakan saat Anda menambahkan ke aplikasi asli Anda: well, inilah sebabnya Agile (dan sebagian besar metodologi serupa) menempatkan penekanan kuat pada pengujian dan refactoring. Refactoring berarti membersihkan kode saat Anda membuat perubahan, dan rangkaian pengujian yang solid (yang Anda jalankan setiap kali Anda melakukan perubahan) memastikan bahwa jika / ketika Anda memperkenalkan bug, Anda tahu tentang mereka (hampir) segera, sehingga ketika Anda merilis sesuatu untuk pengguna Anda, Anda memiliki jaminan yang masuk akal bahwa itu benar-benar berfungsi.

Apakah Anda tahu apakah mereka serius tentang aplikasi, maka Anda mungkin tidak ingin membangun kerangka kerja, dll. Dll.

Namun, Anda perlu menemukan keseimbangan. Pengembangan lincah menyarankan Anda fokus pada apa yang dibutuhkan oleh aplikasi pada tahap ini, tetapi ini tidak berarti Anda harus membatasi diri dengan mengabaikan desain dasar. Ada hal-hal yang dapat dengan mudah dilihat datang (dan ya pengalaman memainkan peran di sini) dan yang lain yang tidak dapat Anda bayangkan pada tahap ini (saya cukup yakin orang-orang yang meminta aplikasi juga tidak dapat membayangkannya).

Saya tidak tahu detail dari aplikasi penjadwalan tetapi saya bisa membayangkan bahwa "jenis janji" adalah sesuatu yang akan Anda temui segera. Mungkin orang tidak meminta ini sekarang, tidak masuk akal untuk mengharapkan fungsi seperti itu.

Saya akan mendekati kasus ini sebagai berikut: Saya akan membangun infrastruktur (kerangka yang Anda sebutkan) dengan membuat tabel dalam database untuk mengadakan jenis janji temu tetapi saya tidak akan repot-repot membuat antarmuka untuk menambah atau memilih jenis. Saya akan mengkode jenis dasar dan beralih dengan fitur yang sebenarnya. Bagaimanapun, tidak ada yang meminta untuk memasukkan berbagai jenis janji.

Kemudian, di masa depan, jika orang-orang kembali kepada Anda meminta fitur ini, Anda memiliki struktur dan Anda hanya membangun ujung tengah / depan.

Seringkali, Anda tidak memiliki informasi yang cukup untuk membangun program yang awalnya lengkap. Pengujian dan umpan balik pelanggan hampir selalu mengungkapkan bagian-bagian dari desain awal Anda yang tidak sebagus teori.

Yang mengatakan, jika masalahnya dipahami dengan baik dan Anda dapat menulis program yang lengkap pada awalnya, ini lebih baik karena jika tidak, Anda terus-menerus memperbaiki kode dan hasilnya jarang sebersih desain padat yang diikuti sejak awal.

Paling tidak, saya pikir penting untuk berpikir keras tentang jenis fitur yang mungkin diperlukan program Anda. Dengan begitu, Anda dapat mendesainnya sehingga fitur seperti itu dapat dengan mudah ditambahkan dalam struktur yang ada.

Dari pengalaman pribadi: buat MVP Anda (Produk yang Layak Minimum) dan kemudian tambahkan fitur berdasarkan umpan balik yang Anda terima. Sangat mudah untuk mendapatkan banyak fitur dan tidak ada orang yang menggunakannya.

Yang juga penting adalah pengalaman pengguna yang Anda gunakan untuk memecahkan masalah. Validasi alur kerja yang Anda buat dengan pengguna Anda yang sebenarnya dan kemudian tambahkan fitur lebih lanjut. Dengan begitu Anda bisa fokus pada nilai inti yang Anda bangun.