Aracılığıyla paylaş

Kümülatif akış, sağlama süresi ve döngü süresi kılavuzu

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Bir sistem üzerinden iş akışını izlemek için kümülatif akış diyagramlarını (CFD) kullanabilirsiniz. Döngü süresi ve sağlama süresi, izleme için kullanılan iki birincil ölçümdür. Bu ölçümleri CFD'den ayıklayabilirsiniz.

Bu makalede, iş sürecinizdeki sorunları belirlemek ve işleri sisteminizde taşımanıza yardımcı olmak için CFD'leri, döngü sürelerini ve sağlama sürelerini nasıl kullanabileceğiniz gösterilmektedir.

Örnek grafikler ve birincil ölçümler

Sürekli akış CFD'si, yalın bir süreci izleyen ekipler tarafından en çok tercih edilen grafiği sağlar.

Ancak birçok ekip, yalın uygulamaları Scrum veya diğer yöntemlerle birleştirir. Sonuç olarak, bir yineleme veya sprint süresince yalın uygulamaları kullanırlar. Bu durumda diyagram biraz farklı bir görünüm alır. Sonraki grafikte gösterildiği gibi sabit dönem CFD'sinde gösterildiği gibi iki ek ve çok değerli bilgi sağlar.

Sürekli akış CFD
Soyut bir sürekli akış CFD'sini gösteren grafik. Etiketler sağlama süresini, döngü süresini, devam eden çalışmayı ve çeşitli durumlardaki öğeleri gösterir.

Bu sabit dönemLI CFD tamamlanmış bir sprint içindir.

Üst satır sprint için ayarlanan kapsamı temsil eder. Çalışmanın sprint'in son gününe kadar tamamlanması gerektiğinden, Kapalı durumunun eğimi bir ekibin sprint'i tamamlamak için yolda olup olmadığını gösterir. Bu görünümü düşünmenin en kolay yolu, bir yanmış grafiktir.

Grafikte, işlemin ilk adımı sol üst alan olarak gösterilir. İşlemin son adımı sağ alt alan olarak gösterilir.

Tamamlanmış sprint için sabit süreli CFD
Soyut bir sabit dönem CFD'sini gösteren grafik. Etiketler etkin, çözümlenmiş ve kapatılan öğeleri ve kapsam değişikliğini gösterir.

Grafik ölçümleri

CFD'ler zaman içinde duruma veya sütuna göre gruplandırılmış iş öğelerinin sayısını görüntüler. İzleme için kullanılan iki birincil ölçüt, döngü süresi ve öncülük süresidir. Bu ölçümleri grafikten ayıklayabilirsiniz.

Ölçüm

Tanım

Döngü süresi1

Tek bir süreç veya iş akışı durumunda çalışmanın ilerlemesi için gereken süre. Uzunluk, bir işlemin başlangıcından sonraki işlemin başlangıcına kadar ölçülür.

Teslim süresi1

Sürekli akış işlemi için: Bir isteğin yapıldığı (önerilen bir kullanıcı hikayesi ekleme gibi) andan itibaren, isteğin tamamlandığı (kapatıldığı) zamana kadar geçen süre.

Sprint veya sabit dönemli bir işlem için: İstek üzerinde çalışmanın başladığı zaman, çalışma tamamlanana kadar (örneğin, Etkin durumundan Kapalı durumuna kadar olan süre).

Devam eden çalışma (WIP)

Etkin olarak üzerinde çalışılan iş miktarı veya iş öğesi sayısı.

Kapsam

Belirli bir süre için taahhüt edilen çalışma miktarı. Bu ölçüm yalnızca sabit dönemli işlemler için geçerlidir.

1 Analiz verilerini kullanan CFD pencere öğesi ve ekip iş listesi veya tahtasından görüntüleyebileceğiniz yerleşik CFD, teslim süresi ve döngü süresi değerlerini ayrı olarak sağlamaz. Ancak Öncelik Süresi ve Döngü Süresi pencere öğeleri bu değerleri sağlar.

Sağlama süresi veya döngü süresi ile WIP arasında iyi tanımlanmış bir bağıntı vardır. Daha fazla WIP, daha uzun çevrim sürelerine neden olur, bu da daha uzun teslim sürelerine yol açar. Bunun tersi de geçerlidir; daha az İş Süreci (WIP), daha kısa çevrim ve teslim sürelerine yol açar. Geliştirme ekibi daha az öğeye odaklandığında döngüyü ve sağlama sürelerini azaltır. Bu bağıntı, çalışmayı izlemek ve yönetmek için kullandığınız panoda WIP sınırları belirlemenizin önemli bir nedenidir.

İş öğelerinin sayısı, belirli bir gündeki toplam çalışma miktarını gösterir. Sabit dönemLI CFD'de, bu sayıdaki bir değişiklik belirli bir dönem için kapsam değişikliğini gösterir. Sürekli akış CFD'sinde, kuyrukta bulunan ve belirli bir gün için tamamlanan toplam çalışma miktarını gösterir.

Çalışmayı belirli pano sütunlarına kategorilere ayırmak, işlemin her alanındaki çalışma miktarını gösterir. Bu görünüm, işin nerede sorunsuz bir şekilde ilerlediğini, nerede tıkanmalar olduğunu ve hiçbir işin yapılmadığı yerleri hakkında içgörüler sağlar. Verilerin tablosal görünümünü çözmek zordur. Ancak görsel CFD, iş sürecinizde neler olduğunu ve bunun neden gerçekleştiğini anlamanıza yardımcı olur.

Sorunları tanımlama ve uygun eylemleri gerçekleştirme

CFD aşağıdaki soruların yanıtlarını sağlar. Yanıtlara bağlı olarak, sistemde işleri ilerletmeniz için süreci ayarlayabilirsiniz.

Ekip çalışmayı zamanında tamamlayacak mı?

Bu soru yalnızca sabit dönemLI CFD'ler için geçerlidir. Panonun son sütunundaki çalışmanın eğrisine (veya ilerlemesine) bakarak bir anlayış kazanabilirsiniz.

Yarım tamamlanmış cfd gösteren grafik. Tamamlanan öğeler için öngörülen eğri, sprint'in sonundaki kapsam düzeyinin altındadır.

Bu senaryoda, yinelemedeki çalışma kapsamını azaltmayı düşünebilirsiniz. Bu eylem, kararlı bir hızda devam ettiğini varsayarak işin yeterince hızlı tamamlanmadığının açıkça anlaşıldığı durumlarda uygundur. Bu senaryo, çalışmanın hafife alındığını ve bir sonraki sprint planlamasına dahil edilmesi gerektiğini gösterebilir.

Ancak, çalışmanın yeterince hızlı tamamlanmamasının başka nedenleri de olabilir. Grafikteki diğer verilere bakarak bu nedenleri belirleyebilirsiniz.

İş akışı nasıl ilerliyor?

Ekip çalışmayı düzenli bir hızda tamamlar mı? Bunu anlamanın bir yolu, grafikteki çeşitli sütunlar arasındaki aralıklara bakmaktır. Baştan sona benzer veya tekdüzen bir mesafedeler mi? Birden çok günlük bir süre boyunca düz çizgi olarak görünen sütunlar var mı? Ya da kabarmış gibi görünen var mı?

Mura veya eşitsizlik, düz çizgiler ve kabarıklıklar için yalın bir terimdir. Mura, sistemde bir tür atık (Muda) olduğunu gösterir. Sistemdeki herhangi bir eşitsizlik CFD'de kabarıklıkların görünmesine neden olur.

CFD'nin düz çizgiler ve kabarıklıklar için izlenmesi, Kısıtlamalar Teorisi proje yönetimi sürecinin önemli bir bölümünü destekler. Sistemin en yavaş bölgesini yönetmek, çalışma planlamasının bir parçası olarak tambur-tampon-halat metodu şeklinde adlandırılır.

İki sorun görsel olarak düz çizgiler ve kabarıklıklar olarak gösterilir.

Ekip, iş öğelerinin durumunu düzenli bir tempoyla güncelleştirmediğinde düz çizgiler görüntülenir. Çalışmayı izlemek ve yönetmek için kullandığınız pano, çalışmayı bir sütundan diğerine dönüştürmenin en hızlı yolunu sağlar.
Düz çizgiler, bir veya daha fazla işlemdeki çalışma planlanandan uzun sürdüğünde de görünebilir. Sistemin birçok bölümünde düz çizgiler görünür, çünkü yalnızca bir veya iki bölümde sorun varsa, bir kabarıklık görürsünüz.

Düz çizgiler
Soyut CFD grafiği. Etkin, çözümlenmiş ve kapatılan madde sayısı için satırlar, önemli sayıda zaman aralığı için düz olur.

Çalışma sistemin bir bölümünde biriktiğinde ve bir işlemde ilerlemediğinde bulgeler oluşur.
Örneğin, test uzun sürdüğü ancak geliştirmenin daha az zaman aldığı durumlarda bir şişkinlik oluşabilir. Sonuç, çalışmanın geliştirme aşamasında birikmesidir. Şişkinlikler, sonradan gelen bir adımın sorun yaşadığını belirtir, şişkinliğin oluştuğu adım olması gerekmez.

Çıkıntı
Soyut CFD grafiği. Etkin öğeler için alan grafiğin sağ alt köşesine doğru dolgunlaşır.

Akış sorunlarını nasıl düzeltirsiniz?

Aşağıdaki eylemleri gerçekleştirerek zamanında güncelleştirme olmaması sorununu çözebilirsiniz:

  • Günlük stand-up toplantılarını düzenleme
  • Diğer düzenli toplantıları düzenleme
  • Günlük takım hatırlatma e-postası planlama

Sistemik düz çizgi sorunları daha zorlu bir soruna işaret eder, ancak bu tür sorunlar nadirdir. Düz çizgiler, sistem genelinde çalışmanın durdurulduğunu gösterir. Temel nedenler aşağıdaki sorunları içerebilir:

  • İşlem genelinde tıkanıklıklar
  • İşlemler uzun sürüyor
  • Başka fırsatlara doğru gerçekleşen iş değişimi, panoda yakalanmamış durumda.

Sistemsel durgunluğun bir örneği HHA (Hesaplamalı Hidrodinamik) özelliklerinde ortaya çıkabilir. Özellikler birkaç hikayeden oluştuğundan özellik çalışması, kullanıcı hikayeleri üzerinde çalışmaktan önemli ölçüde daha uzun sürebilir. Bu gibi durumlarda eğim beklenir (önceki örnekte olduğu gibi) veya sorun iyi bilinmektedir ve ekip bunu zaten ortaya çıkarmıştır. Bu bilinen bir sorunsa, sorun çözümü bu makalenin kapsamı dışındadır.

Ekipler CFD çıkıntıları olarak görünen sorunları proaktif olarak çözebilir. Uygun olan düzeltme, bulgenin nerede oluştuğuna bağlı olabilir. Örnek olarak, bulgenin geliştirme sürecinde gerçekleştiğini varsayalım. Şişkinliğin, test etmenin kod yazmaktan çok daha uzun sürmesi nedeniyle gerçekleşiyor olabilir. Test ediciler çok sayıda hata da buluyor olabilir. Geliştiriciler, çalışmayı sürekli olarak geliştiricilere geri döndürdüğünüzde, artan bir etkin çalışma listesini devralır.

Bu sorunu çözmenin iki kolay yolu vardır:

  • Geliştiricileri, geliştirme sürecinden test sürecine geçirin ve oluşan yığın ortadan kaldırılana kadar bu şekilde çalışmaya devam edin.
  • çalışma sırasını değiştirin. Özellikle, hızlı bir şekilde yapılabilen işleri, daha uzun süren işlerle birleştirin.

Şişkinlikleri ortadan kaldırmak için temel çözümleri arayın.

Not

Çalışmanın düzensiz ilerlemesine neden olan çeşitli senaryolar ortaya çıkabileceğinden, sorunun gerçek bir analizini gerçekleştirmeniz kritik önem taşır. CFD size bir sorun olduğunu söyleyebilir. Ayrıca sorunun yaklaşık olarak nerede olduğunu da söyleyebilir, ancak kök nedenlere ulaşmak için araştırmanız gerekir. Bu kılavuz belirli sorunları çözen önerilen eylemler sağlar, ancak çözümler durumunuz için geçerli olmayabilir.

Kapsam değişti mi?

Kapsam değişiklikleri yalnızca sabit dönemLI CFD'ler için geçerlidir. Grafiğin üst satırı, çalışma kapsamını gösterir. Sprint, ilk gün yapılacak iş ile önceden yüklenir. Üst satırda yapılan değişiklikler, işin eklenmesini veya kaldırılmasını gösterir.

Belirli bir senaryoda cfd ile kapsam değişikliklerini izleyemezsiniz. Bu senaryo, aynı gün aynı sayıda iş öğesi eklendiğinde ve kaldırıldığında oluşur. Bu durumda çizgi düz kalır.

Bu durumda kapsam değişikliklerini izlemek için aşağıdaki eylemleri gerçekleştirin:

  • Birkaç grafiği birbiriyle karşılaştırın.
  • Belirli sorunları izleyin.
  • Kapsam değişikliklerini izlemek için sprint burndown kullanın.

Çok fazla WIP var mı?

WIP sınırlarının aşılıp aşılmadığını belirlemek için kartı kolayca izleyebilirsiniz. CFD'yi kullanarak WIP düzeylerini de izleyebilirsiniz.

Büyük miktarda WIP genellikle dikey bir bulge olarak gösterilir. WIP miktarı ne kadar büyük ve uzun süreli olursa, kabarıklık o kadar oval bir şekil alır. Bu davranış, WIP'nin döngüyü ve sağlama süresini olumsuz etkilediğinin bir göstergesidir.

İşler üzerinde çalışma için iyi bir kural: Herhangi bir zamanda, takım üyesi başına en fazla iki iş bulunmalıdır. Daha katı bir sınır değil, iki öğelik bir sınır kullanmanın temel nedeni, gerçekliğin yazılım geliştirme sürecine sıklıkla müdahale ediyor olmasıdır.

Bazen bir paydaştan bilgi almak veya gerekli yazılımları almak zaman alır. çalışmanın durdurulmasının çeşitli nedenleri vardır. İkinci bir iş öğesine odaklanabilmek biraz esneklik sağlayabilir. Her iki öğe de engellenirse, engeli kaldırılan bir öğeyi almak için kırmızı bayrak eklemenin zamanı geldi; yalnızca başka bir öğeye geçiş yapma zamanı değil. Devam eden çok sayıda öğe olduğunda, bu öğeler üzerinde çalışan kişi bağlamı değiştirmekte zorlanabilir. Muhtemelen ne yaptıklarını unuturlar ve bu da hatalara yol açabilir.

Sağlama süresi ile döngü süresi karşılaştırması

Aşağıdaki diyagram, tedarik süresinin döngü süresinden nasıl farklı olduğunu gösterir. Sağlama süresi, iş öğesi oluşturulduğunda başlar ve iş öğesi Tamamlandı durum kategorisine girdiğinde biter. Döngü süresi, bir iş öğesinin devam eden veya Çözümlenen durum kategorisine ilk kez girmesiyle başlar. çalışma öğesi Tamamlandı durum kategorisine girdiğinde döngü süresi sona erer.

Durum kategorilerinin döngü süresini ve sağlama süresini ölçmek için nasıl kullanıldığını gösteren diyagram.

Bir iş öğesi Tamamlandı durum kategorisine girer ve sonra yeniden etkinleştirilirse, geçen süre ve döngü süreleri etkilenir. Teklif Edilen, Devam Eden veya Çözümlenmiş durum kategorisinde harcadığı ek süreler, öncülük ve çevrim sürelerine katkıda bulunur.

Ekibiniz çalışmayı izlemek ve yönetmek için bir pano kullanıyorsa, sütunlarınızın iş akışı durumlarına nasıl eşlediğini anlamanıza yardımcı olur. Panonuzu yapılandırma hakkında daha fazla bilgi için bkz. Panonuzdaki sütunları yönetme.

Sistemin Önerilen, Devam Ediyor, Çözüldü ve Tamamlandı durum kategorilerini nasıl kullandığı hakkında daha fazla bilgi için Backloglar ve panolardaki iş akışı durumları hakkında bölümüne bakın.

Teslimat süreçlerini teslimat öncesi ve döngü sürelerine göre tahmin et

Ortalama öncü ve döngü süreleriniz ile standart sapmalarınızı kullanarak teslimat sürelerini tahmin edebilirsiniz.

Bir iş öğesi oluşturduğunuzda, bu iş öğesinin tamamlanma tarihini tahmin etmek için ekibinizin ortalama sağlama süresini kullanabilirsiniz. Ekibinizin standart sapması, tahminin değişkenliğini gösterir. Benzer şekilde, iş başladıktan sonra bir iş öğesinin tamamlanmasını tahmin etmek için döngü sürenizi ve standart sapması kullanabilirsiniz.

Örnek Döngü Süresi pencere öğesi

Aşağıdaki grafikte ortalama döngü süresi sekiz gündür. Standart sapma altı gündür. Bu verileri kullanarak, ekibin çalışmaya başladıktan yaklaşık 2-14 gün sonra gelecek kullanıcı hikayelerini tamamladığını tahmin edebilirsiniz. Standart sapma ne kadar dar olursa tahminleriniz o kadar tahmin edilebilir olur.

Döngü Zamanı pencere öğesinin ekran görüntüsü. Dağılım grafiğinde iş öğeleri için noktalar, hareketli ortalama çizgisi ve standart sapma bandı bulunur.

İşlem sorunlarını tanımlama

Aykırı değerler genellikle temel alınan bir işlem sorununu temsil eder. Örnekler arasında çekme isteklerini gözden geçirmeyi çok uzun süre ertelemek veya dış bağımlılığı hızlı bir şekilde çözmemek yer alır. Aykırı değerler için ekibinizin denetim grafiğini gözden geçirin.

Birkaç aykırı değeri gösteren Örnek Döngü Süresi pencere öğesi

Aşağıdaki grafik birkaç aykırı değerleri gösterir çünkü birkaç hatanın tamamlanması ortalamadan uzun sürdü. Bu hataların neden daha uzun sürdüğünü araştırmak işlem sorunlarının ortaya çıkarılmasına yardımcı olabilir. süreç sorunlarının giderilmesi, ekibinizin standart sapması azaltmaya ve ekibinizin öngörülebilirliğini artırmaya yardımcı olabilir.

Döngü Zamanı pencere öğesinin ekran görüntüsü. Birkaç iş öğesi noktası hareketli ortalama çizginin ve standart sapma bandının çok üstündedir.

İşlem değişikliklerinin öncü ve çevrim sürelerinizi nasıl etkilediğini de görebilirsiniz. Örneğin, 15 Mayıs'ta ekip WIP'yi sınırlamak ve eski hataları gidermek için büyük çaba sarf etti. Standart sapmanın bu tarihten sonra daraldığını ve daha iyi tahmin edilebilirlik gösterdiğini görebilirsiniz.

Sonraki adımlar

Kümülatif akış diyagramını görüntüleme ve yapılandırma

Sağlama Süresi ve Döngü Süresi pencere öğeleri