{"id":3947,"date":"2022-02-07T10:08:40","date_gmt":"2022-02-07T10:08:40","guid":{"rendered":"https:\/\/www.cybermedian.com\/id\/?p=3947"},"modified":"2025-02-11T14:45:55","modified_gmt":"2025-02-11T06:45:55","slug":"how-to-write-effective-user-story-with-invest-principles","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/id\/how-to-write-effective-user-story-with-invest-principles\/","title":{"rendered":"Bagaimana Menulis User Story yang Efektif dengan Prinsip INVEST?"},"content":{"rendered":"

Prinsip INVEST untuk Membuat User Stories<\/h3>\n

Selain format yang terstandarisasi dan elemen yang lengkap, sebuah user story<\/a> juga harus mengikuti INVEST<\/strong> prinsip: 1. I<\/strong>independen; 2. N<\/strong>egosiasi; 3. V<\/strong>alutif; 4. E<\/strong>stimasi; 5. S<\/strong>kecil; 6. T<\/strong>etap.<\/p>\n

<\/p>\n

1. Independen<\/strong> \u2013 Penting untuk membuat satu user story seindependen mungkin dari user story lainnya. Mempertahankan independensi antara user story tidak hanya memfasilitasi prioritas dan penyelarasan, membuat perencanaan rilis dan iterasi lebih mudah, memfasilitasi pemahaman, pelacakan, implementasi, pengujian, dan pengiriman yang sering secara independen, tetapi juga membuat ruang lingkup estimasi ukuran user story menjadi lebih jelas dan dengan demikian mengurangi bias estimasi.<\/p>\n

2. Negosiasi<\/strong> \u2013 Konten dari sebuah user story dapat dinegosiasikan; sebuah user story bukanlah kontrak. Sebuah user story hanyalah deskripsi singkat dari user story tanpa banyak detail; detail spesifik dihasilkan selama fase komunikasi. Sebuah user story dengan terlalu banyak detail sebenarnya membatasi pengguna, ide dan komunikasi tim.<\/p>\n

3. Bernilai<\/strong> \u2013 Setiap cerita harus bernilai bagi pelanggan (apakah itu pengguna, pembeli, atau peran internal perusahaan). User stories bernilai bagi pengguna akhir, jadi mereka harus ditulis dari perspektif pengguna, menggambarkan FITUR daripada TUGAS.<\/p>\n

Fitur ini memfasilitasi pergeseran dari gaya kerja berbasis arahan tradisional ke gaya kerja yang berorientasi nilai yang dipimpin sendiri bagi anggota pengembangan dan pengujian tim, sehingga setiap orang di tim mengetahui nilai dari pekerjaan yang mereka lakukan setiap hari.<\/p>\n

4. Dapat diestimasi<\/strong> (dapat dievaluasi) \u2013 Bagian yang sangat penting dalam rapat perencanaan adalah estimasi poin cerita. Ini sebenarnya adalah estimasi kasar dari User Story yang akan dikembangkan sehingga tim dapat mengetahui kompleksitas (beban kerja) dari user story ini.<\/p>\n

Fokusnya adalah pada apakah user story dapat diselesaikan dalam iterasi saat ini sesuai dengan kondisi penerimaan dari user story tersebut dan DoD (kriteria penyelesaian) yang ditentukan oleh tim, dan jika tidak dapat diselesaikan, alasannya diberikan dan PO memutuskan apakah akan membagi atau merancang ulang user story.<\/p>\n

Masalah yang membuat sulit bagi pengembang untuk memperkirakan cerita berasal dari: kurangnya pengetahuan tentang domain (dalam hal ini lebih banyak komunikasi diperlukan), atau cerita terlalu besar (dalam hal ini perlu dipotong menjadi bagian yang lebih kecil).<\/p>\n

5.Kecil<\/strong> \u2013 Sebuah cerita yang baik harus sesingkat mungkin dalam hal beban kerja, sebaiknya tidak lebih dari 10 orang ideal\/hari, setidaknya untuk memastikan bahwa itu diselesaikan dalam satu iterasi. Semakin besar user story, semakin besar risikonya dalam penjadwalan, estimasi beban kerja, dll.<\/p>\n

6. Dapat diuji<\/strong> (dapat diuji) \u2013 Sebuah user story harus dapat diuji untuk mengonfirmasi bahwa itu dapat diselesaikan. Jika sebuah user story tidak dapat diuji, maka Anda tidak dapat mengetahui kapan itu akan diselesaikan. Contoh user story yang tidak dapat diuji: perangkat lunak harus mudah digunakan.<\/p>\n

Tiga Pedoman<\/h3>\n

Sebuah user story pada dasarnya adalah user story yang baik ketika prinsip INVEST diikuti. Kemudian kita fokus pada tiga pedoman untuk membantu mematuhi prinsip-prinsip tersebut saat menghasilkan user stories.<\/p>\n

Tiga pedoman tersebut adalah: satu pengguna, nilai lengkap, dan tanpa ketergantungan.<\/p>\n

Satu Tipe Pengguna<\/strong> \u2013 Sertakan hanya satu tipe pengguna, karena banyak pengguna sering memiliki nuansa. Biasanya ini adalah pengguna tipikal, sering dengan kebutuhan umum dari suatu jenis.<\/p>\n

Nilai Lengkap<\/strong> \u2013 Sampaikan nilai pelanggan secara utuh. Sebuah user story yang lengkap berarti bahwa ketika cerita ini selesai, pengguna dapat mencapai tujuan yang jelas dan berarti.<\/p>\n

Non-dependency<\/strong> \u2013 Tiga jenis ketergantungan yang umum adalah: tumpang tindih, urutan, dan pengandungan.<\/p>\n

Secara umum, titik fungsional yang tumpang tindih antara cerita harus dihindari; hubungan berurutan adalah kenyataan dan dapat diselesaikan dengan beberapa cara dalam kebanyakan kasus; dan hubungan inklusi bermanfaat untuk sistem kompleks, dengan implikasi untuk penjadwalan rilis dan rencana iterasi yang perlu diperhatikan.<\/p>\n

Ketergantungan yang tumpang tindih<\/strong><\/p>\n

Ketergantungan yang tumpang tindih adalah bentuk ketergantungan yang paling bermasalah, terutama ketika beberapa cerita pengguna mengandung beberapa bagian tumpang tindih yang berbeda. Sulit untuk menemukan satu set cerita pengguna yang dapat mewakili set fitur untuk produk minimum yang layak, yang seharusnya mengandung dan hanya mengandung fitur yang dibutuhkan sekali.<\/p>\n

Solusi<\/strong><\/p>\n

Pisahkan bagian yang tumpang tindih sebagai cerita pengguna terpisah.
\nPembagian rasional cerita pengguna dan menjaga tumpang tindih hanya dalam satu cerita pengguna yang paling kohesif.
\nGunakan model pengembangan Scrum.<\/p>\n

Ketergantungan Berurutan<\/strong><\/p>\n

Ketergantungan berurutan berarti bahwa agar sebuah cerita pengguna dapat diselesaikan, satu atau lebih cerita pengguna lainnya harus diselesaikan terlebih dahulu. Ketergantungan berurutan biasanya tidak berbahaya, dan ada cara untuk mengurangi ketergantungan tersebut.<\/p>\n

Dari perspektif pengembangan agile, seluruh sistem berkembang secara bertahap dari produk minimum yang layak awalnya menjadi produk yang kuat, dengan setiap langkah berikutnya dibangun di atas langkah sebelumnya.<\/p>\n

Tetapi dari perspektif lain, ketergantungan berurutan yang tidak perlu membuat lebih sulit untuk mengurutkan dan memprioritaskan, yang pada gilirannya mempengaruhi pengembangan rencana rilis dan iterasi serta membuat lebih sulit untuk memperkirakan ukuran cerita pengguna.<\/p>\n

Solusi<\/strong><\/p>\n

Buat cerita pengguna dalam sebuah iterasi se bebas mungkin dari ketergantungan intrinsik.
\nMenjaga hanya ketergantungan satu arah antara iterasi, dengan hanya ketergantungan satu arah dalam waktu dari cerita di iterasi yang lebih baru ke cerita di iterasi yang lebih awal (ketergantungan maju).
\nMenghapus ketergantungan inti sebagai cerita terpisah dan tidak mencampur persyaratan yang bergantung dan tidak bergantung dalam satu cerita.<\/p>\n

Inklusi ketergantungan<\/strong><\/p>\n

Ketergantungan yang terkontrol mengacu pada penggunaan manajemen hierarkis dalam mengorganisir cerita pengguna, seperti manajemen fitur-cerita dua tingkat yang umum, di mana sebuah fitur mengandung beberapa cerita pengguna, sehingga membentuk ketergantungan yang terkontrol dari fitur pada cerita bawahannya.<\/p>\n

Solusi<\/strong><\/p>\n

Tingkat cerita pengguna digunakan untuk perencanaan iterasi, menghindari perencanaan iterasi yang kasar dengan tingkat fitur, yang dapat digunakan untuk perencanaan rilis.<\/p>\n

Tingkat fitur juga dapat dibagi hingga mencapai tingkat fitur yang dapat dipasarkan minimum, dan cerita pengguna yang terkandung di dalamnya dapat dikelompokkan secara terpisah ke dalam fitur yang baru dibagi.<\/p>\n

Mengikuti konsep produk minimum yang layak, sebuah fitur diimplementasikan dalam beberapa iterasi dari beberapa cerita pengguna, masing-masing dapat menghasilkan hasil yang potensial atau memberikan umpan balik internal atau eksternal.<\/p>\n

\u00a0<\/p>\n

Referensi<\/p>\n