30 saniyelik özet
Dual-Track Discovery ve Delivery, ürün keşfiyle teslimatını bağlantılı çalışma akışları olarak ele alan yaklaşımdır. Discovery, yani keşif, hangi problem ve çözüm için yatırım yapılacağını araştırır. Delivery, yani teslimat, seçilen çözümü güvenilir ve kullanılabilir ürüne dönüştürür. Ekip bir ihtiyacı geliştirirken başka bir belirsizliği inceleyebilir. İki akış, iki ayrı takım kurulmasını gerektirmez. Önemli olan, araştırma bulgularının geliştirme kararlarını ve gerçek kullanımın sonraki araştırmaları beslemesidir. Keşif çalışmasının sonucu mutlaka yeni bir özellik değildir; kapsamı değiştirmek veya bir fikri bırakmak da anlamlı bir karar olabilir.
Neden önemli?
Bir ekibin iş listesi dolu olabilir, fakat maddelerin neden yapılacağı yeterince anlaşılmamış olabilir. Geliştirme başlar, kullanıcı ihtiyacı ve çözüm ayrıntıları uygulama sırasında yeniden tartışılır. Diğer uçta ise araştırma ekibi kapsamlı tasarımlar üretirken teknik sınırlar geç fark edilir. Her iki durumda da bilgi ile kararın zamanı uyuşmaz.
Bağlantılı akışlar bu sorunu ele almaya yardımcı olur. Önümüzdeki işin önemli varsayımları araştırılırken yeterli bilgiyle seçilmiş başka bir kapsam geliştirilebilir. Teknik inceleme gerektiğinde mühendisler keşfe katılır. Kullanıcı gözlemi mevcut kapsamı etkiliyorsa bulgu teslimat çalışmasına taşınır.
Product Owner, yani ürün sahibi, burada yalnızca iş maddesi hazırlamaz. Hangi bilinmeyenin karar için önemli olduğunu, mevcut kapsamın neden seçildiğini ve hangi bilgiyle yeniden değerlendirileceğini açıklamalıdır. Geliştiricilerin her zaman meşgul görünmesi amacıyla belirsiz fikirleri hazır ilan etmek, ilerleme görüntüsü üretirken yanlış yatırımı büyütebilir.
Yönetici açısından keşif ve teslimat aynı soruya cevap vermez. Teslimatta kullanılabilir kapsamın ilerleyişi önemlidir. Keşifte ise hangi varsayımın araştırıldığı ve sonuçta hangi kararın değiştiği görülmelidir. Araştırmayı yalnızca tamamlanan ekran veya kapanan iş sayısıyla değerlendirmek, öğrenmeyi görünmez bırakır.
Yaklaşım kapasiteyi de açık konuşmayı gerektirir. Aynı kişiler hem araştırmaya hem geliştirmeye katkı veriyorsa zamanları iki kez hesaplanmamalıdır. Kritik bir teslimat sorunu keşif katkısını azaltabilir. Bu durumda öğrenme ihtiyacının ertelendiği ve hangi kararın daha zayıf kanıtla verileceği görünür tutulmalıdır.
Terim nedir?
Marty Cagan, Dual-Track Agile yazısında keşif ve teslimatın paralel niteliğini vurgular. Ürün, tasarım ve mühendisliğin birlikte çalışmasını, bir rolün belge hazırlayıp sıradaki role devretmesinden ayırır. Keşif, çözüm fikrine ilişkin öğrenmeyi hızlandırırken teslimat yayımlanabilecek yazılım üretmeye odaklanır.
Cagan aynı yazıya eklediği güncellemede, sürece fazla odaklanılmasına yol açtığı için Dual-Track Agile terimini kullanmayı bıraktığını ve sürekli keşif ile sürekli teslimat ifadelerini tercih ettiğini belirtir. Bu ayrıntı önemlidir: Yaklaşımın değeri iki ayrı pano çizilmesinden değil, çalışma ilkelerinden gelir.
Yöntem kaynağı: Marty Cagan, Dual-Track Agile, Silicon Valley Product Group, 17 Eylül 2012 ve yazıdaki sonraki güncelleme.
Jeff Patton da Dual Track Development is not Duel Track yazısında iki akışın iki takım olarak yorumlanmaması gerektiğini açıklar. Keşif sırasında fikirler değişebilir veya bırakılabilir; yayımlama sonrasında da öğrenme sürer.
Tamamlayıcı kaynak: Jeff Patton, Dual Track Development is not Duel Track.
Prototip, çözümün belirli yönlerini denemek için hazırlanan temsildir. Kullanıcıya bir akışı göstermek veya teknik bir soruyu araştırmak için kullanılabilir. Bu çalışma, üretim ortamında kullanılacak ürünle aynı kalite ve işletim kapsamını taşımayabilir. Hangi koşulları temsil ettiği açıklanmalıdır.
Keşiften teslimata geçmek de bütün belirsizliklerin sona ermesi demek değildir. Ekip, hangi kapsamı hangi kanıtla seçtiğini ve kalan soruları nasıl ele alacağını konuşmalıdır. Ayrıntılandırılmış bir iş maddesi, kullanıcı değerinin garanti edildiği anlamına gelmez.
Gerçek vaka: CarMax’ın inovasyon yaklaşımında iki akış
CarMax’ın SEC arşivinde bulunan 2018 analist günü sunumu, inovasyon yaklaşımını ürün takımları ve Dual Track Agile başlıklarıyla anlatıyor. İlgili slaytlarda Discovery Track ve Delivery Track ayrı adlandırılıyor. Bu, yaklaşımın şirket tarafından kurumsal sunumda açıkça ifade edildiği doğrulanabilir bir örnektir.
Sunum, müşteri deneyimini mağaza ve çevrim içi kanallar üzerinden birlikte ele alıyor. Araç edinme, öneri, finansman ve teslimat gibi faaliyetler aynı müşteri sürecinin parçaları olarak gösteriliyor. Böyle bir bağlamda ürün kararlarının yalnızca bir ekranın geliştirilmesine indirgenmemesi gerektiği yorumu yapılabilir; bu, sunumun ürün yönetimi açısından değerlendirilmesidir.
Belge, her takımın günlük çalışma düzenini veya belirli bir fikrin keşiften teslimata nasıl geçtiğini ayrıntılı açıklamıyor. Yaklaşımın gelir ya da teslimat süresi üzerindeki etkisini ayrı bir karşılaştırmayla kanıtlamıyor. Bu nedenle sayısal bir iyileştirme iddiası çıkarılamaz.
Vakadan alınabilecek ders, keşif ve teslimatın ürün çalışma modelinde birlikte görünür olmasıdır. Uygulamanın kalitesini değerlendirmek için bu çerçeveden başka karar ve sonuç kanıtları da gerekir.
Kaynak: CarMax, 2018 Analyst Day sunumu, Innovation Approach slaytları, SEC arşivi.
Varsayımsal örnek: Rapor gönderimi ve yönetici özeti
Bir kurumsal raporlama ürünü, kullanıcıların düzenli raporlarını zamanında paylaşmasını kolaylaştırmak istiyor. Ekip, seçilmiş bir kapsam olan zamanlanmış rapor gönderimini geliştiriyor. Alıcı, gönderim zamanı ve erişim koşulları konuşulmuş; gerekli kalite çalışmaları planlanmış.
Aynı dönemde ürün sahibi, tasarımcı ve geliştirici yönetici özeti ihtiyacını araştırıyor. İlk öneri, bütün müşterilere aynı göstergeleri sunan bir ekran. Görüşmelerde yöneticilerin farklı kararlar için farklı bilgileri kullandığı görülüyor. Ekip sabit gösterge listesini doğrudan geliştirme kapsamına almıyor.
Tasarımcı, müşterinin kararını destekleyen kısa bir özet prototipi hazırlıyor. Kullanıcıdan son değerlendirme toplantısında hangi bilgiye ihtiyaç duyduğunu anlatması isteniyor. Geliştirici, seçilen göstergelerin mevcut verilerle güvenilir biçimde hesaplanıp hesaplanamayacağını inceliyor.
Araştırma, ilk kapsamın belirli bir yönetici grubuyla sınırlandırılmasına yol açabilir. Bazı göstergeler için veri eksikse bunlar hazırlanmış gibi gösterilmiyor. Önce gerekli veri ve kullanım koşulları netleştiriliyor. Öğrenilenlerin sonucu geniş bir ekran yerine daha dar bir bilgi sunumu olabilir.
Bu sırada zamanlanmış rapor gönderiminin uygulamasında erişim değişiklikleriyle ilgili bir sorun fark ediliyor. Raporun gönderildiği anda alıcının yetkisinin yeniden kontrol edilmesi gerekiyor. Ekip bu bilgiyi hem mevcut geliştirmede hem yönetici özeti fikrinde değerlendiriyor. İki çalışma ayrı ilerlese de ortak bir ürün gerçeğiyle bağlanıyor.
Gönderim kullanıma açıldığında raporun alıcı tarafından bulunup kullanılabilmesi inceleniyor. Yeni gözlem, özet fikrindeki varsayımları da değiştirebilir. Araştırmanın tamamlandığı tarih, öğrenmenin sona erdiği tarih olarak kabul edilmiyor.
Yaygın üç hata
- Akışları ayrı takımlar arasında belge devrine çevirmek
Mühendisliği yalnızca hazır tasarımı uygulayan taraf olarak görmek, teknik soruları geciktirebilir. Karar için gereken uzmanlıkları erken dahil edin. Keşif bulgularını ve uygulama sırasında öğrenilenleri ortaklaştırın.
- Keşfi sürekli iş listesi doldurma faaliyeti saymak
Her araştırma yeni geliştirme üretmek zorunda değildir. Fikri bırakmak veya daraltmak kaynak kullanımını değiştirebilir. Öğrenilenlerin hangi yatırım kararını etkilediğini kaydedin.
- İki akış için aynı kapasiteyi iki kez planlamak
Ortak çalışan kişilerin katkısını gerçekçi değerlendirin. Kritik teslimat işi öğrenme zamanını azaltıyorsa bu tercihi görünür tutun. Planı, herkes iki işi aynı anda sınırsız yapabilirmiş gibi kurmayın.
Mini uygulama / şablon
Yaklaşan çalışma için aşağıdaki alanları birlikte doldurun.
- Amaçlanan kullanıcı sonucu
- —
- Teslimatta ilerleyen kapsam
- —
- Bu kapsamın seçilme gerekçesi
- —
- Keşifte cevap aranan soru
- —
- Kritik varsayım ve mevcut kanıt
- —
- Öğrenme yöntemi
- —
- Her iki çalışmaya katkı verecek kişiler
- —
- Kapasite ve bağımlılıklar
- —
- Öğrenilenlerin değiştirebileceği kararlar
- —
- Teslimattan keşfe taşınacak bulgular
- —
- Kullanım sonrası değerlendirme
- —
Ardından iki akıştaki çalışmaları aynı görüşmede ele alın. Teslimatta yalnızca durum bildirmeyin; yeni bilgiyi açıklayın. Keşifte yalnızca yapılan görüşmeleri saymayın; seçeneklerin nasıl değiştiğini gösterin. Böylece akışlar ortak kararlarla birbirine bağlanır.
İlgili terimler
Continuous Discovery, Continuous Delivery, Product Discovery, Product Trio, Product Backlog, Backlog Refinement, Prototype, Hypothesis, Assumption Testing, Increment, Definition of Done, Outcome ve Output, Capacity Planning, Product Owner