Template data siklus hidup pengembangan perangkat lunak Anda

Azure DevOps
Template data siklus hidup pengembangan perangkat lunak Anda

Template data siklus hidup pengembangan perangkat lunak Anda

Template ini memandu Anda menyiapkan data siklus hidup pengembangan perangkat lunak untuk process mining. Di dalamnya tercantum atribut data penting yang perlu dikumpulkan, aktivitas utama yang perlu dilacak, serta panduan praktis untuk mengambil data tersebut dari Azure DevOps. Gunakan panduan ini agar data tersusun dengan baik untuk analisis dan perbaikan proses.
  • Atribut yang disarankan untuk dikumpulkan
  • Aktivitas utama yang perlu dilacak dalam SDLC Anda
  • Panduan terperinci untuk mengambil data dari Azure DevOps
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut siklus hidup pengembangan perangkat lunak

Berikut adalah kolom data yang disarankan untuk log peristiwa agar Anda dapat menganalisis dan mengoptimalkan siklus hidup pengembangan perangkat lunak.
5 Wajib 7 Disarankan 6 Opsional
Nama Deskripsi
Development Item
DevelopmentItem
Pengenal unik untuk satu unit pekerjaan, seperti fitur, bug, atau user story, yang berfungsi sebagai ID kasus dalam proses.
Deskripsi

Development Item adalah bagian pekerjaan tersendiri yang dilacak di Azure DevOps. Setiap item memiliki ID unik dan menjadi objek utama yang menghubungkan seluruh aktivitas proses, mulai dari pembuatan dan perencanaan hingga pengembangan, pengujian, dan penerapan.

Dalam analisis process mining, atribut ini menjadi dasar untuk menghubungkan semua peristiwa terkait ke dalam satu perjalanan kasus. Dengan begitu, Anda dapat merekonstruksi siklus lengkap setiap work item dan menganalisis waktu siklus, penyimpangan proses, serta siklus pengerjaan ulang untuk tiap item.

Mengapa ini penting

Pengenal utama ini menghubungkan semua langkah proses dalam satu kasus, sehingga analisis siklus pengembangan perangkat lunak dari awal hingga akhir dapat dilakukan.

Sumber data

Atribut ini sesuai dengan kolom 'ID' pada Work Item di Azure DevOps Boards. Anda dapat mengaksesnya melalui Azure DevOps REST API untuk Work Item Tracking.

Contoh
10234102351023610237
Nama aktivitas
ActivityName
Nama peristiwa atau tugas tertentu yang terjadi pada suatu waktu dalam siklus pengembangan untuk sebuah item kerja.
Deskripsi

Nama aktivitas menjelaskan langkah atau tahap tertentu dalam proses, seperti 'Development Started', 'Pull Request Created', atau 'Deployed to Production'. Aktivitas ini berasal dari perubahan status work item, peristiwa tertaut seperti build atau pull request, maupun peristiwa khusus.

Atribut ini penting untuk menyusun peta proses yang menampilkan alur kerja secara visual. Analis dapat memahami urutan peristiwa, menemukan jalur yang umum, mengidentifikasi hambatan di antara aktivitas tertentu, dan menganalisis frekuensi setiap langkah.

Mengapa ini penting

Atribut ini menentukan langkah-langkah dalam proses dan menjadi dasar peta proses. Dengan begitu, Anda dapat menganalisis alur kerja, hambatan, dan penyimpangan.

Sumber data

Biasanya, atribut ini berasal dari perubahan kolom 'State' pada work item atau dari peristiwa tertaut seperti build, commit, dan pull request. Work Item History menyediakan data mentah untuk peristiwa tersebut.

Contoh
Pengembangan dimulaiPull Request selesaiPengujian QA gagalDiterapkan ke produksiWork Item ditutup
Waktu peristiwa
EventTime
Stempel waktu yang menunjukkan dengan tepat kapan aktivitas atau peristiwa tertentu terjadi pada Development Item.
Deskripsi

Waktu peristiwa mencatat tanggal dan waktu setiap aktivitas dalam siklus pengembangan. Stempel waktu ini menjadi dasar untuk mengurutkan peristiwa secara kronologis dan menghitung durasi di antaranya.

Dalam analisis, atribut ini penting untuk menghitung semua metrik berbasis waktu, termasuk waktu siklus, waktu pemrosesan, dan waktu tunggu. Atribut ini memungkinkan pembuatan log peristiwa yang diurutkan berdasarkan waktu, sebagai masukan wajib untuk analisis process mining. Data ini digunakan untuk mencari penyebab keterlambatan, mengukur kinerja terhadap SLA, dan melacak tren dari waktu ke waktu.

Mengapa ini penting

Stempel waktu ini menunjukkan urutan kronologis peristiwa. Informasi ini penting untuk menghitung semua KPI berbasis durasi serta memahami alur proses dan hambatan.

Sumber data

Ini adalah 'Changed Date' yang terkait dengan setiap pembaruan dalam riwayat work item. Untuk peristiwa eksternal seperti build atau penerapan, gunakan stempel waktu saat peristiwa tersebut selesai.

Contoh
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Pembaruan data terakhir
LastDataUpdate
Stempel waktu yang menunjukkan kapan terakhir kali data proses ini diperbarui dari sistem sumber.
Deskripsi

Atribut ini mencatat waktu terakhir kumpulan data diekstrak dan diperbarui dari Azure DevOps. Informasi ini menunjukkan seberapa baru data tersebut dan rentang waktu yang dicakup oleh analisis.

Dalam analisis proses, mengetahui kebaruan data penting untuk mengambil keputusan berdasarkan informasi yang tepat. Stempel waktu ini membantu pengguna memahami apakah data yang dilihat merupakan informasi terkini atau rekam historis, yang memengaruhi relevansi temuan.

Mengapa ini penting

Atribut ini memberi tahu pengguna seberapa baru data yang digunakan, sehingga analisis dan keputusan dibuat dengan memahami rentang waktunya.

Sumber data

Ini adalah stempel waktu metadata yang dibuat dan disimpan selama proses ekstraksi, transformasi, dan pemuatan data (ETL).

Contoh
2024-05-20T08:00:00Z
Sistem sumber
SourceSystem
Sistem tempat data proses diekstrak, dalam hal ini Azure DevOps.
Deskripsi

Atribut ini menunjukkan sistem asal data. Atribut ini sangat berguna jika data dari beberapa sistem digabungkan untuk memberikan gambaran proses yang lebih luas. Untuk model ini, nilainya selalu Azure DevOps.

Dalam analisis yang hanya menggunakan satu sistem, nilainya mungkin tampak tetap. Namun, informasi ini tetap penting untuk tata kelola data, pemecahan masalah, dan integrasi mendatang dengan sistem lain seperti ServiceNow atau SAP.

Mengapa ini penting

Atribut ini memberikan konteks penting tentang asal data, yang berguna untuk tata kelola data, validasi, dan analisis proses lintas sistem.

Sumber data

Nilainya tetap dan perlu ditambahkan saat ekstraksi serta transformasi data untuk memberi label pada kumpulan data.

Contoh
Azure DevOps
Ditugaskan kepada
AssignedTo
Pengguna atau anggota tim yang saat ini bertanggung jawab atas Development Item.
Deskripsi

Atribut ini menunjukkan orang yang bertanggung jawab atas work item pada tahap tertentu dalam proses. Penugasan dapat berubah beberapa kali selama siklus item, misalnya dari developer ke penguji, lalu ke manajer rilis.

Analisis berdasarkan 'Assigned To' penting untuk dashboard Developer and Tester Workload Overview. Analisis ini membantu memahami alokasi sumber daya, menemukan anggota tim yang kelebihan beban, dan membandingkan kinerja individu atau tim.

Mengapa ini penting

Atribut ini memungkinkan analisis berdasarkan sumber daya, sehingga Anda dapat memahami pembagian beban kerja, menemukan hambatan terkait sumber daya tertentu, dan mengelola kapasitas tim.

Sumber data

Atribut ini sesuai dengan kolom 'Assigned To' pada Work Item di Azure DevOps. Nilainya diambil dari riwayat work item untuk setiap peristiwa.

Contoh
jane.doe@example.comjohn.smith@example.combelum ditugaskan
Jenis Work Item
WorkItemType
Klasifikasi Development Item, seperti Bug, Feature, User Story, atau Task.
Deskripsi

Jenis Work Item mengelompokkan pekerjaan yang dilakukan. Jenis work item yang berbeda sering mengikuti jalur proses dan memiliki target kinerja atau SLA yang berbeda. Misalnya, Bug mungkin mengikuti jalur yang lebih cepat daripada Feature.

Atribut ini penting untuk analisis perbandingan. Anda dapat memfilter peta proses atau KPI berdasarkan jenis pekerjaan untuk mengetahui apakah proses tertentu lebih efisien untuk Bug dibandingkan Feature, atau melacak tren waktu siklus historis untuk berbagai kategori pekerjaan.

Mengapa ini penting

Atribut ini memungkinkan analisis proses dipilah berdasarkan kategori pekerjaan, sehingga Anda dapat membandingkan alur kerja dan kinerja, misalnya untuk Bug dan Feature.

Sumber data

Atribut ini sesuai dengan kolom 'Work Item Type' pada Work Item di Azure DevOps.

Contoh
BugFiturUser StoryTugas
Mengalami pengerjaan ulang
IsRework
Penanda boolean yang menunjukkan apakah item pengembangan kembali ke tahap sebelumnya dalam siklus hidupnya.
Deskripsi

Penanda ini bernilai true jika item kerja mengalami siklus pengerjaan ulang, misalnya berpindah dari 'Pengujian QA Selesai' kembali ke 'Pengembangan Dimulai'. Nilainya dihitung dengan menganalisis urutan aktivitas dalam suatu kasus dan mendeteksi alur yang tidak linear.

Atribut ini penting untuk dasbor Frekuensi Pengerjaan Ulang dan Pengujian Ulang serta KPI Frekuensi Siklus Pengerjaan Ulang. Anda dapat memfilter dan menghitung pengerjaan ulang dengan mudah untuk menemukan masalah kualitas, kesenjangan komunikasi, atau pengujian yang kurang memadai sehingga proses menjadi tidak efisien.

Mengapa ini penting

Atribut ini menunjukkan dan menghitung pengerjaan ulang secara langsung, sehingga Anda dapat menemukan masalah kualitas dan ketidakefisienan proses yang memperpanjang waktu siklus.

Sumber data

Atribut ini dihitung dengan menganalisis urutan aktivitas dalam log peristiwa untuk setiap kasus.

Contoh
truefalse
Nama tim
TeamName
Nama tim pengembangan yang bertanggung jawab atas item kerja.
Deskripsi

Nama Tim menunjukkan tim tertentu yang menerima penugasan item kerja. Di Azure DevOps, pekerjaan sering diatur berdasarkan tim, yang bisa menjadi bagian dari proyek yang lebih besar.

Atribut ini memungkinkan Anda menganalisis proses berdasarkan tim. Anda dapat membandingkan proses dan kinerja antar-tim, menemukan praktik baik dari tim berkinerja tinggi, serta mengetahui tim mana yang memerlukan dukungan atau perbaikan proses.

Mengapa ini penting

Atribut ini memungkinkan Anda membandingkan kinerja antar-tim, menemukan perbedaan kinerja, dan berbagi praktik baik di seluruh organisasi.

Sumber data

Nilai ini biasanya diambil dari 'Area Path' item kerja, karena tim di Azure DevOps umumnya dipetakan ke area path tertentu.

Contoh
Tim PhoenixSkuad OmegaInti PlatformTim Frontend
Prioritas
Priority
Peringkat angka atau deskripsi yang menunjukkan tingkat kepentingan item pengembangan dibandingkan item lainnya.
Deskripsi

Prioritas menunjukkan seberapa penting suatu item kerja dalam penjadwalan. Item dengan prioritas lebih tinggi perlu ditangani lebih cepat daripada item berprioritas rendah. Nilai yang umum digunakan berupa angka, seperti 1, 2, 3, dan 4. Angka 1 menunjukkan prioritas tertinggi.

Atribut ini penting untuk dasbor Throughput dan Waktu Siklus Berdasarkan Prioritas. Analisis data dengan atribut ini membantu Anda menilai efektivitas sistem prioritas, yaitu apakah item berprioritas tinggi benar-benar melewati proses lebih cepat daripada item berprioritas rendah.

Mengapa ini penting

Atribut ini membantu Anda menilai apakah proses mempercepat penanganan item berprioritas tinggi. Hal ini penting untuk mengevaluasi keberhasilan strategi penentuan prioritas.

Sumber data

Atribut ini sesuai dengan kolom 'Priority' pada Work Item di Azure DevOps.

Contoh
1234
Status
State
Status terkini item pengembangan dalam alur kerjanya, seperti 'Baru', 'Aktif', 'Terselesaikan', atau 'Ditutup'.
Deskripsi

Atribut State menunjukkan status resmi item kerja pada waktu tertentu, sesuai templat proses proyek. Perubahan status menjadi sumber utama untuk menghasilkan aktivitas dalam log peristiwa.

Atribut 'Activity' biasanya menjelaskan perubahan status dengan lebih terperinci, sedangkan atribut mentah 'State' berguna untuk pemfilteran dan analisis. Atribut ini membantu Anda memahami berapa lama item berada dalam status tertentu, serta menjadi dasar untuk membuat dashboard Durasi Tahap dan menganalisis serah terima.

Mengapa ini penting

Atribut ini menunjukkan status item kerja dalam siklus hidupnya. Informasi ini penting untuk memahami alur proses dan menghitung waktu yang dihabiskan di setiap tahap.

Sumber data

Atribut ini sesuai dengan kolom 'State' pada Work Item di Azure DevOps.

Contoh
BaruAktifDalam QATerselesaikanDitutup
Waktu selesai
EndTime
Stempel waktu yang menunjukkan kapan suatu aktivitas selesai. Data ini digunakan untuk menghitung waktu pemrosesan aktivitas.
Deskripsi

Waktu Akhir menandai selesainya suatu aktivitas. Dalam banyak log peristiwa, waktu mulai aktivitas berikutnya digunakan sebagai waktu akhir aktivitas sebelumnya. Namun, pencatatan waktu akhir secara terpisah memungkinkan perhitungan waktu pemrosesan aktivitas dan waktu jeda antaraktivitas yang lebih akurat.

Atribut ini penting untuk menghitung KPI Waktu pemrosesan dan melakukan analisis hambatan secara terperinci. Atribut ini membantu membedakan waktu yang digunakan untuk mengerjakan tugas secara aktif dari waktu tunggu sebelum langkah berikutnya dimulai. Perbedaan ini penting untuk dashboard Analisis Serah Terima Tahap.

Mengapa ini penting

Atribut ini memungkinkan penghitungan waktu pemrosesan aktivitas dan waktu jeda secara akurat, yang menjadi dasar analisis hambatan dan peningkatan efisiensi.

Sumber data

Nilai ini sering kali diturunkan dari data lain. Nilainya dapat berupa waktu mulai peristiwa berikutnya untuk kasus yang sama, atau tercatat secara langsung jika sistem sumber menyimpan waktu mulai dan waktu akhir tugas.

Contoh
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
ID Pull Request
PullRequestId
ID pull request yang terhubung dengan item pengembangan.
Deskripsi

Atribut ini menghubungkan item kerja dengan pull request tertentu, yaitu mekanisme untuk mengajukan dan meninjau perubahan kode. Satu item kerja dapat terkait dengan beberapa pull request.

ID Pull Request memungkinkan analisis yang lebih terperinci atas proses peninjauan dan integrasi kode. Anda dapat mengukur waktu dari pembuatan hingga penyelesaian pull request, serta menganalisis seberapa sering pull request ditolak atau memerlukan perubahan besar. Hal ini dapat menunjukkan kualitas kode atau kejelasan persyaratan.

Mengapa ini penting

Atribut ini menghubungkan pekerjaan pengembangan dengan aktivitas peninjauan kode tertentu, sehingga Anda dapat menganalisis proses integrasi kode dan penjaminan kualitas secara terperinci.

Sumber data

Informasi ini tersedia di bagian 'Links' atau 'Development' pada item kerja di Azure DevOps.

Contoh
452145334589
Jalur iterasi
IterationPath
Sprint pengembangan atau periode kerja berbatas waktu yang menjadi tempat penugasan item kerja.
Deskripsi

Jalur Iterasi, atau sprint, menunjukkan periode pengembangan tertentu dengan batas waktu yang jelas. Item kerja ditugaskan ke suatu iterasi untuk diselesaikan dalam periode tersebut.

Analisis berdasarkan Jalur Iterasi membantu Anda memahami kinerja proses dari satu sprint ke sprint berikutnya. Anda dapat melacak perubahan waktu siklus, menganalisis pekerjaan yang terbawa ke sprint berikutnya, dan menilai seberapa akurat perencanaan sprint.

Mengapa ini penting

Atribut ini memungkinkan analisis berdasarkan sprint, sehingga tim dapat mengevaluasi kinerja dari waktu ke waktu dan memperbaiki praktik agile.

Sumber data

Atribut ini sesuai dengan kolom 'Iteration Path' pada Work Item di Azure DevOps.

Contoh
Platform E-Commerce\Sprint 12Platform E-Commerce\Sprint 13Peluncuran Ulang Aplikasi Seluler\Fase 2\Sprint 4
Nama proyek
ProjectName
Nama proyek Azure DevOps tempat item pengembangan berada.
Deskripsi

Atribut ini menunjukkan proyek tertentu dalam organisasi Azure DevOps tempat item kerja berada. Atribut ini memberikan konteks tingkat tinggi, terutama bagi organisasi yang memiliki banyak proyek.

Nama Proyek menjadi dimensi penting untuk pemfilteran dan perbandingan. Atribut ini mendukung dasbor Tren Waktu Siklus Historis dengan memungkinkan analisis berdasarkan proyek. Anda dapat melihat apakah suatu proyek lebih atau kurang efisien dibandingkan proyek lain, atau apakah perbaikan proses di satu proyek memberikan dampak positif.

Mengapa ini penting

Atribut ini mengelompokkan data untuk analisis tingkat tinggi, sehingga Anda dapat membandingkan kinerja dan tren antarproyek.

Sumber data

Atribut ini sesuai dengan kolom 'Team Project' pada Work Item di Azure DevOps.

Contoh
Platform E-CommercePeluncuran Ulang Aplikasi SelulerModernisasi Gudang Data
Tingkat keparahan
Severity
Menunjukkan dampak bug atau masalah terhadap sistem atau pengguna akhir.
Deskripsi

Tingkat keparahan digunakan untuk mengelompokkan dampak bug, mulai dari kegagalan sistem yang kritis hingga masalah tampilan kecil. Tingkat keparahan berbeda dari prioritas, yang menentukan urutan pekerjaan. Bug dengan tingkat keparahan tinggi bisa saja berprioritas rendah jika tersedia solusi sementara yang mudah.

Atribut ini menambah dimensi analisis, khususnya untuk dasbor Throughput dan Waktu Siklus Berdasarkan Prioritas. Anda dapat menggunakannya untuk menjawab pertanyaan seperti, 'Apakah kami memperbaiki bug paling kritis terlebih dahulu?' Atribut ini juga membantu memahami tingkat risiko pekerjaan yang sedang diproses.

Mengapa ini penting

Atribut ini membantu mengelompokkan item kerja berdasarkan dampaknya terhadap bisnis, sehingga Anda dapat menilai seberapa efektif tim menangani masalah berdampak besar.

Sumber data

Atribut ini sesuai dengan kolom 'Severity' pada Work Item di Azure DevOps, biasanya untuk bug.

Contoh
1 - Kritis2 - Tinggi3 - Sedang4 - Rendah
Waktu serah terima tahap
StageHandoffTime
Durasi waktu tunggu antara selesainya satu tahap utama dan dimulainya tahap berikutnya.
Deskripsi

Waktu Serah Terima Tahap mengukur waktu tunggu antara tahap-tahap proses yang berurutan, misalnya waktu antara 'Pengembangan Selesai' dan 'Pengujian QA Dimulai'. Nilainya dihitung dengan menemukan transisi penting tersebut, lalu mengukur jeda antara berakhirnya aktivitas pertama dan dimulainya aktivitas kedua.

Metrik ini menjadi fokus dasbor Durasi Tahap dan Analisis Serah Terima. Mengukur waktu serah terima secara terpisah penting untuk menemukan hambatan tersembunyi saat pekerjaan menganggur, sering kali karena sumber daya tidak tersedia, komunikasi terlambat, atau proses yang tidak efisien.

Mengapa ini penting

Atribut ini menghitung waktu tunggu antar-tahap proses, sehingga hambatan tersembunyi dan keterlambatan di luar pekerjaan aktif terlihat jelas.

Sumber data

Atribut ini dihitung dengan menemukan pasangan aktivitas berurutan yang menandai serah terima, lalu menghitung selisih waktunya.

Contoh
2 jam 15 menit1 hari 4 jam0 jam 30 menit
Waktu tunggu persetujuan
ApprovalWaitingTime
Waktu yang dihabiskan item pengembangan untuk menunggu persetujuan setelah permintaan diajukan.
Deskripsi

Metrik ini mengukur durasi waktu tunggu saat item kerja menanti persetujuan. Contohnya, waktu antara 'UAT Dimulai' dan 'UAT Disetujui'. Nilainya dihitung dengan mengukur selisih waktu antara kedua aktivitas tersebut dalam suatu kasus.

Atribut hasil perhitungan ini mendukung dasbor Analisis Waktu Tunggu Persetujuan dan KPI terkait. Dengan mengukur keterlambatan ini secara terpisah, tim dapat memperbaiki komunikasi dan pengambilan keputusan untuk mengurangi waktu menganggur dan mempercepat siklus kerja secara keseluruhan.

Mengapa ini penting

Atribut ini mengukur keterlambatan akibat menunggu keputusan atau persetujuan, sehingga peluang untuk memperbaiki komunikasi dan pengambilan keputusan terlihat jelas.

Sumber data

Nilainya dihitung dengan menemukan aktivitas awal dan akhir persetujuan tertentu dalam log peristiwa, misalnya 'UAT Dimulai' dan 'UAT Disetujui', lalu menghitung selisih waktunya.

Contoh
3 hari 2 jam1 hari 8 jam 30 menit4 jam
Wajib Disarankan Opsional

Aktivitas siklus hidup pengembangan perangkat lunak

Berikut adalah langkah dan milestone proses utama yang perlu dicatat dalam log peristiwa untuk menemukan proses dan mengidentifikasi hambatan secara akurat.
7 Disarankan 8 Opsional
Aktivitas Deskripsi
Diterapkan ke produksi
Menandai keberhasilan penerapan kode yang terkait dengan work item ke lingkungan produksi. Peristiwa ini tercatat secara eksplisit dalam log rilis Azure Pipelines.
Mengapa ini penting

Ini adalah tahap penting yang menandai penyampaian nilai. Tahap ini menjadi titik akhir untuk menghitung lead time dan waktu siklus.

Sumber data

Diambil dari data pipeline rilis Azure Pipelines, khususnya peristiwa penyelesaian penerapan ke tahap 'Production' yang ditautkan ke work item.

Pengumpulan data

Diambil dari peristiwa penyelesaian penerapan di pipeline rilis.

Jenis peristiwa explicit
Pengembangan dimulai
Aktivitas ini menandakan bahwa developer mulai mengerjakan item secara aktif. Peristiwa ini disimpulkan dari perubahan status work item menjadi 'Active', 'In Progress', atau 'Committed'.
Mengapa ini penting

Menandai awal tahap pengembangan aktif. Analisis waktu dari 'Created' hingga 'Development Started' menunjukkan lamanya antrean backlog.

Sumber data

Disimpulkan dari riwayat work item saat kolom System.State berubah dari 'New' atau 'Approved' menjadi 'In Progress'.

Pengumpulan data

Disimpulkan dari perubahan kolom State menjadi 'Active' atau 'In Progress'.

Jenis peristiwa inferred
Pengujian QA dimulai
Menandai awal tahap pengujian quality assurance formal. Aktivitas ini disimpulkan saat status work item berubah menjadi 'In QA', 'Testing', atau nilai serupa.
Mengapa ini penting

Menandai awal siklus QA. Menganalisis durasi tahap ini penting untuk memahami hambatan dan efisiensi pengujian.

Sumber data

Disimpulkan dari riwayat work item dengan melacak perubahan kolom System.State menjadi 'In QA' atau status pengujian lain yang ditetapkan.

Pengumpulan data

Disimpulkan dari perubahan kolom State menjadi 'In QA' atau 'Testing'.

Jenis peristiwa inferred
Pull Request dibuat
Menandakan developer telah menyelesaikan penulisan kode awal dan mengirimkan perubahan untuk ditinjau melalui pull request. Peristiwa ini menghubungkan work item dengan perubahan kode tertentu di Azure Repos.
Mengapa ini penting

Ini adalah serah terima penting dari pengembangan ke peninjauan kode. Pelacakan ini membantu mengukur durasi penulisan kode dan mengetahui kapan kode siap ditinjau oleh rekan kerja.

Sumber data

Diambil dari data Azure Repos dengan menghubungkan peristiwa pembuatan pull request ke work item terkait. Biasanya, developer membuat tautan ini secara langsung.

Pengumpulan data

Diambil dari peristiwa pembuatan pull request di Azure Repos yang ditautkan ke work item.

Jenis peristiwa explicit
Pull Request selesai
Menandai peninjauan kode yang berhasil diselesaikan, saat pull request disetujui dan kode digabungkan ke cabang tujuan. Peristiwa ini tercatat secara eksplisit di Azure Repos.
Mengapa ini penting

Menandai akhir tahap peninjauan kode, yang sering menjadi hambatan. Analisis waktu antara pembuatan dan penyelesaian PR menunjukkan efisiensi siklus peninjauan.

Sumber data

Diambil dari peristiwa penyelesaian atau penggabungan pull request di Azure Repos yang ditautkan ke work item.

Pengumpulan data

Diambil dari peristiwa penggabungan pull request yang ditautkan ke work item.

Jenis peristiwa explicit
UAT disetujui
Aktivitas ini menandakan pemangku kepentingan bisnis menyetujui perubahan setelah User Acceptance Testing. Biasanya, peristiwa ini disimpulkan dari perubahan status 'In UAT' menjadi 'UAT Approved' atau 'Ready for Release'.
Mengapa ini penting

Ini adalah tahap persetujuan penting yang memastikan work item memenuhi persyaratan bisnis dan siap diterapkan ke lingkungan produksi.

Sumber data

Disimpulkan dari riwayat work item dengan mendeteksi perubahan kolom System.State dari status UAT menjadi status yang disetujui atau siap dirilis.

Pengumpulan data

Disimpulkan dari perubahan kolom State dari 'In UAT' menjadi 'Ready for Release'.

Jenis peristiwa inferred
Work Item dibuat
Aktivitas ini menandai awal siklus pengembangan, yaitu saat item kerja baru seperti User Story, Bug, atau Task dibuat. Aktivitas ini tercatat secara eksplisit saat rekaman baru disimpan di Azure DevOps Boards.
Mengapa ini penting

Ini adalah peristiwa awal utama dalam proses. Data ini penting untuk mengukur waktu siklus pengembangan dari awal hingga akhir dan memahami sumber awal pekerjaan.

Sumber data

Peristiwa ini diambil dari kolom 'Created Date' pada work item. Tabel riwayat work item juga mencatat transisi status awal ini.

Pengumpulan data

Diambil dari kolom 'Created Date' pada work item.

Jenis peristiwa explicit
Build berhasil
Aktivitas ini memastikan kode sumber, termasuk perubahan baru, berhasil dikompilasi dan dikemas oleh pipeline build. Azure Pipelines mencatat peristiwa ini secara eksplisit.
Mengapa ini penting

Berfungsi sebagai quality gate penting untuk memastikan kode baru terintegrasi dengan benar tanpa merusak build. Kegagalan pada tahap ini dapat menunjukkan masalah integrasi.

Sumber data

Diambil dari peristiwa penyelesaian build di Azure Pipelines. Build harus ditautkan ke work item, baik secara langsung maupun melalui pull request terkait.

Pengumpulan data

Diambil dari peristiwa penyelesaian build di Azure Pipelines.

Jenis peristiwa explicit
Pengembangan selesai
Menandakan semua aktivitas pengembangan dan pengujian unit telah selesai, dan item siap menjalani pengujian formal. Biasanya, peristiwa ini disimpulkan dari perubahan status work item menjadi 'Resolved' atau 'Ready for Test'.
Mengapa ini penting

Menandai serah terima penting dari tim pengembangan ke tim QA. Mengukur waktu hingga 'QA Testing Started' membantu menemukan keterlambatan serah terima.

Sumber data

Disimpulkan dari riwayat work item saat kolom System.State berubah menjadi nilai seperti 'Resolved' atau status khusus yang menandakan kesiapan untuk QA.

Pengumpulan data

Disimpulkan dari perubahan kolom State menjadi 'Resolved'.

Jenis peristiwa inferred
Pengujian QA gagal
Menandakan work item gagal dalam pengujian quality assurance dan dikembalikan ke tahap pengembangan. Peristiwa ini tercatat saat status berubah dari status pengujian kembali menjadi 'In Progress' atau 'Active'.
Mengapa ini penting

Aktivitas ini penting untuk menemukan siklus pengerjaan ulang. Jika peristiwa ini sering terjadi, mungkin ada masalah pada kualitas kode, persyaratan, atau proses pengujian.

Sumber data

Disimpulkan dari riwayat work item dengan mendeteksi transisi dari status seperti 'In QA' kembali ke status seperti 'Active' atau 'In Progress'.

Pengumpulan data

Disimpulkan dari perubahan kolom State dari 'In QA' kembali menjadi 'Active'.

Jenis peristiwa inferred
Pengujian QA selesai
Menandai keberhasilan penyelesaian tahap quality assurance. Peristiwa ini disimpulkan saat status work item berubah dari status pengujian menjadi status seperti 'Ready for UAT' atau 'QA Approved'.
Mengapa ini penting

Ini adalah quality gate penting yang menandakan item siap untuk pengujian penerimaan pengguna atau rilis. Keterlambatan setelah tahap ini dapat menunjukkan hambatan dalam UAT atau perencanaan rilis.

Sumber data

Disimpulkan dari riwayat work item saat kolom System.State berubah dari 'In QA' ke status berikutnya seperti 'Ready for UAT' atau 'Done'.

Pengumpulan data

Disimpulkan dari perubahan kolom State dari 'In QA' menjadi 'Ready for UAT'.

Jenis peristiwa inferred
UAT dimulai
Menandai awal User Acceptance Testing, saat pemangku kepentingan bisnis memvalidasi fungsi yang tersedia. Biasanya, peristiwa ini disimpulkan dari perubahan status menjadi 'In UAT' atau status serupa.
Mengapa ini penting

Mengukur awal validasi akhir sebelum rilis. Durasi UAT dan waktu tunggu persetujuan penting dianalisis untuk memperbaiki proses.

Sumber data

Disimpulkan dari riwayat work item saat kolom System.State diperbarui ke status khusus yang menandakan UAT, seperti 'In UAT'.

Pengumpulan data

Disimpulkan dari perubahan kolom State menjadi 'In UAT'.

Jenis peristiwa inferred
Work Item dibatalkan
Menandakan work item dibatalkan dan tidak akan diselesaikan atau diterapkan. Peristiwa ini tercatat saat status berubah menjadi 'Removed', 'Cancelled', atau status serupa.
Mengapa ini penting

Ini menandai akhir proses alternatif yang tidak berhasil. Analisis item yang dibatalkan dapat mengungkap masalah dalam perencanaan, penentuan prioritas, atau perumusan persyaratan.

Sumber data

Disimpulkan dari riwayat work item saat kolom System.State berubah menjadi status akhir dalam kategori 'Removed'.

Pengumpulan data

Disimpulkan dari perubahan kolom State menjadi 'Removed' atau 'Cancelled'.

Jenis peristiwa inferred
Work Item disetujui
Menandai persetujuan resmi atas work item, yang memastikan definisinya sudah jelas dan siap dikembangkan. Biasanya, peristiwa ini disimpulkan dari perubahan kolom 'State' menjadi nilai seperti 'Approved' atau 'Ready for Dev'.
Mengapa ini penting

Melacak persetujuan membantu menganalisis waktu antara pengajuan ide dan komitmen untuk mengembangkannya. Data ini menyoroti potensi keterlambatan dalam tahap perencanaan dan peninjauan backlog.

Sumber data

Disimpulkan dari riwayat work item dengan mendeteksi perubahan kolom System.State menjadi 'Approved' atau status khusus serupa.

Pengumpulan data

Disimpulkan dari perubahan kolom State menjadi 'Approved'.

Jenis peristiwa inferred
Work Item ditutup
Menandai penutupan akhir work item setelah penerapan dan validasi pascapenerapan. Peristiwa ini tercatat saat status berubah menjadi 'Closed' atau 'Done'.
Mengapa ini penting

Aktivitas ini menandai penyelesaian akhir yang berhasil untuk seluruh proses work item. Inilah titik akhir yang pasti dalam siklusnya.

Sumber data

Disimpulkan dari riwayat work item saat kolom System.State berubah menjadi 'Closed' atau status akhir serupa dalam kategori 'Completed'.

Pengumpulan data

Disimpulkan dari perubahan kolom State menjadi 'Closed'.

Jenis peristiwa inferred
Disarankan Opsional

Panduan pengambilan data

Cara mengambil data dari Azure DevOps

Siap memulai?

Mulai optimalkan siklus hidup pengembangan perangkat lunak Anda hari ini. Template ini menjadi langkah pertama untuk mendapatkan wawasan proses yang berguna.

Mulai optimalkan SDLC di Azure DevOps hari ini!

Kurangi waktu siklus hingga 30% dan hilangkan hambatan dalam alur kerja SDLC Anda.

Mulai uji coba gratis

Tidak perlu kartu kredit. Anda bisa mulai dalam beberapa menit.