Hızlı üretelim, mükemmel olmasına gerek yok, erken yayında olmak önemli diye diye, kötü geliştirme süreçlerine alışmış/alıştırılmış büyük bir yazılımcı kitlesi yarattık. 2 haftada üretip, 12 ay yama yaptıran zihniyet yok olmadıkça, kimsenin iyi yazılımcı bulamadığı için ağlamaya hakkı yok.
Kavga çıkar bu feed altında, demedi demeyin ;-)
- Emre Sevinc
çıksın emre. bu tür konularda çıkan kavgalar kuruyla yaşı ayırt etmekte çok işe yarıyor :)
- airy
@core, atlanmadığı durumlarda da genellikle yanlış yaklaşım ve pratiklerle, işe değer katmayacak bir şekilde, sadece "yaptık, var" diyebilmek için yapılıyor.
- airy
Gönül ister ki herkes bir Knuth olsun, gizli gizli çalışıp ortaya bi program, bi kitap çıkarsın yok böyle dedirtsin, kristal berraklığında, akdeniz rüzgarı ferahlığında teknik şaheserler olsun. Diğer yandan, Linus Torvalds sık sık ve mükemmel olmayan (artık o nasıl tanımlanacaksa), -- olmasına gerek de olmayan! -- çekirdekleri çitletip çitletip yayımladı da fena mı oldu. Yani işin bir şeyini çıkarmak istedikten sonra çevik süreçlerin de bilmemne metodolojisinin de bir şeyleri çıkarılabilir, öyle değil mi? (Apple'ız da iPhone mu çıkarıyoruz, Mac OS mu çıkarıyoruz?)
- Emre Sevinc
Gel de bunları müşteriye anlat. Al sana 1 birim kaynaklık para, ama 5 birim kaynak ayır! Ayrıca iş 4 birim kaynakla 4 ayda biter sen ne yap et 2 ayda çıkar! yoksa para da vermem!
- Onur Yalazı
Valla işte neyin nasıl yapılacağı müşteriye göre, sektöre değişir, demek ki bazı ortamlarda işler böyle yürüyebiliyor, bazı alanlarda ise Altan'ın şikayet ettiği tarzda yöntemle bırakın bir şey yapmayı, yaptırmayı kapıdan adım attırmazlar.
- Emre Sevinc
turkiyede bu is modelinin degisecegini hic sanmiyorum.
- Berk Ülsoy
Evet değişmez. Bu şekilde de çok acı çekeriz. Başka modellere yönelmek gerekiyor
- Onur Yalazı
Agile süreçlerinin nedense sadece Osman'ın bahsettiği kısmı akılda kalıyor ve gerisini rafa kaldırıyorlar. İlk olarak Agile geliştirme'nin negatif yönlerinden bahsedelim: süreçlerinin senyör düzeydeki yazılımcılar tarafından yapılabilir olduğu, müşteri-odaklı projeler dışında kalan proje geliştirme süreçlerinde sadece patronu tatmin etme odaklı olacağı, gerekli kullanıcı senaryolarının çoğunlukla bu konuda deneyimi az olan müşterilere veya yazılımcının kendisine bırakıldığı, test mühendislerinin görevini müşterilerin kendilerinin yaptığı, yetersiz bir yazılım altyapısı ile yola çıkıldığı, zaman kazanma amacının sık ve uzun süreli toplantılarla anlamsızlaştırıldığı, disipliner yazılım süreçlerinden feragat edilerek formal düzenden çıkıldığı, realistik bir deadline belirlenemediğinden sürecin "hızlı" olmaktan çıkarak müşterinin insafına bırakılan bir zaman dilimine yayıldığı vs. vs. Burada pozitif yönlerinin geri plana ittiğim düşünülmesin ancak şimdi Türkiye'deki "Agile" süreçlerini yazayım: Junior düzeydeki yazılımcıya süreç başlatılır, yazılım öyle böyle "live" olur, biri gelir ilk kapağı çakar, patron yazılımcıya kızar ve düzeltilir, sonra hızlı olacak diye yazılımcıya 10.000 satırlık birbirinin kopyası fonksiyonlardan oluşan bir depo hazırlatılır, bu arada framework, OOP kim öğrenecek prosedürel çak gitsin diyerek yazılımcı arkadaşa yol gösterilir, eğer müşteriye yapılan bir iş ise para alınır ve "devamlılık" göstereceği iddia edilen süreç bıçakla keser gibi bitirilir.
- Altan Tanrıverdi
bir yanlis anlasilma var. insanlar - ozellikle burada gordugum girisimciler - buradan bakiyorlar ve diyorlar ki : "urunu hizli cikartmak cok onemli, o zaman alt yapi dandik olsa da olur, duzensiz olsa da olur, hem silikon vadisinde de oyleymis" ancak sunu gozden kaciriyorlar adamlarin bu kadar hizli hareket edebilmesi icin sıkı sıkıya takip ettikleri bir cok prensip bulunuyor. basit bir ornek vermek gerekirse unit testing. Turkiye'de herhangi bir ben internet girisimcisiyim diyen adamin unit test yazalim istegine olumlu yaklastigini gormedim, lakin daha sonra sistem buyudugunde bi yerini degistirince, diger ve muhtemelen deploy etmeden once farkedemeyeceginiz kisimlari patladiginda bik bik diye otmeye basliyorlar. bizdeki az zamanda, cok is kafasi adamlardaki az zamanda, az ama kaliteli is kafasi gibi gozlemledim birde. bizde musteriler hersey ilk surumde olsun, bitsin istiyorlar, cok sacma sapan abuklukta sureler istiyorlar v.s v.s...
- Gurkan Oluc
Unit test ve functional test deme banaa !!
- Onur Yalazı
Agile ülkemizde yanlış anlaşılıyor. Ama hızlı deployment herzaman iyidir bence. Çoğu zaman hayat kurtarır. Çalışan yazılımı optimize etmek daha kolay değil midir?
- Vehbi Emiroglu
Çalışan yazılımı optimize etmek kolaydır. Ancak optimizasyon ile geliştirme farklı kavramlar.
- Altan Tanrıverdi
KISS, YAGNI, DRY anılmadan, anlaşılmadan agile deniyorsa ordan hızlıca uzaklaşmak lazım der tao
- airy
Hızlı ama kirli geliştir. Çalışan uygulamayı optimize et felsefemdir :)
- Vehbi Emiroglu
O zaman bu hayat felsefesini her yerde kullanmalı. Örneğin araba üretirken güvenlik, konfor, dayanıklılık ve bilumum test süreçlerine, dizayn, mühendislik Ar-Ge araştırmalarına gerek yok, dingillerin üstüne motoru koyalım gitmeye başlasın, sürücünün isteğine göre yolda kaporta, koltuk falan monte edilir. Böylece zaman kaybedilmez :)
- Altan Tanrıverdi
Bilgisayar yazılımı ile arabalar farklıdır. Benim kastettiğim şu. Yazılımın yapması gerekenler bellidir. Eğer bunları hatasız yapabiliyorsa evet o bir çalışan uygulamadır. Bunu ne kadar hızlı ve kolay yapabiliyor konusu ise bence sonraki aşamadır.
- Vehbi Emiroglu
Elbette o işin latifesi ancak Vehbi, yazılım yerine sadece arabayı koyuyorum cümle ne kadar irite edici oluyor sen de görüyorsun: "Bir arabanın da yapması gerekenler bellidir, hatasız ilerleyebiliyorsa o çalışan bir arabadır." Arabada güvenlik vb konuların hayati olması, yazılımda da göreceli olarak geçerli bana göre. Çalışıyor olmak yeterli görülmemeli. Belirli formal süreçlerden geçmemiş bir yazılım geliştirme süreci elde kalır.
- Altan Tanrıverdi
İster istemez müşterinin de bir test ve onay süreci oluyor. Bu süreci bunları tamamlamak için kullanmak ?
- Vehbi Emiroglu
Mümkün değil, arkada para kazanması gerekan bir şirket, çabuk bitsin diyen bir patron/müşteri ve yüksek ihtimalle yaptığı işten o an için tiksinecek düzeye gelmiş bir yazılımcıdan oluşan bir süreçte bu kadar pozitif işler olmuyor.
- Altan Tanrıverdi
kendim kod yazmadığım sürece projelerim gayet güzel ilerliyor... belli bir altyapı varsa üstüne ekran hazırlamak basit ve hızlı oluyor. ama ne zaman kendim kod yazmaya girsem aklıma türlü türlü detay, eklenti, ıvır zıvır geliyor ve kendi kendimin işini uzatıyorum... istediğin kadar yöntem geliştir, aslında herşey insanın kişiliğinde bitiyor
- Sado Yasutora [メーメット]
Ben hep kendi kodlarımı düşündüğüm için böyleyim. Tersini de yaşadım. 6 ayda bitmesi gereken proje yazılımcıların 3 ay da veritabanı diyagramı ile uğraşmaları yüzünden iptal edildi. Burda yazılımcılar sizin dediğinizi yapmış oluyorlar.
- Vehbi Emiroglu
Benimde kendi şirketimde yaşadığım şey şu. Ne zaman kodlamanın dışında kaldıysam o proje hep sıkıntı yarattı. Elemanlar masal anlatmaya bayılıyorlar :)
- Vehbi Emiroglu
ben sadece framework'ü hazırlıyorum, tasarımı oluşturuyorum. bunları nasıl kullanacaklarını yazılımcılara anlatıp çekiliyorum. onlar kuralların dışına çıkmadığı sürece gayet hızlı ve düzgün ilerliyor proje. Hatta o kadar boş vakitleri kalıyor ki zaman zaman onları facebook tan, msn den falan toplamam gerekiyor :))
- Sado Yasutora [メーメット]
Ben sırf bu eleman masalları yüzünden mis gibi para kazandığım yurtdışı müşterisini kaybettim.
- Vehbi Emiroglu
Teslim vakti yaklaşır. ne yaptınız durum nedir sorulur. Ki parçalı bir projedir. parça parça teslim edilecektir. İşte bitti bakın çalışıyor şurda azıcık birşey kaldı denilir. Evet dökümana göre doğru gibidir. Kodlamanın içinde olmadığın için satır satır incelemezsin. Sonra müşteriye kod teslim edildiğinde hiçbir standarta uyulmadığı anlaşılır. Müşteri ile kavga etme görevi yine sana düşmüştür. Sonuçda uyarılır bir dahayapmayalım denir. Bir sonraki teslimat gününde bu sefer başka bir noktadan patlar iş. Böylece sürer gider.
- Vehbi Emiroglu
hımm anlıyorum... ama ortaya çıkan ekranları da mı kontrol etmiyordun? o ekranlardan bazı şeyler anlaşılırdı diye düşünüyorum ama yamuluyor da olabilirim tabii :)
- Sado Yasutora [メーメット]
Mis gibi gelen eurolar kesilir. Başka bir projeye başlanır. 6 ay içinde teslim edilmesi gereklidir. 3 ay sıfır kod yazılarak veritabanı oluşturuyoruz denilir. Yanlış yapıyorsunuz denince mühendis elemanlar senin işi bilmediğini iddia ederler. 5.ayda çalışmayan yarım yamak kodu gören müşteri anlaşmayı fesh eder. Olan yine bana olmuştur.
- Vehbi Emiroglu
1 yılda edilen zararın haddi hesabı olmayınca 2 tane güzide bilgisayar mühendisinin işine son verilir. elde kalanlar freelance arkadaşlara tamamlatılır. Zarar daha da büyür. Vehbi de bir daha aynısını yapmamaya yemin eder.
- Vehbi Emiroglu
3 ay veritabanı tasarımı için baya uzun bir süre değil mi? kontrol etmedin mi adamları?
- Sado Yasutora [メーメット]
Yahu kontrol etmez olurmuyum 2 güne bir napıyorsunuz dedikçe veritabanı veritabanı dediler. bakın ben mühendis değilim. bu yüzden mühendislerin hep küçümsemesi ile karşılaştım. ben işi bilmez patron oldum hep.
- Vehbi Emiroglu
Alla allaa?? Neyse, gelmiş geçmiş olsun. Neticede herşey bir deneyim tabii...
- Sado Yasutora [メーメット]
tabi o deneyim bana baya pahalıya mal oldu :)
- Vehbi Emiroglu
Yazdığı kodu gidip sadece müşteriye anlatıp gelecek elemanın hiç üstüne vazife yokken server raid disklerini karıştırması sebebi ile yediğim azarların giden paraların daha hikayesini anlatmadım :)
- Vehbi Emiroglu
Afişe et elemanları bari de başımıza patlamasınlar
- Onur Yalazı
@vehbi; iki (ve üzeri) kişiyi, birbirleri ile kontrol etme şansına sahipsin aslında
- airy
@airy büyük bir hata ile o iki mühendisi aynı anda mezun olmuş ve samimi 2 arkadaştan seçtim. birbirilerini kontrol etme şansları yoktu :(
- Vehbi Emiroglu
bence sen hatayı sadece proje durumunu sormakla etmişsin. göstermelerini ve bir hafta içinde hangi noktada olacaklarını sürekli sorgulamak onları işlerini bitirmeye itecektir. Ayrıca mühendis olması benim gözümde bilgi olarak birşey ifade etmiyor. Shift tuşunun ne işe yaradığını bilmeyen bilgisayar mühendisi tanıdım ben. Hele ki yeni mezun bir bilgisayar mühendisine kendisini ispatlayana kadar iş konusunda güvenemem.
- Sado Yasutora [メーメット]
Başlıktaki söylemleri bire bir yapıp çok büyük başarı kazanan iPhone örneğini verebilirim. Bu durumda işin kedisi kadar lansmanı da fark yaratır diyebiliriz.
- Bircan HANCI
Ayrıca eleman konusundaki yorumlara katılıyorum. Nice güzel işi ekip elamanlarının rehaveti yüzünden kaçırmışımdır. Şimdilerde ise tek başıma uğraşabileceğim işler dışıda ek iş almıyorum. Ama sadece yazılım değil bu, grafikerlerin de kabahati büyük bu konuda. Yurt dışındaki sitelerden bulduğum adamlar ile kırık ingilizcem ile anlaşıp çok daha güzel işler yaptık. :(
- Bircan HANCI
Acaba iş verenler mi anlamıyorlar elemanları diye düşünüyorum. Ama yok bir sıkıntı var ama çözemiyorum.
- Vehbi Emiroglu
işverenler nefes aldırmadan çalıştırmak istiyor, çalışanlar iş yapmadan maaş almak istiyor. arada dengeyi kurmak önemli :)
- Sado Yasutora [メーメット]
Nefes almalarına izin veriyorum. Ama mola sürelerini epey uzun tutmaya başlıyorlar. Ne yazık ki ülkemizde proje işleri hala "Sabit mağaşlı iş" olarak görüldüğü sürece bu anlayış değişmez. İnsanların kafasında bir "süre" kavramı yerleşmesi şart.
- Bircan HANCI
ben yapacağı işlere bir süre veriyorum. o süre zarfında ister geyik yapsınlar, son dakika yazıp bitirsinler; ister ilk anda bitirsinler, sonra oturup oynasınlar hiç karışmıyorum.
- Sado Yasutora [メーメット]
Memurluk kavramı ölmedikçe bu işler olmaz. Hala maaşımı alırım 8-5 mesaimi yaparım üstüne karışmam aga düşüncesi mevcut. Nereye varıcaz böle.
- Vehbi Emiroglu
ben yazılım işinde yazılımcıyı dinlendirmeden gece-gündüz, mesai dışı çalıştırarak verim alınacağına inanmıyorum. Adamı bir gün, bilemedin iki gün mesaiye bırakırsın; ondan sonra kafa işlemez olur, normal işlerini de aksatır. Kar edicem derken külliyen zarar edersin. Yazılım projelerinin zaman hesaplamalarını yaparken insanları normal mesai saatlerinin yarısında aktif kod yazabileceğini göz önüne alarak zaman planlaması çıkarırsanız gerçekçi bir tarih belirleyebilirsiniz. Zira insan beyni sadece 45 dakika bölünmeden çalışmaya uygundur, bundan fazlasını çalıştırdığınnızda ileriki saatlerden yersiniz. ayrıca adam tam konsantre olmuşken çalan bir telefon, sorulan bir soru bile adamın işine dönmesini en az 15 dakika attırır. dolayısıyla 9-6 mesai yapan bir yazılımcı fabrikasyon bir şekilde sürekli kodlayamaz. gerçekleri görmeden iş planları yapıp yazılımcıları sıkıştırmak onların bir şekilde çalışırken işten kaçmasına, sonuçta yine projenin zarar görmesine neden olur. En güzel yöntem sürekli yaptığı şeyleri göstermesini istemek, ilerleme raporunu düzenli tutmaktır.
- Sado Yasutora [メーメット]
@sado kesinlikle katılıyorum. Ama olay biraz da kişisel disiplinle ilgili bir durum. Dediğim gibi yabancılar ile çalışırken aramızda hem mesafe hem zaman farkı var. Çatır çatır geri besleme alıyorum. Gelen geri beslemeler de söylendiği gibi çıkıyor. Burada ise aynı şekilde ofis bağımsız çalışılıyor ve de gelen geri beslemeler ile yapılan işin alakası olmadığı görülüyor. Her seferinde uyarmak da bir yere kadar.
- Bircan HANCI
Aslında aynı şeylerden bahsediyoruz. Yazılım işi geleneksel çalışma saati kavramına uymaz. Ona uydurmak isteyen biz değil elemanlar oluyor. Ben kimsenin saat 8 de iş başında olmasını istemem. Kendimden biliyorum. Yeterki iş zamanında düzgün bitsin.
- Vehbi Emiroglu
Yazılım işini severek değil de mesleği olduğu için yapan insandan güzel işler beklemek hayal gibi oluyor. Ülkedeki eğitim sistemi nedeni ile insanlar sevdiği işlere değil de puanının tuttuğu işlere yönlendiriliyor. Çıkan sonuç ortada
- Vehbi Emiroglu
BU FEED'İ BÖYLE KOMPLE ALTINDAKİ YORUMLARLA BİRLİKTE BİZİM YÖNETİCİLERE GÖNDERMEK İSTİYORUM
- Lilly Atwerk
Kaldı ki en çok rastladğım olay (Agile benzeri bir sistem denemiştim) iş kartında bir iş vardır o işi eleman alır. Ama düz kodu yazar bırakır, ne bilgi satırı ne doğru düzgün bir açıklama. Yapması gereken standart prosedürleri de ek iş miş gibi söylemeye başlar. Buna da ben tembellik diyorum kimse kusura bakmasın.
- Bircan HANCI
Sektörün oyuncularının birbirini suçlaması ve hatalarla ilgili kendini hep/daha çok haklı görmesi esas problem. Ama süreçlerin kendisini es geçiyoruz ve sektörel bir problemi kişilerin kişisel özellikleri ile açıklamaya başlıyoruz. Oysa ben feedi girerken bunun bir zihniyet meselesi olduğunun altını çizdim. İşini iyi yapmayan yazılımcılar varsa, kötü yönetim gösteren patronlar varsa bu kişisel özellikler ile açıklanabilecek bir durum değil. Çalışma disiplinlerinin değişmesi, insanların şirketin geçtiği süreçlerden bağımsız olarak ana esasları yerinden oynatmaması gerekir. Yoksa insanların "tatmin olma" duygusuna kalırsa iş, Türkiye'de ne öyle bir şirket ne de öyle bir yazılımcı var, bulamayacaksınız! Akıldan çıkmaması gereken iki temel madde şu: Yazılımcılar sizinle aynı heves ve isteği göstermeyecektir, onları zorlamanız belki kısa süreli faydalar sağlayabilir ancak hiçbir zaman istikrarlı bir büyümeyi sağlayamaz, ikincisi ise yazılımcılar sektörün bu durumunu kabul eder bir ruh haline bürünmüş gözüküyorlar, bunun da en büyük suçlusu 20 yaşındaki gençlere milyon dolarlar kazanabileceklerini söyleyerek vaadlerde bulunan bazı aracılar. Doğal olarak o genç yaşlardaki arkadaşların belki binde birinin gerçekleştirebileceği bir hayal, kendi önlerindeki en büyük engel haline geliyor. Koşulların her iki taraf içinde kabul edilebilir hale getirilmesi, ama her iki tarafın da bunu düzgün ve sistematik bir şekilde yapması gerekiyor. Olur mu, başarabilir miyiz bilmiyorum ama olmazsa bu tartışmalar çok su götürür. Kendimiz çalar kendimiz oynarız, her şey aynı kalır.
- Altan Tanrıverdi
@Altan haklısın. Ben hep kendi tarafımdan baktım. Ama tartışma çok faydalı oldu kesinlikle.
- Vehbi Emiroglu
8-5 calisip bunun disinda hayatina minimal mudahale ettirerek da gayet guzel yazilim yapilabiliyor. memur kafasi 8-5 calisan degildir. memur kafasi "benim onume yapmam gereken adim adim yazilmadikca hic birsey yapmam, ogrenmem, denemem" kafasidir. karistirmayalim
- Berk Ülsoy
Ana feed deki sonucu Çevik Yazılım geliştirme metoduna atmak saçmalık olur. Ama Türkiye'de bu metodun uygulanamamasının sonuçları olarak değerlendirilebilinir elbette. Bir çok şeyde olduğu gibi bu konularda da sadece işimize gelen kısmını alıp uygulamak, diğerlerini yok saymak bizim işimiz.
- Savaş DOĞAN
Bu sözünüze kesinlikle katılıyorum. Fakat e-Tohum'da büyük projelerin tutmasındaki roller anlatılırken projenin mükemmel olması için uzun zaman harcamayın dendi. Önce basit yapıda çıkarın, gün geçtikçe geliştirin. Bu sözden hızlı üretelim, mükemmel olmasına gerek yok sözü de çıkarılabilir ya da öz içerik olsun sonra geliştir de.. Ağızdan çıkan sözlere dikkat etmek gerekiyor sanırım..
- hiN~
musteriyi (veya potansiyel musteriyi) ne kadar cabuk uretim surecinin icine sokarsaniz, uretimde de o kadar az bosa caba harcarsiniz demek istemislerdir. hizli uretimin, bir an once musteriye acmanin arkasindaki gerekce budur.
- Berk Ülsoy
Mükemmel olmak ile, düzgün yazılmış olmak arasında fark vardır. Her şeyi yapması ve mükemmel yapması ile sadece gerektiği kadarını, ihtiyaçlar doğrultusunda yapması arasındaki farktan bahsediyorlar orada. Her şartta düzgün yazmak lazım.
- Onur Yalazı