Dari ide sampai rilis: empat tahap Feature untuk developer dan agent AI

Mulai dari hasil yang dibutuhkan pengguna

Agent AI bisa menghasilkan banyak pekerjaan dalam waktu singkat: menulis kode, menyusun tes, merapikan dokumentasi. Papan tugas pun mudah penuh. Namun, daftar aktivitas yang panjang belum menjelaskan apakah pengguna sudah mendapatkan fitur yang telah disepakati. Kode bisa selesai sementara aturan akses belum diuji, panduan masih menggambarkan rancangan lama, atau perubahan belum pernah masuk produksi.

Feature sebaiknya mewakili hasil yang dapat diperiksa. “Staf dapat mengajukan penawaran untuk disetujui manajer” lebih berguna sebagai tujuan daripada “agent mengerjakan modul approval”. Kalimat pertama menyebut kemampuan pengguna. Kalimat kedua hanya menyebut kesibukan pelaksana.

Pembahasan aplikasi agentic sebelumnya menempatkan aturan bisnis dan otorisasi di backend. Prinsip yang sama berlaku saat agent membantu membangun aplikasinya: kemampuan menjalankan perintah perlu dibatasi oleh keputusan yang jelas. Artikel ini memakai satu contoh hipotetis, fitur persetujuan penawaran harga. Contoh tersebut bukan laporan implementasi atau hasil pengujian produk nyata.

Satu Feature, empat tanggung jawab

Rencana kerja ini menempatkan satu Feature sebagai induk dengan tepat empat child langsung. Susunannya tetap sederhana:

Feature: persetujuan penawaran harga
├── Analisis
├── Development
├── Documentation
└── Deployment

Keempatnya adalah saudara dalam hierarki, bukan rantai tugas bertingkat. Security review, code review, UAT, dan PR berada di dalam Development sebagai aktivitas beserta buktinya. Membuat semuanya menjadi child tambahan akan mengaburkan empat tanggung jawab utama tadi.

Pada penggunaan Plane yang menjadi acuan aturan ini, Feature ditandai dengan label operasional Feature, bukan properti kategori khusus. Relasi parent-child hanya menunjukkan pengelompokan. Relasi itu tidak otomatis memblokir coding, memeriksa dokumen, atau mengizinkan deployment. Lead tetap mengatur kesiapan dan perpindahan pekerjaan berdasarkan bukti.

Empat tahap juga tidak berarti semua orang harus menunggu secara berurutan. Dokumentasi dapat mulai disusun saat implementasi berjalan. Yang harus berurutan adalah keputusan yang bergantung pada hasil sebelumnya, seperti menerima analisis sebelum mengizinkan Development dimulai. Pohon tugas membantu pembaca melihat tanggung jawab; aturan kerja menentukan kapan tindakan boleh dilakukan.

Analisis menetapkan kesepakatan yang bisa diuji

Analis menyiapkan PRD, yaitu dokumen kebutuhan produk, beserta skenario UAT atau uji penerimaan pengguna. Hasil minimumnya harus menjawab siapa penggunanya, masalah yang diselesaikan, batas lingkup, aturan bisnis, dan kondisi yang dianggap berhasil. Kontrak data, risiko, serta kebutuhan rollout dan rollback ikut dibahas jika memengaruhi rancangan. PRD dan UAT menjadi acuan bersama antara pemilik kebutuhan dan tim pelaksana. Perubahan lingkup atau kriteria penerimaan perlu disepakati kembali.

Untuk contoh penawaran, PRD menetapkan bahwa staf boleh mengajukan draf, sedangkan manajer berwenang menyetujui. Perubahan item atau total setelah approval harus membatalkan persetujuan lama. Pengiriman penawaran kepada pelanggan berada di luar lingkup contoh ini. Batas terakhir mencegah fitur kecil diam-diam mendapat kewenangan tambahan.

UAT menerjemahkan aturan itu menjadi langkah dan hasil yang diharapkan. Staf tanpa wewenang mencoba menyetujui penawaran; backend harus menolak. Manajer menyetujui draf, lalu totalnya berubah; sistem harus meminta persetujuan baru. Percobaan ulang permintaan juga perlu diperiksa agar tidak menghasilkan transaksi ganda.

Lead memverifikasi dan menerima PRD serta UAT sebelum Development masuk Todo. Child baru berawal di Backlog; Analisis pun baru masuk Todo ketika lingkupnya siap. Todo yang sudah disetujui berarti pelaksana boleh mulai bekerja dalam lingkup tersebut tanpa meminta konfirmasi ulang untuk setiap langkah. Status ini tidak memberikan izin merge atau deploy ke produksi.

Development full-stack tetap perlu pemeriksaan independen

Developer menangani antarmuka dan backend sebagai satu pekerjaan full-stack. Pada contoh ini, tombol persetujuan, endpoint, validasi versi draf, dan perubahan status perlu mengikuti kontrak yang sama. Memisahkan semuanya berdasarkan nama agent justru berisiko membuat bagian yang terlihat selesai tidak cocok dengan aturan di belakangnya.

Tanggung jawab yang menyatu tidak menghapus pemeriksaan independen. Developer menulis kode pada branch tugas dan menjalankan tes pengembangan. Sesudah itu, urutannya adalah security review manual disertai eksekusi Semgrep pada kandidat aktual, code review, UAT otomatis di QA melalui SSH, lalu PR. Owner memegang keputusan merge.

Security reviewer memeriksa otorisasi dan jalur data, serta menilai temuan Semgrep. Laporan scan membantu pemeriksaan; ia tidak menggantikan penilaian risiko oleh reviewer. Tool yang belum dijalankan tidak boleh dilaporkan lulus. Code reviewer kemudian memeriksa kesesuaian terhadap PRD, logika, dan kualitas perubahan. Agent pengujian menjalankan skenario UAT yang sudah disiapkan analis.

Bukti review dan tes harus merujuk kandidat perubahan yang sama. Jika PR ditolak, pekerjaan kembali ke coding, lalu mengulang security review beserta Semgrep, code review, UAT, dan pengajuan PR pada kandidat baru. Temuan keamanan juga kembali ke implementasi dan rangkaian gate tersebut. Hasil pada versi lama tidak membuktikan versi baru aman. PR membawa perubahan beserta bukti tersebut, tetapi PR terbuka maupun owner merge belum cukup untuk menyebut Development selesai.

QA membuktikan perilaku, bukan keberadaan server

Dalam contoh ini, UAT perlu memperlihatkan penolakan akses tanpa izin, pembatalan approval setelah revisi, serta keadaan tersimpan setelah percobaan ulang. Catat versi yang diuji, data uji, skenario, hasil aktual, dan batas integrasinya. Screenshot antarmuka membantu, tetapi pemeriksaan status backend tetap diperlukan. Mock layanan pengiriman hanya membuktikan perilaku terhadap mock, bukan keberhasilan mengirim pesan sungguhan.

Pemisahan server QA dapat mengurangi gangguan pengujian terhadap produksi jika akses dan datanya benar-benar dibatasi. SSH dipakai untuk mengeksekusi pengujian pada lingkungan QA yang dituju; gateway AI melayani inferensi, bukan jaringan eksekusi tes. Profil agent juga bukan sandbox sistem operasi. Lokasi proses, aplikasi, dan database uji perlu diperiksa sebelum tes berjalan. Server kedua atau koneksi yang tersedia belum membuktikan UAT lulus, apalagi membuktikan sistem terdistribusi sudah matang.

Jika aplikasi belum tersedia atau tes berhenti karena timeout, laporkan pengujian belum selesai. Lead memerlukan bukti kegagalan dan langkah perbaikan, bukan ringkasan sukses yang ditulis karena sesi agent sudah berakhir.

Documentation dimulai sebelum rilis, dituntaskan sesudahnya

Developer dapat menyusun dokumentasi sambil mengimplementasikan fitur. Untuk penawaran tadi, draf memuat kontrak bagi pengembang, cara staf mengajukan persetujuan, tindakan manajer, batas fitur, dan pesan kesalahan yang mungkin ditemui. Cantumkan versi, konfigurasi yang aman untuk dijelaskan, serta catatan rilis. Analis atau reviewer memvalidasi kesesuaiannya dengan kandidat sebelum review kesiapan deployment.

Fase sebelum rilis ini memberi kesempatan menemukan ketidakcocokan yang mudah luput di kode. Jika panduan meminta staf menekan tombol yang hanya tersedia bagi manajer, ada aturan atau penjelasan yang perlu diperbaiki. Dokumentasi membantu memeriksa apakah alur dapat dipahami pengguna, bukan sekadar menyalin daftar endpoint.

Sesudah deployment terverifikasi, panduan dan knowledge base harus mengikuti perilaku versi yang benar-benar dirilis. Rencana dalam PRD yang belum terimplementasi tidak boleh berubah menjadi jawaban helpdesk. Untuk Feature, pekerjaan user guide, knowledge, dan RAG tetap berada pada fase pascarilis di child Documentation yang sama; tidak ada child kelima.

Acceptance dokumentasi mencakup validasi isi dan langkah penggunaan terhadap versi rilis. Jika ingestion ke indeks produksi termasuk lingkup, tindakan itu memerlukan izin tersendiri dan bukti readback atau pengujian retrieval. Keberadaan file Markdown belum membuktikan knowledge sudah terindeks. Jika ingestion di luar lingkup, tulis batas itu dengan jelas agar penerimaan dokumentasi tidak memberi kesan pekerjaan tambahan sudah dilakukan.

Deployment memerlukan keputusan dan verifikasi sendiri

Sesudah owner merge dan prasyarat siap, child Deployment menampung pekerjaan DevOps. Lead mengatur jadwal, sementara owner memberi persetujuan untuk produksi. DevOps menyiapkan versi yang disetujui, pemeriksaan awal atau preflight, langkah rollout, dan jalan rollback yang aman. Jadwal rilis adalah rencana pelaksanaan, bukan bukti pekerjaan selesai.

Preflight perlu memastikan artefak sesuai dengan kandidat yang disetujui, target lingkungan benar, dan prasyarat rilis terpenuhi. Jika ada migrasi data, cara pemulihannya harus masuk pertimbangan sebelum perubahan dijalankan. Persetujuan atas kode tidak otomatis mengizinkan semua tindakan operasional yang mungkin menyertainya.

Pada contoh penawaran, verifikasi pascadeploy memeriksa bahwa versi yang tepat sudah berjalan dan alur persetujuan berperilaku sesuai harapan di produksi dengan cara yang aman. Bukti perlu menunjukkan hasil yang dibaca kembali, bukan hanya perintah deployment berhasil keluar. DevOps menyerahkan bukti itu untuk acceptance Lead; kegagalan harus ditangani atau di-rollback sesuai keputusan yang berwenang.

Development baru boleh Done setelah deployment terkait terverifikasi. Setelah Documentation menuntaskan lingkup pascarilisnya dan keempat child diterima, Lead dapat menutup parent Feature. Dengan batas ini, kata selesai merujuk software yang sudah dirilis dan diperiksa, bukan hanya kode yang lolos tes lokal.

Sebelum menutup Feature, periksa hasilnya

Pola ini berguna untuk Feature baru atau aktif, bukan alasan memaksa setiap bug dan tugas legacy menjadi Feature. Riwayat pekerjaan yang sudah ditutup juga tidak perlu dibuka ulang hanya agar bentuk papan terlihat seragam. Konsistensi struktur tidak boleh mengorbankan kejujuran catatan.

Untuk menilai satu Feature, pemilik dapat membuka empat child dan menelusuri kesepakatan antara pemilik kebutuhan dan tim pelaksana: apakah PRD dan UAT diterima, apakah kandidat yang sama melewati pemeriksaan, apakah panduan sesuai versi rilis, dan apakah deployment mempunyai bukti pascaverifikasi. Pada contoh tadi, kesepakatannya adalah menyediakan alur persetujuan penawaran yang menghormati hak akses serta perubahan draf.

Jika salah satu bukti belum ada, catat pekerjaan yang masih menunggu beserta penanggung jawabnya. Jangan menutup Feature untuk merapikan papan. Empat tahap memberi pemilik cara memeriksa hasil tanpa harus membaca setiap percakapan agent, sekaligus mempertahankan keputusan manusia pada titik yang memang membutuhkan kewenangannya.