Story Mapping ve Story Bölme: Walking Skeleton, Dikey Dilimler ve İlk Release'i Seçmek

Sürüm notu: Bu yazı kavramsaldır; story mapping için Jeff Patton'ın "The New User Story Backlog is a Map" (2008) yazısı ve "User Story Mapping" (2014) kitabı, walking skeleton için Alistair Cockburn'ün tarifi esas alınmıştır.

Önce Tahmin Et

Önceki yazıda kurumsal sipariş use case'inden yedi story çıkardık. Selin bunları, elicitation'dan kalan birkaç fikirle birlikte, sıralı bir backlog'a koydu: on üç satır, en önemlisi en üstte. Takvim belli: 1 Eylül'e üç sprint var.

Emre ile Ayşe bir plan öneriyor: "Birinci sprint'te bütün tabloları ve entity'leri kuralım, ikinci sprint'te API endpoint'lerini, üçüncüde Angular ekranlarını. Böylece her katmanı bir kerede, düzgün yaparız."

İki soru. Birinci sprint'in sonunda Nevin Hanım'a ne gösterebilirsin? Üçüncü sprint'in ortasında ERP (kurumsal kaynak planlama sistemi) entegrasyonunun beklenenden iki kat uzun sürdüğü ortaya çıkarsa 1 Eylül'de elinde ne olur?

Düz Backlog'un Sorunu

Sıralı bir backlog tek bir soruya iyi cevap verir: bir sonraki iş ne? Ama başka bir soruya hiç cevap vermez: bu sistem bütün olarak ne yapıyor ve neyi unuttuk? Jeff Patton 2008'deki yazısında bu sorunu, sırayla dizilmiş story'lerin bağlamını kaybetmesi olarak anlatır. On üç satırlık listeye bakan biri, satın alma sorumlusunun yolculuğunu göremez; story'lerin hangisinin hangi adıma ait olduğu, hangi adımın hiç story'si olmadığı listede görünmez.

Bookstore'un listesi bunun iyi bir örneği. Use case "satın alma sorumlusu kurum hesabıyla yeni bir sipariş başlatır" diye başlıyordu; kurum hesabının nasıl açılacağı hiçbir story'de yoktu. Fatura ERP'ye aktarılacaktı ama aktarımı kimin, nasıl yapacağı da yoktu. Liste sıralıydı, ama eksikti, ve sıralı olması bu eksikliği gizliyordu.

Story Map'in Anatomisi

Story map aynı story'leri iki boyutlu bir yüzeye dizer. Yatay eksen, kullanıcının işi baştan sona nasıl yaptığının anlatısıdır: soldan sağa okunduğunda bir hikâye anlatır. En üst satırda kullanıcı aktiviteleri durur; Patton bu satıra backbone (omurga) der. Aktiviteler bir story'ye sığmayacak kadar büyük işlerdir: "kitap listesini oluşturmak" gibi. Her aktivitenin altında onu oluşturan adımlar ve o adımları gerçekleştiren story'ler yer alır.

Dikey eksen önceliktir: bir aktivitenin altında yukarıda duran story daha önemli, aşağıdaki daha az önemlidir. Patton'ın vurguladığı ince bir nokta var: backbone'daki aktiviteler kendi aralarında önceliklendirilmez, çünkü sistemin çalışması için hepsi gerekir. Önceliklendirilen, onların altındaki story'lerdir.

Bookstore ekibi map'i bir workshop'ta, duvarda kuruyor. Backbone'u yazmanın en iyi yolu, önceki yazılardaki görüşmede Nevin Hanım'ın anlattığı geçen eylül hikâyesini yeniden anlatmak: önce kurum hesabı, sonra liste, sonra kontrol, sonra onay ve gönderim, en sonda teslim ve ödeme. Beş aktivite çıkıyor. Ardından eldeki story'ler ilgili aktivitenin altına yapıştırılıyor ve boş kalan sütunlar hemen göze çarpıyor.

Kurumsal Siparişin Story Map'i

Map'in ilk faydası, Düz Backlog bölümündeki eksiklerin görünür olması. "Kurum hesabını hazırla" ve "Teslim al ve öde" sütunlarının altında use case'ten gelen hiçbir story yoktu. Ekip bu sütunlara yeni kartlar yazıyor: kurum hesabını kimin açacağı, faturanın ERP'ye nasıl gideceği. Bu kartlar olmadan 1 Eylül'de çalışan bir ekran olurdu, ama Bookstore tek bir kurumsal siparişi baştan sona işleyemezdi.

İkinci faydası, konuşmanın değişmesi. Düz listede "kısmi sevkiyat mı önce, teslimat noktaları mı?" tartışması iki kart arasında geçer. Map'te soru şuna döner: satın alma sorumlusu eylülde bu yolculuğu baştan sona yapabilecek mi, ve hangi adımda en çok zorlanacak? Görüşmelerden ve doküman analizinden gelen bilgi burada karar verdiriyor: 46 listenin 15'inde ISBN yoktu, bu yüzden "Kitap adıyla ara" ilk release'te; Nevin Hanım'ın okulunun üç kampüsü var, bu yüzden "Teslimat noktaları" da.

Walking Skeleton ve İlk Release

Walking skeleton, Alistair Cockburn'ün adını koyduğu, Patton'ın da story map'e taşıdığı bir fikir: sistemin ana parçalarını uçtan uca bağlayan, küçük bir işi baştan sona yapabilen en ince ilk sürüm. İskelet güzel olmak zorunda değil, ama yürüyebilmeli. Map'te bu, her aktivitenin altından en az bir kart alan, en üstteki yatay dilim demek.

Bookstore'un iskeleti şekildeki yeşil satır. Kurum hesabını müşteri hizmetlerinden Gül elle açıyor; satın alma sorumlusu ISBN ve adet listesini yapıştırıyor ve doğrulama sonucunu görüyor; toplam liste fiyatıyla hesaplanıyor; sipariş satın alma emri numarasıyla gönderiliyor; depo tek sevkiyat yapıyor ve fatura her sabah bir raporla ERP'ye elle giriliyor. Bu iskelet birinci sprint'in sonunda gerçek bir okulun gerçek siparişini, el yordamıyla da olsa, baştan sona işleyebilir.

İskeletin iki manuel adımı bilinçli bir seçim. Kurum hesabı açmak yılda birkaç düzine kez yapılan bir iş; ilk sürümde bir ekranını yazmak yerine Gül'e bırakmak, ekibin zamanını satın alma sorumlusunun her gün yaşadığı adımlara ayırıyor. ERP aktarımı ise ekibin hiç tanımadığı bir sistem; otomatik aktarım ikinci release'e kalıyor ve bu sırada iki günlük bir spike ile ERP'nin API'si deneniyor.

Release 1'in kapsamı ise iskelet artı pembe satır. Bu satırı seçerken ekip öncelik tartışmasını görüşlerle değil, ilk yazıdaki business requirement'la yapıyor: eylülde müşteri hizmetlerinin elle sipariş girme emeğini yarıya indirmek ve yanlış kitap gönderimini sıfıra yaklaştırmak. Kitap adıyla arama ve kurumsal indirim olmadan okulların bir kısmı yine e-postayla sipariş verir ve Gül yine elle girer. Taslak kaydetme prototip testinin bulgusu. Kısmi sevkiyat seçimi ise eylülde stok sıkışıklığının kaçınılmaz olmasından geliyor.

Onay limiti akışı ise ikinci release'e iniyor. Nevin Hanım'a sorulan açık sorunun cevabı belirleyici oldu: okul içi onay ilk yıl e-postayla yapılabilir. Ekip kaba bir tahminle ilk dilimin üç sprint'e sığdığını düşünüyor; sığmazsa pembe satırın en altındaki kart ikinci release'e inecek. Tahmin ve planlamanın kendisi Estimation ve Planning serisinin konusu.

Büyük Story'yi Bölmenin Yolları

Map'teki bazı kartlar bir sprint'e sığmayacak kadar büyük. Story bölmek için yaygın kaynaklar var; Richard Lawrence'ın Humanizing Work'te yayımladığı story bölme rehberi bunların en bilinenlerinden. Biz burada bir liste ezberlemek yerine, Bookstore'un kartlarını hangi eksenlerde böldüğüne bakalım. Hepsinin ortak testi aynı: bölündükten sonra her parça tek başına bir kullanıcıya değer veriyor mu?

Kuralın varyasyonlarına göre bölmek. "Kurumsal indirim" kartının arkasında birkaç kural var: tüm kurumlara tek bir oran, okul ve kütüphaneye farklı oranlar, adet arttıkça artan kademeli indirim. İlk parça tek oranla başlar ve eylülde okulların ihtiyacını karşılar; diğer kurallar ayrı story'ler olarak sonra gelir. Her parça indirimli bir toplam gösterir, yani her parça değer verir.

Verinin varyasyonlarına göre bölmek. Listeyi girme işinde veri biçimi değişiyor: tiresiz 13 haneli ISBN, tireli ya da eski 10 haneli ISBN, yalnızca kitap adı, bir Excel dosyası. İskelet ilk ikisini kabul ediyor, "Kitap adıyla ara" üçüncüsünü ekliyor, dosya yükleme ise "Sonra" satırında, belki hiç gelmeyecek; prototipte kimse dosya aramadı.

Mutlu yolu istisnalardan ayırmak. "Teslimat noktaları" kartının ilk parçası her satırı tek bir noktaya atamak; aynı kitabın adetlerini kampüsler arasında bölmek ikinci parça. İlk parça Nevin Hanım'ın ders kitaplarının çoğunu doğru kampüse götürür; ikinci parça kalan istisnayı çözer.

Akışın adımlarına göre, ama her adım değer verecek şekilde bölmek. Kütüphanenin fiyat teklifi süreci büyük bir kart. İlk parça yalnızca teklif belgesini üretmek: kütüphane bununla kendi iç onayını başlatabilir, bu tek başına bir değer. İkinci parça onaylanmış tekliften tek tıkla sipariş oluşturmak. Dikkat: "önce doğrulama adımı, sonra toplam adımı" gibi bir bölme bu teste uymaz, çünkü doğrulamanın tek başına kullanıcıya verdiği bir şey yok.

Önce manuel, sonra otomatik. İskeletteki kurum hesabı ve ERP aktarımı bu eksenin örnekleri. Bir adımın ilk sürümünü bir insanın elle yapması, story'yi küçültür ve uçtan uca akışı erken çalıştırır. Bedeli de açık yazılmalı: Gül'ün her sabah yarım saati ERP'ye fatura girmekle geçecek ve bu bedel otomatik aktarımın önceliğini belirleyecek.

Bilinmeyeni önce öğrenmek. ERP aktarımı tahmin edilemiyorsa önce zaman sınırlı bir spike yapılır: iki gün, ve çıktısı baştan tanımlı: "Bir test faturası ERP'nin test ortamına aktarıldı, aktarım süresi ve hata biçimleri not edildi." Spike'ın kendisi kullanıcıya değer vermez; değeri, arkasından gelen story'yi tahmin edilebilir ve bölünebilir kılmasıdır. Bu yüzden spike story'den ayrı tutulur ve süresi aşılırsa kapatılıp yeniden konuşulur.

Katman Katman Bölmek Neden Kötü?

Önce Tahmin Et'teki plana dönelim: önce tablolar, sonra API, sonra ekranlar. Bu planda ilk iki sprint'in sonunda kullanıcıya gösterilecek hiçbir şey yok. Nevin Hanım'dan geri bildirim almak ancak üçüncü sprint'te mümkün ve o zaman yanlış anlaşılan bir şeyi düzeltmek için zaman kalmıyor. Entegrasyon riski de en sona birikiyor: ERP aktarımının zor olduğu, iskelet yaklaşımında birinci sprint'te, katman planında üçüncü sprint'in ortasında ortaya çıkıyor.

Katman planı cazip çünkü ekibin uzmanlıklarıyla örtüşüyor ve her katmanı "bir kerede, düzgün" yapma hissi veriyor. Ama bir katmanı ihtiyacı görmeden bir kerede tasarlamak, genellikle sonradan değişecek bir tasarım demek: üçüncü sprint'te ekranlar yapılırken teslimat noktası bilgisinin satır seviyesinde değil sipariş seviyesinde tutulduğu fark edilirse, birinci sprint'in tabloları değişir.

Bill Wake de önceki yazıda kullandığımız 2003 tarihli yazısında Valuable niteliğini anlatırken aynı noktaya gelir: story bölünürken katmanların içinden dikey kesilmeli ki her parça müşteriye bir değer versin. Dikey dilim, her story'nin arayüzden veritabanına kadar ince bir parça geçmesi demek. "Kitap adıyla ara" story'si bir arama alanı, bir endpoint ve bir katalog sorgusu içerir; üçü birlikte teslim edilir.

Bu, Vertical Slice Architecture serisinin ilk yazısında anlattığımız fikrin backlog'daki karşılığı. O seride kodu katmanlara göre değil feature'a göre organize etmenin, bir değişikliğin dokunduğu dosyaları tek bir klasörde topladığını görmüştük. Backlog'u dikey dilimlerle böldüğünde kodu da dikey dilimlerle organize etmek doğal hâle gelir: bir story genellikle bir slice'a, bazen birkaçına dokunur. İkisi birbirinden bağımsız kararlar, ama birbirini güçlendirir.

Üretimde Dikkat

Story map bir kere çizilip arşive kaldırılan bir doküman değil. Her release'ten sonra map'e dön: biten kartları işaretle, release'in business requirement'a ne kadar yaklaştığını ölç (eylülde Gül'ün elle girdiği sipariş sayısı, yanlış gönderilen kitap sayısı) ve öğrendiklerine göre alttaki dilimleri yeniden diz. Ekim'de "Geçen yılın siparişini kopyala" kartının yukarı çıkması, eylülün verisine bağlı bir karar olmalı.

Map'i görünür tut. Fiziksel bir duvar ya da dijital bir whiteboard, ama ekibin ve Product Owner'ın her gün gördüğü bir yerde. Tracker'daki backlog sırası ile map'teki dilimler ayrışırsa, kaynak olarak hangisinin geçerli olduğuna ekipçe karar ver; iki doğru kaynak, hiç olmamasından kötüdür.

Map'in boyutunu yönet. Yüzlerce kartlık bir map kimsenin okuyamadığı bir duvar kâğıdına dönüşür. Bir epic için bir map yeterlidir; daha aşağıdaki ayrıntı, kartların kendisinde ve kabul koşullarında yaşar.

Sık Düşülen Tuzaklar

İlk tuzak, bölünmüş story'lerin tek başına değer üretmemesi. "Kurumsal sipariş: backend" ve "Kurumsal sipariş: frontend" diye ikiye ayrılmış bir story bölünmemiş, katmanlara kesilmiştir. Her parça için "bu bitince kim, neyi yapabilecek?" diye sor; cevap "henüz kimse" ise bölme yanlıştır.

İkinci tuzak map'i bir kez çizip bırakmak. İlk workshop'tan sonra duvarda kalan map, iki sprint sonra gerçeği göstermez: yeni kartlar tracker'a eklenir, map'e eklenmez ve map'in en değerli işlevi, eksikleri gösterme işi, kaybolur.

Üçüncüsü iskeleti şişirmek. "İskelete bir de kurumsal indirimi koyalım, nasılsa basit" diye başlayan konuşma, birinci sprint'in sonunda yürüyen bir iskelet yerine yarım kalmış bir release üretir. İskeletin işi her aktiviteden en ince kartı alıp uçtan uca çalışmayı kanıtlamaktır, kullanıcıyı memnun etmek değil.

Dördüncüsü iskeletten bir aktiviteyi atlamak. "Teslim al ve öde" sütunu boş bırakılan bir iskelet, ekranda sipariş alır ama faturası kesilemeyen siparişler üretir. İskeletin bütün backbone'u kapsaması, yürümesinin şartıdır.

Beşincisi süresiz spike. "ERP'yi araştır" diye açılan ve çıktısı tanımlı olmayan bir spike, bir sprint boyunca sürer ve sonunda "biraz daha araştırmak lazım" cümlesiyle kapanır. Süreyi ve çıktıyı spike'ı açarken yaz.

Küçük Bir Deneme

★☆☆ Üzerinde çalıştığın bir epic için backbone'u yaz: kullanıcının işi baştan sona yaparken geçtiği dört-altı aktivite. Mevcut story'leri bu aktivitelerin altına yerleştir ve altı boş kalan aktiviteyi bul.

★★☆ Aynı map üzerinde bir walking skeleton dilimi çiz: her aktiviteden en ince bir kart. Hangi adımları ilk sürümde elle yapmayı kabul edebileceğinizi ve bunun bedelinin ne olduğunu yaz.

★★★ Backlog'undaki en büyük story'yi bu yazıdaki eksenlerden en az ikisiyle böl. Her parça için "bu bitince kim, neyi yapabilecek?" sorusunu cevapla; cevabı olmayan parçayı bir diğeriyle birleştir.

İlk release'in story'leri belli, sınırları çizildi. Ama "Kurumsal indirim" ve "Kısmi sevkiyat seçimi" kartlarının arkasındaki kurallar hâlâ açık sorularla dolu: minimum 20 adet ne demek, indirim hangi durumda uygulanıyor, stok yetersizse tam olarak ne oluyor? Bir sonraki yazıda acceptance criteria'yı ve Example Mapping'i ele alıp bu kuralları somut örneklerle netleştireceğiz.