Agile ve Jira'nın yavaş ve acılı ölümü
(ehandbook.com)"Agile artık Agile olmaktan çıktığına göre, şimdi Agile'ın Jira ile birlikte ortadan kaybolma zamanı gelmiş olabilir"
- Yazılım geliştirme döngüleri giderek uzuyor, teknik ekipler giderek büyüyor, geliştirme yönetimi için giderek daha fazla uygulama gerekiyor, fiilen kod yazan insanların sayısı giderek azalıyor ve daha kısa süreler içinde, sürekli kontrol noktaları arasında elde edilen ilerleme giderek düşüyor
- Agile'da işler nerede ters gitmeye başladı?
- Agile, belge odaklı ve ağır geleneksel yazılım geliştirme süreçlerine alternatif olarak 2000'lerin başında geliştirilen bir metodolojiydi
- Ancak bugün Agile, mevcut karmaşık proje yönetimi metodolojilerine dönüşmüş durumda
Teknolojik şişkinlik (Tech Bloat) temel sorun
- Birçok insanın Agile'ı bırakmasının ya da bırakmayı düşünmesinin başlıca nedeni teknolojik şişkinliktir
- Teknolojik şişkinlik tüm teknoloji şirketlerinin düşmanıdır; ayrıca kurum içinde veya dış kaynaklı geliştirme ekipleri olan teknoloji dışı şirketler için de risklidir
- Teknolojik şişkinlik teknik borçla aynı şey değildir, ama teknik borç üretir
- Teknolojik şişkinliğin belirtileri şunlardır:
- Müşterilerle tekrar tekrar konuşulur ama müşteri davranışı konusunda uzmanlaşılmaz
- Son tarih ve teslim tarihleri sürekli değerlendirilir ve yeniden değerlendirilir
- Tüm ayrıntılar belgelenene kadar geliştirme sürecini başlatma konusunda aşırı isteksizlik vardır
- En riskli iş yerine en kolay işten başlama yönünde bir teşvik oluşur
Teknolojik şişkinliğin kafa karıştırıcı sonuçları
- Dokümantasyon artışı
- Sürece, sadece neyin neden geliştirildiğini değil, aynı zamanda "nasıl" geliştirildiğini de izleyen bir dokümantasyon anlayışı sızar
- Bu "nasıl", durum güncellemelerinin odağı haline gelir ve ekiplerin nasıl çalıştığı sürekli yeniden değerlendirilir
- Ekipler işi yapmaya zaman harcamaktan çok, işin neden tamamlanmadığını tartışmaya daha fazla zaman harcar
- Sık son tarih belirleme
- Daha sık kontrol noktalarında daha fazla son tarih belirlenir; bu da özünde yaratıcı olan sürecin her dönüm noktasında mikro yönetime yol açar
- Bu, kaliteli yazılım üretimine ters düşer. Çünkü her şey, ne kadar iyi uygulanmış olursa olsun, belirlenmiş tarihte teslim edilir
- Yeniden değerlendirme sürecindeki bitmek bilmeyen şüphe
- Yeniden değerlendirme dönemlerindeki sürekli şüphe yüzünden en iyi uygulamalar ilan edilmez, israf ortadan kaldırılmaz ve ölçek ekonomileri fark edilmez
- Üretim sürecinin mikro yönetimi
- Tüm bir özelliğin yaklaşık %30'u tamamlandığında artık öncelik olmaktan çıkabilir
- Organizasyon, yol haritasının hâlâ başarılı bir ürün inşasını tanımlayıp tanımlamadığına bakmaksızın, yol haritasında olanı üretmeye çalışan bir ölüm sarmalına girer
- Nihai sonuç
- Ürün, çeşitli ve birbiriyle çatışan müşteri taleplerinin ağırlığı altında ezilir
- Özellikler çoğu zaman pazara geç çıkar ve pazara en uygun şekilde ve sırayla değil, teknik ekip için en uygun şekilde ve sırayla sunulur
- Sonunda satış/pazarlama ekipleri, ne sattıklarını ve müşterilerin ne satın aldığını bilmedikleri için tepki göstermeye başlar
- Bunun ardından organizasyon büyük çaplı bir temizlik sürecine girer
Dünyanın ihtiyacı daha fazla özellik değil, önemli işleri daha iyi yapan hafif yazılımlar
- Bu yeni bir fikir değil, ama bütün metodolojilerin sonunda uzaklaştığı bir fikir
- İnsanlar sonunda Toyota yönteminin Toyota için yeterince Toyotamsı olup olmadığını sormaya başlar ve bu da daha fazla iş üreten bir işe dönüşür
- Agile artık sevimli bir isim, daha kısa toplantılar ve daha fazla kuralla gelen bir PMP oldu
- Sorun Agile fikrinin kendisi değil, uygulama ve bunu denetleyecek liderlik eksikliği
- Sorun; faydadan çok son tarihlere, büyümeden çok kesintilere, ilerlemeden çok tasarrufa odaklanan orta kademe yönetimdir
GN⁺ görüşü
- Agile, başlangıçtaki niyetinin aksine bürokratikleşip biçimselleşerek yazılım geliştirmeyi yavaşlatan bir etken haline geliyor
- Teknolojik şişkinlik, yalnızca Agile'da değil tüm teknoloji organizasyonlarında dikkat edilmesi gereken bir risk unsurudur
- Dokümantasyon, son tarih belirleme ve mikro yönetim gibi unsurlar kaliteyi ve hızı tersine düşürebilir
- Agile'ın özü müşteri odaklılık, iş birliği ve esneklikte olduğundan, biçime takılıp kalmak yerine ilkeleri yeniden hatırlamak gerekir
- Yazılım geliştirmede önemli olan daha fazla özellik değil, temel işlevleri iyi hayata geçirmektir
- Organizasyon kültürü ve liderlik, Agile'ın başarısını ya da başarısızlığını belirlediği için teknik yöneticilerin buna dikkat etmesi gerekir
- Agile'ın ötesine geçip yeni metodolojiler aramanın zamanı gelmiş gibi görünüyor
17 yorum
Orijinal makale ücretli olduğu için sonuna kadar göremedim; ancak çevrilmiş ifadelerin biraz daha rafine edilmesi iyi olabilir.
"Agile artık Agile değil, dolayısıyla artık Jira ile birlikte ortadan kaybolmasının zamanı geldi"
=> "Agile, being agile olmayı bıraktı; dolayısıyla artık Jira ile birlikte ortadan kaybolmasının zamanı geldi"
Büyük harfli Agile ile küçük harfli agile arasında yapılan bir ayrım kavramı var.
being agile ile doing agile birbiriyle bağlantılı olsa da ayrı düşünülür.
being agile by doing agile.
Agile'ı neden benimsediğiniz önemli. Bunu geliştirme daha iyi gitsin diye mi benimsiyorsunuz? Hayır, sizin kaytarışınızı izleyemiyorum; ne kadar sıkı çalıştığınızı bir göreyim. İşte böyle bir zihniyetle benimsiyorlar. O yüzden de cehenneme dönüyor.
Bu noktada çevikliğe uyum için bir kontrol listesine ihtiyaç var gibi görünüyor.
Çevre; insanlar ve kültür gibi unsurlar olduğu gibi kaldığı sürece, mesele Agile mı yoksa waterfall mı olduğundan önce, ne kadar yenilikçi bir geliştirme metodolojisi dayatırsanız dayatın, ortaya çıkacak tek şey onun K-OOO versiyonuna dönüşmesi olur.
Gereksinim değişikliği (neredeyse) hiç yoksa, geliştirme tarafında waterfall’un gerçekten de rahat bir yöntem olduğu doğru. Tabii gereksinimler değişmediği sürece…
K usulü Agile yeniden değerlendirme bile görmüyor.!
Müşteri: Bu ekranda buton burada olsa iyi olurdu
Geliştirici: (Demek yine sabahlayacağım, bir de yeni işler var)
Müşteri: Başka bir ekranda da buton olması gerek
Geliştirici: (Biri bana klonlanma yeteneği versin) Evet, haha..
Müşteri: Hâlâ olmadı mı? Takvime göre çoktan bitmiş olması gerekmiyor muydu?
Geliştirici: (Kurtarın beni) Evet..;;
Agile’ın gerçekten Agile gibi, uzun vadeli olarak kullanıldığı örnekler pek yok gibi görünüyor.
Çoğu organizasyon da kısa teslim süreli waterfall işlerine yakınsıyor galiba.
Sorun Agile değil. Sorun, onu uygulayan insanlar. Hangi metodolojiyi getirirseniz getirin, sonunda belirleyici olan onu uygulayan kişinin nasıl yaptığıdır. Bence Agile bir metodolojiden çok, ürünü belirli döngülerle büyütmeye yönelik bir zihniyete daha yakın. Bunu kaçırıp körü körüne planlama ve retrospektif yapmak bana zaman kaybı gibi geliyor.
Bunun sadece K-Agile'a özgü olduğunu sanıyordum ama meğer küresel bir olguymuş.
Sanki sürekli yanlış şeye vuruyormuşuz gibi geliyor... bunun Agile Manifesto'ya uyup uymadığına göre değerlendirilmesi gerekirdi...
Agile Manifestosu'na katılan Uncle Bob da bu sorunu erken fark edip yanlış uygulanan Agile'ı düzeltmek için 2019'da Clean Agile kitabını yayımladı, ama bu sorunlar hâlâ sürüyor. Bana göre bunun nedeni, Agile'ın standart kılavuzlardan yoksun olması ve "kültür" gibi muğlak bir ifadeye dayanması. Keşke somut standart kılavuzlar ortaya konsa.
Yazar muhtemelen herhangi bir metodolojinin bürokratik hale gelir gelmez terk edilmesi gerektiğini savunuyordur.
Katılıyorum. Yanlış bir Agile uygulanıp sonra da Agile'ın hatalı olduğu söylenen şeylerin arttığını düşünüyorum.
Öte yandan aklıma gelen bir düşünce de şu: ortaya çıkışının üzerinden epey zaman geçmiş olmasına rağmen pratikleri sağlam şekilde oturtmanın hâlâ zor olması, belki de kaçınılmaz gibi görünüyor.
Dolanıp dolaşıp yine en başa mı dönüyoruz?
Hacker News görüşü
Agile'ın sorunları
Agile Manifestosu'nun ilkeleri
Agile'ın özü
Agile'ın esnekliği
JIRA hakkındaki görüşler
Agile'ın kökeni
Agile'ın bugünü
JIRA'nın sorunları
Agile'ın uygulanması