สารบัญ:
การประมาณโครงการซอฟต์แวร์
Pixabay
บทนำ
การประมาณค่าเป็นเรื่องยาก น่าเสียดายที่มันจำเป็นมากเช่นกัน บริษัท ต่างๆใช้การประมาณเพื่อคาดการณ์กำหนดการวางจำหน่ายให้คำมั่นสัญญากับลูกค้าตัดสินใจว่าคุณลักษณะที่นำเสนอนั้นคุ้มค่าต่อการนำไปใช้หรือไม่ติดตามความเร็วของทีมและจัดลำดับความสำคัญของงานอย่างมีประสิทธิภาพ ผู้บริหารมักต้องการทราบว่าคุณลักษณะหรือสิ่งที่ส่งมอบได้จะพร้อมสำหรับการผลิตเมื่อใด ท้ายที่สุดแล้วการพัฒนาซอฟต์แวร์ไม่ใช่การลงทุนเล็กน้อย หากไม่มีการประมาณการผู้จัดการโครงการจะทำการประเมินอย่างไร หากมนุษย์สามารถทำนายอนาคตได้อย่างแม่นยำผู้คนจะไม่ชนะในการแข่งม้า 2% ของเวลา การประมาณค่าเป็นปริศนาที่ยิ่งใหญ่ เป็นเรื่องสำคัญและจำเป็นสำหรับ บริษัท ที่จะขอให้คนของพวกเขาทำสิ่งที่เป็นไปไม่ได้นั่นคือทำนายอนาคต
ก่อนอื่นเรามาดูวิธีการประมาณยอดนิยม (ในกรณีที่คุณพลาดความตื่นเต้นบางอย่าง) จากนั้นเราสามารถดูว่าสิ่งนี้มีความหมายต่อเราและโครงการของเราอย่างไร
รุ่นหมอดู
แบบจำลองนี้แทบไม่ต้องใช้ความพยายามในการสร้างค่าประมาณ ผู้ประมาณการคิดสักเล็กน้อยเกี่ยวกับสิ่งที่ต้องทำเพื่อใช้งานและทดสอบคุณลักษณะจากนั้นจึงโยนตัวเลขออกไป ฟังดูเหมือน“… (หยุดยาว)… อืมมมม… 6 สัปดาห์” จากนั้นทุกคนก็พยักหน้าแล้วเราก็เดินต่อไป พวกเขาสามารถใช้เวลาส่วนหน้าในการพูดคุยผ่านสิ่งที่พวกเขารู้เกี่ยวกับข้อกำหนด (ซึ่งอาจไม่ใช่ภาพที่สมบูรณ์) การวิเคราะห์อย่างรอบคอบนี้ทำให้การประมาณการของพวกเขามีความน่าเชื่อถือมากขึ้น ในตอนท้ายของโครงการมีเหตุผลที่ยอมรับได้เสมอว่าเหตุใดการประมาณการจึงห่างไกลจากความเป็นจริง มีสถานการณ์ที่ไม่คาดฝันอยู่เสมอที่สามารถเป็นแพะรับบาปได้ มักไม่เกิดขึ้นกับทุกคนที่แบบจำลองมีข้อบกพร่องอย่างรุนแรง
แล้วเราจะทำให้กระบวนการนี้ดีขึ้นได้อย่างไร? ฉันรู้ว่า! เราสามารถใช้เทคนิคการสลายตัว (เช่นแบ่งและพิชิต) วิธีนี้จะถือว่าคุณทราบขอบเขตทั้งหมดของคุณลักษณะหรือโครงการที่ส่วนหน้า คุณลักษณะทุกอย่างแบ่งออกเป็นชิ้นขนาดพอดีคำ แต่ละชิ้นมีค่าประมาณ (สไตล์หมอดู) จากนั้นเราจะเพิ่มเข้าไปเพื่อรับค่าประมาณคุณลักษณะ / โครงการโดยรวม นี่เป็นแนวทางที่ซับซ้อนกว่าอย่างแน่นอน แต่ดูเหมือนจะดีกว่าด้วยเหตุผลสองประการ:
- งานที่มีขนาดเล็กมักจะประเมินได้ง่ายกว่าอย่างน่าเชื่อถือ
- ในขณะที่ยังมีโอกาสเกิดข้อผิดพลาด (+/- จำนวนหนึ่ง) มีข้อสันนิษฐานว่าข้อผิดพลาดจะยกเลิกซึ่งกันและกันเมื่อคุณเพิ่มทั้งหมดและคุณจะได้ค่าประมาณโดยรวมที่เชื่อถือได้มากขึ้น
ข้อบกพร่องพื้นฐานของแนวทางนี้คือผู้ร่วมให้ข้อมูลแต่ละคน (คนที่ทำงานจริง) โดยทั่วไปประเมินต่ำเกินไป พวกเขายังคงดีกว่าคนที่อยู่รอบข้างและรอบข้างอย่างเห็นได้ชัด แต่นั่นไม่ใช่ระดับสูง ดูเหมือนจะไม่เป็นเช่นนั้นเพราะเราเคยเห็นกรณีที่นักพัฒนาสร้างความประหลาดใจด้วยการทำบางสิ่งให้สำเร็จก่อนกำหนด แต่นี่เป็นจุดข้อมูลเดียวไม่ใช่แนวโน้ม ผู้คนชนะในคาสิโนเป็นครั้งคราว ใช้จ่ายเงินที่คาสิโนทุกวันเป็นเวลาหนึ่งปีและคุณจะมีเงินน้อยกว่าที่คุณเริ่มต้นด้วย หากคุณติดตามค่าประมาณเทียบกับข้อมูลจริงเป็นเวลาหนึ่งหรือสองปีคุณจะพบว่าค่าประมาณนั้นไม่ตรงกับความเป็นจริง ในขณะที่นักธุรกิจจำนวนมากมั่นใจอย่างยิ่งว่านักพัฒนามักใช้เวลาว่างในการประมาณการและใช้เวลาพิเศษในการ "แผ่นทอง" หรือตรวจสอบหุ้นของตนข้อมูลจะแสดงเป็นอย่างอื่น กลยุทธ์ "การยกเลิก" ไม่ได้ผล
แล้วตอนนี้เป็นอย่างไร ลองทิ้งแบบจำลองหมอดูและเปลี่ยนไปใช้วิธีการตามขนาด ปรากฎว่าในขณะที่มนุษย์ค่อนข้างแย่ในการประมาณเวลาที่เสร็จสมบูรณ์ แต่จริงๆแล้วเราก็ค่อนข้างดีที่จะบอกว่าบางสิ่งนั้นใหญ่แค่ไหน เราถนัดในการเปรียบเทียบขนาดโดยเฉพาะ (“ มันใหญ่กว่านั้น แต่เล็กกว่าตรงนั้น”) หากเราคิดในแง่ของขนาดหรือความซับซ้อนมากกว่าเวลาสมองของเราจะประมวลผลได้อย่างน่าเชื่อถือมากขึ้น จากนั้นเราสามารถนำค่าขนาดและคำนวณจำนวนชั่วโมงจริงสำหรับโครงการตามสูตรวิเศษที่ดีได้! และนั่นคือตอนที่โมเดลจุดฟังก์ชันยอดนิยมเข้ามาในฉาก (พื้นที่ด้านซ้าย)
การวิเคราะห์คะแนนฟังก์ชัน (FPA)
สำหรับการวิเคราะห์จุดฟังก์ชันเราจำเป็นต้องระบุสิ่งต่างๆ 5 ประเภทในแอปพลิเคชันของเรา ได้แก่ อินพุตภายนอกเอาต์พุตภายนอกแบบสอบถามภายนอกไฟล์อินเทอร์เฟซภายนอกและไฟล์โลจิคัลภายใน (อย่ากังวลมากเกินไปเกี่ยวกับคำจำกัดความคุณสามารถค้นคว้าข้อมูลเหล่านี้ได้ในภายหลัง). แต่ละตัวอย่างของ (ฟังก์ชัน) มีความซับซ้อนที่เกี่ยวข้อง (ต่ำค่าเฉลี่ยหรือสูง) เราใช้ตารางด้านล่างเพื่อหาจำนวนคะแนนที่กำหนดให้แต่ละฟังก์ชัน
ตอนนี้ถ้าเรารวมคะแนนสำหรับฟังก์ชันทั้งหมดของเราเราอาจได้ตัวเลขเช่น 457 คะแนนฟังก์ชันสำหรับโครงการของเรา จากนั้นเราก็ต้องมีสูตรเพื่อหาจำนวนชั่วโมง…จากโครงการสุดท้ายของเรา“ อัตราการส่งมอบ” ของเราคือ 15 คะแนนการทำงานต่อคนต่อเดือน นั่นเป็นงานที่มีมูลค่าประมาณ 30 คนต่อเดือนซึ่งน่าจะใช้เวลาสองเดือนครึ่งสำหรับทีม 12 คนของฉัน Ta-da!
สิ่งนี้ซับซ้อนกว่ารุ่นก่อนหน้าของเราอย่างแน่นอน ในความเป็นจริงมีสี่ประเด็นหลักของความซับซ้อนที่ต้องรับรู้
- องค์ประกอบทั้งห้าประเภทไม่จำเป็นต้องเข้าใจง่ายและง่ายต่อการลืมใส่บางสิ่งในรายการหรือกำหนดให้กับที่เก็บข้อมูลที่ไม่ถูกต้อง
- ตารางที่ใช้ในการสร้างฟังก์ชันพอยต์จะมีตัวเลขวิเศษที่ต้องใช้ความพยายามอย่างมากในการตรวจสอบ ตัวเลขเหล่านี้ได้รับการปรับเทียบอย่างเหมาะสมเพื่อสร้างค่าประมาณที่เชื่อถือได้สำหรับทีมของฉันหรือไม่
- อัตราการส่งมอบ (ชิ้นส่วนสำคัญของตัวต่อ) คำนวณจากผลงานของทีมคุณ เราต้องคำนวณตัวเลขใหม่บ่อยแค่ไหน? มีคำแนะนำเพียงเล็กน้อยเกี่ยวกับเรื่องนี้
- อะไรที่มีความซับซ้อนต่ำปานกลางหรือสูง เราจะกำหนดอย่างไรเพื่อให้ทุกคนเข้าใจ การได้รับสิทธินั้นสำคัญต่อความแม่นยำของการคำนวณของเราไม่ใช่หรือ?
มีหลายส่วนที่เคลื่อนไหวในตัวอย่างง่ายๆนี้และเรายังไม่ได้พูดถึงโมเดลความซับซ้อนที่ซับซ้อนมากขึ้นและข้อมูลอื่น ๆ ที่สามารถเข้ามามีบทบาทได้ (เช่นอัตราต้นทุนอัตราการรองรับความหนาแน่นของข้อบกพร่อง ฯลฯ) ชิ้นส่วนที่เคลื่อนไหวมากขึ้นหมายถึงโอกาสที่จะเกิดข้อผิดพลาดมากขึ้น ตอนนี้เราทำการประมาณการซับซ้อนเกินไปหรือไม่? เราไม่ได้จ่ายเงินให้นักพัฒนาเพื่อทุ่มเทเวลามากมายในการประมาณค่า ฉันขายค่าประมาณให้กับลูกค้าไม่ได้ ฉันต้องการซอฟต์แวร์ที่ใช้งานได้ มีอะไรอีกไหม?
คล่องตัว
ตอนนี้เรามาดูสั้น ๆ เกี่ยวกับการต่อสู้แบบ Agile (เพียงพอที่จะทำการเปรียบเทียบ) ตามที่ระบุไว้ก่อนหน้านี้มนุษย์นั้นแย่มากในการประมาณเวลาและค่อนข้างดีในการเปรียบเทียบขนาด คำศัพท์สองสามข้อที่ต้องทำความเข้าใจ:
- การวิ่ง - ช่วงเวลาที่บรรจุกล่อง (โดยปกติคือสองสัปดาห์)
- เรื่องราวของผู้ใช้ - ชิ้นงานที่ไม่ต่อเนื่องควรมีขนาดเล็กพอที่จะทำได้โดยคนคนเดียวในการวิ่ง นี่คือสิ่งที่เรากำลังประเมิน
กลยุทธ์ที่ได้รับความนิยมมากที่สุดคือการใช้ลำดับฟีโบนักชี (0, 1, 2, 3, 5, 8, 13) สำหรับการประมาณ มันไม่ได้เป็นเส้นตรง - เมื่อคุณเพิ่มสเกลขึ้นขนาดของช่องว่างจะเพิ่มขึ้น กุญแจสำคัญคือช่องว่างควรกว้างพอที่จะไม่มีเหตุผลที่จะโต้แย้งเกี่ยวกับความแตกต่างที่ไม่สำคัญ เมื่อคุณได้คะแนนสูงกว่า 3 ความแตกต่างระหว่าง 4 และ 5 หรือ 7 และ 8 นั้นเล็กน้อยมากจนไม่มีประโยชน์ที่จะใช้เวลาในการคิดว่ามันคืออะไร ลำดับฐาน 2 ก็ใช้ได้เช่นกัน (0, 1, 2, 4, 8, 16, ฯลฯ)
“ แต่เดี๋ยวก่อนนี่เป็นเพียงตัวเลขเท่านั้น หมายความว่าอย่างไร? คะแนนคือกี่ชั่วโมง " คะแนนไม่ได้มีจุดมุ่งหมายเพื่อเชื่อมโยงโดยตรงกับชั่วโมงเพราะหากพวกเขาทำทีมจะถูกล่อลวงให้กลับไปที่การประมาณค่าเป็นชั่วโมงจากนั้นจึงแปลงเป็นคะแนนอย่างใด ตามที่กล่าวไว้ก่อนหน้านี้ความถูกต้องของการประมาณการของเรามาจากการเปรียบเทียบขนาดและไม่ได้ประมาณจำนวนชั่วโมงที่ต้องใช้ หากคุณให้ความสามารถแก่ทีมในการคิดเป็นชั่วโมงแสดงว่าคุณกำลังลดความสามารถในการประมาณค่าอย่างถูกต้อง
สมมติว่าคุณเริ่มต้นด้วยแบบฝึกหัดการสอบเทียบ ดึงทีมของคุณเข้าห้องและเดินผ่านรายการเรื่องราวของผู้ใช้ 10-12 คน เลือกอันที่เล็ก แต่ไม่เล็กที่สุดแล้วทำก่อน ตรวจสอบและประกาศว่าเรื่องนี้เป็น“ 3” คุณไม่ได้ถาม คุณกำลังบอก จากนั้นไปยังเรื่องถัดไป “ ถ้านั่นคือ 3 อันนี้คืออะไร” ตอนนี้ทีมงานกำลังปรับขนาดเรื่องราวให้สัมพันธ์กับเรื่องราวอื่น ๆ ในที่สุดพวกเขาก็จะมีความคิดที่ดีว่าอะไรประกอบเป็น“ 1”,“ 2” ฯลฯ ซึ่งไม่ได้ประมาณค่า เวลาไม่สำคัญ พวกเขากำลังปรับขนาดเรื่องราวโดยเทียบกับเรื่องราวอื่น ๆ ที่มีตัวเลขอยู่แล้ว จากนั้นคุณสามารถใส่เรื่องราวตัวอย่างสำหรับแต่ละหมายเลขตามลำดับในเอกสารที่เรียกว่าไม้บรรทัด พวกเขาสามารถใช้เป็นข้อมูลอ้างอิงหากไม่แน่ใจว่า“ 5” คืออะไร
นี่คือกุญแจสำคัญ ซอสวิเศษที่ทำให้งานชิ้นนี้คือ“ ความเร็ว” (จำนวนคะแนนที่ทีมทำได้ในการวิ่งโดยเฉลี่ยใน 3-4 สปรินต์) สมมติว่าการวิ่งของคุณใช้เวลาสองสัปดาห์และทีม 8 คนของคุณมีความเร็วเฉลี่ย 35 คะแนน คุณได้รับ 35 คะแนนใน 640 ชั่วโมงของการทำงาน (8 x 80 ชั่วโมง) ถ้าเราคิดออกว่าฟีเจอร์จะต้องใช้เวลาประมาณ 100 คะแนนในการเริ่มทำงานจนเสร็จฉันก็รู้ว่าทำงานได้ประมาณ 6 สัปดาห์และประมาณ 1900 ชั่วโมง ทีมทำงานได้ดีมากในการปรับขนาดเรื่องราวอย่างสม่ำเสมอและคุณใช้ประโยชน์จากสิ่งนั้นในการวางแผนโครงการของคุณ การคำนวณนี้ใช้ได้ผลเนื่องจากระยะเวลาสอดคล้องกันตั้งแต่การวิ่งไปจนถึงการวิ่ง
ในการวางแผนระดับสูงในระยะยาวคุณสามารถขอให้ลีดของคุณแบ่งคุณสมบัติระดับสูงออกเป็นเรื่องราวแบบซับเดียวและใส่ค่าคะแนนให้ ความแม่นยำจะหายไปในระดับหนึ่ง แต่คุณกำลังใช้ประโยชน์จากโมเดลที่พวกเขาเข้าใจอยู่แล้ว เส้นทางที่แม่นยำยิ่งขึ้นจะเป็นการปรับขนาดที่สัมพันธ์กันในระดับคุณลักษณะ “ ฟีเจอร์นี้ใหญ่กว่าฟีเจอร์ 40 แต้มเล็กกว่าฟีเจอร์ 120 แต้มตรงนั้นและใหญ่กว่าฟีเจอร์ 65 แต้มที่เราเพิ่งทำไปเล็กน้อย” เรื่องราวถูกจัดกลุ่มเป็น "มหากาพย์" หากแต่ละคุณสมบัติเป็นมหากาพย์ในตอนท้ายคุณจะรู้ว่าต้องใช้กี่คะแนนในการทำให้คุณลักษณะนั้นสมบูรณ์ เก็บประวัติไว้และคุณสามารถใช้ในการวางแผนการเปิดตัวของคุณ
สรุป
มีวิธีการมากมายที่ใช้ในปัจจุบัน แต่ละคนมีข้อดีข้อเสีย อย่างไรก็ตามเราต้องหาวิธีเพิ่มความแม่นยำของค่าประมาณเพื่อให้เราสามารถตัดสินใจได้ดี นั่นไม่ได้หมายความว่าค่าประมาณของเราจะต้องถูกต้อง เพียงแค่ต้องมีความแม่นยำเพียงพอที่จะเป็นประโยชน์ หากคุณไม่เข้าใจการประมาณค่าคุณอาจคิดว่าค่าประมาณไม่ถูกต้องเนื่องจากทีมทำงานได้ไม่ดี พวกเขาประเมินไม่ถูกต้องหรือไม่ได้ดำเนินการในโครงการอย่างถูกต้อง การทุบตีจะดำเนินต่อไปจนกว่าการประมาณการจะดีขึ้น แต่ไม่ควรใช้การประมาณการเป็นข้อผูกมัด เป็นการคาดเดาที่ดีที่สุดจากข้อมูลที่ จำกัด ที่เรามีในวันนี้ เมื่อมีข้อมูลใหม่ปรากฏขึ้นเราต้องยอมให้มีการทบทวนการประมาณการอีกครั้ง สิ่งอื่นใดที่คาดหวังสิ่งที่เป็นไปไม่ได้ซึ่งเป็นปัญหาเกี่ยวกับความเป็นผู้นำ (ไม่ใช่กับทีม)
แนวทางของ Scrum นั้นง่ายกว่าที่เราเห็นในการวิเคราะห์คะแนนฟังก์ชัน และฉันจะบอกว่ามันน่าเชื่อถือกว่าตารางมายากลที่มีตัวเลขวิเศษมาก ได้รับผลดีที่สุดสำหรับเจ้าชู้ (ใช้ความพยายามน้อยที่สุดและมีความแม่นยำสูงพอสมควร) จากมุมมองของความพยายามจะไม่สร้างกระบวนการที่หนักหน่วงให้ทีมเข้าใจและนำไปใช้ได้ ส่วนการประมาณค่าของความคล่องตัวสามารถเกิดขึ้นได้อย่างรวดเร็วเมื่อทุกคนเข้าใจรายละเอียดของงานที่กำลังประมาณ ดีกว่าการดึงตัวเลขออกจากอากาศอย่างแน่นอน การใช้ประโยชน์จากความเร็วเป็นสิ่งที่สำคัญมากนั่นคือการนำข้อมูลในอดีตมาใช้ในการคำนวณ ทุกการวิ่งคุณจะคำนวณความเร็วของคุณใหม่ นี่เป็นสิ่งสำคัญเนื่องจากเมื่อเวลาผ่านไปปริมาณงานเปลี่ยนแปลงไป ทีมที่ใช้ FPA อาจได้รับอัตราการส่งมอบจากโครงการก่อนหน้าซึ่งในบางกรณีเมื่อหลายเดือนก่อน ตั้งแต่นั้นมาอาจมีการเปลี่ยนแปลงไปมาก คำแนะนำของฉันคือให้คุณสำรวจ Agile และใช้ความพยายามอย่างมากในการทำความเข้าใจประเด็นและความเร็วของเรื่องราว อย่าถอยกลับไปประมาณชั่วโมงเพียงเพราะนั่นคือสิ่งที่คุณเข้าใจ ฉันเชื่อว่าคุณจะขอบคุณตัวเองในภายหลัง