Google'da "UX" arama sorgusunda kaç sonuç çıktığını biliyor musunuz? (Incognito Mode'da) Tam 234.000.000. Hakkında bu kadar çok içerik bulunan UX dünyası içerisinde, terminolojik kavramlarda trafik kazalarının olması da bir o kadar normal. Lakin bazı kazalarda, eğer ki dikkatli olunmaz ve önlem alınmazsa, ekip üyelerinden can kaybı olma ihtimali de çok yükseliyor. Gelin, en çok kaza olan alanlardan bir tanesine birlikte göz atalım.
Google’da “UX” arama sorgusunda kaç sonuç çıktığını biliyor musunuz? (Incognito Mode’da) Tam 234.000.000. Hakkında bu kadar çok içerik bulunan UX dünyası içerisinde, terminolojik kavramlarda trafik kazalarının olması da bir o kadar normal. Lakin bazı kazalarda, eğer ki dikkatli olunmaz ve önlem alınmazsa, ekip üyelerinden can kaybı olma ihtimali de çok yükseliyor. Gelin, en çok kaza olan alanlardan bir tanesine birlikte göz atalım ve ölümcül sorulardan bir tanesini birlikte yanıtlayalım: UX dokümantasyonunda “Use Case” mi yoksa “User Story” mi yazmalıyız? (“İkisini de” diyorsanız, yazıyı hiç okumayın, çıkın bir hava alıp, geri gelin, sonra tekrar başlayalım.)
Agile fırtınası Türkiye’yi vurdu vuralı, meraklıların arasında Use Case ve User Story’lerin yazımı konusundaki tartışmaların ateşi de harlanmaya yüz tuttu. Eğer ki Agile metodolojisinin taşıdığı ana kaygı, “İşe yarayacak en basit adımları önce atıp, diğer endişeleri ürün komponentlerinin yaratım sürecine kadar – detayda boğulmamak amacıyla – ertelemek” olarak yorumlanabilirse, bir UX projesinde hem Use Case hem de User Story yazmak, bu durumla tam anlamıyla bir antitez oluşturuyor.
Neden mi? Gelin, bu iki arasındaki temel farklara, kullanımları esnasında ortaya çıkan risklere ve yaklaşımlara değinerek, biraz detaya girelim.
Bu içerik ücretsiz!
Okumaya devam etmek ve SHERPA Blog okuru olmak için aşağıdakilerden birini seç. Her hafta yenileri eklenen yüzlerce içeriğe ücretsiz ve sınırsız eriş.
Use Case, bir aktör ile sistem arasında gerçekleşen, çoğunlukla aktör lehine gözlemlenebilir bir değer yaratan uçtan uca etkileşim dizisine verilen isimdir.
“Bu şahane bir tanım da, yani biraz kuantum fiziği tanımı gibi olmadı mı?” diye düşünenler, yalnız değilsiniz. Google’daki “Use Case” araması sonuçlarında göreceğiniz çubuk adamlarla yukarıdaki tanımı aynı sepete attığımızda, ortaya hiçbir zaman kullanmak istemeyeceğiniz bir dokümantasyon formatı çıkıyor, öyle değil mi?
Ben, örnek üzerinden ilerlememizin daha faydalı olacağını düşünüyorum.
Aktör bir şey yapar.
Sistem başka bir şey yapar.
Aktör diğer başka bir şeyi yapar.
Sistem bambaşka diğer bir şey yapar.
“Görsel olarak anlat lütfen” diyenler için aşağıdaki örnek Use Case diagramını paylaşıyorum.
Alın size bir dizi etkileşim. Bu mudur yani Use Case? Hayır.
Nihayetinde, bu etkileşim dizisinin uçtan uca bir akış oluşturması için (ana akış ya da main flow), istisnai durumlar ve alternatif adımlar için de “alternatif akışlar” dizisine sahip olmamız gerekiyor. Bir başkasının, örneğin bir UI Designer veya Developer’ın, Use Case’lerinizi ele alıp inceledikten sonra, onları esas alarak faydalı bir üretim yapabilmesi için, Use Case’lerin çerçevesini çizdikleri aktivitelere dair ana ve alternatif akışları bir hayli detaylıca düşünmeniz gerekiyor. Bu düşünme eylemi sizin Use Case içerisinde Sistem ile etkileşimde olan Aktör’ün hangi durumda nasıl davranabilmesini belirleyen iş kurallarına, bu iş kurallarının istisnai durumlarda Aktör’e ne gibi haklar tanıyıp, nasıl yollar göstereceğine vakıf olmanızı da şart koşuyor. Diğer bir deyişle, Agile’ın baştan karşı olduğu BDUF – Big Design Up Front – zorunlu hale geliyor. Hakkıyla ortaya çıkartılan Use Case için, “Önce her şeyi düşüneyim, planlayayım, detaylandırayım, sonra üretime geçerim.” şart.
E, hani Agile’dık?
User Story
User Story yazmanın anahtarı, User Story yazma niyetinin projenin en başından detaya girmemek olduğu; detayların gerektiği zamanda, gerekli oran ve derinlikte projeye eklenebildiği bir çalışma ortamı yaratabilmektir.
Use Case’den farklı olarak, User Story örnekleri çok daha basit akıl yürütmelerle yaratılır;
(Orijinal tanımıyla)
As a <user>, I can <indicate folders not to backup> so that <my backup drive isn’t filled up with things I don’t need saved>
(Türkçe tanımıyla)
Bir <kullanıcı> olarak <yedeklenmemesini istediğim klasörleri belirlemeliyim>, böylelikle <diskim yedeklenmemesini arzu ettiğim bilgilerle dolup taşmasın.>
Anahtar yaklaşımın da özetlediği üzere, aslında User Story’ler aşırı detaycılığa karşı bir tepki olarak doğmuşlardır. BDUF karşıtı yaklaşım olarak da adlandırılmaları tam da bu noktadan kaynaklanır. Kent Beck eXtreme Programming (XP) kavramıyla çıkageldiğinde, User Story’leri de bu iteratif ve artarak ilerleyen üretim yaklaşımına destek noktası olarak konumlandırmış ve gerçek, öz Agile 🙂 metodolojiye selam çakmıştı.
Mike Cohn ise, konuyu bir boyut daha ileriye götürerek “User Story Applied” isimli bir kitap yazdı ve Agile projelerinde User Story’lerin kullanımına dair çok zengin bir kaynakça oluşturdu.
Sonrasında Jeff Patton User Story’lerin bir ürünün fonksiyonel derinliğinde boğulmamaları için Story Mapping tekniğini ortaya attı. Bu efor, “çok basit” şeklinde yerilebilecek bir kullanıcı hikayesini, daha büyük bir hikaye içerisinde nasıl konumlandırıp, diğer (basit!) kullanıcı hikayeleriyle nasıl ilişkilendirebileceğimizi gösteren yöntem oldu.
User Story’nin Agile içerisindeki konumunu özetleyen aşağıdaki grafiği de paylaşmak isterim.
Örneklerden de anlaşılabileceği üzere User Story oluşturma sürecinde 3 öne çıkan kavram var:
“Bu hikayeyi ürünün hangi kullanıcı tipine dair yazıyoruz?” sorusuna yanıt veriyoruz.
Hikaye içerisinde ihtiyaç olarak görülen aktiviteyi tanımlıyoruz.
Bu hikayenin sonucunda ortaya çıkan kullanıcı faydasını, önceliklendirme çalışmamızda tekrar gözden geçirebilmek amacıyla net bir şekilde ortaya koyuyoruz.
User Story’nin, ürünün iş hedefleri ekseninde, değer zinciri içerisinde nereye konumlanacağı da, işte bu 3 adımın mutlak surette ortaya koyulabilmesinden geçiyor.
User Story’lerin kabul durumlarını tanımlayan “Acceptance Criteria”lar, bağlı bulundukları bir üst katman olan Epic’ler ve Mike Cohn’ın “User Story’lerinin 3 C’si; Card, Conversation ve Confirmation” la devam etmek istesem de, burada User Story anlatımına bir son veriyor ve yazımın sonunda vereceğim okuma listesine mutlaka göz atmanızı öneriyorum.
Use Case ile User Story arasındaki temel fark
Bu ikili arasındaki temel ayrıştırıcı kavram, zamanlamadır. Her an, iş hedefleri ve ürün özellikleri bazında değişkenlik göstermeye açık, zaman baskısıyla form değiştirmeye müsait bir ürün geliştirme ortamında, tepki verme süresinin “esas aranan yetkinlik” olduğu bir dönemde ürün geliştirmeye çalışıyorsanız, yola çıkış noktasında olabilecek tüm detayları düşünmeye çalışıp, analizler yapıp, sonrasında “tasarlamayı” tercih etmekle etmemek arasında fark, User Story ile Use Case’i birbirinden apayrı noktalara konumlandırıyor.
Use Case “baştan detaylandırırım”cılar için, User Story ise “en baştan, bana o an gerektiği kadarını detaylandırırım”cıların tercihini simgeliyor.
User Story’ciler, “Gerektiği zaman bu User Story’yi daha da detaylandırabilir, onunla ilişkili başka User Story’ler yaratabilirim. Ve hatta bu User Story, değişen şartlara göre gereksiz hale gelebilir, onu silmekte hiçbir sakınca görmeyebilirim.” eğilimindeyken, Use Case’ci “öncül büyük plandan uzaklaşmamak”, diğer bir deyişle, “detaylı analizden sapmamak adına” değişimle çatışmayı göze alabilir.
Bir Agile Projesi’nde User Story yerine Use Case kullanabilir miyim?
Teoride buna karşı gelen bir durum söz konusu değil. Lakin, Use Case yaratımında çoğunlukla göz ardı edilen “sebep/fayda tanımı” ve iş hedefleriyle kurulması gerekli olan ilişkinin yoksunluğu parçalı ve iteratif yaratımın önüne set çektiğinden; Agile Projesi’nde Use Case’in kullanımı, ortaya “yekpare” ve “ya tamamıyla kabul, ya da red” felsefesinin dayatması gibi devasa bir ikilemi çözümlemeyi şart koşuyor. Baştan birçok detayı çözmeye çalışmaya harcanan efor, üretim süresince bu eforun ortaya çıkardıklarına mutlak sadakat gösterme zorunluluğunu da beraberinde getirdiğinden, hem zamanın efektif kullanımına bariyer oluşturuyor hem de ürünün / servisin yaratımı süresince ortaya çıkabilecek katma değer sağlayıcı “yeni gelişmeleri” görmezden gelmeyi gerektiriyor.
Hangisini kullanmalı?
Ben, hiçbir projenin başladığı/el sıkışıldığı şekilde devam etmediği jenerasyonun bir üyesiyim. Hani Japonlar’ın iş yapış şekline özenen, projenin ortasında yaptığı tüm planlar çatır çutur patlayan ve bu durumda oturup ağlamak yerine çözüm bulmayı ve sonuca ulaşmayı seve seve üstlenmek durumunda kalan, ve muhtemelen mezarında “işine sahip çıkarken ölen adam” yazacak olan emektarlardanım…
“Disiplin”i Alman futbol takımında oyuncu sanan bir iş yapış felsefesinin hakim olduğu bir pazarda iş yapmaya çalışıyorsanız ve yegane sermayeniz zaman ise, User Story ile onun beraberinde getirdiği iteratif üretim yaklaşımını tercih etmenizi öneririm.
“Konuyu sevdim. Okuma listesi var diyordun?”
Konu ilginizi çektiyse, o zaman aşağıdakileri sırasıyla okumaya başlayabilirsiniz…
Bu güzel paylaşımınız için teşekkür ederek başlamak istiyorum. Use Case gibi UML kavramları ile proje modellemek ve User Story gibi iterasyonel Scrum modelleri ile çalışmak arasındaki farklar üzerine bende araştırmalar yapıyorum. iterasyonel yaklaşımların ortaya çıkışı aslında değişime karşı aya uydurabilme arayışının sonucu gibi duruyor. Örneğin yeni bir sosyal medya platformu tasarlıyorsunuz ve insanların bu ortamda nasıl bir davranış sergileyeceğini kestiremiyorsunuz. Belki resim paylaşımları ilgi görecek ve siz o tarafta işin içine görüntü işleme ile renk katmak isteyeceksiniz. Belki başka başka yönler gelişmeye başlayacak ve bazı özellikleri kaldırmak zorunda kalacaksınız. Bu gibi durumlar değişimdi ve buna ayak uydurabilmek şarttır. Kullanıcının neler isteyip neleri reddedeceğini kestiremezsiniz. Diğer taraftan öyle projeler olur ki matbu evrak gibi sık değişmez kuralları vardır. Baştan sona tüm iş adımları belirlidir. Bu durumda projeye göre yöntem seçmek mi gereklidir? Örneğin yeni bir startup ise ve sürekli gelişim öngörülüyor ise User Story, Süreci belli kurumsal proje ise Use Case denilebilir mi?
Bu güzel paylaşımınız için teşekkür ederek başlamak istiyorum. Use Case gibi UML kavramları ile proje modellemek ve User Story gibi iterasyonel Scrum modelleri ile çalışmak arasındaki farklar üzerine bende araştırmalar yapıyorum. iterasyonel yaklaşımların ortaya çıkışı aslında değişime karşı aya uydurabilme arayışının sonucu gibi duruyor. Örneğin yeni bir sosyal medya platformu tasarlıyorsunuz ve insanların bu ortamda nasıl bir davranış sergileyeceğini kestiremiyorsunuz. Belki resim paylaşımları ilgi görecek ve siz o tarafta işin içine görüntü işleme ile renk katmak isteyeceksiniz. Belki başka başka yönler gelişmeye başlayacak ve bazı özellikleri kaldırmak zorunda kalacaksınız. Bu gibi durumlar değişimdi ve buna ayak uydurabilmek şarttır. Kullanıcının neler isteyip neleri reddedeceğini kestiremezsiniz.
Diğer taraftan öyle projeler olur ki matbu evrak gibi sık değişmez kuralları vardır. Baştan sona tüm iş adımları belirlidir. Bu durumda projeye göre yöntem seçmek mi gereklidir? Örneğin yeni bir startup ise ve sürekli gelişim öngörülüyor ise User Story, Süreci belli kurumsal proje ise Use Case denilebilir mi?
Bayram çözüm önerine katılmamak elde değil. Elini görüyor ve artıyorum: belki de projenin ihtiyaçlarına göre bu ikilinin yanında storyframing’i ya da job story’leri de denemeliyiz. İlgini çekerse https://uxdesign.cc/what-is-storyframing-21cd12dfe701#.y4i4fxde0 ve https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27?gi=cb942830b5e7#.hq2n1sjks deki makalelere göz atabilirsin.