İçeriğe geç

Kullanıcı Hikayesi Detaylandırma Yöntemleri

Kullanıcı hikayeleri (User Stories) proje başlarında genellikle belirsizdir. Agile (Çevik) proje geliştiren ekipler, belirsiz olan bu kullanıcı hikayelerini proje başlarında detaylandırmak yerine, bu işlemi tüm proje geliştirme sürecine yaymayı tercih ederler. Bunun nedeni de önceden detaylandırılan bir kullanıcı hikayesi, proje geliştirme süresinde değişikliğe uğrarsa, bu boşa harcanmış bir efor anlamındadır. O yüzden, yakın sprintlerde geliştirilecek olan kullanıcı hikayelesi detaylandırılmalıdır. Agile bir ekibin kullanıcı hikayesi detaylandırma çalışmasını 2 farklı yoldan yapabilir. Bunlar;

  1. Kullanıcı hikayesini alt hikayelere bölmek
  2. Kullanıcı hikayesine kabul kriteri eklemek

1. Hikayeyi Alt Başlıklara Bölmek

Kullanıcı hikayesi detaylandırma için ilk yöntem, hikayeyi birden fazla alt hikayelere (Sub Stories) bölmektir. Birden fazla küçük hikayecikler yazmanın, çok fazla hikaye olmasının yan etkisi dışında daha ayrıntılı bir bilgiye sahip olursunuz. Bir örnek üzerinden gidecek olursak; geliştirilen üründe, sosyal medya ile giriş yapabilme özelliği olduğunu varsayalım ve bu özellik için bir kullanıcı hikayesi yazarak başlayalım.

  • Kullanıcı olarak, giriş yapabilmek için, sosyal medyayı kullanabilirim.

Ekip, yakındaki sprint için bu hikayeyi geliştirmeyecekse, bu hali ürün özelliği ile ilgili şimdilik yeterli bilgiyi içermektedir. Ne zaman ekip, bu kullanıcı hikayesini geliştirecekse, o zaman ekip için ek ayrıntılara ihtiyaç vardır. Ekip, hikayeyi sağlayabilmek için, ürüne giriş yapılırken hangi sosyal medya hesaplarının kullanılabileceğini bilmek isteyecektir. Böylece, ilk kullanıcı hikayesini aşağıdaki gibi alt hikayelere bölmüş oluruz:

  • Kullanıcı olarak, giriş yapabilmek için, Facebook hesabımı kullanabilirim.
  • Kullanıcı olarak, giriş yapabilmek için, Linkedin hesabımı kullanabilirim.
  • Kullanıcı olarak, giriş yapabilmek için, Twitter hesabımı kullanabilirim.

Product Owner, hikayenin geliştirilmesi için, onu alt hikayelere bölerek Development Team’e yeterli bilgiyi vermiş olur.

2. Hikayeye Kabul Kriteri Eklemek

Kullanıcı Hikayesi detaylandırma için ikinci bir yol da, Product Owner’ın hikayenin sağlandığını kabul etmesi için gereken kriterleri belirlemesidir. Bu kriterler Kabul Kriterleri (Acceptance Criteria) olarak adlandırılır.

Yukarıdaki örnek için; Sosyal medya aracılığı ile giriş yapmak hikayesine kabul kriterleri ekleyerek detaylandırdığımızda, aşağıdaki gibi bir detay elde etmiş oluruz:

  • Kullanıcı olarak, giriş yapabilmek için, sosyal medyayı kullanabilirim.
    • Kabul Kriteleri
      • Facebook hesabı ile giriş
      • Linkedin hesabı ile giriş
      • Twitter hesabı ile giriş

Bu iki örnek ile, hikayelere daha fazla ayrıntı sağlamanın yöntemlerini açıklamaya çalıştım. Kullanıcı hikayesi detaylandırma işleminde bu iki yaklaşımın sonuçları birbirine benzer görünse de,  bazen farklı durumlarda diğerine göre daha fazla avantaj sunabilir. Peki bu durumda hangi yöntemi seçmek gerekir?

Hangi Kullanıcı Hikayesi Detaylandırma Yöntemini Seçmeliyiz?

Her iki yöntem de belirgin olmayan kullanıcı hikayeleri için, geliştirme öncesinde development ekibi için yeterli bilgiyi sağlar. Fakat bazı durumlarda biri diğerine göre daha farklı avantaj sağlayabilir. O yüzden bu iki yöntemin hangi durumlarda kullanılması gerektiğini bilmekte fayda olacaktır.

İlk incelediğimiz “Alt Hikayeler Oluşturmak” yöntemini tercih etmenin iki nedeni vardır. Birincisi, parçalanmamış olan hikaye çok büyükse bu yöntem tercih edilmelidir. Geliştirilmek üzere seçilen kullanıcı hikayesi bir Sprint süresinden daha fazla olacak şekilde geliştirilmesi gerekebilir. Bu durumda bu hikayenin alt hikayelere ayrılması daha doğru olacaktır.

Bir hikayeyi kabul kriterlerini eklemek yerine alt hikayelere ayırmanın ikinci bir nedeni ise kabul kriterlerinin ürün sahibi tarafından farklı decerede önceliklendirilmesidir. Örneğin Product Owner için, Linkedin ile giriş yapabilmek, Twitter ve/veya Facebook ile giriş yapabilmekten daha önemli olabilir. Bu 3 sosyal ağını kabul kriterlerine eklemek yerine, ilk hikayeyi alt hikayelere bölmek gerekir. Böylece elimizde aşağıdaki gibi bir hikaye listesi olur:

  • Kullanıcı Hikayesi 1: Linkedin hesabı ile giriş yapabilmek
  • Kullanıcı Hikayesi 2: Diğer sosyal medya hesapları ile giriş yapabilmek
    • Kabul Kriterleri
      • Facebook hesabı ile giriş
      • Twitter hesabı ile giriş

İkinci incelediğimiz “Kabul Kriterleri Eklemek” yöntemini, hikaye Sprint’e sığabilecek büyüklükte ve/veya belirlenen detaylar aynı öncelik değerinde ise kullanmak gerekir. Bir hikayenin küçük eforda ama çok sayıda detay bilgisi varsa yine bu yöntem daha etkili olacaktır. Bir örnek üzerinden gidelim. Aşağıdaki gibi bir kullanıcı hikayemiz olsun;

  • Kullanıcı olarak, hesabımı oluştururken, güçlü bir şifre ile kayıt olmak zorundayım.

Bu hikaye için detay bilgileri düşünecek olursak gereklilikleri çok fazla sayıda olacaktır. Her bir ihtiyaç için alt hikayelere ayırmak fazla kalabalık olacak ve okuma zorluğu yaratacaktır.

  • Kullanıcı olarak, hesabımı oluştururken, en az 8 karakter içeren bir şifre ile kayıt olmak zorundayım.
  • Kullanıcı olarak, hesabımı oluştururken, en az 1 rakam içeren bir şifre ile kayıt olmak zorundayım.
  • Kullanıcı olarak, hesabımı oluştururken, en az 1 harf içeren bir şifre ile kayıt olmak zorundayım.
  • Kullanıcı olarak, hesabımı oluştururken, en az 1 büyük harf içeren bir şifre ile kayıt olmak zorundayım.
  • Kullanıcı olarak, hesabımı oluştururken, en az 1 küçük harf içeren bir şifre ile kayıt olmak zorundayım.
  • Kullanıcı olarak, hesabımı oluştururken, en az 1özel karakter içeren bir şifre ile kayıt olmak zorundayım.

Tüm bu kontrolleri geliştirmek için uzun bir süreye ihtiyaç yoktur. Ayrıca her bir koltrol aynı önem derecesindedir. O yüzden alt hikayelere ayırmak gerekmez. Böyle bir uyarlama yerine aşağıdaki gibi hikayeye kabul kriteri eklemek en doğru yöntemdir.

  • Kullanıcı olarak, hesabımı oluştururken, güçlü bir şifre ile kayıt olmak zorundayım.
    • Kabul Kriteri
      • En az 8 karakter olmalı
      • En az 1 rakam içermeli
      • En az 1 harf içermeli
      • En az 1 büyük harf içermeli
      • En az 1 küçük harf içermeli
      • En az 1 özel karakter içermeli

Aşağıdaki, her iki yöntemin hangi şartlarda kullanılması gerektiği ile ilgili akış diagramını görebilirsiniz.

Kullanıcı Hikayesi Detaylandırma Diagram

Agile’a iyi adapte olmuş bir ekip, kullanıcı hikayesi detaylandırma çalışmalarında her iki tekniği de kullanmalıdır. Orijinal hikayenin büyük olması veya alt hikayelerinin farklı önceliklere sahip olması durumunda hikayeyi bölmeli, her bir hikayeye de kabul kriterlerini eklemelidir.  Proje geliştirme süresinde kullanılan tekniklerde mutlaka bu yöntemlere de yer verilmelidir. Diğer agile teknikler ile ilgili yazıya buradan bulabilirsiniz.

Agile İş Analisti’nin Bilmesi Gereken İş Analizi Teknikleri

 

İlkim Dilara KADAKALOĞLU

 

 

 

Tarih:Agileİş Analizi

İlk Yorumu Siz Yapın

    Bir cevap yazın

    E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

    %d blogcu bunu beğendi: