Kullanıcı Hikayesi Yazım Teknikleri
Merhaba,
İlk medium yazımı çok değerli bulduğum bir konu üzerinden yayınlamış bulunuyorum :) Elimizde bir proje var ama bunu nasıl iş parçalarına bölmeliyiz, bu parçaları nasıl tanımlamalıyız ki ekip ve paydaşlar aynı şeyi anlayabilsin, yol haritamız daha somut veriler ile ortada olsun dediğiniz bir noktada iseniz şuan doğru yerdesiniz :) Keyifli okumalar dilerim :)
Ürün İş Listesi (Product Backlog) Nedir ?
Ürünün geliştirilmesi gereken tüm özellikleri, işlevleri, gereksinimleri ve düzenlemeleri içeren bir listedir. Bu liste içerisinde yer alan her bir ögenin(Product Backlog Item) herkesin aynı şeyi anlayacağı dilde ve kapsamda yazılmış olması gerekir. Bu tanımlamalar için Agile’ da genellikle kullanıcı hikayeleri(User Story) kullanılır.
Kullanıcı Hikayesi (User Story) Nedir ?
Agile metodolojisinde iş listesinin daha verimli yazılabilmesi için kullanılan kullanıcı hikayesi tekniği genelde bir sistem kullanıcısının perspektifinden; kullanıcının türünü, ne istediğini ve neden istediğini açıklar. Kullanıcı hikayeleri ürün parçası hakkında fazla detay içermeden yol gösterici şekilde ve herkesin aynı şeyi anlayacağı günlük bir dilde yazılmalıdır. Üzerinde çalıştıkça hatta geliştirme aşamasında bile detaylandırılabilir. Bu parçalar değişime adapte olabilmelidir.
INVEST
Bu teknik görüşe göre kaliteli bir ürün iş listesindeki maddeler hazırlanırken aşağıdaki 6 kritere dikkat edilmelidir.
Independent (Bağımsız) : Bağımlılığı olan kullanıcı hikayeleri planlamada ve öncelik belirlemede sorun yaşatabilir.
Negotiable (Tartışılabilir) : Kullanıcı hikayelerinin detayları ve Kabul kriterleri müşteri ile geliştiriciler arasında tartışılabilir olmalıdır.
Value (Değerli) : Kullanıcı hikayesi sonucunda ürünü kullanacak son kullanıcılar için bir değer üretilmiş olmalıdır.
Estimable (Tahminlenebilir) : Geliştiricilerin bir kullanıcı hikayesinin geliştirilmesi için harcanabilecek zamanı ve hikayenin büyüklüğü tahmin edebilir olmalıdır.
Small (Küçük) : Bir kullanıcı hikayesi en fazla bir iterasyon içerisinde tamamlanabilecek kadar büyük olmalıdır.
Testable (Test edilebilir) : Bir kullanıcı hikayesi test edilebilir bir parça olmalıdır. Testlerden geçen hikayenin başarılı geliştirildiği ve tamamlandığı kabul edilir. Test edilebilir bir hikaye için Kabul Kriterleri(Acceptance Criteria) ve Bitti Tanımı(Definition of Done) önemlidir.
DEEP
Bu teknik görüşe göre kaliteli bir ürün iş listesindeki maddeler hazırlanırken aşağıdaki 4 kritere dikkat edilmelidir.
Detailed Appropriately (Yeteri Kadar Detaylandırılmış) : Bir kullanıcı hikayesi geliştiricilerin ölçümleyebilmesi ve planlayabilmesine yeterli olabilecek kadar detaylı olmalıdır.
Estimated (Büyüklüğü Tahminlenmiş) : Bir kullanıcı hikayesi karmaşıklık, risk vs gibi durumlar da göz önüne alınarak geliştiriciler tarafından büyüklüğü tahmin edilebilir olmalıdır. Kullanıcı hikayesinin detayları hakkında daha fazl bilgi edindikçe yeniden tahminlemeler yapılmalıdır. Büyüklük tahminleri için Story Point veya Planning Poker gibi puan verme teknikleri kullanılabilir.
Emergent (Değişime Adapte Olabilen) : Ürün iş listesi sabit değildir, aksine sürekli değişim halindedir. Proje ilerledikçe daha fazla bilgi ve birikim elde edilir. Ürün iş listesindeki kullanıcı hikayelerine yeni eklemeler, çıkarmalar ve hikayelerde güncellemeler yapılabilmelidir.
Prioritized (Önceliklendirilmiş) : Ürün iş listesi en değerli öğeler üstte, en az değerli öğeler altta olacak şekilde sıralanmalıdır. Böylece geliştiriciler öncelik sırasına göre çalışıp ürün veya sistemin değerini en üstte çıkarabilir.
SMART
Bu teknik görüşe göre kaliteli bir ürün iş listesindeki maddeler hazırlanırken aşağıdaki 5 kritere dikkat edilmelidir.
Specific (Bir Türe Özgü) : Bir kullanıcı hikayesinde görev veya hedefin ne olduğu konusunda herkes aynı şekilde anlamalıdır. Görev veya hedef tanımlamasında genelleme yapılmamlıdır. Mümkün olduğunca bu hikayeye özgü tanımlamalar yapılmalıdır.
Measurable (Ölçümlenebilir) : İlerlemeyi izlemek, hedeflere ulaşmanın anahtarıdır. Bu nedenle bir kullanıcı hikayesi somut ve sayısal metriklerle ölçümlenebilir olmalıdır.
Achievable (Ulaşılabilir) : Belirlenen hedefler gerçekçi ve ulaşılabilir olmalıdır. Ulaşılması zor hedefler ekipler için motivasyon kaybına sebep olabilmektedir.
Relevant (Uygun) : Bir kullanıcı hikayesindeki hedef asıl hedefe hizmet etmeye uygun olmalıdır.
Time Bound (Zaman Sınırı) : Her hedefin bir son teslime ihtiyacı vardır. Süre belirlerken gerçekçi olmak önemlidir.
3C
Bu teknik görüşe göre kaliteli bir ürün iş listesindeki maddeler hazırlanırken aşağıdaki 5 kritere dikkat edilmelidir.
Card (Kart) : Kullanıcı hikayeleri kısa ve öz olarak gereksinimi tanımlayacak şekilde kartlara yazılır. Kart, gereksinim ile ilgili tüm detayları içermez. Hangi rolün, hangi işlemi yaparak ne fayda sağlayacağı bilgilerini içermesi yeterlidir.
Conversation (Konuşma) : Bir kullanıcı hikayesinin gereksinimlerinin paydaşlar ile birlikte tartışılması, hikaye kartının detaylandırılması konuşmaları yapılır.Aynı zamanda bu konuşma herkes arasındaki iş birliğini teşvik eder.
Confirmation (Onaylama) : Bir kullanıcı hikayesinin doğru şekilde uygulandığını doğrulamak için kullanılan bir Kabul Kriteridir(Acceptance Criteria). Bu Kabul Kriterleri genelde ürün sahibi(Product Owner), geliştiriciler ve kullanıcılar arasındaki konuşmalar(Conversation) sırasında belirlenir.
Dilerim sizler için de faydalı bir içerik olmuştur :) Yeni içeriklerle, mutlu yarınlarda görüşmek dileği ile…
Herkese musmutlu yıllarrr…
