- Günümüzde programlama, 90’lar ve 2000’lerin başına kıyasla çok daha stresli
- O dönemde işler yalnızca son teslim tarihine yakınken çılgınlaşırdı; diğer zamanlarda ise görece sakindi
- Son birkaç on yılda stresin neden arttığını düşünmüş
- Bunun nedeni rekabet, pazar değişimleri ya da sıkı teslim tarihleri değil; sprint tarzı çalışma
1. Sprintler durmaz
- Sprintler, hiç bitmeyen ardışık son teslim tarihleri gibidir
- Waterfall yaklaşımı gerçek teslim tarihleri ve olaylarla uyumluydu
- Sprintler yapay teslim tarihleridir; doğal dinlenme araları yoktur
- Kısa süreli stres sağlık için iyi olabilir, ancak uzun süreli stres bedene zararlıdır
2. Sprintler gönüllü değildir
- Bu, bir ekibin kendi isteğiyle her iki haftada bir kod dağıtımına çıkmasıyla aynı şey değildir
- Sprintlerin her yönü kurallarla belirlenmiştir
- Özerklik, iş deneyiminde önemli bir rol oynar
- Zorunlu çalışma stres ve rahatsızlık yaratır
3. Sprintler önemli destek faaliyetlerini görmezden gelir
- Sprintler bir sonraki işi hazırlamak için zaman tanımaz
- İşi yapabilmek için hazırlık süresine ihtiyaç vardır
- Sprintler hazırlık ile uygulamayı ayırmaya çalışır, ancak bu stres yaratır
Scrumban değil, Scrumpol: gerçek (ve daha kötü) tablo
- Çoğu Scrum uygulaması Waterfall ile Scrum’un karışımıdır
- Büyük teslim tarihleri her zaman arka planda vardır
- Büyük teslim tarihi yaklaştığında Scrum kesintiye uğrar ve stres artar
Sonuç
- Sprintlerde mola yoktur, özerklik azdır ve hazırlık süresi yetersizdir
- Geliştiriciler kendi işlerini ve süreçlerini kontrol edebilmelidir
- Bunun için etik bir organizasyon kurmak ya da freelance çalışmaya geçmek gibi çabalar gerekebilir
GN⁺ özeti
- Bu yazı, Scrum yaklaşımının geliştiricilere neden sürekli stres yüklediğini açıklıyor
- Sprintlerin ardışık teslim tarihleri, özerklik eksikliği ve hazırlık süresinin azlığı başlıca nedenlerdir
- Geliştiricilerin kendi çalışma biçimlerini kontrol edebilmesi sağlanmalıdır
- Benzer işlevlere sahip başka bir proje yönetim yaklaşımı olarak Kanban da vardır
8 yorum
SI, kamu vb. projeleri yürütürken bile phase 1, 2, 3... diye durmaksızın yükleniliyor. Ayrıca her bir phase içinde yine tonla değişiklik oluyor. Böyle olunca başarılı geliştirme hedefleyen scrum’ın özündeki amaç da asla gerçekleştirilemiyor. Sonuçta bu kaotik, darmadağın atmosferin içinde geliştiricilerin yalnızca canı çıkıyor.
Ben aktif olarak çalışan bir PM'im.
İyi işlediğini hissettiğim agile/scrum uygulamalarında, ana sprint bittiğinde retrospektif yapar ve dinlenmek için zaman verilirdi. Geliştirme ekibinin de ürün planlama ekibinin de bir sonrakine hazırlanmadan önce nefes alabileceği bir zaman vardı.
Metindekiyle aynı şekilde iyi işlemediğini hissettiğim yöntemde ise, waterfall’dan gelen deadline’ların altında ürün ekibi içinde scrum da aynı anda işletiliyordu ve bu da stresi artırıyordu. Üstelik deadline’ın kendisi değiştirilemez olduğu için, dinlenmeye ya da retrospektif yapmaya zaman kalmadan her hafta koşturuyor, sanki hiç bitmeyen bir koşunun içindeymiş gibi hissediyorduk.
Benim anladığım kadarıyla waterfall yaklaşımının amacı, gereksinimleri mümkün olduğunca erken belirlemek ve tasarım-uygulama-test işleri arasında bağımlılık olduğu için işi sırayla yürütmek. Agile ve sprintlerin amacı ise, waterfall ile önceden tasarlamak ya da uygulamak için kapsamı fazla büyük olan işleri küçük parçalara bölerek denemek. Bence ikisinin de artıları ve eksileri var; metodolojiyi dogmatik biçimde takip etmektense duruma göre sadece gerekli olanları seçip uygulamak yeterli olabilir. Yazıda savunulduğu gibi dinlenme de olmalı, teknik inceleme ya da prototip hazırlamak için zaman da olmalı.
İş sırasını kimin belirlediğinden bağımsız olarak, engelleri anlayıp öncelikleri işin sahadaki akışına göre belirledikleri sürece geliştirici özerkliğinin olup olmaması da o kadar önemli mi emin değilim.
Acaba hiç geliştirme deneyimi olmayan ve geliştirme metodolojilerinin süreçlerini körü körüne uygulamaya çalışan yöneticiler yurt dışında çok üretildiği için mi yabancı bloglarda böyle yazılar çıkıyor? Sanki bizde sahadaki işi hiç bilmeyen planlamacılarla geliştiriciler arasındaki çatışmayı görüyormuşum gibi geliyor.
İş akışının önceliklerini en iyi belirleyebilecek kişi muhtemelen bizzat geliştiricinin kendisidir; fakat onun özerkliğini elinden alıp bunu başka birinin onun yerine yapması yaklaşımının, tam tersine, pratik iş ile ekip planlamasının birbirinden kopmasına yol açtığını düşünüyorum.
Eğer yöneticiliğin kendisi de başlı başına bir uzmanlık alanıysa, geliştirme deneyimi olmayan bir yönetici bile geliştirme kaynaklarının iyi yönetilemediği bir anla karşılaştığında, o durumun çözümüne yöneticinin uyum sağlaması ya da karşılık vermesi gerektiğini düşünüyorum. Ama bu sorumluluğun bireysel katkı sağlayanlara yıkıldığını gerçekten çok fazla gördüm...
Nihai sorumluluğu yöneticinin üstlenmesi gerekir. Ama görünen o ki gerçek hayatta işler böyle yürümüyor. Tıpkı yalnızca yönetmeyi bilen, ama şirketin ne iş yaptığını hiç anlamayan ve bu yüzden zaman zaman şirketi batıran bir CEO gibi.
Sadece pinpon oynayan PM’ler çok fazla ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama ağlama
Hacker News görüşü
Rich Hickey'den alıntıyla, programcıların kısa mesafe koşucularından farklı olarak sorunları her 100 yardda bir başlangıç silahı patlatılıp yeni bir sprint başlatılarak çözmediği söyleniyor
Yazılım süreçlerinden nefret eder hale gelinmiş. Takım boyutunu uygun ayarlayıp geliştiricilere hedefe ulaşmaları için yetki verirseniz, yönetimin üretkenlik akışları olmadan da işleri gayet iyi yapabilirler. Agile ve benzerleri, yöneticilerin maaşlarını haklı çıkarması için var
"Sprintlerin gönüllü olmaması" ile ne kastedildiği merak ediliyor. Takım sprintin özelliklerini kendisi seçiyor, bunlar rastgele atanmıyor. Bu; liderlik, takım üyeleri ve takım dışı paydaşlar arasında bir iş birliği. Scrum'ın neden fazla katı olduğunu açıklamanız isteniyor
Scrum ilk ortaya çıktığından beri, geliştiricilerin sürekli sprint yapmasının mantıksız olduğu düşünülüyordu. Sprint kısa ve hızlı olur, ardından dinlenme gerekir. Her işi sprint haline getirmek delilik
Scrum pratikte çoğu zaman daha kötü bir "Scrumbut"a dönüşüyor. Başlangıçta uzaktaki ekiplerin iletişimi için Scrum kullanılmış, ama zamanla pazarlama odaklı hedeflere ve stresli sprintlere evrilmiş. Geliştirici tükenmişliği açıkça görülüyor
2000'lerin başında mühendis ekipleri proje yöneticileri olmadan kendi kendine çalışıyordu. Yazılım bugünkü kadar birbirine bağlı değildi ve dağıtım döngüleri daha uzundu. Şimdi CI/CD ve sürekli dağıtım yüzünden her şey çok hızlı ilerliyor. SCRUM stres yaratıyor
Konuşmaların çoğu şu iki cümleye indirgenebilir: "Benim işyerimde Scrum, X, Y, Z yüzünden kötü" ve "O gerçek Scrum değil"
40 yıldır yazılım geliştirildiği, hangi yöntem kullanılırsa kullanılsın işi parçalara bölmek ve hedeflere ulaşıldığını göstermek gerektiği söyleniyor. Küçük ekiplerde basit kod tabanları için Kanban yeterli olabilir, ancak büyük ekiplerde veya karmaşık çözümlerde raporlama gerekir
Agile, Scrum, standup vb. kullanılmıyor. Haftada bir yapılan toplantıyla öncelikler yeniden belirleniyor, bilet sistemiyle ilerleme takip ediliyor. Geliştiricilerin özerk çalışmasına izin veriliyor. Toplantılar veya TPS raporları yerine kod yazmaya daha fazla zaman ayrılmalı
8 şirkette çalışmış biri olarak, Basecamp'in Shape Up yaklaşımının en başarılı yöntem olduğu söyleniyor. Önemli olan "kaç gün" değil, "ne kadar zaman ayıracağın" sorusu. Shape Up, 6 haftalık döngüler arasında soğuma süresi sunuyor ve istikrarlı biçimde başarılı ürünler ortaya çıkarıyor