Neden "Kestirim" Yaparız?
Kestirim faaliyetlerini genellikle aşağıdaki sorulara yanıt bulmak için yaparız
- Belirli bir zaman diliminde ne kadar iş yapabiliriz? (Süre belirli, bu süredeki kapsam ne olabilir)
- Bir işi ne kadar zamanda yapabiliriz? (Kapsam belirli, bu kapsam ne kadar zamanda gerçekleştirilebilir)
- Yapılacak iş bize ne kadara mal olacak?
- Bir şeyi yapmak için ne kadar ve ne türden kaynaklara ihtiyacımız olacak?
Ya da "Kestirim" Yapmamalı mıyız?
Radikal gözüksede, kestirim veya tahminde bulunmamakta en azından bir şeçenek olarak masada durmaktadır:-).Burdaki temel varsayım :<< Bir proje bizim kestirim çalışmalarından bağımsız olarak ne zaman bitmesi gerekiyorsa o zaman biter.(veya ne kadar kaynak tüketecekse o kadarını tüketecektir) Aslında geçiken ya da gecikmiş bir proje yoktur.(ya da maliyetini aşmış). Sadece bizim kestirim veya tahminlerimiz yanlıştır.Zaten kestirimlerimin veya tahminlerimin %100 doğru olması söz konusu değil, o zaman kestirim veya tahmine ayıracağım zamanı neden bizzat yapacağım işe ayırmayayım.Müşterim ne istediği biliyor ve ilgilendiği tek şey işin bir an önce yapılması, o zaman neden zamanımı kestirim veya tahmin çalışmalarıyla israf edeyim,bir an önce işe koyulayım.>>
Şahsen benim favorim olan "kestirim yöntemi" bu :-). Bu tür yaklaşımı "saf olarak" (kestirim ,tahmin yok) kullanan metodoloji yok. Sadece son zamanlarda popüler olan KANBAN Çevik Yöntemi (pull-based software development,lean development) kestirim veya tahmin çalışmalarının göreceli olarak riski düşük olan unsurlar için "es geçilebilceğini" açıkça ifade etmektedir.
Detaylar için bakınız:
Kestirim İçin Kullanılan Yöntemlerden Bazıları
Algoritmik Yöntemler
Bu yöntemde kestirim için matematiksel modeller ( matematiksel formüller) kullanılır.Bu tür modellere geçmişe ait veriler, hesaplamalar-tahmin edilen kod satır sayısı fonksiyon sayısı vb-,istatistikler ve beraberinde programlama platformu, kullanılan yöntem,gibi bilinen ortam faktörleri girdi olarak verilir ve model belirli bir doğruluk aralığında sonuç üretir. Bu tür modellerin içinde bulunan ortama göre bazı parametrelerinin "kalibre" edilmesi gerekmektedir. Bu yöntemlerden bazıları
- COnstructive COst MOdel (COCOMO) ve COCOMO 2.0
- Putnam's Software Lifecycle Model (SLIM)
- Function point analysis
- Quantitative Influencing Factors (QIF)
Deneyime veya Uzman Görüşüne Dayalı Kestirimler
Uzmanın veya uzman grubunun deneyimine veya sezgilerine dayalı olarak işin ne kadar tutacağını dair verdikleri "subjektif" kararlara dayanır.Bunlardan bazıları:
- Delphi
- Wideband Delphi
- Planning Poker
Karşılaştırmaya veya Kıyasa Dayalı Kestirimler
Bu yöntemde “kıyaslamalı kestirimler” kullanılır: kıyaslamlı kestirimde iki unsuru karşılaştırıp birinin gerçekleştirilmesinin göreceli olarak diğerinin kaç katı olduğuna dair bir tahminde bulunursunuz. Örneğin
- Story Points
- Use Case Points
Parçalara Bölme
Yapılacak işe ait kestirim çalışmasını kolaylaştırmak için mevcut iş daha iyi ele alınabilecek ,tanımlanabilecek ve ölçülebilecek şekilde alt parçalara(işlere) bölünür.
Dinamik Yöntemler
Bu tür yöntemler projenin şartlarının -ki bunlar yapılan kestirimi doğrudan etkiler-proje boyunca düzenli olarak değiştiğini vurgular.Bu nedenle kestirim çalışmasının proje boyunca sürekli olarak yeni verilere göre yapılmasını ister.
Not: Burda amacımız yöntemleri "kesin sınırlarla" ayırmak değil.Bazı durumlarda yöntemler arasındaki sınırlar çok "muğlaktır".Yine çoğu zaman bu yöntemler tek başına değil diğer bir kaçı ile beraber kullanılır.
Çevik Süreçlerin Kestirim Çalışmasına Bakışı
Kestirimlerin Daha Güvenilir Olması Adına Harcanan Emek ve Elde Edilen Fayda Arasındaki İlişki
Belirli bir noktadan sonra sarf edilecek ek çabanın kestirimlerin daha kesin ve doğru çıkması üzerinde ciddi bir etkisi olmuyacak ve hatta bu noktadan sonra tam tersi bir etkide bulunabilecektir.Temel amacımız geleceğe ait "mükemmel" kestirimlerde bulunmak değil, minumun emekle işimize yarayacak "kesinlikte" kestirimler elde etmektir. Kestirimleri oluştururken harcanan emek ve elde edilecek kesinlik/doğruluk arasındaki çizgiyi doğru noktada çizmeniz önemlidir.
Belirsizlik Hunisi
Projenin ilk başlarında projeye ait birçok değişen çok net değildir.
- Gereksinimlere ait detaylar
- Çözüme ait detaylarlar
- Proje planı
- Proje Ekibi
- vb
Bunlardaki değişim projeye ait yapılan kestirimleride doğrudan etkiliyecektir.Bu nedenle projenin ilk başlarında yapılan kestirimlerde bu ölçüde kesinlikten ve doğruluktan uzak olacaktır.İlerleyen safhalarda(iteratif ve arttırımlı şekilde) elde edilen deneyim ve bilgi, detay ışığında bu kestirimlerimizin doğruluğu artacaktır: bu tabiki kendiliğinden olmuyacaktır:doğru geri besleme mekanizmaları kurmamız gerekmektedir.
Şekilden de görülebeileceği gibi, projenin ilk başlarında yapacağımız ilk tahminlerin sapma oranı 4 katı bulabilmeketedir.(iyimser yaklaşımla) Örneğin x işi için 4 aylık bir kestirim yaptınız bunun gerçek süresi 4*4ay =16 ay veya 4ay*0.25=1 ay olabilir.(en düşük ve en büyük kestirim arasındaki uçurum 16 kat )
Kestirimler için çok sayıda model- çoğu olması gerekenden daha karmaşık- geliştirilmesine rağmen kestirimlerdeki bu belirsizlik veya sapma hala yazılım dünyasında varlığını sürdürmektedir.Yüzde yüz doğru kestirim diye bir şey yoktur.
Bir Anı: Daha önceleri destek başvurusu için bir projemizi değerlendirmeye gelen işgüzar bir hoca, kendine methiye düzerken kendisinin bir projenin ilk başlarında projenin ne zaman biteceğini %99 olasılıkla doğru belirliyebildiğini söylemişti. Projenin başlangıcında onca bilinmez varken, bunun çok iddialı ve açıkçası gerçekçi olmadığını söylediğimizde bizlere "Ben sizden daha iyi bir mühendisim" gibi bir cevap almıştık.Ortalıkta dolaşan Mühendislik ile Müneccimliği karıştıran "ben kestiririm çünkü gerçek mühendis benim" diyen bu tür tiplere dikkat edin.Unutmayın yaptığımız / yapabileceğimiz mevcut bilgiler ışığında sadece bir "tahmin".
Not:Eğer kestirimlere dayalı olarak mali ve yasal yükümlülük gerektiren sözler vermeniz gerekiyorsa, bunu projenin "nispeten daha güvenilir kestirimler" yapabileceğiniz alanında vermelisiniz.Fakat piyasadaki müşteriler genellikle sabit maliyet ve sabit fiyat üzerinden iş yapma eğilimindeler. Bu durumda mali ve yasal zararlara uğramamak için projeyi iki safhaya ayırabilirsiniz.Birinci safha göreceli olarak kısadır,ve bu safhada sabit fiyat,zaman üzerinden bir anlaşma yapılır.Bu safhada,bir kaç iterasyonla sisteme ait kısmı olarak çalışan sürüm oluşturulur ve beraberinde evrimsel olarak gereksinim analizi çalışması yapılır.
Bu ilk fazda elde edilen geribesleme sonucu, müşteri ile sistemin geri kalanını gerçekleştirmek adına yeni bir sabit fiyatlı anlaşma yapılır. (Bu yöntemi RUP da önerilerir )
Çevik süreçler bu hunideki belirsizliği ortadan kaldırmamaktadır. Sadece akıllıca davranıp , gerçekleri kabul edip bu gerçekler ışığında yapmam gereken en akıllaca şey ne olabilir sorusunu sormaktadır.Cevap olarakta belirsizlik hunusini ters çevirmektedir:-)
Belirsizlik Hunisini Ters Çevirelim
Bu nedenle daha önce belirttiğimiz gibi çevik geliştirmede
- Planlar kısa vadede detaylandırılır -> o noktadaki ufkumuzda: Çevik Metodlar açısından “gelecek ufkundaki” görülebilir alan bir sonraki iterasyondur
- Uzun vadede daha genel ve esnek tutulur -> ufkumuzun dışındaki belirsiz alanda
Bunun Türkçesi,
- Eğer bana önümüzdeki 1 ila 6 hafta arasında ne yapabileceğimi ne teslim edebileceğimi sorarsan,sana vereceğim cevabın kesinliği doğruluğu yüksek olacaktır.
- Eğer bana önümüzdeki 3 ay içinde ne yapabileceğimi ne teslim edebileceğimi sorarsan tahminlerimdeki belirsizlik artar ama belki “makul bir tahmin” –sapmalar olmasına rağmen sapma miktarları kabul edilebilir- verebilirim
- Eğer bana önümüzdeki 6 ay içinde ne yapabileceğimi ne teslim edebileceğimi sorarsan, kusura bakma hiçbir fikrim yok ama mutlaka bir tahmin istersen işkembeden atabilirim :-)
O Zaman Belirsizliği Daha Baştan Detaylı Analiz Çalışmaları İle Neden Ortadan Kaldırmıyoruz?
Klasik şelale modelinde projenin başlangıcında tüm gereksinimler veya çok büyük bir bölümü detaylı “analiz” faaliyetleri ile belirlenmeye çalışılır ve kayıt altına alınır.Daha sonra kağıt üzerinde yapılan bir tasarım çalışmasından sonra, kodlama /gerçekleme faaaliyetlerine geçilir.Analiz ve tasarım faaliyetlerinin ardından ,burda harcanan emeğin, daha sonraki kodlama aşamasında kendini sisteme ait özelliklerin kodlanmasını hızlandırarak telafi edeceği /gösterceği varsayılır.
Çevik yöntemler bu tür detayli gereksinimlerin ve proje planlarının işin başında olusturulabilecegi iddiasinin yazilim gelistirme işinin dogasına aykiri oldugunu iddia ederler.Çevik süreçlerde ,gereksinimler iteratif ve arttırımlı olarak evrimsel bir şekilde ilk başlardan itibaren yapılan erken programlama ve test çalışmaları ile keşfedilir, detaylandırılır, doğrulanır, özellikler halinde gerçeklenir. Projenin ilk anından itibaren test edilmiş, ihtiyaçlarıkarşılayan özellikler müşteri önceliklerine göre geliştirilmeye başlanır.Ayrıca her iterasyonla, müşterinin bizi gerçek ihtiyaçlarına yönlendirmesine izin veririz.Bu yöntem eksiksiz olarak gereksinimleri bulduğumuz yanılgısını ve inzivaya cekilerek anladığımız zannettiğimiz (ve gercekte var olmayabilecek) problem ve çözümüne yonelik calısmalara dalmamızı engeller.
Göreceli veya Kıyaslamalı Kestirim -> Yapılacak İşin Göreceli Büyüklüğü ile Ne Kadar Zaman Tutacağının Birbirinden Ayrılması
Günlük hayattan bir benzetme yaparsak örneğin bir evi boyamanız gerekiyor.Size verilen sadece en başta bu eve ait genel bir kroki.Örneğin evin odalarının duvarlarının ne durumda olduğunu henüz bilmiyoruz, odaların net ebatları hakkında bilgimiz yok.Bu verilen bilgiler ışığında sizden işin ne zaman biteceğine dair bir kestirim oluşturmanız isteniyor.( veya sizden odaları boyamak için ne kadar boya gideceğini ,maliyeti ).
Elimizdeki krokiye bakarak evin şu odasını şu kadar zamanda boyarım demek yerine önce tamamen birimsiz bir şekilde bu odaların boyanmasına ait göreceli ,kıyasa dayalı kestirimler yapıp daha sonra bu kestirimleri gerçek zamana çevirebilirsiniz.
Krokiden hareketle Banyo/WC ’yi boyamak 1 birimlik çabamı alırsa Mutfağı boyamak aşağı yukarı 3 birimlik çabamı alır diyebiliriz.
Eğer boyamaya mutfaktan başlarsak burayı 6 saatte boyarsak, sonrasında kabaca 1 numaralı yatak odasını da 6 saatte,2 numaralı yatak odasını da 10 saatte boyacağımızı söylüyebiliriz.( Hızımız 2 saatte bir Puan) Yine Kabaca mutfağın boyanmasından sonra elde ettiğimiz bilgi ışığında boyama işleminin toplamı
21 puan olduğuna göre mutfağı boyadıktan sonra eldeki verilere göre tüm evin boyama işleminin 21*2 =42 saat süreceğini söyleyebiliriz (mevcut bilgimiz ışığında).
Örneğin mutfağı boyadıktan sonra yanımıza yeni bir eleman aldık. Bu elemanla birlikte 1 numaralı yatak odasını 4 saatte boyadık.(en son hızımız 4 saatte 3 puan) Bu durumda mevcut bilgimiz ışığında kalan 21-(2*3) = 15 puanlık bir işimiz kalmıştır. En son hızımızı dikkate alırsak (4 saatte 3 puan) kalan 15 puanlık işin kabaca 15*(4/3) = 20 saatte biteceğini söylüyebiliriz.
Dikkat ederseniz burada yapılacak işin birbirine olan göreceli büyüklüklerini bulduktan sonra (mutfağı boyamak banyoyu boyamanın 3 katı gibi), mevcut hızımıza göre işin ne kadar zamanda yapılacağını çıkarsamasını yaptık. Yeni bir eleman alıp, işimizi daha hızlandırdığımızda yapmamız gereken tek şey yeni hızımızı belirleyip, bu yeni hıza göre işin ne kadar süreceninin çıkarımını tekrar basitçe yapmak oldu.
Göreceli Kestirim ve Story Points
Çevik metodlarda takım planlama için ana birim olarak ürüne ait özelliklere odaklanır.Bizim genel olarak "özellik" (feature) dediğimiz kavram farklı metodolojilerde farklı isimler alabilmekte ve özelliklerin ifade edilmesi için farklı teknikler kullanılabilmektedir.
Genel proje planlamasında örneğin sürüm planlamasında) İlgili özelliklerin her birisisinin gerçeklenme süresi kestirimi için belirli bir zaman dilimi vermek yerine( saat ve gün birimlerinde) , bu seviyedeki kestiriminlerde “kıyaslamalı kestirimler” kullanılır: kıyaslamlı kestirimde iki özelliği karşılaştırıp birinin karmaşıklığının göreceli olarak diğerinin kaç katı olduğuna dair bir tahminde bulunursunuz.Ama burdaki kestirimlerin bir birimi yoktur (cinsi NUT : Nebulous Unit of Time :-)).
Bu göreceli zaman kestirimlerinden biri Kullanıcı Hikayeleri için kullanılan Story Points’dir. Story Points bir kullanıcı hikayesinin büyüklüğü belirtmek amacıyla kullanılan ölçüm birimleridir.Bu yöntemde kullacı hikayelerine birer puan değeri (point value) atanır. Bu değerin tek başına hiç bir önemi yoktur. Burda önemli olan hikaye puanlarının birbirine olan bağıl değerleridir.Örneğin bir hikayeye 2 değeri atanmışşa bu , ilgili hikayenin 1 hikaye puanı verilmiş başka bir hikayenin
yaklaşık iki katı büyüklüğünde olduğunu düşündüğünüz gösterir.Puanlar bir zaman aralığını göstermezler. Sadece hikayelerin birbirine olan bağıl büyüklüklerini göstermek amacıyla kullanılır. Bazı takımlar olaya biraz eğlence,biraz daha yaratıcılık katmak adına-Olmaması için hiç bir sebep yok :-)- bu tür "göreceli kestirimler" ’i puanlara göre değil örneğin T-Shirt büyüklüğüne (small,medium,large,extra-large GİBİ)göre de vermektedir.
Bu kıyası çok daha farklı unsurlara görede yapabilirsiniz :-)
Genel Proje Planlaması Seviyesinde >> Göreceli Kestirim
Takım bir iterasyondan diğerine kaç tane çalışan, test edilmiş ürün özelliğini gerçeklediğini takip eder.
Örneğin yukarıdaki verilere bakarak
- Uzun vadeli ortalama hız: son 8 iterasyonda bitirilen story points ortalaması= 33 story point
- En kötü hız ortalaması: son sekiz iterasyon arasında seçilen en yavaş 3 iterasyona ait ortalama = 30 story point
- En iyi hız ortalaması : son sekiz iterasyon arasında seçilen en hızlı 3 iterasyona ait ortalama = 36 story point
diyebiliriz.
Buna dayalı olarak ( örneğin iterasyon sürelerimiz sabit ve sürüm tarihine kadar 6 iterasyonunuz var)
- Ortalama Hızda, önümüzdeki 6 iterasyonda 6 x 33 = 198 ek kullanıcı hikaye puanı bitirebilir.
- Ortalama En düşük Hızda, önümüzdeki 6 iterasyonda 6 x 30 = 180 ek kullanıcı hikaye puanı bitirebilir
- Ortalama En İyi Hızda, önümüzdeki 6 iterasyonda 6 x 36 = 216 ek kullanıcı hikaye puanı bitirebilir
- Mevcut Hızda, önümüzdeki 6 iterasyonda 6 x 35 = 210 ek kullanıcı hikaye puanı bitirebilir
diyebiliriz.
Eğer iterasyonlarımızda istikrarlı bir hız tutturabilirsek sürüm planımıza ait bitim tarihlerinin gerçekçi olup olmadığını, ilgili sürüm tarihinde elimizde hangi özelliklerin kodlanmış olcağına dair bir kestirimde bulunabiliriz. Buna dayalı olarak gerekiyorsa sürüm planımızı güncelleriz.(önceki kestirimlerimizi güncellemek gibi) Ya da ilgili sürüm tarihlerimizde bir değişiklik olmamasına karşın, sonraki iterasyonda gerçeklemek istediğimiz özellikler farklılaşabilir [ hedef aynı kalmakla beraber ona ulaşma yolumuz değişti].Temelde sorduğumuz esas soru: elimdeki taze veri ışığında, ilgili amaçlara/hedeflere ulaşmak için atmam gereken bir sonraki en akıllı adım ne olabilir?( knowledge-before-the-fact with knowledge-after-the-fact.)
Not: Hız ( Velocity): Takımın İterasyon başına başarılı bir şekilde gerçeklediği / teslim edilen “özellik” (user stories, requirements, backlog items, etc.) sayısı.Bu kadar basit bir ölçüm! Eğer Kullanıcı Hikayeleri kullanıyorsak ölçtüğümüz sayı birimi Story Points cinsindendir.
Göreceli Kestirimlerde Puanlama Skalası
Temel Varsayımlar:
- İnsanlar -göreceli olarak puanlama yaparken-, iki komşu değer arasındaki puanlama skalası farkı büyüdükçe ilgili puanın seçmesini daha kolay yapmaktadırlar.
- Kıyaslama yapacağımız unsurun ebatı büyüdükçe, kıyaslamamızın doğruluk oranı azalacaktır.
- İnsanlar ,ölçeginizin skalasında tek bir dercelendirme büyüklüğü olduğunda daha iyi kıyaslama yaparlar.
Örneğin puanlamada diyelimki: 1,2,3,4,5,6,7,8,9,10 şeklinde yaptınız diyelim.6 ile 7 puanları arasındaki büyüklük farkı 6x = 7 => x = 7/6 = 1.166 yani 7 ile 6 skalasından farkı 0.166 gibi küçük bir değer.Bir hikayeyi 6 veya 7 puan verdiğimizde ilgili hikayler arasındaki bu kadar küçük ölçek farkını görebiliyor olmanız gerekirki çoğu durumda bu mümkün değildir.Bu nedenle puanlama sakalanız paunlar arasındaki ölçek büyük olacak şekilde yapnız.
Örneğin :
- 1,2,4,8,... .
- 1, 2, 3, 5, 8… (Fibonacci serisinden oluşturulan)
puan skaları bunun için uygundur.
Ölçeginizin skalasının tek bir büyüklük derecelendirme ralaığında tutun. Örneğin 1 rakamı yerine 10, 2 rakamı yerine 20...kullanabilirsiniz fakat böyle bir ölçeklendirmede 11,12 gibi ara derecelendirme puanlamaları yapmayın.Çünkü bunlar arasındaki fark çok az olup, bu kadar küçük farkları doğru bir şekilde kıyaslayamayız.( elimizde böyle ciddi bir veri yok, gerçekten böyle hassas bir kıyaslama yapabilir miyiz)
Iterasyon Seviyesindeki Kestirim
Deaylı planlamada - yani İterasyon seviyesinde planlama yaparken - ise belirsiz bir zaman dilimini (cinsi NUT : Nebulous Unit of Time :-)kullanmanın bize yararı yoktur .Bu seviye ilgili stratejik özelliğin taktik seviyede gerçeklenmesi için yapılması gereken faaliyetleri ve bunların ne kadar zaman alacağını örneğin ideal çalışma saatleri veya günleri cinsinden belirleriz.
Not:Ideal Zaman ( Gün veya Saat Cinsinden Olabilir): Çok kabaca ideal zaman geliştiricinin başka bir işle uğraşmadan sırf ilgili iş için harcadığı toplam zamanı gösterir.Bu zaman geliştiricinin ilgili işe odaklandığı, ilgili faaliyetleri herhangi bir dış unsur tarafından sekteye uğramadan gerçekleştirdiği bir zamandır. Mekanik anlamından öte , temelde geliştiricinin ilgili iş için verimli ve üretken olduğu zaman dilimini göterir.
Bazı takımlar ,iterasyonun süresi için önceden belirlenmiş ve tüm proje boyunca değişmeyen zaman aralıkları kullanmaktadır.( örneğin 2 hafta). Bu durumda önceden belirlenmiş iterasyon zaman aralığını nasıl önceliklendirilmiş ürün özelliklerini gerçekleyecek şekilde doldururum sorusunu sorarız. İterasyon süresi önceden belirli ise
- Takım üyelerinin bir sonraki iterasyon zaman aralığında sahip oldukları "ideal çalışma saatleri",kayıp günleri de hesaba katarak belirlenir.
- Müşterinin taleplerinden, istediği özelliklerden en yüksek seviyede önecelikli olanlar alınır :sürüm planından en yüksek önceliğe sahip özellikler ilgili iterasyon için seçilir
- Bu özellikler yapılacak görevler/faaliyetler (tasks) haline dönüştürülür:bu görevlerin gerçekleştirilme süresi programcılar tarafından tahmin edilir. (ideal saat veya gün cinsinden.Çoğu görevler (tasks) bir gün içinde teslim edilebilecek /gerçeklenebilcek büyüklüktedir[ 4 saaten 2 güne kadar değişebilir].İki günden daha fazla sürecek görevler(tasks) daha küçük görevlere(tasks) bölünür.
- Yukardaki işlemi ilgili iterasyondaki tüm kaynakları doldurulana kadar("ideal çalışma saatleri") tekrarlanır
- Eğer ilgili özellikler bir iterasyon süresinde tamalanamayacak büyüklükte ise, daha alt parçalara ilgili iterasyonda gerçeklenebilecek büyüklükte olana kadar bölünür
Ya da kapsama dayalı olarak itersyonlarınız süresini belirlemek istiyorsanız ( bu durumda farklı iterasyon süreleriniz olacak - bazı çevikçiler bunun yapılmaması gerektiği söylüyor)
- Takım üyelerinin günlük sahip olduğu ideal çalışma zamanını, kayıp günleri hesaba katarak hesaplanır.Örneğin bir geliştiricinin günlük "ideal çalışma" zamanı günlük 4 saat ise, ve bu durumda toplam 25 kullanıcınız varsa bu günlük 100 ideal saat eder.
- İterasyon için belirlenen aday "özellikleri" alınır.
- Eğer bunlara ait bir kestirim yapılmamışşa veya yeniden yapılması gerekiyorsa kestirimleri yapılır.
- Bu özellikler yapılacak görevler/faaliyetler (tasks) haline dönüştürülür.
- Bu görevlerin gerçekleştirilme süresi programcılar tarafından tahmin edilir. (ideal saat veya gün cinsinden)
- Bu faaliyetleri yapmak için gereken zamanı takımınızın sahip olduğu toplam günlük ideal çalışma saatine bölün.
- Çıkan sonucu en yakın haftaya( 5 günlük çalışma gününe) tamamlayın.Örneğin ilgili işler için 800 ideal saat gerekiyor sizin takımınızın günlük ideal çalışma zamanı 100 ideal saat günlük 800/100 = 8 gün ( 5 + 3 çalışma günü) bunu en yakın haftaya tamamlarsa ( 3 çalışma günü 5 çalışma gününe tamalandı) iki haftalık bir iterasyon süresine ulaşırız.
- Eğer bu zaman aralığı arzulanan iterasyon zamanını aşıyorsa, hedefleri / kapsamı küçültün: Küçük takımlar için iterasyon zamanının 3 haftayı geçmemesine Büyük takımlar için iterasyon zamanının 6 haftayı geçmemesine özen gösterin.
Planlama Pokeri
Kestirim Çalışmalarını Takım Halinde yapılmasına olanak veren,ve bunu eğlenceli hale getiren tekniklerden biriside Planlama Pokeri Oyunudur. Fırsat olursa bir sonraki yazımda Planlama Pokeri oyununundan /tekniğinden bahsedeceğim.
Hamiş: İlginizi Çekebilecek Kaynaklar