İki senedir Dünyanın çeşitli ülkelerindeki telekom operatörlerine proje yetiştiriyoruz. Bana sorucak olursanız “Teslim Tarihi, Kalite, Maliyet Etkinliği üçlüsü arasında en önemlisi hangisidir?” diye, “Teslim Tarihi” derim. Çeşitli sebepleri var. (Belki bir gün bu sebepleri yazarım; Emekli olduktan sonra… Kitabın adını da “Emekliyken Dinlet®” koyarım :)) Neyse... Test süreçlerinize güveniyorsanız zaten birinci sıra Teslim Tarihi'ne aittir.
(Devamı için tıklayınız.)

Uzun süredir bu Teslim Tarihi’ni nasıl 3, 4 ay öncesinden en mükemmel şekilde veririzin incelemesini yapmaktayız. Teslim Tarih’i uzun verilse ekipte gereksiz insan gücü kaybı, müşteri memnuniyetsizliği ve/veya projeye olan ihtiyacın ortadan kalkması riskleri mevcut, kısa verilse ekibin üzerindeki fazla mesai yorgunluğu stresi ve beraberinde gelen ekstra gider riski olabilir. Teslim tarihi ile ilişkili olan İş yükü fazla verilse gene müşteri memnuniyetsizliği veya projeden vazgeçilmesi, az verilse sene sonunda maliyet etkinliğinden kötü not ile karşılaşılabilir. Dolayısıyla tahmin toplantılarının sonucunda en uygun değerler bulunmalı; teslim tarihi ve iş yükü ona göre verilmelidir.

Huawei Türkiye ArGe Merkezi (HTRDC) RBT ekibi olarak iki farklı tahmin tekniğini denedik: Pert ve Wideband Delphi.  Tahmincilerin birbirlerini son aşamaya kadar etkileyemediği Wideband Delphi tekniği tahmin toplantısının çok fazla uzamasına sebep olduğu, aynı zamanda deneyim paylaşımını da desteklemediği için uzun zamandır kullanmıyoruz. Bu sebeplerden ötürü yazımın devamı tercih ettiğimiz Pert tahmin tekniği üzerine olacaktır.

Pert Tahmin tekniğini excel veya başka bir yazılım kullanarak gerçeklediğimizde karşımıza şu şekil çıkıyor.

Şema: Pert Makinesi

Tahmin toplantısına başlamadan önce müşteri tarafından onaylanmış “gereksinim analiz dokümanı” (FRS) hazır olmalıdır. Bu dokümanı hazırlayan kişilerin pozisyonları, sıfatları ve rolleri endüstriden endüstriye, şirketten şirkete değişmekte ve tartışmaya açık bir konudur. İş Analisti, Sistem Mühendisi, Çözüm Mimarı, Gereksinim Analisti vs bunlardan bazılarıdır. “Sistem Mühendisi ne alaka?” der gibi duyuyorum bununla da karşılaştım. Gereksinim analiz dokümanı müşterinin ağzından dökülen kullanım durumlarının işlenmiş ve büyük ölçüde çözüme ve ürüne oturtulmuş halidir. Gereksinim analiz dokümanının biçimi, içeriği, teknik derinliği bizim ekibimiz için sabittir. “Her bir cümlesi testerlara testcase yazdıracak kadar yalın ve basit, sunulan teknik çözüm müşterinin teknik olmayan pazarlama çalışanlarının okurken kopmadan anlayabileceği ölçüde alt seviye, gereksinim takip dokümanına ve alt Seviye Tasarım dokümanına girdi olarak girebilecek atomiklikte ve mümkünse 800 satırdan daha fazla kod yazılmadan gerçeklenebilecek parçalara/maddelere ayrılmış olmalıdır.”

Bu gereksinim analiz dokümanını yemiş bitirmiş, gereksinimlerin gerektirdiği teknolojiler üzerinde deneyimli en az iki developer ve iki tester, proje kalite mühendisi ve proje yöneticisi tahmin toplantısında hazır bulunması zaruri kişilerdir.

Yukarıdaki şemadan da anlayacağınız üzere sistemin öncelikli üç olmak üzere dört girdisi mevcuttur: “Kod Satırı Tahmini”, “Üretkenlik”, “Günlük Çalışma saati” ilk aşamada gerekli iken teslim Tarihi için “iş Yükü kırılımı ve Kaynak planlama girdileri” ikinci aşamada sağlanır.

Dokümandaki her bir parça/madde için Kod satırı tahmini birbirileri ile tartışarak “kavga değil”, “fikir alışverişi zemini” içerisinde tahminde bulunan en az iki developer tarafından değerlendirmeye alınır.

Estimated Items Tablosu

Burada önemli olan nokta bu kod satırları verilirken testing, dokümantasyon vs başka herhangi bir iş yükü düşünmüyor olmanızdır. Sadece ve sadece yazılacak olan kod satırı tahmin edilmeye çalışılmalıdır.

Verilen ikinci girdi “Günlük Çalışma Saati’dir”. Bu rakam gün içerisinde bu proje içerisinde yer alacak olan kişilerin bir çalışma günlerinin kaç saatini bu projeye ayıracaklarıdır. Bir gününüz 7,5 saat ise sakın ola ki buraya 7,5 yazmayın, çay kahve molalarını hesaplayaraktan düşürünüz. Tek projede çalışacaklar ise bir günlük efektif çalışma saatini baz alınız. Bir günde birden fazla projede yer almaları durumu varsa daha dikkatli sunmalısınız.

Gelelim üçüncü girdiye “üretkenlik”… O girdiyi anlamak ve anlamlı bir değer verebilmek için 2 sene metrik topladım… Üretkenlik’in değeri “Proje takımının bir üyesi, ilgili proje için bir günde test edilmiş, dokümante edilmiş kaç satır kod yazabilir?” sorusunun cevabıdır. Üretkenlik projeden projeye çok fazla değişkenlik gösterebilir ve ilgili projenin doğasına bağlıdır. Ne kadar çok oynuyorsa (yani 10 proje sonunda gerçek üretkenlik değerlerinin birbiri ile alakası yoksa…) bir proje yöneticisinin yeni bir proje için “Teslim Tarihi” vermesi o kadar zordur. Proje front end / end user web projesi ise kodlama iş yükü düşük, cross browser compability yüzünden testing iş yükü yüksek olabilir. Bu durumda üretkenlik düşük tutulmalıdır veya tam tersi proje otomasyona/unit testing’e yatkın olup kod satır sayısı yüksek ve testing / dokümantasyon iş yükü hafif olabilir, bu durum üretkenliği arttırabilir. Proje bitiminde ise gerçek üretkenlik gerçek değerlerle hesaplanarak bir sonraki projede kullanılmak üzere değerlendirilmelidir.
Üretkenlik hesabı ise benim bildiğim iki yöntem ile yapılır bunlardan ilki eski olan proje sonunda sayılan “geliştirilen satır sayısı” / “adam gün cinsinden harcanan gerçek iş gücü”, ikincisi yeni ve giderek yaygınlaşmakta olan “Functional Points” metodudur. 2011 yılı boyunca gerçekleştirdiğimiz 27 proje, 161 isterden topladığımız reel/gerçek (proje sonunda ölçülen) metrikler sonucunda üretkenlik değerlerini benzer projelerden alıp doğru tahminde kullanabiliyoruz.

Metrik toplamak istiyorsanız Atlassian JIRA kullanmalı ve logwork mantığının farkındalığını ekibinizde yaratmalısınız. JIRA “issue tracking yazılımı” gibi web tabanlı bir yazılımın varlığı olmaksızın büyük takım yönetiminin olası olmadığını düşünüyorum. Gene Jira sayesinde Pert tekniğine ikinci girdi olan “Günlük Çalışma Saati” değerini doğru seçebilirsiniz. Lütfen bu tekniği kullanırken şu üç maddeye dikkat ediniz:

• Tüm engelleyemediğiniz risklerin zararlarını, aksaklıkları, information development ve testing iş yükü, load factor’u düşünerek bu üretkenliği vermeliyiz.
• Kod satırı tahmini sırasında sadece ve sadece developerların yazacağı kod satırına konsantre olunmalı.
• Proje süresince diğer tüm değerlerde olduğu gibi “tahmin edilen” üretkenlik, “yeniden planlanan” üretkenlik ve gerçek/reel üretkenlik değerlerini birbirlerinden ayırıp kayıt altına almalıyız.
• Developerlar toplantı sırasında birbirleri ile tartışırken ağızlarından dökülecek her bir kelimeyi daha sonra kafalarına test case ve defect olarak vuracak olan testerların not tutması, aynı zamanda üretkenlik girdi olarak verilirken Project Manager ile üretkenliğin değeri için tartışmaları hayati önem taşımaktadır.

Bu üç girdi bir araya getirildiğinde ortaya aşağıdaki gibi bir tablo çıkar.

Workload Estiomation Tablosu

Benim her zaman projenin kütlesi dediğim iş yükü şu şekilde hesaplanmaktadır: Estimated Items tablosundaki E (LOC) kolonundaki tüm değerlerin toplamını: “kod satır” sayısı olarak kabul edelim. “(kod satır sayısı/üretkenlik)*(/ (günlük çalışma saatiniz)) = iş yükü” işte yazılım dünyasında ücret müşteriden bu rakama göre istenir. Yazılım şirketleri marka değerlerine vs göre mühendis başına günlük belirledikleri fiyatı bu rakam ile çarpıp müşteriden isterler. Örnek veriyorum: 225*500$ desek … J

Teslim tarihini vermesi açısından Pert Tahminin bundan sonrası en az bu kadar önem taşımakta olup doldurulması buraya kadar olan bölümden daha az emek gerektirmektedir.

İleri derecede metrik analizi yapmak için iş yükü kırılımı da yapılmalıdır. Kısaca projede ölçmek istediğiniz safhaları ayırıp toplam iş yükünü yüzdeler halinde ayırmanız gereklidir. Ayrılan yüzdelerin toplamı %100 olmalıdır. Aşağıdaki tablolar ve rakamlar örnektir:

Daha sonra her bir safha için ayıracağınız kaynak sayısını giriniz:

Gereksinim analiz dokümanı (Functional Requirement Specification) muhakkak müşteriye imzalatılmalıdır. Ardından teslim tarihi için şu şekilde söz verilir: “Ürünün Test sürümü, gereksinim analiz dokümanı tüm proje paydaşları tarafından imzalandıktan 56 iş günü sonra teslim edilecektir. Test sürümü ve son sürüm arasındaki zaman farkı saha ekiplerinin geribildirim performansına bağlıdır.” Şu cümlenin geçtiği bir eposta ile beraber yukarıdakine benzer rakamlar ve bir de geçmiş projelerin reel değerlerini sunarsanız ayağınızı yere sağlam basarak projenin ilk etabını tamamlamış olursunuz.

Projenin bundan sonrası artık tahmin değil, kabaca planlama →yönetim → metrik toplama→ kapanış toplantısı→ iyileştirme döngüsüne girer. İleride gaza gelirsem (ki gelirim) bu safhalar içinde birer yazı yazarım.

Birçok bilgi öğrendiğim, beraber çalışmaktan keyif aldığım HTRDC Kalite Mühendisi, yılların deneyimi Yelda Gürbüz Erdoğan’a teşekkürü bir borç bilirim.

Kaygısız, huzurlu ve başarılı projeler dilerim…

Özkan Gümüş
HTRDC RBT Team
Project Leader

Yorumlar (3)

Bu yorumun beslemesine abone olun

Pert Methodu Hakkında
yazar Emre Günaydın, February 11, 2012

Özkan merhaba
Paylaştığın bilgilier için teşekkür ederiz.Pert methodu konusunda yaptığın araştırmalar ve bu araştırmalar sonucu ortaya çıkan bilgilieri tecrübelerinle birlikte sunduğun profesyonel bir makale hazırlamışsın.Bildiğin üzere workload estimation yapabilmek için kullanılan birçok metod var ve bunlardan bazıları projelerdeki başarısız uygulamlardan ötürü geçerliliğini yitirdi.Bunlardan en fazla kullanılan PERT ve WideBand Delphi Estimation.PERT daha küçük çaplı projelerde kullanılmakla beraber Wideband Delphi Estimation Workloadu yüksek projelerdeki başarısını kanıtlamış durumda.Yazındada belirttiğin gibi bu estimation aktivitesine katılan mühendislerin konuya hakimiyeti ve eski tecrübeleri estimationun bel kemiği diyebiliriz.Bir projenin başarılı bir şekilde tamamlanması Estimationın gerçekçi yapılıp projenin tüm safhalarında karşılaşılabicek risklerin önceden görülüp bunlarla ilgili contingency planları hazırlamak ve olası risklerin takip edilip başarılı bir şekilde atlatılmasıyla mümkün.Yapılan projelerdede gördümüz üzere sektörün bir o kadar yırtıcı olması neticesinde workload estimationun göz ardı edildiği bazı zamanlardada PO ile ilgili baskı bu estimationların gerçekçi olmasını engelliyor.Gereksinimlerin stabilitesi ve çözümün iyi şekilde analiz edilmiş olması 3rd party gruplara olan bağımlılık projenin başarısını etkileyen diğer faktörler.Bildiğin üzere customization projelerindeki workload estimation development projelerindekilere nazaran daha zordur bu konudaki tecrübelerinin diğer proje lideri arkadaşlara faydalı olmasını temenni ediyor tüm proje yöneticisi arkdaşlarıma başarı dolu projeler diliyorum.

Emre Günaydın
HTRDC NGIN Team
Project Leader

• 
• +0
• 
• 

...
yazar Özkan Gümüş, February 11, 2012

Emre Selam,
Intergroup Coordination da productivity tahmini içerisinde Part machine'e giriyor. Örneğin bir projenin intergroup coordination'ı çok yüksek ise productivity'i coordination'ın yoğunluğu çerçevesinde düşürmeyi öngörüyorum.
Temennilerin için teşekkürler,
Risk Planing ile ilgili bir yazıyı da senden bekliyorum
Bundan sonraki yazım kuvvetle muhtemel "How to improve Virtual MAchine capability of your company" olacaktır

• 
• -1
• 
• 

...
yazar Yelda Gurbuz Erdogan, February 12, 2012

Merhaba,

Hepimiz bir şekilde geleceği bilmek isteriz. Bunu hem sosyal yaşantımızda hem de iş yaşantımızda bir sonraki aşamayı bilerek, hali hazırda yaşadığımız anı daha verimli geçirebiliriz.

Bir projeye başlarken yapılacak işe ne kadar zaman harcayacağımızı, ne kadar insan kaynağı kullanacağımızı, iş takvimimizin ne olacağını tahmin ederek iş kırınımımızı yapmak bizi planlı, izlenebililir ve gözlemlenebilir işler ortaya koymamızı sağlar.

1950'li yıllardan beri çeşitli tahmin yöntemleri kullanılmaktadır. Hepsi matematik temelli yaklaşımlardır. Özkan Gümüş tarafından PERT yönteminin uygulaması oldukça güzel bir biçimde anlatılmıştır. PERT yöntemi arge projeleri için özellikle uygulaması önerilen bir yöntemdir.İlk olarak US Navy tarafından denizaltı projesi için (nükleer olabilir) kullanılmıştır.Bu proje o kadar da küçük bir proje değildir.

PERT yöntemi ile ilgili yazılmış pek çok kitap bulunmaktadır. İlgilenen arkadaşların bu kitapları izleyerek proje gözleme ve izlemeyi çok verimli bir biçimde yapabileceklerini düşünüyorum.

Sevgili Özkan'a bu paylaşımından dolayı çok teşekkür ederim. Önümüzde yapacak çok işimiz var, bu Özkan'ın daha pek çok yazıyı burada yayımlayacak demektir

• 
• +0
• 
• 

İsim

E-posta

Website

Başlık

Yorum

daha küçük | daha büyük

E-posta ile takip (sadece kayıtlı kullanıcılar)

Yorum Ekle