Sayılar ve Kuramlar: 2000
Ürün şirketi ile başlayalım.
Microsoft, Oracle gibi büyük şirketler, paket program olarak ürün piyasaya sürerler. Direk ev kullanıcısı, ya da programcılara hitaben altyapı olarak kullanabilek bu ürünler, parakende fiyat ile piyasada satılır. Ya da, Oracle'ın kullandığı oldukça çetrefilli bir lisans (fiyatlandırma) kuralı eşliğinde ürün müşteriye satılır.
Ürün yazılım şirketleri, bir paketi piyasaya sürmeden önce, uzun süreli bir ar-ge dönemi süresince büyük paralar harcarlar. Mesela Oracle veri tabanı, ya da Microsoft Windows işletim sistemi, milyonlarca dolarlık programcı ve testçinin zaman harcayarak ortaya çıkardığı bir sonuçtur (sürekli bozulsa da (!)).
İlginç olan, ilk geliştirme seviyesi aşıldıktan sonra, paket programlar kopyalanma, ya da normal sanayii'nin anladığı şekilde, üretim/çoğaltma safhasında neredeyse yok denecek bir miktar harcanmasıdır.
Yazılım tabanlı ekonomik modele 'yeni ekonomi' denmesinin de sebeplerinden biri budur. Kıyaslayacak olursak, bir maden ocağı ortada olan belli miktardaki bir kaynağı çıkartıp, piyasaya sürerek getiri kazanmaya uğraşır. Eğer maden ocağı daha fazla üretim yapsın der isek, daha fazla elemen işe koyulması gerekir. Fakat bunun anlamı aynı zamanda maliyat fiyatlarının 'artması' demek olacaktır. Belli bir arttırımdan sonra eldeki kâr kaybolmaya başlayacağı için de, maliyet, üretim miktarı gibi ayarların dikkatli gözlenmesi gerekir, nitekim ekonomide bu kuramın 'düşmekte olan getirilerin kuramı (theory of diminishing returns) olarak anılmasının sebebi budur.
Fakat yazılımda, ürün şirketleri için yazılımın kopyalanması safhası çok ucuzdur, hatta şimdi İnternet sayesinde sıfıra yakındır. Bu yüzden herhangi bir firma piyasaya derhal (en önce) çıktığı anda, sıfır üretim maliyeti sayesinde süratle kopya çıkartarak, piyasayı anında tekelleştirmesi mümkün olmaktadır. Nitekim, Microsoft'un mahkemelik olmasının sebebi de biraz da açıdan alınmalıdır. Yazılım sektöründe, dişe-diş, pastayı eşit paylaşmış olan rakiplerin kavgası yerine, bir tekelin ötekini yıkarak geldiği bir savaş vardır, buna değişik zamanlı tekellerin savaşı denebilir.
Programcılar Açısından Ürün Şirketleri
Ürün şirketleri, bir kod bazı ile uzun süre beraber kaldıkları için, tekrar-tekrar kullanır (reusable) kodlama yapmaya daha özen gösterebilirler. Danışman şirketlerinde tanıştığımız, tekrar kullanılan kodlama tekniklerini en çok ilgi gösteren kimseler, ürün geçmişi olan programcılar oluyordu. Tabii daha farklı olan danışmanlık ortamı, bu arkadaşlara genelde biraz garip gelibiliyor. Yazılıp/atılan kodlama, uzun süreli bakılan/genişletilen kodlar ortamından tabii ki değişik olmaktadır. Danışman şirketleri yazının geri kalan kısmında işleyeceğiz.
Bu fark dışında ürün şirketleri de sürekli tümleştirme tekniklerini kullanırlar, mesela Microsoft projelerinde günlük bütün kod bazını derleyen ayrı bir makina vardır diye duyumlar almıştık. Tabii Extreme Programcılık yöntemi, bu sayıyı çok daha sıklaştırmıştır.
Ürün şirketlerinde bir kötü taraf, zamanla programcının aynı konu üzerinde sürekli çalışması ile ortaya çıkan 'aşırı uzmanlaşma' durumudur, bu durumda bir nevi at gözlüğü takılmış gibi sadece bir konuya odanlanma olayı ortaya çıkabilir; Fakat eğer ürünün gelişmesi uzun sürecek ve gelişerek yeni teknolojiler eklenecek ise, bu durum o kadar kötu olmayabilir. Her halukârda, XP'nin eşleme tekniği ve sandalye değiştirme taktikleri ile bu aşırı uzmanlaşmanın önüne geçilebilir.
Bu tür yazılım şirketi çoğu kimse için (hatta çoğu programcı için bile) tam bir muammâdır, bu yüzden özellikle işlemek istedik.
Danışman şirketlerin tarihi, en azından Amerika'da, 'vergi danışmanlık' tarihi ile yanyana gider.
Bunu da anlamak için Amerika'nın vergilendirme sistemini bilmek gerekiyor. ABD'de birçok vergi kanununun oluşturduğu, yılların da verdiği değişim, lobilerin kendi sektörleri için Kongre'den geçirttikleri ekler (rahatlıklar) yüzünden ortaya çıkan tam bir keşmekeş durumu vardır.
Bu keşmekeşin içinden çıkmak bir süre sonra bir uzmanlık haline gelmiş, ve bu tür danışmanlık yapan şirketler holdinglerin kapısını çalmaya başlamıştır. Danışmanlar, müşterileri olan şirketlere vergilerini nasıl vereceklerini, aynı zamanda da, nasıl daha az vereceklerini öğretmek için vergi sistem açıklarını, müşterilerinin bulundukları sektörü gözeterek önemli bir servis sağlamaya başlamışlardır. Bu danışman şirketlerin sunduğu vergi tavsiyesi, bir bakıma holdinglerin kârlılığı üzerinde direk bir etki teşkil ediyordu.
Bu şekilde vazgeçilmez hale gelen danışmanlar, bir süre sonra vergi danışmanı olarak girdikleri şirketlere yan ürünler de pazarlamaya başladılar.
Bu yan ürünlerden birisi (ya da servis demek daha uygun olur) "stratejik tavsiye" türünden bir danışmanlık idi. Holdinglerin işletmesini ilerletmesi için getirilmesi mümkün olan iyileştirmeler, bir şirketin nasıl düzenleneceği, karar mekanizmasının nasıl isleyebileceği, vs. gibi tavsiyeler hep bu şemsiye altında sunulmaya başlanmıştır. Vergi tavsiyesi için zaten müşterinin kapısından girmiş olan danışman, bir yandan da açık gördüğü yerlerde bu tür yeni danışmanlığı pazarlamakta zorluk çekmemiştir.
Tabii, stratejik danışmanlık, 80'li yıllardan sonra beraberinde teknolojik danışmanlığı da otomatikman getirmiştir.
ABD televizyonlarında çıkan bir IBM reklamının da söylendiği gibi, artık şirket başkanlarının (CEO'ların) aldıkları her karar, mutlaka teknolojik bir değişiklik yani yeni bir yazılım projesi içermektedir. Gitgide yazılıma bağımlı olan şirketler, eğer yeni bir düzenleme yapmak istiyor iseler, yeni bir yazılım değişikliği de yapmaya mecbur kalmaktadırlar.
Zamanla, bu üç danışmanlık çeşidi bazen tek başlarına görülmeye başlanmıştır. Günümüzde, kimi şirket sırf yazılım danışmanlığı, kimisi sırf stratejik, kimisi de sadece vergi danışmanlığı yapabilmektedir. Tabii eskiler, ya da beş büyük diye anılan şirketler hala tüm servisleri birarada taşımaktalar. (Taşımakta idiler demek daha da doğru olabilir, çünkü son zamanda meydana gelen şirket bölünmeleri bu durumu biraz değiştirmiştir).
Danışman Şirketlerin Düzeni
Sırf yazılım danışmanı olan bir şirketi ele alalım. Bu şirketlerin atmosferi genelde şöyledir.
Bütün hayat proje etrafında döner. Gelişen teknolojilerinde etkisi ile proje bitme süreleri iyice düşmüştür, ve bu yüzden kim nerede, kim hangi projede gibi konuşmalar duyarsınız. Sürekli bir hareket vardır.
Kültür olarak, danışman şirketlerde çalışan kişiler, programcı seviyesinde bile, teknolojiyi allandırıp pullandırmakta en büyük ustadırlar. Çünkü, söyle ya da böyle müşteri karşısına çıkacaktırlar, ve bu yüzden teknolojiyi satmak zorundadırlar. Teknoloji satmakten kastımız, kendilerinin XYZ teknolojisini kullanarak getireceği çözümü satmaktır. Genelde danışman şirketlerin kendi ürettiği bir ürün yoktur.
Artı olarak danışman şirketlerin en iyi tarafı, dinamik ve sürekli devirdaim olan teknoloji bilgisidir. Her proje 6-7 ayda bittiği için, bu her seferinde yeni bir yazılım projesine silbaştan başlanacak demektir, ve bu yeniden başlama sırasında bir önceki projeden gelen, halâ taze olan bilgilerden muhakkak yararlanılır. Mesela kaynak kod idare sistemi kuruluşu, sürekli tümleştirme makinasının kuruluşu, programcıların ihtiyacı olan Unix kullanıcı hesaplarının sıfırdan kurulması birkaç projeden sonra artık süratle yapılır hale gelirler.
Ek olarak, bir de her projenin getirdiği yenilikler vardır. Danışman programcı, her yeni projede, sürekli değişmekte olan teknolojiden yeni bir tanesini denemeye fırsat bulabilir. Sıfırdan başlandığı için ekleme yapmak zor olmaz. Tabii, yeni teknolojiyi öğrenme için harcanacak (kaybedilecek) zaman göz önünde tutulmalıdır. Eğer danışman her projede yeni bir teknoloji ile uğraşılıyorsa, bir süre sonra öğrenmeyi öğrenir, ve yeni teknolojileri daha süratli bir şekilde yutabilmeye başlar.
Tabii herkesin öğrenmesinin bir sınırı vardır; bu yüzden en çok değişik teknoloji ile haşır neşir olmuş danışmanın bile bir 'favori' teknoloji demeti mevcuttur. Bu demet, ne kadar sektörde kanıtlanmış ve geleceği olan teknolojilerden ise, o kadar iyidir, çünkü bu daha kalıcı olacak ve öğrenildiği zaman danışmanı daha değerli halde en uzun süre tutacak bilgiler toplamıdır. Bu yüzden danışman programcıların kafasından, kişisel bazda, sürekli olarak hangi teknolojiler yeşeriyor, hangisinin geleceği var sorusu mevcuttur. Mesela daha kariyerinin en başında, en büyük yol ayırımı yapılır; Microsoft'mu, Unix'mi sorusuna cevap verilir. Amerika'da çoğu danışman bu soruya Unix cevabını vermişlerdir. Her iki yol da, ötekinden çok ayrı uzmanlık gerektirdiğinden, bu seçim çok önemlidir ve genelde bir programcı (bazen danışman şirketleri de) bu iki yoldan sadece birinde uzmanlaşır.
Burada, sabit zaman/fiyatlı proje usulü çalışan danışman şirketlerinden bahsetmemiz gerekecek. Extreme programcılık hakkındaki yazılarımızda bu şirketlerden biraz bahsetmiştik. Şimdi, sabit modelin satış sürecine getirdiği gerginlikten bahsetmemiz gerekecek.
Netice itibarı ile, danışman şirketin elindeki tek kaynak insandır. Ortada ürün, arazi, gibi demirbaşlar mevcut değildir. Patent yoktur. Bu yüzden satış sürecinde de, satış görevlisinin elinde bir insana dolaylı öteki dolaysız bağlı olan iki sübap vardır. Fiyat ve Zaman.
Bu iki faktör haricinde, mesela Kod kalitesi satış süreci sırasında pek göz önüne alınmaz. Demek ki, satışı kapabilmek için, müşteriye "daha hızlı" ve/veya "daha ucuz" proje satabilmek önemlidir. Eğer danışman şirket 'aç', projeye (yani paraya) muhtaç ise, satış görevlisi bu indirimi yapmak için büyük bir istek duyacaktır.
Potensiyel bir problem işte burada ortaya çıkmaktadır, çünkü satış görevlisi genellikle teknik adam değildir. Bu sebeple yaptıği bu seçimin perde arkasındaki programcılar üzerine getireceği yükten habersiz olabilir. 90'lı yıllarda bu birçok kez olmuş bir vakâdır, faturayı ne yazık ki haftada 70 saat çalışmak zorunda kalan programcılar ödemiştir. CTP, Sapient gibi şirketlerin çalışma durumu 90'lı yıllarda bundan ibaretti. Bu şirketlerdeki programcıların yaş ortalamasınında 30'dan aşağı olması tabii ki raslantı değildir, belli bir yaştan sonra bu tür bir tempoyu kaldırmak zor olmaktadır.
Özetle, öğrenek için iyi bir ortam oluşturan danışman şirketler, tempo olarak hızlı, ve sabit bazda çalıştıkları zaman gerginlik yaratan ortam oluştururlar.
Tabii başka yazıda bahsettiğimiz gibi, eğer danışman şirket belli bir ürün demeti üzerinde uzmanlayı (odaklanmayı) başarır ise, o zaman daha az zamanlı ve fiyatlı proje satmayı başarabilir, ve programcıyı daha az öğütür.
Gönderen Burak Bayramli zaman: 12:45 PM 1 yorum
Dokümandaki yazitipini degistirmek için <FONT> tagi kullanilir, genel kullanimi söyledir:
SIZE degiskeni metnin büyüklügünü ayarlar, bu degiskene -1, +2 gibi degerler verilerek metnin puntosunun bir eksiltilmesini veya iki arttirilmasini saglayabilir, direkt olarak bir rakam vererek puntoyu tayin edebilirsiniz. HTML sayfalarinda SIZE degiskenine verebileceginiz en büyük deger 5'tir. 5'ten sonra vereceginiz her deger siz 5 degeri vermissiniz gibi muamele görecektir. Yazitipi çok büyük olmamalidir, büyük yazitipleri hem kullanicilarin sayfayi okumasini zorlastirir hem de sayfanin güzelligini bozar.
FACE takisini tüm web tarayicilari desteklemese de bu taki kullanilarak sayfada resim kullanmadan oldukça güzel görüntüler elde edilebilir. Örnegin FACE="Arial Tur" takisi kullanildiginda yazi tipi Türkçe Arial olacaktir. FACE degerine Türkçe destegi olmayan "Comic Sans Ms" gibi yazitipleri verilmemelidir, verilirse bazi Türkçe karakterler bozuk olarak görülecektir.
Son olarak COLOR takisi yazitipinin rengini ayarlamakta kullanilmaktadir. Web tarayicilarinin destekledigi temel renklerden olusan tablo geçen ay bu bölümde verilmistir. Tablodan dilediginiz bir rengi seçerek bu degiskenin karsisina yazdiginizda yazitipi rengi degisecektir.
<FONT> ifadesi her zaman bir </FONT> ile sonlanmalidir. Bu tag unutulursa web tarayiciniz sayfalari yanlis görüntüleyebilir. (Bazen de hiç görüntülemez)
Solaris işletim sistemi, süreçlerinizin (process) performansını takip edebilmeniz için bazı ek araçlar sağlamaktadır. Bu yazıda gösterilen bütün komutlar izledikleri süreçlere başlangıçta çok az ek bir ek yük getirirler, o yüzden canlı bir sistem üzerinde, özellikle tekrar eden bir şekilde kullanılmaları uygun olmayabilir. UNIX man proc sayfasından bu ve öteki komutlar hakkında daha fazla bilgi edinebilirsiniz.
Problem araştırme ve inceleme için aşağıdaki programlar yararlı olacaktır.
CPU kullanım yüzdesine (utilization) göre ps çıktısı almak (en cok kullanıma sahip olan en altta olmak üzere) için kullanilan ps komutudur. Bu komut bizi ayrı ayrı ps ve top kullanmaktan kurtaracaktır.
Bu komut size Java sürecinizin içindeki lwp yığıtını gösterir. Her Java Thread'i koşmaya başlamadan önce bir lwp'ye (hafif süreç/lightweight process) bağlanmak zorundadır, ve bu komutu ile hangi Thread'in hangi sistem çağrısı üzerinde beklediğini raporda görebilirsiniz. Bütün Thread'leri bir soketten okumada, ya da bir yerel çağırım üzerinden JDBC sürücünüzü beklediğini görebilirsiniz. Bâzen bu gibi bir bilgi yeterli olmayabilir, çünkü hangi Thread'in hangi soket no'sunu beklediğini bu araç göstermez.
Bu komut hangi yerel kodun (native code) JVM'inize yüklenmiş olduğunu göstermesi açısından yararlıdır. Komut, hangi .so dosyasının JVM sürecine dinamik link edilmiş olduğunu göstererek çalışır.
Bu komut, her süreç içindeki her lwp'nin işaretlerini (flags) ve bekleme durumunu (wait state) rapor eder. Bu komutu kaç tane thread context değtirimi (switch) olduğunu anlamak için kullanabilirsiniz. Eğer her JVM için birden fazla CPU var ise, context değiştirimi büyük bir ihtimalle yüksek sayıda olacaktır.
Pfiles, herhangi bir sürecin açık tuttuğu dosyaları gösterir, böylece dosyaların kapanmaması ile alakalı olan problemleri takip etmenize yarar.
Bir Unix sürecinin açık tuttuğu dosyaları görmek için lsof'u kullanabilirsiniz. lsof, pfiles'a benzer, fakat daha yararlı bir çıktı verir. Daha fazla bilgi için lsof'u şurada ziyaret edebilirsiniz.
truss -c -p
Bu komut, bir sürece karşı başlatılması ve kesilmesi (interrupt) arasında süreç tarafından yapılmış olan sistem çâğrılarını rapor eder. Örnek:
[root@balina /]# ps
11218 pts/5    0:00 ps
11211 pts/5    0:00 bash
[root@balina /]# truss -c -p 11211
^C  <<---------------- burada kesilme oldu  syscall               seconds   calls  errors                     --------  ------   ---- sys totals:              .000       0      0 usr time:                .000 elapsed:                3.750
* Yazının aslı
Gönderen Burak Bayramli zaman: 12:43 PM 0 yorum
Bu yazımızda, Extreme Programcılığın danışmanlık, teknoloji seçimi, takım idaresi gibi açılardan ele alacağız. Gördüğümüz kadarı ile işletimde (execution) çok yerinde tespitler yapan ve kurallar koyan XP'nin, her seviyede doğru anlaşılması için böyle bir anlatımın yapılması iyi olacak.
Satırların yazarının dahil olduğu danışman şirketleri, proje bazında çalışan, sabit zamanlı/sabit bitiş kodlama süreleri koyan ve sabit ücret alan şirketler idi. Bu tür şirketler, hem kendi açılarından tahmin edilebilirlik (ne kadar kazanırız?), personel idaresi (ne kadar kodcu lazım) gibi sorulara kesin cevaplar bulabildikleri için, herşeyi sabit olarak yapmayı seçmişlerdi.
Fakat yazılım projelerinin ne kadar tahmin edilmez olduğu ortaya çıkmaya başlayınca, beton dökerek çizilmiş Microsoft Proje Gantt grafikleri durumu saptırmaya başladı. Bu duruma çözüm olarak şirketler değişik teknikler getirmeye uğraştılar.
Bazıları, programcılara baskı yaparak stres ortamı altında verim almaya çalıştılar. Ya da, birkaç teknoloji üzerinde yoğunlaşarak tahmin edilebilirliği geri kazanmaya çalıştılar.
Bu çözümlerden ikisi de başarasızlığa uğradı. Hatta ilk çözüm kısa vadede bile çökmüştür. Ekonominin iyi olduğu ortamda, programcılar çabuk yer değiştirebilen insanlar oldukları için, stres yerine daha iyi idarecilerin olduğu şirketlere geçiş yapmayı tercih ettiler, ya da, stres altında yaratıcılık yeşermediğinden, kod kalitesinde düşüş yaşandı. Hâtta baskı ile programcıları geç saatlere kadar çalıştırmaya çabalayan danışman şirketler, gene aynı şekilde kod kalitesi açısından kayıp yaşamışlardır.
Geç çalıştırma danışman şirketlerde 80 ve 90 yıllarında öyle yaygındı ki, genelde danışman şirketlerinde akşam 7'da işte çikmak, "erken" çıkmak olarak adlediliyordu. XP, ismine "programcılık" kelimesini özellikle katmıştır, çünkü amaçlarından biri programcının bu şekilde sakız gibi çiğnenip atılmasını engellemektir.
Kural: Programcılar yanlız ve yanlız normal iş saatleri içinde program yazarlar.
İkinci potansiyel çözüm, şu şekilde duvara tosladı. Moore kanuna göre mikroişlemci hızları her 19 ayda ikiye katlandığına göre, mesela artık sürekli derlenmek yerine "yorumlanan" bir dil olarak Java'nın bilişim sahnesine birden çıkıvermesi mümkün olabiliyordu. Bunun gibi ele geçen donanım hızını aç bir şekilde hemen kullanabilen, tabii ki programcıların üretkenliğini arttıran ama arkası kesilmeyen yeni teknolojiler, yararlı olsalarda, yanlarında şu etkiyi getirmişlerdir: Artık programcıların kendini sürekli yenilenmesi, yeni şeyler öğrenmesi gerekiyordu.
Bu yüzden ikinci çözümdeki belirtilen değişmeyen, tek bir teknolojide uzman şirket/takım tipi de tarihe karışacaktı. XP, akıllıca bir yöntem ile tahmin edilmezlik sorununu çözmemiş, sonunu açık bırakarak zamana yaymıştır. XP ile tahmin edilebilirliği önümüzde gelmekte olan tek bir dönem ile sınırlıyoruz.
Sonuç olarak, XP ile yeni teknolojiler ile oynayan, değişimi seven ve bakleyen bir yapıya kavuşacaksınız. Yeni teknoloji ile oynamanın kuralları şunlar.
Teknolojiyi deneyecebileceğiniz bir "smaç zamanı" ayırın. (XP İngilizce belgeleri bu döneme "spike" adını verir). Dönem içinde smaç yapmak için bile bir özellik (kart) yazın, ve tahmin zamanını üstüne yazarak döneme katın. Böylelikle müşteri önem sırasına göre bazı smaçları bazı özellikler için "feda" edebilir. Her dönem içinde ne kadar smaç, ne kadar gerçek özellik kodlanacağı görülecektir.
XP'nin yazılımı gerçekleştiren dönemlerde ne kadar yararlı olduğunu biliyoruz. Fakat bu, stratejik türden danışmanlık yapmadan birkaç paket programı sunarak hemen koda atlayalım demek değildir.
Stratejik danışmanlık yapmak için mutlaka zaman ayırın. Mesela birkaç aylık, proje başlamadan önceki bir dönem içinde, yeni bilgi işlem sisteminin stratejik vizyonu ortaya konmalıdır. Ana teknolojiler kararlaştırılmalıdır. Unutmayın, en kötü plan bile, plansızlıktan iyidir.
Bu seviyede istediğiniz kadar belge/çizelge yaratabilirsiniz. Zaten müşteriniz de bu tür şeyleri görmek isteyecektir. Kodlama başladıktan sonra tabii ki durum değişecek, "programı kodlarken aynı zamanda belgeleyin" diyen olursa, XP'nin kod belgelenmesine yasak koyduğunu belirtin. XP, belge değil, kaliteli kod üreten bir sistemdir. Kodu anlamak isteyen, birim ve kabul testlerine bakabilir.
Stratejik danışmanlık zamanına dönecek olursak, bu seviyede üst kademe teknik liderlerinizi toplantılara katmanız uygun olacabilir. Müşteriniz, teknoloji neleri yapabilir, neleri yapamaz açısından beklentilerini dengelemek açısından bu davranış yararlı olacaktır.
Not: "Beklentilerini dengelemek" kelimesi, bir sabit bitiş çizgili refleks ile çıkmış olsa da, yazıda tutmaya karar verildi, çünkü eski/yeni düşünce farkları göstermesi açısından yararlı olabilir. Klasik projelerde, müşteri sabit parayı ödedikten sonra, sürekli bir danışman/müşteri sürtüşmesi yaşanır. Aynı para ile daha fazla şey isteyen müşteri, bir yandan teknoloji hakkında hayaller de kurmaya başlayınca, danışmanlar toplu bir "hayır" korosuna dönüşebilirler. Yukarıdaki "dengeleme" sözcüğü de bu zamandan miras kalmıştır, fakat yazıda tutulacaktır.
Yani, stratejik dönemde ve sonrasında hem dengeleyin, hem de müşterinizin "ufuklarını" açın.
Gönderen Burak Bayramli zaman: 12:36 PM 0 yorum
Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.
eriş. (Tahmin: 0.5 gün)
işlem bitir. (Tahmin: 0.5 gün).
Sığmak, sığdırmak terimleri bağlamında bir noktayı vurgulamak gerekiyor. Bir dönemin ne kadar büyük olduğu nasıl bulunur? Yani kabımızın büyüklüğü nedir? İlk birkaç dönem için, takım lideri tahmin bir büyüklük ile başlayabilir.. Bir dönem (iteration) büyüklüğü olarak 2 hafta farzederek başlayalım. Takımımızda 5 programcımız var ise de, bu programcıların haftanın 5 çalışma günü içinde 3 ideal günlük iş yaptığını farzedelim; o zaman kap büyüklüğü 3 ideal gün x 5 programcı x 2 hafta = 30 ideal gün olacaktır. Yani kabımızın büyüklüğü 30 gündür.
Bu yapılan "tahminler", XP'nin gevşek bir yöntem olduğu intibası vermemelidir. Esasında, bir kere kap büyüklüğü hesaplandıktan sonra, hangi özellik sığdırma işlemi çok katı bir şekilde takip edilecektir.
Tahminlerin nasıl yapıldığına gelelim: İlk faraziye, 2 haftalık bir dönem koyulması, ikincisi ise programcının bir hafta içinde kaç ideal gün çalışabildiğidir. 2 haftalık dönemi seçerken, diğer XP projelerinin tecrübelerinden yararlanabilirsiniz. Projenizin ritmini ne kadar kısa aralıklarla böleceğinize karar verin. 1 hafta çok kısa olabilir, 4 hafta da çok uzun. Seçim size kalmış, ama dönem uzunluğunu birinden ötekine sürekli değiştirmeyin.
İkinci tahmin hakkında: Projede ilerledikçe ve her özelliğin 'gerçek zamanı'ölçüldükçe, dönemlerin içine sığacak ideal gün sayısını bulabilirsiniz. Böylece bir sonraki döneme özellik koyarken, önceki dönemin büyüklüğüne göre listeye almaya başlarız, vs.. Ve böylece projemiz ilerledikçe, takımınız tahmin yeteneği de ilerleyecek, bu tahmin/gerçek sayıları birbirine iyice yaklaşacaktır.
Gönderen Burak Bayramli zaman: 12:35 PM 0 yorum
XP yönteminin tamamen özellik kontrollü (function oriented) bir sistem olduğu herhalde açık. Bu açıdan, proje başında 3-4 aylık tasarım yapan ve bir torba belge üreten yöntemlerden XP ayrılıyor. XP projelerinde, 'mimari bitti mi?', 'tasarım belgesi hazır mı?' soruları yerine, 'özellik bitti mi?' sorusunu duyarsınız. Zaten bir projede kullanıcı, o proje için mevkisini riske eden üst düzey yönetici için önemli olan da budur. Özellik.
Bu yüzden, özellik olarak kartların üzerine yazılan şeylerin, hakikaten özellik olması çok önemlidir. Bitme/bitmeme mefru 'özellik' olduğu için, eğer özellik olmayan bir şey kart üzerine yazılmış ise, kargaşa yaratacaktır. Mesela:
E-posta gönderecek bir Java yardımcı nesnesi yaz.
- Nesneyi yaz (Tahmin: 1 gün)
Bu yanlış bir özelliktir. Her şeyden önce, bu özelliğin müşteri tarafından konulduğu şüphelidir, zaten müşteri nesne filan bilmez. Büyük bir ihtimalle programcının 'lazım olur, koyalım' diyerek koyduğu bir 'özelliktir' bu.
Bu sözde özellik tipik bir mimari kodlamanın, özellik kartı olarak araya kaynaması durumudur. Özellikle vurgulamak gerekir ki, XP mimariyi sadece bir özelliğe gerek olduğu kadar yazar. Öyle her özelliğe lazım olacağını tahmin ettiğimiz bir 'mimari nesneyi' baştan, ve o mimariyi kullanacak özellik daha ortada bile olmadan kodlayamayız.
Yukarıdaki örnekte, ortak bir e-posta gönderen yardımcı 'kütüphane' kodu vardır, fakat bu kodu hangi özellik kullanacaktır? Nasıl kullacaktır? Ne kadar iyi tahmin yeteneğiniz olursa olsun, bir özelliğin bu yardımcı nesneyi gerçekten kullaması gerektiğinde, ilk arayüz tasarımınızda boşluklar bulacaksınız. Tabii ki siz çok tecrübeli programcısınız, tabii ki 8 programlama dili biliyorsunuz, fakat konumuz bu değildir.
Konumuz, niye gereksiz bir şey hakkında, efor sarfedeceğimizdir.
Ayrıca, üstteki gibi bir sözde özelliğin bitip bitmeme kriteri tanımsızdır. Zaten en iyi turnusol testi de budur. Müşteriniz bu şekilde bir özelliği test edemiyor ise, biliniz ki mimari bir işlem aradan kaynadı.
Daha iyi bir özellik şöyle olabilirdi.
Kullanıcı, banka transferi yaptıktan sonra ona e-posta gönderilir.
- JSP (görsel) kod içine e-posta tetikleyici kod yerleştir. (Tahmin: 0.5 gün)
- E-posta gönderecek nesneyi yaz (Tahmin: 1 gün)
Her ikili takım kendine ait kartlardaki geliştirme kalemlerini teker teker kodlamaya başlar. Her geliştirme kalemi bitince, bu kalemin 'gerçekte' ne kadar zaman aldığını ikili takım not etmelidir. Çünkü bu ölçü, baştaki tahminlerinizin ne kadar doğru olduğunu kontrol için önemli bir sayıdır. Takım lideri olarak siz, bu rakamın tahmine ne kadar uyup uymadığına takımınıza hiçbir sitem, alay, iğneleme yapmamalısınız. XP, programcıya tamamen 'güvenen' bir ortamda olmalıdır. Çıkış amacı ve temeli bunun üzerine kuruludur.
Gerçek zaman not edildikten sonra özellik, şöyle gözükebilir.
- Görsel arayüzü JSP/HTML ile kodla. (Tahmin: 1 gün, Gerçek: 1 gün)
eriş. (Tahmin: 0.5 gün, Gerçek: 1 gün)
işlem bitir. (Tahmin: 0.5 gün, Gerçek: 0.5 gün)
Her kartın kodlaması bittikten sonra, ikili takım müşteriye giderek özelliği 'kabul testinden' geçirmesini ister (acceptance test). Kabul testi, şöyle olabilir.
- Sisteme şifre ile gir.
- Transferi başlatacağı hesabı seç. Hesapta 2,000 olduğunu kontrol et.
- Transferin yapılacağı hedef hesap nosunu seç.
- Hesap miktarı 1,000 TL gir.
- Mevcut para miktarı 1,000'e düştü mü?
- Evet ise, test geçti
- Hesap miktarı 3,000 TL gir.
- Hata mesajı geldi mi? (çünkü mevcut hesap miktari 2,000 idi)
Bu kabul testi ideal olarak, planlama toplantısından önce hazırlanırsa iyi olur. Çünkü bu şekilde hazır olan bir kabul testi, o özelliği tarif eden 'en iyi' şekildir. Çok katı bir şartlar oluşturduğu için, programcılar için özellik kodlamasının ne zaman bitmiş olduğunu anlamak bakımından, kabul testleri onlara yararlı olacaktır.
Fakat kabul testi yok ise, müşteri özelliği aklında kaldığı kadarı ile testten geçirecektir.
Kabul testleri için güzel bir yöntem, birim testler gibi, otomatik şekilde çalıştırılabilen kabul testleri olabilir. Java Swing için yazılmış olan bir kabul test altyapısını sitemizden paylaşmıştık. Swing tıklayıcı alyapısı, XML ile tanımlanan kabul testlerini, otomatik şekilde tıklayarak sonuçlari e-posta ile bildirebiliyordu.
Bu şekilde bir sistem başta çok zahmetli ise, metin şeklinde yazılı testler yeterli olacaktır.
Müşteri özelliği kabul ettikten sonra, kart biten kartlar kefesine konur, ikili takım dağılır ve başka bir ikili takım altında başka bir kartı kodlamaya başlarlar.
Kabul testleri özellik seviyesinde olan şeyler ise, birim testleri nesne (kod) seviyesindeki testlerdir diyebiliriz. Birim testler, banka hesabından 1,000 TL düşülüp düşülmediğini kontrol eden bir kod parçası olabilir. Banka nesnesi üzerinde hesaptanDüş() işlevini test eden, birim testidir.
Fakat yukarıdaki 'kabul testinde aynı şekilde bir test görmüştük. Demek ki bazı durumlarda, kabul testleri ile birim testleri arasındaki çizgi bulanıklaşabiliyor. Yani, eğer elimizde 10-15 diğer işlevi çağıran bir işlem mevcut ise, ve bu işlevi birim test ile çağıriyor isek, bu test birim testinden ziyade bir kabul testine benzemeye başlayabilir. Bu gibi şartlarda hangi testi kullanacağınız size kalmış. Fakat prensip olarak birim testlerini tek bir işlem ve ufak bir ölçüde yapmaya gayret edin.
Gönderen Burak Bayramli zaman: 12:34 PM 0 yorum
DYNSRC tag'ini daha önce duymus muydunuz? Bu takiyi kullanarak asli görevi resim olmak olan bir görüntüyü üzerine gidildiginde veya yüklendikten hemen sonra görülen bir videoya çevirebilirsiniz.
<IMG... komutuyla kullanilan ve sadece Internet Explorer Web tarayicisinda Ã§alisan bu Ã¶zellik videolari oynatmanin gÃ¼zel bir yoludur. Sadece Internet Explorer'in bir Ã¶zelligi oldugundan <EMBED SRC..> komutu kadar ragbet görmeyen bu komut kullaniciyi videonun yüklenmesini beklerken oyalamakta kullanilabilir. Küçük AVI dosyalari kullanarak resmin üzerine gidildiginde kullaniciyi etkilemek yine bu yolla çok kolaydir.
Komutun kullanimi söyledir: <IMG SRC="DENEME.GIF" DYNSRC="DENEME.AVI" START= FILEOPEN| MOUSEOVER>
FILEOPEN Video yüklenen kadar resmi görüntüler, sonra video'yu oynatir. Varsayilan deger budur. MOUSEOVER Kullanici farenin imlecini resim üzerine götürdügünde video'yu baslatir.
Frame'lerden olusan nefis bir sayfa yaptiniz ve sol taraftaki frame'i navigasyon için sag taraftaki frame'i ise içerigi görüntülemek için kullaniyorsunuz. Daha önce <A HREF=.. komutuna target="hedef" gibi bir ek vererek ilgili sayfanin hangi frame'de aÃ§ilacagini tayin edebileceginizi sÃ¶ylemistik. Eger sol taraftaki frame'inizde Ã§ok fazla <A HREF=.. takisi varsa <BASE TARGET.. komutunu kullanmayi düsünebilirsiniz.
<base target="sagtaraf"> <a suraya="sayfa1.htm">Hakkimda</a> <a suraya="sayfa1.htm">Resimlerim</a> <a suraya="sayfa1.htm">Faydali</a>
Yukaridaki gibi kodlar kullandiginizda bu kodlari koydugunuz sayfadaki her bir link sag taraftaki frame sayfasinda açilacaktir.
Web sayfanizda içinde özel bir karakter bulunmayan matematiksel bir fonksiyon kullanmak istiyorsunuz diyelim. Ya da özel bir marka kullaniyor ve TM (c) ifadelerini bu özel markanin sag üst kösesine yerlestirmek istiyorsunuz. HTML dili tüm web tarayicilarinin destekledigi bu islemi gerçeklestirmeniz için size iki adet özel taki sunuyor.
Ingilizce uzatmalari Superscript ve SubScript olan bu iki takiyi kullanarak özel metinlerin, normal metnin yari uzunlugu kadar asagisinda veya yukarisinda olmasini saglayabilirsiniz. Bir metni normal metnin üstüne almak için <SUP> ifadesi ile baslamali metnin bitiminde ise </SUP> ifadesini kullanmalisiniz. Ayni sekilde metnin asagida yaralamasini istiyorsaniz <SUB> takisini kullanin.
Gönderen Burak Bayramli zaman: 12:23 PM 0 yorum