Teknik bir sorunun o kadar da teknik olmayan çözümü — Dönüşüm hikayesi

Her şey 40 yazılımcının yazdığı her kodu nasıl olur da birbirinin ayağına basmadan canlı sisteme kurabiliriz sorusuyla başladı. Arkasından işler büyüdü tabi ki, ninja gibi günde 10 defa canlı sisteme nasıl kurulum yaparız diye sordu birisi. Derken bütün takımları baştan kurmanın en iyi başlangıç olacağına karar verdik ve tüm altyapıyı değiştirmeye koyulduk. Teknik bir yazı olmayacağı için şimdiden özür dilerim, ama bu sefer işin yönetim açısından zorluklarından bahsedeceğim.
Software is hard — Donald Knuth
Biraz geriye alayım. Yaklaşık 2 yıldır Londra’da Wonga adında bir firmada çalışıyorum. Geçirdiğim bu kısa süre içerisinde iki defa takımların hepsinin baştan kurulduğuna tanık oldum. Her seferinde bir amacımız vardı tabi ki, ilk seferde takımların ürün haritalarının (roadmap) karmaşıklığını gidermek, ikincisinde ise daha yetenekli ve birbirinden bağımsız yol haritası olan takımlar kurmaktı. Yetenekliden kastım kendi başına yeterli disiplini içinde barındıran takımlar. Yani yeni takım düzenimizde geliştirilmesi gereken bir özelliği tamamlamak için takım içerisinde yeterli yetenekte kişiler vardı. Burada önemli olan uçtan uca bir geliştirmenin tamamlanması için gereken her teknolojiyi bilen en az bir kişinin takımda olması ve yine takıma tüm zamanını ayıran bir product owner’ın takıma dahil olmasıydı.
Kendi başına yetebilen takımlarla bir çok sorunu çözmüştük, ya da en azından biz öyle düşünüyorduk. Her ne kadar takımların sınırlarını çok iyi tanımlamış olsak da 2006 yılından bu yana karanlık bir bulut gibi bizi takip eden büyük bir ‘legacy’ kodumuz vardı. Yeni servislerin tamamı mikro-servis mimarisiyle geliştirilmişti ancak hala daha kocaman birer kaya gibi duran yekpare servislerimiz ve bir ön yüz bileşenimiz vardı. Dolayısıyla takımlardan biri burada değişiklik yaptığında diğer takımların da değişikliklerini canlı sisteme göndermemiz gerekiyordu. Bunun bir sonucu olarak tabi ki koordinasyon toplantıları yapmamız kaçınılmazdı. Bu durumda ne kadar iyi bir ‘continuous integration’ sisteminiz olsa da her kurulum bambaşka bir maceraya dönüşebilme potansiyelini taşıyordu.
Neler yaptık?
İşin en önemli kısmı ne istediğimize karar vermekti, uzunca bir süre bunu tartıştık. Bizim için en önemli olan konu sürekli canlı sisteme kurulum yapmak ve bunu yaparken diğer takımlara ait bir bileşeni ya da özelliği bozma ihtimalini tamamen ortadan kaldırmaktı. Bunun için sadece takımların etki alanlarını iyi belirlemek değil teknolojiyi ve mimariyi de buna göre planlamak gerekiyordu.
Kararımızı verdikten sonra mimariyi ve takımların etki alanlarını çok yüksek seviyede iş ihtiyaçlarına göre tartışmaya başladık. Sanırım en önemli kısımlardan biri de buydu ve tüm departmanı üç ayrı etki alanına bölmeye karar verdik. Böylece mimarimizi buna göre şekillendirebilir ve kişileri bu etki alanlarına göre dağıtıp ne yapmak istediklerine karar vermelerini isteyebilirdik. Bir başka sorun da tabi kimin hangi etki alanına gideceği ve yeni organizasyonun nasıl olacağıydı. Bunun için takımda anket yaptık ve herkesten çalışmak istediği etki alanını sıralamasını istedik. Ayrı bir ekip de herkesin birinci önceliğini göz önünde bulundurarak doğru alana yerleşmesini sağlamaya çalıştı, ancak sonrasında sonuçları herkesle paylaşıp ince ayar yapıldı. Sonunda büyük bir çoğunluk sonuçtan memnundu, en azından memnuniyet anketine göre %85 memnuniyet sağlanmıştı. Herkesi memnun etmek gerçekten çok zor…
Biz tüm bunlarla uğraşırken firmamızın CTO’sunun daha zor bir görevi vardı. Herkese teknoloji departmanının gelecek 9 ay boyunca kritik görülmeyen hiç bir değişikliği yapmayacağını ve buna ek olarak firmanın yeni özellik geliştirmeyeceğini anlatması gerekiyordu. Sanırım kendisi bu konuda çok güzel bir iş çıkartmış olacak ki bununla ilgili bütçeyi garantileyebildi. Tabi kapalı kapılar arkasında nasıl tartışmalar olduğunu bilmiyorum, ancak ben kendisiyle konuştuğumda biraz stresli olduğunu görmüştüm. Zaten böyle bir projeye başlarken yönetimin desteğini almazsanız başlamadan başarısız olmuşsunuz demektir.
Planladığımız mimariyi biraz daha açmak isterdim, ancak elbette firmanın ticari sırları olduğu için detay veremeyeceğim. Fakat izlediğimiz yoldan bahsedebilirim.
Presiplerin belirlenmesi
Aslında en başından bu yana tepeden inme hiç bir karar verilmedi. Kimse gelip de bunu böyle yapın demedi, zaten şahsen ben ama daha önemlisi firmadaki liderlik ekibi de buna hep karşıydı. Bunun yerine takımlar toplanıp prensiplerini belirlemeye koyuldular ve bu prensiplere uydukları sürece herkes kendi tasarımını yapmaya başladı. Tamamen otonom ilerlemesini istediğimiz bu sürecin herkesi geliştirdiği yazılımı ve teknolojiyi sahiplenmeye itmesi en büyük kazanımlardan biri olsa gerek.
Planlama aşaması
Tüm bunlar belirlendikten sonra herhangi bir yazılım ya da özellik çıktısı olmayan bir hayalet sprint oluşturduk. Yani iki hafta boyunca takımlar kendi içlerinde bir araya gelecekler ve kendi takımlarının temeli olduğunu düşündükleri konularla birlikte kısa vade ve uzun vade olmak üzere planlarını hazırlayacaklardı. Gerçekten zor bir iki haftaydı, çünkü her takım amaçlarını, çalışma yöntemlerini ve etki alanlarını belirleyeceklerdi. Üstelik bunu yaparken diğer takımlarla da workshop’lar yaparak onların etki alanlarını anlayıp boşlukları sahipleneceklerdi. Bunun için büyük bir toplantı takvimi oluşturup duvara astık ve her sabah etrafında 10 dakika boyunca toplanıp her takımın kendi yapacağı toplantıları ve diğer takımlardan ihtiyaçlarını tartıştık. Böylece herkes kimin ne üzerinde çalıştığına hakim olmaya başladı ve kendi eksiklerini de görerek bir sonraki gün kapatma fırsatı yakalamış oldu. Tabi bununla kalmadı, ofisin başka bir yerinde bir duvara yeni oturma planını oluşturduk, her post-it üzerinde başka birinin ismi yazılıydı ve takımlarda ortak işlerde ya da disiplinlerde çalışanların aynı alanlarda oturması çok önemliydi. Yine buna takımlar ortak bir şekilde karar verdiler ve yerler belirlendi.
Her takımın kendi aldığı kararlarla ilerleyebiliyor olması çok önemliydi. Yani ‘biz Scrum uygularık’, ya da ‘burada şöyle çalışılır bu da şu dokümanda yazar’ şeklinde Zeus tarafından koyulmuş kurallar yerine her takım tamamen özgürce kendi kararlarını aldı. Örneğin benim takımımda ‘Kanban’ uygulamaya karar verdik, ancak başka bir takım sprint’lerin iyi olduğunu düşünerek iteratif bir yöntem belirledi. Bir diğeri de ‘Scrumban’ uygulamaya karar verdi. Bunları hiç bir yere yazmadık, dokümante edip tanrı buyruğu gibi başımızın üstüne de asmadık. Diğer taraftan bazı takımlar farklı disiplerin birbirleriyle etkileşimde olmasına inanmazken benim takımım ‘grooming’ toplantılarını ortak yapmaya karar verdi, çünkü benim takımımdaki arkadaşım ve ben teknolojiden ziyade uçtan uca sahipliğin daha önemli olduğuna inanıyorduk. Böylece ortaya bir sürü farklı kültür ve iş yapış biçimi çıkmış oldu.
Söylemeden edemeyeceğim, bu farklı iş yapış biçimlerinin ileride firmaya daha çok katkı sağlayacağına inanıyorum. Yani kanban uygulayan bir takım belki bunu yapmayan takımın ilerlemesini gördüğünde ‘biz de onlar gibi şöyle mi yapsak?’ diyecek ve kendisine başka bir şey katarak belki de süreci daha iyi hale getirecek. Ya da hatalarını görerek kendisini aynı hatalardan sakınabilecek.
Bir diğer önemli konu ise takımların başarı kriterlerinin yani KPI’larının belirlenmesiydi. Her takım kendi KPI’larını kendisi belirleyip herkesle paylaştı, böylece işi en iyi bilen insanlar başarılarını ölçülebilir hale getirebildiler. Yani patron gelip ‘senin performansını bu belirler mesela code review yaptın mı yapmadın mı?’ diye omzumuza gereksiz ve ölçülmesi bile saçma bir kaya bırakmadı. (Eğer bunu okuyanlardan bu taşın nereye gittiğini anlayan varsa bana haber versin!)
Sonunda ne oldu
Korkunç yoğun geçen iki hafta sonunda takımlar kendi planlarını, yapılarını ve amaçlarını anlattıkları sunumlar yaptı. Herkes sorular sordu, eleştirdi ya da mühendislik ekibinde olmayan kişiler bir şeyler eklemeye çalıştı. Kimileri mantıklıydı, takımlar bunları kendi planlarına dahil etti kimileri mantıklı değildi takımlar bunu saygıyla dinleyip yerlerine oturdu. Ama önemli olan firmadaki herkes kimin ne yaptığını öğrendi ve katkı sağlama fırsatı yakaladı.
Amacımız canlı sisteme ninja gibi kurulum yapmakken bir anda şirketin organizasyonunu değiştirmek zorunda kaldık. Ulaşmayı hedeflediğimiz yere küçük adımlarla her gün yaklaşıyoruz, şu anda kurmayı başardığımız bir continuous delivery hattımız bile var. Artık daha küçük bileşenler yazıyoruz, monolit olan kocaman kayayı ilk etapta üç parçaya böldük şimdilerde 6 parça olacak gibi görünüyor ve deneme yanılma yaparak ilerliyoruz. Ön yüz için konuşacak olursam, kocaman bir PHP uygulamasını 4 ayrı Angular uygulamasına ve yekpare duran bir entegrasyon katmanını da Graphql sunucusuna dönüştürmeye karar verdik, bir kısmı bitmek üzere bile. Bittiği gibi hemen devreye alarak sonuçlarını erkenden görüp, erkenden başarısız olmak ve tecrübe edinmek istiyoruz.
Çoğu zaman teknik olduğunu düşündüğümüz bir çok problemin aslında teknik olmayan çözümleri de var. Ya da benzer şekilde teknik olduğunu düşündüğümüz sorunun sebebi teknik olmayan şeyler çıkabiliyor. Bunun en güzel örneğini sanırım geçtiğimiz 3–4 aydır yaşıyorum. Günümüzde yazılım o kadar karmaşık bir hal almaya başladı ki, artık mimarilerin takım organizasyonlarına ya da organizasyonun şeklinin teknik mimarilere etkisi olabiliyor. Teknik bir sorunu çözmek için kimi zaman teknik olmayan çözümlerle başlamak durumunda kalıyorsunuz.
Yazılım zor iş.
Esen kalın!

