Tedarik süresi ve döngü süresi için kümülatif akış kılavuzu

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Kümülatif akış diyagramları (CFD) sisteminizdeki iş akışını görselleştirerek iş sürecinizi izlemenize yardımcı olur. Bu makalede, sorunları belirlemek ve iş akışı verimliliğini artırmak için CFD'lerin, döngü sürelerinin ve sağlama sürelerinin nasıl kullanılacağı açıklanmaktadır.

Yalın bir süreci izleyen ekiplerin en çok tercih ettiği grafik, sürekli akış CFD'sidir.

Ancak birçok ekip, yalın uygulamaları Scrum veya diğer yöntemlerle birleştirir. Bir yineleme veya sprint sırasında yalın uygulamaları kullanırlar. Bu durumda diyagram biraz farklı görünür. Bu iki ekstra özelliği gösterir: Sürekli akış CFD, yalın süreçleri izleyen ekiplerin çoğu tarafından tercih edilen grafiktir.

Ancak birçok ekip, yalın uygulamaları Scrum veya diğer yöntemlerle birleştirir. Bir yineleme veya sprint sırasında yalın uygulamaları kullanırlar. Bu durumda diyagram biraz farklı görünür. Bir sonraki grafikte gösterildiği gibi sabit dönem CFD'sinde gösterildiği gibi ek, değerli iki bilgi parçası gösterir. 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ış sprint'i gösterir.

Üst satır, sprint için belirtilen kapsamı gösterir. Çalışmanın son güne kadar bitmesi gerektiğinden, Kapalı durumundaki eğim bir ekibin doğru yolda olup olmadığını gösterir. Bu görünümü bir burnup grafiği olarak düşünün.

Grafikte, işlemin ilk adımı sol üst alandadır. Son adım sağ alt alandadır.

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 metrikleri

CFD'ler zaman içinde duruma veya sütuna göre gruplandırılmış iş öğelerinin sayısını gösterir. İzleme için iki birincil ölçüm, döngü süresi ve tedarik süresidir. Bu ölçümleri grafikten ayıklarsınız.

Ö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. Bir işlemin başlangıcından sonraki işlemin başlangıcına kadar olan uzunluğu ölçün.

Teslim süresi1

Sürekli akış işlemi için: bir isteğin yapıldığı zaman (önerilen kullanıcı hikayesi ekleme gibi) istek tamamlanana kadar (kapatılır).

*c0>Sürekli akış süreci için: bir isteğin yapıldığı an (önerilen bir kullanıcı hikayesi eklenmesi gibi) istek tamamlanana kadar (kapatılır).

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 devam eden iş miktarı veya iş öğesi sayısı.

Kapsam

Verilen dönem 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 net bir bağıntı vardır. Daha fazla WIP, daha uzun döngü sürelerine ve daha uzun sağlama sürelerine yol açar. Tam tersi de geçerlidir; daha az WIP daha kısa döngüye ve sağlama 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ını ayarlamanın ö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, söz konusu dönem için kapsam değişikliği anlamına gelir. Sürekli akış CFD'sinde kuyrukta olan 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ıkanıklıklar olduğunu ve hiçbir işin yapılmadığı yerleri hakkında içgörü sağlar. Verilerin tablosal görünümünü anlamak zor olsa da görsel CFD, iş sürecinizde neler olduğunu ve neden olduğunu görmenize 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ılar
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.

Bir özellik CFD'sinde sistemik düz astar örneği oluşabilir. Özellikler birkaç hikayeden oluştuğundan özellik çalışması kullanıcı hikayelerinde çalışmaktan daha uzun sürebilir. Bu gibi durumlarda eğim beklenen bir durumdur (önceki örnekte olduğu gibi) veya sorun iyi bilinmektedir ve ekip bunu zaten ortaya çıkarmış durumdadır. Bu bilinen bir sorunsa, sorun çözümü bu makalenin kapsamı dışındadır.

Ekipler, CFD çıkıntıları şeklinde 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şkinlik, test etme süresi kod yazmaktan daha uzun sürdüğü için meydana geliyor olabilir. Test ediciler çok sayıda hata da buluyor olabilir. Geliştiricilere sürekli olarak iş geri aktarıldığında, geliştiriciler artan bir aktif iş 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 çıkıntı olarak görünür. 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ş öğesinin bakımı, beklenmeyen gecikmeler sırasında operasyonel esneklik sağlar. 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.

Tedarik süresi ile döngü süresi karşılaştırması

Aşağıdaki diyagramda, sağlama süresi ve döngü süresinin nasıl farklı olduğu gösterilmektedir. 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ş öğesi Devam Ediyor veya Çözüldü durum kategorisine girdiğinde başlar ve Tamamlandı durum kategorisine girdiğinde biter.

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

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şlenip eşlenmediğini anlamak, çalışmayı daha etkili bir şekilde yönetmenize yardımcı olur. Panonuzu ayarlamayı öğrenmek için bkz. Panonuzdaki sütunları yönetme.

Sistemin durum kategorilerini (Önerilen, Devam Ediyor, Çözüldü, Tamamlandı) nasıl kullandığını öğrenmek için bkz. Geri dönüş listelerinde ve panolarda iş akışı durumları hakkında.

Döngü süresi yeniden etkinleştirilen iş öğelerini nasıl işler?

Yeniden etkinleştirilen iş öğeleri için ( Tamamlandı durumundan Devam Ediyor durumuna geri taşınır), döngü süresi, iş öğesinin devam eden veya Çözümlenen durum kategorisine ilk girdiği ilk seferden başlar ve Tamamlandı durum kategorisine son girişinde biter. Döngü süresi, yeniden etkinleştirmeden sonraki süreler de dahil olmak üzere tüm etkin çalışma dönemini içerir.

Örnek senaryo:

  • Yeni → Etkin → Çözüldü → Kapatıldı → Yeni → Etkin → Kapatıldı
  • Döngü süresi hesaplaması: İlk geçişten Etkin'e son geçişten Kapalı'ya
  • Toplam döngü süresi: Yeniden etkinleştirmeden önce hem etkin çalışma dönemlerini hem de Kapalı durumdaki süreyi içerir

Bu hesaplama yöntemi, yeniden çalışma veya yeniden etkinleştirme sonrasındaki ek çabalar dahil olmak üzere iş öğesini tamamlamak için gereken toplam sürenin tam bir resmini verir. Öncül süre hesaplaması aynı ilkeyi izler; herhangi bir ara tamamlanmış durumdan bağımsız olarak, iş öğesi oluşturmadan son tamamlamaya kadar tüm süreyi kapsar.

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

Teslimat sürelerini tahmin etmek için ortalama öncül ve döngü sürelerinizi ve standart sapmalarınızı kullanın.

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

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

Aşağıdaki grafikte ortalama döngü süresi sekiz gündür ve standart sapma altı gündür. Bu verilerle, ekibin gelecekteki kullanıcı hikayelerini iş başladıktan yaklaşık 2-14 gün sonra tamamladığını tahmin edin. Daha dar bir standart sapma, tahminlerinizi daha öngörülebilir hale getirir.

Döngü Zamanı widget'ının ekran görüntüsü. Dağılım grafiği, iş öğelerinin noktalarını, hareketli ortalama çizgisini ve standart sapma bandını gösterir.

İşlem sorunlarını tanımlama

Temelde bir süreç sorunu olduğunu genellikle aykırı değerler ifade eder. Örneğin, pull isteklerini gözden geçirmek için çok uzun süre beklemek veya dış bağımlılığı hızlı bir şekilde düzeltmemek. ** Aykırı değerleri tespit etmek için ekibinizin kontrol grafiğini kontrol edin.

Örnek döngü süresi widget'ı, birkaç aykırı değeri gösteriyor

Aşağıdaki grafikte, bazı hataların ortalama süreden daha uzun sürmesi nedeniyle birkaç aykırı değer gösterilmektedir. Bu hataların neden daha uzun sürdüğünü denetlemek, işlem sorunlarını bulmanıza yardımcı olabilir. Süreç sorunlarının düzeltilmesi, ekibinizin standart sapmasında azalmaya yardımcı olur ve ekibinizin tahmin edilebilirliğini artırır.

Döngü süresi 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ülük ve döngü sürelerinizi nasıl etkilediğini de görürsünüz. Örneğin, 15 Mayıs'ta ekip WIP'yi sınırlamak ve eski hataları düzeltmek için çalıştı. Standart sapma bu tarihten sonra daralır ve daha iyi tahmin edilebilirlik gösterir.

Sonraki adım

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

  • Last updated on