Sisi gelap lincah

Pembaca yang penuh perhatian membalik kaset itu dan mengajukan pertanyaan: "Apa, lagi, teks tentang lincah?". Ya

Artikel ini adalah tentang proses, aspek teknis, dan sedikit tentang bagaimana kehidupan gesit dan diimplementasikan di Yandex.Money. Jika Anda telah berjalan setidaknya setengah jalan untuk menjadi gesit nyata, beberapa hal mungkin tampak jelas bagi Anda, dan itu tidak masalah.

Di bawah kucing tentang bangku tes, mengunci orang di ruang rapat dan bagaimana mengelola departemen, ketika semua orang tersebar di seluruh tim dan menikmati hidup.

Dan pembaca yang penuh perhatian akan bertanya, "Mengapa Sisi Gelap? Ada apa dengan Darth Vader?" Sayangnya, tidak, itu akan tentang sisi gelap bulan, yang tidak diketahui umat manusia, sampai perangkat terbang untuk memotretnya dan menunjukkannya kepada semua orang.

Ketika Anda menerapkan gesit, Anda merancang proyek eksplorasi bulan, tidak tahu
apa yang ada di sisi lain

Semuanya dimulai dengan upaya untuk memperkenalkan proses pengembangan baru.

Scrum, kanban, scrambana atau sepeda lokal lainnya tidak begitu penting.

Departemen pengembangan klasik biasanya dipimpin oleh seorang manajer sumber daya. Dia berkata kepada dunia luar: "Jangan pergi ke pengembang, pergi ke saya, saya akan mendistribusikan semuanya di sini sekarang." Sekali manajer seperti itu untuk pertama kalinya mengalokasikan aliran, karena beberapa pelanggan khusus telah muncul. Lalu ada lebih banyak pelanggan di dalam dan di luar perusahaan, konflik dimulai, perjuangan untuk sumber daya, dan manajer harus menyelesaikan semuanya. Juga dengan alokasi utas.

Java - kiri, JavaScript - kanan

Permainan ini berlanjut ke beberapa titik kritis, setelah itu perusahaan menerima gagasan bahwa sekarang tepat gesit diperlukan. Tim produk muncul, karena untuk PO tidak ada yang lebih berharga daripada sumber daya khusus dan tim Anda sendiri. Produk ini senang karena tim langsung membuatnya lebih mudah untuk menjawab fungsionalitas dan memikul beban tanggung jawab untuk PNL, lalu lintas dan KPI lainnya.

Kedengarannya benar, tetapi dalam kehidupan nyata, semuanya agak salah.

Di sebagian besar departemen pembangunan klasik, lebih menguntungkan bekerja dengan monolit. Dalam hal ini, semua atribut terpasang - siklus rilis dalam 3-4 minggu, pengujian dan perakitan yang lama.

Terkadang monolit normal

Tetapi tim yang dipilih tidak bekerja seperti itu. Secara umum, dunia datang ke layanan microser karena fakta bahwa semua orang mulai beralih ke tim kecil dan bekerja di dalamnya. Ya, ini mengarah pada fakta bahwa kode "menyebar" dan semuanya menjadi lebih sulit untuk dikendalikan.

Di sisi lain, kami mempercepat rilis produk, meluncurkan rilis lebih sering, tetapi kami mengalami masalah dengan pengujian. Dan mereka juga perlu dipecahkan entah bagaimana.

Menguji Reformasi

Jika Anda memiliki satu tim dan satu test stand - semuanya beres, Anda tidak bisa khawatir (atau khawatir, tetapi untuk alasan yang berbeda). Seringkali dalam kasus seperti itu, bahkan tidak dianggap sesuatu yang kritis - misalnya, alat tambahan seperti email atau obrolan perusahaan. Semua orang memonitor produksi dengan cermat, dan mereka juga baik-baik saja.

Jika Anda telah terbang ke Edgile Moon, maka bangku tes adalah hal yang akan memperlambat seluruh proses, dan itulah sebabnya.

Kisah hidup : di satu perusahaan, entropi di sekitar tangkas mulai tumbuh terlalu cepat. Pada titik ini, para penguji memasuki jadwal satu-satunya bangku tes dalam kalender - mereka membagi waktu menjadi slot setengah jam dan mencoba untuk entah bagaimana mengendalikan kekacauan.

Sebenarnya, 20 tim harus menggunakan dudukan, tetapi mereka tidak bisa, karena salah satu dari mereka merusak segalanya

Tentang tempat tes

Sekali waktu, kami memiliki beberapa monolit, masing-masing dengan bangku tes, dan semua orang senang. Setelah kami membuat proyek kompleks untuk pemisahan tribun, kami mengalokasikan tim, dan kemudian ada 20 tribun.

Sekarang ada 70 dari mereka, tetapi kami bertujuan 200 - sehingga semua orang, gratis, dan tidak ada yang tersinggung.

Dari dialog dengan administrator:
- Katakan, di mana otomasi penyebaran?
- Penghitungan sekali setiap dua minggu membutuhkan satu jam, apa yang harus sayaotomatiskan di sini?

Faktanya, ini: (200 dudukan + produksi) * (50+ komponen) = Banyak upaya untuk digunakan.
Sekarang kami memiliki lebih dari 50 komponen yang diluncurkan robot. Jika bukan karena dia, maka semua orang akan menjadi buruk.

Pada tahap ini, perusahaan, yang bergerak dengan gesit, akan memiliki sistem otomatis untuk perakitan dan pengiriman ke produksi, kerja tim akan secara bertahap meningkat dan kinerja juga akan meningkat - hingga 60-80 rilis per minggu, dan setiap komponen akan dirilis 2-3 kali sehari .

Pada titik ini, semua orang mengerti bahwa sistem telah menjadi terlalu besar untuk dipahami oleh satu orang

Di tim mana pun yang mendukung monolit, pasti ada beberapa orang yang sudah tua. Mereka ada di sini sejak awal dan mengingat semua bug sepanjang masa, ingat keputusan logis aneh yang dijual bisnis.

Kisah hidup:
"Secara umum, itu normal untuk mencoba mengetuk klien 3 kali, tetapi klien ini istimewa, dan kami akan mengetuk 100 kali, ada faktor koreksi, dan tidak perlu menyentuhnya, silakan menyentuhnya, tidak hanya seperti itu."

Begitu banyak sumber daya yang dihabiskan untuk mempertahankan pekerjaan tegakan sehingga operasi menjadi "emas" - gandakan seluruh kebun dengan jumlah tegakan uji, tambahkan produksi, marah dan akhirnya panggil admin.

Pemantauan lainnya

Admin akan datang dan berkata: "Semuanya tercakup oleh pemantauan pada kami". Ini baik-baik saja, tetapi dengan satu klarifikasi - pemantauan akan bagus untuk menjadi kebiasaan.

Metrik “Besi”, jumlah memori yang dikonsumsi oleh Jawa, suhu semua inti dari semua prosesor - semua ini bermanfaat, tetapi itu tidak selalu membantu jika terjadi insiden dengan pelanggan. Metrik bisnis juga tidak akan mengerti jika Anda belum membuatnya khusus. Dunia ini kompleks - jarang semua klien ideal menggunakan API ideal Anda secara ideal. Orang-orang melakukan segalanya, dan setiap orang harus beradaptasi - terkadang klien untuk Anda, kadang-kadang Anda untuk klien.

Seperti pembangkit listrik tenaga nuklir

Kisah hidup : untuk waktu yang lama kami mencari dan memperbaiki bug pada produk kami. Setelah itu, salah satu klien memecahkan beberapa proses di mana bug ini diperhitungkan.

Pada saat-saat seperti itu, Anda harus menambahkan pemantauan khusus, karena tanpa mengisolasi situasi dan agregasi yang luar biasa, itu tidak akan berfungsi. Oleh karena itu, omong-omong, mereka sering berbicara dan menulis tentang pembelajaran mesin dan sistem kompleks yang mendefinisikan masalah alih-alih orang.

Setiap enam bulan sekali, Anda harus melakukan tinjauan pemantauan, karena ekspektasi bisnis meningkat seiring waktu. Itu terjadi seperti ini - semuanya dibangun dan dikendalikan di perusahaan, dan bisnis membawa klien baru yang membutuhkan SLA urutan yang lebih besar. Dan keseluruhan cerita sudah berakhir.

Jika ini diatasi, maka sistem akan bekerja dengan baik dalam semua kasus, kecuali untuk proyek "payung".

Proyek Payung

Ini, misalnya, adalah pengenalan 54-FZ, ketika negara mengatakan: "Dan merestrukturisasi semua proses tunai di negara ini." Atau ketika pemasaran membayar untuk proyek, produk masih harus bekerja dan bekerja, dan tenggat waktu itu nyata, dan kemudian mereka akan menembaknya untuk itu. Atau ketika seseorang dari manajemen puncak baru saja masuk, tidak masalah dengan alasan apa, dan ia juga memiliki proyek dengan tenggat waktu.

Spoiler - sedikit orang di pasar yang mengerti cara membuatnya. Anda dapat membeli berbagai pengaya selain scrum dan kanban, Anda dapat membaca kisah sukses, tetapi latihan menunjukkan bahwa lebih mahal untuk melakukan proyek seperti itu secara teori. Selain itu, semua AMAN dan LEAN ini mahal secara administratif dan sumber daya, dan mereka juga membutuhkan kompetensi yang mahal dan kompleks yang tidak ada di pasaran.

Kisah Hidup: Spotify adalah salah satu perusahaan lincah yang patut dicontoh. Di beberapa titik, mereka datang dengan berlangganan keluarga, tetapi tidak dapat menyadarinya karena kesulitan dalam sinkronisasi dan perencanaan antara tim yang memiliki peta jalan dan rencana mereka sendiri. Setahun kemudian, Google dan Apple meluncurkan langganan keluarga.

Konflik sinkronisasi dan penjadwalan

Masalah utama dengan proyek payung adalah sinkronisasi semua tim yang berpartisipasi. Ini terkait dengan fakta bahwa orang tidak suka bernegosiasi.

Ini memanifestasikan dirinya dalam banyak hal, dimulai dengan scrum, ketika orang tidak bisa setuju dalam kerangka satu departemen sumber daya. Dengan gesit, Anda harus menyinkronkan dan mengoordinasikan semua yang terjadi dengan beberapa tim. Dan jika pada titik tertentu Anda berhenti mengharuskan semua orang untuk bekerja bersama, maka setiap tim kembali ke sudut gelap favorit mereka dan bekerja secara mandiri. Ini mengarah pada kegagalan.


Retas seumur hidup
Jika dua bulan tersisa sebelum hukum berikutnya, atau sebelum kampanye iklan, atau tuntutan bos - bawa orang-orang dari 4 tim, kunci mereka di satu ruangan, berikan makanan dan air dan kontrol. Ini kasar, tetapi berhasil. Karena jika Anda mencoba melakukan sinkronisasi untuk waktu yang terbatas, Anda akan gagal dalam proyek tersebut.

Secara umum, sinkronisasi diperlukan dan tanpanya Anda tidak dapat melanjutkan. Ini mempersulit kehidupan dalam proyek-proyek dengan tenggat waktu yang jelas dan kritikalitas tinggi - tenggat waktu berkisar dari 10% hingga 50%, dan ini sering tidak dapat diterima.

Bagaimana cara mengaturnya?

Pemimpin klasik di departemen terdistribusi tidak mengerti apa perannya karena dia diajari paradigma "Saya memberikan tugas kepada semua orang", dan saya harus bekerja dengan "Saya tidak punya orang sama sekali, mengapa saya ada di perusahaan?".



Hal terburuk adalah bagi orang-orang aneh kontrol yang tidak ketinggalan satu tugas pun yang dipecahkan oleh departemen, mengatur ulasan kode publik ganda dan mengontrol semuanya secara harfiah. Ketika orang-orang didistribusikan ke dalam tim, mereka mengajukan pertanyaan: "Mengapa saya di sini?". Jawabannya adalah agar pengembang di semua tim bertukar informasi, tumbuh serempak dalam satu arah dan sistem tidak merangkak.

Secara umum, ketika pertanyaan seperti itu terdengar, pemimpin perlu diubah atau diajar.

Mengajar karena banyak pemimpin (termasuk kita) tumbuh dari insinyur, dan tidak ada yang pernah mengajari mereka soft skill. Kami percaya bahwa ini penting, dan sekali datang ke HR dan meminta kursus dua tahun besar untuk manajer - dari dasar-dasar ke kinerja dan motivasi non-keuangan.

Budaya dalam IT

Ada poin halus lain tentang lincah dalam mengatur tim. Ketika pengembang menyetujui sesuatu di dalam tim, mereka dapat mulai membela kepentingan tim, melupakan kepentingan perusahaan.



Idealnya, ketika orang mengerti bahwa ada orang lain di sekitar bulan Ajail mereka - layanan keamanan dengan persyaratannya sendiri; arsitektur yang tidak hanya ditemukan; tim lain yang minatnya perlu dipertimbangkan. Kami berusaha mengidentifikasi, memelihara, dan mendorong perilaku tersebut.

Agile - ujung gunung es

Jalan ini memiliki karakteristik penting.
Waktu yang lama Sebagai contoh, DevOps muncul di pasar lima tahun yang lalu, dan implementasinya sekarang akan memakan waktu 1-2 tahun, tergantung pada ukuran perusahaan. Jika Anda mulai berurusan dengan itu ketika Anda memiliki garis di tribun tes, maka Anda dijamin enam bulan neraka, karena admin akan terkoyak di antara semuanya.

Mahal Anda dapat menerapkan gesit dan bergerak di sepanjang jalan ini hanya jika Anda memiliki bisnis yang kuat dan perusahaan yang kuat, dan Anda memahami bahwa di masa depan Anda masih harus tumbuh.

Tidak ada orang. Agile membutuhkan kompetensi baru, yang tidak dimiliki banyak orang. Ternyata lingkaran setan - tidak ada orang -> semuanya tidak berjalan dengan baik -> tidak ada uang -> tidak ada tempat untuk mengambil orang.

Tiga kesimpulan

1. Jangan menyentuh departemen pengembangan "klasik" tanpa perlu. Sistem hybrid bekerja di Yandex.Money - ada tim produk, tetapi ada departemen yang dapat bekerja secara efektif tanpa gesit.
   
2. Jika Anda tidak memiliki tugas untuk membangun kembali seluruh perusahaan, tetapi memiliki keinginan atau kebutuhan untuk membuat produk baru lebih cepat dengan pendekatan baru, maka kadang-kadang lebih mudah untuk mempekerjakan agen outsourcing yang bekerja dengan gesit dan memberi produk sumber daya eksternal.
   
3. Jika transformasi TI tidak terhindarkan, maka yang terbaik adalah menyetujui segala sesuatu yang "mendarat". Layak untuk menyimpulkan semacam "perjanjian tuan-tuan" dengan kepemimpinan - bahwa akan ada anggaran untuk perangkat keras, orang (untuk posisi baru untuk administrator sistem, penguji dan pengembang). Dalam hal ini, dimungkinkan untuk secara berkala kembali ke perjanjian ini dan mendiskusikan apa yang telah dilakukan dan bagaimana.
   

Semua hal di atas memiliki satu masalah. Jalan terus! = Datanglah ke kesuksesan. Jangan lulus = dijamin gagal.

Tetapi jika Anda sedang dalam perjalanan - semoga berhasil!