Yazılım Geliştirme Süresi Nasıl Doğru Tahmin Edilir?

İÇİNDEKİLER:
- Neden Yazılım Projelerini Tahmin Etmemiz Gerekiyor?
- Agile Projelerde Tahminleme Nasıl Yapılır?
- Projeleri Kim Tahmin Eder?
- Tahminler Ne Zaman Yapılmalıdır?
- Tahminler Neden Başarısız Oluyor?
- Bir Yazılım Projesini Doğru Tahminleme Nelere Bağlıdır?
- Örnek Case

Paydaşların ve müşterilerin zaman tahminleri konusunda ne kadar hevesli ve ısrarcı olduklarını biliyoruz. Ayrıca bir projeyi ancak bütçe dahilinde ve söz verilen zaman aralığında tamamlanmışsa başarılı olarak değerlendirdiklerini de biliyoruz.

Aslında bunun arkasında geçerli sebepleri var.

Bir ürün sadece yazılım aşamasından oluşmuyor. Bunun yazılım dışı diğer işleri, pazarlama süreci, pazar fırsatlarını değerlendirme, lansman, sözleşme koşulları vb. çok farklı alanları da kapsıyor. Bu yüzden developer ekibin yapacağı “tahminleme” tüm ekipler için kritik bir mevzu.

Developer gözünden baktığımızda ise faydaları tam net değil. Aslında developer’ın tahminlerini bir vaat olarak yorumlanıp ardından sürekli aleyhine kullanırsanız, süre tahminlemenin hiç bir faydası yokmuş gibi hissedilebilirsiniz. Bu nedenle, developer’ların genellikle tahmin etme süreçlerinde neden isteksiz olduklarını anlamak pek de zor değil. Yaptığınız bir şey size sürekli sıkıntı çıkaracakmış gibi huzursuz hissettiriyorsa, o işi isteyerek yapmaya devam eder misiniz?

Developer’ların bu düşünce tarzını anlayışla karşılamalıyız. Ancak gerçek şu ki, tahminler developerlar’a ciddi fayda sağlayabilir. Hatta zaman içinde paydaşların gözünde statülerini yükseltebilir ve onlara tahmin edebileceklerinden daha fazla pazarlık gücü verebilirler.

Peki nasıl? İsterseniz derin bir görüş elde edebilmek adına önce tanımları yapalım, yazının sonunda bu konuya tekrar dönelim.

Neden Yazılım Projelerini Tahmin Etmemiz Gerekiyor?

Tahmin, tanımı gereği, sezgiye veya bazı verilere dayanarak önceden değerlendirme yapmaktır.

Yazılım sistemleri ne kadarkarmaşık hale geldikçe, SDLC da daha karmaşık hale gelmektedir. Bu karmaşılık işin boyutunu arttırır ve bu da yazılım geliştirme eforunu tahmin etmeyi zorlaştırır.

Product Owner bir fikrin ürüne dönüşmesi sürecinin ne kadar zaman ve emek gerektireceğini bilmesi gerekiyor çünkü ürün için belirlenecek yatırım kararı buna göre şekillendirilecek. Bu nedenle zaman ve diğer maliyetleri doğru bir şekilde hesaplamak, uygulanması sırasında ekstra para ve zaman kaybetmemek ister. İsterseniz fail olan startup listelerine şuradan ulaşabilirsiniz :)

Product Owner’ın ihtiyaç olarak ilettiği bir gereksinimi uygulamak için gerekli olan süreye yazılım geliştirme süresi diyoruz. İhtiyaç olarak iletilen bu gereksinim, örneğin: bir improvement, feature veya bir user story vb. olabilir. Tüm gereksinimlerin uygulanması için gereken saatlerin toplamı, tüm uygulamanın tahminini oluşturur.

Agile projelerde tahminleme nasıl yapılır?

Agile, tanımı gereği sürekli iyileştirmeye odaklanan bir yazılım geliştirme metodudur. Gereksinimler ve çözümler ürün yaşam döngüsü boyunca değişmeye devam eder, bu da waterfall’da olduğu gibi sıkı bir schedule planı oluşturmayı ve ona bağlı kalmayı imkansız hale getirir. Bu konuda daha önce yayınladığım bu yazıma göz atabilirsiniz.

Projeleri kim tahmin eder?

Genellikle projelerin tahmininden proje ekibinin tamamı sorumludur. Product Owner ise, tahminlerin kaydedilmesinden, takip edilmesinden ve tamamlanmasından sorumludur.

Fakat yine de, tahminlerin analizi ve oluşturulmasında tüm ekip ve konunun uzmanları (operasyon ekibi, IT manager, müşteri temsilcisi vb.) yardımcı olmalıdır. Ne kadar bilgili insanları proje analiz aşamasına dahil ederseniz, gerçekçi tahminler oluşturma olasılığınız o kadar artar.

Tahminler ne zaman yapılmalıdır?

Geleneksel bir Waterfall projesinde planlama aşaması, proje başlangıcından hemen sonra gelir. Bu aşamada, kapsam, zaman, maliyet, risk, kaynak gibi bölümler için tahminler oluşturulur ve belgelenir.

Tahminler elbetteki yeni durumlar ortaya çıktıkça, proje boyunca adjust edilebilir. Örneğin, yeni riskler tanımlandıkça proje risk tahminlerinizin güncellenmesi veya bir kaynağınızın farklı bir projeye atanması gerekiyorsa task sürelerinin de bağımlılıkların güncellenmesi gerekecektir.

Agile projeler ise planlamaya daha yinelemeli bir yaklaşım getirir. Çoğu Agile framework’ünde, projeleri sprintlere böleriz. Bu durumda, ilk olarak, genel Project Backlog’u (özellikler ve gereksinimlerin olduğu liste) oluşturulurken ve daha sonra her sprint sırasında tahminler yapılır.

Tahminleme, her sprint sonundaki çıktılara göre Project Backlog’u güncellediğimiz gibi, Sprint Retrospective toplantılarında veya her yeni sprint başlangıcında yaptığımız Sprint Planning toplantısı sırasında da yapılabilir.

Tahminler neden başarısız oluyor?

Bu genellikle ekiplerin tahminleme eforuna bakış açısından kaynaklanıyor. Burada Product Owner’a büyük sorumluluk düşüyor. PO’nun bu sürecin yapılmasının ana faydasını ekiplere açıklarken tahminleme görevinin aslında “aynı frekansta karşılıklı konuşma” olduğunu öğretmelidir. Ne kastediyorum?

Deneyimlerime göre, PO ile ekip arasında genellike şöyle bir konuşma geçiyor:

Ekibe yeni bir feature fikri ile gittiğinizde ve “Sorunuz var mı?” diye sorduğunuzda, %80 “hayır” cevabı alırsınız.

Daha da kötüsü, “Peki her şeyi anladınız mı?” diye sorduğunuzda “Elbette anladım- yıllardır bu işi yapıyorum!” cevabını verirler.

İçiniz rahat bir şekilde “Tamam, o zaman bu feature için zaman tahmini alabilir miyim?” diye sorduğunuzda ise durum tamamen farklılaşır ve ortalık sessizleşir.

İşte bu son sorundan sonra ancak developerlar talebe odaklanmaya, DoD’leri belirlemeye, tecrübeli yazılımcılar ile görüşmeye vs. başlar.

Bu örnek aslında yazımın başında bahsettiğim fayda-çıkar ikileminden kaynaklanıyor. Daha başarılı ve verimli bir tahminleme yönetimi için Product Owner mutlaka ekip ile bu karşılıklı konuşmaları yapmalıdır.

Bir yazılım projesini doğru tahminleme nelere bağlıdır?

Test, proje yönetimi, implementasyon, iletişim, riskler, insan faktörü, deneyim.. Bunlar bir çırpıda aklıma gelenler. Tahminleme teoride basit görünüyor fakat bir yazılım projesi tahmininin kesinliğini etkileyen birçok faktör var.

Yine deneyimlerime göre büyük bir bölümü gereksinimlerin kalitesine ve hedeflerin net bir şekilde belirlenmesine bağlı olduğu düşünüyorum. Çünkü gereksinimler ile implementasyon arasında proje boyunca sürekli bir gerilim yaşıyoruz :) Evet, proje başlarında tam anlamıyla net gereksinimlere sahip olmak biraz hayalperestlik olur çünkü her zaman düşünmediğimiz bir detay ortaya çıkar veya PO kapsam kayması oluşturabilecek bir istekle çıkagelir fakat bunu ne kadar aza indirebilir ve disiplinli olabilirsek (Hayır demeyi öğrenmek) takip ettiğimiz çizgiden çıkmamış ve projeyi ve ürünü güvende tutmuş oluruz. Bunu bir örnekle daha anlaşılır hale getirelim.

Örnek Case:

Herhangi bir yazılım uygulamasının ihtiyaç duyduğu basit bir Authentication gereksinimi oluşturalım.

Gereksinim:
Kullanıcıların oturum açmasını sağlamak

Varsayımlar:
Framework — Seçildi
Infrastructure — Seçildi
Logging — Seçildi

WBS:
Login form yapısının oluşturulması
Credentials’ın gönderileceği rest endpoint oluşturulması
Parola için şifreleme tekniğinin oluşturulması
Credentials’ı depolamak ve almak için datastore oluşturulması

Bu bilgiler ile bir estimation yapmak yeterli mi? Takım işe başladığı andan itibaren daha birçok detay ortaya çıkmaya başlar ve estimation hedefinden saparsınız.

Parola için strenght belirlenecek mi?
Kullanıcılar ne kadar süre login kalabilir? Kullanıcılar ne kadar süre idle kalabilir?
Kullanıcıların kaç hatalı giriş hakkı var?

Gördüğünüz gibi, gerçekten ne istediğinize yeterince kafa yormadıysanız her gün aklınıza gelecek yeni bir gereksinim ilk tahminden biraz daha sapmanıza neden olacaktır. Bu ileride ürün üzerindeki kontrolünüzü kaybetmenize bile neden olabilir. Ne istediğinizi ne kadar çok bilirseniz ve odaklanmayı sürdürebilirseniz o kadar iyi tahminler elde edersiniz.