Eylul 2019 yine yoğun geçti. 

Aşağıdaki sınıflarda, Eylül ayında, akıllarda en çok kalan benzetmelerden biri "Hamburger'in TURŞUSU da EKSİK Kalsın" idi.  :) 

Logo Yazılım (CBAP), Halkbank (COBIT, Temel Yazılım, CBAP), Havelsan Teknoloji Radar, Türkiye Bankalar Birliği, BT Akademi CBAP Açık sınıf derken Eylül ayı bitmiş.  Akıllarda Turşu kalmış.  Tabi, eğitimlerime katılanlar bilir esas SUÇUK önemli.  :) 

"Hamburger'in TURŞUSU da EKSİK Kalsın" ile ne kast ediyoruz?  Bunu çevik yöntemler ile klasik yöntemler arasındaki farkı anlatmak için kullanıyorum.

Klasik yöntemlerde Kapsamdan taviz verilmez.  Onun yerine zamandan taviz verilir.  Yani, gereksinimlerin hepsi eksiksiz olsun ama bunun karşılığında gerekirse geç kalınsın.  Klasik yöntemlerde geç kalmak normal olmuş artık, sebeb gereksinimlerden taviz verilmez, verilemez.  Halbuki, geç kalmaya değmeyecek gereksinimler de olabilir (Hamburgerin içindeki turşu gibi...  :)  

Öte yandan, Çevik yöntemlerde ise zamandan taviz verilmez (buna TIMEBOX denir.  Timebox yerine "zaman konservesi" de denebilir.)  Diğer bir deyişle, zamandan taviz vermemek için kapsamdan taviz vermeyi tercih ederiz (çevik yöntemlerde)...  Yukarıdaki resimde hamburger projenin beklenen çıktısını temsil ediyor.  Gereksinimleri, ÖNCELİKLENDİRMEK çevik yöntemlerde daha bir anlamlı oluyor çünkü vakit yetmediğinde bazı gereksinimlerden vaz geçmek, geç kalmaktan daha iyi olabilir (çoğu zaman geç kalmaktansa eksik çıkmak daha iyi olur).  O yüzden hangi gereksinimlerin "olmazsa olmaz", hangi gereksinimlerin "olmasa da olur" olduğunu en baştan ayırt etmek gerekli.  Bu çevik yöntemlerin ruhunda var.  Kısaca, geç kalmaktansa Hamburgerin TURŞUSU da eksik olsun.  :) 

Önceliklendirme için kullanılan yöntemlerden biri MOSCOW dur:
Must - Birinci öncelikliler
Should - İkinci öncelikliler
Could - Olmasa da olurlar
Won't - Kapsamdan hali hazırda çıkarttığımız gereksinimleri temsil ederler.  

Bunu daha iyi anlamak için EXCEL kullanırken bir düşünün, excel in yüzde kaçını kullanıyorsunuz.  Excel'de olmasa da fark etmeyeceğiniz ne kadar çok fonksiyon var dimi...  Bir excel projesi yaptırdığınızı düşünün ve bu kullanmadığınız fonksiyonlar için projenin aylarca geç kaldığını hayal edin, böyle bir şey ister misiniz?  Yoksa TURŞUSU da eksik kalsın mı dersiniz?  :) 

Barış, huzur, esenlik üzerinize olsun,
Orhan

Garson:  Is Analistini (BA - Business Analyst ' i)  temsil ediyor.

Mutfak:  Yazilim gelistirme ekibini (Development team ' i) temsil ediyor.

Eger, garson (BA) siparisi yanlis alirsa (ki musterinin ne istedigini bilmedigi gercegini simdilik bir kenara koyalim) mutfak naparsa, yapsin musteri gelen yemekten memnun olmayacaktir. 

Dolayisi ile, garson 'un musteri memnuniyetinde cok onemli bir rol oynadigi asikar.  

Musterinin ne istedigini bilmedigi durumda, musterinin istediklerini parca parca masaya getirerek bir yanlislik varsa, bunu hizlica ogrenmeye calismaya CEVIK yontemler diyoruz.  

Siparisin tamaminin hazirlanmasini beklemeden, hemen masaya icecekleri vb birseyler getirmek ve en azindan masaya gelenler konusunda musterinin tepkisini hizlica almak birseylerin yanlis anlasilmis olma ihtimalini azaltabilir.  (karniyarik isteyen musterine (MVP = minimum viable product) modunda hemen hizlica bir karniyarikimsi birsey getirmek zor olabilir.  ==  Asagida bir e-ticaret sitesinin kismen hizlica nasil yapilabilecegine bir ornek vermeye calisicam = yemek yapmak, insaat yapmak, kopru yapmak gibi, biraz yap, sonra yik tekrar yap seklinde ilerlemeye musait olmayabilir)

Garson'un siparisi yanlis almasi konusunda bir nokta daha var.  Siparisi kimden aldigi... ?!!!

Soyle bir senaryoya ne dersiniz?  

Restaurant'a gelen bir ailede anne-baba tuvalete gitmis, masada cocuklar oturuyor.  Garson geliyor ve anne-babanin da ne yiyecegini cocuklara soruyor. Cocuklar anne-babalari ve kendileri icin siparis veriyor.  Bu durumda garson, siparisi cocuklardan dogru almis olsa bile, cocuklarin anne-babanin ne yemek istedigini dogru bildiklerinden emin miyiz?  Is hayatinda aslinda siklikla karsilasilan bir duruma benzemiyor mu?  Esas ihtiyac sahibi projeye bilgi vermek icin BA ile konusmak icin vakti olmaz, birileri gorevlendirilir.  Gorevlendirilirken TAHMIN ETTIKLERI kadariyla projenin ne yapmasi gerektigini anlatirlar;  onlarin da yanlis anlasilmasi; onlarin yanlis anlatmasi ihtimalleri hep var.  Ama, eger ne istendigini tarif eden kisiler ilk agizdan ne istendigini gercekten bilmiyor ise, bu da klasik buyuk bir sorun degil mi?  

Siparis veren kisilerin tecrubelileri garson'a sorar degil mi?  Ne tavsiye edersin diye?  

Mesela, soyle der "kirmizi et yiycez, ne tavsiye edersin?"  Yani siparisi verenin direk yemek ismini soylemesi yerine garson'a sormasi daha basarili sonuclara yol acabilir.  Garson soyle diyebilir.  Bu aksam su yemek cok iyi, onu tavsiye ederim.  

Musterinin DERTine odaklanip, cozumu garsona birakmasi daha iyi olur.  

Hem PMP hem CBAP icin 4 temel gereksinimler:

Is gereksinileri (Business requirements  = Dert = Projenin AMACI) 
Paydas gereksinimleri (Stakeholder requirements = Paydaslarin ihtiyaclari) 
Cozum gereksinimleri (Solution requirements) 
Gecis gereksinimleri (Transition requirements) = mesela 1000 ATM de birseyler degisecek, degisimin 1000 ATM de hepsinde birden aniden mi yapilmasi daha iyi olur, yoksa 1 -> 10 -> 100 -> 200 ->  500 -> 1000 seklinde mi GECIS (Transition) yapilmasi daha iyi olur.  Bazen guvenlik (security) aciklarini gidermek icin 1000 ATM ye hepsine aniden bir kerede GECIS yapilmasi gerekebilir ancak genellikler acil bir durum yoksa asamali gecis daha az risklidir. 

Sonuc olarak:
Lokantanin basarisi takim olarak herkesin gorevini yerinde ve iyi yapmasi ile mumkun.  Ancak, eger Garson siparisi (is analisti gereksinimleri) dogru alamaz ise, mutfak (gelistirme (development) ekibi caresiz kalir.  Dolayisi ile projelerimizde gereksinimlerin dogru alindigindan emin olmak cok onemli bir konu.  Gereksinimleri soyleyenlerin dogru/gercek/oz/hakiki musteri olmasina (anne-baba yerine siparis veren cocuklara) dikkat!!! 

CEVIK yontemlerin calismasi icin OZ, HAKIKI, GERCEK musteriyi bulmak ve sik sik or: 2 haftada bir calisan yazilimi OZ, HAKIKI, GERCEK musteriye gostermek cok onemli.  

Is analistinin en onemli gorevlerinden biri de:  Musteriyi dogrudan COZUMe odaklanmaktan alip AMAC ve ihtiyac 'a cekmek....  Soylemesi kolay tabi...  :)  

Not:  yukarida monolizayi anlaticam demistim ama yazi cok uzadi, onu bir sonraki yazima birakayim....  Parmaktan sonra...  gelecek yazimda, monaliza'yi kisim kisim (CEVIK) yapmayi anlatirim.  :) 

Ucretsiz PDU - 2 PDU degerinde DevOps semineri - 2 Subat 19:00 - 21:00 : Atasehir - Istanbul

Kayit icin: https://www.eventbrite.com/e/ipyd-seminer-devopsun-7-srr-tickets-55394529529 

Bilişim tarihinde önemli reformlara bir kaç örnek:

Altyapı reformları: Mainframe, Virtual machines, Datacenters, Bulut

Yazılım Mimari reformları: client-server, n-tier, OO, SOA, mikroservisler

Süreç Reformları: Waterfall, Agile (XP, SCRUM), TOGAF, ITIL, PMBOK, BABOK

DevOps, şirketin tamamına aynı anda, bir çok alanda paralel bir değişim getirdiğinden ultra süper bir değişim :)

DevOps'u hayata geçirmek için şirketin organizasyon yapısı (ürün bazlı takımlar), yazılım mimarisi (mikro servisler, containers, CD/CI), teknik alt yapısının (bulut) değişmesi gerekiyor.

DevOps'un temelinde Servis Bakış açısı ile gelen uçtan uça sorumluluk sahibi takımlar ve mikroservisler var.

DevOps başarı ile uygulandığında, şirketlerin 'krizlerden ve rekabetten etkilenmemesi' şöyle dursun, krizlerden ve rekabetten güçlenerek çıkan şirketler göreceğiz: Teknik olarak söylemek gerekirse, DevOps'un amacı AntiKırılgan - ANTIFRAGILE şirketler oluşturmak.

Rekabet ve krizlerden kaçış yok! Sonuç olarak DevOps'a ya geçilecek ya da geçilecek! :)

Elbette, DevOps'a giden yol kolay, dümdüz, rahat bir yol değil. Şirketten kaldırılması gerekenler var: Bölümler arası duvarlar, korku ve aşırı bürokrasi gibi. Şirkete getirilmesi gerekenler var: Cesaret, sayılarla konuşmak ve düşünmek, mühendislik (problem çözme) bakış açısı, yöneticilerin sürekli koçluk yapması gibi.

Okuma önerisi: Antikırılganlık, Deming'in 14 noktası ve Toyota Kata

Deming'in 14 noktası kutsal metinler gibidir, kolay görünür ama zor anlaşılır. Deming'in söylediği en önemli şeylerden biri: 'Şirketinizi sayılarla yönetin, insanları insanlarla yönetin'. Yıllarca, tam tersinin yapıldığını çok gördüm. :)

DevOps sonuç olarak kültürel bir değişim. Şirket yönetiminin şirketi ve çalışanları nasıl yönettiğinin değişeceği ya da klasik şirketlerin yok olacağı bir döneme giriyoruz.

En büyük 500 şirket için eskiden ortalama ömür 75 yıl iken, son zamanlarda en büyük şirketler için bile ömür beklentisi 15 yıllara kadar düşmüş durumda. Rekabetin bu kadar yoğun olduğu bir dönemde DEĞİŞİM zorunlu!
​
Özet: Şirketlerin şu 7 konuda değişime gitmesi şart: DevOps'un 7 sırrı: http://www.devopscu.com/

1. Altyapı : BULUT
2. Mimari: Mikroservis tabanlı mimari
3. Süreçler: Agile, Lean
4. Organizasyon: Ürün bazlı yatay
5. Kültür: Cesur, lean start-up takımlar, çözüm odaklı, mühendislik bakış açısı, deneysel öğrenme, kaliteden taviz vermeyen, servis bakış açısı, otomasyon fanatiği!
6. Otomasyon: Elle bir kaç defa tekrar tekrar yaptığımız herşeyin otomasyona geçirilmesi: CD/CI.
7. Container teknolojisi

DevOps`un 7 sırrını, 28 Eylül Perşembe, DevOpsDays Istanbul'da dinleyebilirsiniz. 

DevOps'un 7 Sırrını ücretsiz indirmek için buraya tıklayabilirsiniz.

Görüşmek üzere,
​Orhan