Utang teknis mengarah ke krisis perusahaan

Akumulasi hutang teknis dapat menyebabkan perusahaan Anda mengalami krisis. Tapi itu juga bisa menjadi pendorong kuat perubahan proses besar-besaran dan membantu adopsi praktik rekayasa. Saya akan menceritakannya pada saya sendiri.



Tim IT Dodo Pizza tumbuh dari 2 pengembang yang melayani satu negara menjadi 60 orang yang melayani 12 negara selama 7 tahun. Sebagai Scrum Master dan Pelatih XP saya membantu tim membangun proses dan mengadopsi praktik-praktik teknik, tetapi adopsi ini terlalu lambat. Sangat menantang bagi saya untuk membuat tim menjaga kualitas kode tinggi ketika beberapa tim mengerjakan satu produk. Kami jatuh ke dalam perangkap preferensi untuk fitur bisnis di atas keunggulan teknis dan mengakumulasi terlalu banyak utang teknis arsitektur. Ketika pemasaran meluncurkan kampanye iklan besar-besaran pada tahun 2018, kami tidak tahan dan jatuh. Itu memalukan. Tetapi selama krisis, kami menyadari bahwa kami dapat bekerja berkali-kali lebih efisien. Krisis telah mendorong kami ke arah perubahan revolusioner dalam proses dan pengenalan cepat praktik rekayasa yang paling terkenal.

Latar belakang

Anda mungkin berpikir bahwa Dodo Pizza adalah jaringan restoran pizza biasa. Tetapi sebenarnya Dodo Pizza adalah perusahaan IT yang kebetulan menjual pizza . Bisnis kami didasarkan pada Dodo IS - platform berbasis cloud, yang mengelola semua proses bisnis, mulai dari mengambil pesanan, kemudian memasak dan menyelesaikan hingga manajemen inventaris, manajemen sumber daya manusia, dan pengambilan keputusan. Hanya dalam 7 tahun, kami telah berkembang dari 2 pengembang yang melayani pizzeria tunggal menjadi 70+ pengembang yang melayani 470+ pizza di 12 negara.

Ketika saya bergabung dengan perusahaan dua tahun lalu, kami memiliki 6 tim dan sekitar 30 pengembang. Basis kode Dodo IS memiliki sekitar 1 juta baris kode. Itu memiliki arsitektur monolitik dan cakupan tes unit sangat sedikit. Kami tidak memiliki tes API / UI saat itu. Kualitas kode sistem mengecewakan. Kami mengetahuinya dan memimpikan masa depan yang cerah ketika membagi monolit menjadi selusin layanan dan menulis ulang bagian paling mengerikan dari sistem. Kami bahkan menggambar diagram "menjadi arsitektur", tetapi jujur ​​tidak melakukan apa-apa terhadap keadaan di masa depan. Tujuan utama saya adalah untuk mengajarkan praktik rekayasa pengembang dan membangun proses pengembangan, membuat 6 tim bekerja pada satu produk .

Seiring berkembangnya tim, kami lebih banyak mengalami kekurangan proses dan praktik rekayasa yang jelas. Rilis kami menjadi lebih besar dan lebih lama karena semakin banyak pengembang berkontribusi pada sistem, tetapi kami tidak memiliki tes regresi otomatis dan karenanya membuang lebih banyak waktu pada regresi manual dengan setiap rilis. Kami menderita dari banyak perubahan yang dilakukan oleh 6 tim di cabang terpisah. Ketika sebuah tim menggabungkan perubahan mereka ke cabang tunggal sebelum rilis, kadang-kadang kami kehilangan hingga 4 jam menyelesaikan konflik penggabungan.

Sial terjadi

Pada 2018 Pemasaran menjalankan kampanye iklan federal pertama kami di TV . Itu adalah acara besar bagi kami. Kami menghabiskan 100 juta rubel ($ 1,5 juta) untuk mendanai kampanye - jumlah yang cukup signifikan bagi kami. Tim TI bersiap untuk kampanye juga. Kami mengotomatiskan dan menyederhanakan penyebaran kami - sekarang dengan satu tombol di TeamCity kami dapat menyebarkan monolit ke 12 negara. Kami menyelidiki tes kinerja dan melakukan analisis kerentanan. Kami melakukan yang terbaik tetapi kami menemukan masalah yang tidak terduga.

Kampanye iklan sangat hebat. Kami beralih dari 100 menjadi 300 pesanan / menit. Ini kabar baik. Berita buruknya adalah bahwa Dodo IS tidak dapat menahan beban seperti itu dan mati. Kami mencapai batas penskalaan vertikal dan tidak dapat menangani pesanan lagi. Sistem reboot setiap 3 jam. Setiap menit downtime menghabiskan jutaan uang bagi kami serta hilangnya rasa hormat dari pelanggan yang geram.

Ketika saya datang ke Dodo 2 tahun lalu sebagai Chief Agile Officer, saya memiliki keinginan besar untuk membuat tim kecil kami saat itu - sekitar 12 orang, tim impian. Saya segera mulai memperkenalkan praktik-praktik teknik. Sebagian besar tim mengadopsi pemrograman pasangan, pengujian unit dan DDD segera. Tapi tidak semuanya mudah. Saya harus mengatasi perlawanan dari pengembang, Pemilik Produk, dan tim dukungan.

Berbeda dengan praktik rekayasa, tidak semua orang menyukai gagasan tim fitur. Pengembang terbiasa berpikir bahwa tim yang fokus pada satu komponen menulis kode yang lebih baik. Tidak jelas bagaimana menggabungkan pengembangan fitur bisnis yang cepat dengan refactoring masif yang telah lama tertunda dari sistem yang kompleks. Aliran bug yang terus menerus juga membutuhkan perhatian terus-menerus. Tim dukungan lebih suka memiliki tim sendiri yang fokus hanya pada perbaikan bug. Banyak tim terbiasa bekerja di cabang yang berbeda dan takut untuk sering berintegrasi. Kami merilis tidak lebih dari sekali seminggu, dan setiap rilis membutuhkan waktu yang cukup lama, membutuhkan sejumlah besar regresi manual dan dukungan tes UI. Saya mencoba memperbaikinya, tetapi perubahan proses saya terlalu lambat dan terfragmentasi.

Kisah jatuh dan bangkit

Keadaan awal: Arsitektur Monolitik

Dalam mengejar kecepatan pengembangan fitur bisnis, kami tidak selalu memikirkan solusi teknis dengan baik. Kurangnya pengalaman juga memengaruhi kami. Pada awalnya, perusahaan tidak mampu merekrut pengembang terbaik. Kami bekerja dengan para penggemar yang setuju untuk membantu penciptaan Dodo IS, percaya pada pendiri perusahaan - Fedor dan bekerja hampir untuk makanan (pizza, tentu saja). Pengembang yang bergabung dengan tim kemudian mengikuti arsitektur yang sudah ada, yang menjadi ketinggalan zaman. Jadi kami memiliki aplikasi monolitik dengan satu basis data, yang berisi semua data dari semua komponen di satu tempat. Pelacak, checkout, situs, API untuk halaman arahan - semua komponen sistem bekerja dengan satu basis data, yang menjadi hambatan. Arsitektur monolitik kami menciptakan masalah monolitik. Satu posting blog mengarah ke penghentian checkout restoran.

Kisah nyata

Untuk menggambarkan betapa rapuhnya arsitektur monolitik, saya akan memberikan satu contoh saja. Setelah semua restoran kami di Rusia berhenti menerima pesanan karena posting blog. Bagaimana ini bisa terjadi?

Suatu hari CEO kami - Fedor menerbitkan sebuah posting di blog-nya. Posting ini dengan cepat mendapatkan popularitas. Ada penghitung di situs web blog Fedor yang menunjukkan sejumlah pizzeria di rantai kami dan total pendapatan dari semua pizzeria. Setiap kali seseorang membaca blog Fedor, server web mengirim permintaan ke database master untuk menghitung pendapatan. Permintaan ini membanjiri database dan berhenti melayani permintaan dari checkout restoran. Jadi posting blog populer mengganggu pekerjaan seluruh rantai restoran. Kami memperbaiki masalah dengan cepat, tetapi itu adalah tanda yang jelas (di antara banyak lainnya) bahwa arsitektur kami tidak dapat memenuhi kebutuhan bisnis dan harus dirancang ulang. Tapi kami mengabaikan tanda-tanda ini. Kami menerapkan solusi cepat dan mudah (seperti menambahkan replika database master read-only), tetapi kami tidak memiliki roadmap desain ulang teknis.

Arsitektur monolitik baik untuk memulai karena sederhana. Tetapi tidak dapat menahan beban tinggi menjadi satu titik kegagalan.

Gagal Dini pada 2017

14 Februari adalah Hari Valentine . Semua orang suka liburan ini. Bagi pecinta untuk saling memberi selamat, pada 14 Februari kami membuat pizza spesial - pepperoni dalam bentuk hati. Saya akan mengingat 14 Februari 2017 selamanya, karena pada hari ini, ketika semua pizza bekerja dengan beban penuh, Dodo IS mulai turun. Di setiap restoran pizza kami memiliki 4-5 tablet untuk melacak pesanan pembuat pizza membuat adonan, menaruh bahan, membuat atau mengirim pengiriman. Jumlah pizza mencapai 300+, setiap tablet memperbarui kondisinya beberapa kali per menit. Semua permintaan ini menciptakan beban besar pada database sehingga SQL server berhenti untuk menahan dan database mulai gagal. Dodo diletakkan pada saat yang paling tidak tepat - selama puncak penjualan. Ada musim liburan yang sibuk di depan: 23 Februari (Hari Angkatan Laut dan Angkatan Laut), 8 Maret (Hari Perempuan Internasional), 1 Mei (Hari Solidaritas Pekerja Internasional) dan 9 Mei (Hari Kemenangan dalam Perang Dunia II). Selama liburan ini, kami mengharapkan pertumbuhan pesanan yang lebih besar.

Hari dimana kamu akan mati . Mengetahui rencana pertumbuhan kami dan batas beban yang dapat kami tahan, kami menemukan berapa lama kami bisa bertahan hidup, yaitu, ketika beban puncak hari ini menjadi teratur. Perkiraan tanggal Armageddon diperkirakan sekitar enam bulan - pada Agustus atau September. Bagaimana rasanya hidup, mengetahui tanggal kematian Anda?

Hentikan pengembangan fitur selama satu tahun . Bersama dengan CEO Fedor, kami harus membuat keputusan yang sulit. Mungkin salah satu keputusan paling sulit dalam sejarah perusahaan. Kami menghentikan pengembangan fitur bisnis. Kami pikir kami akan berhenti selama 3 bulan, tetapi segera kami menyadari bahwa volume utang teknis sangat besar sehingga 3 bulan tidak akan cukup dan kami harus terus bekerja pada masalah teknis dan menunda simpanan bisnis. Faktanya, dengan 6 tim kami hanya membuat satu fitur bisnis selama tahun berikutnya. Sisa waktu, tim terlibat dalam pembayaran utang teknis. Hutang ini sangat merugikan kita - lebih dari $ 1,5 juta.

Beberapa perbaikan setelah satu tahun

Sepanjang tahun, kami memiliki pencapaian penting ini:

• Kami telah mengotomatiskan dan mempercepat pipa penempatan kami. Sebelumnya, penyebarannya semi manual. Kami dikerahkan ke 10 negara dalam waktu sekitar 2 jam.
• Mulai membelah monolit. Bagian yang paling banyak dari sistem - pelacak - dibagi menjadi layanan terpisah, dengan basis datanya sendiri. Sekarang pelacak berkomunikasi dengan seluruh sistem melalui antrian acara.
• Kami mulai memisahkan Kasir Pengiriman - komponen kedua yang menciptakan beban tinggi.
• Tulis ulang pengguna dan sistem otentikasi perangkat.

Arsitek kami mengelola jaminan teknis. Kami menggunakan perubahan arsitektur untuk mendorong backlog. Setiap tim memiliki kebebasan untuk melakukan apa yang benar untuk menciptakan arsitektur yang bermanfaat. Untuk tahun ini dengan tim ke-6 yang kami buat untuk bisnis hanya satu fitur yang berharga. Sisa waktu, tim bekerja pada utang teknis. Tampaknya kita bisa bangga pada diri sendiri. Tapi di depan kami ada kekecewaan besar.

Gagal selama Kampanye Pemasaran 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 menghabiskan setahun penuh melawan hutang teknis, kami tidak siap untuk Kampanye Pemasaran besar-besaran dan mengacau di depan bisnis kami. Anda mendapatkan kepercayaan dalam tetes, Anda kehilangan itu dalam ember. Dan kami harus mendapatkannya lagi.

Kami melewatkan momen ketika perlu untuk memperlambat kecepatan pengembangan fitur bisnis dan mengatasi utang teknis. Sudah terlambat ketika kita perhatikan. Kami berbaring di bawah beban lagi. Sistem macet dan reboot setiap 3 jam. Bisnis kami kehilangan puluhan juta rubel.



Tetapi berkat krisis, kami melihat bahwa dalam kondisi ekstrem kami dapat bekerja berkali-kali lebih efisien. Kami merilis 20 kali sehari. Semua orang bekerja sebagai satu tim, fokus pada satu tujuan. Selama dua minggu krisis, kami telah melakukan apa yang kami takutkan untuk memulai sebelumnya karena kami yakin itu akan memakan waktu berbulan-bulan. Urutan tidak sinkron, tes kinerja, log yang jelas hanya sebagian kecil dari apa yang kami lakukan. Kami ingin terus bekerja secara efektif, tetapi tanpa lembur dan stres.

Pelajaran yang dipetik

Setelah retrospektif, kami sepenuhnya merestrukturisasi proses kami. Kami mengambil kerangka kerja LeSS dan menambahkannya dengan praktik-praktik rekayasa. Selama beberapa bulan ke depan, kami membuat terobosan dalam adopsi praktik rekayasa. Berdasarkan kerangka LeSS, kami telah menerapkan dan terus menggunakan:

• jaminan tunggal;
• tim fitur lintas fungsi dan lintas komponen;
• pemrograman pasangan;
• Mencoba Pemrograman Mob.
• Genuine Continuous Integration, artinya integrasi banyak kode dari 9 tim dalam satu cabang;
• manajemen konfigurasi yang disederhanakan dengan pengembangan berbasis trunk;
• rilis yang sering: Penyebaran Berkelanjutan untuk layanan mikro, beberapa rilis per hari untuk monolit;
• tidak ada tim QA yang terpisah, pakar QA adalah bagian dari tim pengembangan.

6 praktik yang kami pilih setelah krisis

1. Kekuatan fokus . Sebelum krisis, masing-masing tim mengerjakan simpanan sendiri dan berspesialisasi dalam domainnya. Di backlog, ada tugas yang terurai dengan baik, tim memilih beberapa tugas untuk lari cepat. Tetapi selama krisis, kami bekerja sangat berbeda. Tim tidak memiliki tugas khusus, mereka memiliki tujuan yang menantang sebagai gantinya. Misalnya, aplikasi seluler dan API harus menangani 300 pesanan per menit, apa pun yang terjadi. Terserah tim bagaimana mencapai tujuan. Tim-tim itu sendiri merumuskan hipotesis, dengan cepat memeriksanya dalam Produksi dan membuangnya. Dan inilah yang ingin kami terus lakukan. Tim tidak ingin menjadi pembuat kode bodoh, mereka ingin menyelesaikan masalah.

Kekuatan fokus memanifestasikan dirinya dalam memecahkan masalah yang kompleks. Sebagai contoh, selama krisis, kami menciptakan serangkaian tes kinerja meskipun kami tidak memiliki keahlian. Kami juga membuat logika menerima pesanan tidak sinkron. Kami sudah lama memikirkannya dan berbicara, dan bagi kami sepertinya ini adalah tugas yang sangat sulit dan panjang. Tetapi ternyata tim cukup mampu melakukannya dalam 2 minggu, jika mereka tidak terganggu dan benar-benar fokus pada masalah.

2. Hackathon reguler . Kami suka bekerja dalam mode ketika semua tim diarahkan pada satu tujuan dan kami memutuskan untuk terkadang mengatur "hackathons" semacam itu. Tidak dapat dikatakan bahwa kami melaksanakannya secara teratur, tetapi ada beberapa kali. Misalnya, ada hackathon 500 kesalahan ketika semua tim membersihkan log dan menghapus penyebab 500 kesalahan di situs dan di API. Tujuannya adalah menjaga kebersihan log. Ketika log bersih, kesalahan baru terlihat jelas, Anda dapat dengan mudah mengkonfigurasi nilai ambang untuk peringatan. Ini mirip dengan tes unit - mereka tidak bisa sedikit merah.

Contoh lain dari hackathon adalah bug. Kami dulu memiliki tumpukan bug yang besar, beberapa bug telah ada di tumpukan selama bertahun-tahun. Tampaknya mereka tidak akan pernah berakhir. Dan setiap hari ada yang baru. Anda harus entah bagaimana menggabungkan pekerjaan pada bug dan pada item backlog reguler.


3. Tim proyek sementara ke tim fitur stabil . Ada cerita lucu dengan tim proyek. Selama krisis, kami membentuk tim harimau yang terdiri dari orang-orang yang paling terampil untuk tugas itu. Setelah krisis berakhir, tim memutuskan untuk melanjutkan latihan ini dan membubarkan tim. Terlepas dari kenyataan bahwa saya tidak menyukai ide ini sama sekali, saya membiarkan mereka mencobanya. Hanya dalam 2 minggu (satu sprint), pada retrospektif berikutnya, tim meninggalkan praktik ini, (keputusan ini membuat saya sangat senang). Mereka mencoba dan memahami mengapa jauh lebih nyaman bekerja di tim fitur yang stabil. Bahkan jika tim kurang memiliki keterampilan, mereka dapat secara bertahap belajar. Tapi semangat tim, dukungan dan bantuan timbal balik terbentuk untuk waktu yang lama, butuh berbulan-bulan. Tim proyek jangka pendek terus-menerus berada dalam fase pembentukan dan badai. Anda dapat menanggungnya selama beberapa minggu, tetapi Anda tidak dapat bekerja seperti ini setiap saat. Ada baiknya bahwa tim mencoba dan memahami manfaat dari tim fitur stabil.

4. Singkirkan regresi manual . Sebelum krisis, kami dirilis seminggu sekali, dan selama krisis - puluhan kali sehari. Kami menyukai kemampuan kami untuk sering melepaskan. Kami menghargai betapa mudahnya melakukan perubahan kecil, dengan cepat menyebarkannya dan segera mendapatkan umpan balik dari produksi. Oleh karena itu, kami mengubah pendekatan kami ke rilis, dan ini memengaruhi pendekatan pemrograman dan desain. Sekarang kami merilis secara terus menerus, setiap 1-2 hari. Segala sesuatu di cabang dev masuk ke produksi. Bahkan jika beberapa fitur tidak siap, ini bukan alasan untuk tidak merilis kode. Jika kami tidak ingin menampilkan beberapa fitur yang belum siap kepada pengguna, kami menyembunyikannya dengan fitur toggle. Pendekatan ini membantu kami berkembang dalam langkah-langkah kecil.

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 Kinerja adalah bagian dari uji regresi . Selama krisis kami menciptakan serangkaian tes kinerja. Itu adalah area yang sama sekali baru bagi kami. Namun demikian, hanya dalam 2 minggu, kami berhasil membuat beberapa tes kinerja menggunakan alat Visual Studio. Tes ini membantu kami tidak hanya menangkap penurunan kinerja. Kami menggunakannya untuk menambahkan beban sintetis ke server Produksi untuk mengidentifikasi batas kinerja. Misalnya, jika beban produksi organik adalah 100 pesanan / mnt dan kami menambah 50 pesanan / mnt dengan bantuan tes kinerja kami, kami dapat melihat apakah server Produksi dapat menangani peningkatan beban. Segera setelah kami melihat pengecualian atau peningkatan latensi, kami menghentikan tes. Membuat percobaan ini, kami menemukan beban maksimum yang dapat ditangani oleh server Produksi kami, dan apa yang akan menjadi hotspot.

Tahun depan kami melakukan outstaffed tes kinerja untuk tim PerformanceLab yang berpengalaman. Mereka duduk bersama dengan pengembang dan orang-orang infrastruktur kami, dan membantu kami menciptakan serangkaian uji kinerja yang kuat. Sekarang kami menjalankan tes ini setiap minggu dan memberikan umpan balik cepat kepada tim pengembangan jika kinerja terpengaruh.

Beberapa praktik rekayasa dilakukan secara iteratif. Misalnya, sering rilis. Kami mulai dengan siklus rilis mingguan, didukung dengan pengujian manual yang lambat dan rapuh. Kami mengembangkan fitur selama satu minggu dan menguji selama satu minggu lagi. Tapi itu sulit untuk mempertahankan perubahan yang dilakukan oleh banyak selama seminggu. Kemudian kami mencoba rilis tim terisolasi, ketika hanya perubahan yang dibuat oleh tim tunggal yang dirilis. Tetapi proses ini gagal karena setiap tim harus menunggu dalam antrian selama beberapa minggu. Kemudian tim belajar manfaat dari integrasi yang sering dan kami mulai berlatih rilis bersama dari beberapa tim. Para pengembang mulai bereksperimen dengan Fitur Toggle dan mendorong ke fitur Produksi yang belum selesai. Akhirnya kami tiba di Integrasi Berkelanjutan dan beberapa rilis per hari untuk monolit dan Penerapan Berkelanjutan untuk layanan-layanan microser.



Kasus lain yang menarik adalah dengan departemen QA kami. Kami dulu tidak memiliki tim QA, sebaliknya kami memiliki penguji manual. Menyadari perlunya otomatisasi pengujian, kami membentuk tim QA, tetapi sejak hari pertama tim ini tahu bahwa suatu hari akan dibubarkan. Setelah 6 bulan, tim mengotomatiskan skenario bisnis utama kami dan, dengan bantuan pengembang, menulis Bahasa Spesifik Domain (DSL) yang nyaman untuk menulis tes. Tim itu bubar, dan teknisi yang berkualitas bergabung dengan tim fitur. Sekarang tim sendiri mengembangkan dan memelihara autotest.

Hari ini kami memiliki satu simpanan tunggal yang sedang dikerjakan 9 tim fitur. Tim fitur adalah tim yang stabil, lintas fungsi, lintas komponen. Sebagian besar tim kami adalah tim fitur.

6. Fokus pada praktik rekayasa . Semua tim kami menggunakan pemrograman berpasangan. Saya menganggap memasangkan pemrograman sebagai salah satu praktik paling sederhana namun kuat yang membantu menerapkan praktik rekayasa lainnya. Jika Anda tidak tahu praktik rekayasa mana yang harus dimulai, saya sarankan pemrograman pasangan.

Hasil

Hasil utama yang diberikan krisis kepada kami adalah goncangan. Kami bangun dan mulai bertindak. Krisis telah membantu kami melihat peluang maksimal. Kami melihat bahwa kami dapat bekerja berkali-kali lebih efisien dan dengan cepat mencapai tujuan kami. Tetapi ini membutuhkan perubahan cara kerja yang teratur. Kami tidak lagi takut untuk melakukan eksperimen yang berani. Sebagai hasil dari percobaan ini, selama setahun terakhir kami telah secara signifikan meningkatkan kualitas dan stabilitas Dodo IS. Jika selama liburan musim semi tahun 2018, pizza kita tidak dapat bekerja karena Dodo IS, maka pada tahun 2019, dengan pertumbuhan dari 300 menjadi 450 pizza, Dodo IS bekerja dengan sempurna. Kami diam-diam mengalami puncak penjualan di Tahun Baru, selama Kampanye Pemasaran kedua dan liburan musim semi. Untuk pertama kalinya dalam waktu yang lama, kami yakin akan kualitas sistem dan tidur nyenyak di malam hari. Ini adalah hasil dari penggunaan praktik rekayasa yang konstan dan fokus pada keunggulan teknis.

Hasil untuk bisnis

Praktik teknik tidak diperlukan sendiri jika tidak menguntungkan bisnis Anda. Sebagai hasil dari fokus pada keunggulan teknis, kami meningkatkan kualitas kode dan mengembangkan fitur bisnis dengan kecepatan yang dapat diprediksi. Rilis telah menjadi acara rutin bagi kami. Kami merilis monolit setiap 2 hari, dan layanan yang lebih kecil setiap beberapa menit. Ini berarti bahwa kami dapat dengan cepat memberikan nilai bisnis kepada pengguna kami dan mengumpulkan umpan balik lebih cepat. Berkat fleksibilitas tim fitur, kami mendapatkan kecepatan pengembangan yang tinggi.

Hari ini kami memiliki 480 pizza online, 400 di antaranya berada di Rusia. Selama liburan Mei tahun ini, ada masalah dengan pemrosesan pesanan di restoran pizza kami lagi. Tapi kali ini yang menjadi kendala adalah layanan pelanggan di restoran pizza. Dodo IS berjalan seperti jarum jam, meskipun semakin banyak pizza dan pesanan.

Hasil untuk tim

Hari ini kami menggunakan berbagai praktik rekayasa:

1. Tim fitur lintas fungsi dan lintas komponen.
2. Pairing Programming / Pemrograman Mob.
3. Integrasi Berkelanjutan Asli, artinya beberapa integrasi kode dari 9 tim dalam satu cabang.
4. Manajemen konfigurasi yang disederhanakan dengan pengembangan berbasis trunk.
5. Tujuan bersama untuk banyak tim.
6. Subjek Ahli Masalah ada di tim.
7. Tidak ada tim QA yang terpisah, pakar QA adalah bagian dari tim pengembangan.
8. Pengganti regresi manual akhirnya dengan autotest.
9. Kebijakan tanpa bug.
10. Tunggakan hutang teknis.
11. Hentikan Jalur sebagai driver untuk percepatan penyebaran pipa.

Mereka membantu 9 tim untuk mengerjakan kode umum dan satu produk yang mencakup lusinan komponen - situs seluler dan desktop, aplikasi seluler di iOS dan Android, dan kantor belakang raksasa dengan mesin kasir, pelacakan, tampilan restoran, akun pribadi , analitik dan peramalan.

Apa yang bisa lebih baik

Mungkin kelihatannya kita telah membuat kemajuan yang baik dalam praktik-praktik teknik, tetapi kita hanya pada awalnya, kita masih memiliki ruang untuk tumbuh. Sebagai contoh, kami mencoba, tetapi sejauh ini tidak sistematis, pemrograman massa. Kami mempelajari pendekatan penulisan tes BDD. Kami masih memiliki ruang untuk tumbuh di CI, kami memahami bahwa mengintegrasikan bahkan sekali sehari tidak cukup. Dan saat kami bertambah hingga 30 tim, perlu integrasi lebih sering. Kami masih dalam proses transisi dari TDD ke ATDD. Kita harus menciptakan proses pengambilan keputusan arsitektur yang berkelanjutan dan dapat diskalakan.
Yang paling penting adalah kami menuju untuk memperkuat Keunggulan Teknis.

Karena kenyataan bahwa semua 9 tim bekerja pada tumpukan yang sama dan pada satu produk, tim memiliki keinginan yang kuat untuk bekerja sama satu sama lain. Mereka belajar membuat keputusan yang kuat sendiri.



Beberapa tim menunjukkan keinginan untuk menggunakan semua 12 praktik XP dan meminta saya untuk membantu sebagai Pelatih XP dan Scrum Master.

Apa yang kami pelajari

Saya berharap saya tidak akan membiarkan krisis terjadi. Sebagai pengembang, saya merasakan tanggung jawab pribadi untuk mengakumulasi hutang teknis yang terlalu besar dan tidak menaikkan bendera merah sebelumnya:

• Praktik rekayasa melindungi bisnis dari krisis.
• Jangan mengakumulasi hutang teknis. Mungkin sudah terlambat dan biayanya terlalu tinggi.
• Perubahan evolusioner membutuhkan waktu beberapa kali lebih lama daripada perubahan revolusioner.
• Krisis tidak selalu merupakan hal yang buruk. Gunakan krisis untuk merevolusi proses.
• Namun, persiapan evolusi yang panjang diperlukan di muka.
• Jangan membabi buta menerapkan semua praktik yang Anda sukai. Beberapa latihan menunggu di sayap, dan ketika dia datang, tim akan menggunakannya tanpa perlawanan. Tunggu saat yang tepat.
• Perbaiki dan sesuaikan praktik dengan konteks Anda.
• Seiring waktu, tim sendiri mulai membuat keputusan yang kuat dan menerapkannya. Beri mereka lingkungan yang aman untuk mencoba, gagal, dan belajar kesalahan.

Utang teknis membawa kita ke krisis. Tetapi dari krisis, baik pengembang maupun pebisnis belajar betapa pentingnya fokus pada keunggulan teknis dan praktik rekayasa. Kami menggunakan krisis sebagai pemicu perubahan organisasi dan proses besar-besaran.

---

Ucapan Terima Kasih

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

Terima kasih banyak kepada CEO kami, Fedor Ovchinnikov atas kepercayaannya. Anda adalah pemimpin sejati perusahaan dengan budaya lincah yang asli.

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

Terima kasih Alex Andronov dan Andrey Morevsky karena mendukung saya dalam peran saya.

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

Terima kasih banyak untuk Johanna Rothman yang telah membantu saya menulis laporan ini dalam kondisi apa pun: sedang berlibur, pulih setelah sakit. Johanna, senang bekerja dengan Anda. Bantuan, saran, perhatian pada detail, dan ketekunan Anda sangat kami hargai.