5 YAZILIM PROJE YÖNETİMİ RİSKİ

5 YAZILIM PROJE YÖNETİMİ RİSKİ

Risk yönetimi, proje yönetimi bileşenlerinin içinde en fazla öneme sahip ögelerinden bir tanesi. Bu sebeple hakkında yazılmış onlarca kitap bulmak mümkün. Bunlardan bir tanesi ise yazılım geliştirme temelinde; Tom Demarco ve Timothy Lister tarafından yazılmış olan “Waltzing with Bears: Managing Risk on Software Projects” adlı kitap. Yazılım projelerinde karşılaşılan 5 önemli riske ilişkin Demarco ve Lister’ın sundukları agile yaklaşımı temelli çözüm önerileri Mike Griffiths tarafından paylaşıldı. Griffiths’in, ilgili kitabı refere alarak yazdığı konu hakkındaki yazısında yer alan beş yazılım proje yönetimi riski:

1. Yapısal Zamanlama Açıkları

Doğası gereği yazılımın elle tutulabilir olmaması ve kendine has olması sebebiyle; yazılım geliştirirken ölçüm ve zamanlama yapmak oldukça zordur. Demarco ve Lister, bu riski proje takımının planlama ve ölçümlemeye daha fazla dahil edilerek ve müşteriden doğrudan/erken geri bildirimler alınarak azalabileceğinden bahsediyor.

Agile yaklaşımında ise bu riski minimuma indirmek için XP’s planning game ve Wideband Delphi workshops gibi aktivitlerle takım tamamıyla planlamaya ve ölçümlemeye dahil edilir. Kısa koşular halinde çalışmak ve her koşunun sonunda çalışır bir ürün ortaya çıkarmak, takımın gerçek hızının ortaya çıkmasını ve projeye dahil olan tüm paydaşlar tarafından da projenin geldiği noktanın bilinir olmasını sağlamaktadır. Böylelikle, projenin ilerleyişi için şeffaflık ortamı da sağlanmış olur.

2. Artan Gereksinimler

Proje yürütülürken, proje başlangıcında tanımlanmayan ve sonradan dahil edilmesi istenen her yeni özellik ve gereksinim projenin planlanan bitiş süresini tehdit etmektedir. Kitapta bunun önüne müşteri ve geliştiricilerin projeye sürekli olarak involve olması çözüm olarak sunulurken, agile pratikleri çerçevesinde, proje devam ederken gelebilecek her türlü değişiklik ve istekler yazılım projesinin doğal bir sonucu olarak kabul edilir. Agile süreçlerde, değişiklikleri projeye dahil edip, daha önceden belirlenmiş talepler ile birlikte önceliklendirme süreci başlatılır. Önceliklendirilmiş son talep listesi üzerinden, seçilen istekler takım tarafından planlanarak gerçekleştirilmeye başlanır.

3. Çalışan Sirkülasyonu

Proje devam ederken, önemli bir pozisyondaki takım üyesinin ayrılması ve proje için önemli olan bilgileri beraberinde götürmesi, projenin gözle görülür bir şekilde gecikmesine ya da raydan çıkmasına sebep olması, proje yönetiminde karşılaşılması muhtemel bir diğer risk.Demarco ve Lister bu duruma takım içerisindeki işbirliğinin artmasını ve bilginin tüm takımca paylaşılmasını çözüm olarak sunarken; agile yaklaşımında ise daha güçlü bir temelde riski azaltmak için agile projeleri yürütülürken bilgi paylaşımı tekniklerinden biri olan pair programming, common code ownership ve daily stand-up toplantılarında takımın bütününe günlük raporlamaların yapılması önerisinde bulunuluyor. Böylelikle önemli bilgiler birden fazla takım üyesi tarafından paylaşılmakla beraber, takım içerisindeki çalışan sirkülasyon düşüşü gerçekleşmektedir. Sonuç olarak daha geniş bir çerçeveden bakıldığında takımın birbirine bağlı, ödüllendirmenin, yetkilendirmenin ve ortaklığın olduğu bir ortamda çalışması, takım üyelerinin başka bir yerde çalışma isteğini azaltacaktır.

4. Niteliklerin Belirsizliği

Kodlama ve entegrasyon süreci başladığında, spesifikasyonun tamamlanmadığı ya da gereksinimlerin ortaya konmasında çatışmaların olduğu net olarak görülmeye başlanır. Demarco ve Lister kitaplarında bu riski azaltmak için yol ayrımlarında karar vermesi için bu işe özel olarak proje yöneticisinin atanmasını önerir. Agile yaklaşımında ise tüm sorulara cevap verebilecek ve proje üzerinde karar verme yetkisine sahip product owner rolü bulunur. Product owner tek bir kişi ya da bir grubu temsil eden tek bir kişi olabilir. Geleneksel proje yaklaşımlarında ise karar verme ya da çatışmaları sonlandırma rolünü üstlenen kimse olmadığı için zarar görür.

5. Verimsizlik

Proje teslim tarihlerinin çok uzun bir süreci kapsaması, projenin daha ilk basamaklarında takım üyelerinin ‘işin acil olma’ duyarlılığını kaybetmelerine ve tekrar geri kazanamamalarına sebep olmaktadır. Bu riskin azaltılması için uzun proje süreçleri yerine kısa iterasyonlarla ve doğru insanlarla projeyi yürütmek, onlara koçluk etmek ve takım gelişimini sağlamak bu riski azaltma noktasında kitabın önerdiği bir yaklaşım.
Agile yaklaşımında ise Parkinson Yasası ve öğrenci sendromunu baz alınır. Parkinson Yasası’na göre işin bitmesine odaklanmak yerine, işe odaklanmak önemlidir. Öğrenci sendromunda ise belli bir süre içerisinde bitirilmesi gereken işlerde; insanlar verilen süre içerisinde işlerini bitirmek yerine, daha çok teslim tarihine yakın bir tarihe kadar beklemeyi tercih ederler ve öyle işe başlarlar. Agile yaklaşımında genellikle 1 – 4 hafta arasında değişen kısa iterasyonlarla çalışmak her zaman için aciliyet hissini canlı tutar.

Mike Griffiths’in The Top Five Software Project Risks adlı yazısından Türkçe’ye çevrilmiştir.