Mẫu dữ liệu vòng đời phát triển phần mềm
Mẫu dữ liệu vòng đời phát triển phần mềm
- Các thuộc tính nên thu thập
- Các hoạt động chính cần theo dõi trong SDLC
- Hướng dẫn chi tiết cách trích xuất dữ liệu từ Azure DevOps
Các thuộc tính của vòng đời phát triển phần mềm
| Tên | Mô tả | ||
|---|---|---|---|
|
Development Item
DevelopmentItem
|
Mã định danh duy nhất cho một đơn vị công việc, chẳng hạn như tính năng, lỗi hoặc User Story. Mã này được dùng làm mã định danh case của quy trình. | ||
|
Mô tả
Development Item là một phần công việc riêng biệt được theo dõi trong Azure DevOps. Mỗi hạng mục có một ID duy nhất và là đối tượng trung tâm gắn với mọi hoạt động của quy trình, từ tạo và lập kế hoạch đến phát triển, kiểm thử và triển khai. Trong phân tích process mining, thuộc tính này giúp liên kết mọi sự kiện liên quan thành hành trình của một case. Nhờ đó, bạn có thể dựng lại vòng đời từ đầu đến cuối của từng work item, rồi phân tích thời gian chu kỳ, sai lệch quy trình và các vòng lặp làm lại cho từng hạng mục.
Vì sao điều này quan trọng
Đây là mã định danh cốt lõi, kết nối mọi bước của quy trình thành một case thống nhất và cho phép phân tích toàn bộ vòng đời phát triển phần mềm.
Lấy dữ liệu ở đâu
Đây là trường 'ID' của Work Item trong Azure DevOps Boards. Bạn có thể truy cập trường này qua Azure DevOps REST API dành cho Work Item Tracking.
Ví dụ
10234102351023610237
|
|||
|
Tên hoạt động
ActivityName
|
Tên của sự kiện hoặc nhiệm vụ cụ thể xảy ra tại một thời điểm trong vòng đời phát triển của một mục công việc. | ||
|
Mô tả
Tên hoạt động mô tả một bước hoặc cột mốc cụ thể trong quy trình, chẳng hạn như 'Development Started', 'Pull Request Created' hoặc 'Deployed to Production'. Các hoạt động này được xác định từ thay đổi trạng thái của work item, sự kiện liên kết như build hoặc pull request, hay sự kiện tùy chỉnh. Thuộc tính này cần thiết để tạo sơ đồ quy trình, thể hiện trực quan quy trình làm việc. Nhờ đó, chuyên viên phân tích có thể hiểu trình tự sự kiện, xác định các luồng phổ biến, tìm điểm nghẽn giữa những hoạt động cụ thể và phân tích tần suất của từng bước.
Vì sao điều này quan trọng
Thuộc tính này xác định các bước trong quy trình, tạo nền tảng cho sơ đồ quy trình và giúp phân tích quy trình làm việc, điểm nghẽn cũng như sai lệch.
Lấy dữ liệu ở đâu
Thông tin này thường được xác định từ các thay đổi trong trường 'State' của work item hoặc từ sự kiện liên kết như build, commit và pull request. Work Item History cung cấp dữ liệu thô cho các sự kiện này.
Ví dụ
Bắt đầu phát triểnHoàn tất pull requestKiểm thử QA không đạtTriển khai lên productionĐóng work item
|
|||
|
Thời điểm sự kiện
EventTime
|
Dấu thời gian chính xác cho biết một hoạt động hoặc sự kiện cụ thể của Development Item đã xảy ra khi nào. | ||
|
Mô tả
Thời điểm sự kiện ghi lại ngày giờ của từng hoạt động trong vòng đời phát triển. Đây là dữ liệu thời gian cơ bản để sắp xếp sự kiện theo trình tự và tính khoảng thời gian giữa chúng. Trong phân tích, thuộc tính này rất quan trọng để tính mọi chỉ số dựa trên thời gian, bao gồm thời gian chu kỳ, thời gian xử lý và thời gian chờ. Thuộc tính này giúp tạo nhật ký sự kiện theo thứ tự thời gian, đầu vào cần thiết cho mọi phân tích process mining. Bạn có thể dùng dữ liệu này để tìm nguyên nhân chậm trễ, đo hiệu suất so với SLA và theo dõi xu hướng theo thời gian.
Vì sao điều này quan trọng
Dấu thời gian này xác định thứ tự sự kiện, yếu tố cần thiết để tính mọi KPI về thời lượng và hiểu luồng quy trình cũng như điểm nghẽn.
Lấy dữ liệu ở đâu
Đây là 'Changed Date' gắn với mỗi lần cập nhật trong lịch sử work item. Với các sự kiện bên ngoài như build hoặc triển khai, đây là dấu thời gian hoàn tất sự kiện.
Ví dụ
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
Hệ thống nguồn
SourceSystem
|
Hệ thống nơi trích xuất dữ liệu quy trình. Trong trường hợp này, đó là Azure DevOps. | ||
|
Mô tả
Thuộc tính này xác định hệ thống nguồn của dữ liệu. Thuộc tính đặc biệt hữu ích khi kết hợp dữ liệu từ nhiều hệ thống để có cái nhìn rộng hơn về quy trình. Trong mô hình này, giá trị luôn là Azure DevOps. Dù giá trị có vẻ cố định khi chỉ phân tích một hệ thống, thuộc tính này vẫn cung cấp thông tin cần thiết về nguồn gốc dữ liệu. Đây là yếu tố quan trọng để quản trị dữ liệu, xử lý sự cố và tích hợp thêm các hệ thống như ServiceNow hoặc SAP trong tương lai.
Vì sao điều này quan trọng
Thuộc tính này cung cấp thông tin quan trọng về nguồn gốc dữ liệu, cần thiết cho việc quản trị, xác thực và phân tích quy trình trên nhiều hệ thống.
Lấy dữ liệu ở đâu
Đây là giá trị cố định, cần được thêm vào tập dữ liệu trong quá trình trích xuất và chuyển đổi dữ liệu.
Ví dụ
Azure DevOps
|
|||
|
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
|
Dấu thời gian cho biết lần gần nhất dữ liệu của quy trình được làm mới từ hệ thống nguồn. | ||
|
Mô tả
Thuộc tính này ghi lại thời điểm tập dữ liệu được trích xuất và cập nhật gần nhất từ Azure DevOps. Qua đó, bạn biết dữ liệu còn mới đến đâu và phân tích bao quát khoảng thời gian nào. Trong mọi phân tích quy trình, biết dữ liệu được cập nhật gần đây hay chưa là điều cần thiết để đưa ra quyết định phù hợp. Dấu thời gian này giúp người dùng biết họ đang xem thông tin gần thời gian thực hay ảnh chụp dữ liệu lịch sử, từ đó đánh giá mức độ phù hợp của các phát hiện.
Vì sao điều này quan trọng
Thuộc tính này cho người dùng biết dữ liệu được cập nhật đến thời điểm nào, giúp họ hiểu rõ khoảng thời gian làm cơ sở cho phân tích và quyết định.
Lấy dữ liệu ở đâu
Đây là dấu thời gian siêu dữ liệu được tạo và lưu trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL).
Ví dụ
2024-05-20T08:00:00Z
|
|||
|
Có làm lại
IsRework
|
Cờ đúng/sai cho biết hạng mục phát triển có quay lại một giai đoạn trước đó trong vòng đời hay không. | ||
|
Mô tả
Cờ này được đặt thành true nếu hạng mục công việc đi vào một vòng lặp làm lại, chẳng hạn chuyển từ 'Đã hoàn tất kiểm thử QA' về 'Bắt đầu phát triển'. Giá trị được tính bằng cách phân tích chuỗi hoạt động của một trường hợp và phát hiện tiến trình không đi theo một chiều. Thuộc tính này rất cần thiết cho bảng điều khiển Tần suất làm lại và kiểm thử lại, cũng như KPI Tần suất vòng lặp làm lại. Bạn có thể dễ dàng lọc và định lượng công việc làm lại, từ đó xác định vấn đề về chất lượng, khoảng trống trong giao tiếp hoặc khâu kiểm thử chưa đầy đủ gây lãng phí.
Vì sao điều này quan trọng
Thuộc tính này xác định và định lượng trực tiếp công việc làm lại, giúp phát hiện vấn đề về chất lượng và điểm kém hiệu quả trong quy trình khiến thời gian chu kỳ kéo dài.
Lấy dữ liệu ở đâu
Đây là thuộc tính được tính toán bằng cách phân tích chuỗi hoạt động trong nhật ký sự kiện của từng trường hợp.
Ví dụ
truefalse
|
|||
|
Loại work item
WorkItemType
|
Phân loại hạng mục phát triển, chẳng hạn Bug, Feature, User Story hoặc Task. | ||
|
Mô tả
Loại work item phân loại tính chất của công việc. Mỗi loại thường đi theo luồng quy trình và có kỳ vọng về hiệu suất hoặc SLA khác nhau. Ví dụ, Bug có thể được xử lý theo luồng nhanh hơn Feature. Thuộc tính này cần thiết để so sánh. Bạn có thể lọc sơ đồ quy trình hoặc KPI theo loại công việc để xem quy trình xử lý Bug có hiệu quả hơn Feature hay không, hoặc theo dõi xu hướng thời gian chu kỳ của từng nhóm công việc.
Vì sao điều này quan trọng
Thuộc tính này cho phép phân nhóm khi phân tích quy trình, giúp so sánh quy trình làm việc và hiệu suất giữa các loại công việc như Bug và Feature.
Lấy dữ liệu ở đâu
Đây là trường 'Work Item Type' của Work Item trong Azure DevOps.
Ví dụ
BugTính năngUser StoryNhiệm vụ
|
|||
|
Mức độ ưu tiên
Priority
|
Thứ hạng bằng số hoặc mô tả mức độ quan trọng của hạng mục phát triển so với các hạng mục khác. | ||
|
Mô tả
Mức độ ưu tiên cho biết thứ tự cần xử lý của một hạng mục công việc. Hạng mục có mức ưu tiên cao thường cần được xử lý sớm hơn hạng mục có mức ưu tiên thấp. Giá trị thường là các số như 1, 2, 3, 4, trong đó 1 là mức cao nhất. Thuộc tính này rất cần thiết cho bảng điều khiển Thông lượng và thời gian chu kỳ theo mức ưu tiên. Phân tích dữ liệu theo thuộc tính này giúp bạn đánh giá hệ thống ưu tiên có hiệu quả hay không, tức là các hạng mục ưu tiên cao có thực sự đi qua quy trình nhanh hơn các hạng mục ưu tiên thấp hay không.
Vì sao điều này quan trọng
Thuộc tính này giúp đánh giá quy trình có ưu tiên xử lý nhanh các hạng mục quan trọng hay không, một yếu tố then chốt để xem xét hiệu quả của chiến lược ưu tiên.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Priority' của Work Item trong Azure DevOps.
Ví dụ
1234
|
|||
|
Người được giao
AssignedTo
|
Người dùng hoặc thành viên nhóm hiện được giao Development Item. | ||
|
Mô tả
Thuộc tính này xác định người chịu trách nhiệm xử lý work item ở từng giai đoạn của quy trình. Người được giao có thể thay đổi nhiều lần trong vòng đời của hạng mục, chẳng hạn từ nhà phát triển sang người kiểm thử rồi đến quản lý phát hành. Phân tích theo 'Assigned To' rất quan trọng đối với dashboard Developer and Tester Workload Overview. Thuộc tính này giúp bạn hiểu cách phân bổ tài nguyên, xác định thành viên đang quá tải và so sánh hiệu suất giữa các cá nhân hoặc nhóm.
Vì sao điều này quan trọng
Thuộc tính này cho phép phân tích theo tài nguyên, giúp bạn hiểu cách phân bổ khối lượng công việc, xác định điểm nghẽn liên quan đến tài nguyên và quản lý năng lực của nhóm.
Lấy dữ liệu ở đâu
Đây là trường 'Assigned To' của Work Item trong Azure DevOps. Giá trị được lấy từ lịch sử work item cho từng sự kiện.
Ví dụ
jane.doe@example.comjohn.smith@example.comchưa được giao
|
|||
|
Tên nhóm
TeamName
|
Tên nhóm phát triển chịu trách nhiệm xử lý hạng mục công việc. | ||
|
Mô tả
Team Name cho biết nhóm cụ thể được giao xử lý một hạng mục công việc. Trong Azure DevOps, công việc thường được chia theo nhóm, mỗi nhóm có thể là một phần của dự án lớn hơn. Thuộc tính này cho phép phân tích quy trình theo từng nhóm. Bạn có thể so sánh quy trình và hiệu suất giữa các nhóm, tìm ra cách làm hiệu quả ở những nhóm có kết quả tốt, đồng thời xác định nhóm nào cần được hỗ trợ hoặc cải tiến quy trình.
Vì sao điều này quan trọng
Thuộc tính này cho phép so sánh các nhóm, giúp phát hiện khác biệt về hiệu suất và chia sẻ cách làm hiệu quả trong toàn tổ chức.
Lấy dữ liệu ở đâu
Thông tin này thường được lấy từ 'Area Path' của hạng mục công việc, vì trong Azure DevOps, mỗi nhóm thường được gắn với một đường dẫn khu vực cụ thể.
Ví dụ
Nhóm PhoenixĐội OmegaNền tảng cốt lõiNhóm giao diện người dùng
|
|||
|
Thời điểm kết thúc
EndTime
|
Dấu thời gian cho biết một hoạt động hoàn tất khi nào. Dữ liệu này được dùng để tính thời gian xử lý hoạt động. | ||
|
Mô tả
Thời gian kết thúc đánh dấu lúc một hoạt động hoàn tất. Trong nhiều nhật ký sự kiện, thời gian bắt đầu của hoạt động tiếp theo được dùng làm thời gian kết thúc của hoạt động trước đó. Tuy nhiên, nếu ghi nhận thời gian kết thúc riêng, bạn có thể tính chính xác hơn cả thời gian xử lý hoạt động lẫn thời gian chờ giữa các hoạt động. Thuộc tính này rất quan trọng để tính KPI ProcessingTime và phân tích chi tiết điểm nghẽn. Nó giúp phân biệt thời gian thực sự làm nhiệm vụ với thời gian chờ bước tiếp theo bắt đầu. Đây là thông tin cần thiết cho dashboard Stage Handoff Analysis.
Vì sao điều này quan trọng
Thuộc tính này giúp tính chính xác thời gian xử lý hoạt động và thời gian nhàn rỗi, làm cơ sở để phân tích điểm nghẽn và cải thiện hiệu quả.
Lấy dữ liệu ở đâu
Giá trị này thường được suy ra. Có thể dùng thời gian bắt đầu của sự kiện tiếp theo trong cùng trường hợp, hoặc ghi nhận trực tiếp nếu hệ thống nguồn lưu cả thời gian bắt đầu và kết thúc của nhiệm vụ.
Ví dụ
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
Trạng thái
State
|
Trạng thái hiện tại của hạng mục phát triển trong quy trình làm việc, chẳng hạn như 'Mới', 'Đang thực hiện', 'Đã xử lý' hoặc 'Đã đóng'. | ||
|
Mô tả
Thuộc tính State thể hiện trạng thái chính thức của một hạng mục công việc tại từng thời điểm, theo mẫu quy trình của dự án. Các lần chuyển trạng thái là nguồn chính để tạo hoạt động trong nhật ký sự kiện. Thuộc tính 'Activity' thường mô tả thay đổi trạng thái rõ hơn, nhưng thuộc tính 'State' thô vẫn hữu ích khi lọc và phân tích. Thuộc tính này giúp bạn biết hạng mục ở từng trạng thái trong bao lâu, đồng thời là cơ sở để tạo dashboard Thời lượng giai đoạn và phân tích các lần bàn giao.
Vì sao điều này quan trọng
Thuộc tính này cho biết hạng mục công việc đang ở trạng thái nào trong vòng đời. Đây là thông tin thiết yếu để hiểu luồng quy trình và tính thời gian ở từng giai đoạn.
Lấy dữ liệu ở đâu
Tương ứng với trường 'State' của Work Item trong Azure DevOps.
Ví dụ
MớiĐang thực hiệnĐang kiểm thử QAĐã xử lýĐã đóng
|
|||
|
Đường dẫn vòng lặp
IterationPath
|
Sprint hoặc khoảng thời gian phát triển được ấn định cho hạng mục công việc. | ||
|
Mô tả
Iteration Path, hay sprint, là một khoảng thời gian phát triển có giới hạn cụ thể. Hạng mục công việc được đưa vào một vòng lặp để hoàn thành trong khoảng thời gian đó. Phân tích theo Iteration Path giúp bạn hiểu hiệu suất quy trình qua từng sprint. Bạn có thể theo dõi thời gian chu kỳ có cải thiện qua các sprint hay không, phân tích công việc chuyển tiếp sang sprint sau và đánh giá mức độ dự đoán được của việc lập kế hoạch sprint.
Vì sao điều này quan trọng
Thuộc tính này cho phép phân tích theo sprint, giúp nhóm đánh giá hiệu suất theo thời gian và cải thiện cách làm agile.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Iteration Path' của Work Item trong Azure DevOps.
Ví dụ
Nền tảng thương mại điện tử\Sprint 12Nền tảng thương mại điện tử\Sprint 13Ra mắt lại ứng dụng di động\Giai đoạn 2\Sprint 4
|
|||
|
ID pull request
PullRequestId
|
Mã định danh của pull request được liên kết với hạng mục phát triển. | ||
|
Mô tả
Thuộc tính này liên kết hạng mục công việc với một pull request cụ thể, nơi gửi và xem xét các thay đổi mã. Một hạng mục công việc có thể liên kết với nhiều pull request. Pull Request ID cho phép phân tích chi tiết hơn giai đoạn xem xét và tích hợp mã. Bạn có thể đo thời gian từ lúc tạo pull request đến khi hoàn tất, đồng thời xem pull request thường bị từ chối hoặc cần sửa đổi lớn đến mức nào. Đây có thể là dấu hiệu cho thấy chất lượng mã hoặc yêu cầu chưa rõ ràng.
Vì sao điều này quan trọng
Thuộc tính này liên kết công việc phát triển với các hoạt động xem xét mã cụ thể, giúp phân tích chi tiết quá trình tích hợp mã và đảm bảo chất lượng.
Lấy dữ liệu ở đâu
Bạn có thể tìm thông tin này trong mục 'Links' hoặc 'Development' của Work Item trong Azure DevOps.
Ví dụ
452145334589
|
|||
|
Mức độ nghiêm trọng
Severity
|
Cho biết lỗi hoặc sự cố ảnh hưởng đến hệ thống hay người dùng cuối ở mức nào. | ||
|
Mô tả
Mức độ nghiêm trọng dùng để phân loại tác động của lỗi, từ sự cố nghiêm trọng làm hệ thống ngừng hoạt động đến lỗi nhỏ về giao diện. Khái niệm này khác với mức độ ưu tiên, vốn quyết định thứ tự xử lý. Một lỗi nghiêm trọng vẫn có thể có mức ưu tiên thấp nếu đã có cách khắc phục tạm thời dễ áp dụng. Thuộc tính này bổ sung một góc nhìn khác cho phân tích, đặc biệt là bảng điều khiển Thông lượng và thời gian chu kỳ theo mức ưu tiên. Bạn có thể tìm hiểu những câu hỏi như 'Chúng ta có xử lý các lỗi nghiêm trọng nhất trước không?' và đánh giá mức độ rủi ro của công việc đang được xử lý.
Vì sao điều này quan trọng
Thuộc tính này giúp phân loại hạng mục công việc theo tác động đến hoạt động kinh doanh, từ đó đánh giá nhóm xử lý các vấn đề ảnh hưởng lớn hiệu quả đến đâu.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Severity' của Work Item trong Azure DevOps, thường dùng cho lỗi.
Ví dụ
1 - Nghiêm trọng2 - Cao3 - Trung bình4 - Thấp
|
|||
|
Tên dự án
ProjectName
|
Tên dự án Azure DevOps chứa hạng mục phát triển. | ||
|
Mô tả
Thuộc tính này xác định dự án cụ thể trong tổ chức Azure DevOps nơi lưu hạng mục công việc. Nó cung cấp bối cảnh tổng quan, đặc biệt hữu ích với các tổ chức có nhiều dự án. Tên dự án là một tiêu chí quan trọng để lọc và so sánh dữ liệu. Thuộc tính này hỗ trợ bảng điều khiển Xu hướng thời gian chu kỳ theo lịch sử, cho phép phân tích theo từng dự án. Qua đó, bạn có thể biết dự án nào hoạt động hiệu quả hơn, hoặc những cải tiến quy trình ở một dự án có mang lại kết quả tích cực hay không.
Vì sao điều này quan trọng
Thuộc tính này giúp nhóm dữ liệu ở cấp tổng quan, để so sánh hiệu suất và xu hướng giữa các dự án.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Team Project' của Work Item trong Azure DevOps.
Ví dụ
Nền tảng thương mại điện tửRa mắt lại ứng dụng di độngHiện đại hóa kho dữ liệu
|
|||
|
Thời gian bàn giao giữa các giai đoạn
StageHandoffTime
|
Thời gian chờ giữa lúc hoàn tất một giai đoạn chính và lúc bắt đầu giai đoạn tiếp theo. | ||
|
Mô tả
Thời gian bàn giao giữa các giai đoạn đo khoảng chờ giữa những giai đoạn liên tiếp trong quy trình, chẳng hạn từ 'Hoàn tất phát triển' đến 'Bắt đầu kiểm thử QA'. Chỉ số này được tính bằng cách xác định các lần chuyển tiếp quan trọng, rồi đo khoảng thời gian từ khi hoạt động đầu tiên kết thúc đến khi hoạt động thứ hai bắt đầu. Chỉ số này là trọng tâm của bảng điều khiển Thời lượng từng giai đoạn và phân tích bàn giao. Việc tách riêng và đo thời gian bàn giao rất quan trọng để phát hiện các điểm nghẽn tiềm ẩn, nơi công việc bị đình trệ do thiếu tài nguyên, chậm trao đổi hoặc quy trình chưa hiệu quả.
Vì sao điều này quan trọng
Chỉ số này đo thời gian chờ giữa các giai đoạn, giúp phát hiện trực tiếp điểm nghẽn và độ trễ tiềm ẩn không thuộc thời gian làm việc thực tế.
Lấy dữ liệu ở đâu
Đây là thuộc tính được tính toán. Trước tiên, cần xác định các cặp hoạt động liên tiếp thể hiện việc bàn giao, sau đó tính khoảng thời gian giữa chúng.
Ví dụ
2 giờ 15 phút1 ngày 4 giờ30 phút
|
|||
|
Thời gian chờ phê duyệt
ApprovalWaitingTime
|
Thời gian hạng mục phát triển chờ được phê duyệt sau khi gửi yêu cầu. | ||
|
Mô tả
Chỉ số này đo thời gian hạng mục công việc chờ phê duyệt. Ví dụ điển hình là khoảng thời gian từ 'Bắt đầu UAT' đến 'UAT được phê duyệt'. Chỉ số được tính bằng cách đo thời gian giữa hai hoạt động này trong một trường hợp. Thuộc tính được tính toán này hỗ trợ trực tiếp bảng điều khiển Phân tích thời gian chờ phê duyệt và KPI tương ứng. Khi xác định riêng các độ trễ này, nhóm có thể cải thiện cách trao đổi và ra quyết định để giảm thời gian chờ, đồng thời rút ngắn toàn bộ vòng đời.
Vì sao điều này quan trọng
Chỉ số này đo riêng độ trễ do chờ quyết định hoặc phê duyệt, qua đó cho thấy cơ hội cải thiện việc trao đổi và ra quyết định.
Lấy dữ liệu ở đâu
Chỉ số được tính bằng cách tìm các hoạt động bắt đầu và kết thúc phê duyệt cụ thể trong nhật ký sự kiện, chẳng hạn 'Bắt đầu UAT' và 'UAT được phê duyệt', rồi tính khoảng thời gian giữa chúng.
Ví dụ
3 ngày 2 giờ1 ngày 8 giờ 30 phút4 giờ
|
|||
Các hoạt động trong vòng đời phát triển phần mềm
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
Bắt đầu kiểm thử QA
|
Đánh dấu thời điểm bắt đầu giai đoạn kiểm thử đảm bảo chất lượng chính thức. Sự kiện này được suy ra khi trạng thái work item chuyển sang 'In QA', 'Testing' hoặc giá trị tương tự. | ||
|
Vì sao điều này quan trọng
Đánh dấu thời điểm bắt đầu chu kỳ QA. Phân tích thời lượng giai đoạn này rất quan trọng để hiểu các điểm nghẽn và hiệu quả trong kiểm thử.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item bằng cách theo dõi khi trường System.State chuyển sang 'In QA' hoặc một trạng thái kiểm thử được chỉ định khác.
Thu thập
Suy ra khi trường State chuyển sang 'In QA' hoặc 'Testing'.
Loại sự kiện
inferred
|
|||
|
Bắt đầu phát triển
|
Hoạt động này cho biết nhà phát triển đã bắt đầu xử lý work item. Sự kiện được suy ra khi trạng thái của work item chuyển sang 'Active', 'In Progress' hoặc 'Committed'. | ||
|
Vì sao điều này quan trọng
Đánh dấu thời điểm bắt đầu giai đoạn phát triển thực tế. Phân tích thời gian từ 'Created' đến 'Development Started' giúp xác định thời gian chờ trong backlog.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item khi trường System.State chuyển từ 'New' hoặc 'Approved' sang 'In Progress'.
Thu thập
Suy ra khi trường State chuyển sang 'Active' hoặc 'In Progress'.
Loại sự kiện
inferred
|
|||
|
Hoàn tất pull request
|
Đánh dấu việc đánh giá mã đã hoàn tất thành công, pull request được phê duyệt và mã được gộp vào nhánh đích. Azure Repos ghi nhận sự kiện này. | ||
|
Vì sao điều này quan trọng
Đánh dấu kết thúc giai đoạn đánh giá mã, vốn thường là một điểm nghẽn. Phân tích thời gian từ lúc tạo đến khi hoàn tất PR giúp đánh giá hiệu quả của chu kỳ đánh giá.
Lấy dữ liệu ở đâu
Ghi nhận từ sự kiện hoàn tất hoặc gộp pull request trong Azure Repos có liên kết với work item.
Thu thập
Ghi nhận từ sự kiện gộp pull request có liên kết với work item.
Loại sự kiện
explicit
|
|||
|
Tạo pull request
|
Cho biết nhà phát triển đã hoàn tất phần lập trình ban đầu và gửi các thay đổi để đánh giá qua pull request. Sự kiện này liên kết work item với một thay đổi mã cụ thể trong Azure Repos. | ||
|
Vì sao điều này quan trọng
Đây là bước bàn giao quan trọng từ phát triển sang đánh giá mã. Theo dõi bước này giúp đo thời gian lập trình và xác định khi nào mã sẵn sàng để đồng nghiệp đánh giá.
Lấy dữ liệu ở đâu
Ghi nhận từ dữ liệu Azure Repos bằng cách liên kết sự kiện tạo pull request với work item tương ứng. Nhà phát triển thường tạo liên kết này trực tiếp.
Thu thập
Ghi nhận từ sự kiện tạo pull request trong Azure Repos được liên kết với work item.
Loại sự kiện
explicit
|
|||
|
Tạo work item
|
Hoạt động này đánh dấu thời điểm bắt đầu vòng đời phát triển, khi một hạng mục công việc mới như User Story, Bug hoặc Task được tạo. Azure DevOps Boards ghi nhận sự kiện này khi lưu bản ghi mới. | ||
|
Vì sao điều này quan trọng
Đây là sự kiện bắt đầu chính của quy trình. Sự kiện này cần thiết để đo thời gian phát triển từ đầu đến cuối và hiểu công việc bắt nguồn từ đâu.
Lấy dữ liệu ở đâu
Sự kiện này được ghi nhận từ trường 'Created Date' của work item. Bảng lịch sử work item cũng lưu lại lần chuyển trạng thái ban đầu này.
Thu thập
Lấy từ trường 'Created Date' của work item.
Loại sự kiện
explicit
|
|||
|
Triển khai lên production
|
Đánh dấu mã liên quan đến work item đã được triển khai thành công lên môi trường production. Sự kiện này được ghi nhận từ nhật ký phát hành của Azure Pipelines. | ||
|
Vì sao điều này quan trọng
Đây là mốc quan trọng, đánh dấu giá trị đã được chuyển giao. Mốc này được dùng làm điểm kết thúc để tính thời gian từ lúc bắt đầu đến khi hoàn tất và thời gian chu kỳ.
Lấy dữ liệu ở đâu
Ghi nhận từ dữ liệu release pipeline của Azure Pipelines, cụ thể là sự kiện hoàn tất triển khai lên giai đoạn 'Production' có liên kết với work item.
Thu thập
Ghi nhận từ sự kiện hoàn tất triển khai của release pipeline.
Loại sự kiện
explicit
|
|||
|
UAT được phê duyệt
|
Hoạt động này cho biết các bên liên quan trong doanh nghiệp đã phê duyệt thay đổi sau khi kiểm thử chấp nhận người dùng. Sự kiện thường được suy ra khi trạng thái chuyển từ 'In UAT' sang 'UAT Approved' hoặc 'Ready for Release'. | ||
|
Vì sao điều này quan trọng
Đây là mốc phê duyệt quan trọng, xác nhận work item đáp ứng yêu cầu nghiệp vụ và sẵn sàng triển khai lên môi trường production.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item bằng cách phát hiện trường System.State chuyển từ trạng thái UAT sang trạng thái đã phê duyệt hoặc sẵn sàng phát hành.
Thu thập
Suy ra khi trường State chuyển từ 'In UAT' sang 'Ready for Release'.
Loại sự kiện
inferred
|
|||
|
Bắt đầu UAT
|
Đánh dấu thời điểm bắt đầu kiểm thử chấp nhận người dùng (UAT), khi các bên liên quan trong doanh nghiệp xác nhận chức năng. Sự kiện này thường được suy ra khi trạng thái chuyển sang 'In UAT' hoặc trạng thái tương tự. | ||
|
Vì sao điều này quan trọng
Đo thời điểm bắt đầu bước xác nhận cuối cùng trước khi phát hành. Cần phân tích thời lượng UAT và thời gian chờ phê duyệt để cải tiến quy trình.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item khi trường System.State được cập nhật sang trạng thái tùy chỉnh đại diện cho UAT, chẳng hạn như 'In UAT'.
Thu thập
Suy ra khi trường State chuyển sang 'In UAT'.
Loại sự kiện
inferred
|
|||
|
Build thành công
|
Hoạt động này xác nhận mã nguồn, bao gồm các thay đổi mới, đã được biên dịch và đóng gói thành công bằng build pipeline. Azure Pipelines ghi nhận sự kiện này. | ||
|
Vì sao điều này quan trọng
Đây là cổng chất lượng quan trọng, đảm bảo mã mới tích hợp đúng mà không làm hỏng build. Lỗi ở bước này có thể cho thấy vấn đề khi tích hợp.
Lấy dữ liệu ở đâu
Ghi nhận từ sự kiện hoàn tất build trong Azure Pipelines. Build cần được liên kết với work item, trực tiếp hoặc thông qua pull request liên quan.
Thu thập
Ghi nhận từ sự kiện hoàn tất build trong Azure Pipelines.
Loại sự kiện
explicit
|
|||
|
Đóng work item
|
Đánh dấu work item đã được đóng sau khi triển khai và hoàn tất các bước xác nhận sau triển khai. Sự kiện này được ghi nhận khi trạng thái chuyển sang 'Closed' hoặc 'Done'. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu toàn bộ quy trình của work item đã hoàn tất thành công. Đây là điểm kết thúc cuối cùng của vòng đời.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item khi trường System.State chuyển sang 'Closed' hoặc trạng thái kết thúc tương tự thuộc nhóm 'Completed'.
Thu thập
Suy ra khi trường State chuyển sang 'Closed'.
Loại sự kiện
inferred
|
|||
|
Hoàn tất kiểm thử QA
|
Đánh dấu giai đoạn đảm bảo chất lượng đã hoàn tất thành công. Sự kiện này được suy ra khi trạng thái work item chuyển từ trạng thái kiểm thử sang trạng thái như 'Ready for UAT' hoặc 'QA Approved'. | ||
|
Vì sao điều này quan trọng
Đây là cổng chất lượng quan trọng, cho biết work item đã sẵn sàng để kiểm thử chấp nhận người dùng hoặc phát hành. Chậm trễ sau bước này có thể cho thấy điểm nghẽn trong UAT hoặc lập kế hoạch phát hành.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item khi trường System.State chuyển từ 'In QA' sang trạng thái tiếp theo như 'Ready for UAT' hoặc 'Done'.
Thu thập
Suy ra khi trường State chuyển từ 'In QA' sang 'Ready for UAT'.
Loại sự kiện
inferred
|
|||
|
Hoàn tất phát triển
|
Cho biết các hoạt động phát triển và kiểm thử đơn vị đã hoàn tất, work item sẵn sàng chuyển sang kiểm thử chính thức. Sự kiện này thường được suy ra khi trạng thái work item chuyển sang 'Resolved' hoặc 'Ready for Test'. | ||
|
Vì sao điều này quan trọng
Đánh dấu bước bàn giao quan trọng từ nhóm phát triển sang nhóm QA. Đo thời gian đến khi 'QA Testing Started' giúp xác định chậm trễ trong khâu bàn giao.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item khi trường System.State chuyển sang giá trị như 'Resolved' hoặc trạng thái tùy chỉnh cho biết hạng mục đã sẵn sàng cho QA.
Thu thập
Suy ra khi trường State chuyển sang 'Resolved'.
Loại sự kiện
inferred
|
|||
|
Hủy work item
|
Cho biết work item đã bị hủy và sẽ không được hoàn tất hoặc triển khai. Sự kiện này được ghi nhận khi trạng thái chuyển sang 'Removed', 'Cancelled' hoặc trạng thái tương tự. | ||
|
Vì sao điều này quan trọng
Đây là một kết thúc khác của quy trình, không dẫn đến kết quả thành công. Phân tích các hạng mục bị hủy có thể giúp phát hiện vấn đề trong lập kế hoạch, sắp xếp ưu tiên hoặc xác định yêu cầu.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item khi trường System.State chuyển sang trạng thái kết thúc thuộc nhóm 'Removed'.
Thu thập
Suy ra khi trường State chuyển sang 'Removed' hoặc 'Cancelled'.
Loại sự kiện
inferred
|
|||
|
Kiểm thử QA không đạt
|
Cho biết work item không đạt kiểm thử QA và được chuyển lại cho nhóm phát triển. Sự kiện này được ghi nhận khi trạng thái chuyển từ trạng thái kiểm thử về 'In Progress' hoặc 'Active'. | ||
|
Vì sao điều này quan trọng
Hoạt động này rất cần thiết để xác định các vòng lặp làm lại. Sự kiện xảy ra thường xuyên có thể cho thấy vấn đề về chất lượng mã, yêu cầu hoặc quy trình kiểm thử.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item bằng cách phát hiện trạng thái chuyển từ 'In QA' về trạng thái như 'Active' hoặc 'In Progress'.
Thu thập
Suy ra khi trường State chuyển từ 'In QA' về 'Active'.
Loại sự kiện
inferred
|
|||
|
Phê duyệt work item
|
Đánh dấu work item đã được phê duyệt chính thức, xác nhận rằng hạng mục được mô tả rõ và sẵn sàng phát triển. Sự kiện này thường được suy ra khi trường 'State' chuyển sang giá trị như 'Approved' hoặc 'Ready for Dev'. | ||
|
Vì sao điều này quan trọng
Theo dõi phê duyệt giúp phân tích thời gian từ lúc gửi ý tưởng đến khi cam kết phát triển. Qua đó, bạn có thể phát hiện chậm trễ trong khâu lập kế hoạch và rà soát backlog.
Lấy dữ liệu ở đâu
Suy ra từ lịch sử work item bằng cách phát hiện trường System.State chuyển sang 'Approved' hoặc một trạng thái tùy chỉnh tương tự.
Thu thập
Suy ra khi trường State chuyển sang 'Approved'.
Loại sự kiện
inferred
|
|||
Hướng dẫn trích xuất dữ liệu
Sẵn sàng bắt đầu chưa?
Bắt đầu tối ưu vòng đời phát triển phần mềm ngay hôm nay. Mẫu này là bước đầu tiên giúp bạn khám phá những thông tin hữu ích về quy trình.
Bắt đầu tối ưu SDLC trên Azure DevOps ngay hôm nay!
Giảm 30% thời gian chu kỳ và loại bỏ điểm nghẽn trong quy trình SDLC.
Không cần thẻ tín dụng. Bắt đầu chỉ trong vài phút.