11.6 Memecah Solusi Menjadi Bagian yang Bisa Dikerjakan
Dokumen yang hidup akan menjadi dasar untuk memecah solusi menjadi bagian-bagian yang bisa dikerjakan secara bertahap.
Bayangkan Anda sudah punya solution architecture yang lengkap. Diagram context sudah jelas, komponen sudah terpetakan, trade-off sudah ditulis, dan dokumen terus diperbarui. Sekarang tim engineering mulai bertanya, "Kita mulai dari mana?" Ini pertanyaan yang lebih sulit dari kelihatannya.
Banyak tim menjawab pertanyaan itu dengan membagi fitur berdasarkan modul. Modul A dikerjakan dulu, lalu modul B, lalu modul C. Pendekatan ini sering gagal karena modul tidak pernah benar-benar independen. Modul A mungkin butuh data dari sistem lama yang belum siap. Modul B mungkin bergantung pada API yang belum dibuat di modul A. Akibatnya, tim terus menunggu dan progress terhambat.
Solution architecture yang baik membantu kita memecah solusi dengan cara yang lebih cerdas. Bukan berdasarkan modul, tetapi berdasarkan dependency, mitigasi, data migration, dan readiness.
Langkah pertama adalah mengidentifikasi work package. Work package adalah unit pekerjaan terkecil yang bisa direncanakan, diestimasi, dan diassign. Setiap work package harus punya output yang jelas: sebuah komponen jadi, sebuah integrasi selesai, sebuah data migration tervalidasi. Jangan membuat work package yang terlalu besar karena sulit diestimasi, atau terlalu kecil karena malah bikin overhead tracking.
Berikut adalah contoh definisi work package dalam YAML yang menunjukkan dependency, output, dan kaitannya dengan epic.
work_packages:
- id: wp-001
name: Integrasi API sistem lama
dependency: []
output: API endpoint siap diuji
epic: epic-001
- id: wp-002
name: Mapping data pelanggan
dependency: [wp-001]
output: Skema mapping tervalidasi
epic: epic-001
epics:
- id: epic-001
name: Migrasi data pelanggan
work_packages: [wp-001, wp-002]
Berikut adalah diagram alur yang menunjukkan bagaimana solution architecture dipecah menjadi work package, lalu dikelompokkan ke dalam epic, dengan mempertimbangkan dependency dan output.
Dari work package, kita bisa mengelompokkannya menjadi epic. Epic adalah kumpulan work package yang menghasilkan satu kemampuan bisnis yang berarti. Misalnya, epic "Customer Onboarding" berisi work package untuk registrasi, verifikasi identitas, dan notifikasi. Epic membantu bisnis melihat kapan satu kemampuan akan siap, bukan hanya kapan satu komponen teknis selesai.
Selanjutnya, kita perlu milestone. Milestone adalah titik pemeriksaan yang menandai selesainya satu tahap penting. Milestone tidak harus berupa fitur yang siap dipakai. Bisa berupa "Integrasi dengan sistem legacy selesai diverifikasi" atau "Data migration batch pertama berhasil". Milestone memberi manajemen dan bisnis visibility tanpa harus masuk ke detail teknis.
Yang paling kritis adalah release slice. Release slice adalah potongan solusi yang bisa dirilis ke pengguna dan memberikan nilai, meskipun belum lengkap. Ini berbeda dengan modul. Release slice dipotong secara vertikal: dari antarmuka pengguna hingga database, tetapi hanya untuk satu alur bisnis yang utuh. Misalnya, rilis pertama hanya bisa menangani satu jenis transaksi. Rilis kedua menambah jenis transaksi lain. Setiap rilis sudah bisa dipakai, meskipun belum sempurna.
Terakhir, setiap release slice harus punya verification point. Verification point adalah momen untuk memeriksa apakah potongan solusi yang sudah jadi benar-benar berfungsi seperti yang diharapkan. Bukan hanya unit test engineer, tetapi juga uji coba oleh pengguna, security review, dan operasional readiness. Verification point mencegah kita menumpuk utang yang baru ketahuan di akhir.
Pemecahan seperti ini membutuhkan pemahaman dependency yang jujur. Tim harus mengakui mana yang benar-benar harus selesai dulu, mana yang bisa dikerjakan paralel, dan mana yang masih perlu mitigasi karena risikonya tinggi. Data migration sering menjadi dependency yang paling merepotkan karena butuh persiapan lebih awal. Readiness tim juga perlu dipertimbangkan: jangan menaruh komponen paling rumit di rilis pertama jika tim belum matang.
Dengan pendekatan ini, solution architecture tidak hanya menjadi gambar dan tulisan. Ia menjadi peta jalan yang bisa dieksekusi. Setiap orang tahu apa yang harus dikerjakan minggu ini, kapan satu kemampuan akan siap, dan apa yang harus diperiksa sebelum melangkah ke tahap berikutnya.
Setelah solusi terpecah menjadi bagian-bagian yang bisa dikerjakan, tantangan berikutnya adalah menyusun urutan pengerjaan yang realistis. Tidak semua work package bisa dikerjakan bersamaan. Ada yang harus menunggu, ada yang bisa jalan duluan, dan ada yang perlu dikerjakan lebih awal karena risikonya tinggi.
