SAFe'de Agile ekibinin Scrum'a göre çalışmasının özellikleri pratikte

Arkadaşlar arasında Burn Down Chart hakkındaki ilk makaleninyayınlanmasından sonra, yorumlarda sorulan ilk soru şuydu: "SAFe ile deneyiminiz hakkında daha fazla bilgi edinmek ilginç olurdu". Bu nedenle, bu makalede SAFe'de çalışmanın Scrum'a göre özelliklerini bizim pratiğimiz üzerinden açıklamaya çalışacağım. Kesinlikle ilk elden doğruluk iddiasında değilim ve meslektaşlarımın her türlü düzeltme ve açıklamasına memnuniyet duyarım.

Önce, bence SAFe'de çalışmayı SCRUM'dan ayıran en temel şeyleri maddeler halinde sıralayacağım.

• Scrum'da Increment ve SAFe'de Program Increment
• ART - Agile Release Train
• Etkileşimde bulunan ekiplerin sayısı
• PIPE
• SOS
• PO - işin sahibi değil
• RTE
• Eğitim için beşinci sprint
• System Demo

Scrum'da Increment ve SAFe'de Program Increment. Aslında farklı terimler, ancak bunlarda kafa karıştırmak kolay çünkü bizde kimse Program Increment terimini kullanmıyor, herkes sadece Increment diyor - ki bu da SCRUM'da kullanılan başka bir terim. Ama genel olarak anlam açısından bence oldukça benzerler. SCRUM'daki Increment - aslında mevcut ürün + sprint için planlanan hikayelerin tamamlanmış durumda (ekibin DOD'sini geçmiş) hali. Program Increment - trenin (Agile Release Train) üretime artımlı değer teslim ettiği zaman aralığı. Süre olarak bizde bu, geliştirme için 2 haftalık 4 sprint ve eğitim için bir sprint.

Agile Release Train - tek bir değer akışı üzerinde çalışan ekiplerin ekibidir. Biz buna kısaca tren diyoruz, ancak çerçeveye göre doğru adı "Solution" olmalı. Bizim durumumuzda bu kural tam olarak uygulanmıyor ve ekipler teknik açıdan sıklıkla farklı ürünler üzerinde çalışıyor, çünkü iş özelliklerinin çoğu kapsamlı şekilde gerçekleştiriliyor ve birkaç ürünü etkiliyor. Bu teknik taraftan. Ancak, birilerinin tüm IT sistemlerini şirketin tek bir ürünü olarak gördüğünden eminim ve belki bu daha doğrudur bile.

Etkileşimde bulunan ekiplerin sayısı bizde SAFe'de önemli ölçüde daha fazla, toplamda bir trende 125 kişiye kadar öneriliyor. Bizde 3 tren var ve bu kural her birinde uygulanmıyor, 125 kişiden fazla olan trenler var. SCRUM, bildiğim kadarıyla diğer ekiplerle nasıl etkileşim kurulacağını tanımlamıyor, SAFe'nin aksine, bu konuda çok net öneriler var. Bence bunun için en belirgin artefakt Program Board.

Üzerinde trenin ekipleri arasındaki ilişkiler gösteriliyor ve bunu tartışarak bizde haftalık Scrum Of Scrums (SOS) etkinlikleri yapılıyor.

Yaklaşık her 2,5 ayda bir (her 5 sprintte bir) şu etkinlik gerçekleşiyor: PIPE - Programm Increment Planning Event. Bu, tüm dağıtılmış ekiplerin 2 gün boyunca tek bir salonda toplanıp sonraki 2,5 ay için çalışmalarını planladığı zamandır. Bu etkinlik sürecinde, örneğin her bir tren için ekiplerin birbirleriyle tüm bağımlılıklarının gösterildiği Program board gibi artefaktlar ortaya çıkar, yukarıda nasıl göründüğünü zaten gösterdim. Bu etkinlikte her ekibin Scrum Master'ının görevi, mümkün olan en fazla sayıda bağımlılığın ortaya çıkarılmasını kolaylaştırmak, ardından mümkünse bunları ortadan kaldırmaktır (örneğin, yetkinliklerin sözlü olarak bir ekipten diğerine aktarılması yoluyla veya bir bağımlılığın bir ekipten diğerine alınması yoluyla, böylece ekibin özelliğini kimseye bağımlı olmadan otonom olarak gerçekleştirebilmesi). Pratikte bizde bu şekilde gerçekleşiyor. Önce özellikler User Story'lere ayrıştırılıyor, User Story'ler 4 sprinte dağıtılıyor. Özellikler Program Board'a yerleştiriliyor ve diğer ekiplerden hangi bağımlılıklar varsa belirtiliyor. Etkinlik boyunca bu tartışılıyor, düzeltiliyor.

SOS - Scrum Of Scrum. Bu etkinlik her tren için ayrı ayrı haftada bir kez yapılıyor. Trenin tüm ekiplerinin Scrum Master'ları çevrimiçi toplanıyor, trenin Program Board'u yayınlanıyor ve belirli bir trenin ekiplerinin tüm bağımlılıklarının ve özelliklerinin durumları tartışılıyor. Aslında bu etkinlik, tren içindeki ekiplerin merkezi senkronizasyonu için gerekli. Bir tür standup gibi, ama haftada bir ve ekip için değil, Scrum Master'lar için.

PO (Ürün Sahibi) - işin sahibi değil. Product Manager var - ilgili iş yönlerinin Bussiness Owner'ları ile çalışıyor ve aslında özellikleri Ürün Sahiplerine dağıtıyor. Ürün Sahibi ise doğrudan ekipte çalışıyor - özellikleri User Story'lere bölüyor (bizim durumumuzda ekiple birlikte) ve her zaman bölmüyor, ancak biz bu yönde sürekli ilerliyoruz.

RTE (Release Train Engineer - tren makinisti. Scrum Master'ların Scrum Master'ı. Kendi treninin SOS etkinliklerini yürütür. Özellik düzeyinde Product Manager ile etkileşimde bulunur. PIPE'ı kolaylaştırır.

Öğrenme için beşinci sprint - evet, Scrum'dan farklı olarak burada artışın sonunda takıma öğrenme için bütün bir sprint ayrılmıştır. Biz pratikte bunu kural olarak öncelikle iç eğitimlere katılmak için kullanıyoruz, bunların arasında SAFe eğitimleri de var, ama sadece bunlar değil. Özel kursları ve meetup'ları mümkün olduğunca bu zamana planlamaya çalışıyoruz. Ayrıca 5. sprint boyunca yetkinlik yığınını genişleten geliştiricilerimiz var, böylece takımda birinin yetkinliğini kapatma (gerektiğinde yedek olma) imkanı oluyor.

System Demo. PIPE sonucunda her takımın artış için bir hedef listesi vardır ve bu hedeflerin her biri trenin Business Owner'ı tarafından 10 puanlık ölçekte değerlendirilir. Buna Business Value denir. Bu hedefler temel ve genişletilmiş olarak ayrılır. Temel hedefler - takımın ulaşılmasında hiçbir risk görmediği hedeflerdir. Genişletilmiş - ulaşılma riski olan hedeflerdir. Tüm hedefler zorunludur ve iş hacmi tüm hedefler için planlanır. System Demo'da Business Owner artış için iş sonuçlarını kabul eder. Diyelim ki takımın 10, 6, 8 puanlı 3 temel hedefi ve 10, 3 puanlı 2 genişletilmiş hedefi vardı. Business Owner'ın sırasıyla şu puanları verdiğini varsayalım: 8, 6, 4, 2, 0. Şimdi hedeflere ulaşma yüzdesini hesaplayabiliriz: %100 olarak temel hedefler için başlangıçtaki puan toplamı alınır, bizim durumumuzda bu 10+6+8=24. Ulaşılan puanlar genişletilmiş hedefler dikkate alınarak hesaplanır (yani takım 24'ten 20'sine ulaştı), yani sonuçta takımın hedeflere ulaşma yüzdesi (20*100)/24 = %83,3 olacaktır. Normal sonuç %80 ile %100 arasında ulaşma olarak kabul edilir.

Geri kalan her şeyde SCRUM'a göre çalışıyoruz. Ya da neredeyse her şeyde :) Deneyimimize gelince: söyleyebilirim ki, benim bakış açıma göre evrim açık. Bir yıllık çalışmada takımlar çok büyüdü, kendi kendini organize eden hale geldi, bazı takımlar doğru, dağıldı, ama bunda da belirli bir evrim görülüyor. Büyümeye daha da yer var.

facebook'taki meslektaşların yorumları

«Jenia, merhaba! Yazman harika, aferin! Trenler konusunda biraz düzelteyim - onlar ürün etrafında değil, değer yaratma akışı etrafında toplanıyor. Ve perakendede bizde SAFe açısından tren değil, Solution var. Sadece iletişim kolaylığı ve anlaşılmayı basitleştirmek için biz buna tren demeye devam ediyoruz)»

– Konstantin Voronin (Ingosstrakh proje ofisi temsilcisi)

«Ve belki biri fark eder ki, SAFe açısından hedeflerin değerlendirilmesi I&A'da gerçekleşir; (SD bunun bir parçası olarak girer, ama doğrudan değerlendirmeyle bağlantılı değildir) ve SD'lerin kendisi her sprintte gerçekleşmelidir (takım demolardan sonra). Ama biz henüz bundan uzağız, bu yüzden bilinçli olarak her şeyi senin makalende yazdığın gibi adlandırıyoruz)»

– Konstantin Voronin (Ingosstrakh proje ofisi temsilcisi)

«Jenia, lütfen devam et, çok faydalı!»

– Aleksey Ionov (SAFe Sertifikalı Eğitmen)