เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์ของคุณ
เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์ของคุณ
- แอตทริบิวต์ที่แนะนำให้เก็บ
- กิจกรรมสำคัญที่ควรติดตามใน SDLC
- คำแนะนำโดยละเอียดสำหรับดึงข้อมูลจาก Azure DevOps
แอตทริบิวต์วงจรการพัฒนาซอฟต์แวร์
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
Development Item
DevelopmentItem
|
รหัสเฉพาะของงานหนึ่งรายการ เช่น ฟีเจอร์ Bug หรือ User Story ซึ่งใช้เป็นรหัสเคสของกระบวนการ. | ||
|
คำอธิบาย
Development Item คือหน่วยงานที่แยกจากกันและติดตามภายใน Azure DevOps โดยแต่ละรายการมี ID เฉพาะและเป็นศูนย์กลางของกิจกรรมทั้งหมดในกระบวนการ ตั้งแต่การสร้างและวางแผน ไปจนถึงการพัฒนา การทดสอบ และการนำขึ้นใช้งาน ในการวิเคราะห์ process mining คุณลักษณะนี้เป็นหัวใจสำคัญที่ใช้เชื่อมเหตุการณ์ที่เกี่ยวข้องทั้งหมดให้เป็นเคสเดียวกัน ช่วยสร้างภาพวงจรการทำงานตั้งแต่ต้นจนจบของ Work Item แต่ละรายการ และวิเคราะห์ระยะเวลาของวงจร ความเบี่ยงเบนของกระบวนการ และการทำงานซ้ำแยกเป็นรายรายการได้.
เหตุผลที่สำคัญ
นี่คือรหัสหลักที่เชื่อมทุกขั้นตอนของกระบวนการให้เป็นเคสเดียวกัน ทำให้วิเคราะห์วงจรการพัฒนาซอฟต์แวร์ตั้งแต่ต้นจนจบได้.
แหล่งข้อมูล
ตรงกับฟิลด์ 'ID' ของ Work Item ใน Azure DevOps Boards โดยเรียกดูได้ผ่าน Azure DevOps REST API สำหรับ Work Item Tracking.
ตัวอย่าง
10234102351023610237
|
|||
|
ชื่อกิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรืองานที่เกิดขึ้น ณ ช่วงเวลาหนึ่งในวงจรการพัฒนาของรายการงาน. | ||
|
คำอธิบาย
ชื่อกิจกรรมระบุขั้นตอนหรือหมุดหมายเฉพาะในกระบวนการ เช่น 'Development Started', 'Pull Request Created' หรือ 'Deployed to Production' โดยได้มาจากการเปลี่ยนสถานะของ Work Item เหตุการณ์ที่เชื่อมโยง เช่น build หรือ pull request หรือเหตุการณ์ที่กำหนดเอง คุณลักษณะนี้จำเป็นต่อการสร้างแผนผังกระบวนการ ซึ่งแสดงภาพเวิร์กโฟลว์ ช่วยให้นักวิเคราะห์เข้าใจลำดับเหตุการณ์ ระบุเส้นทางที่เกิดขึ้นบ่อย ค้นหาคอขวดระหว่างกิจกรรมเฉพาะ และวิเคราะห์ความถี่ของแต่ละขั้นตอนได้.
เหตุผลที่สำคัญ
คุณลักษณะนี้กำหนดขั้นตอนในกระบวนการ เป็นโครงหลักของแผนผังกระบวนการ และช่วยให้วิเคราะห์เวิร์กโฟลว์ คอขวด และความเบี่ยงเบนได้.
แหล่งข้อมูล
โดยทั่วไปได้มาจากการเปลี่ยนฟิลด์ 'State' ของ Work Item หรือจากเหตุการณ์ที่เชื่อมโยง เช่น build, commit และ pull request โดย Work Item History เป็นแหล่งข้อมูลดิบของเหตุการณ์เหล่านี้.
ตัวอย่าง
เริ่มพัฒนาดำเนินการ Pull Request เสร็จสิ้นทดสอบ QA ไม่ผ่านนำขึ้นใช้งานจริงแล้วปิด Work Item
|
|||
|
เวลาเกิดเหตุการณ์
EventTime
|
เวลาประทับที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์ของ Development Item เกิดขึ้นเมื่อใด. | ||
|
คำอธิบาย
เวลาเกิดเหตุการณ์บันทึกวันที่และเวลาของแต่ละกิจกรรมในวงจรการพัฒนา เวลาประทับนี้เป็นข้อมูลพื้นฐานสำหรับเรียงเหตุการณ์ตามลำดับเวลาและคำนวณระยะเวลาระหว่างเหตุการณ์ ในการวิเคราะห์ คุณลักษณะนี้สำคัญต่อการคำนวณตัวชี้วัดด้านเวลา เช่น ระยะเวลาของวงจร เวลาประมวลผล และเวลารอ อีกทั้งยังใช้สร้าง event log ที่เรียงตามเวลา ซึ่งเป็นข้อมูลที่จำเป็นสำหรับการวิเคราะห์ process mining นอกจากนี้ยังช่วยวินิจฉัยความล่าช้า วัดผลเทียบกับ SLA และติดตามแนวโน้มตามช่วงเวลา.
เหตุผลที่สำคัญ
เวลาประทับนี้ระบุลำดับเหตุการณ์ตามเวลา ซึ่งจำเป็นต่อการคำนวณ KPI ที่อิงระยะเวลา และทำความเข้าใจลำดับการทำงานกับคอขวด.
แหล่งข้อมูล
คือ 'Changed Date' ที่บันทึกไว้กับการอัปเดตแต่ละครั้งในประวัติ Work Item ส่วนเหตุการณ์ภายนอก เช่น build หรือการนำขึ้นใช้งาน จะใช้เวลาที่เหตุการณ์นั้นเสร็จสิ้น.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ใช้ดึงข้อมูลกระบวนการ ซึ่งในกรณีนี้คือ Azure DevOps. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุระบบต้นทางของข้อมูล มีประโยชน์เป็นพิเศษเมื่อรวมข้อมูลจากหลายระบบเพื่อให้เห็นภาพกระบวนการในมุมกว้าง สำหรับโมเดลนี้ ค่าจะเป็น Azure DevOps เสมอ แม้การวิเคราะห์จากระบบเดียวอาจทำให้คุณลักษณะนี้ดูเหมือนไม่เปลี่ยนแปลง แต่ก็ช่วยให้ทราบที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูล การแก้ไขปัญหา และการเชื่อมต่อกับระบบอื่นในอนาคต เช่น ServiceNow หรือ SAP.
เหตุผลที่สำคัญ
คุณลักษณะนี้ให้บริบทสำคัญเกี่ยวกับที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลข้อมูล การตรวจสอบความถูกต้อง และการวิเคราะห์กระบวนการจากหลายระบบ.
แหล่งข้อมูล
เป็นค่าคงที่ที่ควรเพิ่มระหว่างการดึงและแปลงข้อมูล เพื่อระบุชุดข้อมูล.
ตัวอย่าง
Azure DevOps
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาประทับที่ระบุว่ามีการรีเฟรชข้อมูลของกระบวนการจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
คุณลักษณะนี้บันทึกเวลาที่ดึงและอัปเดตชุดข้อมูลจาก Azure DevOps ครั้งล่าสุด ช่วยให้เห็นว่าข้อมูลเป็นปัจจุบันเพียงใดและการวิเคราะห์ครอบคลุมช่วงเวลาใด การทราบว่าข้อมูลเป็นข้อมูลล่าสุดแค่ไหนมีความสำคัญต่อการตัดสินใจอย่างมีข้อมูลประกอบ เวลาประทับนี้ช่วยให้ผู้ใช้ทราบว่ากำลังดูข้อมูลปัจจุบันหรือข้อมูลย้อนหลัง ซึ่งมีผลต่อความเกี่ยวข้องของข้อค้นพบ.
เหตุผลที่สำคัญ
ช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้เข้าใจช่วงเวลาที่ใช้ในการวิเคราะห์และตัดสินใจ.
แหล่งข้อมูล
เป็นเวลาประทับของข้อมูลเมตาที่สร้างและจัดเก็บระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL).
ตัวอย่าง
2024-05-20T08:00:00Z
|
|||
|
ชื่อทีม
TeamName
|
ชื่อทีมพัฒนาที่รับผิดชอบรายการงาน. | ||
|
คำอธิบาย
ชื่อทีมระบุทีมที่ได้รับมอบหมายให้ดูแลรายการงานนั้น ใน Azure DevOps มักจัดงานตามทีม ซึ่งอาจเป็นทีมย่อยภายในโปรเจกต์ขนาดใหญ่ แอตทริบิวต์นี้ช่วยแบ่งการวิเคราะห์กระบวนการตามทีม มีประโยชน์อย่างยิ่งในการเปรียบเทียบกระบวนการและผลการดำเนินงานระหว่างทีม ระบุแนวทางปฏิบัติที่ดีจากทีมที่ทำผลงานได้ดี และค้นหาจุดที่บางทีมอาจต้องการการสนับสนุนหรือปรับปรุงกระบวนการ.
เหตุผลที่สำคัญ
ช่วยเปรียบเทียบผลการดำเนินงานระหว่างทีม ระบุความแตกต่าง และแบ่งปันแนวทางปฏิบัติที่ดีทั่วทั้งองค์กร.
แหล่งข้อมูล
โดยทั่วไปข้อมูลนี้ได้มาจาก 'Area Path' ของรายการงาน เนื่องจากใน Azure DevOps มักกำหนดเส้นทางพื้นที่ให้แต่ละทีม.
ตัวอย่าง
ทีมฟีนิกซ์ทีมโอเมกาแพลตฟอร์มหลักทีมฟรอนต์เอนด์
|
|||
|
ประเภท Work Item
WorkItemType
|
การจัดประเภทของรายการพัฒนา เช่น Bug, Feature, User Story หรือ Task | ||
|
คำอธิบาย
ประเภท Work Item ใช้จัดหมวดหมู่ลักษณะของงานที่ทำ โดย Work Item แต่ละประเภทมักมีเส้นทางกระบวนการและความคาดหวังด้านประสิทธิภาพหรือ SLA ต่างกัน เช่น 'Bug' อาจใช้เส้นทางเร่งด่วนกว่า 'Feature' คุณลักษณะนี้จำเป็นต่อการวิเคราะห์เปรียบเทียบ โดยช่วยกรองแผนผังกระบวนการหรือ KPI ตามประเภทงาน เพื่อดูว่ากระบวนการใดมีประสิทธิภาพกว่าสำหรับ Bug หรือ Feature และติดตามแนวโน้มระยะเวลาของวงจรในแต่ละหมวดหมู่งานได้.
เหตุผลที่สำคัญ
ช่วยแบ่งการวิเคราะห์กระบวนการเป็นหมวดหมู่ เพื่อเปรียบเทียบเวิร์กโฟลว์และผลการทำงานของงานประเภทต่างๆ เช่น Bug และ Feature.
แหล่งข้อมูล
ตรงกับฟิลด์ 'Work Item Type' ของ Work Item ใน Azure DevOps.
ตัวอย่าง
Bugฟีเจอร์เรื่องราวผู้ใช้งาน
|
|||
|
มอบหมายให้
AssignedTo
|
ผู้ใช้หรือสมาชิกทีมที่ได้รับมอบหมายให้ดูแล Development Item ในขณะนั้น. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุผู้รับผิดชอบ Work Item ในแต่ละช่วงของกระบวนการ การมอบหมายอาจเปลี่ยนได้หลายครั้งตลอดวงจรของรายการ เช่น จากนักพัฒนาไปยังผู้ทดสอบ แล้วต่อไปยังผู้จัดการการเผยแพร่ การวิเคราะห์ตาม 'Assigned To' สำคัญต่อแดชบอร์ด Developer and Tester Workload Overview ช่วยให้เข้าใจการจัดสรรทรัพยากร ระบุสมาชิกทีมที่มีภาระงานมากเกินไป และวิเคราะห์ความแตกต่างของผลการทำงานระหว่างบุคคลหรือทีม.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ตามทรัพยากร ทำให้เข้าใจการกระจายภาระงาน ระบุคอขวดที่เกี่ยวข้องกับทรัพยากรเฉพาะ และบริหารขีดความสามารถของทีมได้.
แหล่งข้อมูล
ตรงกับฟิลด์ 'Assigned To' ของ Work Item ใน Azure DevOps โดยดึงค่าจากประวัติ Work Item ของแต่ละเหตุการณ์.
ตัวอย่าง
jane.doe@example.comjohn.smith@example.comไม่ได้มอบหมาย
|
|||
|
มีการแก้งานซ้ำหรือไม่
IsRework
|
ค่าสถานะบูลีนที่ระบุว่ารายการพัฒนากลับไปยังขั้นตอนก่อนหน้าในวงจรการทำงานหรือไม่. | ||
|
คำอธิบาย
กำหนดค่านี้เป็น true เมื่อรายการงานวนกลับไปทำขั้นตอนเดิม เช่น จาก 'ทดสอบ QA เสร็จแล้ว' กลับไปเป็น 'เริ่มพัฒนา' ระบบคำนวณค่านี้โดยวิเคราะห์ลำดับกิจกรรมของเคสและตรวจจับการดำเนินงานที่ไม่เป็นเส้นตรง แอตทริบิวต์นี้จำเป็นสำหรับแดชบอร์ดความถี่ในการแก้งานและทดสอบซ้ำ รวมถึง KPI ความถี่ของการวนกลับไปแก้งาน ช่วยกรองและวัดปริมาณงานแก้ซ้ำได้ง่ายขึ้น ทำให้ระบุปัญหาด้านคุณภาพ ช่องว่างในการสื่อสาร หรือการทดสอบที่ไม่เพียงพอ ซึ่งทำให้กระบวนการไม่มีประสิทธิภาพ.
เหตุผลที่สำคัญ
ระบุและวัดปริมาณงานซ้ำได้โดยตรง ช่วยให้เห็นปัญหาด้านคุณภาพและความไม่มีประสิทธิภาพของกระบวนการที่ทำให้ระยะเวลารอบยาวขึ้น.
แหล่งข้อมูล
แอตทริบิวต์นี้คำนวณจากการวิเคราะห์ลำดับกิจกรรมในบันทึกเหตุการณ์ของแต่ละเคส.
ตัวอย่าง
truefalse
|
|||
|
ลำดับความสำคัญ
Priority
|
การจัดอันดับความสำคัญของรายการพัฒนาเมื่อเทียบกับรายการอื่น โดยใช้ตัวเลขหรือคำอธิบาย. | ||
|
คำอธิบาย
ลำดับความสำคัญบอกว่ารายการงานใดควรจัดตารางและดำเนินการก่อน รายการที่มีลำดับความสำคัญสูงควรได้รับการจัดการเร็วกว่ารายการที่มีลำดับต่ำกว่า ค่าที่ใช้กันทั่วไปเป็นตัวเลข เช่น 1, 2, 3, 4 โดย 1 หมายถึงลำดับความสำคัญสูงสุด แอตทริบิวต์นี้จำเป็นสำหรับแดชบอร์ดปริมาณงานและระยะเวลารอบตามลำดับความสำคัญ การวิเคราะห์ข้อมูลนี้ช่วยให้ประเมินได้ว่าระบบจัดลำดับความสำคัญมีประสิทธิภาพหรือไม่ กล่าวคือ รายการที่มีความสำคัญสูงผ่านกระบวนการได้เร็วกว่ารายการที่มีความสำคัญต่ำจริงหรือไม่.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ได้ว่ากระบวนการเร่งจัดการรายการที่มีความสำคัญสูงได้ผลหรือไม่ ซึ่งเป็นข้อมูลสำคัญในการประเมินกลยุทธ์การจัดลำดับความสำคัญ.
แหล่งข้อมูล
ตรงกับฟิลด์ 'Priority' ของ Work Item ใน Azure DevOps.
ตัวอย่าง
1234
|
|||
|
เวลาสิ้นสุด
EndTime
|
เวลาประทับที่ระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด ใช้คำนวณเวลาประมวลผลของกิจกรรม. | ||
|
คำอธิบาย
เวลาสิ้นสุดระบุจุดที่กิจกรรมจบลง ใน event log หลายกรณี เวลาเริ่มต้นของกิจกรรมถัดไปจะใช้เป็นเวลาสิ้นสุดของกิจกรรมก่อนหน้า แต่การมีเวลาสิ้นสุดแยกต่างหากช่วยให้คำนวณเวลาประมวลผลของกิจกรรมและเวลาว่างระหว่างกิจกรรมได้แม่นยำขึ้น คุณลักษณะนี้จำเป็นต่อการคำนวณ KPI ProcessingTime และการวิเคราะห์คอขวดอย่างละเอียด ช่วยแยกเวลาที่ใช้ทำงานจริงออกจากเวลาที่รอขั้นตอนถัดไป ซึ่งเป็นข้อมูลสำคัญสำหรับแดชบอร์ด Stage Handoff Analysis.
เหตุผลที่สำคัญ
ช่วยคำนวณเวลาประมวลผลกิจกรรมและเวลาว่างได้อย่างแม่นยำ ซึ่งเป็นพื้นฐานของการวิเคราะห์คอขวดและปรับปรุงประสิทธิภาพ.
แหล่งข้อมูล
ค่านี้มักได้จากการคำนวณ โดยอาจใช้เวลาเริ่มต้นของเหตุการณ์ถัดไปในเคสเดียวกัน หรือใช้เวลาที่บันทึกไว้โดยตรง หากระบบต้นทางเก็บทั้งเวลาเริ่มต้นและเวลาสิ้นสุดของงาน.
ตัวอย่าง
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
สถานะ
State
|
สถานะปัจจุบันของรายการพัฒนาในเวิร์กโฟลว์ เช่น 'ใหม่' 'กำลังดำเนินการ' 'แก้ไขแล้ว' หรือ 'ปิดแล้ว'. | ||
|
คำอธิบาย
แอตทริบิวต์ State แสดงสถานะอย่างเป็นทางการของรายการงาน ณ เวลาใดเวลาหนึ่ง ตามที่กำหนดไว้ในเทมเพลตกระบวนการของโปรเจกต์ การเปลี่ยนจากสถานะหนึ่งไปอีกสถานะหนึ่งเป็นข้อมูลหลักที่ใช้สร้างกิจกรรมในบันทึกเหตุการณ์ แอตทริบิวต์ 'Activity' มักอธิบายการเปลี่ยนสถานะได้ชัดเจนกว่า แต่แอตทริบิวต์ 'State' ดิบก็มีประโยชน์สำหรับการกรองและวิเคราะห์ ช่วยให้เข้าใจว่ารายการงานใช้เวลาอยู่ในแต่ละสถานะนานเท่าใด และเป็นข้อมูลสำคัญสำหรับสร้างแดชบอร์ด Stage Duration และวิเคราะห์การส่งต่องาน
เหตุผลที่สำคัญ
แอตทริบิวต์นี้ระบุสถานะของรายการงานในวงจรการทำงาน ซึ่งเป็นข้อมูลสำคัญในการทำความเข้าใจลำดับงานและคำนวณเวลาที่ใช้ในแต่ละขั้นตอน.
แหล่งข้อมูล
ตรงกับฟิลด์ 'State' ของ Work Item ใน Azure DevOps.
ตัวอย่าง
ใหม่กำลังดำเนินการอยู่ระหว่าง QAแก้ไขแล้วปิดแล้ว
|
|||
|
ชื่อโปรเจกต์
ProjectName
|
ชื่อโปรเจกต์ Azure DevOps ที่มีรายการพัฒนาอยู่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุโปรเจกต์ในองค์กร Azure DevOps ที่มีรายการงานอยู่ ช่วยให้เห็นบริบทในภาพรวม โดยเฉพาะองค์กรที่มีหลายโปรเจกต์ ชื่อโปรเจกต์เป็นมิติสำคัญสำหรับการกรองและเปรียบเทียบ ใช้กับแดชบอร์ดแนวโน้มระยะเวลารอบย้อนหลัง โดยแบ่งการวิเคราะห์ตามโปรเจกต์ เพื่อดูว่าโปรเจกต์ใดมีประสิทธิภาพมากหรือน้อยกว่าโปรเจกต์อื่น และการปรับปรุงกระบวนการในโปรเจกต์หนึ่งส่งผลดีหรือไม่.
เหตุผลที่สำคัญ
ช่วยจัดกลุ่มข้อมูลในภาพรวม เพื่อเปรียบเทียบผลการดำเนินงานและวิเคราะห์แนวโน้มระหว่างโปรเจกต์ต่างๆ.
แหล่งข้อมูล
ตรงกับฟิลด์ 'Team Project' ของ Work Item ใน Azure DevOps.
ตัวอย่าง
แพลตฟอร์มอีคอมเมิร์ซเปิดตัวแอปมือถืออีกครั้งปรับปรุงคลังข้อมูลให้ทันสมัย
|
|||
|
รหัส Pull Request
PullRequestId
|
รหัสของ Pull Request ที่เชื่อมโยงกับรายการพัฒนา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เชื่อมโยงรายการงานกับ Pull Request ซึ่งใช้ส่งและตรวจสอบการเปลี่ยนแปลงโค้ด รายการงานหนึ่งรายการอาจเชื่อมโยงกับ Pull Request ได้หลายรายการ รหัส Pull Request ช่วยให้วิเคราะห์ขั้นตอนตรวจสอบและผสานโค้ดได้ละเอียดขึ้น ใช้วัดเวลาตั้งแต่สร้าง Pull Request จนเสร็จ และวิเคราะห์ว่ามีการปฏิเสธ Pull Request หรือต้องแก้ไขครั้งใหญ่มากน้อยเพียงใด ซึ่งอาจบ่งชี้ถึงคุณภาพโค้ดหรือความชัดเจนของข้อกำหนด.
เหตุผลที่สำคัญ
เชื่อมโยงงานพัฒนากับกิจกรรมตรวจสอบโค้ดที่เกี่ยวข้อง ทำให้วิเคราะห์ขั้นตอนผสานโค้ดและประกันคุณภาพได้ละเอียดขึ้น.
แหล่งข้อมูล
ดูข้อมูลนี้ได้ในส่วน 'Links' หรือ 'Development' ของรายการงานใน Azure DevOps.
ตัวอย่าง
452145334589
|
|||
|
ระดับความรุนแรง
Severity
|
แสดงผลกระทบของบั๊กหรือปัญหาที่มีต่อระบบหรือผู้ใช้ปลายทาง. | ||
|
คำอธิบาย
ระดับความรุนแรงใช้จัดประเภทผลกระทบของบั๊ก ตั้งแต่ระบบขัดข้องร้ายแรงไปจนถึงปัญหาด้านรูปลักษณ์เล็กน้อย ซึ่งต่างจากลำดับความสำคัญที่ใช้กำหนดลำดับการทำงาน บั๊กที่มีความรุนแรงสูงอาจมีลำดับความสำคัญต่ำได้ หากมีวิธีแก้ไขชั่วคราวที่พร้อมใช้งาน แอตทริบิวต์นี้เพิ่มมิติในการวิเคราะห์ โดยเฉพาะในแดชบอร์ดปริมาณงานและระยะเวลารอบตามลำดับความสำคัญ ช่วยตอบคำถาม เช่น 'เราแก้บั๊กที่สำคัญที่สุดก่อนหรือไม่' และทำให้เข้าใจระดับความเสี่ยงของงานที่กำลังดำเนินการ.
เหตุผลที่สำคัญ
ช่วยจัดหมวดหมู่รายการงานตามผลกระทบต่อธุรกิจ ทำให้วิเคราะห์ได้ว่าทีมจัดการปัญหาที่มีผลกระทบสูงได้ดีเพียงใด.
แหล่งข้อมูล
ตรงกับฟิลด์ 'Severity' ของ Work Item ซึ่งโดยทั่วไปใช้กับบั๊กใน Azure DevOps.
ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
|
|||
|
เวลารออนุมัติ
ApprovalWaitingTime
|
เวลาที่รายการพัฒนารอการอนุมัติหลังจากส่งคำขอแล้ว. | ||
|
คำอธิบาย
ตัวชี้วัดนี้วัดระยะเวลาที่รายการงานรอการอนุมัติ เช่น เวลาระหว่าง 'เริ่ม UAT' กับ 'อนุมัติ UAT' คำนวณโดยวัดช่วงเวลาระหว่างกิจกรรมทั้งสองของเคสที่กำหนด แอตทริบิวต์ที่คำนวณนี้รองรับแดชบอร์ดวิเคราะห์เวลารออนุมัติและ KPI ที่เกี่ยวข้อง เมื่อแยกความล่าช้าเหล่านี้ออกมา ทีมจะปรับปรุงการสื่อสารและกระบวนการตัดสินใจเพื่อลดเวลาที่งานหยุดรอและเร่งวงจรการทำงานโดยรวมได้.
เหตุผลที่สำคัญ
วัดความล่าช้าที่เกิดจากการรอการตัดสินใจหรืออนุมัติโดยเฉพาะ ช่วยชี้โอกาสในการปรับปรุงการสื่อสารและกระบวนการตัดสินใจ.
แหล่งข้อมูล
คำนวณโดยค้นหากิจกรรมเริ่มต้นและสิ้นสุดของการอนุมัติในบันทึกเหตุการณ์ เช่น 'เริ่ม UAT' และ 'อนุมัติ UAT' แล้วหาช่วงเวลาระหว่างกิจกรรมทั้งสอง.
ตัวอย่าง
3 วัน 2 ชั่วโมง1 วัน 8 ชั่วโมง 30 นาที4 ชั่วโมง
|
|||
|
เวลาส่งต่องานระหว่างขั้นตอน
StageHandoffTime
|
ระยะเวลาที่งานหยุดรอระหว่างขั้นตอนหลักหนึ่งเสร็จสิ้นกับการเริ่มขั้นตอนถัดไป. | ||
|
คำอธิบาย
เวลาส่งต่องานระหว่างขั้นตอนใช้วัดช่วงเวลารอระหว่างขั้นตอนที่ต่อเนื่องกัน เช่น เวลาระหว่าง 'พัฒนาเสร็จ' กับ 'เริ่มทดสอบ QA' คำนวณโดยระบุการเปลี่ยนผ่านที่สำคัญเหล่านี้ แล้ววัดช่วงเวลาระหว่างสิ้นสุดกิจกรรมแรกกับเริ่มกิจกรรมที่สอง ตัวชี้วัดนี้เป็นหัวใจของแดชบอร์ดระยะเวลาในแต่ละขั้นตอนและการวิเคราะห์การส่งต่องาน การแยกและวัดเวลาส่งต่องานช่วยระบุคอขวดที่ซ่อนอยู่ ซึ่งงานหยุดรอโดยไม่ได้ดำเนินการ มักเกิดจากทรัพยากรไม่พร้อม การสื่อสารล่าช้า หรือกระบวนการที่ไม่มีประสิทธิภาพ.
เหตุผลที่สำคัญ
วัดเวลารอระหว่างขั้นตอนของกระบวนการ ทำให้เห็นคอขวดและความล่าช้าที่ซ่อนอยู่ ซึ่งไม่ได้เกิดจากการลงมือทำงานโดยตรง.
แหล่งข้อมูล
แอตทริบิวต์นี้คำนวณจากการระบุคู่กิจกรรมที่ต่อเนื่องกันและแสดงถึงการส่งต่องาน จากนั้นคำนวณช่วงเวลาระหว่างกิจกรรมทั้งสอง.
ตัวอย่าง
2 ชั่วโมง 15 นาที1 วัน 4 ชั่วโมง30 นาที
|
|||
|
เส้นทางรอบการทำงาน
IterationPath
|
สปรินต์หรือช่วงเวลาที่กำหนดไว้สำหรับการพัฒนา ซึ่งเป็นช่วงที่มอบหมายรายการงานให้ดำเนินการ. | ||
|
คำอธิบาย
เส้นทางรอบการทำงาน หรือสปรินต์ คือช่วงเวลาการพัฒนาที่กำหนดไว้อย่างชัดเจน โดยมอบหมายรายการงานให้เสร็จภายในช่วงนั้น การวิเคราะห์ตามเส้นทางรอบการทำงานช่วยให้เข้าใจผลการดำเนินงานของแต่ละสปรินต์ ใช้ติดตามว่าระยะเวลารอบดีขึ้นในสปรินต์ต่อๆ ไปหรือไม่ วิเคราะห์งานที่ยกยอดไปทำต่อ และประเมินความแม่นยำในการวางแผนสปรินต์.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ผลการดำเนินงานแยกตามสปรินต์ ทำให้ทีมประเมินผลงานตามช่วงเวลาและปรับปรุงแนวทางการทำงานแบบ Agile ได้.
แหล่งข้อมูล
ตรงกับฟิลด์ 'Iteration Path' ของ Work Item ใน Azure DevOps.
ตัวอย่าง
แพลตฟอร์มอีคอมเมิร์ซ\สปรินต์ 12แพลตฟอร์มอีคอมเมิร์ซ\สปรินต์ 13เปิดตัวแอปมือถืออีกครั้ง\ระยะที่ 2\สปรินต์ 4
|
|||
กิจกรรมในวงจรการพัฒนาซอฟต์แวร์
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
ดำเนินการ Pull Request เสร็จสิ้น
|
หมายถึงการตรวจสอบโค้ดเสร็จสมบูรณ์ โดยอนุมัติ pull request และรวมโค้ดเข้ากับ branch เป้าหมาย Azure Repos บันทึกเหตุการณ์นี้ไว้อย่างชัดเจน. | ||
|
เหตุผลที่สำคัญ
เป็นจุดสิ้นสุดของขั้นตอนตรวจสอบโค้ด ซึ่งมักเป็นคอขวด การวิเคราะห์ระยะเวลาตั้งแต่สร้าง PR จนเสร็จสิ้นช่วยให้เห็นประสิทธิภาพของรอบการตรวจสอบ.
แหล่งข้อมูล
ดึงข้อมูลจากเหตุการณ์ดำเนินการ pull request เสร็จสิ้นหรือรวมโค้ดใน Azure Repos ซึ่งเชื่อมโยงกับ Work Item.
บันทึก
ดึงข้อมูลจากเหตุการณ์รวม pull request ที่เชื่อมโยงกับ Work Item.
ประเภทเหตุการณ์
explicit
|
|||
|
นำขึ้นใช้งานจริงแล้ว
|
แสดงว่ามีการนำโค้ดที่เชื่อมโยงกับ Work Item ขึ้นใช้งานในสภาพแวดล้อมจริงเรียบร้อยแล้ว โดยดึงเหตุการณ์นี้จากบันทึกการเผยแพร่ของ Azure Pipelines. | ||
|
เหตุผลที่สำคัญ
เป็นหมุดหมายสำคัญที่แสดงถึงการส่งมอบคุณค่า และใช้เป็นจุดสิ้นสุดในการคำนวณระยะเวลาตั้งแต่เริ่มจนส่งมอบและระยะเวลารอบการทำงาน.
แหล่งข้อมูล
ดึงข้อมูลจาก pipeline การเผยแพร่ของ Azure Pipelines โดยเฉพาะเหตุการณ์ที่การนำขึ้นใช้งานในขั้น 'Production' เสร็จสิ้นและเชื่อมโยงกับ Work Item.
บันทึก
ดึงข้อมูลจากเหตุการณ์นำขึ้นใช้งานเสร็จสิ้นใน release pipeline.
ประเภทเหตุการณ์
explicit
|
|||
|
เริ่มทดสอบ QA
|
หมายถึงการเริ่มขั้นตอนทดสอบประกันคุณภาพอย่างเป็นทางการ โดยอนุมานเมื่อสถานะ Work Item เปลี่ยนเป็น 'In QA', 'Testing' หรือสถานะที่มีความหมายใกล้เคียงกัน. | ||
|
เหตุผลที่สำคัญ
เป็นจุดเริ่มต้นของรอบ QA การวิเคราะห์ระยะเวลาของขั้นตอนนี้สำคัญต่อการทำความเข้าใจคอขวดและประสิทธิภาพในการทดสอบ.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item โดยติดตามการเปลี่ยนฟิลด์ System.State เป็น 'In QA' หรือสถานะทดสอบอื่นที่กำหนดไว้.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State เป็น 'In QA' หรือ 'Testing'.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มพัฒนา
|
กิจกรรมนี้แสดงว่านักพัฒนาเริ่มทำงานกับรายการนั้นแล้ว โดยอนุมานจากการเปลี่ยนสถานะของ Work Item เป็น 'Active', 'In Progress' หรือ 'Committed'. | ||
|
เหตุผลที่สำคัญ
เป็นจุดเริ่มต้นของช่วงพัฒนาที่ลงมือทำจริง การวิเคราะห์ระยะเวลาตั้งแต่ 'Created' ถึง 'Development Started' ช่วยให้เห็นเวลาที่งานรออยู่ใน backlog.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item เมื่อฟิลด์ System.State เปลี่ยนจาก 'New' หรือ 'Approved' เป็น 'In Progress'.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State เป็น 'Active' หรือ 'In Progress'.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้าง Pull Request
|
แสดงว่านักพัฒนาเขียนโค้ดเบื้องต้นเสร็จและส่งการเปลี่ยนแปลงให้ตรวจสอบผ่าน pull request เหตุการณ์นี้เชื่อมโยง Work Item กับการเปลี่ยนแปลงโค้ดที่เกี่ยวข้องใน Azure Repos. | ||
|
เหตุผลที่สำคัญ
เป็นจุดส่งต่องานสำคัญจากการพัฒนาไปสู่การตรวจสอบโค้ด การติดตามเหตุการณ์นี้ช่วยวัดระยะเวลาเขียนโค้ดและระบุได้ว่าโค้ดพร้อมให้เพื่อนร่วมทีมตรวจสอบเมื่อใด.
แหล่งข้อมูล
ดึงข้อมูลจาก Azure Repos โดยเชื่อมเหตุการณ์สร้าง pull request กับ Work Item ที่เกี่ยวข้อง ซึ่งนักพัฒนามักเป็นผู้เชื่อมโยงไว้อย่างชัดเจน.
บันทึก
ดึงข้อมูลจากเหตุการณ์สร้าง pull request ใน Azure Repos ที่เชื่อมโยงกับ Work Item.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้าง Work Item
|
กิจกรรมนี้เป็นจุดเริ่มต้นของวงจรการพัฒนา โดยแสดงการสร้างรายการงานใหม่ เช่น User Story, Bug หรือ Task ระบบจะบันทึกเหตุการณ์นี้โดยตรงเมื่อมีการบันทึกระเบียนใหม่ใน Azure DevOps Boards | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ ซึ่งจำเป็นต่อการวัดระยะเวลาการพัฒนาตั้งแต่ต้นจนจบ และทำความเข้าใจแหล่งที่มาของงานในช่วงแรก.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้จากฟิลด์ 'Created Date' ของ Work Item ตารางประวัติ Work Item ยังบันทึกการเปลี่ยนสถานะครั้งแรกนี้ด้วย.
บันทึก
ดึงข้อมูลจากฟิลด์ 'Created Date' ของ Work Item.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติ UAT
|
กิจกรรมนี้แสดงว่าผู้มีส่วนได้ส่วนเสียทางธุรกิจอนุมัติการเปลี่ยนแปลงหลังการทดสอบการยอมรับโดยผู้ใช้ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะจาก 'In UAT' เป็น 'UAT Approved' หรือ 'Ready for Release'. | ||
|
เหตุผลที่สำคัญ
เป็นจุดอนุมัติสำคัญที่ยืนยันว่า Work Item ตรงตามข้อกำหนดทางธุรกิจและพร้อมนำขึ้นใช้งานจริง.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item โดยตรวจพบการเปลี่ยนฟิลด์ System.State จากสถานะ UAT เป็นสถานะที่อนุมัติแล้วหรือพร้อมเผยแพร่.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State จาก 'In UAT' เป็น 'Ready for Release'.
ประเภทเหตุการณ์
inferred
|
|||
|
Build สำเร็จ
|
กิจกรรมนี้ยืนยันว่า build pipeline คอมไพล์และจัดแพ็กเกจซอร์สโค้ด รวมถึงการเปลี่ยนแปลงใหม่เรียบร้อยแล้ว Azure Pipelines บันทึกเหตุการณ์นี้ไว้อย่างชัดเจน. | ||
|
เหตุผลที่สำคัญ
ทำหน้าที่เป็น quality gate สำคัญ เพื่อให้มั่นใจว่าโค้ดใหม่ทำงานร่วมกับโค้ดเดิมได้โดยไม่ทำให้ build ล้มเหลว หากไม่ผ่านในขั้นตอนนี้ อาจบ่งชี้ถึงปัญหาการผสานรวม.
แหล่งข้อมูล
ดึงข้อมูลจากเหตุการณ์ build เสร็จสิ้นใน Azure Pipelines โดยต้องเชื่อม build กับ Work Item ไม่ว่าจะเชื่อมโดยตรงหรือผ่าน pull request ที่เกี่ยวข้อง.
บันทึก
ดึงข้อมูลจากเหตุการณ์ build เสร็จสิ้นใน Azure Pipelines.
ประเภทเหตุการณ์
explicit
|
|||
|
ทดสอบ QA ไม่ผ่าน
|
แสดงว่า Work Item ไม่ผ่านการทดสอบประกันคุณภาพและถูกส่งกลับไปยังทีมพัฒนา โดยบันทึกจากการเปลี่ยนสถานะจากสถานะทดสอบกลับเป็น 'In Progress' หรือ 'Active'. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้จำเป็นต่อการระบุวงจรการทำงานซ้ำ หากเกิดเหตุการณ์นี้บ่อย อาจชี้ถึงปัญหาด้านคุณภาพโค้ด ข้อกำหนด หรือกระบวนการทดสอบ.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item โดยตรวจพบการเปลี่ยนจากสถานะอย่าง 'In QA' กลับไปเป็นสถานะอย่าง 'Active' หรือ 'In Progress'.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State จาก 'In QA' กลับเป็น 'Active'.
ประเภทเหตุการณ์
inferred
|
|||
|
ทดสอบ QA เสร็จสิ้น
|
แสดงว่าขั้นตอนประกันคุณภาพเสร็จสมบูรณ์และผ่านการทดสอบ โดยอนุมานเมื่อสถานะ Work Item เปลี่ยนจากสถานะทดสอบเป็น 'Ready for UAT' หรือ 'QA Approved'. | ||
|
เหตุผลที่สำคัญ
นี่คือ quality gate สำคัญที่แสดงว่า Work Item พร้อมสำหรับการทดสอบการยอมรับโดยผู้ใช้หรือการเผยแพร่ หากเกิดความล่าช้าหลังจากจุดนี้ อาจมีคอขวดในขั้นตอน UAT หรือการวางแผนเผยแพร่.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item เมื่อฟิลด์ System.State เปลี่ยนจาก 'In QA' เป็นสถานะถัดไป เช่น 'Ready for UAT' หรือ 'Done'.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State จาก 'In QA' เป็น 'Ready for UAT'.
ประเภทเหตุการณ์
inferred
|
|||
|
ปิด Work Item
|
หมายถึงการปิด Work Item หลังนำขึ้นใช้งานและตรวจสอบหลังการนำขึ้นใช้งานแล้ว โดยบันทึกจากการเปลี่ยนสถานะเป็น 'Closed' หรือ 'Done'. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้แสดงว่ากระบวนการทั้งหมดของ Work Item เสร็จสมบูรณ์และสำเร็จ เป็นจุดสิ้นสุดที่ชัดเจนของวงจรการทำงาน.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item เมื่อฟิลด์ System.State เปลี่ยนเป็น 'Closed' หรือสถานะสิ้นสุดที่คล้ายกันในหมวด 'Completed'.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State เป็น 'Closed'.
ประเภทเหตุการณ์
inferred
|
|||
|
พัฒนาเสร็จสิ้น
|
หมายถึงการพัฒนาและการทดสอบหน่วยเสร็จสิ้น พร้อมส่ง Work Item เข้าสู่การทดสอบอย่างเป็นทางการ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะ Work Item เป็น 'Resolved' หรือ 'Ready for Test'. | ||
|
เหตุผลที่สำคัญ
เป็นจุดส่งต่องานสำคัญจากทีมพัฒนาไปยังทีม QA การวัดระยะเวลาจนถึง 'QA Testing Started' ช่วยระบุความล่าช้าในการส่งต่องาน.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item เมื่อฟิลด์ System.State เปลี่ยนเป็น 'Resolved' หรือสถานะที่กำหนดเองซึ่งแสดงว่าพร้อมให้ QA ตรวจสอบ.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State เป็น 'Resolved'.
ประเภทเหตุการณ์
inferred
|
|||
|
ยกเลิก Work Item
|
แสดงว่า Work Item ถูกยกเลิกและจะไม่มีการดำเนินการให้เสร็จหรือการนำขึ้นใช้งาน โดยบันทึกจากการเปลี่ยนสถานะเป็น 'Removed', 'Cancelled' หรือสถานะที่มีความหมายใกล้เคียงกัน. | ||
|
เหตุผลที่สำคัญ
เป็นจุดสิ้นสุดอีกแบบหนึ่งของกระบวนการที่ไม่สำเร็จ การวิเคราะห์รายการที่ถูกยกเลิกอาจช่วยให้เห็นปัญหาในการวางแผน การจัดลำดับความสำคัญ หรือการกำหนดข้อกำหนด.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item เมื่อฟิลด์ System.State เปลี่ยนเป็นสถานะสิ้นสุดในหมวด 'Removed'.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State เป็น 'Removed' หรือ 'Cancelled'.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่ม UAT
|
หมายถึงการเริ่มทดสอบการยอมรับโดยผู้ใช้ (UAT) ซึ่งผู้มีส่วนได้ส่วนเสียทางธุรกิจจะตรวจสอบการทำงาน โดยทั่วไปอนุมานจากการเปลี่ยนสถานะเป็น 'In UAT' หรือสถานะที่มีความหมายใกล้เคียงกัน. | ||
|
เหตุผลที่สำคัญ
ใช้วัดการเริ่มต้นการตรวจสอบขั้นสุดท้ายก่อนเผยแพร่ การวิเคราะห์ระยะเวลา UAT และเวลารออนุมัติเป็นสิ่งสำคัญต่อการปรับปรุงกระบวนการ.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item เมื่ออัปเดตฟิลด์ System.State เป็นสถานะที่กำหนดเองเพื่อระบุ UAT เช่น 'In UAT'.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State เป็น 'In UAT'.
ประเภทเหตุการณ์
inferred
|
|||
|
อนุมัติ Work Item
|
หมายถึงการอนุมัติ Work Item อย่างเป็นทางการ เพื่อยืนยันว่ากำหนดรายละเอียดชัดเจนและพร้อมพัฒนา โดยทั่วไปอนุมานจากการเปลี่ยนค่าฟิลด์ 'State' เป็น 'Approved' หรือ 'Ready for Dev'. | ||
|
เหตุผลที่สำคัญ
การติดตามการอนุมัติช่วยวิเคราะห์ระยะเวลาตั้งแต่ส่งแนวคิดจนถึงการตกลงเริ่มพัฒนา และช่วยให้เห็นความล่าช้าที่อาจเกิดขึ้นในขั้นตอนวางแผนและจัดระเบียบ backlog.
แหล่งข้อมูล
อนุมานจากประวัติ Work Item โดยตรวจพบการเปลี่ยนฟิลด์ System.State เป็น 'Approved' หรือสถานะที่กำหนดเองซึ่งมีความหมายใกล้เคียงกัน.
บันทึก
อนุมานจากการเปลี่ยนฟิลด์ State เป็น 'Approved'.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงวงจรการพัฒนาซอฟต์แวร์ของคุณได้วันนี้ เทมเพลตนี้เป็นก้าวแรกที่จะช่วยให้คุณค้นพบข้อมูลเชิงลึกเกี่ยวกับกระบวนการที่มีประโยชน์.
เริ่มปรับปรุง SDLC บน Azure DevOps ได้วันนี้!
ลดระยะเวลารอบลง 30% และกำจัดคอขวดในเวิร์กโฟลว์ SDLC ของคุณ.
ไม่ต้องใช้บัตรเครดิต เริ่มต้นใช้งานได้ในไม่กี่นาที.