Jadilah seperti Munch, atau beberapa kata tentang tugas teknis

Merasa mati, kesepian, pada saat yang sama, haus gila seumur hidup ... Anda mungkin berpikir bahwa kami memutuskan untuk memberikan ceramah tentang ekspresionisme dan membenamkan Anda dalam pekerjaan Munch. Tapi tidak. Anda melewati semua tahapan ini pada saat Anda melihat bahwa utang teknis Anda akan segera mendorong perusahaan Anda ke dalam jurang krisis.



Selama 8 tahun, tim IT Dodo Pizza telah berkembang dari 2 pengembang yang melayani satu negara menjadi 80 orang yang melayani 12 negara. Tiga tahun lalu, saya bergabung dengan Dodo Pizza sebagai Chief Agile Officer dan mulai membantu tim menciptakan proses dan menerapkan praktik-praktik teknik. Seringkali implementasi ini terlalu lambat. Selain itu, ditemukan bahwa ketika beberapa tim mengerjakan produk yang sama, sulit untuk membuat mereka mempertahankan kode kualitas tinggi.

Kami mengejar pengembangan fungsi bisnis, menunda kesempurnaan teknis kode untuk nanti. Jadi kami terjebak. Hutang teknis yang sangat besar membawa kepalan tangan pada kami, tetapi tidak menghancurkannya, tetapi hanya, dengan satu jentikan jari kami, melemparkan perusahaan kami ke dalam jurang krisis. Pada tahun 2018, tim pemasaran meluncurkan kampanye iklan besar-besaran, kami tidak tahan menanggung beban dan jatuh. Malu, malu dan malu. Tetapi selama krisis, kami menyadari bahwa kami dapat bekerja berkali-kali lebih efisien. Krisis memaksa kami untuk segera menerapkan praktik-praktik teknik paling terkenal dan merevolusi proses.

Latar belakang

Dodo Pizza adalah perusahaan cyborg yang menjual pizza . Bisnis kami didasarkan pada platform Dodo IS, yang mengelola semua proses bisnis: menerima pesanan, persiapan pizza, manajemen persediaan, manajemen sumber daya manusia (manajemen), dan banyak lagi. Hanya dalam 8 tahun, kami telah berkembang dari 2 pengembang yang melayani satu pizzeria menjadi 80+ pengembang yang melayani 498 pizza di 12 negara.

Tiga tahun lalu, Dodo IS adalah monolith yang berisi 1 juta baris kode. Ada sedikit cakupan dengan tes unit, tidak ada tes API / UI sama sekali. Kualitas kode itu sendiri mengecewakan. Semua orang tahu tentang ini, atau setidaknya menebak. Dalam mimpi masa depan yang lebih cerah, kami membagi monolit menjadi selusin layanan dan menulis ulang bagian yang paling menjijikkan dari sistem. Kami bahkan menggambar diagram arsitektur "masa depan", tetapi, terus terang, tidak melakukan apa pun untuk mendekatinya.

Semakin banyak tim tumbuh, semakin kita menderita karena kurangnya proses dan praktik rekayasa yang jelas. Rilis menjadi semakin banyak, karena keenam tim pengembangan secara bersamaan membuat perubahan di cabang yang berbeda. Ketika tim menggabungkan perubahan mereka dalam satu cabang, kami kadang-kadang kehilangan hingga 4 jam mencoba menyelesaikan konflik gabungan. Tidak ada tes regresi otomatis, dan dengan setiap rilis kami menghabiskan lebih banyak waktu pada regresi manual.

Sial terjadi

Pada tahun 2018, tim pemasaran meluncurkan kampanye iklan TV federal pertama kami dengan anggaran 100 juta rubel. Itu adalah acara yang hebat untuk Dodo Pizza. Tim TI juga dipersiapkan dengan baik untuk kampanye. Kami telah mengotomatiskan dan menyederhanakan penyebaran kami - sekarang dengan satu tombol di TeamCity kami dapat menggunakan monolit di 12 negara. Menggunakan tes kinerja, kami melakukan analisis kerentanan. Kami melakukan yang terbaik, tapi tetap saja gagal.

Kampanye iklan sangat mengagumkan. Kami menerima 100 hingga 300 pesanan per menit. Itu berita bagus. Berita buruknya: Dodo IS tidak bisa menahan beban seperti itu dan mati. Kami mencapai batas skala vertikal dan tidak dapat lagi memproses pesanan. Sistem reboot setiap 3 jam. Setiap menit downtime menghabiskan puluhan ribu rubel, tidak termasuk hilangnya rasa hormat dari pelanggan yang marah.

Ketika saya tiba di Dodo Pizza tiga tahun lalu, saya segera mulai menerapkan praktik-praktik teknik. Sebagian besar tim mengadopsi pemrograman pasangan, pengujian unit, dan DDD dengan cukup cepat. Tapi tidak semuanya begitu sederhana. Saya harus mengatasi perlawanan dari pengembang, produk, dan tim pendukung.

Berbeda dengan ide praktik rekayasa, pada awalnya tidak semua orang mendukung gagasan tim fitur. Pengembang terbiasa berpikir bahwa tim yang fokus pada satu komponen menulis kode terbaik. Tidak jelas bagaimana menggabungkan pengembangan fungsi bisnis yang cepat dengan refactoring masif yang telah lama tertunda dari sistem yang kompleks. Selain itu, aliran serangga tanpa akhir ini terus-menerus membutuhkan perhatian ... Kami merilis produk tidak lebih dari sekali seminggu, dan setiap rilis membutuhkan waktu yang cukup lama, diperlukan sejumlah besar regresi manual dan dukungan untuk tes UI. Saya mencoba memperbaikinya, tetapi proses perubahannya terlalu lambat dan terfragmentasi.

Kisah kejatuhan dan kebangkitan

Keadaan awal: arsitektur monolitik

Dalam mengejar kecepatan pengembangan fungsi bisnis, kami tidak selalu memikirkan solusi teknis dengan baik. Dipengaruhi oleh kurangnya pengalaman. Kami memiliki aplikasi monolitik dengan basis data tunggal yang berisi semua data dari semua komponen di satu tempat. Pelacak, akuntansi, situs web, API untuk halaman arahan - semua komponen sistem bekerja dengan satu basis data, yang merupakan hambatan.

Kisah nyata

Arsitektur monolitik baik untuk memulai, karena sederhana. Tapi itu tidak bisa menahan beban tinggi, menjadi satu-satunya titik kegagalan. Setelah semua restoran kami di Rusia berhenti menerima pesanan karena posting blog. Bagaimana ini bisa terjadi?

CEO kami, Fedor, memposting sebuah posting di blog-nya. Posting ini dengan cepat mendapatkan popularitas. Situs blog Fedor memiliki penghitung yang menunjukkan jumlah restoran pizza di jaringan kami dan total pendapatan semua restoran pizza. Setiap kali seseorang membaca blog Fedor, server web mengirim permintaan ke database master untuk menghitung pendapatan. Permintaan ini membanjiri database terlalu banyak sehingga berhenti melayani permintaan dari meja kas restoran. Kami dengan cepat memperbaiki masalahnya, tetapi ini adalah salah satu dari banyak tanda bahwa arsitektur kami tidak dapat memenuhi kebutuhan bisnis dan harus dirancang ulang. Namun, kami terus mengabaikan tanda-tanda ini.

Kecelakaan awal pada tahun 2017

14 Februari. Untuk pecinta selamat pada 14 Februari, kami membuat pizza spesial - Pepperoni dalam bentuk hati. Saya akan selalu ingat 14 Februari 2017, karena pada hari ini, ketika semua pizza bekerja dengan beban penuh, Dodo IS mulai turun. Setiap pizzeria memiliki 4-5 tablet untuk manajemen produksi: untuk pesanan apa pembuat pizza menggulung adonan, meletakkan bahan-bahan, membuat roti atau mengirimkannya untuk pengiriman. Pada saat itu, jumlah pizza mencapai 150+, setiap tablet diperbarui beberapa kali dalam satu menit. Semua pertanyaan ini menciptakan beban yang sangat besar pada database sehingga tidak lagi bertahan dan mulai gagal. Dodo IS meninggal selama penjualan puncak. Tetapi ada musim liburan yang sibuk di depan: 23 Februari, 8 Maret, 1 dan 9 Mei. Selama liburan ini, kami mengharapkan pertumbuhan pesanan yang lebih besar.

Hari kamu mati Mengetahui rencana pertumbuhan kami dan batas beban yang dapat kami tahan, kami mengetahui berapa lama kami dapat bertahan hidup. Perkiraan tanggal Armageddon diperkirakan sekitar enam bulan: pada Agustus - September 2017. Bagaimana rasanya hidup, mengetahui tanggal kematian Anda?

Hentikan pengembangan fungsi selama satu tahun. Bersama dengan CEO Fedor, kami harus membuat keputusan yang sulit. Mungkin salah satu keputusan paling sulit dalam sejarah perusahaan. Selama tahun berikutnya, kami hanya membuat satu fitur bisnis. Sisa waktu tim membayar utang teknis. Hutang ini sangat merugikan kami - lebih dari 100 juta rubel hanya untuk gaji pengembang.

Beberapa perbaikan setelah satu tahun

Sepanjang tahun, kami telah tumbuh dengan pesat:

• Kami mengotomatiskan dan mempercepat proses penerapan hingga 4-5 jam
• Akhirnya, kami mulai melihat monolit: pelacak dan papan TV dipindahkan ke layanan terpisah dengan basis datanya sendiri
• Kami mulai memisahkan meja kas pengiriman - komponen kedua yang menciptakan beban tinggi
• Tulis ulang pengguna dan sistem otentikasi perangkat

Tampaknya kita bisa bangga pada diri sendiri. Tapi di depan kami ada kekecewaan besar.

Gagal selama kampanye iklan federal. Krisis kepercayaan kedua

Utang teknis mudah untuk diakumulasikan, tetapi sangat sulit untuk dilunasi. Kecil kemungkinan bahwa Anda akan dapat memahami terlebih dahulu berapa biayanya.

Terlepas dari kenyataan bahwa kami berjuang dengan jaminan teknis selama setahun penuh, kami tidak siap untuk kampanye pemasaran massal dan mengacau di depan bisnis kami lagi. Kepercayaan yang kami peroleh setetes demi setetes menghilang.

Di bawah beban Kampanye Pemasaran Federal, kami berbaring lagi. Sistem macet lagi dan reboot setiap 3 jam. Bisnis kami kehilangan puluhan juta rubel.



Berkat krisis, kami belajar bahwa dalam kondisi ekstrem kami dapat bekerja berkali-kali lebih efisien. Kami dilepaskan 20 kali sehari. Semua bekerja sebagai satu tim, fokus pada satu tujuan. Selama dua minggu krisis, kami melakukan apa yang kami khawatirkan untuk mulai lakukan lebih awal, percaya bahwa itu akan memakan waktu berbulan-bulan untuk bekerja. Penerimaan pesanan yang tidak sinkron, penonaktifan pesanan, stress test, log bersih - ini hanya sebagian kecil dari apa yang telah kami lakukan. Kami ingin terus bekerja dengan efisien, tetapi tanpa lembur dan stres.

Pelajaran yang dipetik

Setelah retrospektif, kami sepenuhnya mengatur ulang proses kami. Kami mengambil LeSS sebagai dasar dan menambahkannya dengan praktik rekayasa. Selama beberapa bulan ke depan, kami membuat terobosan dalam memperkenalkan praktik-praktik teknik. Berdasarkan LeSS, kami telah menerapkan dan terus menggunakan:

• Backlog Produk Tunggal
• Perintah Lintas Komponen Fungsional dan Lintas Komponen
• Pemrograman pasangan dan massa
• True Continuous Integration (CI) - Integrasi kode dengan 12 tim dalam satu cabang
• Pekerjaan yang disederhanakan dengan cabang (pengembangan berbasis trunk)
• Rilis yang sering: penyebaran berkelanjutan untuk layanan microser, rilis harian untuk monolit
• Penolakan tim QA terpisah, ahli QA adalah bagian dari tim pengembangan

6 praktik yang kami pilih setelah krisis:

1. Kekuatan fokus. Sebelum krisis, masing-masing tim mengerjakan utangnya sendiri dan berspesialisasi dalam bidangnya. Selama krisis, tim tidak memiliki tugas khusus, mereka memiliki satu tujuan besar yang sulit. Misalnya, aplikasi seluler dan API harus memproses 300 pesanan per menit, apa pun yang terjadi. Tim mengambil tujuan dan secara mandiri memikirkan cara mencapainya. Tim itu sendiri merumuskan hipotesis dan dengan cepat mengujinya pada prod. Tim tidak ingin menjadi pembuat kode sederhana, mereka ingin menyelesaikan masalah.

Kekuatan fokus dimanifestasikan dalam tugas-tugas kompleks. Sebagai contoh, selama krisis, kami menciptakan stress test, terlepas dari kenyataan bahwa kami tidak memiliki pengalaman. Kami juga membuat logika untuk menerima pesanan asinkron. Kami memikirkannya untuk waktu yang lama dan berbicara, dan tampaknya bagi kami ini adalah tugas yang sangat sulit, yang bisa memakan banyak waktu. Tetapi ternyata tim cukup mampu melakukan ini dalam 2 minggu, jika tidak terganggu dan benar-benar fokus pada masalah.

2. Hackathon internal. Kami melakukan 500 Kesalahan Hackathon. Semua tim bersama-sama membersihkan log dan menghapus penyebab 500 kesalahan di situs dan di API. Tujuannya adalah menjaga kebersihan log. Saat log bersih, kesalahan baru terlihat jelas, Anda dapat dengan mudah menetapkan ambang peringatan.

Contoh lain dari hackathon adalah bug. Sebelumnya, kami memiliki tumpukan lengkap bug, beberapa dari mereka nongkrong di sana selama bertahun-tahun. Mereka sepertinya tidak pernah berakhir. Dan setiap hari yang baru muncul. Kami menggabungkan pekerjaan pada bug dan elemen backlog yang biasa.


3. Dari tim proyek ke tim yang stabil. Ada cerita lucu dengan tim proyek. Selama krisis, kami membentuk tim ahli dari orang-orang yang paling memenuhi syarat untuk tugas itu. Setelah krisis berakhir, tim memutuskan untuk melanjutkan latihan ini. Terlepas dari kenyataan bahwa saya tidak menyukai gagasan ini sama sekali, kami mencoba. Hanya dalam 2 minggu (satu sprint), di retrospektif berikutnya, tim meninggalkan praktik ini (keputusan ini membuat saya bahagia). Jika tim tidak memiliki keterampilan, mereka dapat secara bertahap belajar. Tetapi semangat tim, dukungan, dan bantuan timbal balik membutuhkan waktu yang sangat lama untuk diselesaikan, butuh berbulan-bulan. Tim proyek jangka pendek secara konstan berada pada tahap pembentukan dan penyerbuan. Anda dapat menoleransi ini selama beberapa minggu, tetapi Anda tidak akan dapat bekerja dengan cara ini sepanjang waktu.

4. Tidak ada regresi manual. Kami menetapkan tujuan untuk menyingkirkan regresi manual. Kami membutuhkan 1,5 tahun untuk mencapainya. Tetapi memiliki tujuan ambisius jangka panjang membuat Anda berpikir tentang langkah-langkah menuju tujuan.


5. Tes stres adalah bagian dari regresi. Selama krisis, kami menulis tes stres. Ini adalah pengalaman yang sama sekali baru bagi kami. Namun, hanya dalam 2 minggu, kami dapat membuat sesuatu menggunakan alat Visual Studio. Kami menggunakannya, termasuk untuk menghasilkan beban buatan di server, untuk menemukan batas kinerja. Misalnya, jika beban organik pada produk adalah 100 pesanan / mnt, kami menambahkan 50 pesanan / mnt lain menggunakan pengujian kami untuk melihat apakah sistem mampu menangani peningkatan beban.

Tahun berikutnya, kami menulis ulang tes stres dengan tim PerformanceLab yang berpengalaman. Hari ini, tes ini dijalankan setiap minggu dan memberikan umpan balik cepat ke tim pengembangan.



6. Praktek rekayasa. Semua tim kami menggunakan pemrograman berpasangan. Saya menganggap pemrograman pasangan sebagai salah satu praktik paling sederhana tetapi paling kuat. Jika Anda tidak tahu praktik rekayasa apa yang harus dimulai, saya sarankan pemrograman pasangan.

Hasil

Hasil utama bagi kami adalah perombakan. Kami bangun dan mulai berakting. Krisis membantu kami melihat potensi maksimal kami. Kami melihat bahwa kami dapat bekerja berkali-kali lebih efisien dan dengan cepat mencapai tujuan kami. Tetapi untuk ini perlu untuk mengubah cara kerja yang biasa. Kami tidak lagi takut dengan eksperimen yang berani.

Sebagai hasil dari percobaan ini selama setahun terakhir, kami telah meningkatkan kualitas dan stabilitas Dodo IS secara signifikan. Jika selama liburan musim semi 2018, pizza kami tidak dapat berfungsi karena Dodo IS, maka pada 2019, dengan peningkatan dari 300 menjadi 498 pizza, Dodo IS bekerja dengan sempurna. Kami dengan tenang selamat dari puncak penjualan di tahun baru, selama kampanye pemasaran Kedua dan liburan musim semi.

Untuk pertama kalinya dalam waktu yang lama, kami yakin dengan kualitas sistem dan mampu tidur nyenyak di malam hari. Ini adalah hasil dari penggunaan metode teknik yang berkelanjutan dan fokus pada keunggulan teknis.

Hasil Bisnis

Praktik teknik tidak diperlukan sendiri jika tidak menguntungkan bisnis Anda. Sebagai hasil dari fokus pada keunggulan teknis, kami meningkatkan kualitas kode dan mengembangkan fungsi bisnis dengan kecepatan yang dapat diprediksi. Rilis telah menjadi acara yang umum bagi kami.

Hasil untuk Tim

Hari ini kami menggunakan berbagai metode teknik:

1. Perintah Lintas Komponen Fungsional dan Lintas Komponen
2. Pemrograman Pair / Mob
3. Integrasi Berkelanjutan - integrasi kontinu dari 12 perintah ke dalam satu cabang
4. Pakar Subjek sebagai Tim
5. Tidak ada tim QA yang terpisah, ahli QA adalah bagian dari tim pengembangan
6. Mengganti regresi manual dengan autotest
7. Kebijakan Tanpa Bug (#Zerobugspolicy)
8. Hentikan Jalur sebagai pengemudi untuk mempercepat penyebaran

Apa yang telah kita pelajari

Saya ingin krisis tidak terjadi. Sebagai seorang pengembang, saya secara pribadi merasa bertanggung jawab untuk mengakumulasi terlalu banyak hutang teknis dan tidak dapat memperkirakan konsekuensinya.

1. Praktik rekayasa melindungi bisnis dari krisis
2. Jangan mengakumulasi hutang teknis. Ini bisa terlambat dan terlalu mahal
3. Perubahan evolusioner membutuhkan waktu beberapa kali lebih lama daripada yang revolusioner
4. Krisis tidak selalu merupakan hal yang buruk. Gunakan krisis untuk merevolusi proses
5. Namun, pelatihan evolusi yang panjang diperlukan di muka.
6. Jangan membabi buta menerapkan semua metode yang Anda sukai. Beberapa metode menunggu di sayap, dan ketika dia tiba, tim akan menggunakannya tanpa perlawanan. Tunggu saat yang tepat
7. Seiring waktu, tim sendiri mulai membuat keputusan penting dan menerapkannya. Beri mereka lingkungan yang memungkinkan untuk mencoba, biarkan mereka gagal dan belajar dari kesalahan

Utang teknis telah membawa kita ke krisis yang mengerikan. Saya sangat senang bahwa tim kami menemukan kekuatan untuk menggunakan jalan buntu ini sebagai titik pertumbuhan. Di kulit kita sendiri, kita menyadari bahwa masa krisis dapat dan harus digunakan untuk perubahan organisasi dan proses besar-besaran. Jadi jangan pernah menyerah, karena bahkan dalam situasi yang paling sulit ada ruang untuk prestasi.

---

Ucapan Terima Kasih

Saya ingin mengucapkan terima kasih yang sebesar-besarnya kepada semua orang yang telah membantu saya dalam perjalanan saya dari krisis menuju transformasi LeSS. Saya terus merasakan dukungan Anda.

Terima kasih banyak kepada CEO kami Fedor Ovchinnikov atas kepercayaannya. Anda adalah pemimpin sejati dalam perusahaan dengan budaya fleksibel sejati.

Terima kasih banyak kepada Dmitry Pavlov, Pemilik Produk kami, teman lama saya dan pelatih bersama.

Terima kasih kepada Alexander Andronov dan Andrey Morevsky atas dukungan mereka.

Terima kasih banyak kepada Dasha Bayanova, master Scrum penuh waktu pertama kami, yang selalu membantu dan mendukung saya dengan semua inisiatif kami. Bantuan Anda sulit ditaksir terlalu tinggi.

Terima kasih khusus kepada Joanna Rothman, yang membantu saya menulis laporan ini dalam kondisi apa pun: berlibur, pulih dari penyakit. Joanna, senang bekerja denganmu. Saran Anda, perhatian pada detail dan kerja keras banyak membantu saya.