จำนวนงานประจำในการพัฒนาซอฟต์แวร์และผลกระทบต่อการประมาณ


11

ฉันเชื่อว่าจำนวนงานประจำในการพัฒนาซอฟต์แวร์คือ - และควรจะค่อนข้างเล็กถ้าไม่ได้เล็กน้อยและนี่เป็นปัญหาพื้นฐานของการประเมินซอฟต์แวร์

ให้ฉันอธิบายว่าฉันมาถึงข้อสรุปนี้และบอกฉันว่าการโต้แย้งมีข้อบกพร่องร้ายแรง:

  1. สิ่งที่สามารถประมาณได้ด้วยความแม่นยำสูงคืองานประจำซึ่งหมายถึงสิ่งที่เคยทำมาก่อน งานประเภทอื่น ๆ ที่เกี่ยวข้องกับการวิจัยและความคิดสร้างสรรค์ไม่สามารถคาดการณ์ได้จริง ๆ อย่างน้อยก็ไม่มีความแม่นยำเท่ากับ +/- 20 เปอร์เซ็นต์

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

จากจุดทั้งสองนี้ฉันได้ข้อสรุปข้างต้น

จริงๆแล้วฉันสงสัยมาระยะหนึ่งแล้วว่าทำไมความสัมพันธ์นี้ถึงไม่ได้กล่าวถึงในการอภิปรายการโพสต์บล็อกหรือบทความเกี่ยวกับการประมาณค่าซอฟต์แวร์ ในทางทฤษฎีมันเกินไปหรือไม่ สมมติฐานของฉันผิดหรือเปล่า? หรือเล็กเกินไป - แต่แล้วทำไมนักพัฒนาส่วนใหญ่ถึงรู้ว่าเชื่อว่าพวกเขาสามารถทำการประเมินด้วยความแม่นยำ +/- 20 เปอร์เซ็นต์หรือดีกว่า


7
99% ของการพัฒนาซอฟต์แวร์ทั้งหมดนอกพื้นที่เช่นเมล็ดเคยทำมาหลายพันครั้งแล้ว นักพัฒนาจำนวนมากที่มากเกินไปต้องการทำทุกอย่างด้วยวิธีที่แปลกใหม่สร้างปัญหาที่เหมือนกันซ้ำแล้วซ้ำอีก
Bent

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

1
@rwong: แน่นอนว่ามันสมเหตุสมผลที่จะใช้ห้องสมุด แต่การหาฟังก์ชั่นที่เหมาะสมในห้องสมุดและวิธีการใช้งานที่ถูกต้องก็คืองานวิจัย (ถ้า lib นั้นเป็น complaex และ / หรือคุณไม่รู้ว่ามันดี) หรือไม่สำคัญ (ถ้าคุณรู้ตัวว่าฟังก์ชั่นนั้น) สิ่งที่คุณเรียกว่า 'รหัสกาว' ในประสบการณ์ของฉันมักจะซับซ้อน การใช้มันไม่ได้เป็นงานประจำที่จำเป็น
Frank Puffer

1
@ JohnR.Strohm: ฉันไม่ได้อ่านหนังสือเฉพาะเหล่านี้ แต่คุ้นเคยกับพื้นฐานของ COCOMO - ไม่เคยใช้มันในทางปฏิบัติ ฉันอ่านหนังสืออีกสองหรือสามเล่มโดย DeMarco คุณสามารถให้คำแนะนำเกี่ยวกับเนื้อหาเฉพาะที่เกี่ยวข้องกับคำถามของฉันได้หรือไม่
Frank Puffer

2
@ Frankpuffer, "เศรษฐศาสตร์วิศวกรรมซอฟต์แวร์" ของ Boehm จำเป็นต้องอ่านเพื่อการประเมินซอฟต์แวร์ หนังสือของ Demarco อยู่ไม่ไกลนัก คำตอบของ SHORT คือ: ถ้าคุณคุ้นเคยกับสิ่งที่ซอฟต์แวร์ต้องทำเพื่อประเมิน AT ALL คุณจะคุ้นเคยพอที่จะคิดว่ามันเป็นกิจวัตรประจำวัน
John R. Strohm

คำตอบ:


11

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

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

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

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

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

ข้อกำหนดมีแนวโน้มที่จะแบ่งออกเป็นสามประเภท:

  1. คลุมเครือรายละเอียดเหลือให้นักพัฒนา

"สร้างเว็บไซต์ให้ฉันต้องเด็ดและขายเครื่องมือของฉัน"

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

  1. เฉพาะเจาะจงมาก

"ทำให้สีพื้นหลังส่วนหัว # ff1100"

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

  1. คลุมเครือรายละเอียดสันนิษฐาน

"ทำให้ฉันเป็นเว็บไซต์ (เช่นเดียวกับ facebook)"

นี่คือสมมติฐานจำนวนมากที่ไม่แน่นอน "แน่นอนว่าคุณจะต้องการโลโก้ที่แตกต่าง", "ควรมีการเลื่อนแบบไม่มีที่สิ้นสุด", "จะต้องปรับขนาดได้สำหรับผู้ใช้ 1 พันล้านคน!" ควบคุมการประมาณได้อย่างมีประสิทธิภาพ ทั้ง dev คิดว่าทุกอย่างและผลักดันการประมาณการเกินความคาดหมาย "1 meeelion man hours" หรือพวกเขาคิดว่า / สมมติว่ามีเพียงคุณสมบัติพื้นฐานที่จำเป็นและให้การประเมินที่ต่ำเกินไป "โอ้สัปดาห์หรือสองสัปดาห์ฉันคิดว่าคุณแค่ใส่เฟสบุ๊คใน iframe ใช่มั้ย"

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


ฉันเห็นด้วยอย่างยิ่งกับสิ่งที่คุณเขียนเกี่ยวกับข้อกำหนดที่ไม่เพียงพอ แต่นั่นเป็นเรื่องที่แตกต่าง ในส่วนแรกของคำตอบของคุณคุณบอกว่าคุณมักจะใช้เทคนิคที่เป็นที่รู้จักกันดีเพื่อให้งานของคุณมีมากขึ้น คุณจงใจทำโดยไม่มี abstractions เพิ่มเติม อาจใช้งานได้ดีในช่วงเวลาสั้น ๆ อาจใช้เวลา 2-5 ปีขึ้นอยู่กับเทคโนโลยีที่คุณใช้ แต่คุณอาจสังเกตเห็นว่าคุณไม่ได้ปรับปรุงกระบวนการของคุณมากเท่ากับคู่แข่งของคุณ นอกจากนี้นักพัฒนาซอฟต์แวร์อื่น ๆ ที่จะดูแลรหัสของคุณในภายหลังอาจมีปัญหา
Frank Puffer

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

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

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

@Ewan "แนวคิดหรือเทคโนโลยี" สำหรับฉันคนแรกมีแนวโน้มที่จะเกี่ยวข้องกับกฎเกณฑ์ทางธุรกิจและ / หรือสิ่งที่ผู้ออกแบบต้องการ มันไม่ใช่แค่เทคโนโลยีใหม่
Izkata

6

ทำไมนักพัฒนาส่วนใหญ่ที่ฉันรู้ว่าเชื่อว่าพวกเขาสามารถทำการประเมินด้วยความแม่นยำ +/- 20 เปอร์เซ็นต์หรือดีกว่า

เพราะเราประเมินความอดทนต่อปัญหามากกว่าปัญหาที่เกิดขึ้นจริง

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

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

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


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

@ FrankPuffer ฉันไม่เห็นด้วยกับวิธีการที่ว่องไวไม่ได้ทำให้ชัดเจน โดยเฉพาะอย่างยิ่ง SCRUM ไม่ได้ขอให้นักพัฒนาประเมินจนกว่าค่าของคุณสมบัติจะสูงจนมีกำหนดเวลาที่จะต้องทำจริง ๆ นั่นก็คือการประมาณเวลา วิธีการแบบเปรียวเหมาะอย่างยิ่งกับสิ่งนี้ก่อนอื่นให้ระบุคุณลักษณะที่มีมูลค่าทางธุรกิจสูงสุดจากนั้นจึงทำการประมาณค่าจากนั้นทำการตั้งค่าและดูว่าใช้เวลานานเท่าใด ทำความสะอาดฟองซ้ำ หลังจากผ่านไปสองสามรอบคุณจะมีความคิดที่ดีมากเกี่ยวกับเวลาในการประเมินเทียบกับเวลาจริง
RibaldEddie
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.