เหตุใดเราจึงใช้คะแนนเรื่องราวแทนผู้ชายวันเมื่อประเมินเรื่องราวของผู้ใช้

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

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

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

ฉันคิดว่าหนึ่งในข้อได้เปรียบหลักคือมนุษย์และนักพัฒนาซอฟต์แวร์โดยเฉพาะนั้นค่อนข้างแย่ในการประมาณเวลา ลองนึกถึงลักษณะของการพัฒนาเช่นกัน - มันไม่ใช่ความก้าวหน้าเชิงเส้นตั้งแต่ต้นจนจบ บ่อยครั้งที่ "เขียน 90% ของรหัสใน 10 นาทีจากนั้นจึงทำการดีบักผมของคุณเป็นเวลา 17 ชั่วโมง" มันค่อนข้างยากที่จะประมาณความรู้สึกในเวลาของนาฬิกา

แต่การใช้สิ่งที่เป็นนามธรรมจะให้ความสำคัญกับเวลาจริงเป็นชั่วโมงหรือเป็นวันและให้ความสำคัญกับการอธิบายค่าใช้จ่ายและความซับซ้อนของงานเมื่อเทียบกับงานอื่น ๆ มนุษย์ / นักพัฒนานั้นเก่งกว่า จากนั้นเมื่อคุณได้รับเสียงฮัมด้วยการประมาณจุดเหล่านั้นและความคืบหน้าจริงบางอย่างคุณสามารถเริ่มดูเวลาที่ชัดเจนมากขึ้น

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

หากคุณกำลังใช้หมายเลขฟีโบนักชี (หรือบางอย่างที่คล้ายกัน) มันจะ จำกัด จำนวนตัวเลือกเมื่อประเมินเรื่องราว ฉันทำงานกับกลุ่มที่ใช้ตัวเลขต่ำเท่านั้น: 1, 2, 3, 5, 8 และ 13 เรามีเรื่องราวอ้างอิงที่เป็น 5 สิ่งนี้ช่วยให้เราตัดสินใจได้อย่างง่ายดายเกี่ยวกับความซับซ้อนของเรื่องราวขณะทำการวางแผนโป๊กเกอร์ . ผลข้างเคียงอื่น ๆ คือสิ่งที่อันดับ 13 อาจมีข้อมูลไม่เพียงพอและจำเป็นต้องแยกย่อยออกไปอีก ฉันสงสัยอย่างจริงจังว่าจะเป็นเรื่องง่ายและตรงไปตรงมาถ้าเราใช้เวลาดิบ

เจ้าของผลิตภัณฑ์ของคุณพูดภาษาของผู้มีส่วนได้ส่วนเสียของคุณและควรสามารถแปลระหว่างจุดเรื่องราวและจำนวนชั่วโมง (หรือหน่วยอื่น ๆ ) ตามที่ต้องการ ในช่วงเวลาที่ฉันเป็น PO ฉันมีข้อมูลบางอย่างที่ว่า 1 story point = 4 ชั่วโมงมนุษย์ แต่เห็นได้ชัดว่าทุกทีมแตกต่างกัน

แก้ไข:

ด้วยความรู้ที่ว่า 1 point = 4 ชั่วโมงคุณสามารถเปลี่ยน deck poker ของคุณเป็น 4, 8, 12, 20, 32 และ 52 ได้ แต่ตัวเลขเหล่านั้นยากที่จะจัดการ ฉันคิดว่าฉันจะทำให้ค่าทางใจกลับไปสู่สิ่งที่เรียบง่ายเช่น "น้อยกว่าหนึ่งวัน", "มากกว่าหนึ่งสัปดาห์" เป็นต้นและถ้าฉันจะทำอย่างนั้นฉันก็อาจจะยึดติดกับหน่วยนามธรรม ไม่มีจุดเรื่องราว

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

แทนที่จะทุกคนที่เกี่ยวข้องในการประมาณต้องคิดเช่น "ตกลง .. ดูเหมือน 2 วันมนุษย์ .. แต่สุดท้ายวิ่งเราประเมินทุกอย่างดังนั้นอาจเป็น 2.5 คนวันหรือ 3?" พวกเขาดำเนินการเหมือนกันเสมอ "5 เรื่องคะแนน!"

จากนั้นคุณปรับการประมาณจำนวนเรื่องราวที่ทีมสามารถทำได้ในการวิ่งโดยขึ้นอยู่กับความสำเร็จที่วัดจริงในการวิ่งครั้งก่อน "เราทำคะแนน 90-110 เรื่องต่อการวิ่งหนึ่งครั้งก่อนหน้านี้!"

ผมจะบอกว่าทฤษฎีที่อยู่เบื้องหลังนี้คือนักพัฒนาจะดีกว่าที่ประมาณการญาติซับซ้อนของงาน dev ที่แตกต่างกันกว่าที่พวกเขาจะอยู่ที่ประมาณตายตัว โดยเฉพาะอย่างยิ่งหากมีหลายคนกำลังประเมินงานซึ่งสามารถทำได้โดยคนใดคนหนึ่ง (และไม่ใช่ทุกคนที่ทำงานด้วยความเร็วเท่ากับคนอื่น ๆ )

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

วันคนหรือชั่วโมงคนเป็นอย่างที่คุณพูดเป็นรูปธรรม ดังนั้นเมื่องานประมาณ 5 ชั่วโมงและใช้เวลา 6 ก็เป็นงานที่ล่าช้า

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

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

นั่นไม่ได้หมายความว่าจะไม่มีการโต้เถียงหรือมีการมอบหมายคะแนนโดยพลการ เรามีสมาชิกในทีมของเราที่เกือบจะโหวตน้อยที่สุดและบ่นเมื่อพวกเขาคิดว่างานเป็น 1 และเราคิดว่ามันเป็น 3 ที่เรากำลังทุกข์ทรมานจากอัตราเงินเฟ้อจุด

สิ่งที่เป็นนามธรรมเป็นจุด การใช้ 'วันคน' เป็นการวัดมีข้อผิดพลาดมากมายรวมไปถึง:

1. หากทีมไม่คุ้นเคยกับเทคโนโลยีที่พวกเขากำลังจะใช้มันอาจเป็นเรื่องยากที่จะประเมินเวลาตามเวลาจริงของงาน พวกเขามีแนวโน้มมากขึ้นที่จะสามารถให้การประมาณสัมพัทธ์ที่ดี - เช่น "งาน A อาจจะใช้เวลานานเป็นสองเท่าของงาน B"
2. ผู้คนต่างทำงานในอัตราที่ต่างกัน! หากคุณใช้ 'วันคน' คุณจะต้องเปลี่ยนเวลาโดยประมาณเมื่องานถูกส่งผ่านจากผู้พัฒนารายหนึ่งไปยังอีกคนหนึ่ง ใครเป็นผู้กำหนดว่างานมากแค่ไหนถือว่าเป็น 'วันคน' อยู่แล้ว?

หากคุณต้องการที่จะประมาณวันคนมันเป็นการคำนวณง่าย ๆ :

user points in story / average user points per developer per day = estimated man days

ดังที่ได้กล่าวไปแล้วจุดเรื่องราวเป็นตัวชี้วัดความซับซ้อน หนึ่งสามารถใช้พลังงานของ 2 ซีรีส์ (1,2,4,8,16 ... ) หรือสเกลฟีโบนักชี (1,2,3,5,8,13,20 ... ) สำหรับการประมาณ ในฐานะนักพัฒนาที่ได้รับการฝึกฝนค่อนข้างเชี่ยวชาญในการพูดบางอย่างเช่นนี้:

คุณสมบัติ A นั้นใกล้เคียงกับฟีเจอร์ B เกือบสองเท่า

แต่มันยากที่จะพูดว่าคุณลักษณะนี้ใช้เวลานานแค่ไหนในการติดตั้ง คุณปล่อยให้มีความสมดุลด้วยความเร็ว ดังนั้นหากบางสิ่งประมาณว่าเป็น 5 แต่กลายเป็น 13 ความเร็วที่ช้ากว่าจะทำให้ปกติสำหรับการคำนวณซ้ำ (หรือคุณสามารถประมาณใหม่ได้)

ตอนนี้มีอีกทางเลือกหนึ่งเรียกว่า 'อุดมคติในวัน' (บางอย่างคล้ายกับวันคน แต่ฉันไม่แน่ใจว่านั่นคือสิ่งที่คุณหมายถึง) และฉันรู้ว่ามีบางทีมที่ชอบมัน วันในอุดมคติจะต้องตีความเป็น:

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

Mike Cohn หนึ่งในผู้ประกาศข่าวประเสริฐที่มีชื่อเสียงหลายคนให้การเปรียบเทียบระหว่างจุดเรื่องราวกับวันในอุดมคติ

คะแนนเรื่องราว

• ช่วยผลักดันพฤติกรรมการทำงานข้ามสายงานเช่นทีมประเมินเรื่องราวที่ซับซ้อนรวมถึงการนำไปปฏิบัติตั้งแต่ UI จนถึง DB และด้านหลัง
• ประมาณการ SP ไม่ได้ลดลงเช่นสองสามเดือนนับจากนี้เรื่องราว 5 จุดยังคงเป็น 5 คะแนน แต่การประเมินวันในอุดมคติอาจเปลี่ยนไปขึ้นอยู่กับทักษะการพัฒนา / ความเร็วของโปรแกรมเมอร์นั้น
• SP คือการวัดขนาดที่แท้จริงนั่นคือมีเพียง แต่สะท้อนความซับซ้อนของขนาดเท่านั้น ระยะเวลา ไม่มีระยะเวลา ฯลฯ โยนมัน นั่นคืองานของความเร็ว แต่ไม่เป็นเช่นนั้นกับวันในอุดมคติ ในความเป็นจริงกับวันในอุดมคติมีแนวโน้มที่จะยุ่งเหยิงกับวันปฏิทิน ทำให้เป็นนามธรรมเมื่อ SPs ต่อสู้กับสิ่งล่อใจเพื่อเปรียบเทียบกับความเป็นจริง เพียงแค่วัดขนาด ไม่มีเรื่องไร้สาระ
• โดยทั่วไปจะเร็วกว่าวันในอุดมคติ มันอาจจะเป็นเรื่องยุ่งยากสำหรับคู่แรกของเรื่อง แต่เมื่อคุณได้รับมันก็จะเร็วขึ้น
• นักพัฒนาซอฟต์แวร์ที่แตกต่างกันสามารถใช้เวลาประเมินวันในอุดมคติที่แตกต่างออกไป ฉันสามารถทำเช่นเดียวกันใน 3 และคุณสามารถใน 5 SPs เป็นเครื่องแบบมากขึ้นหรือน้อยลงทั่วกระดาน พวกเขาเลเวลสนามเด็กเล่นเพื่อพูด

วันในอุดมคติ

• ง่ายต่อการอธิบายนอกทีม ด้วยเหตุผลที่ชัดเจน :)
• ประเมินได้ง่ายกว่าในตอนแรกตามที่กล่าวไว้ข้างต้น แต่เมื่อคุณได้รับการแขวนของ SP มันมาตามธรรมชาติ

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

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

ใช้ตัวอย่างนี้ซึ่งใช้วันคน

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

ทำไม? เนื่องจากประสิทธิภาพของทีมของคุณเพิ่มขึ้น แต่คุณไม่รู้เกี่ยวกับมัน

ตัวอย่างเดียวกันกับคะแนนเรื่องราว:

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

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

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

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

ดังที่นโปเลียนกล่าวว่า: แผนไม่มีราคาการวางแผนเป็นสิ่งที่มีค่า

ประการที่สามผู้จัดการโครงการไม่จำเป็นต้องแก้ไขการประมาณการทั้งหมดเพียงเพราะปรากฎว่าการประมาณการถูกปิดโดยปัจจัยเช่น 130%

คะแนนเรื่องราวสะท้อนถึงความซับซ้อนของปัญหาและดังนั้นจึงสะท้อนความเชื่อมั่น (หรือความเสี่ยง) ของการประมาณการที่ถูกต้อง

เรื่องราวที่มีเรื่องราวสูงบอกฉันว่ามีเรื่องราวมากมายเกี่ยวกับผู้ใช้ที่ไม่เป็นรูปธรรม

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

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

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

ตัวอย่างเช่นถ้าพนักงานขายสามารถโทรหาลูกค้าได้ 20 คนต่อวันโดยเฉลี่ยเราสามารถคำนวณเวลาที่ใช้ในการโทรแต่ละครั้งและจากนั้นเราสามารถประเมินได้ว่าจะใช้เวลากี่วันในการโทร 1,000 ครั้ง

ในตัวอย่างนี้เราสามารถคิดอย่างเป็นรูปธรรมในแง่สถิติเกี่ยวกับความยาวของค่ามัธยฐานของการโทรเพราะการโทรทั้งหมดสามารถสันนิษฐานว่าเป็นสิ่งเดียวกันได้อย่างมีประสิทธิภาพ

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

ตัวอย่างเช่นทีมของคุณพัฒนา 5 ชั้นรวมเป็น 23 คะแนนในการทำซ้ำ 1 และ 8 ชั้นสำหรับ 20 คะแนนในการทำซ้ำ 2 จากนี้คุณสามารถประเมินได้ว่าในการทำซ้ำสองทีมของคุณจะทำเรื่องราวไม่กี่ที่มีทั้งหมดประมาณ 20 คะแนน ในการทำซ้ำ 3.

โปรดทราบว่าเราไม่จำเป็นต้องกำหนดขนาดของจุดใดจุดหนึ่งและโดยเฉพาะอย่างยิ่งไม่มีข้อสันนิษฐานใด ๆ ที่แต่ละเรื่องที่มีขนาดเท่ากันจะใช้เวลาในการพัฒนาเท่ากัน! เราทำงานเฉพาะกับจำนวนเงินและคะแนนต่อการทำซ้ำ ฉันไม่ได้เอ่ยถึงนานเท่าไหร่ซ้ำ

ถ้าคุณเดินขึ้นไปหามนุษย์บนถนนแล้วถามว่า "T-rex ใหญ่แค่ไหน?" คำตอบจะผันผวนแม้ว่ามนุษย์ส่วนใหญ่จะรู้ว่า T-rex คืออะไรมันใหญ่แค่ไหน แต่ก็ไม่มีใครรู้แน่นอน - เพราะเราไม่มีระดับสัมพัทธ์ถึงพื้นฐาน

นั่นเป็นพฤติกรรมที่เกี่ยวกับความรู้ความเข้าใจที่คุณพยายามคาดการณ์และมีวิธีการมากมายที่หมุนรอบด้วย " ฉันเข้าใจแล้ว .. ฉันมีความลับในการพยากรณ์ที่แม่นยำ! " น้ำมันงูสู่มวลชน เมื่อคุณคาดการณ์จริง ๆ แล้วคุณกำลังพูดเกินจริง " ฉันจะอนุญาตให้ x วัน / ชั่วโมง / คะแนนสำหรับการที่จะเสร็จสมบูรณ์ " - ในความรู้สึกการสร้าง "กล่องเวลา" สำหรับเหตุการณ์ที่จะดำเนินการภายใน

สำหรับฉันคะแนนเป็นเพียงการเปลี่ยนขอบเขตในตอนท้ายของวันจนกว่าคุณจะอยู่ในทีมที่มีความสุขที่จะพูดว่า " * เรามี 3 สัปดาห์ต่อการวิ่งและดูดนิ้วหัวแม่มือ ... ฉันคิดว่าเราควรจะยิง ครบ 30 คะแนนในรอบนั้น! ใครอยู่กับฉัน! * "และนั่นก็ลึกเท่าที่คุณไปในการสร้างแบบจำลองการคาดการณ์ - ดี! .. ตามความเป็นจริงคุณแค่ตั้งงบประมาณงบประมาณและนั่นแหละ จากนั้นคุณก็ย้อนกลับไปดูงานที่ทำเสร็จแล้วด้วยความรู้สึกว่า "อึศักดิ์สิทธิ์เราทำ 33 พอยต์ที่วิ่งนั่นเจ๋งมาก" และไม่สามารถทำอะไรได้มากนัก คุณสามารถใช้ความเร็วในการกำหนดความเร็วในการวิ่งกลางคันที่คุณจะได้รับจากงบประมาณของคุณโดยขอให้ outloud " เราได้คะแนน 15 พอยต์หรือยัง"แต่อันตรายที่นี่คือตอนนี้คุณกำลังใช้ Velocity เพื่อวัดประสิทธิภาพการผลิตไม่ใช่ความจุซึ่งจากสิ่งที่ฉันเข้าใจว่าเป็นการจัดการ Reactive Release Management (เนื้อเรื่องจุด) ในหัว ..

ระบบจุดเกือบจะฉลาดเกินไปที่จะไม่แจ้งให้ทราบว่าคุณยังคงแนบเวลาเทียบกับสมการทุกอย่างจากคุณตกลงที่ "รอบวิ่ง" เพื่อ standups ประจำวันของคุณในที่ที่คุณออกกฎหมายกฎบางซ่อนรอบระยะเวลา + ซับซ้อน = " แม็กซ์คือการไปอีกนาน กับภารกิจนั้น "อวัยวะภายในรู้สึกรหัสช่วงเวลาสีแดงทีม?

สมองมนุษย์ไม่สามารถพยากรณ์ได้เพราะมันเกี่ยวข้องกับหน่วยความจำในการทำงานจำนวนมากผสมกับการเรียกคืนในระยะสั้น / ระยะยาวดังนั้นมันเหมือนกับการขอให้นักเรียนคณิตศาสตร์สามเณรทำการเศษส่วนในหัวของพวกเขาไม่ใช่บนกระดาษ ตรวจสอบความถูกต้องของการคาดการณ์ในเวลาที่สัมพันธ์กัน (เช่นนักธรณีวิทยาไม่เคยหยุดการสร้างแบบจำลองการพยากรณ์จนกระทั่งลูกบาศก์เมตรถูกขุดขึ้นมาจากพื้นดินแล้วจึง "ทำ")

ผมว่าระบบจุดทำงานหากคุณไม่ได้คาดการณ์ คุณเห็นด้วยกับชิ้นงานที่ใช้อัลกอริทึมย่อยแบบแยกย่อย แต่นั่นเป็นวิธีการพยากรณ์ที่ใกล้เคียงที่สุดของคุณจริงๆ ในความเป็นจริงคุณกำลังจัดการการเปิดตัวจะมองหาการแบ่งตามธรรมชาติในคิว "งานในมือ" ที่พอดีกับธีม (เช่นใน Silverlight เราผู้จัดการผลิตภัณฑ์จะรอจนกว่าพวกเขาจะทำ Backlog ของพวกเขาจนเสร็จสมบูรณ์ ไม่เคยรู้ว่าทีมวิศวกรรมกำลังทำอะไรโดยเฉพาะเราเพิ่งมีโครงร่างพื้นฐานจากนั้นเราจะนำงานนั้นมาใช้และสร้างกิจกรรมทางการตลาดของเรา (Microsoft Mix)

เมื่อคุณเริ่มล็อคความเร็วความคาดหวังภายในรอบการวิ่งที่ใช้ความเร็ว + เวลาคุณจะกลับไปคาดการณ์การคาดการณ์อีกครั้งในเวลานี้ที่คุณแย่ลงเพราะคุณกำลังเล่น "มันขึ้นอยู่กับเกม" ... ที่สำคัญคุณ กำลังฆ่าศักยภาพในการเติบโตของทีม / การเติบโตในอาชีพด้วยเช่นกัน

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

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

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

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

หลังจากเดินทางไปทั่วโลกในฐานะผู้สอนศาสนาฉันเห็นหลายทีมสาบานตนต่อสิ่งที่พวกเขารักว่าพวกเขาถอดรหัสรหัสพยากรณ์เปรียว ... แต่ฉันคลิกลิ้นของฉันยิ้มและเดินออกไปพร้อมกับความคิด " ใช่ ... คุณเกือบจะได้ แต่ผู้เป็นที่รักเราเรียกว่า 'เวลา' ... เธอโหดร้าย ... "

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

ฉันคิดว่าวิธีการของ Story Point มีข้อดีอย่างน้อยสองข้อที่สำคัญกว่าวิธี Man-day: อย่างแรกมันง่ายกว่าที่จะประมาณใน SP SP นั้นสัมพันธ์กันและมนุษย์อย่างเรานั้นดีกว่าเมื่อเทียบกับการประเมินแบบสัมบูรณ์เช่นวิธีการวัน

ประการที่สองเมื่อคุณประมาณค่า SP คุณจะได้รับ "Team SP" ไม่ใช่ "Manday รายบุคคล" เมื่อคุณถามว่า "งานนี้จะใช้เวลานานเท่าไหร่" ผู้พัฒนาระดับสูงสามารถให้ 1 วัน แต่ 5 วันสำหรับผู้เริ่มต้น นั่นคือ Man-day ขึ้นอยู่กับว่าใครจะทำสิ่งนั้นให้สำเร็จ หากเจ้าของถูกบังคับให้เปลี่ยน (และมันจะ!) คุณต้องกำหนดทุกสิ่งใหม่ ด้วย SP มันยังคงเป็นคนเดิมที่ทำหน้าที่นี้

ฉันประหลาดใจที่ไม่มีใครพูดถึงกฎของพาร์กินสันเลย

งานจะขยายเพื่อเติมเวลาให้เสร็จสมบูรณ์

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

การประเมินจุดเรื่องราวตามฟีโบนักชีซีรีส์ 1,2,3,5,8,13,21 ...

สมองของมนุษย์สามารถแมปสิ่งต่าง ๆ ตามขนาดได้อย่างง่ายดาย ตัวอย่างเช่น: เรามีการ์ดโพสต์และกำหนดให้เป็นจุดเรื่องราว 2 และสามขนาดของการ์ดจะหมายถึง 2 * 3 = 6 จุดเรื่องราว

จุดที่ 6 อยู่ระหว่างหมายเลขฟีโบนักชี 5 และ 8 โดยที่ 5 เป็นจำนวนที่ใกล้เคียงกว่าและด้วยเหตุนี้จุดเรื่องราวจะเป็น 5