Online etkinlik serimiz DevOpsX Talks’ın üçüncü oturumunda ACMAgile’ın Agile Dönüşüm danışmanları ile bir araya gelerek sohbet ettik. Bugüne dek çok sayıda dönüşüm projesi gerçekleştiren Agile danışmanları Ahmet Akdağ ve Murat Yurdakul’un katıldığı etkinlikte çevik yazılım geliştirme metodolojisini değerlendirerek, yazılım geliştirme ve DevOps’la ilişkisini konuştuk. Youtube kanalımızdan tüm kaydına ulaşabileceğiniz etkinlikte konuşmacılarımıza hem kendi merak ettiklerimizi hem de katılımcılarından gelen bazı soruları yönelttik ve dönüşüm projelerine dair deneyimlerini dinledik. Bu yazımızda ise etkinlikte öne çıkan en önemli konuları kısaca özetledik.
1.Agile neden önemli?
Ahmet Akdağ:
“Hızla değişen bir dünyada endüstriyel devrimin bitiminden uzun zaman geçtiğini ve internetin hayatımıza girmesiyle dünya her zamankinden daha hızla akmaya başladı, ürünlerin kullanım süreleri düştü, şirketlerin yaşam ömürleri kısaldı dolayısıyla böyle hızla değişen bir dünyada yeni bir projeyi hayata geçirmek hız ve çeviklik isteyen bir konu haline geliyor. Bu noktada agile olmanın ve agile hareket etmenin önemi gittikçe artıyor. DevOps’la ilişkisi ise değişimin ve Agile yöntemlerin iteratif olmasından kaynaklanıyor. Yani ortaya çıkardığımız ürünün üstüne koya koya ve test ederek ilerliyoruz. Bu senaryoda da devamlı test etmenin ve pipeline otomasyon pratiklerinin kullanımı gerekliliği ortaya çıkıyor.
2.Çevik yaklaşımların sağladığı business ve development birlikteliğini DevOps yaklaşımı operasyon olarak gerçekleştiriyor aslında baktığımızda, bu sizce ne kadar gerekli, eksi ve artıları neler?
Berk Dülger:
“Çevik geliştirmede aslında yapılan fikrin business ile birlikte gelişiminin bir araya gelmesiydi, burada yazılım geliştirme sürecinin çok ciddi bir kısmı yazılım canlıya geçtikten sonra gerçekleşiyor. Canlıya çıktıktan sonra Tesla’nın sürekli değişen araba hayali gibi yazılımlarda da benzer şekilde bu sürekli yaşayarak devam ediyor fakat organizasyon içindeki silolaşma, bakış açısının farklılığı, en önemlisiyse yaptıklarının sonucunu görme ve bunlardan sorumlu olmama durumlarından dolayı bu olaylar zor oluyordu. Gerçek bir dönüşüm için geliştirme ekiplerinin ve operasyon ekiplerinin yaptıkları işin sonucunu görmeleri lazım, ancak bu şekilde başarıya ulaşılır, DevOps bunu getirdi. DevOps, business ve IT birlikteliğini operations olarak genişletti, ilk kez süreci uçtan uca ele alma imkanı doğdu.”
3.Teknik çevikliğin organizasyonel çeviklik ile ilişkisi hakkında ne düşünüyorsunuz, bir tercih mi yoksa zorunluluk diyebilir miyiz?
Murat Yurdakul:
“DevOps’un dünyada ilk olarak Agile Infrastructure olarak ünlendiğini sonradan DevOps ismiyle yaygınlaştığını okumuştum. Oradaki vurgu şuydu; DevOps diye kavramın ortaya çıkması çevik takımların ihtiyacı sonunda anlaşılan, sürekli teslimat ihtiyaçları, bazen takımlar bir sprint sonunda her şeyi teslim edebiliyorlardı ama olması gereken sürekli teslimatın yapılması, bir şeyi test etmek veya o değeri müşteriye ulaştırmak için zaman kaybetmemek günümüzde hızla değişen ortam koşullarında çok önemli, bunları dikkate aldığımızda herhangi bir fikri test etmek gerçekten bir sonraki adımı doğru yere atabilmek için, geri dönüşleri toplayabilmek için organizasyonlar özelinde gerçekten çevikleşmek, adapte olmak, yön verebilmek için bunun ben kaçınılmaz bir zorunluluk olduğunu düşünüyorum.
IT bazlı konuştuk ama herhangi bir iş fikrini deneyebilmek için bile sürekli teslimatın sağlanabilmesi, kalitenin hep bir standardın üzerinde tutulabilmesi gerekli, pazara rakip olarak girme çizgisi çok aşağıda, o yüzden kalitenin de çok çok önemli olduğu dünyada hata payına yer bırakmadan, manuel işleri minimize ederek bizi DevOps pratiklerini uygulamaya mecbur bırakıyor.”
Ahmet Akdağ
“Pandeminin ortaya çıkması bizim için bir milat, birçok şey değişti, güçlü bir motivatör oldu, çevikliği düşük olan kimi şirketler içinse büyük bir challenge yarattı. Teknik prensiplerle DevOps’un getirdiği sadece DevOps’un da değil kalite kavramının getirdiği prensiplerle çeviklik arasındaki bağlantı önemli hale geldi.
Mutfakta yemek yaparken biraz da temizlik yapmak zorundasındır, o ortamı sürekli temiz tutman gerekir ki yeni bir şeye yer açılabilsin. Teknik borcun organizasyonların çevikliği ile ilgili büyük bir engel oluşturabileceğini düşünüyorum.”
4.Agile için kültürel adaptasyon önemli bir konu, danışmanlık verdiğiniz ekipler iş yapış kültürlerinin değişmesi konusunda ne düşünüyor, direnç yönetimi yapmanız gereken durumlardan örnekler verebilir misiniz?
Ahmet Akdağ:
“Direnç neden oluyor diye bakmakta fayda var. İnsanların değişim olduğu zaman o kişinin bana ne faydası var sorusuna bir cevap bulması gerekir, bunu bulamadığın her noktada dirençle karşılaşırsın ve bu direnç eğer buna iyi bir cevabın yoksa gizli dirence dönüşür. Yaptığımız bütün dönüşümlerde bu dirençle karşılaşıyoruz, samimiyeti ortaya koymak, insanlara faydasını göstermek, denediklerinde o faydayı görmelerini sağlayabilmek vs,. Dönüşüm uzun bir süreç, DevOps kültürel bir yaklaşım. Otomasyon dediğimiz zaman insanlarda otomasyonun bir ‘mindset’ olarak oturmuş olması önemli bu da muhakkak bir sürü dirençle karşılaşılacak bir konu olduğunu düşünüyorum.”
5.Yazılım ve yazılım ürününün kalitesi herkesin sorumluluğunda inanışı yavaş yavaş yerleşiyor, bu anlamda çevik ekiplerdeki farklı rol ve sorumluluklar tarafından önemsenmesi gereken konulara örnek verebilir misiniz?
Murat Yurdakul:
“Kalitenin herkes tarafından aynı algılanması ve herkesin çalışması biraz da “cross-functional” takımlarla ilgili, değer üretimini sadece kod yazan ya da o kodu test eden insanlarla değil de gerçekten değer üretimini bir ürünle ve servisle müşteriye ulaştığında ve hatta müşteri kullanırken de sağlamak, onu gözetmek ve kaliteden bu şekilde emin olmak ve bu yetkinliklerin tamamının da o ürünü geliştiren takımların tamamında yer alması gerekli diye düşünüyorum.”
Ahmet Akdağ:
“Ürün odaklı mıyız, proje odaklı mıyız konusu da burada işin içine giriyor. Proje odaklı olunca yapıyorsun, tamamlıyorsun ve “proje” diyorsun. ‘You build it you fix it’ çalışması için senin bir ürünün var ve bu üründen sorumluyum diyebileceğin hesap verilebilir bir ortamın da oluşması gerekiyor. Takımların güçlendirilmesi, kendi araçlarını seçebilmesi, pipeline’daki bağımsızlıklar vs. de önemli hale geliyor fakat şu an birçok organizasyonda bu böyle değil, bunlar da ele alınması gereken konular.”
6.Microservices’in çevik yapılanma, ürün odaklılık ve bağımlılıkların azalması konusunda gözlemleriniz oldu mu, bu tarz bir mimari dönüşümü zorlaştıran şeyler nelerdir?
Berk Dülger:
“Dependency’i azaltma anlamında, teknoloji bağımsızlığı anlamında, ekiplerin kendi yolunu çizerek motive olmaları anlamında çok değerli ama bir o kadar da zor. Büyük yapıları küçük projeler, kendi başına işleyen ürünlere dönüştürmek zor bir iş, ben bunun biraz daha yeni geliştirmelerde mümkün olabildiğini gördüm, örneğin mevcuttaki yazılım eski bir teknolojiyse mikro’ya remaster etmeye başladığınızda gerçekten zorlu bir iş oluyor, baştan yapmak daha zor gibi ama çok büyük faydaları var. Yatırım gerektiren bir iş, zaman istiyor, iyi bir mimari pratiğe ihtiyaç var. Bu aslında bir trade off, servis sayısı arttıkça yönetim zorlaşıyor, oraya da çok gitmemek, odağı korumak lazım.”
