#ef7e12

Descartes, Product Owner Olursa

Cihan Demir // Çevik Takım Üyesi

Gelin beraber bir beyin jimnastiği yapalım. Sorumuz şu: Fransız matematikçi, filozof Rene Descartes, 17’nci yüzyılda değil günümüzde yaşasaydı ve Product Owner* olsaydı user story'leri** nasıl yazardı?

Bilmeyen ya da yeni duyanlar için user story'nin tanımını yaparak başlayayım: Kullanıcının, ürünü kullanırken gerçekleştirmeyi hedeflediği fonksiyonun kendi ağzından yazılmasına user story diyoruz. Yani hedeflenen şeyin nasıl yapılacağından ziyade kullanıcı ihtiyacını kendi penceresinden bakarak tanımlar.

En temelde bir user story şu sorulara cevap vermeye çalışır: “Kim”, “Ne” ve “Neden”.

Çok basit ve kısa olacak şekilde şöyle bir şablon hazırlayabiliriz: "<X kullanıcı> olarak, <Y aktivite> gerçekleştirmek istiyorum. Böylece <Z fayda> sağlayabilirim." Bu şablon sayesinde sırasıyla “Kim”, “Ne” ve “Neden” sorularına cevap verebiliriz.

Şablonumuzdan hareketle, user story’yi "Kasko poliçesi sahibi olarak, dolu yağışı beklenen durumda haberdar olmak istiyorum. Böylece aracımı hasardan koruyabilirim" olarak yazabiliriz. 

Peki böyle bir durumda Descartes'ın problem çözme yaklaşımı ile user story arasında nasıl bir bağ kurulabilir? Bize ışık tutabilecek özdeyişi karşımızda duruyor. Diyor ki Descartes, "Divide each difficulty into as many parts as is feasible and necessary to resolve it." Türkçesi, “Her zorluğu, onu çözebilmeyi mümkün kılacak kadar çok ve gerekli parçalara bölün.” Descartes bize, her bir zorluğu ya da problemi, mümkün mertebe parçalara bölerek ele almayı öneriyor.

Bir adım daha ilerleyelim: Descartes’ı dinlersek, parçalara bölme işlemini daha metodik nasıl yapabiliriz?

Bu noktada da INVEST kısaltması yardımımıza koşuyor ve iyi, kaliteli bir user story'nin yazılabilmesi için kılavuzluk ediyor:

Independent: Bağımsız olmalı. Diğer user story'lere bağlılığın olmaması, tamamlanabilmesini kolaylaştırır.

Negotiable: Üzerinde tartışılabilmeli. İyi bir sonuca varmak ve istenen ihtiyacı gerçekleştirerek değer yaratabilmek için takım üyeleri tarafından tartışmaya açık olmalıdır.

Valuable: Değer üretebilmeli. İstenen özellik ya da fonksiyon, tamamlandığında hem ürüne değer katmalı hem de kullanıcıya değer yaratabilmeli.

Estimable: Eforlanabilmeli. Önceliklendirilebilmesi için eforlanabilmesi gerekir. Ne kadar zamanda yapılabileceği tahmin edilemiyorsa parçalara bölerek netlik sağlanabilir.

Small: Küçük olmalı. İlgili sprint ya da iterasyon içerisinde bitebilmeli. Örneğin, 2 haftalık sprintler koşuluyorsa en fazla 3-4 günde bitmesi tahminlenebilmeli.

Testable: Test edilebilir olmalı. User story hayata geçirildiğinde "tamamlandı" statüsüne getirilebilmesi ve bittiğinin görülebilmesi için test edilebiliyor olmalı.

İyi ve kaliteli bir user story için şablonumuz (“Kim”, “Ne” ve “Neden”) ve çapraz kontrol yapabileceğimiz metodumuz (INVEST) artık elimizde. Takım olarak güne iyi bir daily’yle başladığınızda üzerinde konuşup tartışabileceğiniz mükemmel user story'leriniz olması dileğiyle.

Ufak bir not: Bu konu hakkında merak ettiklerini sormak için buraya tıklayarak bize ulaşabilirsin.

*: Product Owner: Ürün geliştirmeden sorumludur. Ürün iş listesinin (Product Backlog) yönetiminden sorumludur; listedeki kalemleri sıralar, önceliklendirir. Müşterinin sesidir.

**: User story: Sprint içerisinde her işin nasıl yapılacağının, son kullanıcı tarafından kullanılacak bir özelliğin, yine bu kullanıcı tarafından en basit ve anlaşılır şekilde açıklanmasıdır.

Comments

Resimli CAPTCHA
Resimde görünen karakterleri girin.