เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์ของคุณ

ServiceNow DevOps
เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์ของคุณ

เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์ของคุณ

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

แอตทริบิวต์ของวงจรการพัฒนาซอฟต์แวร์

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

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

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

เหตุผลที่สำคัญ

คุณลักษณะนี้กำหนดขั้นตอนในแผนผังกระบวนการ ช่วยวิเคราะห์การไหลของกระบวนการ ระบุคอขวด และค้นหาจุดที่เบี่ยงเบนจาก SDLC มาตรฐาน.

แหล่งข้อมูล

โดยทั่วไปได้จากการจับคู่การเปลี่ยนสถานะ ระเบียนเหตุการณ์ หรือรายการในบันทึกการตรวจสอบ กับรายการชื่อกิจกรรมมาตรฐาน ตัวอย่างเช่น การเปลี่ยนฟิลด์ 'state' เป็น 'In Progress' อาจจับคู่กับ 'เริ่มพัฒนา'.

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

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไป รหัสนี้เป็นคีย์หลักจากตารางที่จัดการ story, bug หรือ task เช่น ตาราง 'rm_story', 'rm_bug' หรือ 'task' ใน ServiceNow.

ตัวอย่าง
STRY0010015BUG0034092TASK0050118
เวลาเริ่มต้น
EventTime
เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์เกิดขึ้นเมื่อใด.
คำอธิบาย

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

ใน process mining จะใช้เวลาเริ่มต้นคำนวณระยะเวลาระหว่างกิจกรรม ระบุเวลารอ และวัดระยะเวลารอบการทำงานทั้งหมดของกระบวนการ นอกจากนี้ยังเป็นองค์ประกอบสำคัญของแดชบอร์ดวิเคราะห์ประสิทธิภาพ เช่น การวิเคราะห์ระยะเวลารอบการทำงาน SDLC ตั้งแต่ต้นจนจบ และใช้คำนวณตัวชี้วัดประสิทธิภาพหลัก เช่น ระยะเวลาตั้งแต่เริ่มจนตรวจสอบโค้ดเสร็จ.

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไปพบในฟิลด์เวลาที่ระบบสร้างขึ้น เช่น 'sys_updated_on' หรือ 'sys_created_on' ในบันทึกการตรวจสอบหรือตาราง task.

ตัวอย่าง
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
ระบบต้นทาง
SourceSystem
ระบุระบบที่ดึงข้อมูลมาใช้ ซึ่งในกรณีนี้คือ ServiceNow DevOps.
คำอธิบาย

คุณลักษณะนี้ระบุระบบต้นทางของข้อมูลเหตุการณ์ สำหรับกระบวนการนี้ ค่าจะเป็น 'ServiceNow DevOps' เสมอ

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

เหตุผลที่สำคัญ

ช่วยติดตามที่มาของข้อมูลและรักษาความถูกต้องของข้อมูล โดยเฉพาะเมื่อนำข้อมูลจากเครื่องมือพัฒนาหลายระบบมารวมกัน.

แหล่งข้อมูล

เป็นค่าคงที่ที่ควรเพิ่มระหว่างขั้นตอนดึงและแปลงข้อมูล.

ตัวอย่าง
ServiceNow DevOps
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่บันทึกว่ามีการรีเฟรชข้อมูลของบันทึกเหตุการณ์นี้จากระบบต้นทางครั้งล่าสุด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ให้บริบทสำคัญเกี่ยวกับความใหม่ของข้อมูล เพื่อให้ผู้ใช้ทราบว่าการวิเคราะห์กระบวนการอ้างอิงข้อมูลล่าสุดเพียงใด.

แหล่งข้อมูล

ระบบสร้างและเพิ่มเวลานี้ระหว่างการดึงข้อมูล เพื่อบันทึกเวลาที่ดำเนินการดึงข้อมูล.

ตัวอย่าง
2023-11-15T08:00:00Z
กลุ่มผู้รับผิดชอบ
AssignmentGroup
ทีมที่รับผิดชอบรายการพัฒนาในขณะที่เกิดกิจกรรม.
คำอธิบาย

แอตทริบิวต์นี้ระบุทีมที่ได้รับมอบหมายให้ทำรายการงาน เช่น 'ทีมพัฒนา Frontend', 'ทีมบริการ Backend' หรือ 'ทีม QA' เมื่อรายการงานดำเนินไป มักมีการส่งต่องานระหว่างกลุ่มผู้รับผิดชอบ

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ข้อมูลนี้จัดเก็บในฟิลด์ 'assignment_group' ซึ่งเป็นฟิลด์มาตรฐานในตารางที่เกี่ยวข้องกับงานของ ServiceNow.

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

คุณลักษณะนี้ระบุผู้รับผิดชอบงานหรือกิจกรรมแต่ละรายการ โดยค่าเปลี่ยนแปลงได้เมื่อรายการพัฒนาเคลื่อนผ่านขั้นตอนและทีมต่าง ๆ

คุณลักษณะนี้สำคัญต่อการวิเคราะห์การจัดสรรทรัพยากร ปริมาณงาน และการส่งต่องาน ใช้กับแดชบอร์ด 'ปริมาณงานและการส่งต่องานของนักพัฒนา' และ KPI 'จำนวนกิจกรรมต่อนักพัฒนา' ได้โดยตรง เมื่อติดตามการเปลี่ยนแปลงของฟิลด์นี้ คุณจะวัดเวลาส่งต่องานและระบุคอขวดในการทำงานร่วมกันระหว่างนักพัฒนา หรือระหว่างทีมพัฒนาและ QA ได้.

เหตุผลที่สำคัญ

จำเป็นต่อการวิเคราะห์ตามทรัพยากร ทั้งการกระจายปริมาณงาน ประสิทธิภาพการส่งต่องาน และรูปแบบประสิทธิภาพเฉพาะของแต่ละทีม.

แหล่งข้อมูล

โดยทั่วไปข้อมูลนี้จัดเก็บไว้ในฟิลด์ 'assigned_to' ของตารางที่เกี่ยวข้องกับ task ใน ServiceNow.

ตัวอย่าง
David MillerAnna WilliamsJames Brown
ประเภทรายการพัฒนา
DevelopmentItemType
การจัดประเภทของรายการงาน เช่น 'ฟีเจอร์', 'บั๊ก', 'หนี้ทางเทคนิค' หรือ 'งาน'.
คำอธิบาย

แอตทริบิวต์นี้ใช้แยกประเภทงานที่ดำเนินอยู่ในกระบวนการ SDLC ตัวอย่างเช่น กระบวนการแก้บั๊กร้ายแรงอาจแตกต่างจากการพัฒนาฟีเจอร์ใหม่ และอาจใช้เวลาน้อยกว่า

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

เหตุผลที่สำคัญ

ใช้แยกประเภทงาน เช่น ฟีเจอร์และบั๊ก ซึ่งอาจมีเส้นทางกระบวนการ ลำดับความสำคัญ และระยะเวลาที่คาดหวังแตกต่างกัน.

แหล่งข้อมูล

ระบุประเภทได้จากตารางต้นทางของระเบียน เช่น 'rm_story' กับ 'rm_bug' หรือจากฟิลด์ 'type' ในตารางงานทั่วไป.

ตัวอย่าง
ฟีเจอร์บั๊กงานงานทดลองศึกษา
เป็นการแก้งานซ้ำหรือไม่
IsRework
ค่าสถานะแบบบูลีนที่เป็นจริงเมื่อกิจกรรมเป็นส่วนหนึ่งของการวนกลับไปแก้งาน เช่น กลับไปพัฒนาต่อหลังการทดสอบ.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

เครื่องมือ process mining คำนวณแอตทริบิวต์นี้โดยวิเคราะห์ลำดับกิจกรรมของแต่ละเคส เพื่อตรวจจับการย้อนกลับในกระบวนการ.

ตัวอย่าง
truefalse
โมดูล/คอมโพเนนต์ที่ได้รับผลกระทบ
ModuleComponentAffected
โมดูลซอฟต์แวร์ แอปพลิเคชัน หรือคอมโพเนนต์ที่เกี่ยวข้องกับรายการพัฒนาโดยเฉพาะ.
คำอธิบาย

แอตทริบิวต์นี้จัดหมวดหมู่งานพัฒนาตามส่วนของระบบที่ได้รับผลกระทบ เช่น microservice, คอมโพเนนต์ UI หรือแอปพลิเคชัน backend

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

เหตุผลที่สำคัญ

ช่วยแบ่งการวิเคราะห์ตามแอปพลิเคชันหรือคอมโพเนนต์ เพื่อแยกดูคอขวดหรือปัญหาด้านคุณภาพที่เกิดกับบางส่วนของระบบโดยเฉพาะ.

แหล่งข้อมูล

ข้อมูลนี้มักอยู่ในฟิลด์ที่กำหนดเอง หรือเป็นการอ้างอิงไปยัง Configuration Management Database (CMDB) ซึ่งเชื่อมรายการงานกับระเบียน 'cmdb_ci' โปรดดูเอกสาร ServiceNow DevOps.

ตัวอย่าง
บริการเรียกเก็บเงินUI สำหรับการยืนยันตัวตนผู้ใช้ฐานข้อมูลการรายงานAPI Gateway
ระยะเวลารอบการพัฒนารายการ
DevelopmentItemCycleTime
เวลารวมตั้งแต่สร้างรายการพัฒนาจนปิดงานหรือนำขึ้นใช้งานเสร็จสิ้น.
คำอธิบาย

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

นี่คือตัวชี้วัดผลการดำเนินงานหลักของกระบวนการ SDLC และใช้คำนวณ KPI 'ระยะเวลารอบการพัฒนา SDLC เฉลี่ย' โดยตรง ช่วยวัดความเร็วและประสิทธิภาพของกระบวนการในภาพรวม การวิเคราะห์ตัวชี้วัดนี้ตามช่วงเวลาและมิติต่างๆ เช่น ลำดับความสำคัญหรือทีม ช่วยติดตามผลของการปรับปรุงกระบวนการได้.

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ฟิลด์นี้ไม่มีในระบบต้นทาง เครื่องมือ process mining จะคำนวณโดยนำ StartTime ต่ำสุดมาลบออกจาก StartTime สูงสุดของแต่ละ CaseId.

ตัวอย่าง
15 วัน 4 ชั่วโมง3 วัน 12 ชั่วโมง32 วัน 8 ชั่วโมง
ลำดับความสำคัญ
DevelopmentItemPriority
ระดับความสำคัญที่กำหนดให้รายการพัฒนา เช่น 'สูง', 'ปานกลาง' หรือ 'ต่ำ'.
คำอธิบาย

คุณลักษณะนี้จัดกลุ่มรายการพัฒนาตามความเร่งด่วนทางธุรกิจ ระดับความสำคัญช่วยให้ทีมมุ่งเน้นงานที่สำคัญที่สุด และมักใช้บริหาร SLA กับความคาดหวังของผู้มีส่วนเกี่ยวข้อง

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

เหตุผลที่สำคัญ

ช่วยกรองและเปรียบเทียบกระบวนการตามระดับความสำคัญ เพื่อตรวจสอบว่ารายการที่มีความสำคัญสูงได้รับการดำเนินการเร็วและมีประสิทธิภาพกว่าหรือไม่.

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์มาตรฐานชื่อ 'priority' ในตารางที่เกี่ยวข้องกับ task ของ ServiceNow.

ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
สถานะรายการพัฒนา
DevelopmentItemState
สถานะของรายการพัฒนา ณ เวลาที่เกิดเหตุการณ์ เช่น 'เปิด', 'กำลังดำเนินการ' หรือ 'ปิดแล้ว'.
คำอธิบาย

แอตทริบิวต์นี้แสดงสถานะอย่างเป็นทางการของรายการพัฒนาใน ServiceNow กิจกรรมคือขั้นตอนที่ได้จากข้อมูลกระบวนการ ส่วนสถานะจะแสดงขั้นตอนอย่างเป็นทางการในเวิร์กโฟลว์ของระบบ

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไป ฟิลด์มาตรฐานนี้มีชื่อว่า 'state' หรือ 'stage' ในตารางที่เกี่ยวข้องกับงานของ ServiceNow.

ตัวอย่าง
รอดำเนินการกำลังดำเนินงานพร้อมทดสอบปิดงานเรียบร้อย
รหัส Commit
CommitId
ตัวระบุเฉพาะของ commit ในซอร์สโค้ดที่เกี่ยวข้องกับงานพัฒนา.
คำอธิบาย

แอตทริบิวต์นี้เชื่อมรายการพัฒนาโดยตรงกับการเปลี่ยนแปลงโค้ดในคลังซอร์สโค้ด เช่น Git โดยระบบจะบันทึกเมื่อเกิดกิจกรรม 'Commit โค้ดแล้ว'

ใน process mining รหัส Commit ช่วยเพิ่มรายละเอียดในการวิเคราะห์ โดยเชื่อมข้อมูลกระบวนการกับข้อมูลด้านวิศวกรรม นักวิเคราะห์สามารถตรวจสอบย้อนกลับจากการนำระบบขึ้นใช้งานที่มีปัญหาไปยังการเปลี่ยนแปลงโค้ดที่เกี่ยวข้อง หรือเปรียบเทียบความซับซ้อนของโค้ดกับระยะเวลารอบการพัฒนาได้ จึงช่วยวิเคราะห์สาเหตุที่แท้จริงในระดับเทคนิคได้ละเอียดขึ้น.

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ข้อมูลนี้บันทึกผ่านการเชื่อมต่อ ServiceNow DevOps กับระบบจัดการซอร์สโค้ด เช่น Git หรือ SVN โดยจัดเก็บไว้ในตารางที่เกี่ยวข้องและเชื่อมกับรายการพัฒนา.

ตัวอย่าง
a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
เวลาสิ้นสุด
EventEndTime
เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมเสร็จสิ้นเมื่อใด สำหรับเหตุการณ์ที่เกิดขึ้นทันที จะตรงกับเวลาเริ่มต้น.
คำอธิบาย

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

ใน process mining การมีทั้งเวลาเริ่มต้นและเวลาสิ้นสุดช่วยคำนวณเวลาที่ใช้ทำกิจกรรมได้อย่างแม่นยำ และแยกออกจากเวลารอระหว่างกิจกรรม ทำให้ระบุได้ว่าความล่าช้าเกิดจากงานที่ใช้เวลานานหรือการรอทรัพยากรนาน สำหรับเหตุการณ์ที่เกิดขึ้นทันที เช่น 'เริ่ม build' เวลาเริ่มต้นและเวลาสิ้นสุดอาจตรงกัน.

เหตุผลที่สำคัญ

ช่วยคำนวณเวลาที่ใช้ทำกิจกรรมได้อย่างแม่นยำ และแยกเวลาทำงานออกจากเวลารอ.

แหล่งข้อมูล

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

ตัวอย่าง
2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
เวอร์ชันที่วางแผนจะเผยแพร่
PlannedReleaseVersion
ซอฟต์แวร์รุ่นหรือเวอร์ชันเป้าหมายที่วางแผนจะส่งมอบรายการพัฒนา.
คำอธิบาย

แอตทริบิวต์นี้เชื่อมรายการพัฒนากับรุ่นที่วางแผนไว้โดยเฉพาะ เช่น 'เวอร์ชัน 2.3' หรือ 'รุ่นไตรมาส 4 ปี 2023' ซึ่งเป็นองค์ประกอบสำคัญของการบริหารโครงการและการวางแผนเผยแพร่

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

เหตุผลที่สำคัญ

เชื่อมงานพัฒนากับรุ่นที่กำหนด เพื่อวิเคราะห์การทำงานตามกำหนดและผลกระทบของความล่าช้าในกระบวนการต่อกำหนดการเผยแพร่.

แหล่งข้อมูล

โดยทั่วไป ข้อมูลนี้จัดเก็บในฟิลด์ 'release' หรือ 'planned_release' ซึ่งมักอ้างอิงตารางการจัดการรุ่นใน ServiceNow โปรดดูเอกสาร ServiceNow DevOps.

ตัวอย่าง
v3.4.1รุ่นเผยแพร่ไตรมาส 1 ปี 2024เปิดใช้งาน Project Phoenix
สถานะการนำขึ้นใช้งาน
DeploymentStatus
ระบุผลลัพธ์ของกิจกรรมการนำขึ้นใช้งาน โดยทั่วไปคือ 'สำเร็จ' หรือ 'ล้มเหลว'.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไป สถานะนี้บันทึกไว้ในงานติดตามการนำขึ้นใช้งาน หรือระเบียนการทำงานของ CI/CD pipeline ที่เชื่อมต่อกับ ServiceNow DevOps.

ตัวอย่าง
สำเร็จล้มเหลวเสร็จสิ้นพร้อมคำเตือน
สาเหตุที่ต้องแก้งานซ้ำ
ReworkReason
การจัดประเภทหรือคำอธิบายสาเหตุที่ต้องแก้รายการพัฒนาซ้ำหลังการทดสอบ.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ข้อมูลนี้อาจบันทึกในฟิลด์ 'close_notes' เมื่อการทดสอบไม่ผ่าน หรือในฟิลด์ที่กำหนดเองชื่อ 'rework_reason' โปรดดูเอกสาร ServiceNow DevOps.

ตัวอย่าง
ตีความข้อกำหนดไม่ตรงกันบั๊กที่เกิดซ้ำไม่ผ่านการทดสอบประสิทธิภาพปัญหา UI/UX
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในวงจรการพัฒนาซอฟต์แวร์

ขั้นตอนและหมุดหมายสำคัญที่ควรบันทึกไว้ในบันทึกเหตุการณ์ เพื่อค้นพบและปรับปรุงกระบวนการได้อย่างแม่นยำ.
7 แนะนำ 9 ไม่บังคับ
กิจกรรม คำอธิบาย
การนำระบบขึ้นใช้งานล้มเหลว
หมายถึงการนำรายการพัฒนาขึ้นสู่สภาพแวดล้อมใช้งานจริงไม่สำเร็จ ServiceNow DevOps บันทึกเหตุการณ์นี้โดยตรงเมื่อไปป์ไลน์ CI/CD รายงานความล้มเหลว.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ดึงข้อมูลจากค่า 'completion_status' ของระเบียน Pipeline Execution [sn_devops_pipeline_execution] หากสถานะเป็น 'Failed' ณ เวลาสิ้นสุด ให้ถือว่าเกิดเหตุการณ์นี้.

บันทึก

บันทึกเมื่อไปป์ไลน์นำระบบขึ้นใช้งานจริงรายงานสถานะล้มเหลว.

ประเภทเหตุการณ์ explicit
ตรวจสอบโค้ดเสร็จสิ้น
กิจกรรมนี้หมายถึงการตรวจสอบโค้ดโดยเพื่อนร่วมทีมเสร็จสิ้น โดยทั่วไปเกี่ยวข้องกับ pull request หรือ merge request บันทึกเหตุการณ์นี้ได้โดยตรงผ่านการเชื่อมต่อ DevOps หรืออนุมานจากการเปลี่ยนสถานะของระเบียนที่เกี่ยวข้อง.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ดึงข้อมูลจากเหตุการณ์ 'Merged' หรือ 'Completed' ของระเบียน Pull Request ในการเชื่อมต่อ Git ของ ServiceNow หรืออนุมานจากการเปลี่ยนสถานะรายการพัฒนาเป็น 'Code Review Complete'.

บันทึก

บันทึกเมื่อมีการ merge Pull Request ที่เชื่อมโยงกับรายการงาน.

ประเภทเหตุการณ์ explicit
ทดสอบ QA เสร็จสิ้น
หมายถึงทีม Quality Assurance ทดสอบรายการพัฒนาเสร็จเรียบร้อย โดยทั่วไปอนุมานเมื่อสถานะของรายการออกจากขั้นตอนทดสอบไปเป็นสถานะอย่าง 'Ready for UAT' หรือ 'Done'.
เหตุผลที่สำคัญ

หมุดหมายนี้หมายถึงการผ่านจุดตรวจสอบคุณภาพสำคัญ และเป็นเงื่อนไขก่อนเข้าสู่ขั้นตอนถัดไป เช่น User Acceptance Testing หรือการเตรียมเผยแพร่.

แหล่งข้อมูล

อนุมานจากเวลาที่สถานะเปลี่ยนจากสถานะทดสอบ เช่น 'In QA' ไปเป็นสถานะหลังทดสอบ เช่น 'Ready for UAT' หรือ 'Resolved'.

บันทึก

อ้างอิงเวลาที่สถานะเปลี่ยนจาก 'Testing' ไปเป็นสถานะถัดไป.

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

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

แหล่งข้อมูล

ดึงข้อมูลจากค่า 'completion_status' ของระเบียน Pipeline Execution [sn_devops_pipeline_execution] หรือ Stage Execution Run ที่เกี่ยวข้อง หากสถานะเป็น 'Success' ณ เวลาสิ้นสุด ให้ถือว่าเกิดเหตุการณ์นี้.

บันทึก

บันทึกเมื่อไปป์ไลน์นำระบบขึ้นใช้งานจริงเสร็จสมบูรณ์.

ประเภทเหตุการณ์ explicit
เริ่มพัฒนา
กิจกรรมนี้หมายถึงจุดที่นักพัฒนาเริ่มเขียนโค้ดหรือนำรายการพัฒนาไปลงมือทำ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะของรายการเป็น 'In Progress', 'Development' หรือ 'Coding'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากเวลาที่ฟิลด์ 'State' ในระเบียนรายการพัฒนา เช่น Story [rm_story] เปลี่ยนเป็น 'In Progress' หรือสถานะที่มีความหมายเทียบเท่า.

บันทึก

อ้างอิงเวลาที่สถานะเปลี่ยนเป็น 'In Progress' หรือค่าใกล้เคียงกัน.

ประเภทเหตุการณ์ inferred
สร้างรายการพัฒนา
กิจกรรมนี้หมายถึงการสร้างรายการพัฒนาใหม่ เช่น story, bug หรือ epic ใน ServiceNow โดยทั่วไปจะบันทึกเหตุการณ์นี้โดยตรงเมื่อมีการเพิ่มระเบียนใหม่ลงในตารางที่เกี่ยวข้อง เช่น ตาราง Story [rm_story].
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

บันทึกไว้ในตาราง sys_audit หรือ sys_history_line เมื่อสร้างระเบียนในตารางที่เกี่ยวข้องกับการพัฒนา เช่น Story [rm_story], Epic [rm_epic] หรือ Defect [rm_defect] โดยทั่วไปเวลา创建จะอยู่ในระเบียนนั้น.

บันทึก

ดึงข้อมูลจากเวลาที่สร้างระเบียนรายการพัฒนา.

ประเภทเหตุการณ์ explicit
อนุมัติ UAT
หมายถึงผู้มีส่วนเกี่ยวข้องทางธุรกิจอนุมัติรายการพัฒนาอย่างเป็นทางการหลัง User Acceptance Testing เป็นหมุดหมายสำคัญที่อนุมานจากการเปลี่ยนสถานะ เช่น จาก 'In UAT' เป็น 'Ready for Release' หรือ 'Approved'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะในระเบียนรายการพัฒนาที่แสดงว่า UAT เสร็จสมบูรณ์ โดยบันทึกไว้ในประวัติกิจกรรมของรายการ.

บันทึก

อนุมานจากการเปลี่ยนสถานะจาก 'UAT' เป็นสถานะที่อนุมัติแล้วหรือพร้อมเผยแพร่.

ประเภทเหตุการณ์ inferred
เตรียมพร้อมสำหรับการเผยแพร่เวอร์ชัน
กิจกรรมนี้หมายถึงรายการพัฒนาผ่านจุดตรวจสอบคุณภาพทั้งหมดและถูกรวมไว้ในรุ่นเผยแพร่ที่ระบุ อนุมานได้เมื่อรายการเชื่อมโยงกับระเบียน Release หรือสถานะเปลี่ยนเป็น 'Ready for Deployment'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'State' เป็น 'Ready for Release' หรือติดตามเวลาที่ฟิลด์ 'Release' ในระเบียนรายการพัฒนาถูกกรอกหรืออัปเดต.

บันทึก

อนุมานจากการเปลี่ยนสถานะหรือการเชื่อมโยงกับระเบียน Release.

ประเภทเหตุการณ์ inferred
บันทึกโค้ด
หมายถึงนักพัฒนาส่งโค้ดเข้า repository ของระบบควบคุมเวอร์ชันที่เชื่อมโยงกับรายการพัฒนา ServiceNow DevOps บันทึกเหตุการณ์นี้โดยตรงจากเครื่องมือ SCM ที่เชื่อมต่อ เช่น Git หรือ GitHub.
เหตุผลที่สำคัญ

การติดตาม commit ช่วยให้เห็นความคืบหน้าและความถี่ของกิจกรรมพัฒนาอย่างละเอียด อีกทั้งยังช่วยเชื่อมโยงการเปลี่ยนแปลงโค้ดแต่ละครั้งกับรายการพัฒนาหลัก.

แหล่งข้อมูล

บันทึกเป็นเหตุการณ์โดยตรงในตาราง Commits [sn_devops_commit] ของ ServiceNow DevOps ซึ่งรับข้อมูลผ่าน webhook จากระบบจัดการซอร์สโค้ดที่เชื่อมต่อ.

บันทึก

บันทึกเมื่อได้รับ webhook แจ้ง commit จากเครื่องมือ SCM.

ประเภทเหตุการณ์ explicit
พบงานที่ต้องแก้ไขซ้ำ
หมายถึงพบปัญหาระหว่างการทดสอบและต้องส่งรายการกลับไปให้ทีมพัฒนา อนุมานได้จากการย้อนกลับของขั้นตอน เช่น สถานะเปลี่ยนจาก 'In QA' กลับเป็น 'In Progress'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากการวิเคราะห์ประวัติฟิลด์ 'State' ในตาราง sys_audit หรือ sys_history_line การเปลี่ยนจากสถานะขั้นตอนหลัง เช่น 'Testing' กลับไปยังสถานะก่อนหน้า เช่น 'In Progress' หมายถึงมีงานแก้ไขซ้ำ.

บันทึก

อนุมานจากการเปลี่ยนสถานะย้อนกลับ เช่น 'Testing' -> 'In Progress'.

ประเภทเหตุการณ์ inferred
ยกเลิกรายการพัฒนา
หมายถึงการยุติรายการพัฒนาก่อนเสร็จสิ้น เป็นสถานะสิ้นสุดอีกแบบหนึ่ง ซึ่งโดยทั่วไปอนุมานจากการตั้งสถานะของรายการเป็น 'Cancelled' หรือ 'Closed Incomplete'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากเวลาที่ฟิลด์ 'State' ในระเบียนรายการพัฒนาเปลี่ยนเป็นสถานะสิ้นสุดที่ยังไม่เสร็จสมบูรณ์ เช่น 'Cancelled'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'Cancelled' หรือสถานะสิ้นสุดที่มีความหมายเทียบเท่า.

ประเภทเหตุการณ์ inferred
เริ่ม Build
เหตุการณ์นี้หมายถึงการเริ่ม build ของไปป์ไลน์ CI/CD ซึ่งมักเกิดจากการ commit โค้ด ServiceNow DevOps บันทึกเป็นการทำงานของไปป์ไลน์และเชื่อมโยงกลับไปยังรายการพัฒนาต้นทาง.
เหตุผลที่สำคัญ

กิจกรรมนี้เชื่อมขั้นตอนพัฒนาเข้ากับการทดสอบหรือการนำระบบขึ้นใช้งานโดยอัตโนมัติ การวิเคราะห์เวลาตั้งแต่ commit จนถึงเริ่ม build ช่วยให้เห็นความล่าช้าในกระบวนการ CI/CD.

แหล่งข้อมูล

บันทึกโดยตรงในตาราง Pipeline Execution [sn_devops_pipeline_execution] เมื่อเริ่ม build ในเครื่องมือ CI/CD ที่เชื่อมต่อ เช่น Jenkins หรือ Azure DevOps.

บันทึก

ดึงข้อมูลจากเวลาเริ่มต้นของระเบียนในตาราง Pipeline Execution.

ประเภทเหตุการณ์ explicit
เริ่ม UAT
หมายถึงการเริ่ม User Acceptance Testing ซึ่งผู้มีส่วนเกี่ยวข้องทางธุรกิจจะตรวจสอบการทำงาน โดยอนุมานเหตุการณ์นี้จากการเปลี่ยนสถานะเป็น 'UAT', 'In UAT' หรือ 'User Acceptance Testing'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะในระเบียนรายการพัฒนา โดยโมเดลสถานะของลูกค้าต้องมีสถานะ UAT แยกต่างหาก.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'UAT'.

ประเภทเหตุการณ์ inferred
เริ่มทดสอบ QA
หมายถึงการเริ่มขั้นตอนทดสอบอย่างเป็นทางการของ Quality Assurance โดยเกือบทุกกรณีอนุมานจากการเปลี่ยนสถานะของรายการพัฒนาเป็นค่าอย่าง 'In QA', 'Testing' หรือ 'Ready for Test'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากเวลาที่ฟิลด์ 'State' ในระเบียนรายการพัฒนา เช่น Story หรือ Defect เปลี่ยนเป็นสถานะเฉพาะของ QA.

บันทึก

อ้างอิงเวลาที่สถานะเปลี่ยนเป็น 'Testing' หรือสถานะที่มีความหมายเทียบเท่า.

ประเภทเหตุการณ์ inferred
เริ่มนำระบบขึ้นใช้งานจริง
กิจกรรมนี้หมายถึงการเริ่มไปป์ไลน์เพื่อนำระบบขึ้นสู่สภาพแวดล้อมใช้งานจริง ServiceNow DevOps บันทึกเหตุการณ์นี้โดยตรงเมื่อขั้นตอน production ของไปป์ไลน์ CI/CD เริ่มทำงาน.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

บันทึกโดยตรงในตาราง Stage Execution Run [sn_devops_stage_execution] โดยกรองเฉพาะขั้นตอนที่เกี่ยวข้องกับสภาพแวดล้อมใช้งานจริง.

บันทึก

ดึงข้อมูลจากเวลาเริ่มต้นของขั้นตอนนำระบบขึ้นใช้งานจริงใน Pipeline Execution.

ประเภทเหตุการณ์ explicit
เริ่มออกแบบ
หมายถึงช่วงที่กำลังจัดทำการออกแบบทางเทคนิคหรือสถาปัตยกรรมโซลูชันสำหรับรายการพัฒนา โดยทั่วไปอนุมานจากการเปลี่ยนค่าฟิลด์สถานะหรือ state ในระเบียนรายการพัฒนาเป็นค่าอย่าง 'Design' หรือ 'Solutioning'.
เหตุผลที่สำคัญ

การวิเคราะห์ระยะเวลาของขั้นตอนออกแบบช่วยให้เห็นคอขวดในการแปลงความต้องการและวางแผนโซลูชัน ก่อนเริ่มงานพัฒนา.

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะในระเบียนรายการพัฒนา เช่น Story [rm_story] ให้ตรวจดูการเปลี่ยนค่าฟิลด์ 'State' หรือฟิลด์ 'Stage' ที่กำหนดเองเป็นค่าที่เกี่ยวข้องกับการออกแบบ.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'Design' หรือสถานะที่มีความหมายใกล้เคียงกัน.

ประเภทเหตุการณ์ inferred
แนะนำ ไม่บังคับ

คู่มือการนำข้อมูลออก

วิธีนำข้อมูลจาก ServiceNow DevOps มาใช้

พร้อมเริ่มต้นหรือยัง?

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

อย่ารอช้า เริ่มปรับปรุงวงจรการพัฒนาซอฟต์แวร์วันนี้

ระบุจุดที่ทำงานได้ไม่เต็มประสิทธิภาพ เพื่อลดระยะเวลาวงจร SDLC ลง 30% หรือมากกว่า.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงได้วันนี้