Sprint 0'ın Ötesinde: Takımları Entegre Etmek İçin Bir Alternatif

Scrum, ekiplerin %72'sinden fazlasının Scrum veya bir scrum-hybrid kullandığı dünyadaki en popüler proje yönetimi metodolojisidir. Web geliştirmede çalışıyorsanız, Scrum'ı bir şekilde kullanıyor olma ihtimaliniz yüksektir.

Scrum'daki güncel bir trend, "Sprint 0" veya onun daha iddialı kuzeni "Tasarım Sprint"idir. Bunların gerçek sprintler olup olmadığı hakkında çok şey yazıldı (öyle değiller), ancak ilk etapta neden var oldukları, neden bu kadar inatla takılıp kaldıkları ve hangi alternatiflerin var olduğu hakkında daha az şey söylendi.

Ben kişisel olarak Scrum'ı seviyorum ve her zaman onu nasıl uyguladığımı adım adım iyileştirmenin yollarını ararım. Bu makalede, iş akışıma dahil ettiğim ve UX/UI ile geliştirmeyi birleştirirken ve daha güçlü proje vizyonları oluştururken faydalı bulduğum yöntemleri paylaşmak istiyorum.

Başlamadan önce birkaç hızlı tanım:

• Sürat 0
  Bir ekibin scrum projeleri için gerekli kılavuz belgeleri oluşturmaya yönelik ilk çabası: bir vizyon, bir ürün biriktirme listesi ve ürün sürüm tahminleri.
• Tasarım Sprint
  Bir ekibin, sürümün geri kalanı için yol gösterici bir tasarım oluşturmaya yönelik ilk çabası.
  

Sprint 0 ve Tasarım Sprint Neden Var?

“Sprint 0 gerçek bir sprint değil, yapma” demek güzel ve güzel. Ancak bu sprint-ish uyarlamaları bir nedenden dolayı var. Birçok takım, projelerinin Scrum kapsamının ötesinde karşılanmamış bir ihtiyacı olduğu için bunları benimser. Benim gözlemim, Sprint 0 ve tasarım sprintlerinin en sık aşağıdaki durumları ele almak için kullanıldığıdır:

1. Güçlü bir yol gösterici vizyonun olmaması;
2. Geliştirme iş akışına tasarım entegrasyonu eksikliği.

Scrum süreci, ürün sahibi tarafından net bir vizyonun geliştirildiğini ve iletildiğini varsayar. Ancak vizyonun zayıf, yanlış veya görünmez olduğu projelerde çalıştıysanız elinizi kaldırın. Ben de! Sprint 0, geliştirme ekibinin vizyon boşluğunu doldurma girişimidir. En kötü fikir değil, sorun ne? Çevik bir bakış açısından, Sprint 0 yinelemeli değildir, tüm ekibin yeteneklerini kullanmaz ve belirsiz sonuçlar verir. Ve siz, "Hey, buradaki asıl sorun, scrum ekiplerinin ürün sahibinin işini yapmak zorunda olmamasıdır" diye belirtmeden önce, aslında disiplinler arası bir çevik ekibin güçlü, gerçekçi bir ekip geliştirmek için en iyi ortamlardan biri olduğuna inanıyorum. vizyon ve hedefler.

Aktarma gerektirmeyen projelerde başarıyla kullandığım daha çevik bir vizyon oluşturma yöntemi öneriyorum. Bu sprint benzeri uyarlamaların kullanıldığı her iki durumu da keşfedeceğim ve bu alternatif ilk sprint'in çevik iş akışını nasıl daha iyi desteklediğini anlatacağım.

Vizyon ve Prototip Sprint

Güçlü bir vizyon eksikliğinin olduğu ilk durumda, yol gösterici belgeler veya fikirler bir Scrum projesine gerçekten başlamak için çok zayıftır. Herhangi bir süreç için (Scrum dahil), yolculuğa başlamadan önce yönlendirmeye ihtiyacınız vardır. Çevik, bir hedefe ulaşmanın en iyi yolunu bulmak için harikadır, ancak ilk vizyonu oluşturmak onun kapsamında değildir. Aslında, Scrum'da tamamen eksik olmak, geliştirme sürecinin başlaması için gerekli vizyonun bir tanımıdır. Gerçekten Scrum olsun ya da olmasın, Sprint 0 sadece ön saflarda bulunan, sahip oldukları araçları kullanan ve yapmaya başlamadan önce ne yapmaları gerektiğini bulmaya çalışan bir web ekibidir.

Sprint 0'ın gerçek dezavantajı, en az bilgiye sahip olduğunuz zamanda proje için kılavuz belge oluşturmanın, takip eden geliştirme sürecine düşük değer sağlamasıdır.

Yinelemeli olarak ortaya çıkan gerçeklikle uyumlu olmayan rehberlik eden proje vizyonları, ya başka bir Sprint 0'ın pahalı sürecinden geçmeli ya da daha sıklıkla görmezden gelinmelidir.

Daha iyi bir alternatif, prototip sprintidir: aslında ilk prototipin kendisini oluştururken tüm ekibi meşgul eden bir ilk sprint.

Prototip Sprint Vizyon Süreci

Beyin fırtınası fikirleri, düşük bir görsel aslına uygun hale dönüştürülür ve mümkün olan en kısa sürede prototip çalışır. Prototip, işlevsel bir ön uç HTML ve CSS çerçevesinde, yani ekibin paylaşılan dilinde yazılmıştır. Herkes bir teknik özellik sayfasını veya bir vizyon ifadesini anlayamaz. Herkes bir web sitesini anlayabilir ve iletişim daha kolaydır ve daha geniş bir disiplin yelpazesini içerir.

İlk sprintin sonunda prototip, genel kullanılabilirlik, erişilebilirlik ve mobil yanıt verme dahil olmak üzere çeşitli cephelerde ilk test için hazırdır. Ekiplerimde bu, geçerli ve önemli bir tamamlanmış artıştır. Prototip sprint aynı zamanda bir ilk ürün biriktirme listesi de üretir. Birikmiş işler gelecekteki sprintlerde tamamlandıkça, prototip aslına uygunluk kazanır. Prototip, kullanılıp atılan kod değildir - temeldir.

Bazı projelerde prototip üretilirken yazılı bir vizyon oluşturulur. Ancak birçok projede prototip , vizyondur. Ekibin ortak dilinde konuşuyor ve elbette üründen asla kopmuyor.

Örnek vermek

Aşağıdaki örnek, ilk RFP'deki kaba taslaktan tamamlanmış bir e-ticaret uygulaması için çalışan bir prototiptir. Ne kadar kaba olursa olsun, ekibin enerjilerini üretken bir yöne odaklamada, işlevsel kriterlere odaklanmak için birçok potansiyel dikkat dağıtıcı ve tuzaktan sıyrılmada etkili oldu.

Bir ilk prototip, genellikle, kullanıcı deneyiminin ışığına kadar tutulana kadar en iyi tahminler olan gereksinimlerde değişikliklerle sonuçlanacaktır. Örnek olarak, yukarıda gösterilen prototip sprintinden edindiğimiz içgörülerden biri, fiyatlandırma ve 'satın al' düğmesinin başlangıçta sayfada çok düşük olduğudur. İlk istek, bunları ürün bilgilerinin altına ve önerilerin üstüne yerleştirmekti, ancak işlevsel bir prototip, hiyerarşinin çok işlevsel olmadığını çabucak gösterdi.

Ortaya çıkan bir başka işlev de, galeri görüntülerinin orijinal olarak büyük olmasının ve sayfanın tüm genişliğini genişletmesinin istenmesiydi. Prototip, paydaşlara bunun neden işe yaramayacağına dair varsayımsal nedenler sunmak yerine, sorunları tüm ekibin anladığı ortak bir dilde gösterebildi. Paydaşlarla yapılan bir güç oturumunda, bu sayfayı evrensel olarak üzerinde anlaşmaya varılan bir hiyerarşiye göre hızla yeniden düzenledik.

Prototip, erişilebilir ve duyarlı olarak doğduğundan, hemen birden fazla cihaz ve teknoloji üzerinde test etmeye başlayabiliriz. Tasarım (bu erken aşamada bile böyle denilebilirse) kasıtlı olarak düşük doğrulukta tutulsa da, masaüstündeki yıl değiştirici mesajlaşmasının mobilde çok büyük olduğu ve kullanılabilirliği engellediği hemen görüldü (solda). Başlıkta daha küçük bir anahtarlayıcı kullanmak için prototipi hızla güncelledik (sağda).

Bu prototip sprint sırasında birkaç başka sorun hızla ortaya çıktı:

• Müşteri, işlevsel gezinmeyi tıkladıktan sonra, özelliklerinde önemli bir işlevsel bileşeni kaçırdıklarını hemen fark etti: bir blog. Bu, tahmini ve zamanlamayı etkiledi, ancak hızlı bir şekilde ayarlayabildik.
• UI ekibi, fiyatlandırma ekranının aşırı karmaşık ve kafa karıştırıcı olduğunu açıkça gördü. Müşteriyle diğer olasılıkları araştırdık ve prototip sprinti sırasında hızlı bir şekilde prototipleme ve kullanıcı tarafından çeşitli çözümleri test etme imkanı bulduk.

Vizyonun potansiyel olarak bir engel olması veya geliştirme başlar başlamaz modasının geçmesi yerine, bir prototip sprint'te vizyon ve işlevsel kriterler birlikte geliştirilir ve birbirini destekler. Ve vizyon ekip tarafından oluşturulduğu için ekibe herhangi bir geçiş olmaz ve geliştirme sürecindeki bu riskli dönemi kolayca önler.

Tasarım Ve Prototip Sprint

İkinci durumda - tasarımın geliştirme ile entegrasyonunun eksikliği - genellikle bir "tasarım sprint"inin kullanıldığını göreceksiniz. Bu yönü bir Sprint 0'dan bile daha verimsiz buluyorum. Tasarımı karmaşık bir geliştirme sürecine entegre etmenin zorlukları gerçektir, ancak bir tasarım sprint'i kendi kendini yenilgiye uğratan bir yaklaşımdır. Tasarım sprinti, semptom için bir yara bandıdır - entegre ekipler oluşturma zorluğu - ancak altta yatan sorunu - kullanıcı ihtiyaçlarını anlama ve karşılama zorluğu - ele almaz. Tasarımın tek bir sprintte önden yüklenmesi, entegrasyon zorluğunu ortadan kaldırır, ancak entegre ve artımlı tasarım sürecinin faydaları ve kullanıcıları anlamak ve onlara ulaşmak için açtığı pencere tamamen kaybolur.

Aktarma gerektirmeyen projelerde kullandığım prototip sprint, tasarım sprintine üretken ve tamamen çevik bir alternatif. İşbirliğine dayalıdır ve hem UI/UX hem de geliştirmeyi projenin ilk aşamalarından itibaren birleştirir. En deneyimli tasarım ekibi bile diğer disiplinlerin katılımından yararlanabilir ve kritik olarak, kod ve tasarım hedeflerinin çapraz amaçlarda olmamasını sağlar.

Genellikle tasarım süratinin de vizyonu ortaya çıkarması beklenir. Bu, tasarım sürecinin geliştirmeden çok vizyon oluşturmak için daha donanımlı olduğuna dair belirsiz ama anlayışlı bir anlayışa dayanan umutsuz bir harekettir. Bununla birlikte, tasarımla oluşturulmuş bir vizyon, gerçek, işbirlikçi, ekip çapında bir çaba için zayıf bir alternatiftir.

Zavallı tasarımcılar, bu çabayı gerçekten değerli kılmak için gerekli olan disiplinler arası bilgi olmadan gelişmeyi başlatmak için bir son ürün üretmekle uğraşıyorlar. Teknik bilgiye ve daha fazla deneyime sahip bir tasarımcının bunu doğru yapma şansı daha yüksek olsa da, yine de çok risklidir. Aşamanın sonunda potansiyel olarak sevk edilebilir bir ürün olmadan, teste karşı varsayımlara karşı geliştirme çalışmalarına devam edilir. Tasarım isabetli değilse veya teknik özellikler değişirse, tasarım ekibine geri döndüğü için uzun gecikmelere neden olabilir. Çevik, özünde bir risk yönetimi sürecidir ve çevik projelerimize doğası gereği riskli bir tasarım sprintiyle başlamaktan daha iyisini yapabiliriz.

Prototip Sprint Tasarım Süreci

Daha geleneksel bir tasarım sprintinden en önemli değişiklik, prototip sprinti sırasında ekibin doğrudan kağıttan prototipe geçmesi ve Sketch, InVision, Photoshop veya diğer dijital yerleşim programlarının kullanımını atlamasıdır. Bu aşamada görsel bir koltuk değneği görevi görürler ve çok hızlı bir şekilde değer katar gibi görünürler (çünkü iyi tasarımcılar güzel şeyler yapar), ancak yüksek kaliteli bir maketin bu erken dönemdeki gerçek değeri çok düşüktür, ancak potansiyel tehlike arz eder — düğün paydaşları için yanlış çözümler – yüksektir.

Bu araçlar, aslına uygun düz modellerde en iyisidir, ancak ilk prototip ne yüksek kaliteli ne de düzdür. Beyaz tahta, kurşun kalem ve kağıt, ekibin fikirlere bağlanmadan hızlı bir şekilde çalışmasına izin verir. Ardından bu düşünceyi mümkün olan en kısa sürede işlevsel bir prototip haline getirin.

Tasarımcılar da dahil olmak üzere her ekip üyesi, lo-fi aşamalarında doğrudan prototipe aşina olmalı ve üzerinde çalışabilmelidir. Ancak bu mümkün değilse (veya daha uzun vadeli bir hedefse ve şimdi ilerlemeniz gerekiyorsa), tasarımcı ve geliştiricinin yan yana çalıştığı ikili bir yaklaşım iyidir. Eskizler, tasarımcı tarafından tanımlanabilir ve geliştirici tarafından birlikte yorumlanabilir, böylece her bir bakış açısına ilişkin ortak anlayışları genişletilebilir.

Örnek vermek

Aşağıdaki örnek, mevcut bir web sitesinin derinlemesine analizini doğrudan işlevsel bir prototipe ayırma sürecimizi göstermektedir. Raporun bulgularının yerel bir web ortamında değerlendirilmesine izin verdi, basılı bir belgedeki önerileri entelektüel olarak analiz etmekten çok farklı bir deneyim:

Ayrıca, derinlemesine analiz belgesinden farklı olarak (olduğu kadar yararlı), işlevsel prototip jargon içermez ve herkesin anlayabileceği ortak bir sözlü ve görsel dil kullanır. Sohbeti tüm ekip üyelerine ve disiplinlere görsel olarak açar.

Bu şablonu oluştururken asıl sorumuz, ne kadar tasarım detayının dahil edileceğiydi. Analizlerle dolu zengin bir belgeye sahip olduğumuz için prototipi daha ileriye götürebilirdik. Ancak, görsellerin hızlı (ve istemeden) fikir alanından gerçek alanına geçebileceğini akılda tutarak, düzeni bağlayıcı olmayan tuttuk ve belgeyi yalnızca temel öğelerine ve anlamına göre damıttık.

Dahili testler, bizi daha kullanıcı odaklı bir çözümün balo sahasına soktu ve birçok potansiyel sorunun üstesinden geldi, ancak sürecin bu kadar erken safhalarında herhangi bir rafine tasarım kararı vermekten bilinçli olarak kaçındık. Müşterininki de dahil olmak üzere tüm fikir ve önerileri bilinen verilere karşı sürekli olarak tartmak ve bu noktada bilgi havuzumuzun projenin diğer herhangi bir aşamasında olacağından daha küçük olduğunu hatırlamak önemlidir.

İlk prototipi düşük tutmanın ve herhangi bir "tasarım" öğesi içermemenin kritik olmasının bir başka nedeni de, ekibin katılımının, istenmeyen içgüdüsel tepkileri ortaya çıkaran alakasız görsel öğeler tarafından raydan çıkarılabilmesidir. Renkten uzak duruyoruz ve müşteri logosunu bile eklemiyoruz (yerine yer tutucu olarak boş bir alan veya açık gri bir kutu kullanın). Konuşma, içerik hiyerarşisi, erişilebilirlik, kullanılabilirlik, dil ve anlam gibi işlevsel kriterlere göre sürekli olarak yönlendirilmelidir. "Eğlenceli şeylerin" geleceğine, ancak bu erken aşamada olmayacağına dair ekibe güvence verin.

Aslında, başarılı bir prototip sprintinin önemli bir amacı, mümkün olduğunca az ön tasarım kararı vermektir. Başarılı tasarım, kullanıcı deneyimiyle beslenir, bu nedenle ortaya çıkan proje bilgisinin kullanıcı arayüzünü bilgilendirmesi için zaman tanıyın.

Prototip Sprint Ne Zaman Tamamlanır?

Prototip ve eşlik eden eserler tüm ekip (müşteri dahil) tarafından onaylandığında ve prototip ilk kullanılabilirlik ve erişilebilirlik testi için hazır kabul edildiğinde sprint tamamlanır.

Erken işlevsel bir prototip, ölçek (sayfa sayısı, gezinme kapsamı ve diğer ana UI öğeleri), gelecekteki karmaşıklık (yararlı tanımlayıcılara sahip yer tutucu içeriği, muhtemelen bazı erken işlevsellik kodlu) ve ihtiyaçların belirlenmesi (gerekli belirli teknolojiler) aracılığıyla proje vizyonunu hayata geçirir. , konuşlandırılacakları yer, herhangi bir bağımlılık). Araçlar, çalışma ortamı ve kod yığını ile ilgili kararlar tüm ekibin girdisi ile alınacaktır.

Bu tamamlanmış artışa ulaşmak, duyarlı bir müşteriye sahip deneyimli bir ekip için bir gün kadar kısa bir süre alabilir, ancak genellikle yaklaşık bir hafta ve iki haftadan fazla sürmez. Prototip sprintler hızlı bir şekilde hareket etmelidir ve iki haftalık zaman dilimini aşmak kırmızı bayrak olabilir. Bu, oyunda başka sorunlar olduğu anlamına gelebilir.

Prototip Sprint Sırasında Dikkat Edilmesi Gereken Bazı Genel Sorunlar

Prototip sprintini uygularken dikkat edilmesi gereken birkaç yaygın sorun şunları içerir:

• Düşük aslına uygunluk değerini benimseyin ve görsellere vurgu yapmaktan kaçının. Bu yaklaşımda yeni olan ekipler, "logonun nerede" ötesine geçerken ve daha derin işlevsellik ve hiyerarşi sorularına odaklanırken yardıma ve güvenceye ihtiyaç duyabileceklerinden bu noktada dikkatli olun.
• Yukarıdakilerin farklı bir yönü, kendi tasarım/düzen fikirlerinize bağlı kalmama konusunda da dikkatli olun. Prototip sprintleri sırasında değerli hiçbir şeyin üretilmediğini hatırlamak ve nihai sonuçlardan ayrı kalmak yararlıdır. Ayrıca, prototipleri minimal ve açıkçası oldukça çirkin tutmak için bir başka neden daha. Kullanıcıları ayrı tutma amacına hizmet eder.
• Liderlik sürecinin erken dönemde satın alınması kritik öneme sahiptir . Çünkü tüm ekip müvekkiliniz, patronunuz ve geliştiricilerin katılımı, yaratıcılıkları ve zamanlarıyla süreci desteklemeli ve beslemelidir. Yalnız bir amigo kız olmayın, tüm ekibinizin ponponlarını sallaması gerekiyor!
• Zayıf iletişim, tüm ekip çalışmasının Aşil topuğudur . Prototip sprint, kalıcı iletişim sorunlarını çözmeyecek, ancak tüm ekip neredeyse anında işbirliğine dayalı bir iş akışına daldığı için bunları daha kısa sürede ön plana çıkaracaktır. Siz fikir birliğine ve ilk yaptığınız artışa doğru çalışırken, halihazırda var olan herhangi bir iletişim sorunu erken ve sıklıkla bir prototip sprintinde ortaya çıkacaktır. İletişimi geliştirme fırsatını benimseyin ve tüm ekibi çözüm bulmaya dahil edin.
• Doğru ön uç çerçevesini seçin . Halihazırda bir çerçeveniz yoksa, ekibinizin iş akışına uyan bir çerçeve bulmadan önce çeşitli ön uç çerçevelerini denemeniz gerekebilir. Fomantic veya Bulma gibi minimal çerçevelere bakmanızı ve çanlar ve ıslıklarla çıkmaza girmemenizi öneririm. Ancak, doğru çerçeve her zaman ekibiniz için işe yarayan çerçevedir.
• UI/UX ekibinin bir konfor seviyesi geliştirmesi ve ön uç çerçeveye erişim sağlaması gerekir. İdeal olarak, gereksiz aktarımdan ve bir ortamdan diğerine (yani Sketch'ten prototipe) çeviri ihtiyacından kaçınarak doğrudan prototip üzerinde çalışacaklardır. Ön uç ekibinizin CSS ve HTML'ye aşinalığı yoksa, eşleştirilmiş bir yaklaşım (bir tasarımcı ve bir programcının çerçeve üzerinde birlikte çalışması) da iyi sonuç verir.
• Son olarak, bir takım olarak daha iyi ve daha hızlı olacağınızı unutmayın! Üretken bir prototip sprint çalıştırmak, pratikle büyüyen bir beceridir.

Sonra ne olur

İlk sprintin tamamlanmış artışı – işlevsel, düşük kaliteli prototip – takip eden tüm sprintler için zemin hazırlar. Çalışan bir prototip ile kullanılabilirlik, erişilebilirlik ve yanıt verme için kullanıcı testi hemen başlayabilir ve gelecekteki sprintlerin UX tarafından bilgilendirilmesini sağlar.

Prototip sprint, herhangi bir scrum süreci için harika bir başlangıçtır, ancak projelerimde, bir sonraki adımımız, UI/UX'in geliştirmeden yarım veya tam bir sprint önce çalıştığı, keşif yaparak ve prototipi görsel olarak güncelleyerek çift yollu bir iş akışına geçmektir. yeni görüşleri yansıtır.

Prototip, UX araştırmaları ve gerçekçi işlevsel ihtiyaçlarla beslenerek organik olarak gelişir ve giderek daha rafine hale gelir. Prototip sprint sırasında mevcut olmayan bu bilgi, yalnızca proje ilerledikçe aşamalı olarak ortaya çıkar. UI/UX ve geliştirme, çift yönlü çevik süreç aracılığıyla birbirlerinin iş akışlarını besler.

İnşa edilecek tasarımdan geliştirme aşamasına geçiş veya tasarımdan dış görünüm için geliştirilmiş bir uygulama yoktur. Bunun yerine, prototip sprint, tüm grubu baştan dahil eder ve proje boyunca işbirlikçi bir çevik iş akışı için güçlü bir temel oluşturur.

Bir prototip sprintinden kaynaklanan yol gösterici vizyon mükemmel olmayacak ve daha fazla şey öğrenildikçe muhtemelen değişecektir, ancak başlangıçta bir projenin diğer herhangi bir aşamasında olduğundan daha az şey bildiğimizi kabul etmek, çevik iş akışının merkezinde yer alır. Aynı felsefeyi proje vizyonunun ortaya çıkışına ve bir prototip sprint yoluyla tasarımın ortaya çıkmasına uyguladığımızda, sonuç, eyleme geçirilebilir bir tamamlanmış artış, gerçekten faydalı eserler, paylaşılan katılım ve proje boyunca sürdürülebilecek bir ekip çalışması ve işbirliği modelidir. .

Ajans Ayarları Hakkında Bir Not

Bir ajansta çalışıyorsanız, bu yaklaşımın zor bir satış olacağını düşünüyor olabilirsiniz. Ne yazık ki, muhtemelen haklısın. Çoğu kurum, doğası gereği çevik değildir ve genellikle resmi onay ve yolun aşağısında değişiklik yapmanın dikkatlice belgelenmiş yansımaları ile, toplam proje devri için aktif olarak çaba gösterir. Çevik olmayan bir organizasyonda bir prototip sprintini savunmak başlangıç ​​değildir: bu onların DNA'sında yoktur. Bir kuruluş, çevik ve disiplinler arası ekipleri benimsediğinde, aktarmasız prototip sprint'in süreçlerini iyileştirip iyileştirmeyeceğini kolayca değerlendirebilirler.

Çözüm

Sprint 0 ve tasarım sprintleri, birçok scrum ekibinin karşılaştığı gerçek zorlukları ele alır: vizyon eksikliği, entegre tasarım eksikliği veya her ikisi. Bunlar anlaşılabilir ve mantıklı yanıtlardır, ancak yüksek değer sağlamazlar veya güçlü çevik ekiplere katkıda bulunmazlar.

Bunları bir prototip sprint ile değiştirmek, Sprint 0'ın dezavantajlarını ele almanın ve sprint tasarlamanın pratik bir yoludur ve aynı zamanda gelecekteki sprintler sırasında daha güçlü çevik işbirliği için zemin hazırlar.

Bir prototip sprint, tüm ekibin yeteneklerini kullanır, gerekli vizyonu oluşturur, ekibin ilk yaptığı artışla sonuçlanır ve proje devrini önler. Bu süreç sayesinde ekipler, proje vizyonunun ortak sahipliğini ve çevik ruhta disiplinler arası işbirliği için daha güçlü bir temel oluşturur.

SmashingMag'de Daha Fazla Okuma :

• Daha İyi Bir Kolaylaştırıcı Olmak
• Yarı Zamanlı Ekipler İçin Çevik Uyarlama
• Proje Retrospektiflerinin Önemi
• Kuruluşunuza Daha İyi Bir Tasarım Süreci Getirmek