Soyut
Kitap, geliştirme sürecini fikirden uygulamaya kadar çevik teknikler kullanarak gerçekleştirmeye yönelik anlatımlı bir algoritmadır. Süreç adımlar halinde ortaya konmuştur ve her adımda süreç adımına yönelik yöntemler belirtilmektedir. Yazar, orijinal olduğunu iddia etmeden, yöntemlerin çoğunun orijinal olmadığını belirtiyor. Ancak iyi yazım tarzı ve sürecin bir miktar bütünlüğü kitabı çok faydalı kılıyor.
Kullanıcı hikayesi haritalamanın önemli bir tekniği, kullanıcı süreç boyunca ilerledikçe fikirleri ve performansları yapılandırmaktır.
Aynı zamanda süreç farklı şekillerde de anlatılabilir. Anahtar bir değere ulaşırken adımlar oluşturabilirsiniz veya kullanıcıların sistemi kullanarak geçirdiği çalışma gününü alıp hayal edebilirsiniz. Yazar, süreçlerin ana hatlarıyla belirtilmesi, bir süreç haritası üzerinde kullanıcı hikayesi şeklinde konuşulması gerektiği gerçeğine odaklanıyor; bu da bize kullanıcı hikayesi haritası adını verdi.
Kime ihtiyacı var
BT analistleri ve proje yöneticileri için. Okunmalı. Okuması kolay ve keyifli olan kitap orta büyüklüktedir.
geri çağırma
En basit haliyle bu şekilde çalışır.
Bir ziyaretçi bir kafeye gelir, yemekleri seçer, sipariş verir, yemeği alır, yer ve ödeme yapar.
Her aşamada sistemden istediklerimizi yazabiliyoruz.
Sistem yemeklerin bir listesini göstermeli, her yemeğin bileşimi, ağırlığı ve fiyatı olmalı ve sepete eklenebilmelidir. Bu gereksinimlere neden güveniyoruz? Bu, gereksinimlerin “standart” tanımında açıklanmamaktadır ve bu durum risk oluşturmaktadır.
Bunun neden gerekli olduğunu anlamayan sanatçılar genellikle yanlış olanı yaparlar. Bir fikir yaratma sürecine dahil olmayan icracılar sonuca dahil değildir. Agile, öncelikle sisteme değil, insanlara, tüketicilere, onların görevlerine ve hedeflerine odaklanalım diyor.
Kişilikler yaratırız, onlara empati için ayrıntılar veririz ve kişiliğin açısından hikayeler anlatmaya başlarız.
Ofis çalışanı Zakhar öğle yemeğine gitti ve hızlıca bir şeyler atıştırmak istiyor. Onun neye ihtiyacı var? Buradaki fikir muhtemelen bir iş yemeği istiyor olmasıdır. Diğer bir fikir ise diyette olduğu için sistemin tercihlerini hatırlamasını istemesidir. Diğer bir fikir. Öğle yemeğinden önce kahve içmeye alışık olduğu için hemen kahvenin kendisine getirilmesini istiyor.
Ve bir de iş var (organizasyonel karakter, bir organizasyonun çıkarlarını temsil eden bir karakterdir). İşletmeler ortalama çeki artırmak, satın alma sıklığını artırmak ve karları artırmak istiyor. Fikir şu; bazı mutfaklardan sıra dışı yemekler sunalım. Başka bir fikir - hadi kahvaltıyı tanıtalım.
Fikirler bir kullanıcı hikayesi biçiminde somutlaştırılabilir, dönüştürülebilir ve sunulmalıdır. Zakhar İş Merkezi çalışanı olarak tercihlerime göre menü alabilmem için sistemin beni tanımasını istiyorum. Garson olarak, müşterinin hızlı servisten memnun kalması için masaya ne zaman yaklaşmam gerektiğini sistemin bana bildirmesini istiyorum. Ve benzeri.
Onlarca hikaye. Sırada önceliklendirme ve biriktirme var mı? Jeff ortaya çıkan sorunlara dikkat çekiyor: Küçük ayrıntılarda takılıp kalmak ve kavramsal anlayışı kaybetmek, ayrıca işlevselliğe öncelik vermek, hedeflerle tutarsızlık nedeniyle düzensiz bir tablo yaratıyor.
Yazarın yolu: İşlevselliğe değil sonuca = kullanıcının sonuçta elde ettiği şeye öncelik veriyoruz.
Açıkça görülmeyen bir nokta: Önceliklendirme oturumu etkisiz olduğu için tüm ekip tarafından değil, üç kişi tarafından yürütülüyor. Birincisi işten, ikincisi kullanıcı deneyiminden ve üçüncüsü uygulamadan sorumludur.
Bir kullanıcı problemini çözmek için minimumu (minimum uygulanabilir çözüm) seçelim.
Sürecin her adımında insanların ve paydaşların neye ihtiyaç duyduğunu ekiple anlatıp tartışarak, kullanıcı hikayesi haritası üzerinde kullanıcı hikayeleri, tasarım eskizleri, kısıtlamalar ve iş kurallarını kullanarak birinci öncelikli fikirleri detaylandırıyoruz. Kalan fikirleri, fırsatlar yığınında incelenmeden bırakıyoruz.
Süreç kartlara soldan sağa yazılır ve fikirler süreç adımlarının altındaki kartlarda yer alır. Karşılıklı anlayışın sağlanması için tüm hikaye boyunca izlenecek yolun ekip üyeleriyle birlikte tartışılması zorunludur.
Bu şekilde detaylandırılma, süreçlere uygun bir bütünlük oluşturur.
Alınan fikirlerin test edilmesi gerekir. Ekip dışı bir üye, kişinin şapkasını takar ve kişinin gününü kafasında yaşayarak sorununu çözer. Gelişmeleri görmemesi, yeniden kart yaratması ve ekibin kendine alternatifler keşfetmesi mümkün.
Daha sonra değerlendirme için detaylandırma yapılır. Bunun için üç kişi yeterli. Kullanıcı deneyiminden sorumlu, geliştirici ve testçinin favori sorusu: "Ya şöyle olursa...".
Her aşamada tartışma, kullanıcının geçmişine ilişkin bir süreç haritasını takip eder; bu, tutarlı bir anlayış oluşturmak için kullanıcının görevini akılda tutmasına olanak tanır.
Yazarın görüşüne göre dokümantasyon gerekli midir? Evet ihtiyacım var. Ancak üzerinde anlaştığınız şeyi hatırlamanıza olanak tanıyan notlar olarak. Dışarıdan birinin tekrar dahil edilmesi tartışma gerektirir.
Yazar, tartışma ihtiyacına odaklanarak dokümantasyonun yeterliliği konusuna girmemektedir. (Evet, çeviklik konusunda derin bir anlayışa sahip olmayan kişiler bunu ne kadar iddia etse de belgelendirmeye ihtiyaç vardır). Ayrıca, yeteneklerin yalnızca bir kısmının detaylandırılması, tüm sistemin tamamen yeniden işlenmesi ihtiyacını doğurabilir. Yazar, fikrin yanlış olması durumunda aşırı detaylandırma riskine dikkat çekiyor.
Riskleri ortadan kaldırmak için, “yanlış” ürün yaratmanın zararlarını en aza indirmek için oluşturulan ürün hakkında hızlı bir şekilde geri bildirim almak gerekir. Fikrin bir taslağını yaptık - onu kullanıcıyla doğruladık, arayüz prototiplerini çizdik - kullanıcıyla doğruladık vb. (Ayrı olarak, program prototiplerinin nasıl doğrulanacağına dair küçük bir bilgi bulunmaktadır). Yazılım oluşturmanın özellikle başlangıç aşamasındaki hedefi, hızlı geri bildirim alarak öğrenmektir; buna göre oluşturulan ilk ürün, bir hipotezi kanıtlayabilecek veya çürütebilecek eskizler olur. (Yazar, Eric Ries'in "Yalın metodolojiyi kullanan Startup" adlı çalışmasına dayanmaktadır).
Hikaye haritası, uygulama birden fazla ekip arasında gerçekleştirilirken iletişimin geliştirilmesine yardımcı olur. Haritada ne olmalı? Konuşmayı sürdürmek için neye ihtiyacınız var? Yalnızca bir kullanıcı hikayesi değil (kim, ne, neden), aynı zamanda fikirler, gerçekler, arayüz taslakları vb.
Tarih haritasındaki kartları birkaç yatay çizgiye bölerek, çalışmayı yayınlara bölebilirsiniz - minimum düzeyde olanı, artan işlevsellik katmanını ve yayları vurgulayın.
Süreç haritası üzerinde hikayeler anlatıyoruz.
Öğle yemeğine bir çalışan geldi.
Ne istiyor? Servis hızları. Öyle ki öğle yemeği zaten masanın üzerinde ya da en azından bir tepsinin üzerinde onu bekliyor. Hata! Kaçırılan bir adım: çalışan yemek yemek istiyordu. Oturum açtı ve iş yemeği seçeneğini seçti. Diyet yapmasına ve kilo almamasına yardımcı olacak kalori içeriğini ve besin içeriğini gördü. Yemeğin resimlerini görünce orada yemek yiyip yemeyeceğine karar verdi.
Sonra öğle ve akşam yemeğini yemeye gidecek mi? Ya da belki öğle yemeği ofisine teslim edilecek? Daha sonra sürecin adımı yemek yiyecek bir yer seçmektir. Kendisine ne zaman teslim edileceğini ve ne kadara mal olacağını görmek istiyor, böylece zamanını ve enerjisini nerede harcayacağını, aşağıya ineceğini veya işe gideceğini seçebiliyor. Sıralarda itişip kakışmamak için kafenin ne kadar meşgul olduğunu görmek istiyor.
Daha sonra çalışan kafeye geldi. Tepsisini görmek ve hemen yemeğe gitmek istiyor. Kafe, hizmetten para kazanmak için para kabul etmek istiyor. Çalışan, değerli zamanını gereksiz yere boşa harcamamak için kafe ile yapılan yerleşimlerde minimum zaman kaybetmek istiyor. Nasıl yapılır? Uzaktan hizmetten sonra peşin veya tam tersi ödeme yapın. Veya bir kiosk kullanarak yerinde ödeme yapın. Bu konudaki en önemli şey nedir? Kaç kişi öğle yemeğini banka kartıyla ödemeye hazır? Tekrarlanan ödemeler için kart numaralarını saklama konusunda kaç kişi bu kantine güvenir? Saha araştırması olmadan belirsizdir, test yapılması gerekir.
Sürecin her adımında bir şekilde işlevsellik sağlamanız gerekiyor, bunun için bir kişiyi temel almanız ve onun için neyin daha önemli olduğunu seçmeniz gerekiyor (aynı üç seçici). Hikayeyi sonuna kadar takip ettim = geçerli bir çözüm ürettim.
Daha sonra detaylandırma geliyor. Müşteri kuyruklarda itişip kakışmamak için kafenin ne kadar meşgul olduğunu görmek istiyor. Tam olarak ne istiyor?
Oraya vardığında 15 dakika içinde kaç kişinin orada olacağına dair tahmine bakın
Bir kafedeki ortalama servis süresini ve dinamiklerini yarım saat önceden görüntüleyin
Durumu ve masa doluluk dinamiklerini görün
Tahmin sistemi belirsiz bir sonuç verirse veya çalışmayı durdurursa ne olur?
Kafedeki kuyrukların yanı sıra masaların doluluk durumunu video aracılığıyla izleyin. Hmm, neden önce bunu yapmıyorsun?
Yazar, pratik yapmak için küçük bir egzersize dikkat çekiyor: Sabah uyandıktan sonra ne yaptığınızı hayal etmeye çalışın. Bir kart = bir eylem. Uygulama yöntemine değil hedefe odaklanarak bireysel ayrıntıları kaldırmak için kartları büyütün (kahve öğütmek yerine canlandırıcı bir içecek içirin).
Bu kitap kimlere yöneliktir: BT analistleri ve proje yöneticileri. Okunmalı.
Uygulamalar
Tartışma ve karar alma 3 ila 5 kişilik gruplarda etkilidir.
İlk karta neyin geliştirilmesi gerektiğini yazın, ikinciye - ilkinde yaptıklarınızı düzeltin, üçüncüye - birinci ve ikincide yapılanları düzeltin.
Kek gibi hikayeler hazırlayın; tarif yazarak değil, pastanın kim için, hangi vesileyle ve kaç kişi için olduğunu öğrenerek. Satışları parçalara ayırırsak kek, krema vb. üretimi değil, küçük hazır kek üretimi olacaktır.
Yazılım geliştirme, film çekmeye benzer; çekimler başlamadan önce senaryoyu dikkatli bir şekilde geliştirmeniz ve cilalamanız, sahneyi, oyuncuları vb. düzenlemeniz gerekir.
Kaynak sıkıntısı her zaman olacaktır.
Çabaların %20'si somut sonuçlar verir, %60'ı anlaşılmaz sonuçlar verir, %20'si zararlıdır; bu nedenle öğrenmeye odaklanmak ve olumsuz bir sonuç durumunda umutsuzluğa kapılmamak önemlidir.
Kullanıcıyla doğrudan iletişim kurun, kendinizi onun yerinde hissedin. Bazı sorunlara odaklanın.
Hikayeyi değerlendirme için detaylandırmak ve geliştirmek, scrum'un en sıkıcı kısmıdır, tartışmaları akvaryum modunda ayakta tutun (kurulda 3-4 kişi tartışır, biri katılmak isterse yerini değiştirir).
Kaynak: habr.com