Çevik Projelerde Risk Nasıl Yönetilir: Her Sprintte Küçük Adımlar

Çevik ortamda risk neden farklı ele alınır?

Klasik projelerde risk kaydı proje başında hazırlanır, belirli aralıklarla güncellenir ve genellikle proje yöneticisinin elindedir. Çevik ekiplerde ise ürün her sprintte değişir; öğrenilen her yeni şey risk resmini de değiştirir. Yılda bir kez güncellenen bir kayıt bu hıza yetişemez.

Çevik yaklaşımın iki avantajı vardır. Birincisi, kısa döngüler riskleri erken ortaya çıkarır: bir entegrasyonun işe yaramayacağı projenin sonunda değil, ilk sprintlerde anlaşılır. İkincisi, çalışan ürün parçaları sürekli gösterildiği için varsayımlar hızla sınanır. Bu nedenle çevik risk yönetimi büyük bir ritüel değil, mevcut sprint olaylarına yedirilmiş küçük alışkanlıklar bütünüdür.

Sorumluluk da dağılır. Risk bir kişinin değil, ekibin işidir. Geliştiriciler teknik belirsizlikleri dile getirir, Ürün Sahibi iş tarafındaki riskleri backlog sıralamasına yansıtır, Scrum Master engelleri görünür kılar. Klasik risk kaydının nasıl tutulduğu için ilgili rehbere bakabilirsiniz; bu sayfa riskin sprint ritmine nasıl yerleştirildiğini anlatır.

Risk backlog'u: olasılık ve etkiyle sıralama

Çevik risk yönetiminin ilk adımı riskleri ürün backlog'u yanına, aynı görünürlükte bir listeye yazmaktır. Her kalemin bir sahibi, kısa bir açıklaması ve bir karşı önlemi olur. Karşı önlem çoğu zaman ayrı bir backlog maddesine dönüşür: örneğin 'ödeme sağlayıcısının sınırları belirsiz' riski için bir araştırma işi ya da yedek sağlayıcı entegrasyonu.

Sıralama için olasılık ve etki birlikte değerlendirilir. Dört durum ayırt edilir.

• Düşük olasılık, yüksek etki: izlenir ve acil durum planı hazırlanır, çünkü gerçekleşirse maliyeti büyüktür.
• Yüksek olasılık, yüksek etki: hemen ele alınır; backlog'un en üstüne çıkar ve erken sprintlere girer.
• Düşük olasılık, düşük etki: kayıtta tutulur, ayrı çaba harcanmaz.
• Yüksek olasılık, düşük etki: genellikle sorun olarak yaşanır; işin içinde ucuza çözülür ya da kabullenilir.

Bu sıralama sabit değildir. Her sprint planlamasında risk listesine bakılır; olasılığı düşenler aşağı iner, yenileri eklenir.

Spike: belirsizliği küçük bir deneme ile azaltmak

Bazı riskler bilgi eksikliğinden doğar: yeni bir kütüphane ekibin ihtiyacını karşılar mı, eski sistemin API'si beklenen veriyi verir mi? Bu sorulara tahminle değil, deneyle yanıt vermek gerekir. Spike tam bu iş içindir. Bir soruya yanıt arayan, zaman kutusuna bağlanmış kısa bir araştırma ya da deneme işidir.

İyi bir spike şu özelliklere sahiptir. Tek bir soruyu yanıtlar ('Bu servis eş zamanlı isteklere dayanır mı?'). Süresi baştan sınırlıdır; süre dolunca eldeki bilgiyle karar verilir. Çıktısı çalışan özellik değil, bilgidir: bir karar, bir not ya da atılabilir bir prototip. Sonucunda ürün backlog'u güncellenir: risk kapanır, küçülür ya da büyür ve yeni maddeler doğar.

Spike'ı aşırıya kaçırmamak gerekir. Her belirsizliği araştırma işine çevirmek ürün işini yavaşlatır. Yalnızca yüksek etkili ve bilgi eksikliğinden doğan riskler için spike açılır. Zaman kutusu dolduğunda 'biraz daha bakalım' diyerek uzatmak, spike'ı kontrolsüz bir araştırma projesine çevirir.

Risk yönetimini sprint ritmine yerleştirmek

Ayrı bir risk toplantısı gerekmez; mevcut sprint olayları bu işi görür.

• Sprint planlaması: Risk listesine bakılır. Yüksek maruziyetli kalemlerin karşı önlemleri sprint backlog'una alınır, ilgili işler öne çekilir.
• Günlük toplantı: Engeller ve yeni riskler dile getirilir. Hedefe giden yolda beliren tehlikeler burada görünür.
• Sprint gözden geçirmesi: Çalışan ürün paydaşlara gösterilir; iş tarafındaki varsayımlar sınanır ve yeni riskler eklenir.
• Retrospektif: Gerçekleşen ve ıskalanan riskler üzerinden ekip süreci iyileştirir; hangi uyarıları geç fark ettiği konuşulur.
• Backlog iyileştirme: Büyük ve belirsiz işler parçalanırken riskler bu aşamada da yakalanır.

Bu yerleşim sayesinde risk, ayrı bir yük olarak değil, zaten yapılan konuşmaların bir boyutu olarak ele alınır. Önemli olan, her olayda riske ayrılan sorunun yinelenmesi ve çıkan kararın backlog'a yansımasıdır.

Risk burndown ile ilerlemeyi izlemek

Risk burndown grafiği, toplam risk maruziyetinin sprintler boyunca nasıl değiştiğini gösterir. Her riske olasılık ve etkiye dayalı bir puan verilir; bu puanların toplamı yatay eksende sprintlere karşı çizilir. İyi giden bir projede çizgi aşağı iner, çünkü riskler karşı önlemlerle azalır ya da kapanır.

Grafik bir tahmin aracı değil, bir konuşma başlatıcıdır. Çizgi inmiyorsa iki olasılık vardır: yeni riskler eskileri kadar hızla ekleniyor ya da karşı önlem işleri sprintlere girmiyor. Çizgi çok hızlı iniyorsa puanlama fazla iyimser olabilir. Her iki durumda da ekip nedenini sorgular.

Puanlamayı basit tutun. Düşük, orta ve yüksek gibi bir ölçek yeterlidir; kesin görünen puanlar yanıltıcıdır. Ayrıca grafik tek başına bir sonuç değildir: yüksek puanlı tek bir risk, düşük puanlı çok sayıda riskten daha tehlikeli olabilir. Bu yüzden toplam çizgiyle birlikte en yüksek riskin durumuna da bakılır. Hedef çizgiyi aşağı çekmek değil, projeyi tehlikeye atan belirsizliği erken kapatmaktır.

Sık hatalar ve önlemler

Çevik ekiplerde risk yönetimi şu hatalarla zayıflar.

• Riski 'çevik zaten halleder' diye sahipsiz bırakmak. Kısa döngüler riskleri erken gösterir ama azaltmaz; karşı önlem işleri ayrıca yapılmalıdır.
• Risk listesini bir kez yazıp bırakmak. Her sprint planlamasında güncellenmeyen liste güvenilirliğini yitirir.
• Riskleri ürün backlog'undan ayrı tutmak. Ayrı listedeki riskler sıralamaya girmez, sprintlere de girmez.
• Spike'ı sınırsız bırakmak. Süre ve soru baştan yazılmazsa araştırma uzar.
• Zor ve belirsiz işleri sona bırakmak. En büyük belirsizlikler erken ele alınırsa hata maliyeti düşer.
• Riski yalnız teknik görmek. Paydaş değişikliği, bütçe ve bağımlılık riskleri de listeye girer.

İyi bir kontrol sorusu şudur: 'Bu sprintte hangi riski azalttık?' Yanıt boşsa risk yönetimi fiilen yapılmıyordur, yalnızca konuşuluyordur.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Agile Project Management Foundation, çevik ortamda proje yönetiminin temelini verir. PRINCE2 Agile Foundation & Practitioner Hazırlık Eğitimi, çevik ortamda risk, kalite ve ilerleme yönetimini ayrı bir başlık olarak işler. Hibrit Proje Yöneticiliği Sertifika Programı ise hibrit ortamda risk ve değişiklik yönetimini ele alır. Hem klasik hem çevik yapıyla çalışan proje yöneticileri ve Scrum Master'lar için uygundur.