Agile: Hayaller ve asla bahsedilmeyen gerçekler
Arama
Genel

Agile: Hayaller ve asla bahsedilmeyen gerçekler

Konuk yazarımız Birge Elif Basık, VNGRS ekibinin Agile Coach’udur. Sağlıklı yazılım yaşam döngüsü, süreç iyileştirme, ürün geliştirme ve yazılım takımlarının verimli çalışması gibi konularda çalışmalar yapmaktadır.

agile-developmentYazılım dünyasında son bir kaç yıldır yeni bir rüzgar esiyor: Agile (Çevik) yazılım geliştirme. Google’ı açıp “Agile Development” yazdığınız zaman önünüze bu yeni yazılım geliştirme sisteminin ne kadar verim arttırdığı, yazılımcıların işini kolaylaştırdığı ve ürününüze gözle görülür katkıyı çabucak yaptığı ile ilgili binlerce makale dökülüyor. Uzmanların makaleleri size bu dönüşümün yazılım geliştirme dünyasının olmazsa olmazı olduğunu anlatıyor, acilen “Agile” uygulamaya başlamazsanız başınızın dertte olduğuna dair sizi uyarıyor.

Bu rüzgara kapılan firmalar aldıkları danışmanlıklarla veya takımlarına ekledikleri yeni proje yöneticileri ile içlerinde pilot programlar uyguluyor, yazılım ekiplerinin odaları renkli post­it’ler ile doluyor, bir heves herkes sabahları 15 dakikalığına toplanıp günlük “Scrum” toplantısını yapıyor. Ama bir kaç ay sonra, yetişmeyen iterasyonlar ve bol hatalı sürümler, mutsuz yazılımcılar ve şikayetçi yönetim kadrosu yaratıyor. Agile yazılım geliştirme suçlanıyor ve bu zamana kadar yapılmış değişiklikler bir kenara atılıyor. Agile yüzünden daha da karışmış bir sistemle, ekipler eskiye dönüyor.

Peki neden agile yazılım geliştirme bu kadar değerli olduğu halde firmalarda çalışmıyor?

Son bir kaç yıldır, Türkiye’de ve yurtdışından farklı firmaların içlerinde barındırdığı 20’den fazla takımla çalıştım. Dünyanın her yerinde dağınık bulunan takımların da, Türkiye’de aynı odada çalışan ekiplerin de yaptıkları hatalar hemen hemen birbirinin aynısı. Bu bağlamda, yukarıdaki sorumun bir kaç tane temel cevabı olduğunu deneyimledim.

Öncelikle, “Agile Yazılım Geliştirme” sadece bir sistem olarak algılanıyor. Ancak agile, bir sistem değil, kendisine ait manifestosu olan bir felsefedir. Bu felsefe bütünüyle firmanın tamamı tarafından benimsenmeden, sadece yazılım ekibini zorlayarak yapılmaya çalışılan değişiklikler yürümüyor. Bu arada şunu da belirtmekte fayda görüyorum, teknoloji temelli olsun olmasın IT ekipleri bir çok firmanın kalbi haline gelmiş durumda.* Bu bağlamda değişime başlanacak en doğru yer IT olmakla birlikte, diğer departmanların da bu değişime hazır olması gerekiyor. Muhasebe veya pazarlama birimleri, “Çok acil!!!” başlıklı emaillerle yazılımcıları taciz edip işlerini bölmeye devam ettiği sürece, söz verilen özelliklerin ürüne eklenmesi imkansız hale geliyor. Bu sebeple geçici bir süre için yazılım ve diğer departmanların arasına bir kalkan koymak, diğer departmanlara “Hayır” veya “Daha sonra” diyebilecek kötü bir adam seçmek, genelde bu dönüşümün daha pürüzsüz olmasına yardım ediyor.

Agile felsefesinin temelinde, tamamlanması düşünülen işlerin düzgün bir şekilde ufak ve anlamlı parçalarına ayrılması, bununla birlikte geri dönüşü en yüksek olacak şekilde sıralanması yatar. Böylece, hata yaptığınız takdirde, kaybınız az, aldığınız ders çok olur. İşlerin uygun şekilde bölünebilmesi ve “yapılacaklar listesi”nin hazırlanması tecrübe ve emek isteyen bir süreçtir. Bu süreci yönetecek kişinin doğru seçilmiş olması, ürünü iyi tanıması ve ileriyi bir parça öngörebilmesi, agile dönüşümün başarısını doğrudan etkiliyor. Ürün sahibinin, tamamlanması planlanan özellikler konusunda seçiçi olmaması, her şeyi aynı anda yapmaya çalışması, sürekli fikir değiştirmesi veya müşteriden gelen geribildirimleri dikkate almaması sadece agile dönüşümü değil aynı zamanda ürünü de tehlikeye atıyor.

Agile dönüşüm planlanırken, sadece proje yönetiminin değil, aynı zamanda kalite anlayışının da değişeceğini öngörmek gerekiyor. Agile, yapısı gereği “Çalışan Ürün”ü her zaman önde tutar. Ürünü hızlı çıkarırken, kaliteden de ödün verilmemesini şart koşar. Kalite standartını belirli bir eşikte tutabilmek için, ürünün piyasaya çıkmadan önce belirli testlerinin tamamlanmış ve hatalarının onarılmış olması gerekmektedir. Hatalı çıkan ürünler, firmalara müşteri ve itibar kaybettirmektedir. Fakat çoğu firma, oldukça yoğun efor gerektiren kalite kontrol sürecini pahalı bulmakta ve arka plana atmaktadır. Ülkemizde yeterli sayıda kalite mühendisinin olmaması da başka bir handikaptır. Firmalar kendileri yapamasalar bile, dışarıdan alınacak bir danışmanlıkla kalite kontrol sistemlerini (agile) dönüşüme uygun hale getirmelidir. Agile proje yönetimi ve kalite kontrol, asla birbirinden ayrı anılmaması gereken iki temel olgudur.

Agile dönüşümden bahsederken, “release” süreçlerini atlamak da büyük hata olur. Müşterilerin sizden bekledikleri ürününüzün yeni özelliklerini çabucak geliştiriyor olabilirsiniz ama bu yenilikleri canlıya almanız günlerce, hatta haftalarca sürüyorsa, “agile” dönüşümü tamamlamış sayılmazsanız. Gözlemlerime göre, yazılımcıları paradan daha çok mutlu ve motive eden şeylerden birisi de yazdıkları kodu çabucak canlıda görebiliyor olmaları. Sık ve hızlı release çıkmanın yolu da düzgün bir DevOps yapısından geçiyor. Kalite kontrol / test mühendisliği kısmındaki sıkıntılar burada da geçerli. Yetersiz kaynaklar, otomatize canlıya alma sistemini hayal kılıyor. Hele kaynak kodda da problemler varsa, ürün üzerinde kritik değişiklik yapmak iyice kabus oluyor. Yazılımcı, ürün geliştirmeye odaklanmak yerine, ürünü canlıya almakla daha çok uğraşabiliyor.

Son olarak yazılımcı mutluluğuna değinmek istiyorum. Agile yazılım geliştirmenin gizli kalmış ve çok bahsedilmeyen noktalarından biri de, mutlu yazılımcıların daha üretken olduğu gerçeğini desteklemesidir. Mutlu yazılımcılar firmanızda daha uzun süre sizinle beraber çalışırlar. Süreçleri bilirler, ürünü sahiplenir ve ileriye götürürler. Agile sanılanın aksine, sizin geleceği planlamanıza ve önünüzü daha net görebilmenize yardım eder. Yazılımcıların, kendilerini geliştirmeye harcayacakları süreyi fazla mesaiye gömmelerini engeller. Fakat, başarısız agile denemeleri yazılımcıyı süreçten de üründen de soğutur. Sürekli hatalı ürün çıkmak, hatta aylarca çıkamamak, yazılımcının kendisini başarısız hissetmesine neden olur ve kendine daha verimli çalışabileceği yeni bir firma aratır.

Özetlemek gerekirse, sadece Agile seramonilerini uygulayarak yapılmaya çalışan bir agile dönüşüm başarısız olur. Agile, sisteminizdeki hataları su yüzüne çıkartır, ancak sizin de bu hataları görüp düzeltmek için çaba harcamanız gerekmektedir. Hiç bir şey önünüze gümüş tabakta sunulmaz, sadece günlük toplantı yapıyorsunuz diye de düzelmez. Firma, bütünüyle agile felsefesini benimsemedikçe; ürün yönetimi, kalite kontrol ve canlıya çıkma süreçlerinin dönüşümünü de planlamadıkça “agile” olunmaz. Sadece boşa vakit ve para harcanmış olur.

Kapak görseli: 2nix Studio/Shutterstock

Yorumları GösterYorumlar Gizle (34)
  1. Mehmet Davut dedi ki:

    Teşekkürler, güzel tespitler ve yorumlar

  2. ibrahim dedi ki:

    gayet güzel özetlemişsiniz özellikle ” Muhasebe veya pazarlama birimleri, “Çok acil!!!” başlıklı emaillerle yazılımcıları taciz edip işlerini bölmeye devam ettiği sürece, söz verilen özelliklerin ürüne eklenmesi imkansız hale geliyor. ” bölümü çok doğru, kural koydunmu uyacaksın

  3. Volkan Akkuş dedi ki:

    Çalıştığınız firmalar veya projeler hakkında daha fazla bilgi verir misiniz?

    Bakalım ne kadar büyük bütçeler bile yetmiyor?

    Yada sadece küçük şirketlerin bir problemi mi?

    1. Merhabalar,
      Hem ABD, hem de Türkiye’de oldukça büyük olan firmalarla da çalıştım. Bu firmalar yoğun olarak yazılım geliştirme yapsalar da asıl pazarları birbirinden çok farklıydı (telekom, ödeme altyapıları/finans, kitap, big data işleme, vb.). Yukarıda değindiğim gibi, problemin büyük bir parçası bütçe ayrılması değil, şirket kültürünün buna hazır olmaması ile alakalı. Şirket kültünün yanı sıra, o şirketin içerisinde bulunduğu ülkenin kültür yapısı da etki ediyor tabii ki.
      Konu ile ilgili daha geniş bilgi almak isterseniz bana Linkedin üzerinden ulaşabilirsiniz.
      B.

  4. ouaee dedi ki:

    “Agile is a cancer that we have to eliminate from the industry” Erik Meijer

    https://vimeo.com/110554082

    1. Mehmet Emin dedi ki:

      Video ilgimi çekti ve izledim taki TDD hakkında söylediklerine kadar. Başta olumlu olan tüm düşüncelerim o noktadan sonra bu adamın dediklerinin anlamsız olduğu şeklinde değişti.

    2. Dsezen dedi ki:

      Benzer yurtdisi ve yurtici agile deneyimlemem oldu farkli takimlar ile. Yurtdisi ile ters dusen bazi gozlemlerim:
      1- Turkiye’deki yazilimciya “operasyonel” is yapan bir calisan gozuyle bakilmasi
      2- Yazilimcinin urunun gelisimine fikir olarak katkisi cok istenmiyor
      3- Turkiye’de Kabul kriterleri yazabilen PO cok az, dolayisiyla cok fazla git-gel ler oluyor
      4- Turkiye’de Portfolio Yonetimi yapan sirket goremiyorum:/ eticaretin en buyuklerinin bile buna ters kararlarini biliyorum….
      5- Maalesef insanlar arasi guvende dunya sonunculari arasindayiz ve Scrum in guvene dayali yapisi buna ters
      6- Micro Management hastaligimiz var

      Bu ve benzer nedenlerden dolayi Turkiye’de bir teknoloji sirketinde calismak istemeyen nitelikli kisileri de ulkeden kaciriyoruz, hele politik hava da boyleyken bir de bu kultur tuz ve biber oluyor

      1. Maalesef aynen katılıyorum…

        Ancak yine de benim umudum var 🙂 Böyle yazılar yazarak, önüme gelen herkese “agile’ın doğrusu budur!” diye anlatarak birazcık da olsa bunun önüne geçmeye çalışıyorum. AgileSparrow gibi (ScrumTurkey’in girişimi) mentorluk projeleriyle, ofise gelen stayjerler vasıtasıyla, vs. genç nesile gerçek agile’ın ne olduğunu anlatıp piyasaya sağlıklı bilgilere sahip yeni kan pompalamaya çalışıyorum.

        En büyük hayalim, Türkiye’deki firmaların sağlıklı yazılım yaşam döngüleriyle dünya standartlarında kaliteli mühendislik yapabilmesi…. Ama ne zaman gerçek olur hiç bir fikrim yok :/
        B.

    3. Mahmut E. dedi ki:

      Video’dan alıntı: “We are developers, we write code, we don’t talk about code, we write code.”

      Hayır dostum, bilakis yazılım üretmenin büyük kısmı kod yazmak değil, iletişim kurmak/kurabilmektir. Kullanıcıyla ya da hemen yan masadaki diğer yazılımcı ile.

      1. kmlckr dedi ki:

        Hacker mentalitesindeki developerlar birbirlerinin yazdıkları kodu anlayabilirler. Bir arada çalıştıkları için birbirlerinin perspektfini bilirler. Tıpkı barcelonanın paslaşmaları gibi. Bu da bi iletişim aslında çok daha güçlü bir iletişim.

  5. Enzeki dedi ki:

    Öncelikle yoruma başlamadan yazının agile ile ilgili yazılmış en iyi türkçe yazılardan biri olduğunu ve yorumumun bu yüzden direkt olarak yazara olmadığını belirtmek isterim. Ancak agile ile ilgili pek olumlu düşüncelerim yok.

    Agile development için söylenen sözlerin %95 genel geçer doğrulardır. Yazılım hızlı üretilmeli anında hatalar görülmeli vs. İyi bir yazılım projesinde iyi developerlar ve zeki insanlar bulunmadığı sürece hangi methodu uygularsanız uygulayın başarısız projeler üretilecektir. Yazılımı nasıl yaptığınızla değil yazılımın kendisine mimarisine zaman ayrılmalı. Her gün sprint yetiştireceğim diye her yeri copy paste kodlara boğarsanız tabi ki test edemezsin. Bırak test etmeyi ne yaptığınızı iki gün sonra hatırlama ihtimaliniz bile olmaz.

    Son olarak Ben her sabah toplantı yapmak kadar gereksiz az şey görmüşümdür.
    Agile development Türkiye’de fazla mesai için bahane. hele sprint kelimesi geçiyorsa.

    1. Merhabalar,
      Yazdıklarınızın bir kısmına katılıyorum ancak şunu da belirtmek isterim ama Türkiye’de uygulanan “agile”, “agile” değil genelde 🙂

      Öncelikle, fazla mesai kesinlikle olmaması gereken, ancak ve ancak çok olağanüstü durumlarda yapılabilecek bir şeydir. Agile’ı herhangi bir şekilde fazla mesai sebebi olarak göstermek yukarıda da bahsettiğim gibi “felsefeyi anlamamaktır.”
      Kod kalitesi de agile’ın içerisinde kontrol altında tutuluyor. Agile, sadece Scrum değildir. XP (eXtreme Programming), “Code Review” gibi, “Refactoring” gibi “Technical Debt” gibi “Peer Coding” gibi kavramlarla bunu kontrol altına almaya çalışır. Eğer iş akışınızın içerisinde, Code Review gibi bir adım tanımlarsanız, kod daha teste girmeden başka bir yazılımcı tarafından kontrol edilecektir.
      Diğer bir sorun “sprint yetiştirme”nin bir kaygı olması. Sprintler özünde, yazılımcıların o iş dönemi içerisinde bitirebilecekleri iş içeriği için anlamlı şeyleri seçmesidir. Yazılımcı, kendi yapacağı işe kendisi “commit” eder. Zaten sağlıklı takımların da iş hızları bellidir.

      Genel olarak şunu söylemek isterim, agile doğru uygulandığı takdirde gayet faydalı. Ama işinin ehli olmayan insanların kafalarına göre okudukları 2-3 makaleden yola çıkarak “yaptırttıkları agile”, gerçek proje yönetimi pratiklerinin başarısını gölgeliyor. Hatalı, yanlış anlaşılmış agile yapılacağına, hiç yapılmamasını ben de yeğlerim.

    2. Burcu dedi ki:

      Yazar detaylı yanıt vermiş. Ben de günlük toplantı konusunda ekleme yapayım, 1.5 yıldır aynı takımla düzenli olarak uyguluyoruz. 15 dakikalık bir toplantının hemen hemen kimseye vakit kaybı-dikkat bölme gibi olumsuz bir etkisi yok, artıları ise çok. “Toplantıdan sonra devam edelim” diye başlayan teknik fikir alışverişleri, gün içinde bir araya gelme konusunda genellikle ilk adımın bu toplantılarda atılması, bir nevi günlük işlerin ve kaynak kullanımının (örn. test pc’si) planlanması, diğerinin yaşadığı problemden feyz alan ya da hatırladığı bir bilgiyi paylaşanlar vb. çok oluyor. Özellikle birebir brilikte çalışmayan kişiler arası haberleşmeyi attırıyor. Ayrıca yapılacak duyurular, aktarılacak haberler varsa kuru bir mail atmak ya da haftalık toplantıyı beklemek yerine günlük toplantının sonunda sıcağı sıcağına yapmak ve takımın tepkisini ölçmek için de bir fırsat.

  6. Volkan Akkuş dedi ki:

    Süreç, araç ve insan. Birisi yetersiz olursa proje başarısız oluyor.

    Bence dünyada iyi yazılımcıdan fazla iyi yöneticiye ihtiyaç var.

    1. Zekeriya Aydin dedi ki:

      Eskiden bu ihtiyac vardi, ama simdi kendi kendine organize olan, proaktif ve sorumluluk alan ekip, yoneticinin yerini doldurmak zorunda, yoneticiler kocluk ya da aksaklik cozucu role burunmeli, en azindan calistigim sirket uzun tartismalar sonucu bu yapiyi kabullendi ve her gecen gun faydasini goruyoruz, sirket kulturu cok onemli.

  7. Özge dedi ki:

    “Muhasebe veya pazarlama birimleri, “Çok acil!!!” başlıklı emaillerle yazılımcıları taciz edip işlerini bölmeye devam ettiği sürece, söz verilen özelliklerin ürüne eklenmesi imkansız hale geliyor.” Bunu engellemesi gereken scrum master ya da product owner iken o sprint içerisinde 10 madde isteyen po’ya 10 maddeyi de almamız mümkün değil yetiştiremeyiz önceliklendirebilir misin denildiğinde “tüm maddelerin önceliği aynı” cevabını verebiliyor. Rework’de geçtiği gibi her iş acil işe hepsi aynı öneme sahiptir ve hiçbiri acil değildir 🙂

    Agile yönetime geçildiğinden beri mesai yapılmıyor diyerek mesainin önünü açmaya çalışan bir yönetim anlayışı ya da daha da kötüsü “ben yazılım ekibinden iş istediğimde 2 hafta beklemek zorunda kalıyorum” diyen CTO gerçekleri var.

    Backlog dışında yönetim tarafından gelen işlerin ekip tarafından sprinte dahil edilme ya da planlama aşamasında konuşulma çabasının görünmezden gelinmesi (bu işi sprint dışı yapın baskısı) ama sprint ortasında o işin de sprint sonunda bitirilmiş olması bekleniyor.

    Hayaller agile ama gerçekler yazılımcıya para veriyorum niye sonuna kadar yararlanmıyorum seviyesinde.

    1. wolkanca dedi ki:

      Maalesef böyle. Benim bildiğim de bu: “Hayaller agile ama gerçekler yazılımcıya para veriyorum niye sonuna kadar yararlanmıyorum”

  8. Levent dedi ki:

    Yaklasik 3 senedir agile metodolojisiyle calisiyoruz. 6 urunumuzde de PO olarak gorev aldim. Kimisi cok buyuk projelerdi kimisi gorece daha kucuk projelerdi. Metodolojinin en onemli parametresi her iste oldugu gibi iletisimden geciyor. Iyi bir iletisim saglanamadigi surece hangi metodolojiyi kullanirsaniz kullanin basarili olmayacaktir.

    Yazilimcilari projeye sokmamak en buyuk hatalardan biri olacaktir. Yazilimcilar PO’lara fikir veren gelecegi daha rahat gormemizi saglayan kisilerdir. Ben her yazilimcinin projenin icinde olmasini onemsiyorum. Onlarin da surekli fikirlerine danisiyorum.

    Yazida belirtilen kalite konusu da cok kritik bir parametre. Ilk projelerde goz ardi edilebiliyor fakat zaman gectikce takimlar ogrendikce isler daha kaliteli oluyor.

    Son olarak IT ekibinin degil is birimlerinin de agile calismasi gerekli. Sprintte karsilasilacak sorulara mumkun oldugunca kisa surede ve dogru olarak bilgi vermeleri gerekli. Planlamayi bunu da dusunerek yapmali.

    Ozetle projelerimizi agile metodolojisinde yapmaktan ekip olarak cok keyif aliyoruz. Umarim is birimleri yazilimcilarin yerine kendini koyabilir yoksa iyi projelerin cikabilecegine inanmiyorum.

  9. Kamil dedi ki:

    Yaşam koçlarımız bitti, şimdi bilişim koçlarımız başladı, Bir tanede buralarda var eticaret başlıklarında takılıyor “eticaret koçu”…

    Türkiye’nin ilk 250 sanayi kuruluşu içindeki firmanın it’sinde çalışıyorum. Bu 250’nin 50 tanesi ile ilişkimiz var. Hepsinin it’sinin nasıl işlediğini biliyorum. Eğer muhasebe veya pazarlama birimi bu çok acil hemen yapmalıyız dediği işi, şimdi değil diyecek olursanız size şunu rahatlıkla söylebilirim, Çalışacak bir işiniz olmaz. Bu sizi işten çıkartacakları için değil, şirketin devasa cezalarla batağa sürükleneceği içindir.

    Devlet gün aşırı mevcut yasaları değiştirir. Ve bu yasalar öyle zannettiğiniz gibi planlı, programlı ve herkesi kapsayacak şekilde detaylandırılmış değildir. “Kervan yolda düzülür” mantığıyla yapılmış yasalardır. “Şimdi bunu yasaklıyoruz, bir sorun olursa düzeltiriz, kapsamı ya genişletir yada daraltırız” diyerek yola çıkılır.

    Bir sabah bir bakarsınız çok saçma ve olmayacağını düşündüğünüz yasa hayatımıza girmiştir. Muhasebe bir anda tutuşur, çünkü olay o kadar saçmadır ki kimse ne olacağını dahi kimse bilmez. Sizde o sırada ne ile uğraşıyorsanız bir mail alırsınız ve bütün programınız değişir çünkü uyum sağlamak zorundasınız. Hemde mümkün olan en kısa sürede. Planlar yapılır, uyum sağlanır, “evet oldu” der yarım bıraktığınız işin başına dönersiniz, ertesi gün firma yasa kapsamı dışına çıkarılır ve bir mail daha gelir, eskiye geri dönüyoruz acil diye…

    Büyük firmalarda çalıştım diyorsunuz, eğer büyük firmalarda çalışmış olsaydınız çıkan her yasanın ilk önce sizi kapsadığını ve daha sonra bu yasanın uygulanamaz olduğundan yeniden kapsam dışına çıkarıldığınızı ve bu sürecin trajı komik bir şekilde böyle devamlı işlediğini bilirdiniz.

    Eğer siz, agile ile it ruhunun, rönesansına ulaşacağına inandığınız bir dünyada yaşıyorsanız, ben kesinlikle bu mesajı paralel bir evrenden gönderiyorum. Benim dünyamda böyle bir gerçeklik yok çünkü…

    1. mert meriç dedi ki:

      büyük firmanın core işine bakmak lazım, Türkiye’de 250 listesine baktığınızda enerji, metalurji, otomotiv, maden, lastik, gıda diye gider liste… (http://www.iso.org.tr/Sites/1/content/500-buyuk-liste.html?j=5024132) Bu sektörlerde IT yardımcı eleman ve şirketler teknoloji üreten değil kullanan şirketler… Büyük firmadan kasıt odağı yazılım olandır diye düşünüyorum…

    2. Merhaba,

      Planlanmamış iş / planlanmış iş kavramları ile ilgili çok güzel makaleler var, ufak bir Google aramasıyla sürü sepeti karşınıza çıkacaktır, dikkatle okumanızı tavsiye ederim. Her zaman kritik iş çıkabilir. Aniden (!) müşteri talebi gelebilir. Ama öngörülemeyen işlerin çok büyük çoğunluğu aslında planlanabilir. (Örn: İş giriş veri analizi yapılır, 2 haftada 1 defa muhasebeden (ACİL!!) etiketli email geldiği görülür, ortalama harcanan süre hesaplanır ve bir dahaki iş dönemi planlanırken muhasebeye, önceden o kadar süre ayrılır.)

      Ama herhangi bir analiz yapmadan bu işlerin “araya sıkıştırılması” size o yasada yazanların 2 gün geç uygulanmasından çok daha fazla para kaybettiriyor olabilir. Çünkü siz aslında o işi araya sıkıştırarak, domino etkisiyle, görünen ve görünmeyen bir çok işi zarara uğratıyor olabilirsiniz. Aklı başında bir PO (veya PM), o çok acil(!!) işin ROI’nı (yatırımın geri dönüşü) hesaplamayı bilecektir. Ayrıca Türkiye’deki büyük firmalarda gördüğüm tek şey “her şeyin acil olduğu” ve dolasıyla “hiç bir şeyin acil olmadığı”. Herhangi bir dataya dayanmadan, el yordamıyla veya en iyi ihtimalle çoğu zaman göstermelik, şişirilmiş datayla iş yapılmaya çalışıldığı… “Bu iş şimdiye kadar böyle yürüdü” anlayışıyla, kuma gömülmüş kafalarla, araştırmadan, kendini eğitmeye çalışmadan, armut gibi sandalye tepesinde oturarak hasbelkader kendini “senior”/”manager”/”cto” ilan eden adamların dev egolarıyla iş yapmaya çalışmaları benim gördüğüm Türkiye gerçeği.

      Yukarıda değindiğim noktalar “olması gereken”ler. Zaten günü kurtarmaya ve kapıya dayanan yumurtalara alışmış memleketimizde bu kafaya iş yapmaya devam edildiği için sektör kan ağlıyor. Size naçizane tavsiyem, dünyanızdaki gerçekler sadece etrafınızda gördüklerinizden ibaret kalmasın. Farklı açılardan bakarak “gerçeklerinizi” değiştirebilir, paralel evrenleri keşfedebilirsiniz. Hatta bu evrenler o kadar çok hoşunuza gidebilir ki, siz de etrafınızı değiştirmek için gerçekten elinizi taşın altına koyabilirsiniz.

      Son not olarak, Agile Coaching kavramı ile ilgili ufak bir bilgi de vereyim. İlk kez 2001 senesinde yazılım dünyasında kullanılmaya başlıyor. Ben de 2011 yılından beri (4 senedir) aktif olarak bu işle uğraşıyorum. “Life coach” ve “eticaret coach”lar hakkında herhangi bir fikrim yok ancak Agile Coach’luğun yeter gereklerini sizinle paylaşmaktan mutluluk durayım.

      Sevgiler,
      B.

      1. Kamil dedi ki:

        Elif Hanım; teorik doğrular gerçek değildir.

        Mobbing doğru değildir, hatta suçtur. Askeriyede cezası 6 aydan başlar. Doğruyu uygulayarak teorik doğruyu, gerçeğe çevirmeyi Askeriyede mobbing üstünde deneyerek ufkuzu ve çevrenizi açmayı deneyin. Deneyimlerinizi bizle paylaşın.

        Sonra benim küçük çevremdeki evrenlerin ne kadarda gerçek dışı olduğunu tekrar konuşalım.

        Agile 2001’de ortaya atılmış olabilir, OOP 1960 larda ortaya atılmış ama hala pratikte ne kadar geçerli tartışılıyor.

        Mert Meriç; Bizde Demir Çelik sektöründe faliyet gösteriyoruz. Bu firmalar artık yazılımlarını kendi içlerinde departman haline çevirmeye başladılar. “Sap kuralım uzaya çıkalım” mantığını bırakıp kendi yazılımlarını üretmeye başladılar. Çok yol aldıkları söylenemez.

        Ve Özge; Sizde yazılımın sadece teknoloji şirketleri tarafından kullanıldığı yanılgısına düşmüşsünüz. Sizin örneğiniz için durum doğru devletin suçu yok. Ama bizim gibi firmalar, sadece eticaret yasasını yasasını takip etmiyor. Bizim muhasebe saate bir değişen imar yasasını bile takip ediyor. Düşün demir işi yapıyoruz…

      2. Birge adını daha çok kullanıyorum, Birge diye hitap edebilirsiniz.

        Asker kökenli bir aileden geliyorum, askeriyenin yapısını ve içerisini emin olunuz ki ortalama bir Türk erkeğinden çok daha fazla biliyorum. Mobbing gerçeği sadece askeriyede değil, büyüklü küçüklü tüm firmalarda aynı şekilde işliyor. Çok yakın bir arkadaşım ciddi şekilde cinsel tacize uğramasına rağmen, sadece mütecavizinin bir kısım siyasal sebeplerle korunması nedeniyle işinden atıldı. Ama bu demek değil ki bunu sineye çekiyor? Davası şu anda sürüyor ve mücadele ediyor. Kendi başına gelenin o firma içerisinde veya o adamın çalışacağı hiç bir yerde başkasının başına gelmemesi için çalışıyor.
        Askeriyede de fiziksel şiddetten tutun oraya buraya sürülmeye kadar çok farklı mobbing türleri var. Askeri mahkemeler de mevcut. Neyse konumuz mobbing veya askeri sistem değil.

        Aslında aynı şeyi söylüyor gibiyiz. Şu andaki Türkiye (ve dünyanın bir kısmının) gerçeği sizin anlattığınız gibi, olması gereken de benim anlattığım gibi. Ancak ayrıldığımız nokta şu, siz bu gerçeği kabullenip değiştirmeye çalışmıyorsunuz. Ben o gerçeği değiştirmek için okumayı, öğrenmeyi, yazmayı, konuşmayı ve paylaşmayı seçiyorum. Öğrenciler yetiştiriyorum. Hemen bugün değilse bile, yarın arkamdan gelecek nesilin şu anda yapılan tekrar etmeyeceğine inanmak istiyorum.

        (İşin hiç politik yaklaşımlar, eğitim düzeyi, cultural power index, vs gibi konularına girmeyeceğim…)

        Sevgiler,

      3. Kamil dedi ki:

        Birge Hanım;

        Bu okuyarak, yazarak, araştırarak veya paylaşarak çözebileceğiniz bir sorun değil. Sizde yazılımın sadece plazalarda, eticaret sitelerinde veya bir birini oyladığınız uygulamaların yazıldığı şirketlerde geliştirildiğini veya kullanıldığını sanıyorsunuz.

        Ben gelen mesajlardan şunu anladım. Sanayi kuruluşları sap kurar, eta kullanılır işte excel bilirler. It’de ağ kurar, pc formatlar. Gelin size yaptığımız bir projeyi anlatim.

        Google’a “boru profil makinesi” Yazın önce makineye ve hatta bakın. Şimdi çokta teknik detaya girmeyecem. Makineler imalatlarına göre belli bir hat hızına sabittir. Hesap dakika bölü metredir. Üretim planınız, üreteceğiniz mala göre hattın hızını ustası veya müdür belirler. Müdür 40 la çalıştırın der makineyi ve ürün kalitesini riske atmaz. Usta inisiyatif alıp 60 la çalıştırır üretimi 1 saat erken bitirip dinlenmek için. Genelde patronlar son hızı tercih eder. 🙂 Genel müdür bir gün gelip “bipppp yapacağınız işi der. Ben ne dersem o olacak der ve it’yi çağırır”. Makinenin kullanım klavuzunu önümüze koyar, bakın bunun şuradan ayarlarına uzakdan erişim varmış der. Biz içimizden “Sıçtık” dedikten sonra, buraya bir program yazın ben buradan basacam hattın hızını belirleyecem diye devam eder. Bu makineler en yenisi 15 yıllıktır, öyle usb’leri yoktur, üstlerindeki lptler ölmüştür. Önce bu Lpt’leri yenilersin, ve portları doğru bağlayana kadar anan ağlar, sonra deneye yanıla verileri okur, deneye yanıla veri göndermeyi başarırsın. Bu süre içerisinde eğer ki muhasebe seni arar ve “acil” sihirli kelimesini kullanırsa, değil genel müdür patron başında olsa bırakıp önce o sorunu giderirsin.

        Bizde plaza edebiyatı yoktur. Felsefik yaklaşımlar yoktur. “Aha şuradan kablo çek benim bilgisayara bağla ben buradan basacam, benim dediğim olacak” vardır. Şimdi gidip Genel Müdür’e “patron bak agile varmış şu bu.” desem. Bana cevabı şu olur “bipp bipppp bipppppppp bip bip bipppppppppppppppppppppppppppppppppppppppppppppppppppppppppp”.

        Bu ne sizin nede herhangi bir yaklaşımın çözebileceği bir durum değildir. Yasalar, piyasa, üretim programı, ürün çeşitliği devamlı değişen şirketlerde, siz belli bir yaklaşım geliştiremezsiniz. Çünkü ortam stabil değildir.

        Buda yaklaşımınızın belli şirketlerde belli alanlarda geçerli olabilme ihtimalini yüz yılın buluşuymuş gibi lanse etmenize yeterli olmaz.

      4. dsezen dedi ki:

        Kamil Bey,

        Türkiye’de bahsettiğiniz birçok plaza şirketi (500+ kişi) Agile yöntemlere çoktan geçmiş durumda ve Enterprise Transition ı tartışıyorlar ve yapmaya çalışıyorlar. Bunu yapmayan şirketler Global yapılan araştırmalarda da gözüken, 10-20 sene içerisinde verimsizlikten dolayı büyük bir rekabet dezavantajı olacak gözüküyor.

        Ortamı stabil yapmak daha çok insanlarda bitiyor, yoksa ben buna plansızlık ve stratjik düşünmeme olarak yorumluyorum. Ama piyasa ve market şartlarının sık değişmesi derseniz, zaten Scrum bunun için var:)

        Bilginize,
        Barbaros Derya

      5. Kamil dedi ki:

        dsezen;

        Geçiş yaptığını söylediğiniz bir tane şirket söyleyin, it’si ile iletişime geçelim. Eğer bu şirket muhasebesine “şimdi değil, daha sonra.” diye biliyorsa. Bende imana gelip, secde edecem…

        Hodri meydan.

      6. dsezen dedi ki:

        Kamil çok büyük konuşuyorsunuz, Agile dönüşümler konusunda kötü tecrübeler yaşamışsınız veya bir nedenden dolayı tepkilisiniz diye anlıyorum.

        Buyrun istediğiniz şirketi arayın:
        EPAM
        GlobalLogic
        Siemens
        Microsoft

        Daha isterseniz de 100lerce verebillirim.

      7. Kamil dedi ki:

        dsezen;

        Bizim sekreter hanıma beni Microsoft’un CTO’suna bağla dedim, şu an sekreter hanımın ne yaptığını daha çok merak ediyorum…

    3. Özge dedi ki:

      Aylar önce 1 mayısta çıkacağı belli olan e-ticaret yasası kapsamında yapılması gereken değişiklikleri nisan ayının son haftasında hatırlayan pazarlama ekibinin cezasını yazılım ekibi çekiyor. Burada devletin ya da işleyişin yanlış yaptığı bir şey yok. Sorumlu her ekip kendi üzerine düşeni yapmamasının sonucu bu.

      Ayrıca özellikle pazarlama tarafında sürekli acil diye gelen işlerin yazılım geliştirme kapsamında olup olmadığı değerledirmeli. Bunların büyük bölümü destek ekiplerinin çözebileceği işler.

      1. Dsezen dedi ki:

        Ozellikle talep edilen islerde estimated-RoI ve Live sonrasi actual-RoI yapilmadan ve bahsettiginiz gibi bir master plan olmadan son dakika talep edilen isler yogunlukla gozlemlenen bir durum. Agile Portfolio Yonetiminin tum sirket tarafindan benimsenmesi gerekir.

  10. mert meriç dedi ki:

    Türkiye’de Agile: “Bugünden yarına değil de, çabuk çabuk…”
    Trükiye’de Agile Coach: “Gerçek Agile bu değil”

    1. 😀

      Dokunabilir misiniz gözyaşlarıma mısralarımda? 🙂

  11. bahtiyartan dedi ki:

    Agile yada diğer metodolojiler doğru uygulandığında doğal olarak iyi sonuç verecektir.
    Başarı temelde; yatırımcı, yazılım geliştirici, yönetici, kullanıcılar vs. gibi tüm paydaşların kendi sorumluluklarını yerine getirmelerine bağlıdır.

    Önemli olan metodojojinizin takımın ruhuna projenin yapısına, beklentilere vs uygunluğudur. Malesef ülkemizde it uygulamalar moda rüzgarları arasında sürüklenir. Gerektiği için değil moda olsun diye uygulanır çoğu şey. Biraz da bakın biz “agile” uyguluyoruz, değişime açığız vs gibi klasik ağızların altını doldurma çabaları.

    Moda olduğu için değil, gereksinimlere ve kaynaklara göre belirlemek gerekir metodolojiyi. Sonuç olarak “Gerçek Agile bu değil” yaklaşımı da bir yere götürmez. Kurum kültürü, yatırımcı, geliştirici yönetici, kaynaklar projenin yapısı, ne gerekiyorsa değerlendirip ona göre bir metodoloji belirlemek en doğrusudur.

Bir Yorum Yazın