Search Results for: sorumluluk

Analist ve İş Bilgisi

İş ve İhtiyaç Analizi, Yazılım Mühendisliği , , ,

Giriş

Soru şu: Analist yani bazen iş analisti, bazen ihtiyaç ya da gereksinim analisti bazen de daha klasik bir isimlendirmeyle sistem analisti dediğimiz rol için iş bilgisi ne kadar önemlidir? “Hoppaaa! Böyle de soru mu olur?” demeyin. Ben de farkındayım, iş bilgisinin, analistin varlık sebebi olduğunun. Analistin en temel sorumluluğudur iş bilgisi, tamam da demek istediğim şeyi açıpa çıkarabilmek için şu soruyu da sorayım: Analistin, benzer şekilde iş bilgisine sahip operasyonel bir kullanıcıdan farkı yok mudur? Vardır deriz ama nedir tam olarak bu fark? Daha analitik olması, daha iyi sorular sorabilmesi, ya da iletişiminin daha güçlü olması mıdır sadece?

Analist Yetkinlikleri

Konuyu biraz açayım. Analistin yetkinlikleri 3 boyutta ele alınabilir:

  1. İş alanı bilgi ve yetkinlikleri (business/application domain knowledge and skills): Analistin çalıştığı sektördeki terimlere, süreçlere, rollere ve çıktılara ne kadar hakim olduğu, onun iş bilgisinin ölçüsüdür. Örneğin bankacılık sektöründeki bir analistin çalıştığı alt alanın krediler olduğunu düşünelim. Bu analist, kredilerle ilgili başvuru ve değerlendirme süreçlerini bilmesi, bunlarla alakalı analiz toplantılarında bulunması vb. yetkinlikler, analistin iş alanı ile ilgili yetkinliklerine örnektir.
  2. İş ve yazılım ihtiyaç analizi bilgi ve yetkinlikleri (business and software requirements analysis knowledge and skills): Analistin, formal olarak bir süreci tanımlayabilme, oradaki adımları, iş kurallarını ve aktörleri detaylarıyla belirleyebilme, detaylar arasındaki benzerlik, farklılık, çelişiklik vb. çıkarımları yapabilme, bu bilgileri bir yazılıma dönüştürebilecek şekilde daha formal ve matematiksel formlara örneğin diyagramlara dökebilme, ihtiyaçlarla alakalı önceliklendirme ve risk analizi yapabilme ve tüm bunları dokümana yansıtma yetkinlikleri.
  3. Bireysel yetkinlikler (individual skills): İletişim, ikna, sorgulama, toplantı yönetimi vb. daha yumuşak yetkinlikler (soft skills). Örneğin bir analistin iyi bir dinleyici olması, iyi not alabilmesi, hızlı ve analitik düşünüp çıkarımlarda bulunarak bir analiz toplantısında geri sorularla muhatabını yönlendirebilmesi, çatışan ihtiyaçlara sahip kullanıcılar arasında inisiyatif alabilmesi, onları yönlendirmesi ve karar verilmesini sağlayacak girdileri sunabilmesi vs. bu türden yetkinliklerdendir.

Yukarıdaki 3 farklı yetkinlik alanından hangisi sizce en önemli olandır? İş bilgisi mi, işi çözümleyebilme yetkinlikleri mi yoksa müşteriyle daha iyi iletişim kurabilme yetkinlikleri mi?

Ülkemizde eğitim ve danışmanlık vesilesiyle gittiğim yerlerde bunu devamlı gözlemliyorum. Hatta ben de, tam zamanlı çalışırken ya da sonrasında danışmanlıklarda, uzun seneler analist işe alımıyla uğraştım ve uğraşıyorum. Dolayısıyla analist işe alma ve seçme süreçlerinden haberdarım. Özellikle eğitimlerde ve seminerlerde katılımcılara soruyorum, sizin kurumunuzda hangisi daha çok öne çıkıyor diye. Örneğin, “siz buraya hangi yetkinliklerinizle alındığınızı düşünüyorsunuz?” diye soruyorum. Elde ettiğim kanı şu: Ülkemizde analist denince akla gelen en temel şey, iş bilgisidir. Tabiri caizse, işi bilmek, o sektörde senelerdir bulunmuş olmak, genel olarak bir kişiyi analist olarak tanımlamada kullanılan en temel etmendir. İkinci sırada gelen, bireysel yetkinliklerdir. Yani iletişimi güçlü mü, müşterilerle konuşurken ne kadar düzgün cümleler kurabiliyor vs. Bu iki yetkinliği bir araya getirdiğimizde, işi bilen ve iletişimi güçlü kişi, ülkemizde mükemmel analist adayıdır. Kurumlar kendi kültürlerine göre bu iki faktörden birisine daha fazla önem verebilirler. Yani örneğin bir kurum, özellikle daha az tecrübe seviyelerinde, iletişim becerileri güçlü bir adayın zekasına da güvenerek, iş bilgisini hızlıca elde edebileceğini düşünerek onu analist olarak işe alabilir.

Bu yazıyı yazdığıma göre benim de kendi fikrimi belirtmem gerekir. Bence bir analistin en temel yetkinliği, rolüne adını veren, iş ve yazılım ihtiyaçları analizi bilgi ve yetkinlikleridir. Bir analist, her şeyden önce, bir süreci nasıl ifade edeceğini, o süreçteki tüm adımları, aktiviteleri, aralarındaki ilişkileri, çıktıları, süreçte yer alan rolleri ya da aktörleri, süreçler arasındaki ilişkileri, süreçleri yönlendiren iş kurallarını vs. ortaya koymakla sorumludur. Bu yetkinlikler, tabi olarak farklı sektörlerde edinilen tecrübeyle kazanılır ama nihayetinde sektörden bağımsızdır. Bir örnek vereyim: Bir süreçte, durumu önemli olan ve farklı durumlar arasında gezen temel bir nesne var. Örneğin bir başvuru sürecinde, başvurunun pek çok duruma sahip olması, buna iyi bir örnektir. Başvuru ilk defa alınmış olabilir, ön elemeyi geçmiş, evrakları bekleniyor, son incelemede, vb. durumların birinde olabilir. Tüm bu durumların, sonlu durumlu bir makina (finite-state machine) olarak ortaya konması, yani durumlar ve aralarındaki geçişlerin detaylı olarak ortaya belirlenmesi yetkinliği, ne bir iş bilgisi ne de iletişim yetkinliğidir. Bu yetkinlik, analisti en temelde analist yapan şeydir. Böyle bir modelleme yetkinliğine sahip bir analist, herhangi bir iş alanında sonlu durum makina modellemesi yapabilir, oluşturduğu modelin tasarımda bir durum tasarım kalıbıyla (state design pattern) tasarlanmasını sağlayabilir ve nihayetinde de developerlar dahil herkes kendisine duacı olur. Çünkü böyle çok durumlu nesneler, kodlamada en problemli nesnelerdir, sebebi ise iş bilgisi çok yüksek olsa bile analistin bu durumları formal bir şekile çözümleyip ifade etmemiş ya da edememiş olması, açıkçası, ne tasarıma ne de programlamaya bir katkı sunmaz.

Nasıl her iş alanı, apayrı süreçleri ve iş kuralları olan bir alan (domain) ise, iş ve yazılım ihtiyaçları mühendisliği (business and software requirements engineering) de apayrı bir iş ve uzmanlık alanıdır. Bu alanın da kendine göre süreçleri, iş kuralları, çalışmaları ve çıktıları vardır. Bu alanın çalışanlarının da kendisine has yetkinlikleri, yaptıkları işleri ve ürettikleri çıktıları vardır.

İş bilgisini çözümleme yetkinliklerine sahip olmayan bir analist ancak postacı olur. Ya da analistlerin kafasına kazındığı şekliyle sadece “köprü” olmaya devam eder, tek yaptığı “al-ver”dir, ne çözümleyici olmak söz konusudur ne de bir katma değer ortaya koymak. Böyle ortamlarda zaten iş bilgisi de malumattan öteye gitmez, bilgi seviyesine çıkamaz çünkü. O ortamda senelerce çalışsanız bile hala aklınızdaki iş bilgisini bir başkasına aktarabilir hale getirmekte güçlük çekersiniz. Aktarsanız bile karşı tarafı zorlarsınız çünkü standart ve verimli yöntemleri kullanmazsınız. Çözümleme süreç ve tekniklerinden haberdar olmayan bir analist iğne oyası gibi malumatla uğraşır, onlar arasında kaybolur. Analistten beklenen, bir soru karşısında “hikmet” (wisdom) seviyesinde katkıda bulunmasıdır ama o ekranın şurasındaki bir arayüz elemanın üzerinden konuşur. Ondan beklenen, iki farklı durumu birbiriyle kıyaslayıp, etki analizi vs. yapmaktır ama o bunu sağlıklı bir şekilde yapamaz çünkü kafasında sistemli ilişkiler değil, malumat bulutları vardır. Ama unutmayın, buradaki temel sorun analistten ziyade, kurumdadır. Analiz çalışmalarında “analitik” olmayan bir kurum, analistinin çözümleme süreç ve tekniklerinden haberdar olmasını da isteyemez çünkü bu konuda fikri yoktur.

İş bilgisi, tabi olarak bir analist için önemlidir, sistemli bilgiyi hazmetmek çok daha kolaydır. İş bilgisine sahip bir analist daha hızlı iş yapar, daha rahat ve doğru davranır. Müşterisiyle daha rahat iletişime geçer ve ona güven verir. Ama iş bilgisi, bilgi olursa işe yarar, değilse, bir malumat yığınından ibaretse, vakit kaybettiren bir stres unsuru olur. Ve analistin yeterince teknik çalışmaması, bu malumatı sadece büyütür, bilgiye çevirmez.

İşte, bir analisti, operasyonel kullanıcıdan temelde farklı kılan şey, formal bir çözümlemeci disipline sahip olmasıdır. Analitik düşünebilen, işini gözlemleyen, baştan sonra kavramaya çalışan operasyonel çalışanların analist olmaları iyi bir şeydir, çözümleme ve modelleme tekniklerini öğrenmeleri kaydıyla.

Ülkemizdeki Durum

Ülkemizde sistemli iş bilgisi biriktiren kurumlar maalesef pek azlar. İşini en detayına kadar anlatabilecek bırakın operasyonel kullanıcıyı, iş birimi sorumlusu, müdürü bulmak bile şanstır bu ülkede. Amerika’dan ilk döndüğüm zamanlardı, ilk projelerimin birinde, sürecin sahibi olan birim müdürüyle analiz amaçlı bir araya gelmiştik. Müdür, daha toplantının başında, süreçlerle ilgili olarak analizi BT’deki programcılarla yapmamızı istemişti bizden! Zaten toplantıda bir de tecrübeli programcı vardı. Aynı kurum agile ödülleri almaya devam ediyor, şatafatlı uluslararası danışmanlık şirketleriyle 3-5 senede bir süreç çalışması yapıyor vs. Ama gidin sorun bakalım, müşteri memnuniyeti artıyor mu? Ya da bugların sayısında azalma olmuş mu? Ya da ya da developerlar, kendilerine gelen analiz dokümanlarından memnunlar mı? Örneğin şöyle tipik durumlar olur ülkemizde: Kurumlar agile metodolojilere geçtiklerini söylerler ama hala hantaldırlar, hala çıktılarının kalitesi kötüdür, hala başarı kişilerin özveriyle çalışmalarına bağlıdır, hala her yeni sürümü canlıya almak çok stresli bir iş olmaya devam eder. Neden? Formal çözümleme teknikleri gibi mühendislik disiplinin gerektirdiği işler yerine “dostlar ‘agile’da görsün” şeklinde, görüntü üzerinden iyileştirmelerle yetindiğimiz için.

Ülkemizde bu durumlardan dolayı mesela “iş analizi danışmanlığı” pek görülen bir durum değildir. Halbuki ABD’de böyle çalışan, 6 ay petrol çıkaran bir organizasyonda çalışıp, süreçlerini analiz eden, sonra bir sigorta şirketinde ürün biriminde analiz danışmanlığı yapan, sonra başka bir yerde örneğin ticari olmayan (non-profit) bir kurumda yine analiz sürecinde çalışan profesyoneller var. Çünkü, PM gibi, programcı gibi, analist olmanın en temel yetkinliklerini kendinde barındırıyor ve her ortamda bunları kullanıyor.

Ve Bir Referans

Bu noktada size, iş ve ihtiyac analizi konusunda çok iyi bir otorite olan Karl Wiegers’ın Software Requirements isimli kitabını tavsiye ederim. Kitabın 3. bölümü “Business Analyst” başlığını taşımaktadır ve bir analistin yetkinliklerini ve sorumluluklarını, kimlerle nasıl iletişimde bulunacağını, hangi geçmişe sahip kişilerin nasıl bir geçiş süreciyle analist olabileceklerini ayrıntılı olarak anlatır. Ayrıca bu kitapla beraber gelen malzemeler arsında, Türkçesini bu yazıda paylaştığım iş analisti görev tanımını da var. O tanımda, bir iş analistinin sahip olması gereken bilgiler anlatılırken, “Gerekli Bilgiler” başlığı altındaki son madde şöyledir:

“Kullanıcı temsilcileri nezdinde güvenilirlik sağlaması ve onlarla etkin çalışabilmek için, zorunlu olmamakla birlikte, uygulama alanı bilgisi bir artıdır.”

Ya da orijinal haliyle:

“Application domain knowledge is a plus, to have credibility with user representatives and be able to work effectively with them.”

Bu yazıyı okuyup da bu cümleye katılmayacak pek çok kişi olacaktır. Ama ben şunu her zaman iddia ediyorum: İş süreçlerini çözümleme formal yetkinliklerine sahip, iletişim yetenekleri iyi bir analist, herhangi bir iş alanını en çok bir senede çok iyi bir şekilde öğrenebilir, o alandaki iş sorunlarını çözebilir, çok etkin analiz toplantıları yapabilir. Yeter ki çalıştığı ortamda iş bilgisi, bölük pörçük, insanların kafalarındaki malumatlardan ibaret olmasın, derli toplu, soyuttan somuta gider şekilde, farklı formal modellerle ifade edilmiş olsun. Ama gelin görün ki, senelerdir aynı iş alanında, hatta aynı kurumda çalışan analistlerin sıklıkla bana, iş alanlarıyla ilgili olarak kaotik bir ortamda olmaktan kaynaklanan rahatsızlıklarını ilettiklerini bilirim. Dahası, böyle bir analist, fırsat verilse, sistemli çalışmasıyla, malumat yığını da olsa bu yığını, çözümleyerek, formal iş bilgisine dönüştürebilir. İş süreçleri mühendisliği (business process engineering) adı verilen böyle bir çalışma, bir kurumun en değerli olan iş bilgisini, rahatça anlaşılacak ve tekrar tekrar kullanılacak bir formata döker. Ve bu bilgi, o kurumun en değerli varlığı olur.

Son bir soruyla yazımı bitireyim: Düşme tehlikesi olan bir uçağın pilotu olarak, uçağı kurtarmak için içeride bulunan sadece 2 kişiden, bir analist ve bir developerdan hangisini aşağıya atarsınız? Bu yazıdan sonra tabi ki “developer” diye cevap vereceksiniz muhtemelen. Ben ise daha ağır olanı atmayı tercih ederdim 🙂

Toplam görüntülenme sayısı: 1636

Tasarım Kalıpları – II: Neden Öğrenelim?

Java, Tasarım Kalıpları, Yazılım Mühendisliği ,

Bu yazıda tasarım kalıplarını neden öğrenmemiz gerektiğini ele alalım.

“Tasarım Kalıpları” tamlaması, kullanıldığında bir “üst perde” havası oluşturan bir kavrama karşılık geliyor. Sanki bu tamlamayı kullanan kişi birden “erenler”den oluveriyor. Kullanıldığında konuya ve özellikle de kullanana “ileri derecede karmaşıklık” ya da “sofistikasyon” atfediyor. Halbuki durum öyle değil, ama belli ki bu algı bizim cehaletimizden kaynaklanıyor.

Bir de bu konuda öğrenilmiş çaresizlik yaşıyor gibiyiz. Ben üç-beş defa bu konuyu öğrenmeye niyetlenmiş ve girişmiş ama her seferinde belli bir yerde bırakmak zorunda kalmış insanlarla tanıştım. Ülkemizdeki “İngilizce”nin durumu gibi 🙁 Sanki bilmek zorundaymışız, ciddi bir miktar zaman harcamışlığımız da var ama malesef henüz tam olarak bilmiyoruz gibi bir durumdayız. Her eğitimde ya da danışmanlıkta müşteri tarafında olan yazılımcı arkadaşlar bazen bir miktar uğraştıklarını göstermek, bazen kötü durumda olan kodlarının bu durumunu açıklamak ya da doğrudan benimle sohbet etmek vs. gibi sebep ve niyetlerle tasarım kalıpları tamlamasını ya da bazı tasarım kalıplarını telaffuz ederler.

Tasarım kalıpları etrafındaki oluşan bu buğulu havayı dağıtmak, başarılı bir öğrenim süreci için elzem görünüyor.

Tasarım kalıplarını kullanmadan program yazmaya başladığınızda ilk yapacağınız hata, program olarak ifade etmeye çalıştığınız iş süreci ya da problemindeki sorumlulukları roller olarak ayırt edememenizdir. Yani “bu problemin çözümünde hangi sorumluluklar var?” ve “bu sorumluluklar farklı nesnelere nasıl dağıtılmalı?” sorularının sorulması ve cevaplanması aslen bir tasarım faaliyetidir. Hatta tasarım daha doğrusu fonksiyonel tasarım faaliyeti temelde bu soruları açıklığa kavuşturmak, alternatif cevaplar verip bunları kıyaslayarak sonuca ulaşmadan ibarettir bile denebilir. Tasarım yapma niyetiniz yoksa ki bunu biz “zamanımız yok” diye ifade ederiz, zaten bu yazının geri kalanı anlamsız olur 🙂 Yok, doğru düzgün bir yapı ortaya çıkarmak için tasarıma niyetimiz varsa tasarıma vakit ayırırız ki yukarıdaki soruları sorarız ve tasarım kalıplarının yardımıyla vereceğimiz cevaplarla nesne modellerini oluştururuz.

Tasarım yapılmazsa dolayısıyla da tasarım kalıpları kullanılmazsa, istenildiği kadar en yeni teknolojiler kullanılsın ya da nesne-merkezli bir dille program yazılsın, sağlıklı bir nesne yapısı kurgulama ihtimali sıfıra yakındır. Çünkü, yukarıda bahsettiğim, sorumlulukları bulma ve nesnelere dağıtma işinin sağlıklı yapılmaması söz konusudur. Bu durumda da gidilecek yön, nesne-merkezli programlama değil, olsa olsa prosedürel programlama hatta daha da kötüsü, karman-çorman kod yığınıdır.

Örneğin, normalde tasarım yaparak ve tasarım şablonlarını kullanarak nesnelere ve üzerinde muhtemelen override edilmiş metotlara bölünecek bir davranışın, tek bir metot altında pek çok “if” kullanarak kodlandığı sıklıkla görülür. Bu durum ise olsa olsa “functional decomposition”dır ve başınızı gittikçe belaya sokan bir yaklaşımdır. Dolayısıyla tasarım kalıpları çoğu defa bize, normalde nesne-merkezli programlama dili kullanmamıza rağmen prosedürel anlayışla yazılım geliştirmeye düşmekten kaçınmamızı sağlar. Tam da bu yüzden pek çok refactoring yani kod iyileştirmesi tekniği, var olan karmaşık ve devasa hale gelmiş nesne ve metotları, farklı kalıpları kullanarak, ufak-tefek nesne ve metotlara dönüştürür. Tasarım kalıplarının bunu yaparken elinde tuttuğu temel teknik, yukarıda bahsettiğim iki sorudur: “bu problemin çözümünde hangi sorumluluklar var?” ve “bu sorumluluklar farklı nesnelere nasıl dağıtılmalı?” Zaten bu sorular sorulmadığından devasa sınıflara ve metotlara ulaşılmıştır.

Ben danışmanlıklarımda, özellikle kod kalitesini arttırıcı işlerimde bu durumlarla çok sık karşılaşıyorum. Tek yapacağım şey konuyu anladıktan sonra bu iki soruyu sormak. Tasarım kalıpları, bu iki sorunun cevabını ciddi oranda veriyorlar. Çünkü tasarım kalıpları hem bir yöntemdir hem de bir sorumluluk kataloğudur. Tasarım kalıpları yöntemdir çünkü bu iki soruyu sormanızı ve nasıl cevap vereceğinizi size öğretir. Tasarım kalıpları aynı zamanda bir sorumluluk kataloğudur, çünkü en basitinden en karmaşığına kadar, farklı sektördeki yazılımlarda bulunan en yaygın sorumlulukları ortaya koyar. Dahası tasarım kalıpları, bu sorumlulukları nasıl bulacağınızı ve bunları iç tutarlılığı yüksek (highly-cohesive) ve dış bağımlılığı düşük (lowly-coupled) nesne modellerine nasıl çevireceğimizi de bize gösterir.

Eğer tasarım faaliyeti, yazılım geliştirme sürecinizin bir parçası ise zaten yolunuz bir şekilde kalıplarla kesişiyor demektir. Yani sadece Gof’un 23 kalıbını kullanmakla kalmıyor, kendi iş alanınızda sıklıkla karşılaştığınız sorumluluk problemlerine özel kalıplar da geliştiriyorsunuz demektir.

Dolayısıyla tasarım kalıplarını şu amaçlarla öğrenmeliyiz:

  • Tekerleği yeniden keşfetmemek, var olan ispatlanmış çözümleri kullanmak: Tasarım kalıpları sıklıkla karşılaştığımız, yaygın sorumluluk bulma ve dağıtma problemlerini çözerek, tekrar kullanılabilen, faydası ispatlanmış modeller ortaya koyar.
  • Formal ve yaygın bir dil oluşturmak: Tasarım kalıpları, formal bir kalıp dili (pattern language) oluşturmaktadır. Bu kalıp dilinin en temel kavramı sorumluluktur. Dolayısıyla tasarım kalıpları zihnimize, “şu şey yapar, şunu alır şuna verir” gibisinden sokak ağzı bir konuşma yerine “kontrol nesnesi (controller), request ve response nesnelerini, ilgili üreticilerden (factory) alıp sunum (view) nesnesine geçer” şeklinde konuşmayı öğretir. Bu dilin yazılım geliştiriciler arasında yayılması, anlaşmayı kolaylaştıracak, ifade gücümüzü arttıracaktır.
  • Tasarıma uygun, yüksek soyutlama gücü kazandımak, detaylardan sıyrılıp, daha yüksek hedefler cinsinden düşünmek: Bu anlamda tasarım kalıpları daha iyi bir yazılım geliştirici hatta mühendisi olmanın en temel gerekliliklerindendir.

Zaman zaman karşılaşıyorum, “biz aslında bir miktar tasarım yapmıştık” şeklinde cümlelerle. Bırakın kalıbı sistemde hiç arayüz yok, hiç bir nesne hiyerarşisi yok, devasa sınıflar ve metotlar var, nesneler arası ilişkiler karmakarışık, kim neyi biliyor belli değil, peki tasarım nerede? Yukarıda anlattığım gibi tasarım yapılacaksa o iki sorudur üzerinde düşünülmesi ve çözülmesi gereken şey. Ve yolunuz bir şekilde tasarım kalıplarıyla kesişir.

Tasarım kalıplarını bilmiyorsanız, tasarım da yapamazsınız.

Bol tasarımlı günler dilerim 🙂

Toplam görüntülenme sayısı: 1732

Staj – 2016

Diğer

Sevgili JavaTürk takipçileri,

Yazılım Mühendisliği ve teknolojik olarak da Java alanlarında yaptığım çalışmalarda bana yardımcı olacak1 ya da 2 tane stajyer arkadaşa ihtiyacım var. Stajyer arkadaşların sorumlulukları şunları içerecektir:

  • YM ve Java başta olmak üzere değişik konularda AR-GE faaliyetlerinde bulunmak,
  • Yürüttüğüm danışmanlık ve eğitim faaliyetlerinde bir miktar kırtasiye de dahil olmak üzere yardımcı olmak.

Staj çalışmalarının bir kısmını kendi yerinizden kalkmadan yapabileceğiniz gibi ofisimizde de yapabilirsiniz.

Aday arkadaşların öncelikle yaptıkları işi çok sevmeleri, tutkulu olmaları şart. Temel konulardaki bilgileri de sağlam olmalı. Yani analitik ve matematiksel düşünme yetenekleri yanında yazılım ve Java dili ile ilgili temel bilgileri haiz olmalılar. Algoritmik düşünce yetkinliklerini kazanmış, nesne-merkezli programlama konusunda temel yapıları özümsemiş ve tercihen Java SE kullanan ve kendini daha da geliştirmek isteyen adayları tercih ederim. Bu anlamda şart olmamakla birlikte, daha yukarı sınıflardaki arkadaşlarla çalışmamız sanırım daha rahat olacaktır. İlgisini, tutkusunu ve bilgisini gösteren herkese kapım açık olmakla birlikte…

İlgilenlerin bana buradan CVlerini paylaşarak ulaşmaları yeterli olacaktır. Lütfen CVlerinizi göndermeden önce bir daha kontrol edin, CV’de yazana değer verdiğimi ve doğru olduğunu düşünmek dışında bir seçeneği göz önüne almadığımı da bilin. Dolayısıyla Cvnizi göndermeden önce şunlara son bir daha göz atın:

  • Mahrem bilgilerinizi CVnize yazmayın. Evli olup olmadığınız, değilseniz kız-erkek arkadaşınızın olup olmadığıyla ilgilenmiyorum 🙂
  • 3 senelik okul hayatına ve 0 günlük profesyonel çalışma tecrübesine rağmen “4 senelik tecrübe” yazmayın,
  • CVnizi teknoloji çorbasına çevirmeyin. “25 seneye sığacak tecrübeyi ben 2 senede elde ettim” demeye getirmeyin. Dolayısıyla seminerine gittiğiniz teknolojiyi “biliyorum” diye yazmayın. Arzu ederseniz bu blogdaki “bilmek” ile ilgili yazılarımı okuyun 🙂
  • CV yazmak sizin kendinizi tanımınızı sağlayabilir. Dolayısıyla “ben zaten XXX’i biliyorum” demek yerine “XXX’i daha iyi öğrenmek istiyorum” gibi cümle kurmaya CV yazarken başlayabilirsiniz. Ben de açıkçası bunu tercih ederim
  • MS Office ürünlerini teknoloji kısmında sıralamayın.
  • İngilizce, bu staj için önemli. “Okuma: 10, Dinleme: 10, Konuşma: 9” şeklinde gelen CV sahiplerinin “Hi, I am calling you from Selsoft regarding your intern application. How are you doing today sir/ma’m?” şeklinde başlayan bir telefon alabileceklerini göz önüne almaları gereklidir.

Bu ülkedeki bir üniversite öğrencisinin neyi ne kadar bilebileceğini fena bir şekilde farkındayım. Beni kandırmak yerine şaşırtmaya çalışın. Bildiklerinizle ilgileniyorum fikir sahibi olduklarınızla değil! Yapabildiklerinizle ilgileniyorum bildiklerinizle değil! Yaptıklarınızla ilgileniyorum yapabildiklerinizle değil!

Ayrıca bu kadar da soğuk bir adam değilim, geyik ve keyifli sohbeti çok severim 🙂

CVlerinizi bekliyorum.

Toplam görüntülenme sayısı: 1763

Öğrenme Sürecinde Programlamadan Yazılım Geliştirmeye Geçişte Workshop Çalışmasının Önemi

Eğitim ve Seminer, Java, Yazılım Mühendisliği

Eğitim hayatımda bana sıkça sorulan birisi de bir programlama dilini öğrenmekten proje geliştirmeye nasıl geçileceği konusudur. Çok sık duyarsınız “Java’yı biliyorum ama bir proje nasıl yapılır, neresinden başlanır, nasıl ilerlenir bilmiyorum” şeklindeki konuşmaları. Doğrudur, bu durum herkesin kariyerinin başında yaşadığı cinsten sıkıntılardandır. Bu yazıda bu sıkıntının nasıl aşılabileceğini ele almak istiyorum.

Programlama, bir programlama dili yoluyla bilgisayara bir iş yaptırmaktır. Programlama dili ise bir araçtır, bilgisayara iş yaptırmanın en temel yoludur. Programlama dilleri dışında da bilgisayara iş yaptırmanın yolları vardır ama bir uygulama kadar geniş ve detaylı iş yaptırmaktan bahsediyorsak, hele işin içinde kullanıcılarla iletişim varsa, programlama dilleri dışında pek alternatifimiz yok gibi. Fakat bir programlama dili öğrenmek, temelde onun anahtar kelimelerini, kullanışlarını ve söz dizimini öğrenmek demektir. Her ne kadar programlama dilini öğrenmek ile onu kullanarak problem çözmek içe içe geçmiş süreçler olarak görünüyorsa da işin başında daha çok programlama dilinin kendisi ile uğraşılırken ilerleyen zamanlarda, özellikle dilin temellerinde belli bir noktaya gelince, problem çözme tarafı daha ağır basmaya başlar. Örneğin üniversitede, algoritmalar, veri yapıları, ağlar, derleyiciler (compilers) vb. ders ya da konularla bir programlama dilinin bir problemi çözmek için nasıl kullanılacağını öğreniriz. Örneğin pi sayısını hesaplamanın farklı yöntemleriyle if-while-for vb. pek çok kontrol yapısını, bir sayıya kadar olan tüm asal sayıları bulmada kullanılan Sieve of Eratosthenes algoritması ile dizileri kullanırız ve nihayetinde hem dile olan hakimiyetimizi geliştiririz hem de dil ile problem çözme yöntemlerini öğreniriz. Sonrasında ise compilers, ağlar ya da bilgisayar grafiği gibi derslerde muhtemelen daha büyük programlama hatta proje ödevleri yaparız. Tüm bu pratikler bizim hem programlama gücümüze katkıda bulunur hem de ağlar, veri tabanı, bilgisayar grafiği vb. temel bilgisayar ve yazılım yapılarıyla ilgili bilgi ve tecrübeye sahip olmamızı sağlar.

Peki tüm bu konularda son derece iyi olmak bir proje geliştirmek yeterli midir? Tabi ki değildir. Çünkü yazılım, programlamadan daha fazla şeyi ifade eder ve ancak proje ile yazılım geliştirilir. Genelde yazılım projelerini, programlamadan ibaret olarak görme eğilimdeyiz, hatta yazılım sistemlerini “program” olarak adlandırıldığına da sıklıkla şahit oluyorum. Yazılımın, programın daha büyüğü olarak görecek şekilde bir basitleştirme mümkün olsa bile, gerçekte böyle bir algıya sahip olmak bizi yazılımla ilgili çok ciddi yanlışlara götürür. Aynen gerçek bir uçağın geliştirilmesini, model uçak yapımının sadece daha büyük hali olarak görmekteki gibi. Zaten bu yazının başında bahsettiğim sıkıntı tam da budur: Programlamayı bilmemize rağmen proje yapmakta zorlanmamız. Sistemlerin büyümesinin getirdiği karmaşıklık çoğu zaman doğrusal değil de doğrusal olmayan şekilde artar ve bu durum zaten başlı başına bir sorundur.

Proje yazılıma özel bir kavram değildir elbet ve yazılım projelerinin de diğer disiplinlerdeki projeler gibi belirlenmesi gereken bazı tarafları vardır. Peki öğrenme sürecinde dile ciddi bir hakimiyet sağlama safhasını geçtik ve geldik kendi kendimize bazı projeler yapmaya. Neler yapmamız gerekli?  (Bu yazıda daha çok kişilerin öğrenme sürecinde, kendi kendilerine yaptıkları projeleri göz önüne alacağımdan, bu gereklilikleri çok ciddi ve formal bir çerçevede düşünmeyeceğim.)

Öncelikle bir yazılım projesinin, iyi ya da kötü ihtiyaçları belirlenmiş ve sınırları çizilmiş olmalıdır. Dolayısıyla programlamadan yazılım geliştirmeye geçerken ele alacağınız projeninizin belli bir detayda çerçevesi olmalıdır. İhtiyaçları belirlenmeden girişilecek bir projenin bitmesi pek de mümkün olmayacaktır, bundan dolayı da yapılan geliştirme “proje” olmaktan çıkacaktır. Eğer ihtiyaçları belirlemede, projenizin çerçevesini çizmede zorlanıyorsanız, en basit ve gerekli olanlara odaklanın ve detayını çıkarmakta zorlandığınız kısımları ileriki sürümlere atın ve bir an önce ilk sürümünüzü çıkarmanızı sağlayacak kısımlara öncelik verin derim.

Öte taraftan bir yazılım projesinin, ihtiyaçları çerçevesinde belirlenmiş bir mimarisinin de olması gereklidir. Nasıl ihtiyaçlar belirlenmediğinde projede pek çok yaz-boz oluyorsa benzer durum mimari belirlenmediğinde de söz konusudur. Mimari yapılar ise belli bir teorik alt yapıya sahip olarak kurgulanmakla birlikte genelde tecrübe tabanlıdır ve mimari algı, okumaktan daha çok deneme-yanılma ile gelişir. Gerçi mimari bilgi birikimimiz de gittikçe daha formal hale geliyor ve çeşitleniyor; bu yüzden gittikçe daha fazla okumak ve uygulamak önemli hale geliyor. Özellikle kullanılan dil vb. teknolojilerin temel kalıplarının (pattern) ve  mimari best practicelerinin bilinmesi bu anlamda çok önemlidir. Örneğin katmanlı yapılar kullanacaksınız, AOP ile aspectleri ayıracaksınız ve olabildiğince durumsuz (stateless) yapılar kullanacaksınız şeklidne üst prensiplerden yola çıkarak detaylara inebilirsiniz. Dolayısıyla projenizin mimari konularına da çala kalem dalmayın, biraz düşünün, okuyun, araştırma yapın ve ihtiyaçlarınızın sizi ne tür bir mimariye doğru ittirdiğini anlamaya çalışın, aksi taktirde projenin büyüklüğüne bağlı olmak üzere sıkıntılı sonuçlarla karşılaşabilirsiniz. Bu tür durumlar aslen öğrenmenizin bir parçasıdır ve doğrudan vakit kaybı olarak da görülmemelidir ama atış yaparken de olabildiğince destekli atmak gereklidir. Aşırı yaz-boz hem kaliteyi düşürür hem de motivasyonu.

Projelerinizde fonksiyonel tasarıma da önem verin. Sınıflar, arayüzler, “is-a” ve “has-a” ilişkileri, hem statik hem de dinamik görüntülerin neler olduklarına, sorumluluk tabanlı yaklaşımla karar verin. Bu gibi çalışmalar için UML kullanabilirseniz çok şık olur ama kullanamıyorsanız çok da takılmayın, bulgularınızı kendinize has bir şekilde, beyaz bir kağıda da olsa ifade edin. Bu sırada yani kavramsal olarak düşünürken nesneler arasındaki ilişkileri tasarım kalıplarıyla nasıl daha rahat hale getirebileceğinizi, nesnelerin nasıl daha sağlıklı olabileceğini de düşünün. Bu tür düşünmeler yazılım üzerine soyut düşünme kapasitenizi arttırarak size çok şey kazandıracaktır.

Sonrasında girişeceğiniz kodlamada birim testlerini yazmak, temiz (clean) bir şekilde kod yazmaya çalışmak ve API dokümantasyonuna önem vermek muhtemelen kodunuzu çok daha kaliteli ve anlaşılır kılacaktır. Ayrıca projenizde üçüncü el bileşen ve frameworkleri kullanmak, projenizi çok daha sağlıklı hale getirebileceğini de unutmayın. Bu anlamda tekerleği yeniden keşfetmeyip, enerjinizi koddaki orijinal taraflara saklayın.

Nihayetinde çok ilgi çekici olmasa da bir miktar test malzemesi oluşturmak, temel süreçleri test edebilmek için bir miktar çalışma yapmak ve örnek veri oluşturmak, projenizin sağlıklı bir şekilde nihayete ermesi açısından önemlidir.

Görüldüğü gibi yukarıdaki proje geliştirme sürecinde, programlama kadar analiz, tasarım ve dokümantasyon gibi çalışmalar da vardır. Dahası programlamanın dışındaki bu çalışmaların sağlıklı yapılması, ciddi bir eğitim ve yazılım mühendisliği nosyonu gerektirmektedir. Aksi taktirde usandırıcı bir git-gel girdabına girmek işten bile değildir. Fakat öte taraftan tam programlamada ilerleyelim derken ap-ayrı bir yazılım mühendisliği duvarına toslamak gibi bir durum söz konusu. Bu noktada öğrenme sürecinde programlamadan proje geliştirmeye geçişin ancak bir yol gösterici sayesinde yapılabileceğini söyleyebiliriz. Yani ciddi teknoloji ve metodoloji bilgi ve tecrübesine sahip bir öncünün yol göstermesi, gerekirse kısıtlaması ve yönlendirmesiyle, kontrollü bir şekilde bu süreci işletmek, sanırım geçişi kansız ve çok daha verimli hale getirecektir.

Ben bu amaçla eğitim faaliyetlerimde müşterilerime, eğitimde verilen malzemenin, yukarıda kısaca açıkladığım gibi, ayrıca bir workshop ile proje geliştirme çalışması olarak da uygulanmasını salık veriyorum. Ancak bu şekilde eğitimde verilenin gerçekten öğrenilmesi mümkün olabilir. Workshopu yapmak için temel bilgiye sahip olmak gereklidir. Ama verilen bilginin sağlıklı bir yazılım geliştirme bağlamında anlam bulması için de ders içi ufak örneklerden öteye geçen workshopa ihtiyaç vardır. Benzerlik kurarsak, workshopsız bir eğitim ile doğrudan gerçek projeye girmenin, tahta üzerinde taktiği alıp maça çıkmaya benzediğini söyleyebiliriz. Bu yüzden workshoplarla bir miktar pişmeyen developerların, gerçek projeyi haklı olarak öğrenme amaçlı olarak kullanmaları çok sık görülen bir durumdur. Her projede öğrenme söz konusudur ama sahip olduğu teorik bilgiyi hiç kullanma imkanı bulamamış kişilerin doğrudan projeye atılmaları, projeyi çoğunlukla çöplüğe çevirmektedir. Halbuki aslolan, gerekirse workshopı çöplüğe çevirmek ama bu sayede anlamayı pekiştirmek ve gerçek uygulama ortamına hazırlanmaktır.

Bu noktada yazılımcı olarak çalışan arkadaşlara tavsiyem, eğitim alırken muhakkak workshop da talep edin. Bence kaç günlük ya da saatlik eğitim alıyorsanız aynı miktar workshopa ihtiyaç vardır.

Bu noktada benzer yaklaşımı, JavaTürk bünyesinde açmış olduğum eğitimlerde de kullanacağım ve gördüğünüz, aldığınız eğitimlerin workshoplarını da sanal ortamda açacağım. Bu şekilde isteyen eğitimden sonra workshopa devam edebilecek, eğitim ihtiyacı olmadığını ama uygulama ihtiyacı olduğunu düşünen de doğrudan workshopa dahil olabilecektir. Workshoplarla ilgili olarak eğitim sayfasını takip etmenizi öneririm.

Toplam görüntülenme sayısı: 1160

1 2 3 4 5 >»