จะเรียนรู้วิธีการประมาณการที่ดีขึ้นได้อย่างไร [ปิด]

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

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

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

ฉันคิดว่ามันเป็นประสบการณ์

กฎการจัดการเวลาของเมอร์ฟี: หากต้องการทราบว่าจะใช้เวลานานเท่าใดให้คิดว่าควรใช้เวลานานเท่าใดและเพิ่มเป็นสองเท่า

จากนั้นเลื่อนไปยังหน่วยเวลาถัดไปที่สูงขึ้น ดังนั้นเราจึงจัดสรรสองสัปดาห์สำหรับโครงการหนึ่งวัน

คุณสามารถเรียนรู้โดยการทำพวกเขารวม

ผมใช้การวางแผนโป๊กเกอร์ มันเป็นเทคนิคที่ใช้ฉันทามติสำหรับการประเมิน

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

ทุกครั้งที่คุณประเมินสิ่ง multiplicate โดยความเร็วล่าสุดของคุณที่จะได้รับการประมาณค่าที่ถูกต้อง

การประมาณค่าซอฟต์แวร์โดย Steve McConnell (MS Press) เป็นการอ่านที่ดี

สิ่งสำคัญกับการประเมินซอฟต์แวร์สรุปได้ดังต่อไปนี้

หากไม่มีข้อมูลประวัติประมาณการของคุณไร้ประโยชน์

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

ประเด็นอื่นที่ควรทราบ:

1. มันจะช้าลงเท่านั้น การใช้กฎ 80/20 หมายความว่าการทำงานหนักจะมาในภายหลังเว้นแต่ว่าการจัดการโครงการของคุณจะมีระเบียบวินัยมาก
2. การประมาณ! = การวางแผน การประมาณเป็นกระบวนการในการหาความพยายามที่จะทำให้เสร็จ การวางแผนเป็นกระบวนการของการปรับให้เป็นตาราง
3. ประสิทธิภาพ 60% เป็นเรื่องเกี่ยวกับสิ่งที่คุณคาดหวัง 70% เป็นยูโทเปีย หากคุณประเมินในไม่กี่วันสร้างสิ่งนี้หากคุณกำลังประเมินในไม่กี่ชั่วโมงอย่าลืมนำไปใช้ในภายหลัง
4. จำหางยาว การคาดคะเนเป็นการคาดเดาคร่าวๆว่าจะใช้เวลานานเท่าใดในการปรับระดับความเสี่ยงและความไม่รู้จัก หางยาวเข้ามาเล่นเพราะจำนวนงานที่ต้องการจริงจะไม่น้อยกว่า 0 OTOH จำนวนเวลาสูงสุดที่ใช้จะ จำกัด เพียงระยะเวลาที่คุณยินดีจ่ายก่อนที่จะยอมแพ้ ในฐานะอดีตหัวหน้าของฉันบอกว่า "การประมาณการทั้งหมดเป็น +/- x% และไม่เคยลบ"

ฉันประหลาดใจที่ไม่มีใครกล่าวถึงเทคนิคการประมาณค่า PERT สไตล์ที่อธิบายไว้ในโรเบิร์ตมาร์ตินสะอาด Coder ในวิธีการนั้นคุณประเมินว่าจะใช้เวลานานเท่าไรใน 3 สถานการณ์: มองโลกในแง่ดี ( O), เล็กน้อย ( N) และมองโลกในแง่ร้าย ( P) จากนั้นในช่วงระยะเวลาที่คาดว่าจะ = และคุณได้รับค่าเบี่ยงเบนมาตรฐาน(O+4N+P)/6(P-O)/6

ดูเหมือนว่าจะทำงานได้ดีและฉันใช้มันสองสามครั้งเมื่อผู้บริหารใส่ใจจริงๆว่าจะต้องใช้เวลานานแค่ไหน

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

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

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

หากฉันต้องทำประมาณชั่วโมงฉันพยายามที่จะทำเพียงสำหรับงานเล็ก ๆ ภายในการทำซ้ำ ฉันวัดทุกอย่างในเวลาประมาณครึ่งวัน (4, 8, 12 ชั่วโมง) เว้นแต่ฉันจะรู้ว่าอาจน้อยกว่านี้ แต่ฉันไม่ค่อยประมาณอะไรเลยที่น้อยกว่า 1 ชั่วโมง

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

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

ประการที่สามเวลาติดตาม (ความพยายาม) อย่างน้อยคุณควรแยกความแตกต่าง:

• การวิเคราะห์
• ออกแบบ
• รหัส
• การทดสอบหน่วย (รวมถึงการแก้ไขข้อบกพร่อง)
• การทดสอบการรวม (รวมถึงการแก้ไขข้อบกพร่อง)

• การทดสอบการยอมรับกับผู้ใช้ (รวมถึงการแก้ไขข้อบกพร่อง)

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

ประการที่สี่ระบุรายการฐานหลักสำหรับการประเมิน ตัวอย่างเช่น:

• จำนวนกระบวนการที่จะเป็นอัตโนมัติ (การวิเคราะห์)
• จำนวนเอนทิตีโมเดลโดเมน (ออกแบบ)
• จำนวนฟอร์มและรายงาน (รหัส)

ประการที่ห้ารายการฐานที่เกี่ยวข้องและความพยายาม ตัวอย่างเช่น:

• ความพยายามในการวิเคราะห์ = X man-hours / กระบวนการให้เป็นอัตโนมัติ
• ความพยายามในการออกแบบ = Y ตัวแบบชั่วโมงทำงาน / เอนทิตีโมเดลโดเมน
• ความพยายามของรหัส = Z คน / ชั่วโมงแบบฟอร์ม (หรือรายงาน); จำนวนฟอร์ม = A * เอนทิตีโมเดลโดเมน
• ความพยายามในการทดสอบหน่วย = M% * ความพยายามในการใช้รหัส
• ความพยายามในการทดสอบการรวม = N% * ความพยายามในการใช้รหัส
• ความพยายามในการทดสอบการยอมรับ = P% * การใช้รหัส

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

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

ดูที่http://en.wikipedia.org/wiki/Personal_Software_Processได้ผล

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

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

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

มันเหมือนกับการยิงเป้า ภาพก่อนหน้าโดยประมาณควรบอกให้คุณรู้ว่าคุณมีเครื่องหมายอย่างไรเพื่อให้คุณสามารถแก้ไขได้

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

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

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

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

หากคุณสามารถย่อยสลายโครงการเป็นงานที่มีขนาดเล็กลงและทำการประมาณสำหรับโครงการที่คุณจะมีความแม่นยำมากขึ้น งานใดที่ใหญ่กว่าสองสามวันควรจะถูกทำลายอีก หากคุณไม่สามารถทำลายมันได้มากกว่าที่คุณต้องการช่องว่างความต้องการ หากคุณต้องประเมิน back-of-the-the-Napkin สำหรับความต้องการแบบบรรทัดเดียว ... ไม่มีอะไรสามารถช่วยคุณได้มากนัก น่าเศร้าที่ร้านค้าจำนวนมากทำงานในลักษณะนี้บ่อยครั้ง

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

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

• เพิ่มงานสำหรับการวางแผนและออกแบบ (ซึ่งรวมถึงสิ่งที่คุณทำอยู่ตอนนี้) ประเมินงาน

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

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

• เพิ่มค่าประมาณการงานเพื่อรับค่าประมาณโดยรวม

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

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

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

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

สูตรที่ใช้งานได้เมื่อทำงานเพื่อตัวเอง:

1. ทำรายละเอียดสิ่งที่ต้องทำเป็น 1 - 4 ชั่วโมงละเอียด ฉันพบว่าฉันมักจะแม่นยำกับสิ่งเหล่านี้

2. the 'unknowns factor': คูณด้วย 2 คูณด้วยจำนวน unknown คือถ้าคุณต้องการพัฒนาแอพพลิเคชั่น couchdb แต่ตอนนี้รู้อะไรเกี่ยวกับจาวาสคริปต์และ http .. เพิ่ม 2 ^ 2 เป็นหลายปัจจัย

3. context-switch-factor: หลายคูณ 1.5 ถ้าคุณจะทำงานในสภาพแวดล้อมที่สมบูรณ์แบบ (ที่บ้านในมุมศึกษา ฯลฯ ) หรือ 2.5 ถ้าคุณจะทำงานในสภาพแวดล้อมที่ไม่สมบูรณ์ (สำนักงาน / สถานที่แออัด ฯลฯ )

ฉันคิดว่านี่น่าจะอยู่ในช่วง +/- 20% ของเวลาจริง !!

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

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

สำหรับ openers อ่าน "เศรษฐศาสตร์วิศวกรรมซอฟต์แวร์" โดย Barry Boehm และ "การควบคุมโครงการซอฟต์แวร์" โดย Tom DeMarco หลังจากคุณอ่านและย่อยทั้งสองแล้วให้อ่าน "การประมาณการต้นทุนซอฟต์แวร์ด้วย COCOMO 2" โดย Barry Boehm

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

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

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

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