MoSCoW ile Önceliklendirme: Must Listesi Şişerse Yöntem Çalışmaz
Proje yönetiminde zor olan hangi işin yapılacağına karar vermek değil, hangisinin yapılmayacağını yazılı hale getirmektir. MoSCoW bu kararı dört kategoriye indirger: Must, Should, Could, Won't. Yöntemin gücü de zaafı da aynı yerden gelir, bu sadelikten.
Dört kategori, tek cümlelik tanımlar
- Must have: Yoksa teslim edilen şey işe yaramaz. Yasal zorunluluklar, sözleşme maddeleri, ürünün temel işlevi.
- Should have: Ciddi değer katar, yokluğunda ürün yine de çalışır. Çoğunlukla bir sonraki sürüme kalır.
- Could have: Zaman ve bütçe artarsa girer. Baskı geldiğinde ilk kesilen küme burasıdır.
- Won't have: Bu turda yapılmayacağı açıkça kararlaştırılmış olan.
Baş harflerin arasındaki küçük o harfleri hiçbir anlam taşımaz, kısaltmayı okunur kılmak için oradadır.
Sabit bir süre yoksa yöntem çalışmaz
MoSCoW'un konuşulmayan varsayımı, işin sabit süreli bir kutuya sığdırılacak olmasıdır. Süre serbestse Must ile Should arasındaki fark ortadan kalkar, çünkü her şey eninde sonunda yapılabilir. Kategoriler ancak bir şeyin kutunun dışında kalacağı kesinken bir anlam üretir.
Yöntemi yaygınlaştıran DSDM'in önerisi bu yüzden efor üzerinden kurulur: Must kümesinin toplam eforu kutunun kapasitesinin %60'ını geçmemeli, kalan pay Should ve Could'a bırakılmalı. Bir projede Must listesinin planlanan eforun neredeyse tamamını kapladığını gördüm; ekip önceliklendirme yaptığını düşünüyordu, yaptığı şey bütün maddeleri yeniden adlandırmaktı.
Sonuç şu: efor tahmini olmadan yapılan MoSCoW çalıştayı bir önceliklendirme değil, bir görüş anketidir.
Kategorize etmek sıralamak değildir
Yüz gereksinim dört kutuya ayrıldığında Must kutusunda yirmi beş madde kalır ve bu yirmi beşin hangisinin önce yapılacağı hâlâ belirsizdir. MoSCoW kaba bir elemedir, ince sıralama vaat etmez.
İnce sıralama gerektiğinde akla gelen ilk yöntem ikili karşılaştırmadır, ama maliyeti n(n-1)/2 ile büyür: yirmi beş madde üç yüz karşılaştırma demek. Yani "uzun listeyi ikili karşılaştırmayla sırala" tavsiyesi tam da listenin uzun olduğu durumda ters çalışır. Önce kaba eleme, sonra küçülmüş küme üzerinde sıralama. Sıra bunun tersi olduğunda ekip günlerini karşılaştırma tablosunda geçirir.
Won't have iki farklı şey söylüyor
"Bu turda yok" ile "hiçbir zaman yok" aynı kutuya konduğunda liste altı ay sonra okunamaz hale gelir. İkisini ayır: maddenin yanına kararın tarihini ve gerekçesini yaz. Won't have'in asıl faydası zaten budur, reddedilen şeyin kaydını tutmak. Aksi halde aynı talep her sprint planlamasında yeniden gündeme gelir ve her seferinde baştan tartışılır.
Çalıştay nasıl yürür
- Talepleri tek bir listede topla, kim istedi bilgisini kaybetme.
- Her maddeye kaba bir efor değeri ver. Gün, puan, tişört bedeni, hangisi işine geliyorsa.
- Kategorileri müşteri tarafı ve geliştirme tarafı birlikte belirlesin. Tek taraflı yapılan MoSCoW listesi ilk itirazda dağılır.
- Must toplamını kapasiteyle karşılaştır. %60'ı aşıyorsa listeyi bitmiş sayma, geri dön.
Her sürümde tekrarla. Öncelikler değişir, özellikle de ilk sürüm sahaya çıkıp gerçek kullanım verisi geldiğinde.
Nerede yetmez
Birbirine bağımlı gereksinimlerde MoSCoW yanıltır. Could kategorisine attığın bir altyapı işi, Must kategorisindeki üç maddenin önkoşuluysa kategorisi kâğıt üzerinde kalır. Bu tür bağımlılıkları kategorilere değil, ayrı bir bağımlılık listesine yazmak gerekir; MoSCoW bu ilişkiyi göstermek için tasarlanmadı.
Kaynaklar