SAFe ve Scrum bağlamında Burn Down Chart kullanım pratiği

Bu makalede, SAFe metodolojisiyle çalışma sürecinde yanma diyagramını (Burn Down Chart) kendi pratiğimizde nasıl kullandığımızı anlatmayı planlıyorum

En ilginç olandan başlayayım sanırım. Yani bu diyagramın SAFe'de kullanımının SCRUM'da kullanımına göre hiçbir özelliği olmaması gerektiğinden. Yoksa olmalı mı?

Bizde SAFe, SCRUM'dan farklı olarak RTEgibi bir role sahip olmasıyla ayrılır. Burn Down Chart, sprintteki iş hacmini izleme aracıdır ve her şeyden önce SCRUM ekibi için gereklidir, dışarıdan biri için değil, öyle değil mi?

Böylece, her şeye rağmen ve hâlâ SAFe çerçevesi içinde kalarak, Burn Down Chart'ı nasıl kullandığımıza geçeyim.

Ben Scrum Master rolündeyim ve bu diyagramı her gün tüm Dev Teamiçin öne çıkarmaya çalışıyorum. Kullandığım araç - bu, ekip sohbeti, "@" ile tüm ekibi etiketleme, diyagramın mevcut durumunun ekran görüntüsü. Tüm ekibi etiketlemek oldukça hassas bir araçtır ve onu mümkün olduğunca nadir kullanmak önemlidir (sonuçta biz Scrum Master'lar ekibin rahat çalışmasına ve mümkün olan en az odak dağılmasıyla çalışmasına yardımcı olmalıyız, öyle değil mi?)

Sonuç olarak ekip her gün sprintin mevcut durumunu görür ve şu olayları takip edebilir

• Planlanmamış işin ortaya çıkması
• Görevlerin tamamlanmamış durumda uzun süre asılı kalması
• Aşırı risk yüklenmesi
• İşin doğru hızda ilerleyip ilerlemediğinin anlaşılması

Şimdi bu olayların her birini açıklamaya ve kendi pratiğimden örnekler vermeye çalışacağım.

Planlanmamış işin ortaya çıkması

Bu diyagramda yeni işin nasıl ortaya çıktığı çok iyi görülüyor (iki haftalık sprintin ikinci Salı günü).

Pratikten bir vaka: "Çevik ilkeleri paylaşan scrum ekibinin bir üyesi olarak geliştirici, Product ile doğrudan harika bir şekilde etkileşim kuruyor. Product ona diyor ki, şunu hızlıca halledelim, sen de anlıyorsun, burada hızlı ve riskler minimum.

Geliştirici harika, çevik hakkında ve iş değeri teslim etmenin önemi hakkında her şeyi biliyor, gidip backlog'dan bir hikâyeyi panoya atıyor, ekip tarafından 6 sp olarak tahmin edilmiş.

Ekibin geri kalanı (geliştirici ve Product dışında) bunu sabah diyagram güncellemesinde fark ediyor. Standup'ta ekip bu durumla ne yapılacağına karar veriyor. Büyük olasılıkla hikâye sprintten çıkarılır, Product ve Geliştirici'ye ekibin bunu böyle yapamayacağı anlatılır, product gerekirse bu hikâyeyi bir sonraki sprinte koyabilir.

Elbette ideal olarak ekip yeni işin ortaya çıkışını diyagram olmadan da standup'ta fark etmelidir. Ancak diyagram, tüm ekip için bu kadar önemli bir değişikliğin fark edilmemesi riskini minimuma indiren iyi bir göstergedir.

Burada senaryonun ekibin seviyesine bağlı olarak farklı şekilde ilerleyebileceğini anlamak önemlidir. Güçlü ekiplerde Ürün Sahibi bunu pek yapmazdı, yapsaydı da bunu «bunu hızlıca halledebiliriz» diye değil, «bunu şimdi halledersek gelecek ay kârımızı %20 artırabilme olasılığını %55 olarak değerlendiriyorum» ya da başka bir ölçülebilir metrikle gerekçelendirirdi.

Görevlerin tamamlanmamış durumda uzun süre asılı kalması

Burada, işin çok uzun süre kısmen bile tamamlanmadığını görüyoruz. Bu, çeşitli sorunlara işaret ediyor olabilir, bazılarını sıralayacağım

• Kötü görev ayrıştırması

  Çoğu zaman acemi ekipler ayrıştırmanın imkansızlığından bahseder. Her şey son günde yanıp biter, iş paralelleştirilemez vb. Elbette, Scrum Master'ın bunun üzerinde çalışması ve ayrıştırmanın değerini ekibe açıklaması gerekir.

• Optimal olmayan şekilde formüle edilmiş DOD

  DOD (Definition of Done) - sprintteki User Story'nin hazır olma kriterlerinin tanımı. Bazen hiç yoktur veya çok soyut tanımlanmıştır. Bu pekala bir sorun olabilir ve elbette Scrum Master'ın bunu çözmeye yardımcı olması gerekir

Aşırı risk yüklemesi

Bu durumda ekibin riskleri fazla yüklediği bir durum görüyoruz.

Belki bir hikaye fazla tahmin edilmiştir. Belki bu daha sistemik bir sorundur ve sprint planlamasında iş hacminin artırılması gerekir. Her durumda, bu durum doğru değildir. Sonuçta iş, sprint görevlerinin tam olarak ve tam olarak sprint sonunda gerçekleştirileceğini planlamıştı. Bağımlılıkların nasıl planlandığına bağlı olarak, burada büyük olasılıkla beklentileri düzeltmek için toplantılar yapılması gerekecektir.

Benim deneyimimde bu, tahmin sırasında tartışılandan daha hızlı bir çözüm bulunduğunda oldu. Tüm ekiple sprint sonuna kadar hangi hikayeyi kapatabileceğimizi tartıştık ve retrospektifte grooming sırasında koda bakmaya çalışacağımız konusunda anlaştık. Çözümün çok daha basit olduğunu anlamak için koda bakmanın yeterli olduğu ortaya çıktı.

Anlayış - iş doğru hızda mı ilerliyor

Burada grafiksel olarak başarısız Burn Down Chart gösterim yöntemlerine dikkat çekmek istiyorum

Görüntünün üst kısmında, aşağıda açıklayacağım iki nedenden dolayı pek de başarılı olmayan bir grafik uygulama örneği verilmiştir.

• Sprint'e yeni SP'lerin girmesi fark edilmiyor

  Burada, üst diyagramda, planlanmamış işin eklendiği neredeyse fark edilmiyor. Alt diyagramda bu daha açık.

• Göreli kalan iş yanlış gösteriliyor

  Üst diyagrama göre çalışmak için 3 gün daha kaldı. Gerçekte 2 gün var, tatil gününde belki birileri dinlenmeyi planlıyor.

Elbette, bazılarına bu tür önemsiz şeyler önemsiz görünebilir. Ancak anlamak gerekir ki, her ekip üyesi bu diyagrama sadece bir göz atacak ve diyagram maksimum faydalı bilgiyi iletmelidir.