อะไรคือคำอธิบายที่ดีที่สุดเกี่ยวกับเรื่องคะแนนคืออะไร

เราเริ่มใช้ Story Points ที่นี่เพื่อการพัฒนาแบบ Agile ของเรา แต่ฉันคิดว่ามันยากที่จะอธิบายและไม่สามารถหาคำตอบที่ชัดเจนสำหรับสิ่งที่พวกเขาเป็น สิ่งที่ดีที่สุดที่ฉันสามารถทำได้คือชี้ไปที่เว็บไซต์อื่น ๆ (เช่นhttp://blog.mountaingoatsoftware.com/tag/story-points ) และให้ลักษณะทั่วไปที่คลุมเครือของสิ่งที่พวกเขาเป็น ฉันกำลังมองหาคำอธิบายที่ดีพร้อมตัวอย่างการใช้งานที่จะเป็นประโยชน์สำหรับผู้อื่นในการใช้งาน มีแหล่งข้อมูลที่ดีสำหรับการอธิบายประเด็นหรือไม่?

สิ่งนี้อาจช่วยได้ในฐานะผู้เริ่มต้น: Mike Cohn ในประเด็นต่างๆ แต่อันนี้ดีกว่ามาก: ทีมพัฒนาแบบ Agile: ขอบเขตและขนาดกับ Mike Cohn

โซลูชันของไมค์ในการประมาณค่าซอฟต์แวร์นั้นง่ายและมีประสิทธิภาพ ข้อเท็จจริงทางชีวภาพ:

• สมองของมนุษย์ไม่สามารถประมาณเวลาได้อย่างถูกต้อง โดยเฉพาะถ้ามากกว่าสองสามชั่วโมง
• สิ่งนี้ได้รับการขยายอย่างมากด้วยจำนวนความไม่แน่นอนในนักพัฒนาซอฟต์แวร์แรงกดดันทางจิตวิทยาจากการจัดการ (เมื่อคุณประเมินคุณยอมรับ ... ) และความแตกต่างของทักษะในทีม
• อย่างไรก็ตามเราค่อนข้างดีในการเปรียบเทียบสิ่งของ เราค่อนข้างแม่นยำ

แนวคิดคือการใช้เรื่องราวของผู้ใช้อ้างอิงหนึ่งคนจากนั้นให้คะแนน(เรื่องราว)โดยพลการจากนั้นเรื่องราวอื่น ๆ จะได้รับคะแนนที่เกี่ยวข้องกับการอ้างอิงนั้น

หากเรื่องราวอ้างอิงของคุณคือ 100 คะแนนและอีกเรื่องใหญ่กว่าสามเท่านั่นคือ 300 คะแนน

การแปลงจุดเรื่องราวลงในเวลาสำหรับการวางแผนของคุณคุณต้องรู้ว่าคุณความเร็ว

เพื่อให้ได้ความเร็วที่ถูกต้องคุณต้องทำซ้ำสองสามครั้งและคำนวณว่าทีมของคุณทำคะแนนได้เท่าไหร่ในเวลาที่กำหนด

มันทำงาน

ฉันเห็นด้วยกับทุกอย่าง @ เปียโน 303: กล่าวไว้ข้างต้น: (นอกเหนือจากจุดอ้างอิง 100 จุด)

สิ่งเดียวที่ฉันต้องการเพิ่ม (เน้น) คือเราไม่เก่งในการประเมินงาน เราสามารถประเมินงานที่เกี่ยวข้องกับงานอื่น ๆ ได้ตราบใดที่งานมีขนาดเท่ากัน ยิ่งความแตกต่างระหว่างงานยิ่งแย่ลงเท่าไหร่

ดังนั้นฉันไม่เห็นด้วยกับการใช้จุดเริ่มต้นที่ 100

ไม่ใช่ว่าคุณจะประเมินงานต่อไปเป็น 42% ของงานอ้างอิง มันเป็นทั้งครึ่งเดียวของงานสองเท่าของงานสามเท่าของงาน ฯลฯ

ทีมของเราใช้Planing Poker : ในนี้เรามีภารกิจอ้างอิง 2 เรื่อง จากนั้นเราจะใช้ชุดฟีโบนักชีในการประเมินงาน: 1,2,3,5,8,13,21 ใหญ่มาก? สัมพันธ์กับภารกิจอ้างอิง (แทนที่จะเป็นฟีโบนักชีฉันเห็นทีมอื่นใช้พลังของ 2 1,2,4,8,16,32, ใหญ่มาก,?) ฉันเคยเห็นทีมอื่นใช้ (เล็ก (1), ปานกลาง ( 2), ขนาดใหญ่ (3), XLarge (4) เมื่อคำนวณความเร็วมันยังใช้ได้อยู่)

ประเด็นก็คือเมื่อขนาดของงานเพิ่มขึ้นเมื่อเทียบกับงานอ้างอิงเราจึงไม่สามารถประมาณการต้นทุนได้อย่างแม่นยำ ดังนั้นจึงไม่มีประเด็นในการลอง นี่คือภาพสะท้อนจากการไล่ระดับสีที่ใหญ่กว่าในตอนท้ายของเส้นทางการประมาณ

ดังนั้นหากงานอ้างอิงของคุณคือ 2SP จากนั้นการประมาณ 1/2/3/5 นั้นค่อนข้างง่ายเนื่องจากงานมีขนาดใกล้เคียงกัน เมื่อคุณมีขนาดใหญ่กว่า 3 เท่าของภารกิจอ้างอิง (5SP) การประเมินจะยากขึ้น (คือ 8/9 / 10SP มันสำคัญ) คุณสามารถพูดได้ว่าใหญ่กว่า 5SP และเล็กกว่า 13SP ดังนั้น 8SP จึงเหมาะกับการเรียกเก็บเงิน

อะไรก็ตามที่มีค่า SP เท่ากับ 13/21 / ใหญ่มากเกินไปสำหรับการค้างค้าง นี่เป็นค่าประมาณสำหรับสิ่งที่คุณยังไม่พร้อมที่จะทำงานจริง (และยังไม่ได้แบ่งย่อยเป็นงานเล็ก ๆ แต่จะให้การประมาณขนาดของงานใน backlog ของผลิตภัณฑ์ (ซึ่งจะช่วยให้การวางแผนในอนาคต) ตามเวลาที่คุณไปถึงจุดที่คุณจะทำงานกับพวกเขาคุณควรมีความรู้เพียงพอที่จะทำลายพวกเขาขึ้นเป็นงานเล็ก ๆ สำหรับ backlog sprint และประเมินพวกเขาอีกครั้งทีละรายการ (หมายเหตุ: มันเข้าใจผิดทั่วไปว่าผลรวมของ ชิ้นส่วนเท่ากับต้นฉบับ)

• ทุกสิ่งที่คุณประเมินว่าใหญ่จำเป็นต้องแยกย่อยออกเป็นงานเล็ก ๆ
• มีอะไรประมาณว่า? หมายความว่ามันไม่ดีพอที่จะประเมิน
  คุณต้องเพิ่มงานเฉพาะเพื่อไปและกำหนดงาน
  (เช่นเขียนเอกสารหรืองานนำเสนอ)

คะแนนเรื่องราวคือการวัดความสัมพันธ์ของงานยาก นี่เป็นเพราะมนุษย์มีการประเมินสัมพัทธ์ดีกว่าการวัดที่แม่นยำ

วิธีที่คุณใช้จุดเรื่องราวคือคุณทำงานสองอย่างในโครงการและกำหนดค่าจุดเรื่องราวที่แตกต่างกันสองค่า จากนั้นคุณประเมินงานอื่น ๆ โดยใช้การประมาณจุดเรื่องราวทั้งสองเป็นพื้นฐานสำหรับการประเมินของคุณ Ie Task C นั้นไม่ใช่งานหนักกว่า A มากนัก แต่ง่ายกว่า Task B อย่างไม่น่าเชื่อดังนั้นมันจึงมีเพียง 2 เรื่องเท่านั้นที่ทำงานมากกว่า task A

เมื่อคุณประเมินความต้องการทั้งหมดของคุณเสร็จแล้วคุณจะประเมินว่าคุณสามารถทำอะไรได้บ้างในการวิ่ง ในการวิ่งต่อไปอีกสองสามครั้งคุณประมาณว่าคุณทำเสร็จไปแล้ว คะแนนเรื่องราวของความต้องการจะถูกนับเมื่อเสร็จสมบูรณ์หากมีการปฏิบัติตามข้อกำหนด ไม่มี "สมบูรณ์ 80%" ในการต่อสู้ นี่เป็นเพราะมนุษย์ไม่ดีจริง ๆ ที่ประมาณความสมบูรณ์ หลังจากการวิ่งสองสามครั้งคุณควรมีความคิดว่าคุณสามารถทำคะแนนได้กี่เรื่องต่อการวิ่งหนึ่งครั้ง

คุณประเมินอย่างไร คุณสามารถใช้การวางแผนโปกเกอร์เพื่อกำหนดว่านักพัฒนาของคุณรู้สึกอย่างไรกับข้อกำหนดที่จะต้องใช้เมื่อเทียบกับข้อกำหนดพื้นฐานของคุณ

ฉันขอแนะนำให้อ่านThe Agile Samuraiด้วย มันเป็นงานที่ดีที่อธิบายแนวคิดเหล่านี้และแนวคิดอื่น ๆ ของ Agile ในความคิดของฉัน

นี่คือลิงค์ของคะแนนเรื่องราวเพิ่มเติม

นี่คือลิงค์อื่น

พวกเขาเสียเวลา

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

น่าสนใจที่ความคิดเห็นนี้มาจากคนที่เขียนScrum และ XP จาก Trenchesและมีชื่อ บริษัท ( Crisp ) สามารถพบได้ในหลาย ๆ ชั้นของการวางแผนไพ่โป๊กเกอร์ที่ใช้โดยทีมมากมายทั่วโลก

ประโยคสุดท้ายของ OP: "มีแหล่งข้อมูลที่ดีสำหรับการอธิบายประเด็นหรือไม่" ใช่หนังสือเล่มนี้เป็นแหล่งข้อมูลที่ดี อาหารสมอง.

คำอธิบายที่ง่ายที่สุดที่ฉันสามารถทำได้คือใช้วัตถุที่จับต้องได้และเป็นตัวอย่างที่เป็นรูปธรรม

พกพากลับบ้าน ถ้าฉันอยู่ในธุรกิจบ้านมือถือฉันจะรู้ว่าการสร้างความกว้างเพียงครั้งเดียวโดยทั่วไปจะใช้เวลา 5 (คะแนน, กบ, วิดเจ็ต ... รูปแบบการวัดนั้นไม่มีกฎเกณฑ์) ดังนั้นการสร้างความกว้างสองเท่าควรใช้ความพยายามเป็นสองเท่าหรือ 10 คะแนน , กบ, วิดเจ็ต)

ความคิดของโปรแกรมเมอร์ในตอนนี้จะเริ่มขึ้นและพูดคุยเกี่ยวกับแนวทางที่คล่องตัว มันใช้เวลาไม่นานสองเท่าเนื่องจากโครงสร้างพื้นฐานใช้เวลาส่วนใหญ่และเป็นตัวอย่างที่คล้ายกัน นี่เป็นสิ่งที่หลีกเลี่ยงไม่ได้ พิณบนความจริงที่ว่านี่คือการประมาณค่าใน (จุด, กบ, วิดเจ็ต) เนื่องจากเราไม่สามารถประเมินเวลาได้อย่างแม่นยำและดังนั้นการประเมินใน (คะแนน, กบ, วิดเจ็ต) จะขจัดความเชื่อที่เราสามารถทำได้

หากต้องการทราบว่าจะใช้เวลาสร้างนานแค่ไหนเราจะใช้ประโยชน์จากแนวโน้มของเราตลอดเวลา ดังนั้นเมื่อเวลาผ่านไปได้รับความแม่นยำมากขึ้นในการประมาณการของเรา

อย่าลืมวางแผนโป๊กเกอร์เมื่อทีมพร้อมที่จะไป

ตามที่คนอื่น ๆ ได้กล่าวถึงเรื่องราวคือการวัดความซับซ้อนของเรื่องราวของผู้ใช้ ประโยชน์ที่แท้จริงของคะแนนเรื่องราวจะถูกรับรู้เมื่อ

1. คะแนนจะถูกวัดโดยหน่วยงานที่รับผิดชอบในการดำเนินการ (ไม่ว่าจะเป็นรายบุคคลหรือทีม)
2. ตัวชี้วัดจะถูกเก็บไว้สำหรับจำนวนคะแนนรวมที่เสร็จสมบูรณ์โดยหน่วยเดียวกันภายในระยะเวลาคงที่ (ความเร็ว)

หลังจากทำการวัดในจุดเรื่องราวและติดตามความเร็วซ้ำแล้วซ้ำอีกคุณควรสามารถประมาณจำนวนจุดเรื่องราวที่จะพอดีภายในระยะเวลาที่กำหนด (ซ้ำหรือวิ่งถ้าใช้การต่อสู้) โปรดทราบว่าการใช้เทคนิคนี้กับกลุ่มและพยายามใช้ตัวชี้วัดเหล่านั้นกับทีมอื่นจะใช้งานไม่ได้ นั่นคือถ้าทีม a สามารถทำคะแนน 120 เรื่องราวให้เสร็จภายในสองสัปดาห์โดยคาดว่าทีม b จะได้ผลลัพธ์เหมือนกันไม่สมจริง

ตามที่คนอื่น ๆ กล่าวไว้การวางแผนโป๊กเกอร์เป็นตัวช่วยที่ดีมากเมื่อใช้วิธีนี้เพราะจะช่วยระบุเรื่องราวที่ต้องมีการปรับแต่งเพิ่มเติม (หากมีความแตกต่างระหว่างการโหวตก็หมายความว่ามีความไม่แน่นอนในข้อกำหนด)