Memecah cerita yang rumit pada awal proyek

9

Saya mencoba memahami manajemen proyek yang gesit (dengan Pivotal Tracker) tetapi terus menemukan diri saya berlari ke dinding ketika mencoba untuk mendefinisikan beberapa cerita pertama dari suatu proyek. Ambil contoh cerita yang sangat sederhana ini:

"Seorang pengguna harus dapat menandai suatu produk"

Dengan asumsi saya sudah mendefinisikan "produk" di tempat lain, cerita ini mungkin melibatkan penulisan sistem penandaan polimorfik di bawah tenda, pada saat penyelesaian id sistem itu akhirnya dapat menambahkan kemampuan untuk menandai suatu produk.

Masalah saya adalah jumlah pekerjaan yang disembunyikan dalam cerita ini. Saya bisa menentukan tugas untuk menyelesaikan cerita tetapi cerita secara keseluruhan seharusnya 1-2 hari kerja? Saya tidak merasa benar tentang cerita yang hanya mengungkapkan ujung gunung es tapi itu satu-satunya bagian yang berhubungan dengan Pengguna.

Bagaimana Anda mengatasi hal semacam ini? Apa praktik terbaik?

UPDATE 25/08 Terima kasih kepada semua orang atas bimbingan Anda, saya telah mengambil semua saran untuk mendefinisikan cerita. Saya sekarang beralih ke Jira Grasshopper yang memiliki dukungan yang lebih baik untuk tugas-tugas dalam cerita (tugas, perkiraan dll) dan pelacakan tugas pengembangan setelah sprint dimulai.

scrum

— matthewrk
sumber

1

Memecah pekerjaan menjadi tugas-tugas yang merupakan pekerjaan paling banyak 1-2 hari jelas merupakan ide yang bagus, dan banyak orang akan mengatakan itu penting. Namun, tugas! = Cerita pengguna . Tugas adalah bagian pengembangan yang harus Anda lakukan untuk memenuhi cerita pengguna, dan satu cerita pengguna dapat terdiri dari banyak tugas.

— vaughandroid

1

@ Baqueta Tapi ceritanya yang punya estimasi dalam poin? dan titik-titik tersebut dilacak sebagai kecepatan tim, setidaknya begitulah pengaturannya di Pivotal Tracker.

— matthewrk

Kisah pengguna dilakukan ketika semua tugas yang diperlukan untuk menyelesaikannya selesai. Jika Anda akhirnya membagi cerita di beberapa sprint mungkin akan sedikit mengurangi kecepatan untuk sprint tertentu, tetapi itu muncul di cuci dan rata-rata Anda masih harus berguna.

— vaughandroid

7

Jika Anda ingin cerita Anda masing-masing menjadi 1 hingga 2 hari kerja pengembang, mungkin Anda harus membagi setiap cerita menjadi tugas pengguna tertentu yaitu 1 hingga 2 hari kerja pengembang.

Pertimbangkan "kisah pengguna" berikut ini:

Seorang pengguna harus dapat menerima faktur dari produk yang dibeli.

Pikirkan tentang apa yang terlibat hanya dalam desain database, dalam memberikan kemampuan ini kepada pengguna. Anda memerlukan tabel pelanggan, tabel tajuk faktur, dan tabel item baris faktur, dan kami bahkan belum membicarakan tentang menerima pembayaran.

Pada kenyataannya, cerita pengguna tidak sesederhana ini. Kisah pengguna yang lengkap termasuk langkah-langkah langkah-langkah pengguna yang terlibat:

Pengguna memasukkan produk ke dalam keranjang

Pengguna menentukan kuantitas

Pengguna menentukan jenis pengiriman

dan seterusnya. Singkatnya, Anda perlu memecah cerita pengguna Anda menjadi detail yang lebih halus.

— Robert Harvey
sumber

Bisakah Anda memberikan contoh rincian berdasarkan kisah saya? Alasan saya berjuang untuk memecahnya lebih jauh adalah karena penandaan adalah cerita yang sangat sederhana di permukaan, dan itu satu-satunya bagian yang disentuh pengguna.

— matthewrk

7

Cerita tidak seharusnya, "1-2 hari kerja". Di bawah cerita Scrum biasanya diperkirakan menggunakan Story Points, sistem ukuran relatif. Jika Anda menggunakan cerita poker perencanaan diberi nilai poin - waktu yang diperlukan untuk menerapkan cerita tergantung pada kecepatan yang telah ditetapkan tim Anda.

Jika Anda merasa cerita itu menyembunyikan kompleksitas (Anda bisa menyebutnya cerita Epic ), Anda harus memecahnya menjadi cerita yang lebih kecil. Pastikan bahwa cerita baru mengikuti kriteria INVEST .

Tapi Anda mungkin overengineering ini; prinsip XP dari YAGNI berlaku di sini. Secara eksplisit Anda tidak boleh menerapkan sistem "penandaan polimorfik di bawah tenda", kecuali Anda benar-benar membutuhkannya. Meski begitu, itu harus dirancang dengan meningkatkan sistem yang ada, yang telah Anda kembangkan dengan serangkaian tes yang baik.

Jika Anda yakin Anda membutuhkan sistem penandaan yang rumit ini, Anda harus memanggil kompleksitas dalam cerita yang berbeda. Mike Cohn menggambarkan pendekatan desain sebagai, " Disengaja, namun muncul "

— Dave Hillier
sumber

Saya tidak melihat hasil edit Anda. Versi asli Anda pada dasarnya mengatakan "jangan lakukan itu," yang saya rasa tidak menambah nilai. Agaknya "sistem penandaan polimorfik" adalah bagian dari persyaratan. Saya telah mengedit untuk tidak menekankan aspek "overengineering" dari jawaban Anda, dan mengubah downvote saya menjadi upvote.

— Robert Harvey

Saya masih siaga, "jangan lakukan itu" :). Scrum adalah metodologi khusus bahwa OP akan menentang prinsip-prinsip Scrum.

— Dave Hillier

Terima kasih untuk tautan pada perencanaan poker, saya telah menggunakan sistem yang serupa dengan itu sebelumnya tanpa mengetahui ada prosedur formal. Alasan saya menentukan sistem penandaan polimorfik adalah karena saya tahu sejak awal kita perlu menandai model lain juga, jadi dalam hal ini harus dipertimbangkan sejak awal? Pekerjaan 1-2 hari per cerita adalah sesuatu yang saya anggap sebagai "ide bagus" ketika meneliti scrum, bekerja pada titik-titik usaha atau kesulitan saja tampaknya agak terbuka untuk interpretasi di mana ketika memperkirakan suatu hari kerja tampaknya cukup akurat .

— matthewrk

2

@matthewrk Itu ini apa YAGNIadalah tentang: Do bahkan tidak mencoba untuk membuat sistem penandaan polimorfik penuh belum . Buat yang sederhana untuk satu use case khusus. Jika pemilik produk kembali dengan cerita lain tentang penandaan hal lain, maka Anda memperluas sistem sederhana yang ada menjadi sistem penandaan polimorfik. Hanya karena Anda pikir itu perlu, tidak berarti pasti bahwa itu akan terjadi; mungkin menunjukkan bahwa pemberian tag pada model lain tidak akan diperlukan untuk sementara waktu, maka semua orang lupa tentang hal itu dan itu tidak pernah menjadi persyaratan. Karenanya, "Kamu Tidak Akan Membutuhkannya".

— Izkata

7

Tampaknya Anda mengacaukan cerita dan tugas.

Kisah Pengguna

Kisah pengguna adalah "fitur" lengkap, sesuatu yang bila ditambahkan ke produk, memberikan nilai lebih pada produk.

Kisah pengguna tidak boleh lebih besar dari yang dapat diterapkan selama sprint . Selama bagian pertama dari perencanaan sprint, Anda memutuskan cerita pengguna mana yang ingin Anda kerjakan selama sprint. Tujuan dari sprint adalah untuk melengkapi cerita pengguna ini, sehingga menambah nilai lebih pada produk.

Tugas

Selama bagian kedua dari fase perencanaan sprint, pengembang membagi cerita menjadi tugas . Tugas adalah tugas pengembangan. Itu bisa berupa "Tambahkan kolom ke basis data", "Perpanjang layanan x", dll. Tugas tidak boleh lebih besar dari yang dapat diselesaikan dalam satu hari.

Selama scrum harian Anda mengevaluasi kemajuan tugas-tugas ini. Jika tugas telah berlangsung selama lebih dari satu scrum harian, itu terlalu lama, dan Anda, sebagai tim, memiliki tanggung jawab untuk menyelesaikan situasi itu.

Ingat, kisah pengguna mewakili nilai bisnis bagi pemegang pasak. Para pemegang pasak harus tertarik pada penyelesaian cerita pengguna, bukan tugas.

Divisi tugas adalah alat bagi tim pengembangan untuk mengelola sprint, untuk memantau perkembangan cerita pengguna selama sprint, dan untuk memvisualisasikan masalah potensial.

Para pemegang pasak hendaknya tidak memusatkan perhatian pada tugas pengembangan ini. Sayangnya, ini adalah pengalaman saya yang sering mereka lakukan, terutama untuk organisasi yang baru untuk pengembangan tangkas. Berurusan dengan situasi ini adalah masalah yang berbeda.

Epik

Jika cerita pengguna lebih besar dari yang Anda kira dapat Anda selesaikan dalam satu sprint, itu disebut epik. Itu perlu dibagi menjadi beberapa cerita pengguna yang lebih kecil sebelum Anda sebagai sebuah tim dapat mulai mengerjakannya.

Ingatlah bahwa kisah pengguna menambah nilai bagi pengguna akhir, jadi memecah epik menjadi cerita "ujung depan" dan "ujung belakang" bukanlah cara yang benar. Menambahkan back-end untuk fitur baru tidak dengan sendirinya memberikan nilai kepada pengguna akhir.

Membagi sebuah epik menjadi cerita pengguna yang dapat dikelola dalam jangka waktu sprint tidak selalu mudah ketika Anda tidak berpengalaman dalam melakukannya.

Menggunakan Pivotal Tracker

Saya pikir Pivotal Tracker adalah alat yang hebat untuk melacak cerita pengguna. Tapi itu bukan alat scrum seperti itu, dan cara scrum mengajarkan untuk membagi cerita menjadi tugas tidak mudah ditangani oleh pelacak penting. Anda dapat mengaktifkan kemampuan untuk menambahkan tugas ke cerita pengguna. Tetapi jika Anda menjalankan proyek menggunakan scrum, saya akan menyarankan menggunakan papan tulis dan catatan tempel untuk melacak kemajuan tugas selama sprint.

— Pete
sumber

1

Terima kasih, ini jelas membersihkan beberapa alur kerja untuk saya. Ketika pengembang membagi cerita menjadi tugas, apakah mereka membuat lebih banyak cerita untuk melacak tugas itu? atau menambahkan tugas ke cerita? Mencoba mencari cara menerapkan ini dalam Pelacak Penting.

— matthewrk

Pengembang tidak membuat cerita baru. Kisah-kisah tersebut dikelola oleh "Pemilik Produk". Anda bisa mengatakan bahwa mereka menambahkan tugas ke sebuah cerita, tetapi saya pikir kalimat itu agak menyesatkan. Saya menambahkan jawaban beberapa kata secara eksplisit tentang Pivotal Tracker.

— Pete

4

Memiliki tujuan desain menerapkan sistem penandaan polimorfik tidak masalah, tetapi Anda harus tetap fokus pada penerapan fitur yang diinginkan pelanggan. Ini mungkin berarti bahwa, Pengguna-Cerita-halus-oleh-Pengguna-Cerita-halus, sistem Anda berkembang menjadi memiliki sistem penandaan polimorfik dari waktu ke waktu. Bagaimanapun juga dalam perjalanan itu, Anda harus memiliki sistem yang terdiri dari banyak fitur kecil dan dapat diuji, dijelaskan oleh kumpulan Cerita Pengguna yang telah Anda terapkan.

Dalam hal ini kedengarannya seperti "Menandai Produk" di sistem Anda mungkin Epic, yaitu sesuatu yang jauh lebih besar dari Kisah Pengguna tunggal dan dapat dipecah menjadi beberapa cerita yang lebih kecil dengan sedikit usaha. Mengambil cukup banyak lisensi artistik, saya bisa memikirkan Kisah Pengguna berikut yang mungkin kira-kira berlaku untuk kebutuhan Anda:

Sebagai administrator sistem, saya ingin menyemai sistem dengan beberapa tag yang valid sehingga pengguna memiliki beberapa nilai untuk dipilih saat pertama kali menggunakan fitur penandaan.
Sebagai pengguna sistem, saya ingin dapat mencari produk dengan nama sehingga saya dapat menandainya nanti.
Sebagai pengguna sistem saya ingin dapat membaca deskripsi suatu produk sehingga saya dapat memutuskan tag apa yang harus dimiliki.
Sebagai pengguna sistem saya ingin dapat melihat gambar produk sehingga saya dapat memutuskan tag apa yang seharusnya.
Sebagai pengguna sistem saya ingin dapat melampirkan tag tunggal ke satu produk.
Sebagai pengguna sistem saya ingin dapat menghapus satu tag dari satu produk.
Sebagai pengguna sistem saya ingin dapat melampirkan tag tunggal ke beberapa produk.
Sebagai pengguna sistem saya ingin dapat melampirkan banyak tag ke satu produk.
Sebagai administrator sistem, saya ingin melihat daftar tag yang berbeda yang digunakan dalam sistem sehingga saya dapat memutuskan apakah salah satu dari mereka adalah duplikat.
Sebagai administrator sistem, saya ingin menggabungkan tag yang digandakan.

... dan saya bisa melanjutkan.

Saya ragu salah satu dari ini akan sangat hidup sehingga Anda akan menggunakannya, tetapi mudah-mudahan itu menggambarkan jenis detail yang bisa Anda kunjungi dengan Cerita Pengguna Anda.

Jika Cerita Pengguna benar-benar tidak dapat dibagi lagi menjadi cerita yang lebih kecil dan Anda masih menganggapnya terlalu besar untuk diterapkan dalam sekali jalan, maka Anda dapat membaginya menjadi irisan vertikal. Ini adalah teknik yang berarti hanya memberikan sebagian fitur di bawah setiap Kisah Pengguna, tetapi setiap bagian menjadi irisan yang dapat diuji melalui semua lapisan teknologi yang relevan, misalnya untuk situs web ini mungkin berarti mengubah basis data, aplikasi, dan lapisan UI. Hindari memiliki satu Kisah Pengguna untuk pekerjaan basis data, yang lain untuk aplikasi dan lainnya untuk UI, karena ini tidak akan dapat diuji secara individual.

Mengambil lebih banyak lisensi artistik, saya mungkin terpecah "Sebagai pengguna sistem saya ingin dapat melampirkan tag tunggal ke satu produk." ke dalam irisan vertikal berikut:

Sebagai pengguna sistem yang melihat satu produk, saya ingin dapat melihat daftar tag sehingga saya dapat memutuskan mana yang akan diterapkan.
Sebagai pengguna sistem yang melihat satu produk, setelah memutuskan tag untuk diterapkan pada produk itu, saya ingin dapat menerapkannya.
Sebagai pengguna sistem yang melihat satu produk, setelah menerapkan tag pada produk itu, saya ingin pesan konfirmasi di layar memberi tahu saya bahwa itu telah berhasil disimpan.

Masing-masing diuji - jika tidak sangat berharga dalam hak mereka sendiri.

— Nick
sumber

Ketika Anda menyebutkan tes, apakah itu dari perspektif pengguna? yaitu tes integrasi / end-to-end? Dengan memberikan contoh cerita Anda sebagai pengembang, bolehkah saya mengambil semua cerita itu, mengimplementasikan struktur yang saya butuhkan (penandaan polimorfik) kemudian menyelesaikan semua cerita sekaligus ketika id memenuhi sisi pengguna dari persyaratan? tetapi kemudian di mana keseluruhan persyaratan teknis dilacak?

— matthewrk

Dalam hal ini yang saya maksud dapat diuji oleh pengguna, sehingga aktor yang disebutkan dalam Kisah Pengguna dapat memverifikasi bahwa Anda telah mengimplementasikan apa yang mereka inginkan.

— Nick

Ada nilai besar untuk memiliki satu mata uang pada suatu proyek ketika berbicara tentang persyaratan. Semua orang berbicara tentang kemajuan dalam hal Cerita Pengguna membuat komunikasi dan pelaporan jauh lebih mudah. Saya akan merekomendasikan Anda menyetujui serangkaian Cerita Pengguna dengan pelanggan Anda dan mengerjakannya dalam urutan yang disepakati (sebagian besar nilai bisnis terlebih dahulu, kecuali jika ada ketergantungan teknis) daripada hanya menerapkan visi Anda. Jika Anda berpikir fitur tambahan dari visi Anda tentang sistem penandaan polimorfik sangat berharga, maka tingkatkan sebagai Kisah Pengguna dan sepakati dengan pelanggan Anda kapan harus melakukannya.

— Nick

2

Ada beberapa buku yang ditulis untuk tujuan menemukan cara yang benar untuk menggambarkan dan menjabarkan persyaratan Anda. Jadi itu bukan tugas yang mudah.

Sering kali saya menemukan tim pengembangan berusaha untuk solusi yang kompleks daripada yang paling sederhana. Ini bisa jadi karena cerita itu sendiri atau karena tim ingin mencari solusi yang terlalu rumit yang tidak hanya menyelesaikan cerita ini tetapi juga meletakkan dasar untuk cerita x, y dan z juga. Ini adalah niat yang baik, tetapi ruang lingkup di mana pekerjaan yang sama dapat dilakukan dengan pekerjaan yang lebih sedikit. Selalu sulit untuk menilai berapa banyak desain yang harus dimasukkan ke dalam cerita untuk tidak merusak cerita masa depan dengan mengacaukan desain. Keputusan ini untuk dibuat oleh tim.

Sebagai pemilik produk, Anda hanya dapat memengaruhi ini dengan memecah cerita menjadi potongan-potongan kecil. Anda harus bertanya pada diri sendiri: Apakah kisah itu solusi terkecil yang dapat kita pikirkan saat ini? Bisakah kita memecahnya menjadi set fitur yang berkurang yang suatu hari akan menjadi "sistem penandaan fleksibel besar yang selalu saya inginkan". Anda bisa mulai dengan sistem tag hanya untuk satu tag, kemudian perluas untuk menyertakan daftar tag yang dipilih sebelumnya, dan kemudian biarkan pengguna menentukan tag, dll.

Untuk tim pengembang, intinya adalah: Bisakah kita menemukan pendekatan yang lebih sederhana untuk mewujudkan cerita, tetapi masih memiliki arsitektur yang solid yang menyelesaikan pekerjaan hari ini tanpa mengorbankan fitur masa depan.

Jika Anda terbuka untuk menerima solusi perantara dan tim pengembang juga mencoba untuk menawarkan solusi yang paling sederhana, namun baik maka Anda mungkin akan menemukan sweet spot di mana ukuran cerita yang ingin Anda lakukan adalah benar (semakin kecil semakin baik) . Ini bukan untuk mengatakan bahwa Anda hanya punya cerita kecil. Beberapa lebih besar dari yang lain, ini hanya fakta yang perlu Anda terima, atau jika terlalu besar, maka bagikan cerita menjadi lebih kecil.

— malte
sumber