Secara umum, apakah lebih baik membuat semua bagian fungsional atau membuat UI berfungsi lebih dulu - atau campuran keduanya?


47

Secara umum, apakah lebih baik membuat semua bagian fungsional atau membuat UI berfungsi lebih dulu - atau campuran keduanya?

Dengan asumsi Anda sedang mengerjakan sesuatu yang besar, apakah ini merupakan praktik yang diterima secara umum untuk mendapatkan semua gumpalan pengumpulan data fungsional berfungsi sebelum UI apa pun, dapatkan semua UI bekerja satu per satu saat Anda bergerak, atau sesuatu di tengah?

Kita semua tahu untuk memecah pekerjaan menjadi bagian-bagian yang dapat dikelola, tetapi pertanyaannya adalah apakah UI termasuk dalam bagian-bagian yang dapat dikelola, saya kira.

Untuk kasus contoh, pertimbangkan aplikasi GUI dengan satu jendela root, tetapi lebih dari selusin tab di berbagai dermaga untuk memisahkan komponen data yang berbeda. Setiap tab individu memiliki seperangkat bagian bergerak yang relatif kompleks di belakangnya dari perspektif unit fungsional.

Contoh aplikasi dalam pertanyaan khusus ini ada di sini dengan blog yang menyertainya dan produk komersial asli .

Jawaban:


85

Ada konsep umum di antara banyak pengguna bisnis dan klien bahwa ketika terlihat lengkap, hampir lengkap. Seperti yang mungkin Anda ketahui, ini jauh dari kebenaran. Satu dapat membuatnya terlihat bagus, tetapi tanpa backend dan beberapa pengguna berpikir bahwa membuatnya terlihat bagus adalah 80% dari pekerjaan, bukan 20% ( atau 80% lainnya ).

Pengembang yang tak terhitung jumlahnya dapat menceritakan kisah-kisah horor ini - mendapatkan maket dari halaman yang dilakukan di Microsoft Word menggunakan tangkapan layar dari beberapa alat lain, dan klien mengatakan "jadi, Anda hampir menyelesaikannya?"

Anda perlu mengatur langkahnya agar semua bagian selesai saat selesai. Mencoba melakukan semua backend terlebih dahulu dan kemudian semua ujung depan akan menyebabkan pengguna akhir berpikir Anda tidak melakukan apa-apa dan menanyakan mengapa Anda dibayar ketika tidak ada yang menunjukkannya. Di sisi lain, ujung depan lebih dulu dan Anda akan menemukan pengguna akhir membuat perubahan yang menyebalkan dan menghabiskan seluruh waktu kita.

Kasus terburuk dengan 'yang pertama dan yang lain' adalah ketika Anda sampai ke bagian yang lain, Anda mendapati bahwa itu tidak sesuai dengan desain sama sekali.

Jadi, bangun keduanya. Tunjukkan kemajuan di ujung depan, buat ujung belakang bekerja dengan apa yang Anda bangun. Dalam banyak kasus ini adalah ide yang baik untuk memberikan bangunan tambahan dan memastikan Anda membuat apa yang diinginkan klien (ini masuk ke Agile). Terlalu lama tanpa 'kemajuan yang terlihat' dapat merusak hubungan klien (ini untuk kedua kasus 'semuanya terlihat dilakukan sejak dini' dan 'tidak ada yang dilakukan sampai akhir' - sulit bagi klien untuk melihat kerangka kerja yang ditulis atau tes unit atau sanitasi data sebagai kemajuan).

Joel menulis tentang ini di The Iceberg Secret, Revealed :

Konsekuensi Penting Dua. Jika Anda menunjukkan layar nonprogrammer yang memiliki antarmuka pengguna yang 100% cantik, mereka akan berpikir programnya hampir selesai.

Orang yang bukan pemrogram hanya melihat layar dan melihat beberapa piksel. Dan jika pikselnya terlihat seperti membuat program yang melakukan sesuatu, mereka berpikir "oh, astaga, seberapa sulitkah untuk membuatnya benar-benar berfungsi?"

Risiko besar di sini adalah bahwa jika Anda membuat UI terlebih dahulu, mungkin sehingga Anda bisa melakukan percakapan dengan pelanggan, maka semua orang akan berpikir Anda hampir selesai. Dan kemudian ketika Anda menghabiskan tahun berikutnya bekerja "di bawah selimut," sehingga untuk berbicara, tidak ada yang akan benar-benar melihat apa yang Anda lakukan dan mereka akan berpikir itu bukan apa-apa.

Ini sekali lagi ditegaskan dalam posting blog Jangan membuat Demo terlihat Selesai yang memiliki grafik bermanfaat ini:

Bagaimana itu dilakukan untuk apa yang terlihat

Perhatikan di sini dua opsi umumnya mencerminkan 'selesaikan ui' (dan kemudian harapannya adalah Anda akan segera selesai) dan 'selesaikan backend' (dan kemudian pelanggan khawatir Anda kehilangan tenggat waktu).

Bagaimana 'selesai' sesuatu terlihat harus cocok dengan bagaimana 'selesai' sesuatu itu.

Setiap pengembang perangkat lunak telah mengalami ini berkali-kali dalam karir mereka. Tetapi alat-alat penerbitan desktop menyebabkan sakit kepala yang sama untuk para penulis teknologi - jika Anda menunjukkan kepada seseorang konsep kasar yang diformat dan diformat dengan sempurna, mereka melihatnya sebagai lebih banyak dilakukan daripada yang Anda inginkan. Kita membutuhkan kecocokan antara di mana kita berada dan di mana orang lain menganggap kita.

Artikel ini juga memunculkan poin penting tentang jenis umpan balik yang Anda dapatkan dengan tingkat kematangan antarmuka pengguna yang berbeda. Jika Anda memiliki sesuatu yang terlihat lengkap, Anda cenderung mendapatkan umpan balik tentang "bisakah Anda mengubah font" daripada "tata letak ini tidak berfungsi - ada terlalu banyak tab."


Bagi mereka yang berkelahi dengan ini di dunia Java Swing, ada tampilan dan nuansa yang disebut Napkin yang membuatnya sehingga UI tidak terlihat lengkap (bahkan jika itu).

Kuncinya di sini adalah membuatnya agar tidak terlihat selesai. Memiliki UI terlihat lengkap adalah sinyal bagi banyak pengguna bisnis bahwa aplikasi selesai (bahkan jika itu hanya beberapa halaman statis tanpa logika di baliknya atau sesuatu yang dibangun dalam pembangun antarmuka).


Bacaan lebih lanjut (dan tautan dari artikel):


7
Kedengarannya Anda sedang mengusulkan semacam metodologi lincah ... :)
Alexander

7
@Alexander Agile membantu dalam kasus ini, tetapi tidak penting. Air terjun dapat memiliki tonggak (pengiriman) dan pelanggan dapat sangat kecewa melihat "kelihatannya sudah selesai, mengapa ada 3 mil lebih batu yang memakan waktu lama?" FWIW, saya punya contoh di mana pengguna bisnis berpikir itu dilakukan karena screen shot + ms dalam desain teknologi (waterfall shop) terlihat bagus.

3
Jika Anda tidak melihat jawaban pakar untuk video itu, ini dia: youtu.be/B7MIJP90biM
ragol

3
Saya telah merancang UI untuk sebagian besar karir pemrograman saya dan BUKAN SEKALI saya punya klien berasumsi bahwa prototipe UI berarti perangkat lunak itu 'hampir selesai'. Kedengarannya bagi saya seperti penyaji dari wireframe UI tidak melakukan pekerjaan dengan baik menjelaskan wireframe di depan jika klien entah bagaimana bingung berpikir bahwa proyek hampir selesai.
Graham

2
+1 untuk Napkin L&F. Itu pasti akan menjadi masa depan saya. :)
Kathy

27

Itu tergantung: Anda memerlukan lingkaran umpan balik yang ketat di sekitar bagian terpenting dari fungsi Anda

Jika inti dari apa yang Anda lakukan, bagian yang berisiko dan menakutkan, adalah beberapa mesin internal, maka dapatkan bagian inti bekerja di konsol atau melalui pengujian unit. Sebagai contoh, parser protokol tidak perlu UI untuk mengetahui apakah operasinya benar.

Jika hal keren Anda melibatkan interaktivitas apa pun - interaktivitas Anda harus terus-menerus mengatasi masalah, membuang, dan menemukan kembali - maka pendekatan UI-pertama sangat penting. Misalnya, saya ingin membuat aplikasi agar orang berinteraksi dengan visualisasi data. Hal yang paling penting yang perlu saya pikirkan adalah jika visualisasi itu bermakna, jadi saya mungkin akan membuang setengah lusin pendekatan sebelum memutuskan satu. Saya akan melakukan ini semua sebelum menulis tes unit tunggal.

Ada area abu-abu kabur di antaranya Anda dapat memutuskan kombinasi terbaik tentang cara terbaik berinteraksi dan memvalidasi kode Anda (tes otomatis? UI untuk eksperimen?). Saya secara pribadi telah melakukan keduanya ekstrem dan segala sesuatu di antaranya, dan memutuskan tempat yang tepat untuk menjadi spektrum itu adalah salah satu hal tersulit yang harus saya putuskan dan 100% tergantung pada jenis benda yang saya bangun.


2
Yaitu mengidentifikasi dan mengatasi komponen paling berisiko dan paling kritis di muka untuk mengurangi kemungkinan overruns dan / atau kegagalan. Apakah komponen-komponen itu adalah UI, logika bisnis, dll ..., atau kemungkinan besar, beberapa kombinasi dari semua berbagai komponen.
Alexander

1
Ini kedengarannya seperti Anda sedang berbicara tentang membuat prototipe kepada saya, karena jika Anda masih membuang desain maka itu yang harus Anda iterasi - bukan kode sebenarnya.
Aaronaught

8

Dalam lingkungan Agile, Anda mungkin mendengar diskusi tentang "kerangka berjalan" atau "irisan vertikal tipis". Gagasannya adalah karena perangkat lunak yang berfungsi adalah hal yang penting bagi pengguna, Anda membuat perangkat lunak dalam mode sepotong demi sepotong.

Dalam contoh aplikasi yang Anda sebutkan, Anda akan mulai dengan jendela dan mungkin satu tab, dan membuatnya semuanya bekerja dari depan ke belakang dengan beberapa cara. Kemudian seiring berjalannya waktu, Anda akan menambahkan fungsionalitas dan karenanya tab berdasarkan kasus per kasus, membuat setiap fitur berfungsi saat Anda membangunnya. Ini adalah bagian dari apa yang sering ditunjukkan demonstrasi pelanggan kepada Anda: kesempatan untuk menunjukkan sesuatu yang baru dan dapatkan umpan balik secara instan.

Singkatnya, ya, pekerjaan UI benar-benar merupakan bagian tak terpisahkan dari unit kerja fungsional, jika Anda memiliki UI.

Mulailah dengan sesuatu yang kecil yang berfungsi, dan ulangi fungsinya hingga memberikan perangkat lunak lengkap.


+1 Selalu memiliki bagian yang dapat dikirim yang penting adalah hal yang penting.
JensG

@Jens: "Selalu memiliki barang yang dapat dikirim yang penting" adalah canard. Paling-paling pepatah itu hanya berlaku untuk sebagian kecil aplikasi perangkat lunak. Dalam dunia nyata, aplikasi yang hanya melakukan sebagian dari pekerjaan yang dibutuhkan tidak berguna sedikit pun.
Dunk

Itu pengalamanmu. Saya punya yang berbeda. Proyek besar, dunia nyata dengan banyak tonggak dan pelanggan nyata disertakan.
JensG

1
@Dunk: Aplikasi yang tidak melakukan bagian pekerjaan apa pun kurang bermanfaat dibandingkan aplikasi yang mengerjakan bagian pekerjaan itu. Namun, saya tidak berbicara tentang aplikasi yang "selesai"; Saya berbicara tentang urutan yang harus dibangun aplikasi. Pengalaman saya sesuai dengan JensG: selalu bisa memotong beta berdasarkan apa yang Anda demokan minggu itu dan mengirimkannya kepada klien segera membuat klien jauh lebih bahagia.
Keith B

Ini satu-satunya jawaban yang bisa saya kenali. Yang lain bahkan tampaknya tidak mempertimbangkan kemungkinan bahwa pengembangan produk yang baik tidak dipecah menjadi "UI" dan "back-end". Ini adalah pertanyaan yang hanya akan diajukan oleh seorang programmer pemula atau manajer proyek, dan bukan pertanyaan yang seorang programmer atau PM berpengalaman harus berkenan menjawab langsung. Gagasan untuk menanyakan air terjun yang seharusnya "dikerjakan dulu".
Aaronaught

3

Saya akan merekomendasikan untuk membuat campuran antara fungsionalitas dan UI (dan mendapatkan umpan balik atau pengalaman pengujian SECEPATNYA).

BTW, bukankah cara sebagian besar perangkat lunak GUI dikembangkan? Lihat misalnya ke dalam browser Firefox : dari satu versi ke versi berikutnya, kedua fungsi dan antarmuka pengguna telah berevolusi.


2

Dalam aplikasi besar (berbasis web PHP) yang saya kerjakan, saya mencoba untuk mendapatkan kelas dan metode di tempat pertama, yang mengembalikan nilai dummy . Ini untuk membuat kontrak semu yang bisa digunakan oleh pengembang lain untuk mengimplementasikan UI.

Keuntungan kedua dari metode ini adalah kita dapat mengasah kontrak / antarmuka saat persyaratan UI berubah (dan mereka selalu berubah), bahkan sebelum semua kode ditulis dan dikirim.


Ini adalah sesuatu yang saya coba lakukan. Karena proyek khusus saya diimplementasikan sebagai shell UI besar-besaran dan setiap pemanen datapoint adalah plug-in, masing-masing plug-in bertanggung jawab untuk mengelola komponen UI sendiri. Dengan cara ini tidak ada "kontrak" yang diperlukan untuk orang / kelompok orang tertentu. Asumsinya adalah bahwa kelompok orang yang sama akan mengerjakan plug-in yang diberikan untuk menyelesaikan. Itu bagian dari alasan saya mendesainnya seperti saya. Bergantian, untuk proyek lain ini adalah nasihat yang sangat baik. Jadi, upvote dari saya karena akan bermanfaat bagi orang lain.
RobotHumans

2

Apa yang saya cenderung lakukan adalah mulai dengan UI jelek : sesuatu yang hanya membuang data variabel di layar. Tidak ada font, tidak ada perataan, tidak ada yang benar-benar grafis untuk waktu yang lama. Hanya "Selamat datang pengguna x" dan tombol yang disebut "load pic" dll. Apa yang baik tentang ini adalah Anda akan mengetahui apakah ada sesuatu di backend yang rusak.

Ketika pengembangan berlangsung, Anda mungkin menemukan lebih banyak hal yang perlu dilakukan, atau lebih sedikit. Tetapi pada tahap tertentu, Anda akan memutuskan backend hampir selesai. Sekarang Anda memiliki UI yang berisi semua lampiran yang diperlukan, dan Anda dapat menghabiskan banyak waktu melakukan semua hal grafis.

Namun waspadalah, ini tidak mudah. Anda perlu sedikit tinjauan ke masa depan untuk melihat masalah tertentu yang muncul. Misalnya, Anda mungkin perlu meneliti komponen UI untuk menampilkan data dengan cara yang masuk akal.


Dan di mana pelanggan berperan dalam metodologi Anda? Ingatlah bahwa biasanya pelanggan Anda hanya memiliki gambaran umum tentang apa yang mereka inginkan. Terserah kepada Anda untuk mencari tahu bagaimana "menarik keluar dari mereka" persis apa yang mereka inginkan sehingga Anda dapat membangunnya. Metodologi Anda baru saja membangun apa yang Anda pikir pelanggan inginkan tetapi itu jarang akan menjadi apa yang sebenarnya diinginkan pelanggan. Jadi Anda baru saja membuang banyak waktu untuk mengkode sesuatu yang tidak diinginkan pelanggan.
Dunk

Ah, "pelanggan" saya duduk tepat di sebelah saya, dan saya memiliki latar belakang di bidang yang memberi saya ide yang cukup bagus tentang apa yang diinginkan. Pada dasarnya kami selalu dekat dengan produk akhir, UI bijaksana, dan saya selalu bisa mendapatkan umpan balik. Saya belum mempertimbangkan masalah memiliki umpan balik yang panjang. Saya kira memiliki pengetahuan domain adalah kuncinya.
Carlos

0

Jika Anda menggunakan tonggak yang baik dan sistem pelacakan masalah, Anda dapat menghindari beberapa masalah ini karena sekilas, manajemen dapat melihat seberapa produktif Anda. Mereka akan dapat melihat bahwa Anda 80% menyelesaikan backend dan bahwa UI adalah tonggak sejarah berikutnya; mereka akan dapat melihat bahwa Anda memiliki satu set UI dan tugas backend untuk menyelesaikan untuk tonggak fitur tertentu. Tapi itu semua dimulai dengan persyaratan proyek, dan jawaban Doug T menimbulkan beberapa poin bagus tentang aspek merancang sistem.


0

Berpikirlah dalam sudut pandang pengguna / klien Anda. Sistem perangkat lunak adalah kumpulan fitur yang memberikan nilai pada pengguna / klien ini. Tentu saja masing-masing fitur ini memiliki UI, backend, dan beberapa hal lainnya.

Bangun sistem Anda selalu fitur demi fitur, dan coba bagi dalam fitur yang sangat kecil. Dengan cara ini Anda selalu dekat untuk memiliki sesuatu yang lebih untuk disampaikan kepada pelanggan Anda, ingat bahwa pengembangan perangkat lunak ini bukan tentang membangun versi 1.0 tentang pergi ke versi 1.0.1 ke 1.0.2 dan seterusnya ...


0

Tergantung. Seberapa jelas kebutuhan Anda? Berapa banyak sistem yang dihadapi UI?

Dari pengalaman saya sebagian besar pelanggan tidak tahu apa yang mereka inginkan sampai mereka melihat sesuatu di depan mereka. Jadi saya biasanya menyediakan beberapa frame-kawat dari aspek UI kunci atau memberikan mayoritas UI (tidak berfungsi). Hal ini memungkinkan pelanggan untuk mengubah pikiran mereka pada fitur / fungsi tanpa terlalu banyak dampak karena desain basis data dan struktur kode masih hanya dalam tahap desain - mudah untuk mengubah desain. Ini adalah urutan besarnya lebih mudah / lebih cepat untuk mengubah desain sebelumnya di proyek kemudian di kemudian hari.

Status tangkas, Anda juga harus mengerjakan item yang paling sulit dan yang paling penting terlebih dahulu. Gagal cepat . Jadi begitu pelanggan telah melihat UI saya fokus pada membangun komponen kecil yang berfungsi penuh berbicara yang paling penting dan paling sulit untuk diterapkan terlebih dahulu sehingga Anda tahu sesegera mungkin jika Anda akan mengalami hambatan.

Kemudian Anda memiliki sprint Anda dan memiliki komunikasi yang konstan dengan pelanggan mengembangkan aspek UI dan fungsional pada suatu waktu.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.