Bagaimana cara mengatasi berbagai gaya pengembangan (top-down vs bottom-up) dalam sebuah tim?

37

Katakanlah Anda baru saja mulai bekerja dalam tim yang sangat kecil pada proyek {saat ini relatif kecil, meskipun semoga lebih besar nanti}. Perhatikan bahwa ini adalah proyek aktual yang dimaksudkan untuk digunakan oleh pengembang lain di dunia nyata, bukan proyek akademik yang dimaksudkan untuk dihapus pada akhir semester.
Namun, kode belum dirilis ke orang lain, jadi belum ada keputusan yang ditetapkan.

Metodologi

Salah satu dari Anda suka memulai pengkodean dan membuat potongan-potongan tersebut cocok bersama saat Anda pergi sebelum Anda tentu memiliki gagasan yang jelas tentang bagaimana sebenarnya semua komponen akan berinteraksi (desain bottom-up). Salah satu dari Anda lebih suka melakukan seluruh desain terlebih dahulu dan memakukan rincian semua komponen dan komunikasi sebelum mengkode solusi.

Asumsikan bahwa Anda bekerja pada sistem baru daripada meniru yang sudah ada, dan dengan demikian tidak selalu jelas seperti apa desain akhir yang tepat. Jadi, di tim Anda, anggota tim yang berbeda kadang-kadang memiliki gagasan yang berbeda tentang persyaratan apa yang bahkan diperlukan untuk produk akhir, apalagi bagaimana cara mendesainnya.

Ketika pengembang bottom-up menulis beberapa kode, pengembang top-down menolaknya karena potensi masalah di masa depan yang dibayangkan dalam desain terlepas dari kenyataan bahwa kode dapat menyelesaikan masalah, percaya bahwa lebih penting untuk mendapatkan desain yang benar sebelum mencoba kode solusi untuk masalah tersebut.

Ketika pengembang top-down mencoba untuk mengerjakan desain penuh dan masalah yang dibayangkan sebelum mulai menulis kode, pengembang bottom-up menolaknya karena pengembang bottom-up tidak berpikir beberapa masalah akan benar-benar muncul dalam praktik , dan berpikir bahwa desain mungkin perlu diubah di masa depan ketika persyaratan dan kendala menjadi lebih jelas.

Masalah

Masalah yang diakibatkan oleh hal ini adalah bahwa pengembang dari bawah ke atas pada akhirnya membuang-buang waktu karena pengembang dari atas ke bawah sering memutuskan solusi yang ditulis oleh pengembang dari bawah ke atas harus dihapus karena cacat desain, sehingga perlu untuk -menulis kode.

Pengembang top-down akhirnya membuang-buang waktu karena alih-alih memparalelkan pekerjaan, pengembang top-down sekarang sering duduk untuk mengerjakan desain yang benar dengan pengembang bottom-up, membuat serial keduanya ke titik di mana bahkan mungkin lebih cepat untuk 1 orang melakukan pekerjaan daripada 2.

Kedua pengembang ingin tetap bekerja bersama, tetapi tampaknya kombinasi tersebut sebenarnya tidak membantu salah satu dari mereka dalam praktik.

Tujuan

Tujuan umum jelas untuk memaksimalkan efektivitas pengkodean (yaitu meminimalkan pemborosan waktu) dan menulis perangkat lunak yang bermanfaat.

Pertanyaan

Sederhananya, bagaimana Anda mengatasi masalah ini dan mengatasi situasi ini?

Satu-satunya solusi efisien yang dapat saya pikirkan yang tidak membuang waktu adalah membiarkan setiap pengembang mengikuti gayanya sendiri untuk desain. Tapi ini lebih sulit daripada kedengarannya ketika Anda meninjau kode dan benar-benar perlu menyetujui perubahan satu sama lain, dan ketika Anda mencoba merancang kerangka kerja yang koheren untuk digunakan orang lain.

Apakah ada cara yang lebih baik?

design development-methodologies methodology

— Mehrdad
sumber

12

Bagi saya kedengarannya seperti orang "top down" ingin melakukan Big Design Up Front. Sementara pria "bawah atas" hanya ingin memulai peretasan dan mendapatkan solusi secara bertahap.

— Euforia

24

Keduanya benar. Anda perlu menemukan kompromi yang disetujui keduanya. Satu pihak perlu belajar bahwa beberapa desain di depan mungkin menghemat waktu dalam jangka panjang. Pihak lain perlu belajar bahwa pada satu titik, bermanfaat untuk berhenti berpikir dan mulai bekerja.

— Euforia

8

@ Euphoric: Saya suka ini. Satu orang mengatakan keduanya salah, satu orang mengatakan keduanya benar, satu mengatakan mereka perlu kompromi, satu mengatakan mereka harus memecah tugas menjadi beberapa bagian dan hanya mengerjakan hal-hal yang berbeda. Pesan yang sebenarnya saya terima adalah bahwa tidak ada yang benar-benar tahu apa pendekatan yang tepat!

— Mehrdad

4

Kata "komunikasi" muncul di pikiran.

— Bryan Oakley

4

Siapa manajernya? Siapa yang membuat keputusan?

— corsiKa

54

Jelas mereka berdua salah.

Cowok dari bawah ke atas itu meretas kode dan tidak akan pernah menghasilkan sesuatu yang melakukan apa yang seharusnya dilakukan - itu akan menjadi churn terus menerus ketika persyaratan yang tidak diketahui ditentukan.

Pria top down dapat menghabiskan waktu selama pada visi arsitektur dan tidak menghasilkan sesuatu yang produktif juga.

Namun, jalan tengah adalah ideal - jika Anda tahu tujuan yang sedang Anda kerjakan (yang Anda dapatkan dari karya desain yang luas) dan mulai mengkodekannya (tanpa perencanaan terperinci) maka Anda menuai hasil dari sistem yang ada. terorganisir dan dikembangkan secara efisien.

Ngomong-ngomong disebut Agile (bukan versi BS lincah yang dipraktikkan beberapa orang di mana prosedur lebih penting daripada perangkat lunak yang bekerja) tetapi tangkas sejati yang bekerja dengan bekerja menuju tujuan akhir yang umum dijelaskan dan dipahami.

Untuk memperbaiki masalah di sini, cobalah pendekatan Agile (Kanban mungkin yang terbaik) yang keduanya akan memaksa pria top-down untuk melakukan pekerjaan, dan akan memaksa pria bottom-up untuk melakukan perencanaan pada apa yang dia coba capai.

— gbjbaanb
sumber

10

+1 untuk versi BS gesit. Ada begitu banyak orang yang salah gesit saat ini ...

— T. Sar - Reinstate Monica

17

Saya tidak tahu apakah jawaban Anda hanya menjadi kacau karena sensasional "mereka berdua salah" pada awalnya, tetapi sisanya tampaknya bergantung pada asumsi yang salah. Perhatikan dalam pertanyaan yang saya katakan bahwa kedua orang itu bahkan mungkin lebih produktif secara individual daripada bekerja bersama. Jadi tentu saja bukan itu masalahnya bahwa pengembang top-down tidak menyelesaikan pekerjaan nyata. Demikian pula, itu juga tidak seperti pengembang bottom-up tidak menghasilkan sesuatu yang melakukan apa yang seharusnya dilakukan. Sebaliknya, kedua gaya itu hanya berbenturan ketika mereka bekerja bersama karena cara masalah itu didekati.

— Mehrdad

18

@Mehrdad juga, kebanyakan orang lebih cepat ketika bekerja secara individual, tetapi Anda mendapatkan perangkat lunak yang lebih baik ketika bekerja bersama - seperti kutipan mengatakan "jika Anda ingin pergi cepat, bepergian sendiri. Jika Anda ingin pergi jauh, bepergian bersama" . Jadi Anda bertanya bagaimana membuat orang-orang ini bekerja sama dengan baik - dan saya memberi Anda jawaban yang saya pikir akan berhasil, itu membatasi mereka berdua dalam kolaborasi tanpa memaksa mereka untuk bekerja sebagai satu - metodologi pengembang yang sama-sama senang diikuti oleh keduanya. Anda mengatakan sendiri bahwa konflik mereka memengaruhi produktivitas mereka.

— gbjbaanb

1

@Mehrdad Jawaban yang Anda butuhkan tetapi tidak layak sekarang;)

— Gila

2

@ThalesPereira Apa itu "versi BS tangkas"?

— Sjoerd222888

23

Kedua pengembang harus saling menghormati satu sama lain.

Orang dari atas ke bawah harus menghargai kenyataan bahwa orang dari bawah ke atas mungkin telah menemukan sesuatu yang benar-benar berfungsi. Seperti yang dikatakan oleh salah satu profesor "quant" saya, "Sebuah model kerja bernilai 1000 tebakan." Jika itu masalahnya, orang dari atas ke bawah harus mempertimbangkan untuk melakukan kembali "desain" -nya untuk mengakomodasi pekerjaan orang dari bawah ke atas.

Orang dari bawah ke atas juga harus menghormati "kerangka" orang atas ke bawah, dan menyadari bahwa itu baik untuk menghindari usaha yang sia-sia, menyelesaikan masalah yang salah, keluar dari topik, dll. Pembuat kode dari bawah ke atas setidaknya harus mengingat apa yang terjadi. orang top down sedang berusaha untuk melakukan, dan mencoba untuk mengatasi setidaknya kekhawatiran top downer, sebagaimana dinyatakan dalam kerangka kerja. Itu akan benar bahkan jika bagian bawah-atas tidak setuju dengan bagian-bagian kerangka itu sendiri.

— Tom Au
sumber

7

Anda dapat meminimalkan hilangnya waktu yang dihabiskan oleh setiap pengembang jika Anda memecah tugas besar menjadi beberapa yang lebih kecil dan lebih fokus. Mintalah mereka bekerja sama secara erat sehingga tidak satu pun dari mereka berada di depan yang lain. Sprint pendek, dan kiriman kecil berjalan jauh. Lebih mudah untuk memperbaiki kesalahan kecil daripada kesalahan besar.

Mungkin terlihat berlawanan dengan tujuan Anda, tetapi pemrograman pasangan berfungsi. Ada hal-hal yang Anda tidak akan tangkap sendiri segera, kadang-kadang berjam-jam atau bahkan berhari-hari. Jika bekerja secara langsung pada tugas bersama tidak ada dalam pertanyaan, coba tinjau kode / standup lebih sering sepanjang minggu.

Beri tahu semua orang!

Jika Anda melihat devs membuang kode karena mereka pergi di dunianya sendiri, Anda perlu menangkap dan mendamaikan konflik secepat dan seefisien mungkin. Bos Anda akan menghargainya, dan tim akan menghargai tidak harus membuang pekerjaan seminggu karena dia tidak tahu apa yang dilakukan orang lain.

Anda juga harus melihat mereka bekerja bersama sebagai berkah. Fakta bahwa mereka bekerja bersama dan memperbaiki kesalahan mereka saat mereka pergi adalah pertanda baik. Aku berhasil melewati setengah dari posmu sambil berpikir "lelaki ini mungkin saling membenci ..." dan mengejutkanku kau mengatakan mereka ingin tetap bekerja bersama.

Saya pikir kutipan ini sesuai dengan skenario Anda.

"Jika dua orang menyetujui segalanya, salah satunya tidak perlu." ~ Beberapa Orang Tua

— Dat Boi
sumber

7

Ini sebenarnya terdengar seperti skenario yang ideal bagi saya. Kemudian lagi, saya adalah kedua pengembang tersebut pada saat bersamaan. Saya suka menyusun "gambaran besar" dalam bentuk catatan yang akhirnya menemukan jalan mereka ke pelacak masalah. Kemudian saya mulai memikirkan detail implementasi dari bawah ke atas. Gambaran besar berkembang ketika saya mendapatkan pemahaman yang lebih baik tentang bagaimana potongan-potongan akan cocok bersama-sama, dan potongan-potongan berkembang seiring persyaratan berubah dan saya mendapatkan ide-ide baru.

Mungkin itu model yang bagus untuk banyak otak.

— Kevin Krumwiede
sumber

5

Saya menemukan Masalah GitHub sebagai win-win yang luar biasa untuk menyisihkan ide acak untuk fitur masa depan, masalah potensial, catatan untuk diri sendiri, dll. Itu membuat mereka keluar dari kepala saya, tetapi dengan cara di mana saya bisa yakin saya akan dapat menemukannya nanti.

— hBy2Py

6

Menurut pendapat saya, mereka adalah profil yang saling melengkapi dan mungkin berakhir dengan sangat baik. Baik pengkodean dan desain adalah fase yang diperlukan dalam pemrograman dan Anda tidak ingin berakhir di tim di mana tidak ada yang ingin melakukan X, semua yang Anda butuhkan adalah sedikit organisasi (lihat saya dapat memiliki kata yang berani juga!)

Hal ini dapat dilakukan melalui pengawasan seperti yang ditunjukkan orang lain, tetapi lebih baik dilakukan dengan kesepakatan bersama pada jadwal iterasi kapan untuk mendesain dan kapan untuk kode, dan menghindari secara umum untuk kode apa yang saat ini sedang dirancang.

Poin bonus, segera setelah proyek terciprat dalam modul-modul yang lebih kecil, programmer top-down dapat merancang hal-hal yang tidak sedang dilakukan oleh programmer bottom-up, menjadikannya sebuah fase di mana keduanya melakukan yang mereka suka. Namun ini menyiratkan kemampuan dari keduanya untuk membuat penyesuaian yang diperlukan ketika saatnya tiba untuk menyatukan semuanya.

— Arthur Havlicek
sumber

1

Memberi +1 sejak yang terakhir adalah solusi yang dapat ditindaklanjuti dalam beberapa kasus, tetapi sebenarnya tidak benar-benar layak di sini. Masalahnya adalah programmer bottom-up ingin berkontribusi pada desain juga, dan programmer top-down ingin berkontribusi pada kode juga. Membagi dua tugas-bijaksana akan masuk akal di sebuah perusahaan di mana Anda memiliki manajer, PM, pengembang, dll. Tetapi dalam tim kecil seperti ini di mana semua orang ingin bekerja pada seluruh sistem, tidak satu pun dari mereka akan senang membagi tugas seperti itu.

— Mehrdad

2

Idealnya, keduanya akan bekerja pada desain dan pengkodean, itu sebabnya memiliki jadwal, bahkan jika tim Anda kecil, itu bagus. Cukup rencanakan beberapa "rapat" ketika keduanya dapat mengajukan pertanyaan dan kontribusi tentang bagaimana merancang / mengimplementasikan modul, dan mengalokasikan waktu untuk tugas berikutnya dan merencanakan pertemuan berikutnya. Agile-like kecuali Anda tidak harus menyebutnya seperti itu;)

— Arthur Havlicek

Sayangnya, dalam kasus seperti itu, pria top-down akan membuat rencana, dan pria bottom-up akan mengabaikannya. yaitu. keduanya akan terus melakukan hal mereka sendiri.

— gbjbaanb

5

Satu catatan: Anda bilang

Asumsikan bahwa Anda bekerja pada sistem baru daripada meniru yang sudah ada, dan dengan demikian tidak selalu jelas seperti apa desain akhir yang tepat.

Ini adalah bagian dari masalah: Kecuali jika Anda mengerjakan proyek kecil untuk masalah yang sudah diselesaikan, sebenarnya tidak ada desain akhir yang tepat . Ada banyak kemungkinan desain. Ingatlah bahwa kecuali Anda melakukan ini untuk meningkatkan ego karena keindahan kode Anda, tujuan akhirnya adalah aplikasi yang berfungsi. Itu dia. Bagaimana Anda sampai di sana tidak relevan, dan cara terbaik untuk membiarkan keduanya berjalan cepat adalah membuat mereka bekerja bersama, dengan cara yang saling melengkapi.

Seperti yang dikatakan orang lain, kedua pandangan itu bisa benar dengan cara tertentu. Jauh dari biasa bagi dua devs untuk tidak setuju pada praktik, terutama untuk sesuatu yang subjektif seperti proses desain dan pengembangan. Anda memiliki dua orang di sini yang bersemangat tentang apa yang mereka lakukan, dan memiliki pengetahuan tentang cara melakukannya: menerima itu!

Ada potensi besar di sini bagi Anda untuk memungkinkan kedua orang untuk bekerja dengan cara mereka sendiri, dan masih mencocokkan potongan untuk mendapatkan aplikasi yang berfungsi.

Saya ingin mereka berdua duduk dan berdiskusi, mendorong mereka untuk melihatnya dari sudut pandang orang lain.
Setelah diskusi itu, Anda dapat mulai berbicara tentang perencanaan: ini harus dilakukan sebagai sebuah tim, dengan pemahaman bahwa keduanya tidak harus 'mengakui' yang lain, tetapi kompromi perlu dilakukan. Ada banyak cara untuk merencanakan arsitektur untuk basis kode yang memungkinkan untuk diperluas lebih mudah nanti, tanpa memperkenalkan satu ton kode tambahan.
Setelah Anda dapat membuat mereka datang ke semacam gencatan senjata, biarkan mereka menjadi liar! Biarkan drive 'top down guy' merencanakan arsitektur tingkat tinggi, antarmuka, hierarki, dll. Biarkan 'bottom up guy' masuk dan mulai menulis kode begitu ada beberapa modul yang direncanakan. Buat mereka setuju secara formal untuk menerima metode pihak lain sebagai hal yang baik untuk keseluruhan proyek: Perencanaan untuk memungkinkan perubahan mudah di masa depan itu baik, tetapi tidak harus segera dikodekan dengan cara itu. Membuat antarmuka dan mematikan metode untuk mendapatkan struktur kode, dan menerima bahwa sedikit kode yang baik untuk masa depan tidak akan benar-benar ditulis sampai diperlukan.
Mintalah mereka meninjau desain dan kode secara bersamaan, bersama-sama. Iterasi melalui siklus di mana Anda menyelam jauh ke dalam beberapa segmen arsitektur, rencanakan lebih detail, dan tulis bagian-bagian itu.
Ini mungkin poin yang paling penting: Fasilitasi poin dalam siklus di mana mereka berbicara tentang proses saja, daripada pekerjaan yang dilakukan. Renungkan dinamika yang sedang dibangun: ada empat pertanyaan yang harus Anda tanyakan. Apa yang berjalan baik yang harus terus kita lakukan? Apa yang buruk yang harus kita hentikan? Apa yang kita lewatkan? Apa yang bisa kita lakukan tentang apa yang kita lewatkan?

Ini akan membutuhkan beberapa pekerjaan: Anda harus membuat mereka setuju untuk bekerja bersama dengan cara mereka sendiri. Tidak mudah bagi sebagian orang untuk mengakui bahwa tidak ada satu pun cara yang benar dalam melakukan sesuatu. Yang penting bukan ke mana Anda bekerja, atau seperti apa kode pada akhirnya; yang penting adalah bahwa kedua orang yang terampil dan berpengetahuan ini belajar bagaimana bekerja bersama dengan baik. Itu bukan sesuatu yang bisa Anda katakan pada mereka; yang dapat Anda lakukan adalah membimbing mereka melalui proses belajar bagaimana melakukannya sendiri. Sama seperti tidak ada desain yang tepat, tidak ada cara yang tepat bagi orang untuk bekerja.

— DrewJordan
sumber

4

Secara umum, dalam pengalaman saya selama karir saya, ada desain yang tidak memadai di depan. Dan desain yang terjadi di depan berkualitas rendah . Ini buruk. Sebagian besar karena hasilnya (pada tingkat yang lebih besar atau lebih kecil) melempar lumpur ke dinding dan melihat apa yang menempel. Utang teknis akan dikerjakan sejak awal.

Top-down umumnya lebih unggul daripada bottom-up. Meskipun saya tidak akan mengesampingkan bottom-up sepenuhnya. Alasan untuk ini adalah bahwa top-down memaksa Anda untuk memikirkan masalah secara lebih luas dan mengajukan pertanyaan yang lebih baik . Ini memperkuat poin pertama di atas ... mengarah ke desain kualitas yang lebih tinggi dan biasanya sangat memengaruhi banyak pekerjaan tingkat bawah. Hal ini mengurangi kerja ulang yang cukup besar yang seringkali diperlukan jika komponen tingkat rendah dibangun terlebih dahulu.

Ada risiko yang tidak signifikan bahwa jika komponen bottom up dibangun terlebih dahulu, tekanan pengembangan mencoba untuk mencetak persyaratan bisnis ke komponen yang telah direkayasa. Ini juga buruk. Persyaratan bisnis harus mendorong desain, yang harus mendorong implementasi. Apa pun yang terjadi dengan cara lain akan mengarah pada hasil yang lebih rendah.

— Brad Thomas
sumber

2

"Ada desain yang tidak memadai di bagian depan. Dan desain yang terjadi di bagian depan adalah kualitas rendah."

— user1172763

1

+1 untuk "Persyaratan bisnis harus mendorong desain". Dengan tidak adanya persyaratan bisnis, desain awal apa pun hanyalah masturbasi mental, namun tanpa persyaratan bisnis maka hanya meretas akan hampir selalu menjadi buang-buang waktu dan berpotensi menghambat buang-buang waktu dan upaya ketika Anda menemukan bahwa Anda membuang begitu banyak upaya pada sesuatu yang tidak berguna.

— maple_shaft

1

@ user1172763 desain berkualitas baik> desain berkualitas rendah> tidak ada desain. Bahkan karya desain termiskin mengandung beberapa nilai setidaknya memberikan fokus pada visi, yaitu bertindak untuk membimbing Anda ke arah yang benar. Tidak ada rencana berarti tidak ada arah berarti kekacauan akhirnya.

— gbjbaanb

4

Tidak ada pendekatan yang memadai. Tampaknya masing-masing dari mereka pintar atau cukup berpengalaman untuk menyadari kedatangan pendek dari pendekatan lain (mungkin mereka terbakar?) Tetapi gagal melihat kedatangan pendek dari pendekatan yang mereka pilih sendiri ...

Yang benar adalah, pendekatan campuran diperlukan:

hampir tidak mungkin menghasilkan desain "benar" di muka; diperlukan tingkat eksperimen untuk mengidentifikasi titik-titik rasa sakit, kemacetan, ... (petunjuk: titik-titik itu tidak pernah Anda pikirkan sebelumnya)
hampir tidak mungkin untuk pergi ke mana pun dengan hanya "pergi", Anda lebih cenderung berakhir di suatu tempat yang tidak Anda inginkan, atau hanya berputar-putar, daripada apa pun

Namun, mencampurkan keduanya, Anda dapat:

memiliki sketsa kasar yang memberi arah dan kerangka infrastruktur
dan mengembangkan komponen yang sesuai dengan visi ini

Karena tidak ada sistem yang ada yang memenuhi tujuan ini, penting untuk menyadari bahwa:

eksperimen / prototyping akan diperlukan
iterasi, oleh karena itu, akan diperlukan

Oleh karena itu, penekanan harus diletakkan pada pencapaian sistem "kerja" sesegera mungkin, bahkan jika ini berarti mengabaikan kasus sudut, dll ... Ini adalah konsep "irisan vertikal tipis": bukannya membangun fondasi rumah , maka dinding, maka struktur atap, ... dan hanya memperoleh sesuatu yang dapat digunakan di akhir (atau tidak pernah mendapatkan itu, atau tidak benar-benar menjadi digunakan) ... lebih baik bukan membangun sepenuhnya dilengkapi ruang pertama, seperti kamar mandi. Ini dapat digunakan segera, dan dapat digunakan untuk mengumpulkan umpan balik.

Agar umpan balik menjadi berharga, yang terbaik adalah mengerjakan bagian inti terlebih dahulu.

Jadi, apa hubungannya dengan rekan kerja Anda?

Hal pertama yang pertama adalah bahwa keduanya perlu memahami kebutuhan untuk berkolaborasi dan kebutuhan untuk menyetujui jalan ke depan: terus-menerus ditegur, seperti mereka, terikat untuk membuat orang-orang gelisah dan mempengaruhi motivasi seseorang. Saya telah mempresentasikan di atas apa yang saya temukan bekerja dengan baik dalam praktek di beberapa proyek, Anda dapat menggunakannya sebagai saran.

Kemudian, mereka perlu menyetujui siapa melakukan apa. Perhatikan bahwa dalam pendekatan jalan tengah yang digarisbawahi di atas, keduanya harus mengerjakan tugas yang mereka hargai.

Perhatikan bahwa baik membangun kerangka dan membangun batu bata paling baik didekati secara bertahap.

Keduanya harus mendapatkan sketsa kasar dari kerangka, dan kemudian memutuskan bersama mana "irisan tipis" yang menjadi fokus
Laki-laki dari bawah ke atas harus mulai mengerjakan bagian "irisan tipis" yang paling dipahami.
Pria top-down harus mulai menyempurnakan kerangka, idealnya menangani bagian yang paling menghalangi terlebih dahulu untuk menyelesaikan potongan

Bilas dan ulangi sampai Anda berhasil mengiris; menumpuk umpan balik di sepanjang jalan untuk mengubah sesuai kebutuhan.

Hati-hati: ini adalah prototipe, keduanya harus siap untuk membuangnya dan mulai dari awal pada desain yang sama sekali berbeda.

— Matthieu M.
sumber

Hapus 4 kata-kata utama, mereka adalah punch-line yang tidak perlu (dan bertentangan total dengan jawaban yang dinyatakan seimbang ini).

1

@Tibo: Kamu kasar, jika kita bahkan tidak bisa mengguncang orang sedikit ...: D

— Matthieu M.

Setuju :) Saya cenderung suka mengguncang mereka yang tinggal di menara gading, berharap semuanya akan hancur di bawah kaki mereka. -1 -> +1 btw.

Akhirnya, orang lain yang melihat kebijaksanaan dalam mendapatkan prototipe ujung ke ujung dengan fungsi minimal-belum-komprehensif sedini mungkin. Terima kasih atas jawaban ini, saya senang membacanya.

— Analisis Fuzzy

3

Yang Anda butuhkan adalah pemimpin (atau penyelia) yang memahami pengembangan perangkat lunak, dan yang membuat keputusan tentang pendekatan mana yang harus digunakan dalam proyek. Jika perlu, pemimpin mengarahkan pengembang untuk bekerja dengan cara tertentu, terlepas dari preferensi pribadi mereka.

Satu-satunya solusi efisien yang dapat saya pikirkan yang tidak membuang waktu adalah membiarkan setiap pengembang mengikuti gayanya sendiri untuk desain.

Sebenarnya, itu bisa sangat tidak efisien ... karena kemungkinan besar akan ada banyak konflik dan pengerjaan ulang. Lebih buruk lagi, Anda mungkin berakhir dengan kegagalan total proyek.

— Stephen C
sumber