Yapay zekadan makale özeti
- Kısa
- Ayrıntılı
- Bu video, yazılım geliştirme alanında çalışan Mert, Fırat, Deniz, Uğur ve diğer profesyonellerin katıldığı bir podcast formatında bir sohbeti içermektedir. Katılımcılar arasında bir Scrum Master, CEO ve teknoloji yöneticileri bulunmaktadır.
- Sohbetin ana konusu, Agile ve Scrum geliştirme yöntemlerinin uygulamaları, bu yöntemlerin yazılım geliştirme süreçlerindeki etkileri ve yaşanan sorunlar üzerine bir tartışma niteliğindedir. Katılımcılar, grooming session'lar, user story'ler, sprint toplantıları, retro toplantıları, pair programming ve takım içindeki iletişim gibi konuları ele alırken, bu yöntemlerin uygulamalarında karşılaşılan zorlukları ve çözüm önerilerini paylaşmaktadır.
- Video boyunca katılımcılar, farklı organizasyonlarda ve kültürel bağlamlarda Scrum uygulamalarının nasıl değiştiğini, takım boyutunun ve planlama stratejilerinin projeler üzerindeki etkisini, ürün sahipleri ve geliştiriciler arasındaki ilişkiyi ve işbirliğini, sürekli entegrasyon ve sürekli teslimat (CI/CD) süreçlerinin Scrum ile nasıl entegre edildiğini tartışmaktadır. Ayrıca, retro toplantılarında kullanılan dört farklı yöntem (balon yöntemi, üç ev üç domuzcuk, yarış arabası ve M/MS aktivitesi) detaylı olarak anlatılmaktadır.
- Dinlenme İstatistikleri ve YouTube Kanalı
- Programın dinlenme istatistikleri paylaşılıyor: İstanbul'dan 615, Ankara'dan 100, İzmir'den 34, Balıkesir'den 32, Kocaeli'den 30 kez dinlenmiş.
- Costfiction adında bir YouTube kanalı açılmış ve ilk iki bölüm oraya atılmış.
- 01:07İşyerindeki Grooming Sorunu
- İşyerinde "release train" adı verilen bir yöntem kullanılıyor, her bir release 6 hafta sürüyor ve bu süre boyunca neredeyse her gün grooming yapılıyor.
- Grooming session'lar çok uzun sürüyor ve 3-4 user story'e sadece bakabiliyorlar.
- Grooming'ın amacı user story'leri "ready for development" hale getirmek ve en az 3 developer olursa session'ı başlatıyor.
- 02:49User Story ve Tasarım Süreci
- Bazı kişiler user story'lerin tasklarını yaratırken en ince ayrıntısına kadar tasarım yapmak istiyorlar.
- Scrum içindeki storylerde genellikle tasarım gelmiyor, tasarım ayrı bir pipeline'dan front-end takımına geliyor.
- Bazı ekiplerde tasarımcı değil yazılımcılar design kararları veriyor.
- 05:02Farklı Ekip Deneyimleri
- Bazı ekipler Kanban'a benzer bir yöntem kullanıyor, iki haftalık sprintler ve her haftada review yapılıyor.
- User story'ler genellikle çok detaylandırılmıyor, sadece spesifik durumlarda detaylı bilgiler veriliyor.
- Bazı ekiplerde planlama yapmıyor, işin ne kadar süreceğini tahmin etmiyorlar.
- 07:33Ekibin Boyutu ve Agile Yöntemleri
- Yazılım ekibinin boyutu, ekibin nasıl ilerleyeceğini etkiliyor.
- Büyük ekiblerde (50 kişilik) farklı takımlar birbirlerine bağlılıklar yaratıyor veya aynı codebase ile çalışıyor.
- Agile ve Scrum gibi yöntemlerin her firmada ve projede aynı şekilde çalışmayacağını, firmaya ve işe göre sürekli ayarlanması gerektiğini vurguluyorlar.
- 08:22Agile ve Scrum Uygulamalarının Sorunları
- Konuşmacı, agile ve scrum uygulamalarının eğitim endüstrisine dönüşmesini ve bazı danışmanların şirketleri bu yöntemlere zorlamasını rahatsız edici buluyor.
- Danışmanların yönetimle konuşurken taviz vermesi ve esneklik bırakmaması, scrum uygulamasının başarısız olmasını sağlıyor.
- Yazılımcılara biraz esneklik vermek gerekiyor, sürekli görev yapmak yerine biraz özgür kalmalarına izin verilmeli.
- 10:15Scrum Master Rolü ve Sorumlulukları
- Scrum master'ın görevi takımın scrum'ı düzgün uyguladığından emin olmak olsa da, pratikte bu rolün başarılı olması için yeterli zaman ve kaynak gerekiyor.
- Scrum master'ın işlerini yapabilmek için en az %20-30 zamanını bu görevlere ayırması gerekiyor.
- Agile koç gibi bir rol de gerekiyor, bu kişi agile'ın sürekli uygulandığını denetleyecek ve takip edecek.
- 11:35Scrum'ın Sorunları ve Şeffaflık
- Scrum'ın en çok şikayet edilen yönü "wilan transparency" (şeffaflık) olarak adlandırılıyor.
- Yazılımcılar sekiz saatlik çalışma süresinin sadece dört saatini verimli şekilde geçiriyor, geri kalan zamanı kendilerini geliştirmeye ve yeni şeyler öğrenmeye ayırmak istiyorlar.
- Scrum'ın sürekli sprint ve kısa vadeli görevler yapma prensipleri, yazılımcıların yaratıcılığını ve iddialarını engelliyor.
- 13:38Çalışma Ortamı ve Open Office
- Bazı şirketler cuma günlerini "Freedom Friday" olarak adlandırıp, çalışanlara kendi geliştirmeleri için zaman ayırıyor.
- Open office ortamı sürekli gürültü ve yöneticilerin sürekli izlemesi nedeniyle can sıkıcı olabiliyor.
- Yöneticinin yaklaşımı, open office ortamının olumlu veya olumsuz olmasını belirliyor.
- 17:52Farklı Çalışma Sistemleri
- Konuşmacılar, kanban board'u kullanıyor ancak keskin hatları olan bir sistem olmadığını belirtiyorlar.
- Bazı zamanlar vadettiği işleri iki haftada bitiremese bile, bu durumda ortalık yangın yönüne dönmemesi ve yöneticinin baskısı olmaması önemli.
- Developerlara olan güven ve serbestlik, şirket içinde iyi ürünler çıkmasına katkı sağlıyor.
- 18:46Geliştiricilerin katkıları ve yönetimin etkisi
- Yönetici ve organizasyon geliştiricilere çok etki ediyor.
- Geliştiriciler planlanan dışında bir özellik eklerken, yöneticinin "şunu da eklesen daha iyi olur" demesi sinirlilik yaratabilir.
- Geliştiriciler zamanlarını ve yaratıcılıklarını koyarken, üstlerinin bu katkıları suistimal ediyor gibi hissedebilirler.
- 21:22Ürün sahibi (Product Owner) rolü ve takım işbirliği
- Product Owner ürünün ne olacağını tek başına karar vermez, takım içindeki herkes ürünün sahibidir.
- Herkesin yetkinlikleri farklı olsa da, ürünün ne olacağına karar veren kişi Product Owner'dur.
- Geliştiriciler genellikle business'ı en az Product Owner kadar iyi anlayabilir ve işin içindeler.
- 24:12Takım içindeki denge ve katkı
- Geliştiriciler günlük problemleri görür ve bunları düzeltme fırsatı bulurlarsa, inovasyonu öldürmek yerine katkı sağlarlar.
- Geliştiriciler hem hobileri hem mesleği olduğu için bazen müşteri odaklı bakamayabilirler.
- İyi teknoloji ve iyi ürün arasında dengesini bulmak, business beklentileriyle teknik performansı uyumlu hale getirmek önemlidir.
- 27:23Product Owner'ın değer katma ve takım içindeki rolü
- İyi bir Product Owner, onboarding gibi alanlarda harika fikirlerle ve analitik verilerle ürünün değerini artırabilir.
- Product Owner takımın bir parçası ve farklı yetkinliklere sahip bir kaynaktır.
- Takım içinde herkesin birinci amacı sprint'i başarılı bir şekilde bitirmek ve iyi planlama yapmaktır.
- 29:24Scrum ve Sprint Uygulamaları
- Sprinte sığmayan inovasyon ve araştırma gibi görevler için farklı yaklaşımlar tercih ediliyor.
- Balıklar gibi görevler sprint yerine epik olarak değerlendiriliyor ve haftalık veya iki haftalık esnek planlama yapılıyor.
- Araştırma görevleri için "spike" adı verilen özel bir görev tipi kullanılıyor ve bu görevler puanlanmıyor.
- 30:35Sprint ve Epik Stratejileri
- Altı haftalık süreçte üç sprint yapılabiliyor ve sprintler psikolojik bir bariyer olarak görülüyor.
- Gelecek periyotta deneme yapmak isteyen ekipler için "spike" adı verilen özel görevler oluşturuluyor.
- Spike'lar boyut olarak small, medium, large gibi kategorilere ayrılıyor, örneğin medium bir spike iki gün bir yazılımcının çalışması gerektiği anlamına geliyor.
- 31:52Continous Integration ve Scrum
- Continous integration sürekli diploya hazır koddan bahsedirken, Scrum sprint sonunda belirli bir değere ulaşmayı amaçlar.
- Bazı ekipler hem continous delivery hem de sprintleri yürütüyor, her gün defalarca kod production'a deploy ediliyor.
- Kritik feature'lar geldiğinde Scrum Master'ı dinlenmeden en üstte çıkıyor ve hemen uygulanıyor.
- 34:19Sprint ve Continous Delivery Uygulamaları
- Sprint sonunda feedback verilebilecek ve yapılabilecek bir şey çıkması gerekiyor.
- Epik veya sprintteki ürünle ilgili geliştirmeler diploy olmuyor, ancak aynı anda bug fix veya minik feature'lar continous delivery ile deploy ediliyor.
- Mikro servislerde sürekli deploy yapılıyorken, diğer epik veya sprint'lar arkada sessizce devam edebiliyor.
- 36:21Scrum Uygulamalarının Esnekliği
- Herkes aslında Scrum'ı bir şekilde uyguluyor, tamamen şablona uymak hayatın gerçekleriyle uyumlu değil.
- Scrum'ı tamamen birebir uygulamak zor çünkü her organizasyonun kendi dinamikleri var.
- Müşteri kim, ne sıklıkla bir şey bekliyor, deadline'lar var mı gibi faktörler Scrum uygulamasını etkiliyor.
- 38:14Kültürel Farklılıklar ve Scrum
- Kültürel dinamikler Scrum uygulamasını etkiliyor, farklı kültürlerde otoriteye saygı seviyesi değişiyor.
- İsveç'te otoriteye saygı seviyesi düşükken, Hindistan ve Türkiye'de yüksek.
- Ekibin yönetim şekli, kültürel dinamiklere göre şekillendirilmeli.
- 39:35Scrum ve Gelişim Rolü Tartışması
- Konuşmacı, Scrum'un sinir ve junior developer arasındaki farkı ortadan kaldırarak herkesi tek bir şeye soktuğunu düşünüyor.
- 30'lara gelince kendini belli bir seviyede hisseden birinin farklı rollerde, özellikle mimarisel rollerde görev almak istediğini belirtiyor.
- Scrum'un sinir ve junior arasındaki farkı ortadan kaldırdığı konusunda genel bir görüş belirlenmeye çalışılıyor.
- 40:31Pair Programming Deneyimleri
- Ekipte kesinlikle bir junior olacağını ve bu kişinin daha az tecrübeye sahip olduğunu vurguluyor.
- Yeni bir ürüne başladıklarında sürekli pair yapıp daha az tecrübeli kişilerle çalıştıklarını, bu durumun uzun vadede seviyelerini yükselttiğini belirtiyor.
- Pair programming'ın yorucu olduğunu ancak çok faydalı olduğunu ifade ediyor.
- 41:40Pair Programming Uygulaması
- Herkesin her işte çalıştıklarını ve bir işin üçüncü gününde yanındaki kişi değişebileceğini açıklıyor.
- Story'leri mümkün olduğunca üç gün içerisinde pair halinde bitirebilecekleri kadar bölmeye çalıştıklarını belirtiyor.
- Pair programming'ın zorlukları hakkında konuşuluyor, bazı kişilerin sürekli klavyeyi eline almaya çalışması gibi sorunlar yaşanabildiğini ifade ediyor.
- 43:16Sinir ve Junior Arasındaki Fark
- Basit story'lerde ve task'lar da sinir ile junior arasında fark yaratmadığını, sonuçların hemen hemen aynı olduğunu belirtiyor.
- Daha kompleks bir problemi çözdüğünde sinir bir yazılımcının juniordan farklı bir çözüm sunabileceği vurgulanıyor.
- Pair programming veya code review yaparak junior seviyesini daha hızlı yükseltme imkanı sağlandığı belirtiliyor.
- 44:01Velocity Chart Kullanımı
- Velocity chart'ı oluşturduklarını ve Pivot Tracker kullanarak bunu yaptıklarını belirtiyor.
- Yöneticilerin bazen bakabildiklerini ancak velocity düşük olduğunda gaz verme gibi bir durumun olmadığını ifade ediyor.
- Daha çok epic üstünden veya hedeflenen ürüne yaklaşma noktasında konuşulduğunu belirtiyor.
- 44:49Yönetim ve Ekip İletişimi
- Konuşmacı, başta CEO ve aynı zamanda ilk versiyon kodunu geliştiren kişi olan bir yöneticinin, teknik ve ürün sorunları konusunda ekip üyeleriyle etkili iletişim kurabildiğini belirtiyor.
- Fırat, yöneticisinin teknik liderlik yaparken aynı zamanda yazılım alanında da çalıştığını ve ekip üyelerine "biz böyle yapıyoruz" demeden, işin içinde olduğunu göstererek iletişim kurduğunu anlatıyor.
- İşletmelerde çalışma saatlerinin düzenlenmesi gibi değişikliklerin, çalışanların stresini azaltmak için yapılabileceği örneklendiriliyor.
- 47:10Stand-Up Toplantıları ve Etkisi
- Stand-up toplantıları (scrum meeting) ekip içinde iletişim sağlama amaçlı kullanılıyor, ancak bazı yerlerde bu toplantılar istenmeyen bir alışkanlık haline gelebiliyor.
- Stand-up toplantılarının sadece iletişim değil, ekip üyeleri arasında sorunları paylaşma ve çözüm arama alanları olarak da kullanılması gerektiği vurgulanıyor.
- Bazı ekipler haftanın beş günü yerine sadece iki gün stand-up toplantıları düzenlemeyi tercih ediyor ve bu durumda herkesin mutlu olduğu belirtiliyor.
- 52:51Retrospektif Toplantıları
- Retrospektif toplantıları, ekip üyeleri tarafından "madset glad" (sıkıntılar, mutluluklar) şeklinde değerlendirilerek, ekip içindeki sorunları ve olumlu noktaları konuşmak için kullanılan bir araç.
- Bu toplantılar sırasında çalışanlar şirketle ilgili çeşitli konularda (meyve getirilmesi, elektronik sigara içmemesi gibi) geri bildirimde bulunabiliyor.
- Retrospektif toplantılarında ekip üyeleri kategorilere göre geri bildirimler veriyor, en çok oy alanlar belirleniyor ve bu sorunların bir hafta içinde çözülmesi hedefleniyor.
- 54:26Retrospective Oturumları Hakkında Tartışma
- Sprint veya ep sonunda bitirilen ürün kısaca konuşulur ve konu tartışılır.
- Scrum dışından gelen taskları nasıl engelleyebilecekleri konusunda yarım saatlik sohbetler yapılır.
- Bu sohbetler katı bir şekilde uygulanmaz ve çoğu zaman uygulanmaz.
- 55:23Deniz'in Retrospective Yöntemleri
- Son dört sprintte farklı retrospektif yöntemleri kullanmışlar: balon yöntemi, üç ev üç domuzcuk yöntemi ve yarış arabası yöntemi.
- Balon yönteminde ağırlıklar (negatif noktalar) ve sıcak hava (pozitif noktalar) tartışılır, ayrıca fırtınaya doğru çeken rüzgarlar ve geriye iten rüzgarlar konuşulur.
- Üç ev üç domuzcuk yönteminde ekip içindeki iletişim gibi konular saman, ahşap veya tuğla evlere yerleştirilir.
- Yarış arabası yönteminde arabayı hızlandıran ve yavaşlatan faktörler, köprüyü sağlamlaştıran ve riskleri konuşulur.
- 57:24Retrospective Oturumlarındaki Etkinlikler
- Retrospective oturumlarının sonunda M (iyi şeyler) ve MS (daha iyi olabilecek şeyler) konuşulur.
- Retrospective'in başında herkesin konuşmasını sağlamak için renkli kutudan rastgele seçilen sorular cevaplanır.
- Bu sorular ekip içinde iletişimi artırır ve ekipteki arkadaşların tanıma konusunda yardımcı olur.
- 58:18Retrospective Oturumlarının Önemi
- Retrospective'in başında konuşan kişilerin sonrasında da konuşacağı garantisi vardır.
- İnsanların retronun başında konuşmaması, sonrasında da katılmaması olasılığını artırır.
- Ice breaker olarak kullanılan bu etkinlik, şeker ve çikolata ile mutluluk hormonu salgılatır ve kan şekerini arttırır.
- 1:01:00Kapanış Konuşması
- Haftalık toplantıda agile ve çevik yazılım geliştirme yöntemleri konuşulmuştur.
- Konuşmacılar arasında hiçbir product owner olmadığı için, product owner'lar farkında olmadan eleştirilmiş olabilirler.