← Denemeler

Scrum ve SAFe bağlamında Cumulative Flow kullanım pratiği

Bu makalede, SAFe çerçevesinde çalışma sürecinde Scrum'da Cumulative Flow Chart'ı kendi pratiğimizde nasıl uyguladığımızı anlatmayı planlıyorum.Kişisel blog.

2 dk okuma
TelegramOrijinal
Scrum ve SAFe bağlamında Cumulative Flow kullanım pratiği

Bu makalede, çalışma sürecinde Scrum'da Cumulative Flow Chart'ı kendi pratiğimizde nasıl uyguladığımızı anlatmayı planlıyorum SAFe

Sanırım şu makaleye bir bağlantıyla başlayayım - bence burada standart biçimindeki amacı iyi açıklanmış, makalemi okumadan önce incelemenizi öneririm. Aşağıda ise onu Scrum süreci için nasıl uyarladığımızı (başlangıçta Kanban'da kullanılır) ve sprintlerle çalışırken hangi sorunları çözmemize yardımcı olduğunu anlatacağım.

Daha önce Burn Down Chart'lar hakkındaki makalede yeni işin ortaya çıkışını ve eski işin tükenişini gördüğümüzü söylemiştim. Burn Down Chart'ın sorunu şu ki, Cumulative Flow Chart'tan farklı olarak, Kullanıcı Hikayelerinin durumlar arasındaki hareketini göremiyoruz. Cumulative Flow Chart'ta durumlar arasındaki hareketleri gözlemlemeye başladığımızda ise günlük değişimleri görmeye başlıyoruz (Burn Down Chart birkaç gün değişmeyebilir ve bazı bağlamlarda bu tamamen normal olabilir) ve daha ince sorunları fark edebiliyoruz.

İşte dinamikte böyle görünebilir (görselde gerçek verilerle oluşturulmuş bir diyagram var).

Image



Image

Bu örnekte şunları görüyoruz

  • Sprintin ilk 7 gününde testte çok küçük bir iş hacmi var ve değişmiyor
  • DOR'dan (burada taslak) işe Kullanıcı Hikayeleri oldukça düzenli geçiyor - bu iyi.
  • Burn Down'da olduğu gibi, eğilime göre Kullanıcı Hikayelerinin sprint sonuna kadar tamamlanmayacağını görüyoruz

Bu 3 gözlem birlikte şu sonuca götürüyor. Burada açıkça daha erken aşamalarda (sprintin ikinci-üçüncü günü civarında) Scrum Master'ın çok küçük olan ve uzun süre değişmeyen "Test" katmanına dikkat etmesi (nedenini doğrulaması) gerekirdi. Teste hazır iş hacminin bazı nedenlerle test edilemediği varsayılabilir, ancak o zaman bu, testçilerin boşta olduğu anlamına gelir, yani en azından en yakın standup'ta onları daha dikkatli dinlemek gerekir.

Uygulama pratiğinden bahsedecek olursak, örneğin ben her gün standup öncesinde tüm ekibi etiketleyerek tüm metrikleri ekip sohbetinde yayınlıyorum.

Genel olarak, metriklerin yine de doğru yorumlanması gerektiğini unutmamak gerekir. Varsa gerçekten sistemik sorunları görebilmek ve bağlamınızda olumlu bir işaret bile olabilecek şeyleri sorun olarak algılamamak