it-swarm-id.com

Apa penjelasan terbaik tentang Story Points itu?

Kami mulai menggunakan Poin Cerita di sini untuk pengembangan Agile kami, tetapi saya merasa sulit untuk menjelaskan dan juga tidak dapat menemukan jawaban pasti untuk apa itu. Hal terbaik yang bisa saya lakukan adalah menunjuk ke situs lain (seperti http://blog.mountaingoatsoftware.com/tag/story-points ) dan memberikan generalisasi yang tidak jelas tentang apa itu mereka. Saya mencari penjelasan yang bagus dengan beberapa contoh penggunaan yang akan bermanfaat bagi orang lain untuk menggunakannya. Apakah ada sumber daya yang baik untuk menjelaskan poin cerita?

36
six8

Ini dapat membantu sebagai starter: Mike Cohn pada poin cerita . Tapi yang ini jauh lebih baik: Tim Pengembangan Agile: Lingkup dan Skala dengan Mike Cohn

Solusi Mike untuk metrik estimasi perangkat lunak sederhana dan efektif. Fakta biologis:

  • Otak manusia tidak dapat memperkirakan waktu dengan tepat. Apalagi jika lebih dari beberapa jam.
  • Ini sangat diperkuat oleh jumlah ketidakpastian dalam pengembang perangkat lunak, tekanan psikologis dari manajemen (ketika Anda memperkirakan, Anda berkomitmen ...) dan perbedaan dalam keterampilan dalam tim.
  • Namun, kami cukup baik dalam membandingkan barang. Kami cukup akurat di sana.

Idenya adalah untuk mengambil satu cerita pengguna referensi , lalu memberikannya angka (cerita) yang sewenang-wenang , maka cerita lain akan mendapatkan poin terkait dengan referensi itu.

Jika cerita referensi Anda adalah 100 poin, dan cerita lain tiga kali lebih besar, maka itu akan menjadi 300 poin.

Untuk mengonversi poin cerita menjadi waktu untuk perencanaan Anda, Anda harus mengetahui kecepatan Anda.

Untuk mendapatkan kecepatan yang akurat, Anda harus melakukan beberapa iterasi dan menghitung berapa banyak poin yang tim Anda selesaikan dalam jumlah waktu tertentu.

Berhasil .

36
user2567

Saya setuju dengan semuanya @ Tier 303: kata di atas: (terlepas dari 100 titik referensi).

Satu-satunya hal yang ingin saya tambahkan (penekanan) adalah bahwa kami tidak pandai memperkirakan tugas. Kita dapat memperkirakan tugas relatif terhadap tugas lain asalkan ukurannya kira-kira sama. Semakin besar perbedaan antara tugas semakin buruk yang kita dapatkan.

Jadi saya tidak setuju dengan menggunakan titik awal 100.

Ini bukan seolah-olah Anda akan memperkirakan tugas berikutnya sebagai 42% dari tugas referensi. Ini bisa berupa setengah pekerjaan yang sama, dua kali lipat pekerjaan, tiga kali lipat pekerjaan, dll.

Tim kami menggunakan Planing Poker : Dalam hal ini kami memiliki tugas referensi 2 poin cerita. Kami kemudian menggunakan seri Fibonacci untuk memperkirakan tugas: 1,2,3,5,8,13,21, Huge ,? relatif terhadap tugas referensi (Daripada Fibonacci saya telah melihat tim lain menggunakan kekuatan 2. 1,2,4,8,16,32, Huge ,?) Saya telah melihat tim lain menggunakan (kecil (1), sedang ( 2), besar (3), XLarge (4) ketika mereka menghitung kecepatannya masih bekerja.).

Intinya adalah bahwa ketika ukuran tugas meningkat relatif terhadap tugas referensi, kita menjadi kurang mampu memperkirakan biayanya secara akurat. Jadi tidak ada gunanya mencoba. Ini tercermin oleh gradien yang lebih besar di akhir jejak estimasi.

Jadi jika tugas referensi Anda adalah 2SP. Maka membuat perkiraan 1/2/3/5 relatif mudah karena tugasnya hampir sama. Setelah Anda melewati 3 kali lebih besar dari tugas referensi (5SP) estimasi menjadi lebih sulit (Apakah 8/9/10SP itu penting) Yang bisa Anda katakan adalah lebih besar dari 5SP dan lebih kecil dari 13SP kemudian 8SP sesuai dengan tagihan.

Apa pun dengan nilai SP dari 13/21/Besar terlalu besar untuk sprint backlog. Ini adalah perkiraan untuk hal-hal yang belum siap untuk benar-benar Anda kerjakan (dan karenanya belum dipecah menjadi tugas yang lebih kecil (jangan putus sampai Anda perlu juga)). Tetapi mereka memang memberi Anda perkiraan untuk ukuran tugas dalam jaminan produk (yang memungkinkan beberapa perencanaan di masa depan). Pada saat Anda sampai ke titik di mana Anda akan mengerjakannya, Anda harus memiliki pengetahuan yang cukup untuk memecah-mecahnya menjadi tugas-tugas kecil untuk sprint backlog dan memperkirakan kembali secara individual (Catatan: Ini adalah kesalahpahaman umum bahwa jumlah bagian-bagian sama dengan aslinya).

  • Apa pun yang Anda perkirakan sebagai Huge perlu dipecah menjadi tugas yang lebih kecil.
  • Apa pun yang diperkirakan? berarti tidak cukup baik untuk memperkirakan
    Anda perlu menambahkan tugas secara khusus untuk pergi dan mendefinisikan tugas
    (mis. menulis beberapa dokumentasi atau presentasi).
5
Martin York

Mereka buang-buang waktu.

enter image description here

http://www.Amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Menarik bahwa pendapat ini sekarang berasal dari orang yang menulis Scrum dan XP dari Parit dan yang nama perusahaannya ( Crisp ) dapat ditemukan di banyak kartu perencanaan poker yang digunakan oleh banyak tim di seluruh dunia.

Kalimat terakhir OP: "Apakah ada sumber daya yang bagus untuk menjelaskan poin cerita?" Ya, buku ini adalah sumber yang bagus. Bahan untuk dipikirkan.

2
azheglov

Poin cerita adalah ukuran relatif dari seberapa sulit suatu tugas. Ini karena manusia sebenarnya lebih baik dalam perkiraan relatif daripada pengukuran yang tepat.

Cara Anda menggunakan poin cerita adalah Anda mengambil dua tugas pada proyek dan menetapkannya dua nilai poin cerita yang berbeda. Kemudian Anda memperkirakan tugas-tugas lain menggunakan dua pendekatan titik cerita itu sebagai dasar untuk perkiraan Anda. Yaitu. Tugas C tidak jauh lebih sulit daripada tugas A tetapi sangat lebih mudah daripada tugas B sehingga hanya sekitar 2 poin cerita lebih banyak pekerjaan daripada tugas A.

Ketika Anda selesai memperkirakan semua persyaratan yang Anda miliki sejauh ini, Anda kemudian memperkirakan berapa banyak yang bisa Anda lakukan dalam sprint. Selama beberapa sprint berikutnya, Anda memperkirakan berapa banyak yang telah Anda selesaikan. Poin cerita suatu persyaratan hanya dihitung sebagai selesai jika persyaratan tersebut terpenuhi. Tidak ada "80% selesai" di Scrum. Ini karena manusia sebenarnya buruk dalam memperkirakan kelengkapan. Setelah beberapa sprint, Anda harus memiliki gagasan tentang berapa banyak poin cerita yang dapat Anda lakukan per sprint.

Bagaimana cara Anda memperkirakan? Anda dapat menggunakan poker perencanaan untuk menentukan berapa banyak pekerjaan yang menurut pengembang Anda akan membutuhkan relatif terhadap persyaratan dasar Anda.

Saya juga merekomendasikan membaca The Agile Samurai . Menurut saya ini adalah pekerjaan yang baik menjelaskan konsep Agile ini dan konsep Agile lainnya.

Inilah tautan dengan lebih banyak tentang poin cerita.

Ini tautan lain.

2
indyK1ng

Seperti orang lain telah menyebutkan poin cerita adalah pengukuran relatif kompleksitas untuk cerita pengguna. Manfaat sebenarnya dari poin cerita diwujudkan ketika

  1. Poin-poin diukur oleh unit yang bertanggung jawab untuk implementasi (baik individu atau tim).
  2. Metrik disimpan untuk berapa banyak titik agregat diselesaikan oleh unit yang sama dalam durasi (kecepatan) yang konstan.

Setelah beberapa iterasi untuk mengukur poin cerita dan kecepatan pelacakan, Anda harus dapat memperkirakan secara akurat berapa banyak poin cerita yang bisa masuk dalam kunci waktu yang diberikan (iterasi atau sprint jika menggunakan scrum). Perhatikan bahwa menerapkan teknik ini ke grup dan mencoba menggunakan metrik tersebut untuk tim yang berbeda tidak akan bekerja dengan baik. Itu adalah jika tim a dapat menyelesaikan 120 poin poin dalam sprint dua minggu, mengharapkan tim b untuk memiliki hasil yang sama tidak realistis.

Seperti orang lain sebutkan, perencanaan poker adalah bantuan besar ketika menggunakan metode ini karena itu akan membantu mengidentifikasi cerita yang perlu penyempurnaan lebih lanjut (jika ada perbedaan antara suara, itu berarti ada ketidakpastian dalam persyaratan).

0
Michael Brown

Penjelasan termudah yang dapat saya lakukan adalah menggunakan objek yang nyata dan dapat memberikan contoh nyata.

Bawa pulang ponsel. Jika saya berada dalam bisnis rumah mobil saya akan tahu bahwa membangun satu lebar biasanya membutuhkan 5 (poin, katak, widget ... bentuk pengukuran sewenang-wenang) dan oleh karena itu membangun lebar ganda harus sekitar dua kali lipat upaya atau 10 (poin , katak, widget).

Pola pikir programmer pada saat ini akan mulai dan berbicara tentang pendekatan yang efisien; tidak memakan waktu dua kali lebih lama karena infrastruktur menghabiskan sebagian besar waktu dan contoh serupa lainnya. Ini tidak bisa dihindari. Harpa pada fakta bahwa ini adalah estimasi dalam (poin, katak, widget) karena kita TIDAK PERNAH dapat memperkirakan waktu secara akurat dan dengan demikian memperkirakan dalam (poin, katak, widget) menghilangkan keyakinan bahwa kita bisa.

Untuk mengetahui berapa lama waktu yang dibutuhkan untuk membangun, kami akan menggunakan tren kami dari waktu ke waktu; jadi seiring waktu semakin akurat dalam perkiraan kami.

Jangan lupa merencanakan poker saat tim siap berangkat.

0
Aaron McIver