Agile Tahminleme Teknikleri - 1

10 Eylül 2017 7531 0 AGILE GELİŞTİRME Hakan Aksungar

Bu BLOG yazısında Çevik Geliştirme Yaklaşımlarında kullanılan Tahminleme Tekniklerden bahsedeceğim. Yazımda Göreceli Boyutlandırma, Story Point ve Planlama Pokeri üzerinde duracağım.  

Ama gelin önce geleneksel yöntemlerde tahminleme nasıl yapılıyor ondan başlayalım;

Geleneksel Tahminleme

Proje, proje kapsamını oluşturan ürün ya da hizmete yönelik fikirlerin zaman-maliyet-kapsam ve kalite planlarının sponsor ya da müşteri tarafından onaylanarak, sözleşmenin imzalanması ile başlar. Gereksinimlerin toplanması ve bu gereksinimleri karşılayacak ürün ya da hizmetlere ilişkin teslimatın  ne kadar süreceği tahmin edilir. Fonksiyonel özellikler çıkartıldıktan sonra, geliştirme ekibi tarafından teknik tasarım ve mimari plan geliştirme tahminleri yapılır. Planlama çalışmaları tamamlandığında, temel planı baz alan tahminleme yapılır.  Takım ayrıca kapasitelerini kaynak türüne göre de tahmin eder, kapasite ve bilinen bağımlılıklar ile proje planına işlenir. Bu noktada, proje takımının kendini güvende hissedeceği bir zaman çizelgesi çıkartılır ve paydaşlar ile paylaşılır.    

Geleneksel yaklaşımlarda bu tahmin sürecinin tamamlanması projenin büyüklüğüne göre birkaç hafta ile birkaç ay sürebilir.

Bir proje zamanaşımı içeriyorsa Proje takımı, işlevsel özellikler, tasarımlar ve tahminler oluşturduğu tüm özellikleri sunmak için yeterli zaman olmadığını görebilir. Takım, daha sonra, takip edilmeyecek özelliklerin tahmin edilmesinde değerli zaman harcadıklarını fark ederek, proje için zaman çizelgesini karşılayacak kalite ve benzeri özelliklerinden taviz vermek zorunda kalabilir. 

Agile Tahminleme Teknikleri

Agile tahmin teknikleri, geleneksel geliştirme yöntemlerindeki tahminleme eksikliklerini giderir.

Sıralama seviyesi ortaya çıkıncaya ve özelliklerin gerekli olduğundan emin olmadan tüm işlevleri tasarlayamaz ve tahmin etmezsiniz. Proje ilerledikçe daha kesin olabileceğinizi ve özelliklerle ilgili daha fazla bilgi edinmenizi kabul eder, aşamalı bir tahmin yaklaşımını kullanarak sonucu tahminlersiniz. Çevik tahminler,

• Basit
• Göreceli büyüklük içerir.

Çevik Tahminler normal olarak adamsüre olarak değerlendirilmez; Soyut-göreceli ölçümler kullanılır.

Tahminler bir işin kesin büyüklüğünü (saat, adam gün vb.) tahminlemek yerine, göreceli büyüklük  tahminleri yapılır.

Relative Sizing ve Story Point Tahminleme Teknikleri

Göreceli tahmin görevleri veya kullanıcı hikayelerini ayrı ayrı ve zamanın mutlak birimi değil, karşılaştırma veya eşdeğer zorluk derecelerine göre görevlerin gruplandırarak tahmin edilmesidir. 

Geleneksel yazılım ekipleri, gün biçimi, hafta, ay gibi belirli bir zaman formatında tahminler sunar, ancak Çevik Takımlar,  Story Point, 0, ½,  1, 2, 3, 5, 8, 13, 20, 40, 100 gibi Fibonacci sayısal dizileri ile işin göreli çabasını ölçer: Sezgisel görünebilir, ancak bu soyutlama aslında yararlıdır çünkü TAkım çalışmanın zorluğu etrafında Takımı karar vermeye zorlar. Story Point puanlarını kullanmanın birkaç nedeni:

• Tahminler, halen devam eden projelerle ilgisi olmayan çalışmaları hesaba dahil etmez.   
• Tarihlere duygusal bağlanmayı ortadan kaldırır.
• Her takım biraz farklı bir ölçekte çalışacağını tahmin ederek, hızlarının (puanlar ölçülür) doğal olarak farklı olacağı anlamına gelir. 

Takım, ürün birikimi (Product Backlog) bir görev alıp, kısaca tartışılarak her üye zihinsel olarak bir tahmin oluşturur. Sonra herkes, tahminlerini yansıtan bir sayıya sahip bir kart tutar. Herkes mutabık kalırsa mükemmel, değilse, farklı tahminlerin arkasındaki mantığı anlamak için biraz zaman ayırılır (çok fazla zaman ayırılmaz, sadece birkaç dakika sürebilir). Hiçbir görev 16 saatten fazla çalışmaz. Story Point üst sınırı 20 puan olduğunu söyleyebilirsiniz. Takımınızın 16 saatlik (veya 20 puanlık) eşiğinin üzerinde bir şey olduğu zaman, bu daha ayrıntılı parçalara ayırmak gerektiğini gösterir. 

Birikim içinde daha derin görevler için kaba bir tahminde bulunulur. Takım üyeleri bu görevler üzerinde gerçekten çalışmaya başlayınca gereksinimler değişebilir ve uygulamanız kesinlikle değişmiş olur. Dolayısıyla önceki tahminler doğru olmayacaktır. Kayma olasılığı bulunan işi tahmin etmek zaman kaybedilmez.

Planlama Pokeri® Tahminleme Tekniği

Çevik Geliştirme Yaklaşımlarının kullanıldığı birçok şirkette, tahminleme için Planlama Poker Tekniği kullanılır.  

Ben de eğitimlerimde Planlama Pokerini öğretiyorum. 

Planlama Pokeri, kullanıcı hikayelerinin göreli boyutlarını oluşturmak için gereken çabayı tahmin etmek için fikir birliğine varmak amacıyla kullanan bir tahmin tekniğidir.

Her takım üyesinin elinde sayılarından oluşan bir kart destesi vardır. Her kart Fibonacci sayıları ile (?, 0, ½,  1, 2, 3, 5, 8, 13, 20, 40, 100, 500, vb.) numaralandırılmıştır.

Takım üyeleri tarafından tahmin edilen, kullanıcı hikayesinin zaman ve çaba açısından karmaşıklığını temsil eder. Takım üyeleri her Kullanıcı Hikayesi’ni geliştirme aşamasındaki tahminlerini vermeden önce daha iyi anlamalarını sağlamak için değerlendirme yapmalarına yardımcı olur.

• Her üye, her kullanıcı hikayesi için tahminlerini temsil eden bir kart seçer.
• Çoğunluk veya tüm takım üyeleri aynı kartı seçerse, o kartın gösterdiği tahmin üzerinde ortak görüş birliği varsa tahmin edilen göreceli büyüklük olarak belirlenir.  Herhangi bir görüş birliği yoksa, takım üyeleri farklı kartların veya tahminlerin seçim nedenlerini tartışır. Bu tartışmadan sonra tekrar kartları seçerler.
• Bu sıralama, tüm varsayımlar anlaşılana kadar, yanlış anlaşılmalar giderilinceye kadar devam eder ve fikir birliğine / anlaşmaya varılır.
• Planlama Poker, takım üyeleri arasında daha fazla etkileşim ve daha gelişmiş iletişimi sağlar.
• Takım üyeleri öncelikle birbirlerinden etkilenmeden, birbirlerinden bağımsız düşünür, sonra takım olarak birbirleriyle etkileşim kurmaya başlayarak, ortak görüş oluşturulur.    

Fibonacci sayısal dizilimini kullanmanın nedeni, daha büyük öğeleri tahmin etmede belirsizlikleri aşmaktır. Yüksek bir tahmin genellikle görevin ayrıntılı olarak anlaşılamadığı ya da birden çok küçük kullanıcı hikayesine bölünmesi anlamına gelir.  

Agile Yazılım Geliştirme ve Agile Dönüşüm hakkında daha fazla bilgi edinmek için bizi takip edin!