Bagaimana saya membuat orang berhenti bikeshedding (fokus pada hal-hal sepele)?

Saya telah ditugaskan untuk mengajarkan basis kode baru kepada tim lain, tetapi saya terus mengalami masalah. Setiap kali saya pergi untuk benar-benar berjalan melalui kode dengan orang-orang, kami tidak mendapatkan terlalu jauh sebelum seluruh latihan berubah menjadi bikeshedding (anggota organisasi yang memberikan bobot yang tidak proporsional untuk masalah sepele) latihan. Karena mereka tidak tahu basis kode, tetapi berpikir mereka perlu membantu memperbaikinya, mereka fokus pada hal-hal yang dapat mereka pahami:

Why is that named that? _{(2 menit untuk menjelaskan alasannya, 10+ menit memperdebatkan nama baru)}

Why is that an abstract base class rather than an interface? _{(2 menit untuk menjelaskan, 10+ menit memperdebatkan manfaat relatif dari keputusan ini)}

...dan seterusnya. Sekarang, jangan salah paham - nama baik dan desain bagus, konsisten adalah penting, tetapi kita tidak pernah membahas apa yang sebenarnya dilakukan kode atau bagaimana sistem dirancang dengan cara yang berarti. Saya telah melakukan beberapa pertemuan wasit untuk mengeluarkan orang-orang dari garis singgung ini, tetapi mereka pergi - terganggu oleh kode apa yang akan / seharusnya terjadi ketika kesederhanaan hewan peliharaan mereka diperbaiki, dan mereka kehilangan gambaran yang lebih besar.

Jadi kami mencoba lagi nanti (atau dengan bagian basis kode yang berbeda) dan karena orang tidak mendapatkan pengetahuan yang cukup untuk mengatasi efek bikeshedding, itu berulang.

Saya sudah mencoba grup yang lebih kecil, grup yang lebih besar, kode, papan tulis, diagram visio, dinding teks raksasa, membiarkan mereka berdebat sampai mati, memotong argumen dengan segera ... beberapa membantu lebih dari yang lain, tetapi tidak ada yang berhasil . Sial, saya bahkan mencoba meminta orang lain dari tim saya menjelaskannya karena saya pikir mungkin saya buruk dalam menjelaskan berbagai hal.

Jadi, bagaimana Anda cukup mendidik programmer lain sehingga mereka berhenti memfokuskan pada hal-hal sepele dan dapat berkontribusi untuk desain?

Saya pikir masalahnya adalah tugas: "Saya telah ditugaskan untuk mengajar tim lain basis kode baru".

Anda telah diberikan pekerjaan yang salah, atau mungkin salah mengartikan pekerjaan yang telah Anda berikan.

Dengan mempresentasikan di tingkat kode, Anda mengundang pemikiran tingkat kode.

Mulai dari level sistem dan sajikan desain dan pilihan desain yang dibuat. Jangan izinkan diskusi panjang: Anda tidak memeriksanya. Izinkan pertanyaan: Anda ingin mereka memahami sistem. Jika orang "akan melakukannya secara berbeda", baiklah. Mungkin setuju. Atau tidak. Tapi lanjutkan. Seperti sekarang ini.

Ketika Anda sampai ke level kode, Anda sudah membuatnya siap dengan terminologi sistem. Nama-nama (saya anggap) akan masuk akal. Sama seperti di atas: tidak ada diskusi panjang, pertanyaan untuk pemahaman. Berpindah.

Sekarang atur beberapa masalah kelas untuk diselesaikan. Bagaimana kita bisa membuat peningkatan X? Pilih sesuatu yang tidak sepele yang "sesuai dengan alur" desain sistem, dan kerjakan apa yang akan Anda ubah. Mereka harus mendapatkan alasan sistem sekarang. Pilih perangkat tambahan lain yang dapat merusak sistem jika dilakukan dengan salah, dan tunjukkan bagaimana itu dapat dilakukan dengan benar. Itu seharusnya menjadi momen Ah Ha bagi mereka. Beberapa bahkan mungkin mengalahkan Anda untuk itu!

Ini adalah pertunjukan yang sulit, terutama setelah awal yang salah yang Anda miliki. Kedengarannya seperti Anda telah menginvestasikan banyak waktu dan usaha, dan mungkin ada sedikit perasaan saya versus mereka. 'Fess, dan mulai lagi. Kami berasumsi bahwa mereka adalah orang pintar. Beri mereka tantangan untuk berpikir di tingkat yang lebih tinggi. Dan bagi grup yang sudah ada dengan memilih berbagai bagian tim yang berbeda untuk sesi baru.

"Parkirkan mereka". Di awal pelajaran, jelaskan apa yang akan Anda diskusikan, dan jelaskan apa yang dianggap Off Topic. Jika Anda ditanya pertanyaan yang jelas-jelas PL, katakan demikian dan teruskan. Jika mereka kembali ke sana, tulis pertanyaan di papan tulis (Ini sangat penting) untuk diskusi nanti dan lanjutkan. Di akhir pelajaran, ketika mereka berada di waktu mereka sendiri, bukan milikmu, perhatikan seberapa cepat pertanyaan-pertanyaan itu diselesaikan.

Tetapkan harapan dengan benar dan jujur, terbuka, dan terbuka.

Pastikan tujuan Anda terbuka dan transparan.

Mulailah diskusi dengan tampilan tingkat tinggi seperti yang dipromosikan oleh andy256 (+1) tetapi juga pastikan bahwa Anda memasukkan tujuan Anda, misalnya

"... seperti yang kita lihat pada masalah ini, mari kita pastikan kita tidak fokus pada x, y dan z. Mari kita juga memastikan bahwa kita tidak melihat detail implementasi seperti a, b, c atau detail sepele seperti j, k, L. Saya tahu pasti ada banyak detail dalam kode dan detail hal-hal yang dapat diatasi, ditingkatkan atau dibuat lebih standar, tetapi mari kita coba dan lihat apa yang sebenarnya dicapai di level yang lebih tinggi terlebih dahulu. "

Jadi, bagaimana Anda cukup mendidik programmer lain sehingga mereka berhenti memfokuskan pada hal-hal sepele dan dapat berkontribusi untuk desain?

Pertama, jangan menganggap kekhawatiran mereka sebagai "hal sepele" atau "bikeshedding". Itu adalah kata-kata menghakimi, dan mereka menghina. Kekhawatiran mereka valid. Mereka tidak penting saat ini.

Kunci dari setiap rapat yang baik adalah agar semua orang tahu:

• mengapa Anda mengadakan rapat dan
• apa yang Anda harapkan dari itu
• berapa lama itu akan bertahan

Nyatakan hal-hal ini di muka, secara eksplisit, dan jelaskan tujuannya.

Misalnya, Anda mungkin berkata: "Rapat ini untuk saya untuk membiasakan Anda dengan paket Foo dan bagaimana itu digunakan dalam modul pelaporan kami. Tujuan saya adalah membuat Anda cukup memahami tentang Foo sehingga Anda dapat bekerja pada proyek Laporan Bar yang akan datang minggu depan. Saya ingin kita selesai dalam 90 menit ke depan. "

Kemudian, ketika sebuah topik muncul, itu bisa seperti ini:

Orang baru: "Mengapa FooWidget diimplementasikan sebagai pola fasad?"

Anda: "Yah, saya pikir itu karena (penjelasan singkat tentang keputusan desain)" atau "Saya tidak tahu."

Jika jawabannya cukup, itu bagus. Jika tidak, dan itu berlanjut:

NP: "Tidakkah Anda pikir itu akan lebih baik dilakukan sebagai seorang lajang?"

Anda: "Saya belum benar-benar memikirkannya, tetapi saya ingin terus bergerak maju dengan menjelaskan bagaimana FooWidget bekerja."

NP: "Tapi jika itu dilakukan sebagai singleton maka kita bisa -"

Anda: "Saya minta maaf mengganggu, tetapi saya harus tetap fokus pada cara kerja FooWidget ini. Rapat ini hanya dijadwalkan hingga pukul 11:00 dan kami harus banyak melewatinya. Diskusi desain harus menunggu waktu lain . "

Setelah melalui satu atau dua kali, Anda dapat menyingkatnya menjadi "Itu di luar ruang lingkup pertemuan ini."

Perhatikan bahwa Anda tidak mengatakan "Itu bodoh untuk dikhawatirkan" atau "Tidak masalah" atau "Diam" atau "Anda terlalu baru untuk mendapat masukan." Anda hanya memfokuskan pertemuan pada apa yang perlu dilakukan dan waktu yang diperlukan.

Dalam organisasi tertentu Anda tidak akan pernah bisa mencapai ini. Banyak organisasi menghargai perselisihan politik dan cara mendaki tangga lebih dari kapasitas intelektual, ketekunan, dan kesetiaan. Dan mengapa tidak? Memanjat tangga menempatkan orang pada posisi kekuasaan, memungkinkan mereka untuk meningkatkan kehidupan pribadi mereka dengan pendapatan yang lebih bebas dan benar-benar tidak pernah menjadi usang.

Bandingkan perselisihan kekuasaan ini dengan penyelesaian masalah aktual, pemikiran abstrak, dan pengambilan keputusan tentang masalah-masalah sulit yang mereka mungkin bertanggung jawab atas konsekuensi di kemudian hari, dan banyak karyawan sangat membebani upaya untuk bersepeda sebanyak mungkin.

Satu-satunya saran yang saya sarankan adalah agar Anda membuatnya lebih jelas, dalam konteks organisasi Anda, jika mungkin, bahwa nasib pribadi para peserta ini tergantung pada pemahaman, kontribusi, dan upaya mereka terhadap masalah nyata yang Anda coba selesaikan. Jika itu arsitektur perusahaan, yang dinyatakan dalam basis kode -er ini dan semua kegagalannya, itu saja. Jelaskan kepada mereka bahwa mereka harus memberikan masukan yang berarti tentang hal itu . Bukan sembarang keacakan, yang kebetulan adalah kesayangan seseorang yang senior atau lainnya dan akan mendapatkan poin-poin brownies yang bagus dengan menyetujui dengan seseorang senior tersebut.

Ini sering kali sulit dilakukan, karena seseorang senior biasanya tidak memahami teknologi yang terjadi, tidak tertarik, dan sayangnya, mengendalikan bahan mentah: waktu karyawan; menyewa & memecat, politik ruang konferensi, promosi, dll. dengan serius, dan lain-lain.

Apa yang Anda sebut bikeshedding, saya sebut mengubah aliran pemikiran seseorang menjadi pemikiran kita sendiri. Dengan mendiskusikan nama, pola, mereka dapat memahami kode ke dalam istilah mereka sendiri dan tidak ada cara untuk mencegahnya, itu diperlukan.

Selain itu, tidak perlu melakukan langkah-langkah yang sangat terperinci dari seluruh basis kode, karena detail akan dilupakan jauh sebelum mereka mengerjakannya.

Berdasarkan dua ide ini, saya akan menyarankan untuk memecah basis kode menjadi unit, dan peserta didik menjadi kelompok dua orang. Untuk setiap unit kode, masing-masing kelompok akan memiliki, katakanlah 25 menit (tergantung pada LOC tentunya), untuk dapat melakukan walkthrough 5-10 menit dari kode ke yang lain. Tiga menit pertanyaan dan ulangi dengan unit berikutnya. Jelaskan adalah kata kuncinya; mereka harus memastikan yang lain mengerti semua itu.

Anda hanya akan berada di sana untuk menegakkan waktu, tidak ada topik di luar dan mengendalikan unit telah cukup dipahami. Mereka akan menjadi aktor pembelajaran mereka dan akan lebih fokus pada menjelaskan kepada yang lain daripada bikeshedding.

Anda mungkin memerlukan skema gambar tangan tingkat tinggi dari mereka dari unit kode, yang akan disalin dan disimpan pada dokumen tim-bersama, sehingga mereka memiliki sesuatu yang nyata untuk dirujuk di masa depan. Itu bagus untuk menyimpan kenangan juga.

Maaf jika Anda sudah mencobanya ...

Sudahkah Anda mencoba membuat pra-pelajaran yang orang pandang secara individual?

Buat video atau presentasi singkat yang menjelaskan konten, bagaimana kode bekerja, atau pada dasarnya semua yang ingin Anda ajarkan dalam format di mana mereka perlu melihatnya sendiri dan mempelajari informasi yang Anda coba ajarkan kepada mereka.

Kemudian Anda menggunakan sesi berbasis tim untuk membahas masalah yang terkait dengan konten. Anda perlu mengidentifikasi dengan jelas bahwa sesi tim adalah untuk membahas dan mengatasi masalah yang terkait dengan konten saja.

Jika Anda memberikan pelajaran kepada orang-orang secara individual, Anda mungkin dapat menghindari masalah sosial lainnya di mana satu masalah dapat menjadi suara kelompok sebagai kolektif dan mengalihkan perhatian dari tujuan sebenarnya dari pelajaran.

Cobalah mengajari mereka desain basis kode terlebih dahulu, membimbing mereka di sekitar arsitektur, SEBELUM Anda mulai melihat contoh-contoh spesifik. Dengan begitu mereka dapat melihat bagaimana contoh kode yang Anda lihat cocok dengan gambar yang lebih besar. Pikirkan tentang bagaimana program pelatihan Anda disusun. Dan sertakan motivasi bisnis di balik desain.

Saya menghabiskan beberapa tahun melatih pengembang lain, dan saya tidak pernah masuk ke kode sebelum menunjukkan kepada mereka bagaimana sistem dipasang bersama. Kemudian ketika saya membuat mereka melakukan latihan kode dalam kerangka pertanyaan terstruktur dan sesuai topik.