การประมาณราคาเวลาใน codebase แบบเก่า

เมื่อเร็ว ๆ นี้ฉันเริ่มทำงานกับโปรเจ็กต์ที่มีการย้ายแอพพลิเคชั่นแบบเสาหินเก่าไปสู่สถาปัตยกรรมแบบไมโครเซอร์วิส

Legacy codebase นั้นยุ่งเหยิงมาก('รหัสสปาเก็ตตี้')และมักจะเป็นฟังก์ชั่นที่เรียบง่าย (เช่นชื่อ "multiplyValueByTen") ต่อมาเผยให้เห็นตัวเองว่า

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

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

ฉันจะเข้าใกล้สถานการณ์แบบนี้ได้อย่างไร

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

อ่าน "Clean Coder" ของ Bob Martin (และ "Clean Code" ขณะที่คุณอยู่ในนั้น) ต่อไปนี้มาจากหน่วยความจำ แต่ฉันขอแนะนำให้คุณซื้อสำเนาของคุณเอง

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

• สถานการณ์กรณีที่ดีที่สุด - สมมติว่าทุกอย่างถูกต้อง (a)
• สถานการณ์กรณีที่เลวร้ายที่สุด - สมมติว่าทุกอย่างผิดพลาด (b)
• การคาดเดาที่เกิดขึ้นจริง - สิ่งที่คุณคิดว่าอาจจะใช้ (c)

ค่าประมาณของคุณคือ (a + b + 2c) / 4

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

แก้ไข:

สมมติฐานของฉันเมื่อฉันตอบนี้:

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

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

ลองทำตัวอย่างที่ใช้งานได้:

• กรณีที่ดีที่สุดจากประสบการณ์ที่เร็วที่สุดที่ฉันเคยทำมาตรงไปตรงมาจริงๆคือสัปดาห์ที่จะเริ่มต้นให้เสร็จ (5 วัน)
• จากกรณีที่เลวร้ายที่สุดจากประสบการณ์มีช่วงเวลาที่มีการเชื่อมโยงทุกที่และในที่สุดก็พาฉันไป 6 สัปดาห์ (30 วัน)
• การประมาณจริงอาจใช้เวลา 2 สัปดาห์ (10 วัน)

5 + 30 + 2x10 = 55

55/4 = 13.75 ซึ่งเป็นสิ่งที่คุณบอก PM ของคุณ บางทีคุณอาจใช้เวลาถึง 14 วัน เมื่อเวลาผ่านไป (เช่นสิบงาน) มันควรจะเฉลี่ย

อย่ากลัวที่จะปรับสูตร บางทีครึ่งหนึ่งของงานฝันร้ายและมีเพียงสิบเปอร์เซ็นต์ที่ง่าย ดังนั้นคุณจึงทำให้ estmate a / 10 + b / 2 + 2c / 5 เรียนรู้จากประสบการณ์ของคุณ

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

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

• 0 - ทันที
• 0.5 - การชนะที่รวดเร็ว
• 1 - การเปลี่ยนแปลงง่าย ๆ
• 2 - การเปลี่ยนแปลงง่ายๆสองสามอย่าง
• 3 - ท้าทายมากขึ้น
• 5 - จะต้องมีการคิดเกี่ยวกับ
• 8 - งานจำนวนมาก
• 13 - ชิ้นใหญ่ที่อาจต้องพัง
• 20 - ชิ้นงานขนาดใหญ่ที่ต้องถูกทำลายลงอย่างแน่นอน

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

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

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

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

ถ้าอย่างนั้นคุณจะไปซื้อหนังสือสักเล่ม

1. การประมาณค่าซอฟต์แวร์: ทำให้เข้าใจถึงศาสตร์มืดโดย Steve McConnell
2. ทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกโดย Michael Feathers

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

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

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

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

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

คุณอาจจะคิดในกล่องของการส่งหนึ่งในการประมาณค่า ฉันต้องทำงานในรหัสดั้งเดิมและเมื่อฉันทำการประมาณเป็นทางการมากขึ้นฉันมักจะทำสองหรือสาม :

1. ประมาณการเบื้องต้น - สมมติว่าฉันต้องใช้เวลาขุด แต่สถาปัตยกรรมอนุญาตให้เปลี่ยนแปลงตามที่เราต้องการ
2. Angelic Estimate - สมมติว่าทุกอย่างโปร่งใส / หาง่ายและฉันต้องทำการเปลี่ยนแปลงเล็กน้อย (นี่คือสิ่งที่ฉันออกไปบางครั้ง ... โดยเฉพาะอย่างยิ่งถ้าฉันรู้ว่ามีปีศาจในฐานรหัสเฉพาะเท่านั้น)
3. Abyssal Estimate - สมมติว่าโครงสร้างพื้นฐานของรหัสดั้งเดิมนั้นไม่สอดคล้องกับคุณสมบัติที่ร้องขอและฉันจะทำการปรับโครงสร้างครั้งใหญ่เพื่อให้สิ่งต่าง ๆ ทำงานได้

ทั้งสามประมาณการคำนึงถึงวิธีการที่ยากคุณลักษณะที่อยู่ในตัวของมันเองประสบการณ์ใด ๆ ที่ฉันเคยมีกับฐานรหัสทั่วไปและลำไส้ของฉันรู้สึกเกี่ยวกับการเปลี่ยนแปลง (ซึ่งผมได้พบสามารถมีความถูกต้องมาก)

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

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

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

มีกุญแจอยู่สองสามตัวสำหรับสิ่งนี้:

• โน้มน้าวหัวหน้าว่าค่าประมาณเหล่านี้ถือว่าเป็นบทสนทนาที่ดีกว่าเพราะคุณจะได้เรียนรู้เพิ่มเติมเกี่ยวกับงานที่ดูเหมือนในขณะที่คุณทำงาน นี่เป็นโอกาสสำหรับหัวหน้าของคุณที่จะมีข้อมูลที่พวกเขาจะไม่มีหากพวกเขาถามถึงการประมาณค่าเพียงครั้งเดียว
• เสนอทางเลือกว่าจะก้าวไปข้างหน้าความเร็วการพัฒนารหัสการค้าอย่างไรกับการปรับปรุงการประมาณการ ให้ลูกบิดพิเศษแก่พวกเขาที่สามารถหมุนได้ บางครั้งผู้บังคับบัญชารู้งานที่ต้องทำและพวกเขาเพียงแค่ประมาณ ballpark ในบางครั้งพวกเขากำลังใช้ข้อดีข้อเสียของงานและความสามารถในการปรับแต่งการประมาณการนั้นมีค่า
• ถ้าเป็นไปได้ฉันจะเสนอโบนัสการทำงานร่วมกันด้วย บ่อยครั้งที่มีการปรับปรุงสถาปัตยกรรมที่จะเป็นประโยชน์ต่องานหลายอย่าง หากฉันมี 10 ภารกิจซึ่งทั้งหมดใช้เวลา "1-2 เดือน แต่จะใช้เวลา 2 สัปดาห์ในการอัพเกรด X" ง่ายกว่าที่จะขายใน 20 สัปดาห์ซึ่งอาจใช้เวลาในการอัพเกรด X

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

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

และ

กฎของ Hofstadter: "มันใช้เวลานานกว่าที่คุณคาดไว้เสมอถึงแม้คุณจะคำนึงถึงกฎหมายของ Hofstadter"

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

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

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

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

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

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

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

เราใช้การวิเคราะห์พฤติกรรมสำหรับการประเมินคุณสมบัติในโครงการดินแดน A: เราประมาณว่านานแค่ไหนก็จะได้รับการดำเนินการในลักษณะโครงการกรีนฟิลด์ว่าไม่มีอะไรที่ดำเนินการแล้ว จากนั้นเราคูณค่าประมาณนั้นด้วย 2 เพื่อจัดการกับการทำความสะอาดเศษซากที่มีอยู่แล้ว

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

ฉันคิดว่าคุณควรนั่งลงกับเจ้านายของคุณดูเขาในสายตาและพูดว่า:

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

ใช้การชี้แนะที่มั่นคงอย่างแน่วแน่เช่นชี้และนั่งลงบนเก้าอี้ของคุณ

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