Hubungan antara kisah pengguna, fitur, dan epik?

Sebagai seseorang yang masih baru untuk gesit, saya tidak yakin saya sepenuhnya memahami hubungan atau perbedaan antara kisah pengguna, fitur, dan epik.

Menurut pertanyaan ini , fitur adalah kumpulan cerita. Salah satu jawaban menunjukkan bahwa fitur sebenarnya epik. Jadi, apakah fitur dan epos dianggap hal yang sama, yang pada dasarnya merupakan kumpulan cerita pengguna terkait?

Manajer proyek kami menegaskan bahwa ada struktur hierarkis:

Epik -> Fitur -> Cerita pengguna

Dan pada dasarnya semua cerita pengguna harus termasuk dalam struktur ini. Oleh karena itu semua kisah pengguna harus berada di bawah fitur payung dan semua fitur harus berada di bawah epik.

Bagi saya, itu terdengar aneh. Adakah yang bisa menjelaskan bagaimana cerita pengguna, fitur, dan epik terkait? Atau adakah artikel yang jelas menguraikan perbedaannya?

Mereka sebenarnya istilah yang sangat umum. Ada banyak cara untuk menafsirkannya, beragam dalam literatur dan bagaimana orang melihatnya. Ambil semua yang saya katakan dengan sebutir garam besar.

Biasanya, sebuah Epic terdiri dari fungsionalitas yang sangat global dan tidak terdefinisi dengan baik dalam perangkat lunak Anda. Ini sangat luas. Biasanya akan dipecah menjadi cerita atau fitur pengguna yang lebih kecil ketika Anda mencoba memahaminya dan membuatnya sesuai dengan iterasi yang gesit. Contoh:

Epik
- Izinkan pelanggan untuk mengelola akunnya sendiri melalui Web

Fitur dan Kisah Pengguna adalah fungsi yang lebih spesifik, yang dapat Anda uji dengan mudah dengan tes penerimaan. Sering direkomendasikan bahwa mereka cukup granular untuk muat dalam satu iterasi tunggal.

Fitur biasanya cenderung menggambarkan apa yang dilakukan perangkat lunak Anda:

Fitur
- Mengedit informasi pelanggan melalui portal web

Kisah pengguna cenderung mengungkapkan apa yang ingin dilakukan pengguna:

Kisah pengguna
Sebagai petugas bank,
saya ingin dapat mengubah informasi pelanggan
sehingga saya dapat tetap mendapatkan informasi terbaru.

Saya tidak berpikir ada benar-benar hirarki di antara keduanya, tetapi Anda dapat memilikinya jika Anda inginkan atau apakah itu sesuai dengan cara Anda bekerja. Cerita pengguna dapat menjadi justifikasi khusus untuk suatu fitur, atau cara spesifik untuk melakukannya. Atau bisa juga sebaliknya. Fitur dapat menjadi cara untuk mewujudkan cerita pengguna. Atau mereka dapat menunjukkan hal yang sama. Anda dapat menggunakan keduanya: Kisah pengguna untuk menentukan apa yang membawa nilai dan fitur bisnis untuk menggambarkan kendala perangkat lunak.

Kisah pengguna : sebagai pelanggan, saya ingin membayar dengan kartu kredit paling populer.
Fitur mendukung GOV-TAX-02 XML API pemerintah.

Ada juga pertanyaan tentang skenario, yang biasanya merupakan cara kisah Fitur / Pengguna akan dieksekusi. Mereka biasanya memetakan secara bersih ke tes penerimaan tertentu. Sebagai contoh

Skenario : Penarikan uang
Mengingat saya memiliki $ 2.000 di rekening bank saya
Ketika saya menarik $ 100
Kemudian saya menerima $ 100 tunai
dan saldo saya $ 1900

Itulah cara kami mendefinisikan istilah tempat saya bekerja . Definisi-definisi tersebut jauh dari definisi matematika atau istilah standar. Ini seperti perbedaan antara politisi sayap kanan atau politisi sayap kiri. Itu tergantung di mana Anda tinggal. Di Kanada, apa yang dianggap sebagai sayap kanan dapat dianggap sebagai sayap kiri di Amerika Serikat. Sangat bervariasi.

Serius, saya tidak akan terlalu khawatir tentang hal itu. Yang penting adalah bahwa semua orang di tim menyetujui definisi sehingga Anda dapat saling memahami. Beberapa metode seperti scrum cenderung mendefinisikannya secara lebih formal, tetapi pilihlah yang cocok untuk Anda dan tinggalkan sisanya. Lagi pula, bukankah lincah tentang Individu dan interaksi atas proses dan alat dan perangkat lunak yang Bekerja lebih dari dokumentasi yang komprehensif ?

Epik : Kisah pengguna yang sangat besar yang akhirnya dipecah menjadi cerita yang lebih kecil.

Kisah pengguna: Definisi persyaratan yang sangat tinggi, berisi informasi yang cukup sehingga pengembang dapat menghasilkan perkiraan yang wajar dari upaya untuk mengimplementasikannya.

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

Fitur : Karakteristik atau kemampuan yang membedakan aplikasi perangkat lunak atau perpustakaan (misalnya, kinerja, portabilitas, atau fungsionalitas).

http://en.wikipedia.org/wiki/Software_feature

Saya memperingatkan Anda agar tidak menerapkan hierarki yang terlalu kaku pada persyaratan ini. Kami mencoba melakukan itu di pekerjaan saya sebelumnya. Dua kali. Kedua upaya itu berbeda dan kedua kali kami mendapati diri kami tidak perlu membatasi diri. Satu-satunya yang konstan adalah definisi Cerita Pengguna . Dari perspektif perencanaan, sebuah cerita adalah blok bangunan dasar sebuah proyek. Istilah yang lebih besar (epik, fitur, dll.) Secara efektif hanya berupa tag . Tag adalah cara mudah untuk memungkinkan cerita ada sebagai bagian dari beberapa Epics dan beberapa Fitur pada saat yang bersamaan. Ini tidak sebanding dengan upaya mental untuk menjadi lebih ketat dari itu.

Tag berfungsi untuk Stack Exchange dan mereka juga bisa bekerja untuk Anda.

Cara kami bekerja dengan Epics, Cerita dan Fitur adalah sebagai berikut

Di awal siklus proyek, kami datang dengan Epics . Ini adalah level poin yang sangat tinggi, hampir terpusat pada pemasaran, fungsionalitas. Hal-hal yang dapat Anda gunakan dalam ringkasan eksekutif, seperti,

Situs web baru kami akan memungkinkan pelanggan untuk menelusuri produk, melihat ketersediaan dan harga, memesan, dan melihat riwayat pesanan sebelumnya

Ini mengarah ke Epics seperti

• Jelajahi Katalog Produk
• Lihat Ketersediaan
• Lihat Harga
• Tempatkan Order
• Lihat Riwayat Pesanan

Ini ditulis sebagai cerita pengguna (misalnya Sebagai pelanggan, saya ingin menelusuri katalog produk, sehingga saya dapat membuat keputusan pembelian yang terinformasi), tetapi hanya berfungsi sebagai starter untuk sepuluh untuk apa yang sebenarnya akan dikembangkan dan dirilis.

Epik-epik ini selanjutnya dipecah menjadi Kisah Pengguna . Ini adalah perjalanan pengguna end-to-end yang sebenarnya, sangat terbatas dalam ruang lingkup dan didefinisikan dengan cara yang dapat diperkirakan dan direncanakan secara independen, dan dikembangkan , diuji , dan dirilis dalam satu siklus rilis.

Kisah Pengguna adalah unit pengiriman. Ini adalah kisah pengguna yang lengkap atau tidak lengkap, ditayangkan atau tidak ditayangkan.

Epik dapat menghasilkan banyak cerita pengguna, tidak semua akan dikembangkan atau dirilis pada saat yang sama.

Sebagai contoh, epik Browse Katalog Produk dapat dipecah menjadi

• Navigasi Hirarki Kategori
• Cari menggunakan kata kunci
• Saring berdasarkan Atribut Produk (mis. Kisaran harga, merek, warna, ukuran, dll.)

Sekali lagi, masing-masing akan ditulis dalam format, mis. Sebagai pelanggan, saya ingin menavigasi hierarki kategori, sehingga saya dapat menelusuri produk dan menelusuri ke produk yang paling sesuai dengan kebutuhan saya.

Secara umum, untuk sebagian besar proyek kami, kami memiliki puluhan Epos dan ratusan cerita.

Sekarang, saat kita menjalani siklus kehidupan cerita, kita menandai cerita-cerita ini dengan Fitur s. Misalnya, semua isi dan cerita pencarian serta stok dan harga akan ditandai, misalnya, 'katalog-produk'. Cerita Place Order yang terkait dengan pembayaran dengan Kartu Kredit dapat ditandai dengan label 'kartu kredit' dan yang terkait dengan pembayaran dengan PayPal akan ditandai dengan label 'paypal'.

Label-label ini berfungsi untuk mengelompokkan cerita-cerita yang menjadi milik bersama, bukan karena mereka berbeda jenis melakukan kegiatan yang sama (misalnya semua cerita urutan tempat) tetapi karena mereka harus dilepaskan bersama.

Misalnya, kisah "menempatkan pesanan membayar dengan kartu kredit" berada di bawah epik yang sama dengan kisah "menempatkan pesanan membayar dengan PayPal", tetapi tidak perlu dirilis bersamaan.

Sedangkan, cerita "menempatkan pesanan membayar dengan kartu kredit", "memproses pengembalian uang kembali ke kartu kredit", dan kisah "memungkinkan pelanggan untuk mengelola kartu kredit yang disimpan di akun mereka" tampaknya menjadi milik satu sama lain . Mereka semua akan ditandai dengan label fitur 'kartu kredit'. yaitu mereka semua akan menjadi fitur "Kartu Kredit". Sangat tidak membantu melepaskan kemampuan untuk melakukan pemesanan dengan menggunakan Kartu Kredit, jika tidak memungkinkan untuk memproses pengembalian uang ke PayPal, atau jika tidak mungkin untuk mengelola Kartu Kredit Anda yang tersimpan di akun Anda

Catatan : Sebagai aturan umum, yaitu. Pada akhirnya, ini adalah keputusan bisnis. Jika waktu-ke-pasar penting, mungkin ada alasan yang sah untuk hidup dengan salah satu dari ini dan bukan yang lain.

Dengan demikian Epics berfungsi untuk memecah menjadi (terkait, tetapi terpisah) cerita yang dapat dikembangkan secara mandiri, sementara Fitur melayani untuk mengelompokkan cerita yang harus dirilis bersama.

Anda dapat mengatakan bahwa Epics terurai menjadi Cerita Pengguna, dan Cerita Pengguna dikomposisikan ke dalam Fitur. Kisah-kisah yang termasuk fitur biasanya di Epos. Dengan demikian Epik dan Fitur ortogonal, bukan dalam hierarki yang ketat.

Dalam cara kita bekerja, begitu Epos dipecah menjadi cerita, mereka kehilangan tujuan mereka. Kami tidak memperkirakan, atau merencanakan Epos. Kami tidak melacak kemajuan dalam Epos. Kami tidak merilis Epics. Kami memperkirakan, merencanakan, dan melacak Cerita Pengguna. Dan kami merilis Fitur.

Saya setuju dengan banyak tanggapan bahwa benar-benar tidak ada jawaban yang benar karena ini hanya istilah yang dapat bervariasi tergantung pada kamp Agile mana Anda didasarkan dan Anda pasti dapat membuat kamp Anda sendiri selama semua orang di tim Anda termasuk pemangku kepentingan eksternal mengerti apa yang mereka maksud. Ini hanya cara mengatur kebutuhan Anda.

Jawaban yang saya suka adalah dari kamp Mike Cohn dan itu cukup sederhana.

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• Epik hanyalah sebuah Cerita besar (hierarkis)
• Tema hanyalah sekelompok Cerita (seperti tag)

Dia sebenarnya menghindari istilah "Fitur". Saya berasumsi bahwa itu terutama karena itu adalah istilah umum di dunia air terjun tradisional. Banyak kamp Agile cenderung menggunakan istilah yang berbeda untuk menekankan perbedaan.

Jadi dalam definisi PM Anda, Fitur adalah suatu tempat di tengah hirarki Epic-Story.

Berikut ini adalah info-grafik saya dari definisi ini dari artikel InfoQ saya http://www.infoq.com/articles/visualize-big-picture-agile ;-)

Fitur dan Epos bukan hal yang sama.

• Sebuah Fitur bukan Cerita Pengguna.
• Epik adalah Kisah Pengguna.
• Kisah Pengguna mungkin adalah Epik.
• Kisah Pengguna dapat berisi banyak Fitur.
• Sebuah Fitur dapat memenuhi 1 hingga banyak Cerita Pengguna.

Dalam fase perencanaan, diskusi menghasilkan User Stories yang biasanya diidentifikasi sebagai Epics karena upaya untuk mengimplementasikan solusi bagi mereka terlalu besar untuk diselesaikan dalam beberapa hari. Fitur Produk diidentifikasi selama fase ini. Tapi itu hanya produk sampingan dari diskusi. Fitur kemudian digunakan untuk merencanakan peta jalan produk, yang merupakan diskusi terpisah.

The epos diambil dan dibahas lebih lanjut, sehingga Kisah Pengguna untuk setiap Epic. The Fitur dan epos digunakan untuk mendorong diskusi di Backlog Penyempitan dan Sprint Perencanaan sesi. Pada saat itu, Cerita Pengguna yang keluar dari diskusi tersebut disempurnakan , diprioritaskan , dan, dalam Perencanaan Sprint , diterima dalam sprint untuk implementasi.

Itu hanya masalah dekomposisi. Mereka hanya cerita, kecuali dengan ukuran berbeda.

Saya pribadi lebih suka untuk tidak memberi label ukurannya, tetapi jika Anda melakukannya juga tidak masalah. Tanyakan kepada Anda PM, apa definisi di ruang kerja Anda.

Organisasi kami memiliki lebih dari 2.000 pengembang, jadi jawaban atas pertanyaan ini penting untuk komunikasi yang lancar dan jelas antara ratusan tim Agile yang telah kami kerjakan bersama untuk produk umum kami. Untuk organisasi yang sangat kecil, Anda dapat memiliki struktur yang sangat sederhana yang bahkan tidak perlu hierarkis (seperti yang dijawab orang lain). Namun, untuk organisasi besar, pasti ada kebutuhan untuk beberapa hierarki yang terorganisir, berskala, konsisten - dan di situlah letak masalahnya dalam berusaha membuat hierarki dari sesuatu yang tidak sepenuhnya hierarkis.

Secara kebetulan, kami menyebut masing-masing level yang berbeda ini sebagai "item pekerjaan". Beberapa organisasi (termasuk beberapa responden di atas) menyebut tingkat yang berbeda sebagai Cerita atau Cerita Pengguna (dan kami juga pernah melakukannya di masa lalu), tetapi kami menemukan ini terlalu ambigu, jadi kami sekarang menyebutnya secara umum sebagai Item Kerja.

Yang terbaik yang telah "secara resmi" kami lakukan sejauh ini adalah mengikuti struktur SAFe Investasi dan Tema Bisnis Epic Dean Leffingwell yang berada di puncak (dan kedua dari atas) hierarki, kemudian Fitur di bawahnya, dan akhirnya Cerita di bawah Fitur. Menurut Agile, Tugas selalu berada di bawah Cerita, jadi kami berhati-hati untuk tidak menggunakan kembali istilah tersebut di atas. Kami memilih untuk mengikuti SAFe untuk setidaknya memiliki BEBERAPA konsistensi di semua tim kami.

Tetapi ini masih belum mencukupi untuk kebutuhan kita. Kami mendefinisikan suatu Fitur sebagai sesuatu yang sangat bernilai yang dapat disampaikan kepada konsumen produk perangkat lunak kami (yaitu, kami mencantumkan Fitur-fitur ini pada pengumuman Rilis kami yang akan datang). Dan kami mendefinisikan Story sebagai jumlah lingkup dan pekerjaan yang lebih kecil yang dapat disampaikan dalam Sprint tunggal oleh tim Agile dev tunggal. Kami juga sekarang MEMULAI untuk mengikuti definisi SAFe tentang Tema Investasi dan Epik Bisnis di tingkat Portofolio (dan tidak di bawah tingkat ini). Dan kami MULAI TIDAK menggunakan definisi LAMA kami tentang "Tema" dan "Epik".

Kita sekarang perlahan berevolusi ke arah ini, tetapi roda kemajuan menggiling perlahan. Kami masih berjuang dengan cara membagi pekerjaan menjadi potongan-potongan berukuran gigitan sehingga kami dapat mendefinisikan pekerjaan dan menyelesaikannya dengan lancar oleh beberapa tim. Untuk melakukan ini, kita melihat kebutuhan untuk "Sub-Fitur" yang lebih kecil dari Fitur tetapi lebih besar dari sebuah Cerita. Sub-Fitur dapat digunakan untuk potongan pekerjaan yang dilakukan pada Fitur oleh tim SETIAP INDIVIDU, atau potongan pekerjaan yang dilakukan oleh tim SINGLE pada waktu yang berbeda (dalam Sprint yang berbeda, atau bahkan rilis yang berbeda).

Kami juga memerlukan beberapa tingkat hierarki antara Fitur dan Epic Bisnis, tetapi kami belum menyelesaikan yang satu ini, selain hanya menyebutnya "Tema" - yang kami tahu bukan istilah yang benar, karena mudah dikacaukan dengan Tema Investasi SAFe. Untuk beberapa proyek besar (rilis) kami memiliki 5-8 level hirarki yang berbeda, masing-masing memecah pekerjaan menjadi potongan-potongan yang lebih kecil dan lebih kecil. Anda dapat menganggap Tema ini sebagai "Grup Fitur", tapi itu belum tentu istilah yang tepat juga.

Saya pikir penting untuk mencoba menggunakan istilah yang menawarkan kejelasan daripada ambiguitas. Jadi siapa pun yang merujuk pada suatu Story berarti unit pekerjaan terkecil yang dapat dilakukan dalam satu Sprint (kecuali untuk Tugas di bawah Story), dan Sub-Feature berarti unit kerja terkecil pada Fitur yang dapat dilakukan oleh satu orang. tim. Demikian juga, Grup Fitur adalah satu tingkat hirarki di atas Fitur. Di atas itu menjadi sedikit kabur, jadi kami biasanya hanya menyebutnya Tema, dan kami mengizinkan Tema sebagai orang tua dan anak-anak dari Tema lainnya. Kami mencoba membatasi level Fitur, Sub-Fitur, dan Cerita masing-masing ke level tunggal (Fitur tidak boleh merupakan anak-anak dari Fitur lain), tetapi kami belum 100% berhasil membatasi ini.

Saya tahu kami dapat menggunakan "Tag" untuk mengatur beberapa hal ini, tetapi tag tidak memberi kami struktur uraian kerja organisasi yang kami perlukan untuk mengelompokkan pekerjaan di antara semua tim kami. Menurut definisi, tag bersifat ambigu (hubungan banyak ke banyak), tetapi hierarki benar-benar satu ke banyak.

Intinya adalah bahwa ini masih dalam proses untuk kita, dan kita masih berjuang dengan itu. Tetapi mengikuti definisi SAFe tentang Tema, Epik, Fitur, dan Cerita membuat kita bergerak ke arah yang benar!

Product Backlog Hierarchy sangat tergantung pada ukuran produk dan modularitasnya (jumlah area produk ditentukan).

Untuk Proyek kecil: Epic> Cerita sudah lebih dari cukup; dan Anda memanggil "fitur".
Proyek-proyek besar mungkin sama seperti: Novel> Tema> Epik> Fitur> Cerita

Contoh terbaik mungkin sebagai berikut:
Novel =
Tema MS Office = MS Word / MS Excel ...
Epic = Tabel / Direktori Font ...
Fitur = Tabel Dasar / Skema Warna Tabel / Operasi dengan Sel ...
Cerita (untuk ' Fitur Tabel Dasar 'dalam Epik' Tabel ') = Tambahkan Tabel / Draw Table / Masukkan Kolom Baku / Sisipkan ...

Apa yang saya yakini bermanfaat untuk diingat ketika mendefinisikan penskalaan Anda sendiri untuk jaminan simpanan adalah:
1. Cerita: a) selalu layak dalam satu sprint; b) tidak selalu dapat diuji untuk pengguna akhir
2. Epik / Fitur: a) tidak sesuai dengan satu durasi sprint dan perlu diurai; b) selalu harus dapat diuji untuk pengguna akhir; c) selalu dapat dikirim, dapat dimonetisasi - dapatkan ROI dihitung untuk itu
3. Saat mempertimbangkan menambah atau tidak Epik> bagian Fitur atau tetap pada Epic> Story: Saya akan merekomendasikan untuk memasukkan Fitur di antara Epic dan Story hanya ketika: Epic tidak ' t pas bahkan 1 Rilis, jadi Anda perlu mendefinisikan elemen yang dapat dikirim yang sesuai dengan 1 Durasi rilis .

Semoga ini bermanfaat.

Di organisasi kami, kami memiliki yang berikut:

Tema = Digunakan untuk mengelompokkan kumpulan cerita

Epik = Menjelaskan kisah pengguna yang besar (sebenarnya suatu persyaratan) yang perlu dipecah menjadi cerita pengguna

Fitur = Melakukan apa yang tertulis di kaleng, menjelaskan fitur produk yang diperlukan

Kisah pengguna = Ini adalah tingkat detail terendah tempat tugas diturunkan.