จะอธิบายได้อย่างไรว่ามันยากที่จะประเมินเวลาที่จำเป็นสำหรับโครงการซอฟต์แวร์ขนาดใหญ่

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

ฉันจะอธิบายสิ่งนี้กับบุคคลที่ไม่ใช่นักพัฒนาซอฟต์แวร์ได้อย่างไร

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

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

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

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

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

ในฐานะนักพัฒนารุ่นเยาว์เริ่มติดตามการประมาณการและเวลาจริงในขณะนี้ คุณอาจสนใจอ่านเกี่ยวกับกระบวนการซอฟต์แวร์ส่วนบุคคลที่พัฒนาขึ้นที่สถาบันวิศวกรรมซอฟต์แวร์ หนังสือหลัก PSP มีวินัยสำหรับวิศวกรรมซอฟต์แวร์ , PSP: Process ตัวเองปรับปรุงซอฟแวร์สำหรับวิศวกรและรู้เบื้องต้นเกี่ยวกับกระบวนการซอฟแวร์ส่วนบุคคล ฉันเชื่อว่าบทนำสู่กระบวนการซอฟต์แวร์ส่วนบุคคลจะครอบคลุมหัวข้อที่คุณจะพบว่ามีประโยชน์มากที่สุด ฉันคิดว่ามันเกินความจริงสำหรับนักพัฒนาส่วนใหญ่ แต่ก็มีความคิดที่ดีและแนวปฏิบัติที่ดีที่สามารถดึงออกมาและใช้เพื่อปรับปรุงประสิทธิภาพการผลิตส่วนบุคคลและฝึกฝนทักษะต่าง ๆ (รวมถึงการประมาณ) ที่คุณจะใช้ในอาชีพของคุณอย่างต่อเนื่อง

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

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

ต้องอ่าน: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

The Mythical Man-Month: บทความเกี่ยวกับวิศวกรรมซอฟต์แวร์เป็นหนังสือเกี่ยวกับวิศวกรรมซอฟต์แวร์และการจัดการโครงการโดย Fred Brooks ซึ่งเนื้อหาหลักคือ "การเพิ่มกำลังคนให้กับโครงการซอฟต์แวร์ที่ล่าช้าทำให้ในภายหลัง" ความคิดนี้เป็นที่รู้จักกันในนามกฎหมายของบรูกส์และนำเสนอพร้อมกับเอฟเฟกต์ระบบที่สองและการสนับสนุนการทำต้นแบบ

การสังเกตของ Brooks ขึ้นอยู่กับประสบการณ์ของเขาที่ IBM ในขณะที่จัดการการพัฒนา OS / 360 เขาได้เพิ่มโปรแกรมเมอร์เพิ่มเติมลงในโครงการที่อยู่เบื้องหลังกำหนดการตัดสินใจว่าเขาจะสรุปได้ในภายหลังโดยสังเขปว่าโครงการล่าช้ายิ่งขึ้น นอกจากนี้เขายังทำผิดพลาดในการยืนยันว่าโครงการหนึ่ง - การเขียนคอมไพเลอร์ ALGOL - จะต้องใช้เวลาหกเดือนโดยไม่คำนึงถึงจำนวนของพนักงานที่เกี่ยวข้อง (ต้องใช้อีกต่อไป) แนวโน้มสำหรับผู้จัดการที่จะทำซ้ำข้อผิดพลาดในการพัฒนาโครงการทำให้บรูกส์อ้างว่าหนังสือของเขาถูกเรียกว่า "The Bible of Software Engineering" เพราะ "ทุกคนพูดถึงมันบางคนอ่านมันและบางคนก็ผ่านมันไป" หนังสือเล่มนี้ได้รับการยกย่องอย่างกว้างขวางว่าคลาสสิกในองค์ประกอบของมนุษย์ของวิศวกรรมซอฟต์แวร์ ...

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

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

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

ฉันได้พบกับคนที่อ้างว่าสามารถประเมินซอฟต์แวร์ได้ แต่ฉันไม่รู้ว่าพวกเขาทำได้อย่างไร ไม่มีใครสามารถอธิบายได้ว่าพวกเขาทำได้อย่างไร

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

ฉันค้นหาหนังสือที่จะสอนวิธีประเมินซอฟต์แวร์มาหลายปีแล้ว แต่ยังหาไม่เจอ

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

หาก บริษัท ใหญ่ ๆ อย่าง Microsoft ไม่สามารถทราบได้ว่าจะประเมินเวลาที่ใช้ในการผลิตผลิตภัณฑ์ของตัวเองได้อย่างไรฉันจะทำอย่างไร

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

การประเมินเวลาทั้งหมดของโครงการมักดำเนินการโดยผู้จัดการโครงการไม่ใช่โปรแกรมเมอร์

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

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

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

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

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