Konuklar: Barkın Özakay, Hasan Kuşçu, Betül Aksoy, Nilay Keven Çavdar
60. bölümümüzde konuğumuz Local Commerce Mobile ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Trendyol Talks'da Trendyol'daki kültürümüzü, kültürümüzden beslenen iş yapış biçimlerimizi ve ritüellerimizi konuşuyoruz. Trendyol Talks podcast kanalımızı takip etmeyi unutmayın!
Transkript
Selam ekip, ben Fulfillment Order Master Data ekibinden Fırat.
Ben Storefront TRPDP ekibinden Cengiz.
Teknoloji ekibini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast'imizin 60.
bölümündeyiz. Güzel bir bölüm ve bu bölümde Local Commerce Mobile ekibiyle birlikteyiz.
Local Commerce Mobile ekibini tanıyacağız.
Ekip yapısı, kullanılan teknolojiler, pratikler gibi konulardan bahsedeceğiz.
Arkadaşlar hoş geldiniz. Hoş geldiniz.
Merhabalar. Hoş bulduk.
Merhabalar. Hoş geldiniz.
O zaman isterseniz sizleri önce bir kısaca tanıyalım.
Böylece bir girişi yapmış olalım diyelim.
Topu kim almak ister, kim başlamak ister?
Bugün dört ayrı guestimiz var.
Barkın seni seçtim. Pikachu.
Selamlar. Ben Barkın.
2019 yılından beri yazılım sektöründeyim.
Yaklaşık da iki senedir Trendyol'da iOS Developer olarak çalışıyorum.
Merhabalar, ben de Betül.
2020 yılından beri yazılım sektöründeyim.
Trendyol'da da Developer'ın Test olarak yaklaşık 2,5 yıldır çalışıyorum.
Merhabalar, ben Hasan. 2020 yılından beri yazılım sektöründeyim.
Yaklaşık 1 senedir Trendyol'da Android Developer olarak çalışıyorum.
Selamlar, Nilay ben de.
28 yaşındayım. 2018 yılından beri sektördeyim.
Yani Android developer olarak başlamıştım.
iOS developer olarak devam ediyorum.
Yaklaşık 2,5 yıldır da trend yolda çalışıyorum.
Bir ihanet sezdim Android'den iOS'a geçiş olunca.
Mobil deyince bunları bir anda bahsetmek güzel oluyor.
Çünkü geçen de bir mobil bölümdeydik.
Ve ben yanlışlıkla o ekibi Android ekibi diye tanıttım sanırım.
Meğersem direkt... Bu ekip iOS artı Android'miş.
Halbuki mobil de demişlerdi.
Neden böyle bir izlenime kapıldım hiçbir fikrim yok.
Ama bu bölümde en azından böyle bir şey olmayacak gibi duruyor.
Tekrardan hoş geldiniz arkadaşlar.
Bu arada Nilay keven ne demek? aslında geven bitkisinden geliyor diyebiliyoruz.
Muhtemelen nüfusta keven olarak geçmiş.
Hani dedemler, büyük büyük dedemler geven topluyorlarmış.
Bir rivayete göre kesin olmamakla birlikte.
Hani benim de bilgim bu şekilde dikenli bir bitki diyebilirim.
Ve diğeri de çavlar. Çok iyi bir evet soyadlar.
Müthiş bir yere gelmiş. Çok iyi.
Fırat'ın muhteşem merak içeren soruları.
Bence önemli bir dinleyen biri. Bence bunu çok merak edebiliriz.
Evet gerçekten Local Commerce Mobile ile alakalı ilk sorumuzun hemen olması.
Evet şaşırtıcı bir soru oldu.
Bu yıla Mobile'in yılı diyebiliriz sanıyorum arkadaşlar.
Bu yıl Mobile yılı olacak diyebiliyorum.
Hoş geldiniz. Sizlerle tanışmak gerçekten çok güzel.
Bu arada Nilay en sonunda yaşını da söyledin.
Diğer arkadaşları egale ettin orada.
Diğer arkadaşlar söylememişlerdi.
Diğerleri yaşlı diye ben gencim demek istedi.
Ben böyle anlıyorum. Bence aranızda en yaşlı benimdir ya bu arada.
Öyle mi? Olsun.
Olsun. Okey. Süper.
Şimdi ufaktan sorularımıza başlayalım.
Birazcık aslında takımı tanımadan önce yani aslında takımı tanırken Trendyol içerisinde siz neler yapıyorsunuz?
Yani Local Commerce Mobile takımının ekibinin Trendyol'daki sorumluluğu nedir diye sormak istiyorum.
Biraz isimden aslında anlaşılabiliyor ama hani tam olarak nelerden sorumlusunuz?
Kısaca başlayayım ben.
Go projesinin ana sayfasından yemek ve market kanallarına kadar tüm geliştirmeler ve en güncel teknolojileri sürekli takip edip iyileşmesi.
veya değişmesi gereken tüm yerlerin bakımı.
Ayrıca yapılan tüm geliştirmeler tamamlandıktan sonra Android, iOS ve Huawei platformlarına paketlerin sağlıklı bir şekilde çıkması sürecini kontrol ediyoruz.
Ek bir konu daha var.
Tüm bunlara ek olarak da backend ve client arasındaki BFF olarak adlandırdığımız backend for frontend katmanımız olan SFX'de backend'den gelen veriyi mapleme sorumluluğunu üstleniyoruz.
Biz SFX Open Source yapmış mıydık ya?
Şu an çok cahilce bir soru da sormuş olabilirim ama.
Yok hayır. SFX bizim internet projemiz.
SFX internet yolumuz aynen.
BFF projesi güzel bir projedir.
Buradan da selam olsun onlara diyelim.
Ve o zaman direkt ekipten hazır bahsetmişken ekibin dağılımından da biraz böyle bahsedebilir miyiz?
Kaç developer var? Developer in test, PO, lead varsa bazılarında direkt lead oluyor, olmuyor vs.
ya da ortak QA'ler olabiliyor.
Sizlerde bu dağılım nasıl? Bu soruya da ben cevap vereyim.
Biz aslında mobil ekip olarak şu anda Trendle Go, Mule ve Grocery olarak 3 ayrı ekiple çalışıyoruz.
Mevcut dağılımımızda da yani developer ve test QA dağılımı şu şekilde.
Trendle Go ekibinde 3 iOS, 3 Android developer ve 1 tane QA arkadaşımız görev yapıyor.
Mule ekibinde ise 4 iOS, 4 Android ve 2 QA arkadaşımız çalışıyor.
Son olarak da Grocery ekibinde 3 iOS, 2 Android ve 2 QA arkadaşımız görev alıyor.
Aslında toplamda 10 iOS developer, 9 Android ve 6 QA'den oluşan 25 kişilik bir ekibiz.
Oldukça da böyle dinamik ve yetkin arkadaşlardan oluşan bir ekip ortamımız var diyebilirim.
Ayrıca tabii şirket içi rotasyon kültürü oldukça güçlü ve destekleyici.
O yüzden de bu sayılar zaman zaman değişkenlik gösterebiliyor.
Aslında bu şekilde. Diğer mobil ekiplere kendinizde şey mi yapıyorsunuz?
Git gel falan mı yapıyorsunuz?
Nasıl oluyor tam? Mesela Mobile PD bir ekibi vardı ya.
Örneğin bir önceki bölümlerimizde vardı.
Rotasyon yapınca birisi oraya mı gidiyor örneğin?
Aslında biz yani local commerce içinde daha çok rotasyon yapıyoruz.
Özellikle de Go Projesi çıktıktan sonra yani Mule'daki arkadaşlar Tego'ya rotate edebiliyor veya işte Tego'daki arkadaşlar Grocery'e gidebiliyor.
Böyle vice versa bir durum var.
Tabii PDP ekibinden hatta yakın zamanda Checkout ekibinden iki arkadaş aramızda katıldı.
Core taraftan da rotasyonlar oluyor.
Çok iyi valla yani aslında skopunuzun bu kadar fazla olması, Ve dokunduğunuz yerlerin de çok kritik yerler olması geniş bir ekip olmanızı açıklayan bir şey.
Barkın sen söylediğin zaman ekibi aslında yani şu kadar insan var falan diye ben biraz şaşırdım açıkçası.
Çünkü baktığımız zaman diğer ekiplere oldukça geniş ama bir yandan iOS'a da bakılıyor, Android'e de bakılıyor.
İşte Huawei tarafına vesaire yani mobilin tamamen kapsadığı için anlaşılabilir bir ölçek.
Çok da güzel bence.
Bir yandan da şey problemi var aslında siz bir...
Local commerce skopu içerisindesiniz ama içeride çok fazla ekip var bildiğim kadarıyla.
Yani mobil tarafta işte kullandığınız servislerde SFX dediniz mesela o taraflarda.
Yani aslında birçok servisle böyle birçok ekiple beraber çalışıyorsunuz.
Bu sizin için bir zorluk yaratmıyor mu?
Yani iletişim, ortak çalışma buradaki süreci nasıl sağlıklı yürütüyorsunuz?
Aslında gerçekten zor bir süreç.
Çünkü çok fazla ekip var.
Sadece aslında mobil de değil. Biz bekent ekipleriyle de çalıştığımız için.
Baya fazla bir ekip var ama bunu dengede tutmak için aslında sürekli updateleşiyoruz.
Mesela core tarafta platform ekibimiz var.
Oradan bazen teknik işler geliyor.
Onları yapıyoruz. Bir de haftalık olarak da biz platform ekibiyle mesela updateleşiyoruz.
Hani neler yapılacak, öngörüleriniz nedir diye.
Bir de geliştirme yaparken de sürekli olarak backend ekipleriyle kurduğumuz Slack kanalları var.
Oradan konuşuyoruz. test dataları olsun ya da ek olarak süreçte hani eklenecek bir şey var mı?
Bunlar hakkında konuşuyoruz sürekli.
Ya çok ekiple çalışmak bazen, yani mesela biz de entegrasyon ekibiyiz, şey olabiliyor kendine göre challenge'ları da var gibi bence.
Yani ekip sayısı arttıkça o ekiplerle olan iletişim de yani her zaman kolay olmuyor gibi geliyor bana.
Bu illa o kişilerle iyi anlaşıp anlaşmamaktan dolayı değil.
Sadece bir iş olduğunda şu kadar insanla şunları konuşmamız gerekiyor demek bile bence bir şey oluyor.
Yani kendine bir konteks ekliyorsun gibi de geliyor.
Bana göre pros ve cons var.
Sizin tabii kişisel düşünceleriniz nelerdir bilmiyorum.
Ama tabii az olsun kendiyi başımıza yapalım tabii ki olmuyor.
Ama bir şekilde arttıkça kendine göre de ayrı bir yan etkisi varmış gibi geliyor bana.
Tabii gerçekten öyle bir de remote çalışıyoruz ya.
İyice böyle aslında iletişim şey ama bir de büyüyen bir şirketiz.
Hep yeni şeyler oluyor.
Yeni insanlar geliyor. O yüzden sürekli select'i konuşuyoruz.
Hatta bazen konuşmak yetmiyor.
Zoom da yapıyoruz. Yazıyı da anlayamayabiliyoruz.
Yazılı bir yere kadar geliyor.
Evet, evet. Peki burada sizlerin mesela haftalık sprint mi yapıyorsunuz?
Instagram, daily sprintler vs.
Buradaki çalışma yöntemleriniz nasıl?
Sprintlerimizde haftalık koşuyoruz.
İlk önce grooming yapıyoruz.
İlk önce bir tek de toplantılarımız oluyor.
Burada alacağımız teknik işleri ayrı ayrı...
iOS, Android olarak toplantılarda konuşuyor.
Daha sonra grooming oluyor. Orada da Piyo bize business işlerinden bahsediyor.
Bizim biraz kafamızda bir roadmap oluşuyor aslında planlamadan önce.
Planlamaya geldiğimizde de ilk önce sprint reviewlerimiz var.
Hani neler yaptık, neler kaldı, hangi işler geldi.
Bir bakıyoruz, daha sonra planlamaya başlıyoruz.
Aslında groomingdeki her şeyi de almıyoruz.
Bazılarını alıyoruz, bazılarını almıyoruz.
Bir de daily'lerimiz var. Daily'ler de 10-15 dakika civarı sürüyor.
Updateleşiyoruz. Bloklandığımız durum var mı diye.
Bu şekilde. Technical depth toplantısı demiştin ya.
Yani grumdan önce yapılıyor diye.
Orada şey nasıl oluyor? Mesela bizde şöyle oluyor.
Grumda grumu yapıyoruz.
Grumda sadece dediğin gibi piyonun getirdiği işleri konuşuyoruz ama kendi eklediğimiz maddeler de grumun içinde oluyor.
Daha sonra teknik bir toplantı yapıyoruz.
Hem piyonun getirdiği hem de bizim açtığımız maddelerin analizlerini.
Önemli madde ise konuşuyoruz.
Değilse zaten içindeki analizi okuyoruz gibi bir şey.
Ama hani sizinkinde eğer önce yapılıyorsa.
O maddenin planlamaya gelip gelmeyeceği de belli değil.
Önden bunu konuşup sonra bunu gruba mı getiriyorsunuz?
Biz de bunu getirdik teknik taraf olarak gibi mi oluyor?
Evet. Bir de platformdan da gelenler oluyor.
Mesela iş teknik bir şeyler.
Bir de mesela refaktör süreçleri falan oluyor.
Onların hepsini konuşuyoruz gibi bir şey.
Öyle. Aslında burada şöyle araya girebilirim.
Bizim tarafta mesela iOS özelinde konuşacağım.
Bir tane şeyimiz var, şiitimiz var.
Teknik borçlarımızın olduğu, hepsini grupladığımız işte market, yemek veya sağlıyorum Go için özel ayrı sayfalarımız var.
Oralarda zaten hali hazırda bekleyen işlerimiz oluyor.
Biz sadece o sprintte hangi işi alacağımızı öncesinde konuşuyoruz.
Yani işin kapsamı ve skopu tam anlamıyla belli oluyor.
Planlamaya hazır olan işi getiriyor oluyoruz.
Okeydir. Burada aslında çünkü birden fazla teknik ekibi bir arada olup ortak grumlar yapıldığı için en başta bir teknikler kendi arasında beylane oluyor gibi anladım.
Evet. Aynen öyle.
Süper. Peki şimdi çok fazla ekiple çalıştığınızdan konuştuk.
İşte daily sprintleri nasıl ilerlettiğinizden konuştuk.
Bu diğer ekiplerle çalışma konusunda aslında şey de çok önemli.
Mesela bizim ekiplerde de bu çok yaşanabiliyor.
İşte bir feature geliştirilecek ama bu feature'ın işte search tarafına bir etkisi var.
PDP tarafına bir etkisi var.
X tarafına bir etkisi var.
Y tarafına bir etkisi var. Dolayısıyla birçok ekiple beraber çalışmak durumunda kalıyoruz.
Hatta bizim işte Slack'te çeşitli kanallar açılıyordu.
Bir feature mesela mobile de geliştirilecek işte web'e de geliştirilecek.
Dolayısıyla mobilden de web'den de çeşitli insanlar toplanıyordu o thread içerisinde işte o kanal içerisinde.
Sizin burada yeni bir geliştirme yaparken diğer ekiplerle aranızdaki iletişim durumu nasıl oluyor?
Bunu nasıl yönetiyorsunuz?
Aslında feature geliştirmelerimizde local commerce altındaki diğer backend ekipleriyle bağlantılı oluyoruz.
Yapacağımız işlerde küçük Slack channelları kuruluyor ve orada aslında işin kapsamını, nasıl ilerleyeceğimizi vs.
konuşuyoruz. Bunun dışında bir de core related olduğumuz alanlar var.
Bunlar da mesela PDP, Checkout gibi diğer takım arkadaşlarımızın, mobilin altındaki diğer takım arkadaşlarımızın bulunduğu kısım.
Burada daha çok...
Temel konuları konuşuyoruz.
Mesela proje genelinde bir karar alınıyorsa ya da yeni bir refaktör yapılınacaksa, sallıyorum yakın zamanda yaptığımız bir guideline toplantısı vardı.
Bu tüm mobili etkileyen bir alanda yapılıyordu.
Bunun için hepimiz kendimize maddeler çıkarıyoruz.
Bunu küçük takımımızın sprintine getiriyoruz ve oralarda...
aslında bu şeyleri fixliyoruz.
Fixleyeceğimiz alanları ya da düzenleyeceğimiz alanları.
İletişimi bu şekilde sağlıyoruz.
Birden fazla böyle tazda ekipler olunca, ekipten ekipe de iletişim tazı ya da biznes bağımlılığına göre herhalde değişiyor gibi.
Aynen öyle. Ek olarak belki şunu da bahsedebilirim.
Mesela iOS ve Android tarafında haftada bir kez tech meetinglerimiz oluyor.
Bu bizim lokal commerce'dan bağımsız olarak yaptığımız tech meetingler oluyor.
Tüm Android developerlar veya tüm iOS developerlar kendi aralarında toplanıyorlar.
Proje genelinde nelere dokunabileceğimize ya da yeni bir mesela yani o hafta konuşacağımız konu tamamen spontane oluyor.
Sunum yapılabiliyor, yeni gelen konularla ilgili teknik borçlardan bahsedebiliyoruz sektörde.
Bir gelişme varsa onu mesela konuşuyoruz ya da projeye şurada şunu yapsak daha iyi olabilir dediğimiz konuları ele alıyoruz.
Ona göre de bir roadmap çiziyoruz aslında.
Süper. Peki burada kullandığınız teknolojiler ne?
Çünkü az önce biz mesela SFX'den bahsetmiştik.
Test kısmında olsun ya da Android ve iOS kısmı ayrı olduğu için büyük ihtimalle teknolojileri de çok ortak mıdır bilmiyorum ama genel olarak hangi teknolojilerden yararlanıyoruz?
Ben SFX'den biraz bahsedeyim.
SFX tarafında aslında biz Go diliyle kendi servislerimizi yazıyoruz.
Aynı zamanda da Argo CD ve Kibana gibi tool'ları kullanıyoruz.
Argo CD'yi kontinüsel veri kısmında, Kibana'yı da loglama kısmında, logları analiz etme kısmında performans sorunlarını tespit etmek için kullanıyoruz.
Android tarafıyla ben devam edebilirim.
Android tarafında Native App geliştiriyoruz.
Programlama dili olarak da Kotlin kullanıyoruz.
XML'i bıraktığımız bu günlerde UI tarafında Jetpack Compose ile devam ediyoruz.
Mimari olarak da MVVM projemizde yer alıyor.
iOS için de şöyle söyleyebilirim.
Yine Android gibi biz de native web geliştiriyoruz.
Programlama dili olarak Swift ile yapıyoruz tüm bu işlemleri.
User interface olarak da genel olarak böyle sektörde hep UI kit kullanılıyor.
Biz de çoğunlukla UI kit kullanıyoruz ama yakın zamanda yani son birkaç aydır herhalde 5-6 aydır Swift UI ile de sayfalar yazmaya başladık.
Aynı zamanda mimari desen olarak da Viper kullanıyoruz.
Ben de test tarafından bahsedeyim.
tarafı Nilay'ın bahsettiği gibi aslında.
Android'de de biz maestro tool'unu kullanıyoruz.
Bunu da Android Stüdyo'da yazıyoruz içinde yani bu.
SFX tarafında Java dilini tercih ediyoruz.
Bir de bizim load testlerimiz var.
Bunu çok fazla sık yapmıyoruz ama kullandığımızda da internal bir tool var.
Oradan faydalanıyoruz. Valla ne güzel.
Açık büfe gibi teknoloji şey oldu ya yani.
Aynen. Şimdi böyle çeşitli ekip olunca böyle olaydı belki.
Valla çok keyifli ya. İki tane Java'dan al, bir tane de Go ekle.
Yani valla çok çok güzelmiş.
Bu kadar böyle yelpazenin geniş olması aslında birçok keyze, birçok dil üzerinde, birçok teknoloji üzerinde birçok keyze dokunabilmek ve buraların avantajlarını kullanabilmek çok güzel.
Biz de bunu kendi ekiplerimizle de pratik etmeye çalışıyoruz yapabildiğimiz kadar.
Oldukça güzel, süper.
Şimdi birazcık daha aslında işlerin daha civcivli noktalarına gelmek istiyorum açıkçası çünkü evet teknoloji konuştuk ekip nasıl vesaire konuştuk ama birçok ekipte zaten böyle
birazcık daha ortalara geldiğimizde artık yavaş yavaş monitoring işte incident konularını konuşmaya başlıyoruz.
Bu tarz konular birçok ekibin sıkıntı yaşadığı konular oluyor genellikle.
Sıkıntı yaşadığından kastım aslında.
Problemler yaşanıyor ve bu problemlere sonrasında çeşitli çözümler getiriliyor.
Önlenebiliyor vs. Sizin burada monitoring mekanizmanız, alert mekanizmanız nasıl işliyor?
Bir incident olduğu zaman önceden nasıl?
haberdar oluyorsunuz.
Bir de böyle güzel bir incident örneğiniz varsa arkasına sıralayabilirsiniz.
Çok mutlu olurum. Çok severiz.
Şimdi şöyle ben biraz konuyu burada...
dahil olacağım. Şey gibi düşünebiliriz.
Biz iki farklı alanda çalışıyoruz.
Yani iOS Developer olarak.
Bir benim iOS Developer şapkam var.
Bir de işte BFF'ini yazdığımız bu SFX dediğimiz tarafta SFX şapkamı takıyorum.
Şöyle düşünün. Mesela biz iOS tarafı için nasıl diyeyim Firebase Crashlytics kullanıyoruz.
Crash'leri oradan sürekli takip ediyoruz.
Hatta burada bizim için Crash Free yüzdesi çok çok önemli bir noktaya geliyor.
Yani ne kadar az Crash varsa Crash Free yüzdemiz o kadar yüksek oluyor ve bunu da oralarda tutmaya özen gösteriyoruz.
Ya da mesela bir release özelinde herhangi bir crash yaşandıysa onu hemen işte hotfix ile çözülmesi gerekiyorsa hotfix ile çözüyoruz.
Eğer çok kritik bir şey değilse bir sonraki pakette kesin çözüme...
ulaştırıyoruz diyebilirim.
Onun dışında New Relay'e tanımladığımız alertler var.
Bunları şey gibi düşünebiliriz.
Belli bir threshold'un üstüne çıktığı zaman işte Slack kanallarına mesajlar geliyor.
Biz o end point'leri kontrol ediyoruz.
İşte mobil tarafta herhangi bir saldırıyorum UI'de bir bozukluğa sebep oluyor mu onları hemen kontrol ediyoruz.
Bu mobil tarafı için de.
Şimdi SFX tarafında da biz baktığımız için SFX'de de yine aynı şekilde alertleri takip ediyoruz.
Herhangi bir instant var mı?
onlarla da ilgileniyoruz. Bu tarafta da Kibana kullanıyoruz.
Herhangi bir instant durumunda direkt logların üzerinden ilerliyoruz ve hızlıca aksiyon almaya çalışıyoruz.
Şu an aklıma gelen güzel bir instant örneği yok.
Arkadaşlarda varsa bilin de vardır.
Benim var aslında.
Hatta ben yaptım.
O zaman şey yapıyorduk.
SFX'e geçiş süreci var.
Biz de bir iOS, bir Android, Mail tarafında geçiş yapıyoruz işte.
Base URL'leri değiştireceğiz.
Biz bir güzel böyle çat, çut, prod da yapıyoruz testleri.
Aynen sonra ama bir beğenmiyor.
Sonra geri alalım falan diyoruz böyle ama.
Gerçekten öyleyiz.
Daha sonra biz geri aldık bu arada.
Eski Base URL'e döndük.
Çünkü bir şey görmüştük.
Ya sonra bir sürü bir kanala eklendik.
Ben bir mutfağa gidip gelmiştim.
Bayağı... Birileri yazmışlar bize hani ne oldu, ne oldu diye.
Şöyle bir şey olmuş. PDP'de modifiyerli ürünler var.
Mesela hamburger. Orada hamburgerin işte soğanı, bilmem nesi, domatesi, bardalı falan.
İnsanlar bir sürü seçim yapmış.
İnsanlara sadece hamburger, ekmeği ve köfte gitmiş.
Yani bir sürü sipariş almış.
O şey mi? Ekstraların hiçbiri geçilmemiş mi sisteme?
Aynen. O ekstra malzemenin hiçbiri yok.
Yan ürünler yok. Ama sadece bu sonra şey olmuş.
iOS'de daha fazla olmuştu.
Ben biraz sevindim. Android tarafındayım dedim.
İyi yırttık. Sonra ne oldu?
Çözüldü. Yani yapacak bir şey yok.
Süreci birazcık daha yalınlaştırmışsınız.
Evet. Ne gerek var o kadar malzemeye hamburger için?
Yerelleştirmişsiniz. Hamburger değil köfte ekmek diye.
Yani yağlı şeylerden uzak tuttuk.
Sağlık. Aynen.
İnsan korkuyor bu arada.
Garip bir korkuydu ama çözüldü ya.
Sen böyle anlatınca benim aklıma başka bir incident örneği geldi.
Ben de yine bu SFX tarafında bir geliştirme yapmıştık.
Pro'da aldım bir şeyi. Pro'da işte development stage ortamında bir farklılık oluşmuş.
Ben de hiç fark etmedim. Direkt Pro'da alınca bir 21 dakika kadar direkt tüm kanalların ve Go app'in şeyi kesilmişti.
Yani 21 dakika sipariş alamamıştık.
için böyle çok unutamadım.
O 21 dakikayı asla unutamıyorum mesela.
Hayatımın en uzun 20 dakikası değil mi böyle?
Evet. Gerçekten stresli ve zordu.
Evet. Böyle kökten şeyler ama eğlenceli oluyor.
Anı oluyor. Yani bak anlatacak bir hikaye oluyor.
Ben olaylara böyle bakıyorum.
Bende de çünkü aynısı oluyordu.
İşte depo tarafındayız.
Komple depoyu durmuşum. Bak ne güzeldi.
Bak hatıra oluyor bunlar falan diye.
Aslında Siz biraz o süreçlere alışıksınız.
Biz şimdi mobil developer olduğumuz için release'lerimiz belli.
Hangi tarihlerde çıkacağımız belli paketler vesaire.
Anlık deployment yapamıyorduk.
Ama biz SFX tarafına geçince artık bu konulara da baya aşina olmaya başladık.
Yeni yeni aslında tam anlamıyla kavruyoruz, çözüyoruz diyebiliriz belki.
Güzel. Hayatımıza hoş geldiniz.
Peki burada...
Yapacağınız işlerin süreçleri nasıl işliyor?
Örneğin bizim depo tarafında OPEX diye ekiplerimiz var.
Operational Excellence diye geçiyor.
İşte verimliliğin arttırılması için şöyle bir şeye ihtiyacımız var.
Kullanıcı böyle yaparsa daha iyi oluyor deyip ihtiyaçlarını gördüğü, takip ettiği ekiplerimiz vs.
var. Onların aracılığıyla aslında bizler buradaki deponun yazılım karşılığını, ihtiyacını gideriyoruz.
Mobil tarafta örneğin...
Bir şeyler yapıyorsunuz ya da oradan data science ekip el aracılığıyla belki de dataları alıyorsunuz.
Kullanıcılar bunu yapıyor, bunu yapıyor gibisinden ama kullanıcının gerçekten neye ihtiyacı olduğunu, kararını veya nasıl öğreniyorsunuz, böyle bir yöntem var mı ya da yeni işler piyaya nasıl geliyor bilmiyorum ama bunun için bir süreciniz vs.
var mı? Bu soruya ben cevap verebilirim.
Aslında genelde işler...
Birçoğu A-B test olarak geliyorlar.
Yani aslında bir feature'ın önce bir ezizde, canlıda bir versiyonu oluyor.
Yeni yapacağımız işle de birlikte aslında kullanıcıların hangi geliştirmeyi daha çok tercih edeceklerini işte arka tarafta data science ekiplerine attığımız eventlerle test edip sonrasında çıkan sonuçlara göre belli
bir süre sonunda product'larla el sıkışıp A veya B versiyonunda karar kılıyoruz.
Eski feature'la devam ediyoruz.
Eski feature'da kalıyoruz veya yeni feature'la devam ediyoruz.
Testlerle alakalı peki yani şey benim de aklıma geldi şimdi bizim mesela webde A-B test uygulandığı zaman işte biz de benzer bir yöntemle uyguluyoruz.
Sonrasında belirli bir süre monitör ediliyor bu işte kullanıcı bunu beğenmiş mi beğenmemiş mi falan diye.
Sonra biz mesela bu A-B testleri çok kolay bir biçimde bize diyorlar ki ya bu A-B test iyi gidiyor biz bunu confine açalım.
Tüm kullanıcılar görsün bunu diyor ve bir konfig değiştirip direkt olarak A-Bitesi de açabiliyoruz.
Aslında bağlantılı bir soruya bağlayacağım buradan.
Deminden beri aklımda hani sormak için fırsat kolluyordum.
Şimdi mobil tarafta paket çıkma olayı bana çok garip geliyor.
Yani biz webde...
böyle direkt olarak release işte continuous deployment muhabbetine çok alıştığımız için bitirdiğimiz işi direkt olarak proda atabiliyoruz.
Burada mesela sizin bir şeyleri mesela işte bir A-B testin sonuçlandı ve bunu işte proda çıkalım dediğiniz noktada paketi mi beklemeniz gerekiyor?
Ve beklerseniz yani paket sıklığı değişebiliyor mu?
Yoksa belirli orada yapılan bir şey var mı?
Yani belirli bir schedule oluyor mu?
Ya genelde iOS schedule'ı için ben Şöyle söyleyebilirim, yıllık yani her sene başında release süreci tüm yıla dalmış bir şekilde bazı aylarda işte her hafta veya işte
bazı aylarda bayram zamanları, tatil zamanları iki haftada bir olacak şekilde release paketlerinin tarihleri belirleniyor.
Sonrasında düzenli olarak işte o haftanın başında regresyon başlıyor.
Regresyona dahil olacak işler, paketler hazırlanmaya başlıyor ve işte gerekli işleri mörşlüyoruz.
Aynı zamanda da şöyle bir şey oluyor.
Mesela A-B testing, yani A-B testing yapacağımız bir işi release paketine dahil ettikten sonra ancak konfigü açabiliyoruz.
Ama şöyle bir durum da oluyor, kademeli release'ler yapıyoruz.
Önce %1 ile başlayıp sonrasında 7 günlük bir sürede, Android için de aynı şey geçerli, kademeli bir şekilde paketi yayına alıyoruz.
Ve A-B testing'in sonuçlarını ancak %100'den sonra daha isabetli bir şekilde tespit edebiliyoruz.
Bu arada paket konusuna gelince şöyle.
Bu senin bahsettiğin şeyleri biz konfikli yapıyla tutuyoruz diyebilirim.
Mesela paketi çıktık, bir hafta geçti.
O feature'ı açacağımız zaman bir toggle gibi düşünebilirsin.
Direkt o konfiye enabled hale getirip aslında kullanıcıların direkt görmesini sağlıyoruz.
Bir paket ihtiyacı hissetmiyoruz.
Ama daha köklü bir değişiklik varsa, beklenmedik bir durumsa, herhangi bir crash'imiz ya da hotfix'lik bir...
problem ortaya çıktıysa bunlar için paketi bekliyor olmamız gerekiyor.
Çünkü kullanıcıya geliştirmelerimizi başka şekilde ulaştıramıyoruz.
Anladım, anladım.
Süper. Yani ben her geliştirmede, her değişiklikte paket gidiyor falan diye düşünmüştüm ama bunun schedule edilmesi de güzelmiş yani.
Biraz düşününce böyle çok aklım almamıştı açıkçası.
Önden herhalde bir schedule olmuyordur.
Paket hazır oldukça çıkılıyordur diye düşünmüştüm ama zaten arada sırada mail de geliyor bize işte bu paketi çıktık falan tarzında.
Oradan da anlaşılabilir bir schedule durumu olduğu.
Süper. Şimdi şey konusunu merak ediyorum biraz da.
Aslında... Genellikle biz projelerimizde bir şey yaptığımız zaman ya da işte yeni bir projeye başlayacağımız zaman falan bu proje yani buna benzer bir şey daha önce yapıldı mı falan diye bir bakıyoruz ve yapıldıysa
eğer ki vakitten kazanmak istiyorsak ve yapılmışsa bu projeyi bir şekilde alıp ilerletiyoruz.
Sizde yeni projeler geldiği zaman ya da işte böyle bir refaktör ihtiyacı da olduğu zaman nasıl ilerliyorsunuz?
Ben cevaplayayım bu soruyu.
Aslında yeni projeler ilk olarak product ekipleri tarafından bize grooming toplantılarında geliyor.
Bir sonrasında işte projenin tasarımı ve iş akışları üzerine fikir alışverişi yapıyoruz.
Mevcut yapılarımızı yani şu an canlıda çalışan bazı yapılara etkileyebilecek durumlar da varsa onlar için işte gerektiği refactoring işlerini konuşuyoruz.
Bir durum değerlendirmesi yapıyoruz.
Refactora gereken alanlar varsa da bunları işte tek tap maddeleri dediğimiz taslar olarak önümüzdeki sprintlere dahil ediyoruz.
Bu yeni gelecek feature'ları da daha sonraki sprintlere erteliyoruz.
Çünkü önden aslında işte gerekli alanları refaktör edip sonrasında o işlere başlamamız gerekiyor.
Eğer iyileştirme gerekmiyorsa da burada yani yeni işlerin büyüklüğüne göre parçalayıp sonrasında sprintlere dahil ediyoruz.
Güzel. Peki burada mobil ekipler arasında kendi aramıza bir alver yapıyoruz gibi bir muhabbet vardı ya bölümün başında.
Buradaki onboarding süreçleri nasıl ilerliyor?
Şundan dolayı soruyorum aslında birazdan.
Zaten Asok kültür birbirine çok benziyorsa bu onboarding süreci normale göre daha kolay diyebilir miyiz?
Şöyle, ekibe yeni katılmış birisi olarak ben sözü devralmak istedim.
Genel olarak ilk başlarda kurulumlarla başlıyoruz onboarding süresince.
Sonrasında bu kurulumlar bittikten sonra Trendyol Learning üzerinden eğitimleri tamamlıyoruz.
İnsan kaynaklarının atmış olduğu feedback eğitimleri.
Oluyor. Ara arada İstanbul'a çağırma gibi toplantılar oluyor.
Onlara katılıyoruz. Sonrasında yavaş yavaş mesela diyelim ki Barkın benim badim oldu.
Genel olarak projeyi tanıtıyor.
Projeyle ilgili sorularımı cevaplıyor.
Kesinlikle bütün ekip arkadaşlarıma tabii ki soru sorabiliyorum.
Ama ilk adresim Barkın oluyor başlarda.
O beni takıma alıştırıyor.
Toplantılara atıyor. Toplantılara ekliyor.
Ve bana yol gösteriyor aslında Trendol'daki ilk roadmap'imi Barkın çiziyor diyebiliriz.
Barkın'ın body'liğine 5 üzerinden kaç verirsin?
Benim body'm olsaydı 5 verirdim ama kendi body'lerini sormak lazım bence.
Ben de body'm olan Gizem Saruhan'a buradan çok sevgiler, selamlarımı gönderiyorum.
Hepimizin body'si olan Gizem Saruhan'a ben de buradan ayrıca teşekkür etmek isterim.
Saruhan Fan Club. Biraz şeyden bahsedebiliriz Gizem'e selam söyledikten sonra.
Projeyi nasıl alışıyoruz, testleri nasıl alıyoruz gibisinden.
Bir Scrum takımına dahil olduktan sonra genel olarak oradaki süreci anlıyoruz.
En azından bir hafta kadar biraz izlemeyle ve Payr olmakla geçiyor.
Payr bizim aslında kültürümüzün bir parçası.
Her zaman Payr oluyoruz arkadaşlarımızla.
Gereksin gerekmesin bir kod üzerinde farklı fikirler almak bize iyi geliyor.
Sonrasında küçük tasklar almaya başlıyoruz.
Projeyi ısınıyoruz. Beraber onları kod review ediyoruz.
Payr olarak. Böylelikle Trendyol standartlarına uyum sağlıyoruz.
Bu şekilde söyleyebilirim onboarding sürecini.
Çok iyi valla yani onboarding zaten Trendyol'un bence en güçlü kaslarından biri.
Gelen arkadaşlar gerek rotasyon olan gerek yeni gelen arkadaşların bu kadar kısa süre içerisinde ekiplere adapte olması ve güzel bir oryantasyon süreciyle karşılaşması bence çok
güzel bir şey. Bunu birçok ekipte de zaten çok iyi yapıldığını duyduk, direkt olarak da gördük.
Gerçekten harika. Şimdi birazcık testten konuşalım.
Yaptığınız siz bu geliştirmeleri, yaptığınız geliştirmeleri nasıl test ediyorsunuz?
Nasıl bir test süreciniz var orada?
İşte manuel test yapıyor musunuz?
Ya da otomasyonlarınız var mı bununla alakalı?
Nasıl oradaki süreçler? Bizim tarafta şöyle, başlangıçta development aşamasında her yaptığımız iş için unit testimiz olmak zorunda.
Yani unit test yazmadan hiçbir şekilde hiçbir işimizi development'a merge'leyemiyoruz.
Bu unit testlere ek olarak da UI testler de yazıyoruz.
Yani işte smoke, rekreasyon, snapshot gibi testlerimiz var.
Mesela biz MR açtığımız zaman önce unit test pipeline'ı koşuyor.
Sonrasında o sayfaya ait smoke testlerimiz koşuyor.
Bu pipeline'larda herhangi bir hata varsa, fail oluyorsa biz direkt o yaptığımız işi merge'leyemiyoruz.
Önce testlerimizi düzeltmemiz gerekiyor.
Ondan sonra MR'ı ilerletebiliyoruz.
İşte CodeReview'den test de verebiliyoruz.
Development aşamasındaki test skopumuz bu şekilde.
Buradan sonra da QA arkadaşlarımız aslında devreye giriyorlar.
O kısım için de Betül'e söz atabilirim.
O daha detaylı anlatacaktır.
Aynen teşekkür ederim Ünal.
Test tarafında olduğum için birazcık daha detaylı bahsetmek isterim.
Niren dediklerine ek olarak, evet böyle bir sürecimiz var.
Bir de aslında biz ilk başta şöyle yapıyoruz.
Biz case'lerimizi belirliyoruz.
Daha sonra otomasyonu yazacaklarımızı boardlara iş olarak alıyoruz.
Hani bu tek deplerde aslında bunu da konuşuyoruz.
Ve bu süreçte sadece biz, developer'in testler değil, developer'lar da buna dahil oluyor.
Aslında bütün ekip yazıyoruz.
Hatta PO'larla beraber bizim bir böyle bir çizelgemiz var.
Ayda bir toplanıyoruz mesela.
Hani nasıl gidiyor? Daha iyi yapabilir miyiz?
Bunu konuşuyoruz. Piyoların da desteğini almak gerçekten güzel burada.
Sadece hani biz nasıl odaklanmış bir ekip değiliz.
Bizim de test tiplerimiz şöyle.
Regresyon, feature, smoke, snapshot.
Bunun yanı sıra aslında manüeli tamamen bıraktığımızı söyleyemem.
Çünkü her şey otomasyonunu yazamayız.
Yani %100 otomasyon diye bir şey yok gerçekten.
Aslında bizim şöyle bir durumumuz var.
Bu iki yöntemi de dengeli bir şekilde kullanmaya çalışıyoruz.
Manuel eforu evet azaltmak istiyoruz ama mesela bir iş alındı Sprint'e.
Biz bu işi yürütürken manuel yürütüyoruz.
Çünkü Barkın'ın da bahsettiği gibi A-B işleri de var.
Hani hemen direkt yazamayız yani otomasyonunu.
Bir de ek olarak da bizim SFX testlerimiz var.
Onun da otomasyonunu yazıyoruz ama biraz daha azalabiliyoruz işlerini.
Son olarak da Slack'ten sürekli olarak scheduled bir şekilde koşan testlerimiz var ve bunların raporları düşüyor.
Buradan da takip ediyoruz. Okeyleri süper.
O zaman buradan da son soruya geçerek aslında bölümü yavaştan kapatabiliriz gibi.
Son sorumuz genelde çoğu ekibe sorduğumuz ve bazen farklı güzel cevaplar aldığımız bir kısım.
O da ekip iletişimini geliştirmek için neler yaptığınız.
Burada arabalardan, mangalardan, gurme ekipler, ödül veren, kendilerine soru cevaplı, ödül istemi olan ekipler gibi.
Farklı şeyler duyduk. Böyle söyleyeyim ki beklentiye atlayayım.
Çok normal bir ekipseniz bir anda düşsün diye.
Geçenki ekip mesela Nargile örneğini verdi.
Nargile'ye gidiyorlarmış.
Araba sevdalısı Recaizade Mahmut Ekrem ekiplerimiz var.
Sizlere bir karar çıkacak bakalım.
Bizim daha cool şeylerimiz var.
Herkesi lokal konverse bekleriz.
Ama şöyle mesela bizim haftalık toplantılarımız oluyor.
Böyle goy goy yaptığımız sesonlarımız oluyor.
O sesonlarda aslında bazen işte önden planladıysak Ortak bir şeyler yapıyoruz.
Planlamadıysak biraz daha akışına bırakıyoruz ama beraber bizim cookie pişirip yemişliğimiz bile var ekip olarak.
Yani herkes kendi mutfağında cookiesini pişirip işte tarifi Gizem Saruhan vermişti.
Ona da teşekkürlerimi ileteyim buradan.
Şahane bir cookie idi. Ya da mesela şey yaptığımız oluyor.
Kabut yapmıştık. Biz sonra havuzu oluşturuyoruz.
Sallıyorum bir arkadaşımız 5 yaşındayken tatil dönüşünde ben bam yiyeceğim diye Ağlayıp dizlerini yere vurmuş.
İşte bu arkadaşımız kimdir gibi soruların oldu.
Yaratıcı soruların oldu. Bir kahut yapmıştık.
O da ödüllü bir kahuttu.
Yani bu tarz böyle yaratıcı şeylerimiz oluyor.
Ekip olarak gerçekten çok eğleniyoruz.
Ben iletişimin çok üst seviyede olduğunu düşünüyorum açıkçası.
Hani bu ekipte olmaktan da mutluluk duyuyorum.
Benim şimdilik aklıma gelenler bunlar.
Kuki biraz şey oldu ya fazla üst seviye olduğu gibi.
Bunu beklemiyordum. Kuki şahaneydi.
Ama Nargile'den sonra bir seviye atladık mı?
Nargile'den sonra zaten evet Nargile'den sonra Koke'ye geldik.
Arkadaşlar kıskançlığınızı gizleyemediğinizi fark ediyorum ses tonunuzdan ama yani.
Nargile yok ya. Ne diyebilirim ki?
Şimdi bunu yaparken Nargile içiyormuş aslında şu anda.
Deli köz hemen. Süper.
Süper. Arkadaşlar çok teşekkür ederiz.
Valla çok keyifli bir bölüm oldu.
Dolu dolu Local Commerce Mobile ne yapar?
Nasıl ilerler?
Kendini nasıl ödüllendirir Cookie ile birlikte?
Bunları öğrenmiş olduk.
Çok teşekkür ediyoruz geldiğiniz için.
Biz teşekkür ederiz.
Biz teşekkür ederiz.
Sağ olun. O zaman herkese bir sonraki bölümde görüşmek üzere diyorum.
Kendinize iyi bakın. Bye bye.
Bye bye. Görüşürüz.
Görüşürüz.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.