Günlerden birgün….

Yineleme iş akışı performansının değerlendirilmesi Haziran 18, 2007

Kategori: Agile — cenkcivici @ 1:31 am

Her yineleme sonunda kendimizi değerlendirdiğimiz ‘retrospective’ adı verilen bir gözden geçirme toplantısı yapıyoruz. Bu toplantının amacı neyi iyi yaptık, neleri daha iyi yapabiliriz tespit etmek. Bu konuyla ilgili daha önce ‘Geçmişe bakış’ adlı bir yazı yazmıştım.

Bu toplantılarda yineleme yöneticisi(iteration manager) tarafından hazırlanan bazı grafikler kullanıyoruz. Bir grafik bin kelimeye bedel. Bu grafiklerden birisi kartların yineleme içindeki süre boyunca hangi aşamalarda ne kadar zaman geçirdiklerini toplu gösteriyor. Yineleme yöneticisi bu grafiği hazırlamak için hergün kaç kartın hangi adımda olduğunu not ediyor. Kartlar yineleme içinde Geliştirme, Analist onayı, QA, testi, Bitti gibi aşamalardan geçiyor. Bu aşamalar içinde hangilerin dar boğaz oluşturduğu hazırlanan grafik sayesinde görülebiliyor. Örneğin geliştirme hızlı iken testçiler bu hıza yetişemiyorsa , grafikte test aşaması ile ilgili kart sayısı sürekli artıyor.

Bu grafiği temel alarak beklemelerin ve darboğazların nedenini sorguluyoruz. Verdiğim örnekten gidersek ; testçi sayısı yeterli değil mi ? Müşteriye erişemiyor muyuz? Geliştiricileri Testçilerle eşleştirerek darboğazı aşabilir miyiz? gibi soruları sorarak süreçte bazı değişiklikler yapmamız sözkonusu olabiliyor.

 

Projeye yeni katılan birinin alışma süreci Haziran 17, 2007

Kategori: Agile — cenkcivici @ 8:49 pm

Diyelim ki uzunca süredir devam eden bir projeniz var ve bu ekibe yeni katılanlar oldu. Yeni katılan arkadaşların projede yararlı olmaya başlamaları için belli bir alışma sürecinden geçmeleri gerekiyor. Bu süreç içinde iş kurallarını, alan bilgisini, kullanılan araçları ve teknolojiyi öğrenmeleri gerekiyor. Proje büyüdükçe ve o ana kadar bitirilen yazılım fonksiyonları fazlaysa bu alışma süreci uzayabiliyor.

Şu an çalıştığım proje yaklaşık bir yıldır devam eden ve 80 e yakın kişinin çalıştığı bir proje. Ekibe yeni katılan olduğu zaman bu kişinin adaptasyonunu kolaylaştırmak için kullandığımız bazı yöntemler şöyle..

  1. Yeni katılan ister geliştirici ister analist ister testçi olsun; ekibe katılımından sonraki 1-2 haftalık süre boyunca test ekibinde çalışıyor. Test ekibi bünyesinde uygulamayı son kullanıcı gözünden kullanarak, uygulamanın ne olduğunu, ne amaçla yazıldığını, nasıl kullanıldığını öğreniyor. Buna ek olarak hataları bularak projeye ilk günden yarar sağlamaya başlıyor. Hataları bulmaya çalışırken iş kuralları hakkında derinlemesi bilgi sahibi olabiliyor.
  2. Sonrasında eğer yeni katılan geliştirici ise kısa bir süre hataları(bug) düzelten grubun içinde çalışıyor. Hataların kaynağını bulmaya çalışırken kodların yapısını çabuk kavramak mümkün oluyor. Değişik hatalarla uğraşırken sistemin birçok farklı kısmını görme imkanı buluyor.
  3. Sonrasında eşli programlama(pair programming) pratiği ile projeye yeni katılan kişiye bir yandan sürekli bilgi transfer edilirken bir yandan gerçek iş üstünde çalışması sağlanıyor.
  4. İşimizi kolaylaştıran bir başka özellik alan modelini projenin merkezine koymamız. Alan modelini oluşturan nesneler ve ilişkileri çalışma ortamımızın duvarında asılı. Tüm tartışmalar alan modelini kullanan bir dille yapıldığı için yeni katılan bir kişi bu modeli öğrendikçe müşteriyi, analistleri, testçileri kısaca tüm ekibin konuşmasını anlamaya başlıyor.
 

Planlama oyunu Haziran 7, 2007

Kategori: Agile — cenkcivici @ 1:52 am

XP ve Scrum ‘ da kullanım hikaye buyukluk tahminlerinin yapıldığı planlama oyunu ile ilgili bir yazı. Pratiği fotoğraflarla beraber güzel şekilde anlatmış.

http://www.crisp.se/planningpoker/

 

Test kapsam(coverage) in yüksek olması sistemin test edildiğini gösterir mi? Haziran 5, 2007

Kategori: Agile — cenkcivici @ 11:00 pm

Diyelim ki Emma veya Clover gibi araçlarla birim testlerinizin kodunuzun yüzde kaçını test ettiğini öğrenmek için raporlar alıyorsunuz. Bu tür araçlar birim testlerinden önce koda özel semboller koyuyor ve testlerin çalışması esnasında bu sembollerin yüzde kaçının üstünde geçildiğini size raporluyor.

Peki test kapsamının yüzde 100 olması tüm kodlarınızın test edildiği anlamına gelir mi?

Kısa cevap HAYIR. Diyelim ki bütün test kodlarınızdaki doğrulama adımlarını ( Junit Assertion ları mesela) kaldırdınız. Test kapsam raporlarını tekrar aldığınız zaman test kapsam yüzdesinde bir değişiklik olmadığını görürsünüz. Testler Assertion lar olmadığı için hiçbir şeyi test etmediği halde test kapsamınız yüzde 100 olarak raporlanıyor olabilir. Bir başka deyişle test kalitesi yüzde 0 olduğu halde test kapsamınız yüzde 100 olabilir.

Bu nedenle test kapsam yüzdesi sistemin ne kadarının test edildiği ile ilgili metrik olamaz. Yazılan testlerin kalitesi test kapsamından daha önemlidir. Ancak kaliteli testlerin olduğu bir sistemde test kapsamı ölçümleri bir anlam ifade eder.

 

Primavera ‘ da Scrum başarı öyküsü Haziran 3, 2007

Kategori: Agile — cenkcivici @ 7:36 pm

Primavera proje yönetimi yazılımları konusunda lider firmalardan biridir. Ürünleri inşaat, telekom, finans gibi sektörlerde kullanılmaktadır. Bu şirket 2003 yılında ürün geliştirme aşamalarında yaşadığı problemlerden kurtulmak amacıyla çevik süreçleri kullanmaya başlamıştır.

Primavera ‘ nın ürünlerine olan talep çok yüksekti ve farklı müşteri ihtiyaçlarına karşılık verebilmesi gerekiyordu. Geliştirme ekibi yeni sürümü yetiştirmek amacıyla fazla mesailer ve fedakarlıklarla dolu bir 2002 yılı geçirmişti. Çoğu projede olduğu gibi bu sürenin özellikle son birkaç ayı çok kötü geçmişti. Yeni gereksinimler haftasonları yapılan çalışmalar sonunda yetiştirilmeye çalışılıyordu.

Bütün bu fedakarlıklara rağmen birkaç hafta gecikmeyle de olsa çıkarılan sürüm üst düzey yönetim tarafından yetersiz bulunmuştu . Ayrıca yoğun bir dönem geçiren geliştirme ekibinin morali bozulmuştu.

Bu aksaklıkların sonucunda Primavera Scrum ve XP ile işe başlamaya karar verdi.

Scrum proje planlaması ve yönetimine ; XP ise analist, testci, geliştirici ve yönetici gibi rolleri barındıran bir ekibin etkin çalışabilmesi için gerekli yöntemlere odaklanıyor. İki sürecin birlikte kullanılması komple bir çözüm ortaya koyuyor.


Primavera işe ürün yönetimi için Scrum ‘ ı kullanarak başlar. Sonrasında ürün kalitesini ve ekip verimliliğini arttırmak için XP pratiklerini uygular.

Günümüzde Primavera halen çevik süreçleri kullanmaya devam ediyor ve müşterinin beğenisini kazanmiş yazılımlar üretiyor. Çevik süreçler aynı zamanda firma kültüründe de farklılıklar meydana getirir. Şu an yenilikçi fikirlerin ortaya çıktığı daha dinamik ve motive ürün geliştirme ekibine sahiptir.

Primavera daha iyi olmanın yollarını arıyor

Bob Schatz yazılım geliştirmeden sorumlu yöneticiliğe geldiğinde ilk önce küçük iyileştirmelerde bulunur. Motivasyonu arttırma amaçlı toplantılar, yeni ofis ortamı, primler gibi iyileştirmeler yapılır Fakat bu iyileştirmeler sonuçlara yansımaz.

Geliştirilen ürünün son sürümü çıktığı halde geliştirme ve pazarlama ekipleri ile üst düzey yöneticiler gidişattan memnun değildirler. Herkes gecikmelerden, ürün kalitesindeki sorunlardan ve yetiştirilemeyen özelliklerden dolayı birbirini suçlar.Hatta üst yöneticiler yazılım geliştirme ekibinin yıl sonu primlerini kaldırır.Daha ciddi bir değişikliğe ihtiyaç olduğuna karar verirler. Yazılım geliştirme konusunda mevcut yaklaşımları incelemeye başlarlar ve çevik süreçlerin kendi problemlerine en iyi ilaç olabileceğini düşünürler. Bunun nedeni şartların sürekli değiştiği kaotik ortamlarda çevik süreçlerin devamı sağlanabilir hızla , disiplinli ve kaliteli yazılım geliştirebilmenin yollarını göstermesidir.

O güne kadar Primavera ‘ nın yazılım geliştirme süreci tipik şelale(waterfall) süreci olmuştur. Pazarlama ekibi yeni sürümde görmek istedikleri özellikleri yazılım ekibine gereksinim dokümanı ile bildirmiştir. Yazılım ekibi ve yöneticiler bu dokümandan çıkardıkları işleri detaylı şekilde planlamaya çalışıp organize olmaya çalışmışlardır. İşler alt işlere bölünmüş ve planlar en ufak detaylara kadar yapılmaya çalışılmıştır. İşlerin bölünmesi sonucu oluşan alt kırılımlar analist, geliştirici ve testçi ekiplerine atanmıştır. Bu şekilde proje yönetimi cepheden çok uzaktaki komuta kontrol merkezinden savaşı yönetmeye benzer.

Müşteri portföyünün genişlemesi sonucu ihtiyaçlarda farklılıklar oluşur ve bu durum ürün geliştirme sürecini sekteye uğratır. Ürün teslimleri değişen gereksinimleri karşılayabilmek için sürekli erteleniyordu. Tüm bu durumlar ekibin üstünde baskı oluşturmuştur. Bu ortam şirketin müşterileri için kabul edilemez bir durum olarak ortaya çıkmıştı

Durum böyleyken Primavera, Scrum ve XP ye bir şans vermeye karar verir ve üst yönetimin desteğiyle Ken Schwaber gibi danışmanları şirkete davet eder.

Scrum ile başlarken

İlk önce yöneticilere ScrumMaster eğitimleri verilir. ScrumMaster proje yöneticisinin Scrum terminolojisinde karşılığıdır. ScrumMaster ‘ in ana görevi işbirliği ortamını güçlü tutmak, ekipler arasında kusursuz iş akışını mümkün kılmak ve aylık yinelemeler sonucu istenen özelliklerin yazılıma eklenmesini sağlamak olarak özetlenebilir.

Scrum sürüm 4.0 için denenmeye başlanır. Bu sürümün en kritik ve pazarlama ekibi için en fazla anlam ifade eden özelliği iş akışı ve işbirliği(collaboration) uygulamaları ile entegrasyonu sağlayabilmektir. Bu nedenle ilk yineleme için bu özellikle ilgili gereksinimler seçilir. Bir aylık yineleme sonunda amaç gereksinimleri mevcut yazılıma eklemek ve çalışan yazılımı teslim etmektir.

Ekip yapısı bu özelliğe odaklanılarak tekrar oluşturulur. Testci, analist, gelistirici gibi rolleri barındıran fonksiyonel bir ekip yapısı kurulur. Daha önce , ekipler roller bazında insanları gruplayarak oluşturulmuştu. Ekip bir aylık kısa süre boyunca belli bir alandaki özellikleri yazılıma eklemeye odaklanır. Hergün ayakta yapılan toplantılarla gidişat hakkında herkes bilgilendirilir.

Bir ayın sonunda yeni özellikler yazılıma eklenir ve yineleme sonunda yapılan toplantıyla yeni özelliklerin demosu yapılır. Pazarlama ekibi, üst düzey yöneticiler bir ay gibi kısa bir sürede önem verilen bir özelliğin yazılıma eklenmiş olmasından müthiş derecede memnundurlar. Artık eklenen özelliklerle ilgili kendileri de çalışmalar yapabilecekler ve stratejiler oluşturabileceklerdir. Bu iyi başlangıç tüm organizasyonun Scrum’ a geçişini hızlandırır.

Birlik olan ekipler

Çevik süreçlere geçişin dışardan farkedilen en büyük özelliği ofis düzenindeki değişikliklerdir. İnsanlarin çevresine bariyerler kuran kubik düzeninden daha açık , herkesin daha kolay iletişim kurabileceği açık ofis ortamına geçilir. İnsanlar birbirleri ile epostalar yollayarak iletişim kurmak yerine en etkili iletişim yöntemi olan yüzyüze iletişimi tercih etmeye başlar. Böylece ekibin içindeki bağlar kuvvetlenir ve bilgi paylaşımı artar.

Primavera ‘ nın doksan kişilik yazılım ekibi onar kişilik alt ekiplerden oluşmaktadır. Her alt ekibin çalıştığı bölgede herkesin görebileceği biçimde alt ekibin amacı, hedefi , duvara asılır. Bunun yanında ekip yineleme planları, farklı grafikler, testlerin kapsam raporları gibi bilgileri duvardaki panolara asarak paylaşır ve sabah toplantıları bu panoların önünde yapılır. Böylece son durum hakkında herkes bilgi sahibi olur.

İlk yayımdan sonra

Proje yönetimi ve planlaması Scrum ile yapılmaya başlandıktan sonra geliştirme, test, entegrasyon konularında farklı pratiklerin gerekliliği ortaya çıkar. Primavera klasik şelale sürecinden geldiği için testleri ve entegrasyonu yazılımı yayınlamadan kısa bir süre önce yapmıştır. Her yinelemeyi yeni özellikler eklenmiş ve kullanıma hazır biçimde bitirebilmek için test, entegrasyon gibi pratikleri baştan sona sürekli yapılır hale getirmek gereklidir Bunun için XP pratiklerinin hayata geçirilmesine karar verilir.

XP ‘ nin getirdiği kurala göre bir özelliğin bitmiş sayılabilmesi için birim ve kabul testlerinin tümünden geçmesi gereklidir. Primavera ‘ da XP pratiklerinin uygulanmaya başlanır. Geliştiriciler birim testlerini kodlarını yazmadan önce kodlamaya başlar. Pazarlama ve analistler kabul test senaryolarını vermeye başlarlar. Object Mentor ‘ dan alınan danışmanlıkla geliştirici ekibe Nesne tabanlı yazılım geliştirme, basit tasarım, test yönlendirmeli tasarım, refactoring gibi pratikler hakkında kabiliyetler kazandırılır. Sürekli entegrasyon pratiği ile yazılım geliştiriciler sık sık yazdıkları kodların versiyon kontrol sistemine eklenir. Bu değişiklikler o anda otomatik olarak kapsamlı testlerden geçerek entegrasyon problemleri anında tespit edilir.

Başarısız olma gibi bir seçenek yok

Primavera ‘ nin CTO’ su Dick Faris yazılım geliştirme sözkonusu olduğunda başarısız olma gibi bir seçeneklerinin olmadığını ve insanların kullanmak isteyecekleri yazılımı verebilmenin en önemli şey olduğuna dikkat çeker. Bu nedenle yazılım firmaları 18 ay önce aldıkları gereksinimleri değişmez olarak kabul edip yazılım geliştiremezler. Değişiklikleri kontrol etmeye ve önlemeye çalışan süreçler yerine bu değişiklikleri müşteriye daha iyi değer sağlayabileceğimiz fırsatlar olarak gören ve bunun için formüller öneren süreçleri kullanmak zorundayız.

Primavera ‘ nın uygulamasında yineleme sonlarındaki değerlendirme toplantılarında (Sprint Review meeting) ilgili herkese yeni eklenen özellikler tanıtılır ve fikirleri alınır. Bu fikirler somut çalışan yazılım üstünden sağlandığı için şirkete rekabet anlamında yararlı fikirlerin ortaya çıkması kolaylaşır.

Farkedilen değişikler

Primavera proje yöneticilerinden ve Scrum Master Jennifer Coyle şöyle diyor.

‘ Yinelemeler boyunca tek hedefe odaklanarak sürekli işbirliği içinde ve uyumla çalıştığımız için daha verimli oluyoruz. Bu verim herkesin eve saatinde gitmesi ve ailesine daha fazla zaman ayırabilmesi anlamına geliyor. Böylece bununda kişisel motivasyon üstünde olumlu etkileri oluyor. Herkes bir sonraki iş gününe daha fazla iş başaracağız diyerek geliyor ve yaptığı işlerden gurur duyuyor.

Scrum ‘ ın en tuttuğumuz başka bir yönü sürekli gözden geçirmelerin olması ve yeni isteklerle uyumu. Bu sayede müşterinin gerçekten ne istediğini somut şekilde anlayabiliyoruz. Uygulanan pratiklerle sürekli yazılım teslimine hazır şekilde durabiliyoruz.’

Bugün

Primavera Scrum ve XP pratiklerini kullanmaya başladıktan dokuz ay sonra hedefledikleri sürümü çıkarmayı başarır. Bu sürüm daha önce yapılan iki sürümün içeriğini oluşturan özelliklerin toplamından daha fazla özellik içermektedir. Pazarlama, ürün yöneticileri, geliştiriciler , yöneticiler ve testcilerin olduğu büyük bir ekibin işbirliği ile bu başarılı sonuç yaratılır.

Primavera çevik yaklaşımları öylesine başarılı bulur ki çevik proje yönetimi ile ilgili bir araç geliştirerek müşterilerine sunar.

En büyük zorluk

Primavera ‘ nın başarısı sonucunda her firma aynı yöntemleri uygulayabilmek isteyebilir. Fakat başarılı olabilmek için organizasyon olarak kültür değişikliği gerekir. Bu kültürü değişikliğini yapmaksızın sadece belli pratikleri kullanarak fayda sağlanması güçtür. Primavera bu başarısını yaptığı kültür değişikliğine borçludur.

 

Sürecin adı yok Haziran 2, 2007

Kategori: Agile — cenkcivici @ 11:40 pm

Geçenlerde işe giderken aklıma takılan bir soru oldu. Acaba projede uyguladığımız sürecin adı var mı veya adının olması önemli mi?

Tüm çalıştığım ekiplerde çevik prensipleri temel alan süreçler kullanıyoruz. Sürekli entegrasyon, TDD, Refactoring, Yinelemeler, Planlama oyunları, Yayım planları -yönetimi, Kullanım hikayeleri(user story) gibi pratikler isim olarak ortak fakat detaylara baktığımda projeden projeye birçok farklılık göryorum..

Bu farklılığın nedeni süreçler projelere göre uyarlanıyor ve bu uyarlanma proje süresi boyunca son güne kadar devam ediyor.Proje süresi boyunca projeye başlangıcındaki şartlar aynı kalmıyor. Şartlar değiştikçe ortaya çıkan olumsuzlukları ortadan kaldırmak ve  daha etkin çalışma olanaklarını değerlendirmek gerekli. Projenin başından sonuna aynı süreç yapısını aynı şekilde hiç değişmeden uygulamaya çalışmak belki süreç denetim memurlarını mutlu edebilir fakat ekibin daha verimli çalışabilme olanaklarını ortadan kaldırıyor.

Çevik süreçler kendini değişikliklere nasıl adapte ediyor ? Öncelikle kültürel olarak bir fark var. Çevik ekipler kendi çalışma şekillerini seçme ve kendilerini organize etmeleri konusunda yetkili kılınıyor. Kısa sürelerle toplanıp projede neyi iyi yaptıklarını, neyin daha iyi olabileceğini tartışıyorlar. Bu toplantılara Retrospectives diyoruz. Bir nevi ekip çalışma şeklini kodların Refactor edilmesi gibi iyileştiriyor ve yola devam ediyor. Ekibi oluşturan tüm bireyler sürekli daha iyi nasıl çalışabiliriz sorusunu kendisine soruyor. İyileştirmeler tepeden değil tabandan yukarı yayılıyor. Bu konuyla ilgili daha önce yazdığım bir yazı http://cenkcivici.wordpress.com/2007/05/23/gecmise-bir-bakis/

Bu nedenle Scrum, XP vesaire gibi süreçleri kullanıyoruz demek bana çok anlamlı gelmiyor. Çevik(Agile) yapıda süreçler kullanıyoruz demek ve genellemek daha mantıklı. XP, Scrum başlangıç noktaları oluşturuyor. Sonrasında iş projeye en uygun yöntemi süzmeye kalıyor Sürecin adının ne olduğu hiç önemli değil…..

 

Tahminleri kim verir? Haziran 1, 2007

Kategori: Agile — cenkcivici @ 12:33 am

Diyelim ki kullanım hikayelerini(user story) leri çıkardınız. İşlerin ne kadar zamanda bitebileceğini kestirebilmek için bir tahmin yapmak şart.

Bu aşamada tahminleri kim verir? Tahminler ne olarak verilir?

Çok kısaca bizim projelerde uygulamalarımız nedenleriyle şu şekilde.

Tahminler tüm ekipçe planlama oyunu denilen pratikle verilir. Bu pratiğin detaylarını daha önceki bir yazıda anlatmıştım.Kısaca tekrarlamak gerekirse bu aktiviteye ekipteki tüm yazılım geliştiriciler katılır.  Her kullanım hikayesi teknik ve iş mantığı açısından Teknik lider ve Analist tarafından sırayla açıklanır. Bu konuda yazılımcıların soruları cevaplanır. Riskler , varsayımlar ortaya dökülür. Tahminlemeye geçmek için her ekip üyesinden onay alınır. İşin kapsamı hakkında bilgi sahibi değilseniz tahmin vermeyeceğim deyip kısa araştırma(spike) çalışması isteyebilir ve risklerin azaltabilirsiniz. Herkes tahminleme için evet diyorsa kart için herkesten aynı anda tahmin vermesi istenir.Tahminler ideal gün olabileceği gibi 1,2,3,5 gibi sayılar olarak verilebilir. Sonrasında eğer aşırı fazla veya az tahminler varsa bu tahminleri verenler neden az veya fazla verdiklerini açıklarlar ve ekip ortak bir değerde buluşur. Süreç diğer kartlarla devam eder. Bu tahminler daha sonra yayım ve yineleme planlamasında kullanılır. Özellikle projenin ilk safhalarında kartlar birbirlerine göre bağıl olarak tahmin edilir. X kartı 1 denir, ölçü olarak alınır ve Y kartının tahmini X e göre bağıl olarak verilir. Bunun nedeni projenin ilk aşamalarında zaman tahminlerinin verilmesinin zorluğudur.

Bazı ekiplerde tahminlerin sadece ekibin teknik lideri tarafından verildiğini görmek mümkün.Bunun yapılmasının nedeni tahminlerin doğruluğunu sağlayabilmek fakat işi yapacak kişi teknik lider olmayacağı için aslında tahminler doğru demek yanlış olur. Planlama oyunu aktivitesinde olduğu gibi tahminler tüm ekip tarafından verilmeli.

Peki tahminler tutmaz ise ne olur? Planlama oyununda tahminlerin birbirlerine bağıl olarak verildiğinden bahsetmiştim. Proje başladıktan bir süre sonra 1 , 2 ,3, 5 gibi ölçekte işlerin ne kadar sürdüğü ile ilgili cetveller oluşmaya başlayacaktır. 1 olan kart 0.5- 1.5 gün arası sürüyor gibi. Kartlara dair iş miktarı birbirlerine bağıl olarak tahmin edildiği için zaman tahminlerinde yaşanan problemler yaşanmayacaktır.

Ayrıca asıl olan tahminler değil ekibin birim zamanda yani yineleme(iteration) bazında ne kadar iş yapabildiğidir. Buna kısaca hız diyelim. Tahminlerin tek başına hiçbir anlamı yoktur ve işlerin ne kadar zamanda bitebileceğini hızı hesaba katmadan bulmak mümkün değildir. Eğer projenin şartları değişirse örneğin projeye yeni elemanlar eklenirse bu yineleme sonunda ölçülen hızı yükseltebilir . Bu sayede tahminlerinizi değiştirmeden projeyi süresindeki kısalma ile ilgili kestirim bulunabilirsiniz.

Özetlemek gerekirse tahminleri tüm ekip tarafından vermek gerekiyor.Tahminleri zaman olarak değil birbirlerine bağıl büyüklük değerleri ile vermek ve tahminlere TAHMIN gözüyle bakmak gerekli.  Hız ölçümü projenin süresi ile ilgili hesaplarda kullanılan asıl ölçümdür.