Proje Yönetiminde Çevik Yaklaşım – SCRUM

Proje Yönetiminin önemini kavramış birisi olarak, yürüttüğüm projelerde PMI’ın proje yönetim metodolojisini kullanmaya gayret ediyorum. PMI’ın bu alanda çıkarmış olduğu sertifikaları da almaya çalışarak bilgimi taze tutmaya çalışıyorum. Nitekim PMP sertifikasını aldıktan sonra çok önem verdiğim risk yönetimi üzerine de PMI’ın çıkarmış olduğu PMI-RMP sertifikasını almış ve bununla ilgili bir kaç yazı yazmıştım(Yazı 1, Yazı 2)

Fakat PMBOK’da bahsedilen dünyanın, yazılım dünyasına tam oturmadığı fikrini bir süredir yönetmiş olduğum projelerde deneyimleyerek görüyorum. Sanırım PMI’da bunu farketmiş olacak ki, PMP-Agile adında yeni bi sertifika hazırlıkları içine girmiş.

Yazılım projeleri diğer alanlardaki projelerden biraz farklı dinamikleri olan projelerdir. Her ne kadar projenin tanımda bulunan tekil olma yani benzersiz olma özelliği olsa da, bu onların daha önce yapılan projelere benzemediği anlamını taşımaz. Bir inşaat projesinde(çok uç ve dünyada ilk defa yapılan projelerden bahsetmiyorum) az çok neyin ne zaman yapılacağı ve nasıl bir şey çıkacağı bellidir. Bunu müşteri de, yüklenici de, sponsor da az çok bilir. Bu tip projelerde PMBOK’da bahsedilen şelale mantığında kesin çizgilerle ayrılmış proje süreçlerini nisbeten işletmek daha kolaydır. Dünyada yapılan AR-GE projelerini de bu kapsama almıyorum. Bu tip projeler de çevik yaklaşım(Örneğin sprila model) uygulanması daha mantıklıdır.

İş IT dünyasına gelince durum biraz değişiyor. Müşteri daha başında tam olarak ne istediğini bilemiyor. Ortada deneyimlenmiş bir örnek yoksa ortaya nasıl bir ürün çıkacağını hayal dahi edemiyor. Bu durum yüklenici firmaya sürekli değişen müşteri talepleri, yap-boz haline gelen çöplüğe dönüşmüş uygulamalar olarak yansıyor.

PMBOK dünyasının katı kuralları ile bu tip projelere uygulamak ise yukarıda anlattığım sebepler dolayısı ile müşteri memnuniyetsizliğini artırıyor. Henüz hiç bir şey eline geçmeden ve görmeden milyon dolarları sokağa atmak istemiyorlar haklı olarak.

Bu gibi durumları bir süredir gözlemleyen birisi olarak çevik proje yönetim konusunda araştırma içerisindeyim. Daha önce de yazılım projelerine özel bir çok çevik yaklaşımı inceleme fırsatım oldu. Fakat bu yazımda SCRUM konusuna biraz giriş yapmak istiyorum. Muhakkak ki bunu deneyimlemiş bir çok değerli kişi mevcuttur, ben de bunu elimden geldiğince yazıya dökmek istedim.

Dediğim gibi burada yazacaklarım SCRUM teorisine giriş niteliğinde dolayısı ile biraz özet olarak görülebilir. Aşağıda SCRUM teorisi ve SCRUM organizasyonu ile ilgili okuduğum makaleden kendimce özetlediğim bir grafiği göreceksiniz. . Ardından ise temel kurallardan bahsederek yazımı bitireceğim.

RULES(Kurallar)

• Scrum Master takımın Scrum teorisine göre işgörmesini sağlayan ortadaki engelleri(varsa) kadıran kişidir
• Scrum Master ve Product Owner aynı kişi olmamalıdır
• Product Owner yukarıda şekilde görülen Product Backlog’un yönetiminden ve önem derecesine göre sıralnmasından sorumludur
• Product owner bir kişi olmalıdır
• Product Owner ve Scrum Master aynı kişi olmamalıdır
• Takım çoklu disiplinli(cross-functional) elemanlardan oluşmalıdır.
• Takımın içinde hiyerarşi yoktur. Herkes kendi üzerine düşen işi bir fiil yapar. Başkasına iş yaptırtılmaz
• Takım içinde ünvanlar yoktur. Herkes takım üyesi olarak geçer
• Takım sayısı için optimal sayı 7 (+/-2)’dir
• Release Planning Meetings opsiyoneldir. Product Backlog’u oluşturacak paketlerin tahminlemesi(bütçe/süre) ve önceliklendirmesi yapılır
• Sprint bir iterasyondur. Sprint başladığı andan itibaren sprint’in kapsamında değişiklik yapılamaz. Bu değişiklik Product Backlog’a eklenir. Gerekli zamanda başka bir sprint ile devreye alınır
• Sprintler iteratiftir. Aralarında zamansal olarak boşluk olmaz.
• Sprinter hedef bitiş tarihinden önce durdurulup iptal edilebilir. Sadece Product Owner buna karar verebilir.
• İptal edilen sprint içinde tamamlanmış iş paketleri gözden geçirilir. Eğer bunlar anlamlı bir iterasyon olabilecekse live’a alınır. Diğerleri ise product backlog’a geri gönderilir.
• Sprint Planning Meeting, sprint’in planlandığı yerdir. Bir aylık sprint için 8 saaten fazla sürmemelidir. 2 parçadan oluşur. Yarısı sprint’de neler yapılacağının berlilenmesi ile diğer yarısı ise bunların nasıl yapılacağının belirlenmesi ile geçer.
• Nasıl yapılacağı kısmında sprint’in WBS ve aktiviteleri oluşturulur(Sprint Backlog). Genelde bu aktivitelerin tamamı bu toplantıda tam olarak belirlenmez. %60-70’ı bu toplantıda yani sprint başlamadan önce konuşulur. Geri kalan kısım sprint başladıktan sonra yapılır(PMI’daki progressive elaboration)
• Her Sprint sonunda Sprint Review yapılır. 1 aylık sprint için 4 saati geçmemelidir.
• Sprint Retrospective, Sprint Review’den sonra yapılır. 1 aylık sprint için 3 saati geçmemelidir.
• Daily Scrum hergün takım tarafından yapılır. 15 dakikayı geçmemelidir. Statü toplantısı değildir.
• Product Backlog yapılacak iş listesinin tutulduğu yerdir. Sorumlusu Product Owner’dır
• Release Burndown Product Backlog için zaman ve kalan iş ilişkisini gösterir
• Sprint Backlog, Product Backlog’daki işleri gerçekleştirmek için gerekli taskları içerir
• Sprint Burndown, Sprint Backlog için zaman ve kalan iş ilişkisini gösterir.