Yazılım Geliştirme Yaşam Döngünüz için Veri Seti Templatei

Azure DevOps
Yazılım Geliştirme Yaşam Döngünüz için Veri Seti Templatei

Yazılım Geliştirme Yaşam Döngünüz için Veri Seti Templatei

Bu Template, yazılım geliştirme yaşam döngüsü verilerinizi Process Mining için hazırlamanızda size net bir yol haritası sunar. Toplamanız gereken temel veri özniteliklerini ve izlemeniz gereken önemli etkinlikleri açıklar. Ayrıca bu bilgileri Azure DevOps'tan nasıl çıkaracağınızı gösteren pratik yönergeler içerir. Verilerinizin anlamlı analiz ve süreç optimizasyonu için doğru yapıda olmasını sağlamak üzere bu kaynaktan yararlanın.
  • Toplanması önerilen öznitelikler
  • SDLC'niz için izlenecek önemli etkinlikler
  • Azure DevOps için ayrıntılı veri çıkarma yönergeleri
Event Loglarına yeni misiniz? Öğrenin Process Mining Event Logu oluşturmayı öğrenin.

Yazılım Geliştirme Yaşam Döngüsü Öznitelikleri

Yazılım Geliştirme Yaşam Döngüsünü kapsamlı biçimde analiz edip optimize etmek için Event Logunuza eklemeniz önerilen veri alanları aşağıdadır.
5 Gerekli 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 zamanda gerçekleşen olayın veya görevin adıdır.
Açıklama

Activity Name, Development Started, Pull Request Created veya Deployed to Production gibi süreçteki belirli bir adımı ya da kilometre taşını tanımlar. Bu etkinlikler, iş öğesinin durumundaki değişikliklerden, build veya pull request gibi bağlantılı olaylardan ya da özel olaylardan türetilir.

Bu öznitelik, iş akışını görsel olarak gösteren süreç haritasını oluşturmak için gereklidir. Analistlerin olayların sırasını anlamasına, yaygın yolları belirlemesine, belirli etkinlikler arasındaki darboğazları keşfetmesine ve her adımın sıklığını analiz etmesine yardımcı olur.

Neden önemli?

Süreçteki adımları tanımlar, süreç haritasının temelini oluşturur ve Workflow, darboğazlar ile sapmaların analizini mümkün kılar.

Nereden alınır?

Genellikle bir iş öğesinin 'State' alanındaki değişikliklerden veya derlemeler, commit'ler ve pull request'ler gibi bağlantılı olaylardan türetilir. Work Item History, bu olaylar için ham veriyi sağlar.

Örnekler
Geliştirme başladıPull Request tamamlandıQA Testi BaşarısızÜretime Dağıtıldıİş Öğesi Kapatıldı
Geliştirme Öğesi
DevelopmentItem
Süreçteki bir özellik, hata veya kullanıcı hikâyesi gibi tek bir iş biriminin benzersiz tanımlayıcısıdır ve süreçteki vaka tanımlayıcısı olarak kullanılır.
Açıklama

Geliştirme Öğesi, Azure DevOps içinde izlenen 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 merkezindeki nesnedir.

Process Mining analizinde bu öznitelik, ilgili tüm olayları tek bir vaka yolculuğunda ilişkilendirmek için temel niteliktedir. Her iş öğesinin uçtan uca yaşam döngüsünü yeniden oluşturmayı sağlar; böylece cycle time, süreç sapmaları ve yeniden çalışma döngüleri öğe bazında analiz edilebilir.

Neden önemli?

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

Nereden alınır?

Azure DevOps Boards içindeki bir Work Item'ın '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 gerçekleştiği kesin zaman damgasıdır.
Açıklama

Event Time, geliştirme yaşam döngüsündeki her etkinliğin tarih ve saatini kaydeder. Bu zaman damgası, olayları kronolojik sıraya koymak ve aralarındaki süreleri hesaplamak için kullanılan temel zamansal unsurdur.

Analizde bu öznitelik, çevrim süreleri, işlem süreleri ve bekleme süreleri dahil olmak üzere zamana dayalı tüm metrikleri hesaplamak için gereklidir. Zaman sıralı bir Event Log oluşturulmasını sağlar. Bu log, Process Mining analizleri için gerekli girdidir. Gecikmeleri teşhis etmek, performansı SLA’ler ile karşılaştırmak ve zaman içindeki eğilimleri izlemek için kullanılır.

Neden önemli?

Olayların kronolojik sırasını sağlar. Bu sıra, süreye dayalı tüm KPI'ları hesaplamak ve süreç akışı ile darboğazları anlamak için gereklidir.

Nereden alınır?

Bir iş öğesi geçmişindeki her güncellemeyle ilişkili 'Changed Date' alanıdır. Derleme veya dağıtım gibi harici olaylarda, ilgili 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 geldiği kaynak sistemi tanımlar. 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 sürekli olarak Azure DevOps'tur.

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

Neden önemli?

Verinin kaynağı hakkında önemli bağlam sağlar. Bu bilgi, veri yönetişimi, doğrulama ve çok sistemli süreç analizi için önemlidir.

Nereden alınır?

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

Örnekler
Azure DevOps
Son Veri Güncellemesi
LastDataUpdate
Bu sürece ait verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgasıdır.
Açıklama

Veri setinin Azure DevOps'tan en son ne zaman çıkarılıp güncellendiğini kaydeder. Verilerin güncelliğini ve analizin kapsadığı zaman aralığını açıkça gösterir.

Her süreç analizinde verilerin ne kadar güncel olduğunu bilmek, bilinçli kararlar almak için önemlidir. Bu zaman damgası, kullanıcıların gerçek zamanlı bilgilere mi yoksa geçmişe ait bir anlık görüntüye mi baktığını anlamasına yardımcı olur. Bu durum, bulguların geçerliliğini etkiler.

Neden önemli?

Verilerin güncelliği hakkında bilgi verir ve analizlerle kararların belirli bir zaman aralığına dayandığını anlamayı sağlar.

Nereden alınır?

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

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

Bu öznitelik, sürecin belirli bir aşamasında iş öğesinden sorumlu kişiyi tanımlar. Atama, öğenin yaşam döngüsü boyunca bir geliştiriciden test uzmanına ve ardından sürüm yöneticisine geçecek şekilde birkaç kez değişebilir.

Assigned To alanına göre analiz yapmak, Geliştirici ve Test Uzmanı İş Yükü Genel Görünümü Dashboardu için önemlidir. Kaynak dağılımını anlamanıza, aşırı yüklenmiş ekip üyelerini belirlemenize ve kişiler ya da ekipler arasındaki performans farklılıklarını analiz etmenize yardımcı olur.

Neden önemli?

Kaynak bazlı analiz yapılmasını sağlar; iş yükü dağılımını anlamaya, kaynağa özgü darboğazları belirlemeye ve ekip kapasitesini yönetmeye yardımcı olur.

Nereden alınır?

Azure DevOps'taki bir Work Item'ın 'Assigned To' alanına karşılık gelir. Değer, her olay için iş öğesi geçmişinden alınır.

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

End Time, bir etkinliğin sona erdiği zamanı gösterir. Birçok Event Logda 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üresinin hem de etkinlikler arasındaki boşta geçen sürenin daha doğru hesaplanmasını sağlar.

Bu öznitelik, ProcessingTime temel performans göstergesini hesaplamak ve ayrıntılı darboğaz analizi yapmak için gereklidir. Bir Task üzerinde gerçekten çalışılan süreyle sonraki adımın başlamasının beklendiği süreyi ayırt etmeye yardımcı olur. Bu ayrım, Aşama Devir Teslim Analizi Dashboardu için önemlidir.

Neden önemli?

Etkinlik işlem ve boşta kalma sürelerinin hassas biçimde hesaplanmasını sağlar. Bu, darboğaz analizi ve verimlilik iyileştirmeleri için temel niteliktedir.

Nereden alınır?

Genellikle türetilir. Aynı vaka için sonraki olayın başlangıç zamanı olabilir veya kaynak sistem görevlerin hem başlangıç hem de 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 Workflow içindeki mevcut durumudur; örneğin 'New', 'Active', 'Resolved' veya 'Closed'.
Açıklama

State özniteliği, bir iş öğesinin herhangi bir andaki resmi durumunu gösterir. Bu durum, projenin süreç Templateinde tanımlanır. Bu durumlar arasındaki geçişler, Event Logdaki etkinlikleri oluşturmak için kullanılan temel kaynaktır.

Activity özniteliği çoğu zaman durum değişikliğinin daha açıklayıcı bir biçimi olsa da ham State özniteliği filtreleme ve analiz için kullanışlıdır. Öğelerin belirli durumlarda ne kadar zaman geçirdiğini anlamaya yardımcı olur. Aşama Süresi Dashboardunu oluşturmak ve devir teslimleri analiz etmek için temel bir özniteliktir.

Neden önemli?

İş öğesinin yaşam döngüsündeki durumunu gösterir. Bu bilgi, süreç akışını anlamak ve çeşitli aşamalarda geçirilen süreyi hesaplamak için temeldir.

Nereden alınır?

Azure DevOps'taki bir Work Item'ın 'State' alanına karşılık gelir.

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

Team Name, bir iş öğesinin atandığı belirli ekibi tanımlar. Azure DevOps'ta işler genellikle daha büyük bir projenin alt kümeleri olan ekipler tarafından düzenlenir.

Bu öznitelik, süreç analizinin ekibe göre bölümlere ayrılmasını sağlar. Farklı ekiplerin süreçlerini ve performansını karşılaştırmaya, yüksek performanslı ekiplerdeki iyi uygulamaları belirlemeye ve belirli ekiplerin desteğe veya süreç iyileştirmelerine ihtiyaç duyduğu alanları bulmaya yardımcı olur.

Neden önemli?

Farklı ekipler arasında karşılaştırmalı analiz yapılmasını sağlar. Böylece performans farklılıkları belirlenebilir ve iyi uygulamalar kuruluş genelinde paylaşılabilir.

Nereden alınır?

Genellikle bir iş öğesinin 'Area Path' alanından türetilir; çünkü Azure DevOps'ta ekipler çoğunlukla belirli area path'lerle eşleştirilir.

Örnekler
Team PhoenixOmega SquadPlatform CoreFrontend Ekibi
İş Öğesi Türü
WorkItemType
Geliştirme öğesinin Bug, Feature, User Story veya Task gibi sınıflandırmasıdır.
Açıklama

Work Item Type, gerçekleştirilen işin niteliğini sınıflandırır. Farklı iş öğesi türleri genellikle farklı süreç yollarını izler ve farklı performans beklentilerine veya SLA'lara sahiptir. Örneğin bir 'Bug', bir 'Feature'a göre daha hızlı ilerleyen bir yolu izleyebilir.

Bu öznitelik karşılaştırmalı analiz için gereklidir. Süreç haritasını veya KPI'ları iş türüne göre filtreleyerek hatalarla özellikler için belirli süreçlerin daha verimli olup olmadığını anlamayı ya da farklı iş kategorilerinin geçmiş cycle time eğilimlerini izlemeyi sağlar.

Neden önemli?

Süreç analizini bölümlere ayırmanızı ve hata ile özellik gibi farklı iş kategorilerinin iş akışlarını ve performansını karşılaştırmanızı sağlar.

Nereden alınır?

Azure DevOps'taki bir Work Item'ın 'Work Item Type' alanına karşılık gelir.

Örnekler
HataÖzellikKullanıcı HikayesiGörev
Öncelik
Priority
Geliştirme öğesinin diğer öğelere göre önemini gösteren sayısal veya açıklayıcı sıralamadır.
Açıklama

Priority, bir iş öğesinin planlama açısından önemini gösterir. Daha yüksek bir öncelik, öğenin düşük öncelikli öğelere göre daha hızlı ele alınması gerektiğini belirtir. Yaygın değerler 1, 2, 3 ve 4 gibi sayılardır; 1 en yüksek önceliği ifade eder.

Bu öznitelik, Önceliğe Dayalı İşlem Hacmi ve Çevrim Süresi Dashboardu için gereklidir. Bu öznitelikle yapılan analiz, önceliklendirme sisteminin etkili olup olmadığını belirlemeye yardımcı olur. Başka bir deyişle, yüksek öncelikli öğelerin süreçte düşük öncelikli öğelerden gerçekten daha hızlı ilerleyip ilerlemediğini gösterir.

Neden önemli?

Sürecin yüksek öncelikli öğeleri gerçekten hızlandırıp hızlandırmadığını analiz etmeyi sağlar. Bu, önceliklendirme stratejilerinin başarısını değerlendirmek için önemlidir.

Nereden alınır?

Azure DevOps'taki bir Work Item'ın 'Priority' alanına karşılık gelir.

Örnekler
1234
Yeniden Çalışma mı
IsRework
Bir geliştirme öğesinin yaşam döngüsünde önceki bir aşamaya yeniden girip girmediğini gösteren boolean işaretidir.
Açıklama

Bu işaret, bir iş öğesi yeniden çalışma döngüsü içeriyorsa true olarak ayarlanır. Örneğin öğe QA Testing Completed durumundan Development Started durumuna geri dönebilir. Değer, bir vakanın etkinlik sırası analiz edilerek 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ığı temel performans göstergesi için gereklidir. Yeniden çalışmayı kolayca filtrelemenizi ve ölçmenizi sağlar. Böylece verimsizliğe yol açan kalite sorunlarını, iletişim eksikliklerini veya yetersiz testleri belirleyebilirsiniz.

Neden önemli?

Yeniden çalışmayı doğrudan belirleyip ölçer ve cycle time'ı uzatan kalite sorunlarıyla süreç verimsizliklerini görünür kılmaya yardımcı olur.

Nereden alınır?

Bu, her vaka için Event Logdaki etkinlik sırası analiz edilerek türetilen hesaplanmış bir özniteliktir.

Örnekler
truefalse
Aşama Devir Süresi
StageHandoffTime
Bir ana aşamanın tamamlanmasıyla sonraki aşamanın başlaması arasında geçen boşta bekleme süresidir.
Açıklama

Aşama Devir Teslim Süresi, ardışık süreç aşamaları arasındaki bekleme süresini ölçer. Örneğin Development Completed ile QA Testing Started arasındaki süreyi gösterir. Bu değer, önemli geçişlerin belirlenmesi ve ilk etkinliğin bitişiyle ikinci etkinliğin başlangıcı arasındaki zaman farkının ölçülmesiyle hesaplanır.

Bu metrik, Aşama Süresi ve Devir Teslim Analizi Dashboardunun odağındadır. Devir teslim süresini ayırıp ölçmek, işlerin boşta kaldığı gizli darboğazları belirlemek için önemlidir. Bunun nedeni çoğu zaman kaynakların kullanılamaması, iletişim gecikmeleri veya verimsiz süreçlerdir.

Neden önemli?

Süreç aşamaları arasındaki bekleme sürelerini ölçer ve aktif çalışmanın parçası olmayan gizli darboğazlarla gecikmeleri doğrudan ortaya çıkarır.

Nereden alınır?

Hesaplanmış bir özniteliktir. Deviri temsil eden ardışık etkinlik çiftlerinin belirlenmesi ve aralarındaki zaman farkının hesaplanması gerekir.

Örnekler
2 saat 15 dakika1 gün 4 saat0 saat 30 dakika
Onay Bekleme Süresi
ApprovalWaitingTime
Bir geliştirme öğesinin onay talebi oluşturulduktan sonra onay bekleyerek geçirdiği süredir.
Açıklama

Bu metrik, bir iş öğesinin onay beklediği belirli dönemlerin süresini ölçer. Buna UAT Started ile UAT Approved arasındaki süre örnek verilebilir. Belirli bir vaka için bu iki etkinlik arasındaki süre ölçülerek hesaplanır.

Bu hesaplanmış öznitelik, Onay Bekleme Süresi Analizi Dashboardunu ve ilgili temel performans göstergesini doğrudan destekler. Bu gecikmeleri ayırarak ekiplerin iletişim ve karar alma süreçlerini iyileştirmesine, boşta geçen süreyi azaltmasına ve genel yaşam döngüsünü hızlandırmasına yardımcı olur.

Neden önemli?

Karar veya onay beklemekten kaynaklanan gecikmeleri özel olarak ölçer ve iletişim ile karar alma süreçlerinin iyileştirilebileceği alanları gösterir.

Nereden alınır?

Event Logda belirli başlangıç ve bitiş onay etkinlikleri bulunur, örneğin UAT Started ve UAT Approved. Ardından bu iki etkinlik arasındaki zaman farkı hesaplanır.

Ö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

Severity, bir hatanın etkisini sınıflandırmak için kullanılır. Kritik sistem arızalarından küçük görsel sorunlara kadar farklı düzeyleri kapsar. İş sırasını belirleyen Priorityden farklıdır. Kolayca uygulanabilecek bir geçici çözüm varsa yüksek önem derecesine sahip bir hata düşük öncelikli olabilir.

Bu öznitelik, özellikle Önceliğe Dayalı İşlem Hacmi ve Çevrim Süresi Dashboardu için ek bir analiz boyutu sunar. En kritik hataları önce düzeltip düzeltmediğinizi incelemenize ve işlenen çalışmaların risk profilini anlamanıza yardımcı olur.

Neden önemli?

İş öğelerinin iş etkisine göre kategorilere ayrılmasını sağlar ve ekibin yüksek etkili sorunları ne kadar etkili ele aldığını analiz etmeye yardımcı olur.

Nereden alınır?

Azure DevOps'ta genellikle hatalar için kullanılan bir Work Item'ın 'Severity' 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ıdır.
Açıklama

Bu öznitelik, iş öğesinin bulunduğu Azure DevOps kuruluşundaki belirli projeyi tanımlar. Özellikle çok sayıda projenin bulunduğu kuruluşlarda üst düzey bağlam sağlar.

Project Name, filtreleme ve karşılaştırma için önemli bir boyuttur. Geçmiş Çevrim Süresi Eğilimleri Dashboardunu destekler. Analizi projeye göre bölümlendirerek bazı projelerin diğerlerinden daha verimli olup olmadığını veya bir projedeki süreç iyileştirmelerinin olumlu sonuç verip vermediğini görmenizi sağlar.

Neden önemli?

Analiz için üst düzey bir gruplama sağlar ve farklı projeler arasında performans karşılaştırması ile eğilim analizini mümkün kılar.

Nereden alınır?

Azure DevOps'taki bir Work Item'ın 'Team Project' alanına karşılık gelir.

Örnekler
E-Ticaret PlatformuMobil Uygulama Yeniden BaşlatmaVeri Ambarı Modernizasyonu
Pull Request Kimliği
PullRequestId
Geliştirme öğesiyle ilişkilendirilmiş pull request'in tanımlayıcısıdır.
Açıklama

Bu öznitelik, bir iş öğesini kod değişikliklerinin gönderilip incelendiği belirli bir pull request'e bağlar. Tek bir iş öğesi birden fazla pull request ile ilişkilendirilebilir.

Pull Request ID, kod inceleme ve entegrasyon aşamalarının daha ayrıntılı analiz edilmesini sağlar. Pull request'in oluşturulmasından tamamlanmasına kadar geçen süreyi ölçmek ve pull request'lerin ne sıklıkla reddedildiğini veya önemli değişiklikler gerektirdiğini analiz etmek için kullanılabilir. Bu durum, kod kalitesinin veya gereksinimlerin netliğinin bir göstergesi olabilir.

Neden önemli?

Geliştirme çalışmasını belirli kod inceleme etkinliklerine bağlar ve kod entegrasyonu ile kalite güvence sürecinin ayrıntılı analizini mümkün kılar.

Nereden alınır?

Bu bilgi, Azure DevOps'ta bir iş öğesinin 'Links' veya 'Development' bölümünde bulunur.

Örnekler
452145334589
Yineleme Yolu
IterationPath
Geliştirme sprint'i veya zaman kutusudur; iş öğesi bu döneme atanır.
Açıklama

Iteration Path veya sprint, geliştirme için belirlenmiş ve süresi sınırlı bir dönemi ifade eder. İş öğeleri, bu süre içinde tamamlanmak üzere bir yinelemeye atanır.

Iteration Path'e göre yapılan analiz, süreç performansını sprint bazında anlamaya yardımcı olur. Ardışık sprint'lerde cycle time'ın iyileşip iyileşmediğini izlemek, devreden işleri analiz etmek ve sprint planlamasının öngörülebilirliğini değerlendirmek için kullanılabilir.

Neden önemli?

Sprint bazlı analiz yapılmasını sağlar; ekiplerin zaman içindeki performansını değerlendirmesine ve çevik uygulamalarını geliştirmesine yardımcı olur.

Nereden alınır?

Azure DevOps'taki bir Work Item'ın 'Iteration Path' alanına karşılık gelir.

Örnekler
E-Ticaret Platformu\Sprint 12E-Ticaret Platformu\Sprint 13Mobil Uygulama Yeniden Başlatma\Aşama 2\Sprint 4
Gerekli Önerilen İsteğe bağlı

Yazılım Geliştirme Yaşam Döngüsü Aktiviteleri

Doğru süreç keşfi ve darboğaz tespiti için Event Logunuzda kaydetmeniz gereken temel süreç adımları ve kilometre taşları aşağıdadır.
7 Önerilen 8 İsteğe bağlı
Aktivite Açıklama
Geliştirme başladı
Bu faaliyet, bir geliştiricinin iş öğesi üzerinde aktif olarak çalışmaya başladığını gösterir. İş öğesinin durumunun 'Active', 'In Progress' veya 'Committed' olarak değiştiği tespit edilerek yakalanır.
Neden önemli?

Aktif geliştirme aşamasının başlangıcını gösterir. 'Created' ile 'Development Started' arasındaki sürenin analiz edilmesi backlog kuyruk sürelerini ortaya çıkarır.

Nereden alınır?

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

Yakalayın

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

Olay türü inferred
İş öğesi oluşturuldu
Bu faaliyet, yeni bir User Story, Bug veya Task gibi iş öğesinin oluşturulmasını ifade eder ve geliştirme yaşam döngüsünün başlangıcını gösterir. Azure DevOps Boards'ta yeni bir kayıt kaydedildiğinde açıkça yakalanır.
Neden önemli?

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

Nereden alınır?

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

Yakalayın

İş öğ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 bir 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 incelemesine gerçekleşen önemli bir devirdir. İzlenmesi, kodlama süresinin ölçülmesine ve kodun akran incelemesine ne zaman hazır olduğunun belirlenmesine yardımcı olur.

Nereden alınır?

Azure Repos verilerinden, pull request oluşturma olayının ilişkili iş öğesiyle bağlanmasıyla alınır. Bu bağlantı çoğu zaman geliştirici tarafından açıkça oluşturulur.

Yakalayın

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

Olay türü explicit
Pull Request tamamlandı
Bir pull request'in onaylandığı ve kodun hedef dala birleştirildiği başarılı kod incelemesinin tamamlanmasını ifade eder. Bu olay Azure Repos'ta açıkça kaydedilir.
Neden önemli?

Yaygın bir darboğaz olan kod inceleme aşamasının sona erdiğini gösterir. Pull request'in oluşturulmasıyla tamamlanması arasındaki sürenin analiz edilmesi inceleme çevriminin verimliliğini ortaya çıkarır.

Nereden alınır?

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

Yakalayın

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

Olay türü explicit
QA testi başladı
Resmi kalite güvence testi aşamasının başlangıcını ifade eder. İş öğesinin durumu 'In QA', 'Testing' veya benzer bir değere değiştiğinde anlaşı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ğini anlamak için önemlidir.

Nereden alınır?

System.State alanındaki değişiklik izlenerek iş öğesi geçmişinden 'In QA' veya belirlenmiş başka bir test durumuna geçiş yapıldığı çıkarılır.

Yakalayın

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

Olay türü inferred
UAT Onaylandı
İş birimi paydaşlarının Kullanıcı Kabul Testinden sonra değişiklikleri onayladığını gösterir. Genellikle 'In UAT' durumundan 'UAT Approved' veya 'Ready for Release' durumuna geçişten çıkarılır.
Neden önemli?

Bu, iş öğesinin iş gereksinimlerini karşıladığını ve üretime dağıtıma hazır olduğunu doğrulayan önemli bir onay aşamasıdır.

Nereden alınır?

System.State alanında UAT durumundan onaylanmış veya sürüme hazır bir duruma geçiş tespit edilerek iş öğesi geçmişinden çıkarılır.

Yakalayın

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

Olay türü inferred
Üretime 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 alınan açık bir olaydır.
Neden önemli?

Bu, değerin teslim edildiğini gösteren önemli bir aşamadır. Lead time ve cycle time hesaplamalarının bitiş noktası olarak kullanılır.

Nereden alınır?

Azure Pipelines sürüm hattı verilerinden, özellikle iş öğesine bağlı 'Production' aşamasına dağıtımın tamamlanma olayından alınır.

Yakalayın

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

Olay türü explicit
Build başarılı oldu
Bu faaliyet, yeni değişiklikler dahil olmak üzere kaynak kodunun bir build pipeline tarafından başarıyla derlendiğini ve paketlendiğini doğrular. Azure Pipelines tarafından kaydedilen açık bir olaydır.
Neden önemli?

Yeni kodun entegrasyonunu ve build'in bozulmadan çalışmasını sağlayan önemli bir kalite kapısı görevi görür. Bu aşamadaki hatalar entegrasyon sorunlarına işaret edebilir.

Nereden alınır?

Azure Pipelines build tamamlanma olaylarından alınır. Build'in iş öğesiyle doğrudan veya ilişkili pull request üzerinden ilişkilendirilmesi gerekir.

Yakalayın

Azure Pipelines build tamamlanma olayından alınır.

Olay türü explicit
Geliştirme tamamlandı
Tüm geliştirme ve birim testi faaliyetlerinin tamamlandığını ve iş öğesinin resmi teste hazır olduğunu gösterir. Bu durum genellikle iş öğesi durumunun 'Resolved' veya 'Ready for Test' olarak değişmesinden anlaşılır.
Neden önemli?

Geliştirme ekibinden QA ekibine gerçekleşen önemli bir devri gösterir. 'QA Testing Started' aşamasına kadar geçen sürenin ölçülmesi devir gecikmelerinin belirlenmesine yardımcı olur.

Nereden alınır?

İş öğesi geçmişinde System.State alanının 'Resolved' veya QA'ya hazır olduğunu gösteren özel bir duruma değiştiği tespit edilerek anlaşılır.

Yakalayın

State alanının 'Resolved' olarak değişmesinden anlaşılır.

Olay türü inferred
İş Öğesi İptal Edildi
İş öğesinin iptal edildiğini ve tamamlanmayacağını veya dağıtılmayacağını belirtir. 'Removed', 'Cancelled' veya benzer bir duruma geçişle yakalanır.
Neden önemli?

Bu, sürecin alternatif ve başarısız bir şekilde sonlandığını gösterir. İptal edilen öğelerin analizi, planlama, önceliklendirme veya gereksinim tanımlama sorunlarını ortaya çıkarabilir.

Nereden alınır?

System.State alanı 'Removed' kategorisindeki son bir duruma değiştiğinde iş öğesi geçmişinden çıkarılır.

Yakalayın

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

Olay türü inferred
İş Öğesi Kapatıldı
Dağıtım ve dağıtım sonrası doğrulamalar tamamlandıktan sonra iş öğesinin son kez kapatılmasını ifade eder. 'Closed' veya 'Done' durumuna geçişle yakalanır.
Neden önemli?

Bu etkinlik, bir iş öğesi için tüm sürecin nihai ve başarılı şekilde tamamlandığını gösterir. Yaşam döngüsünün kesin bitiş noktasıdır.

Nereden alınır?

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

Yakalayın

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

Olay türü inferred
İş öğesi onaylandı
Bir iş öğesinin resmi olarak onaylandığını, iyi tanımlandığını ve geliştirmeye hazır olduğunu gösterir. Bu durum genellikle 'State' alanının 'Approved' veya 'Ready for Dev' gibi bir değere değişmesinden anlaşılır.
Neden önemli?

Onayları izlemek, fikrin sunulmasıyla geliştirme taahhüdü arasındaki süreyi analiz etmeye yardımcı olur. 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 tespit edilerek anlaşılır.

Yakalayın

State alanının 'Approved' olarak değişmesinden anlaşılır.

Olay türü inferred
QA Testi Başarısız
İş öğesinin kalite güvence testini geçemediğini ve geliştirmeye geri gönderildiğini belirtir. Bu durum, test durumundan 'In Progress' veya 'Active' durumuna geri geçişle yakalanır.
Neden önemli?

Bu etkinlik, yeniden çalışma döngülerini belirlemek için gereklidir. Bu olayın 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ş tespit edilerek çıkarılır.

Yakalayın

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. İş öğesi durumu bir test durumundan 'Ready for UAT' veya 'QA Approved' gibi bir duruma değiştiğinde çıkarılır.
Neden önemli?

Bu, öğenin kullanıcı kabul testine veya sürüme hazır olduğunu gösteren önemli bir kalite kapısıdır. Bu noktadan sonraki gecikmeler, UAT veya sürüm planlamasındaki darboğazlara işaret edebilir.

Nereden alınır?

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

Yakalayın

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

Olay türü inferred
UAT Başladı
İş birimi paydaşlarının işlevselliği doğruladığı Kullanıcı Kabul Testinin başlangıcını ifade eder. Genellikle durumun 'In UAT' veya benzer bir duruma değişmesinden çıkarılır.
Neden önemli?

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

Nereden alınır?

System.State alanı 'In UAT' gibi UAT'yi temsil eden özel bir duruma güncellendiğinde iş öğesi geçmişinden çıkarılır.

Yakalayın

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

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

Veri çıkarma rehberleri

Verilerinizi Azure DevOps'tan 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ü optimize etmeye bugün başlayın. Bu Template, değerli süreç içgörülerine ulaşmanız için ilk adımınızdır.

Azure DevOps'ta SDLC'nizi optimize edin, bugün başlayın!

SDLC iş akışınızdaki çevrim süresini %30 azaltın ve darboğazları ortadan kaldırın.

Ücretsiz denemenizi başlatın

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