ใครควรเข้าร่วมการประเมินเวลา

ในโครงการ IT:

1. ใครควรเข้าร่วมการประเมินเวลา นักพัฒนาหัวหน้าทีม scrum master และอื่น ๆ ?
2. ใครควรนับคะแนนมากที่สุด?

มันไม่ได้เกี่ยวกับคนที่เกี่ยวข้องมากเท่าทักษะที่จำเป็นต้องมีอยู่:

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

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

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

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

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

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

(a) อย่าไปกับหมายเลขที่คุณ "ต้องการ" มันแค่ขอปัญหาและสิ่งที่คุณต้องการไม่มีผลกระทบอย่างมีนัยสำคัญกับวิธีการทำงานได้อย่างรวดเร็ว

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

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

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

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

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

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

โครงการมีข้อกำหนดทางธุรกิจและกำหนดส่งที่มาจากบนลงล่าง นี่คือ "การประมาณที่กำหนด" สำหรับการคำนวณซ้ำครั้งแรก

ข้อกำหนดเหล่านี้ต้องได้รับการแบ่งพาร์ติชันให้เป็นงานที่ใหญ่ที่สุดซึ่งมีค่าใช้จ่ายที่ทราบ 100% (เช่น "เปิดใช้งานการบันทึก" = 2 ชั่วโมง = "ดาวน์โหลดlog4j / SLF4Jและปลั๊กอิน")

การประเมินควรทำในระดับสูงสุดที่เป็นไปได้ซึ่งมีความเชี่ยวชาญด้านเทคนิคเพียงพอที่จะทำเช่นนั้น

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

ใครหรือใครควรมีส่วนร่วมในการประเมินเวลา? นักพัฒนาหัวหน้าทีม scrum master และอื่น ๆ ?

ฉันชอบให้ทุกคนอยู่ในการประมาณเวลาและเราก็ทำเช่นเดียวกันที่นี่

ใครควรลงคะแนนเสียงมากที่สุด?

นักพัฒนา แต่ก็ยังคงทำงานเกี่ยวกับทีมทั้งหมด

นักพัฒนาที่ถูกเรียกเก็บเงินจากการใช้งานโครงการ! ไม่มีใครอื่น!

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

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

Rule of thumb: จะใช้เวลาอย่างน้อย 3 เท่าของการประเมินผู้จัดการโครงการหรือบุคคลธุรกิจที่ไม่คุ้นเคยอย่างใกล้ชิดกับความท้าทายของการพัฒนาและฐานรหัสที่เป็นปัญหา

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