Template data siklus hidup pengembangan perangkat lunak Anda
Template data siklus hidup pengembangan perangkat lunak Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak dalam SDLC Anda
- Panduan terperinci untuk mengambil data dari Azure DevOps
Atribut siklus hidup pengembangan perangkat lunak
| 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
|
|||
Aktivitas siklus hidup pengembangan perangkat lunak
| 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
|
|||
Panduan pengambilan data
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.
Tidak perlu kartu kredit. Anda bisa mulai dalam beberapa menit.