Bir Sprint önde çalışan UX tasarımcıları

UX tasarımcılarımız genellikle Sprint X'te geliştiricilerin Sprint X + 1'de uygulayacakları bir hikayeye sahiptir (UX tasarımcıları ve geliştiricileri / testçileri tek bir ekiptedir). Bunun mantıklı olduğunu düşünüyorum çünkü ekran modelleriniz ve net spesifikasyonlarınız yoksa Sprint Planlama sırasında işi gerçekten tahmin edemezsiniz.

Ancak Scrum'da yalnızca kullanıcıya değer sağlayan kullanıcı öykülerine sahip olmanız gerekir. Bizim durumumuzda UX tasarım öyküleri böyle bir değer sağlamaz (daha çok bir biriktirme bakım faaliyeti gibidir). Ayrıca genellikle Scrum antrenörleri Sprint başlamadan önce tam teknik özelliklere sahip olmanızı önermez, bu da anlaşılması zor bulduğum bir öneri.

Yaklaşımımızda herhangi bir dezavantaj görüyor musunuz? Bizim için işe yarıyor gibi görünüyor, ama Scrum ilkelerine biraz aykırı.

Ancak Scrum'da yalnızca kullanıcıya değer sağlayan kullanıcı öykülerine sahip olmanız gerekir.

Değer yalnızca sevk edilebilir kod satırlarında ölçülmez.

İyi tasarlanmış bir kullanıcı arayüzüne sahip olmanın herhangi bir değer sağlamadığını ima ediyorsunuz. Tabii ki öyle. Açıkçası son kullanıcıya değer vardır, ancak geliştirme ekibiniz için de değer vardır, ki bu tamamen geçerli bir paydaştır. İşinizi yapacak araç ve gereçlere sahip değilseniz, son kullanıcıya değer veremezsiniz.

Scrum dogmaya takılma. Scrum sizi daha verimli hale getirmek için orada. Kullanıcı arayüzünü uygulamadan önce bir UX hikayesi yapmak daha iyi bir yazılım sunmanıza yardımcı oluyorsa yapın.

Ana dezavantajları şunlardır:

1. Boru astarlısınız: tasarımcılarınız geç kalırsa, geliştiricileriniz işsiz kalır; geliştiricileriniz geç kalırsa, tasarımcınız nihayetinde birden fazla yineleme çalışacaktır. Bu istikrarlı bir durum değil - sürdürülebilir değil .

2. Tasarımcılarınız önceden çalışıyor, geliştirilebilecek veya geliştirilemeyecek hikayeler için ücret ödüyorsunuz. Nadiren olsa bile, hala para atıyorsunuz.

3. UX tasarımcılarınız geliştiricileri dahil etmeden önceden kararlar alıyorlar. Yararlı içgörüler eksik ve tasarımların tamamen yanlış veya gerçekçi olmama riskini artırıyorsunuz. Bu oldukça yaygındır, çünkü UX tasarımı "soyut" bir çalışma değildir - uygulamanın özelliklerinden (teknik olarak yapılması / önerilmesi veya yapılması gerekenler dahil) hazırlanmalıdır.

4. Geliştiricilerinizin hariç tutulması veya yetkilendirilmemesi, bir proje yürütmenin sürdürülebilir bir yolu değildir.

5. Tasarımcılar değer vermiyorlar: bu, imkansız olmasa bile, çalışmalarına doğru öncelik vermenin zor olduğu anlamına geliyor. Genellikle, geliştirici çalışmalarına farklı kaygılar, değer, sonraki sprintte fizibilite, çaba miktarı kullanılarak öncelik verilir. Onları "uydurmak" için veya yararlı tartışmalar nedeniyle birçok zaman hikayesi müzakere edilir ve değiştirilir: bunlardan herhangi biri kullanıcı arayüzünü değiştirirse (ve yalnızca bir uygulama detayı değilse bunu yaptığını varsayabilirsiniz), ne yaparsınız? hikaye ile? Artık oynayamazsın.

6. Tasarımcılar için bir yinelemeye sığabilecek bir hikayenin geliştiriciler için bir yinelemeye uyduğunu varsayıyorsunuz: hikayeleri nasıl bölebilirsiniz, böylece bu varsayım doğru mu?

Bunu iki nedenden dolayı seviyorum:

1. sizin için çalışıyor gibi görünüyor; başarı ile tartışmak zor!
2. UX ekibi hikayeyi alır ve sohbete erken başlar - ve sohbetler bir tür öykü noktasıdır

Scrum'ın temel bir gereksinimi, scrum ekibinin potansiyel olarak serbest bırakılabilir bir ürün oluşturmak için gereken tüm becerilere sahip olmasıdır. Açıkladığınız durumda, bu gerçekleşmiyor.

UX ekibi potansiyel olarak serbest bırakılabilir bir ürün üretmemektedir ve scrum ekibi, gerekli tüm becerilere sahip olmadıkları için dikey işlev dilimleri üretemezler. Bunlar işlev bozuklukları.

Sklivvz, yukarıdaki işlev bozukluklarının yol açabileceği sorunlar hakkında mükemmel bir yazı yazmıştır. Özetle, Scrum uyguladığınızı sanmıyorum.

Ama bunda kesinlikle yanlış bir şey yok. Hepinize değer katan bir çalışma yöntemi keşfettiyseniz ve bundan memnunsanız, yapmaya devam edin. Tek tavsiyem sık sık denetlemek ve uyum sağlamak olacaktır.

Bununla birlikte, amacınız Scrum kullanarak yazılım sunmaksa, belirlenen işlev bozukluklarını ele almanız gerektiğini unutmayın.

Burada biri kullanıcı merkezli tasarım, diğeri de sprint hizalama ile ilgili iki sorun var.

İlk olarak : Kullanıcı öyküleri, yalnızca biriktirme listesi ile değil, kullanıcı ihtiyaçları ile uyumlu olmalıdır. UX öykülerinin kullanıcılara açık değeri olmalıdır. Bu tam bir spesifikasyon ve kısa bir açıklama gerektirmez,

"Kullanıcılar, birden çok sayfaya bölünmek yerine tek bir sayfada hesap etkinliğine daha kolay erişebilecekler"

çeşitli uygulamalara uyarlanabilir ve uyarlanabilir olmakla birlikte, kullanıcı için değer konusunda hala nettir (hesap etkinliğine daha kolay erişim).

İkincisi : Sprint hizalaması. UX, sprint X'te geliştiricilerin X + 1 baharında uyguladığı özellikleri tasarlar. Pratikte, bu birçok dükkanda olur ve bazen daha çok sprint X + 2 veya X + 3'te uygulama gibi olabilir. Sıkı bir nit ve deneyimli ekiple bu kurulum işe yarayabilir. Yeni bir ekibiniz veya ekibin diğer üyelerinin beceri setlerine, tercihlerine, alışkanlıklarına, çalışma tarzlarına ve eğilimlerine aşina olmayan yeni üyeleriniz varsa zorlaşır. 6 aydan daha az bir süredir birlikte çalışıyorsanız, bu bir sorun olabilir.

Geri adım atın ve yeniden değerlendirin. Olumlu tarafta, bir nimet olan UX tasarımcıları ve geliştiricileri yan yana çalışıyor. Hikayelerinizin kullanıcılar için net bir değere sahip olduğundan emin olun.

Gördüğüm olası sorunlardan biri Scrum'da sprint N + 1 kapsamının normalde başlamadan hemen önce belirlenmesidir. Hangi hikayelerin kapsamda olacağını bilmeden önce sprint N'de sprint N + 1 hikayeleri için UX'i nasıl yapabilirsiniz? Sprint N'nin başlangıcında sprint N + 1 kapsamını düzeltmeye karar verirseniz, biraz esneklik kaybedersiniz.

Ancak Scrum'da yalnızca kullanıcıya değer sağlayan kullanıcı öykülerine sahip olmanız gerekir. Bizim durumumuzda UX tasarım öyküleri böyle bir değer sağlamaz (daha çok bir biriktirme bakım faaliyeti gibidir).

Gördüğüm gibi, kullanıcılarına çok fazla değer sağlıyorlar. Mesele şu ki: kullanıcıları şirketin son kullanıcısı değil, kullanıcıları sprint X + 1'de bu özelliği uygulayacak geliştirme ekibi.

Sürecin dinine takılıp kalıyorsun ve scrum / agile'ın yanlış kullanıldığını ve kullanıcıların yanlış etiketlendiğini görüyorum. Scrum evrensel bir araç değil, bir amaç için bir araçtır.

Grubunuzun kullanıcılarınızın kimler olduğunu yanlış etiketlediğini ve yanlış kitleyi planladığını düşünüyorum.

UX grubu scrum'ı klasik şekilde, kullanıcı değerini ve bazı sihirli son kullanıcılardan gelen girdilere çevik adaptasyonu kullanıyor. Kullanıcıları olan onlar. Grubunuz scrum'u kötüye kullanıyor çünkü mevcut bir tasarımın çalışması için sadece mekaniği dolduruyorsunuz, çevik bir şey gerekmiyor ve scrum yönetim takibi rolünü dolduruyor.

Bu yüzden bu sizin için yanlış geliyor, aslında hiçbir şekilde scrum'a ihtiyacınız yok veya bundan faydalanmıyorsunuz çünkü bir hizmet grubundasınız ve işiniz zaten çevik / scrum parçalarını yapmış olan UX insanlarından ileriye doğru akıyor.

Orada gerçekten kötü bir şey yok, size söylenenden farklı bir süreç var.