ในการตรวจสอบรายละเอียดงานทั้งหมด บริษัท ของฉันได้ตัดสินใจที่จะรวมสิ่งต่อไปนี้เป็นผลลัพธ์สำคัญ:

การพัฒนาเว็บไซต์เสร็จตรงเวลาตรงตามข้อกำหนดและปราศจากข้อผิดพลาด

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

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

ฉันจะเป็นฝ่ายตรงข้ามกับคำตอบส่วนใหญ่และบอกว่ามันสมเหตุสมผลและเป็นจริง

การพัฒนาทั้งหมดจะเสร็จสมบูรณ์ตรงเวลาหรือไม่ แน่นอนมันจะไม่เสมอไป

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

และการพัฒนาทั้งหมดจะปราศจากข้อผิดพลาดหรือไม่? ไม่เคย

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

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

ตอบโต้คำถาม: KPIs อะไรที่คุณจะเสนอให้โปรแกรมเมอร์ มันเป็นเรื่องที่ยาก สิ่งที่เราทำมากมายยากที่จะวัด

ถ้ามันเป็นรายละเอียดงานฉันก็ไม่ต้องกังวลอะไรมากไปกว่านี้เพราะการทำงานกับโค้ดที่ปราศจากข้อผิดพลาดเป็นส่วนหนึ่งของงานโปรแกรมเมอร์ทั่วไป (แม้ว่าเราจะไม่สามารถทำได้)

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

นี่คือตัวอย่างที่ทำให้ประเด็นดี
โปรแกรมเมอร์พบว่าซอฟต์แวร์ของเรามีข้อผิดพลาด "ปี 3000" และจะหยุดทำงานหลังจากวันที่ 31 ธันวาคม 2,999 จะใช้เวลา 6-8 เดือนในการแก้ไขปัญหา จาก KPI ได้รับการสนับสนุนให้ทำโครงการนี้แม้จะไม่มีมูลค่าที่แท้จริงสำหรับ บริษัท

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

ไม่

ไม่เพียง แต่จะไม่เหมาะสม แต่ก็น่าหัวเราะ

การทดสอบสามารถพิสูจน์การมีอยู่ของข้อผิดพลาดไม่ใช่การหายไปดังนั้นทุกโปรแกรมที่เขียนภายใต้การมีส่วนร่วมนี้จะต้องมีการพิสูจน์ความถูกต้องอย่างเข้มงวด ... และการทดสอบครอบคลุม 100%

"ระวังข้อผิดพลาดในโค้ดด้านบน; ฉันได้พิสูจน์แล้วว่าถูกต้องเท่านั้นไม่ใช่ลองใช้" - D. Knuth

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

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

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

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

คุณรู้หรือไม่ว่าทำไม บริษัท ต่างๆจึงสร้างแผนก QA ของซอฟต์แวร์ขึ้นมา? เพราะโปรแกรมเมอร์ไม่ทำงาน! โปรแกรมเมอร์กำลังปล่อยอึมากที่ บริษัท ต้องจัดตั้งแผนกใหม่ทั้งหมดเพื่อตรวจสอบพวกเขา

รายการบั๊กนานแค่ไหน เป็นมืออาชีพหรือไม่ที่จะมีข้อบกพร่องนับพันในฐานข้อมูลบั๊ก? ค่อนข้างชัดเจนว่าไม่ใช่ มันเป็นภาพสะท้อนของพฤติกรรมที่ไม่ดีมีระเบียบวินัยไม่ดีและตรงไปตรงมาไร้ชื่อเสียง

เราจะไม่เป็นมืออาชีพจนกว่าเราจะรู้ว่ามันเป็นหน้าที่ของเราที่จะทำให้แน่ใจว่า QA ไม่พบสิ่งใด

น่าเศร้าที่นี่ดูเหมือนเป็นวิธีที่พวกเขาจะ "ปกปิดฐานทั้งหมด" และไม่แนะนำอย่างชัดเจนและมีแนวโน้มที่จะทำให้เกิดความท้อแท้ในนักพัฒนา

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

"ปราศจากข้อผิดพลาด" ในขณะที่ "สมบูรณ์แบบ" ในขณะที่ "เขียนโดยพระเจ้าและเทวดาไม่ใช่มนุษย์?" (เรากำลังพูดถึงโปรแกรมตรรกะและข้อผิดพลาดฮาร์ดแวร์ตรรกะ)

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

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

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

หากฉันเห็นโฆษณาสำหรับวิศวกรซอฟต์แวร์ที่สร้างรหัส "ปราศจากข้อผิดพลาด" ฉันจะสมัครทันทีหรือทำงานทันที: บริษัท ไม่ได้คิดมากเกี่ยวกับการพัฒนาทดสอบและส่งมอบซอฟต์แวร์ของ บริษัท . ดังนั้นมันจะเป็นโอกาสที่ดีหรือฝันร้ายไม่รู้จบ

ของซอฟต์แวร์ใด ๆ ฉันสามารถทำได้อย่างง่ายดายและต้องบอกว่าฉันคาดหวังว่าโค้ดที่ไม่มีข้อผิดพลาดที่อยู่ข้างนอกสิ่งที่น่าอับอายมืดมนตรรกะลวงตา: โค้ดที่รวบรวมและลิงก์โดยไม่มีข้อผิดพลาดหรือคำเตือน; นั่นคือ "html ที่ถูกต้อง" หรือ "valid css"; JavaScript (พูด) ที่สร้างไม่มีข้อความแสดงข้อผิดพลาดที่ไม่ได้อธิบายหรือความผิดพลาดของเบราว์เซอร์ ส่วนนั้นฉันสามารถวัดได้อย่างตรงไปตรงมาและทำเครื่องหมายเป็นขาวดำบนกราฟ

ส่วนนั้นง่ายเหมือนพาย ทุกคนสามารถทำที่

เฮ้โชคดีในการค้นหาของคุณ :-)

ฉันเป็นคนโง่หรือ "ผิดพลาด" ไม่ได้หมายความว่า "ข้อความคอมไพเลอร์ร้ายแรงถึงจำนวนที่ไม่สามารถคอมไพล์โค้ด" ได้หรือไม่?

ตามคำนิยามนั้นมันเป็นข้อกำหนดที่สมเหตุสมผลมาก ...