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

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

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

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

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

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

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปได้มาจากการเปลี่ยนค่าของช่อง 'status' ในประวัติหรือบันทึกการเปลี่ยนแปลงของ Jira issue และอาจเพิ่มข้อมูลจากเครื่องมือพัฒนาที่เชื่อมต่อไว้ได้.

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

รายการพัฒนาเป็นรหัสอ้างอิงหลักของแต่ละกรณี โดยแทนหน่วยงานที่ต้องทำหนึ่งรายการ เช่น ฟีเจอร์ การแก้ bug หรือ task รหัสนี้เชื่อมโยงกิจกรรมทั้งหมดของรายการนั้น ตั้งแต่เริ่มคิดและวางแผน ไปจนถึงการพัฒนา การทดสอบ และการนำไปใช้งานจริง ใน Jira โดยทั่วไปจะตรงกับ issue key เช่น 'PROJ-123'.

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

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

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

แหล่งข้อมูล

นี่คือช่อง 'key' มาตรฐานของ issue ในออบเจ็กต์ Jira Software Issue API.

ตัวอย่าง
PROJ-101CORE-5432API-789
เวลาที่เกิดเหตุการณ์
EventTime
วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์ในการพัฒนาเกิดขึ้น.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ตรงกับเวลาที่บันทึกในช่อง 'created' ของแต่ละรายการในบันทึกการเปลี่ยนแปลงหรือประวัติของ issue.

ตัวอย่าง
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
ระบบต้นทาง
SourceSystem
ระบบที่ใช้ดึงข้อมูลวงจรการพัฒนาออกมา.
คำอธิบาย

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

ในสภาพแวดล้อม IT ที่มีหลายระบบ การระบุระบบต้นทางช่วยให้ตรวจสอบที่มาของข้อมูลได้ชัดเจน และช่วยจัดการคุณภาพข้อมูลกับการเชื่อมต่อข้อมูลระหว่างแพลตฟอร์มต่างๆ.

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

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

แหล่งข้อมูล

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

ตัวอย่าง
Jira Software
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่ระบุว่าข้อมูลของกระบวนการนี้ได้รับการรีเฟรชจากระบบต้นทางครั้งล่าสุดเมื่อใด.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ระบบสร้างและบันทึกเวลานี้เมื่อสิ้นสุดกระบวนการดึง แปลง และโหลดข้อมูล (ETL).

ตัวอย่าง
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
ชื่อทีม
TeamName
ทีมพัฒนาที่รับผิดชอบรายการงาน.
คำอธิบาย

ระบุทีม Agile หรือทีมฟีเจอร์ที่ได้รับมอบหมายให้ดูแลรายการพัฒนา ใน Jira มักกำหนดเป็นช่องแบบกำหนดเอง หรืออนุมานจากข้อมูลอื่น เช่น โปรเจกต์หรือคอมโพเนนต์.

แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ประสิทธิภาพระดับทีม คุณสามารถกรองแดชบอร์ดเพื่อดูตัวชี้วัด เช่น เวลารอบงาน อัตราการแก้ไขซ้ำ และปริมาณงานของแต่ละทีม ข้อมูลนี้สำคัญต่อแดชบอร์ด 'Inter-Phase Handoff Efficiency' และ 'Developer Workload & Item Progress'.

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

ช่วยวัดและเปรียบเทียบประสิทธิภาพของทีมพัฒนาต่างๆ เพื่อค้นหาทีมที่ทำผลงานได้ดีและแบ่งปันแนวทางปฏิบัติที่ดี.

แหล่งข้อมูล

โดยทั่วไปจะเป็นช่องแบบกำหนดเองใน Jira โปรดสอบถามผู้ดูแล Jira เพื่อระบุชื่อช่องที่ใช้ ซึ่งอาจเป็น 'Team', 'Squad' หรือชื่ออื่นที่คล้ายกัน.

ตัวอย่าง
ทีม Phoenixบริการหลักทีม UI/UX Avengers
ชื่อโปรเจกต์
ProjectName
ชื่อโปรเจกต์ Jira ที่รายการพัฒนาสังกัดอยู่.
คำอธิบาย

ใน Jira รายการงานทั้งหมดจัดอยู่ในโปรเจกต์ ชื่อโปรเจกต์ช่วยให้เห็นบริบทในภาพรวม ซึ่งมักสอดคล้องกับผลิตภัณฑ์ ทีม หรือโครงการริเริ่มหนึ่งรายการ.

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

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

ช่วยแบ่งการวิเคราะห์กระบวนการตามโปรเจกต์ ผลิตภัณฑ์ หรือทีม เพื่อเปรียบเทียบประสิทธิภาพและค้นหาแนวทางปฏิบัติที่ดี.

แหล่งข้อมูล

นี่คือช่อง 'project' ในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API.

ตัวอย่าง
พัฒนาแอปมือถือแพลตฟอร์มหลักวิทยาศาสตร์ข้อมูล
ประเภทรายการงาน
ItemType
การจัดประเภทของรายการพัฒนา เช่น ข้อบกพร่อง เรื่องราว งาน หรือมหากาพย์
คำอธิบาย

ประเภทรายการงานใช้จัดหมวดหมู่ลักษณะของงานที่ทำ Jira ใช้ช่องมาตรฐาน 'issuetype' เพื่อแยกประเภทของรายการงาน ซึ่งแต่ละประเภทมักมี workflow เฉพาะ.

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

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

ช่วยแบ่งการวิเคราะห์กระบวนการตามประเภทงาน เพื่อเปรียบเทียบวิธีจัดการงานต่างๆ เช่น bug กับฟีเจอร์ใหม่ และดูว่ากระบวนการแตกต่างกันตรงไหน.

แหล่งข้อมูล

นี่คือช่อง 'issuetype' ในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API.

ตัวอย่าง
StoryBugงานEpic
ผู้รับผิดชอบ
Assignee
ผู้ใช้ที่ได้รับมอบหมายให้ดูแลรายการพัฒนาในขณะนี้.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

นี่คือช่อง 'assignee' ในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API.

ตัวอย่าง
Alice SmithBob Johnsonยังไม่ได้มอบหมาย
ลำดับความสำคัญของรายการงาน
ItemPriority
ระดับความสำคัญที่กำหนดให้รายการพัฒนา เพื่อบอกความเร่งด่วน.
คำอธิบาย

ลำดับความสำคัญของรายการงานระบุความสำคัญหรือความเร่งด่วนเมื่อเทียบกับงานอื่น Jira มีช่องมาตรฐาน 'priority' ซึ่งกำหนดระดับได้ เช่น Highest, High, Medium และ Low.

การวิเคราะห์ลำดับความสำคัญช่วยตรวจสอบการปฏิบัติตามข้อกำหนดและค้นหาคอขวดของรายการสำคัญ ตัวอย่างเช่น แดชบอร์ด 'Priority Item Conformance Check' ใช้แอตทริบิวต์นี้ตรวจสอบว่ารายการที่มีความสำคัญสูงได้รับการเร่งดำเนินการตามที่คาดไว้หรือไม่ หรือยังค้างอยู่ในคิวเดียวกับรายการที่มีความสำคัญต่ำ.

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

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

แหล่งข้อมูล

นี่คือช่อง 'priority' ในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API.

ตัวอย่าง
สูงสุดสูงปานกลางต่ำ
สถานะรายการงาน
ItemStatus
สถานะปัจจุบันของรายการพัฒนาในเวิร์กโฟลว์.
คำอธิบาย

แอตทริบิวต์นี้แสดงสถานะของรายการพัฒนา ณ ช่วงเวลาหนึ่ง เช่น 'In Progress', 'In Review' หรือ 'Done' การเปลี่ยนสถานะตามลำดับเวลาจะกลายเป็นกิจกรรมสำหรับ process mining

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

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

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

แหล่งข้อมูล

นี่คือช่อง 'status' ในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API.

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

ใน Jira ใช้คอมโพเนนต์จัดกลุ่ม issue ภายในโปรเจกต์ให้เป็นส่วนย่อยที่จัดการได้ง่ายขึ้น เช่น พื้นที่ฟีเจอร์ 'User Authentication' ชั้นทางเทคนิคอย่าง 'Backend API' หรือโมดูลอย่าง 'Reporting'.

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

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

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

แหล่งข้อมูล

นี่คือช่อง 'components' มาตรฐานในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API.

ตัวอย่าง
ส่วนติดต่อผู้ใช้ฐานข้อมูลAPI Gatewayการยืนยันตัวตน
ชื่อสปรินต์
SprintName
ชื่อสปรินต์ Agile ที่รายการพัฒนาได้รับมอบหมายให้ทำ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปข้อมูลนี้จัดเก็บในช่องแบบกำหนดเอง 'Sprint' ซึ่งจัดการโดย Jira Software (Agile) และเรียกดูได้ผ่าน Issue API.

ตัวอย่าง
สปรินต์ 1 ของ PROJสปรินต์ 3 ของ Q4-2023สปรินต์ 2 ของ PI เดือนพฤศจิกายน
ซอฟต์แวร์รุ่นตามแผน
PlannedReleaseVersion
เวอร์ชันซอฟต์แวร์หรือซอฟต์แวร์รุ่นเป้าหมายที่วางแผนจะนำรายการงานไปใช้งาน.
คำอธิบาย

แอตทริบิวต์นี้มักตรงกับช่อง 'Affects Version/s' ใน Jira และระบุซอฟต์แวร์รุ่นที่วางแผนจะรวมฟีเจอร์หรือการแก้ไขไว้ โดยใช้เป็นกำหนดเวลาหรือเป้าหมายให้งานเสร็จ.

แอตทริบิวต์นี้สำคัญต่อ KPI 'On-Time Release Delivery Rate' เมื่อนำวันที่นำไปใช้งานจริงมาเปรียบเทียบกับวันที่ซอฟต์แวร์รุ่นตามแผน คุณจะวัดได้ว่าส่งมอบตามกำหนดหรือไม่ และประเมินความแม่นยำในการวางแผนออกซอฟต์แวร์รุ่นใหม่.

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

กำหนดวันที่หรือซอฟต์แวร์รุ่นเป้าหมายสำหรับส่งมอบ เพื่อคำนวณอัตราการส่งมอบตรงเวลาและวิเคราะห์การทำงานตามกำหนดการ.

แหล่งข้อมูล

ตรงกับช่อง 'versions' หรือ 'fixVersions' ใน Jira Issue API ช่องที่ใช้วางแผนอาจแตกต่างกันไป.

ตัวอย่าง
เวอร์ชัน 2.1ซอฟต์แวร์รุ่น Q1 2024เปิดตัว Project Phoenix
เป็นการแก้ไขงานซ้ำหรือไม่
IsRework
ตัวบ่งชี้ว่ากิจกรรมเป็นส่วนหนึ่งของการวนกลับไปแก้งานหรือไม่.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
truefalse
ผลลัพธ์ของรายการงาน
ItemResolution
ผลลัพธ์สุดท้ายหรือเหตุผลที่ปิดรายการพัฒนา.
คำอธิบาย

Resolution อธิบายว่าเหตุใดรายการงานจึงถูกเปลี่ยนเป็นสถานะปิด แม้สถานะจะเป็น 'Closed' แต่ resolution อาจเป็น 'Done', 'Won't Do', 'Duplicate' หรือ 'Cannot Reproduce' ซึ่งช่วยให้เข้าใจผลลัพธ์ของงานได้ชัดเจน.

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

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

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

แหล่งข้อมูล

นี่คือช่อง 'resolution' ในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API โดยทั่วไปจะมีค่าเมื่อปิด issue แล้วเท่านั้น.

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

ผู้รายงานคือบุคคลที่สร้าง issue ใน Jira อาจเป็นผู้พัฒนา ผู้ทดสอบ QA ผู้จัดการผลิตภัณฑ์ หรือแม้แต่ลูกค้าที่ส่งข้อมูลผ่านการเชื่อมต่อกับ service desk.

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

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

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

แหล่งข้อมูล

นี่คือช่อง 'reporter' ในออบเจ็กต์ 'fields' ของการตอบกลับจาก Jira Issue API.

ตัวอย่าง
Charles DarwinMarie CurieIsaac Newton
ระยะเวลารวมของวงจร
CycleTime
ระยะเวลารวมตั้งแต่ต้นจนจบของรายการพัฒนา.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
12096002592000604800
เวลารอระหว่างการส่งต่องาน
HandoffWaitTime
ช่วงเวลาที่ไม่มีการทำงานระหว่างกิจกรรมสองรายการที่เกิดขึ้นต่อเนื่องกัน.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

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

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

ขณะที่ 'EventTime' (StartTime) ระบุเวลาเริ่มกิจกรรม EventEndTime จะระบุเวลาสิ้นสุด ผลต่างระหว่างเวลาทั้งสองคือเวลาที่ใช้ดำเนินกิจกรรมนั้น ข้อมูลนี้จำเป็นต่อการคำนวณ KPI 'Average Stage Processing Time' และสร้างแดชบอร์ดเพื่อวิเคราะห์ระยะเวลาของกิจกรรม.

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

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

แหล่งข้อมูล

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

ตัวอย่าง
2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
เวอร์ชันที่แก้ไข
FixVersion
เวอร์ชันซอฟต์แวร์ที่ใช้แก้ไขและเผยแพร่รายการพัฒนาจริง.
คำอธิบาย

ช่อง 'Fix Version' ใน Jira ระบุซอฟต์แวร์รุ่นที่รวมงานที่เสร็จแล้วของรายการนั้นไว้ จึงแสดงผลลัพธ์ที่เกิดขึ้นจริงจากการพัฒนา.

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

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

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

แหล่งข้อมูล

ตรงกับช่อง 'fixVersions' ในการตอบกลับจาก Jira Issue API.

ตัวอย่าง
v2.1.1 แก้ไขเร่งด่วนv3.0.0 ซอฟต์แวร์รุ่นหลักv2.2.0
จำเป็น แนะนำ ไม่บังคับ

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

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยใช้เวลาที่ฟิลด์ 'status' เปลี่ยนจาก 'In QA' ไปเป็นสถานะถัดไป เช่น 'Ready for UAT' หรือ 'Ready for Release'.

บันทึก

เวลาที่สถานะเปลี่ยนจาก 'In QA' เป็น 'Ready for UAT'.

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

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

แหล่งข้อมูล

อนุมานได้จากประวัติการเปลี่ยนแปลงของ Jira issue เมื่อสถานะเปลี่ยนเป็น 'Released' หรือ 'Done' หากต้องการความแม่นยำมากขึ้น ให้บันทึกเหตุการณ์นำไปใช้งานจริงที่ส่งมาจากเครื่องมือ CI/CD เช่น Jenkins, Bamboo หรือฟีเจอร์ Deployments ใน Jira.

บันทึก

เวลาที่สถานะเปลี่ยนเป็น 'Done' หรือ 'Released'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยใช้เวลาที่ฟิลด์ 'status' เปลี่ยนเป็นสถานะทดสอบ QA ที่กำหนด เช่น 'In QA'.

บันทึก

เวลาที่สถานะเปลี่ยนเป็น 'In QA' หรือ 'In Testing'.

ประเภทเหตุการณ์ inferred
เริ่มพัฒนา
หมายถึงเวลาที่นักพัฒนาเริ่มทำงานกับงานพัฒนาอย่างจริงจัง โดยเกือบทุกครั้งอนุมานจากการเปลี่ยนสถานะในเวิร์กโฟลว์ของ Jira เช่น เมื่อสถานะ issue เปลี่ยนเป็น 'In Progress'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยใช้เวลาที่ฟิลด์ 'status' เปลี่ยนเป็น 'In Progress', 'In Development' หรือสถานะที่กำลังดำเนินการในลักษณะเดียวกันเป็นครั้งแรก.

บันทึก

เวลาที่สถานะเปลี่ยนเป็น 'In Progress'.

ประเภทเหตุการณ์ inferred
สร้างงานพัฒนา
เป็นจุดเริ่มต้นของวงจร เมื่อมีการบันทึกงานพัฒนาใหม่ เช่น story, bug หรือ task ใน Jira อย่างเป็นทางการ ระบบจะบันทึกเหตุการณ์นี้พร้อมเวลาที่สร้างของทุก issue.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

เหตุการณ์พื้นฐานที่เกิดกับ Jira issue ทุกชิ้น เวลาที่สร้างจะจัดเก็บไว้ในฟิลด์ 'created' ของระเบียน issue และเรียกดูได้ผ่าน Jira API.

บันทึก

ฟิลด์เวลาประทับ 'created' ในออบเจ็กต์ Jira Issue.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยใช้เวลาที่สถานะเปลี่ยนจาก 'In UAT' ไปยังสถานะถัดไปในเวิร์กโฟลว์ ซึ่งแสดงถึงการอนุมัติ.

บันทึก

เวลาที่สถานะเปลี่ยนจาก 'In UAT' เป็น 'Ready for Release'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยดูเวลาที่ฟิลด์ 'status' เปลี่ยนเป็นค่าอย่าง 'Ready for Dev', 'To Do' หรือ 'Selected for Development'.

บันทึก

เวลาที่สถานะเปลี่ยนเป็นสถานะพร้อมก่อนเริ่มพัฒนา.

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

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

แหล่งข้อมูล

โดยทั่วไปอนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue เมื่อสถานะออกจาก 'Code Review' นอกจากนี้ยังบันทึกเป็นเหตุการณ์โดยตรงได้ หากเชื่อมต่อเครื่องมือจัดเก็บโค้ด เช่น Bitbucket หรือ GitHub.

บันทึก

เวลาที่สถานะเปลี่ยนจาก 'In Review' ไปยังสถานะถัดไป.

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

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

แหล่งข้อมูล

โดยทั่วไปอนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue เมื่อสถานะเปลี่ยนเป็น 'Ready for Release' หรือจากเวลาที่กำหนดค่าในช่อง 'Fix Version/s'.

บันทึก

เวลาที่สถานะเปลี่ยนเป็น 'Ready for Release' หรือเวลาที่กรอกค่าในช่อง 'Fix Version'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยบันทึกเมื่อฟิลด์ 'status' เปลี่ยนจากสถานะทดสอบ เช่น 'In QA' ไปเป็นสถานะพัฒนาก่อนหน้า เช่น 'In Progress'.

บันทึก

เวลาที่สถานะเปลี่ยนจากสถานะทดสอบเป็นสถานะพัฒนา.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยใช้เวลาที่ช่อง 'status' เปลี่ยนเป็น 'Closed' และมีการกำหนด resolution.

บันทึก

เวลาที่สถานะเปลี่ยนเป็น 'Closed'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยบันทึกเวลาที่ฟิลด์ 'status' เปลี่ยนจากสถานะกำลังพัฒนาไปเป็นสถานะถัดไป เช่น 'In Review' หรือ 'Ready for QA'.

บันทึก

เวลาที่สถานะเปลี่ยนจาก 'In Progress' เป็น 'In Review' หรือ 'Ready for QA'.

ประเภทเหตุการณ์ inferred
ยกเลิกรายการพัฒนา
ระบุการยุติรายการพัฒนาก่อนทำเสร็จ อนุมานได้จากการเปลี่ยนสถานะเป็นสถานะสิ้นสุด เช่น 'Canceled', 'Rejected' หรือ 'Won't Do' และมักมีการกำหนด resolution ที่เกี่ยวข้องด้วย.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยใช้เวลาที่ช่อง 'status' เปลี่ยนเป็น 'Canceled' หรือ 'Won't Do' และมีการกำหนด resolution ที่เกี่ยวข้อง.

บันทึก

เวลาที่สถานะเปลี่ยนเป็น 'Canceled', 'Rejected' หรือ 'Won't Do'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการเปลี่ยนแปลงของ Jira issue โดยใช้เวลาที่ฟิลด์ 'status' เปลี่ยนเป็น 'In UAT' หรือสถานะที่กำหนดไว้ในลักษณะเดียวกัน.

บันทึก

เวลาที่สถานะเปลี่ยนเป็น 'In UAT'.

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

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

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

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

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

เริ่มปรับ SDLC ใน Jira Software ให้มีประสิทธิภาพยิ่งขึ้นวันนี้!

ค้นหาจุดที่ไม่มีประสิทธิภาพและลดระยะเวลาดำเนินการใน SDLC ได้ 30%.

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

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