Tampaknya dalam tim pengembangan kecil (20+ orang) seharusnya tidak ada masalah dengan perpecahan, bekerja pada kode umum dan membuat keputusan teknis. Tapi kita semua tahu bahwa ini tidak begitu (belum lagi tim seperti kami, di mana 80+ orang). Tiga tahun lalu, untuk menyelesaikannya, kami mulai mengadakan konferensi pengembang internal DevForum mingguan. Di bawah kucing Anda akan belajar tentang bagaimana itu membantu kami, mengapa format lain (seperti pertemuan mingguan atau Tinjauan Sprint) dan instruksi untuk membuatnya tidak selalu berhasil.
Selama tiga tahun kami telah mengumpulkan banyak konten yang bagus. Oleh karena itu, akan ada serangkaian artikel yang ditulis berdasarkan pidato di DevForum :
1. Kucing Schrodinger tanpa kotak: masalah konsensus dalam sistem terdistribusi.
2. Infrastruktur sebagai kode: kenalan pertama.
3. Infrastruktur sebagai Kode: bagaimana mengatasi masalah dengan XP.
4. Bagaimana server setuju satu sama lain: Algoritma konsensus didistribusikan Raft.
5. Kuda sudah mati - menangis: transisi dari tslint ke eslint.
6. Generasi kontrak naskah untuk model c #. (Sedang berlangsung ...)
...
Apa itu DevForum dan masalah apa yang dipecahkannya?
DevForum adalah acara internal mingguan kami untuk pengembang Dodo IS. Sudah berjalan pada hari Kamis selama tiga tahun. Pengembang berkumpul dan mencurahkan satu jam untuk berkomunikasi satu sama lain.
Pada pertemuan ini, kami membahas masalah teknis yang relevan dengan seluruh tim. Satu jam waktu, dua laporan setengah jam, waktu untuk pertanyaan dan jawaban.
Masalah apa yang dipecahkan oleh konferensi internal?
Untuk maju menuju pencapaian tujuan bersama, penting bagi kita untuk mempertahankan fokus pada masalah perusahaan yang signifikan. Untuk sinkronisasi keseluruhan dari semua Dodo, kami memiliki pertemuan mingguan pada hari Senin. Semua karyawan, mitra / pewaralaba hadir di sana, rekaman rapat dapat dilihat
di domain publik . Untuk sinkronisasi dengan bisnis dan mitra, kami mengatur
Ulasan Sprint dua mingguan. Untuk fokus tunggal dan sinkronisasi teratur tim TI, Anda perlu lebih banyak perendaman dalam "daging" teknis. Inilah yang kami lakukan di DevForum.
Berikut adalah daftar masalah dan solusinya:
- Berbagi pengetahuan . Sekarang kami memiliki 80+ pengembang di tim kami. Masing-masing dari mereka memiliki latar belakang sendiri, spesifik pekerjaannya sendiri, tingkat perendamannya sendiri. Tim kami dibagi berdasarkan produk. Dan mungkin saja dua tim independen harus melewati hutan yang sama. Ketika mereka memiliki kesempatan untuk berbagi praktik terbaik, pikiran, kesuksesan, atau sebaliknya satu sama lain, itu menjadi lebih baik. Ada kemungkinan kecil untuk tidak menginjak penggaruk seseorang.
Plus, tim kami terus berkembang, orang-orang baru datang dan mendapatkan alat yang siap pakai untuk peningkatan berkala dan berbagi pengetahuan. - Pelatihan Di sini Anda dapat belajar jika Anda tidak dapat melakukannya sendiri dan mengajar jika Anda bisa. Pelatihan adalah hal yang sangat erat terkait dengan berbagi pengetahuan. Suka atau tidak suka, kita harus terus meningkatkan tingkat teknis kita.
- Sinkronisasi teknis perintah (jangan dikacaukan dengan sinkronisasi perintah harian) . Sangat mudah untuk mengikuti segala sesuatu ketika Anda hanya tiga orang. Sekarang kita jauh lebih. Kadang-kadang kita menghadapi masalah seperti itu: tim bekerja secara paralel pada satu produk, tetapi tidak tahu apa yang dilakukan masing-masing. Akibatnya, timbul konflik, penulisan ulang kode orang lain, dll. Ketika beberapa melakukannya, sementara yang lain melempar, proses pengembangan mungkin tergelincir. Di DevForum, kami juga fokus pada sinkronisasi teknis tim dan berjuang dengan perpecahan.
- Alat untuk perubahan . Anda bisa datang ke sini dan mengubah jalannya sejarah. Di sini Anda perlu memberi contoh.
Sebuah contoh Katakanlah kita memiliki Oleg. Dia duduk di infrastruktur dan melakukan proyek Otonomi dengan para pria. Ketika proyek dimulai pada potensi penuhnya, kehidupan pengembang sederhana akan menjadi lebih mudah. Mereka akan berhenti menarik infrastruktur dan akan melakukan semuanya sendiri. Anda melakukan semuanya sendiri, Anda tidak bergantung pada siapa pun, baik-baik saja.
Oleg siap untuk melakukan perubahan di perusahaan. Tetapi dia tahu bahwa menulis tentang perubahan yang dilakukan pada Slack saja tidak cukup. Penting untuk memberi tahu di depan umum, menjelaskan, menjawab pertanyaan, menulis artikel, melakukan serangkaian tindakan, jika tidak, tidak ada yang akan berubah. Oleg datang ke DevForum dan menggunakannya sebagai alat untuk perubahan.
- Pelatihan sebelum pertunjukan . Di sini Anda dapat berlatih sebelum pertunjukan besar. Sekali lagi, ambil Oleg sebagai contoh.
Sebuah contoh Oleg ingin berbicara di konferensi besar. Dia membutuhkan kehormatan, ketenaran dan ribuan tampilan di Youtube.
Dia datang kepada kami dan dengan jujur berbicara tentang tujuannya yang ambisius. Kami, pada gilirannya, memberinya platform untuk pelatihan (praktis) tanpa rasa sakit. Jika perlu, kami membantu, meminta, membimbing.
Ambang untuk memasuki DevForum (tidak seperti mitap atau konferensi) minimal. Oleg perlu menyiapkan topik, menyiapkan slide selama setengah jam dan datang pada waktu yang tepat. Ini adalah tempat yang bagus untuk latihan uji coba. Pelatihan tentang kucing, mis. pada kita. Kami akan memberikan umpan balik, dan pergi melalui slide, dan Anda dapat memeriksa lelucon pada kami.
Setelah DevForuma, laporan sudah dapat dilemparkan ke mitap lokal. Dan kemungkinan besar mereka akan membawanya.
Agak retro: bagaimana DevForum muncul
Dari mana format ini berasal? Korotenechko. Tiga tahun lalu, perusahaan kami melakukan upaya pertama untuk memperkenalkan Ulasan Sprint secara teratur.
Itu tampak seperti ini: semua orang berkumpul di satu ruangan, benar-benar segalanya dan bergiliran memberi tahu satu sama lain yang telah melakukan apa selama beberapa minggu terakhir. Pada saat itu, hanya ada 20 dari kita, tetapi bayangkan bagaimana rasanya mendengarkan dan melihat perwakilan bisnis untuk kode, dan pengembang untuk melihat pengembangan pizza. Kami dengan cepat menyadari bahwa orang-orang hanya mendengarkan topik-topik yang menarik bagi mereka, dan pada topik-topik lain mereka dengan susah payah terjebak di telepon.
Kita dihadapkan dengan fakta bahwa demonstrasi yang sangat teknis kepada orang-orang yang jauh dari ini adalah seperti itu. Mereka datang untuk melihat bagaimana meja kas dimulai, dan kami memberi tahu mereka tentang pengalaman menggunakan kerangka kerja Polly untuk menerapkan perjalanan ulang antar layanan. Kami segera menyadari bahwa format seperti itu tidak banyak berguna bagi orang-orang, dan Sprint Review menolak formulir itu. Di beberapa titik, itu dibatalkan, dan pertemuan di kalender tetap.
Sekelompok orang inisiatif berpikir: sangat keren untuk menunjukkan hal-hal teknis kepada mereka yang berada dalam subjek. Ada pertemuan, orang-orang, ada keinginan, ada topik. Jadi kami mulai berkumpul seminggu sekali dan terus melakukannya hingga hari ini.
Selama tiga tahun, formatnya telah mengalami beberapa perubahan.- Kami mulai merekam penampilan kami. Formatnya sendiri telah berlangsung selama tiga tahun, kami memiliki catatan dalam dua tahun. Semuanya disimpan di satu tempat, jika diinginkan, Anda bisa mengulas.
- Kami meninggalkan format demonstrasi karena kami sampai pada kesimpulan bahwa persiapan dan demo itu sendiri membutuhkan waktu lebih lama daripada format presentasi.
- Kami beralih ke format presentasi, yang mudah disiapkan, memberikan waktu 40 menit secara harfiah (meskipun di sini, tentu saja, itu tergantung pada kompleksitas topik dan pembicara).
- Pada awalnya, setiap pengembang berbicara di DevForum. Pada titik waktu tertentu, kami membuat asumsi bahwa tidak setiap orang berbicara, tetapi seorang wakil dari tim.
- Kemudian kami melangkah lebih jauh dan berhenti mengganggu proposal untuk berbicara dengan tim-tim yang sekarang "tidak ada yang terjadi."
- Awalnya, kami memenuhi empat topik per jam, tetapi sampai pada kesimpulan bahwa tidak peduli betapa menariknya laporan itu, pada akhir jam hanya bubur yang tersisa di kepala saya. Jadi sekarang kita ambil satu atau dua topik tentang DevForum, 25 menit laporan dan 5 menit untuk pertanyaan.
- Baru-baru ini, kami memutuskan untuk sedikit memperluas topik dan terkadang mengundang pembicara dari luar.
Kami tahu bahwa DevForum kami bukan format yang sangat unik, banyak kolega kami yang mencoba hal serupa. Tetapi, sayangnya, seringkali pertemuan rutin seperti itu tidak berakar, dengan cepat menjadi usang dan layu. DevForum kami hidup selama tiga tahun - ini adalah waktu yang lama untuk menganalisis, mengumpulkan keahlian, dan berbagi dengan Anda pengalaman membuat dan memelihara format ini.
Bagaimana cara mengatur DevForum di perusahaan Anda
Anda akan membutuhkan 6 hal dasar:
1. Memahami tugas dan format DevForum.
Lebih detailUntuk memahami apakah perlu menjalankan DevForum di rumah, Anda dapat berkonsultasi dengan tugas yang dipecahkan format ini di Dodo kami.
Ini adalah tugas komunikasi, pelatihan dan realisasi diri programmer. DevForum adalah mekanisme yang fleksibel dan pada suatu waktu dapat bekerja lebih untuk mencapai tujuan yang berbeda.
Ada dua format pidato terverifikasi yang telah kami kembangkan selama tiga tahun. Anda dapat mengadopsi:
Laporkan : satu pengembang menyiapkan dan berbicara, sementara yang lain mengajukan pertanyaan.
Sebuah contoh Suatu hari, topiknya adalah “Penebangan Struktural”, di mana mereka berbicara tentang serilog, penggunaannya dalam proyek kami, dan bagaimana hal itu membantu untuk bekerja lebih baik dengan kayu di Kibana. Ini juga membahas topik logging struktural melalui NLog dan penggunaan antarmuka ILogging umum untuk proyek .NET CORE.
Setelah presentasi, ada sesi pertanyaan, dan semua peserta memahami betapa mudahnya menambahkan lib ini ke proyek baru. Kami butuh 30 menit. Selama setengah jam kami mendiskusikan level pencatatan hari itu seperti Debug, Info, Peringatkan, Kesalahan, dll., Dan secara spesifik, level apa yang menggambarkan situasi apa dalam sistem. Pada sesi pertanyaan, masalah kesalahan kebisingan dalam log, terutama yang terkait dengan pelatihan ulang, muncul. Sejak DevForum, semua proyek microservice baru menggunakan persis Serilog, dan itu juga muncul di templat layanan kami.
Pengambilan keputusan : ada masalah yang entah bagaimana mempengaruhi semua orang. Orang-orang datang dengan solusi yang memungkinkan untuk memikirkan satu hal.
Sebuah contoh Kami mengumpulkan DevForum untuk membahas Definisi yang dilakukan dan ingin menstabilkan kualitas kode yang disediakan untuk produksi. Tetapi bagaimana melakukan ini ketika Anda memiliki beberapa perintah yang bekerja pada kode umum sekaligus? Solusinya adalah untuk membuat semua definisi dari cerita pengguna selesai. DOD yang diusulkan adalah titik kontroversial. Kami berkumpul dan mendiskusikan apakah kami membutuhkannya atau tidak. Keputusan umum dibuat. Untuk mengimplementasikannya, kami menambahkan item ke daftar periksa di pelacak tugas kami (Kaiten) dan menjadikannya item wajib saat menutup tugas. Beberapa tim kemudian semakin memperkuat DoD dengan menambahkan poin mereka sendiri yang penting bagi mereka.
2. Penyelenggara yang tangguh dan berbayar.
Lebih detailApa lagi yang harus diperhitungkan adalah kehadiran orang-orang yang terus-menerus terlibat dalam acara - penyelenggara. Penting bahwa mereka berasal dari pengembang atau orang yang memahami bagian teknis. Mereka harus membantu peserta merumuskan topik, mencari pembicara baru, dan bahkan terkadang mempertahankan diskusi dengan mengajukan pertanyaan yang bagus.
Dalam kasus kami, kami memiliki 3 penyelenggara dari pengembang, serta tim merek TI yang aktif membantu.
3. Persetujuan dari manajemen departemen TI Anda.
Lebih detailSelain tujuan dan penyelenggara, komponen penting dari kesuksesan acara adalah kurangnya oposisi dari atas. Proses ini adalah inisiatif murni akar rumput, kita dapat mengatakan bahwa penggemar melakukannya. Bantuan dari manajemen dapat bermanfaat, dan pertentangan akan menjadi bencana. Namun, orang-orang berkumpul selama jam kerja, menggunakan gedung dan peralatan kantor. Paling tidak, ini tidak boleh dilarang.
4. Ketersediaan ruang dan peralatan untuk rapat.
Lebih detailRuang tersebut dapat berupa ruang pertemuan di kantor, atau tempat pertemuan virtual, panggilan umum di Skype atau Google meet.
Kami selalu berkumpul di satu ruang pertemuan yang dipesan "selamanya saat ini" di kantor, tetapi pada saat yang sama kami menyiarkan semua yang secara umum Google temui, yang juga sama dan tidak berubah di antara rapat.
Negosiasi kami besar, menampung 20-30 orang. Ada proyektor dan sistem output suara untuk panggilan jarak jauh. Semua orang tahu bahwa pada hari Kamis dari jam 4:00 sampai 5:00 siang, DevForum diadakan di ruang rapat ini.
Karena fakta bahwa kami memiliki pengembangan yang didistribusikan sebagian, kami yakin akan membawa pekerja jarak jauh ke panggilan umum. Ini juga memungkinkan speaker untuk menampilkan layar mereka dari komputer mereka, menghubungkan ke pertemuan umum. Pembicara dapat berada di ruang rapat umum atau di tempat lain yang nyaman bagi mereka. Kita semua akan mendengarnya, dan juga melihat layar mereka.
Ruang permanen yang ditunjuk menjadikan pertemuan ini lebih andal dan dapat diprediksi bagi para peserta.
5. Kehadiran audiensi pendengar.
Lebih detailUntuk mengumpulkan peserta, kami memiliki saluran permanen di #devforum slack, tempat semua pengembang yakin. Kami bahkan memasukkan saluran ini dalam daftar saluran yang diperlukan dalam daftar periksa pengembang baru. Plus, mentor pemula memastikan bahwa mereka masuk ke saluran #devforum.
Ada pengumuman rapat, setelah diskusi, pilihan topik dan diskusi tentang topik.
Agar orang dapat berpartisipasi dalam kehidupan forum, kami mengatur jajak pendapat, meminta pembicara untuk memberikan umpan balik, dan juga menerbitkan rekaman pertemuan pada hari berikutnya di pagi hari.
Penting juga bahwa acara ini bersifat sukarela dan opsional. Ya, itu diadakan selama jam kerja, tetapi jika seseorang ingin bekerja atau memiliki hal-hal yang lebih penting untuk dilakukan saat ini, ia mungkin kehilangan.
Contoh publikasi pasca acara:
Contoh diskusi setelah pertemuan:
6. Kehadiran pembicara dan topik untuk diskusi.
Lebih detailIni adalah bagian paling penting dan paling sulit dalam organisasi. Di sini kita dihadapkan dengan masalah, baik pencarian pembicara dan ketersediaan topik.
Berikut ini adalah daftar singkat kegiatan yang dilakukan penyelenggara untuk melibatkan orang:
- Kami mencari topik sebelumnya, menyusun rencana kinerja selama lebih dari seminggu. Pada awalnya, kami mencari topik pada awal minggu, dan pada hari Kamis kami harus berbicara.
- Kami masuk ke saluran perintah dan bertanya secara eksplisit: apakah ada topik untuk DevForum?
- Kami melakukan percakapan pribadi dengan programmer, mendorong mereka untuk melakukan. Kami memperkuat nilai bagi pembicara untuk berpartisipasi: pemahaman yang lebih dalam tentang topik, pengalaman berbicara, manfaat publik, materi untuk artikel mendatang, konferensi.
- Kami membahas topik saluran untuk didiskusikan sehingga orang tertarik untuk mendengarkannya. Pengembang yang berpengetahuan luas dapat merespons dan bertindak sebagai pembicara.
- Kami menanggapi peristiwa penting secara sosial, secara mandiri mengatur diskusi tentang topik pembangunan yang bermasalah.
- Kami menonton konferensi yang lalu dengan peserta kami. Setelah menghadiri konferensi, selalu ada sesuatu untuk diceritakan.
- Mengikuti hasil konferensi yang penting bagi kami, yang dihadiri oleh banyak orang dari kami, kami menyelenggarakan diskusi dalam format "3 laporan terbaik dari Highload ++ terbaru".
- Kami mengundang pembicara eksternal.
Sesuatu yang penting
Mungkin kelihatannya semuanya sederhana (atau sebaliknya tidak ada yang jelas), jadi saya akan membuat daftar beberapa fitur organisasi yang harus dipertimbangkan dan diingat.
Penyelenggara perlu bekerja dengan pembicara. Kami mengatasi rasa takut berbicara melalui bantuan dalam mempersiapkan pidato. Kemalasan atau disorganisasi dihentikan oleh permintaan untuk merumuskan topik terlebih dahulu, bahkan dalam bentuk konsep, dan dengan tanggal pidato yang tepat.
Terkadang tidak ada. Ada saat-saat ketika begitu banyak ditemukan, kadang-kadang ketika ada sedikit. Dalam hal ini, Anda tidak dapat membatalkan acara secara kategoris. Kita harus mencoba menemukan topik atau berbicara sendiri. Penyelenggara juga pengembang, jadi kami juga selalu punya sesuatu untuk diceritakan. Anda dapat menggunakan trik, mengatur lebih banyak diskusi gratis.
Kualitas video dan suara. Ini benar-benar momen teknis, tetapi penting bagi orang-orang bahwa suaranya bagus (periksa koneksi dan internet di muka), dan demonstrasi kode pada layar dapat dibaca. Bahkan topik yang paling menarik, diajukan dengan kelemahan teknis, dapat mengasingkan pemirsa.
Kami mengumpulkan material. Rapat harus direkam. Kami memiliki arsip video, dengan presentasi dan materi tambahan terlampir. Ada daftar putar di YouTube. Kami menempatkan semua catatan dalam sistem dokumentasi kami, di mana ada pencarian teks lengkap dan Anda dapat menemukan topik yang menarik setelah dan berkenalan.
Didedikasikan untuk tim pengembangan di mana tidak ada manajer tempat Anda mengerjakan satu kode, di mana pengembang tertarik untuk mengetahui apa yang terjadi di sekitar, untuk orang-orang yang ingin mengembangkan dan membantu orang lain tumbuh, tim-tim yang memiliki kepercayaan penting di dalamnya.
Dari Dodo Pizza Engineering dengan kemanusiaan