Çalıştığınız şirkette bir sabah proje yöneticinizden mail gelir: “Super kod adlı projeye kaynak olarak atandın. Bu projede seninle çalışacağız. Yazılım geliştiricimiz olarak senden aktif katılım, etkili zaman kullanımı ve hızlı sonuç bekliyoruz. Her zaman olduğu gibi, bu projede de başarılı sonuçlar alacağımıza eminim. Öncelikle senden proje için ihtiyaç duyacağın zamanı öğrenmem gerekiyor. Bunun için bana en kısa sürede dönüş yapabilir misin? Planlama yapacağım ve taskleri oluşturacağım.”
Yeni bir proje, yeni bir süreç… Ama daha önce de bu tip işleri yapmıştınız; öğrenciliğinizden itibaren bildiğiniz bir durum var karşınızda. Proje için gerekli işleri değerlendirip bir plan yapmanız gerekli ve bu plana uygun şekilde de kaç gün/haftaya ihtiyaç duyacağınızı belirteceksiniz. Peki, ne kadar zamana ihtiyaç duyuyorsunuz? Planlamayı, nasıl bir hesap üzerinden yapıyorsunuz?
Proje için belirlenmiş bir plan zaten büyük ihtimalle mevcut; projenin genel kısıtları dahilinde bir hedef tarihi var. yapılması gereken, bu süreyi nasıl değerlendireceğiniz ve size düşecek iş yükünü nasıl dağıtacağınız. Yani başlangıç bitiş tarihleri için sınırınız var. Ama sizin kişisel olarak ihtiyaç duyacağınız rakamı söylemeniz gerekiyor.
Maliyetin Çıkartılması
“Projede ne isteniyor? Hmm… Yeni bir iş akışı var, onay mekanizmaları, bazı uyarı ekranları, bilgilendirme emailleri… Şu kısım daha önce yaptığım projeye benziyor, şu satırlar için yeni bir modül yazmak gerekebilir… Evet, burası da dikkat edilmesi gereken bir nokta, yeni yazdığımız kütüphanedeki metotları kullanırsam faydalı olur. 20 gün desem? Yok, test zamanı süprizler olabilir, 30 desem? Bu sefer de fazla olacaktır. Tamam, en iyisi 25 gün diyelim. Ama şimdi de 25 dersem proje yöneticisi sıkıştırabilir, en iyisi birkaç gün daha ilave edeyim. Direk 25 demeyelim.” Değerlendirme sürecini hızlıca geçip maile cevap dönersiniz: ”Bu proje için 27-28 günlük bir efor harcayacağımı öngörüyorum. Buna göre plan yapılabilir. Tabi, önümüzdeki 3 ay birkaç projem daha var, planlama yaparken buna da dikkat etmek gerekecektir. Ama neticede toplam ihtiyaç yukarıdaki gibi olacaktır.”
Sizden bir tahmin istendi, birtakım değerlendirmeler yaptınız, karşılaştırma kullandınız ve belki küçük bir kısmı kafanızda çözümlediniz ve buna göre bir rakam ürettiniz. Daha sonra oluşabilecek negatif durumlar için de bir kota koydunuz ve sonuçta ihtiyaç duyduğunuz süreyi hesaplamış ve iletmiş oldunuz. Peki tam olarak bu süreçte ne tür işlemler oldu?
– Önce size bir talep geldi
– Talep içeriğini incelediniz
– Yapılması gerekecek işleri genel olarak sıraladınız
– Her bir iş için ya da benzer işler için ne kadar zaman harcayacağınızı düşündünüz
– İşlerin hangilerinin önceki yaptıklarınıza benzer olduğunu, hangilerinin yeni bir çaba gerektireceğini değerlendirdiniz
– Geçmiş tecrübeniz- az ya da çok, kod yazma hızınız, yeni ortam/modül/fonksiyon ihtiyaçları gibi birden çok açıdan durumu değerlendirdiniz
– İhtiyaç olan optimum zamanı, güvenli bir şekilde verdiniz
– Projede zaman kontrolü için oluşabilecek pazarlık payını da düşünerek kendinizi sağlama aldınız ve rakamı revize ettiniz 🙂
Yaptığınız işlem, efor tahmini olarak ifade edilmektedir. Yazılım geliştirme efor tahmini, yazılım projesinin tamamlanması için gereken kaynağın hesaplanması olarak tanımlanabilir. Buradaki senaryoda yazılım geliştirici gözüyle, sadece ilgili kişi için adam/gün cinsinden bir tahmin üretilmiş oldu.
Efor Tahmininde Temel Yaklaşımlar
Dikkat edilecek olursa, tahmin sürecinde temel girdilerden birisi, önceki işlerle mukayese iken, bir diğeri, ihtiyaç duyulacak özelliklerin geliştirilmesi için yazılması gereken nesnelerin değerlendirilmesiydi. Sonuçta da bu iki ana tema birleştirilerek bir rakam üretildi. İşte efor tahmininde de aslında bu 3 yaklaşım vardır. Tabi, akademik olarak çok daha standart adımları ve ölçüm noktaları mevcut , ancak, basitleştirilecek olursa 3 yaklaşım aşağıdaki gibi olacaktır:
– Uzman görüşüne göre tahminleme modelleri
– Parametrik modeller
– Hibrit modeller
Her bir başlık altında birden çok yöntem ve araç mevcuttur. Fakat örnek üzerinden gidilerek yaklaşımları tekrar değerlendirirsek, uzman görüşü, efor tahmini yapabilecek kabul edildiğiniz düşünüldüğünde, kişisel olarak sizin yetkinliğinize güvenilerek elde edilen bir veri oluyor. Parametrik modeller, daha çok standart birtakım ölçüm ve karşılaştırmaları içeriyor ve burada kullanacağınız metot, fonksiyon vs değerlendirmelerini bu noktada parametrik modeller altında sayabiliriz. Hibrit modeller de aslında her iki değerlendirmenin belli niteliklere göre birlikte kullanılmasını ifade ediyor. Olmayan dördüncü bir yaklaşım daha var tabi, kendini sağlama alma J bunun için de ekstradan birkaç gün eklediniz.
Efor tahmini konusu, hem literatürde, hem de pratikte sürekli tartışılan, sürekli gündemde olan, metotların varlığının, ölçüm kalitesinin, kullanılan yöntemlerin sürekli eleştirildiği ama yine de eleştirilen unsurların kullanıldığı canlı bir konudur. Yazılım geliştirici, test uzmanı, analist, proje yöneticisi ya da proje içerisindeki herhangi bir kaynak için geçerli olan bir kavramdır efor tahmini. Tekil olarak bu sorumlulukların ortaya çıkardığı tahminlerin toplamı da bir bakıma proje bağlamında eforu ortaya çıkaracaktır. Dolayısıyla, yazılım dünyasında olan herkesin, hasbelkader konuyla ilgilisi ve bağı vardır. Bu ilginin daha net tanımlanması, belki de hergün yapılan işlerin aslında nasıl bir model üzerine oturduğunun bilinmesi, projelerimizde daha efektif tahmin ve dolayısıyla planlama yapılmasına katkı sağlayacaktır.
Bu yazıda efor tahmini denilince akılda canlanan kavram ve literatürdeki anlamı arasında ilişki kurulması üzerinde duruldu. Bundan sonraki yazıda biraz daha teknik tanımlara gidilecek ve tahmin modellerinden genel olarak bahsedilecek, daha sonra bu modellerin avantaj dezavantajları izah edilecektir. Devamında da pratik uygulamalarda nasıl bir yöntem izleneceğiyle ilgili genel değerlendirmeler yapılacaktır.
