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ı (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.

Alternatif olarak, Panolarınıza Sağlama süresi ve döngü süresi denetim grafiklerini de ekleyebilirsiniz.

Ö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 metodolojilerle birleştirmeye başlamıştır. Bu, yineleme veya sprint'in kapsamına göre alıştırma yaptıkları anlamına gelir. Bu durumda diyagram biraz farklı bir görünüm alır ve sonraki grafikte gösterildiği gibi iki ek ve çok değerli bilgi parçası sağlar.

Sürekli akış

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

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

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

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üresi¹

Ç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üresi¹

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

Sprint veya sabit dönem işlemi için: bir istek üzerinde çalışmanın ne zaman başladığının çalışma tamamlanana kadarki süreyi (yani Etkin olandan Kapalı'ya kadar olan süreyi) ölçer.

Devam Eden Çalışma

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

Scope

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

---

¹ CFD pencere öğesi (Analiz) ve yerleşik CFD grafiği (iş izleme veri deposu) Sağlama Süresi ve Döngü Süresi'nde 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. 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 toplam çalışma miktarını gösterir ve belirli bir gün için tamamlanır.

Çalışmayı belirli Kanban pano 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 bir şekilde ilerlediğini, nerede tıkanıklıklar 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ı belirleyin, uygun eylemleri gerçekleştirin

CFD belirli birkaç soruyu yanıtlar ve yanıta bağlı olarak, işlemi sistem üzerinden taşıma işlemini ayarlamak için eylemler gerçekleştirilebilir. 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ış kazanırsınız.

Bu senaryoda, kararlı bir hızda çalışmanın yeterince hızlı tamamlanmadığının açıkça anlaşıldığı durumlarda yinelemedeki çalışma kapsamını azaltmak 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 anlamanın bir yolu, grafikteki farklı sütunlar arasındaki aralıklara bakmaktır. Baştan sona benzer veya tekdüzen bir mesafedeler mi? Bir sütun birden çok gün içinde düz çizgi olarak görünüyor mu? Yoksa "kabarıyor" gibi mi görünüyor?

Düz çizgiler ve kabarıklıklar 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 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ş alanını korumak tambur-tampon-halat 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 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

Çalışma sistemin bir bölümünde biriktiğinde ve bir işlemde ilerlemediğinde bulgeler oluşur.
Örneğin, test uzun bir süre sürerken geliştirme daha kısa sürerken bir zorlanma oluşabilir ve bu da çalışmanın geliştirme durumunda birikmesine neden olur (kabarçlar, başarılı bir adımın sorun yaşadığını gösterir, zorbanın oluştuğu adım değildir).

Çıkıntı

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 normal 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.
• Tahtada yakalanmamış diğer fırsatlara geçiş.

Bir sistemsel düz çizgi örneği CFD özellikleriyle ortaya çıkabilir. Özellikler birkaç hikayeden oluştuğundan özellik çalışması, kullanıcı hikayeleri üzerinde çalışmaktan çok daha uzun sürebilir. Bu gibi durumlarda eğim beklenir (yukarıdaki örnekte olduğu gibi) veya sorun iyi bilinir ve zaten ekip tarafından bir sorun olarak ortaya çıkarılı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. Bulgenin nerede oluştuğuna bağlı olarak, düzeltme farklı olabilir. Örnek olarak, kabarmasının geliştirme sürecinde gerçekleştiğini varsayalım. Sınamaları çalıştırmak kod yazmaktan çok daha uzun sürdüğünden zorlanıyor 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 şunlardır: 1) Geliştirme sürecinden test sürecine geçiş yapan geliştiriciler, zorlanma ortadan kaldırılana kadar veya 2) hızlı bir şekilde yapılabilecek işlerin sırasını değiştirmek, daha uzun süren işlerle iç içe geçmiş olur. Kabarcıkları ortadan kaldırmak için basit çözümler arayın.

Not

Çalışmanın düzensiz ilerlemesine neden olan birçok farklı senaryo meydana gelebileceğinden, sorunun gerçek bir analizini 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 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'lerine uygulanır. 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, çalışmanın eklendiğini veya kaldırıldığını gösterir.

CFD ile kapsam değişikliklerini izleyememe 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 burndown'ını 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 bulge 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 en fazla iki öğe olmalıdır. İki öğenin ve daha katı sınırların temel nedeni, gerçekliğin her 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 daha fazla zaman alır. Çalışmanın durdurulmasının çeşitli nedenleri vardır. Özetlenecek 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 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ştirme konusunda zorluk yaşar. Ne yaptıklarını unuturlar 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 Ediyor veya Çözüldü durum kategorisi girildiğinden Tamamlandı durum kategorisine girilmesine kadar hesaplanır.

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

Bir iş öğesi Tamamlandı durumuna girer ve sonra yeniden etkinleştirilirse, Önerilen, Devam Ediyor veya Çözüldü durumunda harcadığı ek süre, ikinci kez Tamamlandı durum kategorisine girdiğinde sağlama/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, Sürüyor, Çözüldü 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 kurşun/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 bir 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ğına dair tahminde bulunabiliriz. Standart sapma ne kadar dar olursa tahminleriniz o kadar tahmin edilebilir olur.

Örnek 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ğerlerin gösterildiği 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ı azaltmaya ve ekibinizin öngörülebilirliğini artırmaya yardımcı olabilir.

Birkaç aykırı değeri gösteren Örnek 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 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

Toplu akış grafiklerinizi yapılandırma veya Sağlama süresi veya döngü süresi grafiği yapılandırma