Yazılım Projelerinin Zaman Planmasında 12 Problem
Bir yazilim projesinde zaman planlamasi yapmak zor bir istir, fakat hala çogu firma bu zaman planlamalarina dayanarak projelerini yürütmeye devam ederler. Bu yazida yazilim projelerinde yapilan zaman planlamalarinda yapilan en temel 12 hataya dikkat çekmeye çalisacagim.
- Bilinmeyen üzerine plan yapmak imkansizdir
- Yapilan Planlar Genelde Iyimserdir
- Verilen Zaman Sonuna Kadar Kullanilir
- Firmalar Zaman Planlamarina Oldukça Fazla Itimat Eder
- Önrülemeyen Seyler Üzerine Çok Fazla Zaman Harcanir
- Zaman Planlamasina Tahmi Gözüyle Bakilmamasi
- Programcilar Arasindaki Verimlilik Farklari Gözardi Edilir
- Müsterinin Isteklerindeki Degisiklik Proje Planina Yansitilmaz
- Gerçek Anlasildiginda Genelde Çok Geç Kalinmistir
- Bir Plan Geciktiginde Digerleri de Güncellenmeli
- Planlar Gerçeklesmediginde Programcilar Suçlanir
- Planlari Yanlis Insanlar Yapar
Çogu yazilim birbirinden farklidir, ve her projede neredeyse daha önce hiç yapilmamis bir ürün gelistirilir. Projede yapilacaklar belirli olsa bile, karmasik bir sistemi gelistirmek istenen belli olmasina ragmen bile zordur.
Bir program bir çok farkli yöntem ile yapilabilir. Zaman planlamasi asamasinda net olarak belirlenemeyen dizayn seçimleri, bir yazilimin bitis zamanini dogrudan etkiler.
Yapilan zaman planlarinin, istenildigi sekilde yürüyebilmesi için kabul görmüs belli basli yöntemler vardir fakat, en iyi yöntemle bile yapilan plan, yazilim gelistirme aktif olarak baslamadigi için öngörü ve varsayimdan ibarettir.
Çogu programci planlarini oldukça iyimser varsayimlar üzerine yapar. Proje basladiginda daha üretken olacaklarini düsündüklerinden veya projenin karmasikligini tam olarak anlayamadiklarindan iyimser varsayimlarda bulunmus olabilirler. Bu planlari degerlendiren kisiler genelde bu iyimser planlamari biraz daha genisletip daha gerçekçi hale getirirler. Örnegin kodun yazilmasi bir haftada biter gibi bir tahminde bulunulmussa bunu 2 hafta veya bir aya çikarmakla daha gerçekçi planlar elde edilebilir.
Çogu programci verilen zamani sonuna kadar kullanmaya meyillidir. Yaptiklari isi erken bitirseler bile, kalani zamani projeye katkisi olmayacak kod düzeltmeleri yapmak, kodu birazcik hizlandirmak için harcarlar. Bazende isini bitirdikten sonra verilen zamanin bitmesini bekleyip farkli bir ise baslamazlar. Bu yaklasimla isler asla planlandigindan çabuk bitmez, ya saydigim nedenlerden ötürü zamaninda biter, ya da isler yolunda gitmez ve gecikir.
Ürün çikis tarihleri, fuarlara katilim ve tanitim tarihleri hepsi projenin zaman planmasi baz alinarak yapilir. Satis ve pazarlama birimleri anlasmalarini bu tahminler üzerine yapar ve yapilan planlamada olusacak bir gecikme daha baska yapilan bir çok planinda gecikmesine neden olur.
Yapilan tahminler mükemmel bile olsalar, proje üzerinde çalisirken karsimiza öngöremedigimiz bir çok problem çikar. Eski versiyonlarda problemler çikar bunlari düzelmek için kaynak ayirmamiz gerekir, çalisanimiz hastalanmis olabilir, proje esnasinda bekledigimiz yeni isler çikmis olabilir. Çogu sirket planlarini yaparken bu gibi durumlar için ekstra zaman ayirir, fakat varsayimlar üzerine yapilmis bir plana varsayimlar üzerine ekstra zaman eklemekle nekadar güvenilir birsey elde etmis oluruz ?
Yapilan zaman planlari aslinda bir tür tahmindir fakat insanlar buna tahmin gözüyle bakmazlar, bu planlara kesinlikle aksamayacak gerçeklesecek gözüyle bakilir ve baska planlarda buna güvenerek yapilir. Ilk planda olacak bir gecikme bu yüzden zincir etkisiyle diger planlari da etkiler.
Bu durum yapilan zaman planlamarini daha da zorlastirir. Insaat sektöründe duvar ustalarinin ortalama bir duvari örme hizini bilebilirsiniz fakat bir isi yapma hizi programcilar arasinda çok büyük farklilik gösterir. Is yapma hizi ve bir isin bitmesi için gerek efor: bu iki bilinmeyeni kullanarak tahmin yapmaya çalistiginiz da isiniz daha da zorlasir.
Programci kendi yapacagi isin zaman planlamasini kendi yaptiginda isiniz az da olsa kolaylasir çünkü kendi üretkenlikleri hakkinda sizden daha çok bilgileri vardir. Fakat bu tahminleri onlar yerine genelde proje yöneticileri yapar ve bütün programcilara esit üretkenlikteymisler gibi davranir.
Proje devam ederken, ortaya ufak ufak birseyler çikmaya basladiginda müsteri ortaya çikan bazi özelliklerden memnun olmaz degistirtmek ister veya memnun kalir ve ekstra bir kaç sey daha eklenmesini ister. Bu gibi degisiklikler proje planina bazen yansitilmaz fakat her gelen istek yapilacak fazladan is oldugu için bu gibi durumlar plana yansitilmak zorundadir.
Önceki maddelerde belirtmistik programcilar genelde iyimser tahminlerde bulunurlar. Çogu zaman iyimser tahminde bulunduklarina ve projeyi yetistiremeyeceklerine inanmazlar taa ki son gün gelipte daha yapilacak bir çok isin kaldigi anlasilincaya kadar. Fakat artik çok geç kalinmistir, proje gecikmis ürün çikis tarihi ertelenmistir.
Programcilar genelde projenin planlanan bir kismini zamaninda bitiremediklerinde, diger yapacaklari islerin planlarini güncellemezler. Arada kaybolan zamani sonraki isleri daha hizlari yaparak kapatacaklarina inanirlar fakat genelde tam tersi. Böyle bir durum genelde iyimser tahmin yapildiginda isarettir
Planlar geciktiginde suçlanacak birileri bulunmaya çalisilir ve bu genelde plana ayak uyduramayan programcilar olur. Bu stresli bir çalisma ortami yaratir ve programci sonraki projelerde suçlanmamak için yaptigi zaman planlamarinda genis davranir.
Programcilar üzerinde çalistiklari konuyla ilgili tahminleri kendileri yapmalilar. Proje yöneticisi bu tahmini onun yerind yaptigi zaman zamanlama konusunda sikintilar yasanir. Eger çalistiginiz yerde MBA yapmis biri sizin yerinize çalistiginiz is üzerinde plan yapiyor ise orada durmayin
12 Problems With Software Estimation yazisinin çevirisidir.
