Selama lebih dari setahun sekarang, di MyStore, kami telah menciptakan fungsionalitas yang membantu pengguna kami membeli dan menjual barang berlabel. Berita tentang pelabelan telah berkali-kali menyelinap di Habré, begitu singkat: sejak 2019, barang-barang ditandai dengan sendirinya. Tidak semuanya sekaligus, tetapi sekarang Anda perlu memberi label rokok, sepatu, parfum, dan ban mobil. Pada saat yang sama, kami bekerja dalam situasi ketidakpastian ketika API sistem pemerintah terus berubah.
Oleh karena itu, kami hanya memiliki dua cara untuk berintegrasi dengan lembaga pemerintah: tunggu sampai semuanya beres dan ketinggalan kepemimpinan pasar atau kembangkan sistem di dunia dengan persyaratan yang terus berubah.
Kami memilih yang kedua - hanya dalam semangat metodologi yang fleksibel. Saya pikir Agile dapat sangat membantu dalam memecahkan masalah yang diterapkan. Dan kehidupan di dunia dengan tuntutan yang terus berubah adalah bidang di mana Anda bisa berbalik.
Nama saya Maxim Sukharenko, pemimpin tim platform layanan MySklad. Dan hari ini saya akan memberi tahu Anda bagaimana kami bekerja dengan perubahan persyaratan.
Dari Klasik ke Scrum
Batas waktu awal untuk pengembangan sistem oleh otoritas pengawas direncanakan untuk April 2019, tetapi Anda mengerti segalanya. Akibatnya, tenggat waktu dipindahkan ke Oktober. Dan di mana ada tenggat waktu baru, ada persyaratan baru dan format baru. Kami tidak bisa menunggu API diperbaiki - maka kami tidak akan punya waktu untuk mengimplementasikan integrasi. Karena itu, mereka memutuskan untuk "ragu dengan garis partai."
Kami memikirkan pendekatan klasik yang menawarkan kami membuat adaptor untuk sistem eksternal. Lengkapi dengan steker dengan sakelar dan dari waktu ke waktu tarik fungsionalitas steker dan adaptor ke kondisi sistem eksternal saat ini.
Logika menyarankan agar untuk mengembangkan sistem dengan antarmuka yang terus berubah, Anda perlu memperbaiki persyaratan di beberapa titik waktu. Tetapi hanya pada apa? Sampai kita mengembangkan beberapa bagian dari fungsionalitas?
Anda harus mengakui bahwa tidak menyenangkan meninggalkan fungsionalitas yang belum selesai di mana tes tidak lulus, dan juga mulai merusaknya pada yang baru. Anda dapat memperbaiki persyaratan untuk periode pengembangan fitur. Tetapi apa yang harus dilakukan dengan fitur besar yang dapat hidup dalam pengembangan selama beberapa bulan? Sangat tidak mungkin untuk memperbaiki persyaratan untuk jangka waktu yang lama.
Jadi kami beralih ke Scrum. Dia memberi tahu kita bahwa pada akhir sprint, kita harus menyediakan produk yang berfungsi dengan fungsionalitas baru. Tapi bagaimana ini berkelahi dengan memperbaiki persyaratan dan fitur besar? Ada lelucon tentang hal ini:
"Dokter, ketika saya melakukannya seperti ini, itu menyakitkan saya."
"Dan kamu tidak melakukannya seperti itu."
Siapa yang tidak mengerti, jangan membuat fitur besar . Anda dapat memperbaiki persyaratan untuk satu atau dua minggu agar sesuai dengan sprint, dan mengatur implementasi fungsional sesuai dengan persyaratan untuk tujuan sprint. Dan fungsinya harus dikalahkan menjadi beberapa bagian sehingga cocok menjadi satu atau dua sprint. Berpikir terlalu rumit? Dan kemudian! Anda tidak tahu cara memotong tiket. Melihat, Syura, melihat, mereka emas.
Tentu saja, ini tidak begitu sederhana, kita perlu dengan sengaja bergerak menuju hal ini - untuk meninggalkan pengembangan dari "kita akan melakukannya selama enam bulan, maka kita akan meluncurkan versi baru untuk ujian."
Rahasianya adalah memiliki versi stabil di akhir setiap sprint . Tentu saja, ini kelihatannya akan meningkatkan waktu pengembangan karena pertumbuhan biaya overhead untuk stabilisasi cabang dan bahwa pengembangan akan menjadi kurang optimal. Tapi di sini situasinya hampir sama dengan tes, mari kita bicarakan di bawah ini.
Untuk memerangi misi
Dan sekarang untuk situasi nyata. Tugas kami adalah mengonfigurasi enkripsi antara sistem kami dan API sehingga pengguna menandatangani semua permintaan dengan kunci. Saya pikir banyak dari Anda telah menemukan CryptoPro, jadi kami harus melakukannya.
Jika Anda menggunakan pendekatan standar, satu tugas yang terisolasi akan dibentuk - menyiapkan kriptografi untuk layanan. Kami akan menggantungnya di satu orang dan selama sebulan kami akan menghapus status dan membenci mengapa itu tidak akan berakhir dengan cara apa pun. Dan pengembang secara bertahap akan berubah menjadi makhluk liar dari dunia lain, dengan busa di mulut dan mata liar.
Kami memotongnya menjadi tugas-tugas kecil dan tersebar di seluruh tim. Saya membandingkan kriptografi dengan alkohol: bersama dan dalam dosis sedang, itu jauh lebih baik daripada banyak dan sendirian.
Karena kami sedang mengembangkan layanan cloud, lebih mudah bagi kami untuk menggunakan plug-in CryptoPro EDS Browser (ini bukan iklan, ini adalah keputusasaan). Ini memungkinkan CryptoPro CSP untuk memperluas kunci dan metode enkripsi ke halaman web.
Pertama, pengguna memilih kunci yang akan digunakannya dalam bekerja dengan layanan, kemudian otentikasi dilakukan untuk mendapatkan token. Dan hanya dengan bantuan enkripsi dan panggilan API token dibuat. Sepertinya semuanya sederhana (tidak).
Pertama-tama, kami melakukan MVP secara terpisah dari layanan kami - untuk mengonfigurasi interaksi plugin dengan API. Apakah Anda tahu berapa banyak dokumentasi yang ada tentang plugin browser cryptoPro dari produsen? Tidak semuanya! Hanya contoh rekayasa terbalik, hanya hardcore. Tanpa tidur malam dan upaya untuk menentukan apa yang mempengaruhi parameter ini atau lainnya.
Dan hanya pada saat itulah kami dapat mencoba membangunnya ke dalam ekosistem kami. Satu orang membawa penampilan komponen prototipe ke dalam bentuk manusia, yang kedua menghubungkannya dengan logika bisnis, yang ketiga menulis instruksi untuk anak cucu untuk mengkonfigurasinya. Setiap tugas memiliki tujuan tertentu dan relatif terisolasi dari yang lain. Dan orang-orang memiliki sesuatu untuk didiskusikan dan dengan siapa mereka berbagi rasa sakit.
Jadi situasinya menjadi cukup stabil. Dalam iterasi kecil, kami menambahkan fungsionalitas baru, dari waktu ke waktu kami memperbarui antarmuka eksternal dan menyebarkan perubahan jauh ke dalam sistem kami. Tetapi muncul pertanyaan: hidup di cabang terpisah sampai yang terakhir, atau mencoba terus-menerus menjaga fitur kecil di master?
Fungsionalitas pengujian
Saya mengusulkan untuk mencari tahu apa yang harus dilakukan dengan pengujian dan apa yang harus dilakukan jika kita menambahkan integrasi ke proyek langsung.
Mari kita mulai dengan pengujian. Untuk memulainya, kita akan menentukan apa yang dapat kita sebut fungsionalitas yang diuji. Saya mengusulkan untuk menyebutkan fungsional yang lulus tes penerimaan, termasuk yang regresi. Kami hanya akan setuju bahwa kami tidak akan menggunakan hack "tidak ada tes - itu berarti semuanya telah diuji". Kita perlu mempertahankan kode kita di dalam produk, dan semakin banyak cakupan pengujian, semakin baik. Semakin besar persentase otomatisasi pengujian semacam itu, semakin murah setiap iterasi untuk menguji fungsionalitas dan semakin sering dapat dilakukan.
Kami memiliki serangkaian tes penerimaan dan regresi tertentu, beberapa di antaranya otomatis, beberapa diadakan dengan tangan.
Jika kita melakukan pendekatan secara formal, kita harus melakukan pengujian setelah setiap perubahan kode. Misalnya, mereka memecah fitur Anda menjadi enam tiket dan selama proses pengujian ditemukan sepuluh kesalahan. Dan biarkan setiap tes memakan waktu empat jam: otomatis tidak masuk hitungan, tetapi manual hanya membutuhkan empat jam. Ternyata dengan cara kerja dasar dan formal, kita akan menghabiskan 64 jam.
Sekarang mari kita coba untuk menguji bukan setelah setiap perubahan kode, tetapi setelah satu. Logika menunjukkan bahwa kita hanya menghabiskan 32 jam. Dan jika Anda melakukan pengujian hanya setelah mengembangkan fungsionalitas dan setelah memperbaiki semua cacat. Tetapi ini disediakan bahwa semua cacat terisolasi satu sama lain, yang dalam hidup tidak terjadi.
Dalam kehidupan, ternyata setelah pengembangan fungsionalitas, pengujian dilakukan dan gelombang bug pertama dilakukan. Kemudian bug diperbaiki, fungsinya rusak, mereka diuji oleh bug bug. Mereka melakukan tes global kedua, dan gelombang baru bug muncul. Bug ini disembunyikan dan muncul ketika mereka memperbaiki gelombang pertama dan mengubah fungsinya. Dan beberapa kali.
Biasanya Anda mendapatkan tiga hingga lima tes penuh - tergantung pada kompleksitas fungsi dan keterusterangan tangan. Tetapi prosesnya dapat dipercepat lebih - jika Anda mengalahkan fitur kecil.
Misalnya, jika Anda memecah satu fitur dengan pengujian pada empat jam menjadi dua dengan pengujian pada tiga setengah jam, Anda mendapatkan lima jam alih-alih empat. Sepertinya tidak ada untung. Tapi itu memanifestasikan dirinya dalam penurunan kompleksitas fungsi yang dirilis dan penurunan kemungkinan rantai cacat terkait. Akibatnya, iterasi pengujian penuh menjadi kurang.
Tambahkan ke proyek
Sekarang kita akan menganalisis situasi ketika Anda membuat fitur dalam proyek di mana pengembang masih bekerja. Misalkan kita menggunakan konsep kode sumber Cabang Per Fitur (Cabang Per Tiket) yang relatif standar.
Jelas, jumlah biaya untuk mempertahankan relevansi brunch sebanding dengan masa pakainya. Semakin sedikit persimpangan kode dalam tiket saat ini, semakin sedikit masalah yang ada pada merger mereka. Ini secara tidak langsung tergantung pada masa pakainya: semakin banyak waktu berlalu, semakin tinggi kemungkinan tiket terkait akan muncul. Dengan demikian, semakin sedikit brunch hidup, semakin sedikit upaya yang kita habiskan untuk relevansinya.
Masih memahami bagaimana cara meluncurkan fungsionalitas fungsional parsial pada prod. Jawabannya cukup sederhana: seharusnya tidak dapat diakses oleh pengguna. Jika Anda ingin bertanya mengapa Anda harus melakukan ini, Anda dapat mengembalikan beberapa paragraf di atas.
Tampaknya menyimpan kode mati di wizard tidak terlalu baik. Itu benar, tapi dia belum mati. Anda dapat membuat halaman rahasia dengan pena yang akan menyertakan fungsionalitas tersebut. Atau urutan tindakan khusus, yang, seperti telur Paskah dalam gim, akan membawa Anda ke fungsi ini. Selain itu, Anda dapat mengujinya segera.
Tentu saja, ada cara lain untuk menangani variabilitas persyaratan. Dan pendekatan ini memiliki keterbatasan dan ketentuan penggunaan. Seperti yang Anda tahu, masih belum ada peluru perak.