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

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

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

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

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

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

สิ่งแรกคือการประมาณ การประมาณตัวเองไม่ใช่ตัวเลขเดียวนั่นคือข้อผูกพัน "ABC ใช้เวลานานแค่ไหน" -> "ประมาณ 5 วัน" หมายความว่าจะใช้เวลาประมาณ 5 วัน อย่างไรก็ตามการประมาณที่ดีคือช่วงที่คุณมั่นใจ 90% ว่าคุณจะมีช่วงนั้น ถ้าคุณตั้งใจจะพูดว่า "ฉันมั่นใจ 90% ว่าจะต้องใช้เวลา betwene 1 และ 5 วัน" จากนั้นพูดอย่างนั้น อย่าทำงานจาก "ฉันคิดว่ามันจะใช้เวลาระหว่าง 1 ถึง 10 วันดังนั้น 5 วันน่าจะเป็นค่าเฉลี่ย" - นั่นไม่ใช่ค่าประมาณและคุณผิด 50% ของเวลา

50% หรือมากกว่านั้นโปรแกรมเมอร์เป็นผู้ประเมินที่ต่ำต้อยในเวลางาน

พิจารณากรวยแห่งความไม่แน่นอน:

^{_{ภาพจากhttp://www.construx.com - บทความเต็มรูปแบบที่http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/}}

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

ด้วยการประมาณแต่ละครั้งที่คุณให้คุณต้องแน่ใจว่า 90% ของการประมาณการนั้นอยู่ในช่วงนั้น คุณสามารถผิด - 10% ของเวลาที่มันจะหลุดออกจากช่วงนั้น

มีหลายวิธีในการประเมินขนาดของโครงการ เปรียบเทียบกับโครงการที่ผ่านมาโดยใช้พร็อกซี (ฉันคิดว่ามันจะใช้รหัส 1,000 บรรทัดซึ่งใช้เวลานานในการเขียน) โดยใช้ฟังก์ชั่นคะแนน (แปลงเป็น LOC ... ) รับการประเมินจากผู้คนจำนวนมากแล้ว ปรับแต่งซ้ำแล้วซ้ำอีก ... งานบางอย่างสำหรับบางโครงการบางงานสำหรับโครงการอื่น ๆ

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

กุญแจสำคัญในการประมาณค่าเป็นกระบวนการวนซ้ำของการปรับแต่งหลังจากทำงานเล็กน้อย

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

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

จากวิธีการตอบสนองเมื่อคุณถูกขอให้ประมาณ?

จะพูดอะไรเมื่อถูกขอให้ประมาณ

คุณพูดว่า "ฉันจะกลับไปหาคุณ"

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

จากบทที่ 4 ของการประมาณค่าซอฟต์แวร์:

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

บอส : เอเจเรามีสุนัข 3 ตัวกระต่าย 2 ตัวหนังสติ๊กและแม่ชี เราจำเป็นต้องหาวิธีที่จะได้รับทั้งหมด 7 (ใช่หนังสติ๊กเกินไป) ข้ามกำแพง 20 ฟุตและเข้าไปในทะเลสาบในด้านอื่น ๆ โดยไม่ต้องสุนัขกินกระต่ายใด ๆ และโดยไม่ต้องจมน้ำแม่ชี ใช้เวลานานแค่ไหนในการแก้ปัญหา?

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

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

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

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

ฉันอยากจะแนะนำให้คุณลองทำอะไรสักอย่างระหว่างคำตอบของtylerlและMichaelTกับสิ่งต่อไปนี้:

• แบ่งงานที่จะทำใน 3 หรือ 4 ขั้นตอน ระยะควรเป็น:
  1. การวิเคราะห์ปัญหา
  2. การสร้างต้นแบบโซลูชัน
  3. ทางออกโลกแห่งความจริง
  4. การประเมินผลการทดสอบ (ทดสอบ)
• จัดเตรียมการประมาณสำหรับเฟส 1 (การวิเคราะห์) ตามประสบการณ์ของคุณหรือเฟส 1 + 2 (การวิเคราะห์ + ต้นแบบ) เพื่อการจัดการของคุณ จากนั้นจัดเตรียมการประมาณสำหรับเฟส 3 + 4 เมื่อขั้นตอนปัญหา 1 และ 2 เสร็จสิ้น (หรืออย่างน้อยขั้นสูงเพียงพอเพื่อให้คุณมั่นใจในการประเมิน)

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

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

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

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

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

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

จากนั้นภารกิจที่แท้จริงคือการคิดถึงวิธีแก้ปัญหาการปรับใช้และแนวทางที่เป็นไปได้

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

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

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

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

การจับเวลาโดยทั่วไป