Çevik Takımda Tasarım: "Yeterince İyi" Bir Karardır, Bahane Değil

Çevik takımlarda tasarım işi bir yerde durur. Asıl sorun mükemmeliyetçilik değil, durma noktasının hiç konuşulmamış olması: eşik yazılı değilse herkes kendi eşiğini kullanır ve aynı tartışma her sprint yeniden açılır. "Yeterince iyi", işi savuşturmak için kullanılan bir laf değil, sprint başında yazılan bir kabul kriteridir.

Eşiği sprint başında yaz

Kabul kriteri yazılmadan başlanan tasarım işi, review toplantısında estetik tartışmasına dönüşür. Ortada ölçü yoktur; olan tek şey, odadaki en ısrarlı kişinin zevkidir. Eşik yazıldığında tartışma bitmez, yer değiştirir: artık "bu güzel mi" değil, "konuştuğumuz şeyi karşılıyor mu" sorulur.

Bir kayıt ekranı için eşik şuna benzer:

• Kullanıcı kaydı üç adımda bitirebiliyor.
• Boş durum ve hata durumu çizilmiş.
• Mevcut bileşen setinin dışına çıkan yeni bir öğe yok.

Üçü de karşılanıyorsa iş biter, cila turu açılmaz. Karşılanmıyorsa iş bitmemiştir ve "yeterince iyi" denerek kapatılamaz.

İterasyon geri dönmeyi garanti etmez

"Mükemmelliği zamanla, tekrar eden iterasyonlarla elde edersiniz" cümlesi kulağa makul gelir, pratikte çoğu takımda çalışmaz. Bir sonraki sprintte backlog'un başına yeni bir özellik gelir; geri dönülmek üzere bırakılan iş her önceliklendirmede ikinci sırada kalır ve orada yaşlanır.

Bunu ölçmek zor değil: "sonra düzeltiriz" notuyla açılmış kayıtların kaçının kapandığına bak. Oran düşükse takımın gerçek "yeterince iyi" tanımı, bugün gönderdiği şeydir. Geri dönülmeyecek bir iş için bugünkü eşik nihai eşiktir, eşiği de ona göre koymak gerekir.

Ekranda beş dakikalık karar, kodda kalıcı

Tasarımda hızlı alınan karar, uygulamada aynı hızla geri alınmaz. Mockup'ta iki piksel farkla duran iki kart kodda iki ayrı bileşene dönüşürse, sonraki her değişiklik iki kere yapılır ve bir süre sonra biri unutulur. Prototipte tek seferlik varyant açmak ucuzdur, onu bileşen kütüphanesine sokmak değil (bu ikisi sürekli aynı iş sanılıyor, değiller).

O yüzden "hızlı çözelim" derken iki tür kararı ayırmak gerekir. Sistemin içinde kalan kararlar, yani mevcut renk, mevcut bileşen, mevcut düzen ile verilenler ucuzdur; bunlarda rahatça yeterince iyiyle yetinilir. Sistemin dışına çıkan kararlar ucuz değildir, hız oradan kazanılmaz.

Nerede yetinilmez

Yetinmecilik, geri alınabilir kararlar için bir yöntemdir. Buton rengi bir sprint sonra değişir. Kayıt akışına eklenen zorunlu bir alan ise veri modeline ve üç ekrana yayıldıktan sonra değişmez; onu değiştirmek ayrı bir proje olur.

Ölçü basit: geri almanın maliyeti düşükse yetin, yüksekse yetinme. Bilgi mimarisi, adres yapısı, veriyi şekillendiren form alanları ve erişilebilirlik kararları ikinci gruptadır ve iterasyona bırakılamaz. Kalan her şeyde erken çık, kullanıcının önüne koy, dönen veriye bak.