Dari monolit ke tim modular

Perusahaan besar sering berduka atas masalah kemampuan beradaptasi dan kemampuan manuver. Lebih tepatnya, hampir dari ketiadaan keduanya.

Bayangkan: semua tim platform sibuk dengan satu fitur, dan bisnis memiliki persyaratan mendesak untuk melakukan sesuatu yang lain atau menyesuaikan fungsionalitas yang sudah dikembangkan. Dan saat ini bekerja pada satu fitur berhenti dan bekerja pada fitur lainnya dimulai. Pada saat berikutnya, persyaratan baru dari bisnis muncul, dan fitur tetap belum selesai. Pengembang tersinggung dan bisnisnya menderita.



Inilah situasi lain: API berubah, Anda harus segera berlari ke departemen backend untuk mengetahui detailnya, lalu kembali ke garis depan (iOS / Android / web). Selanjutnya, setelah membahas koreksi Anda dengan front, Anda harus kembali ke belakang dan berbicara persyaratan kami. Itu sangat melelahkan, kehilangan waktu tim, seorang pengembang individu dan keberanian semua orang yang tertarik.

Nama saya Valery, tim kami terlibat dalam QIWI Wallet untuk iOS. Tetapi selalu diperlukan untuk menjaga komunikasi dengan tim lain, jika tidak, desync lengkap akan terjadi. Adapun ketidaknyamanan kami, bisnis selalu maju dan memberikan kebebasan untuk eksperimen. Karena itu, muncul pertanyaan untuk mengubah struktur yang ada. Lingkungan yang menguntungkan untuk menguji ide kami untuk perubahan adalah scrum. Setiap dua minggu, kami di dalam platform dapat mengedit kursus sehingga setidaknya terkoordinasi dengan tim lain. Butuh waktu lama untuk menguji teori. Dari sebulan hingga enam bulan. Opsi apa yang telah kami coba:

Fitur oouner

Satu orang dari tim ditunjuk untuk bertanggung jawab atas fitur untuk sprint berikutnya. Orang ini menghabiskan sebagian waktunya dengan desainer dan dengan fitur dari tim garis depan lainnya (cadangan memutuskan untuk tidak menggunakan fitur-ower), mencari tahu jebakan dan seluk-beluk pekerjaan yang akan datang, ia setuju dengan backend tentang kontrak. Dia juga memantau semua perubahan pada backend dan bisnis. Dan semuanya tampak baik-baik saja. Tidak ada yang panik, kecuali orang ini yang mengambil pukulan dari lingkungan yang bisa berubah pada dirinya sendiri. Semua orang tenang sejenak.

Tapi kebahagiaan terus berlanjut sampai fitur OUNER sakit tepat sebelum berlari. Dan seluruh ilusi ketenangan menghilang, dan kami kembali ke tempat kami mulai.

Perawatan umum

Perwakilan dari berbagai platform diundang untuk merawat satu tim platform. Itu menjadi sedikit lebih baik, tetapi orang-orang tidak suka (dari kata sama sekali) untuk duduk di beberapa pertemuan berturut-turut. Tetapi alasan utamanya adalah variabilitas API dan kontrak, perubahan dalam tujuan sprint, dan itu baik jika hanya berubah pada hari pertama sprint. Tapi biasanya semua sama, perubahan turun selama dua minggu. Intinya - tujuan tidak terpenuhi, orang-orang sedang memproses, bisnis ini menderita.

Obrolan

Salah satu opsi non-standar adalah pembuatan obrolan. Obrolan terpisah dibuat untuk setiap fitur. Selain itu, ada juga ruang obrolan tim di mana masalah dibahas. Dan juga obrolan umum khusus untuk masalah di mana semua tim berada. Pada awalnya, masalah itu tampaknya diselesaikan.

Tapi obrolan cepat berlipat ganda, dan, Anda tahu, itu menjadi beban. Ketika masalah muncul, menjadi tidak jelas di mana mencari informasi - baik dalam obrolan di bagian profil, atau dalam obrolan tentang refactoring klien jaringan atau mengganti modul informasi pengguna. Akibatnya, itu menjadi lebih membingungkan. Sekali lagi saya harus menjalankan antar departemen.

Fitur-tim

Kemudian sebuah toko grosir datang dan menawarkan untuk mencoba format fitur-tima. Apa artinya ini: dua pengembang diambil dari setiap platform (iOS, Android, web, backend) dan dua penguji) dan tim baru dibentuk.

Pendekatan ini seharusnya menyelesaikan beberapa masalah utama, selain koherensi dan kecepatan rilis rilis:

Otonomi
Sebuah tim yang pergi ke pertemuan bersama adalah se independen mungkin dari orang lain. Tautan utama dari dependensi eksternal adalah produk.

Tes Teori Cepat
Lagi pula, sebelum seluruh tim dompet melakukan beberapa fungsi baru dan kebetulan fungsi yang sangat keren ini tidak masuk ke pengguna. Ternyata seluruh pembangunan menggergaji hal-hal yang tidak perlu dan anggarannya tidak ke mana-mana.

Seluruh tim memahami apa itu "pengembangan produk"
Fitur dibuat atau persyaratan bisnis tiba, dan pengembang tidak selalu mengerti mengapa, mengapa, dan siapa yang membutuhkannya.

Seluruh tim mempengaruhi produk. Sampai penemuan fitur baru
Akibatnya, semua orang menyukai pendekatan ini, dan saat ini kami memiliki 3 tim independen yang terlibat dalam tugas produk mereka. Sekarang, ketika mengubah kontrak, Anda tidak perlu berkeliling departemen dan mencari yang bertanggung jawab, juga tidak perlu untuk sekelompok obrolan yang membingungkan, cukup tusuk pengembang yang duduk di dekatnya. Rapat diadakan semua fitur, di mana perwakilan dari semua platform dan QA segera hadir.

Pertanyaan dipecahkan dalam kata-kata dalam beberapa menit dan tidak ada yang mengalami rasa sakit yang sama. Selain itu, manfaat besar lainnya untuk bisnis ini adalah jika fitur tidak menjangkau pengguna, maka hanya satu fitur tim (saat ini dari tiga) yang akan dihabiskan, dan bukan seluruh pengembangan, seperti sebelumnya.

Sebagai hasilnya, kami berhasil mencapai keunggulan berikut:

• Otonomi dari tim lain.
• Pengembangan fleksibel maksimum, kita dapat dengan aman mengubah arah, jika perangkat lunak memerlukannya.
• Pemecahan masalah yang cepat dan mudah.
• Tes cepat teori fitur.

Saya harap contoh ini membantu Anda memecahkan masalah komunikasi antar tim. Jika Anda memiliki opsi keren lainnya, maka saya menunggu umpan balik).

Terima kasih

Dan kami akan segera memiliki mitap untuk pengembang iOS.