Kullanıcı hikayesi (user story) nedir?

XP projelerinde müşteri gereksinimlerinin yer aldığı kullanıcı hikayeleri oluşturulur. Bir kullanıcı hikayesi sistemin tipik bir özelliğini bir ya da iki cümle ile anlatan araçtır. Örneğin üye girişi olan bir sistemde, şöyle bir kullanıcı hikayesi düşünülebilir:

Kullanıcı isim ve şifreni kullanarak sisteme giriş yapar.

Kullanıcı hikayeleri hikaye kartlarına (story card) yazılır. Bu kartlar sürüm ve implementasyon planları yapılırken kullanılır. Her kullanıcı hikayesinin implementasyon zamanı programcılar tarafından tahmin edilir. Müşteri kullanıcı hikayelerine öncelik sırası vererek implementasyon sırasını tayin eder. Programcılar tarafından yapılan tahmin ve müşteri tarafından belirlenen öncelik sırası kullanıcı hikayesinin üzerinde yer aldığı hikaye kartlarına not edilir. Ayrıca müşteri tarafından oluşturulan akseptans (onay/kabul) testleri hikaye kartlarının arka bölümüne not edilir.

Bir kullanıcı hikayesinin büyüklüğü ne kadar olmalı?

Bu sorudaki büyüklük sıfatı ile kullanıcı hikayesinin kaç günde implemente edilebilir olduğu kastedilmektedir. Programcılar tarafından kullanıcı hikayelerin implementasyon süreleri gün bazında tahmin edilir. Bir kullanıcı hikayesinin en fazla dört yada beş günde implemente edilebilir yapıda olması gerekmektedir. Daha fazla zaman gerektiren kullanıcı hikayelerinin müşteri tarafından bölünerek, küçültülmeleri gerekmektedir.

Kullanıcı hikayelerini kim oluşturur?

Kullanıcı hikayelerini müşteri oluşturur, çünkü gereksinimleri en iyi bilen müşteridir.

XP projelerinde müşterin programcılarla beraber çalışması talep edilir. Müşteri kendi işini bırakıp, nasıl proje için çalışabilir? Başka işi yok mu?

Bu genelde müşterinin kendi işini gücünü bırakıp, projede başka işlerle uğraşması gerektiği şeklinde değerlendirilir, ama durum öyle değildir. Müşterinin programcılara yakın bir yerde olması, programcıların oluşan sorulara kısa sürede müşteri yardımıyla cevap bulmalarını kolaylaştırır. Asıl maksatta budur zaten. Müşteri gün boyunca programcıların sorularına cevap verir. Bunun yanı sıra kendi günlük işlerini takip eder. Çoğu zaman günlük işleri yapabilmek için bir bilgisayar yeterli olacaktır. Müşteri kendi işlerini yaparken ara sıra programcılara zaman ayırarak, soruları cevaplar.

Birden fazla müşteri varsa, hangisinin sözü geçerlidir?

Proje ekibinin karşısında sadece bir müşteri olmalıdır. Eğer birden fazla müşteri varsa, bu şahıslar bir araya gelerek, tek bir şahıs gibi programcı ekibi ile iletişim kurmalıdırlar.

Sürüm planını kim oluşturur?

Sürüm planı müşteri ve programcılar tarafından ortaklaşa oluşturulur. Ne ve hangi sıraya göre yapılması gerektiği müşteri tarafından belirlenir. Bu yüzden sürüm planının oluşumunda müşterinin ağırlığı daha fazladır. Planlama için zaman tahminleri programcılar tarafından yapılır. Bu şekilde programcılar proje planlama sürecine aktif olarak katılarak sorumluluk alırlar.

Sürüm planını ne oranda sabittir?

Proje başında oluşturulan sürüm planı projenin çeşitli safhalarında değişikliğe uğrayabilir. Bu doğaldır. Müşteri yazılım sisteminin ilk sürümleriyle gereksinimlerinin ne olduğunu daha iyi anlayabilir ve mevcut kullanıcı hikayeleri üzerinde değişilik yapılmasını talep edebilir ya da yeni kullanıcı hikayeleri oluşturabilir. Bu durumda sürüm planının değiştirilmesi gerekmektedir.

Sürüm ve iterasyon arasındaki fark nedir?

Sürüm yazılım sisteminin belirli bir versiyondaki halidir. Her yeni sürüm yeni özelliklerin implemente edildiği ve müşteri tarafından produktif kullanılan program versiyonudur. XP projelerinde her yeni sürüm bir ile dört ay süren bir çalışma sonunda oluşturulur. Müşteri tarafından seçilen kullanıcı hikayeleri belirli bir zamansal uzunluğa sahip olan iterasyonlarda implemente edilir. İterasyonlar bir ile dört haftalık zaman birimini kapsarlar.

Bir önceki resimde yer alan sürüm beş iterasyondan oluşmaktadır. Her iterasyon iki hafta sürmektedir. Sürüm onuncu haftanın sonunda oluşturulmaktadır.

Hangi kullanıcı hikayesiyle işe başlanır?

Bu sorunun cevabını sürüm ve iterasyon planı verir. Sürüm ve iterasyon planlarında müşteri tarafından belirlenen kullanıcı  hikayeleri yer alır. Müşteri, kullanıcı hikayeleri için sahip oldukları değere göre öncelik sırası belirler. Sürüm ve iterasyon planlarında kullanıcı  hikayeleri bu öncelik sırasına göre yer alırlar. Programcılar her iterasyonda, o iterasyon için seçilmiş olan kullanıcı hikayelerini öncelik sırası yüksekten düşüğe doğru implemente ederler. Buradaki ana amaç, müşteri için en değerli özelliklerin yer aldığı bir sürümü oluşturarak, müşteri tarafından kullanılabilir hale getirmektir. Bu yüzden her zaman müşteri açısından en değerli olan sistem özellikleri öncelikli olarak implemente edilir.

Kullanıcı hikayesi implementasyonu ne zaman tamamlanmıştır?

Programcılar bir kullanıcı hikayesini test güdümlü implemente ederler. Testler tamamlandıktan sonra akseptans testleri yapılmak üzere kullanıcı hikayesinin yer aldığı hikaye kartı (story card) testçiye (tester) devredilir. Testçi müşteri tarafından tanımlanmış olan akseptans (onay/kabul) testlerini implemente eder. Akseptans testlerini geçen bir implementasyon bitmiş olarak kabul edilir.

Mevcut projeler üzerinde XP uygulanabilir mi?

Bu büyük ölçüde projedeki JUnit testleri oluşturma alışkanlığına bağlı. XP test güdümlü implementasyonu şart koşmaktadır. Eğer programcılar tarafından programlara paralel olarak testler geliştiriliyorsa, test güdümlü implementasyona geçmeleri zor olmayacaktır. Bunun yanı sıra projedeki mevcut iletişim kültürü önemlidir. XP çok yönlü iletişimi gerekli kılmaktadır. Örneğin pair programming gibi tamamen iletişim ve takım işine bağımlı olan bir metot programcılar tarafından ne oranda uygulanabilir, bunun araştırılması gerekmektedir.

Sürekli entegrasyon, test güdümlü yazılım, müşterinin projeye dahil edilmesi, kısa sürelerde yeni sürüm oluşturulması gibi konular XP’yi yeni başlamayan projeler için zor adapte edilebilir kılmaktadırlar. XP’nin yeni projelerde adaptasyonu çok daha kolaydır.

Bir iterasyon süresi ne kadar olmalı?

Bu yazılım sisteminin sahip olması gereken özelliklerle doğru orantılıdır. Eğer iki ay içinde ilk sürüm oluşturulması planlanıyorsa, iterasyon süresi bir ile iki hafta olacak şekilde seçilebilir. Bunun yanı sıra müşteri tarafından oluşturulan kullanıcı hikayelerinin implementasyonu için programcılar tarafından verilen tahminlerin dikkate alınması gerekmektedir. Örneğin programcılar tarafından ortalama her kullanıcı hikayesi için bir ile iki gün tahmin edilmişse,  bir haftalık iterasyonda en az üç en çok beş kullanıcı hikayesi implemente edilebilir. Eğer kullanıcı hikayeleri ortalama dört veya üzeri günde implemente edilebilir durumda ise, o zaman interasyonun en az iki hafta olarak seçilmesi gerekmektedir. İterasyon süresi sabittir ve uzatılamaz, bu yüzden seçilen kullanıcı hikayelerinin seçilen sürede implemente edilebilir yapıda olmaları gerekmektedir.

Akseptans (okay/kabul) testlerini kim oluşturur?

Akseptans testleri kullanıcı hikayesini oluşturan müşteri tarafından tanımlanır. Akseptans testlerinin implementasyonunu programcılar yada testçiler üstlenir.

Kaç tane JUnit testi hazırlanmalı?

Produktif olarak kullanılan her sınıf için bir JUnit testi sınıfı oluşturulması gerekmektedir. Bu sınıf bünyesinde birden fazla test metodu yer alır. Produktif sınıfta bulunan her metodun test edilmesi gerekmektedir. Çoğu zaman oluşturulan test sınıfının büyüklüğü test edilen sınıfın 2-3 katı büyüklüğe sahiptir. Bu test adedi hakkında bir fikir sahibi olmanızı kolaylaştırır.

Kod paylaşımı nasıl yapılır?

Kod paylaşımını kolaylaştırmak için bir versiyon kontrol sisteminin kullanılması şarttır. Subversion son zamanlarda kullanılan en popüler açık kaynaklı versiyon kontrol sistemi haline gelmiştir.

Kurumsal Java Akademisi Subversion eğitimi »

Pair programming yaparken tecrübeli bir programcı ile tecrübesiz bir programcının beraber çalışması zaman ve kaynak kaybı değil midir?

Hayır! Pair programming tekniği ile programcıların teknik anlamda ayni seviyeye gelmeleri sağlanır. Tecrübeli programcılar can, tecrübesiz programcılar patlıcan değildir :) Tecrübesiz programcılar için seminer düzenlemek yerine, onlara pair programming seanslarında teknoloji ve proje hakkında bilgi transfer etmek daha mantıklıdır.

Pair programming iki programcının bir kişilik iş çıkarması anlamına gelmez mi?

Pair programming maliyetli bir yöntemdir. Lakin iki programcının beraber aynı implementasyon üzerinde çalışmasından sinerjiler doğar. Pair programming iş kalitesini yükseltir. Ayrıca pair programming ile kodun ve tasarımın iki değil dört göz ile kontrol edilmesini sağlanır.

XP projelerinde mimariyi ve tasarım nasıl oluşur?

Mimari (altyapı) proje öncesinde yapılan keşif safhasında (Exploration Phase) oluşur. Programcılar müşteri tarafından oluşturulan kullanıcı hikayelerini okudukça, neye ihtiyaç duyduklarını anlarlar ve ona göre altyapıyı geliştirirler.

Proje öncesi detaylı tasarım oluşturulmaz. Tasarım test güdümlü implementasyon esnasında programcılar tarafından oluşturulur. Eğer programcılar implementasyon esnasında sorunlarla karşılaşırlarsa, refactoring yöntemleri kullanarak tasarım üzerinde değişiklik yaparlar. Unit testleri refactoring işleminin yapılmasını kolaylaştırır. Yapılması gereken değişiklikler sonraya bırakılmaz, çünkü bu ilerde maliyetin yükselmesine sebep olabilir.

XP projelerinde mimariyi ve tasarımı kim oluşturur?

Programcılar.

Bilgi bankası olan bir sistemde test güdümlü yazılım nasıl uygulanır?

Bunun çeşitli yöntemleri vardır. Öncelikle bilgi bankası işlemlerinin DAO (Dao Access Object) tasarım şablonu kullanılarak bir interface sınıf arkasında saklanması en mantıklı çözümdür. Mock sınıflar kullanılarak DAO katmanı simule edilebilir. Bu sistemin diğer bölümlerinin test güdümlü implementasyonunu kolaylaştırır. DAO kullanıldığı taktirde, gerçek bilgi bankasına olan bağımlılık azaltılır. DAO interface sınıfını değişik türde implemente ederek, bilgi bankası yerine başka bir yapıda kullanılabilir.

Hibernate ve IBatis gibi bir framework kullanılması durumunda, test güdümlü yazılımı mümkün kılabilmek için bu frameworklerin sunduğu interface sınıflar (SessionFactory, Session vs.) mock nesneler ile simüle edilebilir.

Planlama pokeri nedir?

Programcı bir kullanıcı hikayesini implementasyon öncesi tüm detaylarıyla bilmek zorunda değildir. Bir kullanıcı hikayesini en son detayına kadar kavramaya çalışmak zaman kaybı olabilir, çünkü kullanıcı hikayesinde yeralan müşteri gereksinimi değişikliğe uğrayabilir. Bu genelde müşterinin programın ilk sürümlerini görmesiyle gerçekleşir. Çalışır bir program aracılığıyla müşteri gereksinimlerini daha iyi kavrayacak ve gerekli değişiklikleri talep edecektir. Bu sebepten dolayı implementasyona başlamadan önce kullanıcı hikayesinin ihtiva ettiği tüm detayları tespit etmek faydalı olmayacaktır, çünkü kullanıcı  hikayesi değişikliğe ugrayabilir. Programcı ekibin kullanıcı hikayesi hakkında implementasyon için gerekli zamani tahmin edebilecek kadar bilgiye sahip olması yeterli olacaktır.

Programcılar müşteri tarafından seçilen kullanıcı hikayesinin implementasyon süresini tahmin ederler. Bu tahminler planlama pokerinde yapılır.

Planlama pokeri yapılmayan tahminler bazen sağlıklı sonuçlar vermeyebilir. Bir programcı tarafından yapılan tahmin diger programcıları etkiliyebilir. Yada bazı programcılar herhangi bir sebepten dolayı tahmin etme sürecine aktif olarak dahil olmayabilirler. Bu gibi sebeplerden dolayı oluşan tahmin süreleri yanıltıcı olabilir. Daha geçerli tahminler elde edebilmek için planlama pokeri oynanır.

Planlama pokeri için kullanılan kartlar bir önceki resimde yer almaktadır. Her programcı bu kartların bir setine sahiptir. Planlama pokeri şu şekilde oynanır: Bir moderator ilk kullanıcı hikayesini okur. Müşteri bu kullanıcı hikayesi için implementasyon süresinin ne olduğunu sorar. Programcılar kısa bir zaman düşündükten sonra hep beraber planlama poker kartlarından birisini seçerek gösterirler. Çoğu zaman kullanılan kartlardakı değerler farklı olacaktır. En çok süreyi ve en az süreyi tahmin eden programcılardan bu sonuca nasıl vardıklarının açıklanması istenir. Verilen bilgiler dogrultusunda ortak bir değer bulunur.

Tahminler için hikaye puanları (story points) kullanılır. 1 hikaye puanı örneğin 1 iş günü (8 saat) olabilir. Programcılar her kullanıcı hikayesini kendi başına tahmin etmek yerine, kullanıcı hikayelerini birbirleriyle kıyaslıyarak tahminde bulunurlar. Örneğin kullanıcı hikayesi A için 2 hikaye puanı tahmin edilmişse, kullanıcı hikayesi B bu değer göz önünde bulundurularak tahmin verilir. Eğer kullanıcı hikayesi B A dan üç katı daha büyükse, o zaman B için tahmin 2×3 = 6 hikaye puanı olarak verilir.

Load Factor nedir?

Bir kullanıcı hikayesinin ideal şartlarda implementasyonu için gerekli zaman dilimi ile normal şartlarda implementasyonu için gerekli zaman dilimi farklı olacaktır. Örneğin programcılar gün boyunca yazılım haricinde toplantı, bilgi alışverişi gibi işler için zaman ayırmak zorundadir. Bir programcının sekiz saatlik bir iş gününde sekiz saat program yazabilmesi ideal zaman dilimi olarak tanımlanır. Toplantı ve diğer işler için kullanılan zaman ideal zaman diliminde çikartıldığı zaman normal zaman dilimi elde edilir. Kullanıcı hikayelerinin tahminlerinde ideal ve normal zaman dilimlerinin göz önünde bulundurulması gerekmektedir, aksi taktirde kullanıcı hikayesi için yapılan tahmin gercekleri yansıtmıyacaktır. Gerçekci bir tahmin yapabilmek için load factor olarak bilinen değer kullanılır. Bu değer bir kullanıcı hikayesinin implementasyonu için kullanılan zamanın ideal zamana bölünmesiyle elde edilir. Örneğin bir kullanıcı hikayesi için 1 iş günü (8 saat) tahmin edilmiş ve programcı kullanıcı hikayesini 2 iş gününde tamamlamış olsun. Bu durumda load factor 16 / 8 = 2  olacaktır. Load factor için 2 ila 5 arasında bir değer normaldir. Tahmin yapılırken tahmin edilen implementasyon zamanı load factor ile çarpılır. Örneğin programcı bir kullanıcı hikayesini 2 iş gününde implemente edebileceğini düşünüyorsa, kullanıcı hikayesi için tahmin süresi 2 değil, 2 iş günü x 2 load factor = 4 olmalıdır. Bu şekilde daha gerçekci tahmin elde edilir.

Programcılar load factor değerini göz önünde bulundurarak, tahminde bulunurlar.

Spike solution nedir?

Eğer programcılar bir kullanıcı hikayesi için tahminde bulunamazlarsa küçük çaplı bir demo implementasyonu yaparak implementasyon süresini tahmin etmeye çalışırlar. XP dilinde bu işe spike solution ismi verilir. İdeal şartlarda bu işlemin sürüm planlama oyunundan önce yapılmış olması gerekir. Buradan sürüm planlama oyunu için kullanıcı hikayelerinin oyun öncesi hazırlanmış olması gerektiği sonucunu çikartabiliriz.

Programcılar yaptıkları denemeler sonunda kullanıcı hikayesi için tahmin verebilecek duruma gelirler.
 

Özcan Acar

Extreme Programming ve Scrum gibi çevik süreçlerin popüler olmasının sebebi, müşteri gereksinimlerini tatmin edebilen yazılım sistemlerinin oluşturulma sürecini kolaylastırmalarında yatmaktadır. Bu böyle olunca, yazılım firmaları, yıllarca şelala (Waterfall) metodundan çektikleri sıkıntılardan kurtulmak amacıyla çevik süreçlerin adaptasyonuna yönelmektedirler. Doğal olarak burada firmaların çevik sürecin adaptasyonu esnasında kafalarında oluşan bazı sorular var. Bunlardan en önemli iki soru şöyle: Okumaya devam et →