วัดระบบส่งมอบซอฟต์แวร์

เริ่มจากการตัดสินใจที่ต้องทำ

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

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

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

ใช้นิยามปัจจุบัน

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

Dashboard อาจใช้นิยามอื่น อ่านนิยามก่อนตีความผล เอกสาร deployment ปัจจุบันของ Taiga อธิบายตัวชี้วัดที่รายงานสี่รายการ ซึ่งคำนวณจากระเบียน deployment ของผู้ให้บริการ ตัววัดการกู้คืนใช้ deployment ถัดไปที่สำเร็จ จึงไม่ใช่บันทึกครบถ้วนของทุก incident ใน production นิยามของ Taiga

ตรวจสอบลำดับการเปลี่ยนแปลงสมมติ

สมมติว่าบริการมี deployment สิบสองครั้งในหนึ่งเดือน แปดครั้งส่งมอบการเปลี่ยนแปลงตามแผน สี่ครั้งซ่อมปัญหาจาก release ก่อนหน้า จำนวนรวมคือสิบสอง แต่องค์ประกอบของจำนวนนั้นสำคัญ

เดือนถัดมาทีมมี deployment สิบครั้ง: การเปลี่ยนแปลงตามแผนเก้าครั้งและซ่อมปัญหาหนึ่งครั้ง Deployment ที่น้อยลงอาจมาพร้อมงานที่มีประโยชน์มากขึ้น ตัวเลขเหล่านี้ใช้แสดงวิธีตีความ ไม่ใช่เกณฑ์มาตรฐานผลงาน

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

พิจารณาการไหลของงานคู่กับผลที่ตามมา

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

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

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

ทำให้การวัดยังมีประโยชน์

หลีกเลี่ยงการจัดอันดับบุคคลจากจำนวน PR หรือโค้ดที่สร้าง ตัววัดเหล่านี้อาจให้รางวัลกับการแบ่งงานอย่างไม่มีเหตุผล การหลีกเลี่ยงงานบำรุงรักษายาก หรือการผลักภาระตรวจทานให้เพื่อนร่วมงาน

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

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

ฝึกกับการเปลี่ยนแปลงสิบรายการ

ชุดข้อมูลสมมติแยกต่างหากนี้บันทึกการเปลี่ยนแปลงตามแผนสิบรายการ เวลาทั้งหมดเป็น UTC ในวันที่แสดง ช่องการแก้ไขที่ว่างหมายถึงไม่มีการบันทึกการแก้ไขในชุดข้อมูลนี้

เปรียบเทียบเวลาตั้งแต่โค้ดพร้อมจนเริ่มตรวจทาน แล้วเปรียบเทียบเวลาตั้งแต่ยอมรับจนออก release ระบุช่วงรอที่ยาวที่สุดที่มองเห็น สืบหาสาเหตุก่อนสรุปว่าหลีกเลี่ยงได้ Timestamp เหล่านี้ไม่ได้วัดเวลาลงมือทำจริงหรือระบุว่า incident เริ่มเมื่อใด Release เพื่อแก้ไขเพียงอย่างเดียวระบุ failed deployment recovery time ไม่ได้

ดาวน์โหลดชุดข้อมูลสมมติ (CSV)