🕔 🔹 👩🏾‍🚀 Pekerjaan tim terdistribusi dalam kondisi isolasi diri: karena kami hampir tidak melihat perbedaannya 👩🏿‍💼 ❕ 👸🏼

Mode isolasi diri memaksa banyak orang untuk bekerja dari rumah. Lebih mudah bagi seseorang, yang lebih sulit, dan seseorang tidak akan melihat perbedaan sama sekali, tetapi setelah pengumuman minggu karantina (dan kemudian bulan), peningkatan postingan lifehack, efisiensi dan produktivitas dalam umpan telah meningkat secara signifikan.

Nama saya Mikhail Troshev, saya mengepalai Layanan Antarmuka Pencarian Yandex. Tim kami telah bekerja berdasarkan distribusi selama bertahun-tahun - saya akan memberi tahu Anda di bawah ini bagaimana perbedaannya, dan bagaimana itu mirip dengan "jarak jauh", bagaimana itu diorganisir, mengapa itu tidak pecah, dan bagaimana pengalaman kami dapat bermanfaat bagi mereka yang tiba-tiba diambil secara tiba-tiba oleh perubahan jam kerja.

Sesuatu pasti akan terasa dangkal bagi Anda (Agile, Scrum, Kanban, DevOps - wow penemuan!), Tapi itu seperti mengisi daya di pagi hari: semua orang tahu itu berguna, tetapi karena alasan kemalasan dilakukan secara teratur dan dengan kekuatan penuh. Jadi: kita lakukan. Dan itu berhasil.

Tidak jauh, tetapi didistribusikan

Seperti apa: 90 vendor ujung depan berkumpul setiap hari di kantor Moskow, St. Petersburg, Kazan, Innopolis, Yekaterinburg, Simferopol dan Minsk - mudah untuk mengetahui bahwa kita dipisahkan tidak hanya oleh jarak, tetapi juga berdasarkan zona waktu. Namun, ini tidak semua: distributor front-end didistribusikan antara tim produk (tim virtual) sekitar tiga hingga tujuh + back-end, desainer, penguji dan manajer (pada 2019 ia berbicara secara rinci tentang struktur kerja kami di sini ). Artinya, hampir semua anggota dari satu tim semacam itu berada di kota yang berbeda. Tidak terlalu jauh, tetapi sangat dekat dengan ini: meskipun beberapa rekan kerja masih berdekatan, kemungkinan sinkronisasi dengan yang lain sangat terbatas dibandingkan dengan bekerja di ruang terbuka.

Penting untuk menggunakan komunikasi asinkron dengan penundaan reaksi yang lama. Semakin kuat tim tersebar di antara kantor yang berbeda, semakin besar overhead menunggu dalam interaksi kerja sehari-hari yang dapat dikubur oleh proyek mana pun. Untuk menghemat waktu:

- siklus hidup setiap tugas dari ide ke produksi diatur secara konsisten mungkin: prosedur, status, transisi antar tahap - segala sesuatu yang mungkin diformalkan (sekitar 90% dari tugas). Pada saat yang sama, kami mencoba untuk membuat birokrasi tetap sederhana dan dapat dimengerti, jika tidak maka biayanya tidak lagi berguna dan mulai mengganggu;

- seluruh tim menyadari aturan yang mengatur proses kerja, dan berusaha untuk mengikuti mereka dengan jelas; Kami mencoba mengotomatiskan rutinitas. Dengan demikian, semua orang sibuk dengan bisnisnya sendiri dan tidak membuang waktu membuat jenis keputusan mikro yang sama: programmer - program, manajer produk datang dengan fitur produk, desainer - desainer.

Tidak ada yang baru, bukan? Namun, pendekatan sederhana ini banyak membantu kami dalam kondisi isolasi diri: setiap karyawan dapat membawa manfaat maksimal sendiri, karena mereka menyadari perincian yang cukup untuk bekerja.

Tetapi hal pertama yang pertama.

Tahap 0. Perencanaan

Setiap tim memiliki backlog, yang peringkatnya diberi peringkat dan diprioritaskan:

Poin mendasarnya adalah bahwa setiap anggota tim harus mengerti: tugas ini perlu dilakukan karena terkait dengan epik, epik terkait dengan tujuan, dan tujuan itu penting. Kalau tidak, orang akan mulai melakukan apa yang tidak diperlukan, atau manajer akan dipaksa untuk terus memantau dan memadamkan api. Yang terakhir, omong-omong, mungkin sulit untuk diperhatikan di kantor, tetapi tidak mungkin untuk dilewatkan dari jarak jauh: ada banyak kebingungan, pekerjaan sedang berlangsung, selusin ruang obrolan mulai di messenger dalam upaya untuk menyinkronkan - sebagai hasilnya, seluruh tim mengobrol, bukannya menulis kode. Sangat penting untuk mengatur perencanaan dalam sebuah tim sehingga setiap peserta dalam proses memahami apa dan dalam urutan apa yang perlu dia lakukan. Kemudian pemimpin tim akan dapat fokus pada produk tanpa terganggu oleh pertanyaan kecil yang konstan.

Tentu saja, tidak mungkin untuk merinci seluruh simpanan ke bawah, tetapi penelitian berkualitas tinggi memungkinkan Anda untuk dengan cepat merekrut tugas baru dalam sprint - hampir semua tim hidup dalam sprint dua minggu - dan mempertahankan cadangan untuk yang berikutnya. Dengan pendekatan ini, tim yang berpengalaman dapat mengetik sprint bahkan tanpa manajer, jika tiba-tiba ternyata tidak dapat diakses.

Agar tidak memperpanjang waktu mengerjakan tugas, tim terlibat dalam "birokrasi yang berguna": manajer merumuskan uraian yang jelas, pelaksana menuliskan status yang benar, tugas "mengalir" dari kiri ke kanan pada papan sprint:

Di sini seluruh tim melihat gambar sprint penuh dan terkini. Jika seseorang jatuh sakit, pergi bertugas atau berlibur, peserta lain segera mengambil tugas dalam status mereka saat ini.

Nah, bagaimana bisa tanpa sinkronisasi harian, ketika organisasi formal dari proses tidak cukup untuk menyelesaikan beberapa kasus tertentu, dan birokrasi lebih cenderung untuk mengganggu proses. Biasanya merinci tugas berdasarkan status (buka> sedang berlangsung> sedang ditinjau> siap untuk tes> pengujian> diuji> siap untuk dev> dev> rc> ditutup) sudah cukup, tetapi dalam 10% kasus Anda perlu mengklarifikasi sesuatu, ucapkan dengan kata-kata, jelaskan “ di jari ". Ngomong-ngomong, saya yakin bahwa semua rapat kerja (termasuk stand-up) harus dilakukan menggunakan komunikasi video, dan bukan hanya dengan suara, karena memaksa seseorang untuk mengatur diri sendiri dan menyetel untuk bekerja.

Sangat penting bahwa seluruh tim hadir di sinkronisasi: mereka dengan cepat memeriksa konteksnya, memilah-milah tugas dan mulai bekerja, dibimbing oleh dewan, tanpa membuang lebih banyak waktu untuk saling bertanya. Tentu saja, kami juga memiliki obrolan yang berfungsi, tetapi kami mencoba untuk tidak membanjiri mereka dan menggunakannya untuk mendapatkan jawaban cepat (idealnya biner): apakah mungkin untuk meluncurkan rilis, di mana menemukan instruksi, dengan siapa mendiskusikan API sumber data.

Di mana waktu dimenangkan: sinkronisasi, pengambilan keputusan mikro

Tahap 1. Pengembangan: buka> sedang berlangsung

"Buka" - tugas sedang menunggu pemain. Pengembang mengambilnya sehingga masing-masing siap secepat mungkin. Misalnya, kebetulan hari Jumat di halaman, dan pengembang akan bertugas minggu depan (dan ini diketahui sebelumnya, selama sebulan). Dalam hal ini, lebih baik baginya untuk mengambil tugas kecil untuk berhasil melakukannya dalam satu hari: kami mencoba untuk tidak mentransfer apa yang sudah dimulai. Jika seseorang tidak punya waktu untuk menyelesaikan pekerjaan, lebih baik untuk menuangkan apa adanya, dan kemudian untuk menyelesaikan sisa-sisa dengan permintaan kolam terpisah.

Saya menyebarkan copy pekerjaan proyek lokal - jangan lupa untuk mentransfer tugas dari "terbuka" ke "dalam proses" sehingga orang lain tidak mengambilnya. “Lokal” adalah kata kunci - Anda dapat bekerja dari mana saja, kualitas koneksi internet Anda tidak akan menjadi faktor pemblokiran. Sekarang karena infrastruktur dan jaringan kelebihan beban, itu sangat penting. Server pengembangan lokal kami memungkinkan Anda untuk menggunakan data dump - arsip zip dengan data untuk permintaan yang berbeda, sehingga Anda dapat sepenuhnya bekerja tanpa internet. Setelah pengembang menyelesaikan pekerjaan dan mengirim permintaan kumpulan, otomatisasi dihidupkan.

Di mana waktu diperoleh: penilaian kekuatan dan kemampuan yang independen, tidak selalu diperlukan untuk mengatasi koneksi Internet yang tidak stabil

Tahap 2. Pemeriksaan otomatis: sedang berlangsung> sedang ditinjau

Sebelum tugas masuk ke tinjauan, ia melewati pemeriksaan pada kualitas kode, kinerja, kurangnya bug visual dan fungsional. Di sini orang bisa menulis banyak tentang kelengkapan dan ragam pemeriksaan otomatis kami, tetapi, pertama, ia mengacu pada beberapa cerita yang terpisah, dan kedua, jauh melampaui topik yang dibahas. Saya hanya akan memberikan tautan ke deskripsi alat:

- seperangkat alat standar untuk analisis statis: ESLint dan Stylelint dengan banyak plug-in;
- pemeriksaan statis kami sendiri: ketersediaan dan kualitas terjemahan, validasi file yaml;
- alat standar untuk pengujian unit: Mocha , Karma , PhantomJS ,istanbul ;
alat pengujian fungsional dan visual kita sendiri, Hermione ;
- Pulsa - untuk pengujian kinerja - juga milik kita. Mereka menyebutkannya di sini .

Ngomong-ngomong, tugas akan digulirkan kembali ke sini jika ada masalah pada tahap apa pun - sayangnya, bahkan perencanaan yang paling hati-hati tidak menghemat 100% dari kesalahan, sesuatu mungkin salah. Orang yang memanggil panggilan orang yang tepat untuk tugas tersebut, menjelaskan esensi masalah, mengunggah tangkapan layar atau bahkan video, juga dapat menulis perintah ke obrolan sehingga semua orang akan melihat bahwa tugas tersebut terhenti. Apa pun itu - bug keluar saat pengujian, desain berubah, tidak ada cukup data dari backend.

: — , - —

3. -: in review > ready for test

Pertama, saya ingin memanggil permintaan bukan hanya resensi gratis, tetapi orang yang mengerti apa yang terjadi dalam kode Anda; kedua, dari tim yang berdekatan, sehingga seluruh layanan memiliki gagasan tentang siapa yang melakukan apa - semua ini dijabarkan dalam peraturan kami. Bahkan di kantor kecil mungkin sulit dan memakan waktu untuk mengaturnya secara manual, untuk tidak mengatakan apa-apa tentang distribusi (dan isolasi sendiri!). Peninjau kode otomatis datang untuk menyelamatkan: dia juga mengubah statusnya sendiri. Saya tidak akan membahas secara rinci tentang cara kerjanya, saya tidak akan - lebih baik mendengarkan cerita pengembang. Dia juga tahu cara melakukan ping ke pemain: semakin lama tugasnya hang di review, semakin parah pingnya.

Di mana Anda memenangkan waktu: cari peninjau yang relevan, pengingat untuk memproses permintaan kumpulan

Tahap 4. Pengujian: pengujian> diuji

Ketika perubahan telah melewati tinjauan kode, jalankan autotest. Hanya setelah semuanya berubah hijau, tugas tersebut ditransfer ke pengujian manual. Adalah penting bahwa untuk tugas tersebut, sampai jelas diteruskan ke orang lain, pelaku selalu bertanggung jawab - dialah yang harus dengan cepat menyeret kodenya melalui peninjauan kode dan pengujian ke produksi. Artinya, kita selalu tahu siapa yang ekstrem, semua orang terus-menerus memantau tidak hanya tugas mereka, tetapi juga segala sesuatu yang terjadi di tim. Penguji dalam tim biasanya sendirian, dan ini juga nyaman baginya: dia melihat bahwa dia akan terbang berikutnya, dia dapat menggunakan waktunya lebih efisien.

Penguji dapat:

- memberikan tugas pengujian kepada penilai - pos dengan semua detail. Sebagai hasil pengujian oleh penilai, sesuatu mungkin memerlukan pengujian atau pengecekan ulang penelitian;
- Tes sendiri tugasnya di perangkat langsung atau gunakan peternakan perangkat dengan akses jarak jauh - Kebun Kolektif.

Perangkat langsung terletak di Hypercubes di setiap kantor Yandex. Setiap karyawan dapat mengambil perangkat yang dia butuhkan dengan karakteristik yang diperlukan, setelah memilih titik terdekat dengan perangkat gratis. Biasanya, setelah beberapa saat, sistem akan secara otomatis mengingatkan Anda bahwa sudah saatnya mengembalikan perangkat, tetapi fungsi ini dinonaktifkan selama periode isolasi sendiri. Tim tugas memastikan bahwa mereka yang membutuhkannya secara kritis membutuhkan peralatan hidup, dan bahwa semua orang, agar tidak memperlambat proses kerja, membantu menghubungkan ke pertanian kolektif.

Pertanian kolektif adalah pertanian perangkat pengujian jarak jauh yang dapat digunakan siapa pun. Android, iOS - kami memeriksa perubahan bahkan pada versi sistem tertua yang paling sulit untuk didukung, sehingga layanan kami tersedia untuk siapa saja. Namun kami juga berusaha mendapatkan flagships sesegera mungkin di Collective Farm dan Hypercubes. Ingat "tirai" (itu adalah "monobrow") yang muncul di iPhone kesembilan, dan semua masalah yang terkait dengannya?

Di mana waktu diperoleh: perencanaan, pengujian otomatis, distribusi perangkat: tersedia bahkan dengan isolasi sendiri

Tahap 5. Infus: siap untuk fev> dev

Tugas diuji - saatnya untuk menuangkannya ke cabang umum.

N.B. , master trunk, dev. . trunk.

Ketika ada banyak suntikan (misalnya, kami memiliki lebih dari 30 permintaan kumpulan infus per hari), dua masalah muncul:

- minor : riwayat di git, jika Anda bergabung secara acak dan tidak rebase, itu menjadi sangat membingungkan, dan jika ada beberapa jenis bug , memutar kembali sangat sulit;

- kritis : pengujian integrasi. Secara fisik tidak selalu memungkinkan untuk menunggu sampai akhir pengujian perubahan Anda bersama dengan versi terbaru dari trunk, sehingga hal berikut dapat terjadi: dua permintaan kumpulan, yang masing-masing secara individual tidak merusak apa pun, akan memecahkan bagasi setelah infus. Untuk mencegah hal ini, kami mematuhi pengembangan berbasis Trunk, yaitu, rilis dapat diluncurkan dari komit apa pun. Dan meskipun kami belum akhirnya datang ke Penyebaran Berkelanjutan, bagasi kami adalah "hijau". Dan memecahkannya sekali seminggu sekali sudah pasti tidak dapat diterima oleh kami.

Selama beberapa tahun sekarang kami telah menggunakan alat Antrian Gabung untuk mengotomatisasi antrian dan terus meningkatkannya. Perubahan dituangkan bukan oleh pengembang, tetapi oleh robot. Dalam setiap permintaan kumpulan, ia ditata kembali sesuai dengan versi terbaru dari trunk dan menjalankan serangkaian tes lengkap. Ini adalah proses yang agak panjang, oleh karena itu tidak mungkin untuk membangunnya pada orang yang hidup - seseorang tidak akan menunggu hasil akhir. Dan robot itu bekerja tanpa tidur, istirahat dan hari libur. Selain itu, bukan pengembang sendiri yang dapat menempatkan tugas dalam antrian, tetapi penguji tepat setelah akhir pengujian, ini sekali lagi memungkinkan Anda untuk menghemat waktu.

Keterangan lebih lanjutTentang Gabung Antrian.

Di mana waktu dimenangkan: kami mencegah pemblokiran kerusakan, Anda tidak perlu mengontrol pemasukan permintaan kumpulan secara manual

Tahap 6. Rilis: rc> ditutup

Setiap hari kerja pada jam 5 pagi dari komit terakhir di trunk, kami secara otomatis mendapatkan rilis baru: perakitan paket statis dan dinamis, memberikan penilaian, pengujian oleh penilai. Selanjutnya, penguji yang bertugas meninjau laporan tersebut dan, jika ada bug, melaporkan pengembang yang sedang bertugas tentang mereka. Dan jika semuanya baik-baik saja, berikan ke manajer tugas. Jika dia memberikan lampu hijau, pengembang yang bertugas meluncurkan rilis.

Penting untuk mengklarifikasi bahwa tugas-tugas dari tim yang berbeda termasuk dalam rilis, oleh karena itu bermanfaat bagi semua orang ketika satu pengembang panggilan dialokasikan dengan jelas untuk rilis tersebut, yang telah melakukan pekerjaan sepanjang minggu pada rolling release dan memantau kesalahan pemantauan. Ini memungkinkan pengembang proyek lain untuk beralih ke tugas baru sedini mungkin (sebenarnya segera setelah mengirim ke Gabung Antrian).

Biasanya, semua kegiatan rilis terjadi selama jam kerja (bahkan dari rumah kami meminta semua orang untuk mengamati rezim - sebagai hasilnya, semua orang memecahnya ke arah yang berbeda, tetapi kami tidak berhenti mencoba), tetapi jika ada sesuatu yang salah dalam produksi, pergantian tugas akan membangunkan pengembang yang bertugas, bahwa dia segera merespons.

Saya mengingatkan Anda bahwa tugas utama adalah untuk mengurangi waktu sinkronisasi anggota tim satu sama lain dan jumlah rutin: semua orang tahu siapa yang bertugas. Semua orang tahu apa yang harus dilakukan dan bagaimana, setiap orang memiliki instruksi. Ketika manajer mengizinkan rilis untuk diluncurkan, dia tidak akan menjelaskan kepada pengembang prosedur, pengembang tahu segalanya dan tahu caranya.

Di mana waktu dimenangkan: sinkronisasi, pengambilan keputusan mikro,
siklus ditutup.

Pekerjaan yang didistribusikan adalah vaksinasi terhadap proses yang buruk dan tidak efisien yang menghambat proyek bahkan dalam kondisi biasa, untuk mengatakan apa-apa tentang yang tidak standar. Pengalaman tim kami menegaskan bahwa jika, dengan kejenuhan, Anda pergi ke pengaturan prosedur dan interaksi dan dengan jujur mematuhi semua aturan, tidak peduli seberapa biasa mereka tampaknya, alur kerja akan sangat sulit untuk dilumpuhkan.

Sesuatu yang mengingatkan pada manajemen lalu lintas: ketika ada sedikit mobil dan mereka lambat, hanya sedikit orang yang memikirkan peraturan lalu lintas. Sekarang ada banyak mobil dan mereka cepat - pergerakan tanpa aturan menjadi tidak mungkin. Semakin baik (dan pada saat yang sama lebih sederhana) aturan-aturan ini dirumuskan, semakin menyeluruh peserta memenuhinya, semakin tinggi kapasitas lalu lintas jalan.

Terima kasih sudah membaca sampai akhir. Sampai jumpa di komentar!

Pekerjaan tim terdistribusi dalam kondisi isolasi diri: karena kami hampir tidak melihat perbedaannya