Sürdürülebilir Ekip Performansı

Zamanında Almanlarla bir proje yapıyorduk. Bir ekip toplantısında bahsetmiştim onlara; bizde "Türk gibi başka Alman gibi bitir" diye bir söz vardır diye. "Ee ekip hem Alman hem de Türkler'den oluşuyor, bu iş olur" gibisinden lafa girmiştim bir yerlerde. Sonrasında, elemanlar suratıma kös kös bakınca, olayı daha da detaylı açıklamam gerekmişti :)

İşin Türk gibi başla kısmına gelirsek, uzun soluklu projelerde sürdürülebilir performans gösteren bir kültürümüz maalesef yok. Hızlı ve canavar gibi başlayan projeler, akabinde projelerinin ortalarına geldikçe tükenmiş ve motivasyondan düşmüş insanlar, sonrasında terk-i diyar eyleyen arkadaşlar. Bu senaryo memleketimizin güzide köşelerinde bir yerlerde yaşanıyordur muhakkak.

Bir iş tamamlanmadıktan sonra bir işe yaramıyor elbette. O yüzden bir işi tamamlamaya odaklanmamız ve gerekirse can alıcı performansı sonda gösterilecek bir motivasyon planı oluşturmamız gerekiyor.

Bu aşamada da uzun soluklu planlı mesailerden, negatif insanlardan, macera arayışlarından (kısa vadede bir heyecan yaratsa da, tutmadığı durumlarda ileri safhalarda acı ve göz yaşı ile telafi edilmesi gereken bir durum ortaya çıkartabiliyor) ve ekibi gereksiz stres yapmaktan mümkün olduğu kaçınmak bir projenin selameti için elzem görünüyor.  Her şeyi önceden kestirip bir plan yapmak uzun soluklu işlerde biraz gerçek dışı olmakla beraber; yakışıklı ve uyarlanabilir bir plan ile birlikte, işleri zamanında bitirecek ve bu arada da çeşitli vesilelerle ekibi diri tutacak bir yol haritası herkes için güzel bir tecrübe yaratacaktır diye düşünüyorum.

Son olarak gene stresi azaltıcı faktör ve aslında bir best practice olan bir uygulama olarak; bir projenin çıktısının projenin sonunda büyük bir sürümle değil de, arada yapılacak küçük sürümlerle devreye alınmasını tavsiye edebilirim. Bu ekipte hem bir ilerleme hissi yaratırken, müşteride de bir katma değer yaratacak; hem de sondaki büyük gerilimi büyük ölçekte elemine edecektir.

Daha Çok Okumanın Yollarını Ararken

Kitap okuyan bir insan mıyım derseniz, kendimi iyi bir okuyucu olarak tanımlamamakla beraber; evet derim aslında. Kızıma okuduğum hikaye kitaplarını saymazsak, genellikle işime değer katacak kitapları okumayı da tercih ediyorum. Ama takdir ederseniz ki bizim sektör o kadar hızlı ilerliyor ve o kadar öğrenilecek şey var ki; ortama 350 sayfa deseniz (referans nitelikteki kitapları hiç saymıyorum bile, kafanıza düşse öldürür) bir kitabı baştan sona okumak büyük bir emek istiyor. Hele yabancı bir dildeyse (Türkçe zaten pek bulunmuyor) daha da fazla emek istiyor.

Geçmişte; bu probleme bir çözüm lazım dedim ve şirketimizde açılan bir Hızlı Okuma kursuna kaydoldum (Alge adlı bir firma tarafından verilmişti, herkese de muhakkak tavsiye ederim). Buradan biraz artı topladım ama özellikle yabancı dildeki bir kitabı bu kadar hızlı okuyamıyorum hala. O yüzden eğitimde de bahsedilen Etkin Okuma yoluna daha ağırlık verdim.

Okuduğum kitaplar konusunda zaten seçici olmuşumdur. Eskiden içindekiler kısmına çok dikkat etmezdim. Şimdi özellikle dikkat ediyorum ve hatta okumam gerektiğine ikna olmadığım bölümleri atlıyorum. Bir de reel olarak bakarsanız bence bir kitabın ana fikri ve anlatmak istedikleri bütün kitap hacminin %20'si oluyor. Zaten bir kitabında da bu kadarı ancak aklımızda kalıyormuş. Bu noktada da
laf salatası yerlerde dikkatli bir şekilde atlayarak okuma yoluna gidiyorum.

Bunlar benim bulduğu teknikler değil elbette. Bahsettiğim eğitimde konu teknikleri tecrübe ederek, daha etkin okumanın yollarını arıyorum. Sizin de tavsiyeleriniz olursa mutlaka beklerim.

Bazen Platform Mimarisine de Dikkat Etmek Lazım

Küçük bir Internet Explorer add-on yazmam gerekiyordu ama kısa bir müddet de olsa sinirimi bozdu doğrusu. Hayır, sinirimi bozan yazmak değil; her zamanki gibi çalışması gereken bir şey çalışmıyordu :)

Geliştirmeyi C# ile yapıyordum. Bu iş için öncelikle bir COM nesnesi oluşturmak ve bunu regasm aracı ile kaydetmek lazım. Browser Helper Object diye aratınca zaten aynı örneği göreceksiniz. Regasm aracı ile dll dosyamızı kaydedince, IE add-on listesinde, yazdığınız add-on da görünecektir. Buraya kadar herşey güzel gidiyor zaten. Sorun şu ki bu add-on neden tetiklenmiyor :) Eğer bu noktaya gelecek olursanız dediğime kulak verin. Esasında aynı sorun bir çok COM senaryosunda da yaşanabilir.

Any CPU olarak derlememe rağmen, IE add-on listesinde benin yazdığım arkadaşın yanında sadece "32 bit" yazıyordu. Bu arada 64 bit bir ortam kullandığımı belirtmemde de fayda var. Diğer add-on'ların yanında da "32 ve 64 bit" gibi bir ifade var hepsinde. Regasm aracını, VS Command Prompt'tan direk çağırınca path altında olduğu için zaten kullanılabiliyor. Fakat "c:\Windows\Microsoft.NET\Framework\v4.0" altındakinin kullanıldığını gördüm ($>where regasm komutu ile siz de görebilirsiniz) "c:\Windows\Microsoft.NET\Framework64\v4.0" altındakini kullandıktan sonra geçersiz bir .NET assembly'si kaydetmeye çalıştığımı iddia etse de; derleme seçeneklerinde Any CPU'dan x64 platformuna çekince problemlerim toptan çözülmüş oldu.

.NET uygulamalarında, genelde, platform mimarisi ile çok işimiz olmaz. Any CPU olarak derledikten sonra her türlü çalışmasını bekleriz; ama 3ncü taraf ortamlar ve kütüphaneler olunca bu büyü bozulabiliyor. Elbette regasm aracı da bu işin tuzu biberi oldu ve olan 1 saatime oldu.

Yazılım Projelerinde Tahminleme Derdi

Wikipedia'ya göre,  projenin tarifi aşağıdaki şekilde verilmiş:

Proje, bir probleme çözüm bulma ya da beliren bir fırsatı değerlendirmeye yönelik, bir ekibin, başlangıcı ve bitişi belirli bir süre ve sınırlı bir finansman dahilinde, birtakım kaynaklar kullanarak, müşteri memnuniyetini ve kaliteyi göz önünde bulundururken olası riskleri yönetmek şartıyla, tanımlanmış bir kapsama uygun amaç ve hedefler doğrultusunda özgün bir planı başlatma, yürütme, kontrol etme ve sonuca bağlama sürecidir.

Yani projeyi konuşuyorsak, bir başının ve sonunun olması gerekiyor. Bunun için de en temelinde yapılabilecek işin ölçülebilir olması lazım doğal olarak. Peki yazılım projelerini göz önüne alırsak, bu ne kadar mümkün? Şu teknik bu teknik vs. falan bahsetmek istemiyorum. Ben gerçekten bunun ne kadar mümkün olduğunu sorguluyorum :) Bir yazılım projesinin %100 tahmin edilebilmesi için şartları sıralayım:

1) Yapılacak işin en ince detayına kadar biliniyor olması
2) Baştan çıkartılacak analizin %100 değişmez ve hatasız olması
3) En doğru teknik çözümün 1 kerede baştan çıkartılmış olması
4) Projede görev alacak insanların kesin belirlenmiş olması ve taslak olarak belirlenmiş görevlere yetkinliklerine göre atanmış olması. Ahmet'in 2 günde yapacağı, Mehmet 5 günde yapabilir; bu çok doğal bir durumdur ve süre üzerinde etkisi vardır.  Gene de bütçe tarafında değişikliklere sebep olma pahasına, kaynak yönetimi ölçeklenerek süre üzerindeki etkisi zayıflatılabilir. Tabii ki projenin tanımındaki "sınırlı finansman" tabirinin de altını çizmek lazım :)
5) Proje kadrosunun bu işe benzer işleri yapmış olması (Aksi takdirde tahminleme işin niteliğine göre daha büyük bir risk içerecektir)

Yukarıdaki şartların bir araya gelmesi mümkün mü? Bence, işin çapına göre elbette mümkün. Fakat bu işin içerisinde olan herkes görmüştür ki gerçek dünyadaki işler çoğunlukla bu şekilde ilerlemiyor.

***

Bu yazımda bu derde bir çözüm önerme işine girişmeyeceğim ama bir probleminin çözülemediğini düşünüyorsanız, zaten o problem var olduğu şartlarda çözülemiyordur. Bu problemi çözmek için öncelikle şartları ve bakış açını değiştirmek gerekmektedir.

Bu yazıyı okuyan herkes eminim, yazar acaba ne zaman çevik yöntemleri övmeye başlayacak diye düşünmüştür sonuna gelene kadar :) Tarz olarak uzun uzun derdini anlatmayı seven bir insan değilim. Birinin yalın bir şekilde anlatabileceği meramını uzun uzun okumaktan da hoşlanmam aslında. Çevik yöntemlerin bu konuda ki yaklaşımı da kısa bir yazıda anlatılabilecek bir konu değil. Zaman zaman, olabilecek en yalın şekilde bu konuda da paylaşımlar yapmak isterim kısmet olursa.

Aşırı Mühendislik (Over-engineering)

Bu yazında, yazılım geliştirirken ara sıra yapılan bir gafletten bahsetmek istiyorum. Gaflet de şu ki; bir problemi en efektif-yalın şekilde çözmek yerine, sırf bazı kalıplara uysun ya da daha fazla haz alalım diye daha karmaşık çözümlerin uygulanması gibi bir hastalık her kodşinasın içinde vardır herhalde.

Bu tarz durumlara iki örnek vermek gerekirse:

1) Framework yazma sevdası. İşe konsantre olmak yerine, girişilen framework yazma maceralarında eminim sıkıntıya düşmüş çok proje vardır. Bir framework tabii ki bir proje için hayat kurtarıcı olabilir, hatta ve hatta yokluğu büyük bir kaos yaratabilir; ama özellikle önden büyük bir tasarımla girişilen framework, projenin gelişen ihtiyaçları doğrultusunda yetersiz kalabileceği gibi (yetersizden ziyade, ihtiyaçları doğru karşılamaması daha büyük bir risk) akabinde daha fazla bir iş yükü çıkartmaya başlayabilir.

2) Tasarım desenleri yerinde ve amacına uygun kullanıldığı vakit tadından yenmez. Lakin ve lakin, her şeyi mükemmel bir nesne yönelim anlayışı ile çözmeye çalışırsak; ortaya basit yerine, gereksiz karmaşık bir yapı da çıkabilir. Mesela, basit bir if-else ifadesini ele alalım. En temel refactoring'lerden biri burada strateji deseninin uygulanması olabilir. Fakat 3-4 satırlık kodu, ben desen uygulayacağım sevdası ile daha karmaşık bir yapı ile sonuçlandırabiliriz. Bunun elbette gerekli oldu birçok durum vardır elbette ama bu karmaşıklığın bir geri dönüşünün de olmasını beklemek bana daha mantıklı geliyor.

***

Yazılım camiasında her zaman her yerde geçerli kurallar bulmak zordur. Yukarıda anlattıklarımı lütfen bir genelleme olarak değerlendirmeyin. Her çözüm, kullanıldığı bağlamı dikkate almak zorundadır. Bunun da kantarı akıl, izan ve gereksinimlerdir.  Bu noktada KISS ve YAGNI   presiplerini referans almak akıllıca olacaktır.