ความสามารถส่วนบุคคลควรได้รับการพิจารณาในประเด็นหรือไม่


11

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

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

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

ฉันขอขอบคุณที่อ้างอิงอย่างเป็นทางการในคำตอบ แต่ความคิดเห็นธรรมดา ๆ ก็ดีเช่นกัน

คำตอบ:


9

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

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

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

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


1
การเปรียบเทียบฉันชอบใช้การประมาณขนาดของกองทราย สมาชิกของทีมแต่ละคนมีพลั่วขนาดแตกต่างกันและดังนั้นจะย้ายกองทรายในอัตราที่แตกต่างกัน แต่ในฐานะที่เป็นทีมเราสามารถเห็นด้วยกับสิ่งที่ใหญ่โตนี้ก่อนที่เราจะเริ่มพรวนดิน? นั่นคือสิ่งที่เรื่องราวมีไว้สำหรับ
Greg Burghardt

7

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

แต่นั่นเป็นสาเหตุของปัญหาในทางปฏิบัติทุกประเภท จะเกิดอะไรขึ้นถ้าคุณไปเที่ยวพักผ่อนในสัปดาห์นั้น จะเกิดอะไรขึ้นเมื่อเวลาในการตรวจสอบเกิดขึ้นและคุณรู้ว่าคุณผลิตคะแนนเฉลี่ย 200% ของเงินเดือนเฉลี่ย 110% จะเกิดอะไรขึ้นเมื่อธุรกิจเริ่มคิดว่าความเร็วของทีมที่หารด้วยผู้คนเป็นความจริงโดยประมาณที่ถูกต้อง? จะเกิดอะไรขึ้นเมื่อธุรกิจตระหนักว่าคุณกำลังสร้างข้อบกพร่องมากกว่าเพื่อน (ในขณะที่เพิกเฉยต่อคุณสร้างวิธีการทำงานที่มากขึ้น) อะไรคือเรื่องราวที่ "กัดขนาด" เมื่อผู้คนมีการกัดที่แตกต่างกันเช่นนี้?

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

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


ขอบคุณสำหรับคำตอบ. ฉันคิดว่าประเภทของปัญหาที่คุณพูดถึงไม่เกี่ยวข้องกับสถานการณ์ปัจจุบันของฉัน: นายจ้างปัจจุบันของฉันจัดการแยกระหว่าง devs และธุรกิจได้เป็นอย่างดีและสิ่งต่าง ๆ เช่น "ถ้าคุณไปเที่ยวพักผ่อน?" แก้ไขได้อย่างง่ายดายด้วยการปรับภาระผูกพันการวิ่งระหว่างการวางแผน
henrebotha

"ในที่สุดพวกเขาก็ทำคะแนนสำหรับกระบวนการที่คุณต้องปรับให้เข้ากับสภาพแวดล้อมของคุณ" ... นั่นคือ +1
svidgen

5

TL; DR
เราควรสันนิษฐานไว้เสมอว่านักพัฒนาที่มีความสามารถเท่านั้นที่จะได้รับมอบหมายให้กับเรื่องใดเรื่องหนึ่ง

ความสามารถ (หรือขาดความสามารถ) ไม่ได้เป็นการดูถูก มันเป็นเพียงการวัดทักษะทักษะของนักพัฒนาที่ไม่ได้ล้าหลังหรือมีประสบการณ์เป็นพิเศษ


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

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


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

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

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

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

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

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

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

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

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


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

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


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

4

นี่คือหัวข้อที่ซับซ้อนและมีการอภิปรายบ่อยครั้งในหัวข้อ ฉันไม่ชอบแนวคิดของความคิดเห็น "บัญญัติ" ในเรื่องนี้: มีความคิดเห็นต่างๆที่มีคุณค่า แต่มีค่านิยมหลักการและแนวทางปฏิบัติที่ควรเป็นแนวทางแนวทาง

ต่อไปนี้ขึ้นอยู่กับความคิดเห็นของฉันเองที่ทำงานกับทีมต่อสู้มานานกว่า 10 ปี แต่มันเป็นเพียงความเห็นของฉัน

  1. คะแนนเรื่องราวเป็นวิธีการพยากรณ์ความตั้งใจดั้งเดิมของคะแนนเรื่องราวคือการหาวิธีที่รวดเร็วในการประเมินความพยายามโดยมีวัตถุประสงค์ในการคาดการณ์ว่าทีมสามารถทำอะไรได้บ้างในช่วงระยะเวลาหนึ่ง สถานะ "ผู้ทรงคุณวุฒิ" บางจุดที่ใช้เพื่อคาดการณ์ขอบเขตระยะยาวเท่านั้น (เช่นการปล่อยตัวอย่าง) และไม่พิจารณาความจุที่ระดับการวิ่ง นอกจากนี้แนวคิดคือทีมกำลังใช้ "การปรับขนาดสัมพันธ์" ตามค่าในอดีต (Effort X คล้ายกับ Effort B ซึ่งเป็น 3 คะแนน) วิธีนี้ช่วยเร่งกระบวนการประเมินให้เร็วขึ้นเพื่อให้ทีมไม่ต้องแยกงานในอนาคตออกเป็นแพ็คเกจงานโดยละเอียดและใช้เวลากับงานทั้งหมด ทีมที่มีประสิทธิภาพสูงพยายามที่จะพัฒนาคนงานด้านเทคนิคทั้งหมดให้เป็นสมาชิกที่มีความสามารถระดับเดียวกัน (แนวคิดนี้จะได้รับการสำรวจเพิ่มเติมในจุดที่ 4) เมื่อสิ่งนี้บรรลุผลแล้วระดับความสามารถเฉพาะบุคคลนั้นไม่ใช่ตัวแปรในการปรับขนาด แต่: มันมักจะใช้เวลาค่อนข้างนานและพยายามร่วมกันเพื่อให้บรรลุเป้าหมายนั้น ดังนั้น ... เราจะทำอย่างไรก่อนที่เราจะไปที่นั่น?

  2. ชั่วโมงงานกำหนดความสามารถในการวิ่ง: ตาม "ผู้ทรงคุณวุฒิ" คนเดียวกันซึ่งระบุว่ามีการใช้คะแนนสำหรับการพยากรณ์ระยะยาวพวกเขายังเสนอว่าจะใช้ชั่วโมงงานเพื่อกำหนดความสามารถในการวิ่งแทนที่จะเป็นคะแนน ในความเห็นของฉันมันเป็นเรื่องดี แต่ฉันจะบอกว่าเมื่อฉันได้ช่วยทีมโค้ชให้ "ประสิทธิภาพสูง" ทักษะการปรับระดับของพวกเขาออกมาเฉลี่ยที่พวกเขาสามารถกำหนดสิ่งที่พวกเขาสามารถทำได้อย่างสมบูรณ์ในการวิ่งด้วยคะแนนเรื่องราวเท่านั้น . อีกครั้งนั่นอาจเป็นเป้าหมายที่เรามุ่งมั่น แต่ทีมใหม่ไม่พร้อมสำหรับเรื่องนั้น ดังนั้นคุณอาจพบเรื่องราวหนึ่งเดียวที่มี 2 คะแนนซึ่งมีความพยายาม 12 ชั่วโมงและอีก 25 ชั่วโมงที่มีความพยายาม แล้วคุณจะทำอย่างไร? บางคนที่ฉันเรียกว่า "agile-purists" จะระบุว่าขนาดของเรื่อง (เป็นคะแนน) ควรไม่เชื่อเรื่องพระเจ้าในระยะเวลา คนอื่นไม่เห็นด้วย อ่านตรรกะในข้อ 3 และดูว่าคุณคิดอย่างไร

  3. การเล่าเรื่องตามฉันทามติ: การใช้ปริมาณความรู้ความซับซ้อนความรู้

ดังนั้นทีมจะต้องดูงานและต้องเห็นด้วยกับประเด็นที่จะเป็นตัวแทนของระดับความพยายาม ขวา? สมมติว่าทักษะทั้งหมดเท่ากันจากนั้นฉันทามติเข้าถึงได้ง่าย แต่บ่อยครั้งที่ทีมมีคนที่แต่งตัวประหลาดที่เป็นกูรู Java อีกคนที่ไม่ดีใน Java (บางทีเธออาจเป็น C # หรือ. Net หรือ Cobol และเรียนรู้ Java) task X สำหรับ Bob นั้นง่ายมาก สำหรับเจนมันยากขึ้น

ทีมเปรียวพยายามที่จะส่งเสริมการเป็นเจ้าของรหัสส่วนรวมและการเพิ่ม / ขยายความเชี่ยวชาญ ดังนั้นเรามักจะไม่มอบหมายเรื่องให้กับผู้คนตามความเชี่ยวชาญของพวกเขา: เราต้องการให้ทีมทำงานร่วมกันในเรื่องและเรียนรู้ร่วมกัน สิ่งนี้สอดคล้องกับแนวคิดของ "ช้าลงเพื่อเร่งความเร็ว": ถ้าเราใช้เวลาในการให้ประสบการณ์ของเจนกับ Java ในขณะที่สิ่งนี้อาจทำให้เราช้าลงในตอนแรกหลังจากนั้นเราจะมีนักพัฒนา Java ที่มีความสามารถมากกว่า ในความเป็นจริงถ้าเรามีผู้เชี่ยวชาญชวาเพียงคนเดียวและทุกคนทำงานด้วยความเชี่ยวชาญของตัวเองเรากำลังสร้างสถานการณ์ที่มี "ความล้มเหลว" ที่อาจเกิดขึ้นได้ จะเกิดอะไรขึ้นในการวิ่งเมื่อ 90% ของงานเป็น Java แต่ Bob (ผู้เชี่ยวชาญด้าน Java ของเรา) ป่วยหรือพักร้อน? ด้วยการขยายทักษะทำให้เราขจัดปัญหาคอขวดที่อาจเกิดขึ้นและลดความเสี่ยง โดยที่ในใจ: เมื่อทีมดูเรื่องพวกเขาควรมีแนวคิดหลายอย่างในใจเมื่อปรับขนาด คุณสามารถคิดถึงคำย่อ VUCK เพื่อจดจำสิ่งนี้

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

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

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

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

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

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

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

ดังนั้นถ้าเจนอาสาที่จะใช้ความพยายามของจาวาและนั่นก็จะทำให้ความพยายามเท่าเดิม 2x หรือ 3x ระยะเวลาของความพยายามเดียวกันถ้าบ๊อบทำเช่นนั้นคุณจะทำอะไร? เมื่อเวลาผ่านไปทีมของฉันตัดสินเรื่องการปรับขนาดตามระดับของความพยายาม (LOE) / VUCK สำหรับคนที่ทำงานด้วยความพยายาม บ๊อบทีมคุรุไม่มีเหตุผลที่จะพูดว่า "นั่นคือ 1" เมื่อเจนจะไม่สะดวกและต้องใช้เวลาหนึ่งสัปดาห์จึงจะเสร็จสมบูรณ์และต้องใช้เวลาของ Bob ในการเขียนรหัสคู่และตรวจสอบรหัส ดังนั้นเราจึงชนคะแนนเหล่านั้นเพื่อสะท้อน LOE จริง ครั้งต่อไปที่มีเรื่องราวคล้ายกันเกิดขึ้นก่อนหน้านี้สิ่งที่ 8 สำหรับเจนกลายเป็น 5 ในที่สุดทุกคนเห็นด้วยว่ามันเป็นเรื่องง่าย 3. ณ จุดนั้นเรารู้ว่าเราเติบโตขึ้นเป็นทีม


0

TLDR

ไม่ แต่อาจไม่ใช่เพราะเหตุผลที่คุณคิด

รุ่นยาว

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

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

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

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

ไม่มี "ฉัน" ในทีมและไม่แน่นอนในการวางแผนที่คล่องตัว!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.