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

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

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

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

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

ฟิลด์ข้อมูลเหล่านี้เป็นรายการแนะนำสำหรับบันทึกเหตุการณ์ เพื่อวิเคราะห์และปรับปรุงวงจรการพัฒนาซอฟต์แวร์ได้อย่างครบถ้วน.
3 จำเป็น 5 แนะนำ 12 ไม่บังคับ
ชื่อ คำอธิบาย
กิจกรรม
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' คือเวลา created_at ของ Issue ส่วน StartTime ของกิจกรรม 'ผสาน Merge Request' คือเวลา merged_at ของ merge request

เวลานี้เป็นข้อมูลหลักด้านเวลาสำหรับ 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 หรือ assignees ของ Issue หรือ Merge Request

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

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

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

แหล่งข้อมูล

ดึงจากฟิลด์ '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 มีค่า state เป็น 'opened' หรือ 'closed' ส่วนสถานะที่ละเอียดขึ้นมักจัดการด้วย label แบบมีขอบเขต เช่น 'Status::Triage', 'Status::In-Dev' และ 'Status::In-Review'

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

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

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

แหล่งข้อมูล

สถานะหลักมาจากฟิลด์ 'state' ของ GitLab Issue ('opened', 'closed') ส่วนสถานะที่ละเอียดขึ้นมักอนุมานจาก label.

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

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

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

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

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

แหล่งข้อมูล

เครื่องมือดึงข้อมูลหรือกระบวนการ ETL จะสร้างและบันทึกเวลานี้เมื่อมีการรีเฟรชข้อมูล.

ตัวอย่าง
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
จำเป็น แนะนำ ไม่บังคับ

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

ขั้นตอนและ Milestone สำคัญที่ควรบันทึกในบันทึกเหตุการณ์ เพื่อค้นพบกระบวนการและระบุคอขวดได้อย่างแม่นยำ.
4 แนะนำ 8 ไม่บังคับ
กิจกรรม คำอธิบาย
ติดตั้งใช้งานบน 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
แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก GitLab

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

ใช้เทมเพลตนี้เตรียมข้อมูลและเริ่มปรับปรุงวงจรการพัฒนาซอฟต์แวร์ของคุณ เริ่มปรับปรุงกระบวนการได้เลยวันนี้!

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

ลดคอขวดใน SDLC ลด cycle time 30% และยกระดับคุณภาพ.

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

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