Değerlendirme & Başlangıç Noktası
Çevik yöntemin bir puristine bir keresinde şöyle demiştim: "Piramitlerin hiçbir zaman tamamlanamamasına şaşmamalı: o zamanlar çevik geliştirmeye hâkim değillerdi, bir Scrum Master'ları yoktu…"
Bu elbette kışkırtıcı bir söz. Ama bazen bir bakış açısını sorgulamak ve karşıdaki kişiyi "her yeni moda olanı" sadece tekrarlamak yerine kendi düşüncelerini geliştirmeye yöneltmek için kışkırtmak gerekir.
Kavramlar: Artefaktlar mı, Dokümanlar mı?
Çevik: "Artık" dokümanlar ve sonuçlar artefakt olarak adlandırılıyor. Gerekçe (yöntemi inceleyin*) makul görünüyor. Ancak benim görüşüme göre burada bir değişiklik tamamen gereksiz: toplantı tutanaklarını öyle adlandıralım, aynı şekilde spesifikasyonları, SSS'leri, proje ilerleme raporlarını, sunumları, karar dokümanlarını vb.
*Çevik: Artefakt geniş bir uygulanabilirliğe sahiptir. Bir artefakt, kullanıcı hikayeleri, ürün backlog'ları, sprint backlog'ları, burndown grafikleri veya yazılımın artışları gibi birçok farklı biçim alabilir. Kavram, tüm bu farklı sonuçları kapsayacak kadar geniştir.
Başarı Faktörü Olarak Çeviklik
Tamam, bir projede daha fazla çeviklikle başarıya daha iyi ulaşacağımız bir gerçek. Bu şunları gerektirir: yeni bilgilere uyum sağlamak, yanlış olduğu ortaya çıkan bir spesifikasyonu gözden geçirmek, yeniden önceliklendirmek ve ekibi verimli şekilde yönetmek.
Ama şimdiye kadar beni başarıya ulaştırmış olan her şeyi "alaşağı" etmem mi gerekiyor?
Ritüeller, Roller & Gerçeklik
Yöntemden alıntı yaptığımda veya ChatGPT'ye sprint için bir plan ve Scrum Master'ın sorumluluğunu sorduğumda, şu öne sürülüyor: her sabah yaklaşık 15 dakika önceliklendirmeyi güncellemek, engelleri sormak, motivasyonu korumak vb.
Scrum Master'ımız için gereken becerileri sorduğunuzda, yalnızca soft skill'ler listeleniyor. Şimdi şunu hayal edin: Sprint toplantısında 50 yaşında bir kişi olarak otururken önde genç bir kişi Scrum ritüellerini "dans ediyor". Bu kişi bana gerçekten bir şey söyleyemiyorsa, giderek motivasyonum kırılır.
Olgun Organizasyonlar İçin Pragmatik Yaklaşım
Kanaatim şu: Şirket, emekliliğe kadar orada çalışmaya devam edecek deneyimli yazılım geliştiriciler istihdam ediyorsa (Telekom, SAP, bankalar, sigorta şirketleri vb.), o zaman klasik yöntemlerimi çevik şekilde "tazelemek" ve aşamalı bütçe planlamama uyarlamak için yapıcı yollar bulmam gerekir.
Aksi takdirde büyük çaba harcanır ama ulaşılması gereken şeye ulaşılmaz: Yönetimimi (!) ve ekiplerimi daha esnek hale getirmek.
Zaman Baskısı, Planlama & Yönetim
Geliştirme döngüleri giderek kısalıyor, sonuçların giderek daha hızlı sunulması gerekiyor. Bu nedenle çevik metodolojinin unsurları yapıcı şekilde benimsenmelidir. Ancak kilometre taşı trend analizi gibi verimli araçları bile mümkün kılmayan, kontrol edilemez bir geliştirme türünün benimsenmesinden kesinlikle kaçınılmalıdır. Burndown grafiği genellikle gerçek bir alternatif değildir, çünkü çevik planlama gerekli proje bütçelerimi çok sık altüst eder.
İş açısından, proje bütçelerinin onaylanmasını sağlamak için klasik bir maliyet-fayda planlaması yapmam ve bunu savunmam gerekir. Earned Value Management – yani erken aşamalarda bile geliştirme performans analizleri – mümkün olmaya devam etmelidir.
Sonuç
Çevik olmak, yeni bilgileri dikkate alarak planlanan sonuçları beklenen faydaya karşı tartmak, hedefleri uygun şekilde uyarlamak ve böylece proje planlamasını müşteri ve şirket bakış açısından döngüsel olarak güncellemek demektir – gerekli bütçe ve kaynak onaylarını da dahil ederek.
Çevik çalışmak, yönetimde de olgunluk düzeyine bağlı liderlik gibi kanıtlanmış yöntemleri yerleştirmek ve uzmanlık bilgisini çalışanlar tarafından saygı görecek şekilde organize etmek anlamına gelir.
Çeviklik ayrıca, şirketlerin veya kamu sektörünün planlama ufuklarının koşullarını, yönetim ve ekiplerin zihniyetini ve şimdiye kadarki çalışma yöntemlerini yapıcı bir şekilde bir araya getirmeyi gerektirir.