Lean UX ve Agile Terimleri Sözlüğü: Tanımlar ve Pratikteki Karşılıkları

Aynı terimin ekipte iki farklı anlama gelmesi, toplantıyı uzatan şeylerin başında geliyor. Aşağıdaki sözlük Lean UX ve Agile kavramlarını tek tek tanımlıyor, ama asıl derdi tanım değil: hangi terimin pratikte nereye kadar işe yaradığı. Karışması en kolay olan tahmin ve ölçüm terimlerini ayrı bir bölüme aldım.

Süreç çerçevesi

• Agile: Kısa döngülerle çalışıp her döngünün sonunda geri bildirim toplayan, plan değiştiğinde planı savunmayan geliştirme yaklaşımı.
• Scrum: Agile'ın en yaygın uygulaması. İş, süresi sabit sprintlere bölünür; her sprintin başında plan, sonunda teslim vardır.
• Kanban: Sabit döngü yok, akış var. Panodaki her sütuna aynı anda kaç işin girebileceği sınırlanır, tıkanan yer kendiliğinden görünür hale gelir.
• Sprint: Genelde iki haftalık, kapsamı başladıktan sonra değişmeyen çalışma dilimi.
• Backlog: Yapılacak işlerin öncelik sırasıyla durduğu tek liste. İkinci bir liste açıldığı anda backlog olmaktan çıkar.
• Backlog refinement: Maddelerin sprinte girmeden önce netleştirildiği, bölündüğü, gerekirse silindiği toplantı.
• Daily standup: On beş dakikalık günlük senkron. Durum raporu için değil, tıkanıklık bildirimi için.
• Sprint demo: Sprint sonunda çalışan ürünün gösterildiği toplantı. Slayt gösterilen demo, demo değildir.

Scrum ile Kanban arasında seçim yaparken bakılacak tek şey işin ritmi. Kapsamı önceden belirlenebilen ürün geliştirmede sprint sınırı işe yarar, çünkü ekibe "bu iki hafta bu kadar" diyebileceği bir zemin verir. Talebin ne zaman geleceğinin belli olmadığı işlerde, yani destekte, hata düzeltmede, içerik akışında, aynı sınır yapay kalır ve sprintin ortasında bozulur. Tasarım tarafını genelde Kanban'la, geliştirme tarafını sprintle takip ederim. İkisini tek panoda birleştirme denemelerinin çoğu aynı yerde tıkanıyor: tasarımın geliştirmeden bir sprint önde gitmesi gerekiyor, tek pano bunu gösteremiyor.

İşi parçalama terimleri

• Epic: Tek sprinte sığmayan, altında birden fazla hikaye barındıran iş paketi.
• User story (kullanıcı hikayesi): İhtiyacı kullanıcının ağzından tek cümlede anlatan tanım. "Bir müşteri olarak tek tıkla ödeme yapmak istiyorum, böylece sepette oyalanmayayım."
• Kabul kriteri: Hikayenin bittiğine kimin, neye bakarak karar vereceği. Yazılmadıysa hikaye bitmez, tartışılır.
• MVP: Bir varsayımı test etmeye yetecek en küçük çalışan sürüm.
• Spike: Çıktısı özellik değil cevap olan, süresi baştan sınırlanmış araştırma işi.

MVP bu listenin en çok yıpranmış terimi. Çoğu yerde "bütçe bitti, elimizde kalanı çıkaralım" anlamında kullanılıyor. Ölçüt açık: sürümün sonunda hangi soruya cevap alacağınızı tek cümleyle söyleyemiyorsanız elinizdeki MVP değil, yarım üründür.

Tahmin ve ölçüm terimleri

• Story point: Bir işin zorluğunu ve belirsizliğini, saat yerine göreli bir puanla ifade etme yöntemi.
• T-shirt sizing: İşleri S, M, L, XL olarak kabaca sınıflandırmak. Backlog'un henüz puanlanacak kadar netleşmediği erken aşamada puandan daha dürüst sonuç verir.
• Velocity: Ekibin bir sprintte tamamladığı puan toplamı.

Velocity'nin ölçüm değeri sanıldığından düşük, sebebi de basit: puanı veren ekip, hızı da kendi verdiği puanla ölçülüyor. Aynı iş üçe yerine beşe puanlandığında velocity yükselir, teslim edilen şey değişmez. Velocity'yi performans göstergesi haline getiren her yapı bu yüzden birkaç sprint içinde puan enflasyonu üretir, üstelik kimse yalan söylemeden. Ekipler arası karşılaştırma ise büsbütün anlamsız; iki ekibin puan ölçeği aynı olmadığı sürece 40 ile 25 arasında kıyas kurulamaz. Bu sayı yalnızca tek bir ekibin kendi planlamasında, "önümüzdeki sprinte yaklaşık ne sığar" sorusuna cevap vermek için işe yarar.

UX borcu

Teknik borç er geç bir araç tarafından yüzünüze vurulur. Statik analiz uyarır, test düşer, derleme yavaşlar, bağımlılık güncellemesi patlar. Kullanıcı deneyimi borcunun böyle bir alarmı yok.

Sekiz alanlık formu aylar önce hızlı çıkmak uğruna üç adıma bölmüşsünüzdür; kod temizdir, testler geçer, hata kaydı açılmaz, sadece tamamlama oranı sessizce düşer. Bu yüzden UX borcu ancak yazıldığı yerde vardır. Fark edildiği anda backlog'a bir madde olarak girmezse, sonraki sprintte hiç yaşanmamış sayılır ve üstüne yeni ekranlar kurulur.