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 | TFS 2018

Bir sistem üzerinden iş akışını izlemek için kümülatif akış diyagramları (CFD) kullanırsınız. İzlemek için iki birincil ölçüm olan döngü süresi ve sağlama süresi grafikten ayıklanabilir. CFD grafiklerini yapılandırmak veya görüntülemek için bkz. Kümülatif akış grafiği yapılandırma.

Ö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ştirmeye başlamıştır. Bu da bir yineleme veya sprint süresi içinde yalın çalışma yaptıkları anlamına gelir. Bu durumda diyagram biraz farklı bir görünüme sahip olur ve sonraki grafikte gösterildiği gibi iki ek ve çok değerli bilgi parçası sağlar.

Sürekli akış
CFD ölçümlerinin kavramsal görüntüsü.

Burada gösterilen Sabit dönem CFD'si tamamlanmış bir sprint içindir.

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

Veriler her zaman işlemin ilk adımı sol üst, son adım ise sağ altta gösterilir.

Tamamlanmış sprint için sabit dönem CFD'si
CFD ölçümleri, sabit dönem.

Grafik ölçümleri

CFD grafikleri zaman içinde durum/Kanban sütununa göre gruplandırılmış iş öğelerinin sayısını görüntüler. İzlemek için iki birincil ölçüm olan döngü süresi ve sağlama süresi grafikten ayıklanabilir.


Ölçüm

Tanım


Döngü Süresi1

Çalışmayı tek bir işlem veya iş akışı durumunda taşımak için gereken süreyi ölçer. Hesaplama, bir işlemin başlangıcından sonraki işlemin başlangıcına kadardır.

Sağlama Süresi1

Sürekli akış işlemi için: İstek tamamlanana (kapatılana kadar) bir istek yapıldığında geçen süreyi ölçer (önerilen bir kullanıcı hikayesi ekleme gibi).

Sprint veya sabit dönem işlemi için: bir istek üzerinde çalışmanın başlamasından çalışma tamamlanana kadar olan süreyi (etkin olandan kapalıya kadar olan süreyi) ölçer.

Devam Eden Çalışma

Etkin olarak çalıştırılan çalışma miktarını veya iş öğelerinin sayısını ölçer.

Kapsam

Belirli bir süre için yürütülen çalışma miktarını temsil eder. Yalnızca sabit dönemli işlemler için geçerlidir.


1 CFD pencere öğesi (Analiz) ve yerleşik CFD grafiği (iş izleme veri deposu) Sağlama Süresi ve Döngü Süresi ile ilgili ayrık sayılar sağlamaz. Ancak , Sağlama Süresi ve Döngü Süresi pencere öğeleri bu sayıları sağlar.

Sağlama Süresi/Döngü Süresi ile Devam Eden Çalışma (WIP) arasında iyi tanımlanmış bir bağıntı vardır. WIP ne kadar uzun olursa, döngü süresi o kadar uzun olur ve bu da daha uzun sağlama sürelerine yol açar. Tam tersi de geçerlidir; WIP ne kadar az olursa döngü ve sağlama süresi de o kadar kısa olur. Geliştirme ekibi daha az öğeye odaklandığında döngüyü ve sağlama sürelerini azaltır. Bu bağıntı, Kanban panosunda Devam Eden Çalışma sınırlarını ayarlayabilmenizin ve ayarlamanız gerektiğinin önemli bir nedenidir.

İş öğelerinin sayısı, belirli bir gündeki toplam çalışma miktarını gösterir. Sabit dönem CFD'sinde, 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, kuyruktaki ve belirli bir gün için tamamlanan toplam çalışma miktarını gösterir.

Çalışmayı belirli Kanban panosu sütunlarına ayırmak, çalışmanın devam ettiği bir görünüm sağlar. Bu görünüm, işin nerede sorunsuz ilerlediğini, engellemelerin nerede 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 grafiği belirli bir şekilde bir şeyler olduğuna dair kanıt sağlar.

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

CFD çeşitli belirli soruları yanıtlar ve yanıta bağlı olarak, işlemi sistem üzerinden taşıma işlemini ayarlamak için eylemler yapılabilir. Bu soruların her birine burada göz atalım.

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

Bu soru yalnızca sabit dönem CFD'leri için geçerlidir. Kanban panosunun son sütunundaki çalışmanın eğrisine (veya ilerlemesine) bakarak bir anlayış elde edebilirsiniz.

Yarım tamamlanmış bir grafikle örnek CFD, noktalı çizgiler çalışmanın tamamlanmayacağını gösteriyor

Bu senaryoda, kararlı bir hızda çalışmanın yeterince hızlı tamamlanmaması durumunda yinelemedeki çalışma kapsamının azaltılması uygun olabilir. Çalışmanın hafife alındığını ve sonraki sprint planlamasına dahil edilmesi gerektiğini gösterebilir.

Ancak grafikteki diğer verilere bakarak belirlenebilecek başka nedenler de olabilir.

İş akışı nasıl ilerliyor?

Ekip çalışmayı düzenli bir hızda tamamlar mı? Bunu söylemenin bir yolu, grafikteki farklı sütunlar arasındaki aralıklara bakmaktır. Başlangıçtan sona kadar birbirlerine benzer veya tekdüzen bir uzaklıktalar mı? Bir sütun birden çok günlük bir süre boyunca düz çizgi olarak görünüyor mu? Yoksa"bülge" gibi mi görünüyor?

Düz çizgiler ve çıkıntılar için yalın terim olan Mura, eşitsizlik anlamına gelir ve sistemde bir atık biçimini (Muda) gösterir. Sistemdeki herhangi bir eşitsizlik CFD'de kabarıklıkların görünmesine neden olur.

CFD'nin düz çizgiler ve çıkıntılar için izlenmesi, Kısıtlamalar Teorisi proje yönetimi sürecinin önemli bir bölümünü destekler. Sistemin en yavaş alanını korumak, drum-buffer-rope işlemi olarak adlandırılır ve çalışmanın planlanma şeklinin bir parçasıdır.

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

Ekip çalışmalarını düzenli bir tempoyla güncelleştirmediğinde düz çizgiler görünür. Kanban panosu, ç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 daha uzun sürdüğünde de görünebilir. Sistemin birçok bölümünde düz çizgiler görünür, çünkü sistemin yalnızca bir bölümünde veya iki bölümünde sorun varsa bir kabarıklık görürsünüz.

Düz çizgiler
CFD ölçümleri, düz çizgiler.

Çalışma sistemin bir bölümünde biriktiğinde ve bir işlemde ilerlemediğinde bulgeler oluşur.
Örneğin, geliştirme daha kısa bir süre sürerken test uzun bir süre sürerse bir bülge oluşabilir ve bu da işin geliştirme durumunda birikmesine neden olur (bulgeler, başarılı bir adımın sorun yaşadığını gösterir, bulgenin gerçekleştiği adım olmayabilir).

Çıkıntı
CFD ölçümleri, çıkıntılar.

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

Zamanında güncelleştirme olmaması sorununu şu yöntemle çözebilirsiniz:

  • Günlük stand-up'lar.
  • Diğer düzenli toplantılar.
  • Günlük ekip anımsatıcısı e-postası zamanlama.

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:

  • İşlem genelinde tıkanıklıklar.
  • İşlemler uzun sürüyor.
  • Panoda yakalanmamış diğer fırsatlara geçiş.

Sistemsel düz çizginin bir örneği CFD özellikleriyle ortaya çıkabilir. Özellikler birkaç hikayeden oluştuğundan, özellik çalışması kullanıcı hikayelerinde çalışmaktan çok daha uzun sürebilir. Bu gibi durumlarda eğim beklenen bir durumdur (yukarıdaki örnekte olduğu gibi) veya sorun iyi bilinmektedir ve zaten ekip tarafından sorun olarak ortaya çıkarılmaktadır. Bu bilinen bir sorunsa, sorun çözümü bu makalenin kapsamı dışındadır.

Teams, CFD çıkıntıları olarak görünen sorunları proaktif olarak çözebilir. Bulgenin nerede oluştuğuna bağlı olarak düzeltme farklı olabilir. Örnek olarak, şişkinlik işleminin geliştirme sürecinde gerçekleştiğini varsayalım. Test çalıştırma işlemi kod yazmaktan çok daha uzun sürdüğü için kabarma gerçekleşebilir. 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 şunlardır: 1) Geliştiricileri geliştirme sürecinden test sürecinege ortadan kaldırılana kadar kaydırma veya 2) hızlı bir şekilde yapılabilecek işlerin daha uzun süren işlerle iç içe geçmesi için işin sırasını değiştirmek. Çıkıntıları ortadan kaldırmak için basit çözümler arayın.

Not

Çalışmanın eşit olmayan bir şekilde ilerlemesine neden olan birçok farklı senaryo meydana gelebileceğinden, sorunun gerçek bir çözümlemesini gerçekleştirmeniz kritik önem taşır. CFD size bir sorun olduğunu ve yaklaşık olarak nerede olduğunu söyler, ancak kök nedenlere ulaşmak için araştırmanız gerekir. Burada sağlanan kılavuz, belirli sorunları çözen ancak sizin durumunuz için geçerli olmayan önerilen eylemleri gösterir.

Kapsam değişti mi?

Kapsam değişiklikleri yalnızca sabit dönem CFD'leri için geçerlidir. Grafiğin üst satırı, çalışmanın kapsamını gösterir. Sprint, ilk günde yapılacak iş ile önceden yüklenir. Üst satırda yapılan değişiklikler, çalışmanın eklendiğini veya kaldırıldığını gösterir.

CFD ile kapsam değişikliklerini izleyememenize neden olan senaryo, aynı gün kaldırılan aynı sayıda iş öğesi eklendiğinde gerçekleşir. Çizgi düz olmaya devam eder. Birkaç grafiği birbiriyle karşılaştırın. Belirli sorunları izleyin. Kapsam değişikliklerini izlemek için sprint yazma durumunu görüntüle/yapılandır'ı kullanın.

Çok fazla WIP mi var?

WiP sınırlarının aşılıp aşılmadığını Kanban panosundan kolayca izleyebilirsiniz. CfD'den de izleyebilirsiniz.

Büyük miktarda WIP genellikle dikey bir çıkıntı olarak gösterilir. Büyük miktarda WIP ne kadar uzun olursa, kabarıklık o kadar genişleyerek oval olur. WIP'nin döngüyü ve sağlama süresini olumsuz etkilediğinin bir göstergesidir.

Devam eden çalışmalar için iyi bir temel kural aşağıdadır. Herhangi bir zamanda ekip üyesi başına devam eden ikiden fazla öğe olmamalıdır. İki öğenin katı sınırlara karşı temel nedeni, gerçekliğin her yazılım geliştirme sürecine sıklıkla müdahale etmelerindendir.

Bazen bir paydaştan bilgi almak zaman alır veya gerekli yazılımları almak daha uzun sürer. Çalışmanın durdurulmasının çeşitli nedenleri vardır. Özetleyebilmek için ikinci bir iş öğesinin olması biraz yol sağlar. Her iki öğe de engellenirse, engeli kaldırılan bir öğeyi almak için kırmızı bayrak oluşturmanın zamanı geldi; henüz başka bir öğeye geçmeyin. Devam eden çok sayıda öğe olduğunda, bu öğeler üzerinde çalışan kişi bağlam değiştirme konusunda zorluk yaşar. Yaptıkları şeyi unutma olasılığı daha yüksektir ve hatalar olabilir.

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

Aşağıdaki diyagramda sağlama süresinin döngü süresinden ne kadar farklı olduğu gösterilmektedir. Sağlama süresi, iş öğesi oluşturma işleminden Tamamlandı durumuna girmeye kadar hesaplanır. Döngü süresi, ilk olarak Devam Eden veya Çözümlenen durum kategorisi girildiğinden Tamamlandı durum kategorisi girilmesine kadar hesaplanır.

Sağlama süresi ve döngü süresi çizimi

Döngü süresi ve sağlama süresinin nasıl ölçülmesine ait kavramsal görüntü

Bir iş öğesi Tamamlandı durumuna girip yeniden etkinleştirilirse, Önerilen, Devam Eden veya Çözümlenmiş durumunda harcadığı ek süre, ikinci kez Tamamlandı durum kategorisine girdiğinde müşteri adayı/döngü süresine katkıda bulunur.

Ekibiniz Kanban panosu kullanıyorsa, Kanban sütunlarınızın iş akışı durumlarına nasıl eşlediğini anlamak istersiniz. Kanban panonuzu yapılandırma hakkında daha fazla bilgi için bkz. Sütun ekleme.

Sistemin durum kategorilerini (Önerilen, Devam Ediyor, Çözümlendi ve Tamamlandı) nasıl kullandığı hakkında daha fazla bilgi edinmek için bkz . İş akışı durumları ve durum kategorileri.

Müşteri adayı/döngü sürelerine göre tahmin teslim sürelerini kullanarak planlama

Teslimat sürelerini tahmin etmek için ortalama müşteri adayı/döngü sürelerini ve standart sapmaları kullanabilirsiniz.

Bir iş öğesi oluşturduğunuzda, ekibinizin bu iş öğesini ne zaman tamamlayacağına dair tahminde bulunurken ekibinizin ortalama sağlama süresini kullanabilirsiniz. Ekibinizin standart sapması, tahminin değişkenliğini gösterir. Benzer şekilde, çalışma başladıktan sonra iş öğesinin tamamlandığını tahmin etmek için döngü süresini ve standart sapması kullanabilirsiniz.

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 gelecekteki kullanıcı hikayelerini tamamlayacağı tahmininde bulunabiliriz. Standart sapma ne kadar dar olursa tahminleriniz de o kadar tahmin edilebilir olur.

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

Döngü Süresi pencere öğesi

İşlem sorunlarını tanımlama

Aykırı değerler için ekibinizin denetim grafiğini gözden geçirin. Aykırı değerler genellikle temel alınan bir işlem sorununu temsil eder. Örneğin, çekme isteği gözden geçirmelerini tamamlamak için çok uzun bekleme veya dış bağımlılığı hızlı bir şekilde çözmeme.

Birkaç aykırı değerleri gösteren aşağıdaki grafikte görebileceğiniz gibi, birkaç hatanın tamamlanması takımın ortalamasından daha 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ında azalmaya ve ekibinizin öngörülebilirliğini geliştirmeye yardımcı olabilir.

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

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

İşlem değişikliklerinin müşteri adayınızı ve döngü sürenizi 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 aynı çabayı göstermiş. Standart sapmanın bu tarihten sonra daraldığını ve daha iyi tahmin edilebilirlik gösterdiğini görebilirsiniz.

Sonraki adımlar