Bir şeyi, bir olguyu, bir kavramı gerçekten anladığımızı ve içselleştirdiğimizi iddia edebilmemiz için onun felsefesini, tarihini (nereden nereye geldiğini), o kavram hakkındaki güncel gelişmeleri takip etmemiz ve neye dönüşüyor olduğunu bilmemiz gerekir. Bu perspektiften bakınca, geçmişi çok da uzaklara gitmeyen yazılım geliştirme süreçlerinin de, zamanın ruhunu yakalamak için hayatın doğal akışı içerisinde kendine yeni kalıplar aradığını ve güncel gelişmelere ve ihtiyaçlara bağlı olarak yeni kavramlar ortaya çıkardığını söyleyebiliriz. Ancak geliştirme ekibinin ihtiyaçlarını karşılayan bir yöntem, gelecekte bu ihtiyaçlara cevap veremeyebilir ve yerini o zamanın ihtiyaçlarına cevap veren başka yöntemlere bırakması gerektiği de her zaman göz önünde bulundurulması gereken bir gerçektir. Öyle ya da böyle, günümüz IT ekiplerinin büyük çoğunluğu ya Çevik yöntemlerle yazılım geliştiriyor* ya da geleneksel yöntemlerden çıkıp ihtiyaçlarına cevap bulabilmek adına Çevik yöntemlere geçmek için danışmanlık alıyor**. Yazılım geliştirme sürecinde takip edilen yöntemde değişikliğe gidilirken süreç içerisinde uyum sağlamakta en çok zorlanılan husus hiç şüphesiz zihin yapısını değiştirmektir. Çevik pratikler, bilişim dünyasına birçok yeni kavram getirir ve yazılım geliştirme süreçlerinde paradigma değişikliğine gider; böylelikle sizden düşünme sistematiğinizi ve olaylara bakış açınızı değiştirmenizi talep eder.
Story Point
Yazılım eforlandırma, IT ekiplerinin en çok zorlandığı hususların başında gelir. Çevik yaklaşımlardaki iyi uygulamalar, adam/gün bazlı eforlandırma yerine Story Point kavramını karşımıza çıkartır ve sizden yapılacak işin büyüklüğü, karmaşıklığı, içerdiği riskler ve belirsizlikleri göz önünde bulundurarak harcanacak çaba hakkında tahmini bir eforlama yapmanızı ister***. Bu açıklamaya göre, yapılacak tahminlemeyi aşağıdaki gibi formülize edebiliriz. Story Point tahminleme yaparken bu parametrelere göre düşünerek puanlama yapılması beklenir.
Story Point = ƒ (Volume, Risk & Uncertainty, Complexity)
Volume: Yapılacak İşin miktarını gösterir. Yapılacak işten kaç tane yapılacağına göre işin büyüklüğü de artacaktır. Örneğin bir web sayfasına datetime-picker alanı eklenmesini düşünelim. Bundan 1 tane eklenmesiyle 5 tane eklenmesi arasında volume olarak fark vardır. Volume olarak fark olmasına karşın 1 tane eklemekle 5 tane eklemek arasında risk olarak ve komplekslik olarak bir fark bulunmadığı da aşikardır.
Risk & Uncertainty: Story point tahminlemesi yapılan iş tam anlamıyla net değilse, belirsizlikler varsa, teknolojik olarak kısıtlamalar varsa ve araştırma yapılması gerekiyorsa bunlar da göz önünde bulundurulmalı ve içerdiği risk ve belirsizlik nispetinde puanı artırılmalıdır.
Complexity: Şöyle düşünelim, aynı uygulamanın iki farklı sayfasına birer filtre alanı eklenecek. Sayfalardan birine güveniyorsunuz. Fakat diğer sayfada ise bir sürü iş kuralı var, kodlar birbirine girmiş, işi üzerine alanın elinde kalacak türden bir sayfa haline gelmiş. Üstelik bu sayfanız süreç içerisinde işin yürütüldüğü önemli bir sayfa ve sayfanın patlaması süreçte aksaklığa yol açacak. Şimdi bu sayfalara eklenecek filtre alanlarının ikisine de 5 puan demek doğru olabilir mi? Olmaz tabii ki. Daha kompleks sayfa, hem geliştirme bakımından hem de test bakımından daha fazla uğraş gerektirdiği için bu parametreyi göz önünde tutarak daha fazla puan verilmesi gerekir.
Neden Story Point?
Bakış açısında böyle bir değişikliğe gidilmesinin altında yatan temel motivasyon, yıllar içinde özellikle yazılım geliştirme süreçlerindeki adam/gün gibi mutlak zamana dayalı tahminlemede verilen sürelerin çoğu kez karşılanamamasından kaynaklanıyor. Bu durumu şöyle de açıklayabiliriz: İnsan beyni mutlak zamana dayalı tahminlemede iyi değil, hatta çok kötü. Zamana yayılan bir projenin bitirilmesini ve ortaya çıkarılmasını etkileyen o kadar çok faktör var ki; 6 aya biter denilip ancak yıllar sonra bitirilebilen birçok proje var. İyimserlik önyargısıyla azımsanarak verilen deadlinelar’ın proje ekiplerinin fazla mesailerle geçen aylarına mal olduğu bilinen bir gerçek. “Bu işi ne zamana bitiririz?” sorusuyla karşılaşılan bir durumda verilen “Yaa biz o işi daha önce yapmıştık, o iş kolay 2 aya hallederiz.” söylemleri maalesef bir varsayımdan öteye geçememiştir. Üstelik karşı tarafı beklentiye soktuğu için de IT ekiplerinde imaj kaybı yaratmıştır. Her halükarda, ortada yapılacak bir iş ve belli bir zaman dilimi sonunda o işin bitirilmesini bekleyen patron, iş birimi, proje yöneticisi var. İşte bu noktada, odak noktasını yapılacak işin ne kadar zamanda çıkarılacağı yerine işin büyüklüğüne kaydırarak göreceli bir öngörüde bulunabiliriz.
Story Point tahminleme belki de Çevik süreçlerin en önemli aktivitelerinden birisidir. Bunun yanında, güvenilir ve denenmiş bir yöntem izlenmeksizin girişilen tahminleme aktivitesi de maalesef Çevik felsefesinden uzak sonuçlara sebep olacak ve tutarsız tahminlemekten kaynaklı ekstra mesailer ve memnuniyetsizlikler getirecektir. Bu durumun önüne geçmek için kazanılması gereken bazı iyi uygulamalar bulunmaktadır.
Objektif ölçütler kullanın
Örneğin; İstanbul’u ve Ankara’yı bilen bir grup insana bir harita gösterip aşağıdaki soruları soralım:
- İstanbul’dan Ankara’ya kaç saatte gidersiniz?
- İstanbul-Ankara arası kaç km?
İlk soruya; 1 saatte giderim, 5 saatte giderim, 4 saatte giderim, 48 saatte giderim veya 88 saatte giderim diyenler çıkacaktır. Bunların hepsi bir bakıma doğrudur çünkü kimi uçakla gitmeyi düşündü, kimi arabayla, kimi trenle, kimi bisikletle veya kimi de yürüyerek gitmeyi düşündü. 1 saatle 88 saat arasında değişen bir tahminleme kümesi.
İkinci soruya ise; 350 km, 450 km, 450 km, 400 km, 450 km gibi birbirine yakın tahminler gelecektir. Daha önceden bildikleri ve deneyimledikleri bir güzergahın mesafesini tahmin etmekte zorlanmamış olsa gerek.
İlk soru bizden zaman gibi subjektif bir yargı isterken; ikinci soru mesafe gibi ölçütleri iyi tanımlanmış objektif bir yargı istiyor. İki nokta arasındaki mesafeyi kolaylıkla kestirebiliyoruz çünkü mesafelerle ilgili mutlak ölçütlerimiz var, metre santim gibi. Doğal olarak, ikinci soruya gelen cevaplar bakış açısını yapılacak işe odaklayarak, objektif yargı içeren tahminler ortaya çıkmasını sağlıyor.
İşte bunun gibi Yazılım Geliştirme süreçlerinde efor tahminlemesi yaparken “geliştirme süresi (adam/gün)” gibi bir ölçü yerine “Story Point” gibi bir ölçü kullanmamız daha doğru olacaktır. User Story’nin içerisinde iş kurallarının belirlenmesi, kabul testleri, UI prototipleme, aktivite diyagramı, tasklar gibi işler olduğu düşünülürse bu seviyedeki bir işin “TAMAM” olana kadar geçecek zamanı adam/gün olarak tahminlemenin zorluğu daha net ortaya çıkacaktır.
Mümkün olduğunca göreceli tahminler kullanın
Sizin de fark edeceğiniz üzere “story point” kavramı soyut bir ölçü gibi kalıyor ve sanki biraz kafa karıştırıcı. Yani metre, santim, inch, mil, vs. nedir dediğimizde üzerinde mutabık kalınmış, iyi tanımlanmış ve dokümante edilmiş uluslararası standartlar bulunurken; aynı şeyi “story point” için söyleyemeyiz. Zira elle tutulur, gözle görülür somut bir ölçütü yok. Ancak bunun çok da bir önemi yok çünkü story point kavramındaki asıl mesele göreceli tahminler kullanmak.
Yukarıdaki örneğimizde İstanbul ve Ankara’yı bilen bir grup insana haritada bildikleri iki şehir arasındaki mesafeyi sormuştuk. Onlar da tahmini yaklaşık cevaplar vermişlerdi. Şimdi ise; bu gruptaki insanlara bilmedikleri bir mesafe olan İstanbul-Sivas arasındaki mesafeyi soralım. Bilmedikleri mesafe hakkında tahminleme yaparken zorlanacakları çok açık. Ancak tahmini bir cevap vermeleri de çok kolay çünkü baz alabilecekleri bir mesafe zaten var: İstanbul-Ankara. Yani haritaya bakıp şunu deme noktasına gelmeleri çok kolay: İstanbul-Sivas arasındaki mesafe, İstanbul-Ankara arasındaki mesafenin 2 katı. Kimse kaç kilometre olduğunu düşündü mü? Hayır. Sadece haritaya bakıp 2 katı kadar mesafe olduğunu gördüler. Bu da bize gösteriyor ki; insan beyni göreceli değerler arasında tahmin yapmakta çok daha iyi. “Story Point” kavramını ortaya çıkaran motivasyonun arkasındaki felsefe de bizden bunu bekliyor: Göreceli Tahminleme.
Story Point tahminlemede esas mesele mutlak bir tahminleme yapmaktan ziyade göreceli bir tahminleme yapabilmekte. Göreceli tahminleme yapmakta en çok kullanılan yöntem ise Fibonacci dizisi.
Fibonacci dizisi hatırlayacağınız üzere 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55,… şeklinde önceki iki sayının toplamı olacak şekilde artan sayılardan oluşuyor. Fibonacci dizisini ilginç kılan durum dizideki sayıların arasındaki artış oranının bir süre sonra %61 civarında devam etmesi, ki bu da bizim göreceli tahmin yapmamızı kolaylaştırıyor. Yani artan sayılar arasındaki oransal değişiklik aynı kalıyor. Tabi burada önemli olan sayılar arasındaki orandır. Yani 0, 10, 10, 20, 30, 50, 80, 130, 210,… da bir Fibonacci dizisidir.
Bu noktada şunu belirtmekte fayda var, Story Point tahminlemesi yaparken ortalama almak tutarsızlığa neden olacaktır. Yani; bir user story düşünelim; takımın yarısı 3 puanlık bir iş diyor, diğer yarısı da 5 diyor. “O zaman 4 puanda anlaşalım” deyip geçmek yanlış olacaktır. Bunun yerine, 3 diyenler ya da 5 diyenler neden öyle dediklerine dair birbirini ikna etmeli ve ölçek olarak kullanılan puan noktası üzerinde anlaşmalıdır. Unutmamak gerekir ki; hedefimiz %100 doğru puanlamak değil, sadece göreceli tahminleme yapmak.
Olabildiğince farklı kişilerden tahmin alın
Story Point tahminleme aktivitesinin anahtar noktası takım içindeki herkesin (ama herkesin: analist, tester, developer, designer, deploy eden; kim var kim yoksa) bu aktiviteye dâhil edilmesi gerektiğidir. Bir ekip üyesi tarafından basit olarak nitelendirilen bir iş, başka bir roldeki takım üyesi tarafından hiç de kolay bulunmayabilir. Dolayısıyla yapılacak iş “TAMAM” olana kadar, süreç içerisinde dokunacağı kişilerin tahminini almak sağlıklı olacaktır. Böylece, yapılacak işin içerdiği riskler ve tıkanma yaşanabilecek darboğazlar daha sağlıklı görülebilecek ve ona göre tahminleme yapılacaktır. Bu noktada Story Point kullanmanın getirmiş olduğu kolaylığı da farketmişsinizdir. Aynı işin farklı kişilere göre ne kadar sürede yapılabileceği konusunda ekip içerisinde çıkacak anlaşmazlık da böylelikle minimize edilmiş olacaktır. Junior birinin 5 günde bitireceği bir işi Senior birisi 1 günde bitirebilir. Farklı konumlardaki kişilerin de tartışmaya dahil olduğunu düşündüğümüzde toplantı uzadıkça uzayacaktır. Bunun yerine yapılacak işin büyüklüğüne odaklanmak, ekip üyelerini konsensüs sağlayabilecekleri bir zemine çekmiş olacaktır.
Çıkarılan story point tahminlerinin %100 kesinlik içermesi gerekmediğini söylemiştik. Ancak verilen puanların tutarlı olması gerekir. Bu tutarlı puanlamaya göre takımın elde edeceği velocity zaman içerisinde tahminlemeden doğan hataları düzeltecek ve takımın sprint sonlarında teslim edeceği iş miktarı da olması gereken yere gelecektir. Zaman içinde elde edilen velocity verisi, takımın belli bir zaman diliminde ne kadarlık iş çıkarabileceği hakkında içgörüde bulunmamızı sağlayacaktır. Burada dikkat edilecek husus, takımın velocity’sini hesaplarken tam anlamıyla “TAMAM” olmamış user storyler’in hesaplamaya katılmaması gerektiğidir. Parçalı “TAMAM” diye de bir şey olmamalıdır.
Hataları Ne Yapalım?
Bu konuda oldukça fazla tartışma var. Kimileri hataları puanlamaya dahil etmek taraftarıyken, kimileri de hiçbir şekilde dahil etmemek eğiliminde. Sanırım bu konudaki iyi uygulama, legacy kodlardan kaynaklı, üzerinden hayli zaman geçmiş ve bir şekilde tespit edilmiş hataların puanlamaya tabi tutulması ve velocity’e dahil edilmesi olacaktır. Ancak yakın zamanda veya o sprint içerisinde ortaya çıkan hatalar da bir şekilde çözümlenmelidir. Tabii bu durum ancak ekip sprint içerisinde belli bir zamanı hataların çözümüne ayırmadığı durumlarda geçerli.
Sonuç olarak:
Story Point kavramı anlaşılması kolay, uygulaması biraz zor olabilen bir kavram. Bir iş için verilen zamana dayalı tahminler konusunda insanoğlunun zayıf kalması, bakış açımızı değiştirmeye götürmüş ve odağımızı yapılacak işin büyüklüğüne kaydırmamızı sağlamıştır. Bu da bir takımın belirli bir süre içerisinde (ki buna sprint diyoruz) ne kadarlık iş çıkarabilecek kapasitede olduğunu daha net bir biçimde verecek ve bir sprint içerisinde ne kadarlık user story alınabileceğini ortaya çıkaracaktır. Story point tahminleme aktivitesi sırasında aşağıdaki noktalara dikkat etmek bu işin doğru yapılmasını sağlayacaktır:
Olabildiğince farklı kişilerden tahmin alın.
Mümkün olduğunca göreceli tahminler kullanın.
Objektif ölçütler kullanın.
İyi uygulamalar takip edilir ise tahminleme aktivitesinde yolumuz Scrum Guide yazarlarından Jeff Sutherland’in de dediği noktaya çıkacaktır: “Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.”
Samet Şimşek
BA-Works
KAYNAKLAR:
(*) https://insights.stackoverflow.com/survey/2018#development-practices
(**) https://techbeacon.com/app-dev-testing/survey-agile-new-norm
(***) https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points