Yazılım geliştirme yaşam döngüsü veri Templateiniz

Azure DevOps
Yazılım geliştirme yaşam döngüsü veri Templateiniz

Yazılım geliştirme yaşam döngüsü veri Templateiniz

Bu Template, yazılım geliştirme yaşam döngüsü verilerinizi Process Mining için hazırlarken izleyeceğiniz yolu gösterir. Toplamanız gereken temel veri özniteliklerini ve izlemeniz gereken önemli etkinlikleri açıklar; ayrıca bu bilgileri Azure DevOps’tan nasıl çıkaracağınıza dair pratik öneriler sunar. Verilerinizi anlamlı analiz ve süreç iyileştirmesi için uygun biçimde yapılandırmak üzere bu kaynaktan yararlanın.
  • Toplanması önerilen öznitelikler
  • Yazılım geliştirme yaşam döngünüzde izlenecek temel etkinlikler
  • Azure DevOps’tan veri çıkarmaya yönelik ayrıntılı yönergeler
Olay günlüklerine yeni misiniz? Process Mining için nasıl Event Log oluşturacağınızı öğrenin.

Yazılım geliştirme yaşam döngüsü öznitelikleri

Yazılım geliştirme yaşam döngüsünü ayrıntılı biçimde analiz etmek ve iyileştirmek için Event Logunuza eklemeniz önerilen veri alanları.
5 Zorunlu 7 Önerilen 6 İsteğe bağlı
Ad Açıklama
Etkinlik adı
ActivityName
Bir iş öğesinin geliştirme yaşam döngüsünde belirli bir anda gerçekleşen olayın veya Task’ın adıdır.
Açıklama

Etkinlik adı, süreçteki Development Started, Pull Request Created veya Deployed to Production gibi belirli bir adımı ya da kilometre taşını belirtir. Bu etkinlikler, iş öğesinin durumundaki değişikliklerden, derleme veya pull request gibi bağlantılı olaylardan ya da özel olaylardan elde edilir.

Bu öznitelik, iş akışını görsel olarak gösteren süreç haritasını oluşturmak için gereklidir. Analistlerin olay sırasını anlamasına, yaygın yolları belirlemesine, etkinlikler arasındaki darboğazları bulmasına ve her adımın ne sıklıkta gerçekleştiğini incelemesine yardımcı olur.

Neden önemli?

Süreçteki adımları tanımlar, süreç haritasının temelini oluşturur ve iş akışını, darboğazları ve sapmaları analiz etmenizi sağlar.

Nereden alınır?

Genellikle iş öğesinin State alanındaki değişikliklerden veya derleme, commit ve pull request gibi bağlantılı olaylardan elde edilir. Bu olayların ham verileri Work Item History’de bulunur.

Örnekler
Geliştirme başladıPull Request tamamlandıQA testi başarısız olduÜretim ortamına dağıtıldıİş öğesi kapatıldı
Geliştirme öğesi
DevelopmentItem
Özellik, hata veya kullanıcı hikâyesi gibi tek bir iş biriminin benzersiz tanımlayıcısıdır ve süreçte vaka kimliği olarak kullanılır.
Açıklama

Development Item, Azure DevOps’ta takip edilen belirli bir iş parçasını temsil eder. Benzersiz kimliğiyle tanımlanan her öğe, oluşturma ve planlamadan geliştirme, test ve dağıtıma kadar tüm süreç etkinliklerinin merkezindedir.

Process Mining analizinde bu öznitelik, ilgili tüm olayları tek bir vaka yolculuğunda bir araya getirmek için temel oluşturur. Her iş öğesinin uçtan uca yaşam döngüsünü yeniden oluşturmanızı sağlar. Böylece çevrim sürelerini, süreç sapmalarını ve yeniden çalışma döngülerini öğe bazında analiz edebilirsiniz.

Neden önemli?

Tüm süreç adımlarını tek bir vakada birleştiren temel tanımlayıcıdır. Yazılım geliştirme yaşam döngüsünü uçtan uca analiz etmeyi mümkün kılar.

Nereden alınır?

Azure DevOps Boards’taki bir iş öğesinin ID alanına karşılık gelir. Azure DevOps REST API üzerinden Work Item Tracking için erişilebilir.

Örnekler
10234102351023610237
Olay zamanı
EventTime
Bir geliştirme öğesi için belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren kesin zaman damgasıdır.
Açıklama

Olay zamanı, geliştirme yaşam döngüsündeki her etkinliğin tarih ve saatini kaydeder. Olayları kronolojik sıraya koymak ve aralarındaki süreleri hesaplamak için bu zaman damgası kullanılır.

Analizde bu öznitelik, çevrim süreleri, işlem süreleri ve bekleme süreleri dâhil zamana dayalı tüm metrikleri hesaplamak için gereklidir. Process Mining analizinin ihtiyaç duyduğu, zamana göre sıralanmış olay günlüğünü oluşturmayı sağlar. Gecikmeleri belirlemek, SLA’lara göre performansı ölçmek ve zaman içindeki eğilimleri takip etmek için kullanılır.

Neden önemli?

Bu zaman damgası olayların kronolojik sırasını gösterir. Süreye dayalı tüm KPI’ları hesaplamak, süreç akışını ve darboğazları anlamak için gereklidir.

Nereden alınır?

İş öğesi geçmişindeki her güncellemeyle ilişkili Changed Date değeridir. Derleme veya dağıtım gibi harici olaylarda ise olayın tamamlanma zaman damgasıdır.

Örnekler
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Kaynak sistem
SourceSystem
Süreç verilerinin çıkarıldığı sistemdir. Bu örnekte Azure DevOps’tur.
Açıklama

Bu öznitelik, verilerin hangi sistemden geldiğini belirtir. Daha geniş bir süreç görünümü için birden fazla sistemden gelen verilerin birleştirildiği ortamlarda özellikle yararlıdır. Bu modelde değer her zaman Azure DevOps’tur.

Tek sistemli bir analizde sabit bir değer gibi görünse de verinin kaynağı hakkında önemli bağlam sağlar. Bu bilgi, veri yönetişimi, sorun giderme ve gelecekte ServiceNow veya SAP gibi diğer sistemlerle yapılacak bütünleştirmeler için gereklidir.

Neden önemli?

Verinin kaynağı hakkında önemli bağlam sağlar. Bu bilgi, veri yönetişimi, doğrulama ve birden fazla sistemi kapsayan süreç analizleri için önemlidir.

Nereden alınır?

Veri setini etiketlemek için veri çıkarma ve dönüştürme sırasında eklenmesi gereken sabit bir değerdir.

Örnekler
Azure DevOps
Son veri güncellemesi
LastDataUpdate
Bu süreçteki verilerin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgasıdır.
Açıklama

Bu öznitelik, veri setinin Azure DevOps’tan en son ne zaman çıkarılıp güncellendiğini kaydeder. Verilerin ne kadar güncel olduğunu ve analizin hangi dönemi kapsadığını açıkça gösterir.

Bilinçli kararlar almak için analizde kullanılan verilerin ne kadar güncel olduğunu bilmek önemlidir. Bu zaman damgası, kullanıcıların gerçek zamanlı bilgilere mi yoksa geçmişten alınmış bir anlık görüntüye mi baktığını anlamasına yardımcı olur. Bu da bulguların ne kadar geçerli olduğunu etkiler.

Neden önemli?

Verilerin güncelliğini göstererek analizlerin ve kararların hangi dönemi kapsadığı konusunda netlik sağlar.

Nereden alınır?

Veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde oluşturulup kaydedilen bir meta veri zaman damgasıdır.

Örnekler
2024-05-20T08:00:00Z
Atanan kişi
AssignedTo
Geliştirme öğesinin şu anda atandığı kullanıcı veya ekip üyesidir.
Açıklama

Bu öznitelik, sürecin belirli bir aşamasında iş öğesinden sorumlu kişiyi gösterir. Öğe yaşam döngüsü boyunca atama birkaç kez değişebilir; örneğin geliştiriciden test uzmanına, ardından sürüm yöneticisine geçebilir.

Developer and Tester Workload Overview Dashboardında analiz yapmak için Assigned To alanını kullanmak önemlidir. Kaynak dağılımını anlamanıza, aşırı iş yükü olan ekip üyelerini belirlemenize ve kişiler ya da ekipler arasındaki performans farklarını incelemenize yardımcı olur.

Neden önemli?

Kaynak bazında analiz yapmanızı sağlar. Böylece iş yükünün dağılımını anlayabilir, kaynaklara özgü darboğazları belirleyebilir ve ekip kapasitesini yönetebilirsiniz.

Nereden alınır?

Azure DevOps’taki bir iş öğesinin Assigned To alanına karşılık gelir. Her olay için değer, iş öğesi geçmişinden alınır.

Örnekler
jane.doe@example.comjohn.smith@example.comatanmamış
Bitiş zamanı
EndTime
Bir etkinliğin ne zaman tamamlandığını gösteren zaman damgasıdır. Etkinliğin işlem süresini hesaplamak için kullanılır.
Açıklama

Bitiş zamanı, bir etkinliğin sona erdiği anı gösterir. Birçok olay günlüğünde sonraki etkinliğin başlangıç zamanı, önceki etkinliğin bitiş zamanı olarak kullanılır. Ancak ayrı bir bitiş zamanının bulunması, hem etkinliğin işlem süresini hem de etkinlikler arasındaki boşta geçen süreyi daha doğru hesaplamayı sağlar.

Bu öznitelik, ProcessingTime KPI’ını hesaplamak ve ayrıntılı darboğaz analizi yapmak için gereklidir. Bir Task üzerinde etkin biçimde çalışılan süreyle sonraki adımın başlamasını beklerken geçen süreyi ayırt etmeye yardımcı olur. Bu ayrım, Stage Handoff Analysis Dashboardı için önemlidir.

Neden önemli?

Etkinliklerin işlem sürelerini ve boşta geçen süreleri doğru hesaplamayı sağlar. Bu hesaplamalar, darboğaz analizi ve verimlilik iyileştirmeleri için temel oluşturur.

Nereden alınır?

Bu değer çoğunlukla türetilir. Aynı vaka için sonraki olayın başlangıç zamanı kullanılabilir veya kaynak sistem Task’ların hem başlangıç hem bitiş zamanlarını kaydediyorsa doğrudan alınabilir.

Örnekler
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Durum
State
Geliştirme öğesinin iş akışındaki mevcut durumu. Örneğin 'Yeni', 'Etkin', 'Çözüldü' veya 'Kapatıldı'.
Açıklama

Durum özniteliği, bir iş öğesinin herhangi bir andaki resmî durumunu gösterir. Bu durum, projenin süreç şablonunda tanımlanır. Durumlar arasındaki geçişler, Event Log içindeki etkinlikleri oluşturmanın temel kaynağıdır.

'Aktivite' özniteliği durum değişikliğini çoğu zaman daha açıklayıcı biçimde ifade eder. Ancak ham 'Durum' özniteliği filtreleme ve analiz için yararlıdır. Öğelerin belirli durumlarda ne kadar zaman geçirdiğini anlamanıza yardımcı olur; Aşama Süresi Dashboardunu oluşturmak ve devir teslimleri analiz etmek için temel oluşturur.

Neden önemli?

Öğenin yaşam döngüsündeki durumunu gösterir. Süreç akışını anlamak ve farklı aşamalarda geçirilen süreyi hesaplamak için temel bilgidir.

Nereden alınır?

Azure DevOps’taki bir iş öğesinin 'Durum' alanına karşılık gelir.

Örnekler
YeniEtkinKalite güvencesindeÇözüldüKapatıldı
Ekip adı
TeamName
İş öğesinden sorumlu geliştirme ekibinin adı.
Açıklama

Ekip adı, iş öğesinin atandığı ekibi belirtir. Azure DevOps’ta işler genellikle daha büyük bir projenin alt ekipleri olabilen ekipler üzerinden düzenlenir.

Bu öznitelik, süreç analizini ekiplere göre ayırmanızı sağlar. Farklı ekiplerin süreçlerini ve performansını karşılaştırabilir, başarılı ekiplerdeki iyi uygulamaları belirleyebilir ve desteğe ya da süreç iyileştirmelerine ihtiyaç duyan ekipleri görebilirsiniz.

Neden önemli?

Ekiplerin performansını karşılaştırmanıza, farklılıkları belirlemenize ve iyi uygulamaları kuruluş genelinde paylaşmanıza yardımcı olur.

Nereden alınır?

Azure DevOps’ta ekipler genellikle belirli alan yollarıyla eşleştirildiğinden, bu bilgi çoğu zaman iş öğesinin 'Alan Yolu' alanından elde edilir.

Örnekler
Phoenix EkibiOmega EkibiPlatform Çekirdek EkibiÖn Yüz Ekibi
İş öğesi türü
WorkItemType
Geliştirme öğesinin Bug, Feature, User Story veya Task gibi sınıflandırmasıdır.
Açıklama

İş öğesi türü, yapılan işin niteliğini sınıflandırır. Farklı türdeki iş öğeleri çoğunlukla farklı süreç yollarını izler ve farklı performans beklentilerine ya da SLA’lara tabidir. Örneğin bir Bug, Feature’a kıyasla daha hızlı bir süreçten geçebilir.

Bu öznitelik karşılaştırmalı analiz için gereklidir. Süreç haritasını veya KPI’ları iş türüne göre filtreleyerek belirli süreçlerin hatalarda mı yoksa özelliklerde mi daha verimli olduğunu anlayabilir, farklı iş kategorilerinin geçmiş çevrim süresi eğilimlerini takip edebilirsiniz.

Neden önemli?

Süreç analizini iş türüne göre ayırmanızı sağlar. Böylece hata ve özellik gibi farklı iş kategorilerinin iş akışlarını ve performansını karşılaştırabilirsiniz.

Nereden alınır?

Azure DevOps’taki bir iş öğesinin Work Item Type alanına karşılık gelir.

Örnekler
HataÖzellikKullanıcı hikâyesiTask
Öncelik
Priority
Geliştirme öğesinin önemini diğer öğelere göre gösteren sayısal veya açıklayıcı sıralama.
Açıklama

Öncelik, bir iş öğesinin planlamadaki önemini gösterir. Önceliği yüksek bir öğenin, önceliği düşük olanlardan daha önce ele alınması beklenir. Yaygın değerler 1, 2, 3 ve 4 gibi sayılardır; 1 en yüksek önceliği belirtir.

Bu öznitelik, Önceliğe Göre İşlem Hacmi ve Çevrim Süresi Dashboardu için gereklidir. Verileri bu özniteliğe göre analiz ederek önceliklendirme sisteminin işe yarayıp yaramadığını, yani yüksek öncelikli öğelerin süreçte gerçekten daha hızlı ilerleyip ilerlemediğini görebilirsiniz.

Neden önemli?

Sürecin yüksek öncelikli öğeleri öne alıp almadığını analiz etmenizi sağlar. Bu, önceliklendirme stratejilerinin başarısını değerlendirmek için önemlidir.

Nereden alınır?

Azure DevOps’taki bir iş öğesinin 'Öncelik' alanına karşılık gelir.

Örnekler
1234
Yeniden çalışma var mı
IsRework
Bir geliştirme öğesinin yaşam döngüsünde önceki bir aşamaya geri dönüp dönmediğini belirten mantıksal değer.
Açıklama

Bir iş öğesi yeniden çalışma döngüsüne girerse bu işaret true olarak ayarlanır. Örneğin, 'Kalite güvencesi testleri tamamlandı' aşamasından 'Geliştirme başladı' aşamasına geri dönülmesi buna örnektir. Bu değer, bir kaydın etkinlik sırası incelenerek ve doğrusal olmayan ilerlemeler belirlenerek hesaplanır.

Bu öznitelik, Yeniden Çalışma ve Yeniden Test Sıklığı Dashboardu ile Yeniden Çalışma Döngüsü Sıklığı KPI’ı için gereklidir. Yeniden çalışmayı kolayca filtreleyip ölçmenizi sağlar; verimsizliğe yol açan kalite sorunlarını, iletişim kopukluklarını veya yetersiz testleri belirlemenize yardımcı olur.

Neden önemli?

Yeniden çalışmayı doğrudan belirleyip ölçer; çevrim sürelerini uzatan kalite sorunlarını ve süreç verimsizliklerini görünür kılar.

Nereden alınır?

Bu öznitelik, her kayıt için Event Log içindeki etkinlik sırası analiz edilerek hesaplanır.

Örnekler
truefalse
Aşamalar arası devir teslim süresi
StageHandoffTime
Bir ana aşamanın tamamlanmasıyla sonraki aşamanın başlaması arasında geçen bekleme süresi.
Açıklama

Aşamalar arası devir teslim süresi, süreç aşamaları arasındaki bekleme süresini ölçer. Örneğin, 'Geliştirme tamamlandı' ile 'Kalite güvencesi testleri başladı' arasındaki süreyi gösterir. Bu süre, önemli geçişler belirlenerek ve ilk etkinliğin bitişiyle ikinci etkinliğin başlangıcı arasındaki fark hesaplanarak bulunur.

Bu metrik, Aşama Süresi ve Devir Teslim Analizi Dashboardunun odağındadır. Devir teslim süresini ayrı olarak ölçmek, işin beklediği gizli darboğazları belirlemeye yardımcı olur. Bu beklemeler çoğu zaman kaynakların müsait olmamasından, iletişim gecikmelerinden veya verimsiz süreçlerden kaynaklanır.

Neden önemli?

Süreç aşamaları arasındaki bekleme sürelerini ölçerek, aktif çalışmanın dışında kalan gizli darboğazları ve gecikmeleri ortaya çıkarır.

Nereden alınır?

Bu öznitelik hesaplanır. Önce devir teslimi gösteren ardışık etkinlik çiftlerini belirleyin, ardından aralarındaki zaman farkını hesaplayın.

Örnekler
2 saat 15 dakika1 gün 4 saat0 saat 30 dakika
Onay bekleme süresi
ApprovalWaitingTime
Bir geliştirme öğesinin onay isteği gönderildikten sonra onay beklediği süre.
Açıklama

Bu metrik, bir iş öğesinin onay beklediği belirli süreleri ölçer. Örneğin, 'Kullanıcı kabul testleri başladı' ile 'Kullanıcı kabul testleri onaylandı' arasındaki süreyi gösterir. Belirli bir kayıt için bu iki etkinlik arasındaki zaman farkı hesaplanır.

Bu hesaplanan öznitelik, Onay Bekleme Süresi Analizi Dashboardunu ve ilgili KPI’ı doğrudan destekler. Ekipler, bu gecikmeleri ayrı olarak inceleyerek iletişim ve karar alma süreçlerini iyileştirebilir, bekleme süresini azaltabilir ve genel yaşam döngüsünü hızlandırabilir.

Neden önemli?

Karar veya onay beklemekten kaynaklanan gecikmeleri ölçer; iletişim ve karar alma süreçlerini iyileştirme fırsatlarını gösterir.

Nereden alınır?

Event Log içinde onay sürecinin başlangıç ve bitiş etkinliklerini (ör. 'Kullanıcı kabul testleri başladı' ve 'Kullanıcı kabul testleri onaylandı') bulun, ardından aralarındaki zaman farkını hesaplayın.

Örnekler
3 gün 2 saat1 gün 8 saat 30 dakika4 saat
Önem derecesi
Severity
Bir hatanın veya sorunun sistem ya da son kullanıcılar üzerindeki etkisini gösterir.
Açıklama

Önem derecesi, sistemin çalışmasını durduran hatalardan küçük görsel sorunlara kadar hataların etkisini sınıflandırır. İşin hangi sırayla yapılacağını belirleyen öncelikten farklıdır. Örneğin, kolayca uygulanabilecek bir geçici çözümü bulunan ciddi bir hatanın önceliği düşük olabilir.

Bu öznitelik, özellikle Önceliğe Göre İşlem Hacmi ve Çevrim Süresi Dashboardu için analize farklı bir boyut katar. 'En ciddi hataları önce mi düzeltiyoruz?' gibi soruları incelemenize ve işlenen işlerin risk düzeyini anlamanıza yardımcı olur.

Neden önemli?

İş öğelerini iş üzerindeki etkilerine göre sınıflandırır. Böylece ekibin etkisi yüksek sorunları ne kadar iyi ele aldığını analiz edebilirsiniz.

Nereden alınır?

Azure DevOps’ta genellikle hatalar için kullanılan iş öğesinin 'Önem derecesi' alanına karşılık gelir.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Proje adı
ProjectName
Geliştirme öğesinin ait olduğu Azure DevOps projesinin adı.
Açıklama

Bu öznitelik, iş öğesinin bulunduğu Azure DevOps kuruluşundaki projeyi belirtir. Özellikle çok sayıda projesi olan kuruluşlarda genel bir bağlam sağlar.

Proje adı, filtreleme ve karşılaştırma için önemli bir boyuttur. Geçmiş Çevrim Süresi Eğilimleri Dashboardunda analizleri projeye göre ayırmanıza yardımcı olur. Böylece bazı projelerin diğerlerinden daha verimli olup olmadığını veya bir projedeki süreç iyileştirmelerinin olumlu sonuç verip vermediğini görebilirsiniz.

Neden önemli?

Analiz için üst düzey bir gruplama sağlar; farklı projelerin performansını ve eğilimlerini karşılaştırmanıza yardımcı olur.

Nereden alınır?

Azure DevOps’taki bir iş öğesinin 'Ekip Projesi' alanına karşılık gelir.

Örnekler
E-ticaret platformuMobil uygulamanın yeniden kullanıma sunulmasıVeri ambarının modernizasyonu
Pull Request kimliği
PullRequestId
Geliştirme öğesine bağlı bir pull request’in kimliği.
Açıklama

Bu öznitelik, iş öğesini kod değişikliklerinin gönderilip incelendiği belirli bir pull request’e bağlar. Bir iş öğesi birden fazla pull request ile ilişkili olabilir.

Pull Request kimliği, yaşam döngüsünün kod inceleme ve entegrasyon aşamalarını daha ayrıntılı analiz etmenizi sağlar. Pull request’in oluşturulmasından tamamlanmasına kadar geçen süreyi ölçebilir; pull request’lerin ne sıklıkla reddedildiğini veya önemli değişiklikler gerektirdiğini inceleyebilirsiniz. Bu durum kod kalitesine ya da gereksinimlerin açıklığına işaret edebilir.

Neden önemli?

Geliştirme işini belirli kod inceleme etkinliklerine bağlar. Böylece kod entegrasyonu ve kalite güvencesi sürecini ayrıntılı biçimde analiz edebilirsiniz.

Nereden alınır?

Bu bilgi, Azure DevOps’ta iş öğesinin 'Bağlantılar' veya 'Geliştirme' bölümünde bulunur.

Örnekler
452145334589
Yineleme yolu
IterationPath
İş öğesinin atandığı geliştirme sprinti veya zaman aralığı.
Açıklama

Yineleme yolu, yani sprint, geliştirme için belirlenmiş bir zaman aralığını ifade eder. İş öğeleri, bu süre içinde tamamlanmaları için bir yinelemeye atanır.

Yineleme yoluna göre analiz, süreç performansını sprint bazında anlamanıza yardımcı olur. Ardışık sprintlerde çevrim sürelerinin iyileşip iyileşmediğini izleyebilir, sonraki sprintlere aktarılan işleri inceleyebilir ve sprint planlamasının öngörülebilirliğini değerlendirebilirsiniz.

Neden önemli?

Sprint bazında analiz yapmanızı sağlar. Ekipler zaman içindeki performanslarını değerlendirebilir ve çevik çalışma yöntemlerini geliştirebilir.

Nereden alınır?

Azure DevOps’taki bir iş öğesinin 'Yineleme yolu' alanına karşılık gelir.

Örnekler
E-ticaret platformu\Sprint 12E-ticaret platformu\Sprint 13Mobil uygulamanın yeniden kullanıma sunulması\Aşama 2\Sprint 4
Zorunlu Önerilen İsteğe bağlı

Yazılım geliştirme yaşam döngüsü etkinlikleri

Süreci doğru biçimde keşfetmek ve darboğazları belirlemek için Event Logunuza kaydetmeniz gereken temel süreç adımları ve kilometre taşları.
7 Önerilen 8 İsteğe bağlı
Aktivite Açıklama
Geliştirme başladı
Bu etkinlik, bir geliştiricinin iş öğesi üzerinde çalışmaya başladığını gösterir. İş öğesinin durumu Active, In Progress veya Committed olarak değiştiğinde çıkarılır.
Neden önemli?

Etkin geliştirme aşamasının başlangıcını gösterir. Created ile Development Started arasındaki süreyi analiz ederek backlog kuyruğunda bekleme sürelerini görebilirsiniz.

Nereden alınır?

İş öğesi geçmişinde System.State alanının New veya Approved durumundan In Progress durumuna değiştiği saptanarak çıkarılır.

Kaydedin

State alanının Active veya In Progress olarak değişmesinden çıkarılır.

Olay türü inferred
İş öğesi oluşturuldu
Bu etkinlik, geliştirme yaşam döngüsünün başlangıcını gösterir. User Story, Bug veya Task gibi yeni bir iş öğesi oluşturulduğunda gerçekleşir. Azure DevOps Boards’a yeni bir kayıt kaydedildiğinde açıkça kayda alınır.
Neden önemli?

Bu, sürecin temel başlangıç olayıdır. Uçtan uca geliştirme çevrim süresini ölçmek ve işin ilk kaynaklarını anlamak için gereklidir.

Nereden alınır?

Bu olay, iş öğesindeki Created Date alanından alınır. İş öğesi geçmişi tablosu da bu ilk durum geçişini kaydeder.

Kaydedin

İş öğesinin Created Date alanından alınır.

Olay türü explicit
Pull Request oluşturuldu
Geliştiricinin ilk kodlama çalışmalarını tamamladığını ve değişiklikleri inceleme için pull request aracılığıyla gönderdiğini gösterir. Bu olay, iş öğesini Azure Repos’taki belirli bir kod değişikliğiyle ilişkilendirir.
Neden önemli?

Bu, geliştirmeden kod incelemeye geçişteki önemli bir devir teslimdir. Takip ederek kodlama süresini ölçebilir ve kodun ekip incelemesine ne zaman hazır olduğunu belirleyebilirsiniz.

Nereden alınır?

Azure Repos verilerinden, pull request oluşturma olayının ilişkili iş öğesiyle eşleştirilmesiyle alınır. Geliştirici bu bağlantıyı çoğunlukla açıkça kurar.

Kaydedin

Azure Repos’ta iş öğesiyle ilişkilendirilmiş pull request oluşturma olayından alınır.

Olay türü explicit
Pull Request tamamlandı
Kod incelemesinin başarıyla tamamlandığını, pull request’in onaylandığını ve kodun hedef dala birleştirildiğini gösterir. Bu olay Azure Repos’ta açıkça kaydedilir.
Neden önemli?

Kod inceleme aşamasının sonunu gösterir. Bu aşama sık karşılaşılan bir darboğazdır. PR oluşturulmasıyla tamamlanması arasındaki süreyi analiz ederek inceleme çevriminin verimliliğini ölçebilirsiniz.

Nereden alınır?

Azure Repos’ta iş öğesiyle ilişkilendirilmiş pull request’in tamamlanma veya birleştirme olayından alınır.

Kaydedin

İş öğesiyle ilişkilendirilmiş pull request birleştirme olayından alınır.

Olay türü explicit
QA testi başladı
Resmî kalite güvence testi aşamasının başlangıcını gösterir. İş öğesinin durumu In QA, Testing veya benzer bir değere değiştiğinde çıkarılır.
Neden önemli?

QA çevriminin başlangıcını gösterir. Bu aşamanın süresini analiz etmek, test darboğazlarını ve verimliliği anlamak için önemlidir.

Nereden alınır?

İş öğesi geçmişinde System.State alanının In QA veya belirlenmiş başka bir test durumuna değişmesi izlenerek çıkarılır.

Kaydedin

State alanının In QA veya Testing olarak değişmesinden çıkarılır.

Olay türü inferred
UAT onaylandı
İş paydaşlarının Kullanıcı Kabul Testinden sonra değişiklikleri onayladığını gösterir. Genellikle durumun In UAT’den UAT Approved veya Ready for Release durumuna değişmesinden çıkarılır.
Neden önemli?

Bu önemli onay aşaması, iş öğesinin iş gereksinimlerini karşıladığını ve üretim ortamına dağıtıma hazır olduğunu doğrular.

Nereden alınır?

İş öğesi geçmişinde System.State alanının UAT durumundan onaylanmış veya sürüme hazır bir duruma değişmesi saptanarak çıkarılır.

Kaydedin

State alanının In UAT durumundan Ready for Release durumuna değişmesinden çıkarılır.

Olay türü inferred
Üretim ortamına dağıtıldı
İş öğesiyle ilişkili kodun üretim ortamına başarıyla dağıtıldığını gösterir. Azure Pipelines sürüm günlüklerinden açıkça alınan bir olaydır.
Neden önemli?

Değerin teslim edildiğini gösteren önemli bir aşamadır. Teslim süresini ve çevrim süresini hesaplamak için bitiş noktası olarak kullanılır.

Nereden alınır?

Azure Pipelines sürüm hattı verilerinden, özellikle iş öğesiyle ilişkilendirilmiş Production aşamasına dağıtımın tamamlanma olayından alınır.

Kaydedin

Sürüm hattındaki dağıtımın tamamlanma olayından alınır.

Olay türü explicit
Derleme başarılı oldu
Bu etkinlik, yeni değişiklikleri içeren kaynak kodun derleme hattı tarafından başarıyla derlenip paketlendiğini doğrular. Azure Pipelines bu olayı açıkça kaydeder.
Neden önemli?

Yeni kodun derlemeyi bozmadan doğru biçimde bütünleşmesini sağlayan önemli bir kalite kapısıdır. Bu aşamadaki hatalar bütünleştirme sorunlarına işaret edebilir.

Nereden alınır?

Azure Pipelines derleme tamamlama olaylarından alınır. Derlemenin iş öğesiyle doğrudan veya ilişkili pull request üzerinden bağlantılı olması gerekir.

Kaydedin

Azure Pipelines derleme tamamlama olayından alınır.

Olay türü explicit
Geliştirme tamamlandı
Tüm geliştirme ve birim testi çalışmalarının tamamlandığını, iş öğesinin resmî teste hazır olduğunu gösterir. Genellikle iş öğesinin durumu Resolved veya Ready for Test olarak değiştiğinde çıkarılır.
Neden önemli?

Geliştirme ekibinden QA ekibine yapılan önemli bir devir teslimi gösterir. QA Testing Started aşamasına kadar geçen süreyi ölçerek devir teslim gecikmelerini belirleyebilirsiniz.

Nereden alınır?

İş öğesi geçmişinde System.State alanının Resolved gibi bir değere veya QA’ya hazır olduğunu belirten özel bir duruma değişmesinden çıkarılır.

Kaydedin

State alanının Resolved olarak değişmesinden çıkarılır.

Olay türü inferred
İş öğesi iptal edildi
İş öğesinin iptal edildiğini, tamamlanmayacağını veya dağıtılmayacağını gösterir. Durum Removed, Cancelled veya benzer bir değere değiştiğinde kaydedilir.
Neden önemli?

Bu, sürecin alternatif ve başarısız bir şekilde sona erdiğini gösterir. İptal edilen öğeleri analiz ederek planlama, önceliklendirme veya gereksinim tanımlama sorunlarını ortaya çıkarabilirsiniz.

Nereden alınır?

İş öğesi geçmişinde System.State alanının Removed kategorisindeki bir son duruma değişmesinden çıkarılır.

Kaydedin

State alanının Removed veya Cancelled olarak değişmesinden çıkarılır.

Olay türü inferred
İş öğesi kapatıldı
Dağıtım ve dağıtım sonrası doğrulama tamamlandıktan sonra iş öğesinin son kez kapatıldığını gösterir. Durum Closed veya Done olarak değiştiğinde kaydedilir.
Neden önemli?

Bu etkinlik, iş öğesine ait sürecin başarıyla tamamlandığını gösterir. Yaşam döngüsünün kesin bitiş noktasıdır.

Nereden alınır?

İş öğesi geçmişinde System.State alanının Closed veya Completed kategorisindeki benzer bir son duruma değişmesinden çıkarılır.

Kaydedin

State alanının Closed olarak değişmesinden çıkarılır.

Olay türü inferred
İş öğesi onaylandı
İş öğesinin resmen onaylandığını, yeterince tanımlandığını ve geliştirmeye hazır olduğunu gösterir. Genellikle State alanının Approved veya Ready for Dev gibi bir değere değişmesinden çıkarılır.
Neden önemli?

Onayları takip etmek, fikrin sunulmasıyla geliştirme taahhüdü arasındaki süreyi analiz etmenizi sağlar. Planlama ve backlog düzenleme aşamalarındaki olası gecikmeleri ortaya çıkarır.

Nereden alınır?

İş öğesi geçmişinde System.State alanının Approved veya benzer bir özel duruma değiştiği saptanarak çıkarılır.

Kaydedin

State alanının Approved olarak değişmesinden çıkarılır.

Olay türü inferred
QA testi başarısız oldu
İş öğesinin kalite güvence testini geçemediğini ve geliştirmeye geri gönderildiğini gösterir. Test durumundan In Progress veya Active durumuna geçişle kaydedilir.
Neden önemli?

Bu etkinlik, yeniden çalışma döngülerini belirlemek için gereklidir. Sık tekrarlanması kod kalitesi, gereksinimler veya test süreçleriyle ilgili sorunlara işaret eder.

Nereden alınır?

İş öğesi geçmişinde In QA gibi bir durumdan Active veya In Progress gibi bir duruma geçiş saptanarak çıkarılır.

Kaydedin

State alanının In QA durumundan Active durumuna değişmesinden çıkarılır.

Olay türü inferred
QA testi tamamlandı
Kalite güvence aşamasının başarıyla tamamlandığını gösterir. İş öğesinin durumu test durumundan Ready for UAT veya QA Approved gibi bir duruma değiştiğinde çıkarılır.
Neden önemli?

Bu önemli kalite kapısı, iş öğesinin kullanıcı kabul testine veya sürüme hazır olduğunu gösterir. Bu aşamadan sonraki gecikmeler UAT ya da sürüm planlama darboğazlarına işaret edebilir.

Nereden alınır?

İş öğesi geçmişinde System.State alanının In QA durumundan Ready for UAT veya Done gibi sonraki bir duruma değişmesinden çıkarılır.

Kaydedin

State alanının In QA durumundan Ready for UAT durumuna değişmesinden çıkarılır.

Olay türü inferred
UAT başladı
İş paydaşlarının işlevselliği doğruladığı Kullanıcı Kabul Testinin başlangıcını gösterir. Genellikle durum In UAT veya benzer bir değere değiştiğinde çıkarılır.
Neden önemli?

Sürüm öncesindeki son doğrulama aşamasının başlangıcını ölçer. Süreç iyileştirmesi için UAT süresini ve onay bekleme sürelerini analiz etmek önemlidir.

Nereden alınır?

İş öğesi geçmişinde System.State alanının In UAT gibi UAT’yi belirten özel bir duruma güncellenmesinden çıkarılır.

Kaydedin

State alanının In UAT olarak değişmesinden çıkarılır.

Olay türü inferred
Önerilen İsteğe bağlı

Veri çıkarma rehberleri

Azure DevOps’tan verilerinizi nasıl alırsınız?

Başlamaya hazır mısınız?

Yazılım geliştirme yaşam döngünüzü iyileştirmek için bugün ilk adımı atın. Bu Template, süreçleriniz hakkında değerli içgörüler edinmeye başlamanızı sağlar.

Azure DevOps’ta yazılım geliştirme yaşam döngünüzü bugün iyileştirin!

Çevrim süresini %30 azaltın ve yazılım geliştirme iş akışınızdaki darboğazları ortadan kaldırın.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez. Dakikalar içinde başlayın.