Scrum projesinde UX kimi yapar?

TAMAM. Diyelim ki bir ders kitabı scrum projesi üzerinde çalışıyorsunuz. Bir ürün sahibiyle işbirliği yapan bir scrum ustanız var. Bir sonraki sürat UI-ağırdır - senin kodlayıcılar ekranları oluşturmaya başlamak zaman, gerçekten sahip olmak istiyorum bazı onlar gibi görünmek için gidiyoruz fikir.

Tel kafeslemeyi kim ve ne zaman yapıyor? Ürün sahibi mi? Ürün sahibini destekleyen biri var mı? Scrum ustası mı? Bir UX uzmanınız varsa , sprint başladıktan sonra kodlayıcılarla birlikte çalışıyorlar mı yoksa geliştiricilerin yaptığı işi yönlendirmek ve bilgilendirmek için hikaye kartlarınızın ve kısıtlamalarınızın yanında oturan tel kafesler ve maketler önlüyorlar mı?

Biraz UX yardımına ihtiyacımız olduğundan eminim, ama nereye uygulayacağınızdan gerçekten emin değilim ...

EDIT: Soruyu yeniden ifade edeyim.

Çevik bir projede nasıl tutarlı, yüksek kaliteli kullanıcı deneyimi sunuyorsunuz?

Etkileşim tasarımcısı

UX! = UI Bir programcı olmayan popüler inanışın aksine, iyi bir kullanıcı deneyimi sunmak için deneyimli bir etkileşim tasarımcısına ihtiyacınız var . UX yapabileceklerini düşünen tüm programcılar için (bu beni içeriyor) bunu söyleyeyim. Etkileşim tasarımında iyi olmak, programlamada iyi olmak için en az zaman gerektirir. Saf etkileşim tasarımı yapmak için ne kadar zaman harcadınız?

İlk aşamada etkileşim tasarımcılarının sorumluluğu:

1. Çözümün asıl hedeflerini ürün sahibinden çıkarma
2. Çözümü kullanacak kişileri tanımlayın.
3. Çözümün nasıl kullanılacağına dair hikayeler olan senaryolar yazın.
4. UX açısından belirsizliğe çok az yer bırakan bir tasarım belgesi derleyin

Proje sırasında bu tasarımcıların görevi bu yönergelere uyulduğundan emin olmak ve ortaya çıkacak ek sorunları ele almaktır (ve olacaktır).

Pek çok programcı bu yaklaşımı benimseyecektir. Eminim ki herkes "harika" arayüzler tasarlayabilecek istisna olduklarını düşünüyor, muhtemelen değilsiniz. Öte yandan, iyi bir etkileşim tasarımcısı - programcı ilişkisi, programcı için genellikle çok güzeldir ve "aptal bir spesifikasyona" karşı savaşmak zorunda değildirler. Maalesef iyi etkileşim tasarımcılarını deneyimlerime göre bulmak zor ama oradalar.

Her zaman olduğu gibi Alan Coopers'ın konuyla ilgili kitaplarını derinden tavsiye ediyorum ("Yüz Hakkında" ve "Mahkmatmlar iltica yapıyor")

UX erkeğinin çalışmasını ekibin geri kalanıyla aynı şekilde düzenlemenizi öneririm. Ekibin eşit bir üyesi olarak görülmeli, stand-up'lara katılmalı ve programcılar ile yakın iletişim kurmalıdır.

İdeal olarak, maketler en az bir sprint önceden yapılmalıdır, ancak daha küçük özellikler için maketlerin mevcut iterasyon için planlanan bir hikayenin alt görevi olarak düşünülmesi mantıklı olabilir.

Her zaman olduğu gibi çevik, sağduyunuzu kullanın, farklı yaklaşımlarla denemeler yapın ve kendi durumunuza uygun olana sadık kalın.

Bence bu bir şekilde özel bir şekilde ele alınması gereken özel bir durum. Scrum ustası kesinlikle buna katılmayacak - bu onun rolü değil. Takım genellikle bir grup geliştiricidir ve birçoğunun UX ile deneyimi yoktur ve onları buna zorlamak için zaman kaybı olacaktır. UX uzmanını işe alacaksınız ve uzman ekibin bir parçası olmayacak - takım çapraz fonksiyonel olmalı ve UX uzmanı muhtemelen bir geliştirici olmayacaktır. Ayrıca UX uzmanı tüm süre boyunca projede olmayacak. UX uzmanı, gelecek kullanıcı hikayeleri için maketler ve tel çerçeveler hazırlamak için ürün sahibiyle bir sprint önde çalışacak, böylece takım bir sonraki sprint'te ne yapılması gerektiğini bilebilir - maketler planlama toplantısında hazır olacak.

Düzenle:

Biraz daha araştırma yaptım, çünkü bunu bir yerde okuduğumu biliyordum ve sonunda bunu Mike Cohn'un Scrum Kullanarak Agile ile Başarılı Olmak bölümünde buldum . Mike, takımdaki UX tasarımcısının rolünü tam olarak tartışıyor. İlk açıklaması benimkine benzer ve şirket geliştirme yöntemini şelaleden Scrum'a değiştirdiğinde doğal bir değişim olduğunu düşünüyor, ancak daha sonra bunu tavsiye edilmeyen bir şekilde sonuçlandırıyor. Bunun nedeni, UX tasarımcıları ekibin bir parçası değilse, kendilerini ayrı ekip olarak düşünebilirler ve geliştirme ekibinin bağlılığını paylaşmak zorunda kalmazlar.

Buna rağmen @Adam Byrtek'in cevabı doğru gibi görünüyor. UX Guy'ı ekibin bir parçası haline getirin ve şu anda uygulanmış kullanıcı hikayelerinde geliştiricilerle işbirliği yapmasına izin verin. UX adamının tüm zamanını almayacak, bu yüzden bir veya iki sprint için maketler ve tel çerçeveler hazırlamak için ürün sahibi veya müşteri ile işbirliği yapacak.

Jakob Nielsen'in uyarı kutusuna abone oldum (çoğunlukla sinir bozucu web tasarım uygulamalarına eleştirisi nedeniyle) ve son zamanlarda konu hakkında bazı makaleler okuduğumu hatırlıyorum (tüm çevik geliştirme sürecini çok az anlasam da), belki de sizin için herhangi bir kullanım:

• Çevik Kullanıcı Deneyimi Projeleri
• Çevik Geliştirme Projeleri ve Kullanılabilirlik

"Ders kitabı Scrum" için:

Öncelikle, Scrum Masters Ürün Sahipleriyle işbirliği yapmaz - SM ve PO dahil tüm ekibin sistemi kurmak için işbirliği yapması dışında hiçbir anlamda değil.

İkincisi, Scrum takımlarının çapraz fonksiyonel ekip üyeleriyle homojen olması gerekiyordu. Yani "UX Guy" ınız olmazdı.

Ayrıca, muhtemelen işlevsel kodun önünde UX bir Sprint oluşturmazsınız. Özellikler tamamen tek bir Sprint içinde sunulur. Bir özellikle ilişkili UX, tek bir Sprint'te fonksiyonel kodla birlikte iletilemeyecek kadar karmaşıksa, tüm özelliği UX öğeleri de dahil olmak üzere tek bir Sprint'te yapılabilecek bir şeye bölersiniz.

UX bir şelale projesinde kimler yapıyor? Bir XP projesinde anabilgisayar geliştirme kim yapar?

Proje metodolojisi önemli değil. Her teknoloji projesi belirli özel roller gerektirir. Bazen, bir proje tamamen lisanslı ve bağlı bir "etkileşim tasarımcısı" (ne anlama gelirse) olmadan kurtulabilir. Bazen uzman birisine ihtiyacınız olabilir. Fakat aynı şey diğer her rol için de söylenebilir.

Bu yüzden, çevik kullanarak yüksek kaliteli kullanıcı deneyimi sunma konusundaki ikinci sorunuz üzerine. İş analisti ve müşteriyi erken ve sık sık dahil ederek dahil olduğum son scrum projesinde bunu başardık. Ayrıca, UX için özellikle iyi bir göze sahip bir geliştiricimiz vardı. Devs yaptıktan sonra geliştiricilerin üzerinde çalıştığı kullanıcı arayüzlerine küçük değişiklikler yapma eğilimindeydi.

Her sprint sonunda mükemmel UX sunmadık. Demolar genellikle bir veya iki konuyu UX perspektifinden ortaya çıkardı. Ama bir sonraki sprint için bunları düzelttik (eğer müşteriye değerse) ve üretime bıraktığımız zaman çok sağlam bir UX'e sahiptik.

UX ile, kullanıcı arayüzü tasarımcısı demek istiyorsan, bunlar ekip için başka bir rol veya kaynaktır. Kullanıcı Arayüzü tasarımı, herhangi bir tasarım gibi, bir projeyi de keser. Önden yapılması gereken makul miktarda mimari / tasarım çalışması var ve ilerledikçe yapılabilecek bir miktar var.

UI tasarım görevlerinin genellikle bir geliştirme sprint ile aynı kapsama uymadığına dikkat edilmelidir. Bir UI bileşeni tasarlarken, tasarımın uygulanması çok sayıda sprint alabilir.

Uygulamada, UI / UX tasarımcılarının çözüm boyunca tutarlı olması gereken yönlerle başa çıkmak için makul bir teslim süresine ihtiyaç duyduklarını düşünüyorum. Bunu yazılım mimarisi olarak düşünmeyi seviyorum. Belirli bileşen tasarımı genellikle uygulamadan önce bir sprint yapılabilir, ancak tasarımcılar başladıktan sonra, uygulamanın hızını aşabileceklerini fark ettim. Daha sonraki sprint'ler, görünüm şekillendirmeye ve keşfetmeye ve çözüm şekillenmeye başladığında kullanılabilirlik geri bildirimi almak için iyi yerler olma eğilimindedir. Daha sonraki bu alıştırmaların sonuçları bir sonraki sprint planlamasına geri beslenir.