Nama saya Victor, saya seorang analis sistem di Sportmaster. Dan hari ini saya ingin berbicara tentang penguraian tugas dan mentransfernya ke pengembangan. Objek apa pun terdiri dari bagian-bagian, baik itu mobil atau produk perangkat lunak. Dan akan membutuhkan waktu untuk merakit objek-objek ini menjadi satu kesatuan dari bagian-bagian komponennya. Terkadang bahkan sangat memakan waktu. Apalagi jika sebelumnya Anda tidak hanya membongkar bagian utama, tetapi memutuskan untuk sampai ke dasarnya di tingkat atom.
Di manakah garis antara pengaturan tugas yang memadai dan kekacauan total? Saya akan membagikan contoh bagaimana kami di Sportmaster secara berkala menerima tugas pengembangan dari bisnis.
Seperti yang dapat Anda lihat dari contoh di atas, deskripsi setiap tugas sangat bergantung pada imajinasi dan akal sehat pelanggan. Di suatu tempat itu lebih banyak, di suatu tempat itu lebih sedikit, tetapi analis perlu bekerja dengannya entah bagaimana. Terkadang mereka juga menunjukkan batasan fungsionalitas, dan terkadang mereka hanya mengirim topik. Jika kita mentransfer tugas seperti itu langsung ke pengembangan, kita akan mendapatkan sesuatu yang tidak dapat dipahami pada hasilnya. Apa yang harus Anda lakukan?
Berjalanlah ke pelanggan dengan kaki Anda dan tanyakan semua persyaratan, klarifikasi apa yang seharusnya ada di pintu keluar. Benar, ada juga pelanggan emas, yang sebenarnya adalah mayoritas - mereka menulis semua persyaratan di Confluence mereka, sehingga Anda dapat pergi dan membacanya kapan saja dan mengajukan pertanyaan. Dan ketika semuanya sudah jelas dengan kerangka fitur, Anda dapat mulai memotong tugas.
Mengapa membusuk
Tujuan utama dekomposisi adalah agar bisnis dapat dengan cepat menerapkan semua keinginannya, dan agar pengguna membutuhkan waktu sesedikit mungkin dari ide itu sendiri hingga tampilan fungsionalitasnya. Untuk melakukan ini, Anda dapat melakukan tugas-tugas yang lebih kecil, dari mana, meskipun kecil, tetapi fungsionalitas yang berfungsi akan menjangkau pengguna.
Selain mencapai tujuan global untuk memenuhi kebutuhan pengguna dan bisnis, dekomposisi tugas memungkinkan Anda mendapatkan umpan balik yang lebih cepat dari pelanggan, baik pengembangan sedang menggali ke arah yang benar, atau ternyata tidak seperti yang dibayangkan pelanggan.
Jika tugas awalnya besar dan kami mengerjakannya seluruhnya sekaligus, maka kami akan menghabiskan banyak waktu untuk itu dan setelah komentar pelanggan kami harus membuang semuanya. Nah, jika tugasnya kecil, satu atau dua hari kerja paling banyak, - tidak apa-apa. Pengerjaan ulang akan memakan waktu kurang lebih sama. Pendekatan kedua juga lebih murah. Belum lagi saraf yang disimpan di kedua sisi.
Jika satu fungsionalitas dibagi menjadi beberapa bagian, pengembang dapat mengerjakannya secara paralel. Dengan demikian, kami akan memparalelkan aliran dan mempercepat output dari fungsionalitas di prod. Yang penting adalah bahwa tugas harus saling bergantung sesedikit mungkin.
Ditambah pengujian cepat dan perbaikan bug. Sekali lagi, fungsionalitas kecil jauh lebih mudah dan lebih cepat untuk diuji daripada raksasa raksasa. Dan jika terjadi kesalahan, pengembang akan menghabiskan sedikit uang untuk "memperbaiki", dan semuanya akan bekerja lebih cepat.
Pada tahap penguraian tugas, bersama dengan pelanggan, Anda dapat segera memahami fungsionalitas mana yang penting saat ini juga, untuk mulai menghasilkan keuntungan, apa yang tersisa untuk nanti, dan apa, mungkin, akan dianggap tidak diperlukan.
Penting bagi bisnis untuk mengetahui seberapa cepat fungsi yang berfungsi akan muncul. Dan ketika dipecah menjadi beberapa tugas, kami dapat memprediksi dan memperkirakan dengan lebih akurat waktu yang dibutuhkan untuk menyelesaikannya daripada saat Anda memiliki pekerjaan yang besar. Tetapi selain fakta bahwa tugas-tugas kecil lebih mudah dinilai dalam hal waktu untuk menyelesaikannya, juga lebih mudah bagi pengembang untuk menilai risiko yang mungkin timbul dalam proses tersebut.
Misalnya, kerangka kerja diperbarui, beberapa metode dikeluarkan dari layanan, masalah dengan kode, dan sebagainya. Dengan melakukan tugas-tugas kecil ke dalam pekerjaan, kami meminimalkan semua risiko ini, dan bahkan jika tugas semacam itu memblokir sesuatu di utas, itu tidak akan sepenting jika itu adalah bagian yang besar dan kuat (yang akan memblokir semuanya). Jika perlu, akan memungkinkan untuk membuat solusi yang berfungsi dan menempatkan hutang teknis di simpanan, yang dapat ditangani nanti, ketika masalah teratasi.
Pendekatan dasar dan aturan dekomposisi
Ada dua pendekatan utama untuk tugas dekomposisi - horizontal dan vertikal. Dengan horizontal, tugas dibagi berdasarkan jenis pekerjaan, tingkat, atau komponen. Misalnya, kami memiliki setiap tugas melalui beberapa tahap: front-end, back-end, database. Dan dengan pendekatan horizontal, satu tugas ke belakang, yang kedua ke depan, dan yang ketiga mengarah ke perubahan dalam database.
Mengapa pendekatan ini buruk? Kami tidak mendapatkan fungsionalitas yang berfungsi setelah menyelesaikan setiap tugas individu. Hanya dengan mengumpulkan hasil dari tiga sumber, kita bisa mendapatkan semacam hasil dan umpan balik. Karena alasan ini, dekomposisi horizontal paling sering tidak digunakan.
Jauh lebih nyaman adalah pendekatan vertikal, di mana fungsionalitas visual dapat dibuat di setiap tugas - tugas melewati semua tahapan dan hasilnya adalah hasil yang dapat dianalisis, diuji, ditampilkan kepada pelanggan dan dikoreksi, jika perlu. Dan segera mulai dan gunakan.
Jika kita berbicara tentang aturan, di sini saya hanya mengidentifikasi tiga. Pertama, tugas harus diselesaikan secara logis, yaitu mandiri. Ini seharusnya tidak merusak logika di sekitarnya dan harus membawa setidaknya beberapa naluri bisnis yang akan diterima pengguna sebagai hasilnya. Pada saat yang sama, Anda tidak boleh memecah menjadi beberapa bagian tugas-tugas yang tidak membawa naluri bisnis (idealnya, tugas tersebut tidak boleh ada sama sekali).
Kedua, hasil dari menyelesaikan satu tugas kecil harus membawa perubahan kecil. Semakin kecil perubahannya, semakin cepat mereka masuk ke dalam kode umum, dan dengan demikian kode tersebut tidak menjadi usang. Selain itu, tugas-tugas kecil membantu menghindari konflik antar pengembang saat menggabungkan.
Ketiga, Anda tidak boleh memecah tugas menjadi bagian yang sangat mikroskopis. Jika dipecah terlalu kecil, akan membutuhkan waktu yang sangat lama untuk mengelola tugas tersebut. Pada setiap tahap, mereka mungkin harus diprioritaskan kembali, dependensi ditempel ulang, dan itu saja. Dengan demikian, kecepatan pengembangan tidak akan meningkat, tetapi sebaliknya akan menurun tajam. Oleh karena itu, Anda perlu mencari jalan tengah.
Metode dekomposisi
Bergantung pada sumbernya, jumlah metode dekomposisi sangat bervariasi: di mana mereka hanya ditunjukkan oleh delapan, sepuluh, dua puluh. Saya ingin fokus pada cara-cara yang harus saya gunakan setiap hari di tempat kerja.
Berbagai kebutuhan
Metode ini paling nyaman digunakan jika ada kata sambung "dan", "atau" dalam cerita. Misalnya, konsumen ingin memesan dan membayar dengan kartu atau bonus. Tugas ini dapat dibagi menjadi tiga: yang pertama, di mana pengguna melakukan pemesanan, yang kedua, di mana dia membayar dengan kartunya, dan yang ketiga, di mana bonus digunakan.
Skenario penggunaan
Cara umum lainnya adalah membagi tugas tergantung pada kasus penggunaan. Dalam hal ini, satu cerita adalah satu jalur utama dan beberapa jalur alternatif. Katakanlah seorang pengguna ingin membeli sebuah barang, dan itu akan menjadi skenario utama. Tetapi masih ada cara alternatif - dia mungkin langsung memasukkan produk ke dalam keranjang dan membayar, atau dia mungkin ingin membandingkan produk ini dengan yang lain sebelum membeli. Dan kemudian kami membuat perbandingan produk sebagai tugas terpisah.
Mungkin dia tidak ingin membeli sekarang, tetapi menundanya di suatu tempat, menambah favorit, sehingga dia dapat kembali lagi nanti. Atau pengguna menyukai produk dan siap untuk membelinya, tetapi stoknya habis. Jadi, Anda perlu memberi tahu dia kapan barang itu akan muncul. Dan inilah hasil dari empat skenario.
Dari yang sederhana sampai yang rumit
Halaman utama dari situs "Sportmaster" terdiri dari spanduk. Dan hal paling sederhana yang dapat kami lakukan adalah mengambil satu gambar dan menunjukkannya kepada pengguna. Ini adalah cara termudah dan tercepat untuk menyampaikan informasi yang benar. Kemudian kita dapat meningkatkan fungsionalitas dan menambahkan bukan hanya satu gambar, tetapi tiga atau empat, yang digabungkan menjadi sebuah kisi. Ini adalah tugas terpisah.
Dengan pendekatan ini, dengan setiap tugas berikutnya, fungsinya harus berkembang. Misalnya, kita dapat membuat carousel dari grid, lalu menambahkan beberapa link, teks, tombol, dan lainnya. Secara umum, pertama-tama kami menerapkan versi yang paling sederhana dan berperforma tercepat, lalu melanjutkan ke versi yang lebih kompleks.
Baru-baru ini saya terlibat dalam tugas serupa untuk mengimplementasikan spanduk. Spanduk seharusnya digantung di spanduk utama dan dikontrol dari CMS. Jika Anda bertanya kepada pelanggan apa sebenarnya yang ingin dia kelola, dia, tanpa berkedip, dengan senang hati akan menjawab - semuanya. Oleh karena itu, penting di sini untuk sedikit menyelami topik dan menyoroti apa yang perlu dikelola sekarang, apa yang sering, dan apa yang hampir tidak pernah digunakan sama sekali. Dan dengan demikian, prioritaskan implementasi dan bagi menjadi tugas.
Operasi (CRUD)
Ini mungkin cara dekomposisi yang paling umum. Di sini, tugas dibagi menjadi operasi Buat, Baca, Perbarui, dan Hapus. Ini cocok untuk tugas-tugas di mana Anda perlu mengelola sesuatu atau mengkonfigurasi sesuatu. Misalnya, tugas menempatkan pesanan dibagi menjadi empat pesanan yang lebih kecil: membuat pesanan, melihatnya, mengeditnya, dan menghapusnya.
Opsi antarmuka
Digunakan ketika beberapa opsi antarmuka perlu didukung. Misalnya, situs harus mendukung banyak bahasa. Pertama, kami membuat versi Rusia. Kemudian, saat meluncurkan di negara lain, kami menambahkan bahasa Inggris. Jika negara menggunakan bahasa selain bahasa Inggris, maka kami dapat menambahkannya juga. Dalam hal ini, lebih mudah untuk melakukan semuanya terlebih dahulu dalam satu bahasa, lalu menambahkan terjemahan secara bertahap.
Baru-baru ini, kami menyelesaikan proyek untuk akun pribadi untuk badan hukum, yang membutuhkan dukungan multibahasa. Tenggat waktunya ketat, jadi mereka awalnya melakukan semuanya dalam satu bahasa, tetapi meletakkan dasar untuk terjemahan lebih lanjut. Sekarang, menambahkan dukungan untuk bahasa baru hanya membutuhkan satu tugas kecil. Jika Anda perlu menambahkan beberapa bahasa sekaligus, tugas terpisah dibuat untuk masing-masing bahasa.
Pemisahan berdasarkan peran
Cocok untuk situasi di mana fungsionalitas menyiratkan pengoperasian beberapa peran dan grup pengguna. Di situs Sportmaster, pengguna dapat memiliki peran berbeda. Misalnya, pengguna dibagi menurut peran menjadi pengguna yang sah, pengguna anonim, dan, katakanlah, pengguna pusat panggilan. Peran terakhir juga dapat dibagi menjadi dua - dapat berupa pengguna biasa atau administrator.
Untuk setiap peran, kita dapat membuat tugas terpisah. Mulailah dengan menampilkan untuk pengguna anonim dan kemudian menambahkan beberapa fungsionalitas tingkat lanjut sebagai bagian dari tugas untuk pengguna yang berwenang. Dan jangan lupa tentang peran teknis operator pusat panggilan dan fungsionalitasnya.
Pemrosesan kesalahan
Jika tenggat waktu ketat, dan fungsionalitas minimum diperlukan secepat mungkin, Anda dapat menangani kesalahan dalam tugas terpisah. Di sini kita tidak berbicara tentang menulis tes, tetapi tentang menangani kesalahan pengguna dan sistem yang terintegrasi dengan situs. Katakanlah kita sedang memproses halaman katalog yang berisi ubin produk. Setiap kartu memiliki deskripsi, foto, dan informasi tambahan.
Kebetulan beberapa informasi tidak berasal dari database.
Mungkin, jika kita berbicara tentang merek atau bahan, maka ini bisa diabaikan dan tidak ditampilkan informasi. Tetapi jika harga atau nama tidak muncul, apakah layak untuk menunjukkan kartu ini?
Apa yang harus dilakukan dalam situasi seperti ini? Pertanyaan ini dapat diambil dalam tugas terpisah dan kemudian memproses setiap bidang terpisah. Artinya, jika harga tidak kunjung datang, maka kita melakukan satu tindakan, keterangan produk hilang - lain. Itu sama dengan kesalahan pengguna. Jika dia memasukkan sesuatu yang salah dan kesalahan ditampilkan, misalnya, "Halaman tidak ditemukan" atau kesalahan 500, kita harus menunjukkan kepadanya informasi spesifik tentang apa yang terjadi dan menawarkan skrip apa yang dapat dia lakukan selanjutnya.
Metode ini juga cocok untuk situasi di mana Anda perlu dengan cepat mendapatkan umpan balik tentang fungsionalitas untuk memutuskan apakah akan menyimpannya atau tidak.
Statis lalu dinamis
Ini adalah salah satu cara favorit saya. Cocok dalam situasi di mana dimungkinkan untuk mengimplementasikan fungsionalitas "pada rintisan", yaitu, sistem eksternal belum siap untuk mendukung fungsionalitas tersebut. Misalnya, beberapa pemblokiran di halaman utama tidak dapat dikontrol dari CMS. Atau menu, ketika kami membuatnya dalam kode kami dan menampilkannya kepada pengguna, tetapi pada saat yang sama tidak dapat dikontrol oleh bisnis. Dan untuk membuat perubahan, bisnis perlu terus berkembang dan meminta untuk melakukannya.
Di sini, kami memprioritaskan kebutuhan dan keuntungan pengguna. Pengguna segera menerima fungsionalitas siap pakai, meskipun kami mungkin mengalami beberapa ketidaknyamanan di dalamnya. Oleh karena itu, kami membagi tugas menjadi beberapa dan pertama-tama membuat blok baru tersedia untuk pengguna, tetapi bisnis belum dapat mengelolanya secara langsung. Tetapi kemudian kita dapat berintegrasi dengan beberapa sistem atau database, di mana bisnis itu sendiri dapat menukar item dan menambahkan item baru sendiri, dan kita akan menariknya tanpa partisipasi pengembangan.
Kami sering menggunakan metode ini: pertama, kami membuat fungsionalitas pada data kami sendiri, yang tidak dapat dikontrol dari luar, lalu kami menambahkan dinamika dan mulai menerima data dari sistem pihak ketiga.
Performa
Jika tugas secara keseluruhan rumit dan banyak, tidak jelas dari ujung mana harus menanganinya, maka kinerja dapat diabaikan. Tugas pertama adalah menghadirkan fungsionalitas yang sudah jadi, yang entah bagaimana, meskipun lambat, tetapi berfungsi. Dan tugas selanjutnya adalah mempercepat pekerjaan. Misalnya, ini bisa menjadi pekerjaan yang lambat dalam mencari barang, menerapkan filter, mendapatkan informasi apa pun.
Terkadang sebagian besar upaya diinvestasikan untuk membuat fungsi dengan cepat - implementasi awalnya tidak begitu sulit. Namun Anda dapat belajar banyak dari penerapan yang lambat, ditambah lagi memiliki beberapa nilai bagi pengguna yang jika tidak, tidak akan dapat melakukan beberapa tindakan penting. Dalam semua kasus ini, tugas dipecah menjadi "membuatnya berhasil" dan "membuatnya cepat".
Kesulitan yang mungkin terjadi
Jika Anda memutuskan untuk menggunakan dekomposisi tugas dalam proyek Anda, kemungkinan besar kesulitan pertama yang akan Anda hadapi adalah ketergantungan tugas satu sama lain. Menurut pengalaman saya, ini adalah masalah pemblokiran thread yang paling umum. Untuk menghindari hal ini, dekomposisi harus dilakukan secara bertanggung jawab dan diberikan waktu yang cukup.
Kesulitan lainnya adalah menentukan seberapa baik Anda perlu menguraikan tugas. Dan di sini hanya akal sehat yang bertindak sebagai batasan. Misalnya kita ambil komponen pemilihan kota. Ini memiliki tombol, beberapa teks, bidang input. Seberapa kecil Anda harus menyelesaikan tugas ini?
Kami telah menyimpulkan aturan untuk diri kami sendiri bahwa tugas harus dilakukan di sepanjang alur tidak lebih dari satu minggu (sekitar 40 jam). Kita berbicara tentang semua tahapan: tahap analitik, pengembangan, pengujian. Plus, dua tahap pengembangan backend dan frontend diperhitungkan, termasuk peninjauan dan pengujian di masing-masing.
Kami juga bermasalah dengan fakta bahwa batas-batas epik tidak selalu jelas. Baru-baru ini kami diberi tugas untuk melakukan pemesanan. Dimana perbatasannya? Apa yang seharusnya menjadi keluarannya? Tidak jelas bagi kami apakah kami perlu melakukan semua fungsi sampai akhir, atau memilih beberapa bagian. Apakah epik ini termasuk pembayaran, atau sudah menjadi epik tersendiri.
Ada tugas yang sulit dipahami bagaimana cara membusuk dan kapan. Kami menguraikan sebagian besar tugas pada tahap menerima epik, tetapi ada situasi ketika ini perlu dilakukan, misalnya, pada tahap analitik. Kami mengambil tugas untuk bekerja dan percaya bahwa semua data yang diperlukan sudah ada di sistem integrasi kami, tetapi selama analisis ternyata kami tidak puas dengan format datanya, atau masalahnya ada pada kualitas data itu sendiri, atau diperlukan peningkatan dari sistem lain yang dengannya kita terhubung. Kemudian kita harus melakukan tugas "on stubs" dan menambahkan item lain ke backlog, yang akan kita mulai setelah kita menyelesaikan masalah utama.
Sepertinya itu saja. Akan sangat bagus jika Anda berbagi cerita tentang pendekatan dekomposisi tugas yang Anda gunakan dan mengapa di komentar.
Terima kasih sudah membaca!