User Story

 

User Story Nedir?

“User Story”‘ler, kullanıcı hikayeleri olarak çevirebileceğimiz, kullanıcı ile sistem arasındaki etkileşimi anlatmak için kullanılan ve kullanıcının kazancını  vurgulayan metinlerdir. Bu metinler oldukça basit, sade ve kısadır. 

Bir hikaye, yazılım geliştiricinin harcayacağı eforun tahminini yapabilmesi için gereken bilgiyi içeren ve bir gereksinimden daha üst düzeyde olan tanımlamadır. Hikayeleri daha iyi anlamak için kendinizi müşterinin yerine koymanız gerekmektedir. User Story’ler “use case”‘ler veya senaryolardan daha küçük parçalardır ve bunları yazılımcıların kendisi değil projenin sahibi yazar.

Bir iş bulma sitesi düşünürsek aşağıdaki gibi hikaye örnekleri oluşturabiliriz.

• Kullanıcı iş arayabilmelidir.

• Kullanıcıya yeni işler için bildirim gönderilmelidir.

• Kullanıcı öz geçmiş hazırlayabilmelidir.

Hikayeler kullanıcı için değerli olan bilgileri içermelidir. Projede hangi yazılım dilinin kullanılacağı, bağlantıların nasıl olacağı gibi detaylar hikaye olarak değerlendirilmemelidir.

3C (Card, Conversation and Confirmation)

Ron Jeffries'e göre kullanıcı hikayeleri 3 bileşenden oluşmaktadır. Bunlar Kart, Görüşme ve Onay'dır.

Card (Kart)

Kart, sohbete davet olarak düşünülebilecek hikayenin amacını açıklamak için kullanılan 2-3 cümleyi temsil eder. Kart, amacı özetleyen ve ayrıntıları belirlenecek olan daha ayrıntılı bir gereksinimi temsil eden, akılda kalıcı bir simge görevi görür. Tüm Ürün İş Listesi Öğelerinin mükemmel bir şekilde önden yazılmasına gerek yoktur. Müşterinin ve ekibin, üzerinde çalışırken ihtiyaç duyulan temel işi / sistemi keşfedeceğini kabul eder. Bu keşif, kullanıcı hikayeleri etrafında konuşma ve işbirliği yoluyla gerçekleşir.

Conversation (Görüşme)

Görüşme, hedef kullanıcılar, ekip, ürün sahibi ve diğer paydaşlar arasındaki, amacı uygulamak için gereken daha ayrıntılı davranışı belirlemek için gerekli olan bir tartışmayı temsil eder. Başka bir deyişle, kart aynı zamanda niyetle ilgili bir konuşma vaadini de temsil eder. Görüşme, hikayenin gerçek değerinin yattığı yerdir ve yazılı Kart, bu konuşmanın mevcut ortak anlayışını yansıtacak şekilde ayarlanmalıdır. Bu konuşma çoğunlukla sözlüdür, ancak çoğunlukla dokümantasyon ve çeşitli türlerde ideal olarak otomatikleştirilmiş testlerle desteklenir (örneğin Kabul Testleri).

Confirmation (Onay)

Onay, müşteri veya ürün sahibinin hikayenin tatmin edici şekilde uygulandığını, nasıl onaylayacağı Kabul Testini temsil eder. Başka bir deyişle, Onay, hikayenin amacı ve daha detaylı gereksinimleri yerine getirip getirmediğini belirlemek için uygulanacak memnuniyet koşullarını temsil eder. Ürün Sahibi, "tamamlandı" olarak kabul edilmeden önce hikayenin tamamlandığını onaylamalıdır Ekip ve Ürün Sahibi, Ekibin mevcut "bitti" tanımına göre her hikayenin "uyumunu" kontrol eder. Mevcut "bitti" tanımından farklı özel kabul kriterleri bireysel hikayeler için oluşturulabilir, ancak mevcut kriterler iyi anlaşılmalı ve Ekip tarafından kabul edilmelidir. İlgili tüm kabul testleri geçer durumda olmalıdır.

Detaylar Ne Olacak?

Hikayeler için bir kart hazırladığımızda bu kart ile ilgili bir sürü detay soru ortaya çıkmaktadır. Bu detaylar yeni birer kart olarak oluşturulmalıdır. Hikayelerin çok olması uzun olmasından çok daha iyidir.

Kullanıcı öz geçmiş oluşturabilmelidir dediğimizde öz geçmiş içerisinde hangi bilgiler olacak, hangi bilgiler gruplanacak gibi detaylar ortaya çıkmaktadır. Bu detaylar için aşağıdaki şekilde kartlar oluşturulabilir.

• Kullanıcı kişisel bilgilerini girebilmelidir.

• Kullanıcı eğitim bilgilerini girebilmelidir.

• Kullanıcı iş tecrübelerini girebilmelidir.

Bir kart ile bağlantılı olan diğer kartlar EPIC altında gruplandırılabilir. Fakat bu kartların birbiri ile bağımlı olmasına neden olmamalıdır.

User Story'nin Yaşam Döngüsü

Bir yazılım projesi boyunca her bir kullanıcı hikayesi için altı ana durum vardır:

• Pending

Kullanıcı ve proje ekibi arasındaki iletişim sayesinde kullanıcı hikayeleri bulunur. Bu durumda, kullanıcı hikayeleri, kullanıcının ihtiyacının kısa bir açıklamasından başka bir şeye sahip değildir. Gereksinimler hakkında ayrıntılı bir tartışma, sistem mantığı ve ekran tasarımı henüz yoktur. Aslında, kullanıcı hikayesinin şimdilik tek amacı, bu kullanıcı hikayesinde (kart) yazılan kullanıcının talebinin gelecekteki tartışması için tüm taraflara hatırlatmaktır. Gelecekte kullanıcı hikayesinin atılması mümkündür.

• To-Do

Farklı paydaşlar arasında bir tartışma yoluyla, önümüzdeki birkaç hafta içinde ele alınacak kullanıcı hikayelerine karar verilir ve sprint planlaması yapılır. Bu kullanıcı hikayelerini yapılacaklar olarak sınıflandırılır. Bu durumda henüz ayrıntılı bir tartışma yapılmamıştır.

• Discussing

Bir kullanıcı hikayesi Tartışma durumundayken, son kullanıcı, gereksinimleri onaylamanın yanı sıra kabul kriterlerini tanımlamak için geliştirme ekibiyle iletişime geçecektir. Geliştirme ekibi, gereksinimleri veya kararları konuşma notları olarak yazacaktır. UX uzmanı, kullanıcının önerilen özellikleri görsel modellerde önizlemesini ve hissetmesini sağlamak için tel kafesler veya hikaye tahtaları oluşturabilir. Bu süreç, kullanıcı deneyimi tasarımı (UX tasarımı) olarak bilinir.

• Developing

Gereksinimler netleştirildikten sonra, geliştirme ekibi, kullanıcıların isteklerini yerine getirmek için özellikleri tasarlayacak ve uygulayacaktır.

• Confirming

Geliştirme ekibinin bir kullanıcı hikayesini uygulamaya koyması üzerine, kullanıcı hikayesi son kullanıcı tarafından onaylanacaktır. Özelliği onaylaması için test ortamına veya yarı eksiksiz bir yazılım ürününe erişimi sağlanacaktır. Onay, kullanıcı hikayesi detaylandırılırken yazılan onay maddelerine göre yapılacaktır. Onay tamamlanana kadar kullanıcı hikayesinin Onaylama durumunda olduğu söylenir.

• Finished

Son olarak, özelliğin yapılacağı onaylanır, kullanıcı hikayesi Bitmiş durumda kabul edilir. Tipik olarak bu, kullanıcı hikayesinin sonudur. Kullanıcının yeni bir gereksinimi varsa, ya yeni bir özellikle ilgiliyse ya da bitmiş kullanıcı öyküsünün bir geliştirmesi ise, ekip bir sonraki yineleme için yeni bir kullanıcı öyküsü oluşturacaktır.

User Story yazarken nelere dikkat edilmelidir?

• Hikayeleri belirlemek için, her bir kullanıcının amaçlarını belirleyerek başlanmalıdır.

• Bir hikayeyi bölerken uygulamanın tüm katmanları ile ilişkisini kesmesine dikkat edilmelidir.

• Kısıtları belirleyin ve bunları not edin. Kısıtların ihlal edilmediği testler sırasında kontrol edilmelidir.

• Kullanıcı arayüzü ile ilgili detaylara mümkün olduğunca hikayelerde yer vermeyin.

• Hikayeyi yazarken mümkünse kullanıcı rolünü hikayeye dahil edin.

• Hikayeleri tek bir kullanıcı için yazın. Örneğin “Kullanıcılar kişisel bilgilerini girebilmelidir” yerine “Kullanıcı kişisel bilgilerini girebilmelidir.”

• Hikayeleri müşterinin yazması sağlanmalıdır.

• Hikayeler kısa tutulmalıdır, detayların sonradan gerçekleştirilecek görüşmeler aşamasında tartışılacağı unutulmamalıdır.

• Hikayeler numaralandırılmamalıdır.

İyi bir Story için yapılabilecekler

İyi bir kullanıcı hikayesi oluşturmak için 6 adet kriter vardır. Bunlar  INVEST olarak adlandırılmıştır.

1. Independent (bağımsız) : Mümkün olduğunca, hikayeler arasında bağımlılıklardan kaçınmak için özen gösterilmelidir. Böylece hikayelerin önceliklerine göre yapılabilmesi, sağlanabilir, yüksek öncelikli bir hikaye için düşük öncelikli hikayelerin tamamlanması beklenmez. Eğer birbirleri ile bağımlı hikayeler oluşuyor ise bu hikayeler birleştirilerek bağımsız bir hikaye oluşturulabilir, yada farklı bir yöntem ile bölünmeleri gerekmektedir.

2. Negotiable : (tartışılabilir) Üzerinde tartışılabilir olmalıdır, böylece detaylandırılabilir. Hikayeler kısa açıklamalardır. Ayrıntılar müşteri ile geliştirme ekibi arasındaki bir görüşmede müzakere edilerek netleştirilir. Çünkü hikayeler tüm detayları içermez, sadece detayları konuşabilmek için hatırlatıcı olarak görev alırlar. Fakat hikayenin oluşturulması sırasında bilinen detaylar not olarak yazılabilir.

3. Valuable: (değerli) Müşteriye bir değer sağlar.

4. Estimatable: (tahmin edilebilir) Yazılımcı tarafından ne kadar efor gerektireceği tahmin edilebilmelidir. Çok büyük veya anlaşılmaz olursa efor tahmini yapılamaz. Burada yazılımcının hikayenin tüm detaylarını anlamasına gerek yoktur. Genel olarak anlaması yeterlidir.

5. Small: (küçük) Hikayelerin uzunlukları planlama için önem arz etmektedir. Bu nedenle küçük olmaları planlanmasını kolaylaştıracaktır. Bir haftadan daha kısa sürede takım tarafından gerçekleştirilebilir olması önemlidir.

6. Testable: (test edilebilir) Hikayeler mümkün olduğunca test edilebilecek şekilde yazılmalıdır. Bir geliştirmenin doğru şekilde tamamlandığını testinin başarı ile yapılmasıyla anlayabiliriz. Bu nedenle test edilebilir hikayeler oluşturmak hikayelerin tamamlandığını takip edebilmek için önemlidir. Mümkün ise hikaye oluşturulurken test senaryoları not edilerek test edilmesi kolaylaştırılabilir.

Neden User Story?

Hikayeleri kullanmanın aşağıdaki gibi avantajları mevcuttur.

• Yazılı iletişimden çok sözlü iletişimi vurgular.

• Hem müşteri hem de geliştiriciler tarafından anlaşılır.

• Planlama için doğru boyuttadır.

• Yinelemeli geliştirme için uygundur..

• Kullanıcı hikayeleri, gerçekte neye ihtiyacınız olduğunu en iyi şekilde anlayana kadar ayrıntıların ertelenmesini teşvik eder.

Kaynakça

• https://sherpa.blog/makale/use-case-mi-user-story-mi
• User Stories Applied: For Agile Software Development (Mike Cohn)
• http://www.agilemodeling.com/artifacts/userStory.htm
• https://www.visual-paradigm.com/guide/agile-software-development/what-is-user-story/#:~:text=A%20user%20story%20is%20a,simplified%20description%20of%20a%20requirement.
• https://www.agile-scrum.be/whats-great-scrum-methodology/user-stories-important-agile/