DigiPoint

Agile metodolojisinde akıllarda soru işareti bırakan en yaygın sorulardan biri tahmin edebileceğiniz gibi ‘tahminleme’dir :)

Tahminleme yapmak istememizin sebebi bir sprintte yaklaşık ne kadarlık iş alacağımızı belirlemek ve buna bağlı releaselerimizi yönetmek denilebilir. Buna ek olarak tahminleme ritüelleri işe ışık tutar, işin nasıl daha hızlı ve kaliteli yapılacağına dair tartışma ortamı yaratarak risk ve tıkanmaları aydınlatır. Sprintlerimizde efora bağlı değil sprint hedefine göre çıktı vermek asıl amacımız olsa da, amaca giden yolda bu tahminlemenin önemi de büyüktür.

Scrum Guide işin büyüklüğünü tahminleme konusunda özel bir kullanım önermemekle birlikte “Relative Estimation” tarzını seçen takımlar story point tahminlemesini yaygın olarak kullanırlar. Çoğunlukla birim işin büyüklüğünün ya da belirlenmiş use caselerin Story Point ile tanımlanmasından sonra anlam ifade eden bu teknikte; uyuşmamazlık, yapılan anlaşmalarda tanım farklılığı nedenleri ile uygunsuzluk(outsourced projeler gibi), karmaşık organizasyonlarda ekipler arası tutarsızlık gibi sorunlar yaşanabilmektedir.

Story pointe alternatif ISO ile taçlandırılmış CFP(Cosmic Function Point) kullanmak da mümkündür. CFP’nin mobil uygulama geliştirme çevik akışında oluşturduğu negatif yönleri ise; mobil uygulama geliştirme döngüsü için çizgilerinin belli olmaması, önden kurallar bütününün tanımlanması gerekliliği ve özellikle scrumda tavsiye edilmeyen detaylı analiz ve inceleme gerektiren hesaplanmasının aldığı vakit diyebilirim.

Burada ise SP ve CFP’ye nazaran, daha analitik bir tahminleme ve ölçümleme yöntemi olabilir mi sorusuna bulduğumuz yanıtı değerlendireceğiz :)

Bulduğumuz yanıta DigiPoint adını verdik ve özetle belirtmek gerekirse, yaklaşık eforlar ile paralellik gösteren, karmaşıklık ve risk faktörlerini de sayısal anlamda barındıran, işin büyüklüğünü belirten yeni sizing yöntemi diye tanımlayabiliriz.

Bu yöntem için farklı ekiplerin development takımları ile bir araya gelerek çeşitli büyüklüklerdeki işlerimizi belirlediğimiz parametreler üzerinden değerlendirme ile başladık. Parametreleri de aslında use caselerimize dayanarak oluşturmuş olduk.

Use caselerimizi en küçükten başlayarak ve deneyimlenmişlerden seçerek ilerledik.

Bu use caselerimizi farklı mobil uygulama geliştiren ekiplerin developerları ile değerlendirdik, hem parametrelere değer vermelerini ve story point değeri olarak ne vereceklerini hem de tahminen eforlarının ne kadar olacağı bilgisini aldık.

Değerlendirme parametrelerimiz, SP değerlemesi yaparken düşünmemiz gereken parametrelerden pek farklı değil, buna ek olarak projemize uygun eklediğimiz parametrelerimiz de oldu. Bunları ise mobil uygulama geliştirmede backend ve client developerlarca önemli, işin büyüklüğünü, eforunu etkileyecek parametreler neler sorusunu düşünerek gerçekleştirdik.

Sonuçta elde ettiğimiz değerlendirme parametrelerimiz ve açıklamaları şöyle:

Değerlendirmeler sırasında tıpkı SP verme ritüellerinde olduğu gibi işin masaya yatırılarak irdelenmesine özen gösterdik. Çünkü aslında bu ritüeller hem işlerimizi kolaylaştırdığımız, anlamlandırdığımız, sahiplendiğimiz hem de pandemi sürecinde iletişimi güçlendirdiğimiz önemli zamanlardır diye düşünüyorum.

Elimizde örnek use caseler için parametrelere verilen değerlere göre değişen varsayımsal eforlar, SPler oluşmuş oldu. Yani birçok bilinmeyenli denklem :)

Bu denklem üzerinde yeniden dev team ile parametrelerin ağırlık oranları değerlendirdiğimiz bir session gerçekleştirdik.

Aynı ürünler üzerinde çalışan farklı dev teamlerden alınan ve gerçekleşmiş use caseler üzerinden değerlendirilerek ilerlenen bu araştırmada DigiPoint formülümüzü hem backend hem client için elde etmiş olduk.

Backend DigiPoint = [(0,5 * Tahmini servis entegrasyon sayısı)+(0,25 * Tahmini servis modifikasyon sayısı)] * [(Karmaşıklık * 2) + (Risk&Belirsizlik * 2)]

Client DigiPoint = (Yeni Ekran Sayısı * ortalama ekran karmaşıklığı * 0,9) + [(yeni component sayısı +(değişiklik yapılacak component sayısı * 0,3)) x ortalama component karmaşıklığı] + [(servis modifikasyonu sayısı * 0,25 + yeni servis sayısı *0,5)*( temel mimariye müdahale karmaşıklığı *2)]

Formülümüz sonucu uygulamaya başlamadan önce pilot olarak iki sprint boyunca bu yöntemi kullanmaya ve izlemeye başladık.

İzleme sonuçlarına göre tıpkı SPte olduğu gibi bir iterasyonda ortalama kaç digipoint üretilebildiği, digipointi belli bir seviyenin üzerinde çıkan işlerin yeterince bölünmemiş olduğuna kanaat getirilmesi gibi kerteriz alınacak bilgiler elde edileceğini düşünüyorum.

İzleme sonuçlarına göre tıpkı SPte olduğu gibi bir iterasyonda ortalama kaç digipoint üretilebildiği, digipointi belli bir seviyenin üzerinde çıkan işlerin yeterince bölünmemiş olduğuna kanaat getirilmesi gibi kerteriz alınacak bilgiler elde edileceğini düşünüyorum.

‘Neden SP değil de bu yöntem, hemen hemen aynı’ düşüncesini ise şöyle bertaraf edebiliriz:

• Story point yalnızca risk, karmaşa ve çıktıya bakıyorken, digipoint değerlendirmesinde geliştirmede efora etki eden değerler de göz önünde bulundurulur. Bu da aslında digipointin mobil uygulama geliştirmenin CFPsi gibi konumlanabileceğini göstermektedir.
• Story point verirken genellikle tahmini efor ile ilişkilendirilmesi yapılan yaygın hatalardan biridir. Bu yöntemle aslında “Relative Estimation”ın faydası olan hızı kaybetmiş oluruz, çalışılan saate göre sp azaltılması gibi süreçler daha çok belirsizliklere sebep olabilir. Digipoint formülümüze ulaşırken parametrelere ek tahmini efor bilgisini de eşitlikte değerlendirdiğimiz için bu sorun da elimine edilmiş olur.
• Story point verirken yaşanan anlaşmazlıklarda ‘ortada buluşalım’cılıktan digipoint sayesinde kaçınmış oluruz; digipoint parametreleri değerlendirilirken verilen puanlamalar bu konularda dev teamin tartışıp irdelemesine olanak sağlar.
• Story point verirken ortamda bir expert varsa onun puan vermesini beklemek de itiraf edelim ki herkesin konfor alanı denilebilir J Digipointin hedefi bunu da kırarak ilgili konunun karmaşası, riski konuşulurken expertten bu oranları nasıl düşürülebileceği bilgisini almaya imkan vermektir.
• Digipoint ile aynı ürünü geliştiren farklı takımlar arası konuşulan dilin ortaklaşması sağlanmış olur.
• Dış kaynak desteği alan projelerde taraflarca tanımı değişen bir SP modeline göre değil, efor, risk, karmaşa, geliştirilecek servis sayısı gibi analitik zemine oturan bir yöntem ile ilerlenerek uyumsuzluk engellenmiş olur.