kozsu on air

Yılmaz bebek geldi

Thu, 19 Jun 2008 14:44:54 GMT

Yılmaz bebek 17 Haziran'da sabaha karşı 5.30'da aramıza katıldı. 2980 gr ve 50 cm. Bebeğin ve annesinin sağlığı yerinde. Çok tatlı, mırıl mırıl sesler çıkarıyor; ışıktan ve sesten rahatsız olup şikayet ediyor. Sağlıklı, mutlu ve başarı dolu bir ömrü olsun, vatana millete içinde yaşadığı topluma ve dünyaya faydalı bir evlat olsun.

Dünya Leyla Gencer için ağlıyor

Sun, 11 May 2008 15:05:45 GMT

Operanın mabedi La Scala'nın ana sayfasında Leyla Gencer'e veda var. Dünyanın en büyük sopranolarından biri daha hayata gözlerini yumdu. O artık eserlerinde ve adını taşıyan şan yarışmasında (www.leylagencer.org) yaşayacak. Yaşı nedeniyle maalesef yeterince canlı performansını seyredemediğim gerçek divayı 90'lı yıllarda bir kez İstanbul Festivali kapsamında Aya İrini'de seyretme şansını bulduğum için kendimi ayrıcalıklı addediyorum.

Kurumsal BT'nin geleceği - 2: IT BT oluyor

Sat, 03 May 2008 17:48:20 GMT

BT'yi (bilgi teknolojileri) bi-ti olarak okuyanlar vardır. (tıpkı lcv'yi el-ci-vi olarak okuyanlar gibi, bilmeyen varsa, lcv lütfen cevap verinizin kısasıdır). Türkçe kısaltmayı ingilizce okumaya ne gerek var ki? Komik! Neyse, bizim konumuz farklı, ingilizce isteyenler için IT, BT oluyor, ya da türkçe tercih edenler için ise komik bir tesadüf, BT, İT oluyor. Şöyle ki:

Daha önce pek çok kereler değindiğimiz gibi, kurumsal BT'nin varlık sebebi, stratejik kurumsal hedeflere ulaşmak için teknolojiyi kullanmaktır. Vurgu ve odak iştir, bu sebepten de bilgi teknolojisi ifadesi yerine iş teknolojisi daha doğru olabilir. Son dönemde moda olmaya başlayan bu yaklaşımla bilgi teknolojileri (BT) yerini iş teknolojilerine (İT) bırakıyor; ya da başka bir ifadeyle information technologies (IT), business technologies (BT) oluyor.

Korkarım hepsi birbirine karışacak yakın zamanda, pek ala şu soruyu duyabilirsiniz biryerlerden: "biti derken??"

Kurumsal BT'nin geleceği - 1

Wed, 30 Apr 2008 19:05:08 GMT

Biraz fikir jimnastiği yapsak. Gelin, kurumsal bilgi teknolojileri departmanları önümüzdeki dönemde nerede olacak, fikir yürütmeye çalışalım. Önümüzdeki dönem derken de, beş ve on yıllık yakın geleceğe odaklanalım.

Bugün kurumsal BT'nin yaşadığı temel sorun kaynak yetersizliği ve üretkenlik gibi duruyor olabilir, ancak bence temel sorun verimlilik. Önümüzdeki yakın dönemde BT sahip olduğu kaynakları daha verimli kullanmaya, daha fazla kaynaktan faydalanabilir hale gelmeye ve yönetim süreçlerine yönelecek. Bu üç maddeyi açmaya çalışalım:

Şu anda BT yönecileri kendilerinden tamamlanması beklenen projelerle boğuşuyor. Çoğu kez ellerindeki kaynakla üretebilecekleri çıktıyı ölçemedikleri için kapasitelerini basit bir değerle ifade edemiyorlar. Örneğin üretimin böyle bir sorunu yok, çünkü elindeki tesislerde hangi üründen ne kadar zaman ve zahmetle ne kadar ürün çıkar biliyorlar ve ölçebiliyorlar. Ama elli kişilik bir kurumsal yazılım ekibinden kaç proje çıkar diye sormak bile anlamsız, çünkü proje ile herhangi bir boyut ifade edemiyoruz. Ayda kaç satır kod yazarlar desek bunun bile hiçbir manası olmuyor, çünkü işi yapmak için kaç satır lazım bunu bilmiyoruz! Yardım masası ve operasyon için kaynak/hizmet oranı belki ölçülebilir ama kurum içi anlık mesajlaşmayı devreye almak için ya da bekleyenmeyen enerji sorunu sonrasında açılmayan veritabanı için ne kadar kaynak gerektiğini; yani kısaca kapasiteyi ölçmek bir sorun. Bu sebeplerden faal kurumların BT'leri üzerlerine yağan proje yağmurunda, sel sularına kapılmamak için direnirken başka şeyler için zaten pek vakit bulamıyorlar.

Yakın zamanda BT yöneticileri ellerindeki kaynakların kapasitesini ölçmeye çalışacaklar ve verimliliklerini sorgulayacaklar. Bunun için temel süreçlerin tanımlanması ve ölçmeye başlamak gerekiyor.

İkinci adımda BT yöneticileri acımasız bir gerçekle yüzleşecekler: ellerindeki kadrolu kaynaklarla tüm projeleri yetiştirmeleri asla mümkün olmayacak, üstelik çalkantılı pazar koşullarında bu kadrolar asla yeterince hızlı genişlemeyecek. Şu an düşünebildiğim tek çözüm dış kaynak kullanımı. Çeşitli yöntemler var, daha önceki blog girdilerinden birinde kontrat tiplerinde bunları gözden geçirmiştik.

BT yöneticileri, bu yollardan bir veya birkaçı birlikte kullanılarak kaynakları çoğaltmayı tercih edecekler. Buradaki temel sorunları çözmek için dışkaynak, sözleşme ve tedarikçi yönetimi süreçlerini yapılandırmaları gerekecek. (Tercihin artacağı model hakkında da bir öngörüm var, ama başka bir girdi konusu..)

Verimlilik arttıkça artan yönetim yükü, BT yöneticilerini içinden çıkılmaz bir girdaba doğru çekebilir. Bir kısım yönetici ard arda proje başarısızlıkları yaşarken, bir kısım kendini projelerden sıyırıp yönetim süreçlerini geliştirmeye yönelecek. Bazı sektörlerde bu zorla, bazılarında ise gönüllü olarak gerçekleşecek.

Böylece bundan beş sene sonra -doğal olarak- bugünkünden daha olgun bir kurumsal BT ortamı ile karşı karşıya olacağız. Sonraki beş sene, yani bugünden itibaren on sene sonra bizi bekleyen tablonun radikal farklar taşıyacağına inanıyorum, ama bu yazı fazla uzadı, devamını ikinci bölüme bırakalım en iyisi..

SPM Web

Tue, 29 Apr 2008 21:17:04 GMT

SPM web sayfası www.i-con.com.tr/spm adresinde yayına başladı. Emeği geçenlere teşekkürler.

SPM logo

Mon, 28 Apr 2008 19:47:21 GMT

SPM web sitesini yarın gece yarısı açıyoruz. Ana fikir üretkenlik ve verimli çalışma; tema doğa ve tarım.

Aynı çizgiler SPM'in logosuna da yansıyor. Sekizgen yıldız ya da octagram, zamanın devinimi, dönüşüm ve yenilenmenin gücünü temsil ediyor. Ayrıca sekiz, hasatın sembolü ve önceden ekilen tohumların mahsulünü, projelerin dönüşünü ve öğrenmeyi temsil ediyor.

Logoyu Kaan Şibay tasarladı. Orjinal i-con logosu da Kaan'ın eseridir, 2002'de şirketi kurarken ismi bulmak için çok uğraşmıştık ama Kaan logoyu tek seferde çizmişti. Hala soran olur, niye i-con diye. Başka isim bulamadığımız için, muhtemelen.

Çok işim var..

Wed, 23 Apr 2008 09:22:26 GMT

İnsanın çok işi olunca hangisini yapacağını şaşırıyor.. böyle durumlarda ben genellikle başka şeylerle oyalanmayı tercih ediyorum. :)

Sun Tzu - Savaş Sanatı (2)

Fri, 11 Apr 2008 19:29:25 GMT

Gerilla taktiği - kısıtlı kaynaklarla büyük orduları yenmek

"dar vadilerden geçilerek ulaşılabilen, içinden daracık keçi yolları ile çıkılabilen arazilere 'kuşatılmış arazi' denir. Bu tür alanlarda zayıf bir birlik koca bir orduyla başa çıkabilir."

İşte küçük şirketler için büyük, devasa rakipleriyle başa çıkma taktiği. Stratejinin temeli, birliklerin yerleştirilmesidir, yerleştirme araziye göre yapılır, bu yüzden strateji eşsizdir, birliklere, araziye ve düşmana göre geliştirilmelidir. 25 kişilik bir şirket 125 bin kişilik bir şirkete rakip olabilir mi?

"Savaşta sürat ana silahtır. Düşmanın hazır olmadığı anı kollayın. Beklenmedik yollardan geçip, korunması ihmal edilmiş noktaları vurun."

Boyuna bakmadan yollara düşen komutan takip edilir mi?

"Ordunu ölüm tehlikesine, zorluklara sür; zaferle dönecektir."

Gereksinimlerde kuralcı yaklaşım

Wed, 09 Apr 2008 17:44:28 GMT

Gereksinim yönetimi modellerinden birincisi olarak tanımladığımız use-case realization ya da kuralcı veya klasik yaklaşım olarak adlandırdığımız yaklaşım hakkında biraz daha detay vermenin gereğini duyuyorum. Bu yaklaşım da kendi içinde farklılıklar gösteren yöntemlere ayrışabiliyor.

Model ya da diagram odaklı yaklaşım

Adından da anlaşılacağı gibi odakta use-case ve diğer diagramlar bulunmaktadır. Use-case tanım olmadan birşey ifade etmediği için tabii ki metinsel tanımlar ile desteklenir ancak bu diagrama ektir. Genellikle diagramın çizildiği yazılım ile otomatize edilir. Örneğin SparxSystems Enterprise Architect bu işi için uygun bir araçtır.

SRS yaklaşımı

Gereksinim yönetiminde doküman odaklı yaklaşım olarak da görülebilir. Use case ve diğer diagramlarca desteklenir, ancak ana unsur SRS dokümanıdır. Burada temel sorunlardan biri use-case tanımlarının SRS dokümanında mı yoksa her use-case için ayrı ayrı mı takip edileceğidir. Otomasyon bulunmadığı sürece her iki yöntem de sıkıntı yaratabilir. Ayrı dokümanlar sürekli bir derleme ihtiyacı doğurur, müşteriye veya başka bir takıma gönderirken birini unutmak ya da yanlış versiyonu kullanmak işten bile değildir. Diğer taraftan tek dokümanı yönetmek ve özellikle iteratif olarak geliştirmek ciddi şekilde zorlaşabilir.

SPM RM'in sanal doküman (virtual document composer) ve gereksinimler arası ilişkilerin takip edilebilmesi özellikleri bu sorunu mükemmel şekilde çözmektedir. Ayrık dokümanlar halinde takip edilebilen gereksinimler birbirleriyle ilişkilendirilebilir, son sürümleri istenilen formatta birleştirilebilir. Böylece müşteriye ve diğer üçüncü şahıslara istenilen içerikte bir doküman üretmek kolaylaşır, diğer taraftan tekrar eden bilgilerin tutarlılığı ya da büyük dokümanın incelenmesi gibi sorunlarla uğraşmaya gerek kalmaz.

Ziyaretçilerim

Wed, 02 Apr 2008 10:21:02 GMT

Blogumda neler oluyor, biraz bilgi paylaşma zamanıdır, çünkü son zamanlarda dikkatimi çeken bir husus var.

Toplam ziyaret sayısı, ilk günden bu yana 8850 olmuş. Bu muhtemelen düşük bir sayı ama zaten daha kalabalık bir kitleye hitap ettiğimi de sanmıyorum. Son dönemlerde ziyaret sayısında bir azalma dikkatimi çekiyor; zaten yeni girdi olmayınca pek ziyaret olmuyor doğal olarak, ama yeniliklere rağmen de eskisi kadar çok gelen giden yok. Bunu öğrencilerle daha az haşır neşir olmama bağlıyorum. Aslında hala çok kişiyle irtibattayım ama çoğunlukla kurumsal müşteriler ve onlar da blog ziyareti vs gibi şeylerle vakit geçirmiyorlar..

Diğer taraftan sayılar azalmıyor bilakis artıyor, bunun sebebinin de RSS'ler olduğunu düşünüyorum. İstatistiklerde ciddi miktarda RSS feed var.. Live Spaces istatistik konusunda zayıf olduğu için uzun dönemli karşılaştırma gibi bir analiz de yapamıyorum haliyle.

Ancak asıl ilginç olanı, son dönem ziyaretçilerin bir kısmının google'dan aramalarla gelen yabancılar olması.. İlginç şeylerin aranması sonucunda bir şekilde blogumda bulmuşlar kendilerini.. Herhangi bir not vs bırakmadıklarına göre ilginç bir şey bulamadıklarını varsayıyorum, ama gerçekten gelen gidenin ne düşündüğünü merak ediyorum. Son dönemde aranan bazı anahtar kelimeler şöyle:

savaş sanatı; sıkça aranıyor.. birşeyler daha yazacaktım ama bu aralar sözlerimi hiç vaktinde yerine getiremez oldum, bu beni üzüyor..
dünyadaki harikalar - aynı aramayı google'da yaptım, ben kendimi bulamadım valla, ziyaretçi nasıl bulmuş şaşırdım..
gezi yazısı iller - bu kelimeler arandığında google'da ilk sırada çıkıyorum, komik...
girişimcilikle ilgili hikayeler - google yanılmış, burada girişimcilikle ilgili hikaye yok, ama büyük bedellerle kazanılmış birkaç tecrübe bulabilirsiniz.. belki sonra devamı da gelir
Picasso bilim ve merhamet - bunu yazdığımı açıkçası unutmuştum, arama istatistiğinde görünce dönüp baktım.. evet, Picasso'nun baş yapıtlarından biri kesinlikle, bunu arıyor olmamız güzel..
eleman aranıyor - evet, yaklaşık 670 bin sonuç var bu arama için, ziyaretçi buraya bu arama ile ulaştığına göre bayağı uğraşmış olmalı. türkiyedeki yapısal işsizlik sorunu temel meselelerden biri, bence hükümet politik krizlerle topu taca atıyor, yapacak çok iş var oysa ki..

Başka ilginç anahtarlarla da bulunmuşum, ancak onlar Windows Live'ın karanlık sayfalarına gömülmüş durumda..

Gereksinim yönetimi modelleri

Sun, 30 Mar 2008 15:23:19 GMT

Gereksinim yönetiminde seçeneklerimiz nelerdir, temel bir liste yapmak istiyorum. Böyle bir çalışmaya girişince yapılacakları yaptım, temel bir literatür taraması, google, wikipedia ve uzmanına başvurdum. Biraz detay verebilirim sanırım burada..

Literatür deyince, hemen başvurduğum bazı kaynaklar vardır, oralarda pek çok kez kolayca sonuç elde edebiliyorum. Bu kaynakların başında swebok geliyor (bkz: www.swebok.org), Rapid Development (Steve McConnell, MS Press) ve CMMI rehberleri (www.sei.cmu.edu) geliyor. Bunlar hemen hemen her ilgili arayışta kullandığım ilk kaynaklardır, ilgili derken, yazılım mühendisliği ile ilgili tabii, bazen fazla dar bakıyorum galiba hayata :)...

Tabii liste hazırlamak için sadece bunlarla yetinmek yetmez, daha çok kaynak gerekir. Konuya göre bildiğim kaynaklara bakarım hemen ardından sonra da uygun olduğunu düşündüğüm anahtar kelimelerle google. Ancak durum bu sefer çok parlak değil, çünkü istediğim kadar detay ve çok seçenek bulamıyorum.

Gereksinim yönetimi için model teşkil edebilecek yaklaşımlardan bahsediyorum. Bir şirketin gereksinim yönetimini şekillendirecek temel yöntem ve metodlar. Maalesef ilk düşünmede aklıma gelen üç yöntemden başka da bulamıyorum. Tabii aramaya devam, özellikle swebok'u daha detaylı inceleyip, referanslara dalmalıyım. Peki bu ilk üç model nedir, hemen sıralayalım:

1. Use case realization

Temel yaklaşım. Kuralcı (prescriptive) olarak da adlandırılan, gereksinimlerin detaylandırılması ile işe koyulan yaklaşım. Senaryolar, özellikler gibi farklı isimlerle anılabiliyor, ama bence use-case en uygun örneği bu yaklaşımın. Özelliklerin detaylı olarak tanımlandığı, gereksinim yönetiminin dokümantasyon ağırlıklı yönetildiği bir metod use-case.

2. Kullanıcı hikayeleri (user stories)

XP yaklaşımı. Use case ile aynı maksatla kullanılıyor, ama aynı değiller, diye açıklıyor extremeprogramming.org sitesi. Önemli iki farkı var: use case kadar detaylı ve dokümante değil (çünkü müşteri zaten hep orada olmalı..) ve müşteri tarafından hazırlanıyorlar. Bu bence gerçekten devrilci bir yaklaşım, ama ciddi şüphelere neden olmuyor değil. Bence uygulanması oldukça zor, özellikle müşteri tarafından hazırlanacak şekilde. Birincisi müşteriler bu konuda tecrübeli olmayabilir (yazılımcıların yardımcı olması bekleniyor zaten) ayrıca müşteriler bu işlerle uğraşmaya gönüllü değil (zaten bu durumda XP uygulamayın denebilir). XP de bu risklere dikkat edilmesini salık veriyor zaten.

3. Liste yaklaşımı

Scrum product/sprint backlog bu konudaki en detaylı yaklaşım şu ana kadar gördüğüm. Basitçe tüm isterleri bir liste olarak takip etme üzerine kurulu. Use case kadar detaylı bir yönetim imkanı sunmadığı aşikar, ama zaten yaklaşım da bu kadar detaylı yönetmeye gerek olmadığı yolunda. Özellikle şartların baştan belirlendiği ve kontrata konu olan projelerde uygulanması pratik sorunlar getiriyor.

Bunlardan tamamen ayrışan, farklı yaklaşımlar da bulunuyordur diye düşünüyorum. Aramaya devam ediyorum, ancak ana modellerin bunlar olduğunu düşünmek de çok yanlış olmayabilir.

MSDN Showtime'da yüksek skor

Fri, 28 Mar 2008 21:23:08 GMT

Birkaç sene önce MSDN Showtime için ASP.NET Road Show'da 4 sunum yapmıştım. Bunlar daha sonra MSDN'de yayınlandı. Biraz önce MSDN'in bir rating sayfası açtığını ve dört sunumumdan birinde 4/5 skor elde ettiğimi gördüm. 16 Sunumda sadece iki tane beşte dört olduğunu düşününce, bu durum hoşuma gitti. (http://www.microsoft.com/emea/msdn/spotlight/event.aspx?id=26)

O ilginç bir etkinlikti. Ankara'da ingilizce sunum yapmak gerçekten çok garibime gitmişti. Tüm dinleyiciler Türk, sen kalk sunumu ingilizce yap. Üstelik yanyana iki oturumda bizim salon hep daha doluydu. Değerlendirmelerden birinde, "niye bir türkü yarım yamalak ingilizcesiyle dinliyoruz!" gibi bir yorum okumuştum. Haliyle ingilizce anadilim değil, (aslında öğrendiğim 2. yabancı dil, önce almanca öğrendim!!) ama dünyanın geri kalanının o dinleyiciyle aynı fikirde olmamasına sevindim. Üstelik de hastalıktan baygın düşmek üzereydim, Melda Kelebek'in her arada getirdiği sıcak sıvıyı ve suda eriyen birşeyleri içerek ayakta durmaya çalışıyordum. Seyrederseniz ne kadar korkunç halde olduğumu göreceksiniz..

Bu etkinliğe Gürkan Salk sayesinde (yüzünden!) katıldım. Gürkan bak, iyi iş yapmışız.

SPM RM Baseline

Thu, 27 Mar 2008 19:09:57 GMT

1,5 yıldır devam eden büyük projemiz SPM'in Requirement Management (RM) ürünü önümüzdeki günlerde önemli bir önemli bir aşama daha kaydediyor: RM 1.3 yayınlanıyor. RM 1.3 çeşitli iyileştirmeler ve bug fixlerin dışında dört önemli özellikle gelecek. Bunlardan bir tanesi temel çizgi ya da daha bilinen adıyla base line. Bu özelliğin bugün ilk demosunu gördüm. Gerçekten güzel bir iş yaptığımızı hissettim. Henüz düzelecek çok şey var tabii ama SPM RM'in geldiği yer gerçekten kayda değer.

SPM RM ile gereksinimleri yönetiyoruz. Doküman şablonlarını tanımlamak ve istediğiniz gibi dokümanları doldurmak temel işlevleri RM'in. Gereksinim olarak işaretlenen başlıkların tarihçesini ve diğer gereksinimleriyle ilişkilerini de takip etmek mümkün. Sanal doküman özelliği ile farklı dokümanlardaki başlıkları birleştirmek ve bunlardan yeni doküman üretmek mümkün.

Doğal senaryolardan biri, bu şekilde doküman üretmek ve bunu diğer paydaşlarla, örneğin müşterilerle paylaşmak. Dokümanı müşterilere yolluyoruz tabii, ama diğer taraftan da gereksinim yönetimi süreci burada durmuyor, devam ediyor. Bir süre sonra müşteriden onay ya da itiraz geldiğinde acaba hangi andaki dokümanı kastediyoruz bunu düşünmek gerekiyor. İşte temel çizgi burada devreye giriyor. Herhangi bir anda, seçilen gereksinimleri bir temel çizgi olarak tanımlıyoruz; istendiği anda bunlardan birine dönmek, ya da bunları aynı ekranda yanyana koyarak karşılaştırmak mümkün.

Hatta karşılaştırma sırasında değişen, eklenen ve silinen gereksinimleri de görmek mümkün. Bu, silinen gereksinimlerin de gözden kaçırılma riskini ortadan kaldırıyor. Bu özelliklerin eklenmesi ile SPM RM iyice yetenekli bir hal alıyor. Diğer eklenen özellikleri de kısa süre sonra açacağımız SPM sitesinde görebileceksiniz..

MSF Takım modellerinde değişiklikler

Tue, 25 Mar 2008 21:14:29 GMT

MSF'e neler oluyor? Herşeyden önce MSF'te değişiklik görmek kimseyi şaşırtmamalı, çünkü MSF canlı bir yapıdır, ve zaman içinde değişikliklere tabi olması normaldir. Ancak V3'ten sonraki değişiklikler doğal mı yoksa zorlama mı burada bazı soru işaretleri doğmaktadır.

Bu soru işaretlerinin ardında yatan temel neden, MSF'in aniden ve radikal bir biçimde değişirken bu değişimi ağırlıklı olarak VSTS'e uymak için yaşıyor olmasıdır. İşte bu pek de MSF'ten beklenen türde bir gelişme değil!

MSF'teki tüm değişiklikleri konuşmaya bir blog girişi yetmez. Tamamına da vakıf değilim zaten, daha çok işime yarayan şeyleri ayıklamaya çalışıyorum. Bu arada VSTS ile birlikte gelen şeylere nazaran da farklılıklardan bahsediliyor MSF 4 için. MSF v4 terminolojisinde ilk defa çekirdek ve yaklaşım (örneklem) ifadeleri yer alıyor. Ürün ve süreç birbirine yaklaşırken MSF'in içinden çıkmak zorlaşıyor.

MSF v3 (v2'de de aynıdır) Program Management rolünden bahseder. Elimde bu rolü ikiye bölüp Architect ve Project Management olarak gösteren sunular var, burada anlatılmak istenen, PgM, mimari ve proje yönetimini üstlenen roldür. Bu yaklaşım kalabalık takımlarda sorunsuz çalışabilir, ancak program management rolünü bir kişi üstlendiğinde burada bir çelişki ile karşı karşıya kalırız.

Bu sorun genellenen bir sorun, tabii ki istisnaları olacaktır, ancak ben şu ana kadar rastlamadım. Yazılım mimarisi gayet teknik bir iştir, yazılım geçmişi, tercihen uzun ve derin bir yazılım geçmişi ister; diğer taraftan proje yönetimi (takvim ve kaynakların yönetimi anlamında) gayet yönetseldir. Genellikle insanlar, kendi geçmişlerine ve ilgi alanlarına uygun olarak bu konulardan sadece biriyle yakından ilgilenmeyi tercih ederler. Sonuç olarak projelerde mimari ya da proje yönetimi disiplini aksar.

MSF v4, doğru olarak bu sorunu görmüş, biraz da proje yönetimi disiplininin savunucularından (PMI!!) proje yöneticisi nerede baskısı altında kalarak bu rolü bölmüştür. Bazı VSTS dokümanlarında bu rol project manager ve architect olarak bölünse de Microsoft Solutions Framework Essentials - Building Successful Technology Solutions (MS Press) isimli kitabın yazarı Michael S. V. Turner, ki MS Services'te kıdemli yönetici, program management ifadesini korumuş. MSF v4 ile ilgili tüm alıntılar ve referans ağırlıklı olarak bu kitap, eğer VSTS/TFS dokümantasyonu vs olarak aksi belirtilmemişse.

Ben bu takım modelinde bazı değişiklikler yapılması gereğini düşünüyorum, özellikle de proje tiplerine dayalı olarak. Şu anda da bundan bahsediyor ve çeşitli şekillerde hem tavsiye ediyorum hem de uyguluyorum. Ama bunu da daha sonraki bir blog girişine bırakalım.. Şimdilik bu kadar yeter..

Dışkaynak kontrat modelleri

Mon, 24 Mar 2008 22:47:10 GMT

Bugün hızlıyım, peş peşe üç blog girişi birden.. Burayı karalama defteri gibi kullanmayı seviyorum, bazen dönüp kendim okuyorum, ne düşünmüştüm hatırlamak için bazen de başkalarına öneriyorum, şuraya yazmıştım, gidip bakın diye. İşte onlardan biri, üzerinde fazla düşünmeden dışkaynak kontrat modelleri:

Body leasing - bir uzmanın önceden kontratta belirlenen bir süreyle kaynak alan şirkette, kaynak alan şirketin istediği işte çalışması. (eti senin kemiği benim modeli) Burada önemli olan, kaynak sağlayan projeyle ilgili bir sorumluluk taşımaz, genellikle uzmanın değiştirilmesi talebine karşı belirli bir sürede cevap vermesi beklenir. İK şirketleri ucuza, danışmanlık şirketleri pahalıya sağlar (ucuz etin yahnisi durumu).
Keyturn ya da Service Contract - kaynak sağlayan, işi kaynak üzerinden değil hizmet üzerinden fiyatlandırır ve kaynağın zamanı yerine bir servis seviyesi ya da paket halinde işin teslimini vaad eder. Projenin sorumluluğu servis sağlayana geçer. Kapsam kaymalarında sorun yaşanabilir. Mesela boyacı gelir, evi görür, kaç para istediğini ve işin ne kadar süreceğini söyler; işi yapar parayı alır; fazladan bir oda daha boyatmak isterseniz bunun extra bedeli olur (genellikle, ya da papaz olunur)..
Time-and-material - servis sağlayanın proje sorumluluğunu üstlendiği ancak hizmeti kaynak üzerinden ücretlendirdiği model. Boyacı günlüğü bu kadara çalışırım der, bütün evi boyamak ne kadar sürerse o kadar zamanda boyar, sonra da o zamanın karşılığını alır.. birinci modelden farkı, evi düzgün boyamak boyacının sorumluluğundadır.

Eleman aranıyor: UI Developer

Mon, 24 Mar 2008 21:10:48 GMT

SPM projesinde çalışmak üzere UI developer arıyoruz. SPM ürünlerinin kullanıcı deneyimini yükseltecek arabirimler tasarlayacak ve bunları geliştirecek ya da diğer developerların bunları geliştirmesini sağlayacak bir uzmanlığa ihtiyacımız var. Genel olarak aşağıdakileri bilmesi gerekiyor:

grafik tasarım araçlarının kullanımı
asp.net ve c#
mümkün olduğunca javascript
web tasarımı yapmış ancak uygulama ya da uygulama arabirimi geliştirmeye yatkın
yeni teknolojiler, özellikle silverlight tercih nedeni olacaktır

Bu rolün özelliği, ne tam olarak yazılımcı ne de tam olarak web tasarımcısı. Bizim için önemli olan kullanıcı tecrübesini arttırabilecek tasarımların yapılması ki bu da sadece görsel tasarımdan fazlasını gerektiriyor.

pozisyon Kocaeli Uni bünyesindeki teknopark ofisimizde, bu yüzden istanbuldan başvuru kabul edemiyoruz (Gebze, İzmit, Sakarya ve civarı uygun)
yeni mezun olabilir, hatta bilgili ise tercih nedeni (bütçe dar!)

Nasıl bir iş tanımından bahsettiğimi en güzel anlatan kitaplardan biri Alan Cooper'ın The Inmates Are Running The Asylum isimli kült kitabıdır. Bize bundan lazım, bilen varsa söylesin.

Yeni teori: jetlag işi olmayanların başına gelir

Mon, 24 Mar 2008 19:44:26 GMT

Perşembe sabah saat 8.30'da Seattle'dan hareket ettim (bu dönemde GMT-7), net 16 saatlik uçuştan sonra (aktarmalarla 19+) cuma öğlen saatlerinde İstanbul'a ulaştım. Havaalanında üstümü değiştirdim ve bir toplantıya katıldım. Ertesi sabah sürünerek uyandım ama yine de Aytekin'le toplantıma geç kalmadım (15 dk sayılmaz!). Pazar sabah uyanamadım, Hasan'a 11'de kahve sözü vermiştim ama zar zor kalkıp 1'e erteledim; ona bile zor gittim.. Dün gece 2'ye kadar rapor yazdım, sabah 7.40'da hiç sorun yaşamadan kalktım.

Kıssadan hisse, kalkıp yapacak işin varsa jetlag falan olmuyorsun, ama yapacak bir şey yoksa öğlene kadar da uyusan toparlanamıyorsun :)

VSTS Inner Circle'ın ardından

Sat, 22 Mar 2008 18:45:29 GMT

Microsoft'un düzenlemiş olduğu VSTS Inner Circle toplantısından döndüm. Redmond'a 15 dakika mesafedeki Bellevue'de gerçekleşen toplantıya ALM kavramları damgasını vurdu. Microsoft'un, VSTS/TFS'e bayağı yatırım yapıyor olmakta beraber, henüz yolun oldukça başında olduğunu düşünüyorum. Ancak şurası çok açık bir gerçek ki, Microsoft'un istediği mesajı yaymak konusunda olağanüstü bir gücü var. Kısa zamanda istediği odaktaki büyük kitlelere istediği mesajı duyurmayı ve insanların söylenene inanmalarını sağlıyor. Bu özellikle alm konusunda olgunlaşmamış şirketlerde büyük etki yaratacak.

MSFT'un ALM konusunda içinde bulunduğu en önemli yanlışın her işin içinden SCRUM ile çıkılacağını zanneden yaklaşımı olduğunu düşünüyorum. Her ne kadar MSF, Agile ve CMMI kavramlarını birbirine karıştırıp güzel gözüken bir kavram çorbası yapsalar da aslında pişirip sundukları özünde SCRUM. Bu yaklaşım özellikle regülasyona tabii kurumlar için birçok sorunu çözebilecek yetenekte değil. Bu arada kıymetli MSF araya kaynayıp gidiyor, ama adı sık geçtiği için bunu kimseye anlatmak mümkün değil.

Microsoft'un ALM konusundaki yaklaşımı aslında bir amerikan atasözünün karikatürize hali gibi, elinde sadece çekiç olan herşeyi çivi zannediyor. TFS/VSTS kötü mü diyorum? Öncelikle VSTS benim çok da ilgi alanımda değil, burada Test Edition dışında tam anlamıyla bir ALM aracından bahsetmek mümkün değil. Geliştirme aracı olarak çok çok iyi, hatta lisanslarımız izin verdiğince biz de kullanıyor ve daha çok özelliğini kullanmak istiyoruz. Esas ALM aracı TFS ile geliyor. Microsoft bunun tam olarak farkında.

TFS kötü mü? Bunu ima etmek bile haksızlık. Ancak sorun, TFS'in nasıl pozisyonlandığı ile ilgili. ALM'in cennete giden yol, TFS/VSTS'in de bunun anahtarı olduğunu ima etmek, hem kavrama hem ürüne haksızlık. Bellevue'deki 3 gün boyunca bu yaklaşıma itiraz ettim sıkça, bu yüzden de çok taraftar kazanmadım, ama şunu gördüm ki birçok iş ortağı benimle aynı fikirde.

Ürünle ilgili şunları söylemek mümkün; 2008 sürümünde büyük değişiklikler yok, bir sonraki sürüm Rosario daha yetenekli olacak. Ne zaman yayınlanacağı konusunda spekülasyon bile yapılmayan bu ürün (bu soruların sorulmasına bile izin verilmedi, merakımız iyice arttı) daha çok tet özelliklerine odaklancak gibi duruyor. Sanırım MSFT kendisine bu alanda Mercury'yi rakip görüyor.. Bekleyip göreceğiz.

Önerilere gelince, VSS kullanıyorsanız ve lisans sorununuz yoksa hemen TFS'e geçin.
Kaynak kod kontrolü kullanmıyorsanız hemen TFS'e geçin.
OSS SCM kullanıyorsanız ve destek sorunlarınız varsa TFS'e geçin.
TFS kullanıyorsanız, görev takibini buradan yapabildiğinizi unutmayın.
Web uygulamaları (aspx) geliştiriyorsanız TFS 2008 ile otomatik derleme özelliğini burada da kullanabiliyorsunuz, kullanın!

TFS Inner Circle Airlift

Sat, 15 Mar 2008 05:51:43 GMT

Team Foundation Server ile ilgili dar katılımlı bir iş ortağı etkinliğine katılmak üzere üç günlüğüne Redmond'a gidiyorum. Tabii gitti geldi bu yedi gün olacak maalesef.. Dönünce izlenimlerimi paylaşırım.. Bir hafta yokum..

VS 2008 lansmanı

Mon, 10 Mar 2008 22:26:46 GMT

12 Mart Çarşamba günü yeni Visual Studio lansmanı gerçekleşiyor. Konuşmacı olarak katılacağım etkinliğe kayıt olmak gerekiyor: http://www.bilisimkahramanlariaramizda.com/

Sunumum Visual Studio dizisinde son oturum. O saate kadar kalırsanız beklerim.

Photo Album: IC2007 @ Seoul

Thu, 16 Aug 2007 13:42:17 GMT

IC2007 @ Seoul

CIMG1715

CIMG1770

CIMG1841

CIMG1844

CIMG1845

CIMG1847

CIMG1848

CIMG1906

CIMG1842

DSC_0276

More Photos...

Photo Album: Dostlar

Sun, 10 Sep 2006 20:21:49 GMT

Dostlar

Görünt007

Görünt011

Sao Paulo 049

yigit18082004

san francisco 075

san francisco 100

Custom List: Sevdiğim Şarkılar

Fri, 11 Apr 2008 19:08:28 GMT

Sevdiğim Şarkılar

Sen gelmez oldun (F. Agayev)
Somewhere over the rainbow (I. Kamakawiwo'ole)
Meşhur şarkının farklı bir yorumu, first 50 kisses filminin soundtrackinden.. Ertan'a teşekkürlerimle..
One more cup of coffee (B. Dylan)
En sevdiğim şarkılardan biri.. Desire'daki orjinali kadar At Budokan albümündeki live kaydıda muhteşemdir. Ayrıca Sertap Erener coverını da ben çok beğeniyorum..
Zu&Co
Zucchero'nun birçok müzisyenle yaptığı düet albümü. Çoğu beraber söylediği müzisyenlerin bilindik şarkılarından oluşan albümde özellikle dikkat çekici güzellikteki şarkılar Dolores O'riordan ile Pure Love ve Cheb Mami ile Cosi Celete (she's my baby).
Dance me to the end of love
Leonard Cohen'in çok meşhur şarkısı ama muhakkak Cate Gibson yorumu ile.. Cate Gibson'ı bir çok yerde aramama rağmen bulamadım, bu parçayı ise sadece strange days filminin cd'sinde bulabildim.
You are so beautiful
Joe Cocker'ın belki en meşhur değil ama muhtemelen en güzel şarkısı. Youtube'daki enfes akustik versiyonunu tamamen tesadüfen buldum.
My Way
Sinatra, Sinatra ve Pavarotti; Carreras, Pomingo ve Pavarotti.. Hangisi daha güzel, seçemiyorum.. Hepsi süper.. Yine de, sanırım Sinatra.. Ya da Sinatra ve Pavarotti.. Galiba hepsi.. :)