Perbaikan bug adalah bagian yang membosankan, tetapi wajib dari setiap pengembangan, dan tidak semua orang ingin melakukannya. Bagaimana mengubah perbaikan bug menjadi sesuatu yang menarik? Atur kompetisi! Dalam posting ini, kita akan berbicara secara rinci tentang "marathon perbaikan bug" 24 jam kami - mulai dari persiapan awal hingga pencarian komit terakhir setelah memberikan pemenang.
Terinfeksi dengan gagasan itu
Skala pengembangan aplikasi Sberbank Online kami telah meningkat secara signifikan selama setahun terakhir. Seiring dengan ini, bug kecil mulai menumpuk, yang tidak tercermin dengan cara apa pun pada metrik kunci. Tetapi kami mengerti bahwa ini adalah bom waktu dan sesuatu harus dilakukan dengannya.
Kami terinspirasi oleh bagaimana rekan-rekan
Avito kami memecahkan masalah seperti itu, dan kami memutuskan untuk mengatur serangan besar-besaran terhadap bug dalam format bagaton - dengan mempertimbangkan struktur pengembangan, budaya, dan kekhasan aliran kami.
Itu perlu untuk mengatur segalanya sehingga orang-orang itu sendiri ingin berpartisipasi dalam bagaton dan membuktikan kesejukan mereka tanpa arahan dari atas. Untuk melakukan ini, kompetisi harus memiliki suasana yang sejuk. Kami memutuskan untuk datang dengan gaya khusus, sesuatu yang dikenali tentang bug. Bug adalah bug. Siapa yang menghancurkan bug dalam kehidupan biasa? Disinsektor adalah orang-orang berjas perlindungan kimia kuning. Di mana mereka menyala dalam beberapa tahun terakhir? Dalam satu seri populer tentang seorang guru kimia. Ada dasar, kita selesaikan dengan kegiatan. Mereka menyelenggarakan turnamen video game, kuis dengan hadiah, nominasi individu yang keren ... dan tentu saja, banyak makanan lezat. Tetapi hal utama, apa pun yang dikatakan orang, adalah kompetisi untuk menghilangkan bug. Ini mengingatkan pada dashboard dengan antarmuka web, menunjukkan kemajuan tim, posisi mereka saat ini, jumlah poin, dll. Kami mendiskusikan semuanya dengan para pemimpin tim - mereka menyetujui rencana kami.
Android vs iOS - sangat tidak jujur
Pertama, kami ingin mendorong pengembang Android Sberbank Online dengan rekan iOS mereka, untuk bermain di persaingan platform. Tetapi dalam prosesnya, organisasi menyadari bahwa ini bukan solusi terbaik, karena secara teknis platform bekerja dalam kondisi yang tidak setara. Kebetulan di iOS, build lebih cepat dan autestest dijalankan.
Kemudian kami mengubah format dan membuat tim campuran: masing-masing lima pengembang Android dan iOS. Sebelumnya, kapten dipilih dari antara pengembang proaktif untuk membantu membentuk tim. Ternyata sembilan tim. Dan terlepas dari kenyataan bahwa kami menemukan masalah besi dari sudut pandang fair play, kami masih harus memastikan bahwa pembatasan lain tidak akan menghalangi pasukan pemecah bug kami.
Pencarian selanjutnya adalah memilih tanggal bagaton. Tanggal rilis untuk setiap platform berbeda - mereka dipilih sehingga semua orang merasa nyaman. Kami mencoba membuat tanggal sedekat mungkin dengan tanggal saat kandidat pelepas ditugaskan.
Selain itu, bagaton banyak memuat infrastruktur platform. Ketika ada kompetisi, yang memperbaiki bug lebih cepat, jumlah permintaan tarik lepas landas. Satu setengah bulan lagi sebelum bagaton, ada risiko bahwa peralatan kami tidak dapat mengatasi puncak yang diprediksi. Tetapi pada saat itu kami mengharapkan besi baru, dan tiba tepat pada waktunya. Kami berhasil menghubungkan, mengkonfigurasi, dan memperkuat infrastruktur bandwidth kedua platform beberapa kali.
Pipeline - bagaimana tidak menurunkan semuanya menjadi pipa
Semuanya dilakukan di sini sebagai berikut: segera sebelum dimulainya bagaton dari pengembangan kami, kami mengambil cabang di mana tim harus bekerja. Banyak permintaan tarik dengan bug yang diperbaiki dituangkan ke dalamnya selama bagaton. Autotest dijalankan pada masing-masing, pengembang meninjau permintaan tarik, dan penguji memeriksa bangunan baru untuk memperbaiki bug. Jadi, semua 24 jam kompetisi.
Itu juga perlu untuk mendistribusikan beban penguji. Kami membuat grafik per jam dari perkiraan jumlah permintaan tarik dalam interval bagaton 24 jam - tergantung pada jumlah peserta, beban server, aktivitas pihak ketiga, dll. Dibandingkan dengan kinerja rata-rata penguji dan jumlah jam efektif dari masing-masing bagaton. Kami membagikan "tugas" itu sehingga pada Sabtu pagi antriannya sesedikit mungkin. Secara umum, mereka bingung.
Pada saat yang sama, kami memperhitungkan bahwa setelah bagaton, perlu untuk segera memulai pengujian regresi untuk mengevaluasi kualitas cabang sesegera mungkin dan memutuskan infusnya ke dalam cabang dev. Ini merupakan beban tambahan bagi penguji.
Ulasan Fitur
Itu sangat penting bagi kami tidak hanya untuk memperbaiki bug, tetapi untuk melakukannya secara kualitatif. Tiga prosedur memberikan verifikasi kode yang dikirim oleh pengembang dalam permintaan tarik. Agar kode dapat diambil, mereka harus lulus dengan sukses:
- Tiga pengembang berpengalaman meninjau dan menyetujui kode tersebut.
- kode biasanya macet dan tidak gagal autotest;
- Setelah pembuatan dan pemasukan, bug dalam rakitan pada kondisi yang dijelaskan tidak melanjutkan.
Kami takut bahwa dalam mode kompetitif tidak ada yang akan saling meninjau. Dan di dalam tim Anda tidak dapat meninggalkan ulasan. Oleh karena itu, mereka memutuskan untuk tidak menciptakan apa pun dan bertindak berdasarkan aliran standar, seperti dalam mode kerja: tinjauan silang yang sewenang-wenang - siapa pun yang bebas, ia mengambil proses atas dirinya sendiri.
Itu juga perlu dilacak agar ulasan tidak menuju ke antrian. Untuk bermain aman, kami menarik penandatangan ke ulasan (bahkan mereka yang tidak berpartisipasi dalam bagaton itu sendiri) dan secara aktif mengingatkan para peserta tentang orientasi pada kualitas. Salah satu pengembang senior iOS, bersamaan dengan memperbaiki bug untuk timnya, dalam sehari berhasil melewati 80 permintaan tarik - dia membaca dan mengerti. Ini sangat banyak!
Kami memilih dan mengevaluasi bug
Kami mengambil bug prioritas rendah, kami menghilangkan sampah dengan label dan tanggal. Secara total, 490 bug ternyata - sebagian besar kecil dan sedang, yang tidak dijangkau oleh tangan karena tugas yang lebih penting. Ini semua adalah hal-hal sepele dan tidak waras:
- bug yang telah berulang kali berpindah dari satu versi ke versi lainnya
- bug berakhir atas permintaan pengguna
- kecelakaan terbaru
- bug regresi
- bug yang memengaruhi UX
Semua bug dibagi menjadi tiga gelombang sesuai dengan prioritas penutupan:
- Gelombang pertama - sekitar 230 bug
- Gelombang kedua - sekitar 150 bug
- Gelombang ketiga (cadangan) - sekitar 110 bug
Cacat dievaluasi bukan oleh kompleksitas, tetapi oleh kritikalitas untuk bisnis. Yang paling kritis adalah "artifisial" dan sementara ditempatkan di prioritas "pemblokir" dan "kritis". Semakin tinggi prioritas bug, semakin banyak poin yang diberikan untuk itu. Kompleksitas tidak diperhitungkan - kebetulan pemblokir bug ditutup dalam 20 menit, dan sepele - dalam 4 jam. Untuk satu bug, Anda bisa mendapatkan 1 hingga 7 poin.
Kami menyimpan skor setiap tim untuk bug tertutup sesuai dengan nilainya dalam aturan bagaton. Jika tim punya waktu, mereka mengambil cacat berikut. Motivasi melalui nilai memungkinkan untuk menutup bug yang lebih penting.
Cara menutup bug
Kami membagi gelombang bug pertama menjadi 11 grup (dengan margin), jumlah poin yang sama dan rasio Android dan iOS. Gelombang pertama adalah bug "mahal", yang prioritas dengan biaya yang meningkat. Untuk pencarian yang mudah di Jira, kami memberi mereka label yang sesuai. Sekitar 20 bug dirilis di setiap grup.
Di awal bagaton, kami mengumpulkan kapten tim dan memainkan label. Selanjutnya, para kapten di filter mereka menetapkan label yang diinginkan dan mendistribusikan bug yang sesuai dalam tim. Jadi kami berhasil menghilangkan bug fixing kacau, di mana orang-orang hanya akan mengambil apa yang lebih dimengerti untuk mereka.
Empat jam pertama, tim diberikan poin hanya untuk bug dengan label kelompok yang jatuh kepada mereka untuk mengatur ritme tertentu. Ketika waktu habis, bug yang masih terbuka masuk ke gelombang kedua, menambah yang lain yang masuk akal untuk menutup dalam bagaton.
Pada pukul 19:00, semua bug yang tidak ditutup masuk ke gelombang ketiga - selain bug yang sudah direncanakan di sana. Akibatnya, untuk malam itu kami memiliki bug "cepat" yang akan menutup dalam aliran yang biasa: cache dan yang sekarang, diturunkan secara harfiah sehari sebelum bagaton, serta bug dengan prioritas terendah. Ketiga gelombang itu mulai bekerja. Akibatnya, 286 dari 493 bug yang dipilih ditutup untuk bagaton.
Bagaton bersatu
Kantor pusat Bagaton terletak di ruang konferensi kami, ada juga kuis dan turnamen video game. Tim tidak terbatas, tersebar di mana pun nyaman bagi mereka. Akibatnya, seluruh bank mengetahui tentang bagaton. Salah satu produk ooner dari lantai empat mengatakan: “Saya akan bertemu di lantai 14, mencari ruang pertemuan yang tepat. Tiba-tiba saya mengerti bahwa saya baru saja melihat wajah-wajah yang sudah dikenal, saya akan kembali - pengembang saya sedang duduk patung-patung dengan kekuatan dan utama, dan nol perhatian kepada saya. Ha - saya pikir - mereka tidak akan bersembunyi dari pemilik produk mereka dan lebih dari 10 lantai, oke, sudah duduk, perbaikan bug adalah hal yang benar. "
Ada tim di mana hanya satu Android datang ke bagaton dan pada saat yang sama enam pengembang iOS yang kuat. Kami luar biasa membuat tim ini paket lain dengan iOS-bug.
Selain itu, tujuh pengembang dari daerah datang ke bagaton. Beberapa bertemu dengan tim mereka untuk pertama kalinya, yang sebelumnya hanya mereka lihat melalui konferensi video. Sangat keren menyaksikan bagaimana orang-orang ini secara aktif bergabung dalam proses.
Bagaimana hasil dievaluasi?
Untuk hampir seratus pengembang, kami hanya memiliki 15 penguji. Dan pada malam hari ada empat. Semuanya tidak cukup, jadi pengujian dilanjutkan keesokan harinya. Para pengujilah yang memberikan poin kepada tim, jadi kami memindahkan mereka dari tim untuk menghilangkan bias. Dalam alur kerja normal, penguji dapat menghubungi pengembang dan mencari tahu: "Dengar, bung, ada masalah seperti itu ...". Pada bagaton itu ketat: penguji harus membungkus segala sesuatu yang tidak lulus dengan jelas.
Jadi kami dapat melihat bahwa beberapa pengembang tidak bekerja dalam alur yang diterima. Hackathon telah menjadi semacam katalis untuk semua penyimpangan. Mereka yang bekerja dengan jelas dalam aliran berhasil melewati pengujian di gelombang pertama dan mendapatkan poin. Setiap orang yang tidak benar-benar berkorespondensi masuk ke dalam antrian, yang telah mereka siksa setelah bagaton. Itu mendapat 60 bug.
Insiden
Secara umum, semuanya berjalan seperti biasa, kejadiannya khas dan diselesaikan dengan urutan kerja. Ketika sesuatu pecah, beberapa Penandatangan segera beralih dari perbaikan bug ke penghapusan insiden tersebut.
Ada satu kejadian lucu. Saat menyiapkan dasbor, kami menggambarkan risiko yang mungkin terjadi: akses ke Jira, bergulir pembaruan, dll. Mereka memberi tahu semua administrator bahwa untuk saat bagaton itu perlu untuk menunda semua pekerjaan pemeliharaan, pembaruan Jira dan server. Membuat akun cadangan untuk mengakses Jira. Dan tiba-tiba sekitar pukul 18:00 kami menyadari bahwa dasbor telah berhenti mengumpulkan data. Asumsinya berbeda. Mungkin mereka tidak mempertimbangkan semacam protokol keamanan? Alasannya tak terduga. Organisasi kami sangat besar, tidak selalu mungkin untuk mendapatkan informasi lengkap tentang semua proses yang direncanakan. Dasbor kami digunakan pada mesin virtual di salah satu server sekunder. Ternyata pada hari ini, Jumat malam, server ini, menurut rencana yang tidak diketahui, secara fisik terputus dari outlet, dimuat ke dalam mobil dan dikirim ke tempat tinggal permanen di pusat data baru kami. Akibatnya, pada Sabtu pagi kami harus mengumpulkan semua data dan menghitung poin dalam mode manual.
Gabungkan cabang dan hasil lainnya
Dalam mode operasi normal, seluruh cabang secara manual digerakkan oleh 800+ test case. Tim penguji yang lengkap melakukan pengujian regresi penuh waktu kami dalam dua minggu. Kami tidak mampu terus berkembang tidak berubah begitu lama. Untuk mengurangi waktu pengujian, kami memilih kasus uji utama kesehatan aplikasi - sekitar 107. Hingga akhir hari Senin, mereka menggerakkan 80% iOS, 50% Android dan tidak mengungkapkan satu pun bug kritis. Kami memutuskan bahwa cabang dapat digabung.
Dari 286 bug yang ditutup pada bagaton, 182 bug telah diperbaiki. Sisanya adalah redjack yang tidak relevan karena berbagai alasan, bug (di suatu tempat desain atau fungsi telah berubah). Bug ini tidak penting, tetapi sekarang mereka tidak perlu lagi terganggu dan Anda dapat dengan tenang fokus pada tugas-tugas penting.
Juga, banyak, mengikuti hasil bagaton, punya pertanyaan: berapa banyak bug yang kita buat? Hanya delapan bug di iOS dan tujuh bug di Android.
Penting bagi kami bahwa pengembang merasa bertanggung jawab atas kode produk atas dasar kesetaraan dengan anggota tim lainnya. Ini penting dalam pengembangan apa pun, tetapi dalam pengembangan terdistribusi menjadi prasyarat untuk pekerjaan yang sukses. Dan menurut pendapat kami, kami berhasil meningkatkan tingkat kepemilikan dan semangat tim yang sama. Hasilnya adalah sebuah cerita dengan banyak keuntungan: dalam waktu singkat kami memperbaiki banyak bug, menumpuk muatan, memompa keterampilan tim dan mendapatkan banyak penggemar.
Materi yang disiapkan oleh tim Platform Bisnis Digital Sberbank