ค่าเฉลี่ยอุตสาหกรรมสำหรับเวลาที่ใช้ในการบำรุงรักษา

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

ดังนั้นใครบ้างมีตัวชี้วัดตรงเวลาที่ใช้แก้ไขข้อผิดพลาดกับการพัฒนารหัสใหม่? หรือมีการวิเคราะห์เชิงประจักษ์เกี่ยวกับเวลาในการแก้ไขบั๊กสำหรับอุตสาหกรรมโดยรวมหรือไม่? การใช้ข้อผิดพลาด 50% นั้นแก้ไขมากเกินไปหรือใช่มั้ย แล้วประมาณ 20% หรือ 33% ล่ะ?

ฉันยินดีที่จะยอมรับหลักฐานพอสมควรจากประสบการณ์ส่วนตัวซึ่งจะเป็นส่วนหนึ่งของสถิติบางอย่างที่ฉันสามารถเปรียบเทียบประสิทธิภาพของเรากับ

ผู้จัดการเพิ่งประกาศว่าใช้เวลามากเกินไปในการแก้ไขข้อบกพร่อง

เสียงดังกล่าวข้างต้นโง่มาก การอ่านที่แนะนำสำหรับกรณีเช่นนี้: ข้อเท็จจริงและความล้มเหลวของวิศวกรรมซอฟต์แวร์โดย Robert L. Glass โดยเฉพาะ"ความจริง 43. การบำรุงรักษาเป็นวิธีการแก้ปัญหาไม่ใช่ปัญหา"

บทความ Wikipediaกล่าวถึงความพยายาม 80% ที่ใช้ในการบำรุงรักษาซอฟต์แวร์

ผู้จัดการของฉันทำให้ PHB ของ Dilbert ดูเป็นอัจฉริยะ :)

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

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

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

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

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

ขึ้นอยู่กับจำนวนรหัสที่คุณอยู่ที่นั่นระยะเวลาที่เปิดอยู่ ฯลฯ

เวลาที่ใช้ในการแก้ไขข้อบกพร่องในซอฟต์แวร์ควรเป็นแบบโหลดเข้าสู่ 6-12 เดือนแรกของการวางจำหน่ายอย่างไรก็ตามเมื่อเวลาเข้าใกล้อนันต์เวลาที่ใช้ในการบำรุงรักษาเมื่อเทียบกับเวลาที่ใช้ในการพัฒนาครั้งแรกจะเกิน 100% งาน.

แม้ว่าฉันจะไม่มีสถิติที่ยาก (Code Complete ทำ แต่ฉันไม่สามารถบอกคุณได้ว่าหน้า / ส่วนใด) ในประสบการณ์ของฉันประมาณ 40% ของการพัฒนา (บางครั้งสูงถึง 60%) ใช้ในการบำรุงรักษา เห็นได้ชัดว่ายิ่งคุณปล่อยโค้ดมากเท่าไหร่คุณก็จะมีเวลาบำรุงรักษามากขึ้นเท่านั้น บั๊กนั้นไม่สามารถใช้งานได้ตลอดเวลาและเป็นผลมาจากความไม่แน่นอนเช่นเดียวกับข้อบกพร่องทางโปรแกรม

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

ในโครงการก่อนหน้านี้เราใช้ Jira เพื่อจัดการรายการข้อผิดพลาด / งาน / สิ่งที่ต้องทำของเราและในที่สุดมันก็แสดงให้เราเห็นว่าสาเหตุที่ยิ่งใหญ่ที่สุดของความล่าช้าและปัญหากลายเป็นวิธีการจัดการที่ไม่มีประสิทธิภาพ

แปลกพอเมื่อข้อมูลนั้นออกมาเราบอกทันทีว่าเราจะไม่ใช้จิราอีกต่อไปและจะมีการนำผลิตภัณฑ์ใหม่เข้ามาแทนที่

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

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

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

แน่นอนว่ามันไม่จำเป็นต้องมีอะไรซับซ้อนเหมือนจิรา

หากคุณต้องการโซลูชันที่ให้ผลตอบแทนต่ำคุณสามารถใช้สเปรดชีต google-docs และ API การแจ้งเตือนของ GDocs เพื่อติดตามงาน / tickets / bugs / ร้องขอคุณสมบัติ ฯลฯ

ขณะนี้ GDocs สามารถออกเว็บฮุคและทุกประเภทได้

เชื่อมโยงกับ Git และ / หรือ Github และ hooks ที่เรียกใช้เมื่อมีการกำหนดรหัสให้กับที่เก็บของคุณและคุณมีระบบการชงที่บ้านที่มีประสิทธิภาพพอสมควรซึ่งสามารถบันทึกข้อมูลจำนวนมหาศาลได้

โดยทั่วไปอย่างไรก็ตามจาก 100% ของผลิตภัณฑ์ตลอดอายุการใช้งานตามธรรมชาติการแยกระหว่างกรีนฟิลด์ dev และการบำรุงรักษาโดยทั่วไปคือ 20/80 ต้นทุนส่วนใหญ่ในวงจร ALM (การจัดการอายุการใช้งานแอปพลิเคชัน) นั้นเกิดขึ้นจากค่าใช้จ่ายในการบำรุงรักษา

ไม่มีสิ่งใดที่จะใช้เวลามากเกินไปในการแก้ไขบั๊กเพราะมันเป็นไปไม่ได้ที่จะเขียนโค้ดที่ปราศจากบั๊ก

การทดสอบที่ดีและนโยบายการรวมอย่างต่อเนื่องจะช่วยลดความท้าทาย แต่คุณจะไม่มีทางกำจัดมันได้อย่างสมบูรณ์

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

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

Iv'e ทำงานใน บริษัท ไม่กี่แห่งที่งานประเภทนี้ได้รับการสนับสนุนอย่างแข็งขันด้วยพนักงานระดับสูงที่ทำหน้าที่เป็นพนักงานระดับล่างและในทางกลับกันมันเป็นประสบการณ์การเรียนรู้ที่ดีจริงๆสำหรับทั้งสองฝ่าย