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
- Hướng dẫn trích xuất dữ liệu
Thuộc tính vòng đời phát triển phần mềm
| Tên | Mô tả | ||
|---|---|---|---|
|
Hạng mục phát triển
DevelopmentItemId
|
Mã định danh duy nhất cho một đơn vị công việc phát triển, chẳng hạn như tính năng, sửa lỗi hoặc nhiệm vụ. Mã này được dùng làm mã định danh chính của từng trường hợp. | ||
|
Mô tả
Mã hạng mục phát triển theo dõi một công việc từ khi tạo đến khi triển khai cuối cùng. Mã này liên kết mọi hoạt động liên quan, như tạo nhánh, commit, pull request, đánh giá và triển khai, thành một trường hợp quy trình thống nhất. Trong phân tích, mã này được dùng để tính thời gian hoàn thành nhiệm vụ phát triển từ đầu đến cuối. Nhờ đó, bạn có thể dựng lại toàn bộ quá trình của một tính năng hoặc bản sửa lỗi, rồi phân tích chi tiết điểm nghẽn, vòng lặp làm lại và những khác biệt trong quy trình của từng hạng mục.
Vì sao điều này quan trọng
Đây là khóa thiết yếu cho process mining, giúp liên kết mọi sự kiện phát triển liên quan vào cùng một trường hợp để trực quan hóa và phân tích chính xác toàn bộ vòng đời phát triển phần mềm.
Lấy dữ liệu ở đâu
Thông thường, đây là số Issue hoặc số Pull Request trong GitHub. Bạn có thể lấy mã này từ trường 'number' trong dữ liệu của webhook hoặc phản hồi API liên quan đến issue hay pull request.
Ví dụ
101PR-2345TASK-812
|
|||
|
Hoạt động
ActivityName
|
Tên của một sự kiện hoặc nhiệm vụ cụ thể diễn ra trong vòng đời phát triển phần mềm. | ||
|
Mô tả
Tên hoạt động mô tả một bước trong quy trình phát triển, chẳng hạn như 'Tạo issue', 'Đẩy mã lên PR', 'Phê duyệt pull request' hoặc 'Triển khai thành công'. Các sự kiện này tạo thành chuỗi bước của quy trình từ đầu đến cuối cho một hạng mục phát triển. Thuộc tính này là nền tảng của process mining vì được dùng để dựng sơ đồ quy trình. Phân tích thứ tự, tần suất và thời lượng của các hoạt động giúp làm rõ luồng quy trình thực tế, xác định các đường đi phổ biến, nhận ra điểm khác biệt và tìm ra điểm nghẽn.
Vì sao điều này quan trọng
Thuộc tính này là nền tảng của sơ đồ quy trình, giúp trực quan hóa và phân tích thứ tự sự kiện trong vòng đời phát triển.
Lấy dữ liệu ở đâu
Lấy từ trường 'action' trong dữ liệu sự kiện webhook, chẳng hạn 'opened' hoặc 'closed' của issue, hoặc từ chính loại sự kiện, chẳng hạn 'PushEvent' hay 'PullRequestReviewEvent'.
Ví dụ
Tạo issueMở pull requestĐẩy mã lên PRYêu cầu đánh giáHợp nhất pull request
|
|||
|
Thời gian bắt đầu
EventTimestamp
|
Ngày và giờ chính xác khi một hoạt động hoặc sự kiện phát triển cụ thể diễn ra. | ||
|
Mô tả
Mốc thời gian này ghi lại lúc một hoạt động bắt đầu. Đây là dữ liệu cần thiết để sắp xếp sự kiện theo trình tự thời gian và dựng lại luồng quy trình cho từng hạng mục phát triển. Thứ tự và khoảng cách thời gian giữa các mốc được dùng để phân tích hiệu suất quy trình. Trong phân tích, thuộc tính này cần thiết để 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 xác định độ trễ giữa các bước và cung cấp dữ liệu để phân tích điểm nghẽn cũng như theo dõi hiệu suất trên bảng điều khiển.
Vì sao điều này quan trọng
Mốc thời gian này rất quan trọng để sắp xếp sự kiện chính xác và tính các chỉ số hiệu suất như thời gian chu kỳ và thời lượng điểm nghẽn.
Lấy dữ liệu ở đâu
Thường có trong các trường 'created_at' hoặc 'updated_at' của dữ liệu JSON từ GitHub API và webhook cho nhiều đối tượng như issue, pull request và commit.
Ví dụ
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Kho lưu trữ
RepositoryName
|
Tên kho lưu trữ mã nơi diễn ra hoạt động phát triển. | ||
|
Mô tả
Kho lưu trữ đóng vai trò là mã định danh dự án hoặc sản phẩm, chứa toàn bộ mã, issue và pull request của một ứng dụng hoặc thành phần cụ thể. Thuộc tính này giúp phân nhóm và so sánh quy trình phát triển giữa các sản phẩm hoặc nhóm. Trong phân tích, bạn có thể dùng thuộc tính này để lọc và so sánh hiệu suất quy trình giữa các dự án. Thuộc tính giúp trả lời những câu hỏi như: “Dự án nào có thời gian chu kỳ dài nhất?” hoặc “Quy trình sửa lỗi ở Dự án A khác gì so với Dự án B?”. Đây là thuộc tính thiết yếu cho bảng điều khiển 'Thông lượng theo dự án và loại công việc'.
Vì sao điều này quan trọng
Giúp phân nhóm và so sánh quy trình phát triển giữa các dự án, sản phẩm hoặc nhóm để phân tích tập trung hơn.
Lấy dữ liệu ở đâu
Có trong đối tượng 'repository' ở hầu hết dữ liệu webhook và API của GitHub. Trường cụ thể thường là 'repository.full_name' hoặc 'repository.name'.
Ví dụ
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Loại hạng mục phát triển
DevelopmentItemType
|
Phân loại hạng mục công việc phát triển, chẳng hạn như tính năng, lỗi, nhiệm vụ hoặc epic. | ||
|
Mô tả
Thuộc tính này phân loại công việc đang thực hiện. Thông tin thường được quản lý bằng nhãn hoặc mẫu issue riêng trong GitHub. Hiểu rõ loại công việc là điều cần thiết để đặt kỳ vọng hiệu suất phù hợp, vì thời gian dự kiến để sửa lỗi có thể ngắn hơn nhiều so với phát triển tính năng mới. Thuộc tính này cho phép so sánh các loại công việc khác nhau. Bạn có thể phân tích xem lỗi được xử lý nhanh hơn tính năng mới hay không, hoặc tìm hiểu cách phân bổ tài nguyên giữa nợ kỹ thuật và phát triển mới. Đây là chiều phân tích quan trọng trong bảng điều khiển 'Thông lượng theo dự án và loại công việc'.
Vì sao điều này quan trọng
Phân loại hạng mục công việc để so sánh hiệu suất và phân tích cách từng loại công việc, chẳng hạn như lỗi và tính năng, đi qua quy trình.
Lấy dữ liệu ở đâu
Thường được xác định từ nhãn GitHub gắn cho issue hoặc pull request. Cần có quy ước đặt nhãn nhất quán, chẳng hạn như 'type:bug' hoặc 'type:feature'.
Ví dụ
LỗiTính năngNhiệm vụNợ kỹ thuật
|
|||
|
Mức độ ưu tiên
Priority
|
Mức độ ưu tiên được gán cho một hạng mục phát triển, chẳng hạn như 'Cao', 'Trung bình' hoặc 'Thấp'. | ||
|
Mô tả
Mức độ ưu tiên cho biết một hạng mục công việc cần được xử lý gấp đến đâu hoặc quan trọng thế nào với hoạt động kinh doanh. GitHub không có trường ưu tiên mặc định, nên người dùng thường quản lý bằng nhãn, chẳng hạn 'P1-High', 'P2-Medium'. Cần thống nhất cách đặt nhãn để trích xuất thông tin này một cách đáng tin cậy. Thuộc tính này rất cần thiết để phân tích luồng công việc theo mức độ ưu tiên. Nhờ đó, chuyên viên phân tích có thể kiểm tra xem hạng mục ưu tiên cao có thực sự được xử lý nhanh hơn hạng mục ưu tiên thấp hay không, đồng thời đo chênh lệch thời gian chu kỳ giữa các mức ưu tiên. Đây cũng là cơ sở để đánh giá hiệu quả của quy trình sắp xếp ưu tiên.
Vì sao điều này quan trọng
Giúp phân tích xem hạng mục ưu tiên cao có được xử lý nhanh hơn hạng mục ưu tiên thấp hay không, qua đó đánh giá hiệu quả của chiến lược sắp xếp ưu tiên.
Lấy dữ liệu ở đâu
Được xác định từ nhãn gắn cho issue hoặc pull request trên GitHub. Cần thống nhất quy ước đặt nhãn ưu tiên.
Ví dụ
CaoTrung bìnhThấpNghiêm trọng
|
|||
|
Người dùng được giao
Assignee
|
Người dùng hoặc nhà phát triển được giao xử lý hạng mục phát triển hay một nhiệm vụ cụ thể, chẳng hạn như đánh giá pull request. | ||
|
Mô tả
Thuộc tính này cho biết ai chịu trách nhiệm thực hiện công việc ở từng giai đoạn. Đó có thể là người được giao xử lý issue, tác giả pull request hoặc người được yêu cầu đánh giá mã. Theo dõi người được giao giúp hiểu cách phân bổ tài nguyên và khối lượng công việc. Trong phân tích, thuộc tính này được dùng để theo dõi khối lượng công việc của nhà phát triển, xác định điểm nghẽn về tài nguyên và đánh giá hiệu quả bàn giao giữa các thành viên. Bạn có thể lọc bảng điều khiển theo người được giao để đánh giá hiệu suất cá nhân hoặc nhóm và đảm bảo công việc được phân bổ cân bằng.
Vì sao điều này quan trọng
Cần thiết để phân tích khối lượng công việc của nhà phát triển, hiệu suất nhóm và hiệu quả bàn giao giữa các thành viên.
Lấy dữ liệu ở đâu
Có trong đối tượng 'assignee' hoặc 'user' của dữ liệu JSON cho issue, pull request và sự kiện đánh giá từ GitHub API.
Ví dụ
john.doejane.smithdev-team-lead
|
|||
|
Thời gian kết thúc
EndTimestamp
|
Ngày và giờ chính xác khi một hoạt động hoặc sự kiện phát triển cụ thể hoàn tất. | ||
|
Mô tả
Mốc thời gian kết thúc ghi lại lúc một hoạt động hoàn tất. Nhiều sự kiện trong GitHub diễn ra tức thời, chẳng hạn như 'Tạo issue', nhưng một số hoạt động có thời lượng đo được, chẳng hạn như chạy kiểm tra CI. Lấy thời gian kết thúc trừ thời gian bắt đầu sẽ cho biết thời gian xử lý của hoạt động. Thuộc tính này được dùng để tính chỉ số 'ProcessingTime', giúp xác định thời gian thực sự dành cho các nhiệm vụ như đánh giá mã hoặc kiểm tra tự động. Phân tích thời gian xử lý giúp tìm ra những hoạt động kém hiệu quả và tốn quá nhiều thời gian.
Vì sao điều này quan trọng
Giúp tính chính xác thời gian xử lý của từng hoạt động, qua đó phân biệt thời gian làm việc thực tế với thời gian chờ.
Lấy dữ liệu ở đâu
Có thể tìm thấy trong trường 'completed_at' của đối tượng lần chạy kiểm tra, hoặc suy ra từ mốc thời gian của một sự kiện tiếp theo có ý nghĩa kết thúc hoạt động.
Ví dụ
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Có phải làm lại
IsRework
|
Cờ boolean có giá trị true nếu một hoạt động thể hiện việc quay lại giai đoạn trước trong quy trình. | ||
|
Mô tả
Cờ này được đặt thành true khi hạng mục phát triển lùi lại trong quy trình, chẳng hạn pull request nhận đánh giá 'Changes Requested' hoặc issue được mở lại sau khi đã đóng. Giá trị được xác định bằng cách phân tích chuỗi hoạt động. Thuộc tính này rất cần thiết để định lượng lãng phí và sự kém hiệu quả. Thuộc tính hỗ trợ trực tiếp dashboard 'Vòng lặp làm lại và hồi quy' và KPI 'Tỷ lệ làm lại'. Khi lọc theo 'IsRework = true', chuyên viên phân tích có thể tách riêng và tìm hiểu nguyên nhân làm lại.
Vì sao điều này quan trọng
Đánh dấu rõ các hoạt động cần làm lại, giúp dễ dàng định lượng, trực quan hóa và phân tích nguyên nhân khiến quy trình kém hiệu quả.
Lấy dữ liệu ở đâu
Đây là thuộc tính được suy ra. Cách xác định gồm việc thiết lập luồng quy trình chuẩn, sau đó đánh dấu mọi hoạt động lệch khỏi luồng do quay lại một giai đoạn logic trước đó.
Ví dụ
truefalse
|
|||
|
Hệ thống nguồn
SourceSystem
|
Hệ thống dùng để trích xuất dữ liệu quy trình phát triển. | ||
|
Mô tả
Thuộc tính này cho biết nguồn gốc của dữ liệu sự kiện. Với quy trình này, giá trị thường là 'GitHub'. Trong môi trường phức tạp hơn, nơi hoạt động phát triển diễn ra trên nhiều hệ thống, chẳng hạn Jira để lập kế hoạch, GitHub để quản lý mã và Jenkins để triển khai, trường này giúp phân biệt nguồn của từng sự kiện. Trong phân tích, thuộc tính này giúp truy ngược dữ liệu về nguồn để kiểm tra và xử lý sự cố. Thuộc tính cũng hỗ trợ phân tích quy trình đi qua nhiều nền tảng, giúp làm rõ bối cảnh của từng hoạt động.
Vì sao điều này quan trọng
Cho biết nguồn gốc dữ liệu, cần thiết để kiểm tra dữ liệu và phân tích quy trình có thể trải rộng trên nhiều hệ thống tích hợp.
Lấy dữ liệu ở đâu
Đây thường là giá trị cố định được thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL) để ghi nhãn nguồn của các bản ghi.
Ví dụ
GitHubGitHub Enterprise
|
|||
|
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
|
Mốc thời gian cho biết lần gần nhất dữ liệu của bản ghi này được làm mới từ hệ thống nguồn. | ||
|
Mô tả
Thuộc tính này ghi lại ngày giờ của lần trích xuất hoặc cập nhật dữ liệu gần nhất. Đây là siêu dữ liệu cho biết dữ liệu đang phân tích có mới hay không. Mốc này khác với thời gian sự kiện, vốn ghi lại lúc sự kiện nghiệp vụ diễn ra. Trong phân tích, trường này giúp bạn biết dữ liệu về quy trình được cập nhật đến đâu. Bạn có thể kiểm tra mình đang xem dữ liệu gần thời gian thực hay ảnh chụp dữ liệu tại một thời điểm cụ thể, điều quan trọng khi theo dõi và vận hành bảng điều khiển.
Vì sao điều này quan trọng
Cho biết dữ liệu có mới hay không, giúp đảm bảo các phân tích và bảng điều khiển dựa trên thông tin cập nhật.
Lấy dữ liệu ở đâu
Mốc thời gian này được tạo và thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL).
Ví dụ
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Mã băm commit
CommitHash
|
Mã định danh duy nhất (SHA) của một commit mã cụ thể. | ||
|
Mô tả
Mã băm commit là mã SHA-1 gồm 40 ký tự, dùng để nhận diện duy nhất một commit trong Git. Mã này đóng vai trò như ID cố định cho một phiên bản mã cụ thể. Commit là đơn vị thay đổi nhỏ nhất trong quy trình phát triển. Dù có mức độ chi tiết cao, mã băm commit giúp truy vết đến tận cùng. Chuyên viên phân tích có thể liên kết trực tiếp một sự kiện trong quy trình với chính xác thay đổi mã đã thực hiện. Điều này rất hữu ích cho việc kiểm tra, tuân thủ hoặc phân tích nguyên nhân gốc rễ của sự cố production.
Vì sao điều này quan trọng
Liên kết bước quy trình với chính xác thay đổi mã ở mức chi tiết nhất, giúp truy vết đầy đủ khi kiểm tra và gỡ lỗi.
Lấy dữ liệu ở đâu
Có trong dữ liệu sự kiện push ('head_commit.id') hoặc qua Commits API của pull request hay nhánh.
Ví dụ
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Môi trường triển khai
DeploymentEnvironment
|
Môi trường đích để triển khai, chẳng hạn 'Staging' hoặc 'Production'. | ||
|
Mô tả
Thuộc tính này cho biết mã đang được triển khai đến đâu. Theo dõi việc triển khai ở các môi trường khác nhau là yếu tố then chốt để hiểu toàn bộ vòng đời, từ phát triển đến phát hành chính thức. Thuộc tính này giúp phân tích quy trình con triển khai. Bạn có thể dùng thuộc tính để đo thời gian đưa mã từ staging lên production và theo dõi tỷ lệ triển khai thành công ở từng môi trường. Đây là thông tin cần thiết để xác định khi nào một hạng mục phát triển thực sự hoàn tất và đã đến tay người dùng.
Vì sao điều này quan trọng
Phân biệt bản phát hành trước production với bản phát hành production. Đây là yếu tố quan trọng để đo thời gian đưa sản phẩm ra thị trường và phân tích mô hình triển khai.
Lấy dữ liệu ở đâu
Thông tin này được lấy từ GitHub Deployments API, thường do quy trình CI/CD hoặc công cụ tự động khác kích hoạt.
Ví dụ
developmentstagingproduction
|
|||
|
Người đánh giá
Reviewer
|
Người dùng được yêu cầu đánh giá mã trong pull request. | ||
|
Mô tả
Người đánh giá là lập trình viên hoặc thành viên nhóm được giao kiểm tra các thay đổi mã trong pull request về chất lượng, tính chính xác và mức độ tuân thủ tiêu chuẩn. Một pull request có thể có nhiều người đánh giá. Thuộc tính này rất cần thiết để phân tích quy trình đánh giá mã. Thuộc tính giúp xác định điểm nghẽn liên quan đến từng người đánh giá, hiểu cách phân bổ khối lượng đánh giá và đo thời gian họ phản hồi yêu cầu. Đây là thành phần quan trọng để tính KPI 'Thời gian chu kỳ đánh giá mã trung bình'.
Vì sao điều này quan trọng
Cho biết những người tham gia vào quy trình đảm bảo chất lượng, giúp phân tích khối lượng đánh giá, độ trễ và hiệu quả chung của việc đánh giá mã.
Lấy dữ liệu ở đâu
Có trong mảng 'requested_reviewers' hoặc đối tượng 'user' của sự kiện đánh giá pull request từ GitHub API.
Ví dụ
alex.chenmaria.garciasenior-dev-team
|
|||
|
Nhãn
Labels
|
Danh sách thẻ hoặc nhãn gắn cho issue hay pull request để phân loại. | ||
|
Mô tả
Nhãn trong GitHub là cách linh hoạt để bổ sung siêu dữ liệu cho issue và pull request. Bạn có thể dùng nhãn để thể hiện mức độ ưu tiên, loại công việc, thành phần, nhóm hoặc trạng thái. Danh sách nhãn gốc cung cấp nhiều thông tin ngữ cảnh chưa được cấu trúc. Các thuộc tính như Mức độ ưu tiên và Loại được xác định từ nhãn, nhưng lưu lại toàn bộ danh sách vẫn hữu ích cho phân tích tùy ý và tìm ra các mô hình quy trình khác. Danh sách này cho phép lọc và phân nhóm trường hợp linh hoạt theo bất kỳ tổ hợp nhãn nào.
Vì sao điều này quan trọng
Cung cấp nguồn siêu dữ liệu linh hoạt và phong phú để phân loại hạng mục công việc, hỗ trợ phân tích theo nhiều chiều.
Lấy dữ liệu ở đâu
Có trong mảng 'labels' thuộc dữ liệu JSON của issue và pull request từ GitHub API. Mỗi phần tử trong mảng là một đối tượng có trường 'name'.
Ví dụ
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
Số pull request
PullRequestNumber
|
Mã định danh duy nhất của pull request liên quan đến hạng mục phát triển. | ||
|
Mô tả
Pull request (PR) là đề xuất gộp một nhóm thay đổi mã vào một nhánh cụ thể. Số pull request liên kết các hoạt động phát triển như đẩy mã và đánh giá mã với hạng mục phát triển hoặc issue chính. Mã này rất quan trọng để theo dõi việc tích hợp mã và quy trình con đánh giá mã trong toàn bộ vòng đời phát triển. Bạn có thể phân tích chi tiết quy trình đánh giá mã, bao gồm thời gian đánh giá, các vòng làm lại được phát hiện trong quá trình đánh giá và tỷ lệ gộp mã. Mã này kết nối giai đoạn lập kế hoạch (issue) với giai đoạn triển khai (PR).
Vì sao điều này quan trọng
Liên kết issue với các thay đổi mã và quy trình đánh giá tương ứng, giúp phân tích chi tiết chu kỳ đánh giá mã và ảnh hưởng của chu kỳ này đến tổng thời gian bàn giao.
Lấy dữ liệu ở đâu
Có trong trường 'number' của đối tượng 'pull_request' ở nhiều phản hồi GitHub API, hoặc là mã định danh chính từ Pull Requests API.
Ví dụ
12345678910
|
|||
|
Tác giả
Author
|
Người dùng tạo issue, pull request hoặc commit. | ||
|
Mô tả
Tác giả là người tạo ra một đối tượng cụ thể trong quy trình phát triển. Ví dụ, tác giả của issue là người báo lỗi hoặc đề xuất tính năng. Tác giả của pull request là lập trình viên viết mã. Khi phân tích, bạn có thể dùng tác giả để tìm hiểu nguồn phát sinh công việc. Chẳng hạn, phân tích người gửi báo cáo lỗi có thể cho thấy các xu hướng liên quan đến một nhóm hoặc tính năng cụ thể. Kết hợp thuộc tính này với người được giao việc cũng giúp phân tích cách công việc được bàn giao.
Vì sao điều này quan trọng
Cho biết ai là người khởi tạo hạng mục công việc hoặc thay đổi mã. Thông tin này hữu ích khi phân tích nguồn phát sinh công việc làm lại, báo cáo lỗi hoặc yêu cầu tính năng.
Lấy dữ liệu ở đâu
Có trong đối tượng 'user' thuộc đối tượng chính của phản hồi API cho issue, pull request và commit. Trường thường dùng là 'user.login'.
Ví dụ
sara.jonesmike.leeautomation-bot
|
|||
|
Tên nhánh
BranchName
|
Tên nhánh Git chứa các thay đổi mã cho hạng mục phát triển. | ||
|
Mô tả
Nhánh là một luồng phát triển độc lập, được tạo để làm tính năng mới hoặc sửa lỗi mà không ảnh hưởng đến mã nguồn chính. Tên nhánh thường chứa thông tin hữu ích như số issue hoặc mô tả ngắn về công việc. Phân tích tên nhánh giúp bạn hiểu chiến lược phân nhánh và kiểm tra việc tuân thủ quy ước phát triển. Tên nhánh cũng giúp liên kết các commit mã với hạng mục phát triển, qua đó cung cấp bức tranh đầy đủ về hoạt động lập trình.
Vì sao điều này quan trọng
Cho biết ngữ cảnh của luồng phát triển cụ thể, đồng thời giúp áp dụng và phân tích chiến lược phân nhánh cũng như quy ước đặt tên.
Lấy dữ liệu ở đâu
Có trong trường 'ref' của sự kiện push, hoặc trong các đối tượng 'head' và 'base' thuộc phản hồi API của pull request.
Ví dụ
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
Thời gian chờ khi bàn giao
HandoffWaitingTime
|
Thời gian nhàn rỗi được tính khi một hạng mục phát triển chờ giữa các hoạt động do những người khác nhau thực hiện. | ||
|
Mô tả
Chỉ số này đo thời gian từ lúc một hoạt động hoàn tất đến khi hoạt động tiếp theo bắt đầu, nhưng chỉ tính khi người phụ trách thay đổi. Ví dụ, khoảng thời gian từ sự kiện 'Review Requested' đến sự kiện 'Changes Requested in Review' do người dùng khác thực hiện. Đây là chỉ số quan trọng để phát hiện khoảng trống giao tiếp và vấn đề phối hợp. Chỉ số hỗ trợ dashboard 'Hiệu quả bàn giao ở khâu then chốt' và KPI 'Thời gian chờ bàn giao trung bình'. Thời gian chờ dài tại các điểm bàn giao thường cho thấy thiếu nguồn lực hoặc quy trình thông báo chưa hiệu quả.
Vì sao điều này quan trọng
Giúp xác định độ trễ do phối hợp kém hoặc thiếu nguồn lực khi bàn giao giữa các nhóm hay vai trò khác nhau. Đây thường là nguyên nhân lớn gây kém hiệu quả.
Lấy dữ liệu ở đâu
Tính bằng cách xác định các hoạt động liên tiếp có thuộc tính 'Assignee' hoặc 'User' thay đổi, rồi đo khoảng thời gian giữa chúng.
Ví dụ
PT1H15MP2DT4HPT25M
|
|||
|
Thời gian chu kỳ phát triển
DevelopmentCycleTime
|
Tổng thời gian từ khi tạo hạng mục phát triển đến khi triển khai hoặc đóng hạng mục. | ||
|
Mô tả
Đây là chỉ số ở cấp trường hợp, được tính bằng khoảng thời gian từ sự kiện đầu tiên (chẳng hạn 'Issue Created') đến sự kiện cuối cùng (chẳng hạn 'Deployment Succeeded' hoặc 'Issue Closed') của một hạng mục phát triển. Đây là một trong những KPI quan trọng nhất để đo hiệu quả chung của quy trình phát triển. Chỉ số này hỗ trợ trực tiếp dashboard 'Tổng thời gian chu kỳ phát triển' và KPI 'Thời gian chu kỳ phát triển trung bình'. Các sáng kiến cải tiến quy trình thường đặt mục tiêu giảm chỉ số này.
Vì sao điều này quan trọng
Thể hiện thời gian từ đầu đến cuối để đưa một hạng mục phát triển ra thị trường. Đây là KPI quan trọng để đo tốc độ và hiệu quả chung của quy trình.
Lấy dữ liệu ở đâu
Tính ở cấp trường hợp bằng cách lấy dấu thời gian của hoạt động cuối trừ dấu thời gian của hoạt động đầu tiên.
Ví dụ
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Trạng thái đánh giá
ReviewState
|
Kết quả đánh giá mã trong pull request, chẳng hạn 'Approved' hoặc 'Changes Requested'. | ||
|
Mô tả
Thuộc tính này ghi nhận quyết định của người đánh giá. Các trạng thái thường gặp gồm 'APPROVED', nghĩa là mã đã sẵn sàng để gộp, và 'CHANGES_REQUESTED', nghĩa là cần làm lại. Các trạng thái khác có thể gồm 'COMMENTED' hoặc 'PENDING'. Đây là thuộc tính quan trọng để phân tích công việc làm lại và chất lượng. Tần suất sự kiện 'CHANGES_REQUESTED' cao có thể cho thấy chất lượng mã ban đầu chưa đạt hoặc yêu cầu chưa rõ ràng. Thuộc tính này hỗ trợ trực tiếp dashboard 'Vòng lặp làm lại và hồi quy' bằng cách xác định thời điểm hạng mục phát triển bị yêu cầu chỉnh sửa.
Vì sao điều này quan trọng
Cho thấy trực tiếp các vòng làm lại và bước kiểm soát chất lượng trong quy trình đánh giá mã, giúp xác định nguồn gây kém hiệu quả và vấn đề về chất lượng.
Lấy dữ liệu ở đâu
Có trong trường 'state' của đối tượng đánh giá pull request từ GitHub API, chẳng hạn trong dữ liệu của 'PullRequestReviewEvent'.
Ví dụ
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
Trạng thái hạng mục
State
|
Trạng thái hiện tại của issue hoặc pull request, chẳng hạn như 'open', 'closed' hoặc 'merged'. | ||
|
Mô tả
Thuộc tính này cho biết trạng thái tổng quát của một hạng mục phát triển. Issue thường có trạng thái 'open' hoặc 'closed'. Pull request có thể ở trạng thái 'open', 'closed' hoặc 'merged'. Nhờ đó, bạn có thể nắm được tiến độ hiện tại của hạng mục. Trong phân tích, trạng thái giúp phân biệt công việc đang thực hiện với công việc đã hoàn tất. Đây là dữ liệu cần thiết cho các bảng điều khiển như 'Tiến độ phát triển đang thực hiện', dùng để theo dõi công việc hiện tại. Trạng thái cũng giúp xác định điểm kết thúc quy trình. Ví dụ, trạng thái 'merged' hoặc 'closed' có thể đánh dấu một trường hợp đã hoàn tất.
Vì sao điều này quan trọng
Cho biết rõ hạng mục công việc đang được xử lý hay đã hoàn tất, là thông tin nền tảng để phân tích vòng đời và theo dõi công việc đang diễn ra.
Lấy dữ liệu ở đâu
Có sẵn trong trường 'state' của dữ liệu JSON cho issue và pull request từ GitHub API.
Ví dụ
đang mởđã đóngđã hợp nhất
|
|||
|
Trạng thái kiểm tra CI
CiCheckStatus
|
Trạng thái của một bước kiểm tra Tích hợp liên tục (CI) tự động, chẳng hạn 'passed' hoặc 'failed'. | ||
|
Mô tả
Thuộc tính này ghi nhận kết quả của các bản dựng, bài kiểm thử và lượt quét tự động chạy trên những thay đổi mã trong pull request. Kiểm tra CI là một bước kiểm soát chất lượng quan trọng trong quy trình phát triển hiện đại. Phân tích thuộc tính này giúp bạn hiểu hiệu quả của kiểm thử tự động. Tỷ lệ thất bại cao có thể cho thấy vấn đề về độ ổn định của mã, bộ kiểm thử hoặc môi trường phát triển. Thuộc tính này hỗ trợ các hoạt động 'CI Checks Passed' và 'CI Checks Failed', đồng thời giúp phân tích độ trễ do bản dựng lỗi.
Vì sao điều này quan trọng
Cho biết các bước kiểm soát chất lượng tự động thành công hay thất bại, qua đó cung cấp thông tin về chất lượng mã và hiệu quả của quy trình CI.
Lấy dữ liệu ở đâu
Lấy từ trường 'state' hoặc 'conclusion' của đối tượng check run hoặc status thông qua GitHub Checks API hoặc Statuses API.
Ví dụ
successfailurependingerror
|
|||
Hoạt động trong vòng đời phát triển phần mềm
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
CI kiểm tra thành công
|
Đánh dấu các bước kiểm tra tự động đã hoàn tất thành công, chẳng hạn như biên dịch, kiểm thử đơn vị hoặc phân tích tĩnh trên mã trong pull request. Sự kiện này được suy ra từ trạng thái kiểm tra do các hệ thống như GitHub Actions báo cáo. | ||
|
Vì sao điều này quan trọng
Đây là bước kiểm soát chất lượng tự động, cần thiết để đảm bảo mã ổn định. Lỗi hoặc thời gian chạy kéo dài có thể trở thành điểm nghẽn đáng kể trong quy trình phát hành.
Lấy dữ liệu ở đâu
Được suy ra từ GitHub Checks API hoặc Statuses API. Một lần chạy kiểm tra hoặc cập nhật trạng thái báo 'success', hoặc báo 'completed' với kết luận 'success'.
Thu thập
Theo dõi Checks API để tìm kết luận 'success' trong các bộ kiểm tra liên quan.
Loại sự kiện
inferred
|
|||
|
Đóng issue
|
Hạng mục phát triển được xem là hoàn tất và issue tương ứng được đóng chính thức. Việc này có thể diễn ra tự động khi pull request được liên kết đã hợp nhất, hoặc do một thành viên trong nhóm thực hiện thủ công. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu điểm kết thúc chính thức của quy trình cho một hạng mục phát triển. Đây là dữ liệu cần thiết để tính thời gian hoàn thành từ đầu đến cuối.
Lấy dữ liệu ở đâu
Đây là sự kiện được ghi nhận trực tiếp từ luồng sự kiện của GitHub Issues API. Loại sự kiện là 'closed'.
Thu thập
Theo dõi sự kiện 'closed' của issue qua webhook hoặc truy vấn API định kỳ.
Loại sự kiện
explicit
|
|||
|
Hợp nhất pull request
|
Các thay đổi mã đã được phê duyệt trong pull request được tích hợp chính thức vào nhánh đích, chẳng hạn như main hoặc develop. Đây là thao tác cuối cùng được ghi nhận trực tiếp trên pull request, đưa mã mới vào nhánh đích. | ||
|
Vì sao điều này quan trọng
Đây là cột mốc quan trọng, đánh dấu hoàn tất việc phát triển và đánh giá mã. Với nhiều nhóm, đây là bước cuối trước khi tự động triển khai.
Lấy dữ liệu ở đâu
Được ghi nhận từ luồng sự kiện của GitHub Pull Request API hoặc qua webhook. Hành động của sự kiện là 'closed' và thuộc tính 'merged' trong dữ liệu pull request có giá trị true.
Thu thập
Theo dõi hành động 'closed' của pull request và kiểm tra xem cờ 'merged' có giá trị true hay không.
Loại sự kiện
explicit
|
|||
|
Mở pull request
|
Đánh dấu thời điểm phần mã đầu tiên sẵn sàng để đánh giá và tích hợp. Nhà phát triển tạo pull request (PR) để đề xuất đưa thay đổi từ nhánh tính năng vào nhánh chính. Đây là sự kiện được ghi nhận trực tiếp trong GitHub. | ||
|
Vì sao điều này quan trọng
Đây là cột mốc quan trọng, đánh dấu kết thúc giai đoạn phát triển ban đầu và bắt đầu quy trình đánh giá, tích hợp. Cột mốc này giúp phân tích riêng thời gian phát triển và thời gian đánh giá.
Lấy dữ liệu ở đâu
Được ghi nhận từ luồng sự kiện của GitHub Pull Request API hoặc qua webhook. Hành động của sự kiện là 'opened'.
Thu thập
Theo dõi hành động 'opened' của pull request qua webhook hoặc truy vấn API định kỳ.
Loại sự kiện
explicit
|
|||
|
Phê duyệt pull request
|
Người đánh giá chính thức phê duyệt các thay đổi trong pull request, xác nhận chúng đáp ứng tiêu chuẩn chất lượng và chức năng. Sự kiện này được ghi nhận khi người đánh giá gửi kết quả với trạng thái 'approve'. | ||
|
Vì sao điều này quan trọng
Đây là bước kiểm soát chất lượng quan trọng và là cột mốc lớn trước khi hợp nhất mã. Thời gian từ lúc tạo PR đến khi đạt trạng thái này là KPI quan trọng để đánh giá hiệu quả của quy trình đánh giá.
Lấy dữ liệu ở đâu
Được ghi nhận từ GitHub Pull Request API hoặc qua webhook khi kết quả đánh giá có trạng thái 'APPROVED'.
Thu thập
Lọc các sự kiện gửi kết quả đánh giá pull request theo trạng thái 'APPROVED'.
Loại sự kiện
explicit
|
|||
|
Tạo issue
|
Đánh dấu thời điểm bắt đầu vòng đời của một hạng mục phát triển, khi một nhiệm vụ, lỗi hoặc yêu cầu tính năng được tạo chính thức. Sự kiện này được ghi nhận khi người dùng tạo issue mới trong kho lưu trữ GitHub. | ||
|
Vì sao điều này quan trọng
Đây là hoạt động bắt đầu chính của quy trình, cần thiết để đo tổng thời gian phát triển và hiểu công việc ban đầu đến từ đâu.
Lấy dữ liệu ở đâu
Đây là sự kiện được ghi nhận trực tiếp từ luồng sự kiện của GitHub Issues API. Loại sự kiện thường là 'opened' cho một issue cụ thể.
Thu thập
Theo dõi sự kiện 'opened' của issue qua webhook hoặc truy vấn API định kỳ.
Loại sự kiện
explicit
|
|||
|
CI kiểm tra thất bại
|
Đánh dấu một bước kiểm tra tự động thất bại, chẳng hạn như lỗi biên dịch hoặc kiểm thử đơn vị không đạt, trên mã trong pull request. Sự kiện này được suy ra từ trạng thái lỗi do hệ thống như GitHub Actions báo cáo. | ||
|
Vì sao điều này quan trọng
Hoạt động này cho thấy vấn đề kỹ thuật về chất lượng cần nhà phát triển xử lý, khiến quy trình quay lại bước làm lại. Phân tích tần suất lỗi giúp xác định cách cải thiện kiểm thử tại máy cá nhân hoặc chất lượng mã.
Lấy dữ liệu ở đâu
Được suy ra từ GitHub Checks API hoặc Statuses API. Một lần chạy kiểm tra hoặc cập nhật trạng thái báo 'failure', hoặc báo 'completed' với kết luận 'failure'.
Thu thập
Theo dõi Checks API để tìm kết luận 'failure' trong các bộ kiểm tra liên quan.
Loại sự kiện
inferred
|
|||
|
Đẩy mã lên PR
|
Đánh dấu lần cập nhật mã được gửi để đánh giá, có thể là một phần của PR ban đầu hoặc để phản hồi ý kiến đánh giá. Sự kiện này được ghi nhận mỗi khi có commit mới được đẩy lên nhánh gắn với một pull request đang mở. | ||
|
Vì sao điều này quan trọng
Theo dõi các sự kiện này là điều cần thiết để nhận ra vòng lặp làm lại. Nếu có nhiều lần đẩy mã sau khi đánh giá, nhóm có thể đã phải chỉnh sửa, khiến tổng thời gian hoàn thành kéo dài.
Lấy dữ liệu ở đâu
Đây là sự kiện được ghi nhận trực tiếp trong dòng thời gian của pull request, thường có nhãn cho biết đã thêm commit. Có thể ghi nhận sự kiện này từ webhook 'push' hoặc bằng cách theo dõi các commit gắn với PR.
Thu thập
Theo dõi sự kiện 'push' trên nhánh gắn với pull request đang mở.
Loại sự kiện
explicit
|
|||
|
Mở lại issue
|
Một issue đã đóng được kích hoạt lại, thường vì bản sửa lỗi chưa đủ hoặc phát hiện lỗi hồi quy. Đây là sự kiện được ghi nhận trực tiếp, bắt đầu lại vòng đời của hạng mục phát triển. | ||
|
Vì sao điều này quan trọng
Đây là dấu hiệu của một vòng lặp làm lại đáng kể, có thể cho thấy lỗi đã lọt ra production hoặc bản sửa chưa hoàn chỉnh. Theo dõi tần suất sự kiện này là cách quan trọng để đo chất lượng phần mềm tổng thể.
Lấy dữ liệu ở đâu
Đây là sự kiện được ghi nhận trực tiếp từ luồng sự kiện của GitHub Issues API. Loại sự kiện là 'reopened'.
Thu thập
Theo dõi sự kiện 'reopened' của issue qua webhook hoặc truy vấn API định kỳ.
Loại sự kiện
explicit
|
|||
|
Tạo nhánh
|
Đánh dấu thời điểm bắt đầu công việc phát triển cho một issue, khi nhà phát triển tạo nhánh mới từ mã nguồn chính. Sự kiện này được ghi nhận khi nhánh mới được đẩy lên kho lưu trữ. Tên nhánh thường có chứa số issue. | ||
|
Vì sao điều này quan trọng
Đánh dấu bước chuyển từ lập kế hoạch sang viết mã. Đo khoảng thời gian từ lúc tạo issue đến sự kiện này giúp phân tích thời gian nhà phát triển bắt đầu xử lý và độ trễ do tồn đọng ban đầu.
Lấy dữ liệu ở đâu
Được ghi nhận qua GitHub Git API hoặc webhook theo dõi sự kiện 'create' có loại 'branch'. Thường cần liên kết tên nhánh với issue theo quy ước đặt tên, chẳng hạn 'feature/issue-123'.
Thu thập
Phân tích sự kiện webhook 'create' để tìm nhánh mới, rồi liên kết nhánh với issue tương ứng.
Loại sự kiện
explicit
|
|||
|
Triển khai thành công
|
Các thay đổi mã đã được triển khai thành công lên một môi trường cụ thể, chẳng hạn như staging hoặc production. Sự kiện này thường được ghi nhận qua GitHub Deployments API, thường do GitHub Action kích hoạt sau khi hợp nhất mã. | ||
|
Vì sao điều này quan trọng
Đánh dấu thời điểm mã được chuyển từ kho lưu trữ sang môi trường đang hoạt động. Theo dõi sự kiện này là điều cần thiết để đo toàn bộ thời gian từ ý tưởng đến production.
Lấy dữ liệu ở đâu
Được ghi nhận qua Deployments API. Một dịch vụ bên ngoài hoặc GitHub Action tạo lượt triển khai, sau đó cập nhật trạng thái thành 'success'.
Thu thập
Theo dõi sự kiện trạng thái triển khai qua webhook để tìm trạng thái 'success'.
Loại sự kiện
inferred
|
|||
|
Yêu cầu chỉnh sửa sau khi đánh giá
|
Người đánh giá đã hoàn tất việc xem xét mã và xác định cần chỉnh sửa trước khi có thể phê duyệt pull request. Người đánh giá gửi kết quả chính thức với trạng thái 'request_changes'. | ||
|
Vì sao điều này quan trọng
Sự kiện này cho thấy rõ quy trình đã quay lại bước làm lại. Phân tích tần suất sự kiện giúp xác định vấn đề chất lượng, yêu cầu chưa rõ hoặc những nội dung nhà phát triển cần được đào tạo thêm.
Lấy dữ liệu ở đâu
Được ghi nhận từ GitHub Pull Request API hoặc qua webhook khi kết quả đánh giá có trạng thái 'CHANGES_REQUESTED'.
Thu thập
Lọc các sự kiện gửi kết quả đánh giá pull request theo trạng thái 'CHANGES_REQUESTED'.
Loại sự kiện
explicit
|
|||
|
Yêu cầu đánh giá
|
Tác giả pull request chính thức yêu cầu một số thành viên hoặc nhóm cụ thể đánh giá mã. Đây là thao tác trực tiếp trong giao diện hoặc API của GitHub, đồng thời gửi thông báo đến những người được yêu cầu đánh giá. | ||
|
Vì sao điều này quan trọng
Hoạt động này đánh dấu thời điểm chính thức bắt đầu bàn giao sang khâu đánh giá mã. Thời gian từ lúc này đến khi gửi kết quả đánh giá giúp đo tốc độ phản hồi và xác định điểm nghẽn tiềm ẩn.
Lấy dữ liệu ở đâu
Được ghi nhận từ luồng sự kiện của GitHub Pull Request API hoặc qua webhook. Hành động của sự kiện là 'review_requested'.
Thu thập
Theo dõi hành động 'review_requested' của pull request.
Loại sự kiện
explicit
|
|||
Hướng dẫn trích xuất dữ liệu
Sẵn sàng bắt đầu?
Dùng mẫu này để chuẩn bị dữ liệu và bắt đầu tối ưu vòng đời phát triển phần mềm. Tìm ra những khâu kém hiệu quả để phát hành nhanh hơn, suôn sẻ hơn.
Cải thiện SDLC: nhanh chóng tìm ra khâu kém hiệu quả
Giảm 30% thời gian chu kỳ và tinh gọn quy trình phát triển trên GitHub.
Không cần thẻ tín dụng, thiết lập chỉ trong vài phút.