เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์
เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์
- แอตทริบิวต์ที่แนะนำให้เก็บ
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางดึงข้อมูล
แอตทริบิวต์วงจรการพัฒนาซอฟต์แวร์
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
Activity
|
ชื่อขั้นตอนหรือเหตุการณ์เฉพาะที่เกิดขึ้น เช่น 'สร้าง Issue' หรือ 'ผสาน Merge Request แล้ว'. | ||
|
คำอธิบาย
แอตทริบิวต์กิจกรรมบันทึกเหตุการณ์ต่างๆ ที่เกิดขึ้นกับรายการงานพัฒนา โดย GitLab ไม่ได้เก็บข้อมูลเหล่านี้ไว้ในฟิลด์เดียว แต่ได้มาจากการดำเนินการและฟิลด์เวลาหลายรายการใน Issues, Merge Requests และ CI/CD Pipelines เช่น การสร้าง Issue การส่ง commit การที่ pipeline ล้มเหลว หรือการอนุมัติ merge request ล้วนเป็นกิจกรรมที่แยกจากกัน แอตทริบิวต์นี้เป็นพื้นฐานในการสร้างแผนผังกระบวนการ แสดงเวิร์กโฟลว์ และวิเคราะห์ลำดับกับความถี่ของเหตุการณ์ ใช้ระบุจุดเบี่ยงเบน คอขวดระหว่างขั้นตอน และเส้นทางกระบวนการที่เกิดขึ้นบ่อย.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้กำหนดขั้นตอนในแผนผังกระบวนการ เพื่อให้แสดงและวิเคราะห์เวิร์กโฟลว์การพัฒนาตั้งแต่ต้นจนจบได้.
แหล่งข้อมูล
ได้มาจากประเภทเหตุการณ์และการเปลี่ยนสถานะใน event stream ของ GitLab หรือจากการตีความฟิลด์เวลา เช่น 'created_at', 'merged_at' และ 'closed_at' ใน Issues และ Merge Requests.
ตัวอย่าง
สร้าง Issueเริ่มพัฒนาผสาน Merge Request แล้วPipeline ล้มเหลวติดตั้งใช้งานบน Production แล้ว
|
|||
|
รายการงานพัฒนา
DevelopmentItem
|
รหัสเฉพาะของหน่วยงาน เช่น ฟีเจอร์ การแก้บั๊ก หรืองานที่ต้องทำ ซึ่งใช้เป็นรหัสอ้างอิงหลักของเคส. | ||
|
คำอธิบาย
รายการงานพัฒนาคืองานหนึ่งชิ้นที่ติดตามได้ตลอดวงจรการพัฒนาซอฟต์แวร์ โดยเชื่อมกิจกรรมที่เกี่ยวข้องทั้งหมดตั้งแต่สร้างงานจนถึงติดตั้งใช้งานเป็นเคสเดียวกัน ใน GitLab มักใช้ ID ภายในของ Issue (IID) ซึ่งไม่ซ้ำกันภายในโปรเจกต์ การวิเคราะห์ตามรายการงานพัฒนาช่วยวัดระยะเวลาตั้งแต่ต้นจนจบ ระบุคอขวด และตรวจสอบว่ากระบวนการเป็นไปตามที่กำหนดหรือไม่ ข้อมูลนี้เป็นพื้นฐานในการทำความเข้าใจว่าทีมส่งมอบงานจากแนวคิดไปสู่ production ได้มีประสิทธิภาพเพียงใด.
เหตุผลที่สำคัญ
นี่คือรหัสอ้างอิงหลักที่เชื่อมเหตุการณ์ทั้งหมดในกระบวนการเข้าด้วยกัน ทำให้ติดตามวงจรงานทั้งหมดของรายการงานแต่ละรายการได้.
แหล่งข้อมูล
โดยทั่วไปคือ ID ภายใน (IID) ของ GitLab Issue ซึ่งดูได้จากฟิลด์ 'iid' ในการตอบกลับของ Issues API.
ตัวอย่าง
1024512PRJ-2345
|
|||
|
เวลาเริ่มต้น
StartTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นเมื่อใด. | ||
|
คำอธิบาย
StartTime ระบุวันและเวลาที่กิจกรรมหนึ่งๆ เกิดขึ้นอย่างแม่นยำ สำหรับเหตุการณ์ใน GitLab จะดึงค่าจากฟิลด์เวลาต่างๆ เช่น StartTime ของกิจกรรม 'สร้าง Issue' คือเวลา เวลานี้เป็นข้อมูลหลักด้านเวลาสำหรับ process mining ใช้เรียงเหตุการณ์ตามลำดับเวลา คำนวณระยะห่างระหว่างกิจกรรม วัดระยะเวลารอบ และวิเคราะห์ประสิทธิภาพของกระบวนการในช่วงเวลาต่างๆ.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้แสดงลำดับเหตุการณ์ตามเวลา ซึ่งจำเป็นต่อการคำนวณตัวชี้วัดด้านเวลาและทำความเข้าใจลำดับการทำงานของกระบวนการ.
แหล่งข้อมูล
ดึงจากฟิลด์เวลาต่างๆ ใน GitLab เช่น 'created_at', 'updated_at' และ 'closed_at' ของ Issue รวมถึง 'merged_at' ของ merge request.
ตัวอย่าง
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
ชื่อโปรเจกต์
ProjectName
|
ชื่อโปรเจกต์ GitLab ที่มีรายการงานพัฒนาอยู่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุคลังโค้ดหรือโปรเจกต์ที่ใช้ทำงาน ใน GitLab ทุก Issue และ merge request จะอยู่ภายในโปรเจกต์ การวิเคราะห์ตามชื่อโปรเจกต์ช่วยเปรียบเทียบประสิทธิภาพระหว่างผลิตภัณฑ์ คอมโพเนนต์ หรือบริการ ช่วยระบุว่าโปรเจกต์ใดมีกระบวนการ SDLC ที่มีประสิทธิภาพกว่า และใช้กรองแดชบอร์ดให้แสดงเฉพาะส่วนที่สนใจได้.
เหตุผลที่สำคัญ
ช่วยแบ่งการวิเคราะห์กระบวนการตามผลิตภัณฑ์ แอปพลิเคชัน หรือคอมโพเนนต์ เพื่อให้ปรับปรุงได้ตรงจุด.
แหล่งข้อมูล
ดึงจากฟิลด์ 'name' หรือ 'path_with_namespace' ใน Project API โดยเชื่อมโยงผ่าน 'project_id' ใน Issues และ Merge Requests.
ตัวอย่าง
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
ประเภทงานพัฒนา
DevelopmentItemType
|
ประเภทของรายการงานพัฒนา เช่น 'ฟีเจอร์', 'บั๊ก', 'งาน' หรือ 'การบำรุงรักษา'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้จัดประเภทลักษณะของงานที่ทำ ใน GitLab มักใช้ label กับ Issue เพื่อแยกงานฟังก์ชันใหม่ การแก้ข้อบกพร่อง หนี้ทางเทคนิค และงานประเภทอื่นๆ การวิเคราะห์ตามประเภทงานพัฒนาช่วยเปรียบเทียบโฟลว์กระบวนการและระยะเวลารอบของงานแต่ละประเภท เช่น วิเคราะห์ว่าการแก้บั๊กใช้เวลาน้อยกว่าการพัฒนาฟีเจอร์หรือไม่ หรือการจัดการหนี้ทางเทคนิคใช้ขั้นตอนตรวจสอบที่ต่างออกไปหรือไม่.
เหตุผลที่สำคัญ
การแบ่งกระบวนการตามประเภทงานช่วยระบุว่างานบางประเภทมีแนวโน้มล่าช้า ต้องแก้งานซ้ำ หรือเบี่ยงเบนจากกระบวนการมากกว่าหรือไม่.
แหล่งข้อมูล
โดยทั่วไปได้จาก 'labels' ที่กำหนดให้กับ GitLab Issue โดยต้องมีตรรกะการจับคู่เพื่อแปลง label เฉพาะให้เป็นประเภทมาตรฐาน.
ตัวอย่าง
ฟีเจอร์บั๊กงานหนี้ทางเทคนิค
|
|||
|
ผู้รับผิดชอบ
Assignee
|
ผู้ใช้ที่ได้รับมอบหมายให้ดูแล Issue หรือ merge request ในเวลาที่เกิดเหตุการณ์. | ||
|
คำอธิบาย
ผู้รับผิดชอบคือผู้พัฒนาหรือผู้ใช้ที่ดูแลงาน ณ จุดหนึ่งของกระบวนการ ใน GitLab ข้อมูลนี้อยู่ในฟิลด์ การวิเคราะห์ตามผู้รับผิดชอบมีความสำคัญต่อแดชบอร์ด 'ภาระงานและการจัดสรรงานของนักพัฒนา' ช่วยให้เข้าใจการใช้ทรัพยากร ระบุผู้ใช้หรือทีมที่มีงานล้นมือ และวิเคราะห์การส่งต่องานระหว่างบุคคล.
เหตุผลที่สำคัญ
ติดตามว่าใครเป็นผู้ทำงาน ช่วยวิเคราะห์ภาระงาน ประสิทธิภาพการจัดสรรทรัพยากร และความล่าช้าที่เกิดจากการส่งต่องาน.
แหล่งข้อมูล
ดึงจากฟิลด์ 'assignee.username' หรือ 'assignees' ในการตอบกลับของ GitLab Issues API และ Merge Requests API.
ตัวอย่าง
jdoeasmithr.williams
|
|||
|
ระดับความรุนแรง
Severity
|
ระดับความรุนแรงของรายการงานพัฒนา ซึ่งมักใช้กับบั๊กหรือเหตุการณ์ผิดปกติ. | ||
|
คำอธิบาย
ระดับความรุนแรงแสดงผลกระทบของบั๊กหรือปัญหา ตั้งแต่ระดับวิกฤตจนถึงเล็กน้อย GitLab ไม่มีฟิลด์ระดับความรุนแรงในตัว จึงมักกำหนดผ่าน label เช่น 'severity::1' หรือ 'severity::2' แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'แนวโน้มการยกระดับความรุนแรง' และ KPI ที่เกี่ยวข้อง การวิเคราะห์การเปลี่ยนแปลงระดับความรุนแรงตลอดวงจรงานช่วยชี้ให้เห็นปัญหาที่ประเมินความรุนแรงต่ำเกินไปตั้งแต่แรก หรือกระบวนการที่ทำให้ปัญหาหนักขึ้น.
เหตุผลที่สำคัญ
ช่วยจัดลำดับความสำคัญของงานและวิเคราะห์ว่างานที่มีความรุนแรงสูงได้รับการจัดการเร็วขึ้นหรือไม่ การติดตามการเปลี่ยนแปลงช่วยคำนวณ KPI 'ความถี่ในการยกระดับความรุนแรง'.
แหล่งข้อมูล
ได้จาก 'labels' ที่กำหนดให้กับ GitLab Issue โดยต้องจับคู่ label เช่น 'S1' และ 'S2' กับระดับความรุนแรง.
ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
|
|||
|
เวลาสิ้นสุด
EndTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด. | ||
|
คำอธิบาย
EndTime ระบุวันและเวลาที่กิจกรรมเสร็จสิ้นอย่างแม่นยำ สำหรับเหตุการณ์ย่อยหลายรายการใน GitLab เช่น 'สร้าง Issue' EndTime จะตรงกับ StartTime ส่วนกิจกรรมที่มีระยะเวลา เช่น 'ตรวจสอบโค้ด' จะหมายถึงเวลาที่เสร็จสิ้น เช่น เวลาที่ได้รับอนุมัติขั้นสุดท้าย แอตทริบิวต์นี้จำเป็นต่อการคำนวณระยะเวลาของแต่ละกิจกรรม (เวลาประมวลผล) ได้อย่างถูกต้อง และช่วยวิเคราะห์คอขวดโดยแยกเวลาที่ใช้ลงมือทำงานออกจากเวลาระหว่างรอทำงานขั้นถัดไป.
เหตุผลที่สำคัญ
ช่วยคำนวณระยะเวลาของกิจกรรม (เวลาประมวลผล) ได้อย่างแม่นยำ ซึ่งจำเป็นต่อการระบุขั้นตอนที่ไม่มีประสิทธิภาพในกระบวนการ.
แหล่งข้อมูล
สำหรับเหตุการณ์ย่อย เวลานี้ตรงกับ StartTime ส่วนกิจกรรมที่มีระยะเวลาต้องอนุมานจากเหตุการณ์ที่แสดงว่ากิจกรรมนั้นเสร็จสิ้น.
ตัวอย่าง
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Cycle Time
CycleTime
|
เวลารวมตั้งแต่กิจกรรมแรกจนถึงกิจกรรมสุดท้ายของรายการพัฒนา. | ||
|
คำอธิบาย
Cycle Time เป็นตัวชี้วัดที่คำนวณจากระยะเวลารวมของเคส โดยทั่วไปคำนวณจากเวลาระหว่างเหตุการณ์แรกสุด เช่น 'Issue Created' กับเหตุการณ์สุดท้าย เช่น 'Deployed to Production' ของรายการพัฒนาแต่ละรายการ นี่คือตัวชี้วัด KPI หลักสำหรับวัดประสิทธิภาพของกระบวนการโดยรวม และเป็นตัวชี้วัดสำคัญในแดชบอร์ดอย่าง 'SDLC End-to-End Cycle Time' ใช้ติดตามการปรับปรุงและค้นหาเคสที่ใช้เวลานาน ซึ่งอาจบ่งชี้ถึงปัญหาเชิงระบบ.
เหตุผลที่สำคัญ
นี่คือ KPI หลักของ process mining ที่ใช้วัดประสิทธิภาพตั้งแต่ต้นจนจบของวงจรการพัฒนา.
แหล่งข้อมูล
เครื่องมือ process mining คำนวณโดยนำ StartTime ต่ำสุดลบออกจาก StartTime สูงสุดของ CaseId แต่ละรายการที่ไม่ซ้ำกัน.
ตัวอย่าง
10 วัน 4 ชั่วโมง23 ชั่วโมง 15 นาที35 วัน
|
|||
|
Target Branch
TargetBranch
|
ชื่อ branch ปลายทางที่ใช้ผสาน Merge Request. | ||
|
คำอธิบาย
Target Branch คือ branch ที่ต้องการผสานการเปลี่ยนแปลงเข้าไป เช่น 'main', 'develop' หรือ branch สำหรับรุ่นที่กำลังจะออก เช่น 'release/1.5' ข้อมูลนี้เป็นส่วนสำคัญของ Merge Request การวิเคราะห์แยกตาม Target Branch ช่วยให้เห็นความแตกต่างของกระบวนการเมื่อผสานโค้ดไปยังปลายทางแต่ละแบบ ตัวอย่างเช่น การผสานเข้า 'main' อาจต้องผ่านการอนุมัติที่เข้มงวดกว่าและใช้เวลานานกว่าการผสานเข้า feature branch นอกจากนี้ยังช่วยแยกการนำขึ้นระบบจริงออกจากการผสานโค้ดประเภทอื่นได้.
เหตุผลที่สำคัญ
ช่วยแยกเวิร์กโฟลว์การพัฒนาและการออกรุ่นแต่ละแบบ เพราะกระบวนการอาจแตกต่างกันมากตาม branch ปลายทาง.
แหล่งข้อมูล
ดึงข้อมูลจากฟิลด์ 'target_branch' ในการตอบกลับของ GitLab Merge Requests API.
ตัวอย่าง
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
ชื่อ Milestone
MilestoneTitle
|
ชื่อ Milestone หรือ sprint ที่กำหนดให้รายการพัฒนา. | ||
|
คำอธิบาย
ใน GitLab ใช้ Milestone เพื่อติดตามงานตามเป้าหมายหรือกรอบเวลาที่กำหนด เช่น sprint หรือรุ่นซอฟต์แวร์ แอตทริบิวต์นี้บันทึกชื่อหรือหัวข้อของ Milestone แอตทริบิวต์นี้ช่วยวิเคราะห์ประสิทธิภาพของกระบวนการในแต่ละ sprint หรือช่วงวางแผน คุณใช้ดูได้ว่า Cycle Time ดีขึ้นจาก sprint หนึ่งไปยังอีก sprint หรือไม่ หรือกรองมุมมองกระบวนการให้แสดงเฉพาะงานที่เกี่ยวข้องกับรุ่นซอฟต์แวร์ที่กำลังจะออก.
เหตุผลที่สำคัญ
เชื่อมโยงงานพัฒนากับรอบการวางแผน เช่น sprint หรือรุ่นซอฟต์แวร์ เพื่อวิเคราะห์ผลการทำงานเทียบกับกรอบเวลาที่วางไว้.
แหล่งข้อมูล
ดึงข้อมูลจากฟิลด์ 'milestone.title' ในการตอบกลับของ GitLab Issues API หรือ Merge Requests API.
ตัวอย่าง
Q4-2023 ReleaseSprint 23.11Phase 1: MVP
|
|||
|
ชื่อทีม
TeamName
|
ทีมพัฒนาที่เกี่ยวข้องกับโปรเจกต์หรือผู้รับผิดชอบ. | ||
|
คำอธิบาย
ชื่อทีมระบุกลุ่มหรือทีมย่อยที่รับผิดชอบรายการงานพัฒนา โดยทั่วไป GitLab ไม่มีฟิลด์มาตรฐานสำหรับข้อมูลนี้ จึงมักอนุมานจากรูปแบบการตั้งชื่อโปรเจกต์ โครงสร้างกลุ่ม หรือการจับคู่ผู้รับผิดชอบกับทีมจากตารางอ้างอิงภายนอก แอตทริบิวต์นี้ใช้วิเคราะห์ประสิทธิภาพกระบวนการในระดับทีม ช่วยเปรียบเทียบประสิทธิภาพ ภาระงาน และการทำตามกระบวนการของแต่ละทีม รวมถึงใช้กับแดชบอร์ดอย่าง 'วิเคราะห์คอขวดแยกตามขั้นตอน' ในมุมมองระดับทีม.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประสิทธิภาพและเปรียบเทียบกระบวนการระหว่างทีม เพื่อระบุคอขวดเฉพาะของแต่ละทีมหรือแนวทางปฏิบัติที่ดี.
แหล่งข้อมูล
มักได้จากการจับคู่ชื่อโปรเจกต์หรือผู้รับผิดชอบกับโครงสร้างทีมที่กำหนดไว้นอก GitLab หรืออนุมานจากลำดับชั้นกลุ่มใน GitLab.
ตัวอย่าง
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
|
เป็นงานแก้ซ้ำหรือไม่
IsRework
|
ค่าสถานะบูลีนที่ระบุว่ากิจกรรมเป็นส่วนหนึ่งของการวนกลับไปแก้งานหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์ที่คำนวณนี้ใช้ระบุกิจกรรมที่เป็นการย้อนกลับไปทำขั้นตอนก่อนหน้า เช่น กลับไปพัฒนาอีกครั้งหลังเริ่มทดสอบแล้ว โดยทั่วไปจะตรวจจับรูปแบบลำดับกิจกรรมที่กำหนด เช่น เหตุการณ์ 'Development Started' เกิดขึ้นหลังเหตุการณ์ 'Pipeline Failed' หรือ 'QA Testing Started' ในเคสเดียวกัน แอตทริบิวต์นี้ใช้กับแดชบอร์ด 'Rework & Rerun Analysis' และ KPI 'Rework Rate After Testing' โดยตรง ช่วยกรองและวัดปริมาณงานแก้ซ้ำได้ง่ายขึ้น ทำให้ทีมเข้าใจความถี่ สาเหตุ และผลกระทบต่องานตามกำหนดเวลา.
เหตุผลที่สำคัญ
ระบุและวัดปริมาณงานแก้ซ้ำโดยตรง ช่วยให้วิเคราะห์สาเหตุและผลกระทบของความไม่มีประสิทธิภาพในกระบวนการและปัญหาด้านคุณภาพได้ง่าย.
แหล่งข้อมูล
เครื่องมือ process mining คำนวณโดยวิเคราะห์ลำดับกิจกรรมของแต่ละเคสและค้นหารูปแบบที่บ่งชี้ว่ามีการแก้งานซ้ำ.
ตัวอย่าง
truefalse
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบุระบบที่เป็นแหล่งที่มาของข้อมูล. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลกระบวนการ สำหรับโมเดลข้อมูลนี้ ค่าจะเป็น 'GitLab' เสมอ แอตทริบิวต์นี้สำคัญในสภาพแวดล้อมที่รวมข้อมูลกระบวนการจากหลายระบบ เช่น Jira สำหรับวางแผน และ GitLab สำหรับดำเนินงาน ช่วยกรองและแบ่งกลุ่มข้อมูล รวมถึงติดตามที่มาของข้อมูลได้.
เหตุผลที่สำคัญ
ช่วยให้ทราบแหล่งที่มาของข้อมูลอย่างชัดเจน ซึ่งสำคัญต่อการกำกับดูแลข้อมูลและการเชื่อมข้อมูลจากระบบต่างๆ ในองค์กร.
แหล่งข้อมูล
เป็นค่าคงที่ 'GitLab' ซึ่งเพิ่มระหว่างการแปลงข้อมูล.
ตัวอย่าง
GitLab
|
|||
|
รุ่นซอฟต์แวร์
ReleaseVersion
|
แท็กเวอร์ชันซอฟต์แวร์ที่วางแผนไว้หรือใช้งานจริง ซึ่งเชื่อมโยงกับการนำขึ้นระบบ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุรุ่นซอฟต์แวร์ที่รายการพัฒนาสังกัด ใน GitLab อาจเชื่อมโยงข้อมูลนี้ผ่าน Milestone, protected tag หรือรายการในฟีเจอร์ Releases ข้อมูลนี้จำเป็นต่อแดชบอร์ด 'Release Schedule Adherence Tracking' โดยเปรียบเทียบวันที่นำขึ้นระบบจริงกับวันที่วางแผนไว้สำหรับรุ่นนั้น องค์กรจึงวัดได้ว่าทำตามกำหนดการได้ดีเพียงใด และวิเคราะห์สาเหตุของความล่าช้าในการออกรุ่นได้.
เหตุผลที่สำคัญ
เชื่อมโยงรายการพัฒนากับรุ่นซอฟต์แวร์ที่ระบุ ซึ่งสำคัญต่อการติดตามความคืบหน้าและการทำตามกำหนดการออกรุ่น.
แหล่งข้อมูล
ดึงข้อมูลได้จาก GitLab Releases ชื่อ git tag หรือชื่อ Milestone ที่ใช้วางแผนการออกรุ่น.
ตัวอย่าง
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
เวลารอระหว่างส่งต่องาน
HandoffWaitTime
|
เวลาว่างที่คำนวณได้ระหว่างกิจกรรมสองรายการที่ทำต่อเนื่องกันโดยผู้รับผิดชอบคนละคน. | ||
|
คำอธิบาย
ตัวชี้วัดนี้คำนวณช่วงเวลาระหว่างการทำกิจกรรมหนึ่งเสร็จกับการเริ่มกิจกรรมถัดไป โดยนับเฉพาะกรณีที่ผู้รับผิดชอบเปลี่ยนคน เช่น วัดเวลาตั้งแต่นักพัฒนาทำงานเสร็จจนถึงผู้ตรวจทานเริ่มตรวจโค้ด ตัวชี้วัดนี้ใช้คำนวณ KPI 'Average Handoff Wait Time' และช่วยค้นหาความไม่มีประสิทธิภาพที่ซ่อนอยู่ในการจัดสรรทรัพยากรและการสื่อสารระหว่างทีมหรือบุคคล พร้อมชี้ให้เห็นความล่าช้าที่ไม่ได้เกิดจากการลงมือทำงาน.
เหตุผลที่สำคัญ
วัดเวลาว่างระหว่างการส่งต่องานให้บุคคลหรือทีมอื่น ช่วยให้เห็นความล่าช้าและปัญหาการสื่อสารที่ซ่อนอยู่.
แหล่งข้อมูล
เครื่องมือ process mining คำนวณค่านี้โดยวิเคราะห์เหตุการณ์ที่เกิดขึ้นต่อเนื่องกันในเคส ตรวจสอบว่า 'Assignee' เปลี่ยนไปหรือไม่ แล้วคำนวณส่วนต่างของเวลา.
ตัวอย่าง
1 วัน 2 ชั่วโมง15 นาที8 ชั่วโมง
|
|||
|
สถานะ Merge Request
MergeRequestStatus
|
สถานะของ Merge Request ที่เกี่ยวข้องกับเหตุการณ์ เช่น 'Opened', 'Merged' หรือ 'Closed'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกสถานะของ Merge Request (MR) ณ เวลาที่เกิดเหตุการณ์ โดย MR ใน GitLab มีสถานะต่างกัน ได้แก่ 'opened', 'closed', 'merged' และ 'locked' ซึ่งแยกจากสถานะโดยรวมของรายการพัฒนา การติดตามสถานะ MR มีความสำคัญต่อการวิเคราะห์ขั้นตอนการผสานโค้ดใน SDLC โดยตรง และช่วยให้แดชบอร์ดอย่าง 'Code Review Cycle Time & Throughput' แสดงช่วงเวลาที่ล่าช้าระหว่างการสร้าง MR การตรวจทาน การอนุมัติ และการผสานโค้ดได้ชัดเจนขึ้น.
เหตุผลที่สำคัญ
ช่วยให้เห็นภาพขั้นตอนการตรวจทานและผสานโค้ด ซึ่งมักเป็นคอขวดสำคัญใน SDLC.
แหล่งข้อมูล
ดึงข้อมูลจากฟิลด์ 'state' ในการตอบกลับของ GitLab Merge Requests API.
ตัวอย่าง
เปิดอยู่mergedปิดแล้วlocked
|
|||
|
สถานะ Pipeline
PipelineStatus
|
สถานะการทำงานของ CI/CD pipeline เช่น 'Success', 'Failed' หรือ 'Running'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผลการทำงานของ CI/CD pipeline ที่เกี่ยวข้องกับ commit หรือ Merge Request สถานะที่พบบ่อยใน GitLab ได้แก่ 'running', 'pending', 'success', 'failed', 'canceled' และ 'skipped' ข้อมูลนี้จำเป็นต่อแดชบอร์ด 'Rework & Rerun Analysis' เพราะ pipeline ที่ล้มเหลวบ่อยอาจทำให้ต้องแก้งานซ้ำและเกิดความล่าช้า การวิเคราะห์ความถี่ จุดที่เกิด และผลกระทบของปัญหาเหล่านี้ช่วยให้ปรับปรุงประสิทธิภาพการพัฒนาและคุณภาพโค้ดได้.
เหตุผลที่สำคัญ
ติดตามผลสำเร็จและความล้มเหลวของการ build และทดสอบอัตโนมัติ พร้อมชี้ให้เห็นการวนกลับไปแก้งานและปัญหาด้านคุณภาพโค้ดหรือระบบทดสอบอัตโนมัติ.
แหล่งข้อมูล
ดึงข้อมูลจากฟิลด์ 'status' ในการตอบกลับของ GitLab CI/CD Pipelines API.
ตัวอย่าง
successfailedrunningcanceled
|
|||
|
สถานะงานพัฒนา
DevelopmentItemStatus
|
สถานะของรายการงานพัฒนาในเวลาที่เกิดเหตุการณ์ เช่น 'เปิดอยู่', 'กำลังดำเนินการ' หรือ 'ปิดแล้ว'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงสถานะของรายการงานหลัก ซึ่งโดยทั่วไปคือ Issue ใน GitLab โดย Issue มีค่า การติดตามการเปลี่ยนสถานะจำเป็นต่อการทำความเข้าใจวงจรของเคส ช่วยระบุว่าแต่ละรายการใช้เวลาอยู่ในแต่ละสถานะนานเท่าใด และใช้กรองงานที่กำลังดำเนินการหรืองานที่เสร็จแล้วในแดชบอร์ด เช่น 'ระยะเวลารอบ SDLC ตั้งแต่ต้นจนจบ' ได้.
เหตุผลที่สำคัญ
แสดงสถานะของเคส ณ เวลาหนึ่ง ช่วยวิเคราะห์เวลาที่ใช้ในแต่ละขั้นตอน และกรองงานที่กำลังดำเนินการกับงานที่เสร็จแล้ว.
แหล่งข้อมูล
สถานะหลักมาจากฟิลด์ 'state' ของ GitLab Issue ('opened', 'closed') ส่วนสถานะที่ละเอียดขึ้นมักอนุมานจาก label.
ตัวอย่าง
เปิดอยู่ปิดแล้วกำลังดำเนินการกำลังตรวจสอบ
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่าข้อมูลของเหตุการณ์นี้ได้รับการดึงจากระบบต้นทางและอัปเดตล่าสุดเมื่อใด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกวันและเวลาที่ดึงหรืออัปเดตข้อมูลเหตุการณ์ในชุดข้อมูล process mining ล่าสุด ไม่ได้ระบุเวลาที่เหตุการณ์เกิดขึ้น แต่ระบุเวลาที่ซิงโครไนซ์ระเบียนเหตุการณ์ล่าสุด ข้อมูลนี้จำเป็นต่อการตรวจสอบว่าข้อมูลเป็นปัจจุบันเพียงใด และช่วยยืนยันว่าการวิเคราะห์กระบวนการใช้ข้อมูลที่ทันเวลา ผู้ใช้จึงมั่นใจได้ว่าแดชบอร์ดและ KPI อ้างอิงข้อมูลล่าสุด พร้อมทราบว่าข้อมูลวิเคราะห์อาจล่าช้าจากระบบต้นทางเท่าใด.
เหตุผลที่สำคัญ
แสดงความใหม่ของข้อมูลอย่างชัดเจน เพื่อให้ผู้ใช้ทราบว่าการวิเคราะห์กระบวนการเป็นปัจจุบันเพียงใด.
แหล่งข้อมูล
เครื่องมือดึงข้อมูลหรือกระบวนการ ETL จะสร้างและบันทึกเวลานี้เมื่อมีการรีเฟรชข้อมูล.
ตัวอย่าง
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
กิจกรรมในวงจรการพัฒนาซอฟต์แวร์
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
ติดตั้งใช้งานบน Production แล้ว
|
กิจกรรมนี้หมายถึงการติดตั้งโค้ดบนสภาพแวดล้อม production ที่ใช้งานจริงสำเร็จ ทำให้ผู้ใช้ปลายทางเข้าถึงได้ ระบบบันทึกเหตุการณ์นี้เมื่องาน 'deploy to production' ที่ระบุใน pipeline CI/CD ของ GitLab ทำงานสำเร็จ. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์สิ้นสุดหลักของกระบวนการ ซึ่งหมายถึงการส่งมอบคุณค่าแล้ว จำเป็นต่อการวัดระยะเวลารอบ SDLC ตั้งแต่ต้นจนจบและความถี่ในการเผยแพร่.
แหล่งข้อมูล
ดึงข้อมูลจากเวลา 'finished_at' ของงาน CI/CD ที่สำเร็จและกำหนดไว้สำหรับติดตั้งใช้งานบน production โดยเฉพาะ ฟีเจอร์ Environments ของ GitLab ติดตามเหตุการณ์นี้โดยตรง.
บันทึก
ใช้เวลา 'finished_at' จากงาน CI ที่ติดตั้งใช้งานบน production สำเร็จ.
ประเภทเหตุการณ์
explicit
|
|||
|
ผสาน Merge Request แล้ว
|
กิจกรรมนี้หมายถึงกระบวนการตรวจสอบและผสานรวมโค้ดเสร็จสมบูรณ์ โดยเกิดขึ้นเมื่อผู้ใช้ผสาน branch ของ merge request เข้ากับ branch เป้าหมาย. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสำคัญที่แสดงว่าการพัฒนาและการตรวจสอบเสร็จสิ้น ใช้เป็นจุดสิ้นสุดในการวัดระยะเวลารอบการพัฒนา และเป็นจุดเริ่มต้นในการวัดเวลาจนถึงการติดตั้งใช้งาน.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้โดยตรงจากเวลา 'merged_at' ในตาราง 'merge_requests' และยังสร้าง system note เมื่อผสานรวมแล้วด้วย.
บันทึก
ใช้เวลา 'merged_at' ของ merge request.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้าง Issue
|
กิจกรรมนี้เป็นจุดเริ่มต้นของวงจรการพัฒนา โดยบันทึกการสร้างรายการงานใหม่ เช่น ฟีเจอร์ บั๊ก หรืองานที่ต้องทำ ระบบจะบันทึกเหตุการณ์นี้เมื่อผู้ใช้สร้าง Issue ใหม่ใน GitLab พร้อมบันทึกเวลาที่สร้าง. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการตั้งแต่ต้นจนจบ การวิเคราะห์เวลาตั้งแต่สร้าง Issue จนถึงติดตั้งใช้งานช่วยให้เห็นระยะเวลาตลอดวงจร SDLC.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้โดยตรงจากเวลา 'created_at' ในตาราง 'issues' หรือผ่าน Issues API นอกจากนี้ system notes ยังบันทึกเหตุการณ์การสร้างไว้ด้วย.
บันทึก
ใช้เวลา 'created_at' ของ Issue.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้าง Merge Request
|
หมายถึงงานพัฒนาเบื้องต้นเสร็จแล้ว และโค้ดพร้อมสำหรับการตรวจสอบและรวมเข้าด้วยกัน นี่เป็นเหตุการณ์หลักที่ GitLab บันทึกโดยตรงเมื่อผู้พัฒนาเปิด merge request (MR) ใหม่. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสำคัญที่แสดงการส่งต่องานจากการพัฒนาไปสู่การตรวจสอบและทดสอบ ใช้เป็นจุดเริ่มต้นในการวิเคราะห์วงจรการตรวจสอบโค้ดและ pipeline CI/CD ทั้งหมด.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้โดยตรงจากเวลา 'created_at' ในตาราง 'merge_requests' หรือผ่าน Merge Requests API.
บันทึก
ใช้เวลา 'created_at' ของ merge request.
ประเภทเหตุการณ์
explicit
|
|||
|
Pipeline ล้มเหลว
|
กิจกรรมนี้เกิดขึ้นเมื่อการทำงานของ pipeline CI/CD ล้มเหลวในขั้นตอนใดขั้นตอนหนึ่ง เช่น build ผิดพลาดหรือการทดสอบไม่ผ่าน GitLab บันทึกสถานะสุดท้ายของทุก pipeline โดยตรง จึงระบุความล้มเหลวได้ง่าย. | ||
|
เหตุผลที่สำคัญ
Pipeline ที่ล้มเหลวเป็นสาเหตุหลักของการแก้งาน การวิเคราะห์ความถี่ ระยะเวลา และสาเหตุช่วยให้พบปัญหาคุณภาพ การทดสอบที่ให้ผลไม่แน่นอน และคอขวดในวงจรการส่งผลกลับไปยังนักพัฒนา
แหล่งข้อมูล
ระบุจากสถานะ 'failed' ของระเบียน pipeline ในตาราง 'ci_pipelines' เวลา 'finished_at' แสดงเวลาที่เกิดความล้มเหลว.
บันทึก
กรองระเบียน pipeline ที่มีสถานะ 'failed' แล้วใช้เวลา 'finished_at'.
ประเภทเหตุการณ์
explicit
|
|||
|
ปิด Issue
|
หมายถึงการปิดรายการงานอย่างเป็นทางการ ซึ่งโดยทั่วไปเกิดขึ้นหลังจากติดตั้งและตรวจสอบการเปลี่ยนแปลงแล้ว GitLab บันทึกเหตุการณ์นี้โดยตรงเมื่อผู้ใช้ปิด Issue. | ||
|
เหตุผลที่สำคัญ
การปิด Issue มักหมายถึงงานที่เกี่ยวข้องทั้งหมดเสร็จสิ้น การเปรียบเทียบเวลานี้กับเวลาติดตั้งใช้งานช่วยให้เห็นความล่าช้าในการตรวจสอบหลังติดตั้งหรือในขั้นตอนธุรการ.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้โดยตรงจากเวลา 'closed_at' ในตาราง 'issues' หรือจาก system note ที่เกี่ยวข้อง.
บันทึก
ใช้เวลา 'closed_at' ของ Issue.
ประเภทเหตุการณ์
explicit
|
|||
|
เพิ่มการอนุมัติ
|
หมายถึงผู้ตรวจสอบอนุมัติการเปลี่ยนแปลงโค้ดใน merge request อย่างเป็นทางการ GitLab บันทึกเหตุการณ์นี้โดยตรงเมื่อผู้ใช้คลิกปุ่ม 'Approve'. | ||
|
เหตุผลที่สำคัญ
การอนุมัติเป็นจุดตรวจสอบคุณภาพที่สำคัญ การติดตามช่วยวิเคราะห์เวลาที่ใช้ในการขออนุมัติที่จำเป็น และตรวจสอบว่าปฏิบัติตามนโยบายการตรวจสอบหรือไม่.
แหล่งข้อมูล
ดึงข้อมูลจากเหตุการณ์อนุมัติ merge request ซึ่งดูได้ผ่าน Approvals API หรือจากประวัติของ MR.
บันทึก
ใช้เวลาจากบันทึกเหตุการณ์การอนุมัติ merge request.
ประเภทเหตุการณ์
explicit
|
|||
|
มอบหมาย Issue
|
แสดงการมอบหมาย Issue ให้กับนักพัฒนาหรือทีมที่ระบุ ซึ่งหมายความว่ามีผู้รับผิดชอบงานแล้ว GitLab บันทึกเหตุการณ์นี้โดยตรงทุกครั้งที่มีการกรอกหรือเปลี่ยนช่อง assignee ของ Issue. | ||
|
เหตุผลที่สำคัญ
การติดตามการมอบหมายงานมีความสำคัญต่อการวิเคราะห์การจัดสรรทรัพยากร ภาระงานของทีม และเวลาส่งต่องาน อีกทั้งช่วยระบุความล่าช้าระหว่างการสร้างงานกับการเริ่มรับงาน.
แหล่งข้อมูล
ดึงข้อมูลจาก system notes ของ Issue ใน GitLab ซึ่งบันทึกเวลาที่เพิ่มหรือเปลี่ยน 'assignee' โดยมีการบันทึกเวลาของเหตุการณ์ไว้ในโน้ต.
บันทึก
ดึงเหตุการณ์ 'assignee changed' จาก system notes ของ Issue.
ประเภทเหตุการณ์
explicit
|
|||
|
เริ่ม Pipeline
|
หมายถึงการเริ่ม pipeline CI/CD อัตโนมัติ ซึ่งโดยทั่วไปจะทำงาน build ทดสอบ และสแกนความปลอดภัย GitLab จะสร้างระเบียน pipeline พร้อมเวลาเริ่มต้นโดยตรงทุกครั้งที่มีการเรียกใช้ pipeline เช่น จาก commit หรือการสร้าง MR. | ||
|
เหตุผลที่สำคัญ
การติดตามการทำงานของ pipeline จำเป็นต่อการตรวจสอบสุขภาพและประสิทธิภาพของกระบวนการทดสอบและผสานรวมอัตโนมัติ อีกทั้งช่วยให้เห็นว่าใช้เวลาไปกับการตรวจสอบอัตโนมัตินานเท่าใด.
แหล่งข้อมูล
ดึงข้อมูลจากเวลา 'created_at' หรือ 'started_at' ของระเบียน pipeline ในตาราง 'ci_pipelines' หรือผ่าน Pipelines API.
บันทึก
ใช้เวลาจากระเบียนการทำงานของ pipeline ที่เชื่อมโยงกับ branch ของ MR.
ประเภทเหตุการณ์
explicit
|
|||
|
เริ่มตรวจสอบโค้ด
|
หมายถึงการเริ่มกระบวนการตรวจสอบโดยเพื่อนร่วมทีมสำหรับ merge request โดยอนุมานจากการดำเนินการแรกที่เกี่ยวข้องกับการตรวจสอบ เช่น ความคิดเห็นแรกหรือ thread แรกที่ผู้ใช้ซึ่งไม่ใช่ผู้เขียนโพสต์ไว้. | ||
|
เหตุผลที่สำคัญ
การวัดเวลาตั้งแต่สร้าง MR จนเริ่มตรวจสอบช่วยให้เห็นความล่าช้าจากการรอคิว การลดเวลารอนี้เป็นกุญแจสำคัญในการย่นวงจรการตรวจสอบโค้ดโดยรวม.
แหล่งข้อมูล
อนุมานจากเวลาของความคิดเห็นหรือ thread ตรวจสอบรายการแรกใน merge request ที่มาจากผู้ใช้ซึ่งไม่ใช่ผู้เขียน MR ข้อมูลนี้ดูได้จาก system notes หรือ Notes API.
บันทึก
ค้นหาเวลาของความคิดเห็นแรกใน MR จากผู้ใช้ที่ไม่ใช่ผู้เขียน.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มติดตั้งใช้งาน
|
หมายถึงการเริ่มนำโค้ดไปเผยแพร่ในสภาพแวดล้อมที่ระบุ เช่น staging หรือ production ใน GitLab เหตุการณ์นี้ตรงกับการเริ่มงาน 'deploy' ภายใน pipeline CI/CD. | ||
|
เหตุผลที่สำคัญ
การติดตามเวลาเริ่มติดตั้งใช้งานช่วยแยกระยะเวลาของขั้นตอนนี้ออกมาได้ และจำเป็นต่อการวัดและปรับปรุงเวลาจนถึงการติดตั้งใช้งาน.
แหล่งข้อมูล
ดึงข้อมูลจากเวลา 'started_at' ของงาน CI/CD ที่กำหนดให้เป็นงานติดตั้งใช้งาน ซึ่งเป็นส่วนหนึ่งของฟีเจอร์ Environments and Deployments ใน GitLab.
บันทึก
ใช้เวลา 'started_at' จากบันทึกงาน CI สำหรับงานติดตั้งใช้งาน.
ประเภทเหตุการณ์
explicit
|
|||
|
เริ่มพัฒนา
|
กิจกรรมนี้หมายถึงการเริ่มลงมือเขียนโค้ดใน Issue โดยทั่วไปจะอนุมานจาก commit แรกที่ส่งขึ้น branch ซึ่งเชื่อมโยงกับ Issue เนื่องจาก GitLab ไม่มีปุ่ม 'start development' โดยตรง. | ||
|
เหตุผลที่สำคัญ
ระบุจุดเริ่มต้นที่แน่นอนของงานพัฒนาที่สร้างคุณค่า ช่วยวัดเวลาที่ใช้เขียนโค้ดจริงได้แม่นยำ และแยกออกจากเวลาวางแผนหรือเวลารอคิว.
แหล่งข้อมูล
อนุมานจากเวลาของ commit แรกบน feature branch ที่เชื่อมโยงกับ Issue โดยต้องเชื่อมโยง Issue กับ branch ซึ่งมักทำผ่านรูปแบบการตั้งชื่อหรือ metadata.
บันทึก
ค้นหาเวลาของ commit แรกบน branch ที่เชื่อมโยงกับ ID ของ Issue.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เตรียมข้อมูลและเริ่มปรับปรุงวงจรการพัฒนาซอฟต์แวร์ของคุณ เริ่มปรับปรุงกระบวนการได้เลยวันนี้!
ยกระดับวงจรการพัฒนาซอฟต์แวร์ เริ่มปรับปรุงได้เลย
ลดคอขวดใน SDLC ลด cycle time 30% และยกระดับคุณภาพ.
ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้ทันที.