ในทางปฏิบัติเก้าสิบเก้า

90 เปอร์เซ็นต์แรกของรหัสบัญชีสำหรับ 90 เปอร์เซ็นต์แรกของเวลาในการพัฒนา ส่วนที่เหลืออีก 10 เปอร์เซ็นต์ของรหัสบัญชีคิดเป็น 90 เปอร์เซ็นต์ของเวลาในการพัฒนา

- Tom Cargill, Bell Labs

ในทางปฏิบัติหมายความว่าอย่างไร โปรแกรมเมอร์รายนั้นทำงานเป็นกอบเป็นกำและพวกเขาให้ผลประโยชน์ 180% หรือ?

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

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

มันเป็นการอ้างอิงถึงสถานการณ์ทั่วไปที่น่าเศร้าที่ยังคงเกิดขึ้นวันนี้:

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

"90%" เป็นตัวเลขตามอำเภอใจ แต่มันทำให้ประเด็นดี: การคาดคะเนมีการคาดเดาและอาจจะผิดพลาด (มักจะผิดมาก) และธรรมชาติของมนุษย์ทำให้เรามั่นใจได้ว่าเราจะถูกประเมินตลอดเวลา

ฉันเคยได้ยินรุ่นที่แตกต่างจากนี้ (เรียกอีกอย่างว่า "90-90 กฎ") ที่จะเป็นเช่นนี้:

หลังจากที่ผมได้ดำเนินการ 90% ของการทำงานฉันยังคงมีการดำเนินการอื่น ๆ 90%

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

• โยนสถิติออกมาเมื่อจำเป็นต้องมีการประเมินและคาดเดาอย่างเป็นหลัก ("ฉันเสร็จแล้ว 80%")
• มุ่งเน้นไปที่ความซับซ้อนของอัลกอริทึมของโค้ดที่จะเขียนที่ระดับความเสียหายของงาน (การประเมินความพยายามต่ำเกินไปสำหรับงานทั่วไป)
• ขั้นตอนที่หายไป ("มองไม่เห็น, ออกจากใจ")
• การประเมินความพยายามในการบำรุงรักษาและการเปลี่ยนรหัสที่มีอยู่ต่ำเกินไป
• การประเมินความพยายามต่ำเกินไปสำหรับรหัส boilerplate / "กาว"

กฎนี้เติมเต็มกฎ 80-20 ตอนนี้มีการตีความที่แตกต่างกันของกฎ 80-20 แต่ทั้งสองฉันชอบมากที่สุดคือ:

1. การพัฒนาผลิตภัณฑ์ 80% แรกนั้นใช้ความพยายาม 20%
2. ข้อผิดพลาด 80% อยู่ในรหัส 20%

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

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

บรรทัดล่างคือมันง่ายกว่าที่จะเข้าใกล้เป้าหมายมากกว่าที่จะไปถึงมัน

ฉันพบว่าคำอธิบายของวิกิพีเดียมีความสว่างมาก

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

ในทางปฏิบัติหมายความว่าอย่างไร โปรแกรมเมอร์คนนั้นทำงานที่ไม่ได้ผลจำนวนมากและพวกเขาให้ 180% ของพวกเขาเองหรือ?

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

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

สิ่งนี้หมายความว่าในทางปฏิบัติคือคนโกหกตัวเอง

หากโปรแกรมเมอร์บอกว่า "เราทำเสร็จแล้ว 90%" นั่นหมายถึง 90% ของความพยายามในการสร้างคุณลักษณะนั้นถูกใช้ไปแล้ว

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

ความแตกต่างคือการใช้ความพยายามมากกว่าการเขียนรหัสคุณสมบัติเพื่อให้โครงการเสร็จสิ้น: qa, แก้ไขข้อผิดพลาด, คัดลอกแก้ไข, ปรับใช้

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