Wednesday, November 1, 2000

Yazılım Şirket Çeşitleri

Bu yazımızda, yazılım üreten şirketlerin hangi kategorileri oluşturduğunu, bu kategorilerin tarihini birkaç örnek ile göstermeye çalışacağız. Kategorilerden birisi olan "ürün şirketi", rahatça bilinen ve tasvir edilen bir şirket olsa da, öteki şirket türü, danışman şirketi, yaygın olarak bilinmeyen yazılım şirketleridir. Yazının bilgilendirici olacağını umuyorum.

Ürün şirketi ile başlayalım.

Ürün şirketleri

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.

Danışman Şirketler

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.

Önce tarih.

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.

Bu açığı kapatmak için danışman şirketler, ek bir servis olarak yazılım danışmanlığını da dağarcıklarına ekleyerek yelpazelerini genişletmişlerdir.

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.

Satış

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.

HTML ve Yazitipleri

Dokümandaki yazitipini degistirmek için <FONT> tagi kullanilir, genel kullanimi söyledir:

<FONT SIZE="x" FACE="[isim] COLOR="#XXXXXX">

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)

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Yararlı Solaris Araçları

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.

ps -eo pid,pcpu,args | sort +1n

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.

/usr/proc/bin/pstack

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.

/usr/proc/bin/pldd

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.

/usr/proc/bin/pflags

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.

/usr/proc/bin/pfiles

Pfiles, herhangi bir sürecin açık tuttuğu dosyaları gösterir, böylece dosyaların kapanmaması ile alakalı olan problemleri takip etmenize yarar.

lsof

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

PID TTY TIME CMD
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

Kaynaklar

* Yazının aslı

XP ve Danışmanlık

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.

Yeni Teknolojiler

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.

Stratejik Boyut

Danışman şirketler!

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.

XP Tarihi

Extreme programcılık, 'önce uzun uzun tasarlama, sonra kodlarsın' fikrinin projelerde başarısız olması ile şekillenmeye başladı. Arkasındaki ilgi, özellikle .com yıllarında daha artmıştır. Bunda, .com projelerinin zorluk ve zamanlama açısından yazılım takımlarına daha büyük yük getirmesi muhakkak rol oynadı. .Com devrinde herkes, piyasaya bir an evvel çıkabilmek için, programcılara ve danışman şirketlere büyük baskılar uygularken, bu baskıların sonucunda, bitirilmesi için 10-11 ay gerektiren proje idare yöntemleri tabii ki 'çatlamaya' başladı.

Eski yöntemler yerine yeni bir yöntem bulmak gerekiyordu, ve XP bu boşluğu doldurdu.

XP'nin bir ayrı doğuş noktası, Kent Beck'in müşteri ve programcı gurupları arasında çok katı çizgiler çizmek istemesidir. Kent, bu iki gurubun birbirinin işlerine karışan ve sonuçta projenin seyrine köstek olan davranışlarını kaldırıp, yerine herkesin kendi işini gördüğü, ve kimsenin kimseye stres yaratıp, baskı uygulayamayacağı bir ortam yaratmak istedi. Çünkü projeyi bitirip/bitirmemek bir yana, Kent programcıların mutsuz ve motivasyon eksikliği yaşadığını farketti, ve altta yatan bityeniğini bularak çözümü sağladı.

Müşteri/programcı çizgileri çizilince, müşteri projenin nereye gideceğinin yegane sorumlusu oluyor, fakat aynı zamanda, hiçbir şekilde programcıya 'şu işi daha hızlı yap' deme hakkına erişemiyordu. XP, her dönemde işin ne kadar hızlı yapıldığını ölçerek, sonraki dönemler için ne kadar iş planlanacağını tahmin etmeye uğraştı. Bir kere tahmin yapıldıktan sonra müşteri, özellik listesini ona göre çıkarıyor, ve sonra 'müşteriliğini bilerek' daha fazla projeye karışmıyordu. Çünkü programcılık teknik bir olay idi, ve özelliklerin ne kadar hızlı yazılıp yazılmayacağı teknik dünyaya ait bir karardı.

Ayrıca, XP'nin teknik kodlama süreci/yöntemleri alanında da hayati tavsiyeler getirdiğini görüyoruz. Kent, anlattıgı bir hikayede, rastladığı bir programcının öteki arkadaşlarına sürekli fark attığını gözlediğini söyler. Bu farkın altında, programcının her yazdığı 3 satıra takabül 1 satır da birim testi yazdığını farkedince Kent, bu yönteme daha dikkatle bakmaya başladı. Genelde programcıyı yavaşlatılacağı düşünülen test yazmak eylemi, uzun vadede test eden programcının lehinde büyük farklar doğuruyordu. Çünkü test yazan programcı, kodunu daha cesurca değiştirebiliyor, ve mimari değişiklikleri bile gözünü kırpmadan yapabiliyordu. Öyle ya, eğer mimari değişikliği yaparken bir hata eklenmiş olsa, derlemeden sonra sürekli işletilen birim testleri, bu yanlışı anında yakalayıyordu!

Ve Kent, bu tekniği de XP dağarcığına kattı.

Mekan

Her hikayeye bir mekan gerekir. XP'nin mekanı, C2 projesi denen General Motors şirketinin bordro kontrol projesidir.

Bu proje, mimari olarak duvara tosladıktan sonra, projede olan Kent, uzun süredir planlamakta XP'yi deneme vaktinin geldiğini anladı. General Motor şirketi yönetiminden izin istedi, ve kolları sıvadı.

Kent ilk önce, en büyük sorun olarak gördüğü iletişim sorununu çözdü. Programcılar ayrı odalarda, ya da aynı odada olsalar bile aralarında plastik duvarlarla ayrıli 'hücrelerde' iş yapmaya uğraşıyorlardı, ve tabii ki iletişim kurmak zor oluyordu. Yazılım projelerinde herkesin bildiği bir vaka şudur: Yanınında olmakta olan bir konuşma, sizin için önemli bilgiler içerir, kulak kabartırsınız, ve gerekli ise konuşmaya katılırsınız. Bu gibi bilgi paylaşımı için hücre sistemi ölüm demekti. Ya da, herhangi birine bir soru sormak isteseseniz, ama soru sormak istediğiniz kişi 50 metre ötede olsa, soruyu sormak için ne kadar zahmete katlanacaksınız? Kafanızı kaldırıp azıcık sesli olarak arkadaşınıza bu soruyu sormak daha iyi olmaz mıydı?

Ufak gibi gözüken bu tip şeyler, çok hızlı gerçekleşen yazılım projeleri için önemli faktörlerdi. Yazılımda, bilinen türden hammadde ve sanayii yoktur, herşey düşünce ve iletişim bağlamında gerçekleşir. Bu yüzden tek bir soru soramamak, hatalı bir kod ile hatasız arasındaki farkı belirleyebilir.

Bunu farkeden Kent, hemen herkesi aynı odada topladı, ve hücre duvarlarını kaldırdı.

Bir sonraki değişiklik, sürekli tümleştirme denen teknik akabinde meydana geldi. Kent, genelde XP yöntemini şöyle tarif eder. "İyi olduğu bilinen yazılım tekniklerinin sesini, sonuna kadar açmak".

Gereksiz bir ifade gibi gelebilir, fakat örneklerle daha berraklaştırmaya çalışalım. Herkesin bildiği programcılık teknikleri arasında, bütün proje kodunu derleyerek, tümleştirmek (entegrasyon) ve testlerden geçirmek gelir. Yani, eğer programımızın kullandıği arayüzleri doğru kullanıp kullanmadığımızı anlamak istiyorsak, bütün kodu beraber derleriz, ve testlerden geçiririz.

Bu işlemi yapmak 'iyi' bir teknik olarak bilinir. Eğer iyi ise, niye her zaman yapmıyoruz? Kent, tümleştirme işini bir otomatik programa bağlayarak, bu programın her yarım saatte bir bütün kodu otomatik derleyerek sonuçlarını projeye e-posta ile bildirsini sağladı.

Bunun sonuçları tabii ki devrim oldu. Artık, eğer kaynak kod idare (KKİ) sistemine yanlış, hatalı, yanlış tümleşen bir kod parçası eklenmiş ise, otomatik derleyici bunu en az yarım saat içinde yakalayabiliyordu. Hata e-posta ile alındığında, proje takımı o anda yaptığı işi bırakıp, tamamen o hatayı düzeltmek ile uğrâşacaklardı.

Böylece, tümleşme hataları taa sonuç ortamına aktarıldıktan sonra değil, hata olduktan 30 dakika sonra yakalanıyordu.

Bir başka örnek kod kontrol sırasında oldu. Arada sırada başkasının kodunu kontrolden geçirmemiz, ve stil, teknik olarak bulduğumuz düzeltmeleri arkadaşımıza bildirmemiz de 'iyi' bir teknik olarak bilinir.

Fakat normal projelerde bu teknik, genelde takım liderinin insiyatifi ile başlatılır, ve bir odaya doluşulur, yazıcıdan basılmış koda herkes bakar, ve fikirlerini söyler, sonra herkes odasına döner düzeltmeler yapılır.

Kent şöyle dedi: 'Bu iyi bir teknik ise, niye her zaman yapmıyoruz?'.

Sürekli kod kontrolu yapabilmenin en iyi yolu olarak, tek kişinin kod yazması yerine bir başkasının sonradan kontrolü yerine, iki kişinin aynı anda kodlama yapması, ve sürekli birbirlerini kontrol etmesi fikrine erişti.

Bu yaklaşım da yazılım projelerinde bir devrim oldu.

XP Planlaması

XP kullanmaya karar verdiniz, ve proje lideri, programcı olarak nasıl işleme koyacağızı düşünüyorsunuz. Nereden başlayacağım sorusu aklımıza geliyor. İlk önce, kavram olarak 'iş süresi' ve 'zaman' terimlerini yerlerine koyalım.

XP'ye göre, bir proje dönemlere ayrılır (iteration). Bu dönemin uzunluğu, bir kere kararlaştırıldıktan sonra sabittir, değişmez. Mesela, sizin takımınız için 2 haftalık döneme karar kıldınız, bu şekilde başlayabilirsiniz. Her takım için bu dönem süresi değişik olabilir. Bu tamamen takımınızın ritmine bağlıdır. Unutmayın, daha hızlı takımlar daha ufak dönem seçer diye bir şey yoktur. Sadece, proje hayatınızı ne kadar ufak parçalara bölmek istediğiniz önemlidir. XP takımlarından alınan istatistiklere göre, genelde iki ya da üç haftalık dönemlerin tercih edildiğini görüyoruz.

Eğer dönem süreniz 2 hafta ise, demek ki 3 aylık olarak görülen bir projenin içine 6 dönem sığacak demektir. Tabii proje eğer 3 ayda bitmemiş ise, yeni dönemler ekleriz. Hemen belirtelim: XP'de sabit zamanlı, sabit bitiş çizgili proje yoktur. Eğer bu tür bir ortamda çalışıyorsanız, arkanıza bakmadan kaçabilirsiniz. Bu satırların yazarı dahil birçok kişi sabit bitiş çizgili projelerde yeterince kan ve ter kaybetmiştir. Eğer böyle bir kültür içindeyseniz, kültürü XP ile değiştirmeye uğraşın. Amerika'da bu tür götürülen projelerin yarısı başarısız olmuş, başarılı olanlarında kod kalitesi şüpheli bir seviyede olmuştur. Neyse..XP'ye dönelim;

Dönem süresi karar kılındıkta sonra, müşteriyi temsil edecek birini seçin. Bu müşteri temsilcisi, projeye hangi özelliklerin ekleneceğini, hangi özelliğin ötekinden önce yazılacağına karar veren kimse olacak. Bu tür kararlar, yazılıma talip şirket (yani programcıların müşterisi) için stratejik türden kararlar olduğu için, bu şahsın şirketini ve iş alanını çok iyi bilmesi yararlı olur. Yazının geri kalan kısmında, bu tek kişiyi 'müşteri' betimleyeceğiz.

Planlama dahilinde, müşterinizin istediği özellikleri bir liste olarak dökmesini isteyin. Siz olarak hitap ettiğim, XP takımının teknik lideri olan sizsiniz. Müşteri bu listeyi en önemliden en önemsize doğru sıraya dizmelidir. Bu özellikleri ya bir Excel hesap tablosu, ya da her özelliği tek bir kart üzerine yazılmak suretle kartlar kümesi olarak tutabilirsiniz. Hattâ, şirket içi İntranet üzerinden kullanılabilen XPlanner gibi bir program da yararlı olabilir.

Kartlar hazır olduktan sonra, bir takım toplantısı tertip edin. Bu toplantıyı, her dönem başında yapmanız lazım. Toplantıya müşteriniz ve bütün programcılar katılacak. Toplantı başında kartları masaya dizin, (ya da Xplanner'dan ekrana getirin) ve kartları en önemliden en önemsize doğru tartışmaya başlayın.

Müşterinin yapması gereken, her kartı alıp, takıma okumaktır. Bu özellik hakkında detaylı bilgiler de verilebilir.

Özellik tanımı bittikten sonra, programcılar kartı geliştirme kalemlerine bölmeye başlarlar.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Programcılar, geliştirme kalemlerine bölerken, müşteriden daha detaylı bilgi isteyebilirler. Bu iletişim çok iyidir. Ayrıca, programcılar kendi aralarında bu bölme işlemi olurken teknik konular hakkında tartışabilirler. Bu da yararlıdır. Sonuçta, mesela şu şekilde kalemler ortaya çıkabilir.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Geliştirme kalemleri:

- Görsel arayüzü JSP/HTML ile kodla.
- Kullanıcı hesap nosuna kullanıcı kimlik nosu ile veri tabanından
eriş.
- Aynı işlem (transaction) altında bir hesaptan al, öteki hesaba yaz,
işlem bitir.

Bütün kartları bu şekilde işlemden geçirdikten sonra müşterinin katıldığı kısım bitebilir.

Toplantı bittikten sonra, müşterinin katılması gerekmeyen kısma geçebilirsiniz. Bu kısımda, kartları kimin kodlayacağına karar verilir. Her karta iki kişili takımlar talip olur ve kartlar sahiplerine verilir. Bu safhadan sonra, ikili takımlar kartlarının geliştirme kalemlerini ne kadar zamanda kodlayabileceklerine karar verirler. Mesela yukarıdaki örnek:

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- Görsel arayüzü JSP/HTML ile kodla. (Tahmin: 1 gün).
- Kullanıcı hesap nosuna kullanıcı kimlik nosu ile veri tabanından
eriş. (Tahmin: 0.5 gün)
- Aynı işlem (transaction) altında bir hesaptan al, öteki hesaba yaz,
işlem bitir. (Tahmin: 0.5 gün).

Talip olma konusunda bir noktayı vurgulamak gerekir. Takım lideri olarak kimseye bir özelliği 'vermeyin'. İkili takımların/kişilerin bir karta 'talip' olmasını bekleyin. Bu nokta çok önemlidir. Eğer birine bir kartı veriyorsanız, emir/komuta zinciri işletmiş oluyorsunuz. Eğer programcı kendisi talip oluyor ise, kendi insiyatifi ile bu işe kalkışmış oluyor. Bu aradaki fark, ufak bir ruhbilimsel fark olarak gözükse bile, etkisi büyüktür. 'Bu özelliği kim kodlamak istiyor' diye sorduktan sonra bir 'sessizlik' durumu olabilir. Bekleyin. Mutlaka talip olan ikili çıkacaktır.

Toplantıdan sonra, geliştirme kalemlerini birbirine toplayın. Sonuç olarak, bütün özelliklerin bir döneme sığmayacağını bulabilirsiniz. O zaman döneme sığmayacak kartları, bir sonraki döneme bırakmanız gerekir. Hangi kartın sonraki döneme bırakılacağını müşteriye sorun. Özellik sırası, iş dünyasına ait bir karardır, teknik bir karar değildir. XP bu konuda çok hassastır, unutmayalım. Müşteri teknik karar alamaz, programcılar da iş hayatını ilgilendiren kararlar alamazlar.

En son kart listesi elinizde olduktan sonra, takımınıza hangi özelliklerin kodlanacağını artık bildirebilirsiniz.

Bir Dönem Ne Kadar Büyüktür?

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.

XP ve Özellikler

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:

Özellik:

E-posta gönderecek bir Java yardımcı nesnesi yaz.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- 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.

Özellik:

Kullanıcı, banka transferi yaptıktan sonra ona e-posta gönderilir.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- 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)

XP İşletimi

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.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

Programcılar:

Ahmet, Veli

Geliştirme kalemleri:

- Görsel arayüzü JSP/HTML ile kodla. (Tahmin: 1 gün, Gerçek: 1 gün)
- Kullanıcı hesap nosuna kullanıcı kimlik nosu ile veri tabanından
eriş. (Tahmin: 0.5 gün, Gerçek: 1 gün)
- Aynı işlem (transaction) altında bir hesaptan al, öteki hesaba yaz,
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.

Özellik:

Kullanıcı, banka hesapları arasında para transferi yapmak istiyor.

--Kabul Testleri--

Test 1:

- 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

Test 2:

- 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ı 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.

Birim Testleri

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.

XP ve İdeal Gün

XP projelerinde, en çok karışıklık yaratan kavramlardan biri budur. "Kartımızı (özelliği) kodladıktan sonra, gerçekte harcadığımız zamanı yazmamız isteniyor. Ben bu karta 2 gün önce başladım, demek ki 2 gündür kodluyorum. Karta, gerçek zaman: 2 gün yazabilir miyim?"

Hayır. XP, tahminler ve gerçek süreler konurken herşeyin 'ideal gün' olarak hesaplanmasını ister. Ideal gün denilen şey, dikkatinizi dağıtacak hiçbir şey olmasa, ve kodlamanızı yarıda kesecek durumlar olmasa, geçireceğiniz hayali bir gün birimidir.

Bir gün içinde sürekli bir takım etkinlikler/oylarlar vuku bulmaktadır. Mesela arkadaşımız ile konuşmakta, veya bir toplantıya katılmak gibi önemli bir şey ile uğraşmaktayız. Fakat XP burada çizgiyi çizerek diyor ki, "bu işlemlerin hiçbiri kodlamanın kendisi olmadığı için, ideal gün altında sayılmazlar. Bütün ölçümler, ideal gün ile yapılmalıdır".

Tahminlerin ve gerçek sayıların ideal gün olarak ölçülmesinin önemi, tahmin sayıları toplandıktan sonra, yönetim merci (müşteri ve teknik lider) kartlarını döneme paylaştırıken ortaya çıkar. Bu sırada şöyle konuşmalar olabilir.

"Geçen dönemde 20 (ideal) günlük kart kodlamışız. Demek ki, 5 programcı x 5 iş günü = 25 normal gün içinde 20 ideal günlük iş yapılabiliyor. Bu yüzden, bir dahaki döneme 25 günlük değil, 20 günlük iş koyuyoruz.

Ya da, şöyle bir sonuca varılabilir: "25 normal günlük dönem içinde, 10 ideal gün kodlama yapmışız. Bu oran biraz az mı? Acaba derleyiciler, bilgisayarlar mı yavaş? Acaba takıma programcı eklemek, hızımızı arttıracağı yerde, azalttı mı?", vs..

Veri Madenciliği

Videoya Donusen Resim

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.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Varsayilan Hedef

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.

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Üst Simage Ve Altsimge

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.

YAZININ<SUB>Altinda</SUB> YAZININ<SUP>�stünde</SUP>

Yazarin izni ile http://draskin.150m.com sitesinden alinmistir

Tuesday, October 31, 2000

Yeni Metod

Yakın zamanda "çevik metod" kategorisi altında yeni dizayn ve kodlama tekniklerine ilgi artmaya başladı. Bazıları tarafından bürokrasi-karşıtı, ya da dağınık kodlama olarak görülse de, bu yeni metod yazılım dünyasında büyük hareket yarattı. Bu yazıda hafif metodları uygulamanın sebeplerini sayacağım ve özellikle "değişebilir" özelliginden ve insanları ön plana almasına değineceğim. Ayrıca, eğer bu dar ve dikenli yoldan geçmek istiyorsanız, size hangi niyet ile yola çıkmanız daha iyidir, onu göstermeye uğraşacağım.

Yokluktan Cokluk, Sonra Hafiflik

Genelde yazılım, bir kargaşa durumudur. Kargaşa halinde yapılan bu yazılım şekline "önce kodla, sonra tamir edersin" derler. Böyle yazılımlar genelde plansız yapılır. Sistem dizaynı genelde kısa vadeli kararlar ile yapılmıştır. Bu şekilde yapılan geliştirme her ne kadar ufak sistem icin idare eder ise, sistem büyümeye başladıkça yeni özellikler eklemek çok zor hale gelir. Bu tür sistemlerin kokusunu uzaktan almak mümkündür: Ne zaman yazılıma özellik eklemesi bittikten sonra, test süreci, gereğinden fazla zaman alıyorsa bilin ki bu sistemin içinde yanlış çok, ve bilâhere dağınık bir şekilde kodlaması yapılmış.

Yazılım hayatımız boyunca uzun bir zaman, bu tip projeleri çok gördük ve hatta yaşadık. Alternatifimiz de yok değildi: Kontrollu Metodlar denen metodlar yazılım isine disiplin getirmeye uğraştılar bir süredir. Amaçları yazılım projelerini daha "tahmin edilir" ve "iyi işler" hale getirmek oldu. Bunu yapmak için yazılım projesine sıkı bir düzen takip ettirmeye uğraştılar, ve en büyük önemi de planlama safhasına takdim ettiler. Aslında gizli gizli öteki mühendislik alanlarına özendiler, mimarlık, inşaatçılık gibi.

Bu kontrollü metodlar bayağı uzun süredir aramızda. Başarılı oldukları söylenemez ve seveni de fazla yoktur. Bu metodlar hakkında en çok duydugumuz şikayet "bürokrasi fazlalığıdır", çünkü izlemek için o kadar çok ekstra faaliyet gerekiyor ki, proje birdenbire kağnı hızına düşüveriyor. O yüzden bu metodlara "ağır" metodlar adı takılmıştır, ve ya Jim Highsmith arkadaşımızın dedigi gibi, "Dev Metodlar".

Fakat yakın bir zaman önce, kontrollu metodlara karşı olarak yeni bir alternatif çıktı. önce "hafif" diye bilinen bu metodlar, şimdi "çevik" metodlar diye biliniyor. Çevik metodları sevenler büyük bir ölçüde ağır metodların bürokrasisinden bıkmış insanlar. Çevik metodlar, yokluk ile çokluk arasında çok güzel bir denge buluyorlar bizce, tam kararında ve en çok getiri verecek bir şekilde bir düzen takip ediyorlar.

Sonuç olarak çevik metodlar, ağır metodlara kıyasla büyük işletim değişiklikleri getiriyorlar karşımıza. Mesela çevik projeler ötekilere kıyasla kod belgelemeye, yani döküman yazma işlemine daha az önem verirler. Çevik metodlarin merkezi kaynak koddur, çeviklere göre bir kod parçasını belgeleyen en iyi yer, o kodun kendisidir. Bu örnek tabii ki esas farkları göstermek için yetmez. Belgeleme fikrinin altında yatan iki büyük fikir vardır.


* Projeler için uyum sağlayabilmek, geleceği görmekten daha faydalı olmalı: Ağır metodlar, yazılım işlemini ince detaylı ve uzun vadede planlamaya uğraşırlar. İşler yolunda gider bir süre, ta ki değişim kapı onune gelinceye kadar. Ağır metodlar bu yüzden değişimi sevmez ve hatta durdurmaya uğraşırlar, teknoloji bakımından olsun, müşterinin istediği özellikler listesi bakımından olsun. Çevik metodlar değişimi bekler, ve hatta hatta 'ister'. Uyum sağlayabilen metod olarak, kendilerini değiştirmek bile anlamına gelse, değişime ayak uydururlar.
* Çevik metodlar "insan" merkezlidir, "düzen" merkezli değil: Yani takip edilen düzen insanların doğasına uygun olarak, onların en rahat ve severek calışıcağı bir ortam yaratmak için uğraşır.

İlerideki bölümlerde yukarıdaki kelimelerin anlamını daha detaylı olarak işleyeceğiz, bu sayede uyum sağlayan, insan merkezli düzen nasıl oluyor anlayabileceksiniz. Böylece bu şekildeki işlem düzeninin yararlarını, eksiklerini göreceksiniz, "kullansak mı kullanmasak mı?" sorusuna cevabı burada bulacaksınız.

Tahmin Edilir mi Olsun, Yoksa Uyum Sağlayan mı

Dizayn ve kodlamayı ayırmak

Genelde bugünün yazılım metodlari, ilham için öteki mühendislik alanlarına dönmüşlerdir, inşaatçılık ya da makina mühendisliği gibi. Bu tür "öteki" mühendislik alanlarında, yapımdan önce planlamak çok önemlidir. Öteki alandaki mühendis arkadaşlarımız, çok detaylı çizimler ile neyin, nasıl, ne kadar, ne ölçüde yapılacağını belgelemek için calışırlar, ve bu parçalarin nasıl birbirine bağlanacağını önceden gösterirler. Önemli dizayn kararlari (mesela bir köpru kuruyorsanız, köprü ağırlığı nasıl taşınacak) bu çizimler sırasında verilir. Çizimler bittikten sonra planlar yapım için başka bir gruba veya şirkete verilir. Yapım sırasında dizayn planının sıkı şekilde takip edileceği bilinir, hatasız bina yapmanın başka yolu yoktur. Yapım grubu dizaynı takip ederken bazı zorluklar ile karşılasabilir, fakat bu durumlar genelde az meydana çıkar.

Bütün ölçümler ve detaylar ilk dökümanda olduğu için, 'yapım planı' denen plan ilk dizayn planını çok kullanır. Yapım planı işbölümü düzeni kurar, yani, yapılacak işler arasında bağlantıları önceden düzenler. Bu sayede yapım bütçesi ve süresi tahmin edilebilir. Yapım planı, işçilerin neyi, ne zaman yapacağını sıkı şekilde tarif ettiği için, inşaatı kurma zamanı geldiğinde planı takip edenlerin fazla kafa calıştırması gerekmez. Bu safhâda el becerisi zihin cimnastiğinden daha önemlidir.

Gördüğünüz gibi, inşaatçılıkta dizayn ve inşaat iki türlü, birbirinden değişik eylemler. Bir tarafta dizayn, tahmin edilmesi zor, yaratıcı ve daha pahalı insanlar gerektiriyor, öteki tarafta yapım, daha rahat tahmin edilebiliyor. Eğer elimizde bir plan varsa, yapımı planlayabiliyoruz. Elimizde bir yapım planı varsa, düzenli bir şekilde yapmaya, kurmaya başlayabiliyoruz. Ayrıca önemli bir nokta: İnşaatçılıkta yapıyı kurmak, planlamaktan her zaman daha pahalıdır ve daha uzun zaman ister.

Alın size bugüne kadar izlenen yazılım metodlarinin temeli. Bugünün yazılım projeleri de, yanlış olarak tahmin edilir bir is düzeni, ve kodlama zamanı için ucuz programcı kullanabilsinler diye, dizaynı, kodlamadan ayırmaya uğraşmışlardır. Ve işte o yüzden dizayn için bir metod bulmaları gerekmiştir ki, sonradan plana bakıp kodu yazmak mümkün olsun, aynen inşaatta olduğu gibi..

Yazılım sektörü için bu planlar ne şekilde çıkar karşımıza? Genelde bugünün yazılımcıları planlama için dizayn demek, UML gibi ok-ve-kutu çizdirebilen bir metod kullanmaktır; Akıllarınca, eğer bütün önemli dizayn kararları UML ile alınabilirse, bu planı alıp kodlama planına çevirilebilir, ve oradan yazılımcı bölüm bu planı alıp, programı yazar.

Şimdi biraz daha zor sorular soralım: Kendini koda çevirecek bir dizayn şekli mümkün mü, ve eğer mümkünse, hangi projenin "yapım" kısmı plandan daha pahalı ki, böyle bir metod takip etmek finansal bize açıdan faydalı olsun?

UML şemalarını programlara verilip kodlattırmak kolay bir iş midir? Ne yazık ki hayır. UML şemaları kağıt üzerinde çok güzel gözükse bile, kodlamaya gelince büyük boşluklar cikar karşımıza. İnşaat mühendislerinin kullandığı şema şekilleri yılların verdiği birikime dayanır, kullandıkları kodlar ona göre anlamlı ve doğruluğu matematiksel olarak ispatlanır türdendir. UML şemalarının doğruluğunu ispatlamak için tek yapabileceğimiz şey bir arkadaşa göz atmasını rica etmektir. En tecrübeli dizayncılar bazen yaptıkları dizayn kodlama sırasında başaşağı dönünce şaşkın kalıyorlar.

İkinci sorun fiyat meselesi. Bir köprü inşa ettiğiniz zaman, planlama safhâsı genel masrafın %10'u kadardır. Geri kalanı inşaata masrafıdır. Yazılım mesleğinde kodlama safhâsı için harcadığımız zaman bunun tam tersidir, yani dizayna göre çok daha azdır. McConnell'a göre büyük bir proje için, zamanımızın %15 kadarı kodlama ve test etmek ile geçer, yani yüzdeler köprü kurma senaryosu ile tamamen ters bir haldedir. Test etme süresini bile kodlama ile aynı yere koysanız, dizayn hala %50 kadar zaman alır. Bu gibi bilgiler ışığında, dizayn işinin yazılımdaki yerinin, öteki mühendislik alanlarındaki yerine göre değişikliği iyice ortaya çıkar.

Bu tip sorunlar, Jack Reeves arkadaşımızı şunu söylemeye itti: "Yeni Metodlarda dizayn dokumanı/şeması aslında kaynak kodunun ta kendisidir. Ve yazılım için inşaat evresi, aslında derleme ve bağlantı programları tarafından otomatik olarak zaten yapılmaktadır". Bu düşünceye göre otomatik yapılan her şey, yazılımın inşaat evresine tekabül eder.

Su ana kadar gördüklerimizi özetlemek gerekirse:


* Yazılımda kodlama evresi ucuzdur.
* Yazılım sektörunde büyük efor dizayn için harcanır, o yüzden akıllı ve yaratıcı insanlar gerektirir.
* Yaratıcı işler, planlaması zor olan şeylerdir, o yüzden tahmin edilebilir planlar bir hayal olabilir.
* Yazılım mühendisligi için, diger mühendislik alanlarından kavram kullanmak yanlıştır. Öteki mühendislik alanları değişik sorunlarla uğraşilar, o yüzden değişik bir metoda ihtiyaçları vardır.

Yazılım Kapsamı Değişimi

Projelerde bazen garip şeyler duyuyorum. Programcılar bana gelip diyorlar ki "bu projenin problemi sürekli değişen özellik listesi (yazılım kapsamı, müşteri kontraktı yani)". Beni en cok şaşırtan ise, insanların bu değişikliğe şaşırması. Şirketler için yazılan yazılımlarda, değişim tek sabittir. Esas sorun bu değil, bu değişime nasıl ayak uyduracağınız.

Bu değişim ortaya çıkınca karşı bir reaksiyon cesidi, "müşteri ihtiyaçları kapsam grubu tarafindan yanlış toplanmış" olabilir. Bu yanlış düşünceye göre kapsam grubu (programcılar yada idarecilerden oluşabilir bu grup) özellik listesini toplar, müşteri tarafından bu listeye imza attırır, yani kabul ettirip döndürür ve sabitleştirir. Böylece düzeni bu sabit merkez üzerine kurup yazılım sırasında değişimi en aza indirgemeye uğraşılır. Eğer değişiklik gerekmişse, bu demek ki kapsam grubunun yanlışıdır.

Bu yaklaşımın açık noktası şurada: İlkinden başlayalım. Bırakın ihtiyaç/kapsam listesinin tamamlanmasına, listesindeki birimlerin değişik variyasyonlarını bile anlamak proje başında çok zor bir şeydir. Diğer bir zorluk, ihtiyaç listesindeki birimlere fiyat biçme zorluğudur: Yani, öyle bir durum düşünün ki, müşteri şirketi mesela arabasına yeni bir cant istiyor, ama araba satış görevlisi (sizin şirketiniz) cant için $10 mi yoksa $10,000 mi isteyeceğini söyleyemiyor. Fiyatı bilmeden müşteri cantı isteyip istemediğini nereden bilecek?

Yazılım zaman takvimini yapmanın zor taraflarından biri işte budur: Yazılım işlemi aslında tamamen bir dizayn eylemi olduğundan, takvime konması zor bir eylemdir. İkinci bir sebep de: Yazılımın "ham maddesi" insanlardır. İnsanlar her zaman tahmin edilmesi zor birimler olmuslardir. Bilâhere insanların hakkındaki planlama işleminin beklenmez olması sürpriz olmamalıdır.

Yazılımın elle tutulamayan özelliği de bir etken: herhangi bir yazılımı kullanmadan, işinize yarayıp yaramayacağını anlayamazsınız. Anlamak için hiç değilse projenin ilk sürümlerinden birini kullanıp şöyle bir tartmanız gerekir, ancak o zaman ne özellikler lazım hangisi daha az lâzım, fikir sahibi olabilirsiniz.

Bütün bunları bir araya getirseniz görürsünüz ki, yazılım hakkındaki genel düşünce, rahat değiştirilebilir bir şey olduğudur. Yazılım, 'yazılan' bir şeydir, yazılan silinir de, tekrar yazılabilir de. O yüzden, proje kapsamının değişmebilmesi de "normal" bir şey olmalı. Müşterileriniz de bunu biliyor zaten, hele hele kendileride bir kaç satır kod yazmışlarsa...

Daha bitmedi: Hadi diyelim, program kapsamını değişmeyecek bir şekilde belgeleyebildiniz (bir mucize sonucu). Bu halde bile, şirketin kendisinin düzen değiştirmeyecegi ne malum? Bugün iyi olan bir kapsam, 6 ay sonraki sektörde müşteriniz için iyi olmayabilir. Bütün iş dünyasi durup onları bekleyecek değil ya! iş dünyasının çoğu değişikligi de böyledir, aksini söyleyen ya yalan söylüyordur, ya da borsada çoktan milyarder olmuştur.

Tahmin Edilebilirlik İmkansiz mi?

Genel de hayır. Bazen yazılım dünyasinda tahmin edilebilirlik mümkündür. Mesela NASA'nın uzay mekiğinin yazılım planı tahmin edilebilir bir plandır. Bir sürü insan, şa-şa lı başlangıçlar, uzun zaman alan plan/geliştirme yaparak o işe koyulurlar... NASA benzeri projeler, başka yerlerde de vardır. Fakat 'işyerleri' için yazılan programlar bu kategoriye girmez. İşyeri programları için değişik bir düzen izlemeniz gerekir.

Esas önemli olan, ne tür durum içinde olduğunu bilmek. En kötüsü, tahmin edilemeyecek bir durumdayken, ettiğini zannetmek. Klasik metodçu arkadaşlarımız genelde bu tür 'dış iş planı hatlarını' çizmekte pek iyi değillerdir. Hani metodların uygunluktan geçip uygunsuzluğa girmeye başladığı o gri alandan bahsediyoruz. Bunun suçu biraz da, metod mucidi olan arkadaşlarımızda. Metodlarının 'herkes' tarafından kullanılabilmesini istedikleri için, etrafına sınır koymaktan genelde kaçınırlar. Bu yüzden takipçileri olan bazı zavallılar, metodu yanlış yerde kullanma hatası yaparlar, beklenmez durumlar için 'beklenir olanı seven' metodlar kullanmak gibi.

Böyle yanlışları yapanı aslında anlıyoruz. Sonuçta bir şeyi tahmin edebilmek, planlayabilmek arzulanan bir özellik. Fakat tahmin edemeyecegin şeyleri planlayabilirim sanmak, proje sırasında geri dönülmez yanlışlara yol açıyor. Böyle durumlarda plan işlevini kaybedince, bu durum yeterince kollanamıyor. Yavaş yavaş plan elinizden kaysa bile, belli bir süre hala bildigim yolu takip ederim gibi işi 'kıvırıyorsunuz', fakat en sonunda gerçek ile plan arasındaki uçurum o kadar çok büyüyor ki, film mecburen bitiyor. Acı sonla.

Bu söylediklerimiz bazılarına ağır gelebilir. O kadar dikkatle kurduğunuz müşteri idare yöntemleri, proje planları demek doğru değilmis. Fakat tahmin edebilmek ne kadar güzeldi! Katılıyoruz. Eski alışkanlıkları bırakmak kolay değildir. Fakat ortada bir problem var. Bu problemin varlığını kabul etmek, çözmeden önce en gerekli aşama. Merak etmeyin: Alternatif, kontrolsuz, anarşik planlama/kodlama metodu değil. Alternatif, bilinmezi kontrol edebilen bir metod. Uyum sağlamanın önemi işte burada.

Bilinmezi Kontrol Etmek

Bilinmez dünyada, kendimizin nasıl müfettişliğini yapabiliriz? En önemlisi, projenin yolda yürüyüp yürümediğini nasil anlarız? Bize lazım olan, bir kendini denetleme mekanizması. Öyle bir mekanizma ki, gerçekçi, ve kendimizi aldatmamıza yer bırakmayan bir mekanizma.

İste anahtar cevap: Sık sürüm yaparak geliştirme metodu. Bu aslında pek yeni bir fikir değil, daha önce başka adlar altında duymuş olabilirsiniz: Azar azar geliştirme, devrim usulü, basamaklı stil, spiral metodu, vs..vs. Önemli olan, sık sürüm metodu ile, çok kısa aralar ile proje özellik listesinden bir kaçı kodlanır kodlanmaz herşeyi paketleyip, bir sürüm yapmak. Tabii ki bu ara sürümler bütün kapsamı içermiyor, ama en son planladığınız sistemin özelliklerinden bir kaçını içeriyor. Unutmayalım, aklımızda sürekli bitiş çizgisi var. Ona göre kısım kısım sürüm yapıyoruz, öyle kafamıza esen özellikleri koymuyoruz program içine. Ve, bu ara sürümü, az özellik içerse bile, sanki son sürümmüş gibi otomatik testlere tabii tutuyoruz (yazabildiğimiz kadarına), ve iç bağlantılarını doğru şekilde kuruyoruz. Burası çok önemli.

Çünkü bir proje için, gerçeklerle yüzyüze gelmenin en iyi yolu, test edilmiş ve "baglanmış" bir sistem ortaya çıkarmaktır. Güzel güzel yazılan o proje dokumanları ve belgeleri bir sürü yanlışı saklayabilir. Calışır program bile, test edilmemişse, yanlışlarını saklayabilir. Fakat bir programın önüne oturup şöyle bir kullanınca, programcılık hataları, ya da müşteri yanlış anlamak yüzünden çıkan hatalar hemen ortaya çıkarlar.

Sık sürüm metodu, klasik planli projeler için bile yararlıdır. Fakat "çevik" metodlar için vazgeçilmez bir durumdur, çünkü proje kapsam değişikliği ile boğuşmak için başka yol yoktur. Sık sürüm metodunu takip edince anlayacaksınız ki, uzun süreli planlar bayağı gevşek, ve bütün dikkatli ve detaylı planlar hemen bir sonra gelen sürüm için yapılıyor. Böylece temeli yavaş yavaş büyütüyorsunuz, ve yeri geldikçe üzerine eklemeler yapıyorsunuz.

Aklınıza bir soru geliyordur, her sürüm ne kadar aralıklar ile yapılmalı? Değişik çevik metodlarden değişik cevaplar alabilirsiniz. XP metodu 1 hafta ile 3 hafta arasında değişen bir süre verir. SCRUM metodu 1 ay der, Crystal metodu daha da uzatabilir. Fakat genel bizce, her sürümü yapabildiginiz kadar sık yapmak. Böylece sonuç sistemin bir parçasını daha sık görerek, nerede olduğunuz anlamak daha rahat olacak.

Uyum Sağlayabilen Müşteri

Uyum sağlayabilen metodlar kullarken müşteri ile ilişkilerin de değişmesi gerekiyor biraz, özellikle program müşteri şirketinin dışında yazılıyor ise. Bugünlerde müşteriler ayrı bir programcı şirkete proje verince, fiyat kontrollu proje vermek istiyorlar. Bu eski sisteme göre ihale başlatılıyor, fiyatlar toplanıyor, bir fiyata göre programcı şirket seçilip, proje veriliyor, ve yazılımın bitirme sorumluluğu bu şirketin üzerinde oluyor.

Tahmin edebileceğiniz gibi, fiyat kontrollü projeler için bilinen kapsam gerekir, ve klasik metod gerektirir. Uyum sağlayabilen metod kullanmak demek, kapsam bilinmiyor demektir, ve fiyat kontrolü bu projeler için anlamsızdır. Bu tür projelere fiyat kontrolü getirmek projeye acı sonuçlar getirebilir. En sonda olacak depremden hem siz, hem de müşteriniz etkilenecektir. Sonuçta müşterinizin bir şekilde bir yazılıma ihtiyacı var ki bunu sizden istemiş. Bu yazılım eline geçmezse, şirket geleceği kötü şekilde etkilenecektir. Yani yazılımı şirkete verdikleri para bir yana, onlara lâzım olan programı alamamaktan ifade bulan bir zarar ile karşı karşıya gelirler.

Demek ki iki taraf için de fiyat kontrollu bir kontrakt imza etmek zararlı. Bu demektir ki, müşteri de, siz de değişik bir ilişki halinde olacaksınız.

Çevik metodlar altında müşterinizin yazılım projeniz üzerinde daha fazla etkisi olmalı. Her sürüm sonunda, hem durum kontrolü için, hem de projenin yonunu değiştirebilmek için katilmalari gerekiyor. Böylece yazılım takımınız ile müşteri arasında daha sıkı bir ilişki doğuyor, tam bir takım oluyorsunuz yani. Kabul edilyoruz: böyle bir yazılım geliştirme yöntemi her müşteri ve her yazılım şirketi için uygun olmayabilir. Fakat böyle olması uyum sağlayabilen metodlar için şarttır.

Böyle bir sistemin müşteriniz için en önemli yararı şudur: Az özellikli olsa bile kullanilabilir bir yazılım, kullanima cok önceden açılabiliyor. Ve yeri geldikçe, ve iş düzeni değiştikçe, kendileri de ne istediklerini daha iyi anladıkça, sistemi değiştirme şansları ellerine geçiyor.

İnsanların, Körü Körüne Metoddan Önce Gelmesi

Uyum sağlayabilen bir metodu kullanmak kolay değil. öncelikle cok kaliteli programcılara ihtiyaç var. Hem kişilerin kaliteli olmasi lazım, hem de yazılım takımının birbiri ile uyum halinde olması lazım. Ve ilginç bir gözlem yapmak gerekirse, uyum sağlayan metod için iyi programcı gerekir, iyi programcılar da, aslında bu tür metodlar ile en rahat çalışırlar.

Programcılar Lego Parçası mi?

Klasik metodlarin asıl istedikleri lego parçası gibi istenen yere konabilen programcı birimleridir. Böyle metodlara göre lazım olan, değişik tipte ve özellikte programcı "parçalarıdır". Bir tarafta analizciler, öteki tarafta testçiler, başka bir tarafta idareciler. İnsanlar, kişi olarak önemli değiller, ne rol üstlendikleri önemli yani. Yani, projeye hangi "kişi" aldığın önemli değil, belli rollerde belli sayıda "parçalar" aldığın önemli.

Fakat gerçek hayat hakikaten böyle mi? Çevik metodların getirdiği en büyük değişiklik iste burada. Bu tür fikirleri bir tarafa atmamız gerekecek.

Bu gözlemi en iyi ispatlayan bence Alistair Cockburn. Bu konu hakkındaki bir yazısında, klasik, başı-sonu belli metodların, sıkıcı ve ne yapacağı belli insanlar gerektirdiğinden bahsediyor. Fakat insanlar tahmin edilir ve planlabilir birimler değil. Cockburn'un yaptığı araştırmalara göre, vardığı sonuç, insanların yazılım projesinin en önemli parçaları olduğudur.

Bu arkadaşımızdan bir paragraf: "Biraz önceki yazımın başlığında, klasik metodlara atıf yaparak, insanlar lego parçası gibi kullanılıyor demiştim. Eski metodlar insanları nedense böyle görüyor. Fakat ötekilerin göremediği, insanların çok değişken, ve başarı-başarısızlık dalgalarının bile çok değişik olduğudur. Bu etkenler o kadar birinci derece de önem taşıyor ve ayrıca planlanamaz türden oluyorlar ki, bu tür değişkenleri hesaba katmayan metod mucidlerimiz, projeler metodlarını kullanınca hüsrana uğruyorlar, ve bu sonuçlar başa gelince nedense şaşırıyorlar".

Bu tür "insan öncelikli" yaklaşımlarda Cockburn arkadaşımız bayağı uç noktada olsa bile, tanıdığımız proje lideri arkadaşlarımız da benzeri gozlemleri bizle çok paylaştılar. Klasik metodun en eksik tarafı, bu tür gözlemleri nedense dinlememesidir.

Bu eğilimin işaretlerini de görmüyor değildiniz herhalde. Mesela bütün programcılariniz lego parçası gibi gördüyseniz, onları kişi olarak görmüyorsunuz demektir. Bunun yan etkisi takım moralini düşürür. Kaliteli olan programcılar buna dayanamayıp, mutlaka daha iyi olarak gördükleri yere gitmeye başlarlar, ve sizde parça-yedek parça fikirlerinizle yanlız kalırsınız.

Evet, aksine karar verip uygulamak çok büyük bir adımdır, uygulamaya koymak büyük kararlılık ister. İnsanların işlemci parçası olarak görülmesi, çok eskiden beri bilinen işletmeci kafasına dayanır, Fredrick Taylor mesela "Bilimsel İdare" sanatında böyle bir yaklaşımdan bahsetmiştir. Eğer fabrika isletiyorsanız, Taylor'ın fikirleri işinize yarayacaktır. Fakat yaratıcı bir olaydan bahsediyorsak, o zaman Taylor'ın fikirleri bırakalım. (Modern üretici tesisleri de aslında Taylor fikirlerini bırakmaya başladı). Yazılım işi yaratıcı bir olgudur.

Kendinden Sorumlu Programcılar

Taylor fikrinin merkez noktası sudur: "Herhangi bir isi yapan kişi, o işin nasıl en iyi şekilde yapılacağını bilemez". Bir fabrikada bu doğru olabilir. İşçiler bir makina gibi kullanıldığı için çok zeki olmaları gerekmez.

Yazılım dünyasında bunun ne kadar yanlış olduğunu görüyoruz. Gün geçtikçe yazılım dünyasının parlak ışıklarından, oturduğun yerden büyük şeyler yaratabilme arzusu, daha çok akıllı ve becerikli insanları bu sektöre çekiyor. Ve hisse senedi hakları, programcıları iyice şirketlerine bağlıyor, kader birliği getiriyor.

İşte bu şekildeki bir gruptan insanları işe alabilmek, ve aldıktan sonra tutabilmek istiyorsanız, bu insanların profosyonel düşünceli işini seven insanlar olduğunu kabul etmeniz lazım. O yüzden teknik sorunları çözerken, unutmayın ki probleme en iyi çözüm getirecek olan insanlar, bu teknik arkadaşlarınızdır. Taylor modelinin işlemesi için, ayrı olan planlama bölümünün, işçilerin ne yaptığını onlardan iyi anlaması gerekir. Eğer işi yapan zeki ve becerikli insanlar ise, bu düzen ise yaramayacaktır yani.

Martin Fowler