Agile geliştirmede kullanıcı arayüzü tasarımı ve ilgili özellik desteği ile nasıl başa çıkılır?


11

Çevik bir geliştirme sürecinde genellikle ana odak Kullanıcı hikayeleri üzerindedir, ancak bazen tek bir gereksinim birkaç kullanıcı hikayesine yayılabilir.

Örneğin, istemci bir forumdaki tüm kullanıcılar için bir arama sayfası isteyebilir ve her kullanıcı üzerinde kullanıcı yasaklama, kullanıcı silme, Parolayı sıfırlama vb. Gibi çeşitli eylemler gerçekleştirilebilir.

Bu özelliği en az 4 kullanıcı hikayesine ayırabiliriz:

  1. Kullanıcı ara
  2. Kullanıcıyı yasakla
  3. Kullanıcıyı sil
  4. Şifreyi yenile

Kullanıcı arayüzü tasarımcısı böyle bir kullanıcı arayüzünü nasıl uygular? İlk kullanıcı hikayesinde çalışmalı ve daha sonra kullanıcı arayüzüne daha fazla özellik eklemeye başlamalı mı? Ancak, son kullanıcı arayüzünün dağıtılacağını düşünüyorum!

Tüm özellik üzerinde çalışmaya karar verirse (arama + eylemler), düşük öncelikli ve arama işlevselliği yapıldıktan sonra birkaç yineleme uygulanacaksa eylemler ne olur?


6
Bu, bazı insanlar tarafından tasvir edilen, onu tanımlasanız da, bir proje yönetim aracı dışında bir şey olan yanlış fikri vurgular. Yine de tüm ürüne mimari bir bakış açısıyla bakacak ve tüm öykülerinizin tutarlı bir şeye katkıda bulunduğundan emin olacak birine ihtiyacınız var.
Blrfl

aşağı seçmenler plz neden açıklamak?
Songo

@Songo: Hayır, aşağı seçmenler normalde açıklama yapmazlar, bu çok fazla çaba. :-(
Giorgio

Yanıtlar:


13

Tekrarlayın. Doğrudan kullanıcılarla çalışıyorsunuz, değil mi? Bu yüzden asla gerçekten dağınık olmamalı.

Önce arama sayfasını yapın. Siz ve kullanıcılar, sonuçlar üzerinde işlem yapmak isteyebileceklerini aklınızda bulundurmalısınız. Kullanıcılar hoşuna gitti mi? Tamam, aramanız var.

Şimdi "Parolayı Değiştir" i (veya öncelikli sırada ne varsa) ekleyin. Hata! Arama sayfasını biraz değiştirmemiz gerekiyor - değişiklik genellikle oyunun bir parçası. Kullanıcılar beğendikleri sonuçları sever mi? İyi.

Şimdi bir sonraki öğeyi ve bir sonraki öğeyi ekleyin ...

Çevik yaklaşım her zaman hemen geri bildirim aldığınızı söylüyor, bu yüzden iyi olmalısınız.

Bununla birlikte, aynı yinelemede bu hikayelerden 2 tanesine saldıramayacağınızın gerçek bir nedeni yoktur (silme kullanıcısı VE kullanıcı yasağı ekleyerek). Anahtar, doğru olduğundan emin olmak için her zaman müşteriyle çalışmaktır.

Kullanıcılarınızın orijinal "tasarımınız" tamamlandıktan ve uygulandıktan sonra bu arama ekranından yapmak istedikleri başka bir şeyi düşündükleriyle sonuçlanırsınız. Böylece, yine de bir noktada değiştireceksiniz . Her şeye bu beklentiyle yaklaşın ve iyi olmalısınız.


8

Bunu çok söylediğimi hissediyorum. Çevik, geleceği görmezden gelmek ve kendinizi bir köşeye tasarlamak için kör bahisler koymanız gerektiği anlamına gelmez. Çevik nasıl hakkındadır teslim işlevselliği ve nasıl yapmak için çok az vardır tasarım işlevselliği.

Başka bir deyişle, kısa vadede işlevsellik sunumunu ertelemediği sürece, tasarımınızı oluştururken geleceğe istediğiniz kadar bakmak iyi olur.

Özel örneğinizde bunun anlamı, devam edip kullanıcı arayüzünü, daha sonra eylem eklemenin kolay olacağı şekilde tasarlamanızdır. Bununla birlikte, eylemler tasarımını doğru bir şekilde yapmaya çalışmak, temel kullanıcı aramasının bir yinelemeyle teslim edilmesini geciktirirse, herhangi bir işlem yapmadan bir aramanın müşteriye değeri olduğunu varsayarak, önce eylemsiz bir tasarım yapmak daha iyidir.

Kendinize sormanız gereken soru, "Bu tasarım işi ilk teslimatımı geciktiriyor mu?" Çoğu zaman, cevap hayır olacaktır. Yine de bir tasarım yapmak zorundasınız, tek yapmanız gereken bazı tasarım kriterleri.


+1: Çok iyi bir cevap: "Çevik, işlevselliği nasıl sağladığınızla ilgilidir ve işlevselliği nasıl tasarladığınızla çok az ilgilidir." Çevik tasarımın yokluğunu haklı çıkarmak için çok sık çevik bir bahane olarak kullanıldığını düşünüyorum (örneğin, bir geliştirici bunu yapmaya istekli veya yapamıyorsa.). Bunun yerine, genel plan ve mimari hazırlandıktan sonra aktiviteler (kullanıcı hikayeleri ve sprintler) planlanmalıdır (elbette projeye devam ederken mimariyi ayarlamanız gerekebilir).
Giorgio

1

İlk kullanıcı hikayesi tüm arayüzün tasarımı olabilir - sadece bir parçasını tasarlamaları gerekmez. İş değeri katan bir bütün olarak tasarım.

Bununla birlikte, burada en az iki farklı özellik görüyorum: kullanıcıları arama yeteneği ve bir veya daha fazla kullanıcı üzerinde bir işlev gerçekleştirme yeteneği. Eğer daha mantıklı olursa tasarımcı her biriyle başa çıkabilirdi.

Unutmayın: amaç kaliteli yazılım sunmaktır, bazı metodolojileri körü körüne takip etmemek. Kendinize tasarımı parçalara ayırmanın bu hedefe yardım edip etmediğini sorun. Scrum polisi yok, sadece mutlu ya da memnun olmayan müşteriler var.


1

Bir Agile / Extreme programlama fabrikasında staj yapma fırsatı buldum. Yinelemeli geliştirme sürecini yürütmek için hikaye kartları kullanıyorlardı. Her hikaye kartı bir uygulama veya değişiklik getirdi. Anahtar kullanıcı etkileşimi idi. Yazılım kullanıcısı ile etkileşime girmeden kullanıcı için bir arabirimi nasıl başarılı bir şekilde tasarlayabiliriz?

Olası bir senaryo, kullanıcının önce ne istediğine karar vermek için kullanıcı etkileşimi ile başlamaktır. Ardından, yinelenen bir şekilde, kullanıcı arayüzünü artan geri bildirime, kullanıcı önceliğine ve kullanıcının sahip olması gereken şeylere göre tasarlayın.

Kullanıcı öyküleri, kullanıcının nasıl etkileşimde bulunacağını, hangi düzeyde ve hangi şekilde olacağını yönlendirmek için vardır. Ancak bunlar yalnızca kullanıcıyla etkileşim kurana kadar yaklaşık değerlerdir. Tümü belirli bir şey isteyen çok sayıda kullanıcı varsa, kullanıcı arayüzü için bazı taban çizgileri tanımlamak için küçük bir insan anketi olabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.