İstatistiği sağduyu olarak kullanmak

29 March 13, Friday @ 13:50

Filmi de çekilen Moneyball kitabının yazarı Michael Lewis, geçen sene Princeton Üniversitesinde bir mezuniyet konuşması vermişti. Tamamını dinlemenizi öneririm, özetle insanların başarılarını ve geldikleri konumları büyük oranda şanslarına borçlu olduklarını ve kendilerini başkalarından daha fazla hakka layık görmeden önce bunu bir düşünmelerini söylüyor.

Şansın etkisini fark etmek için bilinçli bir çaba gerekiyor. Öncelikle egomuz aldığımız eğitimi, çevremizin katkılarını, toplumdan gördüğümüz desteği unutup gözümüzü sadece kendi özelliklerimize dikiyor. Sonra da hikaye anlatmaya olan düşkünlüğümüz, olayları geriye dönük açıklayan, zaman içinde gelişen taraflı yaşam hikayeleri yazmaya başlıyor.

En büyük çok uluslu şirketlerin yöneticilerine bakın. Yakın zamanlara kadar bunlar şirketin en alt kademelerinde işe başlayıp otuz sene her kademede çalıştıktan sonra şirketin başına geliyorlardı. Bugün ise neredeyse üniversiteden çıkar çıkmaz CEO olarak işe başlayan insanlar var. İşe alım kriterleri başarıdan yada bilgi birikiminden ziyade okulda kimin arkadaşı oldukları. Bunu mühendis seçerken yapılan binlerce görüşmeyle kıyaslayın.

İşin komiği performans değerlendirmelerinde girişim (startup) değerleri kullanmaları. Girişimciler için şirketi kurduktan üç ila beş yıl içinde şirketi satmak yada benzeri bir çıkış yapmak normaldir. Kurumsal bir firmanın yöneticisini de bu kadar kısa zaman aralığında değerlendirirseniz, adamın yapacağı iş, bol miktarda adam çıkarmak, uzun vadede şirketin batmasına yol açacak işler yapıp günlük değerleri yüksek göstermek ve üç yıl sonra bonusunu alıp gitmek olur.

Havadan zengin olan, koskoca şirketleri aptalca kararlarla batıran adamlar, aldıkları bonus yetmiyormuş gibi bir de tavsiye vermeye kalkıncalar gülünç oluyor. Başarının sırrı çok çalışmakmış, sabah erkenden işe gelirlermiş, vb vb. Ortalık, liderlik sırları, falanca kişinin iş kuralları, kariyer yapmanın on kuralı gibi zırva yazı ve kitaplardan geçilmez hale geldi. Hele kendi avantajlarını ve yaşam kolaylıklarını unutup, utanmadan ben doğum yaptıktan sonra bile toplantıya girdim, çalışanlardan da aynı şeyi beklerim gibi mesajlar verenler işin tadını kaçırıyor.

Sahip olduğumuz her özelliğe bilgiye ve deneyime karşın, dünya üzerinde aynılarına yada daha iyilerine sahip en az bir milyon kişi var. Medya yalnızca başarılı (=şanslı) olan azınlığa odaklanarak istatistiksel sapmaya yol açıyor ve palavra hayat hikayelerine inanılırlık sağlıyor.

Büyük organizmaların bu aptallığı aslında iyi bir şey, doğal gelişime yer açıyor ve hantallığın ölüp gitmesini sağlıyor. Biz şansın temel faktör olduğu bir ortamda bundan nasıl faydalanılır ona bakalım.

Olasılık konusunda yazan çağdaş filozoflardan Nassim Taleb bize bunun ipuçlarını veriyor. İlk adım, bir şeyin kendisiyle o şeyin bir fonksiyonu arasındaki farkı kavramak.

Bilmediğimiz faktörler sonucu gerçekleşen olayları altı yüzlü bir zar atışıyla ifade edelim. Diyelim ki, attığımız zar sonucu gelen rakam kazancımız olacak. Hilesiz bir zarda beklediğimiz ortalama kazanç (1 + 2 + 3 + 4 + 5 + 6) / 6 = 3.5 olacaktır. Bu, olumlu ve olumsuz faktörler birbirlerini dengelediğinde, yani %50 başarı elde ettiğimizde elimize geçecek kazançtır.

Şimdi ise kazancımız zarın direk değeri değil bir fonksiyonu olsun. İlk önce konveks bir fonksiyon olan f(x) = x*x kare fonksiyonuna bakalım. Beklenen kazancımız (1*1 + 2*2 + 3*3 + 4*4 + 5*5 + 6*6) / 6 = 15.17 olacaktır. Bu değer zarın kendi beklenen değerinin karesinden daha büyük (3.5*3.5 = 12.25) bir değer. Böyle bir durumda ortalamanın altında kar etmemiz için faktörlerin büyük kısmının olumsuz gitmesi gerekecektir.

Eğer konkav bir fonksiyon olan f(x) = kök(x) karekök fonksiyonun seçersek, beklenen değer bu sefer (kök(1) + kök(2) + kök(3) + kök(4) + kök(5) + kök(6)) / 6 = 1.80 olur ki, zarın kendi beklenen değerinin karekökünden (kök(3.5) = 1.87) daha küçük bir değerdir. Bu durumda ise ortalama kar yapabilmemiz için faktörlerin büyük kısmının olumlu gitmesine ihtiyacımız var.

Jensen eşitsizliği adı verilen bu durum, mesela ar-ge projelerinin neden hep geciktiğini bize açıklıyor. Projenin eksi zamanda (daha başlamadan önce) bitmesi söz konusu olamayacağına göre, bilinmeyen faktörlerin etkisi konkav (süreyi daha uzatacak tarafa doğru meyilli) bir fonksiyon. Bu durumda da gecikme olmaması için planlama aşamasında bu faktörlerin çok büyük bir bölümünü doğru tahmin etmiş olmak (imkansız bir çaba) gerekiyor.

Taleb'in Antifragile kitabı bu yaklaşımın sağlık, günlük yaşam, ekonomi gibi birçok alanda doğru riskleri almak için nasıl kullanılabileceği üzerine. Biz yine yalnızca girişimlere odaklanalım.

Ar-ge'nin mutlaka gecikeceğini gördük. Demek ki bunu hesaba katmamız, kaynakları tüketmeden, planlarda çok geniş zaman aralıkları bırakarak hareket etmemiz lazım. Paul Graham, Nasıl Ölmemeli? yazısında farklı bir noktadan yola çıkarak benzer bir sonuca varıyor.

İşgören minimum ürünle işe başlayıp, yapılmasa da olacak herşeyi sonraya bırakmak da çok iyi bir strateji. Hem işi basitleştirip bilinmeyenleri azaltıyor, hem de ürün başarısız olursa çöpe atılacak emeği azaltarak kazanç fonksiyonunu olumlu yönde büküyor.

Bir girişimin şansını çok fazla arttıramayacağımıza göre, girişim sayısını arttırarak toplam şansı yükseltebiliriz. Daha incelikli bir strateji birden fazla girişimi paralel olarak götürmek. Yatırımcılar arasında birbirine rakip şirketlere eşit oranda yatırım yapmak epey rastlanan bir durum. Rekabeti bir şirket kazandığında kaybedenlere yatırdığınız ve batan paranız sınırlı iken, kazanan şirketten kazanacağınız miktarın limiti olmadığı için net bir kazanç sağlama olasılığı çok yüksek olacaktır. Bu daha çok yatırımcılara uygun bir strateji gibi de görünse, girişimciler de uygulayabilir.

Okul dönemi boş zaman açısından paralelde bir kaç girişimde bulunmak için ideal. Bir kaç mobil uygulama yada web sitesi kurmadan mezun olmayın. Okuldan çıkınca yalnızca girişimlere atılmak yerine, tecrübe kazanılacak ama vakit öldürmeyecek makul bir iş bulup, bir yandan para birikimi yaparken, bir taraftan da girişimlerde bulunmak da güzel bir strateji olabilir.

Böyle paralel işler çok yorucu olabiliyor. İnsan beyni de bilgisayar gibi bir önbelleğe sahip, bir işe başladığımızda yavaş yavaş detaylarla doluyor ve hızlı çalışmamızı sağlıyor. Hemen başka bir işe geçince detayları unutup baştan başlıyoruz. Verimliliği düşürmeden paralelliği arttırmak için benim bulduğum strateji işleri atomik parçalara bölmek ve bir parçayı tamamen bitirmeden bir sonraki işe geçmemek. Bir sonraki işi ise farklı bir alandan seçerek sıkılmayı ve yorgunluğu önlemek.

Tabii işin miktarı değil niteliği önemli. O yüzden mutlaka işleri filtrelemek lazım. Yapmayabileceğiniz hiç bir şeyi yapmayın. Emin değilseniz yapmayın gitsin. İş hayatımda önüme acil olarak gelen, bir kaç hafta boyunca ihmal edince de yapılmasına gerek olmadığı anlaşılan bir dolu şey oldu (neyseki hiç birini yapmamıştım zaten eheh). Gerekli ve doğru işler tekrar tekrar ortaya çıkıp kendilerini hatırlatır zaten.

Her şeyi tepkisel olarak planlayıp tamamen bitiş tarihleri üzerine yaşamak, rastlantısal ve keyfi işleri hayatınızdan çıkarıp rastlantılardan etkilenme fonksiyonunuzu olumlu taraftan daraltan bir diğer hata olur.

Bu konuda söylenecek tartışılacak çok şey var ama bu yazı fazla uzadı, artık başka yazılara. Rastgele! :)

1 comments...

Internetin kenarında

29 June 12, Friday @ 17:18

Son iki yılımı şirketin yelpazesindeki ana ürünlerden biri olan Transparent Cache (Şeffaf Önbellek) yazılımını geliştirmekle geçirdim. Bu ürün ağınızdaki kullanıcıların üçüncü parti siteler üzerinden eriştikleri canlı veya sabit video dosyalarını yerel önbellekten sunabilmenizi ve internet bağlantınızın kapasitesinden ciddi oranda tasarruf etmenizi sağlıyor.

Bunu squid yada nginx proxy/cache modülüyle direk olarak yapamıyoruz; video yayınlayan sitelerin bant genişliklerini korumak için kullandığı mekanizmalar, canlı video için gereken düşük gecikme süreleri, sunucu ve istemcilerin uyumsuz davranışları gibi sorunları çözecek kodlara ihtiyaç var.

Önbelleklemeye olan ihtiyaç, gittikçe artan video trafiğinden kaynaklanıyor. Video klip siteleri ve TV kanallarının yayınları dışında, Netflix ve iTunes gibi film yayıncıları en büyük bant genişliği işgalcileri haline geldiler. Yalnızca Netflix, trafiğin tepe zamanlarında Amerika'daki indirme bant genişliğinin neredeyse %30'unu kullanmaya başladı.

Bu hizmetlere olan tercih öyle büyük ki, normalde makul fiyatlara satın alıp bilgisayar, tv, tablet ve telefonunuzdan kolayca izleyebileceğiniz yüzlerce dizinin yanında, izlemek için tüm kablo kanalına abone olmanızı isteyen ve alternatif sunmayan Game of Thrones en çok korsan izlenen dizi oldu!

Bant genişliğine bir çözüm Bittorent gibi p2p (peer-to-peer, yanaktan yanağa :) protokoller. Burada istemciler ellerindeki parçaları diğer istemcilere göndererek ağın daha verimli kullanılmasını ve ana sunucu üzerindeki yükün azalmasını sağlıyorlar. Ancak bu sistem parçaların geliş sırası karışık olacağı için canlı yayına, toplam aktarım miktarını azaltmadığı ve uç noktadaki istemcilerde de gönderme yönünde bant genişliği ihtiyacı gerektirdiği için mobil istemcilere ve aradaki hatların sahiplerine bir çözüm değil.

Yaygın çözüm ise, Content Delivery Network (İçerik dağıtım ağı) denen ve değişik coğrafi konumlardaki sunuculardan oluşan, içeriğin istemciye en yakın sunucudan aktarıldığı hizmetleri kullanmak. Bunlar genelde önbellek mantığıyla değil, içeriğin önceden sunuculara aktarılmasıyla çalışıyorlar; ve şeffaf değiller, yani ana sunucunun istemcileri sisteme yönlendirmesi gerekiyor.

Bazı firmaların kendi özel çözümleri de var. Mesela Google Global Cache, bir kara kutu şeklinde ağınıza koyabileceğiniz bir ürün. Google'ın video başta olmak üzere bir sürü servisini önbellekliyor ve hızlandırıyor. Tam olarak ne yaptığı bilinmeyen ve yalnızca bir firmanın servisleri için çalışan bir sistem doğal olarak hiç bir hizmet sağlayıcının hoşuna gitmez, gene de GGC dünyada epey noktaya kurulmuş durumda.

Netflix ise birçok CDN sağlayıcı ile zaten çalışıyor olmasına rağmen, daha küçük hizmet sağlayıcıların da faydalanabilmesi için OpenConnect adını verdiği ve özgür yazılımları kullanarak oluşturduğu bir sistemi duyurdu. Bunu kurup Netflix'in CDN ağına katılabiliyorsunuz.

Bu gelişmeler sunucuları internetin merkezinden, yüksek hızlı bağlantılara sahip veri merkezlerinden alıp; internetin kenarına (edge), yüksek hızlı ağların istemcilerin yerel ağlarına temas ettiği noktalara doğru taşımakta.

Internetin kenarında oluşan bu bulut sistemleri, önbellekleme ve hızlandırma dışında, faydalı ölçümler yapabilmek için de uygun konumdalar.

Mesela MeasurementLab projesi, böyle bir bulut kurmaya, ve üzerinde çalışacak ölçüm yazılımlarıyla, ağ hızlarını, belli uygulamaların bloklanıp bloklanmadığını, Internet hizmet sağlayıcıların trafik biçimlendirme yapıp yapmadığını, ve benzeri bilgileri ağ haritası üzerinde görselleştirmeye ve herkesin kullanımına açmaya çalışıyor.

Bu tip bir sistemle gizli sansürü veya bilgi değişikliği müdahalelerini yakalamak da mümkün olacaktır.

CDN ve ölçüm sistemleri, kenar bulutlarının -şimdilik- iki uygulaması. Gelecekte yeni uygulamalarla önemleri daha da artabilir.

4 comments...

Yazılımcı pazarı

05 March 12, Monday @ 15:32

Yazılım geliştirici olarak iş aramak garip biçimde hem çok kolaylaşıyor hem de çok zorlaşıyor. Zorlaşmasının nedeni gereken bilgi ve deneyim seviyesinin sürekli artması. Kolaylaşmasının nedeni ise şirketlerin yazılımcı ihtiyacının bu seviyeden daha hızlı biçimde yükselmesi.

Mesela Amerika gibi güçlü CS (Computer Science, Bilgisayar Bilimleri) bölümlerine sahip üniversitelerin olduğu ve bir yandan da yurtdışından yazılımcı ithal eden bir ülkede, iyi bir yazılımcı bulup işe almak beklenmedik kadar güç bir iş. İlk önce verdikleri astronomik rakamlarla Wall Street ve keyifli ortamıyla üniversiteler bu kitlenin kaymağını topluyor, daha sonra da Google, Apple, Microsoft, Facebook, vb gibi isim sahibi firmalar. Kalanları kapabilmek için de küçük startuplar daha "cool" olma ve gelecekte dünyayı ele geçirme umutları satmakta birbirleriyle yarışmaktalar.

Bu kıran kırana ortamın iş ve işçi arayışını hallice değiştirmiş olması şaşırtıcı değil.

İşverenler başvuru beklemek yerine iyi geliştiricilerin takıldığı ortamlarda araştırma yapıp buldukları potansiyel adaylara görüşme teklifi gönderiyorlar. Büyük çaplı olanlar üniversitelere yerleşip potansiyel sahibi öğrencilerden stajyer kapmaya çalışıyor. Araştırma ortamlarından birisi diğer geliştiricilerin sosyal ağları. LinkedIn gibi profesyonel sosyal ağ siteleri, StackOverflow, TopCoder gibi bilgi paylaşımı ve yarışmalar yapılan siteler, özgür yazılım projelerine ev sahipliği yapan GitHub, GoogleCode gibi siteler belli başlı kaynaklar.

Ancak kendinizi görünür kılmanın en kolay ve etkili yolu bir özgür yazılım projesine katkıda bulunmak. Bu konuda geçen sene başında Javascript'çilerin ismini tanıyacağı bir geliştirici, John Resig İşe alma söz konusu olduğunda, bir Github commit'ini herhangi bir CV'ye tercih ederim diye bir laf etmişti ve epey tartışma yaratmıştı. Bu kapalı kod üreten işlerde çalışanların çok işine gelen bir durum değil. Bir şirkette onbeş yıl çalıştıktan sonra elinizde başkalarına göstermeye izniniz olan herhangi bir örnek kodunuz olmayabilir. Ancak eşitsiz ve acımasız da olsa gidişat bu yönde, çünkü birisinin yazılım becerisini değerlendirmenin en kolay ve hızlı yolu yazdığı koda bakmak. Özgür yazılım projelerinde kişinin test ve belge üretme, diğer geliştiricilerle ve kullanıcılarla birlikte çalışma gibi çok daha önemli özellikleri de bir ayna gibi görülebiliyor.

Tabii ki her projenin görünürlüğü farklı derecede. İş ilanlarından güncel bir derleme yaparsak, mesela Nginx, haproxy, Hadoop, memcache, Redis, MongoDB, puppet, vb gibi özgür yazılımlar epey sık geçiyor. Dolayısıyla bunlar üzerindeki deneyim ve katkılarınız daha çok ilgi çekme şansına sahip. Yazılımların sayfalarında yada şirketlerin mesela performansla ilgili sunumlarında neler kullandıklarını daha yakından görebilirsiniz.

Bir şekilde bağlantıya geçtikten sonraki adım ön eleme. Burada genelde daha önce yaptığınız işler, şirketin neler yaptığı, işin ilginizi çekip çekmediği gibi daha klasik konular konuşulmakta ve mesela şirketin yazılımcılarından biriyle kısa süreli bir telefon görüşmesi yapıp teknik bilginiz değerlendirilmekteydi. Ancak son zamanlarda arttığını gördüğüm bir uygulama daha var. Size bir problem ve bu problemi çözmek için yazılmaya başlanmış bir program gönderiyorlar, birkaç saat içinde programın hatalarını ayıklayıp, yeni özellikler ekleyip, belki bazı kısımları daha düzgün şekilde yeniden yapılandırıp geri gönderiyorsunuz. Programın çalışması kolayca test edilebileceği için şirketin yazılımcılarının incelemesinden önce epey bir eleme yapılabiliyor.

Asıl görüşme kısmı ise neredeyse tamamen Google modeline dönmüş durumda. Yarım gün falan süren, tamamen teknik konulardan oluşan ve tahtada kod yazılan zorlu bir sınav. Ağaç ve graph yapıları, arama ve sıralama, karmaşıklık gibi teorik konular, bildiğiniz programlama dilinin en ince detayları, işletim sistemi, ağ ve bilgisayar mimarisi. Bazı firmalar bu konsepti yalnızca gördükleri kadarıyla taklit ettikleri için, anlamsız derecede zor yada adaletsiz sorular sorabilirler. Bazı firmalar ise üniversite CS eğitiminin üzerinde ve gerçekten etkileyici yanıtlar bekleyebilir. Burada başarılı olmak için günceli takip etmek gerekiyor. Bildiğiniz sıralama algoritmaları Quick, merge ve heapsort'tan ibaret olmasın. Ağaç deyince aklınıza binary tree değil, Suffix tree, R tree, Radix tree, Judy array falan gelsin.

Bu konuları öğrenecek bir dolu kaynak var internette. Mesela AI Class, Udacity ve ML Class özellikle istatistiksel yöntemler ve yapay zeka konusunda çok başarılı kaynaklar. Bir diğer yardımcı da yine özgür yazılımlar. Favori yazılımlarınızın hangi algoritmaları kullandığına baktınız mı hiç? Mesela bellekte bir kopyalama işlemini nasıl en hızlı yaparsınız? eğer glibc kodunu açıp memcpy fonksiyonuna baktıysanız cevabı görmüşsünüzdür :) Ya da mesela onbinlerce bağlantıyı aynı anda yönetebilen bir sunucu nasıl yazılır? Nginx, lighttpd ve Apache gibi özgür yazılımların içinde buna dair ipuçları olsa gerek değil mi?

Bütün bu tantana yalnızca almışken daha iyi elemanı alalım kaygısından ya da beğenilen bir şirkete girmeye çalışmaktan kaynaklanmıyor. Gelişen teknoloji ve artan kullanıcı sayısıyla birlikte işlenen veri inanılmaz boyutlara ulaştı ve bu veriden çıkarılacak anlamlı sonuçlara, en başta reklam sektörü tarafından, çok büyük paralar ödeniyor. Dolayısıyla daha hızlı, daha az kaynak kullanan, daha başarılı sonuç üreten ürünler aslan payını kapıyor. Burada rekabet hem algoritma seviyesinde, hem de o algoritmayı en ideal biçimde gerçekleyeceğiniz uygulama seviyesinde.

Bu düzeye yalnızca dört senelik üniversite eğitimiyle (hele hele ar-ge yapılmayan ve seviyesi düşük üniversitelerde) ya da hobi seviyesinde bir programcılık ilgisiyle gelmek mümkün değil. Mutlaka zorlu problemlerle karşılaşıp bunlara çözümler geliştirmeniz, bir yandan da teorik bilgilerinizi sağlamlaştırmanız lazım.

Böyle bir hedefiniz varsa, stajınızı, çalışacağınız şirketleri, yapacağınız kişisel projeleri dikkatle seçmeniz gerekli. Mesela yüksek maaşlı ancak rutin ve yıpratıcı bir işe girip, uzun bir süre çalıştıktan sonra oraya çakılı kalıp, daha iyi bir noktaya geçme şansınız kalmadığını farkedebilirsiniz. Yaptığınız işin başkaları tarafından görülebilir olmaması ve yeni şeyler öğrenmenizi gerektirmemesi çok tehlikeli kariyer riskleri.

10 comments...

Yazılım geliştiricinin çevik olanı...

20 February 12, Monday @ 17:47

Çalıştığım şirkette epey bir süredir Agile (Çevik) yazılım geliştirme metotlarından biri olan Scrum (Ragbi oyununda takımın bir mesafeyi almak için kafa kol girişmesini ifade eden bir terim :) uygulanıyor.

Agile yaklaşımın temelinde gereklerin geliştirme süreci boyunca değişeceği, dolayısıyla yazılımın artımsal olarak kısa adımlarla geliştirilmesi, müşterilerin ve geliştiricilerin süreç boyunca etkileşimi, yazılımın her anında çalışabilir olması gibi bazı genel fikirler var. Scrum ise bu fikirlerden yola çıkıp geliştirme ve planlama sürecinin nasıl yürütüleceğini ayrıntılı olarak (ve süslü deyimlerle) tanımlayan bir yöntem.

Bu yöntemler hakkında detaylı bilgi internette bulunabilir, ben yalnızca deneyimlerimden yola çıkarak öznel görüşlerimi aktaracağım.

İlk olarak, Scrum geliştirme işinin teknik yönüyle ilgili çok az şey içeriyor. Kodlama standartları, sürüm kontrol, inşa, test, vb pratikleriniz olduğunu varsayıp devam edelim.

Scrum takımı, geliştiriciler, ürünün önceliklerini belirleyen bir product owner (ürün sorumlusu) ve Scrum süreçlerinin yürütülmesi, geliştiricileri bloklayan engellerin kaldırılması, varsa diğer takımlarla iletişim gibi işleri yapan ve belli aralıklarla değişebilen bir Scrum Master'dan (Scrum yöneticisi) oluşuyor.

Scrum süreci sabit sürelerle yapılan geliştirme hamleleri (sprint) şeklinde. Bu süre genelde birkaç hafta. Her sprint başında yapılacak işler planlanıyor ve sprint süresince bu planlama değiştirilmiyor. Tabii bu süre bazı işler için küçük bazıları için büyük. Scrum'ın buna çözümü, işleri kendi başına çalışan ve sorunun çözümünde bir miktar ilerlemeye karşılık gelen küçük adımlara bölmek ve her Sprint sonunda bir miktar çalışmayı ürüne katıp o adımı geçmiş olmak. Kağıt üzerinde mantıklı da gelse, uygulamada işler bu kadar basitçe adımlara ayrılamıyor elbette. Bazı durumlarda işi artımsal adımlara bölmek toplamda daha uzun zamanda bitmesine yol açabiliyor. Ara adımlarda çıkan ürünlerin kullanıcılara ulaşması da, bakım zorluğu yaratacaksa istenmeyen bir şey olabilir. Kimi zaman da sprint bitmeden bir özelliği yada hata düzeltmeyi ürüne katıp müşteriye sunmak isteyebilirsiniz. Dogmatik yaklaşmayıp bu tür durumlarda esnek davranabilirseniz sprint yönteminin genel olarak zararlı olmadığını düşünüyorum.

Her gün belirli bir saatte, ekipteki herkesin geçen gün ne yaptığını, bugün ne üzerinde çalışacağını ve devam etmesine engel olabilecek her türlü engeli anlattığı günlük toplantı (standup) yapılıyor. Bu toplantının ayakta ve aynı odada yapılması vb gibi bir dizi kural var ama siz şekilselliğe değil amaca bakın. Önemli olan kısa sürmesi, herkesin birkaç cümle söyleyip birbirinin yaptığından haberdar olması. Amaç ekibi onbeş dakkada senkronize edip, o gün başka toplantıların yapılmasına engel olmak! Scrum'ın pratikte en faydalı uygulaması bence bu.

Akla gelen her özellik ve geliştirme önerisi, user story (kullanıcı hikayesi) adı verilen ve genellikle "bir Gazeteci olarak kelime işlem programında sözcükleri sayabileceğim bir özellik istiyorum, böylece istenen uzunluğu aşmadan yazabileceğim" gibi birinci ağızdan yazılmış fonksiyonel iş tanımları olarak, backlog (yığılmış iş) adı verilen bir listeye ekleniyor. Sprint başında takım bu listeden o sprint süresince yapılacak işleri seçiyor. İşlerin fonksiyonel ve açık biçimde belirtilmesi (user story'ler işin tamamlanma koşullarını ve çeşitli testleri de içerebilir) faydalı bir yaklaşım, ancak backlog fikrini doğru bulmuyorum. Bu konuda Rework çok daha akıllıca bir yöntem öneriyor: Uzun listeler moral bozmaktan başka bir işe yaramaz. Eğer bir işi bir kenara yazmadığınızda unutuluyorsa zaten sandığınız kadar önemli ve yapılması gereken bir şey değildir. Müşteriler ile sürekli bir iletişiminiz varsa zaten size en öncelikli ve gerekli işi sürekli hatırlatacaklardır.

Burada bir sorun da, ürün kalitesini arttıracak ama müşteriye direk yansımayan ufak işleri sıraya almanın çok zor olması. Bunları ya kendi başınıza yapacaksınız, değerlendirmelerde gözükmeyecek ve bunlara harcadığınız zamanın hesabını veremeyeceksiniz. Ya da bunlara birer user story oluşturmak yada eldekilerden birine eklemek için hem zaman hem de ekibi ikna edip sıraya aldırmak için enerji harcayacaksınız.

Backlog'a atılan user story'ler takım tarafından zorluk ve tamamlanma sürelerine göre puanlanıyor. Bu puanlar o sprint'te başlanacak işleri belirlerken ve süreç boyunca burndown chart, velocity gibi süslü isimleri olmasına karşın aslında oldukça basit istatistikleri oluştururken kullanılıyor. Amaç takımın verimini ve işlerin yürüme hızını gözlemlemek ama burada detaylarına girmeyeceğim bir dizi kurnazca yöntemle yapılmalarına rağmen neredeyse hiç bir işe yaramıyorlar. Puanlama, eğer kendinizi kandırmıyorsanız, işe başlamadan bilemeyiz demekten ibaret. Diğer istatistikler ise elma ile armutu karşılaştırıyor.

Bu ölçme girişimleri ar-ge'yi teneke kutu üretimi sanan yöneticileri tatmin etmek için icat edilmiş olsa gerek. Onlara kötü bir haberim var, eğer projeyi en ufak detayına kadar kavrayabilecek kadar bilginiz yoksa bir ar-ge projesini yönetemezsiniz. İyi niyetliler sizi terkeder, kötü niyetliler metriklerinizi kandırır. Bu noktada maalesef velocity yıllar öncesinin kod satırı sayısı kavramından bir adım öteye geçebilmiş değil. Benim önerim şu: projeyi takip mi etmek istiyorsunuz, gidip commit eposta listesini okuyacaksınız. Anlamıyorum olup biteni diyorsanız da proje yönetmeyin lütfen!

Scrum kabaca böyle. Doğru uygularsanız faydalı olabilecek bazı pratikleri var. Bir bütün olarak almayıp, her pratik için bu doğru mu? ve benim durumuma uygun mu? diye sorgulamanızda fayda var. Şekilselliklerinden ve seremonilerinden ise kaçının derim, gülünç duruma düşmeyin.

Agile felsefesine daha uygun başka uygulamalar da mevcut. Bu yazının kapsamı dışındalar, o yüzden netten kendiniz araştırabilirsiniz. Ayrıca herhangi bir çelişki halinde Rework kuralları daima geçiş üstünlüğüne sahiptir :)

3 comments...

Yeni dünyadan bir takım izlenimler

02 January 12, Monday @ 21:20

Bir yıla yakın süredir Amerika'da yazılımcı olarak çalışmaktayım. Çalıştığım şirket Princeton'dan akademik olarak ortaya çıkıp, önce bir startup oldu, daha sonra da büyük bir şirket tarafından satın alındı. Bu tür hikayeler yeni dünyada çok sıradan, girişimcilik günlük yaşamın parçası. Peki biz (yalnızca Türkiye değil, bütün Avrupa) bu kültürden ne kadar uzağız?

Silikon vadisinin gizli tarihi adlı bu video, Amerikan üniversitelerinin dünya savaşının peşinden savunma projelerinde yer almaya başlamasını, bu işlerin içindeki Frederick Terman gibi profesörlerin Stanford'a gelerek, öğrencilerin şirketler kurarak araştırmalarını ticarileştirmelerini teşvik etmesi, böylece vadinin HP, Intel, vb gibi ilk nesil teknoloji firmalarının ortaya çıkışını anlatıyor. Ortaya çıkan model çok özgün. Üniversite temel bilim araştırmalarının yapıldığı bir merkez görevini alıyor. Bu araştırmaları yapan öğrenci ve profesörler, işi somut bir ürüne dökmek istedikleri zaman dışarı çıkıp şirket kuruyorlar ve üniversite onlara araştırma sonuçlarının kullanımı için gerekli her türlü lisans ve kolaylığı sağlıyor.

Modelin başarısı, amacı insanlığın bilgi birikimini arttırmak olan araştırma çabaları ile, insanlığın bir ihtiyacını karşılamayı hedefleyen geliştirme çabalarını birbirinden ayırmış olmasında bence. Araştırma, önceden planlanamayan ve kısa vadede kâr getirmeyen, dolayısıyla bir zaman engeli taşımadan özgürce yapılabileceği bol kaynaklara ve ortama ihtiyaç duyan bir faaliyet. Geliştirme ise, gene planlaması çok zor da olsa, ihtiyaç duyacağı kaynakların gerekliliğini ispatlayabildiği ve tasarım sınırları dahilinde yürütüldüğü sürece ortaya daha başarılı ürünler çıkaran bir süreç. Akademisyenlerin özgürce bu iki dünya arasında geçiş yapabilmesi, doğru bilgilerin doğru ürünlere dönüşmesini çok destekleyen bir sistem.

Türkiye'de bu konudaki ilk sorun akademi ve özel sektör arasındaki büyük maaş uçurumu. Pek çok meslek gibi akademisyen maaşı da rahat bir hayat sürmeye yeterli değil, bu yüzden çoğu parlak genç özel sektörde bol mesaili dolayısıyla araştırma ya da boş vakit içermeyen bir işe girip akademiden tamamen kopuyor. Geçim sorunu yaşamayıp akademide kalabilenler ise devlet memurluğuna tabiyetten öyle kolay kolay şirket kurmak ya da ticari işlere girmek imkanına sahip değiller. Bu ekonomik nedenler üniversitelerdeki hocaların ve dolayısıyla eğitimin kalitesini de düşürüyor. Üniversite devletin verdiği paraya ya da zengin öğrencilerin harçlarına bağlı yaşayan bir meslek okulu pozisyonuna girince, buradan kendi başına ayakta durmayı öğrenmeden çıkan öğrenci de, kendine güvenden yoksun kalıyor. Tek marifeti zamanında dedesinin doğru bir araziyi satın almış olması ya da devlet tarafından zorla zengin edilmiş olmak olan uyduruk bir iş adamının yanında çalışmayı bile büyük bir hedef olarak görüyor. O adamla rekabet edebilecek bir iş kurmayı düşünmüyor bile.

Silikon vadisindeki model kurulduktan sonra, para kaynağı konusunda büyük değişimler geçirmiş. Savunma sanayi yerine normal tüketiciye yönelik ürünler geliştirmeye başlamış ve ilk başta kendi imkanlarıyla para bulan şirketler için bir sürü özel yatırımcı ve yatırım fonu ortaya çıkarak bugün Venture Capital denen girişim sermayesi piyasasını oluşturmuş.

Bu sektörü oluşturan neden tabii ki girişimlerin büyük kazanç getirme şanslarının yüksek oluşu. Ancak sektörün bu kadar büyümesinin nedeni sırf bu değil. Basit bir hesap yaptım, yaklaşık 10.000$ gibi bir miktardan daha büyük paralar için, bu parayı Amerika'dan Türkiye'ye yollamak, 3 aylık faize koyup sonra geri getirmek, tüm transfer ücretlerine rağmen, Amerika'da herhangi bir klasik faiz enstrümanına yatırmaktan daha kârlı. Faiz kazançları bu kadar düşük olunca, para sahipleri ya oturup somut bir iş yapmak, ya da parayı bu tür girişimlere yatırmak zorunda kalıyor. Bizde ise bırakın faizi, taksi plakası gibi absürd enstrümanlarla parayla para kazanmak varken parayı bir işe harcamak akıllıca bir hareket olmuyor (nasıl bu kadar yüksek faiz verebildiğimiz ise Türkiye ekonomisinin büyüdüğünü sananları yakın bir tarihte çok şaşırtacak ayrı bir hikaye).

Bu iki durumun oluşturduğu bir üçüncü durum daha var, o da girişimcilerin profili. Amerikan teknoloji şirketlerinin yatırımcı, kurucu ve üst düzey çalışanlarının büyük kısmı akademi ya da endüstriden gelen ve bağlarını koparmamış kişiler, zenginlik kaynakları ise hep teknolojik başarılar. Bu profilin getirdiği avantaj bu kişilerin zenginliklerini yeni girişimler için kullanma yüzdelerinin oldukça yüksek olması. Bu da gözü çalışanlarına iki saat daha fazladan mesai yaptırma, primlerini vermeme ve ar-ge harcamalarını mümkün olduğunca kısma derdinde olan feodal işadamı profiline göre büyük bir avantaj.

Türkiye'de "üniversite sanayi işbirliği" üzerine çok yazılıp çizildi. Bu konuda Tübitak gibi kurumlar kuruldu çalışmalar yapıldı. Cahit Arf'ın anılarında özellikle sanayicilerin Tübitak'a gelip şöyle teknik problemim var çözün diye istekte bulunmamalarından yakındığını hatırlıyorum. Yukardaki modeli gördükten sonra bunun niye yürümediğini anlamak kolay. Girişim o yönde çalışmıyor, yeniliği sizin yapıp müşteriye götürmeniz gerekli. Zamanla Tübitak da (özellikle son zamandaki mesela Feza Gürsey Enstitüsünün kapatılması gibi değişikliklerle) temel bilim desteğini azaltıp ürüne yönelik geliştirme yapan dolayısıyla çeşitli konularda özel sektörü de baltalayan bir yapı haline geldi. Teorik araştırmalar olmadan yapılan geliştirme yabancı ürünlerin ucuz benzerlerini yapmaktan öteye gidemiyor maalesef.

Son olarak tüm bu faktörler sağlanıp, bir başlangıç ivmesi sağlansa bile çok zamana ihtiyaç olacak, çünkü neredeyse bir yüzyılda ve sayısız başarı ve başarısızlıktan sonra edinilmiş bir kültüre sahip olmak kolay değil.

10 comments...