Yazılım Projelerinde Süre Optimizasyonu

Bu yazımda özellikle yazılım projelerinde sürelendirmenin ve planlamanın kendi açımdan nasıl yapılması gerektiğine değineceğim.

Bildiğimiz gibi projeler doğası gereği belli bir sürede bitirilebilen, tekrarlı olmayan ve belli oranda belirsizlik içeren akitiviteler bütünüdür. Yazılım projeleri ise belirsizlik bacağında diğer projelerden biraz daha farklılaşmaktadır. Büyük oranda sanal dünyada, elle tutulmayan ve gözle görülmeyen bir ürün çıkacağından, gereksinim toplamadan bunu hayata geçirmeye kadar bir çok belirsizlik projeyi beklemektedir. Bu belirsizliklerden bazıları projenin gidişatı için bir tehdit oluşturabilir. Bu tehditlerin farkedilmesi, etkisinin ve oluşma olasığının tahmin edilmesi ile karşı karşıya kalınan riskin büyüklük ve önemini anlayabiliriz.

Konumuza dönecek olursak, yazılım projelerinde proje yöneticilerinin en büyük sorunlarından birisi verilen süre taahhütüne göre projeyi zamanında bitirebilmektir. Bilindiği gibi bir yazılım projesi, gereksinim toplama(ön analiz), analiz, tasarım, kodlama, entegrasyon, sistem test, kullanıcı test ve pilot uygulama ve yaygınlaşma adımlarından oluşur. Bana göre yapılan en büyük hata gereksinim toplama aşamasında işin kabaca büyüklüğünü tahmin ederek verilen sürenin müşteri ve proje ekibi tarafından taahhüt olarak algılanmasında yatmaktadır. Bu aşamada verilen bir süre en kaba tabirle bir “temenni” den öteye geçemez. Bu aşamada elbetteki bir süre verilecektir, fakat bu sürenin kaba bir sürelendirme(Dallpark Estimate) olduğu ve yüksek bir yanılma payı içerdiği mutlaka müşteri ile paylaşılmalıdır.

Daha az yanılma paylı bir tahminleme ancak analiz çalışması olgunlaştıktan sonra yapılabilir. Tahminlemede şunlara dikkat edilmelidir;

• Süre tahminlemesinde mümkünse benzer projelerde yapılan süreler kullanılmalıdır. Fakat bunu yapabilmek için iyi işletilen ve güncelliğini koruyan bir servis envanterine ihtiyaç vardır. Günümüzde yüksek seviyeli diller kullanıldığı için SLOC(Source Lines of Code) gibi tekniklerle tahminleme yapmak da çok sağlıklı olmayacaktır
• Böyle bir tahminleme yapılamıyorsa uzman görüşü almak daha sağlıklı olacaktır. Fakat tek bir uzman yerine birden fazla uzmandan görüş alarak çapraz doğrulama yapmak daha sağlıklı bir yöntem olacaktır.
• Uzmanlarla veya ekip üyeleri ile süre pazarlığı yapılmamalıdır. Bu şekilde yapılan bir planda, yaşanacak herhangi bir gecikme durumunda, proje yöneticisi olarak sorumluluğu tek başınıza alıyorsunuz demektir. Ek olarak çalışan, içine sinmeyen bir planı asla gerçek anlamda sahiplenmeyecektir.
• Aktiviteleri mümkünse tek kişiye atanabilecek seviyeye indirmek daha sağlıklı olacaktır. Aktivite büyüklükleri mutlaka adam/gün bazında büyüklük olarak belirlenmelidir.
•  Aktivitelerin sürelendirmesi yapılırken, bu aktivitede kullanılacak kaynağın günde bu işe ne kadar efor harcayacağına göre sürelendirme yapılmalıdır.
• Eğer birden fazla kaynak aynı akitivite ile uğraşacaksa yazılımda, inşaat işinde olduğu gibi kaynak yüklemesi yapıldıkça aktivite süresinin de o ölçüde azalacağı beklenmemelidir. Yazılım projelerinde aktiviteye birden fazla kaynak atamanın, entegrasyon ve senkronizasyon sorunları getirdiği için süreyi kısaltmak bir yana uzatabileceği göz önünde bulundurumalıdır.
• Projede belli bir tarihe yetişme kaygısı ile fast-tracking diye tabir edilen işlerin üst üste bindirilmesinden mümkün olduğunca kaçınmalıdır. İşler ve kaynaklar birbirinden bağımsız ise bu yapılabilir aksi takdirde aynı kişinin gün içinde iki farklı işi yapabileceğini düşünmek hayalperestlik olur. Bu size kağıt üstünde güzel bir plan sunar ama gerçek hayatta bu asla olmayacaktır.
•  Planı ve süreyi hazırlayıp yayımladıktan sonra mutlaka sıkı bir izleme prosedürü belirlenmeldir. Telafi edilemeyecek bir sapma durumunda plan revize edilmeli, müşteri bu konuda bilgilendirilmelidir.
• Son olarak da projede müşteriden gizli gündem, gizli süre olmamalıdır. Gerekçeli revizyon ihtiyacı müşteriye ne kadar geç ulaşırsa müşterideki hayal kırıklığı ve güvensizlik o kadar büyük olacaktır. Bunun yerine sık sık gerekçeli kararlarla revizyon ihtiyacını müşteri ile paylaşmak hem müşterinin proje ekibine karşı samimiyet duygusunu artırabilecek ve müşteriye projeye daha müdahil olduğu duygusunu verecektir.