Veeam Indoor Kitchen: Bagaimana Proses R&D bekerja

Malam hari Wawancara Litbang berikutnya akan segera berakhir, dan pewawancara kami mendengarkan pertanyaan tak terduga dari kolega masa depan. Tapi tidak ada kejutan: rasio yang disimpulkan oleh Wilfredo Pareto juga berfungsi di sini. Dalam 80% kasus, kami mendengar empat pertanyaan - sekitar 20% dari jumlah total yang diterima. Bagaimana proses Anda diatur? Apa yang akan saya lakukan? Bagaimana cara menjadi pemimpin senior / tim dalam setahun? Bagaimana dengan relokasi ke Eropa?

Dalam posting ini, kami akan menjawab pertanyaan pertama dan berbicara tentang proses pengembangan di Veeam - dari tim ke tim jawaban ini paling sedikit berubah.



Jadi prosesnya. Ini adalah urutan tindakan berulang yang mengarah pada kesuksesan setiap hari, atau setidaknya kadang-kadang. Anda belajar cara memasak borsch dan setiap kali ternyata sama lezatnya - sebuah proses. Parkir bukanlah suatu ketukan - menguasai proses. Proses ini memungkinkan otak untuk tidak memikirkan rutinitas setiap saat, mengubahnya menjadi kerja mekanis. Otak dibebaskan untuk kreativitas.

Proses pengembangan adalah serangkaian tindakan yang mengubah keinginan pengguna menjadi produk nyata. Keinginan ini dirumuskan oleh analis dan manajer produk, diimplementasikan oleh pengembang, dievaluasi secara kritis oleh penguji, dijelaskan oleh penulis teknis.

Kami di Veeam membuat produk besar untuk replikasi dan pusat data replikasi - sehingga tidak ada yang hilang. Produk kotak klasik tanpa pelanggan tertentu. Sekilas, masalahnya sederhana, tetapi ada nuansa, jadi kami melakukannya untuk dekade kedua.

Aktor

Setiap rilis adalah hasil dari beberapa grup:

• Manajer produk, atau analis . Mereka memprioritaskan pekerjaan mereka, berkomunikasi dengan dunia luar - pelanggan dan mitra. Kemitraan bisa termasuk teknologi. Sebagai contoh, seorang distributor dapat memberi tahu apa yang kurang untuk meningkatkan penjualan, dan produsen hypervisor dapat memberi tahu tentang rencana untuk masa depan. Untuk tim ini, "keterampilan berbicara", kemampuan untuk menangkap dan memprioritaskan tren dalam arus pendapat yang berombak sangat penting. Dan kemudian mempertahankan posisi yang dipilih, katakan tidak, jelaskan mengapa sesuatu dilakukan dengan cara ini, dan bukan sebaliknya. Tidak masalah dalam siaran pers, di konferensi atau secara pribadi. Orang-orang ini mendidik dunia penjualan.
  
• Dukungan Teknis Saluran bantuan untuk pelanggan kami. Indikator paling penting dari sebuah tim adalah waktu respons terhadap suatu masalah dan waktu penyelesaiannya (SLA). Sekitar beberapa ribu panggilan telepon dilayani selama bulan tersebut. Tim ini berlapis-lapis, termasuk kelompok interaksi dengan pelanggan, dan kelompok analitik panggilan, pengembangan solusi, dll. Berdasarkan informasi yang diterima oleh dukungan, daftar perbaikan dan urgensi dirumuskan - apakah akan diterapkan dalam perbaikan pribadi, pembaruan berikutnya atau menunda rilis besar.
  
• Pengembang R&D . Orang yang mewujudkan permintaan menjadi kode.
  
• Penguji, atau QA . Penguji pertama, kisaran uji tangki dan dudukan getaran pada saat yang sama. Mereka tidak hanya memeriksa apa yang sudah dilaksanakan - tetapi juga terhubung untuk bekerja pada tahap konsepsi. Mengulangi tugas administrator dalam infrastruktur yang dekat dengan pertempuran, lebih mudah untuk memahami betapa nyamannya antarmuka yang dibuat atau algoritma yang dipilih produktif. Ketika dukungan teknis sampai pada kesimpulan bahwa ada cacat pada produk, QA mereproduksi skenario yang bermasalah dan memantau perbaikannya.
  
• Tim penulis teknis. Mereka membuat dokumentasi pengguna akhir, serta dokumen spesifik seperti "Cara kerjanya" dan "Panduan Penerapan". Mereka mendapatkan bahan untuk bekerja dari pengembang, penguji dan analis.
  

Beberapa tim lebih suka ruang terbuka, tetapi lebih sering - lemari

Tim dihubungkan melalui sistem akuntansi persyaratan. Kami menerapkannya berdasarkan Sistem Microsoft Team Foundation, karena kami secara historis menggunakannya sebagai sistem penyimpanan versi sumber. Sistem menyimpan persyaratan (persyaratan), cacat (bug) dan panggilan untuk mendukung (masalah), yang membutuhkan partisipasi QA dan pengembang. Setiap masalah melibatkan ratusan peserta yang mengerjakan ribuan tugas, persyaratan, dan cacat. Sistem membantu menjaga semua ini dan, yang lebih penting, mendistribusikan beban secara merata, memprioritaskan pengembang.

Cincin pohon: siklus pengembangan

Pengembangan produk kami bersifat siklus, setiap siklus berakhir dengan rilis versi berikutnya - rilis. Inilah yang tercermin dalam rilis:

• Tren pasar jangka panjang . Misalnya, virtualisasi dan kemunculan infrastruktur cloud. Mengubah paradigma pekerjaan TI membutuhkan waktu bertahun-tahun - saat ini, pengguna beralih dari kecurigaan dan penolakan ("apa-apaan ini") ke pengakuan massal ("ya, semua orang melakukannya"). Virtualisasi pusat data pada suatu waktu memunculkan Veeam, karena dalam kondisi virtualisasi, produk lama untuk mesin cadangan tidak efektif.
  
• Dukungan untuk platform baru . Sekali waktu, Veeam dimaksudkan hanya untuk pusat data tervirtualisasi berdasarkan pada platform VMWare. Dengan jumlah dan ukuran pelanggan yang terus bertambah, ada kebutuhan untuk mendukung platform baru. Selain VMWare, hypervisor lainnya (Hyper-V), server fisik, platform cloud (AWS, Azure), dll. Muncul.
  
• Perubahan taktis di pasar . Versi sistem operasi dan hypervisor berikutnya dirilis. Pengalaman diperoleh dengan menggunakan versi produk kami sebelumnya. Sebagai contoh, ini adalah bagaimana kami mendapat dukungan tingkat item - pemulihan selektif dari server aplikasi populer seperti Microsoft Exchange, Microsoft SQL Server, Oracle Database, dll.
  
• Cacat . Terlepas dari semua upaya kami, hidup tidak-tidak, dan itu menghadirkan kejutan. Tentu saja, kami berusaha meminimalkannya.
  

Setiap kuartal kami mendapatkan pembaruan (pembaruan), sekitar setahun sekali - rilis utama (utama). Mereka baik karena meminimalkan pengeluaran untuk menciptakan fungsionalitas volumetrik yang terkait dengan mendukung platform baru dan mengubah paradigma. Berdasarkan rincian penganggaran, departemen TI klien paling aktif di akhir tahun, jadi kami meluncurkan rilis besar juga saat ini.

Pembaruan triwulanan terutama memiliki dua tujuan: dukungan untuk versi baru dari server yang dilindungi dan pemecahan masalah. Dalam pembaruan, kami mengumpulkan semua koreksi kerusakan yang ditemukan oleh pelanggan sejak rilis versi utama. Juga, dengan bantuan pembaruan, kami dengan cepat merespons perubahan pada platform yang didukung. Berdasarkan ketentuan SLA, Veeam harus menambahkan dukungan untuk versi baru hypervisor dalam waktu tidak lebih dari tiga bulan .
Dan bagaimana jika produk tersebut tidak berfungsi untuk klien tertentu? Dalam hal ini, kami mengeluarkan perbaikan pribadi - dengan kata lain, penopang. Perbaikan semacam itu dirilis setiap minggu dan tidak selalu dikaitkan dengan cacat pada produk. Misalnya, pengaturan keamanan klien mungkin tidak kompatibel dengan produk. Dengan mengeluarkan perbaikan pribadi, kami menganalisis frekuensi masalah dan memutuskan apakah akan menyertakan perbaikan dalam pembaruan triwulanan berikutnya.

Dari fajar hingga senja: lepaskan kronik

Setiap siklus rilis dimulai dengan perencanaan - pada tingkat produk secara keseluruhan dan pada tingkat persyaratan tunggal. Dalam kasus pertama, masalah prioritas bisnis dan distribusi persyaratan antara tim diselesaikan. Pertama-tama, persyaratan atau epos paling mendesak dibahas. Dengan cara yang baik, tidak lebih dari 60% dari total volume pekerjaan pada rilis harus dialokasikan ke epik, sehingga ada bantalan waktu. Perencanaan produk dilakukan di tingkat kepala departemen - produk, penguji, pengembang.

Pengembang dan penguji dibagi menjadi beberapa tim. Jumlah optimal orang dalam tim adalah lima. Tim bersifat fungsional dan universal. Dalam kasus terakhir, tim mandiri, berisi pengembang dengan keahlian di beberapa bidang. Perintah fungsional lebih sempit - mereka berfungsi pada antarmuka pengguna, komponen sistem, dll. Orang-orang dari tim fungsional yang berbeda membentuk tim virtual yang mulai menerapkan persyaratan. Setidaknya perwakilan kelompok PM, tim pengembangan dan pengujian berkumpul di sini. Ketua tim ditugaskan sebagai pemimpin tim dari salah satu tim fungsional.

Pekerjaan dimulai pada persyaratan. Tim virtual bertemu setiap minggu. Peserta berbicara tentang keberhasilan selama seminggu terakhir dan merencanakan pekerjaan untuk yang berikutnya.
Pemimpin tim yang bertanggung jawab atas moderasi memoderasi pertemuan dan mencatat hasilnya. Dia juga memecahkan masalah yang tidak bisa diselesaikan dalam tim virtual. Misalnya, jika Anda perlu memindahkan tanggal atau menunda sebagian tugas.

Di dalam pengembangan fungsional atau tim pengujian, titik kontrol lebih dekat. Sebagai aturan, rencana mingguan dibagi menjadi tugas yang berlangsung tidak lebih dari dua hingga tiga hari. Beberapa tim telah mengakar dalam praktik scrum dengan volatile harian, di suatu tempat, interaksi point-to-point antara pemimpin tim dan tim bekerja lebih efisien.


Ruang pertemuan khusus untuk membahas status proyek saat ini

Semua pengembangan dibagi menjadi iterasi mingguan atau dua mingguan. Selama iterasi pertama, penting untuk membuat fungsional yang berfungsi minimal, yang kemudian akan ditumbuhi daging - misalnya, antarmuka pengguna yang canggih, API untuk klien, dll. Dan yang paling penting, keberadaan kerangka sudah memungkinkan penguji untuk mendapatkan fitur.

Siklus rilis termasuk rilis alfa dan beta. Dengan bantuan mereka, kami menampilkan fitur baru ke dunia luar dan mengumpulkan umpan balik sebelumnya. Jika perlu, keputusan tentang arsitektur atau fungsionalitas diubah. Skenario dibawa ke keadaan alfa dan beta tidak segera, tetapi dalam batch. Sebagai aturan, ada sekitar dua beta dalam siklus rilis.

Setelah tahap beta, tim masuk ke mode pengujian regresi. Pada tahap ini, produk, secara keseluruhan, sudah berfungsi, antarmuka pengguna dan skrip sudah mengeras dan berubah dengan intensitas kurang. Tim penulis teknis ikut bermain. Pada saat yang sama, tim dukungan teknis sedang dilatih.

Pengujian regresi dilakukan dalam siklus dua minggu. Waktu siklus ditentukan oleh waktu yang diperlukan untuk melihat semua skenario produk. Semakin besar produk, semakin banyak skenario dan, karenanya, siklus. Blok kode dideklarasikan sebelum loop terakhir. Ini berarti bahwa hanya perubahan kritis yang akan dilakukan pada produk - dan hanya setelah banyak tinjauan kode. Metode kejam seperti itu diperlukan agar tidak secara tidak sengaja memasukkan cacat baru ke dalam produk.

Semakin dekat momen rilis, semakin banyak waktu luang yang dimiliki pengembang dan semakin sedikit orang lain. Manajer produk perlu menyiapkan siaran pers, mengoordinasikan pekerjaan layanan pemasaran. Penguji harus memeriksa perbaikan dan melakukan pengujian regresi akhir. Penulis teknis menambahkan dokumentasi pengguna. Pada saat yang menguntungkan ini, pengembang sedang mengembangkan kegiatan penelitian untuk persyaratan versi berikutnya.

Dan inilah momen yang menyenangkan, yang disebut RTM - Ready To Market. Ini berarti bahwa produk tersebut sudah siap untuk didistribusikan kepada konsumen. Dalam dua minggu, dia akan disiksa oleh jurnalis, penyedia layanan. Ini akan ditampilkan pada presentasi. Dua minggu kemudian, produk akan tersedia untuk semua orang. Pada saat ini, perubahan internal juga terjadi: cabang-cabang baru pembangunan sedang dipersiapkan, kode sedang disimpan. Dan, tentu saja, infrastruktur pembangunan untuk versi berikutnya naik. Setelah rilis publik (GA), ini adalah waktu yang panas untuk dukungan teknis. Dan sisanya sudah bekerja pada versi berikutnya.

Tentang Prioritas

Dan akhirnya, sedikit perangkat keras. Seperti yang Anda tahu, dalam trinitas "cepat, kualitas tinggi, murah" Anda dapat memilih maksimal dua opsi. Kualitas, waktu, dan fungsionalitas terus-menerus berjuang di antara mereka. Dalam produk kotak kami, kualitas adalah yang utama. Hmm, tapi apa bidang di mana kualitas tidak menjadi masalah? Tentu saja tidak. Seluruh pertanyaannya adalah definisi kualitas.
Bagi kami, kualitas adalah:

• Pelestarian keandalan dan kinerja dalam konfigurasi kebun binatang . Satu klien memiliki pusat data sederhana dari dua server dari waktu Pertempuran Borodino, sementara yang lain memiliki infrastruktur canggih di hanggar terdekat dengan Amazon. Produk harus bekerja secara memadai dalam kedua kasus.
  
• Kemudahan penggunaan . Pengguna harus paling tidak tegang dan tentu saja mengatasi tanpa instruksi. Tetapi kesederhanaan yang serupa masih jauh dari selalu tersembunyi di balik kesederhanaan eksternal - cobalah untuk menyeberang dengan landak.
  
• Warisan Investasi di perusahaan bersifat jangka panjang, dan CFO tidak akan dibelanjakan untuk TI tanpa alasan yang bagus. Jadi, Anda perlu menjaga kompatibilitas dengan versi sebelumnya dan produk terkait. Seringkali selama pembangunan kembali pusat data, server e-mail era 80-an ditembok di dinding. Dan mereka semua berdengung dan tidak berpikir untuk mati.
  

Dengan serangkaian prioritas untuk menjaga kualitas, Anda selalu perlu menggabungkan sesuatu, baik untuk pengembang dan penguji. Perubahan kecil dalam perilaku fungsi dapat menyebabkan pengujian integrasi paksa bagian terbesar dari produk. Coba tambahkan dukungan lokal Asia ke produk dan pahami tentang apa itu. Oleh karena itu, masalah prioritas adalah masalah diskusi bersama PM, penguji dan pengembang.

Prioritas kedua, yang hampir tidak bisa dihancurkan adalah pemilihan waktu. Dalam hal pembaruan, tanggal rilis ditetapkan oleh SLA, dalam kasus rilis besar - oleh kalender bisnis. Menurut statistik, dalam setiap siklus rilis, hampir 50% dari waktu dihabiskan untuk pengembangan, 50% untuk membawa produk ke pikiran (tahap perbaikan bug).

Apa yang bisa berubah adalah fungsi dari rilis berikutnya. Daftar persyaratan yang diprioritaskan, atau jaminan, membantu di sini. Secara teoritis, semuanya sederhana: pilih fungsi prioritas berikutnya dari jaminan, lihat waktu yang tersisa. Ketika waktu mendekati akhir, hentikan dan lepaskan versi produk selanjutnya. Iblis tersembunyi dalam nuansa:

• Ketidakpastian persyaratan . Misalnya, persyaratan "untuk mendukung mencadangkan mesin fisik di OS Linux" dapat disempurnakan lebih lanjut. Inti mana yang harus didukung? Distribusi apa? Sistem file apa? Satu dan persyaratan tingkat tinggi yang sama dapat diimplementasikan dalam satu bulan atau satu tahun. Pertanyaannya selesai.
  
• Tim memiliki spesialisasi . Tidak semua persyaratan dapat diambil oleh tim mana pun. Pengembang C # tidak akan menulis driver, pengembang komponen sistem tidak akan selalu mengatasi pengembangan web.
  
• Persyaratan tergantung satu sama lain . Ini tidak selalu terlihat di tingkat skenario pengguna, tetapi ada hubungan seperti itu di dalam. Dari sudut pandang dunia luar, dukungan cadangan dari sistem file NTFS dan ExtFS mungkin merupakan persyaratan dengan prioritas yang berbeda, tetapi di dalam Anda perlu menulis mesin umum terlebih dahulu.
  
• Persyaratan dibagi menjadi ditangguhkan dan tidak dapat ditangguhkan . Jika pasar menunggu di versi berikutnya untuk beberapa fungsi, dan diumumkan, maka tidak akan berfungsi untuk menundanya.
  
• Bagian dari persyaratan melibatkan penelitian . Tanpa hasil penelitian, mustahil untuk merencanakan kompleksitas tugas (mungkin tidak mungkin sama sekali), dan bisa sulit untuk memprediksi hasil ini.
  

Di sinilah perkembangan tangkas ikut bermain. Bagi kami, pengembangan tangkas berarti kebutuhan untuk pembangunan kembali secara berkala. Keadaan baru diketahui - rencana yang diubah. Menambahkan persyaratan prioritas baru ke dalam jaminan simpanan - rencana yang diubah. Kami tidak punya waktu dengan persyaratan yang tidak tertunda - kami memotong sebagian tugas atau mengubah persyaratan. Dalam teori kontrol teknis, ini disebut sistem umpan balik. Ingat bagaimana autopilot bekerja.

Setiap perencanaan dalam kondisi di atas bergantung pada penilaian ahli. Penilaian pakar tentang pemimpin tim adalah elemen yang membuat seluruh proses selanjutnya jelas dan terstruktur. Nama lain untuk penilaian ahli adalah "metode juling Leninis," seperti yang sering diulangi oleh Alexander Orlov dari Stratoplan. Ini adalah saat Anda mengambil keputusan berdasarkan pengalaman dan intuisi sebelumnya. Meskipun ada kemungkinan kritik, ini berhasil. Ini bekerja seperti semua proses kami yang dijelaskan di atas. Jika Anda masih memiliki pertanyaan tentang mereka, kami mengundang Anda untuk berkomentar.

Apa selanjutnya

Teknologi proses saat ini nyaman dan nyaman seperti sandal rumah. Satu-satunya masalah adalah bahwa di Veeam beberapa penusuk yang tak terlihat selalu membuat Anda: lebih cepat, lebih, lebih, lebih.
Baru-baru ini, kantor percontohan dibangun di Finlandia dan Republik Ceko, dan tahun ini kami sedang mempersiapkan pembukaan pusat Litbang Praha untuk beberapa ratus orang.


Lobi kantor kami di Praha

Kantor pengembangan baru-baru ini muncul di Israel, tim di Kanada dan Jerman tumbuh. Jumlah proyek pengembangan bersama dengan HP, NetApp, Nutanix, EMC meningkat.
Pabrik berubah menjadi conveyor yang didistribusikan secara geografis, dan pada saat yang sama, proses baru mengkristal. Namun, ini adalah topik untuk artikel terpisah.
Tetap terhubung.