Templat data siklus pengembangan perangkat lunak Anda
Templat data siklus pengembangan perangkat lunak Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data
Atribut siklus pengembangan perangkat lunak
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Nama peristiwa atau tugas tertentu yang terjadi dalam siklus pengembangan perangkat lunak. | ||
|
Deskripsi
Nama Aktivitas menjelaskan satu langkah dalam proses pengembangan, seperti 'Issue dibuat', 'Kode dikirim ke PR', 'Pull request disetujui', atau 'Penerapan berhasil'. Peristiwa-peristiwa ini membentuk urutan langkah dalam keseluruhan proses untuk sebuah item pengembangan. Atribut ini menjadi dasar process mining karena digunakan untuk menyusun peta proses. Dengan menganalisis urutan, frekuensi, dan durasi aktivitas, Anda dapat melihat alur proses yang sebenarnya, menemukan jalur yang umum, menyoroti penyimpangan, dan mengidentifikasi hambatan.
Mengapa ini penting
Atribut ini menjadi dasar peta proses dan membantu memvisualisasikan serta menganalisis urutan peristiwa dalam siklus pengembangan.
Sumber data
Diambil dari kolom 'action' dalam payload peristiwa webhook, misalnya 'opened' atau 'closed' untuk issue, atau dari jenis peristiwanya, misalnya 'PushEvent' atau 'PullRequestReviewEvent'.
Contoh
Issue dibuatPull request dibukaKode dikirim ke PRPeninjauan dimintaPull request digabungkan
|
|||
|
Item pengembangan
DevelopmentItemId
|
Pengenal unik untuk satu unit pekerjaan pengembangan, seperti fitur, perbaikan bug, atau tugas. Pengenal ini berfungsi sebagai ID kasus utama. | ||
|
Deskripsi
ID Item Pengembangan melacak item pekerjaan sejak dibuat hingga penerapan akhir. ID ini menghubungkan semua aktivitas terkait, seperti pembuatan branch, commit, pull request, peninjauan, dan penerapan, ke dalam satu rangkaian proses. Dalam analisis, ID ini digunakan untuk menghitung waktu siklus tugas pengembangan dari awal hingga akhir. ID ini membantu merekonstruksi seluruh perjalanan fitur atau perbaikan bug, sehingga Anda dapat menganalisis hambatan, siklus pengerjaan ulang, dan variasi proses untuk setiap item pekerjaan.
Mengapa ini penting
ID ini menjadi kunci utama process mining karena menghubungkan semua peristiwa pengembangan terkait ke dalam satu kasus. Dengan begitu, siklus pengembangan perangkat lunak dari awal hingga akhir dapat divisualisasikan dan dianalisis secara akurat.
Sumber data
Biasanya berupa Nomor Issue atau Nomor Pull Request dari GitHub. Nilainya dapat diambil dari kolom 'number' dalam payload peristiwa webhook atau respons API yang terkait dengan issue atau pull request.
Contoh
101PR-2345TASK-812
|
|||
|
Waktu mulai
EventTimestamp
|
Tanggal dan waktu persis saat aktivitas atau peristiwa pengembangan tertentu terjadi. | ||
|
Deskripsi
Stempel waktu ini menandai awal suatu aktivitas. Data ini penting untuk mengurutkan peristiwa secara kronologis dan merekonstruksi alur proses setiap item pengembangan. Urutan dan selisih waktu antarstempel waktu digunakan untuk menganalisis kinerja proses. Dalam analisis, atribut ini diperlukan untuk menghitung semua metrik berbasis waktu, termasuk waktu siklus, waktu pemrosesan, dan waktu tunggu. Atribut ini membantu menemukan keterlambatan antarlangkah dan menyediakan data untuk analisis hambatan serta pemantauan kinerja melalui dasbor.
Mengapa ini penting
Stempel waktu ini penting untuk mengurutkan peristiwa dengan benar dan menghitung semua metrik kinerja, seperti waktu siklus dan durasi hambatan.
Sumber data
Biasanya tersedia dalam kolom 'created_at' atau 'updated_at' pada payload JSON dari GitHub API dan webhook untuk berbagai objek, seperti issue, pull request, dan commit.
Contoh
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Jenis item pengembangan
DevelopmentItemType
|
Klasifikasi item pekerjaan pengembangan, seperti fitur, bug, tugas, atau epic. | ||
|
Deskripsi
Atribut ini mengelompokkan jenis pekerjaan yang dilakukan. Informasi ini biasanya dikelola melalui label atau templat issue khusus di GitHub. Memahami jenis pekerjaan penting untuk menetapkan ekspektasi kinerja yang sesuai. Waktu siklus perbaikan bug, misalnya, mungkin jauh lebih singkat daripada pengembangan fitur baru. Atribut ini memungkinkan perbandingan antarjenis pekerjaan. Anda dapat menganalisis apakah perbaikan bug diproses lebih cepat daripada fitur baru, atau memahami alokasi sumber daya untuk utang teknis dibandingkan pengembangan baru. Atribut ini menjadi dimensi penting dalam dasbor 'Throughput berdasarkan Proyek dan Jenis'.
Mengapa ini penting
Mengelompokkan item pekerjaan agar kinerja dapat dibandingkan dan alur berbagai jenis pekerjaan, seperti bug dan fitur, dapat dianalisis.
Sumber data
Biasanya ditentukan berdasarkan label GitHub pada issue atau pull request. Perlu ada konvensi pelabelan yang konsisten, misalnya 'type:bug' dan 'type:feature'.
Contoh
BugFiturTugasUtang teknis
|
|||
|
Pengguna yang ditugaskan
Assignee
|
Pengguna atau developer yang ditugaskan untuk menangani item pengembangan atau tugas tertentu, seperti peninjauan pull request. | ||
|
Deskripsi
Atribut ini menunjukkan siapa yang bertanggung jawab atas pekerjaan pada tahap tertentu. Orang tersebut dapat berupa penerima tugas issue, pembuat pull request, atau peninjau yang diminta untuk meninjau kode. Melacak penerima tugas penting untuk memahami alokasi sumber daya dan beban kerja. Dalam analisis, atribut ini digunakan untuk memantau beban kerja developer, menemukan hambatan terkait sumber daya, dan menganalisis efisiensi serah terima antaranggota tim. Dasbor dapat difilter berdasarkan penerima tugas untuk menilai kinerja individu atau tim dan memastikan pembagian pekerjaan yang seimbang.
Mengapa ini penting
Penting untuk menganalisis beban kerja developer, kinerja tim, dan efisiensi serah terima antaranggota tim.
Sumber data
Tersedia dalam objek 'assignee' atau 'user' pada payload JSON untuk issue, pull request, dan peristiwa peninjauan dari GitHub API.
Contoh
john.doejane.smithdev-team-lead
|
|||
|
Prioritas
Priority
|
Tingkat prioritas yang ditetapkan untuk item pengembangan, seperti 'Tinggi', 'Sedang', atau 'Rendah'. | ||
|
Deskripsi
Prioritas menunjukkan tingkat urgensi atau kepentingan bisnis suatu item pekerjaan. Di GitHub, prioritas bukan kolom bawaan dan biasanya dikelola menggunakan label, misalnya 'P1-High' atau 'P2-Medium'. Agar informasi ini dapat diambil dengan andal, gunakan skema label yang konsisten. Atribut ini penting untuk 'Analisis Alur Berdasarkan Prioritas'. Analis dapat memeriksa apakah item berprioritas tinggi benar-benar diproses lebih cepat daripada item berprioritas rendah, serta mengukur variasi waktu siklus menurut prioritas. Informasi ini juga membantu menilai efektivitas proses penentuan prioritas.
Mengapa ini penting
Membantu menganalisis apakah item berprioritas tinggi diproses lebih cepat daripada item berprioritas rendah, sekaligus menilai efektivitas strategi penentuan prioritas.
Sumber data
Diambil dari label GitHub pada issue atau pull request. Label prioritas harus mengikuti konvensi yang baku.
Contoh
TinggiSedangRendahKritis
|
|||
|
Repositori
RepositoryName
|
Nama repositori kode tempat aktivitas pengembangan berlangsung. | ||
|
Deskripsi
Repositori berfungsi sebagai pengenal proyek atau produk. Repositori memuat semua kode, issue, dan pull request untuk aplikasi atau komponen tertentu. Repositori juga membantu membagi dan membandingkan proses pengembangan di berbagai produk atau tim. Dalam analisis, atribut ini memungkinkan Anda memfilter dan membandingkan kinerja proses di berbagai proyek. Atribut ini membantu menjawab pertanyaan seperti, 'Proyek mana yang memiliki waktu siklus terlama?' atau 'Bagaimana proses perbaikan bug di Proyek A dibandingkan dengan Proyek B?'. Atribut ini penting untuk dasbor 'Throughput berdasarkan Proyek dan Jenis'.
Mengapa ini penting
Memungkinkan proses pengembangan dibagi dan dibandingkan di berbagai proyek, produk, atau tim, sehingga analisis dapat lebih terarah.
Sumber data
Tersedia dalam objek 'repository' di hampir semua payload webhook dan API GitHub. Kolom yang digunakan biasanya 'repository.full_name' atau 'repository.name'.
Contoh
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Waktu selesai
EndTimestamp
|
Tanggal dan waktu persis saat aktivitas atau peristiwa pengembangan tertentu selesai. | ||
|
Deskripsi
Stempel waktu akhir menandai selesainya suatu aktivitas. Banyak peristiwa di GitHub terjadi seketika, misalnya 'Issue dibuat', tetapi beberapa aktivitas memiliki durasi yang dapat diukur, seperti pemeriksaan CI yang sedang berjalan. Selisih antara Waktu selesai dan Waktu mulai menunjukkan waktu pemrosesan aktivitas. Atribut ini digunakan untuk menghitung metrik 'ProcessingTime', yang penting untuk memahami waktu kerja aktif yang digunakan dalam tugas seperti peninjauan kode atau pemeriksaan otomatis. Analisis waktu pemrosesan membantu menemukan aktivitas yang tidak efisien dan memakan terlalu banyak waktu.
Mengapa ini penting
Memungkinkan penghitungan waktu pemrosesan aktivitas secara akurat, sehingga waktu kerja aktif dapat dibedakan dari waktu tunggu.
Sumber data
Dapat ditemukan sebagai 'completed_at' pada objek check run, atau diturunkan dari stempel waktu peristiwa berikutnya yang secara logis menandai penyelesaian.
Contoh
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Apakah pengerjaan ulang
IsRework
|
Penanda boolean yang bernilai true jika suatu aktivitas menunjukkan proses kembali ke tahap sebelumnya. | ||
|
Deskripsi
Penanda ini bernilai true saat item pengembangan bergerak mundur dalam proses. Contohnya, pull request mendapat ulasan 'Perubahan diminta' atau issue dibuka kembali setelah ditutup. Nilainya ditentukan dengan menganalisis urutan aktivitas. Atribut ini penting untuk mengukur pemborosan dan inefisiensi. Atribut ini mendukung dashboard 'Siklus Pengerjaan Ulang dan Regresi' serta KPI 'Tingkat Pengerjaan Ulang'. Dengan memfilter 'IsRework = true', analis dapat memisahkan dan menyelidiki penyebab pengerjaan ulang.
Mengapa ini penting
Menandai aktivitas yang termasuk pengerjaan ulang secara jelas, sehingga penyebab inefisiensi proses mudah diukur, divisualisasikan, dan dianalisis.
Sumber data
Atribut ini diturunkan dari data. Logikanya menetapkan alur proses standar, lalu menandai aktivitas yang menyimpang karena kembali ke tahap logis sebelumnya.
Contoh
truefalse
|
|||
|
Hash commit
CommitHash
|
Pengenal unik (SHA) untuk commit kode tertentu. | ||
|
Deskripsi
Hash commit adalah hash SHA-1 sepanjang 40 karakter yang menjadi pengenal unik untuk sebuah commit di Git. Hash ini berfungsi sebagai ID permanen untuk versi kode tertentu. Commit adalah unit perubahan terkecil dalam proses pengembangan. Hash commit memberikan tingkat keterlacakan yang sangat terperinci. Analis dapat menghubungkan peristiwa proses langsung ke perubahan kode yang tepat. Ini sangat berguna untuk audit, kepatuhan, atau analisis akar masalah secara terperinci saat terjadi insiden di production.
Mengapa ini penting
Menghubungkan langkah proses dengan perubahan kode yang tepat secara terperinci, sehingga seluruh jejak perubahan dapat ditelusuri untuk keperluan audit dan debugging.
Sumber data
Tersedia dalam payload peristiwa push ('head_commit.id') atau melalui Commits API untuk pull request atau cabang.
Contoh
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Label
Labels
|
Daftar tag atau label yang diterapkan pada issue atau pull request untuk pengelompokan. | ||
|
Deskripsi
Label di GitHub memberi cara fleksibel untuk menambahkan metadata ke issue dan pull request. Label dapat menunjukkan prioritas, jenis pekerjaan, komponen, tim, atau status. Daftar label mentah memberikan konteks yang kaya, tetapi tidak terstruktur. Atribut seperti Prioritas dan Jenis diturunkan dari label, tetapi menyimpan seluruh daftar label tetap berguna untuk analisis sesuai kebutuhan dan menemukan pola proses lainnya. Anda dapat memfilter dan mengelompokkan kasus secara fleksibel berdasarkan kombinasi label apa pun.
Mengapa ini penting
Menyediakan sumber metadata yang kaya dan fleksibel untuk mengelompokkan item pekerjaan, sehingga analisis berdasarkan berbagai dimensi dapat dilakukan secara mendalam.
Sumber data
Tersedia sebagai array 'labels' dalam payload JSON untuk issue dan pull request dari GitHub API. Setiap item dalam array berupa objek dengan kolom 'name'.
Contoh
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
Lingkungan penerapan
DeploymentEnvironment
|
Lingkungan tujuan penerapan, seperti 'Staging' atau 'Production'. | ||
|
Deskripsi
Atribut ini menunjukkan tempat kode diterapkan. Melacak penerapan ke berbagai lingkungan penting untuk memahami seluruh siklus, dari pengembangan hingga rilis ke production. Atribut ini membantu menganalisis subproses penerapan. Anda dapat mengukur waktu yang diperlukan untuk memindahkan kode dari staging ke production dan melacak tingkat keberhasilan penerapan di setiap lingkungan. Informasi ini penting untuk mengetahui kapan item pengembangan benar-benar selesai dan tersedia bagi pengguna.
Mengapa ini penting
Membedakan rilis praproduksi dan production. Ini penting untuk mengukur waktu hingga produk tersedia di pasar dan menganalisis pola penerapan.
Sumber data
Informasi ini diambil dari GitHub Deployments API, yang biasanya dipicu oleh pipeline CI/CD atau otomatisasi lainnya.
Contoh
developmentstagingproduction
|
|||
|
Nama cabang
BranchName
|
Nama cabang Git tempat perubahan kode untuk item pengembangan dibuat. | ||
|
Deskripsi
Cabang adalah jalur pengembangan terpisah yang dibuat untuk mengerjakan fitur baru atau memperbaiki bug tanpa memengaruhi basis kode utama. Nama cabang sering memuat informasi berguna, seperti nomor issue atau deskripsi singkat pekerjaan. Analisis nama cabang membantu Anda memahami strategi percabangan dan kepatuhan terhadap konvensi pengembangan. Nama ini juga membantu menghubungkan commit kode tertentu dengan item pengembangan, sehingga aktivitas pengodean terlihat secara utuh.
Mengapa ini penting
Memberi konteks tentang jalur pengembangan tertentu serta membantu menerapkan dan menganalisis strategi percabangan dan konvensi penamaan.
Sumber data
Tersedia dalam kolom 'ref' untuk peristiwa push, atau dalam objek 'head' dan 'base' pada respons API pull request.
Contoh
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
Nomor pull request
PullRequestNumber
|
Pengenal unik untuk pull request yang terkait dengan item pengembangan. | ||
|
Deskripsi
Pull request (PR) adalah usulan untuk menggabungkan serangkaian perubahan kode ke cabang tertentu. Nomor pull request menghubungkan aktivitas pengembangan, seperti pengiriman kode dan peninjauan, dengan item pengembangan utama atau issue. ID ini penting untuk melacak integrasi kode dan subproses peninjauan dalam siklus pengembangan yang lebih luas. Anda dapat menganalisis proses peninjauan kode secara terperinci, termasuk durasi peninjauan, siklus pengerjaan ulang yang ditemukan saat peninjauan, dan tingkat penggabungan. ID ini menghubungkan tahap perencanaan (issue) dengan tahap penerapan (PR).
Mengapa ini penting
Menghubungkan issue dengan perubahan kode dan proses peninjauan terkait. Dengan begitu, Anda dapat menganalisis siklus peninjauan kode secara terperinci dan melihat dampaknya terhadap waktu penyelesaian secara keseluruhan.
Sumber data
Tersedia sebagai kolom 'number' dalam objek 'pull_request' pada banyak respons GitHub API, atau sebagai pengenal utama dari Pull Requests API.
Contoh
12345678910
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu yang menunjukkan kapan data untuk catatan ini terakhir diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu ekstraksi atau pembaruan data terbaru. Atribut ini memberikan informasi tentang seberapa baru data yang dianalisis. Data ini berbeda dari stempel waktu peristiwa, yang mencatat kapan peristiwa bisnis terjadi. Dalam analisis, kolom ini penting untuk mengetahui seberapa mutakhir tampilan proses. Kolom ini membantu pengguna mengetahui apakah data yang dilihat bersifat real-time atau merupakan rekaman dari waktu tertentu. Informasi ini penting untuk dasbor operasional dan pemantauan.
Mengapa ini penting
Menunjukkan seberapa baru data diperbarui. Informasi ini penting untuk memastikan analisis dan dasbor menggunakan data terkini.
Sumber data
Stempel waktu ini dibuat dan ditambahkan selama proses ekstraksi, transformasi, dan pemuatan data (ETL).
Contoh
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Pembuat
Author
|
Pengguna yang membuat issue, pull request, atau commit. | ||
|
Deskripsi
Pembuat adalah orang yang memulai suatu artefak dalam proses pengembangan. Misalnya, pembuat issue adalah orang yang melaporkan bug atau meminta fitur. Pembuat pull request adalah developer yang menulis kodenya. Dalam analisis, informasi pembuat dapat membantu Anda memahami sumber pekerjaan. Analisis pembuat laporan bug, misalnya, dapat menunjukkan pola yang terkait dengan tim atau fitur tertentu. Anda juga dapat menggabungkan informasi ini dengan penanggung jawab untuk menganalisis pola serah terima.
Mengapa ini penting
Menunjukkan siapa yang memulai suatu item pekerjaan atau perubahan kode. Informasi ini berguna untuk menganalisis sumber pengerjaan ulang, laporan bug, atau permintaan fitur.
Sumber data
Tersedia dalam objek 'user' di objek utama pada respons API untuk issue, pull request, dan commit. Nama kolomnya biasanya 'user.login'.
Contoh
sara.jonesmike.leeautomation-bot
|
|||
|
Peninjau
Reviewer
|
Pengguna yang diminta untuk meninjau kode pada pull request. | ||
|
Deskripsi
Peninjau adalah developer atau anggota tim yang ditugaskan untuk memeriksa kualitas, ketepatan, dan kesesuaian perubahan kode dengan standar dalam pull request. Satu pull request dapat memiliki beberapa peninjau. Atribut ini penting untuk menganalisis proses peninjauan kode. Anda dapat mengidentifikasi hambatan yang terkait dengan peninjau tertentu, memahami pembagian beban peninjauan, dan mengukur waktu respons peninjau terhadap permintaan. Atribut ini juga menjadi komponen utama dalam menghitung KPI 'Rata-rata Waktu Siklus Peninjauan Kode'.
Mengapa ini penting
Menunjukkan orang-orang yang terlibat dalam proses penjaminan kualitas. Informasi ini membantu menganalisis beban peninjauan, keterlambatan, dan efisiensi peninjauan kode secara keseluruhan.
Sumber data
Tersedia dalam array 'requested_reviewers' atau objek 'user' pada peristiwa peninjauan pull request dari GitHub API.
Contoh
alex.chenmaria.garciasenior-dev-team
|
|||
|
Sistem sumber
SourceSystem
|
Sistem tempat data proses pengembangan diambil. | ||
|
Deskripsi
Atribut ini menunjukkan asal data peristiwa. Untuk proses ini, nilainya akan selalu 'GitHub'. Dalam lingkungan yang lebih kompleks, saat aktivitas pengembangan berlangsung di beberapa sistem, misalnya Jira untuk perencanaan, GitHub untuk kode, dan Jenkins untuk penerapan, kolom ini membedakan sumber setiap peristiwa. Dalam analisis, atribut ini membantu menelusuri asal data untuk validasi dan pemecahan masalah. Atribut ini juga memungkinkan analisis proses yang melibatkan beberapa platform, dengan konteks yang jelas untuk setiap aktivitas.
Mengapa ini penting
Menunjukkan asal data. Informasi ini penting untuk validasi data dan analisis proses yang melibatkan beberapa sistem terintegrasi.
Sumber data
Biasanya, nilai statis ini ditambahkan saat proses ekstraksi, transformasi, dan pemuatan data (ETL) untuk menandai sumber catatan.
Contoh
GitHubGitHub Enterprise
|
|||
|
Status item
State
|
Status terkini issue atau pull request, seperti 'open', 'closed', atau 'merged'. | ||
|
Deskripsi
Atribut ini menunjukkan status umum item pengembangan. Status issue biasanya 'open' atau 'closed'. Status pull request mencakup 'open', 'closed', dan 'merged'. Informasi ini memberikan gambaran kemajuan item. Dalam analisis, status digunakan untuk membedakan pekerjaan yang masih berlangsung dari pekerjaan yang sudah selesai. Status ini penting untuk dasbor seperti 'Kemajuan Pengembangan Aktif' yang memantau pekerjaan berjalan. Status juga digunakan untuk menentukan akhir proses. Misalnya, status 'merged' atau 'closed' dapat menandai selesainya suatu kasus.
Mengapa ini penting
Menunjukkan dengan jelas apakah item pekerjaan sedang berlangsung atau sudah selesai. Informasi ini menjadi dasar analisis siklus hidup dan pemantauan pekerjaan aktif.
Sumber data
Tersedia langsung dalam kolom 'state' pada payload JSON untuk issue dan pull request dari GitHub API.
Contoh
openclosedmerged
|
|||
|
Status pemeriksaan CI
CiCheckStatus
|
Status pemeriksaan Continuous Integration (CI) otomatis, seperti 'berhasil' atau 'gagal'. | ||
|
Deskripsi
Atribut ini menunjukkan hasil build, pengujian, dan pemindaian otomatis pada perubahan kode dalam pull request. Pemeriksaan CI menjadi gerbang kualitas penting dalam alur kerja pengembangan modern. Analisis atribut ini membantu Anda memahami efektivitas pengujian otomatis. Tingkat kegagalan yang tinggi dapat menunjukkan masalah pada kestabilan kode, rangkaian pengujian, atau lingkungan pengembangan. Atribut ini mendukung aktivitas 'Pemeriksaan CI Berhasil' dan 'Pemeriksaan CI Gagal', serta membantu menganalisis keterlambatan akibat build yang gagal.
Mengapa ini penting
Menunjukkan keberhasilan atau kegagalan gerbang kualitas otomatis. Informasi ini memberi gambaran tentang kualitas kode dan efektivitas pipeline CI.
Sumber data
Diambil dari kolom 'state' atau 'conclusion' pada objek check run atau status melalui GitHub Checks API atau Statuses API.
Contoh
successfailurependingerror
|
|||
|
Status peninjauan
ReviewState
|
Hasil peninjauan kode pada pull request, seperti 'Disetujui' atau 'Perubahan diminta'. | ||
|
Deskripsi
Atribut ini mencatat keputusan peninjau. Status yang umum antara lain 'APPROVED', yang berarti kode siap digabungkan, dan 'CHANGES_REQUESTED', yang berarti kode perlu dikerjakan ulang. Status lainnya dapat berupa 'COMMENTED' atau 'PENDING'. Atribut ini penting untuk menganalisis pengerjaan ulang dan kualitas. Jika 'CHANGES_REQUESTED' sering muncul, kualitas kode awal mungkin bermasalah atau persyaratannya kurang jelas. Atribut ini mendukung dashboard 'Siklus Pengerjaan Ulang dan Regresi' dengan menunjukkan kapan item pengembangan dikembalikan untuk diperbaiki.
Mengapa ini penting
Menunjukkan secara langsung siklus pengerjaan ulang dan gerbang kualitas dalam proses peninjauan kode. Informasi ini membantu menemukan sumber inefisiensi dan masalah kualitas.
Sumber data
Tersedia dalam kolom 'state' pada objek peninjauan pull request dari GitHub API, misalnya dalam payload 'PullRequestReviewEvent'.
Contoh
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
Waktu siklus pengembangan
DevelopmentCycleTime
|
Total waktu sejak item pengembangan dibuat hingga akhirnya diterapkan atau ditutup. | ||
|
Deskripsi
Metrik tingkat kasus ini dihitung dari selisih waktu antara peristiwa pertama, misalnya 'Issue Dibuat', dan peristiwa terakhir, misalnya 'Penerapan Berhasil' atau 'Issue Ditutup', untuk satu item pengembangan. Metrik ini termasuk KPI terpenting untuk mengukur efisiensi proses pengembangan secara keseluruhan. Metrik ini mendukung dashboard 'Waktu Siklus Pengembangan Keseluruhan' dan KPI 'Rata-rata Waktu Siklus Pengembangan'. Mengurangi nilai metrik ini sering menjadi sasaran utama inisiatif perbaikan proses.
Mengapa ini penting
Menunjukkan waktu dari awal hingga produk tersedia di pasar untuk suatu item pengembangan. Karena itu, metrik ini menjadi KPI penting untuk mengukur kecepatan dan efisiensi proses secara keseluruhan.
Sumber data
Dihitung pada tingkat kasus dengan mengurangi stempel waktu aktivitas pertama dari stempel waktu aktivitas terakhir.
Contoh
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Waktu tunggu serah terima
HandoffWaitingTime
|
Waktu menganggur yang dihitung saat item pengembangan menunggu di antara aktivitas yang dilakukan oleh orang berbeda. | ||
|
Deskripsi
Metrik ini mengukur waktu antara selesainya satu aktivitas dan dimulainya aktivitas berikutnya, tetapi hanya jika penanggung jawabnya berubah. Contohnya, waktu antara peristiwa 'Peninjauan Diminta' dan 'Perubahan Diminta dalam Peninjauan' oleh pengguna yang berbeda. Metrik ini penting untuk menemukan kesenjangan komunikasi dan masalah koordinasi. Metrik ini mendukung dashboard 'Efisiensi Serah Terima Kritis' dan KPI 'Rata-rata Waktu Tunggu Serah Terima'. Waktu tunggu yang lama pada titik serah terima sering menunjukkan keterbatasan sumber daya atau proses notifikasi yang tidak efisien.
Mengapa ini penting
Menunjukkan keterlambatan akibat koordinasi yang buruk atau sumber daya yang tidak tersedia saat pekerjaan diserahterimakan antar tim atau peran. Hal ini sering menjadi sumber utama inefisiensi.
Sumber data
Dihitung dengan mencari aktivitas berurutan yang atribut 'Assignee' atau 'User'-nya berubah, lalu mengukur jeda waktu di antaranya.
Contoh
PT1H15MP2DT4HPT25M
|
|||
Aktivitas siklus pengembangan perangkat lunak
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Issue dibuat
|
Menandai awal siklus hidup item pengembangan, yaitu saat tugas, bug, atau permintaan fitur dibuat secara resmi. Peristiwa ini tercatat saat pengguna membuat issue baru di repositori GitHub. | ||
|
Mengapa ini penting
Ini adalah aktivitas awal utama dalam proses. Aktivitas ini penting untuk mengukur total waktu siklus pengembangan dan memahami sumber awal pekerjaan.
Sumber data
Peristiwa ini tercatat secara langsung dalam aliran peristiwa GitHub Issues API. Jenis peristiwanya biasanya 'opened' untuk nomor issue tertentu.
Pengumpulan data
Pantau peristiwa 'opened' pada issue melalui webhook atau polling API.
Jenis peristiwa
explicit
|
|||
|
Issue ditutup
|
Item pengembangan dianggap selesai dan issue terkait resmi ditutup. Penutupan dapat terjadi otomatis saat pull request yang terhubung digabungkan, atau dilakukan secara manual oleh anggota tim. | ||
|
Mengapa ini penting
Aktivitas ini menandai akhir proses untuk sebuah item pengembangan. Tahap ini penting untuk menghitung waktu siklus dari awal hingga akhir.
Sumber data
Peristiwa ini tercatat secara langsung dalam aliran peristiwa GitHub Issues API. Jenis peristiwanya adalah 'closed'.
Pengumpulan data
Pantau peristiwa 'closed' pada issue melalui webhook atau polling API.
Jenis peristiwa
explicit
|
|||
|
Pemeriksaan CI berhasil
|
Menandai keberhasilan pemeriksaan otomatis, seperti build, pengujian unit, atau analisis statis, pada kode dalam pull request. Peristiwa ini disimpulkan dari status pemeriksaan yang dilaporkan oleh sistem seperti GitHub Actions. | ||
|
Mengapa ini penting
Pemeriksaan kualitas otomatis ini penting untuk menjaga kestabilan kode. Kegagalan atau waktu proses yang lama dapat menjadi hambatan besar dalam alur rilis.
Sumber data
Disimpulkan dari GitHub Checks API atau Statuses API. Check run atau pembaruan status melaporkan 'success', atau 'completed' dengan hasil 'success'.
Pengumpulan data
Pantau Checks API untuk mengetahui hasil 'success' pada rangkaian pemeriksaan terkait.
Jenis peristiwa
inferred
|
|||
|
Pull request dibuka
|
Menandakan bahwa bagian awal kode siap ditinjau dan digabungkan. Developer membuat pull request (PR) untuk mengusulkan perubahan dari feature branch ke branch utama. Peristiwa ini tercatat secara langsung di GitHub. | ||
|
Mengapa ini penting
Ini adalah tonggak penting yang menandai berakhirnya tahap awal pengembangan dan dimulainya proses peninjauan serta integrasi. Tahap ini membantu menganalisis waktu siklus pengembangan dan peninjauan secara terpisah.
Sumber data
Data diperoleh dari aliran peristiwa GitHub Pull Request API atau webhook. Tindakan peristiwanya adalah 'opened'.
Pengumpulan data
Pantau tindakan 'opened' pada pull request melalui webhook atau polling API.
Jenis peristiwa
explicit
|
|||
|
Pull request digabungkan
|
Perubahan kode yang telah disetujui dalam pull request resmi digabungkan ke branch tujuan, seperti main atau develop. Ini adalah tindakan akhir pada pull request yang memasukkan kode baru. | ||
|
Mengapa ini penting
Ini adalah tonggak penting yang menandai selesainya pengembangan dan peninjauan. Bagi banyak tim, tahap ini menjadi langkah terakhir sebelum penerapan otomatis.
Sumber data
Data diperoleh dari aliran peristiwa GitHub Pull Request API atau webhook. Tindakan peristiwanya adalah 'closed', dan atribut 'merged' dalam payload pull request bernilai true.
Pengumpulan data
Pantau tindakan 'closed' pada pull request, lalu periksa apakah penanda 'merged' bernilai true.
Jenis peristiwa
explicit
|
|||
|
Pull request disetujui
|
Peninjau secara resmi menyetujui perubahan dalam pull request. Artinya, perubahan tersebut memenuhi standar kualitas dan fungsi. Peristiwa ini tercatat saat peninjau mengirimkan hasil peninjauan dengan status 'approve'. | ||
|
Mengapa ini penting
Ini adalah pemeriksaan kualitas penting dan tonggak utama sebelum penggabungan. Waktu dari pembuatan PR hingga tahap ini merupakan KPI penting untuk mengukur efisiensi proses peninjauan.
Sumber data
Data diperoleh dari GitHub Pull Request API atau webhook saat hasil peninjauan dikirim dengan status 'APPROVED'.
Pengumpulan data
Filter peristiwa pengiriman hasil peninjauan pull request berdasarkan status 'APPROVED'.
Jenis peristiwa
explicit
|
|||
|
Branch dibuat
|
Menandai dimulainya pekerjaan pengembangan aktif untuk sebuah issue, saat developer membuat branch baru dari basis kode utama. Peristiwa ini tercatat saat branch baru dikirim ke repositori. Nama branch sering kali mencantumkan nomor issue. | ||
|
Mengapa ini penting
Menandai peralihan dari perencanaan ke penulisan kode. Dengan mengukur waktu antara pembuatan issue dan peristiwa ini, Anda dapat menganalisis waktu yang dibutuhkan developer untuk mulai menangani pekerjaan serta keterlambatan awal dalam antrean pekerjaan.
Sumber data
Data diperoleh melalui GitHub Git API atau webhook yang memantau peristiwa 'create' bertipe 'branch'. Biasanya, nama branch perlu dikaitkan dengan issue melalui konvensi penamaan, seperti 'feature/issue-123'.
Pengumpulan data
Uraikan peristiwa webhook 'create' untuk branch baru, lalu kaitkan branch tersebut dengan issue.
Jenis peristiwa
explicit
|
|||
|
Issue dibuka kembali
|
Issue yang sebelumnya ditutup diaktifkan kembali, biasanya karena perbaikannya belum memadai atau ditemukan regresi. Peristiwa ini tercatat secara langsung dan memulai kembali siklus hidup item pengembangan. | ||
|
Mengapa ini penting
Peristiwa ini menandai siklus pengerjaan ulang yang signifikan, yang dapat menunjukkan adanya 'cacat produksi yang lolos' atau perbaikan yang belum tuntas. Frekuensinya menjadi salah satu ukuran penting kualitas perangkat lunak secara keseluruhan.
Sumber data
Peristiwa ini tercatat secara langsung dalam aliran peristiwa GitHub Issues API. Jenis peristiwanya adalah 'reopened'.
Pengumpulan data
Pantau peristiwa 'reopened' pada issue melalui webhook atau polling API.
Jenis peristiwa
explicit
|
|||
|
Kode dikirim ke PR
|
Menandai pembaruan kode yang diajukan untuk ditinjau, baik sebagai bagian dari PR awal maupun sebagai tanggapan atas masukan peninjau. Peristiwa ini tercatat setiap kali commit baru dikirim ke branch yang terkait dengan pull request terbuka. | ||
|
Mengapa ini penting
Melacak peristiwa ini penting untuk menemukan siklus pengerjaan ulang. Beberapa kali pengiriman kode setelah peninjauan menunjukkan bahwa perubahan diperlukan dan dapat memperpanjang waktu siklus secara keseluruhan.
Sumber data
Peristiwa ini tercatat secara langsung di linimasa pull request, biasanya dengan keterangan bahwa commit telah ditambahkan. Data dapat diperoleh dari webhook 'push' atau dengan memantau commit yang terkait dengan PR.
Pengumpulan data
Lacak peristiwa 'push' pada branch yang terkait dengan pull request terbuka.
Jenis peristiwa
explicit
|
|||
|
Pemeriksaan CI gagal
|
Menandai kegagalan pemeriksaan otomatis, seperti kesalahan build atau pengujian unit yang gagal, pada kode dalam pull request. Peristiwa ini disimpulkan dari status kegagalan yang dilaporkan oleh sistem seperti GitHub Actions. | ||
|
Mengapa ini penting
Aktivitas ini menyoroti masalah kualitas teknis yang perlu ditangani developer dan memicu siklus pengerjaan ulang. Analisis frekuensi kegagalan dapat membantu tim meningkatkan pengujian lokal atau kualitas kode.
Sumber data
Disimpulkan dari GitHub Checks API atau Statuses API. Check run atau pembaruan status melaporkan 'failure', atau 'completed' dengan hasil 'failure'.
Pengumpulan data
Pantau Checks API untuk mengetahui hasil 'failure' pada rangkaian pemeriksaan terkait.
Jenis peristiwa
inferred
|
|||
|
Penerapan berhasil
|
Perubahan kode berhasil diterapkan ke lingkungan tertentu, seperti staging atau produksi. Peristiwa ini biasanya tercatat melalui GitHub Deployments API, sering kali setelah GitHub Action dijalankan usai penggabungan. | ||
|
Mengapa ini penting
Menandai perpindahan kode dari repositori ke lingkungan aktif. Melacak tahap ini penting untuk mengukur keseluruhan waktu dari ide hingga produksi.
Sumber data
Data diperoleh melalui Deployments API. Layanan eksternal atau GitHub Action membuat penerapan, lalu memperbarui statusnya menjadi 'success'.
Pengumpulan data
Pantau peristiwa status penerapan melalui webhook untuk mengetahui status 'success'.
Jenis peristiwa
inferred
|
|||
|
Peninjauan diminta
|
Pembuat pull request secara resmi meminta anggota atau tim tertentu untuk meninjau kode. Tindakan ini dilakukan melalui antarmuka atau API GitHub dan mengirimkan notifikasi kepada peninjau yang diminta. | ||
|
Mengapa ini penting
Aktivitas ini menandai dimulainya proses serah terima untuk peninjauan kode. Waktu antara permintaan ini dan pengiriman hasil peninjauan membantu mengukur kecepatan tanggapan peninjau serta menemukan potensi hambatan.
Sumber data
Data diperoleh dari aliran peristiwa GitHub Pull Request API atau webhook. Tindakan peristiwanya adalah 'review_requested'.
Pengumpulan data
Pantau tindakan 'review_requested' pada pull request.
Jenis peristiwa
explicit
|
|||
|
Perubahan diminta dalam peninjauan
|
Peninjau telah menyelesaikan peninjauan kode dan memutuskan bahwa perubahan perlu dilakukan sebelum pull request dapat disetujui. Peninjau mengirimkan hasil peninjauan secara resmi dengan status 'request_changes'. | ||
|
Mengapa ini penting
Peristiwa ini secara langsung menandai siklus pengerjaan ulang. Dengan menganalisis frekuensinya, tim dapat menemukan masalah kualitas, persyaratan yang kurang jelas, atau kebutuhan pelatihan developer.
Sumber data
Data diperoleh dari GitHub Pull Request API atau webhook saat hasil peninjauan dikirim dengan status 'CHANGES_REQUESTED'.
Pengumpulan data
Filter peristiwa pengiriman hasil peninjauan pull request berdasarkan status 'CHANGES_REQUESTED'.
Jenis peristiwa
explicit
|
|||
Panduan ekstraksi
Siap memulai?
Gunakan templat ini untuk menyiapkan data dan mulai mengoptimalkan siklus pengembangan perangkat lunak Anda. Temukan inefisiensi dan wujudkan rilis yang lebih cepat dan lancar.
Tingkatkan SDLC: temukan inefisiensi dengan cepat
Kurangi waktu siklus hingga 30% dan sederhanakan proses pengembangan GitHub Anda.
Tidak perlu kartu kredit. Siapkan dalam hitungan menit.