Banyak kisah pengguna berbagi tugas teknis yang sama: apa yang harus dilakukan?


8

Sedikit pengantar untuk kasus saya:

Sebagai bagian dari produk yang lebih besar, tim saya diminta membuat IDE kecil untuk DSL. Pengguna produk ini akan dapat membuat panggilan fungsi dalam kode dan kami juga diminta untuk menyediakan beberapa pustaka fungsi yang berguna. Tim, bersama-sama dengan PO, menempel di dinding sejumlah cerita pengguna tentang berbagai perpustakaan untuk pengguna IDE. Ketika memperkirakan cerita pertama, tim memutuskan bahwa mekanisme pemanggilan fungsi akan menjadi tugas yang menarik tetapi tidak sepenuhnya jelas, sehingga perkiraan untuk cerita pengguna tersebut dinaikkan dari angka 3 yang sederhana menjadi yang lebih berbahaya 5.

Datang ke masalah:

Tim kemudian pindah ke cerita pengguna tentang perpustakaan lain, sebenarnya 10 cerita, dan menambahkan 2 poin hal " mekanisme panggilan fungsi " ke masing-masing cerita pengguna. Ini segera mengangkat total poin untuk produk 20 poin! Semua orang di tim tahu bahwa setiap cerita pengguna dapat diambil oleh PO untuk iterasi berikutnya kapan saja, jadi kami tidak boleh mengisolasi bagian itu dalam satu cerita pengguna, tetapi 20 poin itu terasa sangat tidak realistis!

Saya sudah mengusulkan solusi, tapi saya sama sekali tidak puas:

Kami membuat "Cerita desain" dan menempatkan 2 poin yang menjengkelkan di atasnya. Namun ketika kami menyadari dan menunjukkannya kepada pelanggan kami, kami tidak dapat menunjukkan sesuatu yang sangat berharga bagi mereka tentang kisah itu!

Di sini masalahnya adalah apakah kita harus mengabaikan prinsip memiliki cerita pengguna yang terisolasi (tanpa ada ketergantungan di antara mereka).

Apa yang akan Anda lakukan, atau bahkan lebih baik apa yang telah Anda lakukan, dalam situasi seperti ini?


(catatan kaki kecil: mengikuti saran saya telah memindahkan pertanyaan ini dari stackoverflow)


Dengan IDE, maksud Anda API? Kalau tidak, saya kesulitan mencari tahu apa yang Anda katakan.
Steven Evers

Ini adalah IDE ( en.wikipedia.org/wiki/Integrated_development_environment ) tempat pengguna dapat mengetik kode, kompilasi, dan debug. Fitur penting dari bahasa ini adalah kemampuan untuk memanggil fungsi yang disediakan oleh kami (seperti "v = sin (x)").
Marco Ciambrone

Jawaban:


6

Jika Anda perlu memperkirakan beberapa cerita-pengguna yang memiliki beberapa elemen yang sama, tetapi Anda belum tahu bagaimana urutan cerita-cerita ini untuk diimplementasikan, maka saya akan membagi tugas-tugas yang membentuk setiap cerita menjadi tiga kelompok:

  1. Tugas umum, diperlukan sekali : Tugas yang terjadi untuk banyak cerita, tetapi yang hanya harus dilakukan hanya sekali untuk cerita pertama. Mekanisme panggilan fungsi yang disebutkan mungkin akan jatuh dalam kategori ini.
  2. Tugas yang umum dan berulang : Tugas yang muncul dalam banyak cerita dan harus dieksekusi lagi untuk setiap cerita.
  3. Tugas khusus : Tugas yang khusus untuk cerita tertentu.

Kemudian Anda memperkirakan setiap tugas, di mana tugas umum harus diperkirakan hanya satu kali.

Dalam presentasi kepada pelanggan / PO, saya akan memberikan dua perkiraan untuk setiap cerita: Satu dengan semua tugas "umum, diperlukan sekali" termasuk dan satu dengan mereka dikeluarkan.
Pertahankan pembukuan terinci dari tugas-tugas tersebut, klasifikasi dan estimasi mereka di tangan jika pelanggan menginginkan informasi yang lebih terperinci tentang perbedaan antara perkiraan tersebut. Tugas-tugas itu sendiri tidak dapat dinegosiasikan, tetapi mengetahui tentang mereka dapat membantu pelanggan / PO, terutama jika serangkaian tugas umum tidak sama untuk setiap cerita.


1
+1: Pada waktu retrospektif, Anda akan menaksir ulang semua cerita karena kode umum sudah diterapkan.
S.Lott

Saya pikir saya sudah mengerti maksud Anda, namun dalam hal ini kami memutuskan untuk menghindari analisis yang lebih dalam dan untuk mendukung perkiraan cerita yang lebih cepat, tanpa mengekstraksi semua tugas. Kami sebenarnya telah melakukan sesuatu yang mirip dengan saran Anda, dengan mengekstraksi dari cerita-cerita itu sebuah "cerita umum", seperti sekelompok "tugas umum, yang perlu sekali". Jawaban Anda secara efektif melangkah lebih jauh dan akan sangat berguna, namun saya masih lebih suka estimasi kasar, bila memungkinkan, alih-alih dekomposisi tugas, yang akan saya serahkan pada perencanaan iterasi. - @ S.Lott: pendekatan ini akan membuat 20 poin "menyebalkan" itu ..
Marco Ciambrone

@ d3prok: 20 poin "menjengkelkan" adalah artefak sementara dari pendekatan yang Anda pilih. Mereka tidak benar-benar ada dan mereka pergi begitu tugas bersama diimplementasikan.
S.Lott

4

Mengapa perangkat lunak itu sulit.

Kami membuat "Cerita desain" dan menempatkan 2 poin yang menjengkelkan di atasnya. Namun ketika kami menyadari dan menunjukkannya kepada pelanggan kami, kami tidak dapat menunjukkan sesuatu yang sangat berharga bagi mereka tentang kisah itu!

Benar. Kisah pengguna sederhana SCRUM adalah sederhana. Terkadang, perangkat lunak yang sebenarnya cukup kompleks sehingga pendekatan sederhana tidak berfungsi. Seharusnya ini tidak mengejutkan.

Di sini masalahnya adalah apakah kita harus mengabaikan prinsip memiliki cerita pengguna yang terisolasi (tanpa ada ketergantungan di antara mereka).

Apa alternatif Anda? Harga lebih tinggi dari setiap cerita pengguna karena masing-masing memiliki biaya satu kali tersembunyi? Itu sama konyolnya.

Iya. Anda harus menjauh dari simplistik.

Apa yang akan Anda lakukan, atau bahkan lebih baik apa yang telah Anda lakukan, dalam situasi seperti ini?

Minggir dari penyederhanaan. Ada investasi satu kali yang membuat sekelompok cerita lebih murah. Anda harus benar-benar berbicara dengan orang-orang tentang arsitektur alih-alih berpura-pura bahwa satu-satunya interaksi Anda adalah daftar cerita yang akan dibangun.

Agile berarti Anda harus benar-benar berbicara dengan PO dan pelanggan.

Agile berarti proses penyederhanaan tidak bisa - dan tidak akan - berhasil.


Jadi, apa yang seharusnya kami lakukan adalah menunjukkan kepada pelanggan PO + kami bahwa dalam perjalanan untuk menyelesaikan masing-masing 20 cerita pengguna (nilai riil / uang untuk mereka) ada langkah teknis untuk diatasi. Ini akan membantu membuat mereka menyadari pentingnya "cerita desain" dan karenanya menempatkan mereka pada posisi yang lebih baik untuk memprioritaskan pekerjaan itu. Apakah saya mengerti dengan baik?
Marco Ciambrone

@ d3prok: "membiarkan mereka menyadari pentingnya" cerita desain "dan menempatkan mereka pada posisi yang lebih baik untuk memprioritaskan pekerjaan itu" Ya. Metode tangkas seperti Scrum mengharuskan Anda untuk berbicara dengan PO dan pelanggan. Percakapan. Diskusi. Interaksi. Proses formal 'membangun-perkiraan-memprioritaskan cerita' yang tidak terpikirkan adalah hal yang tepat yang harus Anda hindari.
S.Lott

ini adalah jawaban yang sangat berguna, saya ingin memberi Anda poin tetapi sayangnya reputasi saya terlalu rendah di sini pada programmer ... Terima kasih S.Lott!
Marco Ciambrone

1

Anda tahu bahwa Anda hanya perlu melakukan pekerjaan ekstra sekali, jadi memasukkan pekerjaan tambahan yang sama ke dalam 5 cerita tidak masuk akal. Jika Anda tidak ingin cerita desain yang tidak dapat dilihat pengguna, maka hal terbaik yang harus dilakukan adalah terus maju, sekarang, dan memilih salah satu hal yang bergantung pada pekerjaan desain itu dan mengatakan bahwa itu harus menjadi yang pertama dan tambahkan poin-poin itu ke yang itu. Buat catatan tentang cerita-cerita lain yang harus mereka sampaikan nanti, dan jika, karena alasan tertentu, Anda berubah pikiran, Anda selalu dapat memindahkan poin-poinnya.


1
Saya akan memperingatkan agar tidak menambahkan tugas bersama ke fitur yang Anda pilih (secara acak, atau tidak) sebagai tugas "pertama". Hal ini dapat menyebabkan PO / pelanggan memutuskan untuk drop / downprioritice bahwa fitur (lebih mahal), mendukung (sekarang jauh lebih murah) fitur lainnya. Sekarang ini bukan sesuatu yang bisa Anda jalani. Sebagai gantinya, saya sarankan mengikuti jawaban dari @Bart van Ingen Schenau dan S.Lott di atas.
Svend Hansen
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.